ആത്മവിശ്വാസത്തോടെ നൽകുന്ന ഒരു ഉത്തരം ഉത്തരമില്ലാതിരിക്കുന്നതിനേക്കാൾ മോശമാകുന്നത് എന്തുകൊണ്ട്?

ഒരു മറുപടി ഇല്ലാത്തതിനേക്കാൾ മോശമാണ് ആത്മവിശ്വാസത്തോടെ നൽകുന്ന തെറ്റായ മറുപടി

നിങ്ങൾ കമ്പനിക്കായുള്ള ഇന്റേണൽ ചാറ്റ്ബോട്ട് നിർമ്മിച്ചു കഴിഞ്ഞു. കമ്പനിയുടെ എല്ലാ എച്ച്ആർ (HR) പോളിസികളും, എഞ്ചിനീയറിംഗ് സ്പെസിഫിക്കേഷനുകളും, ഓൺബോർഡിംഗ് ഡോക്യുമെന്റുകളും നിങ്ങൾ അതിലേക്ക് നൽകുന്നു. ഒരു പുതിയ ജീവനക്കാരൻ ക്ലയന്റ് ഡിന്നറുകൾക്കുള്ള യാത്രാ ചെലവ് പരിധി (travel expense limit) ചോദിക്കുന്നു. ബോട്ട് ഉടനടി മറുപടി നൽകുന്നു. അത് വളരെ ആത്മവിശ്വാസത്തോടെയാണ് സംസാരിക്കുന്നത്. ഒരാൾക്ക് $75 ആണ് പരിധി എന്ന് അത് പറയുന്നു.

യഥാർത്ഥ പോളിസി പറയുന്നത് $50 എന്നാണ്. ബോട്ട് ആ ഉത്തരം സ്വയം ഉണ്ടാക്കിയെടുത്തതാണ്. അത് നിങ്ങളുടെ ഫയലുകൾ ഒരിക്കലും പരിശോധിച്ചിട്ടില്ല. വർഷങ്ങൾക്ക് മുമ്പ് അതിന്റെ ട്രെയിനിംഗ് ഡാറ്റയിൽ നിന്ന് ലഭിച്ച പാറ്റേണുകൾ ഉപയോഗിച്ച് അത് വെറുതെ ഊഹിക്കുകയായിരുന്നു. സ്വകാര്യ രേഖകൾക്കായി നേരിട്ടുള്ള (raw) ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (LLM) ഉപയോഗിക്കുമ്പോൾ നേരിടേണ്ടി വരുന്ന കഠിനമായ യാഥാർത്ഥ്യമാണിത്. അവയ്ക്ക് നിങ്ങളുടെ ആന്തരിക അറിവുകളിലേക്ക് (internal knowledge) പ്രവേശനമില്ല. അവയ്ക്ക് ആവശ്യമുള്ള വിവരങ്ങൾ അവരുടെ ട്രെയിനിംഗ് ഡാറ്റയ്ക്ക് പുറത്താണെങ്കിൽ, അറിവില്ലെന്ന് സമ്മതിക്കുന്നതിന് പകരം അവ തെറ്റായ വിവരങ്ങൾ നിർമ്മിച്ചെടുക്കുന്നു. പ്രൊഡക്ഷൻ സാഹചര്യങ്ങളിൽ, ഇത് തമാശയായി മാറുന്നില്ല, മറിച്ച് വലിയൊരു ബാധ്യതയായി മാറുന്നു.

Retrieval-Augmented Generation അഥവാ RAG, ഇതേ പ്രശ്നം പരിഹരിക്കാനാണ് നിർമ്മിക്കപ്പെട്ടത്. മോഡലിനോട് എല്ലാം ഓർത്തു വെക്കാൻ ആവശ്യപ്പെടുന്നതിന് പകരം, വിവരങ്ങൾ തിരഞ്ഞു കണ്ടുപിടിക്കാൻ നിങ്ങൾ അതിനെ അനുവദിക്കുന്നു.

ഊഹിക്കുന്നതിൽ നിന്ന് വായിച്ചു മനസ്സിലാക്കുന്നതിലേക്ക്

