Avaluar agents d'IA: què significa exactament «funciona millor»

«Va molt millor.» És la frase amb què es tanca la majoria de revisions d'un agent en producció. I és una frase que no conté cap informació. Millor que què. Mesurat amb quin criteri. Amb quanta confiança que la diferència no és soroll. Tres preguntes, i a la majoria d'equips no hi ha resposta escrita per a cap de les tres.

El problema no és de rigor personal, és conceptual. «Millor» no és una propietat del sistema: és una relació amb un referent. I «bé» no és una impressió: és el resultat d'aplicar un criteri que algú va escriure abans de mirar la sortida. Els dos objectes que falten són sempre els mateixos: la rúbrica —què compta com a correcte— i el baseline —contra què es compara—. Sense ells, qualsevol comparació entre dues versions d'un agent és una conversa d'opinions amb vocabulari tècnic.

A l'article anterior sobre LLMOps descrivim el cicle complet i dèiem que el nivell 2 de maduresa comença quan un número pot bloquejar un desplegament. Aquest article és d'on surt aquest número: com es construeixen la rúbrica i el baseline a partir del golden set, com se sap si una diferència és real, i què diuen els treballs que han estudiat el problema — perquè porten tres anys documentant exactament els errors que els equips repetim.

Per què en agents la pregunta es trenca

Avaluar una crida solta a un model és incòmode però tractable: entrada, sortida, criteri. Avaluar un agent és una altra cosa, i per cinc raons concretes.

Hi ha més d'una trajectòria correcta. Una tasca resolta bé pot resoldre's consultant primer el CRM i després la base de coneixement, o a l'inrevés, o sense consultar la base de coneixement perquè el CRM ja n'hi havia prou. No existeix una «resposta de referència» única contra la qual comparar cadenes de text.

El resultat no és un text, és un efecte al món. L'agent va crear el tiquet, va fer la devolució, va modificar el fitxer, va enviar el correu. El que cal verificar és l'estat final del sistema, no l'elegància de l'explicació.

Hi ha crèdit parcial i no sempre compta. Vuit de deu passos correctes i un novè que trenca l'estat no és un 80%: és una fallada. En altres tasques, en canvi, vuit de deu sí que val, perquè l'humà corregeix la resta en dos minuts. La rúbrica ha de decidir quin dels dos casos és el teu, i aquesta decisió és de negoci, no tècnica.

El no determinisme es compon. La variància d'un pas es multiplica per la del següent. Toby Ord va proposar el 2025 un model sorprenentment simple per a això: si l'agent té una probabilitat de fallada aproximadament constant per cada minut de feina humana que la tasca representa, aleshores la taxa d'èxit decau exponencialment amb la longitud de la tasca, i cada agent queda caracteritzat per la seva pròpia «vida mitjana». La conseqüència operativa és dura: no pots extrapolar de tasques de cinc minuts a tasques de dues hores. Que el teu agent encerti el 90% de les tasques curtes no diu gairebé res sobre les llargues.

I el cost varia per execució. Dos sistemes amb la mateixa taxa d'encert poden diferir en un ordre de magnitud en el que costa cada execució. Comparar només per encert és comparar mitja foto.

«Bé» és una rúbrica, no una impressió

Una rúbrica és un conjunt explícit de criteris que converteix un judici holístic en verificacions discretes. Un treball de revisió publicat aquest estiu —From Holistic Evaluation to Structured Criteria, Chen i altres, juny de 2026— situa les rúbriques en tres nivells: l'avaluatiu, on descomponen un judici global en dimensions verificables; el d'entrenament, on funcionen com a senyal densa de recompensa; i l'intrínsec, on emergeixen del comportament mateix del model. El que necessita un equip de producte és el primer, i és el que gairebé ningú no escriu.

Comencem pel que una rúbrica no és: una escala de l'1 al 10 de «qualitat». Demanar a un jutge —humà o model— que puntuï la qualitat global d'una resposta produeix un número amb la reproduïbilitat d'una enquesta de satisfacció. Demanar-li que verifiqui dotze criteris concrets produeix dotze respostes auditables, cadascuna amb la seva evidència. La diferència entre les dues coses és la diferència entre una opinió numerada i una mesura.

