മിക്ക RAG ഡെമോകളും ഒരു ലാപ്ടോപ്പിൽ കാണുമ്പോൾ അതിശയകരമായി തോന്നും. ഒരു ഇരുപത് പേജുള്ള PDF നൽകി ഒരു ചോദ്യം ചോദിച്ചാൽ, അത് ശരിയായ പാരഗ്രാഫ് തന്നെ ഉദ്ധരിക്കുന്നത് കാണാം. എന്നാൽ അതേ പൈപ്പ്‌ലൈൻ പ്രൊഡക്ഷനിലേക്ക് (production) മാറ്റാൻ ശ്രമിക്കുമ്പോഴാണ് ആ മാന്ത്രികത അവസാനിക്കുന്നത്. നിയമപരമായ രേഖകൾ (Legal documents) വാചകങ്ങളുടെ ഇടയിൽ വെച്ച് മുറിഞ്ഞുപോകുന്നു. കനത്ത API റെഫറൻസുകൾ പ്രധാനപ്പെട്ട വിവരങ്ങളെ അനാവശ്യമായ വിവരങ്ങൾക്കിടയിൽ (boilerplate noise) മുക്കിക്കളയുന്നു. ലേറ്റൻസി (Latency) വർദ്ധിക്കുന്നു. ഉപയോക്താക്കൾ കാത്തിരിക്കുകയും മടുക്കുകയും ഒടുവിൽ ഉപേക്ഷിച്ചുപോവുകയും ചെയ്യുന്നു. ഞങ്ങൾ ഈ പ്രതിസന്ധി കഠിനമായി അനുഭവിച്ചിട്ടുണ്ട്. അതിനാൽ ഞങ്ങൾ റിട്രീവൽ ലെയറിനെ (retrieval layer) പൂർണ്ണമായും മാറ്റിമറിച്ച്, കൃത്യമായി അളക്കാവുന്നതും ക്രമീകരിക്കാവുന്നതുമായ ഒരു സംവിധാനമായി പുനർനിർമ്മിച്ചു. അതിന്റെ ഫലമായി, ഉപയോക്താവിന്റെ അനുഭവം (user experience) തകരാതെ തന്നെ 95% റീക്കോൾ (recall) കൈവരിക്കാൻ കഴിയുന്ന ഒരു പൈപ്പ്‌ലൈൻ ഞങ്ങൾക്ക് ലഭിച്ചു.

എന്തുകൊണ്ടാണ് ഡെമോ RAG പ്രൊഡക്ഷനിൽ പരാജയപ്പെടുന്നത്

ഹോബി പ്രോജക്റ്റുകളിലും ആദ്യഘട്ട ഉൽപ്പന്നങ്ങളിലും ഉപയോഗിക്കുന്ന സ്റ്റാക്ക് (stack) അത്ഭുതകരമാംവിധം ഒരേപോലെയുള്ളതാണ്: നിശ്ചിത ടോക്കൺ ചങ്കുകൾ (fixed token chunks), റെഡിമെയ്ഡ് എംബെഡിംഗുകൾ (off-the-shelf embeddings), കൂടാതെ ഒരു സിംഗിൾ വെക്റ്റർ സെർച്ച് കോൾ എന്നിവയാണവ. നിങ്ങളുടെ ഡാറ്റാ ശേഖരം (corpus) വൃത്തിയുള്ളതും ചെറുതും പ്രവചിക്കാവുന്നതുമാണെങ്കിൽ ഈ ലാളിത്യം മികച്ചതാണ്. എന്നാൽ പ്രൊഡക്ഷൻ ഡാറ്റ അങ്ങനെയല്ല. 512 ടോക്കണുകൾ മാത്രമുള്ള ഒരു നിശ്ചിത ചങ്ക്, ഒരു SaaS കരാറിലെ ഇൻഡെംനിഫിക്കേഷൻ ക്ലോസ് (indemnification clause) പകുതിക്ക് വെച്ച് മുറിച്ചുമാറ്റിയേക്കാം. പെട്ടെന്ന് നിങ്ങളുടെ റിട്രീവൽ ലെയർ ഒരു നിയമപരമായ ബാധ്യതയുടെ പകുതി ഭാഗം മാത്രം ലാംഗ്വേജ് മോഡലിന് നൽകുകയും, ഒരു ബാധ്യതയെക്കുറിച്ചുള്ള ചോദ്യത്തിന് ഉത്തരം നൽകാൻ ആവശ്യപ്പെടുകയും ചെയ്യുന്നു. കോൺടെക്സ്റ്റ് (context) തകരാറിലായതിനാൽ മോഡൽ ഹാലൂസിനേഷൻ (hallucination) നടത്തുന്നു.

