Avaluació de sistemes LLM

• Per què els prompts necessiten tests
• Anatomia d’una eval
• El conjunt de referència (golden set)
• Anàlisi d’errors
  • El procés
  • El visor de traces
  • On encaixa en el cicle
• Com construir el dataset d’evals
  • Fonts de casos
  • Format del dataset
  • Manteniment del dataset
• Tipus d’avaluadors
  • Quin avaluador per a cada tasca
  • El veredicte binari per defecte
• Qui defineix la qualitat
• Biaixos i fiabilitat del LLM-as-judge
  • Mitigacions pràctiques
• Dissenyar per a la verificabilitat
• No-determinisme: pass@k i pass^k
• Evals d’agents
• Evals per a RAG
  • Per què avaluar les dues etapes per separat
• El cicle de millora dirigit per evals
  • Les palanques de millora
  • Offline i online
• Referències

Les evals són el mecanisme de verificació sistemàtica del comportament d’un sistema LLM. Es poden usar durant el desenvolupament (per validar canvis de prompt) i en producció (per detectar regressions de qualitat). Aquest document cobreix la metodologia; la integració amb el monitoratge en producció s’explica a Sistemes LLM en producció.

Per què els prompts necessiten tests

La prova manual (provar el sistema a mà i veure que “funciona”) no és suficient per a un sistema en producció. Els LLMs fallen de forma no determinista i en casos límit que no s’anticipen durant el desenvolupament. Un canvi al prompt que millora un cas pot trencar-ne un altre silenciosament. Sense un mecanisme de verificació sistemàtic, és impossible saber si un canvi millora o empitjora el sistema.

Les evals compleixen el mateix rol que els tests unitaris en el programari convencional, però adaptats a les propietats dels LLMs: sortida no determinista, qualitat graduada (una resposta pot ser parcialment correcta), i fluxos multi-pas.

La distinció fonamental que s’aplica aquí és la mateixa que per a qualsevol sistema ML: el codi determinista (parsing de la sortida, validació d’esquemes, routing, eines) es testa amb pytest convencional; el comportament del model (qualitat de la resposta, correcció de la tasca) es valida amb evals. Consulta Validació i qualitat per als patrons generals de testing i CI/CD en sistemes ML.

Anatomia d’una eval

Cada eval es compon de quatre elements:

• Tasca: una entrada concreta i uns criteris d’èxit definits. Exemple: “donat aquest text de suport, classifica el sentiment com a positiu/negatiu/neutre”.
• Trial: una execució de la tasca. Com que el model és no determinista, una sola execució no és suficient per jutjar el comportament, cal múltiples trials (es formalitza a No-determinisme: pass@k i pass^k).
• Avaluador (grader): la lògica que puntua la sortida del model per a cada trial (els tipus es detallen a Tipus d’avaluadors).
• Veredicte (outcome): el resultat final de la tasca, s’ha superat o no (la forma que ha de tenir es tracta a Veredicte binari).

El conjunt de referència (golden set)

El golden set (o conjunt de referència) és el dataset de casos curats manualment amb la sortida esperada que serveix de criteri d’èxit objectiu per al sistema. És l’artefacte central de tota la pràctica d’evals: sense ell, no hi ha manera de saber si un canvi al prompt millora o empitjora el sistema.

La seva importància és estructural:

• Evals offline: és el conjunt sobre el qual s’executen les evals de regressió abans de cada desplegament. Si un canvi trenca un cas del golden set, no es desplega.
• Calibració del LLM-as-judge: per validar que un avaluador automàtic és fiable, es compara amb les etiquetes humanes del golden set. Sense aquestes etiquetes, no hi ha referència per mesurar la fiabilitat del jutge.
• Mesura defensable de qualitat: una mètrica sobre el golden set és un número objectiu i repetible. “Sembla que funciona” no és una mesura; “supera el 94% dels casos del golden set” sí.

La diferència entre un sistema LLM que sembla funcionar i un que demostra que funciona és l’existència d’un golden set. L’antipatró habitual és desplegar sense un, descobrir els errors en producció i no tenir cap mecanisme per verificar que la correcció aplicada funciona.

Un golden set de 20–50 casos ben triats ja és suficient per tenir una baseline útil. La baseline és una mesura de referència del rendiment del sistema sobre el conjunt d’evals (el percentatge de casos que supera en un moment donat), i és contra ella que es comparen els canvis posteriors per decidir si milloren o empitjoren el sistema. El volum no és el factor crític; la cobertura sí. Els casos han de representar els escenaris que el sistema ha de gestionar correctament: casos feliços, casos límit i entrades malicioses o ambigües.

