Agenții AI se blochează rareori. Eșuează în tăcere, iar cercetările explică de ce

Agenții bazați pe modele lingvistice mari răspund acum la solicitări de asistență, interoghează baze de date și planifică călătorii. Când ceva nu merge bine, de obicei oferă un răspuns sigur pe sine și un cod de succes. Un număr tot mai mare de cercetări explică de ce aceste eșecuri sunt greu de observat și cum învață echipele de inginerie să le măsoare.

Un eșec care pare un succes

Software-ul tradițional tinde să eșueze în mod evident. O funcție generează o excepție, un server returnează un cod de eroare, iar tabloul de bord pentru monitorizare se înroșește. Un agent AI se comportă diferit. Funcționează în buclă: un model lingvistic citește un prompt, decide să apeleze un instrument, cum ar fi un API de căutare sau o bază de date, citește rezultatul și decide ce să facă în continuare. Fiecare etapă poate eșua, chiar dacă toate cererile de rețea din lanț se încheie cu succes.

Să luăm un caz obișnuit. Un instrument meteo se defectează și returnează textul „serviciu indisponibil” într-un răspuns altminteri normal. Modelul citește acel text, își cere politicos scuze sau, mai rău, generează o prognoză plauzibilă pe baza datelor de antrenare. Utilizatorul primește un răspuns fluent. Jurnalele serverului indică o cerere reușită, cu o latență normală. Nimic din infrastructura convențională de monitorizare nu înregistrează faptul că ceva a mers prost.

Furnizorii de modele descriu aceeași lacună în documentația lor. Ghidul API Gemini de la Google precizează că modelul „nu execută el însuși funcția”. Acesta doar propune numele unei funcții și argumentele, iar aplicația dezvoltatorului efectuează apelul. Prin urmare, aplicația este singura componentă a sistemului care vede rezultatul real. Ghidul de inginerie al Anthropic despre construirea agenților subliniază un aspect înrudit: agenții au nevoie, la fiecare etapă, de „adevărul de referință” din mediul înconjurător, cum ar fi rezultatele instrumentelor, pentru a-și evalua propriul progres. Când un instrument raportează un eșec sub forma unui text obișnuit, acel adevăr de referință este greșit, iar agentul nu are cum să observe acest lucru.

Nu este vorba despre un tip nou de problemă, ci doar despre o versiune mai pronunțată a uneia vechi. În 2015, ingineri de la Google, conduși de D. Sculley, au descris „datoria tehnică ascunsă” din sistemele de învățare automată. Ei au susținut că cea mai mare parte a riscurilor unui sistem de învățare automată aflat în producție se află în afara codului modelului, în dependențele de date, configurație și codul de legătură. Agenții adaugă un nou element la această listă. Prompturile și descrierile instrumentelor sunt configurații care pot schimba comportamentul unui sistem fără nicio modificare a codului său.

Modificări mici, efecte mari

Cât de mult poate conta o mică modificare a unui prompt? În o lucrare prezentată la ICLR 2024, Melanie Sclar de la University of Washington și colegii săi au modificat doar formatarea prompturilor cu exemple few-shot: separatorii, spațierea și folosirea majusculelor. Sensul a rămas același. Cu toate acestea, performanța la aceeași sarcină a variat cu până la 76 de puncte de acuratețe pentru LLaMA-2-13B. Sensibilitatea nu a dispărut nici în cazul modelelor mai mari, al unui număr mai mare de exemple sau al reglării fine cu instrucțiuni.

Autorii recomandă raportarea unui interval al performanței pentru formate de prompt plauzibile, în locul unei singure valori. Pentru echipele de inginerie, lecția practică este mai simplă. O modificare a promptului este o modificare de cod. Trebuie să aibă un istoric al versiunilor și să fie testată înainte de a ajunge la utilizatori.

Același lucru este valabil și pentru descrierile instrumentelor, pe care modelul le citește ca parte a promptului său. Ghidul Anthropic recomandă ca definițiilor instrumentelor să li se acorde „la fel de multă atenție în proiectarea promptului” ca promptului principal. Ghidul descrie un agent de programare care făcea în mod repetat greșeli cu căile relative ale fișierelor. După ce instrumentul a fost modificat astfel încât să solicite căi absolute, modelul l-a folosit fără erori. Modelul nu s-a schimbat. S-a schimbat doar descrierea pe care o citea.

