Most teams build their first retrieval system the same way: slice every document into fixed 512 token chunks, push them

മിക്ക ടീമുകളും അവരുടെ ആദ്യത്തെ റിട്രീവൽ സിസ്റ്റം നിർമ്മിക്കുന്നത് ഒരേ രീതിയിലാണ്: ഓരോ ഡോക്യുമെന്റും കൃത്യമായ 512-ടോക്കൺ കഷണങ്ങളായി (chunks) മുറിക്കുക, അവ ഒരു വെക്റ്റർ ഡാറ്റാബേസിലേക്ക് മാറ്റുക, പിന്നെ എംബെഡിംഗ് മോഡൽ കഠിനമായ ജോലികൾ ചെയ്യുമെന്ന് പ്രതീക്ഷിക്കുക. ആ പ്രതീക്ഷ ഒരു ഡെമോയിൽ നിങ്ങളെ വിജയിപ്പിക്കും. എന്നാൽ യഥാർത്ഥ ഉപയോക്താക്കളുടെ മുന്നിൽ അത് നിലനിൽക്കില്ല.

പ്രൊഡക്ഷനിൽ, ഒരു നിയമപരമായ കരാറിലെ ബാധ്യതയെക്കുറിച്ചുള്ള വ്യവസ്ഥയെ (liability clause) അതിന്റെ ഒഴിവാക്കലുകളിൽ (exceptions) നിന്ന് വേർപെടുത്തുമ്പോൾ അത് തകരാറിലാകുന്നു. ഒരു കോഡ് സാമ്പിൾ അതിന്റെ ഫംഗ്ഷൻ സിഗ്നേച്ചറിൽ നിന്ന് വേർപെട്ടുപോയാൽ API ഡോക്യുമെന്റേഷൻ ഉപയോഗശൂന്യമാകും. ഒരു ഉപഭോക്തൃ സഹായ സംഭാഷണത്തിന്റെ ചരിത്രത്തിൽ നിന്ന് ഒരു പരാതി മാത്രം വേർപെടുത്തുന്നത് ആ സംഭാഷണത്തെ അർത്ഥശൂന്യമാക്കും. പൈപ്പ്‌ലൈനിന്റെ അവസാനം ഇരിക്കുന്ന ലാംഗ്വേജ് മോഡലല്ല ഇവിടെ പ്രശ്നം. നിങ്ങൾ അതിന് നൽകുന്ന വിവരങ്ങളാണ് പ്രശ്നം.

ഞങ്ങൾ ഇത് കഠിനമായ അനുഭവങ്ങളിലൂടെയാണ് പഠിച്ചത്. ഞങ്ങളുടെ ആദ്യത്തെ റിട്രീവൽ ലെയർ സാധാരണ രീതിയിലുള്ളതായിരുന്നുവെങ്കിലും അത് അസ്ഥിരമായി പ്രവർത്തിച്ചു. അതിനാൽ ഞങ്ങൾ ഒരു ലളിതമായ ആശയത്തെ അടിസ്ഥാനമാക്കി അത് പുനർനിർമ്മിച്ചു: റിട്രീവലിനെ ഒരു മാന്ത്രികവിദ്യയായി കാണാതെ, കൃത്യമായി അളക്കാവുന്ന ഒരു ഇൻഫ്രാസ്ട്രക്ചറായി കാണുക. ഞങ്ങൾ എന്താണ് മാറ്റം വരുത്തിയതെന്നും, 95th-percentile ലേറ്റൻസി 850 ms-ൽ നിന്ന് 320 ms-ലേക്ക് കുറയ്ക്കുന്നതിനോടൊപ്പം റീക്കോൾ (recall) എങ്ങനെ 95 ശതമാനമായി ഉയർത്തി എന്നും താഴെ വിവരിക്കുന്നു.

ഫിക്സഡ്-ചങ്ക് കെണി

