El golden set: com es construeix el conjunt de casos que decideix si la teva IA funciona

«Ensenyeu-me el vostre golden set.» És la pregunta que ordena una conversa sobre IA en producció més ràpid que cap altra, perquè les respostes es reparteixen sempre en les mateixes tres. La primera: no en tenim. La segona, la més comuna: sí, hi ha un full amb exemples —i el que ensenyen són els exemples que viuen dins del prompt—. La tercera, la rara: sí, 180 casos, versionats al repositori, amb propietari i amb data d'última revisió.

Les tres primeres setmanes de feina amb un equip s'assemblen molt segons quina de les tres sigui. I no és una qüestió de maduresa tècnica: hem vist equips amb traces distribuïdes impecables, canary automatitzat i un backend d'observabilitat car que, quan els preguntes contra quins casos decideixen si la release de demà és millor que la d'avui, no tenen el fitxer.

A l'article sobre LLMOps descrivim el cicle complet d'un sistema LLM en producció, i a el de la rúbrica i el baseline desmuntem què significa exactament «funciona millor». Tots dos donen per suposat el mateix objecte: un conjunt de casos etiquetats d'on surt tota la resta. Aquest article va sobre aquest objecte — d'on surten els casos, quants en calen, qui els etiqueta, com es protegeix de contaminar-se i per què, si el mires massa, deixa de servir.

Què és un golden set, i les quatre coses que se li confonen

Un golden set és una col·lecció versionada de casos amb condicions d'acceptació escrites abans de mirar la sortida del sistema. Cada cas porta la seva entrada, l'estat inicial que necessita, què s'ha de complir per considerar-lo resolt, quina capacitat exercita, d'on va sortir i qui en respon. Viu al repositori, es revisa en pull request i canvia amb número de versió. És, literalment, la definició operativa de «funciona» per al teu domini.

Gairebé tots els problemes que hem vist en avaluació comencen per confondre'l amb una altra cosa que se li assembla.

Per què és l'actiu de vida més llarga de tot el sistema

Hi ha una pregunta que col·loca el golden set al seu lloc dins de l'arquitectura: si demà canvies de proveïdor de model, què t'emportes?

Els prompts es reescriuen, perquè cada família de models respon diferent a les mateixes instruccions. L'estratègia de recuperació s'ajusta. Els llindars es recalibren. El framework d'orquestració es pot substituir sencer en un trimestre. Fins i tot la rúbrica es retoca, perquè apareixen modes de fallada nous. L'única cosa que creua intacta d'un costat a l'altre és el conjunt de casos: això és coneixement del teu negoci, no del proveïdor.

Això té una conseqüència pràctica en com es pressuposta. El golden set se sol tractar com una tasca de preparació —una cosa que es fa de pressa per poder començar a mesurar— quan en realitat és la inversió amb millor amortització del projecte. En els tres o quatre anys que un sistema d'IA viu en producció, el conjunt de casos s'haurà fet servir per triar model, per validar cada release, per justificar el cost per tasca útil davant de finances i per respondre a una auditoria. Tota la resta s'haurà reescrit dues vegades.

I hi ha una segona conseqüència, menys evident: és també l'actiu que no es pot generar externament. Pots contractar l'arquitectura, pots contractar l'avaluació, pots contractar el desplegament. Els casos que defineixen què és una resposta correcta al teu domini els té una persona de la teva organització al cap, i treure'ls d'allà és una feina que no se subcontracta. Quan en un programa ens toca construir-lo, el nostre paper és el mètode i el ritme; els criteris els posa qui coneix el domini.

D'on surten els casos

Tres orígens, i convé que cada cas porti etiquetat el seu, perquè no valen el mateix.

Trànsit real. És la base i hauria de ser la majoria. Es mostreja de producció, no de la imaginació de ningú. Si el sistema encara no és en producció, es mostreja del procés humà que fa avui aquesta tasca: els tiquets que ja va resoldre l'equip de suport, les factures que ja va processar administració, les consultes que ja van arribar a la bústia.