Com es deriva del golden set, pas a pas

El golden set ja el tens si vas seguir el cicle de l'article anterior: trenta o cinquanta casos per capacitat, etiquetats per qui coneix el domini. La rúbrica s'extreu d'allà, no d'una sessió de pluja d'idees en abstracte. Si encara no el tens —o si el que tens és un full amb els exemples del prompt—, comença per com es construeix el golden set: d'on surten els casos, quants en calen i per què l'error d'etiquetatge és el sostre de tot el que mesuris després.

• Agafa de 20 a 30 casos del golden set amb les seves respostes de referència. No més: l'objectiu d'aquesta fase és trobar patrons, no cobrir-ho tot.
• Pregunta cas per cas a la persona de domini dues coses: què ha d'aparèixer sí o sí, i què no pot aparèixer mai. No preguntis «això està bé?» — aquesta pregunta retorna una impressió. Les dues anteriors retornen criteris.
• Agrupa. El que apareix en més d'un terç dels casos és un criteri general de la capacitat. El que apareix una vegada és un criteri específic d'aquell cas, i també val: HealthBench funciona així.
• Reescriu cada criteri com una verificació binària amb evidència localitzable a la traça. Si no pots assenyalar on es compleix o on falla, el criteri no està acabat.
• Pondera i marca els eliminatoris. No tots els criteris valen el mateix, i alguns no fan mitjana: o es compleixen o el cas falla sencer.

La referència industrial d'aquest mètode és HealthBench, l'avaluació clínica que OpenAI va publicar el 2025: 5.000 converses sanitàries, cadascuna amb la seva rúbrica escrita per metges —262 professionals de 60 països i 26 especialitats—, amb un total de 48.562 criteris, cadascun amb el seu valor en punts segons la importància que el metge li va assignar. Ningú no va escriure «puntua de l'1 al 10 la qualitat clínica». Es va escriure, criteri a criteri, què havia d'aparèixer i què s'havia d'evitar. Tu no necessites 48.562 criteris: necessites la disciplina que produeix aquests criteris.

Anatomia d'un criteri que serveix

La prova de qualitat d'un criteri és aquesta última línia: dues persones diferents, el mateix cas, el mateix veredicte. Si el criteri necessita una conversa per resoldre's, no està acabat. I si no està acabat per a un humà, un model jutge tampoc no l'aplicarà de manera estable.

Ponderació, eliminatoris i el parany de la mitjana

Amb dotze criteris i una mitjana aritmètica, un sistema que falla el criteri de seguretat però encerta els onze restants treu un 92%. És exactament el número equivocat. Per això una rúbrica operativa té dos tipus de criteri:

• Acumulatius: sumen punts ponderats. Mesuren qualitat.
• Eliminatoris: si fallen, el cas val zero, independentment de la resta. Mesuren acceptabilitat.

Els eliminatoris solen ser pocs —dos o tres— i gairebé sempre són de la mateixa família: accions irreversibles sense confirmació, fuita de dades que no havien de sortir del perímetre, i afirmacions inventades presentades com a fets. Si la teva rúbrica no té eliminatoris, o el teu sistema és molt innocu, o encara no has pensat què és inacceptable.

A l'informe, a més, la mitjana agregada no es reporta sola. Es reporta per capacitat, com dèiem al cicle LLMOps: una mitjana que puja amagant que la capacitat crítica va caure vuit punts és pitjor que no mesurar, perquè produeix confiança on hauria de produir una alarma.

Rúbrica de resultat i rúbrica de procés

Hi ha dues preguntes diferents i convé no barrejar-les. La rúbrica de resultat pregunta si l'estat final del món és el correcte: la comanda va quedar cancel·lada, l'import és el que tocava, el fitxer compila? La rúbrica de procés pregunta si l'agent hi va arribar per un camí admissible: va fer servir només les eines permeses, va respectar l'ordre, va evitar efectes col·laterals, no va entrar en bucle?

