Con la misma suscripción y casi la misma pregunta, la calidad de las respuestas puede variar. La mayoría de las veces la cuenta no ha sido alterada: el servidor ha enviado la solicitud a otro modelo. Este artículo explica los factores que influyen y el orden recomendado para diagnosticar el problema.
Aunque tengas un plan de nivel alto y hagas la misma pregunta, a veces recibes una respuesta detallada con un razonamiento completo y otras veces llega demasiado rápido, como si respondiera otra persona. La primera sospecha suele ser que algo cambió en la cuenta. En la mayoría de los casos la cuenta está bien: esa solicitud fue enrutada por el servidor hacia otro modelo.
Qué es realmente el enrutamiento
Los servicios de IA rara vez hacen que un solo modelo atienda todas las solicitudes. Normalmente distribuyen el tráfico entre varios modelos según reglas. Cada vez que llega una solicitud, el servidor evalúa varias condiciones antes de decidir quién la procesa.
| Condición | Cómo influye |
|---|---|
| Nivel de cuenta y cuota | El conjunto de modelos disponibles cambia según la suscripción y la cuota restante |
| Región y salida de red | El tipo y la estabilidad de la salida influyen en la evaluación de riesgo y, de forma indirecta, en la asignación |
| Longitud del contexto | Cuanto más larga es la conversación, menos información puede llegar completa al modelo |
| Tipo de tarea | Algunas solicitudes se consideran ligeras y se envían a modelos más pequeños |
| Carga actual | En horas punta, más solicitudes pueden desviarse a modelos que responden con mayor rapidez |
Desde el punto de vista de ingeniería, tiene sentido. Usar el modelo más grande para una petición como «pasa este texto a voz pasiva» haría difícil sostener tanto el coste como la velocidad de respuesta. Para el usuario, sin embargo, se percibe como una calidad irregular.
Cómo actúa cada condición
El nivel de cuenta y la cuota son los factores más directos. Distintos planes y distintos saldos de cuota dan acceso a conjuntos de modelos diferentes. Si aparece un aviso explícito de cuota o una función restringida, es un problema de cuota y no del mecanismo de enrutamiento. Conviene revisar por separado el estado de la suscripción y los avisos del servicio.
La región y la salida de red suelen subestimarse. Al entrar, una solicitud puede pasar por una evaluación de riesgo de la infraestructura, y el tipo y la reputación de la IP de salida influyen en esa decisión. Las IP de centros de datos, las IP de proxy compartidas por muchas personas, los nodos que cambian con frecuencia o las salidas con antecedentes anómalos pueden considerarse de mayor riesgo y recibir un tratamiento distinto. La web y las aplicaciones móviles exponen cantidades diferentes de información del entorno; la web puede aportar más, por lo que una misma cuenta puede comportarse de forma distinta según el cliente.
La longitud del contexto es la causa más frecuente. En conversaciones largas, la información antigua puede comprimirse o recortarse. Parece que el modelo se ha vuelto menos capaz, pero en realidad dispone de menos contexto. Lo correcto es abrir una conversación nueva y volver a proporcionar el contexto necesario, en vez de seguir preguntando después de miles de turnos.
La clasificación del tipo de tarea prioriza la eficiencia. Reescrituras sencillas o conversiones de formato pueden resolverse más rápido con un modelo ligero sin perder mucho en calidad, así que es razonable que el sistema las enrute así. Si quieres una respuesta profunda, explica la complejidad en el prompt: indica que requiere razonamiento en varios pasos y qué alternativas deben sopesarse. Eso facilita que se reconozca como una tarea compleja.
También influye la carga. En los periodos de máxima demanda pueden bajar tanto la calidad como la velocidad, por lo que conviene realizar las tareas complejas e importantes fuera de las horas punta cuando sea posible.
Orden de diagnóstico cuando baja la calidad
Primero, confirma el estado de la cuenta y la cuota. Revisa si hay avisos de límite o funciones restringidas; suelen ser fáciles de detectar y conviene descartarlos antes de nada.
Segundo, abre una conversación nueva, haz la misma pregunta y compara el resultado. Si mejora de forma clara, lo más probable es que el problema sea el contexto y no la cuenta.
Tercero, revisa el momento. Comprueba si el problema se concentra en determinados periodos de máxima demanda.
Cuarto, prueba otra salida de red. Fíjate en el tipo de salida: las IP de centros de datos y las IP de proxy compartidas por muchas personas son más propensas a activar evaluaciones de riesgo, y cambiar repetidamente entre nodos inestables también es una señal anómala.
Quinto, si todo lo anterior queda descartado, contacta con soporte o revisa la cuenta. Muchas personas se saltan los cuatro primeros pasos, sospechan de la cuenta de inmediato y pierden tiempo en reclamaciones que no atacan la causa real.
En qué se consume la cuota
Si te preocupa el consumo, recuerda que las cuotas suelen calcularse por uso y que el contexto se acumula. En cada turno de una misma conversación hay que arrastrar el historial anterior; cuantos más turnos, mayor es la carga de cada solicitud. Dividir una tarea larga en varias conversaciones cortas con objetivos claros puede ahorrar cuota y facilitar que cada petición llegue a un modelo adecuado.
Para medirlo de forma práctica, separa los tipos de tarea que utilizas con frecuencia. Ejecuta la misma tarea una vez en una conversación nueva, anota el consumo y compáralo con el de una conversación larga. La diferencia numérica suele ser más clara que la percepción subjetiva.
Cómo facilitar que una solicitud se procese con más profundidad
Divide las tareas largas y da a cada conversación un único objetivo claro. Indica el tipo de tarea, la profundidad esperada y el formato de salida; las preguntas vagas se clasifican con más facilidad como solicitudes simples. Vuelve a preguntar una conclusión importante con otra formulación o en otra conversación. Si los resultados difieren mucho, esa solicitud puede haber sido enviada a un modelo ligero. Convierte en plantillas los prompts habituales que ofrecen resultados estables en lugar de redactarlos desde cero cada vez.
También ayuda cambiar la forma de entender el servicio: piensa en un conjunto de capacidades que se distribuyen según reglas, no en un único modelo fijo. Así, cuando la calidad varíe, revisarás primero si la solicitud estaba suficientemente clara en lugar de sospechar de la cuenta o dedicar tiempo a una reclamación.