Incidents. Són els casos més valuosos que tindràs, perquè ja van demostrar que fan mal. Cada fallada que va arribar a un usuari, cada resposta que algú va haver de corregir a mà, cada escalada. Un incident que no acaba convertit en cas del golden set és un incident que pot repetir-se sense que ningú se n'assabenti — i això és exactament el bucle que gairebé tothom deixa obert.

Hipòtesis de risc. El que encara no ha passat però seria car: el client que demana una cosa que el sistema no ha de concedir, la dada personal que no pot aparèixer a la resposta, la instrucció hostil amagada en un dels documents que el sistema recupera. Aquí sí que s'escriuen casos que mai no han ocorregut, i convé marcar-los com el que són — hipòtesis, no evidència. Aquest darrer tipus de cas té a més la seva pròpia disciplina, perquè el que decideix el dany no és el text sinó el permís que l'eina tenia obert.

Estratificar per capacitat, no per volum

L'instint natural és construir el conjunt proporcional al trànsit: si el 70% de les consultes són d'estat de comanda, que el 70% dels casos ho siguin. És un error, i és el que fa que un golden set de 300 casos aporti menys informació que un de 80 ben repartits.

Un conjunt proporcional al trànsit mesura sobretot el que ja saps que funciona. El que decideix si un sistema és desplegable no és el seu rendiment en el cas majoritari, que a més sol ser el més fàcil: és el seu comportament en les capacitats poc freqüents i cares de fallar. L'estratificació correcta és per capacitat —comprendre la intenció, recuperar la dada correcta, respectar una restricció de negoci, encadenar dues eines, reconèixer que no ho pot resoldre— amb un nombre mínim de casos a cadascuna, encara que una representi el 2% del trànsit.

La referència metodològica aquí és anterior als LLM i continua sent la millor: CheckList, de Ribeiro, Wu, Guestrin i Singh (ACL 2020), que trasllada les proves de comportament del programari als models de llenguatge. La seva proposta és una matriu de capacitats per tipus de prova en lloc d'una xifra agregada d'exactitud, i els seus resultats són el millor argument per adoptar-la: un equip responsable d'un model comercial d'anàlisi de sentiment —ja sotmès a proves exhaustives— hi va trobar fallades noves i accionables fent-la servir, i en un segon estudi els professionals que van treballar amb CheckList van escriure el doble de proves i van trobar gairebé el triple de fallades que els qui no la van fer servir. La mateixa tasca, la mateixa gent, diferent manera d'organitzar els casos.

Casos sintètics: variació sí, fonament no

Demanar a un model 200 casos d'avaluació és temptador i està malament en un sentit concret: un conjunt generat per un model mesura, sobretot, l'acord amb el model que el va generar. Hereta els seus punts cecs —justament els que necessites detectar— i sol produir casos nets, ben redactats i amb l'ambigüitat treta, que és el contrari del que hi ha en producció.

La regla que apliquem: generació permesa com a variació d'un cas real ja ancorat —reformular la mateixa consulta de sis maneres, canviar l'idioma, ficar-hi faltes d'ortografia, allargar el context— i prohibida com a fonament. I cada cas generat hereta les condicions d'acceptació del cas d'on surt, revisades per la persona de domini. Si la variació canvia la resposta correcta, deixa de ser una variació i passa a ser un cas nou.

Quants casos: la pregunta que gairebé sempre es fa malament

«Quants casos necessitem?» té una resposta que decep tothom: bastants menys en total del que la gent tem, i bastants més per capacitat del que sol haver-hi. Un punt de partida raonable són 30-50 casos per capacitat avaluable. Un sistema amb sis capacitats ben definides comença a dir coses útils amb 200-300 casos, no amb 5.000.

Però el número per si sol enganya, i l'aritmètica convé fer-la un cop. Amb 50 casos i una taxa d'encert al voltant del 80%, l'error estàndard d'aquesta proporció ronda els 5,7 punts; l'interval de confiança del 95% ocupa uns onze punts a cada costat. Sobre aquest conjunt, una millora de tres punts entre dues versions no és una millora: és soroll amb format de dada. És aritmètica elemental, no un estudi, i n'hi ha prou per descartar la meitat de les comparacions que circulen a les revisions de sprint.

