Cómo decidir la ruta de LLM con evidencia de tráfico real

La empresa eligió el mejor modelo el martes. El jueves cambió el precio, el proveedor degradó la latencia p95 y nadie supo decir si la ruta seguía siendo la correcta, porque la decisión original nunca tuvo un número para defenderla. Elegir ruta de LLM por intuición de laboratorio es fácil. Cambiar de ruta con evidencia es lo que casi nadie organiza.

La tabla de precios de modelos se movió de forma previsible en el último año: Anthropic lanzó Opus 5, OpenAI publicó GPT-6, y cada release reposicionó la relación entre costo por token y calidad percibida. Una decisión de ruta tomada en marzo puede estar equivocada en septiembre sin que se haya mirado un solo gráfico.

Esta guía no discute qué modelo es mejor. Describe cómo una empresa decide su propia ruta con evidencia: duplicando una porción del tráfico en vivo, juzgando las respuestas a ciegas y promoviendo el cambio solo cuando la medición en el tráfico de la propia empresa lo autoriza. El método cabe en cinco pasos y cabe en la infraestructura que la empresa ya tiene.

¿Qué es el shadow evaluation y por qué decide mejor que un benchmark?

El shadow evaluation es correr la ruta candidata en paralelo con la ruta titular, sobre el tráfico real, sin que responda al usuario. El equipo duplica una muestra de las llamadas, las envía por los dos caminos, guarda las dos respuestas y juzga la diferencia a ciegas, antes de cualquier promoción.

La ventaja sobre un benchmark público es simple de enunciar y difícil de discutir: el benchmark mide el modelo, mientras la sombra mide el modelo en tu tráfico, con tus prompts, tu distribución de tareas y tus colas. Un modelo puede ganar en el agregado y aun así perder justo en el caso que más aparece en tu base. La diferencia entre las dos mediciones suele decidir la cuenta a fin de mes.

Un benchmark es una foto. Una sombra es un video.

La decisión de ruta es, en el fondo, una decisión de contabilidad vestida de ingeniería. Y la contabilidad no se decide por reputación del proveedor, se decide por un número propio.

El error que la sombra corrige es el de la evaluación estática. La mayoría de las empresas prueba un modelo nuevo en unas decenas de prompts armados a mano, le gusta el resultado y promueve la ruta. Eso mide la impresión de quien escribió los prompts, no el desempeño en producción. La sombra cambia el prompt de vitrina por la llamada que el usuario realmente hizo.

Prerrequisitos antes del primer paso

Antes de duplicar cualquier cosa, tres piezas tienen que existir, y sin ellas la sombra se vuelve costo sin lectura: cada llamada lleva un identificador de ruta, de tenant y de tarea, un store guarda la respuesta de cada ruta bajo el mismo identificador, y un juez fuerte evalúa los pares con una rúbrica escrita. Si falta cualquiera de las tres, el experimento no empieza.

Sin rastro, no hay veredicto.

• Tráfico identificable. Cada llamada lleva un identificador de ruta, de tenant y de tarea, para que la muestra pueda segmentarse después.
• Registro de las respuestas. Un store que guarda la respuesta de cada ruta con el mismo identificador de llamada.
• Un juez confiable. Un modelo lo bastante fuerte para evaluar, aislado de la ruta bajo prueba, más una rúbrica de criterios.

Si falta el identificador de tarea, el experimento mide un promedio que no orienta a nadie. Una ganancia de calidad agregada esconde una regresión en una clase entera de llamadas, y es la regresión la que duele en producción.

¿Cuál es el costo de correr las dos rutas al mismo tiempo?

El costo de la fase de sombra es el costo de la ruta candidata sobre la porción duplicada, más el costo del juez sobre los pares. No es el doble de la factura, y el número exacto depende de cuánto tráfico reflejas.

La tentación es reflejar todo. Reflejar el 100% del tráfico duplica el gasto de inferencia y convierte una decisión de ruta en un proyecto de presupuesto. La práctica recomendada es reflejar una fracción que produzca muestra suficiente para la decisión, y dejar el resto en paz.

Duplicar una muestra no es la única forma de controlar la cuenta. El enrutamiento por complejidad, que manda cada llamada al modelo más barato capaz de resolverla, corta el costo de la ruta candidata antes de que la sombra empiece.

La comparación de abajo resume lo que el equipo gana en cada enfoque de evaluación. Las dos columnas miden cosas distintas, y por eso se complementan en lugar de competir.

