ഓരോ ലാർജ് ലാംഗ്വേജ് മോഡൽ (LLM) കോളും നിങ്ങളുടെ ബജറ്റിനെ ബാധിക്കുകയും ഉപയോക്താക്കളുടെ ക്ഷമ പരീക്ഷിക്കുകയും ചെയ്യുന്നു. അമ്പത് ആളുകൾ ഏകദേശം ഒരേ കാര്യം തന്നെ ചോദിച്ചാൽ, പരമ്പരാഗത ഇൻഫ്രാസ്ട്രക്ചർ അമ്പത് വ്യത്യസ്ത API റിക്വസ്റ്റുകൾ പ്രോസസ്സ് ചെയ്യാൻ നിങ്ങളെ നിർബന്ധിക്കുന്നു. കാരണം, പരമ്പരാഗത കാഷിംഗ് (caching) കൃത്യമായ സ്ട്രിംഗുകളെ (strings) അടിസ്ഥാനമാക്കിയാണ് പ്രവർത്തിക്കുന്നത്. "What is the capital of France?" എന്നും "Tell me the capital city of France" എന്നും ചോദിച്ചാൽ, ഇവ രണ്ടും ബന്ധമില്ലാത്ത രണ്ട് ചോദ്യങ്ങളായിട്ടാണ് അത് കാണുന്നത്. സെമാന്റിക് കാഷിംഗ് (Semantic caching) അക്ഷരങ്ങൾക്ക് പകരം ഉദ്ദേശ്യം (intent) മനസ്സിലാക്കുന്നു. രണ്ട് ഉപയോക്താക്കളും ഉദ്ദേശിക്കുന്നത് പാരിസ് ആണെന്ന് ഇത് തിരിച്ചറിയുകയും, ഉത്തരം ഒരിക്കൽ മാത്രം സംഭരിക്കുകയും, മോഡലിനെ ബുദ്ധിമുട്ടിക്കാതെ തന്നെ അത് വീണ്ടും നൽകുകയും ചെയ്യുന്നു.

Why Exact Match Falls Short

കീകൾ (keys) മുൻകൂട്ടി പ്രവചിക്കാവുന്നതാണെങ്കിൽ റെഡിസ് (Redis), മെംകാഷഡ് (Memcached) അല്ലെങ്കിൽ ലളിതമായ ഇൻ-മെമ്മറി മാപ്പ് (in-memory map) എന്നിവയെപ്പോലുള്ള സ്റ്റാൻഡേർഡ് കാഷിംഗ് രീതികൾ മികച്ച രീതിയിൽ പ്രവർത്തിക്കും. ഒരു പ്രൊഡക്റ്റ് ഐഡി, യൂസർനെയിം അല്ലെങ്കിൽ URL സ്ലഗ് (slug) എന്നിവയുടെ സ്പെല്ലിംഗ് ഒരിക്കലും മാറുന്നില്ല. എന്നാൽ ഭാഷ അപ്രതീക്ഷിതമാണ്. ഉപയോക്താക്കൾ വാക്കുകൾ മാറ്റം വരുത്തുകയോ, തെറ്റായി എഴുതുകയോ, കൂടുതൽ മര്യാദയോടെ ചോദിക്കുകയോ അല്ലെങ്കിൽ ചില വാക്കുകൾ ഒഴിവാക്കുകയോ ചെയ്തേക്കാം. ഒരു സപ്പോർട്ട് ബോട്ടിന് "how do I reset my password?" എന്ന ചോദ്യത്തിന് പത്ത് മിനിറ്റിന് ശേഷം "forgotten password help" എന്ന ചോദ്യം ലഭിച്ചേക്കാം. എക്സാക്റ്റ് മാച്ച് (exact-match) ലെയർ ഇവ രണ്ടിനെയും രണ്ട് വ്യത്യസ്ത ബൈറ്റ് സീക്വൻസുകളായി കാണുകയും നിങ്ങൾക്ക് രണ്ട് തവണ ബില്ല് അയക്കുകയും ചെയ്യുന്നു. ദിവസേനയുള്ള ആയിരക്കണക്കിന് ഇടപെടലുകൾ കണക്കിലെടുക്കുമ്പോൾ ഈ നഷ്ടം വളരെ വലുതാണ്. പച്ചയായ ടെക്സ്റ്റിൽ നിന്ന് അർത്ഥത്തിന്റെ തലത്തിലേക്ക് (meaning space) മാച്ചിംഗ് ലോജിക് മാറ്റുന്നതിലൂടെ സെമാന്റിക് കാഷിംഗ് ഈ പ്രശ്നം പരിഹരിക്കുന്നു.

