മിക്ക ടീമുകളും അവരുടെ ആദ്യത്തെ റിട്രീവൽ പൈപ്പ്ലൈൻ നിർമ്മിക്കുന്നത് ഇതേ രീതിയിലാണ്. അവർ ഒരു നിശ്ചിത ടോക്കൺ പരിധി (ഒരുപക്ഷേ 512) തിരഞ്ഞെടുക്കുന്നു, ഡോക്യുമെന്റുകളെ ഒരേ വലുപ്പമുള്ള ബ്ലോക്കുകളായി വിഭജിക്കുന്നു, എന്നിട്ട് ആ ബ്ലോക്കുകൾ ഒരു വെക്റ്റർ ഡാറ്റാബേസിലേക്ക് നൽകുന്നു. ലളിതമായ ചോദ്യങ്ങളുള്ള ചെറിയ ഡാറ്റാസെറ്റുകളിൽ ഇത് അത്ഭുതകരമായി തോന്നാം. എന്നാൽ പ്രൊഡക്ഷനിൽ ഇത് പരാജയപ്പെടുന്നു.
ഒരു വാചകത്തിന്റെ ഇടയിൽ വെച്ച് ഒരു ക്ലോസ് (clause) മുറിഞ്ഞുപോയാൽ നിയമപരമായ കരാറുകൾ അർത്ഥശൂന്യമായ കഷണങ്ങളായി മാറുന്നു. ഒരു സിംഗിൾ ചങ്ക് (chunk) മൂന്ന് ബന്ധമില്ലാത്ത ഫംഗ്ഷനുകളെ ഉൾക്കൊള്ളുന്നുവെങ്കിൽ API ഡോക്യുമെന്റേഷൻ ആശയക്കുഴപ്പമുണ്ടാക്കുന്ന ഒന്നായി മാറുന്നു. സെഗ്മെന്റുകൾക്കിടയിൽ ഓവർലാപ്പ് ഇല്ലാതെയാണെങ്കിൽ കസ്റ്റമർ സപ്പോർട്ട് ടിക്കറ്റുകൾക്ക് അവയുടെ സ്വാഭാവികമായ ഒഴുക്ക് നഷ്ടപ്പെടുന്നു. ഇതിന്റെ ഫലം പ്രവചിക്കാവുന്നതാണ്: ഉയർന്ന ലേറ്റൻസി (latency), കുറഞ്ഞ റീക്കോൾ (recall), കൂടാതെ ജനറേറ്ററിനെ ഹാളുസിനേഷൻ (hallucinate) ചെയ്യാൻ പ്രേരിപ്പിക്കുന്ന ഉത്തരങ്ങൾ എന്നിവ.
ഞങ്ങൾ ഞങ്ങളുടെ റിട്രീവൽ ലെയർ പൂർണ്ണമായും മാറ്റി നിർമ്മിച്ചു. അതിന്റെ ഫലമായി റീക്കോൾ 78 ശതമാനത്തിൽ നിന്ന് 95 ശതമാനമായി ഉയർന്നു, ലേറ്റൻസിയിൽ 62 ശതമാനം കുറവുണ്ടായി, കൂടാതെ ഒരു വെക്കൻഡ് ഹാക്ക് (weekend hack) പോലെയില്ലാതെ യഥാർത്ഥ ഇൻഫ്രാസ്ട്രക്ചർ പോലെ പ്രവർത്തിക്കുന്ന ഒരു പൈപ്പ്ലൈൻ ലഭിച്ചു. യഥാർത്ഥത്തിൽ എന്താണ് ഫലപ്രദമായി പ്രവർത്തിച്ചതെന്ന് താഴെ നൽകുന്നു.
സ്മാർട്ട് ചങ്കിംഗ്: ടോക്കണുകളേക്കാൾ ഘടനയ്ക്ക് മുൻഗണന
എല്ലാ ഡോക്യുമെന്റുകളും ഒരേ രീതിയിലാണെന്ന് കരുതുന്നതാണ് ആദ്യത്തെ തെറ്റ്. വിവരണാത്മകമായ ഗദ്യങ്ങൾക്ക് (narrative prose) 512-ടോക്കൺ ചങ്ക് അനുയോജ്യമാണ്, എന്നാൽ മറ്റൊരിടത്തും അത് ശരിയാകണമെന്നില്ല. ഞങ്ങൾ സ്രോതസ്സിന്റെ ഘടനയെ (anatomy) മാനിക്കുന്ന ഒരു തന്ത്രത്തിലേക്ക് മാറി.
നിയമപരമായ രേഖകൾക്കായി ഞങ്ങൾ റിക്കേഴ്സീവ് ചങ്കിംഗ് (recursive chunking) ഉപയോഗിക്കുന്നു. അൽഗോരിതം ആദ്യം സെക്ഷനുകൾ, ആർട്ടിക്കിളുകൾ തുടങ്ങിയ ഉയർന്ന തലത്തിലുള്ള അതിർവരമ്പുകൾ ഉപയോഗിച്ച് വിഭജിക്കാൻ ശ്രമിക്കുന്നു. ഒരു സെക്ഷൻ ഇനിയും വലുതാണെങ്കിൽ, അത് സബ്സെക്ഷനുകൾ, തുടർന്ന് പാരഗ്രാഫുകൾ, പിന്നെ വാചകങ്ങൾ എന്നിവ തിരയുന്നു. ഇത് ക്ലോസുകളുടെ ലോജിക്കൽ ക്രമം നിലനിർത്തുന്നു. ഒരു നോൺ-കോമ്പീറ്റ് അഗ്രിമെന്റ് (non-compete agreement) അതിന്റെ പൂർണ്ണതയിൽ തന്നെ നിലനിൽക്കുന്നു. നിർവചനങ്ങൾ ഇൻഡെംനിറ്റി നിബന്ധനകളിലേക്ക് (indemnity terms) കലരുന്നില്ല.
API ഡോക്യുമെന്റേഷന് സ്ട്രക്ചർ-അവയർ ചങ്കിംഗ് (structure-aware chunking) ആവശ്യമാണ്. ഒരു ഫംഗ്ഷൻ സിഗ്നേച്ചർ, അതിന്റെ പാരാമീറ്റർ ടേബിൾ, അതിന്റെ എക്സാമ്പിൾ റിക്വസ്റ്റ് എന്നിവ ഒരുമിച്ച് ആയിരിക്കണം. ഒരു നിശ്ചിത ടോക്കൺ എണ്ണത്തിന് ശേഷം വിഭജിക്കുന്നത് പലപ്പോഴും പാരാമീറ്ററുകളെ ഒരു ചങ്കിലും ഉദാഹരണങ്ങളെ മറ്റൊരു ചങ്കിലും എത്തിക്കുന്നു. പകരം ഞങ്ങൾ ഡോക്യുമെന്റ് ഒബ്ജക്റ്റ് അനുസരിച്ച് ചങ്കിംഗ് ചെയ്യുന്നു. ഒരു ചങ്കിൽ ഒരു പൂർണ്ണമായ എൻഡ്പോയിന്റോ (endpoint) അല്ലെങ്കിൽ ഒരു ഫംഗ്ഷനോ ഉൾപ്പെടുന്നു. അപ്പോൾ റിട്രീവറിന് ചോദ്യത്തിന് കൃത്യമായ ഉത്തരം നൽകുന്ന സ്വയം പൂർണ്ണമായ ഒരു റഫറൻസ് നൽകാൻ കഴിയും.
സപ്പോർട്ട് ടിക്കറ്റുകൾക്ക് സെമാന്റിക് ചങ്കിംഗ് (semantic chunking) സ്വാഭാവികമായും അനുയോജ്യമാണ്. ഒരു ടോക്കൺ അതിർവരമ്പിൽ വെച്ച് മുറിക്കുന്നതിന് പകരം, വിഷയം മാറുന്നത് എവിടെയാണെന്ന് ഞങ്ങൾ കണ്ടെത്തുന്നു. ലോഗിൻ പരാതിയിൽ തുടങ്ങി ബില്ലിംഗ് ചോദ്യത്തിലേക്ക് മാറുന്ന ഒരു ടിക്കറ്റ് രണ്ട് വ്യക്തമായ ഭാഗങ്ങളായി വിഭജിക്കപ്പെടുന്നു. ഓരോ ഭാഗത്തിനും ആവശ്യമായ മെറ്റാഡാറ്റ (metadata) ലഭിക്കുന്നു, അതിനാൽ ഉപയോക്താവ് യഥാർത്ഥത്തിൽ ഏത് പ്രശ്നത്തെക്കുറിച്ചാണ് സംസാരിക്കുന്നത് എന്ന് മോഡൽ ഊഹിക്കേണ്ടി വരുന്നില്ല.
ഇന്റേണൽ വിക്കികൾ (Internal wikis) കൂടുതൽ സങ്കീർണ്ണമാണ്. അവയിൽ ഗദ്യം, പട്ടികകൾ, ഡയഗ്രമുകൾ, എംബെഡഡ് ത്രെഡുകൾ എന്നിവ കലർന്നിരിക്കുന്നു. ഇവയ്ക്കായി ഞങ്ങൾ ഏജൻറ്റിക് ചങ്കിംഗ് (agentic chunking) ഉപയോഗിക്കുന്നു. ഒരു ചെറിയ ലാംഗ്വേജ് മോഡൽ മുൻകൂട്ടി വായിക്കുകയും ഒരു തീമാറ്റിക് യൂണിറ്റ് എവിടെ അവസാനിക്കുന്നു എന്ന് തീരുമാനിക്കുകയും ചെയ്യുന്നു. ഡാറ്റ ഇൻജസ്റ്റാക്കുമ്പോൾ (ingestion time) ഇതിന് അല്പം കൂടുതൽ ചിലവ് വരുന്നുണ്ടെങ്കിലും, ഓരോ പുതിയ പേജ് ഫോർമാറ്റിനും നിയമങ്ങൾ കൈകൊണ്ട് ക്രമീകരിക്കേണ്ടി വരുന്ന ജോലി ഇത് ഒഴിവാക്കുന്നു.
ഹൈബ്രിഡ് റിട്രീവൽ: എല്ലാ വശങ്ങളും പരിഗണിക്കുക
അവ്യക്തമായ അർത്ഥങ്ങൾ (fuzzy meaning) പിടിച്ചെടുക്കുന്നതിൽ വെക്റ്റർ സെർച്ച് (Vector search) മികച്ചതാണ്. അപ്ലോഡ് വേഗത കുറവിനെക്കുറിച്ച് ചോദിച്ചാൽ ലേറ്റൻസിയെയും ബാൻഡ്വിഡ് deനെക്കുറിച്ചുമുള്ള പാരഗ്രാഫുകൾ അത് സന്തോഷത്തോടെ നൽകും. എന്നാൽ കൃത്യമായ പദങ്ങൾ (exact matches) കണ്ടെത്തുന്നതിൽ ഇത് പരാജയപ്പെടാറുണ്ട്. ഒരു ഡെവലപ്പർ ERR_CONNECTION_REFUSED എന്ന എറർ കോഡിനായി തിരയുകയാണെങ്കിൽ, ഡെൻസ് എംബെഡിംഗുകൾ (dense embeddings) പലപ്പോഴും അതിനെ വെറുമൊരു നോയിസ് ആയിട്ടേ കണക്കാക്കൂ.
ക്ലാസിക് കീവേഡ് അൽഗോരിതമായ BM25 ഇതിന് വിപരീതമായി പ്രവർത്തിക്കുന്നു. ഇത് കൃത്യമായ സ്ട്രിംഗുകളും അപൂർവ്വ പദങ്ങളും കണ്ടെത്തുന്നുണ്ടെങ്കിലും, സെമാന്റിക് സൂക്ഷ്മതകൾ (semantic nuance) ഇതിന് നഷ്ടമാകുന്നു. കരാറിൽ ഒപ്പിടുന്നതിനെക്കുറിച്ചുള്ള ഒരു ചോദ്യം, executing the contract എന്ന് ടാഗ് ചെയ്ത ഉള്ളടക്കം കണ്ടെത്താൻ കഴിഞ്ഞെന്നു വരില്ല.