Cómo evaluar un LLM sin autoengaño: métricas, datasets, contaminación y pruebas “de negocio”

GUÍAS & TUTORIALES · LLMS · EVALUACIÓN PRÁCTICA

Vamos a montar un marco de evaluación que puedas usar hoy mismo: métricas útiles, control de contaminación, un Golden Set que no te traicione, evaluación humana sin drama y, por último, pruebas “de negocio” para decidir con criterio (y no por hype).

1. Por qué los benchmarks te engañan (aunque nadie “mienta”)

Un benchmark público es como un circuito de Fórmula 1: sirve para comparar coches… en ese circuito. Pero tú igual necesitas un todoterreno, un taxi o una furgoneta de reparto. El problema no es que el benchmark esté “mal”, sino que mide una realidad distinta a la tuya.

Y encima hay otros dos efectos que deforman la foto:

1) Goodhart en estado puro. Cuando una métrica se vuelve objetivo, deja de ser buena métrica. Si todo el mundo compite por el mismo leaderboard, el ecosistema empieza a optimizar para esa tabla (prompts, formatos, “harness”, hiperparámetros, filtrados, post-procesado).

2) Inestabilidad de la evaluación. Cambias el prompt del evaluador, el formato de salida, el “judge”, el parser… y el ranking se mueve. Si te interesa este fenómeno (y por qué los rankings a veces parecen una montaña rusa), te va a venir bien esta guía sobre cómo comparar modelos en LMArena sin equivocarte.

2. Antes de medir: define qué significa “mejor” en tu caso

“Mejor modelo” es una frase peligrosa si no la aterrizas. Para no liarte, trabaja con estas cuatro capas:

3. Contaminación: el enemigo silencioso de los resultados bonitos

La contaminación (o leakage) es cuando el modelo ha visto —total o parcialmente— los datos de evaluación durante entrenamiento, ajuste o por exposición indirecta en internet. ¿Consecuencia? El modelo no “razona”: recuerda. Y tú te crees que has encontrado al campeón.

La contaminación no siempre es malicia. A veces pasa por:

Publicación de sets de evaluación en repositorios y foros, datasets reutilizados y remezclados, “fine-tuning” con ejemplos demasiado parecidos, o incluso porque tu propio equipo copió casos reales de soporte en un documento que terminó indexado en algún sitio.

¿Cómo reduces el riesgo sin volverte paranoico?

• Haz privado tu Golden Set (y evita que circule por chats, tickets exportados o wikis abiertas).
• Rotación: ten un set “core” estable y un set “rotativo” que cambias cada 2–4 semanas.
• Time-split: si puedes, separa ejemplos por fecha (eval con datos posteriores al entrenamiento conocido).
• Pruebas de “memoria”: incluye algunos ítems trampa (redactados por ti) que no deberían existir en ningún sitio.

Y ojo: contaminación no es el único autoengaño posible. Si quieres una lista rápida de fallos típicos (alucinaciones, privacidad, sesgos en pruebas), aquí tienes una guía muy alineada con este tema: errores típicos al usar IA: alucinaciones y privacidad.

4. Un marco de evaluación en 4 capas (para equipos normales)

Si intentas hacerlo todo perfecto, no empiezas. Si lo haces demasiado simple, te engañas. Este es el equilibrio que mejor suele funcionar:

Lo importante: no te cases con una sola métrica. Necesitas un “panel” pequeño con prioridades claras. Ahora te enseño cómo montarlo.

5. Cómo construir tu Golden Set (sin convertirlo en un proyecto infinito)

Un Golden Set no es “un dataset enorme”. Es un conjunto pequeño y representativo que te permite comparar modelos con señales fiables. Para la mayoría de equipos, 50–200 ejemplos bien elegidos valen más que 10.000 aleatorios.

Paso a paso (el que de verdad se hace)

1) Define 3–7 jobs-to-be-done. No “chat general”, sino cosas concretas: “resumir contrato en 5 bullets”, “proponer respuesta a reclamación”, “extraer campos del email”, “clasificar intención y prioridad”.

2) Captura ejemplos reales. Los de verdad: con ruido, faltas, contexto incompleto, usuarios pesados, requisitos contradictorios.

