Pri agentnih projektih obstaja znan vzorec. Demonstracija deluje. Pilot izgleda prepričljivo. Prvi interni uporabniki so navdušeni. Potem se začne produkcijska uporaba in sistem ne odpove na en jasen, očiten način. Postane počasnejši. Dražji. Manj predvidljiv. Začne uporabljati napačen kontekst, ponavljati slabe akcije ali samozavestno odgovarjati, ko bi se moral ustaviti.
Objava na LinkedInu, ki je sprožila ta članek, je navedla devet »tihih morilcev« AI agentov v produkciji. To je koristen kontrolni seznam, ker to niso eksotični raziskovalni problemi. So normalni inženirski in upravljavski problemi, ki postanejo ostrejši, ko model lahko kliče orodja, si zapomni kontekst, poišče dokumente, porabi žetone in izvaja akcije.
Produkcija ni kraj, kjer ugotovite, ali agent zna navdušiti ljudi. Produkcija je kraj, kjer ugotovite, katere načine odpovedi vaš operativni model lahko preživi.
1. Napihovanje definicij orodij
Vsako orodje, izpostavljeno agentu, ima svojo ceno. Model potrebuje opise, sheme, primere, omejitve in včasih prejšnje rezultate orodij. Postavite pred agenta štirideset orodij in morda boste porabili na tisoče žetonov, preden se obdela dejanska zahteva uporabnika.
Vidni simptomi so zakasnitev in stroški. Nevarnejši simptom je zmanjšana kakovost odločanja. Ko model izbira med preveč slabo razmejenimi orodji, je lažje poklicati napačno orodje, posredovati napačen argument ali izumiti delovni tok, ki ga noben inženir ni nameril.
Praktičen odziv: izpostavite orodja glede na nalogo in fazo, ne glede na vse, kar platforma tehnično zmore. Počasi nalagajte specialistična orodja. Opise ohranjajte kratke, preizkušene in verzionirane. Obravnavajte oblikovanje orodij kot oblikovanje produktnega vmesnika.
2. Razpad kontekstnega okna
Dolgotrajne seje agenta ustvarjajo lažen občutek kontinuitete. Pogovor je morda še vedno odprt, toda pozornost modela na zgodnja navodila, omejitve in odločitve slabi. Kritična politika je lahko potisnjena v preteklost, medtem ko nedavni izhodi orodij prevladajo nad naslednjo akcijo.
To je posebej tvegano v reguliranih ali operativnih okoljih. Zahteva, ki je bila dogovorjena na začetku delovnega toka, lahko tiho preneha vplivati na vedenje proti koncu, ravno takrat, ko agent pripravlja končno odločitev, nalaganje, sporočilo ali spremembo kode.
Praktičen odziv: zaklenite nepogrešljiva navodila. Vzdržujte kompaktne povzetke stanja. Na kontrolnih točkah znova vbrizgajte trenutne cilje, omejitve in odprta tveganja. Za dolge delovne tokove naj agent piše in bere svoje lastno stanje izvajanja, namesto da se zanaša na pogovornemu spomin.
3. Zastrupitev iskanja
Generiranje z iskanjem (RAG) pogosto odpove, preden model napiše eno samo besedo. Če so najboljši pridobljeni odlomki zastareli, nerelevantni, si nasprotujoči ali vzeti iz napačnega dokumenta, je odgovor morda lepo utemeljen v napačnem gradivu.
To je pogosta slepa pega, ker ekipe ocenjujejo generiran odgovor, ne pa iskalnega cevovoda, ki ga je oblikoval. Izhod izgleda samozavestno, toda izvorni kontekst je bil že ogrožen z šibkim deljenjem, slabimi metapodatki, zastarelimi dokumenti ali preširoko semantično ujemanje.
Praktičen odziv: evalvirajte iskanje ločeno od generiranja. Uporabite ponovno razvrščanje, filtre metapodatkov, pravila o svežosti, lastništvo dokumentov in negativne testne primere. Pregledajte, kaj je agent videl, ne le kaj je rekel.
4. Zanke brez nadzora
Agenti so lahko trmasti na zelo drag način. Klic orodja ne uspe, agent poskusi znova s skoraj enakim vnosom, ista napaka se vrne in zanka se nadaljuje, dokler ni izčrpan proračun, kontekst ali potrpljenje uporabnika. V najslabših primerih končni odgovor trdi, da je uspeh, ker agent nima boljše izhodne poti.
To ni inteligenca. Manjka logika upravljanja.
Praktičen odziv: postavite trde omejitve za klice orodij, ponovne poskuse, porabljeni čas in strošek na nalogo. Zaznajte ponavljajoče se napake in ponavljajoče se argumente. Zahtevajte drugačno strategijo po neuspehu in določite, kdaj mora agent eskalirati k človeku.
5. Tihi odmik shem
Agenti so odvisni od API-jev, baz podatkov, dokumentov, orodij, čakalnih vrst, datotek in uporabniških vmesnikov. Te odvisnosti se spremenijo. Polja se preimenujejo, neobvezna polja postanejo obvezna, formati odgovorov se spremenijo in sistemi nadrejenih dodajajo nove primere. Agent morda še vedno prejme »uspešen« odgovor, medtem ko se je pomen pod njim spremenil.
Odmik shem je nevaren, ker pogosto izgleda kot nezanesljivost modela. V resnici se je sistemska pogodba spremenila in nihče ni obvestil plasti agenta.
Praktičen odziv: napišite pogodbene teste za vsako orodje agenta. Validirajte vhode in izhode. Verzionite sheme orodij. Opozorite na nepričakovana polja, manjkajoča polja, prazne nize rezultatov in nenavadne porazdelitve. Obravnavajte orodja agenta kot produkcijske API-je, ne kot pomožne pripomočke za pozive.
6. Slepota evalvacije
»Deluje na mojih desetih primerih« ni strategija evalvacije. Produkcijski uporabniki bodo prinesli robne primere, dvoumne zahteve, zlonamerne vnose, stare dokumente, nepopolne podatke in delovne tokove, ki si jih ekipa ni nikoli zamislila. Če je evalvacijski nabor premajhen ali preveč urejen, je odločitev o zagonu večinoma upanje.
Agenta je treba evalvirati glede na delo, ki ga pričakujemo od njega, vključno s primeri odpovedi. Se vzdrži? Prosi za manjkajoče informacije? Se izogiba nevarnim akcijam? Ohranja meje podatkov? Ustvarja sled, ki jo je mogoče pregledati?
Praktičen odziv: zgradite neprekinjeno evalvacijo z vzorčenim produkcijskim prometom, sintetičnimi nasprotovalnimi primeri, regresijskimi nabori in merili uspešnosti, specifičnimi za nalogo. Ohranjajte evalvacije blizu dejanskega operativnega tveganja.
7. Skrit nedeterminizem
Nedeterminizem sam po sebi ni slabo. Postane problem, ko incidentov ni mogoče reproducirati, razlik ni mogoče razložiti in inženirji izgubijo zaupanje v sistem. Če ista zahteva vodi do različnih klicev orodij, različnega vmesnega sklepanja in različnih izhodov, postane odpravljanje napak detektivsko delo.
Praktičen odziv: beležite različice modelov, pozive, sheme orodij, pridobljeni kontekst, parametre, seme kjer je na voljo, klice orodij in končne izhode. Reproducibilnost ni birokratizem. To je način, kako ekipe učijo iz napak, ne da bi se prepirali iz spomina.
8. Slepe pege stroškov
Stroški agenta se ne skalirajo kot preprosto dokončanje pogovora. Ena sama zahteva uporabnika lahko sproži iskanje, načrtovanje, več klicev modela, ponovne poskuse orodij, povzemanje, validacijo in post-procesiranje. En patološki delovni tok lahko porabi več kot na stotine navadnih zahtev.
Če so proračuni žetonov pregledani le ob prejemu računa, bo finance odkrila sistem, preden ga bodo operacije.
Praktičen odziv: določite proračune na uporabnika, na sejo, na agenta in na orodje. Prikažite porabo v realnem času. Povežite stroške s poslovnimi rezultati, ne le z rabo modela. Koristen agent je morda vreden denarja, toda organizacija mora vedeti, kaj kupuje.
9. Brez načina odpovedi
Najpogostejša škodljiva odpoved agenta pogosto ni zrušitev. Je samozavestni odgovor, ko je bilo pravilno vedenje ustavitev. Mnogi agenti so zasnovani, kot da je uspeh vedno mogoč. Resnični produkcijski sistemi potrebujejo varne izhode: »Ne vem«, »Do tega ne morem dostopati«, »To je v nasprotju s politiko«, »Vir je nezadosten« ali »Odločiti mora človek«.
Praktičen odziv: ustvarite eksplicitne poti vzdržanja in eskalacije. Nagrajujte negotovost, ko je negotovost pravilna. Olajšajte predajo, jo zabeležite in naredite vidno. Dostojanstvena ustavitev ščiti zaupanje bolje kot uglajene halucinacije.
Upravljavska lekcija
Ti devetimi načini odpovedi imajo eno skupno lastnost: niso rešljivi le z boljšim pozivom. Zahtevajo arhitekturo, testno disciplino, opazljivost, nadzor dostopa, nadzor proračuna in operativna pravila. Z drugimi besedami, agenti potrebujejo upravljanje produkta in platforme.
Za vodstvo je praktično vprašanje preprosto: preden skaliramo agenta, ali znamo pokazati, kako odpove, kdo je lastnik te odpovedi, kako hitro je zaznana, koliko stane in kdaj eskalira? Če je odgovor meglен, je sistem še vedno demonstracija, četudi se ga dotikajo resnični uporabniki.
Zaključek
AI agenti lahko ustvarijo resnični vzvod, toda le ko so obravnavani kot produkcijski sistemi. Tihi morilci so tihi, ker nadzorne plošče pogosto ostajajo zelene, medtem ko se uporabniška izkušnja, zaupanje in profil stroškov počasi slabšajo.
Ekipe, ki bodo uspele, ne bodo tiste z najboljšimi demonstracijami. Bodo tiste, ki oblikujejo za degradacijo, opazujejo dejansko vedenje agenta, testirajo dolgočasne pogodbe in sistemu dajo varen način ustavitve.