People keep writing obituaries for RAG. You have probably seen the headlines by now. Long context windows killed it. Age

ആളുകൾ RAG-ന്റെ മരണവാർത്തകൾ എഴുതിക്കൊണ്ടിരിക്കുകയാണ്. ലോങ്ങ് കോൺടെക്സ്റ്റ് വിൻഡോകൾ ഇതിനെ ഇല്ലാതാക്കി എന്നും ഏജന്റുകൾ ഇതിനെ മാറ്റിസ്ഥാപിച്ചു എന്നും നിങ്ങൾ ഇപ്പോൾ വാർത്തകളിൽ കണ്ടിട്ടുണ്ടാകാം. ഈ രീതി മുഴുവനായി കാലഹരണപ്പെട്ടു എന്നും പറയപ്പെടുന്നു. എന്നാൽ സത്യം ഇതിലും പരിമിതവും എന്നാൽ വളരെ പ്രയോജനപ്രദവുമാണ്. RAG മരിച്ചിട്ടില്ല. ഡോക്യുമെന്റുകളുടെ ഒരു കൂട്ടത്തെ കഷണങ്ങളാക്കി (chunks) വെക്റ്റർ ഡാറ്റാബേസിൽ നൽകിയാൽ മാത്രം ഒരു വിശ്വസനീയവും സത്യസന്ധവുമായ AI ലഭിക്കും എന്ന സുഖപ്രദമായ മിഥ്യാധാരണയാണ് തകർന്നത്.

കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ്, ഇതിന്റെ ലളിതമായ രീതി വളരെ ആകർഷകമായിരുന്നു. നിങ്ങളുടെ നോളജ് ബേസ് എംബെഡ് ചെയ്യുക. അത് ഒരു LLM-മായി ബന്ധിപ്പിക്കുക. ഒരു ചോദ്യം ചോദിക്കുക, എന്നിട്ട് റിട്രീവ് ചെയ്ത ഡാറ്റ ഉപയോഗിച്ച് മോഡൽ ഉത്തരം നൽകുന്നത് കാണുക. നിയന്ത്രിത ഡെമോകൾക്കും ചെറിയ FAQ ബോട്ടുകൾക്കും ഇത് സത്യത്തിൽ പ്രവർത്തിച്ചു. ഇരുപത് പേജുള്ള ഒരു ഹെൽപ്പ് ഡെസ്ക് മാനുവലോ, അല്ലെങ്കിൽ ഒരു ചെറിയ ഇന്റേണൽ വിക്കിയോ ഇതിന് ഉദാഹരണമാണ്. ബോട്ട് ഏകദേശം ശരിയായ പാരഗ്രാഫ് തന്നെ ഉദ്ധരിക്കും, അതോടെ പൈലറ്റ് പ്രോജക്റ്റുകൾക്ക് നേതൃത്വത്തിന്റെ അംഗീകാരവും ലഭിക്കും. എന്നാൽ പൈലറ്റ് പ്രോജക്റ്റുകൾ പ്രൊഡക്ഷൻ നിലവാരമുള്ളതല്ല. യഥാർത്ഥ ബിസിനസ്സ് പ്രവർത്തനങ്ങളിലെ വെല്ലുവിളികൾ പ്രോട്ടോടൈപ്പുകളിൽ ഉണ്ടാകില്ല.

