Nilikuwa ninaichukulia pipeline yangu ya RAG kama black box. Embeddings ziliingia, majibu yakatoka, na mahali fulani katikati, bili yangu ya cloud ilikua. Kama watengenezaji wengi niliowazungumza, nilidhani mifano ya dense vector ndiyo ilikuwa mpinzani. Ilisikika kama ni ghali. Kubadilisha kurasa elfu moja kuwa floats za vipimo vingi (high-dimensional floats) kulihisi kama uzalishaji mzito wa viwandani, kwa hivyo niliichukulia kwa tahadhari inayostahili. Hata nilijenga tabaka la caching (caching layer) mahususi ili kuepuka kuweka embedding tena data ambayo nilikuwa tayari nimeichakata. Nilijivunia uboreshaji huo. Kisha nikafungua ankara na kufanya hesabu.

Nilikuwa ninafanya uboreshaji kwenye kitu kisichofaa kabisa.

Mtego wa Embedding

Hapa kuna namba iliyovunja dhana zangu: kuweka embedding kwenye hati ya kurasa 1,000 inagharimu takriban senti kumi na nane. Hiyo si makosa ya uandishi. Kwa bei ndogo kuliko kikombe cha kahawa katika miji mingi, unaweza kuweka katika mfumo wa vector kitabu kizima. Muhimu zaidi, gharama hiyo inatokea mara moja, wakati wa ingestion. Baada ya hatua hiyo ya awali, vector hizo hukaa kwenye hifadhi na kusubiri. Hazitozi ada kila wakati mtumiaji anapofungua programu yako. Ni gharama ya mtaji (capital expense), si hasara inayojirudia.

Hata hivyo, uvumi huo unaendelea. Sehemu ya mkanganyiko ni kimuundo. Pipeline ya ingestion ndipo wahandisi wanapotumia nguvu zao za awali. Unaandika chunker, unapambana na tokenizer, unatazama progress bars zikitembea kwenye terminal yako. Jitihada hizo zinazoonekana zinatengeneza dhana ya uwiano usio sahihi. Inahisi kama sehemu ya gharama kubwa kwa sababu ndiyo sehemu inayohitaji nguvu kazi nyingi. Lakini nguvu kazi na gharama si kitu kimoja, na katika RAG mara nyingi zinahusiana kinyume.

Bili Tatu Tofauti Kabisa

Mara tu nilipotenganisha gharama kwa hatua badala ya kuzichanganya, picha ilieleweka. Mfumo wa RAG unaendeshwa kwa mifumo mitatu tofauti ya kiuchumi, na kuelewa tofauti hiyo ni muhimu ikiwa unataka kuweka bajeti yako katika hali ya kawaida.

Embeddings ni gharama ya uzalishaji ya mara moja. Unalipia kubadilisha hati kuwa vector, na kisha umemaliza. Ikiwa hati zako ni tuli (static), kipengele hiki hakionekani kabisa kwenye bili yako ya kila mwezi.

Vector databases ni kodi ya miundombinu. Unalipia ili kuweka mfumo hai saa masaa 24. Unalipia SSDs zinazoshikilia vipande (chunks) milioni, kwa CPU cores zinazodumisha indexes, na kwa mtandao unaotoa utafutaji wa chini ya milisekunde 100. Gharama hii ni halisi, na huongezeka kulingana na kiasi cha data, lakini kwa ujumla inatabirika. Inafanya kazi kama uanachama wa gym. Iwe unauliza mara moja au elfu kumi, gharama ya msingi ya miundombinu inabaki karibu sawa.

Large language models ni kodi ya matumizi. Kila swali la mtumiaji linasababisha bili. Kila token inayotoka kwenye tabaka lako la retrieval na kuingia kwenye prompt inagharimu pesa. Kila hatua ya kufikiri (reasoning step), kila maelekezo ya uandishi, kila nukuu (citation) unayoiomba modeli itengeneze inaongeza uzito mdogo sana. Lakini malipo hayo madogo yanazidishwa na idadi ya vikao (sessions), na idadi ya vikao huongezeka. Hapa ndipo latency huongezeka pamoja na matumizi. Swali linalochelewa si kero tu kwa mtumiaji; linachoma pesa wakati mtumiaji anasubiri.

