Agentul reușește o dată? Testul trebuie să includă și erori de API

Înainte de producție, testează agentul AI pe sarcini reale cu rezultat verificabil, repetă fiecare execuție și injectează controlat erori de API. O încercare reușită arată că agentul poate îndeplini sarcina; nu arată cât de consecvent o face sau ce se întâmplă când un instrument răspunde incomplet.

Evaluează fluxul complet, de la cererea utilizatorului până la starea finală a sistemului. Pentru fiecare caz, stabilește înainte de rulare rezultatul acceptat, modificările interzise și comportamentul corect dacă serviciul extern nu poate confirma operația.

Definește rezultatul care poate fi verificat

Alege un flux îngust, reprezentativ pentru produs. În exemplul ipotetic de aici, agentul gestionează programări; într-un produs de suport sau comerț, înlocuiește rezervarea cu obiectul pe care agentul îl consultă ori îl modifică. Fiecare caz are nevoie de o cerere, o stare inițială cunoscută și un criteriu pentru starea finală.

Răspunsul „Am făcut programarea” nu dovedește că operația a reușit. Verificatorul trebuie să găsească în calendar rezervarea corectă, pentru persoana și intervalul cerute, fără duplicat. Dacă utilizatorul nu are permisiunea necesară, rezultatul corect este refuzul fără modificarea calendarului. Folosește verificări automate pentru stări și efecte secundare care pot fi inspectate; păstrează evaluarea umană pentru calitatea formulării sau pentru cazurile cu criterii mai greu de formalizat.

Pregătește și o soluție de referință pentru fiecare caz: un rezultat despre care știi că ar trece verificatorul. Dacă un caz valid nu poate trece, corectează datele de test sau criteriul înainte să interpretezi eșecul agentului.

Construiește o suită inițială cu 24 de cazuri

Lista de mai jos este o propunere de acceptanță pentru agentul ipotetic de programări. Grupează cazurile după comportamentul pe care îl urmăresc și resetează calendarul la aceeași stare înaintea fiecărei încercări. Verifică de fiecare dată atât mesajul către utilizator, cât și modificările efective.

Operații obișnuite:

• Rezervă un interval liber indicat explicit.
• Găsește și rezervă primul interval care respectă preferința cerută.
• Mută o rezervare și eliberează intervalul vechi.
• Anulează o rezervare existentă.
• Verifică o rezervare fără să o modifice.
• Propune o alternativă când intervalul cerut este ocupat.

Limite ale cererii sau ale stării:

• Intervalul devine ocupat între căutare și confirmare.
• Noua cerere se suprapune peste o rezervare existentă.
• Data cerută este invalidă.
• Fusul orar este ambiguu și cere clarificare.
• Lipsește un participant obligatoriu.
• Utilizatorul cere modificarea unui calendar fără permisiune.

Reformulări ale unor intenții deja testate:

• Cererea de rezervare este foarte scurtă, dar completă.
• Aceeași cerere folosește o formulare colocvială în română.
• Data și ora apar în altă ordine.
• Mutarea se referă la „întâlnirea de mâine”, identificabilă în datele de test.
• Anularea este cerută printr-un sinonim.
• Căutarea unui interval este exprimată ca restricție de disponibilitate.

Defecte injectate la apelurile instrumentelor:

• API-ul de căutare nu răspunde până la expirarea timpului permis.
• API-ul de creare salvează rezervarea, dar confirmarea expiră.
• Căutarea primește o limitare temporară a cererilor.
• Crearea primește o limitare temporară și necesită o decizie sigură privind reluarea.
• Lista intervalelor libere sosește incompletă.
• Confirmarea rezervării conține doar o parte dintre câmpurile așteptate.

Pentru reformulări, rezultatul așteptat trebuie să rămână același ca în cazul de bază. Pentru un răspuns parțial, agentul trebuie să obțină o confirmare verificabilă sau să spună că operația rămâne neconfirmată; completarea prin presupunere a datelor lipsă nu trece testul.

Păstrează urma completă a fiecărei încercări

Ghidul OpenAI pentru evaluarea agenților recomandă examinarea urmelor complete în etapa de diagnosticare, apoi folosirea seturilor de date și a rulărilor de evaluare pentru comparații repetabile. Urma include apelurile modelului și ale instrumentelor, precum și pașii intermediari; mesajul final nu arată singur unde a apărut defectul.

Înregistrează identificatorul cazului, versiunea agentului, intrarea, starea inițială, apelurile și răspunsurile instrumentelor, defectul injectat, starea finală, verdictul și durata. Protejează datele sensibile din înregistrări. La un eșec, aceste informații permit să distingi o decizie greșită a agentului de o întrerupere a API-ului, o reluare nesigură sau un verificator configurat incorect.

Compară reușita inițială cu reușita repetată

Ghidul Anthropic despre evaluări distinge între pass@1, reușita la prima încercare, și pass^k, reușita în toate cele k încercări ale unei sarcini. Recomandă să pornești de la sarcini pe care echipa le testează deja manual și să le rulezi în medii izolate, astfel încât starea rămasă dintr-o încercare să nu influențeze următoarea.

Pentru suita propusă, rulează fiecare caz de trei ori, cu aceeași versiune a agentului și cu datele resetate. Prezintă alăturat cele două rezultate:

• pass@1: proporția cazurilor care trec la prima rulare. Un caz trecut o dată contribuie la acest rezultat chiar dacă eșuează ulterior.
• pass^3: proporția cazurilor care trec în toate cele trei rulări. Un caz trecut de două ori și eșuat o dată nu contribuie la acest rezultat.

Arată separat rezultatele pentru operațiile obișnuite, reformulări și defecte. O singură medie poate ascunde faptul că agentul rezolvă cererile normale, dar creează duplicate după întreruperea unei confirmări. Înregistrează și durata, numărul de apeluri și costul pe sarcină, raportate la limitele stabilite de produs.

Injectează erorile și fixează pragul de oprire

În studiul ReliabilityBench, două modele combinate cu două arhitecturi de agent au fost evaluate în 1.280 de episoade din domenii care includ programările; reformulările sarcinilor au redus rata de succes raportată de la 96,9% la 88,1%. Benchmarkul include și erori controlate ale instrumentelor, precum timeouturi, limitări ale cererilor și răspunsuri parțiale. Procentele descriu configurațiile și condițiile acelui experiment, nu fiabilitatea agentului din acest exemplu.

Injectează fiecare defect la un pas cunoscut și scrie dinainte rezultatul admis. După un timeout la citire, agentul poate relua apelul în limita stabilită sau poate opri operația. După un timeout la scriere, verifică mai întâi dacă rezervarea există deja: repetarea directă a cererii ar putea crea un duplicat. Dacă API-ul oferă o cheie de idempotentă, testează folosirea ei; dacă nu, verificarea stării devine esențială înainte de orice reluare.

Ca prag de acceptanță pentru această suită mică, oprește lansarea la orice modificare neautorizată, rezervare duplicată, confirmare falsă sau încercare fără urmă completă. Cere trecerea tuturor cazurilor în toate rulările planificate; în scenariile de defect, oprirea sigură și informarea corectă a utilizatorului pot constitui rezultatul reușit. Acest prag este o decizie de produs pentru cazurile alese, nu o estimare statistică a fiabilității în producție.

Citește și:

• Agentul AI citește un document ostil: filtrul de prompt nu este suficient
• Ce modele stăpânesc gramatica română: 48% din explicații au erori
• Kyndred atrage 500.000 €: companionul AI trebuie să dovedească retenția