മിക്ക RAG ട്യൂട്ടോറിയലുകളും അവസാനിക്കുന്നത് പ്രൊഡക്ഷൻ തുടങ്ങുന്നിടത്താണ്. നിങ്ങൾ നിങ്ങളുടെ ഡോക്യുമെന്റുകളെ 512-ടോക്കൺ ചങ്കുകളായി (chunks) വിഭജിക്കുന്നു, അവയെ ഒരു എംബെഡിംഗ് മോഡലിലൂടെ കടത്തിവിടുന്നു, കൂടാതെ ലളിതമായ top-k റിട്രീവലിലൂടെ ഒരു വെക്റ്റർ ഡാറ്റാബേസ് വിളിക്കുന്നു. ഒരു ഡെമോയിൽ ഇത് ബോധ്യപ്പെടുത്തുന്നതായി തോന്നും. നിങ്ങളുടെ കമ്പനിയുടെ ലീവ് പോളിസിയെക്കുറിച്ച് ബോട്ടിനോട് ചോദിച്ചാൽ അത് വ്യക്തമായ ഒരു ഖണ്ഡിക നൽകുന്നു. എല്ലാവരും അത് ശരിയാണെന്ന് സമ്മതിക്കുന്നു. നിർഭാഗ്യവശാൽ, ഡെമോകൾ കള്ളം പറയുന്നു.

പ്രൊഡക്ഷൻ ഓരോ ഷോർട്ട്കട്ടുകളെയും തുറന്നുകാട്ടുന്നു. നിശ്ചിത വലുപ്പത്തിലുള്ള ചങ്കുകൾ (Fixed chunks) നിയമപരമായ കരാറുകളെ (legal contracts) ഇൻഡെംനിഫിക്കേഷൻ ക്ലോസുകളുടെ (indemnification clauses) ഇടയിൽ വെച്ച് മുറിച്ചുമാറ്റുന്നു. API ഡോക്യുമെന്റേഷൻ അനാവശ്യമായ ശബ്ദങ്ങളായി (noise) മാറുകയും നിങ്ങൾക്ക് ആവശ്യമുള്ള വിവരങ്ങൾ മറഞ്ഞുപോവുകയും ചെയ്യുന്നു. മറുപടി ലഭിക്കുന്നതിന് മുമ്പ് തന്നെ ഉപയോക്താക്കൾ തിരച്ചിൽ ഉപേക്ഷിക്കുന്ന തരത്തിൽ ലേറ്റൻസി (latency) വർദ്ധിക്കുന്നു. ഞങ്ങൾ ഈ പ്രതിസന്ധി നേരിടുകയും എല്ലാം വീണ്ടും നിർമ്മിക്കേണ്ടി വരികയും ചെയ്തു. ഞങ്ങളുടെ റിട്രീവൽ ലെയർ “സെമാന്റിക് സെർച്ച് ആൻഡ് ഹോപ്പ്” എന്നതിൽ നിന്ന് കൃത്യമായ അളവുകോലുകളുള്ള ഒരു പൈപ്പ്‌ലൈനായി പരിണമിച്ചു. ഇതിന്റെ ഫലമായി 95% റീകോൾ (recall) ലഭിക്കുകയും ലേറ്റൻസിയിൽ 40% കുറവ് വരികയും ചെയ്തു. യഥാർത്ഥത്തിൽ എന്താണ് ഫലപ്രദമായി പ്രവർത്തിച്ചത് എന്ന് താഴെ നൽകുന്നു.

ചങ്കിംഗ് സ്ട്രാറ്റജി ഡോക്യുമെന്റുകൾക്ക് അനുയോജ്യമാക്കുക

512-ടോക്കൺ എന്നത് എളുപ്പമായതുകൊണ്ടാണ് ഡിഫോൾട്ടായി നിലനിൽക്കുന്നത്, അല്ലാതെ അത് ശരിയായതുകൊണ്ടല്ല. വ്യത്യസ്ത ഡോക്യുമെന്റുകൾ വ്യത്യസ്ത രീതിയിലാണ് അർത്ഥം കൈമാറുന്നത്, അതിനാൽ നിങ്ങളുടെ ചങ്കിംഗ് സ്ട്രാറ്റജി അത് പ്രതിഫലിപ്പിക്കണം.