ഒരു സാധാരണ LLM-നെ ഫോട്ടോഗ്രാഫിക് മെമ്മറിയുള്ള ഒരു മിടുക്കനായ സഹപ്രവർത്തകൻ എന്ന് കരുതുക, പക്ഷേ നിങ്ങൾ കമ്പനിയിൽ ചേരുന്നതിന് മുമ്പ് തന്നെ അയാൾ ജോലിയിൽ നിന്ന് പോയിരിക്കുന്നു. അവർക്ക് മനോഹരമായ ഗദ്യങ്ങൾ എഴുതാനും ലോജിക് പസിലുകൾ പരിഹരിക്കാനും സങ്കീർണ്ണമായ കാര്യങ്ങൾ ലളിതമായി വിശദീകരിക്കാനും കഴിയും. എന്നാൽ കഴിഞ്ഞ പാദത്തിലെ API മാറ്റങ്ങളെക്കുറിച്ച് അവരോട് ചോദിച്ചാൽ, കേൾക്കാൻ വിശ്വസനീയമെന്ന് തോന്നുന്ന എന്തെങ്കിലും അവർ വെറുതെ ഉണ്ടാക്കി പറയും. അവർക്ക് വേറെ വഴിയില്ല.

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

ഈ പ്രക്രിയയെ രണ്ട് ഭാഗങ്ങളായി തിരിക്കാം: ഓഫ്‌ലൈൻ തയ്യാറെടുപ്പുകളും (offline groundwork) ഓൺലൈൻ മറുപടിയും (online response).

ഘട്ടം 1: തയ്യാറെടുപ്പ് ഘട്ടം (ഓഫ്‌ലൈൻ)

ആരെങ്കിലും ഒരു ചോദ്യം ടൈപ്പ് ചെയ്യുന്നതിന് വളരെ മുമ്പ് തന്നെ, നിങ്ങളുടെ ചിതറിക്കിടക്കുന്ന രേഖകളെ തിരയാൻ കഴിയുന്ന ഒരു നോളജ് ബേസ് (knowledge base) ആയി മാറ്റണം. നിങ്ങളുടെ RAG സിസ്റ്റം വിജയകരമാകണോ അതോ പരാജയപ്പെടണോ എന്ന് തീരുമാനിക്കുന്നത് ഈ അടിസ്ഥാന പ്രവർത്തനങ്ങളാണ്.

Document loaders ആണ് നിങ്ങളുടെ തുടക്കം. ഈ കണക്റ്ററുകൾ PDF-കൾ, Notion വർക്ക്സ്പേസുകൾ, SharePoint ഫോൾഡറുകൾ, വെബ് പേജുകൾ, ഇന്റേണൽ വിക്കികൾ എന്നിവയിൽ നിന്ന് നേരിട്ടുള്ള ടെക്സ്റ്റ് എടുക്കുന്നു. ഇവിടെയാണ് യഥാർത്ഥ വെല്ലുവിളികൾ തുടങ്ങുന്നത്. ഒരു ലോഡറിന് ഒരു വേർഡ് ഡോക്യുമെന്റിൽ നിന്ന് തെളിഞ്ഞ ടെക്സ്റ്റ് എടുക്കാൻ കഴിഞ്ഞേക്കാം, എന്നാൽ ടെക്സ്റ്റ് ലെയർ ഇല്ലാത്ത ഒരു സ്കാൻ ചെയ്ത PDF-ൽ അത് പരാജയപ്പെട്ടേക്കാം. ലോഡർ ഒരു ശൂന്യമായ സ്ട്രിംഗ് (empty string) നൽകുന്നു, നിങ്ങളുടെ ഡാറ്റാബേസിൽ ഒന്നും സേവ് ചെയ്യപ്പെടുന്നില്ല, ഒടുവിൽ ഉപയോക്താവിന് മുന്നറിയിപ്പില്ലാതെ "എനിക്കറിയില്ല" എന്ന മറുപടി ലഭിക്കുന്നു. ലോഡറുകൾ യഥാർത്ഥത്തിൽ എന്താണ് എടുത്തതെന്ന് എപ്പോഴും പരിശോധിക്കുക. ഓരോ സ്രോതസ്സിൽ നിന്നും കുറച്ച് ഡോക്യുമെന്റുകൾ എടുത്ത് പരിശോധിച്ചതിന് ശേഷം മാത്രം ഈ പ്രക്രിയയെ വിശ്വസിക്കുക.