L'interessant és que la sortida no és multiplicar casos. Com argumenta Evan Miller a Adding Error Bars to Evals, una avaluació és un experiment i mereix el mateix tracte que qualsevol altre: error estàndard, comparació aparellada i anàlisi de potència abans d'executar. Comparar en aparellat —els dos sistemes sobre exactament els mateixos casos, mesurant la diferència cas a cas en lloc de restar dues mitjanes— i repetir cada cas tres o cinc vegades per fer la mitjana del no determinisme donen molta més precisió per euro invertit que doblar la mida del conjunt. I el cost marginal de repetir és molt més baix que el d'etiquetar.

Val la pena llegir alhora el diagnòstic de Bowman i Dahl a What Will it Take to Fix Benchmarking in Natural Language Understanding? (2021): els fronts en què l'avaluació necessita progressar no són només el disseny de les tasques, sinó la fiabilitat amb què s'anoten i la seva mida. Cinc anys després, aquesta continua sent exactament la llista de deures de qualsevol equip que munta el seu golden set.

L'etiquetatge és el sostre de tota la resta

Aquí hi ha el punt que més vegades se salta, i el que surt més car: la teva taxa d'error d'etiquetatge és el límit superior del que pots mesurar. Si el 8% dels teus casos tenen malament la resposta de referència, perseguir una millora de cinc punts és perseguir el teu propi soroll. I no és un risc hipotètic.

Northcutt, Athalye i Mueller van revisar el 2021 els conjunts de test de deu dels datasets més utilitzats en visió, llenguatge i àudio, i van trobar almenys un 3,3% d'errors d'etiqueta de mitjana, amb almenys un 6% al conjunt de validació d'ImageNet. El rellevant no és el percentatge: és el que passa en corregir-lo. A les seves anàlisis, l'ordre entre models s'altera —ResNet-18 supera ResNet-50 quan el nivell d'etiquetes errònies puja sis punts—, la qual cosa significa que un conjunt amb soroll no només mesura pitjor: pot recomanar-te el sistema equivocat. Parlem de datasets que portaven una dècada sent el patró de referència de la disciplina.

L'exemple més útil per a un equip de producte és SWE-bench Verified. Quan va quedar clar que el conjunt original contenia enunciats infraespecificats i proves unitàries que marcaven com a incorrectes solucions vàlides, la resposta va ser reconstruir-lo a mà: un subconjunt de 500 instàncies filtrades per 93 desenvolupadors professionals, amb tres anotadors revisant cada mostra. És probablement l'esforç de neteja més ben finançat de la indústria. I tot i així, Epoch AI —que l'executa de manera independent— estima que entre un 5% i un 10% dels casos continuen tenint problemes. La conclusió no és descoratjadora, és calibradora: si el millor esforç possible es queda aquí, el teu conjunt de 200 casos etiquetat en dues tardes no és a l'1%.

El desacord és informació, no una fallada de les persones

Quan dues persones de domini etiqueten el mateix cas de manera diferent, la reacció habitual és buscar qui s'ha equivocat. Gairebé sempre és la pregunta equivocada. Ho van argumentar Lora Aroyo i Chris Welty a Truth Is a Lie: Crowd Truth and the Seven Myths of Human Annotation (AI Magazine, 2015): l'anotació humana de tasques d'interpretació semàntica es recolza en un ideal caducat —el d'una única veritat correcta— quan la interpretació és intrínsecament subjectiva, i mesurar el desacord a través de diverses persones representa millor el ventall de lectures raonables que forçar un consens.

Traduït a un golden set d'empresa: el desacord entre dos anotadors és un defecte de la condició d'acceptació, no dels anotadors. Si dues persones de l'equip de sinistres discrepen sobre si una resposta era acceptable, el que has trobat és que el criteri no estava escrit amb prou precisió — i això és exactament el que cal portar a la rúbrica. És el senyal més barat de tot el procés: trenta casos, dues persones, mig matí.