Paso 1: definir la hipótesis y el criterio de promoción antes de medir

El primer paso no es técnico, es de método. Antes de encender la sombra, escribe la hipótesis y el criterio que autoriza la promoción, porque sin ese preregistro el experimento termina en discusión y cualquier resultado empieza a servir para cualquier posición. Una evaluación de endpoint y política de enrutamiento parte exactamente de esa disciplina.

Una hipótesis sin criterio es un palpite con sello.

La hipótesis tiene que nombrar qué cambia y qué se espera. "La ruta candidata reduce el costo por tarea un 20% sin bajar la tasa de aprobación del juez más de dos puntos porcentuales" es una hipótesis. "Probar el modelo nuevo" no lo es.

El criterio de promoción es la línea que separa aprobar de no aprobar. Se escribe ahora, no después de ver el número, porque un criterio escrito con el resultado sobre la mesa es justificación, no criterio.

Dos parámetros merecen preregistro explícito:

1. Tamaño de muestra mínimo. Cuántas llamadas pareadas antes de cualquier lectura, para que el resultado no sea el ruido de una tarde.
2. Techo de costo. El valor por mil llamadas por encima del cual la ruta candidata reprueba incluso con calidad igual.

El piso práctico queda en el orden de unas decenas de pares por ciclo. Por debajo de eso, el costo de armar el juez no se paga y la revisión humana directa es más eficiente que el marcador automático.

El sesgo de novedad es el enemigo silencioso de este paso. Los equipos tienden a preferir la respuesta del modelo más nuevo y más conocido cuando el juicio no es ciego, y la sombra existe justo para quitar ese atajo.

Paso 2: duplicar una porción representativa del tráfico en vivo

El segundo paso es encender la sombra sobre una muestra que represente la distribución real de llamadas, y la palabra que carga el paso es "representativa", porque una muestra sesgada produce una decisión confiada y equivocada. Duplicar solo la llamada más común mide la tarea fácil y deja fuera la cola, donde viven las sorpresas.

El camino ingenuo es duplicar todo. El camino correcto es duplicar por segmento. Separa las llamadas por clase de tarea, por tenant relevante y por rango de contexto, y refleja dentro de cada segmento. Si reflejas solo el camino más común, el resultado no vale para la cola, y la cola es donde viven las sorpresas.

La elección del splitter también importa. El splitter va en la capa de gateway, en el punto donde la llamada ya fue normalizada y todavía no fue despachada. Poner la duplicación dentro de la aplicación obliga a cada servicio a conocer el experimento, y el experimento muere en la primera refactorización.

Hay un requisito de aislamiento: la ruta candidata no puede responder al usuario. Si responde, estás corriendo un canary, no una sombra, y asumiste el riesgo de exponer a alguien a la ruta que todavía no fue aprobada.

Vale medir el rendimiento de los proveedores de LLM en tu propia carga antes de confiar en cualquier ranking. La latencia de un proveedor en el p95 de tu distribución puede ser bastante peor que el promedio que publica, y la sombra es el instrumento que revela esa diferencia.

Paso 3: juzgar las respuestas a ciegas con un LLM judge

El tercer paso es transformar pares de respuestas en un veredicto. Un LLM judge evalúa las dos respuestas sin saber qué ruta las produjo, siguiendo una rúbrica escrita, y el secreto de las etiquetas es lo que da valor al juicio.

El juez debe ser lo bastante fuerte para evaluar e independiente de las dos rutas bajo prueba. Si el juez es el mismo modelo de una de las rutas, carga el sesgo de esa ruta y el experimento mide la preferencia del juez por sí mismo.

La rúbrica tiene que ser específica. "Calidad" no es criterio. Una rúbrica útil separa al menos tres dimensiones:

• Corrección factual, cuando la tarea tiene una respuesta verificable.
• Apego al formato, cuando el consumidor es un parser y no un humano.
• Utilidad para la tarea, evaluada contra el objetivo declarado de la llamada.
• Control de verbosidad, para que el juez no prefiera por default la respuesta más larga y premie el relleno.

Un juez sin control de extensión tiende a coronar la respuesta más larga, lo que favorece justo a la ruta nueva y más verbosa. O el largo se controla en el par, o la rúbrica penaliza el relleno. Una de las dos, escrita antes de medir.

