Phase 10 - Lesson 10

Evaluación: Benchmarks, Evals, LM Harness

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

Ley de Goodhart: cuando una medida se convierte en un objetivo, deja de ser una buena medida. Todos los laboratorios de frontera manipulan los benchmarks. Las puntuaciones de MMLU suben mientras los modelos todavía no pueden contar con fiabilidad el número de letras "r" en "strawberry". La única evaluación que importa es TU evaluación -- en TU tarea, con TUS datos.

Tipo: Construcción Idiomas: Python Prerrequisitos: Fase 10, Lecciones 01-05 (LLMs desde Cero) Tiempo: ~90 minutos

Objetivos de Aprendizaje

  • Construir un arnés de evaluación personalizado que ejecute benchmarks de opción múltiple y respuesta abierta contra un modelo de lenguaje
  • Explicar por que los benchmarks estándar (MMLU, HumanEval) se saturan y no logran diferenciar a los modelos de frontera
  • Implementar evaluaciones específicas de tareas con métricas adecuadas: coincidencia exacta (exact match), F1, BLEU y puntuación basada en LLM como juez (LLM-as-judge)
  • Diseñar una suite de evaluación personalizada orientada a tu caso de uso específico en lugar de depender únicamente de las tablas de clasificación (leaderboards) públicas

El Problema

MMLU se publicó en 2020 con 15,908 preguntas en 57 materias. En tres años, los modelos de frontera lo saturaron. GPT-4 obtuvo un 86.4%. Claude 3 Opus obtuvo un 86.8%. Llama 3 405B obtuvo un 88.6%. La tabla de clasificación se comprimió en un rango de 3 puntos donde las diferencias son ruido estadístico, no diferencias reales de capacidad.

Mientras tanto, esos mismos modelos fallan en tareas que un niño de 10 años resuelve sin pensar. Claude 3.5 Sonnet, que obtiene un 88.7% en MMLU, inicialmente no podía contar las letras en "strawberry" -- una tarea que requiere cero conocimiento del mundo y cero razonamiento, solo iteración a nivel de caracteres. HumanEval evalúa la generación de código con 164 problemas. Los modelos obtienen más del 90% en esta prueba mientras siguen produciendo código que falla en casos extremos (edge cases) que cualquier desarrollor junior detectaría.

La brecha entre el rendimiento en benchmarks y la confiabilidad en el mundo real es el problema central de la evaluación de LLMs. Los benchmarks te dicen cómo funciona un modelo en ese benchmark en específico. No te dicen casi nada sobre cómo funcionará ese modelo en tu tarea específica, con tus datos específicos, bajo tus modos de falla específicos. Si estás construyendo un bot de soporte al cliente, MMLU es irrelevante. Si estás construyendo un asistente de código, HumanEval solo cubre la generación a nivel de función -- no dice nada sobre depuración, refactorización o explicación de código a través de múltiples archivos.

Necesitas evaluaciones personalizadas. No porque los benchmarks sean inútiles -- son útiles para una selección preliminar de modelos -- sino porque la evaluación final debe coincidir exactamente con tus condiciones de implementación.

El Concepto

El Panorama de la Evaluación

Existen tres categorías de evaluación, cada una con diferentes costos y calidad de señal.

Benchmarks son suites de pruebas estandarizadas. MMLU, HumanEval, SWE-bench, MATH, ARC, HellaSwag. Ejecutas un modelo contra el benchmark y obtienes una puntuación. La ventaja: todos usan la misma prueba, por lo que puedes comparar modelos. La desventaja: los modelos y los datos de entrenamiento contaminan cada vez más estos benchmarks. Los laboratorios entrenan con datos que incluyen preguntas de los benchmarks. Las puntuaciones suben. La capacidad real podría no hacerlo.

Evaluaciones personalizadas (custom evals) son suites de pruebas que construyes para tu caso de uso específico. Defines las entradas, las salidas esperadas y la función de puntuación. Un resumidor de documentos legales se evalúa con documentos legales. Un generador de SQL se evalúa con el esquema de tu base de datos. Crear estas suites es costoso, pero son la única evaluación que predice el rendimiento en producción.