El ritual que funciona és simple. Doble etiquetatge sobre una mostra del 10-20% dels casos, mesura de l'acord, i una sessió curta on els desacords es resolen modificant el criteri, no votant. Els casos que continuen sent ambigus després d'això tenen el seu propi lloc: es marquen com a ambigus i surten de la mètrica principal. Un cas sobre el qual el negoci no té una opinió ferma no pot bloquejar un desplegament.

Els tres calaixos i el pressupost de mirades

Un golden set que es fa servir sencer per a tot s'esgota en uns mesos sense que ningú se n'adoni. La separació mínima són tres calaixos amb regles diferents d'accés.

• Desenvolupament. Es mira cada dia, s'hi depura, s'itera. Es contamina per disseny i no passa res: la seva funció és que l'equip treballi de pressa. Cap número que surti d'aquí no serveix per decidir un desplegament.
• Retingut. Es toca en ocasions comptades i cada consulta es registra. És el que produeix els números de les portes de qualitat.
• Segellat. No s'obre fins a la decisió de release, o fins al canvi de model. És l'única mesura que no ha influït en cap decisió prèvia de disseny.

La raó per la qual el segon calaix necessita disciplina no és organitzativa, és estadística, i està formalitzada des de fa una dècada. Dwork, Feldman, Hardt, Pitassi, Reingold i Roth ho van publicar a Science el 2015: les garanties de validesa d'un conjunt retingut assumeixen que el procediment d'anàlisi es va fixar abans de mirar les dades, mentre que l'anàlisi real és intrínsecament adaptativa — cada iteració es tria a partir del que es va veure a l'anterior. La seva proposta, el reusable holdout, és una tècnica per reutilitzar-lo moltes vegades mantenint la validesa; és a dir, un mètode per gastar-lo a poc a poc, no per no gastar-lo.

D'aquí en surt una regla que recomanem escriure a la capçalera del mateix fitxer: el conjunt retingut és un recurs consumible, amb pressupost de mirades. Un nombre explícit de consultes —vint, trenta— i una data de rotació. Quan s'esgota, es reposa amb casos nous de producció i l'anterior baixa al calaix de desenvolupament. No és purisme acadèmic: és la diferència entre un número que bloqueja desplegaments i un número que l'equip ja ha après a superar sense voler.

Contaminació: la que entra i la que surt

Hi ha dues direccions de contaminació i només se sol vigilar una.

Cap endins: casos que el model ja ha vist. Si vas agafar casos d'un benchmark públic, assumeix que són a l'entrenament. Sainz i altres ho van plantejar com a posició el 2023 —l'avaluació clàssica sobre benchmarks anotats és en problemes, i la contaminació necessita mesurar-se benchmark a benchmark, no en general— i la demostració més neta la va donar el treball de GSM1k: 1.000 problemes nous construïts per replicar l'estil i la dificultat de GSM8k, amb caigudes d'exactitud de fins a 8 punts i una relació positiva (r² d'Spearman de 0,36) entre la probabilitat que un model generés exemples del benchmark original i la seva pèrdua de rendiment en el nou. Diverses famílies de models mostraven sobreajust sistemàtic; les de frontera, tot just.

Cap enfora: casos que surten del teu control. Un golden set enganxat en un tiquet públic, pujat a una eina de tercers o inclòs com a exemple en un prompt que s'envia a un proveïdor deixa de ser un conjunt net. La regla operativa: els casos retinguts i segellats no surten del repositori, i els que es fan servir com a exemples al prompt es marquen permanentment com a cremats.

Hi ha un tercer efecte, més subtil, que convé conèixer abans de treure conclusions èpiques d'una diferència entre conjunts. Recht, Roelofs, Schmidt i Shankar van reconstruir el 2019 els conjunts de test de CIFAR-10 i ImageNet seguint el procediment original, i l'exactitud de tots els models va caure: entre 3 i 15 punts a CIFAR-10, entre 11 i 14 a ImageNet. La seva conclusió és la part interessant: les caigudes no venien de sobreajust per reutilització, sinó que el conjunt nou va resultar una mica més difícil. La lliçó per a un golden set és més incòmoda que la del sobreajust: dos conjunts construïts amb el mateix procediment no són intercanviables. Només són comparables mesures preses sobre el mateix conjunt, i canviar de conjunt obliga a tornar a mesurar el baseline.