El golden set és el subconjunt del dataset d’evals que actua com a porta d’entrada al desplegament: si un canvi el trenca, no es desplega.

El dataset d’evals té tres tipus de components, amb diferent nivell de confiança i diferent rol:

Dataset d'evals (suite completa)
    ├── Golden set          ← nucli de confiança alta; verificació manual; gate de desplegament
    ├── Fallades de prod.   ← confiança alta; etiquetades a mà quan entren
    └── Casos sintètics     ← confiança baixa; amplien cobertura però no bloquegen desplegament

Anàlisi d’errors

Les evals mesuren si una fallada coneguda torna a aparèixer; no et diuen quines fallades existeixen. Aquest segon problema (descobrir com falla realment el sistema) no el resol cap mètrica automàtica: el resol llegir la sortida real, una traça a una. Aquesta pràctica té nom propi, anàlisi d’errors, i és la baula que alimenta tota la resta de la suite.

El reflex habitual quan un sistema falla és retocar el prompt o provar un model més gran. Però sense haver llegit les traces no saps què estàs intentant arreglar: pots dedicar molts esforços a refinar una regla del system prompt quan la major part de les fallades venien d’un altre mode que ni tan sols havies observat. L’anàlisi d’errors inverteix l’ordre: primer s’observa, després es decideix on intervenir.

El procés

L’anàlisi d’errors és un procediment manual i deliberat, no una eina que s’executa. Tampoc s’externalitza ni es delega a un LLM en aquesta fase: el valor no és la llista de categories sinó el coneixement tàcit del producte que s’adquireix llegint, i això es perd si ho fa una altra persona o un model en lloc teu.

1. Recull una mostra de traces reals. El millor material són les traces de producció amb puntuació baixa o errors (vegeu evals online i observabilitat); a falta de producció, executa el sistema sobre els casos inicials escrits a mà (el seed set, vegeu Fonts de casos) i mira les sortides. 30–50 traces són suficients per començar a veure patrons; com a criteri de parada, segueix llegint fins que unes ~20 traces seguides no aportin cap categoria de fallada nova (saturació).
2. Etiqueta què ha fallat a cada traça. Per a cada cas defectuós, escriu en una frase quin error ha comès, no una categoria predefinida, sinó el que realment veus (“ha inventat una política de devolució”, “ha respost en castellà tot i la instrucció”, “ha citat un fragment irrellevant”). Aquesta etiqueta lliure és l’observació crua. En traces multi-pas, etiqueta la primera fallada de la cadena: els errors posteriors solen ser cascada d’aquest primer, i corregir-lo sovint els fa desaparèixer tots de cop.
3. Agrupa les etiquetes en categories i compta-les. Un cop tens 30–50 etiquetes, modes de fallada similars es col·lapsen en poques categories. Comptar quantes traces cau a cada categoria converteix una pila d’anècdotes en una distribució.
4. Corregeix primer la categoria més freqüent. La fallada que apareix més vegades és la que, un cop resolta, millora més el comportament global del sistema. Quan l’hagis corregida, torna a comptar: la distribució de fallades haurà canviat.

Traces (mostra de prod. o seed set)
    │  llegir una a una
    ▼
Etiqueta lliure per traça defectuosa
    │  agrupar etiquetes similars
    ▼
Categories de fallada + recompte
    │  ordenar per freqüència
    ▼
Arreglar la categoria #1 → re-comptar

El recompte és el pas que sovint s’omet, i és el que dóna sentit a tota la resta. Llegir traces sense comptar només dóna intuïcions disperses (“de vegades al·lucina”); comptar-les converteix aquestes intuïcions en una prioritat clara (“el 40% de les fallades són dates mal interpretades”). El mateix sistema sembla inabordable vist com una pila d’errors heterogenis, i esdevé perfectament tractable quan descobreixes que tres categories expliquen el 80% de les fallades.

El visor de traces

L’anàlisi d’errors es fa molt més ràpida amb una eina mínima per llegir traces còmodament: una vista que mostri prompt, resposta, eines cridades i puntuació en una sola pantalla, amb un camp per anotar l’etiqueta de fallada. No cal res sofisticat (sovint un notebook o una pàgina interna és suficient), però la diferència respecte a llegir logs JSON en brut és gran: és el que fa que llegir 50 traces sigui qüestió de minuts i no d’una tarda. Les plataformes d’observabilitat (LangSmith, Langfuse) ofereixen aquesta vista; muntar-ne una de pròpia sol ser una de les primeres eines de suport al desenvolupament que convé construir.

