Resumen — La evaluación de LLM offline y online responden a dos preguntas distintas, y cada una es ciega ante los fallos que la otra detecta. La evaluación offline se ejecuta antes del despliegue sobre un conjunto de datos fijo y detecta las regresiones que tú mismo introduces mediante cambios en el código o la configuración. La evaluación online se ejecuta en producción con tráfico real y detecta todo lo que te sucede a ti: actualizaciones silenciosas del modelo, deriva en los datos de entrada y cambios en las dependencias externas. Si omites la evaluación online y solo realizas la offline, la calidad de tu producción se degradará de formas que no podrás ver hasta que un usuario lo reporte, y para entonces, el incidente ya tendrá un número de ticket de soporte.
Un equipo realiza una evaluación offline exhaustiva antes de lanzar una actualización de RAG. La fidelidad se mantiene en 0.89, cómodamente por encima del umbral de 0.80, y el despliegue se realiza. Seis semanas después, los tickets de soporte se disparan. El modelo detrás de la API del proveedor había sido sustituido silenciosamente sin que ellos lo supieran; la evaluación offline nunca tocó el modelo en vivo, no existía monitorización en producción y el equipo se enteró de la misma forma que sus clientes.
Esa brecha es el tema de este artículo.
Lo que significa realmente la distinción
La evaluación offline se ejecuta antes del despliegue, sobre un conjunto de datos fijo y contra una versión específica del sistema. Tú controlas las consultas, los resultados esperados, la versión del modelo, el juez; todo. Es una evaluación como filtro: ¿supera esta versión el estándar antes de ser lanzada?
La evaluación online se ejecuta en producción, con tráfico real de usuarios y sobre el sistema en vivo. Tú controlas exactamente una variable: la tasa de muestreo. Es una evaluación como monitor: ¿sigue el sistema superando el estándar ahora que ya ha sido lanzado?
Los tipos de fallos que detecta cada una no se solapan. La evaluación offline detecta lo que tú rompiste. La evaluación online detecta lo que se rompió sin que nadie tocara nada.
Qué detecta la evaluación offline y qué pasa por alto
La evaluación offline, tratada en profundidad en la guía de evaluación de LLM, detecta las regresiones que tú mismo introduces. Cambias un prompt, actualizas la versión de un modelo, ajustas la configuración de recuperación; la ejecución offline compara la nueva versión con la línea base y señala qué ha empeorado. Para esa tarea, funciona bien: el conjunto de datos de referencia es una referencia estable, la puntuación es reproducible y el resultado es un aprobado o suspenso claro.
Lo que estructuralmente no puede detectar se divide en tres categorías.
Cambios que te ocurren a ti, no por usted. Los proveedores actualizan el modelo detrás de un nombre de versión sin cambiar el número de versión ni dar aviso previo; las variantes de GPT-4 cambiaron su comportamiento repetidamente a lo largo de 2024 sin que hubiera cambios correspondientes en la cadena que usted tenía fijada. Sus prompts permanecen intactos, su configuración no ha cambiado y no ha ejecutado una nueva evaluación porque nada en su repositorio se ha modificado. Las evaluaciones offline se ejecutan por diseño contra una versión de modelo fija. No tienen mecanismo alguno para detectar un cambio de comportamiento en tiempo real, porque lo que cambió ni siquiera está presente en la evaluación.
Desviación en la distribución de entrada. Su conjunto de datos de referencia es una instantánea de la distribución de consultas en el momento de la creación, generalmente basada en pruebas internas o sesiones de usuarios iniciales. Los usuarios reales llegan con un vocabulario diferente, un alcance más amplio y casos límite que sus evaluadores nunca imaginaron, y la evaluación offline no recibe ninguna señal de ello. La puntuación del conjunto de referencia sigue marcando 0.87, pero la tasa de fallos en producción aumenta porque el 40% de las consultas reales quedan fuera de lo que el conjunto de datos cubría.
Desviación de comportamiento bajo carga o secuencia. Algunos modos de fallo solo aparecen bajo condiciones que un conjunto de datos de referencia no puede reproducir: solicitudes simultáneas, el final de una conversación larga o un patrón de sesión específico. La evaluación offline ejecuta consultas individuales contra un conjunto fijo. Nunca ve la carga ni la secuencia, por lo que nunca detecta el fallo.
Lo que detecta la evaluación online y sus limitaciones
La evaluación online detecta exactamente lo que la offline no puede estructuralmente: actualizaciones del modelo por parte del proveedor, desviación en la distribución de entrada, cambios en dependencias externas y patrones de comportamiento específicos de producción. Sus limitaciones son igual de reales.
No se puede evaluar todo. La revisión humana a escala de producción deja de ser viable a partir de unos pocos cientos de solicitudes al día, por lo que LLM-as-a-judge es el único método que escala. Esto significa que la calidad de la evaluación online está limitada por qué tan bien calibrado esté el juez; un juez mal calibrado le entregará números que parecen convincentes pero que no reflejan la calidad real en absoluto.
Presupuesto de latencia. Si puntúa cada solicitud de producción en línea, habrá añadido cientos de milisegundos y duplicado el costo de inferencia en cada solicitud, permanentemente. La versión funcional muestrea una fracción del tráfico y lo puntúa de forma asíncrona, fuera de la ruta crítica.
La verdad fundamental suele desaparecer. La evaluación offline puntúa contra una respuesta conocida como correcta. La evaluación online puntúa sin ella. La fidelidad y la relevancia no necesitan una verdad fundamental para ser puntuadas; la exactitud sí, a menos que la tarea permita una verificación determinista.
La tasa de muestreo que realmente funciona es del 5 al 10% del tráfico para la mayoría de los volúmenes. Por debajo de unos 500 ejemplos puntuados al día, aumente la tasa o agrupe las puntuaciones en una ventana de tiempo más larga. Una muestra del 0.5% en un sistema de 1,000 solicitudes al día le dará cinco ejemplos puntuados, lo cual no es suficiente para detectar una caída de calidad de cinco puntos con ninguna confianza.
Los tres modos de fallo que solo detecta la evaluación online
- Actualizaciones silenciosas del modelo. El incidente de producción más común en sistemas de LLM no tiene un cambio de código correspondiente: OpenAI, Anthropic y Google han actualizado el comportamiento de sus modelos detrás de una cadena de versión fija sin una entrada en el registro de cambios que lo indique. Sus evaluaciones offline siguen pasando porque están fijadas a esa misma cadena de versión. El sistema en vivo está ejecutando silenciosamente un modelo diferente al que usted evaluó. El monitoreo online detecta el cambio en el tráfico real. La evaluación offline nunca iba a hacerlo.
- Desviación en la distribución de consultas. El conjunto de datos de referencia se creó a partir de pruebas internas. Los usuarios reales llegan con un vocabulario diferente, un alcance más amplio y expectativas que sus evaluadores nunca tuvieron. El conjunto de referencia sigue reportando una fidelidad de 0.87 mientras que la tasa de fallos en producción se sitúa en 0.21, porque el 40% de las consultas de producción nunca tocaron la distribución que cubre el conjunto de datos. La evaluación online sobre tráfico real es la única señal que detecta esto; el número offline nunca estuvo mal, simplemente estaba respondiendo a una pregunta que ya nadie hacía.
- Cambios en las dependencias upstream. La configuración de recuperación, el contenido de la base de datos, las API externas o una actualización de la base de conocimientos: todo esto altera la calidad de los resultados sin necesidad de tocar el modelo ni el prompt. Si actualizas la base de conocimientos con nuevas políticas, la respuesta correcta cambia, pero el conjunto de datos de referencia (golden dataset) sigue reflejando las antiguas. La evaluación en línea del tráfico posterior a la actualización detecta esta discrepancia de inmediato. La evaluación fuera de línea, al compararse con un conjunto de datos inalterado, no tiene forma de saber que algo ha cambiado.
Detección de deriva basada en embeddings
La detección de deriva basada en embeddings complementa el monitoreo de puntuaciones en lugar de reemplazarlo. Realiza un seguimiento de la distribución estadística de los embeddings de las consultas en producción a lo largo del tiempo. Cuando esta cambia —se forman nuevos clústeres o los existentes se desplazan—, significa que el sistema está recibiendo consultas significativamente distintas a las que cubre el conjunto de datos de referencia.
El valor reside totalmente en el tiempo de respuesta. La degradación de la puntuación es un indicador retardado: para cuando la fidelidad cae 0,05 en el monitor en línea, el cambio en la distribución que lo provocó lleva días, a veces semanas, acumulándose. La deriva de embeddings señala el cambio mientras está ocurriendo, no después de que la puntuación ya se haya visto afectada.
La implementación es sencilla. Genera el embedding de cada consulta de producción, o de una fracción muestreada, utilizando el mismo modelo de embedding que ya emplea tu sistema de recuperación. Realiza un seguimiento de la distribución mediante una prueba estadística de dos muestras —la MMD (discrepancia máxima media) y la divergencia KL son las que realmente se utilizan— y configura una alerta cuando se desvíe de la línea base histórica superando un umbral determinado.
Lo que no te dirá es si las nuevas consultas son más difíciles o más fáciles de gestionar. La deriva es una señal de alerta para que un humano la revise, no un veredicto sobre la calidad. Toma una muestra, léela y decide: actualiza el conjunto de datos de referencia, cambia el sistema o añade cobertura al conjunto de evaluación previo al despliegue.
Evaluación canary y puntuación en sombra (shadow scoring)
Existen dos técnicas que se sitúan entre la evaluación fuera de línea y la de en línea cuando estás a punto de implementar un cambio.
- Evaluación canary dirige una parte del tráfico de producción, normalmente entre el 5 y el 20 %, a la nueva versión del modelo o al nuevo prompt antes del despliegue completo. Ambas versiones se evalúan con su propio tráfico, y la versión canary debe igualar o superar a la versión actual antes de ampliar el porcentaje de tráfico. Una versión canary no es un entorno de pruebas (staging); es producción, para un subconjunto real de usuarios reales, y la respuesta ante incidentes debe cubrir los fallos de la versión canary igual que cualquier otro. Degradarle la calidad al 10 % de los usuarios sigue siendo degradarle la calidad a esos usuarios.
- Puntuación en sombra (shadow scoring) ejecuta la nueva versión junto con la actual en cada solicitud de producción, puntúa ambas y solo entrega la respuesta de la versión actual. Cero exposición del usuario al candidato, datos de comparación reales. El coste también es real: la puntuación en sombra duplica aproximadamente el gasto en inferencia y añade latencia a una ruta que los usuarios nunca ven, pero por la que sigues pagando.
La elección depende de la tolerancia a la exposición. Utiliza la puntuación en sombra cuando cualquier exposición del usuario al candidato sea inaceptable: trabajos sensibles a la seguridad, dominios regulados o cualquier cosa en la que aún no tengas plena confianza. Utiliza la evaluación canary cuando una pequeña tasa de error en un subconjunto de producción sea un precio justo a pagar por obtener datos más rápidos y realistas a una fracción del coste de infraestructura.
Muestreo de producción, diseño práctico
Un sistema de muestreo de producción se reduce a cinco componentes.
- Registro de solicitudes (request logging) es la base sobre la que se asienta todo lo demás. Registre cada solicitud, o una fracción muestreada de forma consistente, con todo lo necesario para evaluarla más tarde: consulta, contexto recuperado para RAG, respuesta del modelo, versión del modelo, hash del prompt y marca de tiempo. Si omite el campo de la versión del modelo, hará que sea estructuralmente imposible atribuir un cambio en la puntuación a una actualización específica del modelo; esta es la carencia de registro más común con la que los equipos lanzan sus productos.
- Estrategia de muestreo decide qué solicitudes se puntúan. El muestreo aleatorio funciona bien para la mayoría de los sistemas. El muestreo estratificado —que garantiza la cobertura entre tipos de consulta y segmentos de usuario— es mejor, pero solo si define los estratos de antemano. El muestreo por importancia, que sobremuestrea las solicitudes que parecen propensas a fallar según las puntuaciones de confianza o patrones previos, es la opción correcta cuando se buscan específicamente modos de fallo poco frecuentes pero graves.
- Puntuación asíncrona mantiene la inferencia del juez totalmente fuera de la ruta crítica. Las solicitudes muestreadas se dirigen a una cola y se puntúan en segundos o minutos, no en milisegundos; la mecánica de la cola en sí se trata en la guía de evaluación automatizada de LLM.
- Agregación de puntuaciones es lo que convierte las puntuaciones brutas en una señal sobre la que cualquiera puede actuar. Agregue diariamente o semanalmente, nunca solicitud por solicitud, y segmente siempre por tipo de consulta y segmento de usuario. Un sistema que ejecuta cinco tipos de consulta puede ver cómo una cae de 0,82 a 0,61 mientras que el agregado apenas se mueve, de 0,85 a 0,83. Las regresiones específicas de una categoría siempre se esconden dentro de un agregado que parece estable.
- Enrutamiento de alertas necesita dos tipos de disparadores, no uno: violaciones de umbrales absolutos (la tasa de fallos supera el X% en la categoría Y) y señales de tendencia (la tasa de fallos aumenta un Z% semanal durante tres semanas seguidas). Las alertas de tendencia son las que detectan la regresión lenta que nunca llega a superar un umbral absoluto. Si solo utiliza umbrales absolutos, la degradación gradual pasará desapercibida siempre.
Cuándo es suficiente cada una
La evaluación offline por sí sola es suficiente para herramientas internas con una base de usuarios pequeña y estable, y un equipo lo suficientemente cercano como para notar problemas de calidad mediante el uso directo. Deja de ser suficiente para cualquier sistema en producción con más de unos pocos cientos de usuarios activos diarios, cualquier sistema donde los usuarios reales se comporten de forma distinta a los evaluadores internos, o cualquier cosa que se ejecute en una API de modelo donde el proveedor controla el modelo subyacente.
La evaluación online por sí sola nunca es suficiente, punto. Detecta las regresiones después de que los usuarios ya las hayan sufrido; para cuando la monitorización online señala una caída significativa, la regresión ha estado activa durante el tiempo que tardó en acumularse la señal estadística, a menudo días. La evaluación offline previa al despliegue es el único mecanismo que detecta una regresión antes de que un solo usuario la vea.
La arquitectura correcta ejecuta ambas: offline como filtro de despliegue y online como monitor continuo. La evaluación offline responde a "¿esta versión superó el estándar antes de lanzarse?". La online responde a "¿el sistema en vivo sigue superándolo ahora?". Cuando ambas respuestas divergen, casi siempre significa que algo externo afectó a la producción después del último despliegue.
Plataformas como Galtea evalúe con base en una especificación de calidad compartida, de modo que la puerta de pre-despliegue y el monitor de producción verifiquen los mismos criterios en lugar de dos umbrales calibrados por separado por dos equipos distintos.
Errores comunes
Omitir el monitoreo en línea tras realizar la evaluación fuera de línea. Una evaluación exhaustiva previa al despliegue genera confianza. Y la confianza es precisamente lo que permite que un sistema en producción se desvíe durante semanas antes de que alguien lo revise. Cuanto mejor sea la evaluación fuera de línea, mayor será la sorpresa al descubrir que no es suficiente.
Tasas de muestreo demasiado bajas. Una muestra del 0,5% sobre 1.000 solicitudes al día equivale a cinco ejemplos evaluados; no es suficiente para detectar una caída real en la calidad con confianza. Aumente la tasa o agrupe las evaluaciones en un periodo de tiempo más largo.
Tratar las puntuaciones en línea y fuera de línea como equivalentes. Provienen de distribuciones de consultas diferentes, tienen distinta disponibilidad de datos reales y, a menudo, pasan por jueces calibrados para propósitos distintos. La misma cifra, un 0,85 de fidelidad, significa algo diferente según el entorno que la haya generado.
No registrar la versión del modelo por solicitud. El monitor en línea detecta una caída a partir de una fecha específica y la primera pregunta siempre es qué cambió. Sin la versión del modelo en los registros, un cambio por parte del proveedor es invisible en sus propios datos; nunca lo encontrará allí.
Fatiga por alertas debido a umbrales demasiado estrictos. Una alerta que se dispara constantemente termina siendo desactivada, permanentemente, por lo general en menos de un mes. Establezca el umbral en función de la caída de calidad que realmente requiera una acción, no en lo que mantenga el panel de control en silencio durante la operación normal.
Observar puntuaciones agregadas sin desgloses por segmentos. Las regresiones específicas de una categoría desaparecen dentro de un agregado estable una y otra vez. Monitoree por tipo de consulta, no solo por la cifra global, o no verá el fallo hasta que sea lo suficientemente grande como para afectar al promedio.