പ്രൊഡക്ഷൻ ഡാറ്റ സങ്കീർണ്ണമാണ്. ഒരേ പ്രശ്നപരിഹാര കുറിപ്പ് പല ഫയലുകളിൽ പല സമയക്രമത്തിലും (timestamps) വ്യത്യസ്ത സ്റ്റാറ്റസ് ലേബലുകളിലും കാണപ്പെട്ടേക്കാം. പേജുകൾക്കിടയിൽ മുറിഞ്ഞുപോകുന്ന സങ്കീർണ്ണമായ ടേബിളുകൾ, അവയെ കഷണങ്ങളാക്കുമ്പോൾ അർത്ഥശൂന്യമായി മാറുന്നു. വൈരുദ്ധ്യങ്ങൾ നിലനിർത്താനും ഇവ കാരണമാകും. 2023-ലെ പോളിസി മാനുവൽ ഒരു കാര്യം പറയുമ്പോൾ, 2024 മാർച്ചിലെ ഭേദഗതി മറ്റൊന്ന് പറയുന്നുണ്ടാകാം. പഴയ PDF ഒരിക്കലും ആർക്കൈവ് ചെയ്തിട്ടുണ്ടാകില്ല. കഷണങ്ങളാക്കുക, സൂക്ഷിക്കുക, റിട്രീവ് ചെയ്യുക എന്ന ലളിതമായ രീതി ഓരോ പാരഗ്രാഫിനെയും ഒറ്റപ്പെട്ട ഒന്നായി കാണുന്നു. ഇതിന് ഹയരാർക്കി (hierarchy), വേർഷൻ ഹിസ്റ്ററി (version history) അല്ലെങ്കിൽ വൈരുദ്ധ്യങ്ങൾ പരിഹരിക്കാനുള്ള കഴിവില്ല. LLM തകരാറിലായതുകൊണ്ടല്ല മോഡൽ തെറ്റായ വിവരങ്ങൾ (hallucinate) നൽകുന്നത്, മറിച്ച് അതിന് ലഭിച്ച കോൺടെക്സ്റ്റ് അപൂർണ്ണമോ, ഒറ്റപ്പെട്ടതോ അല്ലെങ്കിൽ തികച്ചും തെറ്റോ ആയതുകൊണ്ടാണ്.

കോൺടെക്സ്റ്റ് വിൻഡോകൾ വലുതാകുമ്പോൾ റിട്രീവൽ ആവശ്യമില്ലെന്ന് ചില നിരീക്ഷകർ അവകാശപ്പെടുന്നു. അവരുടെ വാദം ലളിതമാണ്: മുഴുവൻ വിവരങ്ങളും പ്രോംപ്റ്റിലേക്ക് നേരിട്ട് നൽകുക, എന്നിട്ട് മോഡലിനെ അത് വായിക്കാൻ അനുവദിക്കുക. ഇത് കേൾക്കുമ്പോൾ മികച്ചതായി തോന്നാം, എന്നാൽ ഇത് അപകടകരമായ ശുഭാപ്തിവിശ്വാസമാണ്. ഒരു ചെറിയ നോവലിന് തുല്യമായ വായനശേഷി ഒരു മോഡലിന് സാങ്കേതികമായി ഉണ്ടായേക്കാം, എങ്കിലും ആ വലിയ വിവരശേഖരത്തിനിടയിൽ നിന്ന് ഒരു പ്രത്യേക ഭാഗം മാത്രം കണ്ടെത്തുക എന്നത് തികച്ചും വ്യത്യസ്തമായ ഒരു കഴിവാണ്. വൈക്കോൽ കൂമ്പാരത്തിലെ സൂചി പോലെ അവ നഷ്ടപ്പെട്ടുകൊണ്ടിരിക്കും. ലോങ്ങ് കോൺടെക്സ്റ്റ് വിൻഡോകൾ ലഭ്യമായ ഇടം വർദ്ധിപ്പിക്കുന്നുണ്ടെങ്കിലും, ആ സ്ഥലത്ത് എന്താണ് ഉൾപ്പെടുത്തേണ്ടതെന്ന് തീരുമാനിക്കുന്ന പ്രയാസകരമായ ജോലിയെ അത് പരിഹരിക്കുന്നില്ല. പ്രശ്നം വെറും റിട്രീവൽ മാത്രമല്ല. അത് എപ്പോഴും കോൺടെക്സ്റ്റ് അസംബ്ലി (context assembly) ആയിരുന്നു.

ലളിതമായ റിട്രീവലിൽ നിന്ന് കോൺടെക്സ്റ്റ് എഞ്ചിനീയറിംഗിലേക്ക്

2026-ൽ ഈ മേഖല പക്വത പ്രാപിക്കുകയാണ്. RAG എന്നത് ഒരു ലളിതമായ പൈപ്പ്‌ലൈൻ എന്നതിലുപരി, കോൺടെക്സ്റ്റ് കൃത്യമായി രൂപകൽപ്പന ചെയ്യുന്ന ഒരു ആർക്കിടെക്ചറിലേക്ക് നമ്മൾ മാറിക്കൊണ്ടിരിക്കുകയാണ്.