How It Actually Works

ഗണിത പാഠപുസ്തകങ്ങൾ പറയുന്നതിനേക്കാൾ ലളിതമാണ് ഈ പ്രക്രിയ.

Encoding the question. ഒരു ക്വറി വരുമ്പോൾ, ഒരു എംബെഡിംഗ് മോഡൽ (embedding model) അതിന്റെ അർത്ഥത്തെ ഒരു വെക്റ്ററിലേക്ക് (vector) ചുരുക്കുന്നു; ഇത് യഥാർത്ഥത്തിൽ ഫ്ലോട്ടിംഗ് പോയിന്റ് നമ്പറുകളുടെ ഒരു നീണ്ട പട്ടികയാണ്. ഇതിനെ ഭാഷയുടെ ജിപിഎസ് (GPS) കോർഡിനേറ്റുകൾ എന്ന് കരുതുക. ഒരേ ദിശയിലേക്ക് വിരൽ ചൂണ്ടുന്ന ചോദ്യങ്ങൾ—ഉദാഹരണത്തിന് "capital of France", "France’s capital city"—ഈ സ്പേസിൽ പരസ്പരം വളരെ അടുത്തായിരിക്കും. ബന്ധമില്ലാത്ത വിഷയങ്ങളെക്കുറിച്ചുള്ള ചോദ്യങ്ങൾ വളരെ അകലെയായിരിക്കും.

Vector search. നിങ്ങളുടെ കാഷിൽ മുമ്പ് കണ്ട ചോദ്യങ്ങളും അവയുടെ ഉത്തരങ്ങളും സൂക്ഷിക്കുന്നു, ഓരോ ജോഡിയും അതിന്റെ സ്വന്തം വെക്റ്റർ ഉപയോഗിച്ച് ഇൻഡക്സ് ചെയ്തിരിക്കുന്നു. കോസൈൻ ഡിസ്റ്റൻസ് (cosine distance) പോലുള്ള സമാനത അളക്കുന്ന രീതികൾ (similarity metrics) ഉപയോഗിച്ച് സിസ്റ്റം പുതിയ വെക്റ്ററിനെ ഈ ഡാറ്റാബേസുമായി താരതമ്യം ചെയ്യുന്നു. ആധുനിക വെക്റ്റർ സ്റ്റോറുകൾക്ക് മില്ലിസെക്കൻഡുകൾക്കുള്ളിൽ ദശലക്ഷക്കണക്കിന് എൻട്രികൾ തിരയാൻ കഴിയും.

Cache hit. ദൂരം നിശ്ചിത പരിധിക്കുള്ളിലാണെങ്കിൽ, സിസ്റ്റം സംഭരിച്ച ഉത്തരം ശരിയായി കണക്കാക്കുന്നു. ഇത് ആ ഉത്തരം നേരിട്ട് നൽകുന്നു. ഇതിനായി ഒരു API കീ ഉപയോഗിക്കേണ്ടതില്ല, ടോക്കൺ കൗണ്ടർ വർദ്ധിക്കില്ല, കൂടാതെ ഉപയോക്താവിന് സെക്കൻഡുകൾക്ക് പകരം മില്ലിസെക്കൻഡുകൾക്കുള്ളിൽ ഉത്തരം ലഭിക്കുന്നു.

Cache miss. മതിയായ സാമ്യമുള്ള ഒന്നും ലഭ്യമല്ലെങ്കിൽ, ക്വറി LLM-ലേക്ക് പോകുന്നു. മോഡൽ മറുപടി നൽകിക്കഴിഞ്ഞാൽ, സിസ്റ്റം പുതിയ വെക്റ്റർ-ഉത്തരം ജോഡി കാഷിൽ സൂക്ഷിക്കുന്നു, അങ്ങനെ അടുത്ത തവണ സമാനമായ ചോദ്യം ചോദിക്കുന്നവർക്ക് പ്രയോജനം ലഭിക്കുന്നു.