Avaluar la trajectòria és car si es fa a mà, i aquí és on el treball Agent-as-a-Judge (Zhuge i altres, ICML 2025) aporta una dada útil: un agent avaluador que pot obrir fitxers, executar comprovacions i revisar cada pas va assolir un 90% d'alineació amb el judici humà sobre el seu benchmark DevAI, a un 2,29% del cost i un 2,36% del temps de l'avaluació humana. L'avaluació de procés va deixar de ser un luxe acadèmic.

La regla pràctica que apliquem: resultat sempre; procés quan el resultat correcte pel camí equivocat sigui inacceptable. És a dir, quan hi ha accions irreversibles, quan hi ha obligacions de compliment —ho tractem a Compliance-First AI Design— o quan el camí determina el cost. En un flux de diverses etapes encadenades, el procés gairebé sempre importa.

La teva rúbrica pot ser correcta i estar mesurant una altra cosa

Aquest és el punt que més vegades se salta, i el que surt més car. Una rúbrica ben escrita pot continuar sense mesurar el que creus. El treball Establishing Best Practices for Building Rigorous Agentic Benchmarks (Zhu i altres, NeurIPS 2025) ho formalitza en dues condicions:

• Validesa de tasca: la tasca hauria de ser resoluble si i només si l'agent té la capacitat que dius mesurar. Si es pot resoldre per una drecera que no requereix aquesta capacitat, la tasca no és vàlida.
• Validesa de resultat: la comprovació hauria d'indicar correctament si la tasca es va resoldre. Si la comprovació és feble, mesura una altra cosa.

Els exemples que donen els autors són incòmodes precisament perquè no són de benchmarks improvisats. Documenten que SWE-bench Verified fa servir casos de test insuficients i que τ-bench arriba a comptar respostes buides com a èxit; en conjunt, defectes d'aquest tipus poden infraestimar o sobreestimar el rendiment d'un agent fins a un 100% en termes relatius. Si li passa a benchmarks públics, revisats i àmpliament citats, li passa amb més raó a la rúbrica que el teu equip va escriure un dijous a la tarda.

«Millor» és un baseline, no un adjectiu

Amb la rúbrica ja pots dir «bé». Per dir «millor» cal un referent, i aquí és on la majoria de comparacions cauen: es compara la versió nova contra el record de l'anterior. El record no és un baseline.

El baseline ximple, o per què la teva arquitectura pot no estar aportant res

El 2024, un grup de Princeton —Kapoor, Stroebl, Siegel, Nadgir i Narayanan— va publicar AI Agents That Matter, una anàlisi de com s'avaluen els agents que continua sent el treball més incòmode de llegir si el teu equip acaba de muntar un pipeline agèntic. La seva troballa central: baselines simples dominaven en Pareto agents d'última generació —Reflexion, LDB, LATS— a HumanEval, amb 50 vegades menys cost. I el seu diagnòstic: la comunitat es fixa només en l'exactitud, sense atendre el cost, i d'aquí surten agents innecessàriament complexos i cars, i conclusions equivocades sobre d'on vénen les millores.

Traduït a la realitat d'un equip de producte: si ningú no va mesurar la línia base simple —una sola crida amb bon context, sense orquestració—, no saps si la teva arquitectura de set passos aporta qualitat o només aporta factura. L'ablació és l'experiment més barat del catàleg i gairebé ningú no el corre, perquè el resultat pot ser políticament incòmode.

El baseline humà es mesura, no s'imagina

L'altre baseline que es maltracta és l'humà. Es compara l'agent contra una persona ideal que mai no s'equivoca, i la conclusió és sempre la mateixa: «encara no hi és». Però l'humà que avui fa aquesta tasca té un temps mitjà, un cost per tasca i una taxa d'error que no és zero. Sense aquests tres números, la comparació està esbiaixada d'origen.

Mesurar-ho no requereix un estudi: vint tasques cronometrades i revisades amb la mateixa rúbrica que apliques a l'agent. La mateixa rúbrica és la part important — si a l'humà el jutges amb indulgència i a l'agent amb lupa, no estàs comparant, estàs justificant una decisió que ja havies pres.

El cost no és una conseqüència: és un eix de la comparació

