Cómo evaluar un modelo de lenguaje: de la métrica a la decisión

A 30 de julio de 2026, una tabla que declara un modelo «mejor» suele esconder la pregunta decisiva: mejor ¿para qué decisión, sobre qué población y a qué coste de error? Perplexity, BLEU o una preferencia humana miden objetos distintos. Ninguna cifra aislada convierte una demostración en evidencia. El método duradero consiste en construir una cadena que una tarea real, datos trazables, baseline, métricas, incertidumbre y umbrales de despliegue.

Empieza por el daño, no por el benchmark

Antes de elegir una métrica, escribe la unidad de trabajo: entrada, salida, usuario y acción posterior. Un resumen para localizar documentos tolera un estilo mediocre si no omite el pasaje clave. Un texto que llega a un paciente tiene otro coste cuando inventa una dosis. Una herramienta de traducción puede requerir fidelidad terminológica en vez de naturalidad general.

Después clasifica errores y asigna severidad. ¿Qué ocurre con una omisión, una cifra cambiada, una negativa invertida, una cita falsa o una abstención innecesaria? Esa matriz determina si interesa exactitud media, cobertura, calibración, tiempo de revisión o tasa de fallos críticos. Un benchmark solo es útil si representa la distribución y las consecuencias de esa decisión.

El dataset es parte del resultado

Una evaluación debe declarar procedencia, licencia, periodo, idioma, criterios de inclusión, deduplicación y proceso de etiquetado. Datasheets for Datasets propuso documentar motivación, composición, recogida, preprocesamiento, usos y mantenimiento precisamente para evitar que el conjunto parezca un objeto neutral.

La partición también importa. Ejemplos del mismo autor, documento o conversación pueden caer a ambos lados del entrenamiento y la prueba, inflando la generalización. En datos temporales, la prueba debe ser posterior al corte de entrenamiento si la pregunta es adaptación al futuro. Y si el modelo pudo ver el benchmark en su preentrenamiento, hay contaminación posible. El paper de GPT-3 ya incluyó análisis de solapamiento con conjuntos de prueba: reconocer el problema no lo elimina, pero silenciarlo vuelve la nota difícil de interpretar.

Perplexity mide predicción, no utilidad

La perplexity es la exponencial de la pérdida logarítmica media: expresa cuánta sorpresa asigna el modelo a la secuencia de prueba. Más baja significa que concentra más probabilidad en los tokens observados. Sirve para comparar variantes bajo datos y tokenización compatibles y para seguir el entrenamiento.

No mide directamente verdad, calidad de instrucciones ni seguridad. Tampoco se compara limpiamente entre tokenizadores distintos: partir una palabra en uno o cuatro tokens cambia la unidad sobre la que se promedia. Hay que declarar corpus, tokenizador, tratamiento de final de secuencia y longitud. Si el objetivo del producto es responder con fuentes, perplexity puede ser diagnóstico interno, no criterio de aceptación.

Las métricas de solapamiento cuentan coincidencias

BLEU se diseñó para traducción y agrega precisión de n-gramas con una penalización por brevedad a nivel de corpus. No aplica una «penalización por copia»: premia coincidencias con referencias y puede dar poca puntuación a una paráfrasis válida. ROUGE desarrolló familias orientadas a resumen, incluyendo solapamiento de n-gramas y subsecuencias. Ambas necesitan versiones y opciones declaradas.

METEOR incorporó alineaciones más flexibles con raíces y sinónimos, además de una penalización por fragmentación. CIDEr nació para descripciones de imágenes y pondera coincidencias según su consenso y especificidad entre referencias. Usarlo como métrica genérica de cualquier texto ignora su diseño.

Estas métricas no certifican factualidad, coherencia lógica ni cobertura de todas las afirmaciones importantes. Dos resúmenes pueden compartir vocabulario y diferir en una cifra. Una salida puede ser fiel con palabras diferentes. Conviene usarlas como una señal reproducible dentro de una batería, nunca como sustituto de inspeccionar el contenido.

Factualidad y citas requieren bajar a la afirmación

Para respuestas con fuentes, la unidad de evaluación es cada afirmación verificable. Se comprueba si está respaldada, si el enlace conduce al original, si el pasaje implica realmente la conclusión y si la atribución es correcta. La cobertura de citas —cuántas afirmaciones importantes tienen apoyo— es distinta de la corrección de citas —cuántos apoyos sostienen lo dicho—.

