El golden set: cómo se construye el conjunto de casos que decide si tu IA funciona

«Enseñadme vuestro golden set.» Es la pregunta que ordena una conversación sobre IA en producción más rápido que ninguna otra, porque las respuestas se reparten siempre en las mismas tres. La primera: no tenemos. La segunda, la más común: sí, hay una hoja con ejemplos —y lo que enseñan son los ejemplos que viven dentro del prompt. La tercera, la rara: sí, 180 casos, versionados en el repositorio, con dueño y con fecha de última revisión.

Las tres primeras semanas de trabajo con un equipo se parecen mucho según cuál de las tres sea. Y no es una cuestión de madurez técnica: hemos visto equipos con trazas distribuidas impecables, canary automatizado y un backend de observabilidad caro que, cuando les preguntas contra qué casos deciden si el release de mañana es mejor que el de hoy, no tienen el fichero.

En el artículo sobre LLMOps describimos el ciclo completo de un sistema LLM en producción, y en el de la rúbrica y el baseline desmontamos qué significa exactamente «funciona mejor». Los dos dan por supuesto el mismo objeto: un conjunto de casos etiquetados del que sale todo lo demás. Este artículo es sobre ese objeto — de dónde salen los casos, cuántos hacen falta, quién los etiqueta, cómo se protege de contaminarse y por qué, si lo miras demasiado, deja de servir.

Qué es un golden set, y las cuatro cosas que se le confunden

Un golden set es una colección versionada de casos con condiciones de aceptación escritas antes de mirar la salida del sistema. Cada caso lleva su entrada, el estado inicial que necesita, qué tiene que cumplirse para considerarlo resuelto, qué capacidad ejercita, de dónde salió y quién responde de él. Vive en el repositorio, se revisa en pull request y cambia con número de versión. Es, literalmente, la definición operativa de «funciona» para tu dominio.

Casi todos los problemas que hemos visto en evaluación empiezan por confundirlo con otra cosa que se le parece.

Por qué es el activo de más larga vida de todo el sistema

Hay una pregunta que coloca el golden set en su sitio dentro de la arquitectura: si mañana cambias de proveedor de modelo, ¿qué te llevas?

Los prompts se reescriben, porque cada familia de modelos responde distinto a las mismas instrucciones. La estrategia de recuperación se ajusta. Los umbrales se recalibran. El framework de orquestación puede sustituirse entero en un trimestre. Incluso la rúbrica se retoca, porque aparecen modos de fallo nuevos. Lo único que cruza intacto de un lado al otro es el conjunto de casos: eso es conocimiento de tu negocio, no del proveedor.

Esto tiene una consecuencia práctica en cómo se presupuesta. El golden set suele tratarse como una tarea de preparación —algo que se hace deprisa para poder empezar a medir— cuando en realidad es la inversión con mejor amortización del proyecto. En los tres o cuatro años que un sistema de IA vive en producción, el conjunto de casos se habrá usado para elegir modelo, para validar cada release, para justificar el coste por tarea útil ante finanzas y para responder a una auditoría. Todo lo demás se habrá reescrito dos veces.

Y hay una segunda consecuencia, menos evidente: es también el activo que no puede generarse externamente. Puedes contratar la arquitectura, puedes contratar la evaluación, puedes contratar el despliegue. Los casos que definen qué es una respuesta correcta en tu dominio los tiene una persona de tu organización en la cabeza, y sacarlos de ahí es un trabajo que no se subcontrata. Cuando en un programa nos toca construirlo, nuestro papel es el método y el ritmo; los criterios los pone quien conoce el dominio.

De dónde salen los casos

Tres orígenes, y conviene que cada caso lleve etiquetado el suyo, porque no valen lo mismo.

Tráfico real. Es la base y debería ser la mayoría. Se muestrea de producción, no de la imaginación de nadie. Si el sistema todavía no está en producción, se muestrea del proceso humano que hace hoy esa tarea: los tickets que ya resolvió el equipo de soporte, las facturas que ya procesó administración, las consultas que ya llegaron al buzón.