De l'anterior en surt la conseqüència metodològica: no es compara un punt contra un altre punt, es comparen posicions en una frontera de qualitat i cost. Un sistema amb 92% d'encert a 0,40 € per tasca i un altre amb 86% a 0,04 € no estan ordenats: són dos punts diferents d'una frontera, i quin és «millor» depèn de qui absorbeix el 8% restant i a quin preu. La mètrica que fa comparable aquesta frontera és el cost per tasca útil, i el seu comportament en escalar el desenvolupem a el cost real de posar IA en producció.

Fiabilitat no és capacitat: pass@k davant de pass^k

Aquí hi ha una distinció que decideix més desplegaments dels que sembla, i ve de τ-bench (Yao i altres, 2024), el benchmark de Sierra per a agents que conversen amb un usuari i manegen eines sota polítiques de domini.

• pass@k: l'agent encerta almenys una vegada en k intents. Mesura potencial. És la mètrica correcta quan hi ha un verificador barat que descarta els intents dolents: compilar, passar tests, validar un esquema.
• pass^k: l'agent encerta les k vegades. Mesura fiabilitat. És la mètrica correcta quan la sortida va a producció sense xarxa.

La dada de τ-bench és la que convé tenir present: agents de funció avançats resolien menys del 50% de les tasques en una passada, i al domini de retail queien per sota del 25% en pass^8. És a dir: de cada quatre tasques que sabien resoldre, només una la resolien vuit vegades seguides.

La pregunta de negoci, doncs, no és «quin percentatge treu?» sinó «amb quina k el necessito?». I la k correcta és el nombre de vegades que el procés s'executa abans que un humà el revisi. Si un agent processa 200 devolucions diàries i ningú no les mira, la teva k no és 8: és 200. Reportar pass@1 en aquest escenari no és optimista, és incorrecte.

I la diferència és real? L'estadística mínima que cal fer

Suposem que ja tens rúbrica, baseline i una mètrica ben triada. El sistema nou treu 85% i l'anterior 82%. És una millora?

Probablement no ho sàpigues. Amb 50 casos i una taxa propera al 80%, l'error estàndard ronda els 5-6 punts. Una diferència de 3 punts cap sencera dins del soroll. I si a més cada cas es va executar una sola vegada, part d'aquests 3 punts és simplement el no determinisme del model.

El treball de referència aquí és Adding Error Bars to Evals, d'Evan Miller (Anthropic, 2024), que critica d'entrada la pràctica dominant: reportar avaluacions amb mentalitat de «el número més alt guanya», en negreta, sense cap prova de significació. Les seves recomanacions són directament aplicables a un informe intern:

• Reportar l'error estàndard al costat de la mitjana, fent servir el teorema central del límit.
• Fer servir errors estàndard agrupats quan les preguntes vénen en grups —diversos casos derivats del mateix document o del mateix client—, perquè no són independents.
• Analitzar diferències aparellades: els dos sistemes sobre els mateixos casos, mesurant la diferència cas a cas. És la manera més barata de guanyar potència estadística sense ampliar el conjunt.
• Fer anàlisi de potència abans, per saber quants casos necessites per detectar la diferència que t'importa.
• Generar diverses respostes per cas i fer-ne la mitjana, per reduir el soroll de generació.

Res d'això no requereix un estadístic en plantilla. Requereix acceptar una frase incòmoda a l'informe: «la diferència observada no és distingible del soroll amb aquest nombre de casos». Escriure aquesta frase quan toca és el que separa un equip que mesura d'un equip que decora.

El jutge també cal avaluar-lo

Gairebé tota rúbrica a escala s'acaba aplicant amb un model com a jutge. El treball fundacional —Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, Zheng i altres, 2023— va donar la bona notícia i la dolenta a la mateixa frase: jutges forts assolien més del 80% d'acord amb les preferències humanes, el mateix nivell d'acord que hi ha entre humans; i alhora presentaven biaix de posició (prefereixen la primera opció), biaix de verbositat (prefereixen respostes llargues), autoafalac (prefereixen la seva pròpia família de models) i capacitat de raonament limitada en tasques que exigeixen càlcul.