On encaixa en el cicle

L’anàlisi d’errors és el motor que omple el dataset: cada categoria de fallada que descobreixes es converteix en casos nous del dataset d’evals, de manera que la propera vegada que aquell mode reaparegui, una eval el detecti automàticament. Tanca el cicle amb les evals online: aquestes detecten que alguna cosa ha caigut, mentre que l’anàlisi d’errors explica què ha caigut i prioritza la correcció. Una fallada val per dos: com a cas d’eval (perquè la regressió salti si torna) i com a exemple etiquetat que pots reutilitzar en un prompt més afinat o en un fine-tune.

Com construir el dataset d’evals

Tenir clar QUÈ és una eval no és suficient si no se sap d’on surten els casos de prova. El dataset és la part més valuosa de la suite, i la més difícil de construir bé.

Fonts de casos

Casos escrits manualment (seed set): el punt de partida i el nucli inicial del golden set. Escriu 10–20 casos que cobreixin les situacions que el sistema ha de gestionar correctament: el cas feliç, els casos límit coneguts i les entrades malicioses o ambigües previsibles. Serveixen per tenir una baseline abans de tenir dades reals.

Fallades de producció: la font més valuosa per ampliar el golden set. Cada vegada que el sistema falla en producció (resposta incorrecta, format inesperat, comportament inconsistent), aquell cas s’etiqueta manualment i entra al golden set. Les fallades reals capturen els casos límit que el dissenyador no anticipa; els casos sintètics tendeixen a cobrir els casos fàcils que el model ja resol bé.

Generació sintètica: útil per ampliar la cobertura del dataset general quan falten dades reals, però els casos sintètics no s’incorporen directament al golden set sense revisió manual. Un LLM pot generar variants d’un cas existent (paràfrasis, entrades en idiomes diferents, variacions de format). El risc és que les variants siguin massa similars entre elles i no aportin cobertura nova, així que cal revisar-ne manualment una mostra.

Per evitar aquesta redundància, no generis a partir d’un prompt genèric (“dóna’m 100 consultes d’usuari”). Defineix primer les dimensions que han de variar (tipus d’usuari, intenció, to, idioma, complexitat de la petició). Escriu a mà una vintena de tuples combinant aquestes dimensions i, després, demana a l’LLM que converteixi cada tupla en una consulta en llenguatge natural. Les dimensions forcen una diversitat que un prompt obert no garanteix.

Format del dataset

El format estàndard és JSONL, una línia per cas, fàcil de llegir i d’ampliar incrementalment:

{"input": "El producte va arribar trencat.", "expected": "negatiu", "criteria": "sentiment correcte"}
{"input": "M'ha agradat molt, tornaria a comprar.", "expected": "positiu", "criteria": "sentiment correcte"}
{"input": "El paquet va trigar però el producte és bo.", "expected": "neutre", "criteria": "sentiment correcte quan hi ha valoracions mixtes"}

Cada cas té com a mínim: l’entrada al sistema, el resultat esperat (o un criteri en llenguatge natural per als casos on no hi ha resposta única), i una nota que explica per què aquell cas és rellevant. Aquesta nota és important quan el dataset creix i cal entendre per què un cas va fallar mesos després.

Manteniment del dataset

El dataset no és estàtic. Cal:

• Afegir casos des de producció: cada fallada nova etiquetada via anàlisi d’errors entra al dataset. És el flux continu que evita que la cobertura quedi congelada al moment del disseny.
• Etiquetar els casos per categoria (casos feliços, casos límit, entrades malicioses) per poder analitzar on fallen els canvis de forma selectiva.
• Fer rotació periòdica: un dataset que no s’actualitza envelleix: els usuaris canvien d’hàbits i els casos acaben representant el comportament passat, no el present. Mostrejar tràfic real mensualment i revisar-ne una mostra manualment evita que les evals es converteixin en un fals certificat de qualitat. En la mateixa revisió, elimina els casos que han quedat obsolets per canvis de funcionalitat.

Un dataset de 50 casos ben triats és més útil que un de 500 casos mal etiquetats o redundants.

