Idea en 30 segundos
Golden dataset es un conjunto fijo de casos de prueba con el que el equipo valida de forma estable el comportamiento del agente.
El valor clave: la misma versión de dataset da resultados comparables entre candidate y baseline.
Problema
Sin golden dataset, el testing se vuelve aleatorio rápidamente:
- hoy se prueba un conjunto de prompts;
- mañana, otro distinto;
- pasado mañana, parte de los casos ni siquiera se ejecuta.
En ese modo, cuesta entender qué cambió tras una release: el comportamiento del agente o simplemente el conjunto de escenarios.
Consecuencias más frecuentes:
- las regresiones se detectan tarde;
- el
diffentre versiones se ve inestable; - el CI gate se llena de ruido y el equipo deja de confiar en él.
Concepto principal / modelo
Golden dataset no es solo una colección de ejemplos; es un artefacto versionado: estructura clara de casos, reglas de etiquetado y versión controlada.
| Elemento del caso | Para qué sirve |
|---|---|
id | Identifica el caso de forma estable entre versiones |
input | Fija exactamente lo que se envía al agente |
expected_behavior | Define qué se considera un resultado correcto |
checks | Define validaciones deterministas para el sistema de evaluación |
tags | Permite agrupar casos por riesgos y tipos de escenario |
Cuanto más estables sean el esquema de casos, el etiquetado y la versión del dataset, menor la probabilidad de que las diferencias entre runs se expliquen por ruido y no por un cambio real de comportamiento.
Cómo funciona
En la práctica, golden dataset se actualiza con un proceso separado, no junto con cada release. Cada caso nuevo pasa por los mismos pasos antes de entrar en una versión del dataset.
Cómo se forma una versión operativa de golden dataset
- Sources - los casos salen de trazas de producción, incidentes y edge cases importantes.
- Dedupe and filter - se eliminan duplicados y escenarios ruidosos antes del etiquetado.
- Canonical schema - cada caso se normaliza a una estructura única (
id,input,expected_behavior,checks,tags). - Review and label - se fijan comportamiento esperado y criterios de validación.
- Version and freeze - el dataset recibe versión (por ejemplo,
v1.4) y se usa sin cambios en eval runs.
Golden dataset no ejecuta pruebas por sí solo. Da la base estable para eval harness y comparaciones de regresión.
Implementación
En la práctica, golden dataset se sostiene en unas pocas reglas simples. Los ejemplos de abajo son esquemáticos y no dependen de un framework concreto.
1. Esquema canónico del caso
expected_behavior puede incluir tanto expectativas estrictas para checks deterministas como criterios para scoring con LLM-as-a-judge.
case = {
"id": "support_refund_partial_outage",
"input": "Refund my order #8472",
"expected_behavior": {
"selected_tool": "payments_api",
"allowed_stop_reasons": ["completed", "tool_error_handled"],
},
"checks": ["tool_selection", "valid_output_schema"],
"tags": ["payments", "support", "partial-outage-risk"],
}
Un esquema claro elimina ambigüedad al analizar casos problemáticos.
2. Deduplicación y filtro de ruido
def is_duplicate(case, seen_signatures):
signature = f"{case['input']}|{case['expected_behavior']}"
return signature in seen_signatures
def is_noisy(case):
return len(case["input"].strip()) == 0
Es mejor un dataset más pequeño pero estable que un conjunto grande con duplicados y ruido.
3. Etiquetado de comportamiento esperado
def validate_case(case):
required = ["id", "input", "expected_behavior", "checks"]
for key in required:
if key not in case:
raise ValueError(f"missing_field:{key}")
El etiquetado debe poder validarse: si la expectativa no es verificable, el caso no está listo para golden dataset.
4. Versionado del dataset
dataset_version = "golden-v1.4"
metadata = {
"dataset_version": dataset_version,
"created_from": "incidents_2026_q1",
"notes": "added outage and tool-fallback cases",
}
El dataset debe versionarse con la misma disciplina que el código.
La comparación entre candidate y baseline debe atarse a una versión concreta del dataset.
Cambiar casos sin nueva versión de dataset equivale, en la práctica, a tener otro conjunto de pruebas.
5. Integración con eval harness
run_eval_suite(
agent=candidate_agent,
dataset_path="datasets/golden-v1.4.json",
baseline_report="reports/baseline-golden-v1.4.json",
)
La misma versión de dataset debe usarse para candidate y baseline; de lo contrario, el diff pierde sentido.
Notas para QA y automatización
Los equipos de QA suelen construir suites de regresión automatizadas sobre golden dataset: un smoke set corto para cada PR y un set completo de regresión para runs programados.
Las etiquetas de casos (payments, support, outage-risk) permiten armar estos sets de forma estable sin selección manual y localizar rápido en qué clase de escenarios apareció la regresión.
Errores típicos
El dataset cambia entre runs
Se agregan o editan casos sin nueva versión, por eso los resultados de dos ejecuciones ya no son comparables.
Causa típica: no existe un proceso explícito de versionado del dataset.
Solo casos happy path
El dataset cubre solo solicitudes "limpias" y no incluye incidentes ni edge cases.
Causa típica: los casos se agregan manualmente sin analizar trazas de producción.
Etiquetado poco claro de expected behavior
Los casos tienen input, pero no expectativa verificable, así que los evaluators no pueden dar un verdict fiable.
Causa típica: etiquetado en formato libre sin esquema.
Condiciones de run sin fijar
Incluso pruebas correctas no dan resultados comparables si entre runs cambian modelo, runtime o dependencias externas.
Causa típica: alias de modelo, ajustes runtime flotantes o entorno inestable.
Falta de tags de cobertura
El equipo no ve qué clases de riesgo ya están cubiertas por el dataset y cuáles siguen vacías.
Causa típica: casos guardados sin tags ni agrupación por escenarios.
Casos inestables dentro de golden dataset
El mismo caso a veces pasa y a veces falla, y eso contamina la señal de regresión.
Causa típica: dependencias externas inestables o runtime no totalmente controlado.
Resumen
- Golden dataset hace reproducibles los eval runs.
- Un caso sin esquema claro y comportamiento esperado no debe entrar al golden dataset.
- La versión de dataset debe ser la misma para
candidateybaseline. - Los mejores casos provienen de incidentes de producción y edge cases.
FAQ
Q: ¿En qué se diferencia golden dataset de un conjunto de pruebas normal?
A: Es una base de casos estable y versionada, usada para comparar comportamiento del agente entre versiones.
Q: ¿Con qué frecuencia actualizar golden dataset?
A: Normalmente en versiones separadas, después de acumular incidentes nuevos o escenarios importantes, no antes de cada release pequeña.
Q: ¿Se pueden incluir casos sintéticos?
A: Sí, pero la base debe apoyarse en escenarios reales de producción. Los casos sintéticos complementan bien la cobertura de edge cases.
Q: ¿Qué hacer con casos inestables?
A: O estabilizar runtime y checks, o quitar temporalmente el caso del golden dataset hasta normalizar condiciones de run.
Qué sigue
Después de preparar golden dataset, conéctalo con Eval Harness y controla cambios entre versiones con Regression Testing.
Para incidentes en entornos reales, añade Replay and Debugging. Para la imagen completa de testing, mantén Testing Strategy como referencia.