La victoria que no lo fue
En Towards Data Science, Pratik Rupareliya describe un agente de IA de atención al cliente para un producto SaaS con unos 4M de usuarios mensuales, que corría todas las consultas en un solo modelo de razonamiento capaz y con una factura mensual de seis cifras. El equipo construyó la receta de consenso: un clasificador ligero al frente que etiquetaba cada consulta como “simple” o “compleja”, enviaba el 65% simple a un modelo que costaba la cuarta parte y dejaba el 35% complejo en el modelo capaz.
Era de manual. El clasificador logró 94% de calidad equivalente en un conjunto reservado de 5,000 consultas; el lanzamiento fue gradual; todas las métricas se mantuvieron en verde; la factura bajó a ~40% de su nivel anterior. El director de finanzas envió una nota de agradecimiento. Y luego, durante los tres meses siguientes, la satisfacción de los clientes bajó, la cancelación subió y el volumen de soporte humano creció, hasta que el costo inferido de la pérdida de calidad resultó ser, con una estimación conservadora, de 4 a 5× lo ahorrado. El equipo no había ganado. Había movido el costo a un lugar que no estaba midiendo.
Por qué los tableros siguieron en verde
La parte más importante de la historia es por qué nadie lo vio. La arquitectura de medición se había construido para un solo modelo, y la capa de enrutamiento rompió sin hacer ruido todos los supuestos sobre los que descansaba:
- La revisión agregada escondió la brecha. La revisión humana no se separaba por nivel, así que el 65% de muestras del modelo barato (equivalentes en el centro fácil) diluyó hasta volverlas invisibles las fallas en el extremo difícil.
- La suite de regresión era estática. Se había armado seis meses antes sin ninguna noción de enrutamiento y probaba una distribución idealizada: el modelo barato aprobó la suite y se degradó en el extremo real.
- El botón de retroalimentación tenía demasiado ruido. Unos 3 pulgares abajo por cada 1,000, sesgados hacia usuarios que ya estaban frustrados: incapaz de detectar nada que no fuera una regresión mayor.
Ninguno de estos problemas lo causó el enrutamiento; estaban latentes, y el enrutamiento los expuso. Con un solo modelo había una sola distribución de calidad que medir. El enrutamiento creó dos, y la arquitectura no podía verlas por separado. La desviación empezó en la semana tres, se interpretó mal como “cambio de versión del modelo del proveedor” en la semana seis y solo llegó a las métricas del negocio en la semana trece.
Por qué los modelos baratos se rompen en la cola larga
La razón por la que esto es estructural y no circunstancial es geométrica. La dificultad de las consultas sigue una ley de potencia: un gran centro fácil y una cola larga de consultas ambiguas y dependientes del contexto. Los modelos de frontera están sobredimensionados para el centro, y por eso los ahorros son reales, pero el clasificador no puede separar el centro fácil de la cola larga oculta en el momento de decidir, porque solo ve la forma superficial.
“¿De dónde viene este cargo?” parece una consulta trivial de la cuenta, pero en producción a veces es una investigación de fraude, una falla de conciliación o un cambio de ciclo de facturación que no se notificó. El modelo capaz tenía margen para seguir la conversación hasta la complejidad. El modelo barato respondió la pregunta superficial que el cliente en realidad no estaba haciendo.
Tres mecanismos se suman. La forma superficial es un mal indicador de la profundidad justo donde más importa la elección del modelo: el clasificador está bien calibrado donde no lo necesita y mal calibrado donde sí. Los modelos pequeños fallan con seguridad: una respuesta completa, plausible y equivocada es más difícil de marcar que la reserva o la pregunta aclaratoria de un modelo de frontera. Y las distribuciones se desplazan: un clasificador entrenado con seis meses de historial enruta mal una proporción cada vez mayor a medida que llegan nuevos productos y nuevos grupos de clientes, mientras los ahorros se quedan iguales y el costo en calidad crece en silencio.
Lo crucial es que el costo de la falla cae en otro centro de costos: el equipo de soporte humano, la retención, la experiencia del cliente, ninguno a cargo del equipo que hizo la optimización. Cada equipo optimiza su propio presupuesto; la optimización combinada es negativa. Esa asimetría es la trampa de Pareto. (Rupareliya encontró la misma forma en dos auditorías más: un SaaS de mercado medio y, de manera más aguda, un caso de fintech en el que las consultas “informativas” tenían peso regulatorio y una respuesta equivocada es una infracción, no una molestia).
La solución es la medición, que es todo el punto de este sitio
La conclusión del artículo es una que firmaríamos con gusto: la arquitectura de medición importa más que la decisión de enrutamiento. Un equipo con buena observabilidad por nivel puede enrutar de forma agresiva porque detectará la desviación; un equipo sin ella no puede operar con seguridad ninguna capa de enrutamiento a escala. Las tres adiciones que prescribe son exactamente la disciplina que EyesInAI existe para aportar:
- Monitoreo de calidad por nivel: cada señal de calidad separada por nivel de enrutamiento, nunca leída como un agregado. La cifra agregada es estructuralmente ciega a la desviación de un nivel específico.
- Sobremuestreo de la cola larga: medir a propósito las consultas en las que el clasificador tuvo menos confianza, porque la falla es invisible en el promedio.
- Desviación de la confianza del enrutamiento: seguir la distribución de confianza del clasificador frente a la del entrenamiento; se mueve semanas antes que la señal de calidad, y ese es el margen para corregir el rumbo.
Justo por eso sostenemos que un router que solo mueve la solicitud no basta: tiene que estar conectado a una señal de calidad medida. (Vea el enrutamiento de prompts y cómo probamos).
La mejor arquitectura, y la que de verdad operamos
El patrón que recomienda Rupareliya es una cascada enrutada por incertidumbre: en lugar de que un clasificador decida sobre una consulta antes de que la vea cualquier modelo, cada consulta empieza en el modelo barato, que devuelve una confianza calibrada; las respuestas de baja confianza escalan al modelo capaz. El modelo barato decide por sí mismo en lugar de que otro decida por él, así que las consultas difíciles que habría respondido mal y con seguridad aparecen como de baja confianza y escalan. Lo combina con la calificación en sombra (correr el modelo capaz en paralelo sobre un pequeño % del tráfico para detectar la desviación en condiciones reales) y el enrutamiento ponderado por calidad (retroalimentar con el tiempo la satisfacción observada al umbral).
Esa es, casi línea por línea, la arquitectura detrás de nuestro router: un cambio de nivel se propone a partir de la calidad medida, luego se corre en sombra contra el tráfico real de producción antes de que pueda entrar en vigor, y una degradación se bloquea a menos que los resultados con tráfico real la confirmen: un piso de calidad, no la suposición de un clasificador. Llegamos a ella por la misma razón que el artículo: la cola larga es donde el enrutamiento ingenuo falla en silencio, y solo la medición con tráfico real lo detecta. Es de verdad alentador ver que un análisis posterior independiente llega al mismo diseño.
Las concesiones honestas son reales y también las nombramos: una cascada agrega latencia en las consultas escaladas (barato + capaz en serie), el costo es más difícil de prever (depende de la distribución de confianza) y calibrar la confianza del modelo barato no es trivial. Son concesiones frente a un piso de calidad que el enfoque de enrutar antes simplemente no mantiene, y en cualquier despliegue en el que la cola larga tenga un costo real para el cliente, ese piso es lo que importa. La optimización barata rompe el producto en silencio; la honesta sobrevive el trimestre.