ഈ നാല് ഘട്ടങ്ങളുള്ള പ്രക്രിയ ആവർത്തിച്ചുവരുന്ന ഉദ്ദേശ്യങ്ങളെ സൗജന്യ പ്രകടനമാക്കി മാറ്റുന്നു.

What It Means for Your Application

ഇതിന്റെ ഗുണങ്ങൾ ചെലവ് കുറയ്ക്കുന്നതിൽ മാത്രം ഒതുങ്ങുന്നില്ല.

Lower token spend. കസ്റ്റമർ അസിസ്റ്റന്റുകളോ ഇന്റേണൽ നോളജ് ബോട്ടുകളോ (internal knowledge bots) നടത്തുന്ന ടീമുകൾക്ക് ടോക്കൺ ചെലവ് 70 ശതമാനത്തിലധികം കുറയ്ക്കാൻ സാധിക്കുന്നു. സപ്പോർട്ട്, FAQ തുടങ്ങിയ മേഖലകളിൽ ആവർത്തിച്ചുള്ള ചോദ്യങ്ങളാണ് കൂടുതലായി വരുന്നത്. ഓരോ തവണയും കാഷെ വഴി ലഭിക്കുന്ന മറുപടിയും നിങ്ങളുടെ അക്കൗണ്ടിലെ പണം ലാഭിക്കുന്നു.

Faster responses. ഒരു ലോക്കൽ വെക്റ്റർ ലുക്കപ്പും കാഷെ ഫെച്ചും അൻപത് മില്ലിസെക്കൻഡിൽ താഴെ സമയം കൊണ്ട് നടക്കും. എന്നാൽ ഒരു ഹോസ്റ്റഡ് LLM-ലേക്ക് നടത്തുന്ന API കോൾ മോഡലിന്റെ വലുപ്പവും തിരക്കും അനുസരിച്ച് അര സെക്കൻഡ് മുതൽ ഏതാനും സെക്കൻഡുകൾ വരെ എടുത്തേക്കാം. ഉപയോക്താക്കൾക്ക് ഈ വ്യത്യാസം പെട്ടെന്ന് മനസ്സിലാകും.

Fewer rate-limit headaches. സേവനദാതാക്കൾ മിനിറ്റിൽ അനുവദനീയമായ റിക്വസ്റ്റുകളുടെ എണ്ണം പരിമിതപ്പെടുത്തിയിട്ടുണ്ട്. നിങ്ങൾ ലോക്കലായി പരിഹരിക്കുന്ന ഓരോ ക്വറിയും 429 എറർ (error) ഉണ്ടാക്കുന്നില്ല, കൂടാതെ ചിലവേറിയ റീട്രൈ ലൂപ്പുകൾ ഒഴിവാക്കാനും സഹായിക്കുന്നു. ട്രാഫിക് വർദ്ധിക്കുമ്പോഴും നിങ്ങളുടെ സിസ്റ്റം സുസ്ഥിരമായിരിക്കും.

Real scalability. ആവർത്തിച്ചുള്ള ലോഡ് കാഷെ ഏറ്റെടുക്കുന്നതിനാൽ, നിങ്ങളുടെ LLM ക്വാട്ട വർദ്ധിപ്പിക്കുകയോ വലിയ മോഡൽ ഇൻസ്റ്റൻസുകൾ ഉപയോഗിക്കുകയോ ചെയ്യാതെ തന്നെ കൂടുതൽ ഉപയോക്താക്കളെ സേവിക്കാൻ നിങ്ങൾക്ക് സാധിക്കും. മോഡലിന്റെ ചിലവ് സ്ഥിരമായിരിക്കുമ്പോൾ കാഷെ എളുപ്പത്തിൽ വികസിപ്പിക്കാൻ (scale) സാധിക്കും.

Tools That Handle the Heavy Lifting

വെക്റ്റർ പൈപ്പ്‌ലൈൻ നിങ്ങൾ തന്നെ പൂജ്യത്തിൽ നിന്ന് നിർമ്മിക്കേണ്ടതില്ല. എംബെഡിംഗ്, സ്റ്റോറേജ്, റിട്രീവൽ ലോജിക് എന്നിവ ഉപയോഗപ്രദമായ ലെയറുകളായി നൽകുന്ന നിരവധി പ്രോജക്റ്റുകൾ നിലവിലുണ്ട്.