ഒരേപോലെയുള്ള ടോക്കൺ എണ്ണങ്ങൾ കോഡ് ചെയ്യാനും വിശദീകരിക്കാനും എളുപ്പമാണ്. എന്നാൽ ആ സൗകര്യം ഒരു അടിസ്ഥാന സത്യത്തെ മറച്ചുവെക്കുന്നു: ഡോക്യുമെന്റുകൾക്ക് ഒരു ഘടനയുണ്ട്. ആ ഘടനയെ നിങ്ങൾ അവഗണിക്കുമ്പോൾ, വിവരങ്ങളിലെ കൃത്യത (signal) നിങ്ങൾ നശിപ്പിക്കുന്നു.

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

ചങ്ക് സൈസിനെ (chunk size) വെറുതെ ഊഹിച്ചു നിശ്ചയിക്കുന്ന ഒരു ഹൈപ്പർപാരാമീറ്റർ ആയി കാണുന്നത് ഞങ്ങൾ നിർത്തി. പകരം, ഡോക്യുമെന്റ് തരവും അതിനുള്ളിലെ ഇൻഫർമേഷൻ ആർക്കിടെക്ചറും തമ്മിലുള്ള ഒരു മാപ്പിംഗ് വ്യായാമമായി ഞങ്ങൾ അതിനെ കാണാൻ തുടങ്ങി.

നിങ്ങളുടെ ചങ്കിംഗിനെ ഡാറ്റയ്ക്ക് അനുസൃതമാക്കുക

ഇതിനുള്ള പരിഹാരം ഒരു പ്രത്യേക ചങ്ക് സൈസ് കണ്ടെത്തലല്ല. മറിച്ച്, മൂന്ന് വ്യത്യസ്ത ഡാറ്റാ രൂപങ്ങൾക്കായി ക്രമീകരിച്ച മൂന്ന് വ്യത്യസ്ത തന്ത്രങ്ങളാണ്.

ലീഗൽ ഡോക്യുമെന്റുകൾ ഇപ്പോൾ റിക്കേഴ്സീവ് സ്പ്ലിറ്റിംഗിലൂടെ (recursive splitting) കടന്നുപോകുന്നു. അൽഗോരിതം ആദ്യം ഏറ്റവും വലിയ സ്വാഭാവിക അതിരുകൾ—സെക്ഷനുകൾ, തുടർന്ന് സബ്സെക്ഷനുകൾ, പിന്നെ നമ്പറുകൾ നൽകിയ ക്ലോസുകൾ—തിരയുന്നു, ആവശ്യമുള്ളപ്പോൾ മാത്രം ചെറിയ കഷണങ്ങളായി മുറിക്കുന്നു. ഇത് ഒരു ടെർമിനേഷൻ ക്ലോസിനെ അതിന്റെ നിലനിൽപ്പിന് ആവശ്യമായ വ്യവസ്ഥകളോടൊപ്പം നിലനിർത്തുന്നു. റിട്രീവൽ ഘട്ടത്തിൽ പൂർണ്ണമായ ലോജിക്കൽ യൂണിറ്റുകൾ ലഭിക്കുന്നതിനാൽ, വിട്ടുപോയ ഒഴിവാക്കലുകൾ (exceptions) സ്വയം സങ്കൽപ്പിക്കാനുള്ള മോഡലിന്റെ പ്രവണത ഗണ്യമായി കുറയുന്നു.

API, കോഡ് ഡോക്യുമെന്റേഷൻ എന്നിവയ്ക്ക് സ്ട്രക്ചർ-അവയർ ചങ്കിംഗ് (structure-aware chunking) നൽകുന്നു. മാർക്ക്ഡൗൺ ഹെഡറുകൾ, കോഡ് ഫെൻസുകൾ, പാരാമീറ്റർ ടേബിളുകൾ എന്നിവയെ അറ്റോമിക് യൂണിറ്റുകളായി വിശകലനം ചെയ്യുന്നു. ഞങ്ങൾ ഒരു കോഡ് ബ്ലോക്കിനുള്ളിൽ മുറിക്കാറില്ല. ഡോക്സ്ട്രിംഗുകൾ (docstrings) അവയുടെ സിഗ്നേച്ചറുകൾക്ക് അടുത്തായി തന്നെ സൂക്ഷിക്കുന്നു. ഇതിന്റെ ഫലമായി, ഒരു പ്രത്യേക ക്ലാസ് മെത്തേഡിനായുള്ള ക്വറി ചെയ്യുമ്പോൾ ഡെവലപ്പർക്ക് ആവശ്യമുള്ള പൂർണ്ണമായ വിവരങ്ങൾ—വിവരണം, ടൈപ്പ് ചെയ്ത പാരാമീറ്ററുകൾ, വർക്കിംഗ് എക്സാമ്പിൾ എന്നിവ—ലഭിക്കുന്നു.