3) Define una rubrica simple. 3–5 criterios máximo. Si necesitas 15, nadie lo aplicará de forma consistente.

4) Versiona. Fecha, versión, notas de cambios. Y no mezcles sets al comparar modelos.

5) Separa “core” y “rotativo”. El core te sirve para ver regresiones; el rotativo evita que tu producto se adapte a un examen fijo.

6. Métricas útiles: el panel mínimo que evita discusiones eternas

Aquí tienes un panel mínimo que funciona en la mayoría de productos con LLM. No uses todas si no aplica, pero evita quedarte solo con “accuracy” o “preferencia”.

Métricas de calidad

• Tasa de éxito por tarea: ¿resuelve lo que debe resolver?
• Cumplimiento (policy & instrucciones): ¿respeta reglas, tono, límites?
• Alucinación / invención: ¿se inventa datos? (define qué cuenta como “inventar”).
• Adherencia de formato: JSON válido, campos obligatorios, estructura, citación si la pides.

Métricas operativas

• Latencia p50 y p95: la media no te salva si el 5% tarda 20 segundos.
• Coste por conversación y por tarea resuelta: tokens, llamadas a herramientas, RAG, reintentos.
• Estabilidad: variación entre ejecuciones (con la misma entrada) y sensibilidad a prompts.

Cómo medir tareas abiertas (sin mentirte)

Para redacción, soporte o “razonamiento aplicado”, el truco que mejor evita autoengaño es la comparación pareada: enseñas dos respuestas (A y B) a un evaluador y le pides elegir según rubrica. Es más estable que puntuar del 1 al 10 y reduce sesgos de escala.

7. Evaluación humana sin dolor (ni guerras internas)

La evaluación humana es inevitable cuando el output es “lenguaje”. La pregunta es: ¿cómo la haces de forma que no sea teatro?

Si tienes que elegir solo una cosa: pareado + rubrica + ciego. Con eso ya evitas buena parte del “me parece que…”.

8. Pruebas “de negocio”: la evaluación que decide (aunque a veces no te guste)

Aquí viene el punto incómodo: puedes tener un modelo que “gusta más” a los evaluadores, pero que no mejora el negocio. O peor: lo empeora (por coste, latencia, errores silenciosos, tickets reabiertos).

Las pruebas de negocio responden a: ¿esto mueve una métrica real? Algunas típicas:

Deflexión en soporte (menos tickets humanos), tiempo medio de resolución, tasa de escalado, conversión, retención, satisfacción, ahorro de tiempo interno, calidad percibida, cumplimiento.

Si estás montando el reporting de un proyecto de IA y quieres aterrizar estas métricas de forma presentable, enlaza perfecto con esta guía de KPIs para proyectos de IA: medir resultados de verdad.

9. Coste, latencia y arquitectura: el “mejor” no siempre cabe

Evaluar sin autoengaño también significa medir lo que duele: dinero y tiempos. Dos modelos pueden empatar en calidad, pero uno puede ser inviable por latencia o coste.

Tres trucos prácticos:

• Mide con prompts reales (mismo contexto, mismas herramientas, mismo RAG).
• Reporta p95 y no solo promedio.
• Calcula € / tarea resuelta (incluye reintentos y escalados).

Y si estás decidiendo entre ejecutar en nube, local, o híbrido (por latencia, privacidad o coste), esta guía te ayuda a ordenar el razonamiento: modelo en nube vs local: guía de arquitectura.

10. Plantilla lista para copiar: Golden Set + panel de decisión

Te dejo una plantilla simple para empezar hoy. La idea es que, con esto, puedas comparar 2–4 modelos en una tarde sin convertirlo en un comité eterno.

11. Checklist final: cómo comparar 2–4 modelos sin autoengaño

Si quieres un resumen en modo “hazlo y ya”, aquí va:

Si te quedas con una idea: no estás eligiendo “un modelo”, estás eligiendo un sistema (modelo + prompt + datos + herramientas + guardrails). Evalúa eso, no el logo del proveedor, y vas a tomar decisiones mucho más sólidas.