El golden dataset: el paso que casi nadie da

Última entrega del bloque de evaluación. Las cuatro anteriores describieron métricas y herramientas que comparten una dependencia: un conjunto de preguntas con respuesta verificada y origen anotado. Casi ningún proyecto lo construye, y es lo primero que habría que hacer. Aquí está el procedimiento completo.

Qué es exactamente y por qué se salta todo el mundo

Un golden dataset —conjunto de referencia, si prefieres el término en español— es una colección de casos en los que consta, como mínimo: la pregunta, la respuesta correcta verificada por una persona, y el identificador del fragmento o fragmentos del corpus donde está esa respuesta.

Esa tercera pieza es la que lo distingue de una lista de preguntas frecuentes y la que desbloquea la capa de recuperación entera: sin fragmento anotado no hay recall@k, no hay MRR y no hay forma de saber si el problema está antes o después del modelo.

No se construye por tres motivos, y ninguno es técnico. Es trabajo manual aburrido en un proyecto donde todo lo demás parece más interesante. Su beneficio llega tarde: la primera semana no aporta nada visible, y a partir del tercer mes es lo único que impide que cada cambio sea una apuesta. Y existe la ilusión de que las preguntas sintéticas lo sustituyen: una pregunta generada a partir de un fragmento se responde recuperando ese fragmento, con lo que se evalúa el sistema en el caso más favorable posible.

El tamaño razonable está entre cincuenta y doscientas preguntas. Con cincuenta se detectan regresiones groseras y se empieza a trabajar. Con doscientas bien repartidas se pueden comparar configuraciones con cierta seriedad. Por encima de quinientas el coste de mantenimiento supera al beneficio para casi cualquier proyecto que no sea un producto de evaluación en sí mismo.

De dónde salen las preguntas

El orden de estas fuentes no es arbitrario: va de la más representativa a la menos.

Registros reales

Si el sistema ya está en marcha, aunque sea con diez usuarios internos, los registros de consultas son la mejor fuente que existe. Contienen la distribución real de temas, el vocabulario real —siglas internas, nombres de producto abreviados, faltas de ortografía— y, sobre todo, las preguntas mal formuladas que nadie escribiría al diseñar un conjunto de prueba.

Dos filtros al muestrear: incluir deliberadamente las consultas que terminaron en reformulación o en escalado a un humano, porque son fallos confirmados; y no quedarse sólo con la cabeza de la distribución, porque la cola larga es donde el sistema se rompe.

Atención al cliente y soporte

Tickets, transcripciones de chat, hilos de correo, el buzón interno de dudas. Es material anterior al proyecto y tiene una ventaja añadida: muchas veces incluye la respuesta que dio un humano competente, que sirve de borrador de respuesta de referencia.

Entrevistas con quien sabe

Media hora con dos personas de soporte y una del equipo de producto produce más casos difíciles que una semana de generación automática. La pregunta que hay que hacerles no es «¿qué pregunta la gente?» sino «¿qué pregunta se contesta mal casi siempre?» y «¿qué dos documentos se contradicen?». Ahí están los casos que importan.

Cobertura del corpus

Una vez recogido lo anterior, se revisa qué zonas del corpus no está tocando ninguna pregunta —secciones enteras, tipos de documento, anexos— y se añaden casos para cubrirlas. Aquí sí es legítimo usar generación asistida por modelo, siempre que una persona revise, reescriba la pregunta con vocabulario de usuario y verifique la anotación.

Cómo se anota

La anotación de un caso tiene cuatro decisiones, y conviene tomarlas en este orden.

1. ¿Tiene respuesta en el corpus? Si no la tiene, el caso es igual de valioso: la respuesta esperada es la abstención. Volvemos a ello enseguida.
2. ¿Qué fragmentos la contienen? Se anotan todos, no sólo el primero que aparezca. Si la respuesta completa exige combinar dos fragmentos, se marcan los dos y se indica que hacen falta ambos: es un caso multi-salto y evaluarlo como si bastara uno da métricas engañosas.
3. ¿Cuál es la respuesta correcta? Concisa y factual, con las cifras y las excepciones que deban aparecer. No es el texto que debe producir el sistema palabra por palabra: es el criterio contra el que se compara.
4. ¿Qué categoría y dificultad tiene? Estas etiquetas parecen burocracia y son lo que permite después leer los resultados por segmento en lugar de mirar una media que no dice nada.