സപ്പോർട്ട്, സംഭാഷണ ഡാറ്റകൾ സെമാന്റിക് ചങ്കിംഗ് (semantic chunking) ഉപയോഗിക്കുന്നു. ടോക്കണുകൾ എണ്ണുന്നതിന് പകരം, വിഷയം അല്ലെങ്കിൽ ഉദ്ദേശ്യം മാറുന്നുണ്ടോ എന്ന് ഞങ്ങൾ നോക്കുന്നു. ഒരു ഉപഭോക്താവ് മൂന്നാമത്തെ സന്ദേശത്തിൽ ഒരു ബഗ്ഗിനെക്കുറിച്ച് വിവരിക്കുകയും ഏഴാമത്തെ സന്ദേശത്തിൽ ഒരു സ്റ്റാക്ക് ട്രാസ് (stack trace) നൽകുകയും ചെയ്താൽ, ഞങ്ങൾ സന്ദേശത്തിന്റെ ഇൻഡക്സിന് പകരം അർത്ഥം അനുസരിച്ചാണ് ചങ്കുകൾ തിരിക്കുന്നത്. അങ്ങനെ റിട്രീവൽ ലെയർ ഒരു ഒറ്റപ്പെട്ട വാചകത്തിന് പകരം പ്രശ്നത്തിന്റെ പൂർണ്ണരൂപം നൽകുന്നു.

എന്തുകൊണ്ട് വെക്റ്റർ സെർച്ച് മാത്രം പരാജയപ്പെടുന്നു

കൃത്യമായ ചങ്കുകൾ ഉണ്ടെങ്കിൽ പോലും വെറും വെക്റ്റർ സെർച്ചിൽ അവ പരാജയപ്പെട്ടേക്കാം. ഡെൻസ് എംബെഡിംഗുകൾക്ക് (Dense embeddings) അർത്ഥവും പര്യായപദങ്ങളും പിടിച്ചെടുക്കാൻ മികച്ച കഴിവുണ്ട്, എന്നാൽ കൃത്യമായ സ്ട്രിംഗുകളുടെ (exact strings) കാര്യത്തിൽ അവയ്ക്ക് അത്ര കൃത്യതയില്ല. ഒരു എഞ്ചിനീയർ ERR_CONNECTION_REFUSED എന്ന കൃത്യമായ എറർ കോഡ് തിരയുകയാണെങ്കിൽ, വെക്റ്റർ സിമിലാരിറ്റി പന്ത്രണ്ടോളം സമാനമായ ആശയങ്ങൾ നൽകിയേക്കാം, എന്നാൽ പതിനാലാമത്തെ റാങ്കിൽ ഇരിക്കുന്ന കൃത്യമായ പൊരുത്തം അവരിലുണ്ടായേക്കാം.

BM25 ഉപയോഗിച്ചുള്ള കീവേഡ് സെർച്ചിന് നേരെ വിപരീതമായ പ്രശ്നമാണുള്ളത്. അത് കൃത്യമായ ടോക്കണുകൾ കണ്ടെത്തും, പക്ഷേ അർത്ഥം (semantic intent) മനസ്സിലാക്കില്ല. "എന്തുകൊണ്ടാണ് എന്റെ ഡാറ്റാബേസ് പ്രവർത്തനരഹിതമാകുന്നത്" എന്ന് ചോദിക്കുന്ന ഒരു ഉപയോക്താവിന് "കണക്ഷൻ ടൈമൗട്ടുകൾ പരിഹരിക്കൽ" (troubleshooting connection timeouts) എന്ന് പറയുന്ന ഒരു ഡോക്യുമെന്റുമായി ഒരിക്കലും പൊരുത്തപ്പെടാൻ കഴിയില്ല.