Bifrost എന്നത് നിങ്ങളുടെ ആപ്ലിക്കേഷനും മോഡൽ പ്രൊവൈഡർമാരും തമ്മിൽ പ്രവർത്തിക്കാൻ രൂപകൽപ്പന ചെയ്ത ഒരു ഓപ്പൺ സോഴ്സ് AI ഗേറ്റ്‌വേയാണ്. വളരെ കുറഞ്ഞ ചിലവിൽ സെമാന്റിക് കാഷിംഗ് ഇത് നൽകുന്നു. കാരണം, ഒരു കാഷെ പ്രവർത്തിപ്പിക്കാനുള്ള ചിലവ് അത് പകരം വെക്കുന്ന API കോളുകളേക്കാൾ കൂടാൻ പാടില്ല. കൂടാതെ, ഇരുപതിലധികം LLM പ്രൊവൈഡർമാരുടെ സേവനം ഇത് ലളിതമാക്കുന്നു, അതിനാൽ ഓരോ തവണയും കാഷിംഗ് ലോജിക് മാറ്റാതെ തന്നെ നിങ്ങൾക്ക് OpenAI, Anthropic അല്ലെങ്കിൽ ഓപ്പൺ മോഡലുകളിലേക്ക് ട്രാഫിക് റൂട്ട് ചെയ്യാം.

LiteLLM ഒരു യൂണിവേഴ്സൽ API ആയി പ്രവർത്തിക്കുന്നു. നിങ്ങൾ ഒരു ഇന്റർഫേസിലേക്ക് കോഡ് എഴുതുന്നു, അത് നിങ്ങൾ ആഗ്രഹിക്കുന്ന ഏത് ബാക്കെൻഡിലേക്കും റിക്വസ്റ്റുകളെ മാറ്റുന്നു. ഇതിന്റെ കാഷിംഗ് മോഡ്യൂൾ ഒന്നിലധികം ആപ്ലിക്കേഷൻ സെർവറുകളിലുടനീളം ഷെയർഡ് കാഷുകൾക്കായി Redis-ഉം, ഭാരം കുറഞ്ഞ സിംഗിൾ-നോഡ് വിന്യാസങ്ങൾക്കായി ലോക്കൽ മെമ്മറിയും പിന്തുണയ്ക്കുന്നു. സ്റ്റാക്ക് പുനർരൂപകൽപ്പന ചെയ്യാതെ തന്നെ പ്രോട്ടോടൈപ്പിൽ നിന്ന് പ്രൊഡക്ഷനിലേക്ക് മാറുന്ന ടീമുകളെ സംബന്ധിച്ചിടത്തോളം ഈ വഴക്കം ആകർഷകമാണ്.

LangChain നിങ്ങൾക്ക് ഒരു ഫ്രെയിംവർക്ക്-ലെവൽ സമീപനം നൽകുന്നു. നിങ്ങൾ ഇതിനകം LangChain ഉപയോഗിച്ച് ചെയിനുകളും ഏജന്റുകളും നിയന്ത്രിക്കുന്നുണ്ടെങ്കിൽ, Chroma അല്ലെങ്കിൽ FAISS പോലുള്ള വെക്റ്റർ സ്റ്റോറുകൾ ഉപയോഗിച്ച് കസ്റ്റം സെമാന്റിക് കാഷുകൾ ഇതിലേക്ക് ഘടിപ്പിക്കാം. പ്രാദേശിക പരീക്ഷണങ്ങൾക്കും ചെറിയ ഡാറ്റാസെറ്റുകൾക്കും Chroma നന്നായി പ്രവർത്തിക്കുന്നു. ഒരു പ്രത്യേക ഡാറ്റാബേസ് സർവീസ് പ്രവർത്തിപ്പിക്കാതെ തന്നെ വേഗതയേറിയ, ഇൻ-മെമ്മറി അപ്രോക്സിമേറ്റ് സെർച്ച് ആവശ്യമായി വരുമ്പോൾ FAISS മികച്ചതാണ്.

