Evaluación LLM online vs offline: cuál necesitas (y cuándo)
La evaluación LLM online vs offline es una sola decisión, no dos, y nuestra suite de promptfoo lo demostró el martes pasado: un system prompt reescrito, 47 casos de prueba y la fidelidad cayó de 0.91 a 0.74 en unos 90 segundos de tiempo de CI. El check offline detectó esa regresión antes del merge; el monitoreo en producción la habría encontrado después, disfrazada de ticket de soporte. Offline vs online, mismo veredicto: dos carriles, trabajos distintos.
La evaluación LLM offline ejecuta tu modelo contra un dataset fijo antes del despliegue y demuestra que un cambio no rompió la calidad medida. La evaluación online puntúa el tráfico real de producción después del lanzamiento y expone lo que el dataset nunca contuvo. La mayoría de los equipos necesitan ambas, en secuencia: la offline protege el despliegue, la online detecta la deriva.
Conclusiones clave
- La evaluación offline se ejecuta contra un dataset fijo antes del despliegue; la online puntúa el tráfico real después del lanzamiento.
- La mayoría de los equipos necesitan ambas: la offline protege los despliegues, la online detecta lo que el dataset dejó pasar.
- La offline detecta regresiones de prompt y rupturas de formato; la online detecta deriva, latencia bajo carga y rarezas de integración.
- Conecta las evals offline como puerta de merge en CI y alimenta tu set de evals con las puntuaciones online de las trazas de producción.
¿En qué se diferencian realmente la evaluación online y la offline? (9 dimensiones)
Los dos modos difieren en nueve ejes, pero el decisivo es la fuente de datos: la evaluación offline puntúa un dataset fijo y versionado antes del despliegue, mientras que la online puntúa el tráfico real después del lanzamiento. Todas las demás diferencias, coste, latencia, riesgo y gobernanza, se derivan de esa división.
El centro de aprendizaje de Label Studio presenta el par como modos complementarios y no como rivales, y estamos de acuerdo. La tabla amplía ese enfoque con métricas específicas de LLM que su versión genérica de ML no cubre.
| Dimensión | Offline | Online |
|---|---|---|
| Fuente de datos | Dataset dorado fijo, versionado en git | Trazas de producción reales, muestreadas |
| Momento | Antes del despliegue, en cada PR | Después del lanzamiento, continua |
| Coste por ejecución | Tokens de juez por suite ejecutada; coste marginal casi nulo | Tokens de juez sobre tráfico muestreado; escala con el volumen |
| Restricción de latencia | Ninguna; en lote y sin prisa | Presupuestos de subsegundo en rutas críticas |
| Riesgo para usuarios | Cero; los fallos nunca llegan a usuarios | Real; las malas respuestas afectan sesiones vivas |
| Velocidad de feedback | Minutos por PR | De segundos a minutos en streaming |
| Tipos de métricas | Fidelidad, relevancia de respuesta, cumplimiento de formato, puntuaciones de benchmark | Percentiles de latencia, tasa de error, tasa de alucinaciones, feedback de usuarios |
| Repetibilidad | Determinista con modelo y dataset fijados | No determinista; la mezcla de tráfico cambia a diario |
| Gobernanza y auditoría | Artefactos versionados, diferenciables entre releases | Dashboards y alertas; más difícil de reproducir |
Nuestra interpretación: la columna offline responde "¿este cambio rompió algo?" y la columna online responde "¿producción se está alejando de lo que probamos?". La fila de tipos de métricas es donde más divergen; nuestra guía de métricas de evaluación LLM desglosa cada una.
¿Qué detecta cada modo y qué se escapa por ambos?
Cada modo tiene una clase de fallo privada que el otro no puede ver. La offline detecta los cambios que tú hiciste; la online detecta los cambios que el mundo hizo a tu alrededor. Los fallos costosos, los que sobreviven a ambas redes, necesitan un revisor humano. Esta taxonomía es nuestra síntesis de lo que reporta cada modo, no un estándar publicado.
| Cuadrante | Ejemplos | Acción |
|---|---|---|
| Solo offline | Regresiones de prompt, formatos de salida rotos, caídas en puntuaciones de benchmark, fidelidad bajo el umbral | Bloquear el merge en CI |
| Solo online | Deriva de distribución, latencia bajo carga, rarezas de integración, patrones de abuso adversario | Alertar, muestrear las trazas, enviarlas al set de evals |
| Detectado por ambos | Picos en la tasa de alucinaciones, erosión de la consistencia factual | Mantener ambos; deduplicar el esfuerzo, no la cobertura |
| Detectado por ninguno | Casos límite nuevos, juicios de calidad subjetivos, deriva de la voz de marca | Cola de revisión humana; los casos etiquetados alimentan el set offline |
El cuadrante de solo offline es donde las puertas de CI se ganan el sueldo: un prompt reescrito que baja en silencio el cumplimiento de formato del 99% al 91% es invisible en una revisión de código y obvio en una suite de 47 casos. El cuadrante de solo online es más escurridizo. Los usuarios reales formulan preguntas que tu set dorado nunca contempló, las APIs de terceros se caen en horarios que staging nunca toca y alguien le enviará a tu chatbot un prompt de 40.000 caracteres solo para ver qué pasa. Para ese lado, nuestra guía sobre evaluar agentes en producción cubre la puntuación de trayectorias multipaso, no solo de salidas individuales.
La fila de abajo es la que los equipos se saltan, y la que les quema. Los fallos que te cuestan usuarios son los que ningún modo detecta por sí solo. Necesitan un humano en el bucle.
¿Cómo conectas las evals offline a una puerta de CI? (La config que nadie muestra)
Añade un ejecutor de evals como check de estado obligatorio en cada pull request que toque un prompt, un modelo o la config de recuperación. Afirmas un umbral. Bloqueas el merge por debajo de él. promptfoo documenta exactamente este patrón de CI, y es el que nosotros ejecutamos.
El paso de GitHub Actions
Una versión reducida de la puerta que ejecutamos hoy:
name: llm-eval-gate
on:
pull_request:
paths: ["prompts/**", "evals/**", "src/rag/**"]
jobs:
faithfulness-gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Run offline evals, fail the PR on regression
run: npx promptfoo@latest eval --config evals/support-agent.yaml
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} # LLM-as-judgeLa config YAML declara los casos de prueba y las aserciones; eval termina con código distinto de cero cuando la suite cae bajo el umbral, GitHub marca el check obligatorio como fallido y el botón de merge se pone gris. El filtro de paths importa: un arreglo al README no debería quemar tokens de juez.
Lo que la puerta detecta de verdad
La versión en producción puntúa nuestra cadena RAG del agente de soporte contra 47 casos dorados en cada PR que afecta los prompts. Una ejecución completa toma unos 90 segundos de tiempo de CI y el merge se bloquea automáticamente si la fidelidad cae por debajo de 0.82. En tres meses ha detectado dos regresiones que de otro modo habrían salido a producción: una reescritura del system prompt que empujó la fidelidad de 0.91 a 0.74, y un cambio en el recuperador que duplicó la longitud del contexto y arrastró la relevancia de respuesta bajo el umbral. Ninguna de las dos parecía peligrosa en la revisión.
Una puerta de fidelidad en CI cuesta 90 segundos por PR. Una regresión de fidelidad en producción te cuesta un ticket de soporte y un rollback.
Comparamos los ejecutores que puedes conectar a este patrón, promptfoo, DeepEval y el resto, en nuestro roundup de herramientas de evaluación LLM.
¿Qué herramientas ejecutan cada modo? (Matriz herramienta-modo)
Ninguna herramienta domina ambos carriles con limpieza. promptfoo y DeepEval son ejecutores offline-first que pueden puntuar datos de producción exportados de forma programada; Langfuse y LangSmith son almacenes de trazas online-first que acoplan puntuadores LLM-as-judge a las trazas ingeridas. La matriz es nuestra lectura de la documentación de cada proveedor: interpretación, no dogma.
| Herramienta | Ejecutor offline | Puntuador online | ¿Ambos de forma nativa? | Lo que NO hace |
|---|---|---|---|---|
| promptfoo | Sí: suites YAML, nativo de CI, packs de red team | Parcial: las mismas configs contra logs exportados | Offline-first; el online necesita un paso de exportación | Ingerir trazas vivas; servir de dashboard de monitoreo |
| DeepEval | Sí: tests estilo pytest, más de 14 métricas | Sí, vía la plataforma Confident AI | Sí, con el add-on alojado | La librería open-source sola es solo offline |
| Langfuse | Parcial: experimentos de dataset vía SDK | Sí: evaluadores juez sobre trazas ingeridas | Sí: datasets más puntuadores de trazas | Ejecutar tu puerta de merge en CI; eso lo conectas tú |
| LangSmith | Sí: datasets y experimentos offline | Sí: automatizaciones que puntúan trazas muestreadas | Sí | Vivir fuera del stack de LangChain sin fricción |
| OpenAI Evals | Sí: evals YAML estilo registro | No | No | Pipelines de trazas de producción; modelos que no sean de OpenAI |
| Arize Phoenix | Sí: experimentos en notebook primero | Sí: spans y trazas con evaluadores en línea | Sí | Montaje ligero; la observabilidad va primero |
Elige promptfoo o DeepEval si tu primera necesidad es una puerta de merge que bloquee malos prompts en CI. Elige Langfuse o LangSmith si tu primera necesidad es puntuar tráfico vivo, y nuestra comparativa de Langfuse vs LangSmith analiza esa elección en detalle. OpenAI Evals sigue siendo la rara: un ejecutor offline estilo registro sin lado de producción.
promptfoo protege tus PRs. Langfuse puntúa tus trazas de producción. Ninguna reemplaza a la otra.
¿Cómo convierte el bucle de feedback los fallos online en tests offline?
Muestrea las trazas de producción con baja puntuación, etiquétalas y haz commit al set de evals offline. Entonces la suite de regresión crece con cada sorpresa que producción te lanza, y el siguiente despliegue se evalúa contra el set ampliado. El marco del volante de inercia es nuestro; es la parte que la mayoría de los equipos nunca construye.
El ciclo, tal como lo ejecutamos:
- Los puntuadores online marcan las trazas por debajo de 0.7 de puntuación de juez.
- Muestreamos de 20 a 30 trazas marcadas por semana.
- Un humano etiqueta cada una: salida esperada más clase de fallo.
- Los casos etiquetados se unen al set de evals offline como nuevos ejemplos dorados.
- El siguiente PR se ejecuta contra la suite ampliada y el bucle reinicia.
El muestreo empieza en tu capa de observabilidad LLM, porque las trazas son la materia prima. Sobre la cadencia: semanal gana a mensual, porque la deriva se acumula. Etiquetamos de 10 a 15 casos por semana, y el set es "suficientemente grande" cuando las etiquetas nuevas dejan de mover la tasa de aprobados, entre 150 y 250 casos para un agente de soporte estrecho. La línea entre modos se sigue difuminando: Deepchecks reporta que los ingenieros de Union.ai programan sus evaluaciones "offline" cada pocos minutos, convirtiéndolas de hecho en checks casi en tiempo real.
Tu set de evals no es un artefacto fijo. Crece cada semana que producción te sorprende.
¿Cuándo necesitas ambas? (Evaluación LLM online vs offline por etapa)
Necesitas ambas desde la semana de lanzamiento en adelante, pero el equilibrio cambia por etapa: la offline carga sola con el trabajo previo al despliegue, la semana de lanzamiento añade puntuación shadow o canary, el estado estable se apoya en el monitoreo online con re-ejecuciones offline periódicas, y una alerta de deriva debería terminar en un test offline reproducido más un set de evals más grande.
| Etapa | Offline | Online | Acción |
|---|---|---|---|
| Pre-despliegue | Puerta de regresión en cada PR | Ninguna aún | Bloquear el merge bajo el umbral |
| Semana de lanzamiento | Suite completa sobre el release candidate | Puntuación shadow o canary sobre el 5-10% del tráfico | Comparar las puntuaciones online contra la base offline |
| Estado estable | Re-evaluación periódica sobre un dataset refrescado, semanal o mensual | Puntuación continua muestreada más alertas | Vigilar la deriva; re-baselizar cada trimestre |
| Deriva detectada | Reproducir las trazas fallidas offline | La alerta que disparó el gatillo | Añadir las trazas etiquetadas al set de evals; re-proteger el siguiente despliegue |
El pre-despliegue es el lugar más barato para ser estricto: un merge bloqueado cuesta minutos; un mal release cuesta confianza. La semana de lanzamiento es donde los equipos invierten de menos, aunque la puntuación shadow sobre una porción pequeña de tráfico cuesta poco y revela si el set dorado mintió. El estado estable es donde se instala la complacencia, así que pon la re-evaluación en el calendario.
¿Y qué pasa con la EU AI Act?
Las obligaciones de alto riesgo de la EU AI Act entran en vigor de forma escalonada hasta agosto de 2026, con el calendario completo de plazos publicado en EUR-Lex, y el patrón de conformidad encaja con limpieza en los dos modos. La evidencia offline documentada muestra que el sistema cumplió los objetivos de calidad antes del release; el monitoreo online continuo muestra que los sigue cumpliendo después. Nuestra lectura es que una pista de auditoría necesita ambos artefactos, porque los logs offline solos no prueban que el sistema siguiera siendo conforme, y los dashboards solos no prueban que se lanzara siendo conforme. Eso es interpretación, no asesoramiento legal; nuestra guía pilar sobre el pipeline de evaluación LLM mapea el conjunto completo de requisitos.
La evaluación offline es tu evidencia. La evaluación online es tu sistema de alerta temprana. Los reguladores quieren ambas.
Sobre el autor: Mert Batur es cofundador de Techsy.io, donde el equipo lanza agentes de IA, sistemas de automatización y pipelines de voz/SDR para clientes B2B. Escribe sobre el stack de herramientas LLM que el equipo de Techsy usa de verdad en producción. Conecta en LinkedIn.
Preguntas frecuentes
¿Qué es la evaluación LLM offline?
La evaluación LLM offline ejecuta un modelo o prompt contra un dataset fijo y versionado antes del despliegue. Los checks típicos incluyen fidelidad al contexto recuperado, relevancia de respuesta, cumplimiento de formato y puntuaciones de benchmark. Como el dataset nunca cambia a mitad de ejecución, los resultados son repetibles y diferenciables, que es exactamente la razón por la que las suites offline funcionan como puertas de merge en CI.
¿Qué es la evaluación LLM online?
La evaluación LLM online puntúa el tráfico real de producción después del lanzamiento. Un puntuador LLM-as-judge califica las trazas muestreadas por alucinación, tono o corrección de llamadas a herramientas, y las puntuaciones fluyen a un dashboard. También absorbe señales que los tests offline no pueden ver: latencia bajo carga, feedback de usuarios y cómo las consultas reales difieren de tu set dorado.
¿Cuándo debo usar evaluación LLM offline vs online?
Usa la evaluación offline para proteger los despliegues: cada cambio de prompt, modelo o recuperación debería pasar la suite antes del merge. Usa la evaluación online para monitorear lo que se lanza. La mayoría de los equipos secuencian ambas en lugar de elegir una: offline primero, online desde la semana de lanzamiento, con los fallos de producción fluyendo de vuelta al set offline.
¿Cuál es un ejemplo de evaluación LLM online vs offline?
Ejemplo offline: una suite de promptfoo ejecuta 200 preguntas doradas de soporte en cada pull request y bloquea el merge si la fidelidad cae por debajo de 0.82. Ejemplo online: Langfuse puntúa el 10% de las trazas vivas con un check de alucinación LLM-as-judge y alerta cuando la media semanal baja. La misma rúbrica, distinta fuente de datos.
¿Cómo encaja el human-in-the-loop en la evaluación LLM?
Los humanos cierran la brecha que ningún modo cubre: casos límite nuevos, juicios de calidad subjetivos y deriva de la voz de marca. Una cadencia práctica es etiquetar de 10 a 20 trazas muestreadas de baja puntuación por semana y hacer commit de los casos etiquetados al set de evals offline. La cola de revisión es una entrada del pipeline, no un proyecto paralelo.
¿Cómo funcionan las evaluaciones de Langfuse para la puntuación online?
Langfuse ingiere trazas de tu aplicación y luego acopla evaluadores LLM-as-judge que puntúan cada traza contra una rúbrica: alucinación, relevancia, toxicidad o un prompt personalizado. Las puntuaciones llegan a un dashboard indexado por sesiones y usuarios. Los equipos exportan las trazas de baja puntuación persistente a un dataset offline para tests de regresión. Nuestro roundup de plataformas de observabilidad compara los almacenes de trazas que alimentan este patrón.
¿Cómo añado evals offline a un pipeline de CI/CD?
Añade un ejecutor de evals como check de estado obligatorio en las pull requests que toquen prompts, modelos o config de recuperación. promptfoo y DeepEval se ejecutan en modo headless y terminan con código distinto de cero cuando falla una aserción, lo que bloquea el merge automáticamente. La puerta YAML de antes en este post es una plantilla funcional; empieza con 30 a 50 casos.
¿La EU AI Act exige evaluación offline u online?
En la práctica, ambas. Para sistemas de alto riesgo, la ley espera evidencia documentada de que los objetivos de calidad se cumplieron antes del release, lo que significa artefactos offline, más monitoreo continuo después del despliegue, lo que significa telemetría online. Sus plazos escalonados llegan hasta agosto de 2026 según EUR-Lex. Esa es nuestra lectura del patrón de conformidad, no asesoramiento legal.
¿Puede LLM-as-a-judge ejecutarse en ambos modos, offline y online?
Sí, y debería, porque la rúbrica se transfiere. En offline, el juez puntúa en lote cada salida del set de evals durante el CI. En online, el mismo prompt de juez puntúa las trazas de producción muestreadas casi en tiempo real. Mantener una sola rúbrica en ambos modos es lo que hace que tu base offline sea comparable con tu señal de deriva online.
¿Qué métricas difieren entre la evaluación offline y la online?
Las métricas offline miden la calidad de la salida contra la verdad de referencia: fidelidad, relevancia de respuesta, cumplimiento de formato, puntuaciones de benchmark. Las métricas online añaden señales operativas y de comportamiento: latencia p95, tasa de error, tasa de alucinaciones sobre tráfico vivo, puntuación de deriva y satisfacción del usuario. La lista offline pregunta "¿es buena?" y la lista online pregunta "¿sigue siendo buena?".
La versión corta
- La evaluación offline y la online son carriles complementarios, no una elección excluyente: una protege lo que lanzas, la otra vigila lo que lanzaste.
- Empieza con la puerta de CI esta semana, añade la puntuación de trazas online en el lanzamiento y conecta el bucle de feedback antes de que tu set de evals se pudra.
- El bucle es el sistema. Un dataset dorado estático se pudre; uno que crece se acumula.
Si quieres unos segundos ojos sobre tu pipeline de evals, pide una consulta gratuita.