Evaluaciones humanas utilizan anotadores pagados para juzgar las salidas de los modelos según criterios como utilidad, corrección, fluidez y seguridad. El estándar de oro para tareas abiertas donde la puntuación automatizada falla. Chatbot Arena ha recopilado más de 2 millones de votos de preferencia humana para más de 100 modelos. La desventaja: costo (entre $0.10 y

.00 por juicio) y velocidad (de horas a días).

graph TD
    subgraph Eval["Panorama de Evaluación"]
        direction LR
        B["Benchmarks\n(MMLU, HumanEval)\nBarato, estandarizado\nManipulable, obsoleto"]
        C["Evals Personalizadas\nTu tarea, tus datos\nSeñal más alta\nCaro de construir"]
        H["Evaluaciones Humanas\n(Chatbot Arena)\nEstándar de oro\nLento, costoso"]
    end

    B -->|"selección preliminar de modelos"| C
    C -->|"casos ambiguos"| H

    style B fill:#1a1a2e,stroke:#ffa500,color:#fff
    style C fill:#1a1a2e,stroke:#51cf66,color:#fff
    style H fill:#1a1a2e,stroke:#e94560,color:#fff

Por Qué se Rompen los Benchmarks

Tres mecanismos hacen que las puntuaciones de los benchmarks dejen de reflejar la capacidad real.

Contaminación de datos. Los corpora de entrenamiento extraen información de internet. Las preguntas de los benchmarks viven en internet. Los modelos ven las respuestas durante el entrenamiento. Esto no es hacer trampa en el sentido tradicional -- los laboratorios no incluyen intencionalmente datos de los benchmarks -- pero la extracción a escala web hace que sea casi imposible excluirlos.

Enseñar para el examen (teaching to the test). Los laboratorios optimizan las mezclas de entrenamiento para el rendimiento en benchmarks. Si el 5% de la mezcla de entrenamiento es de opción múltiple al estilo MMLU, el modelo aprende el formato y la distribución de las respuestas. MMLU es una prueba de opción múltiple de 4 opciones. Los modelos aprenden que la distribución de respuestas es aproximadamente uniforme entre A/B/C/D, lo que ayuda incluso cuando el modelo no conoce la respuesta.

Saturación. Cuando cada modelo de frontera obtiene entre el 85% y el 90% en un benchmark, este deja de discriminar. El 10-15% restante de las preguntas puede ser ambiguo, estar mal etiquetado o requerir un conocimiento de dominio muy oscuro. Mejorar de un 87% a un 89% en MMLU puede significar que el modelo memorizó dos preguntas oscuras más, no que se volvió más inteligente.

Perplejidad: Un Control Rápido de Integridad (Health Check)

La perplejidad mide qué tan sorprendido está un modelo ante una secuencia de tokens. Formalmente, es el exponente del promedio negativo de la probabilidad logarítmica:

PPL = exp(-1/N * sum(log P(token_i | context)))

Una perplejidad de 10 significa que el modelo está, en promedio, tan inseguro como elegir uniformemente entre 10 opciones en cada posición de token. Menor es mejor. GPT-2 obtiene una perplejidad de ~30 en WikiText-103. GPT-3 obtiene ~20. Llama 3 8B obtiene ~7.

La perplejidad es útil para comparar modelos en el mismo conjunto de pruebas, pero tiene puntos ciegos. Un modelo puede tener una perplejidad baja al ser bueno prediciendo patrones comunes y, al mismo tiempo, ser terrible con patrones raros pero importantes. Tampoco dice nada sobre el seguimiento de instrucciones, el razonamiento o la precisión objetiva. Úsala como una verificación de integridad, no como un veredicto final.

LLM como Juez (LLM-as-Judge)

