Todo el que ha desplegado una aplicación LLM en producción conoce la secuencia: la demo funciona a la perfección, los stakeholders están entusiasmados, las primeras respuestas parecen convincentes. Y entonces llega un cliente con una pregunta que nadie había probado y el modelo responde con la confianza de un experto algo que es, simplemente, falso. O bien, tras actualizar el prompt, se descubre que un edge case que antes funcionaba ha dejado de funcionar. Sin saber cuándo. Sin saber por qué.
El problema no es el modelo. El problema es la ausencia de medición. Este artículo trata de cómo construir una infraestructura de evaluación que le diga — con números, no con intuición — si su aplicación LLM es mejor o peor que ayer.
Por qué "se ve bien" no es una métrica
En el software tradicional existen unit tests, tests de integración y un pipeline de CI. Antes de cada merge se sabe si algo ha dejado de funcionar. Los outputs de un LLM son probabilísticos — el mismo input puede producir un output ligeramente distinto, y una respuesta incorrecta no lanza ninguna excepción. El fallo es silencioso.
Los equipos sin proceso de evaluación dependen de dos o tres personas que de vez en cuando navegan por la aplicación y dicen "parece que va bien". Esto funciona hasta los primeros 200 usuarios. Después el espacio de casos de uso se expande, los modelos cambian, los prompts se ajustan — y nadie sabe qué acaba de romperse.
Eval (evaluación) es la medición sistemática de la calidad de los outputs de un LLM frente a criterios definidos. No una vez, sino como proceso continuo: antes del deploy, tras cada cambio de prompt, tras cada actualización de modelo y de forma periódica en producción.
Tres tipos de evals — dónde encaja cada uno
Antes de hablar de herramientas, es importante distinguir tres contextos distintos en los que se realiza la evaluación:
Offline eval — se ejecuta antes del deploy sobre un dataset fijo. La respuesta es rápida y reproducible. Adecuado para tests de regresión en CI/CD.
Online eval — se ejecuta en producción sobre consultas reales, habitualmente sobre una muestra. Detecta el distribution shift: los usuarios reales se comportan de forma distinta a los escenarios de prueba.
Fine-tuning eval — caso específico en el que se mide si el modelo ajustado es mejor que el base en las tareas objetivo. Lo describe un artículo separado (Cómo medir si el fine-tuning ha funcionado). No forma parte de este artículo.
RAG eval — mide faithfulness (¿ha respondido el modelo según la información que tenía disponible?), answer relevancy y context recall. El estándar es el framework RAGAS, descrito en el artículo Cómo evaluar RAG (RAGAS). Tampoco forma parte de este artículo.
Este artículo se centra en el offline eval y el online eval para una aplicación LLM en producción — chatbot, copilot, agente.
Cómo construir un eval set a partir de casos reales
El error más frecuente: el eval set lo crea un AI engineer en una sesión de brainstorming durante el fin de semana. El resultado cubre lo que él cree que son los edge cases — no lo que los usuarios reales preguntan de verdad.
El procedimiento correcto:
- 1.Registre los logs reales desde el primer día. Registre cada consulta y cada respuesta (con anonimización de PII). Este es su activo más valioso.
- 2.Identifique los fallos. Revise manualmente las primeras 200–500 interacciones reales. ¿Dónde respondió mal el modelo? ¿Dónde se negó a responder cuando debería haberlo hecho? ¿Dónde fue innecesariamente vago?
- 3.Categorice los fallos por tipo. Ejemplos de categorías: alucinación de hechos, rechazo incorrecto, formato de respuesta erróneo, respuesta relevante pero incompleta, evasión de controles de seguridad.
- 4.Seleccione casos representativos de cada categoría. Muestra dorada mínima (golden set): 100–300 ejemplos con la respuesta correcta o el criterio de evaluación. Para un sistema en producción: 500–1 000+ casos.
- 5.Anote cada ejemplo con ground truth o una rúbrica. Para casos simples: respuesta de referencia o expected output. Para casos complejos: rúbrica (conjunto de criterios que la respuesta debe cumplir).
El golden set no es estático. Cada mes añada nuevos fallos procedentes de producción. Un set antiguo que no se actualiza deja de reflejar el comportamiento real de los usuarios.
Métricas — precisas cuando se dispone de referencia
Para tareas inequívocas (extracción, clasificación, output estructurado) funcionan las métricas deterministas:
- Exact match — el output coincide con la referencia o no. Adecuado para extracción de entidades, clasificación de clases, esquemas JSON.
- F1 score — mide el solapamiento de tokens entre el output y la referencia. Adecuado cuando existen múltiples formulaciones correctas.
- BLEU / ROUGE — estándar para traducción y resumen. En la práctica poco utilizados para aplicaciones LLM generales; más apropiados para tareas NLP específicas.
Estas métricas son rápidas, baratas y deterministas. Pero fallan para la mayoría de casos de uso en producción, donde la "respuesta correcta" puede tener decenas de formulaciones.
LLM-as-judge — potencial y límites
Para tareas abiertas — donde la respuesta de referencia no existe o es demasiado variable — entra en juego el LLM-as-judge: otro LLM (más grande o igual de capaz) evalúa el output según una rúbrica.
¿Por qué funciona? Los modelos de la clase GPT-4 alcanzan aproximadamente un 85 % de acuerdo con revisores humanos, consistencia superior a la concordancia habitual entre humanos (alrededor del 81 %) en las mismas tareas. Con un coste entre 500 y 5 000 veces inferior al de la anotación humana.
Sin embargo, el LLM-as-judge tiene cinco sesgos documentados que hay que compensar activamente:
1. Position bias — el judge prefiere la respuesta que aparece en primer lugar (o en último). Solución: compare siempre con el orden invertido (A vs B → luego B vs A) y use voto mayoritario.
2. Verbosity bias — una respuesta más larga parece más convincente aunque sea menos precisa. Consecuencia directa de cómo se entrenaron los modelos con feedback humano. Solución: penalice explícitamente en la rúbrica la extensión innecesaria.
3. Self-preference bias — el modelo favorece sus propios outputs. Claude v1 mostraba un win rate propio aproximadamente un 25 % superior en la autoevaluación; GPT-4, alrededor del 10 %. Solución: nunca utilice el mismo modelo como productor y como judge.
4. Format bias — las respuestas con markdown, bullet points o estructura ordenada reciben puntuaciones más altas. Solución: la rúbrica evalúa el contenido, no la presentación.
5. Calibration drift — en evaluaciones por lotes largas, el judge se vuelve o demasiado benevolente o demasiado estricto. Solución: inserte siempre en el lote varios ejemplos de calibración con puntuación conocida y monitorice el drift.
Estructura práctica recomendada para una llamada de LLM-as-judge:
- Prompt de sistema: rol del judge, lista de dimensiones de evaluación, escala numérica (p. ej., 1–5 por dimensión)
- Prompt de usuario: contexto de la pregunta, respuesta a evaluar, rúbrica con definiciones de cada puntuación
- Ejemplos few-shot: 3–5 casos bien valorados y 3–5 mal valorados (elevan la consistencia de alrededor del 65 % a alrededor del 77 %)
Concordancia del judge con revisores humanos: si la mide y supera el 75 %, tiene una señal utilizable. Por debajo del 65 %, el judge genera más ruido que información — es momento de reconstruir la rúbrica.
G-Eval y evaluación DAG
Los frameworks de evaluación modernos como DeepEval implementan enfoques que van más allá del simple "asigna una puntuación del 1 al 5":
G-Eval — el judge genera primero un procedimiento de evaluación (pasos de chain-of-thought) y luego puntúa según ese procedimiento. Reduce la arbitrariedad de la evaluación.
DAG scoring — descompone la evaluación en un árbol de condiciones. En lugar de "¿es esto bueno?" recorre: "¿es factualmente correcto?" → si sí: "¿es completo?" → si sí: "¿es seguro?". Cada nodo puede ser una métrica distinta o una llamada a LLM-as-judge.
Para sistemas en producción recomendamos la combinación: métricas deterministas para lo que se puede medir objetivamente, más LLM-as-judge para dimensiones como coherencia, tono o integridad.
Tests de regresión en CI antes de cada release
Este es el workflow práctico que recomendamos a nuestros clientes:
- 1.Golden set en el repositorio — el dataset de evaluación es parte del código, versionado en git junto a los prompts.
- 2.Paso de CI para eval — antes de cada merge a main, se ejecuta el pipeline de evaluación. Si la puntuación agregada cae más del umbral definido (p. ej., 3 puntos porcentuales), el merge queda bloqueado.
- 3.Tests específicos de regresión — a cada fallo detectado en producción se añade un test case. Un error detectado una vez no puede volver a colarse en silencio.
- 4.Entorno de eval separado — el pipeline de evaluación no llama al mismo modelo/endpoint que producción. El aislamiento evita que el eval contamine los logs de producción.
- 5.Resultados visibles — no solo pass/fail. Cada PR incluye un eval diff: qué métricas mejoraron, cuáles bajaron y en cuánto.
DeepEval es el estándar de facto para el CI/CD gating — se integra como plugin de pytest, exporta a JUnit XML para CI y ofrece gating basado en umbrales. Para dashboards de stakeholders y trazabilidad en producción lo complementa Braintrust.
Online eval — lo que se escapa a los tests offline
El offline eval le dice si su aplicación funciona en los ejemplos que ya conoce. No le dice si los usuarios reales se van a encontrar con algo nuevo.
El online eval suele ejecutarse sobre el 5–10 % de las consultas en producción (muestreo por coste). Lo que busca:
- Distribution shift — los usuarios preguntan cosas que no están en el golden set. Monitorice las categorías donde el judge puntúa consistentemente bajo.
- Anomalías — respuestas inesperadamente cortas o largas, baja consistencia en ejecuciones repetidas o patrones de seguridad.
- Trade-off latencia vs. calidad — un modelo más rápido puede ser peor en categorías específicas.
Los datos del online eval se incorporan periódicamente al golden set. El ciclo: producción → fallos → golden set → tests de CI → deploy.
Diferencia respecto al fine-tuning eval y al RAG eval
Los equipos suelen confundir estos tres tipos de evaluación:
Fine-tuning eval — mide si el modelo ajustado hace lo que se pretendía con el ajuste. Compara el modelo base frente al modelo fine-tuned en un dataset específico de la tarea. No pertenece al pipeline de CI de una aplicación en producción — es un experimento puntual (o por ejecución) previo al registro del modelo. Más detalles en Cómo medir si el fine-tuning ha funcionado.
RAG eval (RAGAS) — mide el pipeline RAG: faithfulness (¿cita el modelo solo lo que tenía en el contexto?), answer relevancy, context precision y recall. La herramienta RAGAS proporciona 8 métricas específicas. Es una capa adicional — se evalúa el retrieval y la generación por separado. Más detalles en Cómo evaluar RAG (RAGAS).
LLM eval en producción (este artículo) — mide la calidad end-to-end para el usuario. No importa si el modelo citó correctamente un documento; importa si la respuesta fue útil, segura y coherente con los criterios de negocio.
EU AI Act y la evaluación como obligación legal
A partir del 2 de agosto de 2026 entra en plena aplicación el EU AI Act. Para las empresas que despliegan sistemas LLM en categorías de alto riesgo (sanidad, infraestructuras críticas, RRHH, educación), la documentación de evaluación se convierte en una obligación legal.
En concreto: para los sistemas de alto riesgo, el AI Act exige una gestión de riesgos documentada y continua que incluya pruebas y validación, seguimiento de tasas de alucinación, patrones de sesgo y riesgo de prompt injection. Las multas por las infracciones más graves pueden alcanzar 35 millones de euros o el 7 % de la facturación global anual.
Implicación práctica: si realiza la evaluación de forma ad hoc en un documento de Notion, no cumple el requisito. Necesita un audit trail — versión del prompt, versión del modelo, fecha de la ejecución del eval, resultados, quién aprobó el deploy. Los requisitos técnicos precisos para el formato de la documentación aún no están estandarizados a nivel de actos de implementación, pero la dirección es clara: sin trazabilidad no hay cumplimiento.
Preguntas frecuentes
¿Qué tamaño debe tener el golden set al empezar?
Para el primer despliegue bastan 100–200 ejemplos de interacciones reales. Más importante que el tamaño es la representatividad — cobertura de las principales categorías de fallo, no solo las consultas "típicas". Con el crecimiento del volumen de producción, el golden set crece de forma orgánica: cada mes se añaden decenas de nuevos casos procedentes de fallos.
¿Puedo usar el mismo modelo como productor y como LLM judge?
No. El self-preference bias está bien documentado — los modelos valoran consistentemente sus propios outputs por encima de las alternativas. Si produce outputs con Claude, evalúelos con un modelo de la clase GPT-4 y viceversa. Para stacks de pesos abiertos: producción en Llama, judge en Qwen o DeepSeek.
¿Cuánto cuesta el LLM-as-judge en producción?
Depende del modelo y del volumen. Como orientación: con 1 000 consultas diarias y un sampling rate del 10 %, se realizan 100 llamadas al judge al día. Con un modelo frontier (entrada 2–5 USD, salida 12–25 USD por millón de tokens), el coste con un prompt de judge corto y típico es del orden de unos pocos dólares al día. Mucho menos que la anotación humana equivalente.
¿Qué hacer cuando el LLM judge no es consistente?
Primer paso: añada ejemplos few-shot al prompt del judge — 3–5 casos bien valorados y 3–5 mal valorados con explicación. La consistencia debería aumentar. Si no mejora, el problema está en la rúbrica: los criterios son demasiado vagos o se solapan entre sí. Reescríbalos con condiciones concretas y medibles. Objetivo: concordancia del judge con revisores humanos por encima del 75 %.
¿Puedo automatizar completamente el eval sin supervisión humana?
Para la mayoría de casos de uso sí, pero con una excepción. Para sistemas de alto riesgo (medicina, derecho, finanzas) debería haber al menos una revisión manual mensual de una muestra de outputs. El LLM judge tiene puntos ciegos — sobre todo para errores factuales sutiles en áreas especializadas donde le falta conocimiento de dominio. La automatización reduce el volumen de trabajo, pero no sustituye la valoración experta en decisiones críticas.
*Si no sabe con certeza dónde falla su aplicación LLM — y la mayoría de los equipos no lo sabe — el primer paso es sencillo: revise los logs y encuentre las cinco peores respuestas del último mes. Ahí empieza todo buen programa de evaluación. Estaremos encantados de ayudarle a configurar el proceso completo — desde el golden set hasta el CI gating y el monitoring en producción.*