അടുത്തത് text splitting ആണ്, ഇതിനെ ചങ്കിംഗ് (chunking) എന്നും വിളിക്കുന്നു. എൺപത് പേജുള്ള ഒരു സെക്യൂരിറ്റി പോളിസി മുഴുവനായി ഒരു പ്രോംപ്റ്റിലേക്ക് നൽകാൻ കഴിയില്ല; അത് കോൺടെക്സ്റ്റ് പരിധികളെ മറികടക്കുകയും വിവരങ്ങൾ അവ്യക്തമാക്കുകയും ചെയ്യും. പകരം, നിങ്ങൾ ഡോക്യുമെന്റുകളെ ചെറിയ ഭാഗങ്ങളായി (chunks) മുറിക്കുന്നു. ശരിയായ വലിപ്പം തിരഞ്ഞെടുക്കുക എന്നതാണ് ഇതിലെ പ്രധാന കാര്യം. ഒറ്റ വാചകങ്ങൾ പോലുള്ള വളരെ ചെറിയ ചങ്കുകൾ പലപ്പോഴും പ്രധാനപ്പെട്ട വിവരങ്ങൾ നഷ്ടപ്പെടുത്തുന്നു. "എല്ലാ അഭ്യർത്ഥനകളും മാനേജർ അംഗീകരിക്കണം" എന്ന് മാത്രം പറയുന്ന ഒരു ചങ്ക്, ഈ നിയമം അന്താരാഷ്ട്ര യാത്രകൾക്ക് മാത്രമാണ് എന്ന് പറയാൻ മറന്നുപോയേക്കാം. മുഴുവൻ അധ്യായങ്ങൾ പോലുള്ള വലിയ ചങ്കുകൾ എംബെഡിംഗിനെ (embedding) ദുർബലപ്പെടുത്തുകയും ഒരേസമയം പല വിഷയങ്ങൾ ഉൾക്കൊള്ളുന്നതിനാൽ വിവരങ്ങൾ കണ്ടെത്തുന്നത് പ്രയാസകരമാക്കുകയും ചെയ്യുന്നു. പ്രായോഗികമായി, പല ടീമുകളും 300 മുതൽ 500 ടോക്കണുകൾ വരെയുള്ള ചങ്കുകൾ ഉപയോഗിക്കുന്നു. വാചകങ്ങൾ മുറിഞ്ഞുപോകാതിരിക്കാൻ 50 ടോക്കണുകൾ ഓവർലാപ്പ് (overlap) ചെയ്യാറുണ്ട്. നിങ്ങളുടെ ഉള്ളടക്കത്തിനനുസരിച്ച് ഇത് മാറ്റം വരുത്താം. API ഡോക്യുമെന്റേഷന് ചെറിയ ചങ്കുകൾ മതിയാകും. എന്നാൽ നിയമപരമായ കരാറുകൾക്ക് (legal contracts) നിബന്ധനകൾ കൃത്യമായി നിലനിർത്താൻ വലിയ ചങ്കുകൾ ആവശ്യമായി വന്നേക്കാം.

ചങ്കിംഗ് കഴിഞ്ഞാൽ, ഓരോ ഭാഗവും ഒരു embedding ആയി മാറ്റുന്നു. അതായത്, ആ ടെക്സ്റ്റിന്റെ അർത്ഥം പ്രതിനിധീകരിക്കുന്ന സംഖ്യകളുടെ ഒരു പട്ടിക അല്ലെങ്കിൽ വെക്റ്റർ (vector) ഒരു മോഡൽ വഴി നിർമ്മിക്കുന്നു. സമാനമായ ആശയങ്ങൾ ഈ ഗണിതശാസ്ത്ര ഇടത്തിൽ (mathematical space) അടുത്തടുത്തായിരിക്കും വരുന്നത്. "401k matching policy", "retirement contribution rules" എന്നിവ തമ്മിലുള്ള അകലം "401k matching policy", "office printer setup" എന്നിവ തമ്മിലുള്ളതിനേക്കാൾ കുറവായിരിക്കും. ഈ വെക്റ്ററുകൾ Pinecone, Weaviate അല്ലെങ്കിൽ Chroma പോലുള്ള ഒരു vector database-ൽ സൂക്ഷിക്കുന്നു. വെക്റ്റർ സ്റ്റോർ എന്നത് വെറുമൊരു സംഭരണശാലയല്ല. ദശലക്ഷക്കണക്കിന് ഡോക്യുമെന്റുകളിൽ നിന്ന് പോലും ഏറ്റവും പ്രസക്തമായ വിവരങ്ങൾ മിനിറ്റുകൾക്കുള്ളിൽ കണ്ടെത്താൻ സഹായിക്കുന്ന ഒരു ഇൻഡക്സ് (index) ആണിത്.

ഘട്ടം 2: ലൈവ് പാത്ത് (ഓൺലൈൻ)

ഒരു ഉപയോക്താവ് ഒടുവിൽ, "ക്ലയന്റ് ഡിന്നറുകൾക്കായുള്ള ഞങ്ങളുടെ യാത്രാ റീഇംബേഴ്സ്‌മെന്റ് പോളിസി എന്താണ്?" എന്ന് ചോദിക്കുമ്പോൾ, ലൈവ് പൈപ്പ്‌ലൈൻ പ്രവർത്തിച്ചു തുടങ്ങുന്നു.

ആ