Un singur succes nu dovedește mare lucru

O a doua direcție de cercetare analizează consecvența. Benchmarkul τ-bench, publicat de Shunyu Yao și colegii săi de la Sierra și prezentat la ICLR 2025, simulează conversații de servicii pentru clienți în care un agent trebuie să folosească instrumente și să respecte reguli de afaceri. Autorii au introdus o metrică numită pass^k: probabilitatea ca un agent să rezolve corect aceeași sarcină în toate cele k încercări.

Rezultatele au fost îngrijorătoare. Un agent GPT-4o a rezolvat aproximativ 61% dintre sarcinile din retail dintr-o singură încercare. Când a trebuit să reușească de opt ori la rând la aceeași sarcină, rata a scăzut la aproximativ 25%. O demonstrație care funcționează o dată spune prea puțin despre comportamentul unui sistem la a mia rulare.

Unde cedează sistemele cu mai mulți agenți

Multe echipe conectează acum mai mulți agenți în lanț: unul planifică, altul execută, iar un al treilea verifică rezultatul. Un studiu din 2025 realizat de UC Berkeley, „De ce eșuează sistemele LLM cu mai mulți agenți?”, a analizat peste 1.600 de trase de execuție adnotate, provenite din șapte cadre populare pentru sisteme cu mai mulți agenți. Autorii, conduși de Mert Cemri, au elaborat o taxonomie numită MAST, care cuprinde 14 moduri de eșec grupate în trei categorii: probleme de proiectare a sistemului, nealinierea dintre agenți și verificarea sarcinilor.

Concluzia lor principală este că multe eșecuri țin de modul în care este proiectat sistemul, nu doar de limitele modelului de bază. Agenții ignoră rolul care le-a fost atribuit, pierd firul conversației sau declară o sarcină încheiată fără să verifice rezultatul. Aceste eșecuri nu lasă nicio eroare în urmă. Pot fi observate doar dacă cineva poate citi ce a făcut, de fapt, fiecare agent. Relatarea Unite.AI despre paradoxul sistemelor cu mai mulți agenți evidențiază un aspect înrudit din perspectiva arhitecturii: adăugarea de agenți poate amplifica o eroare inițială, în loc să o anuleze.

Cum facem vizibil ceea ce este invizibil

Răspunsul ingineresc preia o idee din sistemele distribuite, unde solicitările sunt urmărite de multă vreme prin numeroase servicii, folosind o tehnică numită trasare. Aplicată agenților, fiecare solicitare a utilizatorului devine o trasare, iar fiecare apel către un model sau un instrument devine un „span” în cadrul acesteia. Un span înregistrează intrarea, ieșirea, tokenurile utilizate și durata apelului. Organismul de standardizare din domeniu, OpenTelemetry, elaborează convenții comune pentru spanurile de IA generativă. În 2026, aceste convenții sunt încă marcate ca fiind în curs de dezvoltare, așa că numele atributelor se mai pot schimba.

Mai multe proiecte open-source, precum Langfuse, Arize Phoenix și AcruxCore, aplică deja această idee. Codul lor sursă este public, astfel încât echipele pot vedea cum este stocată o trasare și pot rula software-ul pe propriile servere. Aceste proiecte înregistrează apelurile către modele și instrumente ca spanuri ale unei singure trasări și permit echipelor să le atribuie scoruri de calitate. Alegerea instrumentului contează mai puțin decât un detaliu: un span asociat unui instrument trebuie să înregistreze ce a returnat efectiv instrumentul, nu doar dacă solicitarea de rețea a reușit. În lipsa acestei informații, defecțiunea instrumentului meteo descrisă mai sus rămâne invizibilă.

