Wakala wa msaada alijibu ombi la mtumiaji la kuweka upya uthibitishaji wa hatua mbili (two-factor authentication) kwa hatua ambazo hazipo kabisa. Jibu lilionekana la uhakika, ombi la HTTP lilirudisha 200 OK, ucheleweshaji (latency) ulikuwa wa kawaida na kila chati ya ufuatiliaji ilibaki ya kijani.

Wakala wa msaada anayeendeshwa na AI alitunga jibu la uongo (hallucinated) kwa sababu ukaguzi wa ndani uliopaswa kukamata hitilafu hiyo haukufanyika kamwe. Dashibodi ambazo wahandisi wanategemea ziliripoti utendaji mzuri, wakati wakala alikuwa akitunga suluhisho kimyakimya.

Kwa nini dashibodi za kawaida hukosa hali ya AI kutunga mambo (AI hallucinations)

Mifumo mingi ya ufuatiliaji (observability stacks) huuchukulia wakala wa AI kama microservice nyingine yoyote: ombi moja la kuingia (inbound request) na jibu moja la kutoka (outbound response). Huweka kumbukumbu za hali ya HTTP, muda wa jibu na idadi ya makosa. Haziweki kumbukumbu za hatua zilizofichika ndani ya ombi – upatikanaji wa nyaraka za nje, simu kwa mifano mikubwa ya lugha (large language models), matumizi ya zana saidizi, na mantiki yoyote ya kinga (guard-rail logic) inayothibitisha matokeo.

Wakati hatua ya upatikanaji (retrieval step) inaporudisha matokeo tupu, modeli mara nyingi "hujaza pengo" kwa maandishi yanayoeleweka. Kutokana na mtazamo wa mfumo wa ufuatiliaji, simu hiyo ilifanikiwa, kwa sababu hakuna kilichofeli na nambari ya hali (status code) ilibaki kuwa 200. Hali hiyo ya kutunga mambo inabaki kuwa isiyoonekana, na dalili pekee ni jibu lisilo sahihi linalomfikia mtumiaji.

Kubadilisha sanduku jeusi (black box) kuwa mti unaosomeka

Hatua ya kwanza ya kurekebisha hitilafu (debugging) kwa uhakika ni kuacha kumtendea wakala kama ombi moja kubwa (monolithic call) na kuanza kuonyesha kila operesheni ya ndani kama mstari wake wenyewe katika jedwali la ufuatiliaji (trace table). Utendaji wa kawaida hugawanyika katika:

  • Wito wa juu wa wakala (top-level agent invocation)
  • Hatua ya upatikanaji inayovuta nyaraka husika
  • Kila uamuzi wa modeli ya lugha (language-model inference) unaochakata data iliyopatikana
  • Kila wito wa zana (k.m., utafutaji wa hifadhidata, ombi la API)
  • Ukaguzi wa kinga (guard-rail checks) unaohakikisha ukweli au uzingatiaji wa sera

Kila mstari huandika muda (timestamp), alama ya mafanikio, na ujumbe (payload) uliopita katika hatua hiyo. Kwa muundo huu, utendaji unakuwa kama mti ambao unaweza kukaguliwa mstari kwa mstari badala ya kukisia kutokana na matokeo ya mwisho.

Hitilafu iliyopita bila kugundulika

Katika mwingiliano huo wa msaada wenye hitilafu, ufuatiliaji (trace) ulionekana hivi:

  1. Upatikanaji ulifanya kazi lakini haukurudisha nyaraka zozote.
  2. Hatua inayofuata iliendelea hata hivyo, ikipitisha muktadha tupu kwa modeli.
  3. Modeli ilitengeneza jibu ambalo lilijaza habari iliyokosekana kwa hatua za kutungwa.
  4. Mfumo ulirudisha 200 kwa sababu mchakato (pipeline) haukukutana na hitilafu (exception).