El juez también tiene costo y tiene error. Un juez mal calibrado aprueba casi todo o reprueba casi todo, y el equipo lee eso como resultado de la ruta. Vale medir el acuerdo entre el juez y una muestra juzgada por personas, antes de confiar en el marcador automático.

El juicio ciego resuelve el problema que la revisión por gusto personal no resuelve. No hay forma de que el ingeniero sepa qué respuesta era de la ruta nueva cuando el orden de las respuestas es aleatorio, y es esa ignorancia la que produce un marcador honesto.

Paso 4: aplicar el criterio estadístico y leer el resultado por segmento

El cuarto paso es mirar el número. Aquí la decisión deja de ser opinión y pasa a ser la lectura de un resultado medido contra el criterio preregistrado en el Paso 1, segmento por segmento, porque el promedio agregado solo esconde la pérdida que importa.

La lectura empieza por el agregado y no termina en él. Una ganancia promedio de calidad puede esconder una pérdida severa en un segmento pequeño y crítico. Lee el resultado por clase de tarea, por rango de contexto y por tenant, y trata el promedio como resumen, nunca como conclusión.

Una diferencia pequeña dentro del ruido no autoriza promoción. Si el intervalo de confianza de la ganancia pareada por segmento cruza el cero, lo honesto es decir que el experimento no encontró diferencia, no elegir el lado que agrada. Un equipo que promueve con base en ruido va a promover y revertir en ciclo, y cada reversión cuesta más que el experimento.

Tres lecturas condenan la ruta candidata, incluso cuando el agregado agrada:

1. El costo por tarea reventó el techo preregistrado.
2. Un segmento relevante regresó más allá del margen tolerado.
3. La latencia de cola empeoró de una forma que el usuario va a sentir.

El punto contraintuitivo es que el criterio estadístico no existe para probar que la ruta nueva es mejor. Existe para impedir la promoción de la ruta nueva cuando la evidencia es débil. La carga de la prueba queda con quien quiere cambiar.

Paso 5: promover la ruta y mantener la lectura después de la promoción

El quinto paso es promover, y la promoción es un cambio de configuración, no un proyecto. La ruta candidata se vuelve titular porque la medición en el tráfico real la habilitó, y la ruta antigua permanece disponible como fallback, de modo que el cambio sigue siendo una decisión reversible y no un compromiso de largo plazo.

La promoción tiene que ser reversible. Promover sin camino de vuelta convierte una apuesta en compromiso. La ruta anterior queda en el fallback configurado, y el gatillo de reversión se escribe con el mismo cuidado que el criterio de promoción.

Después de la promoción, la medición no para. La distribución de tráfico cambia, el precio del modelo cambia y la calidad del proveedor cambia. Una ruta promovida en septiembre merece una nueva lectura en noviembre, porque la evidencia tiene fecha de vencimiento.

El gate de promoción cabe en una lectura simple. La ruta nueva se promueve cuando la calidad juzgada es igual o mejor que la titular, el costo por tarea queda dentro del techo, y ningún segmento crítico regresó más allá del margen. Fuera de eso, se mantiene la titular y el ciclo vuelve a empezar con nueva hipótesis.

¿Cómo verificar que la sombra está funcionando?

La verificación es directa y no depende de la fe. El pipeline es correcto cuando los pares de respuestas llegan al store con el mismo identificador de llamada, cuando el juez recibe las dos respuestas sin las etiquetas de ruta, y cuando el marcador por segmento coincide con la muestra reflejada.

Una sombra sana deja tres rastros.

La señal de que la infraestructura está mal aparece rápido. Si la tasa de respuestas pareadas es baja, el splitter perdió llamadas. Si el juez está de acuerdo con casi todo, la rúbrica está floja. Si el costo de la fase de sombra roza el costo de producción, la muestra es demasiado grande para lo que se pretende decidir.

El rastreo de llamada de LLM es el instrumento que cierra la verificación. Cada llamada duplicada tiene que ser auditable desde el prompt hasta el veredicto del juez, con el identificador de ruta preservado en toda la cadena, porque sin esa cadena completa el marcador del juez se vuelve una caja negra que nadie puede contestar después.

Errores comunes y cómo corregirlos

Los errores de abajo aparecen repetidamente en implementaciones reales, y cada uno tiene una corrección específica que ninguna cantidad de tráfico resuelve. El patrón común entre ellos es que la decisión de ruta se tomó sin un número propio para defenderla, y no existe volumen de tráfico que corrija la ausencia de criterio escrito antes de la medición.