Incidentes. Son los casos más valiosos que vas a tener, porque ya demostraron que duelen. Cada fallo que llegó a un usuario, cada respuesta que alguien tuvo que corregir a mano, cada escalado. Un incidente que no acaba convertido en caso del golden set es un incidente que puede repetirse sin que nadie se entere — y ese es exactamente el bucle que casi todos dejan abierto.

Hipótesis de riesgo. Lo que todavía no ha pasado pero sería caro: el cliente que pide algo que el sistema no debe conceder, el dato personal que no puede aparecer en la respuesta, la instrucción hostil escondida en uno de los documentos que el sistema recupera. Aquí sí se escriben casos que nunca han ocurrido, y conviene marcarlos como lo que son — hipótesis, no evidencia.

Estratificar por capacidad, no por volumen

El instinto natural es construir el conjunto proporcional al tráfico: si el 70% de las consultas son de estado de pedido, que el 70% de los casos lo sean. Es un error, y es el que hace que un golden set de 300 casos aporte menos información que uno de 80 bien repartidos.

Un conjunto proporcional al tráfico mide sobre todo lo que ya sabes que funciona. Lo que decide si un sistema es desplegable no es su rendimiento en el caso mayoritario, que además suele ser el más fácil: es su comportamiento en las capacidades poco frecuentes y caras de fallar. La estratificación correcta es por capacidad —comprender la intención, recuperar el dato correcto, respetar una restricción de negocio, encadenar dos herramientas, reconocer que no puede resolverlo— con un número mínimo de casos en cada una, aunque una de ellas represente el 2% del tráfico.

La referencia metodológica aquí es anterior a los LLM y sigue siendo la mejor: CheckList, de Ribeiro, Wu, Guestrin y Singh (ACL 2020), que traslada las pruebas de comportamiento del software a los modelos de lenguaje. Su propuesta es una matriz de capacidades por tipos de prueba en lugar de una cifra agregada de exactitud, y sus resultados son el mejor argumento para adoptarla: un equipo responsable de un modelo comercial de análisis de sentimiento —ya sometido a pruebas exhaustivas— encontró fallos nuevos y accionables usándola, y en un segundo estudio los profesionales que trabajaron con CheckList escribieron el doble de pruebas y encontraron casi el triple de fallos que quienes no la usaron. La misma tarea, la misma gente, distinta forma de organizar los casos.

Casos sintéticos: variación sí, fundación no

Preguntar a un modelo por 200 casos de evaluación es tentador y está mal en un sentido concreto: un conjunto generado por un modelo mide, sobre todo, el acuerdo con el modelo que lo generó. Hereda sus puntos ciegos —justo los que necesitas detectar— y suele producir casos limpios, bien redactados y con la ambigüedad quitada, que es lo contrario de lo que hay en producción.

La regla que aplicamos: generación permitida como variación de un caso real ya anclado —reformular la misma consulta de seis maneras, cambiar el idioma, meter faltas de ortografía, alargar el contexto— y prohibida como fundación. Y cada caso generado hereda las condiciones de aceptación del caso del que sale, revisadas por la persona de dominio. Si la variación cambia la respuesta correcta, deja de ser una variación y pasa a ser un caso nuevo.

Cuántos casos: la pregunta que casi siempre se hace mal

«¿Cuántos casos necesitamos?» tiene una respuesta que decepciona a todo el mundo: bastantes menos en total de lo que la gente teme, y bastantes más por capacidad de lo que suele haber. Un punto de partida razonable son 30-50 casos por capacidad evaluable. Un sistema con seis capacidades bien definidas empieza a decir cosas útiles con 200-300 casos, no con 5.000.

Pero el número por sí solo engaña, y la aritmética conviene hacerla una vez. Con 50 casos y una tasa de acierto en torno al 80%, el error estándar de esa proporción ronda los 5,7 puntos; el intervalo de confianza del 95% ocupa unos once puntos a cada lado. Sobre ese conjunto, una mejora de tres puntos entre dos versiones no es una mejora: es ruido con formato de dato. Es aritmética elemental, no un estudio, y basta para descartar la mitad de las comparaciones que circulan en las revisiones de sprint.