📝 Les «entrades malicioses» (la injecció de prompt, però també jailbreaks («ets ara un altre model sense restriccions»), exfiltració de secrets/PII, elicitació de contingut nociu o bypass de refús) poden formar un subconjunt adversarial amb la seva pròpia porta de desplegament, separada de la de qualitat (un red-team gate), amb el seu propi llindar (p. ex. «cap injecció no reïx» o una fracció tolerada i documentada). Es manté a part perquè la seguretat falla per motius diferents de la qualitat: un model que extreu perfectament però és vulnerable a injecció no hauria de passar per «qualitat», i un atac reeixit no s’ha de diluir en la mitjana per camp, el mateix argument que avaluar les etapes per separat. La defensa al prompt és probabilística; la porta és el que la fa complir (vegeu Capes de defensa reals).

Tipus d’avaluadors

Avaluador basat en codi: compara la sortida amb un valor esperat de forma determinista. Ràpid, barat i reproduïble. Adequat quan la sortida és estructurada i la correcció és binària.

Avaluador basat en model (LLM-as-judge): un segon LLM avalua la qualitat de la resposta seguint un criteri en llenguatge natural. Flexible i capaç de capturar matisos que el codi no pot. Adequat quan la qualitat és subjectiva o la sortida és text lliure.

def avaluar_qualitat(resposta: str, criteri: str) -> dict:
    resultat = client.chat.completions.create(
        model=MODEL,
        messages=[
            {"role": "system", "content": "Avalua si la resposta compleix el criteri. "
                                           "Retorna JSON amb 'aprovat' (bool) i 'raó' (str)."},
            {"role": "user", "content": f"Criteri: {criteri}\nResposta: {resposta}"},
        ],
        response_format={"type": "json_object"},
    )
    return json.loads(resultat.choices[0].message.content)

Avaluador humà: la referència de qualitat màxima. Lent i car, però necessari per calibrar els avaluadors automàtics i per als casos on cap automatisme és suficient.

La tria de l’avaluador és una decisió de disseny: combinar els tres tipus en una mateixa suite és habitual: codi per als casos estructurats, model per als subjectius, i humans periòdicament per validar que els avaluadors automàtics segueixen sent fiables.

Quin avaluador per a cada tasca

Aquesta combinació no és arbitrària: per a cada tasca, el tipus de sortida dicta quin avaluador és el natural. La regla de fons és si la tasca té una resposta única. Si en té, un avaluador de codi n’hi ha prou; si la sortida és text lliure, cal descompondre-la en unitats verificables (vegeu Dissenyar per a la verificabilitat) o recórrer a un LLM-as-judge per a la part irreductiblement subjectiva.

L’avaluador humà no hi surt com a opció per defecte de cap tasca: és la referència contra la qual es calibren els altres dos, no l’eina de primera línia (vegeu Qui defineix la qualitat).

El veredicte binari per defecte

Sigui quin sigui l’avaluador, una bona opció per defecte és que el veredicte (l’outcome de l’anatomia) sigui binari (passa / no passa) en lloc d’una nota de l’1 al 5. Les escales graduades semblen més informatives, però sovint no ho són tant com prometen: és difícil dir amb precisió què distingeix un 3 d’un 4, les puntuacions tendeixen a acumular-se al mig, i el número resultant no se sol correlacionar amb el que un expert consideraria acceptable. Forçar una decisió binària, en canvi, obliga a definir explícitament què compta com a èxit per a la tasca, que és justament la reflexió que una escala permet ajornar. Quan una tasca sembla que necessita una escala, sovint és senyal que amaga diversos criteris barrejats, i sol anar millor descompondre-la en diverses evals binàries (una per criteri) que col·lapsar-los en un sol número difús.

Aquest principi val per al veredicte d’un cas individual (passa o no passa). És una cosa diferent de dos tipus de mètriques que responen a una altra pregunta: les agregades sobre el conjunt (com el percentatge de casos que el sistema supera) i les diagnòstiques contínues (com les de RAGAS).

Si descompons un cas en diversos criteris binaris, et cal una regla per recombinar-los en el veredicte del cas. Les dues habituals: exigir que tots passin (com una porta de desplegament) o sumar-los amb pesos i fixar un llindar que el cas ha de superar. Els criteris de seguretat o de política solen ser bloquejants: una sola fallada tomba el cas i no es compensa amb la resta.

📝 El binari és el valor per defecte recomanat aquí, no una regla absoluta. Hi ha contextos on una puntuació graduada és legítima: els models de recompensa de l’RLHF donen un escalar per resposta, i una rúbrica amb nivells ancorats a exemples concrets pot evitar el problema del «3 vs 4». El criteri pràctic: si pots ancorar cada nivell amb un exemple i diferents persones hi coincideixen, una escala pot servir; si no, el binari t’estalvia una falsa precisió.