Les contramesures són mecàniques i barates:

• Un criteri per crida. No demanis una puntuació global; demana un veredicte binari amb l'evidència que el sosté.
• Model jutge diferent de l'avaluat, i si pot ser d'una altra família, per no premiar l'estil propi.
• Ordre alternat en comparacions per parells: executar A-B i B-A i fer-ne la mitjana neutralitza el biaix de posició.
• Calibratge amb etiquetes humanes abans de confiar-hi, mesurant l'acord (kappa) sobre una mostra, i un mostreig humà permanent d'entorn al 10% per detectar quan el jutge es desalinea.

I una observació que ordena tot l'anterior: el jutge és molt més fiable verificant un criteri binari amb evidència que puntuant qualitat global. Aquesta és la raó tècnica —no estètica— per la qual la rúbrica no és un refinament metodològic opcional: és el que converteix el jutge automàtic en una eina utilitzable.

Quan l'eval es converteix en l'objectiu

Tota mètrica que es fa servir per decidir acaba sent optimitzada, i tota mètrica optimitzada deixa de mesurar el que mesurava. En avaluació d'agents això té una forma molt concreta: al cap d'uns mesos, el sistema és excel·lent en els 120 casos del golden set i continua igual de fluix en producció.

Tres contramesures que funcionen i no costen gairebé res:

• Conjunt retingut. Un 20-30% dels casos mai no es fa servir per iterar. Només es toca per decidir promocions importants. Si comença a fer-se servir per depurar, deixa de ser retingut — i cal dir-ho a l'informe.
• Rotació. Cada trimestre entren casos nous de producció i surten els que porten sis mesos en verd sense fallar mai. Un cas que sempre passa ja no aporta informació.
• Separació de rols. Qui optimitza el sistema no escriu els criteris nous sense revisió de la persona de domini. No és desconfiança: és que qui coneix la fallada tendeix a escriure el criteri que la seva solució ja compleix.

La sensació de millora no és evidència

Val la pena tancar l'argument amb la dada més incòmoda de totes. El juliol de 2025, METR va publicar un assaig controlat aleatoritzat amb desenvolupadors open source experimentats treballant als seus propis repositoris: 16 persones, 246 tasques reals. Abans de començar preveien una acceleració del 24%. Després de la sessió, estimaven haver anat un 20% més ràpid. El mesurament va donar un 19% més lents.

Convé ser honest amb l'abast: METR ha marcat aquest resultat com a històric —reflecteix eines i fluxos de principis de 2025— i ha canviat el disseny de l'experiment. La conclusió duradora no és «la IA alenteix». És una cosa més útil i més general: la percepció de millora i la millora mesurada poden apuntar en sentits oposats, fins i tot en professionals experts avaluant la seva pròpia feina, immediatament després de fer-la. Per això «l'equip diu que va molt millor» no és una dada. És un punt de partida per mesurar.

«Millor» també significa «més llarg»

Hi ha una última accepció de «millor» que en agents és cada cop més la que importa. METR manté una mètrica d'horitzó temporal: la longitud de tasca —mesurada en el temps que li portaria a un professional humà— que un agent completa amb un 50% de fiabilitat. A la seva revisió de gener de 2026 (Time Horizon 1.1), el temps de duplicació posterior a 2023 s'estima en uns 131 dies, i al febrer de 2026 el model al capdavant rondava les 14 hores i mitja d'horitzó al 50%.

Per a un equip això reordena la pregunta. Si la fiabilitat decau exponencialment amb la longitud de la tasca —el model de vida mitjana d'Ord— i l'horitzó dels models creix ràpid, la pregunta útil deixa de ser «quin percentatge treu el meu agent?» i passa a ser «fins a quina longitud de tasca aguanta amb la fiabilitat que el meu procés necessita?». Aquesta frontera és el que cal mesurar, i és el que es mou quan canvies de model. Fixar el 50% com a llindar, a més, és una convenció de recerca: per a un procés de negoci sense revisió humana, el llindar rellevant sol estar bastant més amunt.

La fitxa de comparació: què fa creïble un informe