Hizi si tofauti za tatizo moja. Ni matatizo matatu tofauti. Huwezi kutatua tatizo la matumizi wakati wa kuuliza swali kwa kufanya ingestion iwe rahisi zaidi. Hiyo ni kama kurekebisha injini ya gari lako ili kuokoa pesa za maegesho.

Pesa Hupotea Wapi Haswa

Ikiwa unaendesha programu ya RAG ya uzalishaji (production), fungua cost explorer yako na uchuje kwa aina ya matumizi. Niko tayari kuweka dau kwamba kazi yako ya embedding ni mstari ulio sawa (flat line) mara moja kwa siku, wakati LLM endpoint yako inaonekana kama mapigo ya moyo yanayopanda kulingana na msongamano wa trafiki. Mtindo huo unaelezea hadithi nzima. Vector zako zinalala; modeli yako inaamka kila wakati mtumiaji anapokuwa na swali.

Ufahamu huo ulibadilisha jinsi ninavyopanga vipaumbele vya kazi za uhandisi. Niliacha kuuliza jinsi ya kufanya ingestion iwe rahisi zaidi na nikaanza kuuliza jinsi ya kufanya kila swali liwe na gharama ndogo zaidi. Mabadiliko hayo yanaonekana kuwa ya wazi, lakini timu nyingi bado zinafanya kazi kwa hisia tu. Wanajenga mantiki tata ya kuondoa marudio (deduplication logic) kwa hatua ya embedding na kisha wanawapa LLM madirisha ya muktadha (context windows) yaliyovimba bila kufikiria mara ya pili. Wanapiga rangi sakafu wakati paa linavuja.

Jinsi ya Kupunguza Gharama Bila Kuharibu Mfumo Wako

Kuokoa pesa katika mfumo wa RAG kunahitaji kuoanisha mbinu na mfumo wa gharama. Hapa kuna kile kinachofanya kazi hasa.

Ondoa Marudio Kabla ya Kuchakata

Mifumo mingi ya maarifa ya mashirika (knowledge bases) huenda polepole. Sera, miongozo, PDF za utafiti, na ripoti zilizohifadhiwa hukaa bila kuguswa kwa miezi kadhaa. Katika mifumo mingi ya usindikaji (pipelines), takriban asilimia themanini ya hati chanzo hubaki vilevile kati ya awamu za uingizaji (ingestion runs). Licha ya hayo, mifumo mingi hufuta mkusanyiko mzima wa data (corpus) na kujenga upya kielezo (index) kuanzia mwanzo kulingana na ratiba. Usifanye hivyo. Jenga kizuizi (gate) kwenye mlango wa mfumo wako wa usindikaji. Tengeneza hash za faili zinazoingia. Linganisha muda wa marekebisho ya mwisho (last-modified timestamps). Ikiwa hati haijabadilika, iruke kabisa. Kusindika tena faili zisizobadilika ni upotevu mtupu. Inagharimu nguvu za kompyuta (compute), inachosha SSDs bila sababu, na inajaza kumbukumbu za usindikaji (ingestion logs) kwa shughuli zisizo za lazima.

Kiutendaji, hifadhi orodha nyepesi (manifest) inayounganisha njia za faili (file paths) na checksums. Wakati ratiba (scheduler) inapofanya kazi, iache ikague orodha hiyo kwanza. Ni sehemu ndogo tu ya faili zilizobadilika zinazopaswa kupitia mchakato wa kugawa (chunker).

Rekebisha Hati, Usizibadilishe Zote

Hati inapobadilika, epuka tabia ya kuichukulia kama faili jipya kabisa. Maelezo ya kiufundi ya kurasa hamsini yanaweza kupata marekebisho ya aya mbili tu katika sehemu ya nne. Ikiwa mfumo wako wa usindikaji utabadilisha faili nzima, utagawanya na kuweka (re-chunk and re-embed) kurasa arobaini na tisa ambazo ni nzuri kabisa bila sababu yoyote.