ഞങ്ങൾ ഇപ്പോൾ ഇവ രണ്ടും ഉപയോഗിക്കുന്നു. വെക്റ്റർ, കീവേഡ് ഫലങ്ങൾ Reciprocal Rank Fusion-ലേക്ക് നൽകുന്നു, ഇത് സ്കോറുകൾ ക്രമീകരിക്കാതെ തന്നെ രണ്ട് റാങ്ക് ലിസ്റ്റുകളെയും കൂട്ടിച്ചേർക്കുന്നു. ഈ ലിസ്റ്റ് പിന്നീട് ഒരു ക്രോസ്-എൻകോഡർ റീറാംക്കറിലൂടെ (cross-encoder reranker) കടത്തിവിടുന്നു. റീറാംക്കർ ആദ്യത്തെ റിട്രീവലിനേക്കാൾ സാവധാനമേ പ്രവർത്തിക്കൂ, പക്ഷേ അത് കൂടുതൽ കൃത്യമാണ്. കാരണം അത് കംപ്രസ് ചെയ്ത എംബെഡിംഗുകളിലൂടെയല്ല, മറിച്ച് ക്വറിയും ഡോക്യുമെന്റും തമ്മിലുള്ള പ്രസക്തി നേരിട്ട് വിലയിരുത്തുന്നു. ഈ ഹൈബ്രിഡ് പൈപ്പ്‌ലൈൻ മാത്രം ഞങ്ങളുടെ റീക്കോൾ 15 ശതമാനം വർദ്ധിപ്പിച്ചു.

മോശം ക്വറികൾ ഇൻഡക്സിലെത്തുന്നതിന് മുമ്പ് പരിഹരിക്കുക

ഉപയോക്താക്കൾ എപ്പോഴും കൃത്യമായ സെർച്ച് ക്വറികൾ (search queries) എഴുതാറില്ല. അവർ അപൂർണ്ണമായ ലോഗ് ലൈനുകൾ (log lines) പേസ്റ്റ് ചെയ്യുകയോ, “ഇത് പ്രവർത്തിക്കുന്നില്ല” എന്ന് ടൈപ്പ് ചെയ്യുകയോ ചെയ്തേക്കാം. നിങ്ങളുടെ ഡോക്യുമെന്റേഷനിൽ ഇല്ലാത്ത സാങ്കേതിക പദങ്ങൾ (jargon) അവർ ഉപയോഗിച്ചേക്കാം. നിങ്ങൾ നേരിട്ടുള്ള ക്വറികളെ മാത്രം വിശ്വസിക്കുന്നുണ്ടെങ്കിൽ, നിങ്ങൾ വെറും നോയിസിനെയാണ് (noise) വിശ്വസിക്കുന്നത്.

ഇപ്പോൾ ഞങ്ങൾ ഓരോ ഇൻകമിംഗ് ക്വറിയെയും റിട്രീവൽ ലെയറിലേക്ക് (retrieval layer) അയക്കുന്നതിന് മുമ്പ് മൂന്ന് മുതൽ അഞ്ച് വകഭേദങ്ങളിലേക്ക് (variations) വികസിപ്പിക്കുന്നു. ഒരു വകഭേദം നേരിട്ടുള്ള പാരഫ്രേസിംഗ് (paraphrase) ആകാം. മറ്റൊന്ന് ഒരു സാങ്കൽപ്പികമായ ആദർശ ഡോക്യുമെന്റ് ടൈറ്റിൽ ആകാം. മൂന്നാമത്തേത് സംഭാഷണപരമായ അനാവശ്യ വാക്കുകൾ ഒഴിവാക്കി സാങ്കേതിക കീവേഡുകൾ മാത്രം വേർതിരിച്ചെടുക്കുന്നതാകാം. ഓരോ വകഭേദവും എംബെഡ് (embed) ചെയ്യുകയും സെർച്ച് ചെയ്യുകയും ചെയ്യുന്നു. തുടർന്ന് ഞങ്ങൾ അവ ഡ്യൂപ്ലിക്കേറ്റുകൾ ഒഴിവാക്കി (deduplicate) സംയോജിപ്പിക്കുന്നു.