ശുദ്ധമായ സെമാന്റിക്സിന് പകരം ഹൈബ്രിഡ് സെർച്ച്. ഉദ്ദേശ്യം മനസ്സിലാക്കാൻ സെമാന്റിക് സിമിലാരിറ്റി മികച്ചതാണ്, എന്നാൽ കൃത്യമായ ഐഡന്റിഫയറുകൾ കൈകാര്യം ചെയ്യുമ്പോൾ അത് അത്ര കൃത്യതയുള്ളതല്ല. ഒരു എഞ്ചിനീയർ ERR_CONNECTION_REFUSED എന്ന എറർ കോഡോ അല്ലെങ്കിൽ v3.2.1 എന്ന സോഫ്റ്റ്‌വെയർ വേർഷനോ തിരയുകയാണെങ്കിൽ, വെക്റ്റർ സെർച്ച് മാത്രം ഉപയോഗിക്കുന്നത് കൃത്യമായ ഫലത്തിന് പകരം സമാനമായ എന്നാൽ പ്രസക്തമല്ലാത്ത ഫലങ്ങൾ നൽകിയേക്കാം. ആധുനിക സിസ്റ്റങ്ങൾ ഡെൻസ് വെക്റ്റർ റിട്രീവലിനൊപ്പം BM25 അല്ലെങ്കിൽ ഇൻവേർട്ടഡ് ഇൻഡക്സുകൾ പോലുള്ള കീവേഡ് സെർച്ച് രീതികളും സംയോജിപ്പിക്കുന്നു. ഇതുവഴി കൃത്യമായ പേരുകളും എറർ കോഡുകളും വേർഷൻ സ്ട്രിംഗുകളും കീവേഡ് ലെയർ വഴി കണ്ടെത്താനും ആശയപരമായ സൂക്ഷ്മതകൾ വെക്റ്റർ ലെയർ വഴി കൈകാര്യം ചെയ്യാനും സാധിക്കുന്നു.

ജനറേഷന് മുമ്പുള്ള റീറാൻക്കിംഗ് (Reranking). റിട്രീവൽ പ്രക്രിയ സ്വാഭാവികമായും കൂടുതൽ വിവരങ്ങൾ ശേഖരിക്കുന്നതിലേക്ക് (recall) ചായുന്നു. പ്രധാനപ്പെട്ട ഒരു പാരഗ്രാഫ് നഷ്ടപ്പെടുമോ എന്ന ഭയത്താൽ നിങ്ങൾ നാൽപ്പതോ അൻപതോ കഷണങ്ങൾ ശേഖരിച്ചേക്കാം. എന്നാൽ ഇത്രയധികം വിവരങ്ങൾ ഒരു വലിയ മോഡലിലേക്ക് നൽകുന്നത് ടോക്കണുകൾ പാഴാക്കുകയും പ്രധാനപ്പെട്ട വിവരങ്ങൾ മറഞ്ഞുപോവാനും കാരണമാകും. റീറാൻക്കിംഗ് ഈ പ്രശ്നം പരിഹരിക്കുന്നു; ഒരു ചെറിയ മോഡൽ ഉപയോഗിച്ച് ഓരോ കഷണവും ചോദ്യവുമായി എത്രത്തോളം പ്രസക്തമാണെന്ന് പരിശോധിക്കുന്നു. ഏറ്റവും മികച്ച അഞ്ച് ഭാഗങ്ങൾ മാത്രം മുന്നോട്ട് കൊണ്ടുപോകുന്നു, ബാക്കിയുള്ളവ ഒഴിവാക്കുന്നു. ഇത് റിട്രീവലിനും ജനറേഷനും ഇടയിലുള്ള ഒരു ഫിൽട്ടറായി പ്രവർത്തിക്കുന്നു, അതുവഴി വിലകൂടിയ റീസണിംഗ് മോഡൽ പ്രസക്തമായ കാര്യങ്ങൾ മാത്രം വായിക്കുന്നു എന്ന് ഉറപ്പാക്കുന്നു.