വലിയ സാങ്കേതിക രേഖകൾ ഈ പ്രശ്നം വർദ്ധിപ്പിക്കുന്നു. API ഡോക്യുമെന്റേഷനുകളിൽ ഫംഗ്ഷൻ സിഗ്നേച്ചറുകൾ (function signatures), ടേബിളുകൾ, കോഡ് ബ്ലോക്കുകൾ എന്നിവ നിറഞ്ഞിരിക്കുന്നു. ഒരു നിശ്ചിത വിൻഡോ ഉപയോഗിക്കുമ്പോൾ, ഒരു TypeScript ഇന്റർഫേസിന്റെ മധ്യഭാഗം ലഭിച്ചേക്കാം, എന്നാൽ അതിന് മുകളിലുള്ള ഫംഗ്ഷൻ പേരോ താഴെയുള്ള ഉപയോഗ ഉദാഹരണമോ നഷ്ടപ്പെട്ടേക്കാം. ഉപയോക്താവ് ചോദിക്കുന്ന യഥാർത്ഥ കപ്പാബിലിറ്റിക്ക് പകരം സിന്റാക്സ് ഫ്രാഗ്മെന്റുകളും അനാവശ്യ വിവരങ്ങളുമാണ് എംബെഡിംഗ് വെക്റ്റർ പ്രതിനിധീകരിക്കുന്നത്. തെറ്റായ വിവരങ്ങൾ നൽകിയാൽ തെറ്റായ ഉത്തരങ്ങൾ ലഭിക്കുന്നു (Garbage in, hallucination out).

ടോക്കൺ എണ്ണത്തിനനുസരിച്ചല്ല, ഘടനയനുസരിച്ച് ചങ്കിംഗ് (Chunking) ചെയ്യുക

ഞങ്ങൾ വരുത്തിയ ആദ്യത്തെ മാറ്റം ചങ്കുകളെ വെറും ടോക്കണുകളുടെ കൂട്ടമായി കാണുന്നത് നിർത്തി എന്നതാണ്. ചങ്കുകൾ എന്നത് സെമാന്റിക് യൂണിറ്റുകളാണ് (semantic units). ശരിയായ രീതി എന്നത് നിങ്ങൾ ഇൻഡക്സ് ചെയ്യുന്ന ഡാറ്റയെ ആശ്രയിച്ചിരിക്കും.

നിയമപരമായ രേഖകൾക്കായി, ഡോക്യുമെന്റ് ഹൈരാർക്കി (hierarchy) മാനിക്കുന്ന റിക്കഴ്‌സീവ് ചങ്കിംഗിലേക്ക് (recursive chunking) ഞങ്ങൾ മാറി. ഇത് സെക്ഷനുകൾ, സബ്സെക്ഷനുകൾ, ക്ലോസുകൾ എന്നിവയെ അതിർവരമ്പുകളായി പരിഗണിക്കുന്നു. ഒരു ക്ലോസ് എന്നത് അർത്ഥപൂർണ്ണമായ ഒരു യൂണിറ്റായതുകൊണ്ട് അത് മുറിയാതെ നിലനിൽക്കുന്നു. നിങ്ങൾ അതിനെ മുറിച്ചാൽ, നിയമപരമായ യുക്തി നഷ്ടപ്പെടും.