Regla de oro: dos anotadores en los casos dudosos. Cuando dos personas competentes discrepan sobre cuál es el fragmento correcto, no es que una se equivoque: es que la pregunta es ambigua o el corpus se contradice, y eso es un hallazgo que hay que registrar.

Los casos que hay que incluir a propósito

Un conjunto compuesto sólo por preguntas limpias con respuesta clara mide el sistema en su mejor día y no sirve para nada. La composición debe forzar los modos de fallo conocidos:

• Sin respuesta en el corpus. Preguntas plausibles cuya respuesta no está en ninguna parte; lo correcto es «no consta en la documentación». Entre el 10 % y el 20 % del conjunto. Detectan el fallo más peligroso: el sistema que inventa antes que admitir un hueco.
• Multi-salto. La respuesta exige combinar dos o tres fragmentos, quizá de documentos distintos.
• Ambiguas o dependientes de contexto. «¿Y para el caso internacional?» sin turno anterior. La respuesta correcta puede ser pedir aclaración.
• Con vocabulario ajeno al corpus. El usuario dice «devolver» y el documento dice «desistimiento». Separan la búsqueda semántica de la literal.
• Con códigos, referencias y nombres propios. Justo lo contrario: donde BM25 gana y el vector solo falla.
• Temporalmente sensibles. Su respuesta cambió y el corpus contiene la versión antigua y la nueva. Detectan si el sistema sabe cuál manda.
• Fuera de alcance. Temas que el sistema no debe tratar. La respuesta correcta es la negativa educada.

Un formato de fichero

JSON Lines, un caso por línea, en el repositorio y bajo control de versiones junto al código. Legible por humanos, diferenciable en una revisión de cambios, trivial de cargar desde cualquier herramienta.

{
  "id": "gd-0142",
  "pregunta": "¿Cuánto tiempo tengo para devolver un pedido a Portugal?",
  "respuesta_referencia": "30 días naturales desde la entrega. El envío de vuelta lo paga el cliente salvo que el producto sea defectuoso.",
  "fragmentos_relevantes": [
    {"doc_id": "politica-devoluciones-v4", "chunk_id": "pd-v4-012", "grado": 3},
    {"doc_id": "anexo-internacional-2024", "chunk_id": "ai-2024-003", "grado": 2}
  ],
  "requiere_todos": true,
  "categoria": "devoluciones",
  "dificultad": "multi-salto",
  "tiene_respuesta": true,
  "vocabulario_usuario": true,
  "fuente": "log-produccion-2025-11",
  "anotado_por": "mmv",
  "fecha_anotacion": "2025-11-14",
  "verificado_contra_corpus": "2026-02-03",
  "notas": "El usuario dice 'devolver'; el documento dice 'desistimiento'."
}
{
  "id": "gd-0143",
  "pregunta": "¿Puedo devolver un producto comprado en una tienda física?",
  "respuesta_referencia": null,
  "abstencion_esperada": "No consta en la documentación disponible.",
  "fragmentos_relevantes": [],
  "categoria": "devoluciones",
  "dificultad": "sin-respuesta",
  "tiene_respuesta": false,
  "fuente": "entrevista-soporte-2025-10",
  "anotado_por": "jlr",
  "fecha_anotacion": "2025-10-28",
  "verificado_contra_corpus": "2026-02-03"
}

Cuatro campos merecen comentario. grado permite relevancia graduada y por tanto nDCG con grados, como vimos en la entrega 37. requiere_todos distingue el caso multi-salto del que se resuelve con cualquiera de los fragmentos. verificado_contra_corpus es la fecha de la última comprobación de la anotación, y es el campo que hace posible el mantenimiento. Y fuente permite saber, meses después, qué parte del conjunto viene de usuarios reales y qué parte de tu imaginación.