Tot l'anterior es condensa en un artefacte molt poc glamurós: la fitxa amb què un equip declara que la versió B és millor que l'A. Si li falta alguna d'aquestes línies, l'afirmació no és verificable per ningú que no fos a la sala.

Els sis errors que anul·len una comparació

Cap no és exòtic. Els hem vist tots sis en equips tècnicament sòlids.

1. Comparar contra «el que hi havia» sense haver-ho mesurat mai. Si el sistema anterior mai no va passar per la rúbrica, no hi ha comparació: hi ha una versió nova mesurada i un record.

2. Que la rúbrica l'escrigui qui optimitza el sistema. Sense mala fe, els criteris acaben assemblant-se sospitosament al que la solució ja fa bé.

3. Una sola execució per cas. En un sistema no determinista, una passada és una mostra de mida u. Tres a cinc per cas és el mínim raonable, i la variància entre elles ja és informació valuosa.

4. Fer la mitjana de tots els criteris per igual. Sense eliminatoris, una fallada de seguretat es dilueix entre onze encerts i surt un 92% tranquil·litzador.

5. Canviar dues coses alhora. Nou prompt i nou model al mateix release: sabràs que va canviar el número, no per què. El canvi atòmic no és purisme, és el que fa atribuïble el resultat.

6. Deixar el cost fora de l'informe. És l'error que documenta el treball de Princeton, i el que produeix arquitectures cares que ningú no sap justificar sis mesos després.

Les dues primeres setmanes

Si ja tens golden set —i si no, aquest és el pas anterior— això és el que produeix més senyal per hora invertida.

Setmana 1 · La rúbrica. Agafa 25 casos i treu els criteris amb la persona de domini, preguntant què ha d'aparèixer i què no pot aparèixer. Reescriu-los com a verificacions binàries amb evidència localitzable. Marca dos o tres eliminatoris. I passa-la per la prova de l'agent nul abans de fer-la servir per a res.

Setmana 2 · Els baselines i la fitxa. Mesura amb aquesta rúbrica l'agent nul, la release actual i l'ablació més simple que resolgui la tasca. Executa cada cas de tres a cinc vegades. Calcula la diferència aparellada amb el seu interval. Omple la fitxa de nou línies i publica-la on la vegi l'equip.

Al final de la segona setmana no tindràs un sistema millor. Tindràs una cosa més valuosa: la capacitat de saber, la pròxima vegada, si ho és. Tot el cicle LLMOps es recolza en aquesta capacitat — sense ella, les portes de qualitat no poden bloquejar res, i una porta que no bloqueja és decoració.

Mesurar és el que converteix la velocitat en progrés

Hi ha una versió de l'adopció d'IA que consisteix a anar molt ràpid sense saber cap on. Es reconeix fàcil: molta activitat, moltes demos, releases setmanals, i ningú capaç de dir amb un número si el sistema d'avui és millor que el de març. La disciplina de la rúbrica i el baseline és el que separa aquesta versió de l'altra.

És la mateixa lògica que apliquem al codi amb Spec-Driven Development: escriure el criteri abans que l'artefacte. Als programes onext AI-Accelerated Development, la rúbrica i els baselines són part del harness que deixem instal·lat, no un lliurable posterior. Els resultats que signem amb clients el 2026 —×7 velocitat de lliurament, 0 sprints perduts, −50% time-to-production— se sostenen precisament sobre això: equips que despleguen ràpid perquè saben, abans de desplegar, si el canvi és bo.

Preguntes freqüents

Què és una rúbrica en l'avaluació d'agents d'IA?

És un conjunt explícit de criteris que converteix un judici holístic —«aquesta resposta és bona»— en verificacions discretes i comprovables una per una. Cada criteri s'escriu com una comprovació binària amb evidència localitzable a la traça: què ha d'aparèixer, què no pot aparèixer mai, quina eina s'havia de fer servir. No és una escala de l'1 al 10 de qualitat global: demanar a un jutge que puntuï «la qualitat» produeix un número poc reproduïble, mentre que demanar-li que verifiqui dotze criteris concrets produeix dotze respostes auditables.

