En l'ecosistema actual del desenvolupament de programari, els agents d'intel·ligència artificial han esdevingut eines imprescindibles per accelerar la creació de codi, automatitzar tasques repetitives i millorar la productivitat dels equips. No obstant això, mesurar si realment estan funcionant com esperem no és trivial. Les avaluacions tradicionals solen tindre números que semblen sòlids, però que oculten una realitat molt més complexa: criteris mal definits, entorns que no reflecteixen l'ús real i una confiança mal dipositada en les mètriques. En aquest article explorem com construir avaluacions d'AX (Agent Experience) que realment aportin informació útil, evitant els biaixos més comuns i alineant el mesurament amb els objectius de negoci.
El primer pas per obtenir senyals fiables és entendre que una avaluació no és un fi en si mateix, sinó un mitjà per identificar les mancances de l'agent en l'ús de la teva tecnologia. Si el sistema de mesurament et diu que tot va bé quan en realitat l'agent està generant codi incorrecte o incomplet, estaràs optimitzant en la direcció equivocada. Per això, abans de llançar una bateria de proves, convé reflexionar sobre què volem mesurar exactament: la capacitat de l'agent per descobrir una llibreria? La qualitat del codi generat? La integració amb un ecosistema existent? Cada objectiu requereix un disseny d' avaluació diferent.
Un dels errors més freqüents és redactar criteris d'avaluació vagos, com 'el codi ha de manejar errors correctament'. Dos revisors diferents interpretaran aquesta frase de manera diferent, i el mateix passa amb els models de llenguatge que actuen com a jutges. Per obtenir resultats consistents, els criteris han de ser tan específics que no quedi marge a la interpretació. Per exemple, en lloc de demanar 'ús adequat de l'API', podem desglossar la condició en verificacions atòmiques: 'totes les trucades a serveis externs estan embolicades en blocs try-catch', 'els errors de xarxa es reintenten amb backoff exponencial', 'els errors d'aplicació es propaguen a l'cridant preservant el codi original'. Cadascuna d' aquestes comprovacions pot avaluar-se de forma independent, amb estats de passa, falla o se salta, la qual cosa proporciona un senyal granular i accionable.
Un altre aspecte crític és la necessitat de múltiples execucions. Els models de llenguatge són inherentment no deterministes: la mateixa instrucció pot produir resultats diferents en cada invocació. Confiar en una única execució equival a treure conclusions basades en una mostra estadísticament insignificant. L'experiència indica que amb cinc repeticions per escenari es comença a observar un patró estable, suficient per prendre decisions informades sobre si una extensió o millora està realment ajudant. Si els resultats són molt variables entre execucions, això mateix és informació valuosa: pot indicar que l' escenari no està ben definit, que l' entorn té variables ocultes o que l' agent és inherentment inestable per a aquesta tasca.
La neteja de l' entorn d' avaluació mereix una atenció especial. Noms d' usuari, rutes de directori, noms de projectes o qualsevol altre indici semàntic poden esquinçar el comportament de l' agent. Un path com /home/demo/projecte-prova li està dient al model que es tracta d'un escenari de prova, i això pot fer que prengui dreceres o que no apliqui les mateixes pràctiques de qualitat que en un entorn real. L'ideal és que l'entorn sigui neutre, que no contingui pistes sobre el que s'està avaluant. A més, l' entorn ha de representar fidelment el context de treball dels usuaris finals. Si la majoria dels teus desenvolupadors fan servir Windows i Visual Studio Code, avaluar sobre Linux amb un agent CLI no et servirà de gaire. Les diferències en el sistema operatiu, el shell i l'ecosistema d'eines canvien les decisions del model, i el que funciona en un entorn pot fallar en un altre.
El calibratge del jutge és un altre pilar fonamental. No n'hi ha prou amb escriure criteris detallats; cal verificar que el model que actua com a avaluador els interpreta correctament. Per a això, se seleccionen entre cinc i deu outputs reals d'agent —no exemples artificials—, s'anoten manualment els veredictes esperats i es comparen amb els que emet el jutge. Quan hi ha discrepàncies, gairebé sempre és perquè el criteri és ambigu. Ajustar la redacció, repetir el calibratge i assegurar que el jutge encerta en tots els casos de prova és un procés iteratiu indispensable. També convé comprovar la consistència: executar el mateix jutge sobre el mateix output diverses vegades i verificar que el veredicte no canviï. Si ho fa, el criteri necessita més concreció, no un model més potent.
Dins de les fallades més habituals en els avaluadors automàtics, destaca la incapacitat de certs models per raonar sobre versions semàntiques (semver). Un jutge petit pot identificar les dependències d'un projecte, però no determinar de forma fiable si la versió usada és la més recent o si compleix amb rangs de compatibilitat. En aquests casos, la solució no és forçar el model a fer alguna cosa per al que no està preparat, sinó dividir la tasca: que el jutge identifiqui la versió, i que una eina externa —un script determinista— realitzi la comparació. De la mateixa manera, demanar al jutge que calculi puntuacions agregades sol ser font d'errors aritmètics. És molt més fiable que el jutge retorni únicament veredictes individuals (passa/falla/se salta) amb la seva evidència, i que un procés extern calculi les mètriques finals de forma determinista.
Per a les empreses que estan desenvolupant productes basats en agents d'IA, comptar amb un sistema d'avaluació robust no és un luxe, és una necessitat competitiva. En Q2BSTUDIO, entenem que la qualitat del programari generat per intel·ligència artificial depèn directament de com mediem i ajustem el comportament dels agents. Per això oferim serveis d ' aplicacions a mida i consultoria en IA per a empreses, on integrem aquestes pràctiques d' avaluació dins del cicle de desenvolupament. Treballem amb tecnologies cloud com AWS i Azure, implementem solucions de ciberseguretat i desenvolupem dashboards a Power BI perquè la informació de rendiment sigui clara i accionable. El nostre equip ajuda les organitzacions a dissenyar proves d'agent que realment reflecteixin l'ús en producció, evitant els falsos positius que tantes vegades desvien els esforços de millora.
Una recomanació pràctica per a qui comença des de zero: limita l'abast inicial a tres o cinc escenaris que representin les tasques més comunes dels teus desenvolupadors. Redacta prompts que sonin a peticions reals, no a instruccions optimitzades per a l' avaluació. Defineix criteris amb el format de llista de verificació, amb condicions explícites de passa, falla i se salta. Calibra el jutge amb outputs reals de l' agent. Executa cinc vegades cada condició (línia base i amb la teva extensió). Si els resultats són unànimes, tens la teva resposta; si no, executa més repeticions. Fixa l' entorn: registra el sistema operatiu, les versions d' eines, el model i el harness. Cada vegada que canviïs alguna cosa, recalibra. I no compares puntuacions entre versions del rubric sense tornar a calibrar.
La variabilitat no és un enemic, és una font d'informació. Si un escenari passa el 90% de les vegades amb la teva extensió i el 50% sense ella, has trobat un cas on la teva solució marca una diferència real. Però si la taxa d'encert fluctua enormement d'un dia per l'altre, probablement hi hagi una variable no controlada —una actualització del model base, un canvi en el harness, una extensió que es va actualitzar automàticament—. Portar un registre detallat de cada execució et permetrà identificar aquestes derives i corregir-les abans que contaminin les teves conclusions.
En definitiva, construir avaluacions d' AX que realment funcionen exigeix disciplina en el disseny de rúbriques, rigor estadístic i una higiene sistemàtica de l' entorn. No són tasques especialment complexes de forma individual, però mantenir totes elles alineades a mesura que creix el nombre d'escenaris és on molts equips fracassen. La recompensa mereix l'esforç: quan veus que una puntuació canvia, saps que reflecteix una millora real en la capacitat de l'agent. Quan el teu lideratge pregunta si la inversió en agents d'IA està donant resultats, tens dades, no anècdotes. Si estàs llest per donar el següent pas i necessites suport per implementar un sistema d'avaluació sòlid o desenvolupar programari a mesura que integri aquestes pràctiques, en Q2BSTUDIO estem preparats per ajudar-te a convertir la intel·ligència artificial en un motor real de productivitat i qualitat.
