Golden datasets: tu set de casos de prueba para IA
Un golden dataset es un conjunto de casos de prueba con respuestas de referencia, versionado. Cómo construirlo con trazas reales y mantenerlo al día.
¿Qué es un golden dataset?
Si ya leíste qué son los evals, esto es la otra mitad: el eval es la prueba y el golden dataset es el material con el que se prueba. Cada caso tiene una entrada (lo que escribió el usuario, el estado del sistema, los documentos disponibles) y un resultado esperado o un criterio de aceptación. Cuando cambias el prompt, corres el conjunto y comparas.
“Golden” no significa que las respuestas sean perfectas. Significa que son la referencia contra la que se mide. Por eso el set se trata como un artefacto controlado: si cambia en silencio entre dos ejecuciones, la comparación no vale nada.
¿De dónde salen los casos?
Hay tres fuentes, en orden de importancia:
- Trazas reales de producción. Conversaciones que fallaron, respuestas que un usuario corrigió, casos que un revisor marcó. Langfuse considera que los fallos son los elementos de más valor y recomienda mover las trazas marcadas al set mientras el fallo es reciente. Esos casos son candidatos: una persona debe escribir la salida correcta antes de que cuenten en un experimento. También afirma que cualquier tipo de entrada que haya causado un incidente o un ticket de soporte merece estar en el set.
- Importaciones. Una hoja de cálculo de casos que el equipo de soporte ya tiene puede cargarse como CSV.
- Datos sintéticos. Sirven para cubrir huecos que producción todavía no ha ejercitado. La regla de Langfuse es revisarlos con el mismo rigor que los reales y usarlos para ampliar un núcleo basado en producción, no para reemplazarlo.
Hamel Husain y Shreya Shankar van en la misma línea. Dicen que el análisis de errores sobre trazas reales es la actividad más importante de los evals, que las métricas genéricas (utilidad, coherencia) miden cualidades abstractas y que los datos sintéticos solo dan evidencia limitada de cómo se comportarán los usuarios reales. Recomiendan revisar al menos 100 trazas antes de decidir qué medir.
¿Cómo se organiza?
Un error común es meter todo en un solo archivo. Langfuse recomienda un dataset por componente o comportamiento, sin mezclar el flujo completo con un paso aislado, de modo que cuando un caso falla la causa esté localizada. Propone nombres tipo carpeta, como support-agent/golden y support-agent/adversarial.
El tamaño depende del objetivo. Estas son las referencias de Langfuse:
| Objetivo | Tamaño orientativo |
|---|---|
| Explorar un problema concreto | Unos 10 casos |
| Probar los límites de capacidad del sistema | Unos 10 ejemplos complejos y sin resolver |
| Compuerta rápida en cada cambio | Decenas a pocos cientos, para que corra rápido |
| Regresión completa (CI de cambios grandes, antes de publicar) | 100 a 1000 casos que cubran la distribución de producción |
| Pruebas de guardarraíles y ataques | Grande y creciente, con casos añadidos conforme aparecen |
Para arrancar, Langfuse sugiere de 20 a 50 casos revisados. Y subraya algo más importante que el número: cubrir modos de fallo distintos. Diez casos que fallaron por razones diferentes valen más que cien casos del mismo tipo.
¿Cómo se mantiene sin que se vuelva obsoleto?
Langfuse dice que la frescura es lo que se degrada en silencio: un set puede ser válido y estar viejo, porque cambian los usuarios, las políticas, las herramientas y el idioma en que escriben. Un proceso razonable:
- Agrega, no reemplaces. Trata el set como un registro que crece y sigue a producción: cada fallo nuevo entra como caso.
- Fecha cada caso en sus metadatos, para ver de un vistazo qué tan viejo está el conjunto.
- Revisa los casos viejos. Langfuse sugiere una pasada trimestral sobre los casos de más de seis meses, comparando cada uno con el comportamiento actual del producto. Si la política cambió, la referencia está mal.
- Archiva, no borres. Los casos archivados dejan de usarse en las ejecuciones futuras, pero siguen en el historial de versiones, y así las comparaciones antiguas se pueden interpretar.
- No retires un caso solo porque el sistema lo pasa. Retíralo cuando el comportamiento que medía ya no existe (por ejemplo, se eliminó una función) o cuando la respuesta esperada quedó mal por un cambio de política. Los casos que se pasan confirman que algo sigue funcionando.
¿Cómo se versiona?
En Langfuse, cada alta, edición, borrado o archivo de casos crea una versión nueva con marca de tiempo, y cada experimento guarda contra qué versión corrió. Si comparas ejecuciones separadas por días o semanas, conviene fijar una versión, porque si no el experimento usa la más reciente y no sabrás si cambió el modelo o cambiaron los casos. Como línea base, Langfuse indica elegir normalmente la versión que está en producción y comparar cada candidata contra ella.
Si no usas una herramienta que lo haga por ti, replica la idea: un archivo en git con la versión en el nombre o en la etiqueta. Langfuse recomienda guardar al menos la fecha de alta y el origen de cada caso (por ejemplo, production-failure). Añadir quién lo etiquetó es una buena práctica propia del equipo, y ayuda cuando alguien discute un caso.
Ejemplo
Ejemplo ilustrativo: un asistente de reservas de un restaurante tiene un golden dataset de 300 casos, separado en cuatro archivos: reservas, cancelaciones, preguntas de menú y casos de borde. Cuando un usuario reporta que el asistente aceptó una reserva para un día cerrado, el caso entra al archivo de reservas con el origen “traza de soporte” y la respuesta correcta. Al cambiar el prompt, la compuerta rápida corre los 60 casos de reservas y detecta que el cambio arregló ese caso pero rompió dos de cancelación. Ese es el valor de tener el set separado y versionado.
Cada tres meses, el equipo muestrea 50 trazas recientes y descubre que ahora el 30 % de las conversaciones son en inglés, cuando el set tenía solo 5 %. Agregan casos en inglés y anotan el cambio en el registro de versiones.
Pasos para empezar
- Elige un comportamiento de tu producto y reúne de 20 a 50 trazas reales de ese comportamiento, empezando por las que fallaron.
- Escribe para cada una la respuesta de referencia o el criterio de aceptación. No tiene que ser perfecto: Husain y Shankar aconsejan tratar las expectativas iniciales como un punto de partida que se revisa.
- Guárdalo en un archivo propio, con versión y fecha, fuera de cualquier herramienta. Así no dependes de una plataforma: OpenAI, por ejemplo, anunció el cierre de su plataforma de Evals.
- Agrega cada fallo nuevo al archivo en cuanto aparezca.
- Pon una fecha trimestral para revisarlo contra producción. Cuando uses un modelo como juez para calificar, valida ese juez contra casos etiquetados por personas (más en LLM-as-judge).
Errores comunes
- Construir el set solo con ejemplos inventados por el equipo.
- Meter todos los casos en un solo archivo, sin separar por componente o comportamiento.
- Cambiar el set sin versionar y comparar resultados de versiones distintas.
- Borrar casos viejos en vez de archivarlos.
- Creer que un set de 500 casos parecidos vale más que uno de 50 que cubren fallos distintos.
- Usar casos sintéticos sin revisarlos con el mismo rigor que los reales.
Fuentes
- Golden dataset evaluation: build and maintain LLM test sets (Langfuse): tamaños, origen de los casos, datos sintéticos, versionado, revisión trimestral, archivar en vez de borrar.
- LLM Evals: Everything You Need to Know (Hamel Husain y Shreya Shankar): análisis de errores, límites de las métricas genéricas y de los datos sintéticos, conjuntos de evaluación que envejecen.
- Evals guide (OpenAI, documentación): datos de prueba con etiquetas de referencia y aviso de cierre de la plataforma de Evals.