നിയമപരമായ കരാറുകൾക്കായി (legal contracts), ഘടനാപരമായ അതിർവരമ്പുകൾ മാനിക്കുന്ന റിക്കേഴ്സീവ് ചങ്കിംഗ് (recursive chunking) ഉപയോഗിക്കുക. നിയമഭാഷ സങ്കീർണ്ണമാണ്. ഒരു ക്ലോസ് അതിന്റെ മുകളിലുള്ള സെക്ഷനെ ആശ്രയിച്ചിരിക്കുന്നു, വാചകത്തിന്റെ ഇടയിൽ വെച്ച് ഒരു നിശ്ചിത അളവിൽ മുറിക്കുന്നത് ഒരു ബാധ്യതയുടെ (obligation) യുക്തി നശിപ്പിക്കുന്നു. റിക്കേഴ്സീവ് ചങ്കിംഗ് ഒരു ടോക്കൺ പരിധി നിശ്ചയിക്കുന്നതിന് മുമ്പ് സ്വാഭാവികമായ വേർതിരിവുകൾ—ആദ്യം ഖണ്ഡികകൾ, പിന്നെ വാചകങ്ങൾ—ഉപയോഗിച്ച് വിഭജിക്കാൻ ശ്രമിക്കുന്നു. ഇത് ഇൻഡെംനിഫിക്കേഷൻ അല്ലെങ്കിൽ ബാധ്യതയുമായി ബന്ധപ്പെട്ട ക്ലോസുകളെ (liability clauses) തകരാതെ സൂക്ഷിക്കുന്നു.

API ഡോക്യുമെന്റേഷനായി, ഫംഗ്ഷൻ-അവയവമായ (function-aware) ചങ്കിംഗ് ഉപയോഗിക്കുക. ഡെവലപ്പർമാർ വെറുതെ ഏതെങ്കിലും ഖണ്ഡികകൾ തിരയുകയല്ല; അവർ എൻഡ്‌പോയിന്റുകൾ (endpoints), പാരാമീറ്ററുകൾ (parameters), എറർ സിഗ്നേച്ചറുകൾ (error signatures) എന്നിവയാണ് തിരയുന്നത്. ഒരു ചങ്കിൽ ഫംഗ്ഷൻ സിഗ്നേച്ചർ, അതിന്റെ വിവരണം, റിട്ടേൺ സ്കീമ എന്നിവ ഒരു ലോജിക്കൽ യൂണിറ്റായി ഉണ്ടായിരിക്കണം. നിങ്ങൾ ആ ബ്ലോക്ക് പകുതിയായി മുറിച്ചാൽ, റിട്രീവൽ സിസ്റ്റം പകുതി വിവരങ്ങൾ മാത്രമേ നൽകൂ, ബാക്കി വിവരങ്ങൾ ജനറേഷൻ മോഡൽ സ്വയം സങ്കൽപ്പിക്കുകയും (hallucinates) ചെയ്യും.

സപ്പോർട്ട് ടിക്കറ്റുകൾക്കായി, സംഭാഷണങ്ങൾ പിന്തുടരുന്ന സെമാന്റിക് ചങ്കിംഗിനെ (semantic chunking) ആശ്രയിക്കുക. സപ്പോർട്ട് ത്രെഡുകൾ (support threads) ക്രമബദ്ധവും ആവർത്തന സ്വഭാവമുള്ളതുമാണ്. ഒരു ഉപഭോക്താവ് പ്രശ്നം ആവർത്തിക്കുന്നു, ഒരു ഏജന്റ് ലോഗുകൾ ചോദിക്കുന്നു, ഉപഭോക്താവ് അവ അറ്റാച്ച് ചെയ്യുന്നു. ഓരോ സംഭാഷണവും അതിന്റെതായ ഒരു സെമാന്റിക് യൂണിറ്റാണ്. സംഭാഷണങ്ങൾക്കനുസരിച്ച് ചങ്കിംഗ് ചെയ്യുന്നത് ആരാണ് എപ്പോൾ എന്താണ് പറഞ്ഞത് എന്നത് നിലനിർത്തുന്നു, ഇത് ഉപയോക്താവ് “ചൊവ്വാഴ്ച ഏജന്റ് എന്താണ് നിർദ്ദേശിച്ചത്?” എന്ന് ചോദിക്കുമ്പോൾ പ്രധാനമാണ്.