Un error de ruta casi nunca es un error de modelo.

Juicio sin ceguera. Cuando el equipo sabe qué respuesta es de la ruta nueva, la preferencia por el modelo de moda contamina el marcador. La corrección es aleatorizar el orden de las respuestas y quitar las etiquetas antes de enviarlas al juez.

Muestra sesgada. Reflejar solo las llamadas de mayor volumen mide la tarea fácil e ignora la cola. La corrección es segmentar la duplicación por clase de tarea y por rango de contexto.

Juez débil o único. Un juez del mismo proveedor de la ruta candidata carga sesgo incorporado. La corrección es elegir un juez fuerte y, cuando sea posible, juzgar con dos jueces y medir el desacuerdo.

Criterio escrito después del resultado. Promover con base en un criterio que nació después de ver el número es justificar, no decidir. La corrección es el preregistro del Paso 1 y la disciplina de no moverlo.

Promoción sin observabilidad. Ruta promovida sin lectura continua se vuelve deuda silenciosa. La corrección es mantener la medición por segmento después de la promoción, con el mismo panel que decidió el cambio.

Preguntas frecuentes sobre decidir la ruta con tráfico real

¿El shadow evaluation reemplaza el benchmark público? No, lo complementa, y la división del trabajo entre los dos es justo el punto. El benchmark público filtra candidatos rápido y descarta lo que ni merece una prueba costosa, mientras la sombra decide en tu tráfico; la secuencia eficiente es usar el benchmark para elegir qué vale la pena probar y la sombra para autorizar la promoción.

¿Cuánto tráfico hay que duplicar? Lo suficiente para que la lectura por segmento deje de depender de un puñado de llamadas, porque una muestra pequeña pero bien segmentada vale más que reflejar todo sin criterio. El costo de la sombra crece directo con la fracción reflejada, así que la decisión es siempre un equilibrio entre confianza estadística y cuenta a fin de mes.

¿Un LLM judge es confiable para decidir ruta? Confiable lo suficiente cuando la rúbrica es específica, el juicio es ciego y el acuerdo con el juicio humano se mide en una muestra antes de que el marcador se vuelva decisión. Un juez sin rúbrica escrita produce un marcador que nadie puede auditar después, y la ruta termina promovida por un número que no se sostiene en reunión.

¿Cuándo revertir una ruta promovida? Cuando la lectura continua muestra regresión más allá del margen que autorizó la promoción original. El gatillo de reversión se escribe junto con el criterio de promoción, nunca después de que apareció el problema, porque revertir en medio de la crisis obliga al equipo a improvisar justo cuando falta calma para decidir.

¿La sombra sirve para ruta de costo o solo para calidad? Sirve para las dos, siempre que el criterio combine las dos dimensiones en el mismo gate y no trate el costo como desempate. Una ruta más barata que empeora la calidad en un segmento crítico reprueba en la misma prueba que una ruta cara que no mejora nada.

Referencias y Lectura Complementaria

• Cómo una evaluación de endpoint cambia la política de enrutamiento de una empresa
• Enrutamiento por complejidad: calidad sin desperdicio
• Cómo medir el rendimiento de proveedores de LLM
• Rastreo de llamada de LLM: qué es y por qué auditar
• Google SRE Book, el capítulo sobre liberación gradual y canarios: sre.google/sre-book/release-engineering
• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0): nist.gov/itl/ai-risk-management-framework

El próximo paso es instrumentar la decisión, no elegir un modelo

La ruta correcta hoy no es la ruta correcta en tres meses. Lo que sobrevive al cambio de precio, de latencia y de release es el método que convierte una decisión de ruta en un experimento con criterio escrito antes de la medición, porque elegir el mejor modelo es fácil e instrumentar el cambio separa a quien decide de quien apuesta.

Aquí es donde el Nexforce Router entra como infraestructura, no como respuesta lista. Una API única, una llave, 300+ modelos, con enrutamiento inteligente, failover automático y fallback configurable para cuando la ruta titular cae. El rastreo de cada llamada sostiene la sombra con el identificador de ruta preservado. El budget por llave, por agente o por proyecto impide que la fase de reflejo reviente el techo sin aviso. Y el ahorro de hasta el 50% en el costo por token reportado por la propia Nexforce, con factura en BRL, cambia la cuenta que la ruta candidata tiene que batir.

El método es tuyo. La capa que lo ejecuta puede ser una sola.