Timu nyingi za AI zinazotaka kuboresha utendaji wa wakala hutumia mbinu zilezile: madirisha makubwa ya muktadha, nyaraka zaidi na madokeza bora zaidi. Makala haya yanadai kuwa huo ni mwelekeo usiofaa kabisa. Kinachokosekana si taarifa zaidi. Ni udhibiti. Safu ya udhibiti iliyoundwa vizuri ndiyo hutofautisha wakala anayefanya kazi kwenye onyesho na anayefanya kazi katika uzalishaji.
Kumpa wakala wa AI kumbukumbu kubwa, nyaraka zaidi au dirisha refu la muktadha hakumfanyi awe mwerevu zaidi—kunamfanya tu awe polepole na ghali zaidi. Maboresho halisi hutokana na kumfundisha wakala kuchagua anachohitaji na wakati anapokihitaji, badala ya kutumia kila kitu kwa wakati mmoja.
Utegemezi hutokana na mzunguko, si muundo. Tofauti kati ya wakala anayevutia kwenye onyesho na anayestahimili mazingira ya uzalishaji si ubora wa AI—ni ikiwa mfumo hukagua kazi yake mwenyewe. Mawakala wanaopanga, kutenda, kuangalia na kuthibitisha katika kila hatua hutambua makosa yao badala ya kukosea kwa kujiamini.
Mawakala wengi wa AI leo kimsingi ni roboti za mazungumzo zenye hatua za ziada—hawana utaratibu wa kujua ikiwa wanaelekea panapofaa, wakati wa kusimama au wakati wa kujaribu mbinu tofauti. Kuongeza safu thabiti ya udhibiti—vigezo wazi vya mafanikio, hali iliyopangwa na ukaguzi wa uthibitishaji—ndiko kunakobadilisha kitu kinachofanana na wakala kuwa kitu unachoweza kuamini.
Ulikula nini kwa chakula cha mchana jana?
Huenda hukukumbuka upya kila jambo lililowahi kukutokea hadi ukafikia “jana + chakula cha mchana.” Ulienda moja kwa moja kwenye sehemu ya uzoefu wako ambako dhana hizo zinapatikana. Huo ni mfano mzuri wa kiakili wa kuunda mawakala:
Dirisha kubwa la muktadha si kumbukumbu.
Rundo la nyaraka zilizorejeshwa si uelewa.
Msururu mrefu wa mawazo si utegemezi.
Hivyo ni viambato. Lakini kinachofanya wakala aonekane kama wakala ni kilekile kinachoufanya ubongo wako usichanganue kwa nguvu historia yako yote ya maisha: udhibiti.
Utafiti wa hivi karibuni—Agentic Reasoning for Large Language Models—ulifanya kazi nzuri ya kufupisha (na kutaja) mabadiliko ambayo wengi wetu tumekuwa tukihisi tunapounda: kutoka uwazaji ndani ya muundo hadi uwazaji kupitia mwingiliano. Chapisho hili si muhtasari wa utafiti huo. Ni jaribio la kubadilisha mabadiliko hayo kuwa usanifu wa mfumo unaoweza kutekelezwa:
Ukiunda mawakala kama roboti za mazungumzo zenye zana, utaendelea kupata hitilafu za roboti za mazungumzo—ila makosa yatakuwa ghali zaidi.
Kwa muda, mwongozo wetu wa kawaida wa “kuufanya muundo uwe mwerevu zaidi” kimsingi ulikuwa: madokeza bora, msururu wa mawazo, uthabiti binafsi / maboresho yanayotegemea sampuli, na labda utafutaji.
ReAct ilikuwa hatua muhimu kwa sababu ilifanya “wazo → kitendo → uchunguzi” ionekane ya kawaida. Lakini zingatia kikwazo kilichofichika: mengi ya haya bado huishia kuwa “u推aji wa dokezo moja, lakini wenye tokeni zaidi.” Mtazamo wa utafiti ni makini zaidi: uwazaji wa kiwakala unasisitiza kupanua mwingiliano wakati wa majaribio—kubadilisha u推aji kuwa mchakato unaorudiwa ambapo muundo, kumbukumbu na mazingira yote hubaki kwenye mzunguko.
Ikiwa umeunda (au kutumia) mawakala wanaovutia kwenye maonyesho lakini ni dhaifu katika mitiririko halisi ya kazi, hili ni kwa ajili yako.
Nieleze mtindo ambao nimeuona mara nyingi (na ambao bila shaka nimewahi kuunda matoleo yake):
Chukua muundo mzuri wa Chat
Ongeza zana chache (utafutaji, hoja ya hifadhidata, labda utekelezaji wa msimbo)
Ongeza RAG
Ongeza dokeza la mfumo la “wewe ni wakala anayejitegemea”
Weka yote kwenye kitanzi cha while hadi isimame au muda uishe
Hongera, una kitu kinachofanana na wakala. Lakini kwa kawaida hufeli kwa njia zinazotabirika:
Kuvimba kwa muktadha: kila uchunguzi huongezwa; madokeza huwa tabaka za kiakiolojia.
Kuhangaika na zana: “zana isiyofaa lakini kwa kujiamini” huwa aina ya kawaida ya hitilafu.
Hakuna masharti ya kusimama: huendelea kwa sababu inaweza, si kwa sababu inapaswa.
Hakuna utaratibu wa uimarishaji: haitambui kuwa imekosea usipoilazimisha.
Kumbukumbu = historia ya Chat: jambo ambalo kimsingi ni kuandika kumbukumbu za matukio na kuliita kujifunza.
Ndiyo maana “mawakala” mara nyingi huonekana wa ajabu kwenye maonyesho lakini huwa vurugu katika uzalishaji. Uzoefu wetu wa kuweka mifumo ya kiwakala katika uzalishaji pia unaonyesha hili: usipotathmini tena muundo bali mfumo, aina za hitilafu hujumuisha urambazaji, usimamizi mzuri wa zana, upunguzaji wa muktadha na usanifu wa tathmini—si tu “je, muundo ulijibu kwa usahihi?”
Kwa hivyo swali linakuwa: wakala aliyekusudiwa ni yupi?
Ili kufanya hili lieleweke zaidi, huu hapa mtiririko rahisi wa kazi ambao watu wengi wanaweza kuuwazia: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Utekelezaji wa kawaida unaofanana na wakala huwa hivi:
Hurejesha mara moja nyaraka nyingi za sera za mashirika ya ndege/usafiri (hata kama bado hakuna inayohitajika).
Huita zana ya utafutaji, hubandika orodha ndefu ya matokeo kwenye dokeza, kisha “huchagua moja.”
Huweka nafasi mapema bila kuthibitisha masharti (wakati wa kuwasili / mizigo / kiti / sera).
Ikifeli, hujaribu tena kwa njia tofauti kidogo—lakini bila kuelewa wazi kilichobadilika au ilichojifunza.
Tatizo si kwamba muundo hauwezi kuwaza—ni kwamba mfumo haudhibiti mtiririko wa kazi.
Toleo linalofanya kazi zaidi kama wakala huchukulia kazi kuwa mchakato shirikishi wenye hali na ukaguzi ulio wazi:
PANGA: taja tena masharti na uorodheshe taarifa zinazokosekana (k.m., “unapendelea uwanja gani wa ndege?” / “kusimama mara 1 ni sawa?”).
TEKELEZA: ita utafutaji wa ndege kwa hoja yenye muundo maalum (kipindi cha tarehe, sharti la kuwasili, bajeti).
ANGALIA: hifadhi matokeo katika kipengee kifupi cha hali (chaguo 5 bora pamoja na bei/wakati wa kuwasili/vituo), badala ya rundo kubwa lililobandikwa.
SASISHA: boresha hoja ikiwa masharti hayajatimizwa (k.m., “kuwasili kabla ya saa 12 jioni ni sharti kali mno—tuongeze muda au bajeti?”).
THIBITISHA: endesha vithibitishaji (“kuwasili < 18:00,” “bei ≤ £900,” “inatii sera,” “uchaguzi wa kiti unapatikana”).
SIMAMA: baada tu ya API ya kuweka nafasi kurudisha uthibitisho na vithibitishaji vyote kukubali.
Kilichobadilika ni kidogo lakini cha msingi. Urejeshaji una masharti (si mwitikio wa moja kwa moja), muktadha unadhibitiwa (hali imepangwa, haijarundikwa), na uthibitishaji umo kwenye mzunguko (hauachiwi mtumiaji). Badilisha “kuweka nafasi ya ndege” na “kuunda agizo la ununuzi,” “kurejesha pesa,” “kubadilisha usanidi wa uzalishaji,” au “kutoa PR” na hali ni ileile: wakala anapoweza kutenda, mzunguko huwa muhimu kuliko dokeza.
Utafiti uliotajwa hapo juu unapanga uwazaji wa kiwakala katika tabaka tatu: msingi (upangaji/matumizi ya zana/utafutaji), unaojiendeleza (mrejesho + kumbukumbu), na wa pamoja (uratibu wa mawakala wengi).
Lakini wazo la kina zaidi ni hili: uwazaji huwa kanuni inayopanga mipango, ufanyaji maamuzi na uthibitishaji—si kuzalisha tu msururu wa mawazo unaoonekana kukubalika. Hilo linaonekana kuwa la kinadharia hadi unapolinganisha na mabadiliko katika usanifu wako. Kuna mambo matatu ya msingi ya kukumbuka:
Wakala mzuri hapaswi kuchukulia urejeshaji kama jambo la “kufanya kila wakati.” Urejeshaji ni uamuzi, si mwitikio wa moja kwa moja.
Hiki hapa kigezo cha vitendo:
Ikiwa mfumo wako hurejesha taarifa katika kila zamu, hujaunda urejeshaji—umeunda ushuru wa muktadha.
Hili hujitokeza mara kwa mara katika kazi halisi. Unapotatua tukio la uzalishaji, humwagi kumbukumbu zote za matukio kwenye muktadha; unaamua vipimo/kumbukumbu za kuchukua baadaye kulingana na dhana yako ya sasa. Huo ndio “urejeshaji wa kiwakala.” Huu hapa mtindo mahususi zaidi:
Amua ikiwa unahitaji urejeshaji
Ikiwa ndiyo: andaa hoja, chukua, pitia kwa haraka, chambua
Ikiwa ushahidi unakinzana: chukua tena
Kisha ndipo uunganishe matokeo
Hapa pia ndipo “RAG ya kiwakala” huanza kutofautiana na RAG ya kawaida: urejeshaji huwa hatua ya kimakusudi ya uwazaji, si hatua ya kawaida ya mtiririko.
Mara tu unapoacha kutathmini “muundo” na kuanza kutathmini “mfumo,” ufuatiliaji na uchunguzi wa hali huwa muhimu.
Kufikia sasa, jambo moja ambalo sekta imeanza kuweka wazi zaidi ni uwezo wa kufuatilia mtiririko wa kazi wa wakala. Kwa mfano, SDK ya Agents ya OpenAI huja na ufuatiliaji uliojengewa ndani na dashibodi ya Traces inayorekodi utekelezaji wa wakala (matokeo yaliyotolewa, miito ya zana, makabidhiano, vidhibiti, matukio maalum), ili uweze kutatua hitilafu na kukagua kilichotokea hatua kwa hatua.
Hicho si kitu cha “kuwa nacho ikiwezekana.” Ndicho kinachotofautisha mfumo unaoweza kutatulia hitilafu na mfumo unaoweza tu kuhukumu kwa hisia.
Kwa maoni yangu, sehemu ya utafiti inayoweza kutekelezwa zaidi ni jinsi unavyozungumzia maoni ya mrejesho moja kwa moja. Unagawa mrejesho katika mifumo mitatu: mrejesho wa kutafakari (zalisha → kosoa → rekebisha), urekebishaji wa vigezo (kujifunza kupitia usanifu mahususi / RL), na mrejesho unaoongozwa na kithibitishaji (jaribu tena hadi kithibitishaji kikubali).
Timu nyingi zinapaswa kuanza na mrejesho unaoongozwa na kithibitishaji kwa sababu hauna msisimko lakini una ufanisi. Ukiweza kuandika kithibitishaji chochote kinachofanya majaribio ya kitengo, kukagua kielezo, kuweka kanuni/vikwazo vya biashara (“hakuna kurejesha pesa zaidi ya X bila kuwasilisha suala kwa ngazi ya juu”), au kuthibitisha ukweli (“marejeleo yanahitajika”), unaweza kubadilisha matokeo yasiyotabirika ya muundo kuwa kitu unachoweza kuamini.
Mojawapo ya mabadiliko ya “mambo usiyojua kuwa huyajui” hapa ni rahisi: katika ulimwengu wa wakala, utegemezi mara nyingi hutokana zaidi na mzunguko kuliko muundo.
Huu ndio utaratibu mfupi zaidi wa mzunguko ambao nimegundua huboresha tabia kwa uhakika bila mafunzo:
Fanya kazi kwa hatua: Panga → Tekeleza → Angalia → Sasisha,
Baada ya kila Utekelezaji, fupisha Ulichoona kwa vidokezo 1–3,
Simama vigezo vya mafanikio vinapotimizwa au bajeti inapofikiwa; rudisha matokeo bora zaidi yanayojulikana pamoja na mambo yaliyosalia kuwa na utata.
Hii si kuhusu kuufanya muundo utoe maelezo mengi. Ni kuhusu kuufanya mfumo ueleweke na kuushurutisha “ukabiliane na uhalisia” katika kila hatua. Mfano unaoeleweka sana kwa wahandisi ni uimarishaji wa mzunguko funge kama wa CI:
Panga: pendekeza orodha ya mabadiliko
Tekeleza: endesha majaribio / lint
Angalia: chambua yaliyofeli
Sasisha: tia kiraka na ujaribu tena
Maswali machache ambayo kwa kawaida hufichua miundo ya wakala iliyoundwa bila kukusudiwa:
“Je, wakala wangu huchagua cha kurejesha, au mimi hurejesha kila wakati?”
Ikiwa urejeshaji hufanywa kila mara, utagharimika kwa: ucheleweshaji, gharama, kuchanganyika kwa muktadha, na hatari kubwa zaidi ya kuingiza takataka na kupata takataka.
“Je, wakala wangu anaweza kutambua amekosea?”
Ikiwa ishara pekee ya mrejesho ya wakala wako ni “mtumiaji anakasirika,” unafanya RL kwa mateso ya binadamu. Mzunguko wa kujaribu tena unaoongozwa na kithibitishaji ndiyo njia safi zaidi ya kumkutanisha na uhalisia.
“Je, kumbukumbu inaweza kuandikwa, na je, huboreka kadiri muda unavyopita?”
Ikiwa “kumbukumbu” yako inaongezwa tu historia ya gumzo, kimsingi unaandika kumbukumbu za matukio. Mtazamo wa utafiti kuhusu kumbukumbu ni muhimu: kumbukumbu huwa muktadha unaokua na kubadilika ambao mawakala huboresha kadiri muda unavyopita—si nakala ya mazungumzo tu.
Kumbukumbu za matukio hukuambia kilichotokea, ilhali kumbukumbu hukuambia la kufanya wakati ujao. Historia ya Chat ni nakala ya mazungumzo. Kumbukumbu ni sera inayobadilika kuhusu mambo yanayofaa kuendelezwa.
Mwanzo wa vitendo ni jedwali dogo la “mafunzo tuliyopata,” lenye ufunguo unaojumuisha aina ya kazi, zana na aina ya hitilafu, na thamani inayoeleza kilichofanikiwa na cha kuepuka. Lengo si kuunda grafu kamili ya maarifa. Lengo ni kuunda tabia inayozidi kuimarika: kumbukumbu pamoja na mrejesho hubadilisha mawakala kutoka “wasaidizi wasiohifadhi hali” kuwa mifumo inayoboreka kadiri muda unavyopita.
Kuna kishawishi cha kuongeza mawakala zaidi kushughulikia tatizo, lakini mara nyingi hilo huzidisha gharama za uratibu. Mtindo mzuri wa “timu ya msingi inayotosha”:
Mratibu: hugawanya kazi + kuzipangia wahusika
Mtekelezaji: huita zana / hufanya mabadiliko
Mkosoaji/mtathmini: hukagua usahihi/hatari
Mtunza kumbukumbu: huandika/huratibu mafunzo
Ikiwa huwezi kueleza wajibu wa kila wakala, huenda bado huhitaji mawakala wengi.
Ikiwa tunakubali kweli mabadiliko hayo ya mtazamo, huenda tutaacha kujaza kila kitu kwenye madokeza, kuchukulia hitilafu kuwa matokeo ya mwisho na kutathmini mawakala kama roboti za mazungumzo. Na tutaanza kuwachukulia mawakala kulingana na walivyo: mifumo ya programu ambamo lugha ndiyo safu ya udhibiti—na utegemezi hutokana na mzunguko.
Kabla ya kuongeza muundo mwingine, ongeza mzunguko mwingine wa tathmini. Kabla ya kurejesha kila kitu, weka masharti ya urejeshaji. Toa kithibitishaji kimoja kabla ya kutoa kumi. Chukulia kumbukumbu kama maamuzi ya sera, si hifadhidata. Na unapotumia mawakala wengi, anza na mawakala wawili, si ishirini. Hizi si kanuni; ni mifumo iliyofaulu katika mazingira ya uzalishaji.