Unapounganisha modeli kubwa ya lugha (LLM) kwenye mtiririko wa kazi unaohitaji binadamu kusema "ndiyo" kupitia barua pepe, mara chache ni modeli yenyewe inayofeli. Hitilafu hutokea pale ambapo kodi inaishia na sanduku la barua pepe (inbox) linapoanza. Mchakato mmoja wa kiotomatiki (autonomous run) unarusha ombi. Kisha mchakato mwingine unaanza kabla ya ule wa kwanza kukamilika. Sanduku la barua pepe la pamoja linakusanya ujumbe kutoka kwa michakato tofauti. Mtu anabonyeza idhini kwenye ujumbe uliowasili kwa kuchelewa saa kumi na mbili. Sasa unayo matokeo. Unayo maamuzi. Lakini huwezi kuthibitisha ni mchakato upi uliozalisha nini, au kama idhini hiyo ilikuwa imekusudiwa kwa ajili ya toleo hilo. Nimesafisha mifumo mingi ya utendaji wa ndani (internal automation pipelines) kiasi kwamba najua mfumo huu. Huongezeka kutoka kwenye mkanganyiko hadi kwenye tukio la dharura kwa kasi kuliko timu nyingi zinavyotarajia.

Mpaka wa Kiutendaji

Mpaka kati ya mratibu (orchestrator) wako na mtoa huduma wako wa barua pepe siyo tu hatua ya mtandao. Ni mpaka wa hali (state boundary). LLM inapomaliza kuandaa rasimu, mchakato huo bado upo hai. Unasubiri. Ikiwa mfumo wako unachukulia utumaji kama tukio la "tuma na usahau" (fire-and-forget), tayari umepoteza ufuatiliaji.

Nimeona mifumo ambapo mchakato mmoja unazalisha maombi mawili tofauti ya idhini kwa sababu sera ya kujaribu tena (retry policy) ilikuwa kali mno. Nimeona mchakato mwingine ukitumia tena sanduku la barua pepe ambalo bado lina ujumbe wa wiki iliyopita. Mtu anayetoa idhini haoni run IDs. Anaona kichwa cha habari cha ujumbe na kitufe. Bila muundo, anakuwa anakisia katika sanduku lile lile la barua pepe ambapo majarida ya masoko na arifa za ufuatiliaji huishi.

Hatua Iliyosahaulika

Timu zitatumia wiki kadhaa kurekebisha maelekezo (prompts), kuongeza vizuizi (guardrails), na kupima matokeo. Kisha zinaunganisha hatua ya idhini kwenye chaneli ya Slack au sanduku la pamoja la msaada na kusema kazi imekamilika. Hii inasababisha madhara matatu yanayotabirika:

  • Sanduku la barua pepe la pamoja linakuwa mahali pa kutupia matukio kutoka kwa michakato (runs) mingi. Muktadha unaporomoka. Huwezi kutambua ujumbe upi ulihusika na muamala gani wa kibiashara bila kufungua ujumbe na kuchambua muda kwa mkono.
  • Majaribio ya kurudia (retries) yanafuta ushahidi. Ikiwa mchakato utatuma tena ombi lake la idhini, ujumbe wa awali unaweza kuzikwa, kufutwa, au kuwekwa alama kama nakala ya ziada na programu ya barua pepe. Mkondo wa ukaguzi (audit trail) unaharibika.
  • Maamuzi ya binadamu yanabaki nje ya mfumo. Mtu anajibu "inaonekana vizuri" kwenye tiketi au ujumbe wa moja kwa moja. Hisia hiyo haitawahi kuwa data iliyopangwa ndani ya mtiririko wa kazi. Wakala (agent) hana njia ya kuthibitisha nani alisema nini, au lini.

Kitu kinapoharibika na unahitaji kuchunguza, unapata maneno ya kusikia tu. "Nadhani huo ulikuwa barua pepe sahihi." Kumbukumbu siyo ufuatiliaji (traceability). Log ya ukaguzi haiwezi kutumia hisia.

Kutoka Kielelezo cha Uwasilishaji hadi Kituo cha Uhakiki