Lo interesante es que la salida no es multiplicar casos. Como argumenta Evan Miller en Adding Error Bars to Evals, una evaluación es un experimento y merece el mismo tratamiento que cualquier otro: error estándar, comparación pareada y análisis de potencia antes de ejecutar. Comparar en pareado —los dos sistemas sobre exactamente los mismos casos, midiendo la diferencia caso a caso en lugar de restar dos medias— y repetir cada caso tres o cinco veces para promediar el no determinismo dan mucha más precisión por euro invertido que doblar el tamaño del conjunto. Y el coste marginal de repetir es mucho más bajo que el de etiquetar.

Merece la pena leer a la vez el diagnóstico de Bowman y Dahl en What Will it Take to Fix Benchmarking in Natural Language Understanding? (2021): los frentes en los que la evaluación necesita progresar no son sólo el diseño de las tareas, sino la fiabilidad con la que se anotan y su tamaño. Cinco años después, esa sigue siendo exactamente la lista de deberes de cualquier equipo que monta su golden set.

El etiquetado es el techo de todo lo demás

Aquí está el punto que más veces se salta, y el que más caro sale: tu tasa de error de etiquetado es el límite superior de lo que puedes medir. Si el 8% de tus casos tienen mal la respuesta de referencia, perseguir una mejora de cinco puntos es perseguir tu propio ruido. Y no es un riesgo hipotético.

Northcutt, Athalye y Mueller revisaron en 2021 los conjuntos de test de diez de los datasets más usados en visión, lenguaje y audio, y encontraron al menos un 3,3% de errores de etiqueta de media, con al menos un 6% en el conjunto de validación de ImageNet. Lo relevante no es el porcentaje: es lo que ocurre al corregirlo. En sus análisis, el orden entre modelos se altera —ResNet-18 supera a ResNet-50 cuando el nivel de etiquetas erróneas sube seis puntos—, lo que significa que un conjunto con ruido no sólo mide peor: puede recomendarte el sistema equivocado. Estamos hablando de datasets que llevaban una década siendo el patrón de referencia de la disciplina.

El ejemplo más útil para un equipo de producto es SWE-bench Verified. Cuando quedó claro que el conjunto original contenía enunciados infraespecificados y pruebas unitarias que marcaban como incorrectas soluciones válidas, la respuesta fue reconstruirlo a mano: un subconjunto de 500 instancias filtradas por 93 desarrolladores profesionales, con tres anotadores revisando cada muestra. Es probablemente el esfuerzo de limpieza mejor financiado de la industria. Y aun así, Epoch AI —que lo ejecuta de forma independiente— estima que entre un 5% y un 10% de los casos siguen teniendo problemas. La conclusión no es desalentadora, es calibradora: si el mejor esfuerzo posible se queda ahí, tu conjunto de 200 casos etiquetado en dos tardes no está en el 1%.

El desacuerdo es información, no un fallo de las personas

Cuando dos personas de dominio etiquetan el mismo caso de forma distinta, la reacción habitual es buscar quién se equivocó. Casi siempre es la pregunta equivocada. Lo argumentaron Lora Aroyo y Chris Welty en Truth Is a Lie: Crowd Truth and the Seven Myths of Human Annotation (AI Magazine, 2015): la anotación humana de tareas de interpretación semántica se apoya en un ideal caducado —el de una única verdad correcta— cuando la interpretación es intrínsecamente subjetiva, y medir el desacuerdo a través de varias personas representa mejor el rango de lecturas razonables que forzar un consenso.

Traducido a un golden set de empresa: el desacuerdo entre dos anotadores es un defecto de la condición de aceptación, no de los anotadores. Si dos personas del equipo de siniestros discrepan sobre si una respuesta era aceptable, lo que has encontrado es que el criterio no estaba escrito con suficiente precisión — y eso es exactamente lo que hay que llevar a la rúbrica. Es la señal más barata de todo el proceso: treinta casos, dos personas, media mañana.

El ritual que funciona es simple. Doble etiquetado sobre una muestra del 10-20% de los casos, medida del acuerdo, y una sesión corta donde los desacuerdos se resuelven modificando el criterio, no votando. Los casos que siguen siendo ambiguos después de eso tienen su propio sitio: se marcan como ambiguos y salen de la métrica principal. Un caso sobre el que el negocio no tiene una opinión firme no puede bloquear un despliegue.