Utiliza un modelo fuerte para evaluar la salida de un modelo más débil. La idea es simple: pídele a GPT-4o o Claude Sonnet que califique una respuesta en una escala del 1 al 5 en cuanto a corrección, utilidad y seguridad. Esto cuesta aproximadamente $0.01 por juicio con GPT-4o-mini y se correlaciona sorprendentemente bien con los juicios humanos (alrededor del 80% de acuerdo en la mayoría de las tareas).

El prompt de evaluación importa más que el modelo. Un prompt vago ("Califica esta respuesta") produce puntuaciones con mucho ruido. Un prompt estructurado con una rúbrica ("Califica con 5 si la respuesta es tácticamente correcta y cita una fuente, 4 si es correcta pero no tiene fuentes, 3 si es parcialmente correcta...") produce puntuaciones consistentes y reproducibles.

Modos de falla: los modelos juez exhiben sesgo de posición (prefieren la primera respuesta en comparaciones pareadas), sesgo de verbosidad (prefieren respuestas más largas) y autoproferencia (GPT-4 califica las salidas de GPT-4 más alto que las salidas equivalentes de Claude). Mitigaciones: aleatorizar el orden, normalizar por longitud, utilizar un juez diferente al modelo que se está evaluando.

Clasificaciones ELO a Partir de Comparaciones Pareadas

El enfoque de Chatbot Arena. Muestra dos respuestas a la misma instrucción de diferentes modelos. Un humano (or un juez LLM) elige la mejor. A partir de miles de estas comparaciones, calcula una clasificación ELO para cada modelo, el mismo sistema utilizado en el ajedrez.

Ventajas de ELO: la clasificación relativa es más confiable que la puntuación absoluta, maneja los empates con elegancia y converge con menos comparaciones que calificar cada salida de forma independiente. A principios de 2026, las clasificaciones de Chatbot Arena muestran a GPT-4o, Claude 3.5 Sonnet y Gemini 1.5 Pro a menos de 20 puntos ELO de diferencia en la cima.

graph LR
    subgraph ELO["Pipeline de Clasificación ELO"]
        direction TB
        P["Prompt"] --> MA["Salida del Modelo A"]
        P --> MB["Salida del Modelo B"]
        MA --> J["Juez\n(Humano o LLM)"]
        MB --> J
        J --> W["Gana A / Gana B / Empate"]
        W --> E["Actualización de ELO\nK=32"]
    end

    style P fill:#1a1a2e,stroke:#0f3460,color:#fff
    style J fill:#1a1a2e,stroke:#e94560,color:#fff
    style E fill:#1a1a2e,stroke:#51cf66,color:#fff

Frameworks de Evaluación

lm-evaluation-harness (EleutherAI): el framework estándar de evaluación de código abierto. Soporta más de 200 benchmarks. Ejecuta cualquier modelo de Hugging Face contra MMLU, HellaSwag, ARC, etc., con un solo comando. Utilizado por la Open LLM Leaderboard.

RAGAS: framework de evaluación diseñado específicamente para pipelines RAG. Mide la fidelidad (¿coincide la respuesta con el contexto recuperado?), la relevancia (¿es relevante el contexto recuperado para la pregunta?) y la corrección de la respuesta.

promptfoo: evaluación basada en configuración para ingeniería de prompts. Define casos de prueba en YAML, ejecútalos contra múltiples modelos y obtén un informe de aprobación/reprobración. Útil para pruebas de regresión de prompts; asegúrate de que un cambio en un prompt no rompa los casos de prueba existentes.

Construcción de Evaluaciones Personalizadas