ഇത് സൗജന്യമല്ല. ഈ അധിക എംബെഡിംഗ് കോളുകൾക്ക് പണച്ചെലവും ഏതാനും മില്ലിസെക്കൻഡുകളുടെ കാലതാമസവും ഉണ്ടാകും. എന്നാൽ റിപ്പോൾ (recall) നിരക്കിൽ വലിയ മാറ്റമുണ്ടായി: ക്വറികൾ വികസിപ്പിച്ചെടുത്തതിലൂടെ ഞങ്ങൾ 78 ശതമാനത്തിൽ നിന്ന് 96 ശതമാനത്തിലേക്ക് ഉയർന്നു. മികച്ച റിട്രീവൽ ജനറേഷൻ വിൻഡോയെ (generation window) കുറയ്ക്കുകയും മോഡലിന് ശരിയായ കോൺടെക്സ്റ്റ് (context) നൽകുകയും ചെയ്യുന്നതിനാൽ, പിൽക്കാല ഘട്ടങ്ങളിൽ പണം ലാഭിക്കാൻ ഞങ്ങൾക്ക് സാധിച്ചു. ഒരു ചെറിയ ചെലവുള്ള റിട്രീവൽ ഘട്ടം, തെറ്റായ വിവരങ്ങൾ നൽകുന്ന (hallucinated) നീണ്ട ജനറേഷൻ ഘട്ടത്തേക്കാൾ ലാഭകരമാണ്.

ഊഹിക്കുന്നത് നിർത്തൂ. സെർച്ച് ചെയ്യാൻ തുടങ്ങൂ.

ശരിയായ ചങ്കിംഗ് (chunking), ഹൈബ്രിഡ് റിട്രീവൽ (hybrid retrieval), ക്വറി എക്സ്പാൻഷൻ (query expansion) എന്നിവ നടപ്പിലാക്കിയ ശേഷവും ഞങ്ങൾ ഒരു സങ്കീർണ്ണമായ പ്രശ്നം നേരിട്ടിരുന്നു. ചങ്ക് സൈസ് (chunk size), ചങ്ക് ഓവർലാപ്പ് (chunk overlap), top-k റിട്രീവൽ ഡെപ്ത്ത് (retrieval depth), റീറാംക്കർ കട്ട്ഓഫുകൾ (reranker cutoffs), ഫ്യൂഷൻ വെയ്റ്റുകൾ (fusion weights) എന്നിവയെല്ലാം പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു. ഒരു മാനുവൽ ഗ്രിഡ് സെർച്ച് (manual grid search) ആഴ്ചകൾ എടുക്കുമായിരുന്നു, എന്നിട്ടും അത് മികച്ച ഫലം നൽകണമെന്നില്ല.

ഈ പ്രശ്നം പരിഹരിക്കാൻ ഞങ്ങൾ ബേസിയൻ ഒപ്റ്റിമൈസേഷനിലേക്ക് (Bayesian optimization) മാറി. എല്ലാ കോമ്പിനേഷനുകളും പരീക്ഷിച്ച് നോക്കുന്നതിന് പകരം, ഏത് കോൺഫിഗറേഷനുകളാണ് മികച്ച പ്രകടനം കാഴ്ചവെക്കുക എന്നതിനെക്കുറിച്ച് ഒരു ധാരണ നിലനിർത്തിക്കൊണ്ട്, സെർച്ച് അൽഗോരിതം കൂടുതൽ സാധ്യതയുള്ള മേഖലകളിലേക്ക് ക്രമമായി നീങ്ങുന്നു.