API ഡോക്യുമെന്റുകൾക്കായി, സ്ട്രക്ചർ-അവയർ ചങ്കിംഗ് (structure-aware chunking) ഫംഗ്ഷനുകൾ, ക്ലാസുകൾ, എൻഡ്‌പോയിന്റുകൾ എന്നിവയെ അറ്റോമിക് (atomic) ആയി പരിഗണിക്കുന്നു. ഒരു ചങ്കിൽ ഒരു ഫംഗ്ഷൻ സിഗ്നേച്ചർ, അതിന്റെ ആർഗ്യുമെന്റുകൾ, അതിന്റെ ഡോക്സ്ട്രിംഗ് (docstring) എന്നിവ ഉൾപ്പെട്ടേക്കാം. ടോക്കൺ കൗണ്ടർ കൂടിയതുകൊണ്ട് മാത്രം അത് അടുത്ത യൂട്ടിലിറ്റി ഫംഗ്ഷനിലേക്ക് അനാവശ്യമായി വ്യാപിക്കില്ല. ഇത് എംബെഡിംഗിനെ ഒരു പ്രത്യേക കപ്പാബിലിറ്റിയിൽ മാത്രം കേന്ദ്രീകരിക്കുന്നു.

സപ്പോർട്ട് ടിക്കറ്റുകൾ കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്. അവ സംഭാഷണ രൂപത്തിലുള്ളതും, ത്രെഡുകളായി കിടക്കുന്നതും, നോൺ-ലീനിയർ (nonlinear) ആയതുമാണ്. ഫിക്സഡ് ചങ്കുകൾ ഉപയോഗിച്ചാൽ ഒരു എൻജിനീയറുടെ സ്റ്റാറ്റസ് അപ്ഡേറ്റും അതേ ത്രെഡിലെ ഒരു ഉപഭോക്താവിന്റെ പരാതിയും എടുത്ത് അവ രണ്ടും ഒരേ യൂണിറ്റാണെന്ന് വരുത്തിത്തീർക്കാൻ സാധ്യതയുണ്ട്. അതിനാൽ ഞങ്ങൾ സെമാന്റിക് ചങ്കിംഗിലേക്ക് (semantic chunking) മാറി; അതായത് ടോക്കൺ ബജറ്റ് തീരുമ്പോൾ എന്നതിലുപരി, വിഷയം അല്ലെങ്കിൽ സംസാരിക്കുന്ന ആൾ മാറുന്നിടത്ത് വെച്ച് ഡാറ്റയെ വിഭജിക്കുന്നു.

കമ്പനികൾക്കുള്ളിലെ വികികൾ (Internal wikis) പലപ്പോഴും ക്രമരഹിതമായ ഡാറ്റയാണ്. ഫോർമാറ്റിംഗിൽ വ്യത്യാസമുണ്ടാകാം, ഹെഡറുകൾ ഇല്ലാതിരിക്കാം, സെക്ഷനുകൾ തമ്മിൽ കലർന്നിരിക്കാം. ഇവയ്ക്കായി ഞങ്ങൾ LLM അധിഷ്ഠിത ചങ്കിംഗ് ഉപയോഗിക്കുന്നു. ഒരു ചെറിയ മോഡൽ എംബെഡിംഗ് നിർമ്മിക്കുന്നതിന് മുമ്പ് തന്നെ വരാനിരിക്കുന്ന ഭാഗങ്ങൾ വായിച്ച് ലോജിക്കൽ അതിർവരമ്പുകൾ തിരിച്ചറിയുന്നു. ഇത് ക്യാരക്ടർ സ്പ്ലിറ്റിനേക്കാൾ കൂടുതൽ ചിലവ് വരുത്തുമെങ്കിലും, റിട്രീവൽ ക്വാളിറ്റി അതിന്റെ മൂല്യം ഉടൻ തന്നെ തിരിച്ചുനൽകുന്നു.