Sondajele din industrie sugerează că trasarea este acum răspândită, dar testarea rămâne în urmă. Raportul Starea ingineriei agenților al LangChain a inclus răspunsurile a 1.340 de practicieni, la sfârșitul anului 2025. Calitatea a fost cel mai des menționată ca obstacol în calea introducerii agenților în producție, fiind indicată de 32% dintre respondenți. 89% dintre organizații au raportat o formă de observabilitate pentru agenții lor, iar 62% aveau o trasare detaliată a pașilor individuali și a apelurilor către instrumente. Doar 52,4% au efectuat evaluări offline pe seturi de testare, iar 37,3% au evaluat traficul în timp real. Majoritatea echipelor pot vedea ce au făcut agenții lor. Mai puține verifică dacă au făcut ceea ce trebuia.

Evaluarea răspunsurilor la scară largă

Trasările arată ce s-a întâmplat. Ele nu spun dacă răspunsul a fost bun. Citirea manuală a fiecărei conversații nu este o soluție scalabilă, așa că echipele folosesc tot mai des un al doilea model pentru evaluare, o abordare cunoscută drept evaluare de către un model lingvistic de mari dimensiuni (LLM-as-a-judge). O lucrare prezentată la NeurIPS 2023, semnată de Lianmin Zheng și colegii săi, a constatat că modelele performante, precum GPT-4, au fost de acord cu preferințele oamenilor în peste 80% dintre cazuri, aproximativ la fel de des pe cât sunt oamenii de acord unii cu alții.

Aceeași lucrare a documentat punctele slabe ale metodei. Modelele-evaluator preferă răspunsul prezentat primul, preferă răspunsurile mai lungi și pot favoriza textele scrise chiar de ele. Prin urmare, scorurile evaluatorilor sunt estimări. Sunt utile pentru evaluarea unui volum mare de răspunsuri, dar trebuie verificate pe un set restrâns de exemple etichetate de oameni, cu ordinea răspunsurilor aleatorizată.

De la practică la politici

Aceste activități de măsurare devin totodată o cerință de guvernanță. Institutul Național de Standarde și Tehnologie al SUA a publicat Cadrul de gestionare a riscurilor IA în ianuarie 2023. Una dintre cele patru funcții de bază ale cadrului, „Măsurare”, le cere organizațiilor să cuantifice, să urmărească și să documenteze riscurile IA de-a lungul timpului. În cazul unui agent, trasările și scorurile de evaluare sunt dovezile solicitate de această funcție.

Ce pot echipele acum

Aceasta reia argumentul prezentat pe această platformă, potrivit căruia fiabilitatea este adevăratul test al IA agentice. Cercetările de mai sus adaugă detaliul privind măsurarea: fiabilitatea nu este o caracteristică pe care o observi o singură dată, ci un nivel pe care trebuie să îl măsori în continuare.

Cercetările indică un set restrâns de practici, iar principalii furnizori de modele recomandă multe dintre aceleași măsuri. Ghidul practic al OpenAI pentru construirea agenților le recomandă echipelor să „configureze evaluări pentru a stabili o valoare de referință a performanței” înainte de optimizare și să predea controlul unei persoane atunci când un agent depășește un număr prestabilit de încercări eșuate sau se confruntă cu o acțiune cu risc ridicat. Anthropic recomandă „testarea extensivă în medii izolate” înainte ca agenții să acționeze autonom.

În practică, asta înseamnă câțiva pași concreți. Păstrați solicitările și descrierile instrumentelor sub controlul versiunilor, la fel ca pe cod. Testați fiecare modificare a unei solicitări pe baza unui set de date fix și așteptați-vă la o gamă de rezultate, nu la o singură valoare. Rulați fiecare caz de test de mai multe ori, deoarece o singură rulare ascunde inconsecvențele. Înregistrați rezultatele instrumentelor în trasări, astfel încât un instrument defect să nu se poată ascunde în spatele unui cod de succes. Tratați scorurile evaluatorilor automați ca estimări și verificați-le cu ajutorul oamenilor.

Niciuna dintre aceste practici nu presupune o descoperire majoră în ceea ce privește capabilitățile modelelor. Ele presupun să tratăm un agent IA drept ceea ce este: un sistem probabilistic care trebuie măsurat, deoarece rareori își va semnala singur eșecurile.