പൂർണ്ണ നിയന്ത്രണം ആവശ്യമുള്ള ടീമുകൾക്ക് Pinecone അല്ലെങ്കിൽ Milvus പോലുള്ള വെക്റ്റർ ഡാറ്റാബേസുകൾ ഉപയോഗിച്ചുള്ള Self-managed setups ആണ് അനുയോജ്യം. Pinecone എന്നത് സ്കെയിലിംഗും റെപ്ലിക്കേഷനും കൈകാര്യം ചെയ്യുന്ന ഒരു മാനേജ്ഡ് സർവീസാണ്, ഇത് പ്രവർത്തനപരമായ ഭാരം കുറയ്ക്കുന്നു. Milvus ഓപ്പൺ സോഴ്സ് ആണ് കൂടാതെ Kubernetes-friendly കൂടിയാണ്, നിങ്ങളുടെ സ്വന്തം ഇൻഫ്രാസ്ട്രക്ചറിൽ ഡാറ്റ സൂക്ഷിക്കാൻ ആഗ്രഹിക്കുന്നവർക്ക് ഇത് അനുയോജ്യമാണ്. ഇവിടെ നിർമ്മാണം കൂടുതൽ സങ്കീർണ്ണമാണ്—നിങ്ങൾ തന്നെ എംബെഡിംഗുകളും (embeddings), ത്രെഷോൾഡുകളും (thresholds), ഇവിക്ഷൻ പോളിസികളും (eviction policies) നിയന്ത്രിക്കേണ്ടതുണ്ട്—എങ്കിലും ഇതിന്റെ ഫലം പൂർണ്ണമായ വഴക്കമാണ്.

ഒഴിവാക്കേണ്ട കോൺഫിഗറേഷൻ കെണികൾ

ഒരു സെമാന്റിക് കാഷിന്റെ ഗുണനിലവാരം അതിന്റെ ട്യൂണിംഗിനെ ആശ്രയിച്ചിരിക്കുന്നു. പ്രൊഡക്ഷനിലേക്ക് മാറ്റുന്നതിന് മുമ്പ് ശ്രദ്ധിക്കേണ്ട മൂന്ന് കാര്യങ്ങളുണ്ട്.

Embedding quality. എല്ലാ എംബെഡിംഗ് മോഡലുകളും സൂക്ഷ്മമായ വ്യത്യാസങ്ങൾ ഒരുപോലെ തിരിച്ചറിയണമെന്നില്ല. ഒരു ലൈറ്റ്വെയ്റ്റ് മോഡൽ “refund policy”, “return policy” എന്നിവയെ ഏകദേശം ഒരേ വെക്റ്ററായി മാറ്റിയേക്കാം, അത് നല്ലതാണ്. എന്നാൽ അത് “battery life”, “battery warranty” എന്നിവയെയും തമ്മിൽ കൂട്ടിക്കലർത്താൻ സാധ്യതയുണ്ട്, ഇത് തെറ്റായ ഉത്തരങ്ങൾ നൽകാൻ കാരണമാകും. നിങ്ങളുടെ ലോഗുകളിൽ നിന്നുള്ള യഥാർത്ഥ ക്വറി ജോഡികൾ ഉപയോഗിച്ച് മോഡൽ പരിശോധിക്കുക. വിവരങ്ങൾ തമ്മിൽ കൂട്ടിമുട്ടുന്നുണ്ടെങ്കിൽ (collisions), എൻകോഡിംഗ് സമയം കുറച്ച് കൂടുന്നുണ്ടെങ്കിൽ പോലും കൂടുതൽ കരുത്തുറ്റ ഒരു എംബെഡിംഗ് മോഡലിലേക്ക് മാറുന്നതാണ് നല്ലത്.

Similarity threshold. ഇത് “ഏകദേശം ഒന്നുതന്നെ” എന്നതിനായുള്ള നിങ്ങളുടെ സഹിഷ്ണുതയാണ്. ഇത് വളരെ കൂടുതലായി ക്രമീകരിച്ചാൽ—അതായത് വെക്റ്ററുകൾ തമ്മിൽ കൃത്യമായ പൊരുത്തം ആവശ്യപ്പെട്ടാൽ—വ്യക്തമായ സെമാന്റിക് മാച്ചുകൾ പോലും വിട്ടുപോകാൻ സാധ്യതയുണ്ട്. ഇത് വളരെ കുറവാണെങ്കിൽ, “cancellation fees” എന്ന് ചോദിക്കുന്ന ഉപയോക്താവിന് “cancellation procedures” എന്നതിനെക്കുറിച്ചുള്ള കാഷഡ് ഉത്തരം ലഭിച്ചേക്കാം, ഇത് അപ്രയോജനകരവും അസ്വസ്ഥതയുണ്ടാക്കുന്നതുമാണ്. കോസൈൻ സിമിലാരിറ്റിക്ക് (cosine similarity) ഏകദേശം 0.85 എന്ന നിലയിൽ തുടങ്ങുക, തുടർന്ന് നിങ്ങളുടെ ഡൊമൈനിലെ കൃത്യത അനുസരിച്ച് മാറ്റങ്ങൾ വരുത്തുക.

