Hakuna Aliyepima Ile Asilimia 2 Ambapo Modeli Inabadilisha Namba Yako ya Ankara
Chapisho maarufu la wasanidi programu linadai kuwa nusu ya mawakala wa AI (AI agents) wanaotumika kwenye uzalishaji ni miti ya maamuzi yenye bili ya GPU. Matukio yaliyotumika ni ya mfano tu, na data halisi ni makubaliano ya wataalamu wanaofanya kazi hiyo.
Ile asilimia 2 ambayo hakuna anayeirekodi
Hili ndilo tukio la mfano lililo kiini cha chapisho la DEV.to lililochapishwa wiki hii na Dimitris Kyrkos, mchambuzi wa soko katika Cyclopt, Thessaloniki. Timu moja inahitaji kutoa namba za ankara (invoice) kutoka kwenye barua pepe (email) zinazoingia. Namba hizo zina muundo maalum usiobadilika: INV- ikifuatiwa na tarakimu nane. Timu hiyo inatuma kila barua pepe kwa modeli kubwa ya lugha (large language model, yaani modeli ya AI inayoelewa na kuzalisha maandishi) pamoja na prompt (maelekezo ya maandishi kwa AI) inayoiomba kutoa namba hiyo.
Inafanya kazi kwa asilimia 98 ya muda. Kwenye ile asilimia 2 iliyobaki, Kyrkos anaandika, modeli "kwa nia njema" inabadilisha muundo wa namba hiyo, au inachukua namba ya agizo la ununuzi (purchase order) badala yake. Kila simu inagharimu pesa na inaongeza mamia kadhaa ya milisekunde. Regular expression (kanuni ya kulinganisha muundo wa maandishi) ya mistari minne hufanya kazi hiyo hiyo kwa uhakika kamili, kwa mikrosekunde, bila gharama inayoonekana.
Tuwe wazi kuhusu hili ni nini: Kyrkos anasema waziwazi kuwa matukio yake ni ya mfano, si tafiti halisi za kesi. Ile asilimia 98 ni namba ya kuwakilisha tu, si kipimo halisi. Kinachofanya chapisho hili listahili kusomwa si namba hiyo, bali kilichotokea kwenye maoni ya wasomaji.
Makosa matatu ya kategoria, yakifafanuliwa
Hoja hii inasimama juu ya tofauti inayopotea kwenye mazungumzo ya ununuzi wa AI: tofauti kati ya maswali kuhusu ukweli na maswali kuhusu maana.
Regular expression ni kanuni ya kulinganisha muundo. Ukipewa "INV- kisha tarakimu nane," ama inapata inayolingana au haipati. Hakuna uwezekano (probability) unaohusika, hakuna mpangilio wa temperature, hakuna mara inayoamua kuwa ya ubunifu. Hiyo ndiyo biashara: hakuna kubadilika, utabirika kamili.
Vector search (utafutaji wa vekta) hufanya kazi kinyume chake. Maandishi hubadilishwa kuwa orodha ya namba, inayoitwa embedding, inayoyaweka kwenye nafasi ambamo maana zinazofanana hukaa karibu. Kisha unapata matokeo machache ya karibu zaidi, yanayoitwa "top-k." Hii ni nzuri kweli kwa "tafuta tiketi zinazofanana na malalamiko haya." Lakini ni chombo kisichofaa kwa "nionyeshe maagizo yote ambayo hayajalipwa ya mteja 4417 katika siku 30 zilizopita," ambalo Kyrkos analijibu kwa swali la SQL la mistari minne. Igor Eduardo, mhandisi wa AI anayefanya kazi kwenye AI ya kliniki na pharmacovigilance (ufuatiliaji wa usalama wa dawa), alieleza tatizo hilo kwa ukali kwenye maoni: hilo si tatizo la ubora wa urejeshaji wa taarifa, ni kosa la kategoria. Swali la kuchuja lina jibu kamili na sahihi. Orodha ya matokeo ya vekta ni orodha fupi ya uwezekano ambayo haikuombwa kuwa kamili.
Kesi ya tatu ni ya uelekezaji (routing): mpango wa enterprise pamoja na masuala ya malipo huenda kwa usimamizi wa akaunti, hitilafu (bugs) hufungua tiketi, na kila kitu kingine hupata kiungo cha FAQ. Matawi manne. Ukijenga hilo kama wakala huru (autonomous agent), yaani modeli yenye ufikiaji wa zana, mzunguko wa kupanga na hifadhi ya kumbukumbu, uelekezaji unakuwa wa kiuwezekano, wakati mwingine unajirudiarudia, na hakuna anayeweza kujenga upya sababu ya tiketi fulani kwenda kwa timu isiyo sahihi.
Kinachothibitishwa kweli hapa
Hakuna benchmark (kipimo cha ulinganisho), hakuna data ya matumizi ya pesa, hakuna kampuni iliyotajwa. Kinachopatikana kwenye mjadala ni makubaliano mahususi ya wataalamu yasiyo ya kawaida. Eduardo anasema anaendelea kuona kasoro ya pili ndani ya bot za "maarifa." Brian, anayeendesha akaunti ya habari za AI, anasema timu huchukulia uchimbaji wa asilimia 98 kuwa wa kutosha na hazipimi ile asilimia 2 inayobadilisha namba kimyakimya, na anaongeza suluhisho madhubuti: rekodi makosa kama seti iliyowekewa lebo, na baada ya mwezi mmoja utajua kama mabaki hayo ni ya fujo kweli au ni muundo wa pili tu ambao hukuwahi kuuandika.
Mjadala huo pia una kinzani yake wenyewe, ambayo ni sehemu ambayo muhtasari mwingi utairuka. Michael Hairetis, mhandisi wa full-stack mwenye uzoefu wa miaka 25 kwenye uzalishaji, anasema if-statements zake zimekuwa "ai if statements" na anaiita mbinu yenye manufaa. Kyrkos anakubali hoja hiyo: pale sharti lenyewe halieleweki wazi, kipanga njia laini cha LLM (LLM soft router) ni mtindo imara, mradi hatua hiyo ibaki imetengwa ili mfumo uliobaki uendelee kutabirika.
Pierre-Laurent Medori, mkuu wa uhandisi wa backend katika GoodBarber, alitoa mfumo wa kufikiri unaoweza kuhamishika kwa urahisi zaidi. Analinganisha na msimamo wa Python kuhusu madarasa dhidi ya Java, na kutaja hotuba ya Jack Diederich ya mwaka 2012 kwenye PyCon iitwayo "Stop Writing Classes": darasa likiwa na mbinu mbili na moja ni init, hilo ni function. Ukihamishia hapa: ikiwa wakala wako ana zana moja na mpangaji anaichagua kila mara, hiyo ni simu ya function yenye bili ya tokeni. Hoja yake halisi ni ya usanifu: weka hatua hiyo nyuma ya saini ya function ya kawaida, na kuiboresha kutoka if-statement hadi simu ya modeli kunabaki kuwa badiliko la mahali pamoja. Ukifanya mfumo wa wakala (agent framework) kuwa mtindo mkuu tangu siku ya kwanza, kila mtumiaji wake atarithi utegemezi huo.
Maswali Unayopaswa Kujiuliza
- Kwa kila aina ya swali ambalo mfumo wako unajibu, je, ni kamili (exact), kichujio (filter), au maana (semantic)? Ikiwa ni kamili au kichujio na njia bado inapita kwenye embeddings na mzunguko wa wakala, matumizi ya GPU yananunua nini?
- Je, unarekodi visa ambapo matokeo ya modeli yanapingana na ukaguzi wa kanuni thabiti, na je, kuna mtu aliyewahi kuangalia seti hiyo?
- Uamuzi wa uelekezaji ukiwa mbaya, je, mtu anaweza kujenga upya sababu ndani ya saa moja, au jibu linahusisha maneno "mpangaji aliamua"?
- Ikiwa hali ya kushindwa ni data mbaya inayopita kimyakimya badala ya hitilafu inayoonekana, kwa nini kuna kipengele kisichotabirika kwenye njia hiyo kabisa?
- Nani ataboresha, kuelewa na kutatua matatizo ya kila framework kwenye mfumo miezi kumi na miwili kuanzia sasa, na je, wamekubali jukumu hilo?
Cha Kufuatilia Baadaye
Fuatilia kama kuna mtu atachapisha kipimo ambacho mjadala huu unakosa: timu ya uzalishaji ikiweka namba halisi kwenye mabaki hayo, ni pembejeo ngapi zinaangukia kwenye njia ya kanuni thabiti, modeli inarejesha nini, na inaharibu nini kimyakimya. Pendekezo la Brian ndilo toleo la gharama nafuu zaidi la jaribio hilo, na linachukua mwezi mmoja. Hadi mtu atakapolifanya na kuonyesha data, "nusu ya mawakala wanaotumika kwenye uzalishaji ni if-statements" inabaki kuwa dhana iliyojengewa hoja nzuri yenye uungwaji mkono mkubwa wa wataalamu, ambayo ni zaidi ya ushauri wa usanifu wa AI mwingi, lakini bado ni pungufu ya kile ambacho uamuzi unapaswa kutegemea.
- 1Thibitisha kila uchimbaji wa LLM dhidi ya muundo unaojulikana (kwa mfano, regex ^INV-\d{8}$) na peleka yanayoshindwa kwenye njia mbadala au ukaguzi wa binadamu.
- 2Ikiwa data unayolenga ina muundo thabiti usiobadilika, tumia regex kwanza na uite modeli kwa maandishi ambayo regex imeshindwa kuyalinganisha tu.
- 3Rekodi kiwango cha tofauti kati ya matokeo ya modeli yako na ukaguzi wa kanuni, ili ile asilimia 2 ya kimyakimya ionekane kama kipimo badala ya malalamiko ya mteja.
Ready to implement AI in your business?
Our team builds the AI systems you just read about. Start with a free 30-minute discovery meeting.