Qui defineix la qualitat

Una eval només és tan bona com el criteri que codifica, i aquest criteri ha de tenir un propietari únic. El patró recomanat és designar una sola persona experta del domini (el clínic per a salut mental, l’advocat per a documents legals, l’agent de suport sènior per a atenció al client) com la veu definitiva de què és una resposta acceptable: és qui etiqueta el golden set i contra qui es calibra el jutge automàtic. Repartir aquesta autoritat entre diversos anotadors introdueix desacords sobre on cau el llindar i acaba en paràlisi; només es justifica quan el domini ho exigeix (per exemple, contextos multilingües o multijurisdiccionals). Aquesta persona no cal que ho etiqueti tot, una mostra representativa n’hi ha prou, però el criteri ha de ser seu.

Biaixos i fiabilitat del LLM-as-judge

El LLM-as-judge és un avaluador potent, però introdueix biaixos sistemàtics que cal conèixer per no confiar-hi cegament.

Biaix de verbositat: el model tendeix a puntuar millor les respostes llargues, fins i tot quan una resposta curta i precisa és superior. Una resposta de tres paraules que respon correctament pot rebre pitjor puntuació que una de tres paràgrafs que “sembla” més completa.

Biaix de posició: en comparacions entre dues respostes (A vs. B), el model sovint afavoreix la que apareix primer, independentment de la qualitat. Invertir l’ordre i prendre la majoria elimina aquest biaix.

Biaix d’autopresència: un model tendeix a puntuar millor les respostes generades per models de la mateixa família. GPT-4 avaluant respostes de GPT-4 pot ser menys crític que avaluant respostes d’un altre proveïdor.

Mitigacions pràctiques

Demanar raonament abans del veredicte: forçar el model a argumentar la seva decisió abans de donar la puntuació final redueix el biaix de posició i verbositat, perquè obliga a considerar la resposta en detall.

{"role": "system", "content": "Primer explica els punts forts i febles de la resposta. "
                               "Després, a la darrera línia, retorna JSON amb 'aprovat' (bool)."}

Comparació en ambdós ordres: si l’eval compara dues respostes, executar-la amb A→B i amb B→A i prendre la majoria elimina el biaix de posició.

Calibrar el jutge contra etiquetes humanes: la forma més rigorosa de validar un avaluador automàtic. Pren un subconjunt del dataset, etiqueta’l manualment (vegeu qui defineix la qualitat) i mesura quant coincideix el jutge amb els humans.

Compte amb una trampa: l’acord brut (percentatge de coincidències) enganya quan les classes estan desequilibrades. Si el 90% dels casos passen, un jutge que digués sempre “passa” tindria un 90% d’acord i seria completament inútil, perquè no detectaria cap fallada. Cal mesurar per separat la capacitat del jutge en cada classe: quina fracció de les fallades reals detecta i quina fracció dels casos bons no marca per error.

def fiabilitat_jutge(humans: list[bool], jutge: list[bool]) -> dict:
    # convenció: True = passa; el que ens importa és detectar les fallades (False)
    reals_fallen = [(h, j) for h, j in zip(humans, jutge) if not h]
    reals_passen = [(h, j) for h, j in zip(humans, jutge) if h]
    detecta_fallades = sum(not j for _, j in reals_fallen) / len(reals_fallen)
    respecta_bones = sum(j for _, j in reals_passen) / len(reals_passen)
    return {"detecta_fallades": detecta_fallades, "respecta_bones": respecta_bones}

La taxa rellevant és detecta_fallades: un jutge amb acord global alt però que se’n deixa la meitat de les fallades no serveix per al que el necessites. Si aquesta taxa cau (per sota de ~0,8, posem per cas), cal redissenyar el prompt del jutge, canviar de model o recórrer a avaluació humana.

Panell de jutges: en lloc d’un sol LLM-as-judge, executar el mateix criteri amb múltiples jutges de famílies diferents (p.ex. un de Claude, un de GPT, un de Gemini) i agregar els veredictes per majoria. Aborda especialment el biaix d’autopresència: un jutge de la mateixa família que el sistema avaluat tendeix a puntuar-lo millor. El desacord entre jutges és, en si mateix, un senyal; els casos on els jutges es divideixen s’envien a revisió humana en lloc de forçar una majoria. El cost és proporcional al nombre de jutges, cosa que limita el panell a la suite ràpida o als casos crítics. La suite nocturna completa sol usar un jutge únic ben calibrat.