Anatomia d'un cas

Un cas amb entrada i resposta esperada és un cas a mitges. Aquests són els camps que fan que un conjunt continuï sent utilitzable divuit mesos després, quan qui el va escriure ja no és al projecte.

El golden set és un procés, no un fitxer

Un conjunt construït en un sprint i congelat es degrada per tres vies alhora: el negoci canvia les seves regles, el sistema aprèn a superar precisament aquests casos, i els casos fàcils deixen d'aportar informació. El manteniment no és opcional; és la meitat de la feina.

Poder discriminant: el cas que ja no mesura res

Un cas que totes les versions encerten sempre no distingeix entre elles. Ocupa pressupost d'execució i puja la mitjana, però no ajuda a decidir. És un concepte vell, manllevat de la psicometria de tests, on cada ítem es caracteritza per la seva dificultat —quina proporció l'encerta— i la seva discriminació —quant separa els qui rendeixen bé dels qui rendeixen malament—. Un ítem que tothom encerta té discriminació zero, i en un examen ben construït es retira.

En un golden set això es tradueix en una revisió periòdica molt barata: per cada cas, mirar quantes de les últimes versions el van encertar. Els que porten sis mesos en verd per a tothom passen a un conjunt de fum —es continuen executant, perquè una regressió allà seria greu, però surten de la mètrica principal—. I el pressupost alliberat s'inverteix on hi ha senyal: els casos en què les versions discrepen, que són els que estan decidint de debò.

Reposició: el bucle que tanca el cicle

La regla que més ràpid canvia la qualitat d'un conjunt és també la més avorrida: tot incident entra com a cas en menys de cinc dies laborables, amb la seva condició d'acceptació escrita per qui el va patir. No «quan hi hagi temps», no «al pròxim sprint de qualitat». És la tasca que converteix l'observabilitat en aprenentatge, i sense ella el cicle d'LLMOps queda obert: es detecten fallades, s'arreglen a mà i res no impedeix que tornin.

Quaranta-cinc minuts a la setmana, dues persones, tres punts a l'ordre del dia: què va fallar en producció, quin cas nou entra, quin cas ha caducat. En un trimestre això són entre trenta i quaranta casos nous, tots ancorats en fallades reals. Cap exercici de generació sintètica no produeix material d'aquesta qualitat.

Validesa: que el cas mesuri el que diu mesurar

Queda una comprovació que gairebé ningú no fa i que el treball sobre bones pràctiques en benchmarks agèntics —Zhu i altres, NeurIPS 2025— sistematitza en dues preguntes. Validesa de tasca: és el cas resoluble amb la informació i les eines que el sistema té? Un cas impossible no mesura capacitat, mesura frustració, i compta com a fallada eterna que embruta la mitjana. Validesa de resultat: la comprovació accepta exactament les solucions correctes, ni més ni menys? Una verificació massa estricta suspèn solucions vàlides; una massa laxa aprova respostes buides.

Totes dues es comproven amb el mateix gest barat: resoldre a mà deu casos presos a l'atzar i passar aquestes solucions humanes per la verificació automàtica. Si alguna suspèn, el problema és al cas. És mitja hora, i és la mitja hora que evita descobrir sis mesos després que el 12% del teu conjunt mesurava una altra cosa.

Cinc símptomes d'un golden set que ja no serveix

Cap no s'anuncia. Tots es reconeixen des de fora en una revisió de vint minuts.

La taxa d'encert porta mesos per sobre del 95%. No és que el sistema sigui excel·lent: és que els casos difícils mai no van entrar o ja s'hi va depurar un a un. Un conjunt sa viu incòmode, entre el 70% i el 90%.

Ningú no sap dir d'on va sortir un cas concret. Sense camp d'origen, no pots distingir el cas que va costar un client de la hipòtesi que algú va escriure una tarda. I tots dos pesen igual a la mitjana.