Kurekebisha hili kunahitaji mabadiliko ya usanifu. Acha kufikiria barua pepe kama kielelezo cha uwasilishaji tu. Anza kuichukulia kama kituo cha uhakiki (checkpoint) cha mfumo. Hiyo inamaanisha kila ujumbe ni mabadiliko ya hali (state transition), na kila mabadiliko ya hali unahitaji utambulisho, idhini, na ushahidi.

Unapokubali mtazamo huu, maswali yanabadilika. Huulizi tena kama barua pepe imetumwa kwa mafanikio. Unaanza kuuliza ni mchakato upi uliituma, ni ushahidi gani uliacha nyuma, na ni sheria gani iliruhusu mtiririko wa kazi kuendelea. Wakala anaweza kabisa kuandika mwili wa barua pepe. Lakini jukwaa lako lazima lisimamia njia za utambulisho na uhakiki. LLM ndiye mwandishi. Miundombinu ndiyo notari.

Muundo wa Msingi

Hauhitaji utajiri mkubwa ili kujenga hili. Toleo langu la msingi linatumia vipande vitano vya makusudi.

  • Mratibu (orchestrator) hutengeneza run_id wakati ule ule mtiririko wa kazi unapoanza. Kitambulisho hiki ndicho uti wa mgongo wa kila hatua inayofuata. Hakibadiliki kamwe, na hakitumiki tena kamwe.
  • Kila kitendo cha barua pepe hubeba nyanja tatu: run_id, lebo ya message_type kama vile "approval_request" au "evidence_notification," na mfululizo wa policy_version unaotambulisha ni sheria gani za utawala zilizo hai. Hii inageuza ujumbe wa kawaida kuwa tukio lililopangwa.
  • Ushahidi unabaki kwenye sanduku la barua pepe lililotengwa kwa ajili ya mchakato huo. Hiyo haimaanishi kila mchakato unahitaji akaunti tofauti ya barua pepe. Inaweza kumaanisha lebo maalum, folda ndogo, au sheria ya uelekezaji inayotenganisha ujumbe ili mawasiliano ya mchakato mmoja yasichanganyike na mwingine.
  • Jibu la idhini lazima liwe tukio lililopangwa, siyo maandishi huru ya "ok." Binadamu bado anabonyeza au anajibu, lakini mfumo unatafsiri kitendo hicho kuwa data inayoweza kusomwa na mashine inayotaja run_id, uamuzi, na muda (timestamp).
  • Mtiririko unaendelea tu ikiwa ushahidi na uamuzi vinaendana. Mtiririko wa kazi hauna imani na idhini pekee. Unathibitisha data ya idhini dhidi ya ombi la awali kabla ya kuruhusu matokeo ya LLM yafike kwenye utendaji wa kawaida (production).

Kile Kituo cha Uhakiki Kinachothibitisha

Checkpoint yenye manufaa inatolea masharti manne kabla ya kukubali uamuzi wa binadamu.

  • Mpokeaji lazima awe sehemu ya muktadha wa utendaji (run context). Ikiwa muidhinishaji si mkaguzi aliyeteuliwa kwa mfano huu mahususi wa mtiririko wa kazi (workflow instance), mfumo utakataa ishara hiyo.
  • Mada au metadata ya uelekezaji lazima iendane na hali ya sasa ya mtiririko. Idhini ya hatua ya tatu haipitishi hatua ya pili.
  • Timestamp lazima iwe ndani ya kipindi kinachotarajiwa. Uamuzi unaofika baada ya muda kuisha unapaswa kuchochea ukaguzi mpya, si kupitishwa kiotomatiki.
  • Uthibitisho haupaswi kutumiwa tena na utendaji mwingine. Ikiwa ID ile ile ya ujumbe au token itaonekana katika maombi mawili tofauti ya uidhinishaji, hiyo ni mgongano, na mfumo unapaswa kusimama.

Gharama Halisi

Mtindo huu hauna gharama ya bure. Unahifadhi metadata nyingi zaidi. Unaongeza tabaka la sera ambalo mtu lazima alidhibiti. Unalazimisha timu yako kurekodi maamuzi ya binadamu kama data iliyopangwa badala ya maoni ya kawaida. Inaonekana kama urasimu. Lakini kwa vitendo, ni mabadilishano bora sana.

Unabadilishana kasi kwa ajili ya uwazi.