Un evaluador automático puede ayudar a clasificar grandes muestras, pero necesita un conjunto humano de referencia y auditorías periódicas. Las afirmaciones numéricas admiten comprobaciones específicas: unidad, denominador, periodo, fórmula y redondeo. Un único «score de factualidad» oculta qué falló y dificulta corregir el sistema.

La evaluación humana también es un instrumento

«Preguntamos a personas» no describe un método. Hay que definir quiénes evalúan, qué formación reciben, si ven la identidad del modelo, en qué orden aparecen las respuestas, qué rúbrica usan y cómo se resuelven desacuerdos. La aleatorización y el cegamiento reducen efectos de marca y posición; ejemplos ancla ayudan a interpretar la escala.

El análisis debe separar acuerdo de calidad. Dos anotadores pueden coincidir mucho porque la tarea es obvia o porque comparten una mala regla. Hay que publicar distribución de notas, desacuerdos y comentarios, no solo la media. El estudio Human Evaluation of Generated Text revisó prácticas en generación y documentó problemas de diseño y reporte que impiden comparar resultados.

Un modelo juez necesita su propia evaluación

Los jueces LLM abaratan comparaciones abiertas. Judging LLM-as-a-Judge examinó acuerdos con preferencias humanas y mostró también sesgos de posición, verbosidad y auto-preferencia que deben controlarse. Cambiar el prompt, el orden o la versión del juez puede cambiar el veredicto.

Un protocolo defendible aleatoriza posiciones, repite con orden invertido, conserva prompt y versión, permite empate y calibra el juez contra humanos en la tarea concreta. No debe usar la misma familia como árbitro único cuando existe un conflicto de interés técnico. El juez produce una medición; no se convierte en verdad por responder con seguridad.

Baseline, configuración e incertidumbre

Todo resultado necesita una alternativa pertinente: sistema anterior, búsqueda simple, plantilla, modelo menor o trabajo humano. Comparar solo contra una versión débil magnifica el avance. El presupuesto debe ser común: mismo acceso a documentos, número de ejemplos, herramientas, temperatura, límite de tokens y número de intentos.

Una cifra sin variación puede ser azar. Repetir ejecuciones y usar intervalos de confianza o bootstrap muestra si la diferencia es estable. Para eventos raros y graves, la muestra debe ser suficientemente grande o el informe debe admitir que no puede estimar la tasa. También hay que separar significación estadística de relevancia operativa: una mejora mínima puede no pagar su latencia.

Evaluar más de una propiedad

HELM formalizó una evaluación multidimensional con escenarios y métricas de exactitud, calibración, robustez, equidad, sesgo, toxicidad y eficiencia. La idea transferible es hacer visibles los intercambios. Un modelo puede acertar más y estar peor calibrado, o mejorar en inglés y degradarse en otra lengua.

La equidad tampoco se resuelve con una herramienta única. IBM mantiene AIF360 como biblioteca de métricas y algoritmos, pero el equipo debe definir grupos, resultados deseables y contexto legal y social. Una brecha cuantitativa es una observación; decidir su significado requiere conocer la aplicación y cómo se generaron las etiquetas.

Coste y operación pertenecen a la evaluación

Mide latencia de extremo a extremo, tokens, memoria, energía cuando sea accesible, precio, tasa de reintentos y minutos de revisión humana. Una respuesta ligeramente mejor que tarda diez veces más puede ser inviable. Un modelo barato que eleva las correcciones puede desplazar el coste a profesionales y empeorar el servicio.

Después del despliegue cambian entradas, usuarios y proveedores. Hay que monitorizar distribución, fallos críticos, quejas, abstenciones y coste, conservar muestras y fijar disparadores de retirada. La evaluación previa autoriza una versión bajo unas condiciones; no concede un certificado permanente.

La ficha mínima para creer una tabla

Exige diez campos: tarea y usuario; daño por tipo de error; dataset y procedencia; partición y contaminación; baseline; configuración; métricas y por qué corresponden; incertidumbre; coste; y umbral de decisión. Añade quién revisó y qué cambió tras los fallos.

Con esa ficha, BLEU, ROUGE o un juez automático recuperan su lugar correcto: instrumentos parciales dentro de una prueba orientada a una decisión. La pregunta ya no es «¿qué modelo ganó?», sino «¿qué evidencia demuestra que esta versión mejora esta tarea, para estas personas, dentro de este presupuesto y con estos fallos conocidos?».