ഇതിന്റെ ഫലം ഒരു മികച്ച സെറ്റിംഗ് മാത്രമല്ല, മറിച്ച് തിരഞ്ഞെടുപ്പുകളുടെ ഒരു പാറെറ്റോ ഫ്രോണ്ടിയർ (Pareto frontier) ആണ്. ഒരു വശത്ത്, ഞങ്ങളുടെ ഹൈ-ത്രൂപുട്ട് API സപ്പോർട്ട് എൻഡ്പോയിന്റിനായി ഒപ്റ്റിമൈസ് ചെയ്ത ലീൻ കോൺഫിഗറേഷൻ (lean configuration) ഉണ്ട്: വേഗതയേറിയ ഇൻഫറൻസ്, മിതമായ റിപ്പോൾ, കുറഞ്ഞ ലേറ്റൻസി (latency). മറുവശത്ത്, ലീഗൽ റിവ്യൂവിനായി കൂടുതൽ കൃത്യത നൽകുന്ന അഗ്രസീവ് കോൺഫിഗറേഷൻ ഉണ്ട്: ആഴത്തിലുള്ള റിട്രീവൽ, കൂടുതൽ റീറാംക്കിംഗ്, കൂടുതൽ ഓവർലാപ്പ് എന്നിവയിലൂടെ വേഗത കുറച്ച് കൃത്യത വർദ്ധിപ്പിക്കുന്നു. ഈ ഫ്രോണ്ടിയർ വ്യക്തമായതിനാൽ, എല്ലാത്തിനും ഒരേ രീതി ഉപയോഗിക്കുന്നതിന് പകരം ഉൽപ്പന്നത്തിന് അനുയോജ്യമായത് തിരഞ്ഞെടുക്കാൻ ഞങ്ങൾക്ക് സാധിക്കുന്നു.

യഥാർത്ഥ കണക്കുകൾ എങ്ങനെയിരിക്കുന്നു

ഈ മാറ്റങ്ങൾ സിസ്റ്റത്തെ ഒരു പരീക്ഷണാടിസ്ഥാനത്തിലുള്ള പ്രോട്ടോടൈപ്പിൽ നിന്ന് കൃത്യമായ അളവുകോലുകളുള്ള ഒരു പ്രൊഡക്ഷൻ പൈപ്പ്‌ലൈനിലേക്ക് മാറ്റി.

Recall at ten 78 ശതമാനത്തിൽ നിന്ന് 95 ശതമാനമായി ഉയർന്നു. അതായത്, ശരിയായ ഉത്തരം ഞങ്ങളുടെ കോർപ്പസിലുണ്ടെങ്കിൽ, ഇരുപതിൽ പത്തൊൻപത് തവണയും ഞങ്ങൾക്ക് അത് കണ്ടെത്താൻ സാധിക്കുന്നു.

95th percentile-ലെ ലേറ്റൻസി 850 ms-ൽ നിന്ന് 320 ms ആയി കുറഞ്ഞു. ഹൈബ്രിഡ് സ്റ്റാക്ക് കാണുമ്പോൾ കൂടുതൽ സങ്കീർണ്ണമായി തോന്നാമെങ്കിലും, സ്മാർട്ട് ഇൻഡക്സിംഗ്, ചെറിയ റീറാംക്കറുകൾ, ആവശ്യമുള്ളപ്പോൾ മാത്രം കൂടുതൽ വിവരങ്ങൾ നൽകാനുള്ള കഴിവ് എന്നിവ സിസ്റ്റത്തെ വേഗതയുള്ളതാക്കി.

ഹാലൂസിനേഷൻ നിരക്ക് (Hallucination rate)—ഹോൾഡ്-ഔട്ട് ഗോൾഡൻ ഡാറ്റാസെറ്റിൽ (held-out golden dataset) മനുഷ്യർ പരിശോധിച്ചത്—12 ശതമാനത്തിൽ നിന്ന് 3 ശതമാനമായി കുറഞ്ഞു. മോഡലിന് പൂർണ്ണവും പ്രസക്തവുമായ കോൺടെക്സ്റ്റ് ലഭിക്കുമ്പോൾ, അത് തെറ്റായ വിവരങ്ങൾ നിർമ്മിക്കുന്നത് നിർത്തുന്നു.