Com es construeix una rúbrica a partir del golden set?

Amb vint o trenta casos ja etiquetats, es pregunta a la persona de domini cas per cas què ha d'aparèixer sí o sí i què no pot aparèixer mai — no «això està bé?». Les respostes recurrents es converteixen en criteris generals; la resta, en criteris específics de cada cas. Després cada criteri es reescriu com a verificació binària, es pondera i es marca quins són eliminatoris. HealthBench, d'OpenAI, és la referència industrial del mètode: 5.000 converses amb rúbriques escrites per 262 metges i 48.562 criteris ponderats per importància.

Quina diferència hi ha entre pass@k i pass^k, i quina importa en producció?

pass@k mesura si l'agent encerta almenys una vegada en k intents: és potencial, i és la mètrica adequada quan hi ha un verificador barat que descarta els intents dolents (compilar, passar tests). pass^k mesura si encerta les k vegades: és fiabilitat, i és la mètrica adequada quan la sortida va a producció sense xarxa. A τ-bench, agents amb menys del 50% d'èxit en una sola passada queien per sota del 25% en pass^8. En negoci, la k correcta és el nombre de vegades que el procés s'executa abans que un humà el revisi.

Quants casos calen per afirmar que un sistema és millor que un altre?

Més dels que la majoria d'equips fa servir. Amb 50 casos i una taxa d'encert propera al 80%, l'error estàndard ronda els 5-6 punts: una millora de 3 punts és indistingible del soroll. La manera barata de guanyar potència estadística no és multiplicar casos sinó comparar en aparellat —els dos sistemes sobre els mateixos casos, mesurant la diferència cas a cas— i executar cada cas diverses vegades per fer la mitjana del no determinisme. És exactament el que recomana el treball d'Anthropic sobre barres d'error en avaluacions.

Contra quin baseline cal comparar un agent?

Contra quatre, no contra un: l'agent nul (que no fa res, per validar que la rúbrica no regala punts), el sistema anterior, l'humà que avui fa la tasca amb el seu cost i la seva taxa d'error reals, i l'ablació —la versió més simple del teu propi sistema—. Aquesta última és la que dona més sorpreses: el treball de Princeton «AI Agents That Matter» va mostrar baselines simples dominant en Pareto agents d'última generació amb 50 vegades menys cost. Sense ablació no saps si la teva arquitectura agèntica aporta qualitat o només factura.

Puc fiar-me que l'equip digui que l'agent va molt millor?

No com a dada. A l'assaig controlat de METR amb desenvolupadors open source experimentats, els participants preveien un 24% d'acceleració, després de la sessió estimaven un 20% d'acceleració, i el mesurament va donar un 19% d'alentiment. METR ha marcat aquest resultat com a històric i ha canviat el disseny de l'experiment, així que la conclusió duradora no és «la IA alenteix»: és que la percepció de millora i la millora mesurada poden apuntar en sentits oposats, fins i tot en experts avaluant la seva pròpia feina.

Fonts citades

• Yao, Shinn, Razavi, Narasimhan (Sierra) — τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (mètrica pass^k)
• Kapoor, Stroebl, Siegel, Nadgir, Narayanan (Princeton) — AI Agents That Matter (avaluació amb control de cost, frontera de Pareto)
• Zhu i altres — Establishing Best Practices for Building Rigorous Agentic Benchmarks (validesa de tasca i de resultat, NeurIPS 2025)
• OpenAI — HealthBench (rúbriques escrites per metges, 48.562 criteris ponderats)
• Zhuge i altres — Agent-as-a-Judge: Evaluate Agents with Agents (avaluació de trajectòria, ICML 2025)
• Miller, E. (Anthropic) — Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations
• Zheng i altres — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (biaixos del jutge)
• Chen, Han, Yan, Zhu, Sun, Che — From Holistic Evaluation to Structured Criteria: Rubrics Across the Evolving LLM Landscape (juny 2026)
• Ord, T. — Is there a half-life for the success rates of AI agents? (decaïment exponencial amb la longitud de tasca)
• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity i Time Horizon 1.1 (gener 2026)