La única evaluación que importa para producción. El proceso:

  1. Define la tarea. ¿Qué debe hacer exactamente el modelo? Sé preciso. "Responder preguntas" es demasiado vago. "Dada una queja de correo electrónico de un cliente, extraer el nombre del producto, la categoría del problema y el sentimiento" es una tarea que puedes evaluar.

  2. Crea casos de prueba. Mínimo 50 para una evaluación de prototipo, más de 200 para producción. Cada caso de prueba es un par (entrada, salida_esperada). Incluye casos extremos: entradas vacías, entradas de adversario, entradas ambiguas, entradas en otros idiomas.

  3. Define la puntuación. Coincidencia exacta (exact match) para salidas estructuradas. BLEU/ROUGE para similitud de texto. LLM como juez para calidad abierta. F1 para tareas de extracción. Combina múltiples métricas con pesos.

  4. Automatiza. Cada evaluación se ejecuta con un solo comando. Sin pasos manuales. Almacena los resultados en un formato que permita la comparación a lo largo del tiempo.

  5. Haz un seguimiento a lo largo del tiempo. Una puntuación de evaluación no tiene sentido de forma aislada. Necesitas la línea de tendencia. ¿Mejoró la puntuación después del último cambio de prompt? ¿Regresó después de cambiar de modelo? Lleva un control de versiones de tu evaluación junto con tus prompts.

Tipo de evaluación Costo por juicio Acuerdo con humanos Ideal para
Coincidencia exacta ~$0 100% (cuando aplica) Salida estructurada, clasificación
BLEU/ROUGE ~$0 ~60% Traducción, resumen
LLM como juez ~$0.01 ~80% Generación abierta
Evaluación humana $0.10- .00 N/A (es la verdad fundamental) Tareas ambiguas de alto impacto

Construcción

Paso 1: Un Framework Mínimo de Evaluación

Define las abstracciones principales. Un caso de evaluación tiene una entrada, una salida esperada y un diccionario de metadados opcional. Un evaluador (scorer) toma una predicción y una referencia y devuelve una puntuación entre 0 y 1.

import json
from collections import Counter

class EvalCase:
    def __init__(self, input_text, expected, metadata=None):
        self.input_text = input_text
        self.expected = expected
        self.metadata = metadata or {}

class EvalSuite:
    def __init__(self, name, cases, scorers):
        self.name = name
        self.cases = cases
        self.scorers = scorers

    def run(self, model_fn):
        results = []
        for case in self.cases:
            prediction = model_fn(case.input_text)
            scores = {}
            for scorer_name, scorer_fn in self.scorers.items():
                scores[scorer_name] = scorer_fn(prediction, case.expected)
            results.append({
                "input": case.input_text,
                "expected": case.expected,
                "prediction": prediction,
                "scores": scores,
            })
        return results

Paso 2: Funciones de Puntuación

Construye coincidencia exacta, token F1 y un evaluador simulado de LLM como juez.

def exact_match(prediction, expected):
    return 1.0 if prediction.strip().lower() == expected.strip().lower() else 0.0

def token_f1(prediction, expected):
    pred_tokens = set(prediction.lower().split())
    exp_tokens = set(expected.lower().split())
    if not pred_tokens or not exp_tokens:
        return 0.0
    common = pred_tokens & exp_tokens
    precision = len(common) / len(pred_tokens)
    recall = len(common) / len(exp_tokens)
    if precision + recall == 0:
        return 0.0
    return 2 * (precision * recall) / (precision + recall)

def llm_judge_simulated(prediction, expected):
    pred_words = set(prediction.lower().split())
    exp_words = set(expected.lower().split())
    if not exp_words:
        return 0.0
    overlap = len(pred_words & exp_words) / len(exp_words)
    length_penalty = min(1.0, len(prediction) / max(len(expected), 1))
    return round(overlap * 0.7 + length_penalty * 0.3, 3)

Paso 3: Sistema de Calificación ELO

Implementa comparaciones pareadas con actualizaciones de ELO. Este es exactamente el sistema que Chatbot Arena utiliza para clasificar modelos.