Los tres cajones y el presupuesto de miradas

Un golden set que se usa entero para todo se agota en unos meses sin que nadie lo note. La separación mínima son tres cajones con reglas distintas de acceso.

• Desarrollo. Se mira todos los días, se depura contra él, se itera. Se contamina por diseño y no pasa nada: su función es que el equipo trabaje deprisa. Ningún número que salga de aquí sirve para decidir un despliegue.
• Retenido. Se toca en ocasiones contadas y cada consulta se registra. Es el que produce los números de las puertas de calidad.
• Sellado. No se abre hasta la decisión de release, o hasta el cambio de modelo. Es la única medida que no ha influido en ninguna decisión previa de diseño.

La razón por la que el segundo cajón necesita disciplina no es organizativa, es estadística, y está formalizada desde hace una década. Dwork, Feldman, Hardt, Pitassi, Reingold y Roth lo publicaron en Science en 2015: las garantías de validez de un conjunto retenido asumen que el procedimiento de análisis se fijó antes de mirar los datos, mientras que el análisis real es intrínsecamente adaptativo — cada iteración se elige a partir de lo que se vio en la anterior. Su propuesta, el reusable holdout, es una técnica para reutilizarlo muchas veces manteniendo la validez; es decir, un método para gastarlo despacio, no para no gastarlo.

De ahí sale una regla que recomendamos escribir en la cabecera del propio fichero: el conjunto retenido es un recurso consumible, con presupuesto de miradas. Un número explícito de consultas —veinte, treinta— y una fecha de rotación. Cuando se agota, se repone con casos nuevos de producción y el anterior baja al cajón de desarrollo. No es purismo académico: es la diferencia entre un número que bloquea despliegues y un número que el equipo ya ha aprendido a superar sin querer.

Contaminación: la que entra y la que sale

Hay dos direcciones de contaminación y sólo se suele vigilar una.

Hacia dentro: casos que el modelo ya ha visto. Si tomaste casos de un benchmark público, asume que están en el entrenamiento. Sainz y otros lo plantearon como posición en 2023 —la evaluación clásica sobre benchmarks anotados está en problemas, y la contaminación necesita medirse benchmark a benchmark, no en general— y la demostración más limpia la dio el trabajo de GSM1k: 1.000 problemas nuevos construidos para replicar el estilo y la dificultad de GSM8k, con caídas de exactitud de hasta 8 puntos y una relación positiva (r² de Spearman de 0,36) entre la probabilidad de que un modelo generase ejemplos del benchmark original y su pérdida de rendimiento en el nuevo. Varias familias de modelos mostraban sobreajuste sistemático; las de frontera, apenas.

Hacia fuera: casos que salen de tu control. Un golden set pegado en un ticket público, subido a una herramienta de terceros o incluido como ejemplo en un prompt que se envía a un proveedor deja de ser un conjunto limpio. La regla operativa: los casos retenidos y sellados no salen del repositorio, y los que se usan como ejemplos en el prompt se marcan permanentemente como quemados.

Hay un tercer efecto, más sutil, que conviene conocer antes de sacar conclusiones épicas de una diferencia entre conjuntos. Recht, Roelofs, Schmidt y Shankar reconstruyeron en 2019 los conjuntos de test de CIFAR-10 e ImageNet siguiendo el procedimiento original, y la exactitud de todos los modelos cayó: entre 3 y 15 puntos en CIFAR-10, entre 11 y 14 en ImageNet. Su conclusión es la parte interesante: las caídas no venían de sobreajuste por reutilización, sino de que el conjunto nuevo resultó algo más difícil. La lección para un golden set es más incómoda que la del sobreajuste: dos conjuntos construidos con el mismo procedimiento no son intercambiables. Sólo son comparables medidas tomadas sobre el mismo conjunto, y cambiar de conjunto obliga a re-medir el baseline.

Anatomía de un caso

Un caso con entrada y respuesta esperada es un caso a medias. Estos son los campos que hacen que un conjunto siga siendo utilizable dieciocho meses después, cuando quien lo escribió ya no está en el proyecto.

