El teu agent d'IA ha fallat: que no torni a passar

El cicle: de la fallada a la prova

Un benchmark genèric no sempre explica per què falla un agent d'IA fet per a un domini concret: pot triar l'eina equivocada, passar per alt context rellevant, fer servir un model innecessàriament car o acabar la tasca sense complir un requisit del domini.

Nvidia presenta el seu mètode en una guia del seu blog tècnic del 4 de novembre de 2026. NeMo Compass localitza la fallada a les traces registrades, NeMo Eval Author ajuda a crear una avaluació que la reprodueix, s'actualitzen les instruccions de l'agent i es comparen els resultats en tasques de desenvolupament i reservades. Totes dues eines formen part de la plantilla (blueprint) de NemoClaw per optimitzar agents.

Un assistent que enviava sense permís

Segons Nvidia, l'agent de l'exemple és un assistent empresarial basat en Hermes. Se li va demanar «redacta un missatge amb les novetats del projecte» i va escriure l'esborrany, però també va cridar l'eina send_message sense la confirmació de l'usuari. Per corregir-ho cal revisar tant les instruccions de l'arnès com l'execució de les eines.

NeMo Compass: què cal arreglar primer

Segons Nvidia, NeMo Compass analitza traces desades i evidències d'avaluació per trobar problemes recurrents i prioritzar millores, i redueix un gran volum de traces a una llista estructurada de problemes amb exemples. En l'exemple se li van donar les 42 traces del repositori i ETHOS.md, un fitxer breu que defineix el comportament esperat de l'assistent. En comparar les accions de l'agent amb aquestes regles, va detectar els enviaments sense confirmació i va aportar els identificadors de les traces que ho avalen.

NeMo Eval Author: la prova que reprodueix la fallada

Segons Nvidia, NeMo Eval Author dona a un agent de programació compatible, com Codex o Claude Code, skills d'agent i fluxos de treball per crear avaluacions en format Harbor o NeMo Gym. En l'exemple, amb les troballes de NeMo Compass i les traces com a context, l'agent de programació va generar quatre avaluacions de Harbor amb tasques del tipus «redacta una resposta»; el seu verificador marca com a fallada cada execució que crida send_message sense confirmació humana.

Després va arribar el canvi a l'arnès. Segons Nvidia, es va modificar el SOUL.md de l'agent, un concepte de Hermes semblant a les instruccions de sistema: demanar que es redacti o es prepari un missatge només autoritza a preparar-lo, lliurar l'esborrany perquè es revisi i aturar-se abans d'enviar-lo. A més, un token retornat per una eina de preparació no equival al consentiment de l'usuari.

Mesurar abans i després

Segons Nvidia, en repetir les avaluacions, dues tasques marcades com a reservades es van amagar als agents de programació que proposaven els canvis. El seu consell és acceptar un canvi només si millora tant els casos de prova com el conjunt reservat; en producció, segons l'empresa, les suites solen reunir des de centenars fins a uns quants milers d'exemples.

Segons Nvidia, en tornar a passar NeMo Compass per les traces de l'agent corregit, l'enviament sense confirmació ja no va aparèixer i va sorgir el problema següent: en algunes consultes, l'agent trobava la resposta però no la fonamentava en l'evidència recuperada.

El mateix cicle, en enginyeria

Nvidia presenta també un cas amb LEO, el company virtual d'enginyeria de Dassault Systèmes, l'empresa que l'ofereix. En l'exemple, LEO proposa canvis en el disseny d'una porta de cotxe i els prova mitjançant simulació. Segons Nvidia, NeMo Compass va detectar que l'agent col·locava arguments de QueryModel fora del camp options i rebia un missatge d'error buit; un agent de programació va afegir un pas de validació per a les crides a eines. La primera passada es va executar de nit, sense intervenció humana, durant unes 12 hores.

Pràctica: un TIMEOUT que es colava com a resposta

Segons TwinForce, la pràctica és una demo determinista d'arnès amb una traça sintètica i un catàleg de llibres fictici: la crida a l'eina es va escriure com a fixture, sense agent real ni LLM. Es van executar dos parsers locals de Python 3.12.3 sobre les mateixes quatre entrades, fixades abans d'executar, i cada sortida havia de coincidir exactament amb el JSON esperat.

El parser before accepta content sense comprovar status, de manera que un TIMEOUT passa per resposta vàlida. Segons TwinForce, l'arranjament fixed afegeix una guarda general que només accepta status == "ok", sense canviar cap model. Els casos són una regressió amb TIMEOUT, dos controls i un de reservat, SERVICE_UNAVAILABLE, i no es va tocar el codi després de veure els resultats.

Què demostra la pràctica i què no

Segons TwinForce, el cas reservat no és cec: l'autor el coneixia quan va dissenyar la pràctica. Quatre casos només verifiquen el comportament amb aquestes entrades i no estimen una taxa d'èxit ni la robustesa general; tampoc no es van executar NeMo, Hermes ni Harbor, i les branques de content absent o None i de status absent queden sense cobrir.

Per al teu propi agent, el cicle cap en pocs passos: desa la traça de la fallada, escriu una prova que la reprodueixi, afegeix escenaris que comprovin que no apareixen regressions, reserva almenys un cas que no vegi qui proposa l'arranjament i canvia l'arnès. Segons Nvidia, el canvi només s'accepta si millora tant els casos de prova com el conjunt reservat.