Kujenga programu za AI zinazofanya kazi vizuri siyo tu kuhusu kuunda maelekezo (prompt) bora zaidi, bali ni zaidi kuhusu kudhibiti taarifa unazozipa modeli. Ikiwa umewahi kukaa kwenye mazungumzo marefu na msaidizi, kisha ukagundua kuwa amesahau kitu ulichosema dakika kumi zilizopita, basi tayari umeshahisi kinachotokea wakati uhandisi wa muktadha (context engineering) unapofeli. Ni rahisi kudhani kuwa AI ina kumbukumbu mbaya. Ukweli ni kwamba, umegonga kikomo cha uwezo wa dirisha la muktadha (context window).
Ili kujenga mifumo inayobaki ya kuaminika na inayojibu kwa haraka, unahitaji kuelewa misingi mitatu: tokeni, madirisha ya muktadha (context windows), na tofauti kati ya muktadha na kumbukumbu.
Tokeni Ndizo Sarafu Halisi
Tokeni si neno. Unapotuma maandishi kwenye modeli, tokenizer huivunja katika vipande vidogo. Maneno mafupi ya kawaida kama "cat" au "the" yanaweza kila moja kuchukua tokeni moja. Neno la kiufundi lenye msongamano kama "internationalization" hugawanywa katika sehemu kadhaa. Alama za uandishi, nafasi, na alama maalum zote huhesabiwa pia. Hili ni muhimu kwa sababu tokeni huongoza kila kitu: bili yako ya API, kasi ya majibu, na ubora wa matokeo.
Msanidi programu anayepanga gharama kwa kuhesabu maneno anafanya kazi bila mwelekeo sahihi. Maelekezo (prompt) ya maneno mia moja yaliyojaa mabano ya kodi na majina marefu ya vigezo (variable names) yanaweza kuongezeka zaidi ya matarajio. Ndiyo maana tokenizer zipo kama zana zinazojitegemea. Kabla ya kuachia kipengele (feature) kipya, pitisha data zako za kawaida (payloads) kupitia moja. Mara nyingi utagundua kuwa maelekezo ya mfumo, muundo wa awali (boilerplate), na historia ya mazungumzo hula bajeti yako zaidi kuliko swali halisi la mtumiaji. Chukulia tokeni kama rasilimali adimu tangu siku ya kwanza.
Dirisha la Muktadha ni Ubao wa Maandishi (Whiteboard) Wenye Vipimo Maalum
Dirisha la muktadha ni jumla ya kiasi cha taarifa ambacho modeli inaweza kuona katika ombi moja. Ifikirie kama ubao wa maandishi (whiteboard) wenye vipimo maalum. Unaweza kuujaza na sheria za mfumo, historia ya mazungumzo, nyaraka zilizopatikana, na swali la sasa. Lakini mara tu uso wa ubao unapojazwa, kitu lazima kiondolewe. Kumbukumbu za zamani lazima zifutwe, zipigwe picha na kufupishwa, au ubao utajaa kupita kiasi.
Modeli za kisasa hutangaza madirisha ya muktadha yanayovuka kuanzia tokeni elfu chache hadi mamia ya maelfu. Ni rahisi kutoa kosa la kutumia dirisha kubwa kama hifadhi isiyo na kikomo. Siyo hivyo. Ubao bado una kingo zake. Historia inapozidi kikomo, programu lazima iondoe ujumbe wa zamani au uyafupishe. Kuelewa kizuizi hiki kunakusaidia kuacha kutumia dirisha hilo kama kanzi data (database) na kuanza kulitumia kama eneo la kazi linalofanya kazi (active workspace).
Muktadha Si Kumbukumbu
Hapa kuna tofauti inayowachanganya hata wabunifu wenye uzoefu. Modeli yenyewe haina hali ya kudumu (stateless). Haikukumbuki tangu jana, wiki iliyopita, au dakika kumi zilizopita katika kikao tofauti. Wakati AI inaonekana kukumbuka kuwa unapendelea Python kuliko JavaScript, au kwamba unapenda majibu mafupi, kumbukumbu hiyo ipo kwenye tabaka la programu (application layer), siyo kwenye modeli.
Programu huhifadhi ukweli huo kwenye kanzi data (database), cache, au sehemu ya kumbukumbu (memory store). Kila ombi jipya, huingiza data muhimu za wasifu (profile data) tena kwenye maelekezo (prompt). Modeli inasoma tu mswada unaojumuisha mistari yake kutoka sehemu ya kwanza. Haina utambulisho wa kudumu. Mara tu unapoelewa utengano huu, usanifu wako utabadilika. Unaacha kuiomba modeli ikumbuke na kuanza kubuni mifumo inayochukua muktadha sahihi kwa wakati sahihi.
Kwa Nini Muktadha Mwingi Unaweza Kuleta Madhara
Akili ya kawaida inadokeza kuwa taarifa nyingi za awali zinapaswa kutoa majibu bora zaidi. Mara nyingi, kinyume chake hutokea. Muktadha uliopitiliza huleta kelele (noise). Ikiwa unampa modeli kanuni nzima ya kodi (codebase) wakati unahitaji kurekebisha kazi (function) moja tu, unailazimisha itafute ishara katikati ya kelele. Watafiti wamebaini athari ya "Lost in the Middle": modeli mara nyingi huzingatia zaidi maelezo yaliyo mwanzoni na mwishoni mwa maelekezo (prompt), wakati taarifa zilizozikwa katikati hupunguzwa umuhimu au kupuuzwa. Hili si hitilafu unayoweza kurekebisha kwa maneno ya ujanja. Ni tabia ya kimfumo iliyopo katika usanifu wa transformer-based.
Maelekezo (prompts) yaliyovimba pia hukuumiza pale unapohisi. Kila tokeni ya ziada inahitaji hesabu (computation). Ucheleweshaji (latency) huongezeka. Gharama hupanda. Subira ya mtumiaji hupungua. Maelekezo yaliyojazwa nyaraka zisizo na umuhimu huleta migongano, huivuruga modeli kwa maelezo yasiyo ya lazima, na huongeza uwezekano wa jibu kulenga
Tuma tu kile kinachohitajika na kazi. Ikiwa mtumiaji anauliza kuhusu sera yako ya kurejeshewa fedha, usijumuishe mwongozo wa wafanyakazi, hati ya API, na nakala ya masoko ya robo mwaka iliyopita. Uhusiano unashinda ukamilifu.
Tumia RAG kupata hati husika. Retrieval-Augmented Generation inakuwezesha kutafuta katika msingi mkubwa wa maarifa na kuingiza aya zinazoendana zaidi kwenye prompt. Badala ya kumwaga mwongozo wa kurasa elfu moja kwenye dirisha, unaweka (embed) hati zako, unaendesha utafutaji wa kimaana (semantic search) dhidi ya swali la mtumiaji, na kujumuisha aya tatu muhimu zaidi. Modeli inapata kile hasa kinachohitajika, na bajeti yako ya token inabaki vilevile.
Fanya muhtasari wa mazungumzo ya zamani. Nakala kamili za mazungumzo ni ghali na zina kelele nyingi. Badilisha historia ndefu za ujumbe kwa muhtasari unaoendelea. Kwa mfano, badala ya kuipa modeli ujumbe thalathini ya kubadilishana, hifadhi aya moja: "Mtumiaji aliuliza kuhusu kuweka (deployment) Django, alikutana na hitilafu ya faili za kudumu (static files error), na alirekebisha ruhusa. Tatizo la sasa ni uhamiaji wa hifadhidata (database migration) unaofeli kwenye Postgres 14." Muhtasari huo unahifadhi hali bila kuchafua ubao wa kuandikia.
Tenganisha kumbukumbu ya muda mrefu kutoka kwenye mazungumzo ya sasa. Mapendeleo ya mtumiaji, mipangilio ya mradi, na historia ya akaunti yanapaswa kuwa kwenye hifadhi ya kumbukumbu ya nje. Uliza hifadhi hiyo kwa kuchagua. Dirisha la muktadha (context window) la sasa linapaswa kubeba kazi ya haraka tu na muktadha mfupi zaidi wa kibinafsi unaohitajika ili kudumisha mwendelezo.
Fuatilia matumizi ya token wakati wa utendaji (production). Ongezeko la muda wa kusubiri (latency spikes) mara nyingi husababishwa na kuongezeka kwa mkusanyiko wa muktadha (context bloat). Weka tahadhari wakati maombi yanapokaribia kikomo cha modeli yako. Pitia logi ili kutambua prompt zinazobeba uzito usio na lazima. Uboreshaji huanza na swali lile lile kila wakati: ni nini tunaweza kuondoa bila kuharibu kazi?
Jambo la Msingi la Kweli
Programu bora za AI hazishindi kwa sababu zina madirisha makubwa ya muktadha (context windows). Zinashinda kwa sababu zinadhibiti muktadha kwa nidhamu. Ubao mkubwa wa kuandikia hauna faida ikiwa umejaa michoro isiyo na maana. Jenga mifumo inayopata habari, inafanya muhtasari, na kuchuja. Watumiaji wako wanapata majibu ya haraka, gharama za miundombinu yako zinabaki zinazotabirika, na modeli zako hatimaye zinazingatia kile ambacho ni muhimu hasa.
Chanzo: AI Context Engineering: Tokens, Context Windows, & Memory
Jamii: GyaanSetu AI kwenye Telegram