Els evals són l'única suite de regressió que un sistema d'IA et donarà
No pots escriure assertEquals contra un sistema que no retorna la mateixa resposta dues vegades. Tots els equips que construeixen sobre un LLM ho descobreixen la primera setmana — i la majoria hi reacciona deixant d'escriure tests.
Fa dues dècades que treballo en sistemes on la suite de regressió era el contracte. Si el CI estava en verd, desplegaves; si un canvi trencava comportament, la build vermella l'atrapava abans que un client. Després vaig començar a posar en producció funcionalitats sobre LLMs i aquell contracte va saltar pels aires. La temperatura zero no el restaura: amb inferència per lots i acumulació en coma flotant, el mateix prompt pot produir dimarts tokens diferents dels de divendres. La caixa d'eines determinista — fixtures, snapshots, assercions exactes — testeja el 20% del sistema que no s'havia de trencar mai.
La conclusió habitual és que els sistemes d'IA no es poden testejar, així que es llança i es vigilen dashboards. Jo crec que és just al revés. Els sistemes d'IA sí que es poden testejar — la disciplina existeix, se'n diu evals, i els equips que la tracten amb el mateix rigor que el CI són els que tenen agents que sobreviuen al contacte amb producció. A l'últim post de la nostra sèrie sobre loops agèntics defensava que el loop és el 20% fàcil i els guardrails el 80% restant. Els evals són la meitat d'aquest 80% que gairebé tothom se salta.
Una actualització de model és un bump de dependència que ningú no revisa
Comencem per què hi ha regressions en un sistema que no has tornat a desplegar. El comportament de la teva funcionalitat d'IA és funció d'almenys quatre entrades que canvien cadascuna pel seu compte:
- El model. Els proveïdors reentrenen i canvien el model que hi ha darrere d'un àlies estable. El model contra el qual vas afinar el prompt al març no és el que serveix les respostes al juliol, i cap changelog no et dirà què ha canviat.
- El prompt. Cada edició del prompt és un desplegament. Equips que exigeixen revisió per tocar una línia de configuració deixen passar un canvi de 40 línies al system prompt amb un vistiplau a Slack.
- El context. Si fas retrieval, l'índex RAG muta cada dia a mesura que entren documents. Mateix prompt, mateix model, grounding diferent — resposta diferent.
- Les eines. Canvia el nom d'un paràmetre a l'esquema d'una tool i l'agent que feia mesos que la cridava bé comença a jugar a endevinar.
Cadascuna d'aquestes coses és un desplegament que cap test no vigila. En software clàssic en diríem entrega contínua sense pipeline. Aquest és el forat que cobreix la suite d'evals: un conjunt fix de casos, executat a cada canvi, que et diu si el comportament ha canviat.
El golden dataset és l'spec que mai no vas escriure
Una suite d'evals comença per un golden dataset: entrades reals amb el comportament esperat etiquetat. La paraula clau és reals. L'error que em segueixo trobant en auditories és el golden set construït a partir del guió de la demo — vint casos impecables que l'equip s'ha inventat, tots en verd, mentre la funcionalitat es degrada amb el trànsit que els usuaris envien de veritat.
Construeix-lo amb traces de producció. Captura totes les interaccions des del primer dia — entrades, context recuperat, crides a eines, sortides — i seu a etiquetar-ne un centenar. És feina de picar pedra, i és també on es defineix el producte: en el moment que algú ha de deixar per escrit quin és el comportament correcte per a un cas real i brut, afloren tots els desacords que l'equip portava mesos ajornant. El golden dataset és l'spec que mai no vas escriure, extreta cas a cas.
Després, ordena les assercions per cost. Primer les deterministes: la sortida parseja com a JSON, s'ha cridat l'eina correcta, l'import del reemborsament queda per sota del topall de la política, no apareix cap adreça de correu a la resposta. Costen mil·lisegons i no admeten discussió — i «comportar-se bé» es redueix a això més sovint del que sembla. Després les semàntiques, per als judicis que el codi no pot fer: si la resposta estava ancorada al context recuperat, si el to era l'adequat, si va declinar la petició fora d'abast. Aquí entra el jutge.
Un jutge LLM és un revisor que també has de revisar
Fer servir un model frontera per puntuar les sortides del teu sistema ja és pràctica estàndard, i el resultat fundacional s'aguanta: el paper d'MT-Bench (Zheng et al., NeurIPS 2023) va mesurar una concordança de GPT-4 amb avaluadors humans per sobre del 80% — la mateixa que assoleixen els humans entre ells. Un model jutge és l'única manera escalable de puntuar semàntica.
També és un component amb els seus propis modes de fallada, documentats al mateix paper: biaix de posició (preferir la resposta que ha vist primer), biaix de verbositat (premiar respostes llargues al marge de la qualitat), biaix d'autopromoció (afavorir text que s'assembla a la seva pròpia sortida). Un jutge és un revisor que encerta gairebé sempre — i que, quan s'equivoca, ho fa amb sistema i sempre cap al mateix costat.
Així que revises el revisor. Calibra el jutge contra una mostra d'etiquetes humanes — amb vint o trenta casos n'hi ha prou per mesurar concordança — i tracta qualsevol caiguda d'aquesta concordança com una build vermella. Fixa la versió del model del jutge igual que fixes qualsevol dependència, i recalibra quan l'actualitzis, perquè un canvi de jutge t'altera les mètriques sense que canviï res al sistema mesurat. He vist un equip celebrar una millora de cinc punts de qualitat que tenia una sola causa: un jutge que s'havia tornat més indulgent.
Quatre maneres com un eval et menteix
Una execució en verd és un indici, no una prova. L'objecció més seriosa a tot això és que les suites d'evals acaben sent teatre — un conjunt fix de casos que aprova sempre mentre el producte es degrada. Aquest mode de fallada existeix, i opera per quatre mecanismes:
- Sobreajust al golden set. Afina el prompt contra els mateixos cent casos durant sis mesos i hauràs entrenat sobre el teu test set — la llei de Goodhart de manual. Reserva una porció hold-out que els autors del prompt no vegin mai.
- Deriva del jutge. El que ha canviat és el corrector, no el sistema. Versió fixada i calibratge, com abans.
- Fuites. Casos daurats que acaben enganxats al prompt com a exemples few-shot, i l'eval passa a mesurar memorització. Controla d'on surt cada cas i on acaba fent-se servir.
- Obsolescència. El teu trànsit ha canviat i el golden set no. L'eval segueix certificant el rendiment sobre el problema del trimestre passat.
La contramesura per als quatre és la mateixa: mantenir viu el dataset. Alimenta'l cada mes amb traces de producció, retira els casos que ja no representen el trànsit, i converteix les fallades que trobis en producció en els casos de regressió del mes següent — la mateixa disciplina d'afegir un test per cada bug.
Munta-ho com un CI, no com un projecte de recerca
La mecànica, en concret:
- Bloqueja els canvis. Edicions de prompt, canvis d'esquema d'eines i configuració de retrieval entren per pull request i disparen la suite. Una caiguda material de puntuació bloqueja el merge, igual que un test unitari en vermell.
- Executa cada nit contra l'àlies viu. El teu model fixat és el que has testejat; l'àlies del proveïdor és el que serveixes. Una execució nocturna contra tots dos és la manera d'assabentar-te que alguna cosa ha canviat per sota abans que se n'assabentin els teus usuaris.
- Mostreja producció. Passa un 1–5% del trànsit real pel jutge, en asíncron, i alerta sobre la deriva setmana contra setmana. És la comprovació que el golden set no pot fer: atrapa la regressió en el trànsit que no havies previst.
- Pressuposta-ho amb honestedat. Puntuar 200 casos amb un model frontera costa pocs dòlars per execució. La retrospectiva d'un sol incident de producció costa més que un any d'evals nocturns.
Res d'això no exigeix eines exòtiques — harnesses open source com promptfoo o OpenAI Evals cobreixen la mecànica — perquè el difícil no ha estat mai el runner. És el dataset etiquetat i l'hàbit.
Què faria aquest trimestre si fos el teu CTO
- Activa avui la captura de traces. Entrades, context, crides a eines, sortides, versió del model. Tota la resta depèn que aquestes dades existeixin.
- Etiqueta 100 casos daurats a partir de traces reals. Producte i enginyeria a la mateixa sala. Pressuposta-hi dos dies; les discussions que provoca són l'entregable.
- Posa la suite al CI. Els canvis de prompt hi queden bloquejats. Si els teus prompts no són a control de versions, aquest és el pas zero.
- Calibra el jutge cada mes. Vint casos etiquetats per humans, mesura la concordança, fixa la versió del jutge.
- Mostreja un 2% de producció a través del jutge amb una alarma de deriva. Quan salti, les traces que fallin es converteixen en nous casos daurats.
Un sistema que mai no es comporta igual dues vegades pot, tot i així, retre comptes davant d'un estàndard. Només cal escriure aquest estàndard i comprovar-lo a cada canvi — que és, al capdavall, l'únic que ha estat mai una suite de regressió. Els equips que tenen agents fiables en producció no són els que tenen millors models. Són els que van reconstruir la seva disciplina de testing per a un component probabilístic en lloc d'abandonar-la.
Si estàs muntant aquesta disciplina i necessites enginyers que l'hagin operat en producció — golden sets, calibratge de jutges, CI bloquejat per evals — això és el que fan els nostres enginyers LLM.