അർത്ഥം നിലനിർത്തുന്ന കോൺടെക്സ്റ്റ് റിട്രീവൽ. കഷണങ്ങളാക്കി മാറ്റുന്നത് (Chunking) വിവരങ്ങളുടെ ഘടനയെ തകർക്കുന്ന പ്രക്രിയയാണ്. ഒരു സ്പ്ലിറ്റർ ഒരു പാരഗ്രാഫിനെ അതിന്റെ ഹെഡറിൽ നിന്നോ, ടേബിൾ ക്യാപ്ഷനിൽ നിന്നോ, അല്ലെങ്കിൽ അതിന്റെ അർത്ഥം മാറ്റുന്ന ഫൂട്ട്നോട്ടിൽ നിന്നോ വേർപെടുത്തിയേക്കാം. കോൺടെക്സ്റ്റ് റിട്രീവൽ, വിവരങ്ങൾ മോഡലിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ അവയെ മെറ്റാഡാറ്റ ഉപയോഗിച്ച് സമ്പന്നമാക്കുന്നതിലൂടെ ഈ പ്രശ്നം ലഘൂകരിക്കുന്നു. ഉദാഹരണത്തിന്, വിവരത്തിന്റെ ഉറവിടം സൂചിപ്പിക്കുന്ന മെറ്റാഡാറ്റ ചേർക്കുന്നു: ഈ ഭാഗം 2024 Q3 ഇൻസിഡന്റ് റിപ്പോർട്ടിലെ, ഡാറ്റാബേസ് ഔട്ടേജ് വിഭാഗത്തിലെ, ക്രിട്ടിക്കൽ ലെവലിലുള്ള വിവരമാണ്. അപ്പോൾ മോഡലിന് വെറുമൊരു വാചകം മാത്രമല്ല, കൃത്യമായ സന്ദർഭത്തിലുള്ള വിവരമാണ് ലഭിക്കുന്നത്. ആ വിവരത്തിന് അതിന്റെ യഥാർത്ഥ സന്ദർഭം തിരികെ ലഭിക്കുന്നു.

ഉദ്ദേശ്യത്തിനനുസരിച്ചുള്ള മോഡുലാർ റൂട്ടിംഗ്. എല്ലാ ചോദ്യങ്ങളും ഡോക്യുമെന്റേഷൻ നിറഞ്ഞ ഒരു വെക്റ്റർ സ്റ്റോറിൽ ഉൾപ്പെടുത്തേണ്ടതില്ല. പാസ്‌വേഡ് എങ്ങനെ റീസെറ്റ് ചെയ്യാം എന്ന് ചോദിക്കുന്ന ഒരു ഉപയോക്താവിന് ഒരു ഹെൽപ്പ് ആർട്ടിക്കിൾ ആയിരിക്കും വേണ്ടത്. കഴിഞ്ഞ പാദത്തിൽ വടക്കുകിഴക്കൻ മേഖലയിൽ വരുമാനം കുറയാൻ കാരണമെന്താണെന്ന് ചോദിക്കുന്ന ഒരു ഉപയോക്താവിന് ഡാറ്റാ വെയർഹൗസിനെതിരെയുള്ള SQL ആവശ്യമാണ്, അല്ലാതെ പ്രാദേശിക വിൽപന തന്ത്രത്തെക്കുറിച്ചുള്ള സമാനമായ ഒരു ഖണ്ഡികയല്ല. പരിഷ്കൃതമായ സിസ്റ്റങ്ങൾ ഇപ്പോൾ ചോദ്യങ്ങളെ അവയുടെ ഉദ്ദേശ്യത്തിനനുസരിച്ച് റൂട്ട് ചെയ്യുകയും അനുയോജ്യമായ ടൂൾ തിരഞ്ഞെടുക്കുകയും ചെയ്യുന്നു. നടപടിക്രമങ്ങൾക്കായി ഡോക്യുമെന്റേഷൻ. ഘടനാപരമായ അനലിറ്റിക്സിനായി റിലേഷണൽ ഡാറ്റാബേസുകൾ. ട്രേസ് ഡീബഗ്ഗിംഗിനായി ലോഗ് അഗ്രഗേറ്ററുകൾ. ലൈവ് സ്റ്റാറ്റസിനായി APIs. റിട്രീവൽ ലെയർ ഒരു ഡിസ്പാച്ചറായി മാറുന്നു, അല്ലാതെ ഒരു ഏകശിലാത്മക സംവിധാനമായിട്ടല്ല.