El golden set es un proceso, no un fichero

Un conjunto construido en un sprint y congelado se degrada por tres vías a la vez: el negocio cambia sus reglas, el sistema aprende a superar precisamente esos casos, y los casos fáciles dejan de aportar información. El mantenimiento no es opcional; es la mitad del trabajo.

Poder discriminante: el caso que ya no mide nada

Un caso que todas las versiones aciertan siempre no distingue entre ellas. Ocupa presupuesto de ejecución y sube la media, pero no ayuda a decidir. Es un concepto viejo, prestado de la psicometría de tests, donde cada ítem se caracteriza por su dificultad —qué proporción lo acierta— y su discriminación —cuánto separa a los que rinden bien de los que rinden mal—. Un ítem que todo el mundo acierta tiene discriminación cero, y en un examen bien construido se retira.

En un golden set eso se traduce en una revisión periódica muy barata: por cada caso, mirar cuántas de las últimas versiones lo acertaron. Los que llevan seis meses en verde para todo el mundo pasan a un conjunto de humo —se siguen ejecutando, porque una regresión ahí sería grave, pero salen de la métrica principal—. Y el presupuesto liberado se invierte donde hay señal: los casos en los que las versiones discrepan, que son los que están decidiendo de verdad.

Reposición: el bucle que cierra el ciclo

La regla que más rápido cambia la calidad de un conjunto es también la más aburrida: todo incidente entra como caso en menos de cinco días laborables, con su condición de aceptación escrita por quien lo sufrió. No «cuando haya tiempo», no «en el próximo sprint de calidad». Es la tarea que convierte la observabilidad en aprendizaje, y sin ella el ciclo de LLMOps queda abierto: se detectan fallos, se arreglan a mano y nada impide que vuelvan.

Cuarenta y cinco minutos a la semana, dos personas, tres puntos en el orden del día: qué falló en producción, qué caso nuevo entra, qué caso caducó. En un trimestre eso son entre treinta y cuarenta casos nuevos, todos anclados en fallos reales. Ningún ejercicio de generación sintética produce material de esa calidad.

Validez: que el caso mida lo que dice medir

Queda una comprobación que casi nadie hace y que el trabajo sobre buenas prácticas en benchmarks agénticos —Zhu y otros, NeurIPS 2025— sistematiza en dos preguntas. Validez de tarea: ¿es el caso resoluble con la información y las herramientas que el sistema tiene? Un caso imposible no mide capacidad, mide frustración, y cuenta como fallo eterno que ensucia la media. Validez de resultado: ¿la comprobación acepta exactamente las soluciones correctas, ni más ni menos? Una verificación demasiado estricta suspende soluciones válidas; una demasiado laxa aprueba respuestas vacías.

Las dos se comprueban con el mismo gesto barato: resolver a mano diez casos tomados al azar y pasar esas soluciones humanas por la verificación automática. Si alguna suspende, el problema está en el caso. Es media hora, y es la media hora que evita descubrir seis meses después que el 12% de tu conjunto medía otra cosa.

Cinco síntomas de un golden set que ya no sirve

Ninguno se anuncia. Todos se reconocen desde fuera en una revisión de veinte minutos.

La tasa de acierto lleva meses por encima del 95%. No es que el sistema sea excelente: es que los casos difíciles nunca entraron o ya se depuraron uno a uno contra ellos. Un conjunto sano vive incómodo, entre el 70% y el 90%.

Nadie sabe decir de dónde salió un caso concreto. Sin campo de origen, no puedes distinguir el caso que costó un cliente de la hipótesis que alguien escribió una tarde. Y los dos pesan igual en la media.

El fichero no ha cambiado en un trimestre mientras el producto sacaba ocho releases. La evaluación está midiendo un sistema que ya no existe.

Los casos los escribió quien construye el sistema, sin una persona de dominio delante. Sin mala fe, los criterios acaban pareciéndose a lo que la solución ya hace bien.

