El Eval Set Es la Especificación

Solía pensar que la especificación de producto era el documento. Escribe el PRD, consigue la aprobación, constrúyelo, lánzalo. Ese modelo sobrevivió toda mi carrera hasta el momento en que lancé features de LLM — y entonces se desmoronó la primera vez que un stakeholder y yo miramos fijamente el mismo output del modelo y no concordamos sobre si era bueno.

El PRD decía que el asistente debía "proveer resúmenes claros y precisos". Ambos concordábamos en esas palabras. Discrepábamos violentamente sobre si este resumen específico las cumplía. No había nada a qué apelar. Las palabras "claro" y "preciso" eran un sentir, no una spec, y no puedes construir un sistema confiable sobre un sentir.

Esa discusión es donde aprendí la regla que ahora gobierna cómo construyo cada feature de LLM: el eval set es la especificación. No el PRD. El PRD describe la intención en adjetivos. El eval set define lo correcto en ejemplos — inputs concretos emparejados con cómo se ve un buen output — y los ejemplos son el único lenguaje lo suficientemente preciso para zanjar la discusión.

Por Qué las Specs en Prosa se Rompen con LLMs

Para software determinista, una spec en prosa usualmente alcanza porque el comportamiento es enumerable. "Cuando el usuario hace click en guardar, persiste el formulario." No hay mucho espacio para discrepar sobre si eso pasó.

El comportamiento de un LLM no es enumerable. El espacio de inputs es abierto, el output es lenguaje natural difuso, y "correcto" es un juicio que dos personas razonables harán de forma distinta. La prosa no puede fijar eso. Solo los ejemplos pueden.

┌─────────────────────────────────────────────────────────────┐
│   PRD dice:   "Los resúmenes deben ser precisos y concisos"  │
│                          │                                   │
│              ┌───────────┴───────────┐                       │
│         Tú lo lees como:       Ellos lo leen como:           │
│         "3 oraciones,          "1 oración,                   │
│          todos los hechos"      el titular"                  │
│                          │                                   │
│            ambos 'cumplen', ambos distintos                  │
│                          ▼                                   │
│   Eval set dice:  input #14 → ESTE buen output exacto        │
│                   input #15 → ESTE es muy escueto → FALLA    │
│                          ▼                                   │
│            una respuesta, testeable, sin discusión           │
└─────────────────────────────────────────────────────────────┘

El PRD es donde te alineas en dirección. El eval set es donde te alineas en verdad. Necesitas el primero para empezar y el segundo para lanzar.

Constrúyelo a Partir de Fallas Reales

Los peores eval sets se escriben en una sala de juntas antes del lanzamiento, llenos de casos que el autor imaginó. Los mejores se cosechan de producción después de que la feature realmente estuvo mal frente a un usuario.

Cada vez que un clínico corregía a MILA, esa corrección se volvía un caso de eval: el input exacto que produjo la mala respuesta, y el output que el clínico habría aceptado. El eval set creció una cicatriz a la vez. En pocos meses codificaba más conocimiento real de resumen médico que cualquier documento que hubiéramos podido escribir de antemano, porque cada caso era un lugar donde la realidad había discrepado con el modelo.

Mantenlo Adversarial

Un eval set lleno de casos fáciles es un dashboard que te hace sentir bien, no una spec. Si cada caso pasa, el set no está haciendo su trabajo — te está adulando. Los casos que importan son los que casi rompen el sistema: el input ambiguo, la pregunta con trampa, el borde del dominio, el intento de prompt-injection, el paciente con dos interpretaciones válidas.

Deliberadamente agrego casos que la versión actual falla. Una spec que ya cumples no restringe nada. El eval set siempre debe tener un puñado de luces rojas que representan comportamiento hacia el que estás trabajando activamente — esa es la diferencia entre una suite de regresión y una estrella polar.

Distribución sana de un eval set:

  pasando  ████████████████████░░░░  ~80%  (guardia de regresión)
  fallando ████░░░░░░░░░░░░░░░░░░░░░  ~20%  (la frontera de la spec)

  100% pasando  →  tu set es muy fácil, te está adulando
  100% fallando →  tu set es ficción aspiracional, no una spec

Versiónalo Como Código Fuente

Si el eval set es la spec, merece el mismo rigor que el código. Vive en el repo. Los cambios pasan por pull requests. Cuando alguien debilita un caso — relaja un output esperado, borra un ejemplo que falla — eso aparece en un diff y se revisa como cualquier otro cambio a la verdad del producto.

Aquí también es donde producto e ingeniería se alinean de verdad. No en una junta donde todos asienten a los adjetivos, sino en un PR donde producto propone "el input X debe producir el output Y" e ingeniería lo hace ejecutable y evaluable. La revisión es la alineación. Cuando el PRD y el eval set discrepan, gana el eval set — porque es el que realmente puedes correr.

specs/evals/
├── summarization/
│   ├── core_cases.yaml        # el happy path, guardia de regresión
│   ├── adversarial.yaml       # inputs trampa, injections, bordes
│   └── from_production/       # fallas reales cosechadas, con fecha
│       └── 2026-05-08_confusion_dosis_hermano.yaml
└── graders/
    └── factual_consistency.py # cómo se juzga "correcto" mecánicamente

Deja Que Guíe Cada Cambio

Una vez que el eval set es la spec, el flujo se invierte de forma sana. No cambias el prompt y luego esperas que sea mejor. Haces el cambio y corres la spec. El eval set te dice si avanzaste, te quedaste igual, o regresaste — como número, no como opinión.

Un ajuste de prompt que arregla el caso que te importaba pero rompe otros tres ahora es visible antes de lanzar, no tres semanas después en una cola de soporte. Una nueva versión de modelo se evalúa contra la misma spec antes de que se le permita acercarse a producción. El eval set convierte "creo que esto es mejor" en "esto pasa 47 de 50, subió de 44, sin regresiones" — y esa oración puede sobrevivir un code review.

El Cambio de Mentalidad

Tratar el eval set como la spec cambia cómo habla todo el equipo. Las discusiones sobre calidad dejan de ser sobre gusto y empiezan a ser sobre qué caso estás discutiendo y cuál debería ser su output esperado. "No me gusta esta respuesta" se vuelve "agreguémoslo como caso y decidamos juntos el output correcto". La discrepancia se vuelve una contribución a la spec en vez de un punto muerto.

El PRD te apunta en la dirección correcta. El eval set es a lo que realmente construyes, contra lo que lanzas, y lo que defiendes en una revisión. Escribe el doc para empezar la conversación — luego deja que los ejemplos tengan la última palabra.