ഏജന്റിക് റീസണിംഗ് ലൂപ്പുകൾ. ചില ചോദ്യങ്ങൾക്ക് ഒറ്റ സെർച്ച് സ്റ്റെപ്പിലൂടെ ഉത്തരം നൽകാൻ കഴിയില്ല. അവയ്ക്ക് പുനർനിർമ്മാണം (reformulation) ആവശ്യമാണ്. അവ്യക്തമായ ഒരു പ്രാരംഭ ചോദ്യം വ്യക്തമാക്കപ്പെടുന്നു. കണ്ടെത്തിയ അവകാശവാദങ്ങൾ രണ്ടാമതൊരു സ്രോതസ്സുമായി ഒത്തുനോക്കുന്നു. ഡോക്യുമെന്റേഷൻ API സ്പെസിഫിക്കേഷനുമായി വൈരുദ്ധ്യത്തിലാണെങ്കിൽ, സിസ്റ്റം ഒരു ഇടനില കണ്ടെത്താൻ ശ്രമിക്കുന്നതിന് പകരം ആ വൈരുദ്ധ്യം ചൂണ്ടിക്കാണിക്കുന്നു. എപ്പോൾ വീണ്ടും സെർച്ച് ചെയ്യണം, എപ്പോൾ ക്വറി പരിഷ്കരിക്കണം, എപ്പോൾ ഉത്തരം നൽകാൻ ആവശ്യമായ തെളിവുകൾ ശേഖരിച്ചു എന്ന് മോഡൽ തന്നെ തീരുമാനിക്കുന്നു. ഇത് വൺ-ഷോട്ട് റിട്രീവൽ അല്ല. സെർച്ചിനെ ഒരു സബ്റൂട്ടിനായി ഉപയോഗിക്കുന്ന ഘടനാപരമായ റീസണിംഗാണ് ഇത്.

റിലേഷണൽ ചോദ്യങ്ങൾക്കായി GraphRAG. ചില ബിസിനസ് ചോദ്യങ്ങൾ വാചകങ്ങളെക്കുറിച്ചല്ല, മറിച്ച് ബന്ധങ്ങളെക്കുറിച്ചാണ്. ഏത് കമ്പോണന്റ് പരാജയമാണ് ഏത് ഡൗൺസ്ട്രീം അലേർട്ടുകൾക്ക് കാരണമായത്? ഏത് സപ്ലയർ ഏത് ഫാക്ടറിയിലേക്കാണ് സാധനങ്ങൾ എത്തിക്കുന്നത്, ബദൽ മാർഗ്ഗം എന്താണ്? ഈ പ്രത്യേക ബജറ്റ് ലൈനിന്മേൽ സ്ഥാപനത്തിൽ ആർക്കാണ് തീരുമാനമെടുക്കാനുള്ള അധികാരം? ഫ്ലാറ്റ് ടെക്സ്റ്റ് ചങ്കുകൾ (text chunks) ഈ ബന്ധങ്ങളെ ഇല്ലാതാക്കുന്നു, കാരണം അവ ടോപ്പോളജി നിലനിർത്താൻ രൂപകൽപ്പന ചെയ്തതല്ല. എന്നാൽ നോളജ് ഗ്രാഫുകൾ (Knowledge graphs) അത് ചെയ്യുന്നു. സ്വാധീനം, lineage, പാറ്റേണുകൾ അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് ഘടന എന്നിവയെക്കുറിച്ചാണ് ചോദ്യമെങ്കിൽ, ഒരു ഗ്രാഫ് പരിശോധിക്കുന്നത് ഒരു ഖണ്ഡിക റിട്രീവലിനും പകരം വെക്കാൻ കഴിയാത്ത സന്ദർഭങ്ങൾ (context) നൽകുന്നു.