Mostreig repetit (self-consistency): en lloc de cridar el jutge una sola vegada, executa’l N vegades sobre el mateix cas i pren el veredicte majoritari. La fracció de crides que coincideixen amb la majoria és una mesura de certesa: si les 5 execucions donen el mateix veredicte, el jutge és consistent amb si mateix; si es divideixen, el cas és candidat a revisió humana. És la tècnica coneguda com self-consistency, originalment proposada per millorar el raonament multi-pas, aplicada aquí no per triar la resposta sinó per detectar quan no fiar-se’n.

No cal maximitzar N: la major part del valor discriminatiu sol aparèixer amb poques repeticions (2–5), i cada repetició addicional és cost pur. El llindar de certesa per sota del qual es marca un cas per a revisió (p. ex. certesa < 0.8) s’ha de calibrar contra el golden set, igual que el llindar de detecta_fallades de la secció anterior.

La diferència amb el panell de jutges: aquí la diversitat ve de repetir el mateix model, no de combinar models diferents (més barat, però no aborda el biaix d’autopresència que el panell sí ataca). Les dues tècniques es poden combinar (N repeticions × M jutges), que és exactament l’ensemble descrit a l’estudi de referència sobre correcció d’exàmens amb LLM (vegeu Referències).

📝 El mostreig repetit només mesura com de segur està el model del seu propi veredicte; no detecta si el criteri de la rúbrica és ambigu o mal formulat. Aquest segon problema es descobreix per anàlisi d’errors, no per repetició.

Dissenyar per a la verificabilitat

El cost d’avaluar no és una propietat fixa del sistema: depèn de com es dissenya la sortida. Un assistent que respon “He actualitzat la teva reserva” obliga a refer la feina per comprovar si ha encertat: consultar la reserva, validar les dates, mirar el preu. El mateix assistent que respon amb l’itinerari resultant, els supòsits que ha fet (“he assumit sortida al matí”) i les fonts que ha consultat es pot verificar d’un cop d’ull. La sortida verificable no canvia el que fa el model; canvia quant costa jutjar-lo.

Aquesta propietat té un efecte directe sobre les evals. Una sortida que exposa els seus artefactes verificables (els supòsits, les fonts, els passos intermedis que un expert miraria de forma natural) abarateix les dues operacions més cares de tota la pràctica:

• L’etiquetatge humà de l’anàlisi d’errors: llegir una traça que ja mostra els passos intermedis és qüestió de segons; reconstruir-los a partir d’una resposta opaca és el que converteix l’etiquetatge en una tarda.
• El grading automàtic: quan la sortida es descompon en unitats verificables, un avaluador basat en codi pot comprovar cada unitat per separat, en lloc de delegar tota la decisió a un LLM-as-judge sobre text lliure (més car i subjecte als biaixos de la secció anterior).

Dit d’una altra manera: la verificabilitat és una palanca que controles des del disseny del producte, no només des de la tria de l’avaluador. Trencar un flux en unitats més petites i comprovables millora alhora la usabilitat (l’usuari confia perquè pot comprovar) i la tractabilitat de les evals. Aquesta és, de fet, la mateixa lògica que separa el resultat final de la trajectòria en un agent, generalitzada a qualsevol sortida.

Dues tàctiques concretes que en deriven:

• Ancorar la sortida a un punt de partida de confiança. En lloc de generar un resultat des de zero i demanar que es jutgi sencer, parteix d’una base ja validada (un pla revisat, una anàlisi existent) i ressalta només els canvis. Així tant l’usuari com l’avaluador inspeccionen un diff petit i acotat, no un artefacte sencer. És la mateixa lògica de les evals de regressió sobre el golden set, aplicada a la sortida individual.
• Exposar la incertesa com a unitats accionables. Quan el sistema no ha pogut verificar alguna cosa, o quan un resultat contradiu les fonts, val més marcar-ho explícitament que presentar-ho com a resolt. Aquestes marques es converteixen en objectius d’eval naturals (es pot comprovar que el sistema avisa quan toca) i en etiquetes d’anàlisi d’errors directes.

D’aquí en surt una qüestió d’ordre: dissenyar per a la verificabilitat va abans de construir les evals, no després. Si una sortida és difícil de verificar per a tu, gairebé sempre ho serà també per a l’usuari i per a qualsevol avaluador automàtic. Val més reduir aquesta superfície des del disseny que intentar cobrir-la a posteriori amb una bateria de jutges més sofisticats.

No-determinisme: pass@k i pass^k

