Cuando una solicitud correcta sigue siendo un fallo
Imagina que llevas semanas hablando con el mismo personaje. Su voz te resulta familiar, su idioma es coherente y sus respuestas se sienten lúcidas y vivas.
De pronto, sin cambiar el personaje ni el modelo, algo deja de encajar.
La siguiente respuesta tarda diez segundos en empezar. Una función que depende de una salida estructurada deja de funcionar. El personaje comienza a divagar, introduce fragmentos de otro idioma o responde con un estilo que parece propio de un modelo mucho más débil.
Desde el punto de vista del servidor, nada ha fallado. La API ha devuelto 200 OK, han llegado tokens y la solicitud se ha facturado.
Desde el punto de vista del usuario, el modelo acaba de empeorar.
Esa diferencia es la razón por la que construimos para Reverie un sistema de sondas canario y cuarentena de rutas por proveedor.
Un nombre de modelo, muchos entornos de inferencia
OpenRouter es nuestra principal pasarela de modelos. Una de sus ventajas es que un solo modelo puede estar disponible a través de muchos proveedores de inferencia independientes. Si uno no está disponible, otro puede aceptar la solicitud. Así obtenemos más capacidad, precios competitivos y mayor resiliencia que dependiendo de un único endpoint.
Pero también aparece una variable invisible.
El nombre del modelo puede seguir siendo el mismo mientras la infraestructura que lo sirve cambia entre solicitudes. Cada proveedor puede utilizar un motor de inferencia, hardware, nivel de cuantización, parser, plantilla de chat, cola o capa adicional de políticas diferentes.
La documentación de enrutamiento de proveedores de OpenRouter explica que su ruta predeterminada tiene en cuenta la disponibilidad reciente y el precio, y conserva otros proveedores como alternativas. Son señales importantes, pero un endpoint puede estar disponible, ser barato y aun así producir un resultado inaceptable para un producto concreto.
OpenRouter también ha hablado públicamente de diferencias medibles entre proveedores que sirven el mismo modelo. En teoría, los mismos pesos con la misma precisión deberían comportarse de forma parecida. En producción, servir un modelo grande es complejo y aparecen diferencias.
Qué entendemos por «degradación del modelo»
«Degradación del modelo» no es un diagnóstico único y estandarizado, ni significa automáticamente que un proveedor haya sustituido el modelo por otro más pequeño de forma intencionada.
Usamos el término de forma operativa: un endpoint de inferencia está degradado cuando deja de conservar el comportamiento, las capacidades o el rendimiento interactivo que esperamos del modelo solicitado ante prompts representativos, aunque la solicitud pueda completarse técnicamente con éxito.
En Reverie, las formas más claras son:
- Degradación de latencia: la conexión se establece, pero el tiempo hasta el primer token es lo bastante largo como para romper la sensación de una conversación en directo.
- Degradación de capacidades: un endpoint del que se espera salida estructurada devuelve texto mal formado o deja de cumplir el schema.
- Degradación de comportamiento: las respuestas se corrompen, pierden coherencia, se repiten de forma inesperada o cambian visiblemente a otro idioma.
- Desajuste de políticas: un proveedor añade su propia capa de filtrado y convierte una escena admitida por Reverie en un rechazo, una respuesta vacía o una contestación truncada.
Puede haber muchas causas. Una cuantización de menor precisión puede afectar a prompts difíciles, como señalan tanto la documentación de OpenRouter como la investigación publicada sobre cuantización. Pero la cuantización no lo explica todo: los fallos del motor de inferencia, parsers de herramientas, errores del tokenizer o de la plantilla de chat, colas saturadas y middleware del proveedor pueden ser igual de importantes. OpenRouter ha observado que, en las llamadas a herramientas, los parsers suelen provocar más diferencias que la precisión por sí sola.
La pregunta importante no es «¿qué causa suena más sospechosa?», sino «¿podemos aislar el endpoint y reproducir el fallo?».
Dos casos que hicieron tangible el problema
No se trataba de una inquietud teórica.
En una comparación fijada a proveedores concretos, uno de ellos corrompió el comienzo de 19 de 20 respuestas al insertar puntuación o el fragmento de un token no relacionado. En otros catorce proveedores del mismo modelo, el problema apareció 0 veces en 49 respuestas. En el roleplay, donde el primer carácter suele ser un marcador de énfasis de Markdown, un solo byte extraño también podía romper el formato de toda la respuesta.
En otra prueba, un endpoint produjo una mezcla grave de portugués y español en 3 de 3 generaciones. El mismo prompt se mantuvo en portugués en el proveedor oficial del modelo y en los demás proveedores probados con la misma clase de precisión. «El modelo simplemente es inconsistente» dejó de ser una buena explicación: el defecto seguía al endpoint.
Estos fallos son sutiles porque no siempre generan excepciones. La monitorización de disponibilidad tradicional ve una API sana. El usuario ve un personaje que de repente ya no sabe hablar correctamente.
Nuestra respuesta: probar cada ruta, no solo el modelo
Cada treinta minutos, nuestro canario descubre los proveedores activos del modelo de chat predeterminado de Reverie. Después envía un pequeño conjunto de solicitudes sintéticas a cada uno, fijadas exclusivamente a ese proveedor y con los fallbacks desactivados.
Fijar la ruta es esencial. Si una sonda puede recurrir a un fallback, un segundo proveedor sano puede ocultar el fallo del primero. Necesitamos saber exactamente qué entorno produjo el resultado.
El sistema prueba cuatro contratos concretos que una máquina puede evaluar.
1. Tiempo hasta el primer token
En una conversación por streaming, el throughput solo representa la mitad de la experiencia. El primer token determina cuánto tiempo mira el usuario un indicador de carga.
Lo medimos directamente en el stream. Un proveedor que no produce texto en diez segundos falla la prueba de latencia. El umbral es deliberadamente generoso y una sola ronda lenta no basta para retirar un proveedor; la presión temporal de las colas existe.
2. Filtrado y rechazos silenciosos
Enviamos una continuación de roleplay fija y representativa del tráfico que Reverie admite. La prueba comprueba el motivo de finalización, patrones de rechazo de alta confianza y respuestas vacías.
También ejecutamos la prueba contra proveedores conocidos por filtrar, que actúan como controles positivos. Si un control pasa de forma inesperada, no declaramos sanos a todos los demás proveedores: marcamos la propia prueba como débil. Una prueba que ya no detecta su fallo conocido no demuestra que nada esté sano.
3. Salida estructurada
Solicitamos un objeto pequeño con un schema fijo y validamos el resultado. Tratamos de forma distinta un error de transporte y una salida mal formada: una conexión rota indica que el proveedor era inaccesible; una generación completada que no cumple el schema demuestra una regresión de capacidad.
«El endpoint declara que admite el parámetro» y «el endpoint lo respeta de forma fiable» no son la misma promesa.
4. Integridad del idioma
Reverie admite 17 idiomas de interfaz, así que una prueba rápida solo en inglés no detectaría algunos fallos que nuestros usuarios sí experimentan.
El canario rota por los idiomas admitidos con prompts sintéticos de roleplay. Un detector local y determinista busca un cambio de idioma claro en toda la respuesta, mezcla sostenida de idiomas y daños evidentes de codificación. No utiliza conversaciones reales ni pide a otro modelo una valoración subjetiva.
Una salida ambigua o demasiado corta es inconcluyente, no un fallo. Cuando detectamos una anomalía de idioma, el canario realiza de inmediato dos intentos de confirmación y exige una mayoría. En la siguiente ronda se repite el mismo idioma para que el proveedor no eluda la regla de rondas consecutivas solo porque la rotación haya avanzado.
Diseñamos el sistema para desconfiar de sus propias conclusiones
Retirar capacidad de inferencia automáticamente es útil, pero un falso positivo puede causar una interrupción mayor que el defecto original. Por eso el canario incluye varios frenos:
- Los errores de transporte no cuentan como fallos de calidad. Los timeouts, límites de tasa y respuestas 5xx congelan la puntuación en vez de avanzar una racha de suspensión.
- Una ronda mala no basta. Un proveedor debe fallar dos rondas consecutivas ejecutadas cada media hora.
- La observación y la aplicación están separadas. Podemos ejecutar el sistema en modo de observación, registrar qué proveedores se suspenderían, avisar a los administradores y medir falsos positivos antes de activar las acciones automáticas.
- La capacidad tiene un mínimo. El canario no suspende un proveedor si eso deja menos de dos proveedores de producción. En su lugar, avisa a un administrador.
- La recuperación también se prueba. Los proveedores suspendidos siguen recibiendo sondas. Dos rondas limpias consecutivas restauran un proveedor antes de tiempo.
- Los fallos repetidos escalan gradualmente. La suspensión dura un día en el primer incidente, tres en el siguiente y siete en los posteriores. Tras catorce días sin una nueva suspensión, el historial se desvanece y la escala vuelve a empezar.
El objetivo no es castigar a los proveedores. Es apartar el tráfico de los usuarios de una ruta cuyo mal estado podemos reproducir y dejar un camino claro de regreso cuando el problema se resuelva.
Tres capas de protección
La decisión final de ruta combina tres tipos de exclusión:
- Exclusiones integradas y revisadas para defectos o incompatibilidades de políticas que ya hemos medido y no queremos reintroducir por accidente.
- Exclusiones de incidentes en tiempo de ejecución que un administrador puede añadir inmediatamente, sin esperar a un despliegue.
- Suspensiones temporales del canario para proveedores que superan el umbral automático de fallos.
Estas listas se combinan en la preferencia provider.ignore de OpenRouter al crear una solicitud. El usuario no tiene que reintentar hasta que el azar elija un proveedor mejor: la ruta degradada deja de ser candidata.
Cada decisión automática queda registrada, los administradores reciben avisos cuando el estado cambia de forma relevante y una suspensión puede levantarse manualmente si es necesario.
Qué garantiza el sistema y qué no
El canario es deliberadamente limitado. Puede evaluar con código la latencia, la validez del schema, el filtrado de alta confianza, la integridad del idioma y la codificación. No pretende puntuar si un personaje es lo bastante divertido, emocionalmente perceptivo o fiel a una personalidad compleja.
Esas preguntas más amplias todavía requieren evaluaciones con prompts representativos, revisión humana, telemetría de producción y, sobre todo, informes de los usuarios.
El sistema tampoco implica que toda respuesta extraña demuestre una degradación. Los modelos generativos son probabilísticos. Una conversación larga puede acumular contexto contradictorio y una definición de personaje puede contener instrucciones que compiten entre sí. A veces, una respuesta rara es solo una respuesta rara.
Lo que ha cambiado es que «es el mismo modelo» ya no pone fin a nuestra investigación. Ahora podemos aislar la ruta, reproducir fallos objetivos y mantener el tráfico posterior lejos de ella.
La fiabilidad consiste en conservar la experiencia
El enrutamiento multiproveedor sigue siendo valioso. Da a Reverie la capacidad y la resiliencia necesarias para mantener disponibles las conversaciones cuando un endpoint individual deja de funcionar.
Pero la resiliencia no consiste solo en recibir una respuesta HTTP. Una contestación que llega demasiado tarde, pierde la estructura requerida, rechaza contenido admitido o cambia de idioma no es un resultado sano solo porque la factura diga que la solicitud tuvo éxito.
En un producto de personajes de IA, la fiabilidad significa algo más humano: el personaje debe seguir sintiéndose como el mismo personaje, sin importar qué máquina hable por él.
Ese es el estándar que protegen nuestras nuevas salvaguardas de enrutamiento.
Si notas un cambio repentino en la calidad o el idioma de las respuestas, envíanos un informe con el nombre del modelo y la hora aproximada. Esos datos nos ayudan a relacionar lo que viste con la ruta exacta que lo produjo.