De ce agenții AI trec testele de calificare și totuși eşuează în producție

Învățarea continuă devine disciplina de inginerie pentru îmbunătățirea agenților după implementare, fără a strica ceea ce funcționa deja.

Un agent AI poate trece toate testele de calificare și totuși poate eşua în producție o săptămână mai târziu. Acest lucru nu este o contradicție. Setul de testare reflectă ceea ce echipa știa să verifice înainte de lansare. Producția este locul unde apar cazurile lipsă: frazări ciudate, lipsă de context, cazuri limită ale uneltelor, utilizatori impaciente, politici contradictorii și fluxuri de lucru pe care niciun designer de test nu le-a imaginat.

Agentul este corectat de utilizatori tot timpul. Acesta dezamăgește utilizatorii. Apoi sesiunea se încheie, jurnalul este stocat, iar următorul utilizator întâlnește practic același sistem.

Acesta este motivul pentru care învățarea continuă devine centrală pentru ingineria agenților. Nu este o funcție a unui singur produs. Este o categorie de metode pentru îmbunătățirea agenților din experiență, păstrând ceea ce funcționa deja. Cercetarea clasică privind învățarea continuă a abordat problema învățării în timp, fără uitare catastrofală. Agenții fac ca această problemă să fie mai largă. Lucrul care se schimbă poate fi un model, dar poate fi și un prompt, un instrument, o abilitate, un flux de lucru sau o memorie.

Această distincție contează, deoarece majoritatea eșecurilor agenților nu sunt rezolvate prin ajustarea modelului.

Reflexul de reglare fină este prea îngust

Când echipele vorbesc despre îmbunătățirea unui sistem AI, planul implicit sună adesea astfel: colectați eșecuri, etichetați răspunsuri mai bune, reglați modelul. Acest instinct este înțelept. Reglarea fină supravegheată, Optimizarea Directă a Preferințelor, Optimizarea Politicilor Relative de Grup și metodele cu parametri eficienți, cum ar fi LoRA, sunt instrumente utile atunci când modelul însuși trebuie să se schimbe.

Dar multe eșecuri în producție nu sunt eșecuri ale greutății modelului. Sunt eșecuri ale sistemului.

Agentul poate depinde de o memorie învechită, sări peste o confirmare necesară, să apeleze un instrument cu un argument greșit sau să direcționeze un caz prin fluxul de lucru greșit. Adesea, problema nu constă în capacitatea modelului de bază. Este contextul, memoria, interfața instrumentului sau fluxul de lucru care îl înconjoară.

Un agent modern are mai multe straturi. Modelul raționează și generează. Harnașul din jurul său definește prompturile, instrumentele, abilitățile, codul, rutarea și fluxul de lucru. Memoria poartă fapte și proceduri învățate de-a lungul sesiunilor. Învățarea continuă este disciplina care decide care strat trebuie să se schimbe, cât de mică poate fi schimbarea și cum să verifice că schimbarea a funcționat cu adevărat.

Uneori, repararea corectă este o scriere în memorie. Uneori este o editare a promptului. Uneori este un înveliș de instrument, o regulă de rutare sau o reparare a fluxului de lucru. Reglarea fină ar trebui să rămână disponibilă, dar nu ar trebui să fie primul răspuns la fiecare eșec.

Testele de referință sunt utile, dar producția rareori oferă una

Există un lucru interesant care optimizează harnașul agentului însuși. Metode precum GEPA, Meta-Harness și abordări conexe de optimizare a promptului sau a fluxului de lucru tratează agentul ca pe un sistem care poate fi modificat și testat. Ele pot propune editări ale prompturilor sau ale altor componente ale harnașului, pot rula candidați și pot păstra versiunile care obțin scoruri mai bune.

Acesta este direcția corectă. Mută îmbunătățirea din cadrul îngust al „actualizării greutăților” în cadrul mai larg al „îmbunătățirii agentului”.

Dar există o capcană: aceste metode presupun de obicei o testare de referință. Au nevoie de o sarcină care poate fi rulată repetat și de un evaluator care spune dacă candidatul A este mai bun decât candidatul B. Fără aceasta, optimizarea devine o ghicire cu unelte mai bune.

Acesta nu este ceea ce au majoritatea echipelor în producție.

Ceea ce au este jurnale. Au urme, corecții ale utilizatorilor, bilete de suport, evenimente de thumbs-down, note de escaladare și ocazional feedback de la experți. Aceste semnale sunt valoroase, dar nu sunt încă o testare de referință. Ele vă spun că s-a întâmplat ceva. Nu vă spun automat cum să rejucați, ce ar trebui să arate succesul sau cum să evaluați o reparație propusă.

Acest gol este unde multe eforturi de învățare continuă se opresc. Echipa are experiență, dar nu încă un mediu de învățare.

Jurnalele nu sunt lecții

Un jurnal de producție înregistrează o singură cale printr-o interacțiune. Un utilizator a cerut un zbor. Agentul a căutat. Utilizatorul a spus că data era greșită. Acesta este un eșec, dar nu este suficient pentru a învăța.

Jurnalul nu definește contrafactualul. Trebuia agentul să ceară confirmare? Trebuia să inferă data din contextul anterior? Trebuia să apeleze un instrument diferit? Trebuia să refuze să continue până când ambiguitatea era rezolvată? Un om poate ști răspunsul după ce citește urma, dar sistemul nu primește această structură gratuit.