Hali hiyo ya kutunga mambo haikuwa kasoro katika modeli ya lugha yenyewe; ilikuwa ni ukosefu wa kinga (guard-rail) kati ya hatua za upatikanaji na hatua za uundaji. Wakala alijibu hata wakati hakuwa na kitu cha kutegemea ili kutoa jibu lake.

Kinga rahisi zinazozuia hali ya kutunga mambo

Mabadiliko mawili ya wazi yaliondoa tatizo hilo:

  • Sitisha wakati upatikanaji ni tupu – ikiwa hifadhi ya nyaraka hairudishi kitu, wakala lazima ajibu kwa “Sikuweza kupata habari unayohitaji” badala ya kuendelea na uundaji.
  • Ukaguzi wa msingi (Grounding check) – baada ya modeli kutoa jibu, hakikisha kuwa kila dai la ukweli linapatikana katika maudhui yaliyopatikana. Ikiwa ukaguzi utafeli, kataa jibu na urudi kwenye jibu la “haiwezi kujibu”.

Mtiririko wa kazi wa vitendo kwa ajili ya kurekebisha hitilafu haraka

  1. Fuatilia kila wito wa ndani – weka vifaa vya ufuatiliaji kwa wakala ili kila upatikanaji, uamuzi wa modeli, na matumizi ya zana yaandike mstari kwenye kumbukumbu ya kudumu (persistent log).
  2. Hifadhi utendaji ulioshindwa – hifadhi ufuatiliaji kamili wa mwingiliano wowote ambao mtumiaji anaripoti kuwa si sahihi. Kuyafuta ili kuokoa nafasi ya kuhifadhi huficha data inayohitajika kupata kurudi nyuma kwa ubora (regressions).
  3. Weka alama kwenye utendaji kwa taarifa za toleo – jumuisha utambulisho wa toleo (release identifier) na hali yoyote ya bendera ya kipengele (feature-flag state) katika kila mstari wa ufuatiliaji. Hii inakuwezesha kuhusisha hitilafu mpya na mabadiliko ya hivi karibuni ya kodi.
  4. Pima ubora, si kasi pekee – ongeza vipimo vinavyopima jinsi jibu linavyofuata maelekezo na linavyobaki na msingi katika maudhui yaliyopatikana. Uzalishaji mkubwa (high throughput) hauna maana ikiwa majibu ni makosa.
  5. Kagua kushindwa kila siku – ukaguzi mfupi na wa mara kwa mara wa kushindwa kulikohifadhiwa mara nyingi hufichua mifumo (k.m., aina fulani ya swali inarudisha upatikanaji tupu mara kwa mara) kabla hayajaathiri watumiaji wengi.

Kwa kubadilisha “kijani” kuwa “imethibitishwa”, timu zinaweza kukamata hali ya kutunga mambo mapema na kuweka uzoefu wa mtumiaji kuwa wa kuaminika.

Gharama ya kupuuza kushindwa kwa ndani

Wakati dashibodi zinaporipoti mafanikio katika tabaka la HTTP pekee, mashirika hutumia mawakala ambao wanaonekana wa kuaminika lakini mara kwa mara hutoa mwongozo usio sahihi.

Nini cha kufuatilia baadaye

Mpaka pale zitakapokuwa za kawaida, njia salama zaidi ni kuchukulia kila operesheni ya ndani kama inayoweza kufuatiliwa na kufeli haraka wakati ushahidi unapokosekana.

Funzo muhimu: Dashibodi ya kijani inakuambia kuwa mifumo ya ndani inafanya kazi; haihakikishii kuwa jibu ni sahihi. Kwa kufuatilia kila upatikanaji wa data, wito wa modeli, na ukaguzi wa kinga, unageuza hali za uongo zisizoonekana (hallucinations) kuwa makosa yanayoonekana ambayo yanaweza kurekebishwa kabla hayajamfikia mtumiaji.