ഇന്റേണൽ വിക്കികൾക്കായി (internal wikis), ഏജന്റിക് ചങ്കിംഗ് (agentic chunking) പരീക്ഷിക്കുക. ഒരു LLM-ന് ഒരു സെക്ഷൻ നൽകി, ഒരു വിഷയം എവിടെ അവസാനിക്കുന്നുവെന്നും മറ്റൊന്ന് എവിടെ തുടങ്ങുന്നുവെന്നും തീരുമാനിക്കാൻ ആവശ്യപ്പെടുക. ഇത് ഡാറ്റ ശേഖരിക്കുമ്പോൾ (ingest time) കൂടുതൽ ചിലവ് വരുത്തിയേക്കാം, എന്നാൽ വിക്കികൾ പലപ്പോഴും ക്രമരഹിതമാണ്. പേജുകളിൽ വിവിധ ടീമുകളിൽ നിന്നുള്ള അപ്രസക്തമായ അപ്‌ഡേറ്റുകൾ ഉണ്ടാകാം, അതിനാൽ മനുഷ്യൻ നിർവചിക്കുന്ന അതിർവരമ്പുകൾ പലപ്പോഴും സഹായിക്കില്ല. വിഷയം മാറുന്നതിനെ അടിസ്ഥാനമാക്കി ഒരു മോഡലിനെ അതിർവരമ്പുകൾ നിശ്ചയിക്കാൻ അനുവദിക്കുന്നത് അനാവശ്യ വിവരങ്ങൾ (noise) ഗണ്യമായി കുറയ്ക്കുന്നു.

ഒരു പൈപ്പ്‌ലൈനിൽ ഒന്നിലധികം സ്ട്രാറ്റജികൾ പ്രവർത്തിപ്പിക്കാൻ ഡാറ്റ ശേഖരിക്കുമ്പോൾ തന്നെ ഡോക്യുമെന്റുകളെ തരംതിരിക്കേണ്ടതുണ്ട്. ആ ചെറിയ രീതിയിലുള്ള ക്രമീകരണം ഉടൻ തന്നെ ഗുണകരമാകും.

സെർച്ച് രീതികൾ സംയോജിപ്പിക്കുക, ഒരെണ്ണം മാത്രം തിരഞ്ഞെടുക്കരുത്

വെക്റ്റർ സെർച്ച് (Vector search) ഉദ്ദേശ്യം മനസ്സിലാക്കുന്നു, എന്നാൽ കൃത്യമായ പദങ്ങൾ (exact matches) കണ്ടെത്തുന്നതിൽ അത് പലപ്പോഴും പരാജയപ്പെടുന്നു. ഒരു എറർ കോഡ് ERR_CONNECTION_REFUSED അല്ലെങ്കിൽ ഒരു പ്രത്യേക SKU ചോദിച്ചാൽ, ഡെൻസ് എംബെഡിംഗുകൾ (dense embeddings) ആശയപരമായി സമാനമായ എന്നാൽ വസ്തുതാപരമായി തെറ്റായ ഫലങ്ങൾ നൽകിയേക്കാം. BM25, ക്ലാസിക് കീവേഡ് സ്പാർസ് റിട്രീവൽ രീതിയാണ്, ഇത് കൃത്യമായ സ്ട്രിംഗുകളെ (strings) മനോഹരമായി കൈകാര്യം ചെയ്യുന്നുവെങ്കിലും സെമാന്റിക് സൂക്ഷ്മതകൾ (semantic nuance) വിട്ടുപോകുന്നു. നിങ്ങൾക്ക് ഇവ രണ്ടും ആവശ്യമാണ്.