ഹൈബ്രിഡ് റിട്രീവൽ (Hybrid Retrieval): സിഗ്നലുകൾ സംയോജിപ്പിക്കുക

വെക്റ്റർ സെർച്ച് (Vector search) ശക്തമാണ്, പക്ഷേ അതിന് ചില പരിമിതികളുണ്ട്. ERR_CONNECTION_REFUSED_0x800 പോലുള്ള ഒരു കൃത്യമായ എറർ കോഡ് നൽകിയാൽ, എംബെഡിംഗ് സ്പേസ് അവയെ അടുത്തടുത്ത് ക്ലസ്റ്റർ ചെയ്തതുകൊണ്ട് ബന്ധമില്ലാത്ത മറ്റൊരു മോഡ്യൂളിന്റെ ട്രബിൾഷൂട്ടിംഗ് ഗൈഡ് വെക്റ്റർ സെർച്ച് നൽകിയേക്കാം. കൃത്യമായ പൊരുത്തങ്ങൾ (Exact matches) പ്രധാനമാണ്, വെക്റ്റർ സെർച്ച് മാത്രം ഉപയോഗിച്ചാൽ അവ വിസ്മരിക്കപ്പെട്ടേക്കാം.

BM25 ഉപയോഗിച്ചുള്ള കീവേഡ് സെർച്ച് (Keyword search) ഈ എക്സാക്റ്റ് മാച്ച് പ്രശ്നം മനോഹരമായി പരിഹരിക്കുന്നു. എന്നാൽ ആശയപരമായ അകലം (conceptual distance) കണ്ടെത്തുന്നതിൽ അത് പരാജയപ്പെട്ടേക്കാം. ഒരു ഉപയോക്താവ് "heavy load സമയത്തെ പെർഫോമൻസ് കുറവ്" (performance degradation under heavy load) എന്നതിനെക്കുറിച്ച് ചോദിച്ചാൽ, "traffic spikes സമയത്തെ സ്ലോ ത്രൂപുട്ട്" (slow throughput during traffic spikes) എന്ന് വിവരിക്കുന്ന ഒരു ഡയഗ്നോസ്റ്റിക് നോട്ട് BM25 കണ്ടുപിടിക്കില്ല, കാരണം അവിടെ കീവേഡുകൾ തമ്മിൽ വലിയ സാമ്യമില്ല.

ഞങ്ങൾ ഏതെങ്കിലും ഒന്നിനെ മാത്രം തിരഞ്ഞെടുക്കുന്നതിന് പകരം രണ്ടും സമാന്തരമായി പ്രവർത്തിപ്പിക്കാൻ തുടങ്ങി. വെക്റ്റർ സെർച്ചും കീവേഡ് സെർച്ചും അവയുടെ സ്വന്തം റാങ്ക് ചെയ്ത ലിസ്റ്റുകൾ നൽകുന്നു. ഞങ്ങൾ അവയെ Reciprocal Rank Fusion (RRF) ഉപയോഗിച്ച് സംയോജിപ്പിക്കുന്നു. RRF അതിന്റെ ഫലപ്രാപ്തിയിൽ ലളിതവും ശക്തവുമാണ്. ഓരോ ലിസ്റ്റിലും ഒരു ഡോക്യുമെന്റ് എവിടെയാണെന്നതിനെ അടിസ്ഥാനമാക്കി അത് സ്കോർ ചെയ്യുന്നു. രണ്ട് സിസ്റ്റങ്ങളിലും മുകളിൽ നിൽക്കുന്ന ഡോക്യുമെന്റുകൾക്ക് വലിയ മുൻഗണന ലഭിക്കുന്നു. ഒരു എൻജിൻ മാത്രം ഇഷ്ടപ്പെടുന്ന ഡോക്യുമെന്റുകൾക്ക് പോലും ഫൈനൽ ലിസ്റ്റിൽ ഇടം ലഭിക്കുന്നു.