Com que el model pot donar respostes diferents per a la mateixa entrada, cal executar cada tasca múltiples vegades (trials) i agregar els resultats. Hi ha dues mètriques complementàries. pass@k és estàndard en benchmarks de codi (HumanEval, SWE-bench); pass^k és una extensió menys universal, útil com a eina conceptual per raonar sobre fiabilitat en producció, però no sempre trobada amb aquesta notació a la literatura.

Imagina una tasca que el sistema supera 9 de cada 10 execucions. Si l’executes 10 vegades, gairebé segur que alguna passa (pass@10 ≈ 1,0), però que passin totes deu és tota una altra cosa: 0,9¹⁰ ≈ 0,35. El mateix sistema sembla excel·lent amb una mètrica i mediocre amb l’altra:

• pass@k: la probabilitat que almenys un dels k trials superi l’eval. Mesura el potencial del sistema: pot resoldre la tasca?
• pass^k: la probabilitat que tots els k trials la superin. Mesura la fiabilitat en producció: sempre la resol?

Per a sistemes en producció, la mètrica rellevant és pass^k: un sistema que resol una tasca el 60% de les vegades no és desplegable. Quan pass@k és alt però pass^k és baix, el sistema pot resoldre la tasca però no de forma consistent, normalment un senyal que el prompt és ambigú o que cal sortida estructurada.

El mateix mecanisme de trials repetits, aplicat no al sistema avaluat sinó al jutge que l’avalua, és la base del mostreig repetit descrit a Mitigacions pràctiques.

Evals d’agents

Avaluar un agent és més complex que avaluar una crida única, perquè hi ha dos nivells a jutjar:

Resultat final: l’agent ha assolit l’objectiu? Aquesta és la mètrica principal, equivalent a un avaluador de torn únic sobre l’estat final del sistema.

Trajectòria: ha pres el camí adequat? Ha cridat les eines correctes? Ha evitat passos innecessaris? Un agent que arriba a la resposta correcta fent crides redundants o innecessàries no és un agent eficient ni fiable.

Eval d'agent
    ├── Resultat final     → avaluador de codi o model sobre l'output
    └── Trajectòria        → inspecció del transcript: eines cridades, ordre, arguments

El transcript (el registre complet de la conversa incloent totes les crides a eines i els seus resultats) és la unitat d’anàlisi per a les evals d’agents. Llegir transcripts regularment és la manera més ràpida de detectar patrons de fallada que els avaluadors automàtics no capturen, és l’anàlisi d’errors aplicada a la trajectòria de l’agent.

Evals per a RAG

Els sistemes RAG presenten un repte d’avaluació específic: hi ha dues etapes que poden fallar de forma independent, i una eval global sobre la resposta final no distingeix on és el problema.

Consulta de l'usuari
        │
        ▼
  Recuperació         ← pot fallar: fragments poc rellevants
        │
        ▼
  Generació           ← pot fallar: resposta infidel als fragments
        │
        ▼
  Resposta final

Les tres mètriques del marc RAGAS cobreixen aquest espai:

Aquestes són les tres mètriques del marc original. La llibreria actual de RAGAS divideix la context relevance en dues mètriques més fines, Context Precision i Context Recall, però la lògica de diagnòstic és la mateixa.

Per què avaluar les dues etapes per separat

Una resposta final correcta no implica que el sistema funcioni bé: pot ser que el model hagi respost correctament malgrat haver recuperat fragments poc rellevants (perquè la resposta era trivial). Inversament, una resposta incorrecta pot deure’s a una recuperació deficient o a una generació infidel, i el remei és diferent en cada cas.

Context relevance baix  → problema de recuperació: ajustar l'embedding, la query o el chunking
Faithfulness baixa      → problema de generació: el model al·lucina o ignora el context
Answer relevance baixa  → la resposta no respon la pregunta: problema de prompt o de tasca mal definida

Avaluar les tres mètriques per separat permet diagnosticar on falla el sistema i aplicar la solució correcta.

El cicle de millora dirigit per evals

Les evals no són una verificació puntual: són el mecanisme de feedback que fa sostenible l’evolució del sistema. El cicle no se centra en el prompt: se centra a aplicar, a cada iteració, la intervenció que la categoria de fallada demana.