ഹൈബ്രിഡ് റിട്രീവൽ (hybrid retrieval) ഉപയോഗിക്കുക. വെക്റ്റർ സെർച്ചും BM25-ഉം സമാന്തരമായി പ്രവർത്തിപ്പിക്കുക. തുടർന്ന് അവയെ Reciprocal Rank Fusion (RRF) ഉപയോഗിച്ച് സംയോജിപ്പിക്കുക. രണ്ട് രീതികളും പ്രസക്തമാണെന്ന് സമ്മതിക്കുന്ന ഡോക്യുമെന്റുകൾക്ക് RRF മുൻഗണന നൽകുന്നു, അതേസമയം ഏതെങ്കിലും ഒരു രീതിയിൽ നിന്നുള്ള മികച്ച സാധ്യതകളെയും അത് പുറത്തുകൊണ്ടുവരുന്നു. ഇതിന്റെ കണക്കുകൂട്ടൽ ലളിതമാണ്, ഫലവും സ്ഥിരതയുള്ളതുമാണ്: ഒരു റിട്രീവൽ രീതിയും ഫൈനൽ റാങ്കിംഗിൽ ആധിപത്യം സ്ഥാപിക്കുന്നില്ല.

ഫ്യൂഷന് ശേഷം, ഒരു ക്രോസ്-എൻകോഡർ റീറങ്കർ (cross-encoder reranker) ചേർക്കുക. ആദ്യ ഘട്ടം — വെക്റ്റർ പ്ലസ് സ്പാർസ് റിട്രീവൽ — വേഗതയുള്ളതും വിപുലവുമാണ്. ക്രോസ്-എൻകോഡർ ഓരോ ക്വറി-ഡോക്യുമെന്റ് ജോഡിയെയും പൂർണ്ണമായ ശ്രദ്ധയോടെ സ്കോർ ചെയ്യുന്നു, അതായത് അത് യഥാർത്ഥ ചോദ്യത്തിനെതിരെ ഉദ്യോഗാർത്ഥിയെ (candidate) വായിക്കുന്നു. അതെ, ഇത് ലേറ്റൻസി വർദ്ധിപ്പിക്കുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ, ഏകദേശം അൻപത് മുതൽ നൂറ് മില്ലിസെക്കൻഡ് വരെ. എന്നാൽ ഇതിലൂടെ ലഭിക്കുന്ന കൃത്യത (precision) വളരെ വലുതാണ്, അതിനാൽ ഈ മാറ്റം ലാഭകരമാണ്. നിങ്ങൾക്ക് റീകോൾ (recall) പ്രധാനമാണെങ്കിൽ ഇത് ഒഴിവാക്കാൻ കഴിയില്ല.

ഇൻഡക്സ് ശരിയാക്കുന്നതിന് മുമ്പ് ക്വറി ശരിയാക്കുക

ഉപയോക്താക്കൾ നിങ്ങളുടെ സെർച്ച് എഞ്ചിന് വേണ്ടിയല്ല ക്വറികൾ എഴുതുന്നത്. അവർ അത് മനുഷ്യർക്ക് വേണ്ടിയാണ് എഴുതുന്നത്. “ഇത് പ്രവർത്തിക്കുന്നില്ല” എന്നത് സാധാരണമായ ഒരു സപ്പോർട്ട് ക്വറിയാണ്. ഒരു ഫീച്ചറിനെക്കുറിച്ചുള്ള അവ്യക്തമായ വിവരണം സാധാരണമായ ഒരു ഇന്റേണൽ വിക്കി സെർച്ചാണ്. നിങ്ങൾ ആ നേരിട്ടുള്ള ഇൻപുട്ട് (raw input) ഉപയോഗിച്ച് ഇൻഡക്സ് തിരഞ്ഞാൽ, നിങ്ങൾക്ക് ലഭിക്കുന്നത് തെറ്റായ വിവരങ്ങളായിരിക്കും.

റിട്രീവറിൽ എത്തുന്നതിന് മുമ്പ് ക്വറി പരിവർത്തനം ചെയ്യുക.

