Primero la conclusión: que un chatbot de atención al cliente queme dinero, en el ochenta por ciento de los casos no se debe a que el precio unitario del modelo sea caro, sino a que la forma de invocarlo tiene problemas. Un bot interno de preguntas y respuestas postventa con unos miles de usuarios activos diarios vio cómo su factura del primer mes se disparaba directamente hasta el triple del presupuesto. Tras investigarlo, el precio unitario del modelo no había cambiado ni un céntimo; todo eran costes ocultos en la estructura de invocación. Este artículo recoge el proceso de revisión; si te interesa la optimización de costes de API de grandes modelos, puedes contrastarlo con tu propia factura.
Cómo se ve una factura anómala
La característica de la anomalía no es "un total alto", sino "una estructura extraña". Revisamos el detalle de llamadas por día y encontramos tres cosas raras: los días con mayor volumen de llamadas, el número medio de tokens por solicitud iba subiendo; la proporción de reintentos rondaba el veinte por ciento; y para una misma pregunta del usuario, unas veces eran unos cientos de tokens y otras más de diez mil, una varianza enorme. Estas tres cosas juntas bastan para localizar que el problema no está del lado del modelo, sino en nuestra propia cadena de invocación.
Cuatro costes ocultos, cada uno más escondido que el anterior
Primero, el modelo insignia haciendo trabajo pesado. Al principio, por comodidad, todas las solicitudes iban uniformemente al modelo insignia. Pero en el escenario de atención al cliente, más del setenta por ciento son tareas de identificación de intención y respuestas con guiones fijos del tipo "¿dónde está mi pedido?" o "¿cómo devuelvo esto?", para las cuales un modelo pequeño es totalmente suficiente, con una diferencia de coste de un orden de magnitud. Hacer que el modelo insignia responda "¿a qué hora abren?" es como usar un camión para repartir comida a domicilio.
Segundo, expansión descontrolada del contexto. En el diálogo multiturno metíamos de vuelta todos los mensajes históricos; cuando el usuario llegaba al décimo turno, solo el historial ya ocupaba la mayor parte de los tokens. Lo más problemático es que mucho de ese historial no tenía nada que ver con la pregunta actual y solo hacía bulto. El contexto no es más inteligente cuanto más largo; pasado cierto punto, la mejora de precisión es limitada, pero el coste sube de forma lineal.
Tercero, tormenta de reintentos. Configuramos un reintento simple ante fallos, pero sin retroceso ni cortocircuito. Cuando el upstream tenía timeouts esporádicos, el mismo lote de solicitudes se reenviaba una y otra vez: un fallo, un reintento; el reintento fallaba, otro reintento. En la factura, esas llamadas eran puro gasto a fondo perdido, y el usuario seguía viendo un error.
Cuarto, doble facturación por streaming y no streaming. Este es el más fácil de pasar por alto. Algunas de nuestras cadenas, para obtener el resultado completo y hacer posprocesamiento, llamaban una vez en modo no streaming; y el frontend, que quería efecto de máquina de escribir, llamaba otra vez en streaming. La misma pregunta, dos pagos. Luego lo unificamos en recepción por streaming y ensamblado local, y así eliminamos ese coste duplicado.
Cómo implementar el enrutamiento por capas
La idea no es complicada: dividir el tráfico según la dificultad de la tarea. Identificación de intención, extracción de slots, guiones fijos y similares van a modelos ligeros; solo las conversaciones complejas que realmente requieren razonamiento, juicios de varios pasos y contención emocional se entregan al modelo insignia. En medio se añade una capa de pasarela de modelos que hace de juez: la solicitud entra, pasa primero por un clasificador, se etiqueta la tarea y luego se decide a qué modelo enrutarla.
Nosotros usamos la lógica de seleccionar automáticamente el modelo óptimo según la tarea, y en el enrutamiento multimodelo de SiCore TokenWorks hicimos una ronda comparativa: tras cambiar las tareas simples a modelos ligeros, el coste global bajó claramente y la respuesta también fue más rápida. La clave aquí no es "qué modelo usar", sino que la tabla de mapeo de "qué tarea va con qué modelo" hay que ajustarla continuamente. Al principio la configuramos por experiencia; tras dos semanas de funcionamiento la recalibramos según la tasa de acierto real, y el resultado fue mucho mejor que configurarla a ojo. La ventaja de la integración unificada multimodelo también se manifiesta en ese momento: cambiar la estrategia de enrutamiento no requiere tocar el código de negocio, basta con ajustar la capa de pasarela.
Comparación de la factura antes y después de la optimización
No doy cifras concretas, doy proporciones. El volumen total de llamadas no cambió, porque el número de usuarios no cambió. El coste total bajó alrededor de un sesenta por ciento; de ello, la proporción de llamadas al modelo insignia pasó de cerca del cien por cien a alrededor del treinta por ciento, y el resto se desvió a modelos ligeros. Las llamadas relacionadas con reintentos se redujeron de cerca del veinte por ciento a un porcentaje de un solo dígito. El número medio de tokens por solicitud bajó alrededor de un cuarenta por ciento, principalmente por el recorte de contexto. La parte de doble facturación por streaming se fue directamente a cero. En conjunto, pasamos de triplicar el presupuesto a quedarnos dentro e incluso con margen.
Cómo configurar la monitorización y las alertas
El dinero ahorrado hay que defenderlo con monitorización, no con buena voluntad. Configuramos cuatro alertas: se dispara cuando los tokens de una sola solicitud superan el umbral, para evitar que el contexto se descontrole; se dispara cuando la tasa de reintentos supera la proporción fijada, para evitar tormentas de reintentos; se dispara cuando la proporción de llamadas al modelo insignia sube de forma anómala, señal de que el enrutamiento puede haber fallado; se dispara cuando la variación intermensual del coste diario supera el umbral. Estas cuatro no hace falta hacerlas muy complejas; con agregación diaria y alerta al superar la línea es suficiente. En el modelo de facturación por Token, el coste se acumula en tiempo real; si esperas a fin de mes a mirar la factura para optimizar, el dinero ya está gastado.
Resumiendo en una frase: el grueso del coste de un chatbot de atención al cliente está en la estructura de invocación, no en el precio unitario del modelo. Si haces bien estas cuatro cosas —enrutamiento por capas, recorte de contexto, control de reintentos y unificación de streaming—, la factura baja sola. Yendo un paso más allá, si en tu escenario también hay recuperación RAG, el número de documentos recuperados de la base vectorial merece igualmente una revisión con este mismo enfoque.