ഫ്യൂഷന് ശേഷം, ഞങ്ങൾ മികച്ച ഉദ്യോഗാർത്ഥികളെ (top candidates) ഒരു cross-encoder reranker വഴി പരിശോധിക്കുന്നു. ഇത് സൗജന്യമല്ല. ഇത് ഏകദേശം 50 മില്ലിസെക്കൻഡ് കമ്പ്യൂട്ട് സമയം അധികം എടുക്കുന്നു. എന്നാൽ ഇത് recall 15% വർദ്ധിപ്പിക്കുന്നു. ഒരു bi-encoder embedding-നേക്കാൾ വളരെ കൃത്യമായ ഒരു relevance score നൽകാൻ cross-encoder-ന് സാധിക്കുന്നു. ആ അധികം വരുന്ന 50 മില്ലിസെക്കൻഡ് ലാഭകരമാണ്. ഇത് LLM-ലേക്ക് തെറ്റായ വിവരങ്ങൾ (garbage context window) നൽകുന്നതും, ആശയക്കുഴപ്പത്തിലായതോ തെറ്റായതോ ആയ (hallucinated) ഉത്തരങ്ങൾക്കായി രണ്ട് സെക്കൻഡ് കാത്തുനിൽക്കേണ്ടി വരുന്നതും ഒഴിവാക്കുന്നു.

തിരയുന്നതിന് മുമ്പ് ക്വറി (Query) ശരിയാക്കുക

സെർച്ച് എഞ്ചിനീയർമാരെപ്പോലെ ഉപയോക്താക്കൾ ക്വറികൾ എഴുതാറില്ല. അവർ "app broken" എന്ന് ടൈപ്പ് ചെയ്തേക്കാം. അവ്യക്തമായ ലോഗ് ഫ്രാഗ്മെന്റുകൾ (log fragments) പേസ്റ്റ് ചെയ്തേക്കാം. അവ്യക്തവും അനിശ്ചിതത്വമുള്ളതുമായ ചോദ്യങ്ങൾ ചോദിച്ചേക്കാം. ഈ വിവരങ്ങൾ നേരിട്ട് ഇൻഡക്സിലേക്ക് അയച്ചാൽ, നിങ്ങൾക്ക് ലഭിക്കുന്നതും തെറ്റായ വിവരങ്ങൾ മാത്രമായിരിക്കും.

റിട്രീവൽ എഞ്ചിനിലേക്ക് (retrieval engine) എത്തുന്നതിന് മുമ്പ് ഞങ്ങൾ ഓരോ ക്വറിയും പരിവർത്തനം ചെയ്യുന്നു.

ഒന്നാമതായി, ക്വറി എക്സ്പാൻഷൻ (query expansion). ഒരു ചെറിയ ചോദ്യത്തിൽ നിന്ന് സിസ്റ്റം ഒന്നിലധികം സെർച്ച് പദങ്ങൾ നിർമ്മിക്കുന്നു. ഒരു ഉപയോക്താവ് "How do I fix the timeout?" എന്ന് ചോദിച്ചാൽ, കണക്ഷൻ ടൈമൗട്ട് (connection timeouts), റീഡ് ടൈമൗട്ട് (read timeouts), ഗേറ്റ്‌വേ ടൈമൗട്ട് (gateway timeouts), റീട്രൈ ലോജിക് (retry logic) എന്നിവ ഉൾക്കൊള്ളുന്ന രീതിയിൽ എഞ്ചിൻ അതിനെ വിപുലീകരിക്കുന്നു. ഈ രീതി മാത്രം നമ്മുടെ recall 78%-ൽ നിന്ന് 96%-ലേക്ക് ഉയർത്തി.