ഉപയോക്താവിന്റെ ചോദ്യത്തിന്റെ ഒന്നിലധികം പതിപ്പുകൾ നിർമ്മിക്കാൻ query expansion ഉപയോഗിക്കുക. ഒരാൾ “server down” എന്ന് ടൈപ്പ് ചെയ്താൽ, നിങ്ങളുടെ സിസ്റ്റം “service unavailable,” “502 error,” “connection timeout” എന്നിവയും തിരയണം. ഈ ഉദ്ദേശ്യ വ്യതിയാനങ്ങൾ (intent variants) ഉൾപ്പെടുത്തിയത് ഞങ്ങളുടെ റീക്കോൾ (recall) 78%-ൽ നിന്ന് 96%-ലേക്ക് ഉയർത്തി. ഇത് ഒരു ഒറ്റ ഘട്ടമാണ്, കൂടാതെ ലഭിക്കുന്ന നേട്ടവുമായി താരതമ്യം ചെയ്യുമ്പോൾ ഇതിന് ചിലവ് ഏതാണ്ട് ഒന്നുമില്ല.

സങ്കീർണ്ണമായ ചോദ്യങ്ങൾക്ക് query decomposition ഉപയോഗിക്കുക. ഒരു ഉപയോക്താവ് “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?” എന്ന് ചോദിക്കുമ്പോൾ, അതിനെ ഉപചോദ്യങ്ങളായി തിരിക്കുക. ഒരു ഉപചോദ്യം മൈഗ്രേഷൻ ഘട്ടങ്ങളെ ലക്ഷ്യം വെക്കുന്നു. മറ്റൊന്ന് എന്റർപ്രൈസ് അക്കൗണ്ടുകളെ ബാധിക്കുന്ന പ്രധാന മാറ്റങ്ങളെ (breaking changes) ലക്ഷ്യം വെക്കുന്നു. ഇവ ഓരോന്നും ഇൻഡക്സിന്റെ (index) വ്യത്യസ്ത ഭാഗങ്ങളിൽ എത്തിച്ചേരുന്നു. ഡൗൺസ്ട്രീം ലാംഗ്വേജ് മോഡൽ, ഒരു ബഹളമയമായ കോൺടെക്സ്റ്റ് വിൻഡോയിലൂടെ ഊഹിക്കുന്നതിന് പകരം, കൃത്യമായി കണ്ടെത്തിയ വിവരങ്ങളിൽ (chunks) നിന്ന് അന്തിമ ഉത്തരം സംയോജിപ്പിക്കുന്നു.

ഹൈപ്പർപാരാമീറ്ററുകൾ ഊഹിച്ചു കണ്ടെത്തുന്നത് നിർത്തുക

ഒന്നിലധികം ചങ്കിംഗ് സ്ട്രാറ്റജികളും (chunking strategies), ഹൈബ്രിഡ് റിട്രീവലും (hybrid retrieval), ക്വറി ട്രാൻസ്ഫോർമേഷനും ഉണ്ടായുകഴിഞ്ഞാൽ, നിങ്ങൾ ഒരു കോമ്പിനേറ്റോറിയൽ പ്രോബ്ലം (combinatorial problem) നേരിടും. ചങ്ക് സൈസ് (chunk size), ഓവർലാപ്പ് (overlap), ഫ്യൂഷൻ വെയ്റ്റുകൾ (fusion weights), റീറാംകർ ഡെപ്ത് (reranker depth), എക്സ്പാൻഷൻ കൗണ്ട് (expansion count) എന്നിവയെല്ലാം പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു. ഒന്നിനെ മാത്രം മാറ്റുന്നത് മറ്റൊന്നിനെ ബാധിക്കും. ഈ മേഖലയിൽ ഗ്രിഡ് സെർച്ച് (grid search) നടത്തുന്നത് സമയം പാഴാക്കുന്നതും സാവധാനത്തിലുള്ളതുമാണ്.