El fitxer no ha canviat en un trimestre mentre el producte treia vuit releases. L'avaluació està mesurant un sistema que ja no existeix.

Els casos els va escriure qui construeix el sistema, sense una persona de domini al davant. Sense mala fe, els criteris acaben assemblant-se al que la solució ja fa bé.

Ningú no ha mirat mai quant s'equivoquen les etiquetes. És el més silenciós dels cinc i el que invalida tota la resta: sense mesurar el soroll propi, qualsevol millora petita que es celebri pot ser un artefacte de l'etiquetatge.

Els primers 40 casos

Si comences de zero, això és el que produeix més senyal per hora invertida. No cal un projecte: cal una setmana amb les persones correctes a la sala.

1. Escriu les capacitats abans que els casos. Entre cinc i vuit, en llenguatge de negoci: «entendre què demana el client», «trobar la dada correcta al contracte», «no prometre res fora de política», «reconèixer quan ha d'escalar a un humà». Aquesta llista és la que ordenarà el conjunt sencer, i és una conversa de negoci, no tècnica.

2. Treu cinc casos reals per capacitat. De trànsit o del procés humà actual. Reals, amb la seva brutícia: consultes mal escrites, context incomplet, dues preguntes en una. Quaranta casos.

3. Que les condicions d'acceptació les escrigui qui coneix el domini, responent a dues preguntes per cas: què ha d'aparèixer sí o sí, i què no pot aparèixer mai. Aquestes respostes són, a més, la matèria primera de la rúbrica.

4. Dobla l'etiquetatge de deu casos amb una segona persona i compta els desacords. Aquest número és el teu sostre, i convé conèixer-lo el primer dia i no el sisè mes.

5. Reparteix en calaixos i posa-hi propietari. Vint-i-cinc a desenvolupament, quinze a retingut. Un nom a la capçalera del fitxer, una data, un número de versió. I la cita setmanal de quaranta-cinc minuts al calendari.

Al final d'aquesta setmana no tindràs un sistema millor. Tindràs el que cal perquè la rúbrica i el baseline de la peça anterior es puguin construir sobre alguna cosa, i perquè la porta de qualitat del cicle d'LLMOps tingui amb què bloquejar. Quaranta casos ben fets ja distingeixen una release bona d'una de dolenta. Cinc mil casos sense condició d'acceptació no distingeixen res.

Què es compra i què es construeix

Hi ha una asimetria que convé tenir present quan es pressuposta un projecte d'IA. L'arquitectura es pot comprar. El desplegament es pot comprar. L'observabilitat es pot comprar, i hi ha producte bo. Els casos que defineixen què significa «correcte» al teu negoci no estan a la venda enlloc, i són justament els que decideixen si tot l'anterior serveix d'alguna cosa.

És la mateixa lògica que apliquem al codi amb Spec-Driven Development: el criteri s'escriu abans que l'artefacte, i el criteri és l'actiu. Als programes onext AI-Accelerated Development el golden set no és un lliurable de l'última fase, és de les primeres coses que muntem amb l'equip — perquè sense ell no hi ha manera de demostrar que la resta del programa va funcionar. Els resultats que signem amb clients el 2026 —×7 velocitat de lliurament, 0 sprints perduts, −50% time-to-production— es mesuren contra casos que el client va escriure, no contra una promesa nostra.

Si el teu equip ja té traces i monitoratge però no té el fitxer de casos, tens el termòmetre sense haver decidit què és febre. I aquesta és una conversa d'una setmana, no d'un trimestre.

Preguntes freqüents

Què és un golden set en un projecte d'IA?

És la col·lecció versionada de casos amb què el teu equip decideix si un sistema d'IA funciona: cada cas porta la seva entrada, l'estat inicial que necessita, les seves condicions d'acceptació, la capacitat que exercita, d'on va sortir i qui el manté. No és un benchmark públic ni una carpeta de logs ni els exemples que viuen dins del prompt. És la definició operativa de «funciona» per al teu domini, escrita abans de mirar la sortida del sistema i mantinguda com a codi.

Quants casos necessita un golden set?

