Shumica e ekipeve të IA-së që synojnë performancë më të mirë të agjentëve përdorin të njëjtat leva: dritare konteksti më të mëdha, më shumë dokumente dhe kërkesa më të zgjuara. Ky artikull argumenton se ky instinkt është krejtësisht i gabuar. Elementi që mungon nuk është më shumë informacion. Është kontrolli. Një shtresë kontrolli e projektuar mirë është ajo që e dallon një agjent që funksionon në demonstrim nga një që funksionon në prodhim.
T'i jepni një agjenti të IA-së memorie më të madhe, më shumë dokumente apo një dritare konteksti më të gjatë nuk e bën më të zgjuar, por vetëm më të ngadaltë dhe më të kushtueshëm. Përfitimet e vërteta vijnë kur agjenti mëson të zgjedhë çfarë i nevojitet dhe kur i nevojitet, në vend që të konsumojë gjithçka njëherësh.
Besueshmëria vjen nga cikli, jo nga modeli. Dallimi mes një agjenti që lë mbresa në demonstrim dhe një tjetri që qëndron i fortë në prodhim nuk është cilësia e IA-së, por nëse sistemi kontrollon punën e vet. Agjentët që planifikojnë, veprojnë, vëzhgojnë dhe verifikojnë në çdo hap i kapin vetë gabimet, në vend që të gabojnë me vetëbesim.
Shumica e agjentëve të IA-së sot janë në thelb robotë bisede me disa hapa shtesë: nuk kanë mekanizëm për të ditur nëse janë në rrugën e duhur, kur duhet të ndalojnë apo kur duhet të provojnë një qasje tjetër. Shtimi i një shtrese të mirëfilltë kontrolli—kritere të qarta suksesi, gjendje e strukturuar dhe kontrolle validimi—e kthen një objekt që duket si agjent në diçka së cilës mund t'i besoni vërtet.
Çfarë hëngrët dje për drekë?
Me gjasë nuk rikujtuat çdo kujtim që keni pasur ndonjëherë derisa gjetët «dje + drekë». Shkuat drejtpërdrejt te pjesa e përvojës ku gjenden këto koncepte. Ky është një model i dobishëm mendor për ndërtimin e agjentëve:
Një dritare konteksti gjigante nuk është memorie.
Një grumbull dokumentesh të marra nuk është kuptim.
Një zinxhir mendimi i gjatë nuk është besueshmëri.
Këto janë përbërës. Por ajo që e bën një agjent të duket vërtet si agjent është e njëjta gjë që e pengon trurin tuaj të kërkojë me forcë në gjithë historinë e jetës: kontrolli.
Një studim i fundit—Agentic Reasoning for Large Language Models—e përmblodhi (dhe emërtoi) shumë mirë ndryshimin që shumë prej nesh e kanë ndier gjatë ndërtimit: nga arsyetimi brenda modelit te arsyetimi përmes ndërveprimit. Ky publikim nuk është përmbledhje e atij punimi. Është një përpjekje për ta kthyer ndryshimin në projektim praktik të sistemit:
Nëse ndërtoni agjentë si robotë bisede me mjete, do të vazhdoni të merrni të njëjtat mënyra dështimi si te robotët e bisedës, por me gabime më të kushtueshme.
Për njëfarë kohe, strategjia jonë e zakonshme për ta «bërë modelin më të zgjuar» ishte në thelb: kërkesa më të mira, zinxhir mendimi, vetëkonsistencë / përmirësime të bazuara në kampionim dhe ndoshta pak kërkim.
ReAct ishte një pikë kthese, sepse e bëri të natyrshme rrjedhën «mendim → veprim → vëzhgim». Por vini re kufizimin e nënkuptuar: shumë prej kësaj ende përfundon si «inferencë me një shembull, por me më shumë tokenë». Këndvështrimi i studimit është më i mprehtë: arsyetimi agjentik thekson shkallëzimin e ndërveprimit gjatë testimit, duke e kthyer inferencën në një proces përsëritës ku modeli, memoria dhe mjedisi mbeten pjesë e ciklit.
Nëse keni ndërtuar (ose përdorur) agjentë që duken mbresëlënës në demonstrime, por të brishtë në rrjedha reale pune, ky shkrim është për ju.
Më lejoni të përshkruaj një model që e kam parë shpesh (dhe patjetër kam ndërtuar edhe vetë variante të tij):
Merrni një model të mirë bisede
Shtoni disa mjete (kërkim, pyetje në bazën e të dhënave, ndoshta ekzekutim kodi)
Shtoni RAG
Shtoni një kërkesë sistemi “you are an autonomous agent”
Mbështilleni të gjithë në një cikël while derisa të ndalojë ose t'i mbarojë koha
Urime, tani keni një objekt që duket si agjent. Por ai priret të dështojë në mënyra të parashikueshme:
Fryrja e kontekstit: çdo vëzhgim shtohet në fund; kërkesat bëhen shtresa arkeologjike.
Përdorimi i çrregullt i mjeteve: «mjeti i gabuar, por me vetëbesim» bëhet mënyra e zakonshme e dështimit.
Pa kushte ndalimi: vazhdon sepse mundet, jo sepse duhet.
Pa disiplinë për mbështetjen në burime: nuk e kupton se gabon, nëse nuk e detyroni.
Memoria = historiku i bisedës: që në thelb do të thotë të shkruash regjistra dhe ta quash këtë të mësuar.
Prandaj «agjentët» shpesh duken magjikë në demonstrime dhe rrëmujë në prodhim. Edhe përvoja jonë me vendosjen e sistemeve agjentike në prodhim e pasqyron këtë: sapo nuk vlerësoni më një model, por një sistem, mënyrat e dështimit përfshijnë navigimin, përdorimin e disiplinuar të mjeteve, shkurtimin e kontekstit dhe projektimin e vlerësimit, jo vetëm pyetjen «a u përgjigj saktë modeli?».
Pra, pyetja bëhet: si duhet të jetë agjenti i projektuar siç duhet?
Për ta bërë më pak abstrakte, ja një rrjedhë e thjeshtë pune që shumica mund ta përfytyrojnë: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Një zbatim i zakonshëm që «duket si agjent» funksionon kështu:
Merr menjëherë një tufë dokumentesh për politikat e linjave ajrore dhe të udhëtimit (edhe kur ende nuk nevojitet asnjë prej tyre).
Thërret një mjet kërkimi, ngjit në kërkesë një listë të gjatë rezultatesh dhe «zgjedh njërin».
Kryen rezervimin para kohe, pa verifikuar kufizimet (orarin e mbërritjes / bagazhet / ndenjësen / politikën).
Nëse dështon, riprovon në një mënyrë paksa ndryshe, por pa e pasur të qartë se çfarë ndryshoi apo çfarë mësoi.
Problemi nuk është se modeli nuk mund të arsyetojë, por se sistemi nuk e kontrollon rrjedhën e punës.
Një version më agjentik e trajton detyrën si proces ndërveprues me gjendje dhe kontrolle të përcaktuara qartë:
PLANIFIKO: riformulo kufizimet dhe rendit informacionin që mungon (p.sh., «cilin aeroport preferoni?» / «a pranohet 1 ndalesë?»).
VEPRO: thirr kërkimin e fluturimeve me një pyetje të strukturuar (intervali i datave, kufizimi i mbërritjes, buxheti).
VËZHGO: ruaji rezultatet në një objekt kompakt të gjendjes (5 alternativat kryesore me çmimin/mbërritjen/ndalesat), jo si një masë e stërmadhe teksti të ngjitur.
PËRDITËSO: përsos pyetjen nëse kufizimet nuk përmbushen (p.sh., «mbërritja para orës 18:00 është tepër kufizuese—ta zgjerojmë intervalin kohor apo ta rrisim buxhetin?»).
VERIFIKO: ekzekuto validuesit («mbërritja < 18:00», «çmimi ≤ £900», «në përputhje me politikën», «mund të zgjidhet ndenjësja»).
NDALO: vetëm pasi API-ja e rezervimit të kthejë konfirmimin dhe të gjithë validuesit të miratojnë.
Ndryshimi është i imët, por vendimtar. Marrja e të dhënave është e kushtëzuar (jo refleks), konteksti menaxhohet (gjendja strukturohet, jo grumbullohet) dhe verifikimi është pjesë e ciklit (nuk i lihet përdoruesit). Zëvendësoni «rezervimin e një fluturimi» me «krijimin e një urdhërblerjeje», «lëshimin e një rimbursimi», «ndryshimin e konfigurimit në prodhim» ose «publikimin e një PR-je» dhe historia është e njëjtë: sapo agjenti mund të veprojë, cikli ka më shumë rëndësi se kërkesa.
Studimi i përmendur më sipër e organizon arsyetimin agjentik në tri shtresa: themelore (planifikimi/përdorimi i mjeteve/kërkimi), vetëzhvilluese (komentet korrigjuese + memoria) dhe kolektive (bashkërendimi i shumë agjentëve).
Por ideja më e thellë është kjo: arsyetimi bëhet parimi organizues i planifikimit, vendimmarrjes dhe verifikimit, jo thjesht mënyrë për të gjeneruar një zinxhir mendimi bindës. Kjo tingëllon abstrakte derisa ta lidhni me ndryshimet në arkitekturën tuaj. Duhet të mbani mend tri pika kryesore:
Një agjent i mirë nuk duhet ta trajtojë marrjen e të dhënave si diçka që «duhet bërë gjithmonë». Ajo është vendim, jo refleks.
Ja një rregull praktik:
Nëse sistemi juaj merr të dhëna në çdo shkëmbim, nuk keni ndërtuar mekanizëm për marrjen e tyre, por një taksë konteksti.
Kjo shfaqet vazhdimisht në punën reale. Kur diagnostikoni një incident në prodhim, nuk i hidhni të gjithë regjistrat në kontekst; vendosni cilat metrika ose regjistra të merrni më pas, bazuar në hipotezën aktuale. Kjo është «marrje agjentike e të dhënave». Ja një model më konkret:
Vendosni nëse duhet të merrni të dhëna
Nëse po: hartoni një pyetje, merrni të dhënat, shqyrtojini shpejt dhe nxirrni thelbin
Nëse provat bien ndesh: merrni sërish të dhëna
Vetëm atëherë bëni përmbledhjen përfundimtare
Këtu fillon të ndryshojë edhe «RAG-u agjentik» nga RAG-u tradicional: marrja e të dhënave bëhet një hap i qëllimshëm arsyetimi, jo një fazë e parazgjedhur e procesit.
Sapo ndaloni së vlerësuari «një model» dhe filloni të vlerësoni «një sistem», gjurmimi i gjendjes dhe i veprimeve bëhet i rëndësishëm.
Një aspekt që industria tashmë e ka bërë më të qartë është observueshmëria e rrjedhave të punës së agjentëve. Për shembull, Agents SDK i OpenAI përfshin gjurmim të integruar dhe një panel Traces që regjistron ekzekutimet e agjentit (gjenerimet, thirrjet e mjeteve, kalimet, masat mbrojtëse dhe ngjarjet e personalizuara), pikërisht që të mund të diagnostikoni dhe auditoni hap pas hapi atë që ndodhi.
Kjo nuk është diçka që thjesht «do të ishte mirë ta kishim». Është dallimi mes një sistemi që mund ta diagnostikoni dhe një sistemi që mund ta vlerësoni vetëm me përshtypje.
Sipas meje, pjesa më praktike e studimit është mënyra e drejtpërdrejtë me të cilën trajton komentet korrigjuese. Ai i ndan ato në tri mënyra: reflektuese (gjenero → kritiko → rishiko), përshtatje parametrike (mëso përmes përsosjes / RL-së) dhe të drejtuara nga validuesi (riprovo derisa të miratojë validuesi).
Shumica e ekipeve duhet të fillojnë me komentet korrigjuese të drejtuara nga validuesi, sepse janë të zakonshme, por të efektshme. Nëse mund të shkruani çfarëdo validuesi që kryen teste njësie, kontrollon skemën, vendos rregulla ose kufizime biznesi («pa rimbursime mbi X pa përshkallëzim») apo vërteton faktet («kërkohen citime»), mund ta ktheni rezultatin jopërcaktues të modelit në diçka që mund t'i besoni vërtet.
Një nga ndryshimet e thjeshta mes të panjohurave të paparashikueshme është ky: në botën e agjentëve, besueshmëria shpesh vjen më shumë nga cikli sesa nga modeli.
Kjo është disiplina më e thjeshtë ciklike që kam gjetur dhe që e përmirëson sjelljen në mënyrë të besueshme pa trajnim:
Punoni me hapa: Planifiko → Vepro → Vëzhgo → Përditëso,
Pas çdo veprimi, përmblidhni vëzhgimin në 1–3 pika,
Ndaloni kur përmbushen kriteret e suksesit ose arrihet buxheti; ktheni rezultatin më të mirë të njohur dhe pasiguritë e mbetura.
Qëllimi nuk është që modeli të bëhet fjalëshumë. Qëllimi është që sistemi të jetë i kuptueshëm dhe të detyrohet të «përballet me realitetin» në çdo hap. Një shembull mjaft i afërt për inxhinierët është mbështetja në burime me cikël të mbyllur, sipas modelit CI:
Planifiko: propozo listën e ndryshimeve
Vepro: ekzekuto testet / lint-in
Vëzhgo: analizo dështimet
Përditëso: korrigjo dhe riprovo
Disa pyetje që priren të zbulojnë agjentë të projektuar pa qëllim:
«A zgjedh agjenti im çfarë të marrë, apo i marr gjithmonë të dhënat?»
Nëse marrja e të dhënave është e pakushtëzuar, do ta paguani me vonesë, kosto, dobësim të kontekstit dhe rrezik më të lartë që të dhënat e pavlera të prodhojnë rezultate të pavlera.
«A mund ta kuptojë agjenti im se e ka gabim?»
Nëse sinjali i vetëm korrigjues për agjentin tuaj është «përdoruesi acarohet», po bëni RL përmes vuajtjes njerëzore. Një cikël riprovimi i drejtuar nga validuesi është mënyra më e pastër për ta përballur me realitetin.
«A mund të shkruhet në memorie dhe a përmirësohet ajo me kalimin e kohës?»
Nëse «memoria» juaj vetëm shton historikun e bisedës, në thelb po shkruani regjistra. Mënyra se si studimi e koncepton memorien është e rëndësishme: ajo bëhet një kontekst që zgjerohet në mënyrë dinamike dhe që agjentët e përsosin me kalimin e kohës, jo thjesht një transkript.
Regjistrat ju tregojnë çfarë ndodhi, ndërsa memoria ju tregon çfarë të bëni herën tjetër. Historiku i bisedës është një transkript. Memoria është një politikë në zhvillim për atë që ia vlen të ruhet për të ardhmen.
Një pikënisje praktike është një tabelë e vogël me «mësimet e nxjerra», e organizuar sipas llojit të detyrës, mjetit dhe mënyrës së dështimit, ku vlera tregon çfarë funksionoi dhe çfarë duhet shmangur. Qëllimi nuk është të ndërtoni një grafik të përsosur njohurish. Qëllimi është të krijoni sjellje që përmirësohet vazhdimisht: memoria dhe komentet korrigjuese i kthejnë agjentët nga «ndihmës pa gjendje» në sisteme që bëhen më të mira me kalimin e kohës.
Tundimi është t'i shtoni problemit më shumë agjentë, por kjo shpesh shumëfishon barrën e bashkërendimit. Një model i mirë për «ekipin minimal të zbatueshëm»:
Bashkërenduesi: e ndan detyrën dhe e cakton
Ekzekutuesi: thërret mjetet / kryen ndryshimet
Kritiku/vlerësuesi: kontrollon saktësinë/rrezikun
Kujdestari i memories: shkruan/organizon mësimet
Nëse nuk mund të shpjegoni përgjegjësinë e secilit agjent, ndoshta ende nuk ju nevojiten disa agjentë.
Nëse e pranojmë vërtet ndryshimin e paradigmës, ndoshta do të ndalojmë së ngjeshuri gjithçka në kërkesa, së trajtuari dështimet si rezultate përfundimtare dhe së vlerësuari agjentët si robotë bisede. Dhe do të fillojmë t'i trajtojmë agjentët për atë që janë: sisteme softuerike ku gjuha është plani i kontrollit dhe besueshmëria vjen nga cikli.
Para se të shtoni një model tjetër, shtoni një cikël tjetër vlerësimi. Para se të merrni gjithçka, bëjeni marrjen të kushtëzuar. Vendosni në prodhim një validues para se të vendosni dhjetë. Trajtojeni memorien si vendime politike, jo si bazë të dhënash. Dhe kur kaloni te shumë agjentë, filloni me dy, jo me njëzet. Këto nuk janë rregulla; janë modelet që i kanë mbijetuar prodhimit.