പകരം ബേസിയൻ ഒപ്റ്റിമൈസേഷൻ (Bayesian optimization) ഉപയോഗിക്കുക. ഇതിനെ ഒരു മെഷീൻ ലേണിംഗ് ട്യൂണിംഗ് ജോബ് പോലെ കാണുക. നിങ്ങളുടെ ലക്ഷ്യം വ്യക്തമായി നിർവചിക്കുക: ലേറ്റൻസി (latency) ഒരു പരിധിയിൽ താഴെയായി നിലനിർത്തിക്കൊണ്ട് റീക്കോൾ (recall) പരമാവധിയാക്കുക. ഒരു ഗോൾഡൻ ഡാറ്റാസെറ്റ് (golden dataset) നിർമ്മിക്കുക — ഏത് ചങ്ക്സ് (chunks) ആണ് റിട്രീവ് ചെയ്യേണ്ടതെന്ന് നിങ്ങൾക്ക് കൃത്യമായി അറിയാവുന്ന നൂറുകണക്കിന് പ്രതിനിധികളായ ചോദ്യങ്ങൾ ഇതിൽ ഉൾപ്പെടുത്തുക. തുടർന്ന് ബേസിയൻ സെർച്ച് കോൺഫിഗറേഷൻ സ്പേസ് കാര്യക്ഷമമായി പര്യവേക്ഷണം ചെയ്യാൻ അനുവദിക്കുക. ഇത് എന്താണ് പ്രവർത്തിക്കുന്നത് എന്നതിനെക്കുറിച്ച് ഒരു പ്രോബബിലിസ്റ്റിക് മോഡൽ നിർമ്മിക്കുകയും ഏറ്റവും പ്രതീക്ഷയുള്ള മേഖലകൾ അടുത്തതായി പരിശോധിക്കുകയും ചെയ്യുന്നു.

ഓരോ കാൻഡിഡേറ്റ് കോൺഫിഗറേഷനും സ്റ്റേജിംഗിൽ (staging) എത്തുന്നതിന് മുമ്പ് ഗോൾഡൻ ഡാറ്റാസെറ്റിലൂടെ കടന്നുപോകണം. പുതിയ ചങ്ക് സൈസ് റീക്കോൾ കുറയ്ക്കുകയോ അല്ലെങ്കിൽ കൂടുതൽ ഭാരമുള്ള റീറാംകർ ലേറ്റൻസി ബജറ്റിന് അപ്പുറത്തേക്ക് നിങ്ങളെ എത്തിക്കുകയോ ചെയ്താൽ, ഒപ്റ്റിമൈസേഷൻ അത് സ്വയമേവ കണ്ടെത്തും. ഇത് തീരുമാനങ്ങളിൽ വ്യക്തിപരമായ അഭിപ്രായങ്ങൾ ഒഴിവാക്കുന്നു. 256 അല്ലെങ്കിൽ 512 ടോക്കണുകൾ ഏതാണ് “better” എന്ന് തർക്കിക്കുന്നത് അവസാനിപ്പിച്ച് ഫലങ്ങൾ വായിക്കാൻ നിങ്ങൾ തുടങ്ങുന്നു.

ഫലം

പൈപ്പ്‌ലൈനിലെ മാറ്റങ്ങൾ ഞങ്ങൾ പ്രതീക്ഷിച്ചതുപോലെ കൃത്യമായി ഫലം നൽകി.

  • Recall@10 78%-ൽ നിന്ന് 95%-ലേക്ക് ഉയർന്നു.
  • P95 latency 850 ms-ൽ നിന്ന് 320 ms-ലേക്ക് കുറഞ്ഞു.
  • Hallucination rate 12%-ൽ നിന്ന് 3%-ലേക്ക് കുറഞ്ഞു.
  • Cost per query 38% കുറഞ്ഞു, പ്രധാനമായും മികച്ച റിട്രീവൽ കാരണം ഞങ്ങൾക്ക് ചെറിയ ജനറേഷൻ മോഡലും കുറഞ്ഞ പ്രോംപ്റ്റ് ടോക്കണുകളും ഉപയോഗിക്കാൻ കഴിഞ്ഞു.

