Problema de ubicación de fallas después de la reducción de costos en el enrutamiento multimodelo

La primera vez que sentí que algo andaba mal en línea fue una queja difícil de explicar: el mismo usuario hizo la misma pregunta tres veces en 5 minutos. La primera vez respondió bien, la segunda vez empezó a decir tonterías y la tercera vez volvió a la normalidad.

No hay anomalías en los registros, la latencia es estable y el uso del token no ha aumentado. El único cambio que se puede ver es que acabamos de activar el “enrutamiento multimodelo” y utilizamos modelos más baratos para cubrir parte del tráfico.

En ese momento, la intuición del equipo era muy consistente: el modelo es una distribución de probabilidad y las fluctuaciones son normales. Además, el enrutamiento es sólo una capa de la puerta de enlace, entonces, ¿qué grandes problemas pueden ocurrir?

En las siguientes dos semanas sufrimos esta sentencia muchas veces.

Juicio central

El costo principal del enrutamiento multimodelo es cambiar el comportamiento de la misma solicitud de “reproducible” a “distribución de probabilidad”.

En la era del modelo único, no importa cuán difícil sea un problema en línea, siempre que obtenga la entrada, el mensaje, el contexto y el número de versión, lo más probable es que pueda reproducirlo en un entorno determinado y luego seguir la cadena de llamadas para identificar la causa raíz.

Una vez involucrado el enrutamiento, el problema será:

-¿Qué modelo, qué versión y qué conjunto de parámetros utilicé esta vez?

• ¿Por qué se eligió la ruta de esta manera y qué características alcanzó el umbral?
• ¿Tomaste caminos diferentes dos veces en la misma sesión?
• Cuando se produce un fallo, ¿es posible volver a ejecutar la “decisión tomada en ese momento”?

Si no hay registros rastreables ni mecanismos de reversión, las fallas en línea se actualizarán de “modelo inexacto” a “causa raíz no localizable”.

Cómo las cosas se vuelven más difíciles paso a paso

Al principio solo adoptamos la estrategia más simple: usar modelos pequeños siempre que sea posible y actualizar a modelos grandes solo cuando “parecen complicados”.

Las llamadas “parece complejas” son algunas características económicas: longitud de entrada, si contiene bloques de código, si hay múltiples rondas de diálogo y la confianza de un clasificador pequeño.

La primera ola de problemas después de conectarse fue que los métodos de solución de problemas fallaron.

Los colegas de prueba no pueden reproducir el mismo mensaje en el entorno de escala de grises y los desarrolladores no pueden reproducirlo localmente. Al final, sólo los usuarios en línea pueden activarlo de manera estable.

Alguna vez sospechamos que se trataba de un error en el empalme de contexto, el almacenamiento en caché o algún posprocesamiento. No fue hasta que capturamos la entrada completa de una solicitud que descubrimos que esta vez se usó un modelo pequeño en línea, y el modelo grande se usó de forma predeterminada cuando lo reproducimos.

Este es un “cambio de camino”.

Los cambios de ruta cambian la solución de problemas de “entradas recurrentes” a “decisiones recurrentes”. Las decisiones no se pueden repetir en ese momento.

Malentendido 1: Trate el enrutamiento como pura optimización de costos

Lo que ves en la tabla de costos es:

• El 30% del tráfico se destina a modelos pequeños.
• El coste medio por llamada cayó un 18%

Pero lo que no puedes ver en la tabla de fallas es:

• Cada problema de calidad tardará entre 1 y 2 días adicionales para determinar si se debe a la ruta.
• La reproducción en línea requiere un “contexto de toma de decisiones” más completo
• La reversión ya no es un “modelo de reversión”, sino “estrategia de reversión + umbral de reversión + lógica de extracción de características de reversión”

Cuando trata el enrutamiento como un cambio ligero como “cambiar de proveedor”, definitivamente tendrá que pagar interés más adelante en la resolución del problema.

Malentendido 2: Interpretar la inestabilidad como “LLM es inherentemente aleatorio”

La mayoría de los problemas causados por la aleatoriedad de un solo modelo son “muestrear la misma entrada varias veces con diferentes salidas”.