ക്വറി દીന്നുള്ള ചെലവ് $0.008-ൽ നിന്ന് $0.005 ആയി കുറഞ്ഞു. മികച്ച റിട്രീവൽ എന്നാൽ കുറഞ്ഞതും കൃത്യവുമായ LLM പ്രോംപ്റ്റുകൾ എന്നാണ് അർത്ഥം. ക്വറി എക്സ്പാൻഷനായി ഉപയോഗിക്കുന്ന അധിക എംബെഡിംഗ് ചെലവിനേക്കാൾ വലിയ ലാഭം ജനറേഷൻ ഘട്ടത്തിൽ ലഭിക്കുന്നു.

ഒരു ഗോൾഡൻ ഡാറ്റാസെറ്റ് നിർമ്മിക്കുക, റിട്രീവലിനെ ഒരു കോഡ് പോലെ കൈകാര്യം ചെയ്യുക

ഇതിൽ നിന്ന് നിങ്ങൾ പഠിക്കേണ്ട ഒരു കാര്യം അളവുകോലുകൾ ഉപയോഗിക്കാനുള്ള അച്ചടക്കമാണ്. യഥാർത്ഥ ചോദ്യങ്ങളും ശരിയായ ഉത്തരങ്ങളും ഉപയോഗിച്ച് ഞങ്ങൾ ഒരു ചെറിയ ഗോൾഡൻ ഡാറ്റാസെറ്റ് നിർമ്മിച്ചു. ഏതൊരു മാറ്റവും പ്രൊഡക്ഷനിൽ നടപ്പിലാക്കുന്നതിന് മുമ്പ് അത് ഈ ഡാറ്റാസെറ്റിലൂടെ പരിശോധിക്കുന്നു. റിപ്പോൾ, ലേറ്റൻസി എന്നിവ റിയൽ ടൈമിൽ നിരീക്ഷിക്കപ്പെടുന്നു.

റിട്രീവൽ എന്നത് വെറുമൊരു റിസർച്ച് ഡെമോ അല്ല, അതൊരു ഇൻഫ്രാസ്ട്രക്ചർ ആണ്. നിങ്ങളുടെ ബാക്കി സ്റ്റാക്കിനെപ്പോലെ തന്നെ ഇതിനും യൂണിറ്റ് ടെസ്റ്റുകളും (unit tests), റഗ്രഷൻ ബെഞ്ച്മാർക്കുകളും (regression benchmarks), ഓട്ടോമേറ്റഡ് ഒപ്റ്റിമൈസേഷനും ആവശ്യമാണ്. ഡോക്യുമെന്റ് ഘടന അനുസരിച്ച് ചങ്കിംഗ് ചെയ്യുക. വെക്റ്റർ സെർച്ചും കീവേഡ് സെർച്ചും ഒരു റീറാംക്കർ ഉപയോഗിച്ച് സംയോജിപ്പിക്കുക. ഉപയോക്താക്കൾ എഴുതുന്ന ക്വറികൾ വികസിപ്പിക്കുക. തുടർന്ന് നിങ്ങളുടെ ഉൾക്കാഴ്ചയ്ക്ക് പകരം ഒരു സെർച്ച് അൽഗോരിതം ഉപയോഗിച്ച് അത് ക്രമീകരിക്കുക.

ഞങ്ങൾ വിവരിച്ച ഈ പൈപ്പ്‌ലൈൻ വെറും സിദ്ധാന്തമല്ല. നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ ഇവിടെ വായിക്കാം, റിട്രീവൽ എൻജിനീയറിംഗിനെക്കുറിച്ച് ചർച്ച ചെയ്യാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ, GyaanSetu AI group നിങ്ങൾക്ക് ഉപയോഗിക്കാം.