യഥാർത്ഥത്തിൽ പ്രസക്തമായ ചോദ്യങ്ങൾ

RAG-നെ കുറിച്ചുള്ള ചർച്ചകൾ മാറേണ്ടതുണ്ട്. ഒരു ജനറിക് RAG പൈപ്പ്‌ലൈൻ എങ്ങനെ നിർമ്മിക്കാം എന്ന് ചോദിക്കുന്നത് നിർത്തുക. മോഡൽ ഏത് പ്രത്യേക ടാസ്ക് ആണ് ചെയ്യേണ്ടത്, കൃത്യതയ്ക്കായി അതിന് ഏത് ഡാറ്റയാണ് വേണ്ടത്, ശേഖരിച്ച സന്ദർഭങ്ങൾ (context) പര്യാപ്തമാണോ എന്ന് നിങ്ങൾ എങ്ങനെ പരിശോധിക്കും എന്ന് ചോദിച്ചു തുടങ്ങുക. ഈ ചോദ്യങ്ങൾ ഡാറ്റാ ക്വാളിറ്റി, സ്കീമ ഡിസൈൻ, വെരിഫിക്കേഷൻ ലൂപ്പുകൾ, സ്രോതസ്സിന്റെ ഉറവിടം (source provenance) എന്നിവയിലേക്ക് നിങ്ങളെ നയിക്കുന്നു. നിങ്ങളുടെ നോളജ് ബേസ് ഓട്ടോമേറ്റഡ് ഉപയോഗത്തിന് അനുയോജ്യമാണോ എന്ന് ഇവ വെളിപ്പെടുത്തുന്നു.

RAG എന്നത് ഒരിക്കൽ ഇൻസ്റ്റാൾ ചെയ്ത് മറന്നുപോകാവുന്ന ഒരു ലളിതമായ പ്രക്രിയയല്ല. ഒരു മോഡലിന് ഫലപ്രദമായി ചിന്തിക്കാൻ (reason) കഴിയുന്ന രീതിയിൽ ശരിയായ സന്ദർഭം (context) ഒരുമിച്ചുകൂട്ടുന്ന ഒരു രീതിയാണിത്. അതായത്, റിട്രീവലിനെ ഒരു ലൈബ്രറി ഇംപോർട്ട് ആയിട്ടല്ല, മറിച്ച് ഒരു സിസ്റ്റം ഡിസൈൻ പ്രശ്നമായി കാണണം.

ടൂളുകൾ കൂടുതൽ മികച്ചതാകുന്നു. സെർച്ച് ഹൈബ്രിഡ് ആണ്. റൂട്ടിംഗ് ബുദ്ധിപരമാണ്. റിട്രീവൽ റാങ്ക് ചെയ്യപ്പെട്ടതും, സമ്പന്നമാക്കപ്പെട്ടതും (enriched), പരിശോധിക്കപ്പെട്ടതുമാണ്. യഥാർത്ഥത്തിൽ ഉപയോഗപ്രദമായ ഒന്ന് വരാനായി 2022-ലെ ലളിതമായ മിഥ്യാധാരണകൾ തകരേണ്ടി വന്നു. ഒരു ഡാറ്റാബേസിൽ നിന്ന് ടെക്സ്റ്റ് റിട്രീവ് ചെയ്യുക എന്നത് മാത്രമല്ല നിങ്ങളുടെ ജോലി. മോഡൽ ചിന്തിച്ചു തുടങ്ങുന്നതിന് മുമ്പ് അതിന് എന്താണ് വേണ്ടതെന്ന് അറിയുന്ന സിസ്റ്റങ്ങൾ നിർമ്മിക്കുക എന്നതാണ് നിങ്ങളുടെ ലക്ഷ്യം.

നിങ്ങൾ ഈ മേഖലയിൽ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, ഒരേ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്ന ആളുകളുമായി പ്രായോഗികമായ കാര്യങ്ങൾ പങ്കുവെക്കാൻ GyaanSetu ലേണിംഗ് കമ്മ്യൂണിറ്റി സഹായിക്കും: https://t.me/GyaanSetuAi