Cache freshness. പഴയ ഉത്തരങ്ങൾ വിശ്വാസ്യത കുറയ്ക്കും. ഒരു ഉൽപ്പന്നം റീലോഞ്ച് ചെയ്തതിന് ശേഷവും പഴയ വിലവിവരങ്ങൾ തന്നെ പറയുന്ന ഒരു ടെക് സപ്പോർട്ട് കാഷ് ഉപയോക്താക്കളെ അലോസരപ്പെടുത്തും. നിശ്ചിത സമയത്തിന് ശേഷം എൻട്രികൾ നീക്കം ചെയ്യുന്നതിനായി time-to-live (TTL) പോളിസികൾ നടപ്പിലാക്കുക. വേഗത്തിൽ മാറിക്കൊണ്ടിരിക്കുന്ന വിഷയങ്ങൾക്ക് കുറഞ്ഞ TTL ഉപയോഗിക്കുക. ഗണിതശാസ്ത്ര വസ്തുതകൾ അല്ലെങ്കിൽ കമ്പനിയുടെ ചരിത്രം പോലുള്ള സ്ഥിരമായ കാര്യങ്ങൾക്ക് കൂടുതൽ സമയം അനുവദിക്കാം. ചില ടീമുകൾ എൻട്രികളെ വിഷയങ്ങൾക്കനുസരിച്ച് ടാഗ് ചെയ്യുന്നുണ്ട്, അങ്ങനെ സോഴ്സ് ഡോക്യുമെന്റേഷൻ മാറുമ്പോൾ ബന്ധപ്പെട്ട ഉത്തരങ്ങൾ ഒന്നിച്ച് ഇല്ലാതാക്കാൻ (bulk-invalidate) അവർക്ക് സാധിക്കുന്നു.

സംഗ്രഹം

സെമാന്റിക് കാഷിംഗ് എല്ലാ പ്രശ്നങ്ങൾക്കും ഒരു പരിഹാരമല്ല, എന്നാൽ ഒരു LLM ആപ്ലിക്കേഷനിൽ നിങ്ങൾക്ക് ചേർക്കാവുന്ന ഏറ്റവും മികച്ച ഫലം നൽകുന്ന ഒപ്റ്റിമൈസേഷനുകളിൽ ഒന്നാണിത്. പ്രൊഡക്ഷൻ AI വിന്യാസങ്ങളെക്കുറിച്ചുള്ള രണ്ട് പ്രധാന പരാതികളായ ചിലവ് (cost), ലേറ്റൻസി (latency) എന്നിവയെ ഇത് നേരിട്ട് പരിഹരിക്കുന്നു. Bifrost അല്ലെങ്കിൽ LiteLLM പോലുള്ള നിലവിലുള്ള ടൂളുകൾ ഉപയോഗിച്ച് തുടങ്ങുക, യഥാർത്ഥ ട്രാഫിക്കിൽ നിങ്ങളുടെ കാഷ് ഹിറ്റ് റേറ്റ് (cache hit rate) അളക്കുക, തുടർന്ന് എംബെഡിംഗ് മോഡലിലും ത്രെഷോൾഡിലും മാറ്റങ്ങൾ വരുത്തുക. ആദ്യ ദിവസം തന്നെ പൂർണ്ണത കൈവരിക്കുക എന്നതല്ല ലക്ഷ്യം; മറിച്ച് ഒരേ ചോദ്യം കാരണം രണ്ടുതവണ ടോക്കണുകൾ നഷ്ടപ്പെടുന്നത് തടയുക എന്നതാണ്.

Source: Semantic Caching for LLMs: How It Works and the Tools That Do It

Community: GyaanSetu AI on Telegram