Cómo se mantiene cuando el corpus cambia

Este es el punto donde mueren la mayoría de los golden datasets: se construyen una vez, el corpus se reindexa con otro tamaño de chunk y todos los chunk_id anotados dejan de existir.

Cuatro medidas evitan el desastre:

• Ancla al documento, no sólo al chunk. Guarda siempre doc_id además de chunk_id, y una cita textual corta del pasaje relevante. Si el troceado cambia, se puede reanclar automáticamente buscando esa cita en los nuevos fragmentos. Sin la cita, la reanotación es manual y no se hace.
• Verificación programada. Un trabajo semanal comprueba que cada chunk_id anotado sigue existiendo y que cada doc_id sigue en el índice. Los casos rotos se marcan y no se cuentan hasta que alguien los revisa, en lugar de puntuar como fallos y hundir el número sin motivo real.
• Caducidad explícita. Un caso cuyo verificado_contra_corpus tenga más de seis meses se revisa. Un conjunto de referencia con respuestas obsoletas es peor que no tener conjunto: penaliza al sistema por acertar.
• Crecimiento desde producción. Cada fallo real se convierte en un caso nuevo, anotado, con su origen. Es lo que mantiene vivo el conjunto sin campañas de anotación: si algo falló una vez, no volverá a fallar sin que salte la alarma.

Convertirlo en prueba de regresión

El conjunto sólo tiene valor si se ejecuta automáticamente. La pauta, coherente con los tres niveles de integración continua de la entrega anterior:

• En cada cambio, métricas de recuperación sobre el conjunto completo. Son baratas y deterministas. El umbral es relativo a la rama principal, no absoluto.
• En cada solicitud de cambio, métricas de generación sobre un subconjunto estratificado que incluya obligatoriamente casos sin respuesta y casos multi-salto.
• El informe útil no es la media: es la lista de casos que cambiaron de veredicto. Diez casos que mejoran y ocho que empeoran pueden dar una media plana y esconder una regresión grave en una categoría concreta.
• Resultados siempre desglosados por categoria y dificultad. Un sistema que mejora en preguntas fáciles y empeora en las sin respuesta ha empeorado, aunque la media diga lo contrario.

Límites y advertencias

Un golden dataset es una muestra, y toda muestra tiene sesgo. Si se construyó con las preguntas de tres personas de soporte, mide bien el mundo de esas tres personas. Revisar cada trimestre si su distribución se parece a la de los registros de producción es parte del mantenimiento.

Segundo: es optimizable, y por tanto corruptible. Un equipo que mira las mismas doscientas preguntas durante seis meses acaba afinando el sistema para esas doscientas preguntas. La contramedida es reservar entre el 20 % y el 30 % de los casos como conjunto ciego, que no se mira durante el desarrollo y sólo se ejecuta antes de un despliegue importante.

Tercero: no cubre lo que no imaginaste. Sigue haciendo falta leer respuestas reales, y ese trabajo sólo se vuelve más rentable cuando lo previsible ya está automatizado.

Y cuarto, dicho sin adornos: cincuenta preguntas bien anotadas valen más que cinco mil generadas automáticamente. Si sólo puedes permitirte una tarde, dedícala a las cincuenta.

Qué viene ahora

Aquí termina el bloque 6. Con las tres capas de métricas, las fórmulas de recuperación, la evaluación con modelo juez, las herramientas y el conjunto de referencia, ya existe la instrumentación para decidir con datos en lugar de con impresiones. El bloque 7 se ocupa de lo que viene después: producción, riesgos y futuro. Arranca con la arquitectura de referencia de un RAG en producción —indexación offline y consulta online, colas, reintentos, el recorrido completo de una pregunta— y sigue con la economía del sistema, las causas raíz de las alucinaciones, la seguridad del corpus, el control de acceso granular, la observabilidad y, para cerrar la serie, hacia dónde va todo esto.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.