class ELOTracker:
    def __init__(self, k=32, initial_rating=1500):
        self.ratings = {}
        self.k = k
        self.initial_rating = initial_rating
        self.history = []

    def _ensure_player(self, name):
        if name not in self.ratings:
            self.ratings[name] = self.initial_rating

    def expected_score(self, rating_a, rating_b):
        return 1 / (1 + 10 ** ((rating_b - rating_a) / 400))

    def record_match(self, player_a, player_b, outcome):
        self._ensure_player(player_a)
        self._ensure_player(player_b)

        ea = self.expected_score(self.ratings[player_a], self.ratings[player_b])
        eb = 1 - ea

        if outcome == "a":
            sa, sb = 1.0, 0.0
        elif outcome == "b":
            sa, sb = 0.0, 1.0
        else:
            sa, sb = 0.5, 0.5

        self.ratings[player_a] += self.k * (sa - ea)
        self.ratings[player_b] += self.k * (sb - eb)

        self.history.append({
            "a": player_a, "b": player_b,
            "outcome": outcome,
            "rating_a": round(self.ratings[player_a], 1),
            "rating_b": round(self.ratings[player_b], 1),
        })

    def leaderboard(self):
        return sorted(self.ratings.items(), key=lambda x: -x[1])

Paso 4: Cálculo de Perplejidad

Calcula la perplejidad utilizando probabilidades de tokens. En la práctica, obtendrías estas probabilidades de los logits del modelo. Aquí simulamos con una distribución de probabilidad.

import numpy as np

def perplexity(log_probs):
    if not log_probs:
        return float("inf")
    avg_neg_log_prob = -np.mean(log_probs)
    return float(np.exp(avg_neg_log_prob))

def token_log_probs_simulated(text, model_quality=0.8):
    np.random.seed(hash(text) % 2**31)
    tokens = text.split()
    log_probs = []
    for i, token in enumerate(tokens):
        base_prob = model_quality
        if len(token) > 8:
            base_prob *= 0.6
        if i == 0:
            base_prob *= 0.7
        prob = np.clip(base_prob + np.random.normal(0, 0.1), 0.01, 0.99)
        log_probs.append(float(np.log(prob)))
    return log_probs

Paso 5: Agregar Resultados

Calcula estadísticas de resumen a través de una ejecución de evaluación: media, mediana, tasa de aprobación en un umbral y desgloses por métrica.

def summarize_results(results, threshold=0.8):
    all_scores = {}
    for r in results:
        for metric, score in r["scores"].items():
            all_scores.setdefault(metric, []).append(score)

    summary = {}
    for metric, scores in all_scores.items():
        arr = np.array(scores)
        summary[metric] = {
            "mean": round(float(np.mean(arr)), 3),
            "median": round(float(np.median(arr)), 3),
            "std": round(float(np.std(arr)), 3),
            "min": round(float(np.min(arr)), 3),
            "max": round(float(np.max(arr)), 3),
            "pass_rate": round(float(np.mean(arr >= threshold)), 3),
            "n": len(scores),
        }
    return summary

def print_summary(summary, suite_name="Eval"):
    print(f"\n{'=' * 60}")
    print(f"  {suite_name} Summary")
    print(f"{'=' * 60}")
    for metric, stats in summary.items():
        print(f"\n  {metric}:")
        print(f"    Mean:      {stats['mean']:.3f}")
        print(f"    Median:    {stats['median']:.3f}")
        print(f"    Std:       {stats['std']:.3f}")
        print(f"    Range:     [{stats['min']:.3f}, {stats['max']:.3f}]")
        print(f"    Pass rate: {stats['pass_rate']:.1%} (threshold >= 0.8)")
        print(f"    N:         {stats['n']}")

Paso 6: Ejecutar el Pipeline Completo

Conecta todo. Define una tarea, crea casos de prueba, simula dos modelos, ejecuta evaluaciones, calcula ELO a partir de comparaciones pareadas e imprime la tabla de clasificación.

def demo_model_good(prompt):
    responses = {
        "What is the capital of France?": "Paris",
        "What is 2 + 2?": "4",
        "Who wrote Hamlet?": "William Shakespeare",
        "What language is PyTorch written in?": "Python and C++",
        "What is the boiling point of water?": "100 degrees Celsius",
    }
    return responses.get(prompt, "I don't know")

def demo_model_bad(prompt):
    responses = {
        "What is the capital of France?": "Paris is the capital city of France",
        "What is 2 + 2?": "The answer is four",
        "Who wrote Hamlet?": "Shakespeare",
        "What language is PyTorch written in?": "Python",
        "What is the boiling point of water?": "212 Fahrenheit",
    }
    return responses.get(prompt, "Unknown")