Nadie ha mirado nunca cuánto se equivocan las etiquetas. Es el más silencioso de los cinco y el que invalida todo lo demás: sin medir el ruido propio, cualquier mejora pequeña que se celebre puede ser un artefacto del etiquetado.

Los primeros 40 casos

Si vas a empezar de cero, esto es lo que produce más señal por hora invertida. No hace falta un proyecto: hace falta una semana con las personas correctas en la sala.

1. Escribe las capacidades antes que los casos. Entre cinco y ocho, en lenguaje de negocio: «entender qué pide el cliente», «encontrar el dato correcto en el contrato», «no prometer nada fuera de política», «reconocer cuándo tiene que escalar a un humano». Esta lista es la que va a ordenar el conjunto entero, y es una conversación de negocio, no técnica.

2. Saca cinco casos reales por capacidad. De tráfico o del proceso humano actual. Reales, con su suciedad: consultas mal escritas, contexto incompleto, dos preguntas en una. Cuarenta casos.

3. Que las condiciones de aceptación las escriba quien conoce el dominio, respondiendo a dos preguntas por caso: qué tiene que aparecer sí o sí, y qué no puede aparecer nunca. Esas respuestas son, además, la materia prima de la rúbrica.

4. Dobla el etiquetado de diez casos con una segunda persona y cuenta los desacuerdos. Ese número es tu techo, y conviene conocerlo el primer día y no el sexto mes.

5. Reparte en cajones y ponle dueño. Veinticinco a desarrollo, quince a retenido. Un nombre en la cabecera del fichero, una fecha, un número de versión. Y la cita semanal de cuarenta y cinco minutos en el calendario.

Al final de esa semana no tendrás un sistema mejor. Tendrás lo que hace falta para que la rúbrica y el baseline de la pieza anterior se puedan construir sobre algo, y para que la puerta de calidad del ciclo de LLMOps tenga con qué bloquear. Cuarenta casos bien hechos ya distinguen un release bueno de uno malo. Cinco mil casos sin condición de aceptación no distinguen nada.

Lo que se compra y lo que se construye

Hay una asimetría que conviene tener presente cuando se presupuesta un proyecto de IA. La arquitectura se puede comprar. El despliegue se puede comprar. La observabilidad se puede comprar, y hay producto bueno. Los casos que definen qué significa «correcto» en tu negocio no están a la venta en ningún sitio, y son justamente los que deciden si todo lo anterior sirve para algo.

Es la misma lógica que aplicamos al código con Spec-Driven Development: el criterio se escribe antes que el artefacto, y el criterio es el activo. En los programas onext AI-Accelerated Development el golden set no es un entregable de la última fase, es de lo primero que montamos con el equipo — porque sin él no hay forma de demostrar que el resto del programa funcionó. Los resultados que firmamos con clientes en 2026 —×7 velocidad de entrega, 0 sprints perdidos, −50% time-to-production— se miden contra casos que el cliente escribió, no contra una promesa nuestra.

Si tu equipo ya tiene trazas y monitorización pero no tiene el fichero de casos, tienes el termómetro sin haber decidido qué es fiebre. Y esa es una conversación de una semana, no de un trimestre.

Preguntas frecuentes

¿Qué es un golden set en un proyecto de IA?

Es la colección versionada de casos con los que tu equipo decide si un sistema de IA funciona: cada caso lleva su entrada, el estado inicial que necesita, sus condiciones de aceptación, la capacidad que ejercita, de dónde salió y quién lo mantiene. No es un benchmark público ni una carpeta de logs ni los ejemplos que viven dentro del prompt. Es la definición operativa de «funciona» para tu dominio, escrita antes de mirar la salida del sistema y mantenida como código.

¿Cuántos casos necesita un golden set?

Menos de los que la gente imagina en total y más de los que suele haber por capacidad. Un buen punto de partida son 30-50 casos por capacidad evaluable, no varios miles indiferenciados. La razón es estadística: con 50 casos y una tasa de acierto cercana al 80%, el error estándar ronda los 5-6 puntos, así que una mejora de 3 puntos es indistinguible del ruido. Y la forma barata de ganar precisión no es multiplicar casos, sino comparar en pareado sobre los mismos casos y repetir cada ejecución varias veces.

