El eval set es el contrato con tu propio sistema.

Una vez que tu sistema crece. chain de 3 pasos, router con 4 rutas, RAG con generate honesto. ya no podés probarlo mentalmente. Necesitás un set de casos de prueba que demuestren que el sistema hace lo que prometés.

Ese set es el eval set. Y la habilidad de escribir uno bueno es lo que separa al ingeniero de LLMs del que arma demos.

Qué hace bueno a un eval set

Un eval set no es un puñado de casos aleatorios. Es una selección curada de inputs que cubren:

1. Control cases. Casos obvios que cualquier sistema decente debería pasar. Si fallan, el sistema está roto en lo básico.
2. Edge cases. Casos en los bordes. inputs vacíos, inputs muy largos, inputs en otro idioma, inputs ambiguos entre dos categorías.
3. Adversarial cases. Casos que intentan romper el sistema: typos, jerga, instrucciones inyectadas, mensajes que SUENAN como una categoría pero son de otra.

Cada caso lleva un comment: para qué está ahí. Sin comments, cuando un caso falle dentro de 6 meses, no vas a saber si era un control o un edge case que conscientemente decidiste no soportar.

El task

Echo te pide un eval set para el classifier del step 02 (4 categorías: safety, maintenance, social, other).

Al menos 10 cases, distribuidos:

• 4+ con cada categoría representada.
• 2+ ambiguos (donde un classifier mediocre se confundiría).
• 2+ adversariales (jerga, typos, inyección, falsos positivos).
• Todos con comment explicando qué evalúa el caso.

Cómo se evalúa

6 criterios LLM-judge sobre la calidad del set:

1. Al menos 10 cases con shape correcto.
2. Cubre las 4 categorías.
3. Tiene cases ambiguos marcados.
4. Tiene cases adversariales marcados.
5. Comments no triviales que justifican cada case.
6. No es solo casos fáciles.

El test mental: si yo, leyendo solo tu eval set, podría reconstruir qué hace el classifier y dónde le cuesta. pasaste. Si parece "10 inputs random con sus labels", no pasaste.