cases = [
    EvalCase("What is the capital of France?", "Paris"),
    EvalCase("What is 2 + 2?", "4"),
    EvalCase("Who wrote Hamlet?", "William Shakespeare"),
    EvalCase("What language is PyTorch written in?", "Python and C++"),
    EvalCase("What is the boiling point of water?", "100 degrees Celsius"),
]

suite = EvalSuite(
    name="General Knowledge",
    cases=cases,
    scorers={
        "exact_match": exact_match,
        "token_f1": token_f1,
        "llm_judge": llm_judge_simulated,
    },
)

results_good = suite.run(demo_model_good)
results_bad = suite.run(demo_model_bad)

print_summary(summarize_results(results_good), "Model A (concise)")
print_summary(summarize_results(results_bad), "Model B (verbose)")

El modelo "bueno" da respuestas exactas. El modelo "malo" da paráfrasis prolijas. La coincidencia exacta penaliza severamente al modelo prolijo. F1 de tokens y LLM como juez son más tolerantes. Esto ilustra por qué la elección de la métrica importa: el mismo modelo se ve excelente o terrible dependiendo de cómo se califique.

Paso 7: Torneo ELO

Ejecuta comparaciones pareadas entre modelos a lo largo de múltiples rondas.

elo = ELOTracker(k=32)

for case in cases:
    pred_a = demo_model_good(case.input_text)
    pred_b = demo_model_bad(case.input_text)

    score_a = token_f1(pred_a, case.expected)
    score_b = token_f1(pred_b, case.expected)

    if score_a > score_b:
        outcome = "a"
    elif score_b > score_a:
        outcome = "b"
    else:
        outcome = "tie"

    elo.record_match("model_a_concise", "model_b_verbose", outcome)

print("\nELO Leaderboard:")
for name, rating in elo.leaderboard():
    print(f"  {name}: {rating:.0f}")

Paso 8: Comparación de Perplexidad

Compara la perplejidad entre "modelos" de diferentes niveles de calidad.

test_text = "The quick brown fox jumps over the lazy dog in the garden"

for quality, label in [(0.9, "Strong model"), (0.7, "Medium model"), (0.4, "Weak model")]:
    log_probs = token_log_probs_simulated(test_text, model_quality=quality)
    ppl = perplexity(log_probs)
    print(f"  {label} (quality={quality}): perplexity = {ppl:.2f}")

Uso

lm-evaluation-harness (EleutherAI)

La herramienta estándar para ejecutar benchmarks en cualquier modelo.

# pip install lm-eval
# Command line:
# lm_eval --model hf --model_args pretrained=meta-llama/Llama-3.1-8B --tasks mmlu --batch_size 8

# Python API:
# import lm_eval
# results = lm_eval.simple_evaluate(
#     model="hf",
#     model_args="pretrained=meta-llama/Llama-3.1-8B",
#     tasks=["mmlu", "hellaswag", "arc_easy"],
#     batch_size=8,
# )
# print(results["results"])

promptfoo

Evaluación basada en configuración para ingeniería de prompts. Define pruebas en YAML y ejecútalas contra múltiples proveedores.

# promptfoo.yaml
providers:
  - openai:gpt-4o-mini
  - anthropic:claude-3-haiku

prompts:
  - "Answer in one word: {{question}}"

tests:
  - vars:
      question: "What is the capital of France?"
    assert:
      - type: contains
        value: "Paris"
  - vars:
      question: "What is 2 + 2?"
    assert:
      - type: equals
        value: "4"

RAGAS para evaluación de RAG

# pip install ragas
# from ragas import evaluate
# from ragas.metrics import faithfulness, answer_relevancy, context_precision
#
# result = evaluate(
#     dataset,
#     metrics=[faithfulness, answer_relevancy, context_precision],
# )
# print(result)

RAGAS mide lo que las evaluaciones genéricas pasan por alto: si la respuesta del modelo está fundamentada en el contexto recuperado, no solo si la respuesta es "correcta" en abstracto.