Menys dels que la gent imagina en total i més dels que sol haver-hi per capacitat. Un bon punt de partida són 30-50 casos per capacitat avaluable, no diversos milers indiferenciats. La raó és estadística: amb 50 casos i una taxa d'encert propera al 80%, l'error estàndard ronda els 5-6 punts, així que una millora de 3 punts és indistingible del soroll. I la manera barata de guanyar precisió no és multiplicar casos, sinó comparar en aparellat sobre els mateixos casos i repetir cada execució diverses vegades.

D'on haurien de sortir els casos del golden set?

De tres orígens, i convé etiquetar quin és quin: trànsit real (la base), incidents de producció (els casos més valuosos, perquè ja van demostrar que fan mal) i hipòtesis de risc (el que encara no ha passat però seria car). Els casos generats per un model serveixen com a variacions d'un cas real ja ancorat, mai com a fonament: un conjunt sintètic mesura sobretot l'acord amb el model que el va generar.

Per què no es pot reutilitzar sempre el mateix conjunt retingut?

Perquè cada decisió que prens mirant-lo el va gastant. El treball de Dwork i altres a Science sobre anàlisi adaptativa de dades formalitza el problema: les garanties estadístiques d'un conjunt retingut assumeixen que l'anàlisi es va fixar abans de mirar-lo, i a la pràctica cada iteració es tria a partir del que es va veure a l'anterior. La seva resposta —el reusable holdout— és una tècnica per gastar-lo a poc a poc, no per no gastar-lo. A la pràctica: pressupost explícit de consultes i rotació programada.

Quant error d'etiquetatge és normal i per què importa?

Més del que se suposa. Northcutt, Athalye i Mueller van trobar almenys un 3,3% d'errors d'etiqueta de mitjana als conjunts de test de deu datasets de referència, i almenys un 6% al conjunt de validació d'ImageNet; corregir-los arriba a canviar l'ordre entre models. SWE-bench Verified es va filtrar a mà amb 93 desenvolupadors i tres anotadors per mostra, i Epoch AI encara estima entre un 5% i un 10% de casos amb problemes. Importa perquè la teva taxa d'error d'etiquetatge és el sostre: no pots detectar de manera fiable millores més petites que el teu propi soroll.

Què faig amb els casos en què dues persones no es posen d'acord?

Tractar-los com el senyal més barat que aconseguiràs, no com un problema de qualitat de les persones. Aroyo i Welty ho van argumentar el 2015 amb la idea de crowd truth: la interpretació humana és subjectiva i el desacord mesura l'ambigüitat real de la tasca. Si dues persones de domini discrepen en un cas, gairebé sempre vol dir que la condició d'acceptació està mal escrita, no que una s'equivoqui. El desacord es porta a la rúbrica i es resol allà.

Fonts citades

• Ribeiro, Wu, Guestrin, Singh — Beyond Accuracy: Behavioral Testing of NLP Models with CheckList (ACL 2020; matriu de capacitats, el doble de proves i gairebé el triple de fallades)
• Northcutt, Athalye, Mueller — Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks (≥3,3% de mitjana, ≥6% a ImageNet, canvis d'ordre entre models)
• Aroyo, L. i 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ó estesa en obert)
• Recht, Roelofs, Schmidt, Shankar — Do ImageNet Classifiers Generalize to ImageNet? (caigudes d'11-14 punts en reconstruir el conjunt de test)
• Zhang i altres (Scale AI) — A Careful Examination of Large Language Model Performance on Grade School Arithmetic (GSM1k; caigudes de fins a 8 punts, r² d'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. i Dahl, G. E. — What Will it Take to Fix Benchmarking in Natural Language Understanding? (2021; mida i fiabilitat de l'anotació)
• Miller, E. — Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations (comparació aparellada i anàlisi de potència)
• Zhu i altres — Establishing Best Practices for Building Rigorous Agentic Benchmarks (validesa de tasca i validesa de resultat, NeurIPS 2025)
• OpenAI — Introducing SWE-bench Verified i la fitxa del benchmark a Epoch AI (500 instàncies, 93 desenvolupadors, 5-10% d'error residual estimat)