രണ്ടാമതായി, ക്വറി ഡീകമ്പോസിഷൻ (query decomposition). സങ്കീർണ്ണമായ ചോദ്യങ്ങളെ ചെറിയ ഉപചോദ്യങ്ങളായി (sub-questions) മാറ്റുന്നു. "What's the refund policy for enterprise customers past 90 days and how does it differ from monthly plans?" എന്നതുപോലെയുള്ള ഒരു ക്വറി, ഒരു വലിയ എംബഡിംഗ് ലുക്കപ്പ് (embedding lookup) എന്നതിന് പകരം രണ്ട് കൃത്യമായ സെർച്ചുകളായി മാറുന്നു. ഓരോ ഉപചോദ്യവും ഇൻഡക്സിനെ സ്വതന്ത്രമായി സമീപിക്കുന്നു. പിന്നീട് ഫലങ്ങൾ കൂട്ടി യോജിപ്പിക്കുന്നു. ഇത് റിട്രീവൽ കൃത്യതയുള്ളതാക്കുന്നു, കൂടാതെ ഒരൊറ്റ എംബഡിംഗ് ഒരേസമയം ഒരുപാട് കാര്യങ്ങൾ തിരയാൻ ശ്രമിക്കുമ്പോൾ ഉണ്ടാകുന്ന ആശയക്കുഴപ്പം ഒഴിവാക്കുന്നു.

നിങ്ങൾ ഇപ്പോഴും ചങ്ക് സൈസ് (chunk size), ഓവർലാപ്പ് റേഷ്യോ (overlap ratios), റിട്രീവൽ വെയ്റ്റുകൾ (retrieval weights) എന്നിവ മാനുവലായി ട്യൂൺ ചെയ്യുകയാണെങ്കിൽ, നിങ്ങൾ മികച്ച പ്രകടനം നഷ്ടപ്പെടുത്തുകയാണ്. ഞങ്ങൾ ഊഹിച്ചുകൊണ്ട് പ്രവർത്തിക്കുന്നത് നിർത്തി.

ചങ്ക് സൈസ്, ഓവർലാപ്പ് ശതമാനം, വെക്റ്റർ-വിവരസെറ്റ് (vector-versus-BM25) വെയ്റ്റുകൾ, റീറങ്കർ ത്രെഷോൾഡുകൾ (reranker thresholds) എന്നിവയെല്ലാം വേരിയബിളുകളായി കണക്കാക്കുന്ന ഒരു സെർച്ച് സ്പേസ് ഞങ്ങൾ നിർവചിച്ചു. തുടർന്ന് ഞങ്ങൾ Bayesian optimization പ്രയോഗിച്ചു. നൂറുകണക്കിന് ക്രമീകരണങ്ങൾ (configurations) പരിശോധിക്കുന്നതിന് പകരം, ഏതാണ് ഫലപ്രദമെന്ന് കണ്ടെത്തുന്നതിനായി Bayesian search ഒരു പ്രോബബിലിസ്റ്റിക് മോഡൽ നിർമ്മിക്കുന്നു. ഇത് ഒരു കോൺഫിഗറേഷൻ നിർദ്ദേശിക്കുന്നു, അതിന്റെ recall ഉം latency ഉം നിരീക്ഷിക്കുന്നു, തുടർന്ന് അടുത്തത് നിർദ്ദേശിക്കുന്നു. കാലക്രമേണ, ഒരു മനുഷ്യന് മാനുവലായി കണ്ടെത്താൻ കഴിയാത്ത മികച്ച സന്തുലിതാവസ്ഥയിലേക്ക് ഇത് എത്തിച്ചേരുന്നു.

