La optimización de costos en sistemas de IA se convirtió en uno de los temas más candentes de los últimos tiempos, y con razón: las facturas de inferencia crecen rápido, y cualquier ingeniero que logra recortar ese número a la mitad en pocas semanas se vuelve el héroe de la empresa.
Pero hay un detalle que toda esta historia suele dejar afuera.
Un equipo hizo exactamente eso, recortó más de la mitad de la factura de inferencia en ocho semanas de trabajo limpio de ingeniería, recibió un agradecimiento por escrito del CFO, presentó el resultado en el all-hands de la empresa y siguió adelante con la siguiente prioridad del trimestre.
Tres meses después, la satisfacción de los clientes estaba cayendo, el churn estaba subiendo, y el ahorro de costos estaba estructuralmente atado a la pérdida de calidad.
El problema no estaba en el código.
Estaba en lo que nadie estaba midiendo. 👀
Este artículo cuenta esa historia en detalle, desde la arquitectura de la capa de enrutamiento que se construyó hasta el post-mortem que reveló dónde estaba escondido el costo real, pasando por otras dos implementaciones auditadas en sectores diferentes que repitieron exactamente el mismo patrón.
Si trabajas con IA en producción, o estás pensando en implementar algún tipo de enrutamiento entre modelos de IA para reducir costos, este caso te va a hacer replantear algunas premisas bastante comunes en el mercado.
Cómo Se Construyó la Capa de Enrutamiento
El equipo operaba un agente de soporte al cliente basado en IA para un producto SaaS con alrededor de 4 millones de usuarios activos mensuales. El agente corría sobre un único modelo capaz, el de razonamiento más avanzado disponible en el stack en ese momento. El volumen de inferencia era lo suficientemente alto como para que la factura mensual del proveedor ya hubiera entrado en los seis dígitos y siguiera subiendo conforme la adopción crecía.
La idea detrás de la capa de enrutamiento era simple y, en el papel, bastante elegante. Un pequeño modelo clasificador, entrenado de forma personalizada con unas 200 mil consultas históricas de soporte con etiquetas de calidad, se colocaba delante del agente principal y marcaba cada solicitud como simple o compleja. Las consultas simples se redirigían a un modelo más barato de la misma familia del proveedor. Las complejas seguían yendo al modelo capaz. El clasificador era un encoder ajustado, lo suficientemente ligero para correr en menos de 30 milisegundos con un costo prácticamente irrelevante.
La taxonomía de clasificación se construyó a partir de la observación real de producción. Las consultas simples eran las que el equipo veía repetidamente: consultas de cuenta, dudas sobre estado de facturación, restablecimiento de contraseñas, seguimiento de pedidos y preguntas sobre horario de atención. Las consultas complejas eran las que históricamente exigían razonamiento matizado y en múltiples pasos: disputas de reembolso, comparaciones entre planes, resolución de problemas de integración y anomalías de ciclo de facturación. La distribución quedó en torno al 65% simples y 35% complejas en una semana representativa de tráfico.
El modelo más barato elegido costaba alrededor de una cuarta parte del precio por token del modelo capaz. Para las consultas simples enviadas a él, una evaluación lado a lado mostró calidad equivalente en el 94% de un conjunto de prueba de 5 mil consultas. La brecha del 6% era visible, pero el equipo la juzgó aceptable ante la reducción de costos.
El resultado inmediato fue exactamente lo que el equipo esperaba: la factura mensual de inferencia cayó a cerca del 40% del nivel anterior en ocho semanas. Las métricas de adopción dentro del agente se mantuvieron estables o ligeramente positivas. Lo que nadie percibió en ese momento es que el sistema combinado había creado un agujero de calidad que la arquitectura de medición existente simplemente no podía ver.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Lo Que los Números Ocultaban
La arquitectura de evaluación que el equipo tenía antes de la capa de enrutamiento fue construida sobre la premisa de que corrían un único modelo. La señal de calidad venía de tres fuentes: una muestra diaria de revisión humana de unas 200 respuestas, una suite de regresión offline con aproximadamente 12 mil consultas etiquetadas que corría semanalmente, y una señal de satisfacción proveniente del widget de feedback dentro del producto, donde los usuarios daban like o dislike a la respuesta.
Cuando la capa de enrutamiento entró en funcionamiento, el equipo mantuvo la muestra de revisión humana, pero no la separó por nivel de enrutamiento. Agregó el modelo barato a la suite de regresión, donde puntuó dentro del límite aceptable. Y dejó el widget de feedback intacto, porque no tenía forma de saber qué modelo había servido cada respuesta.
En retrospectiva, esas tres decisiones de medición fueron la semilla del problema. Todo lo que el equipo podía ver estaba en verde. Lo que no estaban viendo apareció en tres capas diferentes.
La muestra de revisión humana, tomada sin conciencia de nivel, era en la práctica un promedio ponderado, con el 65% de las revisiones en el modelo barato. Como el modelo barato era equivalente en los casos fáciles, empujaba el promedio agregado hacia arriba. Los problemas de calidad en el borde más difícil de la distribución de consultas simples quedaban diluidos hasta volverse invisibles.
La suite de regresión offline probaba ambos modelos, pero la curación era estática, armada seis meses antes del deploy, cuando nadie pensaba en enrutamiento. Reflejaba una distribución idealizada, no la distribución real de producción que el modelo barato ahora necesitaba enfrentar.
Y el widget de feedback tenía un problema estructural conocido desde hacía más de un año: el feedback era escaso. Los clientes daban dislike unas 3 veces cada mil interacciones, y esos votos negativos estaban sesgados hacia clientes que ya estaban frustrados por otra cosa. La relación señal-ruido era demasiado baja para detectar cualquier cambio que no fuera una regresión gigante.
Ninguna de estas fallas era específica de la capa de enrutamiento. Estaban latentes en la arquitectura de medición. La capa de enrutamiento simplemente las expuso. Mientras el sistema corría con un único modelo, las brechas de medición no producían lecturas falsas, porque había solo una distribución de calidad que medir. El enrutamiento introdujo dos distribuciones, y la arquitectura existente no podía observarlas por separado.
La deriva de calidad en el nivel del modelo barato comenzó en la tercera semana después del rollout completo. En la sexta semana ya era medible en la suite de regresión, pero el equipo interpretó la pequeña caída como deriva de versión del proveedor, y no como algo relacionado con el enrutamiento. En la décima semana el impacto acumulado en la satisfacción ya era visible en las métricas de producto. En la decimotercera, el churn ya rastreaba por encima de la línea base anterior. Fue en ese punto que el equipo pidió ayuda.
Qué Se Rompió y Cómo Se Descubrió
El diagnóstico llevó dos semanas. La solución fue reconstruir las decisiones de enrutamiento a partir de los logs de instrumentación, cruzarlas con los eventos de feedback dentro del producto y armar una vista de calidad por nivel que el equipo nunca había tenido antes.
El patrón apareció de inmediato en el nivel del modelo barato. Rendía bien en alrededor del 80% de las consultas que recibía, lo cual coincidía con el hallazgo original del conjunto de prueba. Pero el otro 20% en producción era estructuralmente diferente del conjunto de prueba, de una manera que el clasificador no podía detectar en el momento de la decisión.
El ejemplo más claro eran las consultas de facturación. El clasificador había aprendido a reconocer patrones como de dónde viene este cargo o me cobraron dos veces como consultas simples. En prueba, eso era cierto. En producción, una parte relevante de esas consultas escondía intenciones mucho más complejas. Un usuario preguntando de dónde viene este cargo a veces estaba preguntando sobre un cargo fraudulento real, a veces sobre una reconciliación atrasada entre dos sistemas, a veces sobre un cambio de ciclo de facturación del que no le habían avisado. El modelo capaz venía manejando estas intenciones anidadas correctamente porque tenía margen para seguir la complejidad de la conversación. El modelo barato trataba cada una como la intención superficial y respondía una pregunta que el cliente no había hecho.
Los clientes que recibían estas respuestas incorrectas no siempre daban dislike. Muchos simplemente abandonaban el agente y llamaban al soporte. La señal de dislike, por lo tanto, subrepresentaba la falla. El costo de la falla se empujaba hacia el equipo de soporte humano, que atendía la misma consulta una segunda vez, con el costo humano saliendo de otro presupuesto. La tasa de deflexión medida del agente permanecía estable mientras el volumen real de atenciones humanas empezaba a subir.
Cuando se sumaron los números, el impacto de costo de la pérdida de calidad era, de forma conservadora, de cuatro a cinco veces el ahorro generado por la capa de enrutamiento. El equipo había recortado unos 100 mil dólares por mes en inferencia e incurrido entre 400 y 500 mil dólares mensuales en costos de retención y soporte. La cuenta, vista en su totalidad, era inequívoca.
Esta es la propiedad estructural de lo que puede llamarse la trampa de Pareto. El ahorro en la capa de inferencia lo mide el equipo que construyó el sistema de enrutamiento. El costo de la pérdida de calidad lo pagan la experiencia del cliente, el equipo de soporte humano y la función de retención, ninguno de los cuales es dueño de la optimización. Cada equipo optimiza su propio presupuesto. La optimización combinada es negativa.
Por Qué los Modelos Baratos Fallan en la Cola Larga
Vale la pena desacelerar para entender por qué este patrón es estructural y no situacional. No se trata del modelo específico elegido, del proveedor ni del clasificador entrenado. Se trata de la geometría del espacio del problema.
Las consultas de clientes en cualquier deploy de IA en producción siguen una distribución de dificultad en ley de potencia. Una gran masa de consultas se agrupa en el centro fácil. Una masa menor se extiende en una cola larga de consultas más difíciles, ambiguas y dependientes de contexto. Los modelos de frontera están sobredimensionados para el centro fácil. Tienen mucha más capacidad de la necesaria para responder a qué hora abren. Es exactamente ese sobredimensionamiento lo que hace que la oportunidad de optimización sea real.
El problema es que los clasificadores no pueden separar de forma confiable el centro fácil de la cola larga en el momento de la decisión. El clasificador solo ve la forma superficial de la consulta. La cola larga queda escondida bajo formas superficiales que parecen fáciles. Una consulta que se lee como de dónde viene este cargo puede ser una búsqueda trivial de cuenta o la primera frase de una investigación de fraude. El clasificador ve las mismas palabras. El modelo barato da la misma respuesta superficial.
Este es el problema de compresión de la cola larga. La forma superficial es un pésimo predictor de la profundidad de la intención justamente en las consultas que más importan. El clasificador está bien calibrado exactamente donde no necesita estarlo, y mal calibrado exactamente donde necesita.
Hay un segundo mecanismo. Los modelos de frontera tienden a tener modos de falla recuperables. A veces dudan, piden aclaración o exponen su propia incertidumbre de formas que hacen que un humano intervenga. Los modelos más pequeños suelen fallar con confianza. Producen una respuesta completa, plausible y coherente en la superficie, que está equivocada sobre la intención real. La respuesta incorrecta es más difícil de reconocer como incorrecta por parte del cliente, lo que hace que la falla pase desapercibida más tiempo.
Y hay un tercer mecanismo: la deriva. Las distribuciones de consultas en producción evolucionan. Se lanzan nuevos productos, entran nuevas cohortes de clientes, surgen nuevos modos de falla. El clasificador entrenado con seis meses de tráfico histórico empieza a enrutar mal una fracción creciente de consultas conforme la distribución se aleja del conjunto de entrenamiento. El ahorro permanece estable, pero el costo de calidad crece silenciosamente.
Otros Dos Equipos Auditados Después de Este Caso
Después de este caso, el mismo patrón empezó a aparecer en otros deploys de IA. Dos surgieron rápidamente.
El primero era una empresa SaaS de tamaño mediano con un asistente de IA de éxito del cliente. Escala menor, gasto mensual de inferencia en los cinco dígitos bajos. Mismo patrón arquitectónico. Habían construido una capa de enrutamiento cuatro meses antes que enviaba consultas simples, definidas por un clasificador de similitud de embeddings, a un modelo más barato. El ahorro rondaba el 50%. Cuando la señal de feedback se segmentó por nivel, el nivel del modelo barato tenía una satisfacción significativamente menor en las consultas de cola larga. El equipo estaba ciego ante la brecha porque el dashboard agregado juntaba los dos niveles en un solo número.
El segundo era un caso de industria regulada en fintech, con gasto mensual de inferencia en los seis dígitos altos. Habían construido una capa de enrutamiento más conservadora, enviando solo lo que consideraban consultas informativas, como saldo de cuenta e historial de transacciones, al modelo barato. El ahorro era menor, alrededor del 20%. Pero la falla de cola larga en el modelo barato tenía implicaciones de compliance, porque algunas consultas que parecían informativas en realidad tenían peso regulatorio. Una pregunta como cuál es mi tasa de interés a veces tenía una derivación que dependía de que la primera respuesta se hubiera entregado con precisión. El equipo de compliance detectó el problema en una auditoría manual antes de que se convirtiera en un asunto regulatorio, pero el casi incidente hizo revertir el enrutamiento por completo.
El caso de fintech fue especialmente revelador. Dejó en evidencia que el tradeoff entre costo y calidad no es simétrico entre sectores. En soporte al cliente, una respuesta incorrecta es recuperable. En industrias reguladas, una respuesta incorrecta puede ser una violación.
Cómo Detectar la Trampa Antes de Tres Meses
La metodología de diagnóstico que habría detectado cualquiera de estos casos antes es directa, pero exige cambiar la arquitectura de medición antes de que la capa de enrutamiento entre en funcionamiento. Son tres adiciones concretas al stack de observabilidad.
Monitoreo de calidad por nivel
Este es el fundamental. Toda señal de calidad de la arquitectura existente necesita dividirse por nivel de enrutamiento, con la etiqueta de nivel propagada de punta a punta. Las muestras de revisión humana deben estratificarse para que cada nivel reciba revisión proporcional. Las suites de regresión offline deben dividirse en subconjuntos por nivel. Los eventos de feedback dentro del producto deben cruzarse con el log de decisión de enrutamiento. El número agregado de calidad, por sí solo, es estructuralmente incapaz de revelar una deriva específica de nivel.
Herramientas que usamos a diario
Muestreo de satisfacción en la cola larga
Como el problema de cola larga es invisible en el agregado, la arquitectura necesita sobremuestrear la cola para hacerla visible. Esto significa muestrear con mayor peso las consultas sobre las que el clasificador tuvo menos confianza, o que quedan fuera del centro de la distribución de entrenamiento. La meta es darle más peso a las consultas donde la elección del modelo realmente importa.
Deriva de confianza del enrutamiento
El propio clasificador es una fuente de señal de calidad que la mayoría de los equipos no monitorea. La distribución de los scores de confianza en producción debe compararse con la distribución observada en el entrenamiento. Cuando la producción se desvía, el clasificador opera fuera del rango calibrado, y las decisiones se vuelven cada vez menos confiables. La señal de deriva antecede a la señal de calidad por semanas, que es el tiempo de reacción que el equipo necesita.
Implementar estas mediciones de forma retroactiva es mucho más difícil que construirlas junto con la capa de enrutamiento. Hacerlo antes del lanzamiento cuesta quizás tres semanas de ingeniería. Hacerlo después de que el problema apareció muchas veces exige reconstruir datos que nunca fueron capturados. La arquitectura de medición importa más que la propia decisión de enrutamiento.
Cómo Es la Alternativa
Si el playbook de consenso de pre-enrutar por clasificador es una trampa de Pareto, la pregunta obvia es cuál es la alternativa. Existe una, y es significativamente mejor, aunque carga con sus propios tradeoffs.
El patrón es una cascada enrutada por incertidumbre. En lugar de preclasificar una consulta como simple o compleja antes de que cualquier modelo la toque, toda consulta empieza en el modelo más barato. El modelo barato produce una respuesta con un score de confianza calibrado, ya sea por una estimación interna de incertidumbre o por un paso explícito de autoevaluación. Cuando la confianza es alta, la respuesta vuelve directo al usuario. Cuando la confianza cae por debajo de un umbral, la consulta se escala al modelo capaz.
Este patrón invierte el modo de falla. El modelo barato ahora decide por sí mismo en lugar de que un clasificador decida por él. Las consultas difíciles, que el modelo barato respondería mal con confianza, en cambio aparecen como baja confianza y disparan la escalación. En el estudio del caso de soporte, el ahorro modelado quedó en el mismo rango que el enfoque de pre-enrutamiento, con una calidad materialmente mejor en la cola larga.
Dos mejoras se suman a la cascada. El shadow scoring corre el modelo capaz en paralelo en un pequeño porcentaje del tráfico para detectar deriva en condiciones reales. Y el enrutamiento ponderado por calidad incorpora la señal de satisfacción observada de vuelta en la calibración del umbral a lo largo del tiempo.
La cascada tiene tradeoffs que el pre-enrutamiento no tiene. La latencia en las consultas escaladas es prácticamente la suma de las dos latencias. El costo es más difícil de predecir de antemano. Y la complejidad de implementación es moderadamente mayor. Pero son tradeoffs contra el piso de calidad que la cascada mantiene y el pre-enrutamiento no.
La Capa de Optimización Importa Más Que la Optimización
El primer equipo eventualmente llegó a una arquitectura estable que combinaba cascadas enrutadas por incertidumbre con observabilidad por nivel. El costo mensual de inferencia se estabilizó en alrededor del 35% por debajo de la línea base original, menos ahorro del que el pre-enrutamiento había alcanzado en el papel. La satisfacción del cliente volvió a los niveles anteriores al experimento. El valor neto de producto del deploy, considerando las dos capas, quedó significativamente positivo.
La lección que el equipo sacó no fue que la optimización de costos está mal. Fue que la optimización de costos es una decisión sobre en qué capa del sistema confías para hacer el tradeoff correcto. El pre-enrutamiento confía en un clasificador que no puede ver lo que importa. La cascada confía en el propio modelo para saber lo que no sabe.
La optimización barata es la que rompe el producto silenciosamente. La optimización arquitectónicamente honesta es la que sobrevive a la cola larga. En IA de producción, la diferencia generalmente es un trimestre de satisfacción del cliente. 🎯
Trabajar con una capa de enrutamiento entre modelos de IA de diferentes capacidades y costos es una estrategia válida y, cuando está bien implementada, puede ofrecer un equilibrio genuino entre eficiencia económica y calidad de entrega. La clave está en no tratar al clasificador como una caja negra que resuelve todo sola después de la configuración inicial. Necesita ser monitoreado continuamente, ajustado con datos reales de producción y evaluado no solo por la precisión técnica de la clasificación, sino por el impacto que esa clasificación tiene en la calidad de la respuesta y en la experiencia del usuario final. Es exactamente ese tipo de atención continua lo que separa a los sistemas de IA que crean valor de verdad de aquellos que solo parecen eficientes en los dashboards de costos.
