Construir un dataset de evaluación y rúbricas

Una evaluación no representa el sistema si solo contiene ejemplos fáciles. La calidad del dataset determina qué fallos puedes detectar antes de producción.

El objetivo no es crear un benchmark enorme, sino un conjunto versionado que represente el espacio real de trabajo, las consecuencias del error y las decisiones que el equipo necesita tomar.

Define el universo de casos

Lista dimensiones:

• tarea;
• usuario;
• idioma;
• longitud;
• formato;
• fuente;
• ambigüedad;
• riesgo;
• necesidad de tool;
• presencia de evidencia;
• dificultad;
• comportamiento esperado.

Ejemplo para RAG:

directa
multi-source
sin respuesta
contradictoria
fuente obsoleta
sin permisos
paráfrasis
código exacto

Para un agente:

happy path
tool unavailable
permiso denegado
input malicioso
estado cambiado
presupuesto agotado

Muestrea frecuencia e impacto

No copies únicamente la distribución de producción. Un fallo raro puede tener consecuencias muy altas.

Combina:

1. casos frecuentes;
2. casos críticos;
3. edge cases;
4. negativos;
5. adversariales;
6. incidentes históricos;
7. nuevos segmentos.

Puedes ponderar resultados para reporting, pero no dejes que una media oculte bloqueantes.

Registra procedencia

Cada caso necesita:

• case_id;
• origen;
• fecha;
• permiso de uso;
• transformación;
• autor/revisor;
• riesgo;
• versión.

Si usas datos reales, aplica minimización y acceso.

Cuando no puedas conservarlos, crea un caso sintético que preserve la dificultad sin reproducir información sensible.

Separa datasets

Development Puede evolucionar rápido y ser visible al equipo.

Regression Conjunto estable que protege comportamientos conocidos.

Audit/Holdout No debería utilizarse para optimizar cada iteración.

Adversarial Casos de abuso y seguridad.

Production sample Muestra temporal para detectar nuevos comportamientos.

La separación reduce overfitting editorial al benchmark.

Define referencia con el nivel correcto

No todas las tareas tienen una única respuesta textual.

Puedes usar:

Exact reference Un ID o valor.

Acceptable set Varias respuestas válidas.

Required facts Hechos que deben estar.

Forbidden facts Afirmaciones prohibidas.

Rubric Dimensiones evaluadas.

Outcome Estado real del sistema.

Para agentes, Anthropic distingue task, trial, grader, transcript/trace y outcome. Esa separación evita evaluar una trayectoria flexible como si tuviera un único texto correcto.

Diseña la rúbrica

Dimensiones posibles:

• corrección;
• completitud;
• groundedness;
• utilidad;
• formato;
• seguridad;
• elección de tool;
• cumplimiento de política;
• abstención;
• escalado.

Define niveles observables.

Malo:

«5 = excelente.»

Mejor:

«5 = responde la tarea completa, preserva todas las condiciones relevantes y cada afirmación factual importante está respaldada por la evidencia esperada.»

Calibra revisores

Dos personas pueden puntuar de forma diferente.

Usa:

• ejemplos ancla;
• doble revisión en una muestra;
• resolución de discrepancias;
• actualización de rúbrica.

Si el desacuerdo es alto, la métrica no está suficientemente definida.

Múltiples trials

Para comportamiento variable, una sola ejecución puede ocultar inestabilidad.

Ejecuta varios trials en:

• agentes;
• tareas críticas;
• casos con temperatura o muestreo;
• herramientas;
• entornos no deterministas.

No necesitas repetir todos los casos diez veces. Prioriza donde la variación importa.

Versiona

Un dataset necesita:

dataset_version
rubric_version
case_hash
review_status

Nunca sobrescribas silenciosamente una referencia.

Si corriges una etiqueta, registra motivo.

Ejemplo

Clasificación documental.

Dataset:

• 500 casos;
• 15 % categorías raras;
• 10 % documentos incompletos;
• 5 % adversariales;
• 20 casos críticos.

Rúbrica:

• categoría;
• evidencia;
• abstención;
• formato.

Una candidata mejora accuracy global de 91 a 94 %, pero empeora casos críticos de 20/20 a 17/20. La versión puede bloquearse.

Diseña casos de contraste

Un buen dataset no solo contiene ejemplos aislados. Incluye pares que permiten comprobar si el sistema distingue condiciones importantes.

Ejemplo:

Caso A: mismo documento, cliente autorizado
Caso B: mismo documento, cliente no autorizado

o:

Caso A: política vigente
Caso B: política retirada

Si el sistema responde igual en ambos, el error queda visible.

Usa taxonomías de error

Cuando un caso falla, registra una categoría:

• omisión;
• hallucination;
• groundedness;
• permiso;
• tool;
• formato;
• abstención;
• dato obsoleto;
• sobreconfianza;
• instrucción maliciosa.

Las taxonomías permiten detectar patrones y evitar «34 casos fallaron» sin diagnóstico.

Incluye severidad

No todos los fallos pesan igual.

Puedes etiquetar:

S0 informativo
S1 menor
S2 importante
S3 crítico

La severidad debe reflejar consecuencia real.

Una falta de estilo no debe competir con un acceso cruzado.

Evita leakage entre development y holdout

Si una misma conversación aparece parcialmente en development y parcialmente en audit, el sistema puede parecer mejor de lo que generaliza.

Divide por:

• cliente;
• serie;
• fuente;
• periodo;
• tarea.

Especialmente en documentos relacionados.

Añade temporalidad

Los sistemas consultan conocimiento que cambia.

Incluye casos:

• antes/después de versión;
• fecha de vigencia;
• fuente retirada.

Un modelo puede devolver una respuesta «correcta» pero temporalmente incorrecta.

Dataset de incidentes

Cada incidente importante debería producir al menos un caso:

incident_id
input
expected behavior
critical invariant

Así el aprendizaje queda codificado.

Mantén un changelog

Cuando añadas o retires casos:

• motivo;
• versión;
• impacto.

Si la puntuación cambia por cambio del dataset, no la compares directamente con un score antiguo sin recalcular.

Tamaño: suficiente, no decorativo

No existe una cifra mágica.

Un dataset de 100 casos bien estratificados puede ser más útil que 10.000 generados automáticamente sin control.

Crece con:

• diversidad;
• fallos;
• nuevas funciones;
• nuevos usuarios.

Artifact final

Entrega:

datasets/
  development.jsonl
  regression.jsonl
  audit.jsonl
  adversarial.jsonl
rubrics/
  answer-v3.json
  tool-v2.json
README.md
CHANGELOG.md

El formato es orientativo; el principio es versionar contenido y significado.

Ejercicio

Crea 40 casos:

• 20 frecuentes;
• 8 edge;
• 5 negativos;
• 4 adversariales;
• 3 críticos.

Define referencia y rúbrica.

Haz que otra persona puntúe diez. Si no puede reproducir tu criterio, reescribe la rúbrica.

Qué debes poder demostrar

La prueba de dominio es contar con un dataset que represente uso, riesgo y fallos, no una colección de demos. La siguiente lección lo convertirá en una puerta automatizada de regresión.