Crear evaluaciones offline y puertas de regresión

Una evaluación offline responde una pregunta concreta:

«¿Esta versión candidata es suficientemente buena para exponerse a usuarios reales?»

No demuestra por sí sola comportamiento de producción, pero reduce cambios ciegos y permite atribuir regresiones antes de ampliar el radio de impacto.

Congela la unidad evaluada

Una ejecución debe registrar:

• código;
• modelo;
• versión de instrucciones;
• herramientas;
• dataset;
• índice;
• parámetros;
• proveedor;
• configuración;
• entorno.

Si cambias dos componentes y mejora el resultado, no sabes cuál fue la causa.

Controla el entorno

Esto es especialmente importante en agentes.

Anthropic ha documentado que diferencias de infraestructura pueden alterar materialmente resultados de benchmarks agentic. Controla:

• CPU/memoria;
• red;
• dependencias;
• versiones;
• repositorio inicial;
• tool latency;
• fixtures.

Si no puedes eliminar ruido, mídelo.

Combina evaluadores

Deterministas

• schema;
• regex;
• IDs;
• catálogo;
• permisos;
• outcomes;
• tests.

Humanos

• utilidad;
• interpretación;
• matices.

Model-based graders

• groundedness;
• relevancia;
• clasificación semántica.

Comparación A/B offline

• preferencia entre outputs.

Ningún grader debe considerarse verdad universal.

Calibra model-based graders contra una muestra humana.

Diseña una puerta

Ejemplo:

BLOCK if:
- any cross_tenant
- any unauthorized_write
- critical_accuracy < 100 %
- regression > 3 pp in segment X

REVIEW if:
- p95_cost +20 %
- latency +15 %

No copies estos valores. Son ejemplos de estructura.

Compara por caso

Guarda un diff:

case
baseline
candidate
delta
reason

Una media de 0,87 frente a 0,88 oculta qué cambió.

Clasifica:

• mejora;
• regresión;
• sin cambio;
• nueva variación;
• inconcluso.

Usa intervalos o repetición cuando haga falta

En sistemas no deterministas, un resultado puntual puede ser ruido.

Para casos críticos:

• múltiples trials;
• proporciones;
• distribución;
• intervalos si tienes muestra suficiente.

No afirmes una mejora del 1 % si la variación del sistema es mayor.

Separa harness y plataforma

El activo duradero debe ser:

• dataset;
• rúbrica;
• graders;
• configuración;
• resultados.

No una interfaz propietaria.

Esto es especialmente importante en 2026: OpenAI ha anunciado la deprecación de su plataforma Evals; los evals existentes pasarán a read-only el 31 de octubre y el cierre del dashboard/API está previsto para el 30 de noviembre de 2026.

Por tanto, este curso no depende de esa plataforma. Puedes ejecutar evals con tu propio runner, CI o una herramienta externa siempre que el formato sea reproducible y portable.

Integra en CI con criterio

No ejecutes el suite completo en cada commit si cuesta horas.

Niveles:

PR

• tests rápidos;
• subset.

Pre-release

• regression completo.

Nightly

• muestras amplias;
• live tests.

Before model change

• suite crítico.

Distingue offline de live

Los tests normales deben usar:

• mocks;
• fixtures;
• simuladores.

Las pruebas live comprueban:

• compatibilidad;
• comportamiento real;
• proveedor.

Hazlas opt-in y controla coste.

Informe de puerta

Debe incluir:

• versiones;
• dataset;
• métricas;
• casos bloqueantes;
• deltas;
• latencia;
• coste;
• incertidumbre;
• decisión.

No solo «PASS».

Haz el runner auditable

Cada run debe emitir:

run_id
timestamp
git_sha
config_hash
dataset_version
model
grader_versions
environment
results

Si no puedes reproducir el run, el score pierde valor operativo.

Controla fallos del evaluador

Un grader puede fallar por:

• rate limit;
• formato;
• ambigüedad;
• drift.

No mezcles «grader error» con «candidate failed».

Registra:

• NOT_GRADED;
• INCONCLUSIVE.

Reintenta de forma limitada o envía a revisión.

Graders programáticos

Prioriza código cuando el criterio es objetivo.

Ejemplos:

• JSON válido;
• cita existe;
• herramienta autorizada;
• fichero creado;
• estado final.

Son más baratos y reproducibles.

Pairwise vs pointwise

Un grader puede puntuar una salida o comparar A/B.

Pairwise puede ser útil cuando la diferencia de calidad es difícil de calibrar en una escala absoluta.

Pero:

• cambia el orden A/B;
• controla sesgo de posición;
• valida contra humanos.

Evalúa coste del eval

Una batería con miles de llamadas puede costar más que la función evaluada.

Registra:

• eval cost;
• duration;
• API calls.

Usa tiers.

Resultados no comparables

Marca un run como no comparable si:

• cambió dataset;
• falló infraestructura;
• faltó un proveedor;
• cambió la rúbrica sin recalibración.

No fuerces una gráfica continua.

Quarantine de casos inestables

Un caso puede ser ambiguo o depender de un servicio inestable.

No lo borres automáticamente.

Muévelo a: quarantine

Investiga y corrige.

Revisión de gates

Las puertas deben evolucionar.

Cuando el producto madura:

• añade nuevos bloqueantes;
• ajusta thresholds.

Cualquier cambio del gate debe versionarse y justificarse.

Ejemplo de salida

Candidate: v42
Regression: PASS
Critical: 50/50
Overall: +2.1 pp
Latency p95: +4 %
Cost: -11 %
Inconclusive: 3
Decision: CANARY

El objetivo es producir una decisión, no un leaderboard.

Ejercicio

Implementa un runner que:

1. carga dataset;
2. ejecuta baseline y candidata;
3. puntúa;
4. compara;
5. aplica gates;
6. genera diff;
7. sale con código distinto si hay bloqueo.

Después introduce una regresión deliberada y comprueba que CI falla.

Resultado de la lección

Debes terminar con una puerta de cambio reproducible e independiente del proveedor. La siguiente lección extenderá la evaluación a RAG, agentes y herramientas, donde «respuesta correcta» deja de ser suficiente.