Badala yake, linganisha toleo jipya na lile la zamani. Tambua tofauti (delta). Kisha gawanya na weka (re-chunk and re-embed) tu sehemu zilizoandaliwa upya. Tumia metadata kama vile namba za kurasa, ID za sehemu, header anchors, au masafa ya aya ili kufuatilia mipaka. Ikiwa mkakati wako wa kugawa (chunking strategy) unaheshimu muundo wa hati, jambo hili ni rahisi. Ikiwa haufanyi hivyo, kurekebisha chunker wako ni uwekezaji bora kuliko kununua cluster kubwa zaidi ya inference. Gharama ya kihandisi ya kudumisha mfumo unaozingatia tofauti (diff-aware pipeline) hujilipa ndani ya wiki chache pindi idadi ya hati inapoongezeka.

Kabiliana na Gharama Zinazojirudia Moja kwa Moja

Kwa kuwa simu za LLM hufanyika kwa kila swali, kupunguza hata token chache au kuhifadhi (caching) majibu machache kunaleta faida kubwa sana. Anza na prompt caching. Ikiwa mtumiaji mmoja anauliza kuhusu sera yako ya kurejeshewa fedha na mwingine anauliza kitu kilekile dakika kumi baadaye, hakuna sababu ya kuuliza modeli mara mbili. Hifadhi jozi za swali-jibu za hivi karibuni kwa kutumia ulinganifu wa kimaana (semantic similarity matching). Swali jipya linapokuwa na ulinganifu wa karibu na lile lililohifadhiwa, rudisha jibu lililohifadhiwa moja kwa moja. Hakuna token zinazozalishwa, hakuna dola zinazotumika.

Kisha, kagua kwa makini ubora wa upatikanaji wako wa taarifa (retrieval quality). Mtafuta taarifa (retriever) asiye na mpangilio huilazimisha LLM kusoma nyasi nyingi ili kupata sindano. Ikiwa utajaza prompt na sehemu (chunks) isiyo na umuhimu ishirini kwa sababu kiwango chako cha top-k ni kikubwa mno, unalipia modeli kusoma kelele tu. Imarisha upatikanaji wako (retrieval). Punguza top-k yako. Punguza ukubwa wa chunks kabla ya kuzituma. Ondoa sehemu zisizo za lazima kama vile footers na headers wakati wa uingizaji ili zisifikie prompt kamwe. Kila token unayoiondoa kwenye dirisha la muktadha (context window) ni sehemu ndogo ya senti inayookolewa, na sehemu hizo hujikusanya kupitia maelfu ya maswali ya kila siku.

Upatikanaji bora pia huboresha kasi ya majibu (latency), ambayo ni aina nyingine ya gharama. Watumiaji huacha kutumia mifumo inayochelewa. Jibu la haraka ni rahisi zaidi kuzalisha na ni bora zaidi kwa kuwafanya watumiaji wabaki.

Hitimisho la Kweli

Acha kuboresha kile kinachoonekana kuwa ghali na anza kuboresha kile ambacho ankara yako inasema ni ghali. Pima kila hatua kando. Huenda ukagundua kuwa embeddings ni sehemu rahisi, hifadhi ya vector (vector storage) ni sehemu ya kawaida, na LLM inference ndiyo sehemu inayotumia pesa nyingi zaidi. Elekeza nguvu zako kwenye ufanisi wakati wa kuuliza maswali (query-time efficiency), maboresho ya hatua kwa hatua (incremental updates), na uondoaji wa data zinazojirudia kwa usahihi (surgical deduplication). Jenga kwa ajili ya swali la elfu ya mtumiaji, siyo kupakia hati ya hamsini. Kikwazo mara nyingi si pale unapofikiri kilipo.

Chanzo: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing

Jiunge na mjadala katika GyaanSetu AI learning community.