Tu evaluación offline miente: mide tu IA en producción

TL;DR: La evaluación offline de un modelo de IA (correrlo contra tu dataset de test) no predice cómo se comportará con usuarios reales. La evaluación de modelos en producción (online evaluation con shadow traffic, canary y A/B testing) mide el comportamiento real, donde de verdad importa. Aquí tienes el mínimo viable para montarla en un equipo pequeño sin montar una plataforma de MLOps entera.

El problema: "funciona en mi dataset" no basta

Cambias un prompt, corres tu suite de evals offline y la métrica sube. Lo despliegas. En producción, los usuarios empeoran su tasa de éxito. ¿Qué ha pasado?

El dataset de test es una foto fija. Los usuarios reales mandan inputs raros, frases a medias, contextos largos y casos que tu golden set nunca capturó. Por eso una mejora offline puede convertirse en regresión online, y al revés: un cambio que apenas movía la aguja offline entrega una mejora clara en producción.

Esto no es teórico. DoorDash documentó un gap de cerca del 4% de accuracy entre sus pruebas controladas y producción. Y es el patrón general: la evaluación offline asegura estabilidad; la online asegura que el cambio sobrevive al mundo real. Necesitas las dos, pero la offline no decide por ti.

En mi experiencia operando pipelines con LLMs, el error más caro es confiar en un número de un notebook como si fuera la verdad. Igual que la explicabilidad de modelos con LIME y SHAP te obliga a mirar dentro de la caja negra, la evaluación online te obliga a mirar fuera de tu máquina.

¿Qué es la evaluación offline?

La evaluación offline mide un modelo contra un dataset fijo con respuestas esperadas, en un entorno controlado y reproducible. Es lo que corres en CI antes de desplegar.

Es barata, rápida y segura. Sirve para detectar regresiones obvias, comparar modelos y experimentar sin riesgo. Su límite es estructural: solo sabe lo que tú metiste en el dataset.

¿Qué es la evaluación online (en producción)?

La evaluación online mide el modelo con tráfico real, en vivo o en sombra, contra métricas de negocio y no solo de accuracy. Captura distribución real de inputs, latencia bajo carga y el comportamiento que ningún golden set predice.

Su precio es la complejidad: los resultados son ruidosos, hay variables que confunden (estacionalidad, cambios de UX) y los errores afectan a usuarios. Por eso se hace por capas.

Aspecto	Offline	Online (producción)
Dónde corre	CI/CD, dataset fijo	Tráfico real
Qué mide	Competencia (accuracy, relevancia)	Valor real (conversión, escalado, satisfacción)
Riesgo para el usuario	Cero	Controlable por capas
Velocidad	Minutos	Días o semanas
Cuándo usar	Antes de desplegar	Validar que el cambio sobrevive

El rollout por capas: de la sombra al 100%

La clave no es elegir online u offline, sino encadenar etapas que suben el riesgo poco a poco. Este es el orden que funciona en producción:

1. Shadow traffic (sombra): el modelo candidato procesa las peticiones reales en paralelo al de producción, pero su respuesta nunca llega al usuario. Solo la registras y comparas. Riesgo cero, datos reales.
2. Canary interno: usuarios de confianza (tu equipo) ven el candidato.
3. Canary externo pequeño: del 1 al 5% del tráfico, con rollback automático si una métrica cae.
4. A/B test: repartes tráfico entre control y variante y comparas KPIs con tamaño de muestra suficiente.
5. Rollout completo: mantienes siempre el camino de vuelta.

El shadow traffic es la joya para equipos pequeños: validas con inputs reales sin arriesgar la experiencia. Es el equivalente, en evaluación, a una separación de responsabilidades limpia: el tráfico que decide es uno, el que observas es otro.

Implementación: el mínimo viable de shadow traffic

No necesitas Braintrust ni Arize para empezar. Con FastAPI y una tarea en segundo plano tienes shadow evaluation funcional.

Lanza el candidato en paralelo sin bloquear ni afectar la respuesta del usuario:

# Sirve la respuesta de producción y evalúa el candidato en sombra
@app.post("/chat")
async def chat(req: ChatRequest, background: BackgroundTasks):
    prod_resp = await prod_model.generate(req.prompt)
    # El candidato corre en background: nunca bloquea ni llega al usuario
    background.add_task(shadow_eval, req.prompt, prod_resp)
    return prod_resp

La tarea en sombra registra ambas salidas para compararlas después, en frío:

# Registra prod vs candidato para análisis posterior (no afecta al usuario)
async def shadow_eval(prompt: str, prod_resp: str):
    cand_resp = await candidate_model.generate(prompt)
    await log_store.save({
        "prompt": prompt,
        "prod": prod_resp,
        "candidate": cand_resp,
        "judge_score": await llm_judge(prompt, cand_resp),  # LLM-as-judge
    })

Con esos logs comparas la calidad del candidato contra producción sobre inputs reales. Si quieres puntuar de forma automática, un modelo fuerte como juez (LLM-as-judge) escala mejor que la revisión manual, con el matiz de que mide si la respuesta parece buena, no si el usuario actúa sobre ella.

En Producción

Mide coste y calidad juntos, nunca por separado. Una ruta más barata que baja la tasa de tareas completadas no es más barata.

• Métricas que importan: coste por tarea exitosa (no por petición), tasa de escalado, re-preguntas, correcciones del usuario, latencia y un score de calidad. En APIs de LLM, un rango realista de gasto para un proyecto pequeño ronda los 10 a 50 € al mes; el shadow traffic lo duplica temporalmente, tenlo en cuenta.
• Tamaños de muestra grandes: la varianza de salida de un LLM es alta. Las muestras pequeñas mienten. Necesitas más muestra que en software determinista y segmentar por tipo de tarea: un prompt puede mejorar el resumen y empeorar el tool calling a la vez.
• Data drift: los inputs cambian con el tiempo. Monitoriza la distribución de entradas, no solo la métrica de salida, para detectar deriva antes de que se note en el negocio.
• Rollback automático: el canary debe revertir solo si una métrica cae bajo un umbral. Sin esa red, el canary es una bomba de relojería.

La diferencia entre el tutorial y producción real es esta: en el tutorial el dataset es estable; en producción la distribución se mueve, la latencia varía bajo carga y el coste se dispara si no lo vigilas.

Errores comunes y depuración

• Error: el cambio sube offline pero empeora en producción. Causa: tu golden set no representa la distribución real de inputs. Solución: reconstruye el dataset a partir de logs de producción, no de ejemplos inventados.
• Error: el A/B no da significancia estadística. Causa: muestra demasiado pequeña para la varianza del LLM. Solución: alarga el experimento, segmenta por tipo de tarea y usa la misma métrica de negocio antes y después.
• Error: el LLM-as-judge premia respuestas largas y vacías. Causa: el juez mide forma, no valor. Solución: calibra el juez contra etiquetas humanas en una muestra y añade métricas de comportamiento real del usuario.

Si tu sistema es un RAG, recuerda que la evaluación de retrieval es su propia capa: medir solo la respuesta final esconde qué falló. Cuando el vector recupera mal, lo arregla la búsqueda híbrida y el re-ranking, no un prompt más bonito.

Preguntas frecuentes

¿La evaluación offline es inútil entonces?

No. Es necesaria pero no suficiente. Sirve para comparar modelos de forma reproducible y atrapar regresiones obvias en CI, pero no predice el comportamiento bajo tráfico real. Es tu primera barrera, no la última.

¿Cuándo paso de offline a online?

Cuando las métricas offline son estables y la mejora parece significativa, especialmente antes de un despliegue amplio o un cambio de alto impacto. Empieza siempre por shadow traffic, que no expone nada al usuario.

¿Y si offline y online se contradicen?

Es común y valioso. El desacuerdo suele señalar distribution shift, problemas de UX o efectos a nivel de sistema que el dataset offline no capturó. Investiga la causa, no descartes el online por incómodo.

Cierre

Hemos visto por qué la evaluación de modelos en producción no es un lujo de equipos enormes, sino la única forma de saber si un cambio sirve de verdad. La clave está en encadenar etapas que suben el riesgo poco a poco (shadow, canary, A/B) y en medir coste y calidad juntos sobre inputs reales, no sobre un dataset que envejece en tu disco. Empieza hoy por lo más barato: registra en sombra el candidato y compáralo con producción antes de exponer a un solo usuario.

Si te interesa cómo se separa la señal del ruido al elegir un modelo, este mismo principio aparece en por qué los benchmarks de coding agéntico te hacen elegir mal tu modelo: un número global no decide por ti. El siguiente paso natural es montar detección de data drift automática, que dejaré para un próximo artículo.

¿Has tenido un cambio que mejoraba offline y empeoraba con usuarios reales? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_.