ലേറ്റൻസി കുറഞ്ഞത് ടീമിലെ ചിലരെ അത്ഭുതപ്പെടുത്തി. റീറാംക്കറുകളും (rerankers) ക്വറി എക്സ്പാൻഷനും ചേർക്കുന്നത് കാര്യങ്ങൾ സാവധാനത്തിലാക്കുമെന്ന് തോന്നാം. എന്നാൽ റിട്രീവൽ നിലവാരം മെച്ചപ്പെട്ടതിനാൽ, ജനറേഷൻ മോഡലിന് കുറഞ്ഞ പ്രോംപ്റ്റിംഗും കുറഞ്ഞ ഊഹപ്രവചനങ്ങളും കുറഞ്ഞ റീട്രൈകളും (retries) മതിയാകും. നല്ല റിട്രീവൽ ഡൗൺസ്ട്രീമിലുള്ള എല്ലാ കാര്യങ്ങളും ലാഭകരമാക്കുന്നു.

റിട്രീവലിനെ ഒരു ഇൻഫ്രാസ്ട്രക്ചർ പോലെ കാണുക

റിട്രീവൽ എന്നത് ഒരിക്കൽ റൺ ചെയ്ത് മറന്നുപോകുന്ന ഒരു നോട്ട്ബുക്ക് അല്ല. ഇതൊരു ഇൻഫ്രാസ്ട്രക്ചർ ആണ്, അത് കോഡ് പോലെ കൈകാര്യം ചെയ്യണം. നിങ്ങളുടെ ചങ്കിംഗ് സ്ട്രാറ്റജികൾ വേർഷൻ ചെയ്യുക (version). ലീഗൽ ടീം ഒരു പുതിയ കരാർ ടെംപ്ലേറ്റ് പുറത്തിറക്കുമ്പോൾ, പ്രൊഡക്ഷനിൽ എത്തുന്നതിന് മുമ്പ് നിങ്ങളുടെ റിക്കേഴ്സീവ് സ്പ്ലിറ്റർ (recursive splitter) പരിശോധിക്കുക. നിങ്ങളുടെ ഗോൾഡൻ ഡാറ്റാസെറ്റ് കഴിഞ്ഞ പാദത്തിലെ ഒരു സ്റ്റാറ്റിക് CSV ആയിട്ടല്ല, മറിച്ച് സജീവമായ രേഖകളായി നിലനിർത്തുക. നിങ്ങളുടെ ഇവാലുവേഷനുകൾ CI-യിൽ ഓട്ടോമേറ്റ് ചെയ്യുക, അങ്ങനെ ഒരു എംബെഡിംഗ് മോഡലിനെയോ ഫ്യൂഷൻ വെയ്റ്റിനെയോ മാറ്റുന്ന ഒരു പുൾ റിക്വസ്റ്റ് (pull request), ഒരു മനുഷ്യൻ പരിശോധിക്കുന്നതിന് മുമ്പ് തന്നെ റീക്കോൾ, ലേറ്റൻസി സംഖ്യകളടങ്ങിയ ഒരു കമന്റ് ലഭിക്കുന്നു.

നിങ്ങൾ ഏത് എംബെഡിംഗ് മോഡലാണ് ഉപയോഗിക്കുന്നത് എന്ന് ഉപയോക്താക്കൾ ഒരിക്കലും ചോദിക്കില്ല. നിങ്ങളുടെ ചങ്കിംഗ് ഹ്യൂറിസ്റ്റിക്കോ (chunking heuristic) റീറാംകർ ആർക്കിടെക്ചറോ (reranker architecture) അവരെ ബാധിക്കില്ല. ഉത്തരം ശരിയാണോ, അത് വേഗത്തിൽ ലഭിക്കുന്നുണ്ടോ, അവന് അതിൽ വിശ്വാസമർപ്പിക്കാൻ കഴിയുമോ എന്നതിനെക്കുറിച്ചാണ് അവർ ശ്രദ്ധിക്കുന്നത്. ആ വിശ്വാസം നേടിയെടുക്കുന്ന ഒരു പൈപ്പ്‌ലൈൻ നിർമ്മിക്കുക, അത് സത്യസന്ധമായി അളക്കുക, റിട്രീവലിനെ വെറുമൊരു അനുബന്ധമായി കാണുന്നത് നിർത്തുക.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community