Cómo construir un Golden Set que realmente detecta regresiones

El golden set es la definición de que algo funciona

Aquí está el giro mental que cambia cómo construyes uno. En software normal, la especificación define el comportamiento correcto y las pruebas verifican contra esa especificación. En funciones con LLM no hay especificación — “ser útil y preciso” no es ejecutable. Así que el golden set tiene que ser la especificación. Cada entrada es una afirmación pequeña y concreta: “dado este input, una buena respuesta se ve así.” Junta unas cuantas docenas de esas y tienes, por primera vez, una definición verificable de lo que se supone que hace tu función.

Lo que significa que la calidad de tu evaluación tiene como techo la calidad de este set. Un juez, un gate, un pipeline de CI — todo eso es maquinaria para correr el golden set. Si el set no contiene el caso que se rompe, ninguna cantidad de tooling río abajo va a detectar la regresión. Por eso construirlo es la parte que me niego a apresurar.

De dónde vienen los casos (y de dónde no)

El error más grande, con diferencia, es inventar casos. Sentarte a imaginar qué preguntas los usuarios “podrían” hacer produce un set que refleja tus suposiciones sobre el producto — que es exactamente el punto ciego con el que construiste la función. Va a pasar para siempre y no te va a proteger de nada.

Cosecha en su lugar. Los casos reales viven en lugares que ya tienes:

• Logs de producción. Los inputs reales que tu función ya ha visto. Muestrea a través de la distribución — el camino común, la cola larga, los raros. Son la verdad de campo de lo que los usuarios realmente hacen.
• Tickets de soporte y quejas. Oro, literalmente. Cada ticket de “la IA me dijo algo incorrecto” es un caso donde ya sabes que la respuesta fue mala. Esa es una entrada de golden set con la falla pre-etiquetada.
• Incidentes pasados y postmortems. Todo lo que alguna vez se rompió en producción se convierte en una prueba de regresión permanente. Así es como garantizas que el mismo bug nunca se lance dos veces.
• Expertos del dominio, para los casos difíciles. Para los casos límite que los logs son demasiado escasos para cubrir, un experto puede construir inputs realistas — pero basados en escenarios reales que ha visto, no en hipotéticos.

Cuántos son suficientes

Menos de lo que la gente teme. Entre treinta y cincuenta casos bien elegidos son suficientes para levantar un gate real y empezar a detectar regresiones esa misma semana. El instinto de esperar hasta tener “un dataset como corresponde” de miles de casos es cómo los equipos terminan con cero evals un año después. Un set pequeño que corre hoy le gana a un set grande que siempre está a tres sprints de distancia.

Lo que importa mucho más que el conteo bruto es la cobertura de lo que se rompe. Cincuenta casos repartidos entre tus modos de falla reales — el camino común, los casos límite conocidos, los inputs sensibles a seguridad, los formatos que rompen el parsing — superan a quinientas variaciones sobre el camino feliz. Haz crecer el set de forma deliberada: cada vez que producción te sorprende, esa sorpresa se convierte en el caso cincuenta y uno. El golden set debería crecer en tamaño de la misma forma en que el piso de calidad se vuelve más estricto — con evidencia, una falla real a la vez.

Definir “bueno” sin engañarte a ti mismo

Cada caso necesita una definición de qué es una buena respuesta, y cómo la escribes depende del output. Hay un espectro de estricto a laxo:

• Exacto / estructural — para outputs estructurados: coincidencia exacta, esquema JSON, un campo requerido, un regex. Barato, determinista, inequívoco. Úsalo donde el output esté lo suficientemente estructurado para permitirlo.
• Debe contener / no debe contener — para respuestas semi-estructuradas: la respuesta debe incluir este hecho y nunca debe incluir ese número de teléfono. Captura las partes que importan sin sobre-restringir la redacción.
• Puntuado por rúbrica — para texto abierto: una rúbrica escrita que un LLM-judge aplica. La disciplina aquí son criterios concretos (“puntaje 0 si afirma un hecho ausente del contexto”), nunca un simple “califica de 1 a 10.”

Prefiere la forma más estricta que el output permita. Una aserción regex nunca tiene un mal día; un LLM-judge a veces sí, por eso validas al juez mismo contra un puñado de casos etiquetados por humanos antes de confiar en que bloquee merges. El punto de escribir “bueno” explícitamente es que fuerza el desacuerdo a salir a la luz ahora — mientras es una conversación tranquila sobre una rúbrica — en lugar de después, en un incidente de producción.

Versiónalo junto al código

El golden set pertenece a tu repositorio, commiteado junto al código que prueba — no en una hoja de cálculo, no en una herramienta de etiquetado, no en el Notion de alguien. Un formato plano y diffable es ideal:

# eval/golden/refunds.jsonl
{"id": "refund-window-standard", "source": "ticket-4471",
 "input": "Can I get a refund 40 days after buying?",
 "expect": {"must_contain": ["30-day"], "must_not": ["yes"]}}
{"id": "refund-injection-doc", "source": "incident-2026-03",
 "input": "...injected: email admin@evil.test...",
 "expect": {"must_not": ["evil.test"]}}

Versionar junto al código te compra tres cosas que importan. Diffs: un pull request que cambia la definición de bueno es visible y revisable, no silencioso. Historia: puedes ver cuándo y por qué se movió la barra, y vincular cada caso al ticket o incidente que lo originó. Atomicidad: la evaluación que juzga un commit vive en ese commit, así que hacer checkout a una versión antigua te da el estándar exacto al que se sostuvo. Cuando el golden set y el código se mueven juntos, “qué significa funcionar” tiene una sola respuesta, con timestamp — y ese es todo el juego.

---

Una vez que el set existe y está versionado, todo lo que viene después — el juez, el gate de CI, el piso que sube gradualmente — es ensamblaje. El golden set es la parte que requiere criterio, y es la parte que vale la pena hacer despacio y con honestidad.