Ni muhimu kuzingatia kwa makini jinsi na mahali ambapo maamuzi hufanywa katika mfumo wako wa mawakala.
Kukabidhi maamuzi zaidi kwa LLM kunaweza kuuwezesha mfumo kushughulikia kazi nyingi zaidi, lakini huenda kukaathiri kasi, kutegemewa na uthabiti.
Inapowezekana, jaribu kuhamisha sehemu kubwa iwezekanavyo ya mchakato wa kufanya maamuzi kutoka kwenye LLM hadi kwenye msimbo bayana wa programu. Hili ni muhimu hasa kwa mitiririko ya kazi yenye hatari kubwa na/au inayotumika katika uzalishaji.
Unapobuni mfumo wa mawakala unaotegemea LLM, mojawapo ya maamuzi muhimu zaidi ni kiwango ambacho ufanyaji maamuzi utawekwa ndani ya muundo wa LLM badala ya programu bayana.
Ili kuelewa jambo hili, tunaweza kuona chaguo hili kama wigo ulio kati ya mbinu zifuatazo:
Usanifu unaotumia kipanga njia hufafanua wazi mpangilio na mantiki katika msimbo, hivyo kuhakikisha kazi za nyanja mahususi zinaweza kujaribiwa, kutabirika na kuwa thabiti (pia huitwa “mawakala wa mtiririko wa kazi”).
Mawakala waratibu hutegemea miundo mikubwa ya lugha (LLM) kuamua mitiririko ya kazi kwa kubadilika kupitia maelekezo ya lugha asilia. Wanafaa kwa maingiliano yasiyo na mipaka maalumu, ambapo mantiki iliyobainishwa mapema haitoshi au haiwezekani.
Kwa mitiririko ya kazi yenye hatari kubwa inayotumika katika uzalishaji, kwa kawaida tunapendekeza vipengele vingi zaidi vya kipanga njia na kuhifadhi waratibu kwa programu zinazohitaji mazungumzo nyumbufu ya matumizi ya jumla.
Usanifu Unaotumia Kipanga Njia
Mifumo ya mawakala inayotumia kipanga njia:
Hufafanua wazi mtiririko wa kufanya maamuzi kupitia msimbo/programu na hutumia LLM kuamua njia ambayo programu hiyo itafuata.
Inafanana zaidi na mifumo ya kawaida ya programu kwa kuwa ina njia zilizo wazi na zinazotabirika, ambazo hutoa matokeo yenye uthabiti zaidi.
Inafaa kwa kazi zinazoweza kufafanuliwa kikamilifu.
Ufuatao ni mfano rahisi wa wakala wa Chatbot ya Kuhifadhi Nafasi za Ndege anayetumia “mbinu ya kipanga njia.” Ingawa LLM hutusaidia kuainisha nia ya swali kati ya chaguo tatu, hatimaye programu yetu ndiyo huunganisha nia hiyo na jibu la maandishi la kiolezo. Kwa kuwa LLM imewekewa mipaka mikali, mtumiaji atapata mwenendo wenye uthabiti zaidi.
Usanifu wa Mratibu
Tofauti na mfumo wa kipanga njia, mifumo ya mawakala waratibu:
Hufafanua mitiririko ya mantiki kupitia maelekezo ya lugha asilia badala ya programu. Kumbuka: ikilinganishwa na lugha ya programu, lugha asilia ina utata na unyumbufu kiasili (sifa ambazo zina faida na hasara, kama tutakavyojadili baadaye). Tunachukulia hili kama “nia badala ya agizo.”
Inaweza kutoa chaguo nyingi za uchakataji, huku LLM ikiamua mpangilio na mbinu ya utekelezaji.
Inaweza kuunda kwa kubadilika njia mpya za kimantiki ambazo ni vigumu kuzifafanua wazi katika programu.
Utata huu unaweza kusababisha matokeo yasiyo thabiti, lakini unapofanya kazi vizuri unaweza kuonekana kama “uchawi.”
Mfano ufuatao unatumia mbinu ya mratibu kutatua tatizo lilelile rahisi la shirika la ndege. Badala ya kuiacha programu iamue jibu linalofaa, ufanyaji maamuzi unakabidhiwa kwa safu ya LLM. Hapa tuna mfumo wa mawakala wengi ambapo wakala mratibu “mkuu” huchanganua ombi la mtumiaji na kulikabidhi kwa wakala aliyebuniwa mahususi kubadilisha safari za ndege, ambaye hatimaye humjibu mtumiaji.
Katika mfano huu, safu ya LLM inatekeleza majukumu ya kiainishaji, kipanga njia na mwandishi wa jibu. Katika mfano wa Kipanga Njia, ilitekeleza tu jukumu la kiainishaji (huku programu ikishughulikia mengine).
Inapowezekana, tunapendekeza usanifu unaotumia kipanga njia kwa sababu una faida zifuatazo:
Kasi na ufanisi: Uchakataji wa ndani una kasi ya juu kuliko waratibu wanaotegemea API za nje. Pia ni nafuu zaidi kuchakata mantiki yako ya “IF/ELSE” katika Python kuliko kumlipia mtoa huduma wa LLM aipitishe kwenye muundo wake wenye vigezo bilioni 400.
Uwezo wa kujaribiwa na kutabirika: Ni rahisi zaidi kutatua hitilafu, kujaribu na kudumisha kwa kutumia mbinu zilizoimarika za uundaji programu.
Uwazi na kutegemewa: Tofauti ndogo katika mwenendo hurahisisha utatuzi wa matatizo. Sehemu kubwa zaidi ya mtiririko wa programu pia huwakilishwa katika programu iliyo wazi na inayodhibitiwa kwa matoleo, badala ya uzani wa LLM usio wazi na usiofafanulika.
Hasara za mbinu za kipanga njia ni kwamba zinaweza kuwa ngumu kubadilika, zisizo nyumbufu na zikashindwa kushughulikia matatizo yasiyo na mipaka maalumu. Chatbot inayotoa majibu yaleyale kila wakati inaweza kuonekana kuwa ya kuchosha au iliyodumaa kwa watumiaji wake.
Miundo ya mratibu ina uwezo mkubwa:
Upangaji: Inaweza kupanga majibu kwa kubadilika kulingana na hali.
Uteuzi wa Zana/Uhamishaji kwa Wakala: Huteua zana zinazofaa au kukabidhi kazi kwa mawakala.
Uunganishaji wa Matokeo kwa Kurudia: Huboresha na kuunganisha upya matokeo kwa ubunifu.
Kuamua Ukamilifu: Huamua wakati ambapo taarifa za kutosha zimekusanywa ili kukamilisha jibu.
Kutumia mifumo kama Pydantic-AI au Agents SDK ya OpenAI hurahisisha uratibu na kuufanya uwe wa haraka kutekeleza. Hivyo, mbinu hii inafaa sana kwa maonyesho au uthibitishaji wa dhana.
Hasara za mbinu hii ni kwamba:
Hakuna hakikisho kwamba hatua za upangaji za LLM na vitendo vinavyofuata zitakuwa sahihi au kufaa. Mfumo wa kipanga njia una tatizo hilohilo, lakini kwa kuwa umewekewa mipaka zaidi, mwenendo wake unatabirika zaidi.
Kwa kazi rahisi na zilizofafanuliwa vizuri, huenda tusihitaji uwezo kamili wa mfumo wa mawakala wengi. Kwa mfano, katika mfano wetu wa Wakala wa Shirika la Ndege, huenda kuna aina chache tu za maombi ambayo mtu anayetumia mfumo wa usaidizi wa shirika la ndege angependa kutekeleza.
Kwa kuwa mantiki nyingi zaidi zimo ndani ya LLM, ni rahisi zaidi kwa wahalifu kuvunja ulinzi wake kwa jailbreak au kuutumia vibaya.
Huficha ufanyaji maamuzi ndani ya LLM, hivyo kufanya mfumo wako uwe mgumu kuelewa (ingawa zana za ufuatiliaji kama Langfuse au Braintrust zinaweza kusaidia kwa kiasi fulani).
Dokezo kwa msomaji: ingawa uwezo wa muundo unabadilika haraka, huenda maelezo yaliyo hapa chini yasibadilike hivi karibuni.
Bainisha upeo wa tatizo lako.
Je, unaweza kufafanua kwa urahisi mantiki unayotaka ya kufanya maamuzi katika mchoro?
Je, programu yako haipaswi kamwe kushindwa au kuonyesha mwenendo usiotarajiwa?
Kujibu “ndiyo” kwa mojawapo ya maswali hayo kunaonyesha kuwa vipengele vya kipanga njia vinafaa zaidi.
Inapowezekana, tunapendekeza utumie mbinu za kipanga njia kwa muda wote zinapotosheleza. Kama kanuni ya jumla, ikiwa sehemu ya mfumo wako inaweza kuwakilishwa katika msimbo, basi iweke kwenye msimbo (yaani, usitumie LLM kupita kiasi pasipo ulazima).
Mbinu hizi zinapofikia kikomo, baadhi ya faida za mratibu asiye na mipaka maalumu zinaweza kuigwa kwa njia yenye udhibiti. Kwa mfano:
Uteuzi wa Zana/Uhamishaji kwa Wakala: Hutekelezwa kwa urahisi kupitia matawi ya masharti au viainishaji vya LLM.
Kuamua Ukamilifu: Viainishaji rahisi vya LLM vinaweza kukagua kama jibu limekamilika kabla ya kulirejesha kwa mtumiaji.
Hata hivyo, bila shaka ni vigumu zaidi kutekeleza “Upangaji” na “Uunganishaji wa Matokeo kwa Kurudia” katika mfumo wa kipanga njia usio nyumbufu. Kwa hivyo, kazi inapohitaji uwezo huu (kama inavyoamuliwa na kiainishaji cha LLM au mantiki nyingine), tunapendekeza uunde tawi la mratibu lenye mipaka michache zaidi katika mfumo wako.
Uchaguzi wako kati ya usanifu wa kipanga njia na wa mratibu unapaswa kuzingatia uwazi na uchangamano wa programu yako, pamoja na mtindo wake wa maingiliano. Kwa sasa, mbinu zinazotumia kipanga njia hutoa kutegemewa, ufanisi na urahisi wa kujaribu kazi zilizofafanuliwa vizuri. Waratibu hutoa unyumbufu zaidi kwa maingiliano mapana ya kimazungumzo.
Kadiri LLM zinavyoendelea kuimarika, uwiano kati ya mbinu hizi unaweza kubadilika. Tunapendelea usanifu unaotumia kipanga njia au usanifu mseto kwa kazi za uzalishaji, huku tukihifadhi waratibu kwa matatizo yasiyo na mipaka maalumu yanayohitaji maingiliano yenye kubadilika na yanayofanana na ya binadamu.