1. Captura el cas: quan l’anàlisi d’errors revela una fallada nova, afegeix-la al dataset d’evals abans d’intentar resoldre-la, així el remei és verificable (escriure el test primer).
2. Mesura la baseline: executa les evals sobre la versió actual.
3. Aplica la palanca de millora més barata que ataqui la categoria de fallada que l’anàlisi d’errors ha prioritzat, no necessàriament el prompt. Vegeu Les palanques de millora.
4. Re-executa les evals i compara amb la baseline.
5. Decideix: si millora i no trenca cap cas del golden set, desplega; si empitjora, reverteix o prova una altra palanca.

📝 Cada cop més, el pas 3 no és del tot manual: els optimitzadors de prompts dirigits per evals (com GEPA a DSPy) consumeixen tant la puntuació com el feedback de les traces per fer evolucionar el prompt automàticament, en lloc d’editar-lo a mà. L’eval deixa de ser només la porta de validació i passa a ser el senyal d’optimització.

La baseline i el golden set no s’actualitzen dins del cicle: es mouen de forma deliberada en desplegar una versió nova (vegeu Avaluació), mai automàticament a cada correcció: si la porta es mou cada vegada que arregles alguna cosa, la mètrica deriva i deixa de ser una referència.

Un conjunt inicial de 20–50 casos derivats de fallades reals és més valuós que centenars de casos sintètics (vegeu Fonts de casos).

📝 Per a una visió detallada de les evals d’agents, incloent la distinció entre avaluadors de codi, model i humans, i la interpretació de pass@k en sistemes reals, consulta l’article d’Anthropic Demystifying Evals for AI Agents.

Les palanques de millora

Quan el pas 3 del cicle demana “aplicar una intervenció”, hi ha tot un ventall d’opcions, no només reescriure el prompt. Estan ordenades de la més barata i ràpida d’iterar a la més costosa, i la tria no és lliure: la dicta la categoria de fallada que l’anàlisi d’errors ha identificat. Reescriure el prompt no arregla una fallada de recuperació, igual que canviar de model no arregla un context mal construït.

• Prompt i exemples few-shot: reescriure les instruccions, afegir restriccions de format o incloure exemples que fixin el comportament. És la primera palanca per a fallades de format, to o casos ambigus. Vegeu Prompts i integració.
• Recuperació: quan la fallada és context incorrecte o absent: revisar el chunking, el model d’embeddings, el reranking o la cerca híbrida. Cap reescriptura del prompt arregla un fragment que mai s’ha recuperat. Vegeu Evals per a RAG.
• Context engineering: què entra a la finestra i en quin ordre: filtrar soroll, prioritzar el que importa, evitar el context rot. Ataca fallades on la informació hi era però el model no l’ha feta servir.
• Eines i scaffolding de l’agent: en sistemes agentics, canviar la maquinària que el model opera (quines eines té, el bucle de decisió, les condicions de parada) en lloc del text del prompt. Ataca fallades de trajectòria (eines mal triades, passos redundants, bucles sense fi) que cap reescriptura resol. Vegeu Evals d’agents.
• Canvi de model: provar un model més capaç o un de raonament. Útil quan la tasca supera la capacitat del model actual, però rarament és la causa real: la majoria de fallades viuen al context, no als pesos. Un model més gran sovint només entrega la mateixa resposta incorrecta amb més fluïdesa.
• Fine-tuning: últim recurs, quan cap de les anteriors n’hi ha prou i s’han acumulat prou dades etiquetades. Car i lent d’iterar. Vegeu Sistemes LLM en producció.

Offline i online

El cicle anterior s’executa abans de desplegar, sobre el dataset fix de la suite: són les evals offline, deterministes i bloquejants. Detecten regressions conegudes, és a dir, casos que el sistema resolia bé i que un canvi ha trencat. Però el mateix mecanisme també s’aplica un cop el sistema és en producció. Les evals online s’executen de forma asíncrona sobre una mostra del tràfic real, no bloquegen el desplegament i destapen modes de fallada que ningú havia anticipat. Les fallades que troben tornen al dataset offline com a casos nous, i així el cicle es realimenta.

Dit d’una altra manera: les offline responen a “hem trencat alguna cosa?”; les online, a “hi ha alguna cosa que no sabíem que podia fallar?”. La mecànica operativa de les evals online (mostreig, jutge asíncron, alertes) es desenvolupa a Sistemes LLM en producció.

Referències

• Wang et al. (2023). Self-Consistency Improves Chain of Thought Reasoning in Language Models.
• Korthals et al. (2026). Towards Reliable LLM Grading Through Self-Consistency and Selective Human Review. Disponible a https://www.mdpi.com/2504-4990/8/3/74 (repositori: https://github.com/lukekorthals/sure).