Conclusión

Esta lección produce outputs/prompt-eval-designer.md -- un prompt reutilizable que diseña suites de evaluación personalizadas para cualquier tarea. Dale una descripción de la tarea y generará casos de prueba, funciones de puntuación y una recomendación de umbral de aprobación/reprobación.

También produce outputs/skill-evaluation.md -- un marco de decisión para elegir la estrategia de evaluación correcta según el tipo de tarea, el presupuesto y los requisitos de latencia.

Ejercicios

  1. Agrega un evaluador de "consistencia" que ejecute la misma entrada a través del modelo 5 veces y mida qué tan a menudo coinciden las salidas. Las respuestas inconsistentes en entradas deterministas revelan prompts frágiles o configuraciones de temperatura elevadas.

  2. Extiende el rastreador ELO para admitir múltiples funciones de juez (coincidencia exacta, F1, LLM como juez) y asígnarles un peso. Compara cómo cambia la tabla de clasificación cuando asignas un peso alto a la coincidencia exacta en comparación con F1.

  3. Construye una suite de evaluación para una tarea específica: clasificación de correos electrónicos en 5 categorías. Crea 100 casos de prueba con diversos ejemplos, incluyendo casos extremos (correos electrónicos que podrían pertenecer a múltiples categorías, correos electrónicos vacíos, correos electrónicos en otros idiomas). Mide el rendimiento de diferentes "modelos" (basados en reglas, coincidencia de palabras clave, LLM simulado).

  4. Implementa la detección de contaminación: dado un conjunto de preguntas de evaluación y un corpus de entrenamiento, verifica qué porcentaje de preguntas de evaluación (o paráfrasis cercanas) aparece en los datos de entrenamiento. Así es como los investigadores auditan la validez de los benchmarks.

  5. Construye una herramienta de "model diff". Dados los resultados de la evaluación de dos versiones de modelo, resalta qué casos de prueba específicos mejoraron, cuáles empeoraron y cuáles permanecieron igual. Este es el equivalente de evaluación de un diff de código -- esencial para entender si un cambio ayudó o perjudicó.

Términos Clave

Término Lo que la gente dice Lo que realmente significa
MMLU "El benchmark" Massive Multitask Language Understanding -- 15,908 preguntas de opción múltiple en 57 materias, saturado por encima del 88% para 2025
HumanEval "Evaluación de código" 164 problemas de completado de funciones en Python de OpenAI, solo evalúa la generación de funciones aisladas
SWE-bench "Evaluación de codificación real" 2,294 problemas de GitHub de 12 repositorios de Python, mide la corrección de errores de extremo a extremo, incluyendo la generación de pruebas
Perplejidad "Qué tan confundido está el modelo" exp(-avg(log P(token_i dado el contexto))) -- menor significa que el modelo asigna una mayor probabilidad a los tokens reales
Clasificación ELO "Clasificación de ajedrez para modelos" Una calificación de habilidad relativa calculada a partir de registros pareados de victorias y derrotas, utilizada por Chatbot Arena para clasificar más de 100 modelos
LLM como juez "Usar IA para calificar IA" Un modelo fuerte califica las salidas de un modelo más débil frente a una rúbrica, ~80% de acuerdo con jueces humanos a un costo de ~$0.01 por juicio
Contaminación de datos "El modelo vio el examen" Los datos de entrenamiento incluyen preguntas de benchmarks, lo que infla las puntuaciones sin mejorar la capacidad real
Suite de evaluación "Un grupo de pruebas" Una colección con control de versiones de tripletas (entrada, salida_esperada, evaluador) que miden una capacidad específica
Tasa de aprobación "Qué porcentaje hace bien" Fracción de casos de evaluación que puntúan por encima de un umbral -- más accionable que la puntuación promedio porque mide la confiabilidad
Chatbot Arena "Sitio web de clasificación de modelos" Plataforma de LMSYS con más de 2 millones de votos de preferencia humana, que produce la tabla de clasificación de LLM más confiable a través de calificaciones ELO

Lecturas Adicionales