ഞങ്ങൾ ഒരിക്കലും പരീക്ഷിക്കാത്ത കോമ്പിനേഷനുകൾ ഇത് കണ്ടെത്തി. കൂടുതൽ ഓവർലാപ്പുള്ള ചെറിയ ചങ്കുകൾ (smaller chunks with heavier overlap). ഡെൻസ് വെക്റ്റർ സെർച്ചിൽ (dense vector search) കുറഞ്ഞ വെയ്റ്റും കൂടുതൽ ശക്തമായ റീറങ്കർ ത്രെഷോൾഡും ഉപയോഗിച്ചുള്ള രീതി. ഇത്തരം സങ്കീർണ്ണമായ മാറ്റങ്ങൾ (tradeoffs) ഉയർന്ന recall ഉം കുറഞ്ഞ latency ഉം നൽകി.

ഇതൊരു ഒറ്റത്തവണത്തെ ജോലിയല്ല. ഞങ്ങൾ മാസം തോറും ഹൈപ്പർപാരാമീറ്റർ ഒപ്റ്റിമൈസേഷൻ (hyperparameter optimization) വീണ്ടും ചെയ്യുന്നു. നിങ്ങളുടെ കോർപ്പസ് (corpus) മാറിക്കൊണ്ടിരിക്കും, ഉപയോക്താക്കളുടെ പെരുമാറ്റവും മാറും. അതിനാൽ നിങ്ങളുടെ പൈപ്പ്‌ലൈൻ മാറുന്ന സാഹചര്യത്തിനനുസരിച്ച് മാറിക്കൊണ്ടിരിക്കണം.

ഫലം

ഈ മാറ്റങ്ങളുടെ ഫലം വളരെ വ്യക്തമാണ്.

പത്താം സ്ഥാനത്തെ recall 78%-ൽ നിന്ന് 95%-ലേക്ക് ഉയർന്നു. ശരിയായ ഉത്തരം നമ്മുടെ നോളജ് ബേസിലുണ്ടെങ്കിൽ, ഇരുപതിൽ പത്തൊൻപത് തവണയും അത് കൃത്യമായി ലഭിക്കുന്നു. 95th percentile-ലെ ലേറ്റൻസി (latency) 850 മില്ലിസെക്കൻഡിൽ നിന്ന് 320 മില്ലിസെക്കൻഡിലേക്ക് കുറഞ്ഞു. ചാറ്റ് ഇപ്പോൾ വളരെ വേഗത്തിൽ പ്രതികരിക്കുന്നു.

മെച്ചപ്പെട്ട റിട്രീവൽ ലാംഗ്വേജ് മോഡലിന് മികച്ച അടിത്തറ (grounding) നൽകി. Hallucination നിരക്ക് 12%-ൽ നിന്ന് 3%-ലേക്ക് കുറഞ്ഞു. ശരിയായ കോൺടെക്സ്റ്റ് (context) ലഭിക്കുമ്പോൾ മോഡൽ തെറ്റായ വിവരങ്ങൾ നിർമ്മിക്കുന്നത് നിർത്തുന്നു. ഓരോ ക്വറിക്കുമുള്ള ചിലവ് 38% കുറഞ്ഞു. വേഗതയേറിയതും കൃത്യവുമായ റിട്രീവൽ എന്നാൽ അനാവശ്യമായ വിവരങ്ങൾക്കും റീട്രൈ ലൂപ്പുകൾക്കും (retry loops) ഉപയോഗിക്കുന്ന ടോക്കണുകളുടെ എണ്ണം കുറയുന്നു എന്നാണ് അർത്ഥം.

ഇൻഫ്രാസ്ട്രക്ചർ പോലെ നിർമ്മിക്കുക

നിങ്ങൾ ഒരു പ്രോട്ടോടൈപ്പിൽ നിന്ന് പ്രൊഡക്ഷനിലേക്ക് മാറാൻ തയ്യാറെടുക്കുകയാണെങ്കിൽ, റിട്രീവലിനെ വെറുമൊരു കോൺഫിഗറേഷനായി കാണാതെ ഇൻഫ്രാസ്ട്ര