¿Qué es la evaluación de LLMs y por qué los benchmarks públicos no te sirven?
Cómo medir de verdad si un LLM responde bien a tu caso de uso. Métricas, benchmarks, modelo juez, evaluación humana y construcción de evals propios para producción.
Actualizado mayo 2026
Evaluación LLM: medir sistemáticamente la calidad de respuestas de un modelo en una tarea concreta.
La evaluación de LLMs (también llamada "evals") es la disciplina de medir de forma sistemática y reproducible la calidad de las respuestas de un LLM en una tarea concreta. Es la pieza que permite responder con datos a preguntas como "¿mi asistente responde mejor con Claude o GPT?", "¿este prompt nuevo es mejor?", "¿el sistema ha empeorado?".
A diferencia del software clásico (tests unitarios deterministas), evaluar LLMs es difícil porque las salidas son texto libre con múltiples respuestas válidas. Una pregunta puede tener 15 respuestas correctas con redacción distinta. Por eso se usan métricas estadísticas, modelos juez y validación humana en lugar de comparación exacta.
Hay tres tipos de evaluación complementarios: (1) evaluación con métricas automáticas tradicionales (BLEU, ROUGE, exact match) — rápida pero limitada, (2) evaluación con modelo juez (otro LLM evalúa con criterios) — escalable, (3) evaluación humana — gold standard pero cara. Sistemas en producción combinan los tres: automáticas para iterar rápido, modelo juez para escala, humana para validar el juez.
En una pyme española en 2026, los benchmarks públicos (MMLU, HELM, GPQA) son casi inútiles: miden capacidades genéricas, no tu caso. Lo que necesitas son evals propias: 100-500 ejemplos input/expected_output o criterios de éxito, etiquetados según tu negocio. Esa es la verdad de referencia que te permite decidir si un cambio mejora o empeora.
Seis métricas de evaluación LLM que usamos en producción
Lo que se mide en sistemas reales, no en papers académicos.
Accuracy / Exact match
Para tareas con respuesta determinable (clasificación, extracción estructurada): % de respuestas correctas. Simple, automática, fiable. Útil cuando la respuesta esperada es un valor o conjunto pequeño.
Hallucination rate
En sistemas RAG y QA: % de respuestas con información inventada o no presente en el contexto. Crítica para sistemas empresariales. Se mide con modelo juez verificando contra fuentes citadas.
BLEU / ROUGE
Métricas clásicas para tareas de generación con referencia (traducción, resumen). Comparan n-gramas con respuesta de referencia. Limitadas (no entienden semántica), pero útiles como señal complementaria.
Modelo juez (LLM-as-judge)
Otro LLM evalúa según rubrica: relevancia, factualidad, tono, completitud. Escala donde humano no llega. Hay que validarlo con muestra humana para confirmar que sus criterios coinciden con los reales.
Format compliance
En tareas con salida estructurada (JSON, tabla): % de respuestas con formato válido y parseable. Crítica si el output alimenta otro sistema. Validable con parsers automáticos sin coste.
Satisfacción humana / NPS
Feedback explícito de usuarios (thumbs up/down, rating 1-5). Conectado a métrica de negocio (conversión, retención). Es la verdad última: si los usuarios están contentos, el resto de métricas son intermediarias.
Proceso para crear un dataset de evaluación robusto
Cinco fases. 30-80 horas de trabajo en pyme estándar. Activo de larga vida.
Identificar casos representativos
Si ya hay producción: muestreo aleatorio de 500-1.000 interacciones reales. Si no hay producción: brainstorm con stakeholders, casos límite y casos típicos. Cubrir distribución real de uso.
Etiquetar la respuesta esperada o criterios
Para cada caso: respuesta ideal (si determinable) o rubrica de criterios (si abierto). Etiquetado por humano experto del dominio (legal, médico, ventas). 5-15 minutos por caso bien hecho.
Dividir en categorías
Etiquetar cada caso con tags: tipo de pregunta (factual, opinión, multi-paso), dificultad, dominio, casos límite. Permite análisis granular: "el sistema falla en preguntas multi-paso pero acierta en factuales".
Versionar y bloquear
Dataset en git con versión, congelado para iteraciones. Cambios al dataset son cambios mayores documentados. Si añades casos nuevos, mantienes los anteriores: comparación temporal posible.
Mantener vivo
Casos problemáticos detectados en producción se añaden al dataset (con etiquetado adecuado). Revisión trimestral para asegurar que el dataset sigue siendo representativo del uso real.
Cinco errores típicos al evaluar LLMs
Confiar en benchmarks públicos para decidir
MMLU, HELM, ArenaHard miden capacidades genéricas. Que Claude 4.5 supere a GPT-4o en MMLU no significa que rinda mejor en TU sistema. Tu eval propio es el único válido para tu decisión.
Dataset demasiado pequeño
Evaluar con 10 casos da margen de error enorme. Cambios <5% son ruido. Mínimo viable: 100 casos para señal razonable, 300-500 para conclusiones sólidas, 1.000+ para casos críticos.
Solo evaluar lo fácil
Tendencia a coger casos donde el sistema funciona bien. Resultado: métricas infladas. El dataset debe incluir <strong>casos límite, ambiguos, adversariales</strong>, lo difícil. Donde fallas es donde mejoras.
No validar el modelo juez
Asumir que GPT-4 juez es fiable sin contrastar con humanos. Riesgo: el juez tiene sesgos sistemáticos (prefiere respuestas largas, su propio estilo). Validar con muestra humana 50-100 casos antes de fiarse.
No medir métricas de negocio
Evals técnicos al 95% pero usuarios no usan el sistema. Hay desconexión entre lo que mides y lo que importa. Métrica técnica debe correlacionarse con métrica de negocio (conversión, retención, satisfacción).
Evaluación LLM en el mapa de IA empresarial.
La evaluación es pieza central de LLMOps: sin evals reproducibles, no hay forma de saber si un cambio mejora o empeora. Es la diferencia entre "parece que va mejor" e "incremento del 12% en accuracy con p<0.01". Sin evals, las decisiones son intuición; con evals, son datos.
Se usa para comparar modelos (¿Claude vs GPT vs Llama?), para validar cambios de prompt (¿la nueva versión es mejor?) y para detectar regresiones en producción (¿el modelo ha empeorado?). También para decidir entre fine-tuning y RAG: sin medición sistemática es imposible saber qué técnica funciona mejor en tu caso.
En sistemas RAG hay evals específicos: retrieval evaluation (¿el sistema recupera los chunks correctos?), faithfulness (¿la respuesta se basa en los chunks?), relevance (¿responde a la pregunta?). Frameworks como Ragas, TruLens cubren estos casos específicos.
Para pymes españolas que quieran tener sus asistentes IA en producción con evals reales, Magnetia construye datasets y pipelines de evaluación como parte de automatización de procesos con IA. Cofinanciable por Kit Consulting.
Dudas que nos hacéis llegar
¿Mides la calidad real de tu LLM o navegas a ciegas?
Diseñamos dataset de evaluación a medida, configuramos pipeline de evals automáticos con modelo juez y validación humana de muestra. Entregamos infraestructura LLMOps básica.