Pentru ca învățarea continuă să funcționeze, un eșec brut trebuie transformat în ceva rejuocabil. Acesta înseamnă o sarcină pe care agentul o poate întâlni din nou, un utilizator sau simulator care re creează modelul relevant, instrumente pe care agentul le poate apela și evaluatori care definesc succesul. Evaluatorul poate verifica răspunsul final, apelurile instrumentelor, o limită de politică, întârziere, cost sau toate acestea.

Acesta este partea mai puțin vizibilă a muncii, dar este partea care face îmbunătățirea reală. Odată ce un eșec devine un mediu rejuocabil, puteți pune o întrebare concretă: a funcționat realmente reparația propusă?

Fără acest pas, echipele sunt în mare parte patch-uri din memorie.

David Silver și Richard Sutton au descris o viitoare eră a experienței, în care agenții învață în primul rând din interacțiunea cu lumea, și nu din datele statice umane. Pentru agenții întreprinderilor, această viziune depinde de transformarea experienței de producție haotice în medii care pot fi rejuocate, evaluate și reutilizate.

Experiența singură nu este suficientă. Trebuie să fie făcută testabilă.

Regresia este costul ascuns

Chiar și atunci când un eșec devine testabil, partea cea mai grea rămâne: repararea fără a strica altceva.

Oricine a întreținut un agent complex a văzut acest model. Adăugați o instrucțiune astfel încât agentul să escaladeze cererile de rambursare agresive. Acum escaladează rambursări rutiniere care ar trebui să fie gestionate rapid. Reduceți apelurile instrumentelor într-un flux de lucru. Acum alt flux de lucru sări peste o verificare necesară. Corectați o memorie învechită. Acum agentul generalizează excesiv corectarea pentru o linie de produse diferită.

Fiecare patch are sens local. Sistemul încă derivă global.

Acesta este versiunea agentului a uitării catastrofale. În rețelele neuronale, termenul se referă de obicei la noua instruire care șterge capacitățile mai vechi. La agenți, eșecul este mai larg și adesea mai greu de văzut. Uitarea poate apărea în prompturi, instrumente, memorie, rutare și flux de lucru. Apare nu ca o metrică curată pe o curbă de antrenament, ci ca un utilizator care spune: „Acesta a funcționat înainte.”

De aceea, controlul regresiei nu poate fi doar un pas de revizuire finală. Trebuie să fie în interiorul buclei de învățare însăși.

Scopul nu este doar să maximizeze performanța pe cel mai recent eșec. Scopul este să îmbunătățească cazul nou, păstrând cazurile vechi. Fiecare reparație care funcționează ar trebui să devină parte a memoriei agenților a ceea ce trebuie să funcționeze în continuare. În practică, acest lucru înseamnă că vechile eșecuri devin teste de regresie. Istoria agentului devine o constrângere, nu doar un arhiv.

Acesta este locul în care învățarea continuă devine mai mult ca o inginerie serioasă a software-ului decât o ajustare a prompturilor. O schimbare nu este bună pentru că sună mai bine. Este bună pentru că îmbunătățește un comportament măsurat și nu regresează comportamentele pe care sistemul le-a câștigat deja.

Ce necesită învățarea continuă practică

O buclă de învățare continuă gata pentru producție are nevoie de patru proprietăți.

În primul rând, eșecurile trebuie să fie rejuocabile. Un eșec unic este o anecdotă. Un mediu rejuabil și evaluat este un test. Până când agentul nu poate întâlni același model din nou, nimeni nu poate dovedi că reparația a funcționat.

În al doilea rând, diagnosticul trebuie să fie holistic. Reparația poate aparține modelului, dar poate aparține și memoriei, promptului, stratului instrumentului sau fluxului de lucru. Cea mai bună reparație este de obicei cea mai mică schimbare durabilă care explică eșecul.

În al treilea rând, învățarea trebuie să fie pe viață. Agentul nu ar trebui să se îmbunătățească în această săptămână, anulând în mod tacit comportamentul câștigat cu greu din săptămâna trecută. Succesele anterioare ar trebui să devină constrângeri în timpul optimizării, nu surprize după implementare.

În al patrulea rând, bucla trebuie să fie eficientă. Dacă fiecare îmbunătățire necesită un proiect de reantrenare trimestrial, sistemul nu va ține niciodată pasul cu producția. Bucla trebuie să încerce reparații ieftine mai întâi, să escaladeze numai atunci când este necesar și să păstreze verificarea aproape de schimbare.

Niciuna dintre acestea nu înseamnă că agenții ar trebui să se actualizeze orbește. Înseamnă contrariul. Îmbunătățirea ar trebui să devină măsurabilă. Fiecare schimbare ar trebui să aibă un test, un scor înainte și după, și o verificare a regresiei.

Acesta este ceea ce transformă învățarea continuă dintr-o aspirație vagă într-o disciplină de inginerie.

Viitorul agenților nu va fi definit doar de ferestre de context mai mari, modele de bază mai puternice sau mai multe instrumente. Acestea vor conta. Dar întrebarea mai importantă pentru întreprinderi este ce se întâmplă după implementare.

Când agentul eşuează mâine, poate sistemul să transforme acel eșec într-un test? Poate să direcționeze reparația către stratul corect? Poate să dovedească că reparația a funcționat? Poate să dovedească că nimic altceva nu s-a stricat?

Dacă răspunsul este nu, agentul nu învață realmente din producție. Acesta acumulează risc.

Agenții care contează în continuare vor face ceva mai bine. Ei vor compune.