ഞാൻ എന്റെ RAG പൈപ്പ്ലൈനെ ഒരു ബ്ലാക്ക് ബോക്സ് പോലെയാണ് കണ്ടിരുന്നത്. എംബെഡിംഗുകൾ അകത്തേക്ക് പോയി, ഉത്തരങ്ങൾ പുറത്തേക്ക് വന്നു, അതിനിടയിൽ എവിടെയോ എന്റെ ക്ലൗഡ് ബിൽ വർദ്ധിച്ചുകൊണ്ടിരുന്നു. ഞാൻ സംസാരിച്ച മിക്ക ഡെവലപ്പർമാരെയും പോലെ, ഡെൻസ് വെക്റ്റർ മോഡലുകളാണ് ഇതിന്റെ കുറ്റവാളികൾ എന്ന് ഞാൻ കരുതി. അവ വളരെ ചിലവേറിയതാണെന്ന് തോന്നിയിരുന്നു. ആയിരം പേജുകളെ ഹൈ-ഡൈമൻഷണൽ ഫ്ലോട്ടുകളാക്കി മാറ്റുന്നത് വലിയൊരു നിർമ്മാണ പ്രക്രിയ പോലെയായിരുന്നു, അതിനാൽ ഞാൻ അതീവ ജാഗ്രതയോടെയാണ് അതിനെ കൈകാര്യം ചെയ്തത്. നേരത്തെ പ്രോസസ് ചെയ്ത ഡാറ്റ വീണ്ടും എംബെഡ് ചെയ്യുന്നത് ഒഴിവാക്കാൻ ഞാൻ പ്രത്യേകം ഒരു കാഷിംഗ് ലെയർ (caching layer) പോലും നിർമ്മിച്ചു. ആ ഒപ്റ്റിമൈസേഷനിൽ ഞാൻ അഭിമാനിച്ചിരുന്നു. എന്നാൽ പിന്നീട് ഇൻവോയ്സ് പരിശോധിച്ചപ്പോൾ കണക്കുകൾ തെറ്റാണെന്ന് ഞാൻ മനസ്സിലാക്കി.
ഞാൻ ഒട്ടും തെറ്റായ കാര്യമാണ് ഒപ്റ്റിമൈസ് ചെയ്തുകൊണ്ടിരുന്നത്.
എംബെഡിംഗ് കെണി (The Embedding Trap)
എന്റെ ധാരണകളെ തെറ്റിച്ച ആ കണക്ക് ഇതാ: 1,000 പേജുള്ള ഒരു ഡോക്യുമെന്റ് എംബെഡ് ചെയ്യാൻ ഏകദേശം പതിനെട്ട് സെന്റ് മാത്രമേ ചിലവ് വരുന്നുള്ളൂ. ഇത് ടൈപ്പിംഗ് പിശകല്ല. മിക്ക നഗരങ്ങളിലും ഒരു കപ്പ് കോഫിയുടെ വിലയേക്കാൾ കുറഞ്ഞ ചിലവിൽ നിങ്ങൾക്ക് ഒരു പുസ്തകം മുഴുവൻ വെക്റ്ററൈസ് ചെയ്യാം. അതിലുപരിയായി, ഈ ചിലവ് വരുന്നത് ഡാറ്റ ഇൻജസ്റ്റ് (ingestion) ചെയ്യുന്ന സമയത്ത് ഒരു തവണ മാത്രമാണ്. ആദ്യഘട്ടത്തിന് ശേഷം, ആ വെക്റ്ററുകൾ സ്റ്റോറേജിൽ ഇരിക്കും. ഓരോ തവണയും ഒരു ഉപയോക്താവ് നിങ്ങളുടെ ആപ്ലിക്കേഷൻ തുറക്കുമ്പോഴും അവയ്ക്ക് അധിക ചിലവ് വരുന്നില്ല. അവ ഒരു മൂലധന ചിലവാണ് (capital expense), ആവർത്തിച്ചു വരുന്ന ചിലവല്ല.
എങ്കിലും ഈ തെറ്റായ ധാരണ ഇപ്പോഴും നിലനിൽക്കുന്നു. ഇതിന്റെ ഒരു കാരണം ഘടനാപരമായതാണ്. എൻജിനീയർമാർ അവരുടെ ആദ്യകാല ഊർജ്ജം ചെലവഴിക്കുന്നത് ഇൻജഷൻ പൈപ്പ്ലൈനിൽ ആണ്. നിങ്ങൾ ചങ്കർ (chunker) എഴുതുന്നു, ടോക്കണൈസറുമായി (tokenizer) പൊരുതുന്നു, ടെർമിനലിൽ പ്രോഗ്രസ് ബാറുകൾ നീങ്ങുന്നത് നോക്കി നിൽക്കുന്നു. ഈ പ്രകടമായ പരിശ്രമം ഒരു തെറ്റായ തോന്നിപ്പിക്കൽ ഉണ്ടാക്കുന്നു. ഇത് വളരെ അധ്വാനം ആവശ്യമുള്ള ഭാഗമായതുകൊണ്ട്, ഇതാണ് ഏറ്റവും ചിലവേറിയ ഭാഗം എന്ന് നമുക്ക് തോന്നുന്നു. എന്നാൽ അധ്വാനവും ചിലവും ഒന്നല്ല, RAG-ൽ അവ പലപ്പോഴും വിപരീത അനുപാതത്തിലാണ് പ്രവർത്തിക്കുന്നത്.
മൂന്ന് വ്യത്യസ്തമായ ബില്ലുകൾ
ചിലവുകളെ ഒന്നിച്ച് കാണുന്നതിന് പകരം ഓരോ ഘട്ടമായി വേർതിരിച്ചു നോക്കിയപ്പോൾ കാര്യങ്ങൾ വ്യക്തമായി. ഒരു RAG സിസ്റ്റം മൂന്ന് വ്യത്യസ്ത സാമ്പത്തിക മാതൃകകളിൽ പ്രവർത്തിക്കുന്നു, നിങ്ങളുടെ ബജറ്റ് നിയന്ത്രിക്കണമെങ്കിൽ ഇവ തമ്മിലുള്ള വ്യത്യാസം മനസ്സിലാക്കേണ്ടത് അത്യാവശ്യമാണ്.
എംബെഡിംഗുകൾ എന്നത് ഒരു തവണ മാത്രം വരുന്ന നിർമ്മാണ ചിലവാണ് (one-time manufacturing cost). ഡോക്യുമെന്റുകളെ വെക്റ്ററുകളാക്കി മാറ്റാൻ നിങ്ങൾ പണം നൽകുന്നു, അതിനുശേഷം ആ ജോലി കഴിഞ്ഞു. നിങ്ങളുടെ ഡോക്യുമെന്റുകൾ സ്ഥിരമാണെങ്കിൽ (static), മാസ ബില്ലിൽ ഈ തുക വളരെ കുറവായിരിക്കും.
വെക്റ്റർ ഡാറ്റാബേസുകൾ എന്നത് ഇൻഫ്രാസ്ട്രക്ചർ വാടകയാണ് (infrastructure rent). സിസ്റ്റം ഇരുപത്തിനാല് മണിക്കൂറും പ്രവർത്തിക്കാൻ നിങ്ങൾ പണം നൽകുന്നു. ദശലക്ഷക്കണക്കിന് ചങ്കുകൾ (chunks) സൂക്ഷിക്കുന്ന SSD-കൾക്കും, ഇൻഡക്സുകൾ നിലനിർത്തുന്ന CPU കോറുകൾക്കും, സെക്കൻഡിന്റെ നൂറിലധികം ഭാഗത്തിനുള്ളിൽ സെർച്ച് റിസൾട്ട് നൽകുന്ന നെറ്റ്വർക്കിനും നിങ്ങൾ പണം നൽകുന്നു. ഈ ചിലവ് യഥാർത്ഥമാണ്, ഡാറ്റയുടെ അളവ് കൂടുന്നതിനനുസരിച്ച് ഇത് വർദ്ധിക്കുകയും ചെയ്യും, എങ്കിലും ഇത് പൊതുവെ പ്രവചിക്കാവുന്നതാണ്. ഇത് ഒരു ജിം മെമ്പർഷിപ്പ് പോലെയാണ്. നിങ്ങൾ ഒരു തവണ ക്വറി ചെയ്താലും പതിനായിരം തവണ ചെയ്താലും അടിസ്ഥാന ഇൻഫ്രാസ്ട്രക്ചർ ചിലവ് ഏകദേശം ഒരുപോലെ തന്നെയായിരിക്കും.
ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (LLMs) എന്നത് ഉപയോഗത്തിനനുസരിച്ചുള്ള നികുതിയാണ് (consumption taxes). ഓരോ ഉപയോക്താവിന്റെ ചോദ്യവും ഒരു ബില്ല് ഉണ്ടാക്കുന്നു. നിങ്ങളുടെ റിട്രീവൽ ലെയറിൽ നിന്ന് പ്രോംപ്റ്റിലേക്ക് പോകുന്ന ഓരോ ടോക്കനും പണം ചിലവാക്കുന്നു. ഓരോ റീസണിംഗ് സ്റ്റെപ്പും, ഫോർമാറ്റിംഗ് ഇൻസ്ട്രക്ഷനും, മോഡലിനോട് ആവശ്യപ്പെടുന്ന ഓരോ സൈറ്റേഷനും ചെറിയ രീതിയിൽ ചിലവ് കൂട്ടുന്നു. എന്നാൽ ഈ ചെറിയ തുകകൾ സെഷനുകളുടെ എണ്ണം കൂടുന്നതിനനുസരിച്ച് വലിയ തുകയായി മാറുന്നു. ഇവിടെയാണ് ലേറ്റൻസിയും (latency) ചിലവും തമ്മിലുള്ള ബന്ധം കൂടുന്നത്. ഒരു സാവധാനത്തിലുള്ള ക്വറി ഉപയോക്താവിന് ബുദ്ധിമുട്ട് ഉണ്ടാക്കുക മാത്രമല്ല, ഉപയോക്താവ് കാത്തിരിക്കുമ്പോൾ നിങ്ങളുടെ പണം പാഴാക്കുക കൂടിയാണ് ചെയ്യുന്നത്.
ഇവ ഒരേ പ്രശ്നത്തിന്റെ വിവിധ രൂപങ്ങളല്ല. ഇവ മൂന്ന് വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്. ഇൻജഷൻ ചിലവ് കുറച്ചതുകൊണ്ട് ക്വറി സമയത്തെ ചിലവ് കുറയ്ക്കാൻ കഴിയില്ല. അത് പാർക്കിംഗ് ചാർജ് ലാഭിക്കാൻ വേണ്ടി കാറിന്റെ എഞ്ചിൻ ട്യൂൺ ചെയ്യുന്നതുപോലെയാണ്.
പണം യഥാർത്ഥത്തിൽ എവിടെയാണ് പോകുന്നത്?
നിങ്ങൾ ഒരു പ്രൊഡക്ഷൻ RAG ആപ്ലിക്കേഷൻ ആണ് പ്രവർത്തിപ്പിക്കുന്നതെങ്കിൽ, നിങ്ങളുടെ കോസ്റ്റ് എക്സ്പ്ലോറർ (cost explorer) പരിശോധിച്ചു ഉപയോഗത്തിന്റെ തരം അനുസരിച്ച് ഫിൽട്ടർ ചെയ്യുക. നിങ്ങളുടെ എംബെഡിംഗ് ജോബ് ഒരു നേർരേഖ പോലെ സ്ഥിരമായിരിക്കുമെന്നും, എന്നാൽ LLM എൻഡ്പോയിന്റ് ട്രാഫിക് കൂടുന്നതിനനുസരിച്ച് മാറിക്കൊണ്ടിരിക്കുമെന്നും ഞാൻ ഉറപ്പിച്ചു പറയാം. ആ പാറ്റേൺ എല്ലാ കാര്യങ്ങളും വ്യക്തമാക്കുന്നു. നിങ്ങളുടെ വെക്റ്ററുകൾ ഉറങ്ങുകയാണ്; എന്നാൽ ഒരു ഉപയോക്താവിന് ചോദ്യം ഉണ്ടാകുമ്പോഴെല്ലാം നിങ്ങളുടെ മോഡൽ ഉണരുന്നു.
ഈ തിരിച്ചറിവ് എന്റെ എഞ്ചിനീയറിംഗ് ജോലികളുടെ മുൻഗണനകൾ മാറ്റിമറിച്ചു. ഇൻജഷൻ എങ്ങനെ കുറയ്ക്കാം എന്ന് ചോദിക്കുന്നതിന് പകരം, ഓരോ ചോദ്യത്തിന്റെയും ചിലവ് എങ്ങനെ കുറയ്ക്കാം എന്ന് ഞാൻ ചിന്തിക്കാൻ തുടങ്ങി. ഈ മാറ്റം കേൾക്കുമ്പോൾ വളരെ ലളിതമായി തോന്നാം, എന്നാൽ മിക്ക ടീമുകളും ഇപ്പോഴും ഊഹങ്ങളുടെ അടിസ്ഥാനത്തിലാണ് പ്രവർത്തിക്കുന്നത്. അവർ എംബെഡിംഗ് ഘട്ടത്തിനായി സങ്കീർണ്ണമായ ഡ്യൂപ്ലിക്കേഷൻ ലോജിക് നിർമ്മിക്കുന്നു, എന്നാൽ പിന്നീട് LLM-ലേക്ക് അനാവശ്യമായ വിവരങ്ങൾ നിറഞ്ഞ കോൺടെക്സ്റ്റ് വിൻഡോകൾ നൽകുന്നു. അവർ മേൽക്കൂര ചോരുമ്പോഴും തറ മിനുക്കിക്കൊണ്ടിരിക്കുകയാണ്.
പൈപ്പ്ലൈൻ തകരാതെ എങ്ങനെ ചിലവ് കുറയ്ക്കാം
ഒരു RAG സിസ്റ്റത്തിൽ പണം ലാഭിക്കാൻ ഓരോ ചിലവ് മാതൃകയ്ക്കും അനുയോജ്യമായ രീതികൾ സ്വീകരിക്കണം. ഫലപ്രദമായ ചില വഴികൾ താഴെ പറയുന്നവയാണ്.
പ്രോസസ് ചെയ്യുന്നതിന് മുമ്പ് ഡ്യൂപ്ലിക്കേറ്റുകൾ ഒഴിവാക്കുക (Deduplicate Before You Process)
മിക്ക ഓർഗനൈസേഷണൽ നോളജ് ബേസുകളും (knowledge bases) വളരെ സാവധാനത്തിലാണ് പ്രവർത്തിക്കുന്നത്. നയങ്ങൾ, ഹാൻഡ്ബുക്കുകൾ, ഗവേഷണ പിഡിഎഫുകൾ, ആർക്കൈവ് ചെയ്ത റിപ്പോർട്ടുകൾ എന്നിവ മാസങ്ങളോളം മാറ്റമില്ലാതെ കിടക്കുന്നു. പല പൈപ്പ്ലൈനുകളിലും, ഇൻജഷൻ (ingestion) റണ്ണുകൾക്കിടയിൽ ഏകദേശം എൺപത് ശതമാനം സ്രോതസ്സ് ഡോക്യുമെന്റുകളും ഒരേപോലെയാണ് ഇരിക്കുന്നത്. എന്നിരുന്നാലും, പല സിസ്റ്റങ്ങളും മുഴുവൻ കോർപ്പസും (corpus) ഒഴിവാക്കി ഷെഡ്യൂൾ അനുസരിച്ച് ഇൻഡക്സ് ആദ്യം മുതൽ വീണ്ടും നിർമ്മിക്കുന്നു. അത് ചെയ്യരുത്. നിങ്ങളുടെ പൈപ്പ്ലൈനിന്റെ പ്രവേശന കവാടത്തിൽ ഒരു ഗേറ്റ് നിർമ്മിക്കുക. വരുന്ന ഫയലുകൾ ഹാഷ് (hash) ചെയ്യുക. അവസാനമായി മാറ്റം വരുത്തിയ ടൈംസ്റ്റാമ്പുകൾ (timestamps) താരതമ്യം ചെയ്യുക. ഒരു ഡോക്യുമെന്റിൽ മാറ്റം വന്നിട്ടില്ലെങ്കിൽ, അത് പൂർണ്ണമായും ഒഴിവാക്കുക. സ്റ്റാറ്റിക് ഫയലുകൾ വീണ്ടും പ്രോസസ്സ് ചെയ്യുന്നത് വെറുതെ സമയം കളയലാണ്. ഇത് കമ്പ്യൂട്ട് ചിലവ് കൂട്ടുന്നു, എസ്എസ്ഡി (SSD) അനാവശ്യമായി ഉപയോഗിക്കുന്നു, കൂടാതെ ഇൻജഷൻ ലോഗുകളിൽ തെറ്റായ ആക്റ്റിവിറ്റികൾ നിറയ്ക്കുകയും ചെയ്യുന്നു.
പ്രായോഗികമായി, ഫയൽ പാത്തുകളെ ചെക്ക്സമ്മുകളുമായി (checksums) ബന്ധിപ്പിക്കുന്ന ഒരു ലഘുവായ മാനിഫെസ്റ്റ് (manifest) സൂക്ഷിക്കുക. ഷെഡ്യൂളർ പ്രവർത്തിക്കുമ്പോൾ, ആദ്യം മാനിഫെസ്റ്റ് പരിശോധിക്കാൻ അനുവദിക്കുക. മാറ്റം വന്ന കുറഞ്ഞ എണ്ണം ഫയലുകൾ മാത്രം ചങ്കറിലൂടെ (chunker) കടന്നുപോകണം.
ഡോക്യുമെന്റുകൾ പാച്ച് ചെയ്യുക, അവ മാറ്റിവെക്കരുത്
ഒരു ഡോക്യുമെന്റിൽ മാറ്റം വരുമ്പോൾ, അതിനെ ഒരു പുതിയ ഫയലായി കാണാനുള്ള പ്രവണത ഒഴിവാക്കുക. അൻപത് പേജുള്ള ഒരു ടെക്നിക്കൽ സ്പെസിഫിക്കേഷനിൽ നാലാം സെക്ഷനിൽ രണ്ട് പാരഗ്രാഫുകളുടെ ഒരു തിരുത്തൽ വന്നേക്കാം. നിങ്ങളുടെ പൈപ്പ്ലൈൻ മുഴുവൻ ഫയലും മാറ്റിവെക്കുകയാണെങ്കിൽ, കാരണവുമില്ലാതെ നിങ്ങൾ നാൽപ്പത്തിയൊൻപത് പേജുകൾ വീണ്ടും ചങ്ക് ചെയ്യുകയും (re-chunk) എംബെഡ് ചെയ്യുകയും (re-embed) ചെയ്യേണ്ടി വരും.
പകരം, പുതിയ വേർഷനെ പഴയതിനോട് താരതമ്യം ചെയ്യുക. മാറ്റം (delta) തിരിച്ചറിയുക. തുടർന്ന് മാറ്റം വന്ന ഭാഗങ്ങൾ മാത്രം വീണ്ടും ചങ്ക് ചെയ്യുകയും എംബെഡ് ചെയ്യുകയും ചെയ്യുക. പേജ് നമ്പറുകൾ, സെക്ഷൻ ഐഡികൾ, ഹെഡർ ആങ്കറുകൾ അല്ലെങ്കിൽ പാരഗ്രാഫ് റേഞ്ചുകൾ പോലുള്ള മെറ്റാഡാറ്റ ഉപയോഗിച്ച് അതിരുകൾ ട്രാക്ക് ചെയ്യുക. നിങ്ങളുടെ ചങ്കിംഗ് സ്ട്രാറ്റജി ഡോക്യുമെന്റ് ഘടനയെ മാനിക്കുന്നുണ്ടെങ്കിൽ, ഇത് വളരെ ലളിതമാണ്. ഇല്ലെങ്കിൽ, ഒരു വലിയ ഇൻഫറൻസ് ക്ലസ്റ്റർ (inference cluster) വാങ്ങുന്നതിനേക്കാൾ നല്ലൊരു നിക്ഷേപമാണ് നിങ്ങളുടെ ചങ്കർ ശരിയാക്കുന്നത്. ഡോക്യുമെന്റുകളുടെ എണ്ണം കൂടുമ്പോൾ, മാറ്റങ്ങൾ തിരിച്ചറിയുന്ന (diff-aware) ഒരു പൈപ്പ്ലൈൻ നിലനിർത്തുന്നതിനുള്ള എഞ്ചിനീയറിംഗ് ചിലവ് ആഴ്ചകൾക്കുള്ളിൽ തന്നെ ലാഭമായി തിരിച്ചുകിട്ടും.
ആവർത്തിച്ചുവരുന്ന ചിലവുകളെ നേരിട്ട് നേരിടുക
ഓരോ ക്വറിയും നടക്കുമ്പോൾ LLM കോളുകൾ പ്രവർത്തിക്കുന്നതിനാൽ, ഏതാനും ടോക്കണുകൾ കുറയ്ക്കുന്നതോ അല്ലെങ്കിൽ കുറച്ച് മറുപടികൾ കാഷ് (cache) ചെയ്യുന്നതോ വലിയ ലാഭമുണ്ടാക്കും. പ്രോംപ്റ്റ് കാഷിംഗിൽ (prompt caching) നിന്ന് തുടങ്ങുക. ഒരു ഉപയോക്താവ് നിങ്ങളുടെ റീഫണ്ട് പോളിസിയെക്കുറിച്ച് ചോദിക്കുകയും പത്ത് മിനിറ്റിനുശേഷം മറ്റൊരാൾ അതേ കാര്യം തന്നെ ചോദിക്കുകയും ചെയ്താൽ, മോഡലിനെ രണ്ടുതവണ ഉപയോഗിക്കേണ്ടതില്ല. സെമാന്റിക് സമാനത (semantic similarity) ഉപയോഗിച്ച് സമീപകാല ക്വറി-റെസ്പോൺസ് ജോഡികൾ സൂക്ഷിക്കുക. ഒരു പുതിയ ചോദ്യം കാഷ് ചെയ്ത ഒന്നുമായി സമാനമാണെങ്കിൽ, സൂക്ഷിച്ച മറുപടി നേരിട്ട് നൽകുക. ടോക്കണുകൾ ഉപയോഗിക്കേണ്ടതില്ല, പണവും ചിലവാകില്ല.
അടുത്തതായി, നിങ്ങളുടെ റിട്രീവൽ ക്വാളിറ്റി (retrieval quality) പരിശോധിക്കുക. മോശമായ ഒരു റിട്രീവർ (retriever) ഒരു സൂചി കണ്ടെത്താൻ വൈക്കോൽ കൂമ്പാരത്തിൽ തിരയുന്നത് പോലെ LLM-നെ പ്രയാസപ്പെടുത്തുന്നു. നിങ്ങളുടെ top-k കട്ട്ഓഫ് വളരെ അയഞ്ഞതാണെങ്കിൽ, പ്രോംപ്റ്റിൽ ഇരുപത് അപ്രസക്തമായ ചങ്കുകൾ നിറയ്ക്കുന്നതിലൂടെ നിങ്ങൾ വെറുതെ നോയ്സ് (noise) വായിക്കാൻ മോഡലിന് പണം നൽകുകയാണ് ചെയ്യുന്നത്. നിങ്ങളുടെ റിട്രീവൽ കൂടുതൽ കൃത്യമാക്കുക. top-k കുറയ്ക്കുക. ചങ്കുകൾ അയക്കുന്നതിന് മുമ്പ് അവ കംപ്രസ്സ് ചെയ്യുക. ഇൻജഷൻ സമയത്ത് ബോയ്ലർപ്ലേറ്റ് (boilerplate) ഫൂട്ടറുകളും ഹെഡറുകളും ഒഴിവാക്കുക, അങ്ങനെ അവ പ്രോംപ്റ്റിൽ എത്തുന്നില്ലെന്ന് ഉറപ്പാക്കുക. കോൺടെക്സ്റ്റ് വിൻഡോയിൽ (context window) നിന്ന് നിങ്ങൾ നീക്കം ചെയ്യുന്ന ഓരോ ടോക്കണും ചെറിയൊരു തുക ലാഭിക്കാൻ സഹായിക്കുന്നു, ഈ ചെറിയ തുകകൾ ആയിരക്കണക്കിന് ദൈനംദിന ക്വറികളിലൂടെ വലിയൊരു തുകയായി മാറും.
മികച്ച റിട്രീവൽ ലേറ്റൻസി (latency) കുറയ്ക്കാനും സഹായിക്കുന്നു, ഇത് മറ്റൊരു തരത്തിലുള്ള ചിലവാണ്. പതുക്കെയുള്ള ഇന്റർഫേസുകൾ ഉപയോക്താക്കൾ ഉപേക്ഷിക്കും. വേഗതയേറിയ മറുപടി നൽകുന്നത് ചിലവ് കുറയ്ക്കാനും ഉപയോക്താക്കളെ നിലനിർത്താനും സഹായിക്കുന്നു.
യഥാർത്ഥ പാഠം
ചിലവേറിയതെന്ന് തോന്നുന്ന കാര്യങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നത് നിർത്തി, നിങ്ങളുടെ ഇൻവോയ്സിൽ (invoice) ഏതാണ് ചിലവേറിയതെന്ന് കാണിക്കുന്നത് അത് ഒപ്റ്റിമൈസ് ചെയ്യാൻ തുടങ്ങുക. ഓരോ ഘട്ടവും സ്വതന്ത്രമായി അളക്കുക. എംബെഡിംഗുകൾ (embeddings) കുറഞ്ഞ ചിലവുള്ള ഭാഗമാണെന്നും, വെക്റ്റർ സ്റ്റോറേജ് (vector storage) സ്ഥിരമായ ഭാഗമാണെന്നും, LLM ഇൻഫറൻസ് (LLM inference) ആണ് ഏറ്റവും കൂടുതൽ പണം ചിലവാക്കുന്ന ഭാഗമെന്നും നിങ്ങൾക്ക് കാണാൻ സാധിക്കും. ക്വറി സമയത്തെ കാര്യക്ഷമത (query-time efficiency), ഇൻക്രിമെന്റൽ അപ്ഡേറ്റുകൾ, കൃത്യമായ ഡ്യൂപ്ലിക്കേഷൻ ഒഴിവാക്കൽ എന്നിവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക. അമ്പതാമത്തെ ഡോക്യുമെന്റ് അപ്ലോഡിന് വേണ്ടിയല്ല, ആയിരമത്തെ ഉപയോക്താവിന്റെ ചോദ്യത്തിന് വേണ്ടി പൈപ്പ്ലൈൻ നിർമ്മിക്കുക. തടസ്സങ്ങൾ (bottleneck) നിങ്ങൾ വിചാരിക്കുന്ന ഇടത്തല്ല പലപ്പോഴും ഉണ്ടാകുന്നത്.
Source: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing
Join the discussion in the GyaanSetu AI learning community.