¿De dónde deberían salir los casos del golden set?

De tres orígenes, y conviene etiquetar cuál es cuál: tráfico real (la base), incidentes de producción (los casos más valiosos, porque ya demostraron que duelen) e hipótesis de riesgo (lo que todavía no ha pasado pero sería caro). Los casos generados por un modelo sirven como variaciones de un caso real ya anclado, nunca como fundación: un conjunto sintético mide sobre todo el acuerdo con el modelo que lo generó.

¿Por qué no se puede reutilizar siempre el mismo conjunto retenido?

Porque cada decisión que tomas mirándolo lo va gastando. El trabajo de Dwork y otros en Science sobre análisis adaptativo de datos formaliza el problema: las garantías estadísticas de un conjunto retenido asumen que el análisis se fijó antes de mirarlo, y en la práctica cada iteración se elige a partir de lo que se vio en la anterior. Su respuesta —el reusable holdout— es una técnica para gastarlo despacio, no para no gastarlo. En la práctica: presupuesto explícito de consultas y rotación programada.

¿Cuánto error de etiquetado es normal y por qué importa?

Más del que se supone. Northcutt, Athalye y Mueller encontraron al menos un 3,3% de errores de etiqueta de media en los conjuntos de test de diez datasets de referencia, y al menos un 6% en el conjunto de validación de ImageNet; corregirlos llega a cambiar el orden entre modelos. SWE-bench Verified se filtró a mano con 93 desarrolladores y tres anotadores por muestra, y Epoch AI aún estima entre un 5% y un 10% de casos con problemas. Importa porque tu tasa de error de etiquetado es el techo: no puedes detectar de forma fiable mejoras más pequeñas que tu propio ruido.

¿Qué hago con los casos en los que dos personas no se ponen de acuerdo?

Tratarlos como la señal más barata que vas a conseguir, no como un problema de calidad de las personas. Aroyo y Welty lo argumentaron en 2015 con la idea de crowd truth: la interpretación humana es subjetiva y el desacuerdo mide la ambigüedad real de la tarea. Si dos personas de dominio discrepan en un caso, casi siempre significa que la condición de aceptación está mal escrita, no que una se equivoque. El desacuerdo se lleva a la rúbrica y se resuelve ahí.

Fuentes citadas

• Ribeiro, Wu, Guestrin, Singh — Beyond Accuracy: Behavioral Testing of NLP Models with CheckList (ACL 2020; matriz de capacidades, el doble de pruebas y casi el triple de fallos)
• Northcutt, Athalye, Mueller — Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks (≥3,3% de media, ≥6% en ImageNet, cambios de orden entre modelos)
• Aroyo, L. y Welty, C. — Truth Is a Lie: Crowd Truth and the Seven Myths of Human Annotation (AI Magazine 36(1), 2015)
• Dwork, Feldman, Hardt, Pitassi, Reingold, Roth — The reusable holdout: Preserving validity in adaptive data analysis (Science 349, 2015; versión extendida en abierto)
• Recht, Roelofs, Schmidt, Shankar — Do ImageNet Classifiers Generalize to ImageNet? (caídas de 11-14 puntos al reconstruir el conjunto de test)
• Zhang y otros (Scale AI) — A Careful Examination of Large Language Model Performance on Grade School Arithmetic (GSM1k; caídas de hasta 8 puntos, r² de Spearman 0,36)
• Sainz, Campos, García-Ferrero, Etxaniz, Lopez de Lacalle, Agirre — NLP Evaluation in trouble: On the Need to Measure LLM Data Contamination for each Benchmark (2023)
• Bowman, S. R. y Dahl, G. E. — What Will it Take to Fix Benchmarking in Natural Language Understanding? (2021; tamaño y fiabilidad de la anotación)
• Miller, E. — Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations (comparación pareada y análisis de potencia)
• Zhu y otros — Establishing Best Practices for Building Rigorous Agentic Benchmarks (validez de tarea y validez de resultado, NeurIPS 2025)
• OpenAI — Introducing SWE-bench Verified y la ficha del benchmark en Epoch AI (500 instancias, 93 desarrolladores, 5-10% de error residual estimado)