El problema causado por la aleatoriedad del enrutamiento es que “la misma entrada va a diferentes sistemas”.

Ambos parecen fluctuaciones, pero se diagnostican de formas completamente diferentes.

El primero a menudo ajusta la temperatura, las indicaciones del sistema y agrega restricciones; este último debe responder primero: ¿Se equivocaron esta vez?

Sin enrutar registros de decisiones, el equipo caerá en un muy mal hábito: atribuir todas las anomalías a la “inestabilidad del modelo”, por lo que la estrategia se vuelve cada vez más agresiva y la calidad se parece cada vez más a un dado.

Tres tipos de trazabilidad que realmente deben completarse

Para que el enrutamiento sea un sistema “resoluble”, se deben completar al menos tres tipos de registros y deben poder unirse en una dimensión de solicitud.

1) Registro de decisiones de enrutamiento (registro de decisiones)

No solo registre “qué modelo se seleccionó”, sino también registre:

• Conjunto de candidatos (qué modelos disponibles están disponibles en ese momento)
• Puntuación o juicio de umbral para cada candidato.
• Valores de características utilizados (longitud de entrada, recuento de rondas múltiples, salida del clasificador, etc.)
• Número de versión de la política (muy crítico)

Sólo así podremos responder “¿Por qué lo elegí esta vez?”

2) Solicitar instantánea (reproducir instantánea)

Al menos deberá estar disponible lo siguiente en caso de fallo:

• Entrada del usuario sin procesar
• El mensaje realmente enviado al modelo (incluidas las palabras del mensaje del sistema, el contexto empalmado y los resultados de la herramienta)
• Configuración de claves (temperatura, top_p, max_tokens, stop y su propio switch de posprocesamiento)

Sin instantáneas, las recurrencias son sólo conjeturas.

3) Reversión de enrutamiento (primitiva de reversión)

La reversión debe ser lo suficientemente “áspera” y puede ejecutarse con un solo clic:

• Obligar a todos los jugadores a seguir un determinado modelo estable.
• O arreglar una determinada versión de la estrategia.

No espere cambiar temporalmente el umbral en caso de accidente. Lo que se necesita en un accidente es certeza.

Caso de falla: “umbral adaptativo” aparentemente inteligente

Más tarde probamos un enfoque más “inteligente”: ajustar dinámicamente el umbral en función de la calidad de la señal de los últimos 10 minutos para permitir que el modelo pequeño absorba más tráfico.

El resultado es una autooscilación muy típica:

• Los modelos pequeños tragan más y la calidad de la señal empeora
• El umbral aumenta, los modelos grandes tragan más y la calidad de la señal mejora.
• El umbral se reduce y los modelos pequeños tragan más

Externamente parece “buenos y malos tiempos”, pero internamente la estrategia está flaqueando.

Si no existe un número de versión de la política y un registro de decisiones para este tipo de problema, es básicamente imposible explicarlo claramente, y mucho menos solucionarlo.

Límites aplicables

El enrutamiento multimodelo no es imposible, pero es más adecuado para equipos que cumplen con los siguientes requisitos previos:

• ¿Es aceptable pagar costos adicionales de almacenamiento y cumplimiento de la privacidad por la trazabilidad?
• Tener advertencias y métricas de calidad claras, en lugar de depender de las quejas de los usuarios.
• ¿Se puede mantener la estrategia como un “sistema en línea” con versiones, escalas de grises y retrocesos?

Si la observabilidad actual todavía se limita a “volumen de solicitudes, retrasos, códigos de error”, entonces no se apresure a realizar enrutamientos complejos todavía. El dinero ahorrado puede perderse en el tiempo de resolución de problemas.

Resumen

Lo más subestimado del enrutamiento multimodelo es que cambia los objetos de resolución de problemas.

Lo que antes se reproducía eran insumos, pero ahora lo que hay que reproducir es la toma de decisiones. Sin registros de decisiones, instantáneas de solicitudes y primitivas de reversión, las fallas en línea se volverán “aleatorias” y no podrán explicarse ni repararse.

Las cuentas de reducción de costos son fáciles de calcular, mientras que las cuentas recurrentes son las más difíciles de calcular, pero al final definitivamente aparecerán en la revisión de accidentes.