നിങ്ങളുടെ RAG പൈപ്പ്ലൈൻ ഒരു സാധാരണ ലോഡ് ടെസ്റ്റിൽ മികച്ച വിജയം നേടുന്നുണ്ടാകാം. p95 ലേറ്റൻസി (latency) ആരോഗ്യകരമായ നിലയിലാണ്. എറർ റേറ്റുകൾ പൂജ്യത്തിന് അടുത്താണ്. എന്നിരുന്നാലും, ഉപയോക്താക്കൾ റിപ്പോർട്ട് ചെയ്യുന്നത് ചോദ്യങ്ങളെ ഒഴിവാക്കുന്നതോ, നിലവിലില്ലാത്ത രേഖകൾ ഉദ്ധരിക്കുന്നതോ, അല്ലെങ്കിൽ ആറ് മാസം മുമ്പ് അപ്ലോഡ് ചെയ്ത ഒരു വൈറ്റ് പേപ്പറിൽ നിന്നുള്ള പ്രസക്തമല്ലാത്ത ഖണ്ഡികകൾ പുറത്തെടുക്കുന്നതോ ആയ മറുപടികളാണ്. ഡാഷ്ബോർഡ് എല്ലാം ശരിയാണെന്ന് പറയുന്നു. എന്നാൽ യഥാർത്ഥ അനുഭവം അത് തകരാറിലാണെന്ന് പറയുന്നു.
ഈ വ്യത്യാസം നിലനിൽക്കുന്നത് പരമ്പരാഗത പെർഫോമൻസ് ടെസ്റ്റിംഗ് നിർമ്മിച്ചിരിക്കുന്നത് റിക്വസ്റ്റ്-റെസ്പോൺസ് (request-response) സിസ്റ്റങ്ങൾക്കായിട്ടായതുകൊണ്ടാണ്, ചിന്തിക്കുന്ന സിസ്റ്റങ്ങൾക്കായിട്ടല്ല. ഒരു REST എൻഡ്പോയിന്റിലേക്ക് ആയിരം സമാന്തര റിക്വസ്റ്റുകൾ അയക്കുമ്പോൾ, നിങ്ങളുടെ സെർവറുകൾ നിലനിൽക്കുന്നുണ്ടോ എന്ന് നിങ്ങൾക്ക് മനസ്സിലാകും. എന്നാൽ നിങ്ങളുടെ റിട്രീവൽ ലെയർ (retrieval layer) ശരിയായ ഭാഗങ്ങൾ (chunks) എടുക്കുന്നുണ്ടോ, നിങ്ങളുടെ പ്രോംപ്റ്റ് ടെംപ്ലേറ്റ് (prompt template) കോൺടെക്സ്റ്റ് നിലനിർത്തുന്നുണ്ടോ, അല്ലെങ്കിൽ വെക്റ്റർ സ്റ്റോർ കാലിയാകുമ്പോൾ മോഡൽ സ്രോതസ്സുകൾ കെട്ടിച്ചമയ്ക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് ഒന്നും അറിയാൻ കഴിയില്ല. സാധാരണ ലോഡ് ടെസ്റ്റിംഗ് വേഗത അളക്കുന്നു. എന്നാൽ RAG ആപ്ലിക്കേഷനുകൾ നിങ്ങൾ മനസ്സിലാക്കൽ (understanding) അളക്കണമെന്ന് ആവശ്യപ്പെടുന്നു.
സ്റ്റാറ്റസ് കോഡ് 200-ന് അപ്പുറം
ഒരു സാധാരണ API ലോഡ് ടെസ്റ്റ് മൂന്ന് കാര്യങ്ങളാണ് പരിശോധിക്കുന്നത്: ലഭ്യത (availability), ലേറ്റൻസി (latency), ത്രൂപുട്ട് (throughput). സെർവർ മറുപടി നൽകിയോ, അതിന് എത്ര സമയമെടുത്തു, എത്ര സമാന്തര ഉപയോക്താക്കളെ അതിന് താങ്ങാൻ കഴിഞ്ഞു എന്നിവയാണ് ഇത് ചോദിക്കുന്നത്. ഒരു RAG ആപ്ലിക്കേഷനെ സംബന്ധിച്ചിടത്തോളം, ഈ സംഖ്യകൾ മുൻകൂർ ആവശ്യകതകൾ മാത്രമാണ്, അവ നിഗമനങ്ങളല്ല. വേഗതയേറിയ ഒരു തെറ്റായ ഉത്തരം ഇപ്പോഴും തെറ്റായ ഉത്തരമാണ്, കൂടാതെ വലിയ തോതിലുള്ള തെറ്റായ ഉത്തരങ്ങൾ സാവധാനത്തിലുള്ളവയേക്കാൾ കൂടുതൽ ചിലവേറിയതാണ്.
ഓരോ റിക്വസ്റ്റിലും RAG രണ്ട് വ്യത്യസ്ത ഘട്ടങ്ങൾ കൂട്ടിച്ചേർക്കുന്നു. ഒന്നാമതായി, സിസ്റ്റം ഒരു ഉപയോക്താവിന്റെ ചോദ്യത്തെ ഒരു എംബെഡിംഗinto (embedding) മാറ്റുന്നു, ഒരു വെക്റ്റർ സ്റ്റോർ ക്വറി ചെയ്യുന്നു, കൂടാതെ കോൺടെക്സ്റ്റ് ചങ്ക്സുകളുടെ (context chunks) ഒരു കൂട്ടം തിരികെ എടുക്കുന്നു. രണ്ടാമതായി, ആ ചങ്ക്സുകൾ ഒരു പ്രോംപ്റ്റിലേക്ക് നിറയ്ക്കുന്നു, എല്ലാം ഒരു ലാംഗ്വേജ് മോഡലിലേക്ക് (language model) അയക്കുന്നു, കൂടാതെ ഒരു പൂർത്തീകരണം (completion) സ്ട്രീം ചെയ്യുന്നു. പരമ്പരാഗത ടെസ്റ്റുകൾ പലപ്പോഴും ഇവയെ ഒരു ഒറ്റ "റെസ്പോൺസ് ടൈം" (response time) മെട്രിക് ആയി കാണുന്നു. അവ റിട്രീവൽ എൻജിനെയും ജനറേറ്ററെയും ഒരൊറ്റ ബ്ലാക്ക് ബോക്സ് ആയി പരിഗണിക്കുന്നു.
നിങ്ങൾക്ക് ആ ബോക്സ് തുറക്കേണ്ടതുണ്ട്. ലോഡിന് കീഴിൽ നിങ്ങളുടെ വെക്റ്റർ ഡാറ്റാബേസ് പതുക്കെയായാൽ, റിട്രീവൽ ലേറ്റൻസി വർദ്ധിക്കുന്നു. LLM വേഗത്തിൽ പ്രതികരിച്ചേക്കാം, പക്ഷേ അത് തിടുക്കത്തിൽ ശേഖരിച്ച തെറ്റായ കോൺടെക്സ്റ്റിനെ അടിസ്ഥാനമാക്കിയായിരിക്കും പ്രതികരിക്കുന്നത്. പകരമായി, വെക്റ്റർ സെർച്ച് വേഗത്തിൽ നടക്കുമ്പോൾ LLM ക്യൂ നിറയുകയും, ഉപയോക്താക്കൾ തിളങ്ങുന്ന കർസറിലേക്ക് നോക്കി നിൽക്കുന്നത് വരെ time-to-first-token വർദ്ധിക്കുകയും ചെയ്യുന്നു. ഒരു സിംഗിൾ എൻഡ്-ടു-എൻഡ് ടൈമർ ഈ രണ്ട് പരാജയങ്ങളെയും മറച്ചുവെക്കുന്നു.
ഡാറ്റാബേസ് മാത്രമല്ല, റിട്രീവലും പരിശോധിക്കുക
മിക്ക ടീമുകളും ഒരു വേഗത്തിലുള്ള വെക്റ്റർ സെർച്ച് ബെഞ്ച്മാർക്ക് നടത്തുകയും റിട്രീവൽ ലെയർ പരിശോധിച്ചു എന്ന് പറയുകയും ചെയ്യുന്നു. ആ ബെഞ്ച്മാർക്ക് സാധാരണയായി അളക്കുന്നത് ഒരു തിരഞ്ഞെടുത്ത ക്വറിക്ക് ഡാറ്റാബേസ് എത്ര വേഗത്തിൽ അടുത്തുള്ള അയൽക്കാരെ (nearest neighbors) തിരികെ നൽകുന്നു എന്നതാണ്. ആ അയൽക്കാരുകളിൽ യഥാർത്ഥത്തിൽ ഉത്തരം ഉണ്ടോ എന്ന് അത് അപൂർവ്വമായി മാത്രമേ അളക്കുന്നുള്ളൂ.
ലോഡിനനുസരിച്ച് റിട്രീവൽ ഗുണനിലവാരം സൂക്ഷ്മമായ രീതിയിൽ മാറുന്നു. സമാന്തരമായ സമ്മർദ്ദത്തിന് കീഴിൽ, അപ്രോക്സിമേറ്റ് നിയേർഡ് നെയിബർ (approximate nearest neighbor) ഇൻഡക്സുകൾ ഒറ്റപ്പെട്ട അവസ്ഥയിൽ പ്രവർത്തിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായി പെരുമാറാം. ഒരു നോട്ട്ബുക്കിൽ തികഞ്ഞതായി തോന്നിയ ചങ്കിംഗ് സ്ട്രാറ്റജികൾ (chunking strategies), പതിനായിരം ഡോക്യുമെന്റുകൾ ഒരേ എംബെഡിംഗ് സ്പേസിനായി മത്സരിക്കുമ്പോൾ അതിരുകൾക്ക് അപ്പുറം കോൺടെക്സ്റ്റ് നഷ്ടപ്പെടുത്താൻ തുടങ്ങുന്നു. ശാന്തമായ സാഹചര്യത്തിൽ ആദർശമായ ഖണ്ഡിക നൽകുന്ന ഒരു ക്വറി, ഇൻഡക്സ് പുനർനിർമ്മിക്കുമ്പോഴോ അല്ലെങ്കിൽ റിക്വസ്റ്റ് സമ്മർദ്ദത്തിൽ മെറ്റാഡാറ്റ ഫിൽട്ടറിംഗ് ഒഴിവാക്കപ്പെടുമ്പോഴോ തെറ്റായ ഒരു മാർക്കറ്റിംഗ് സ്ലൈഡ് നൽകിയേക്കാം.
ഇത് ശരിയായി പരിശോധിക്കാൻ, നിങ്ങൾക്ക് ഒരു ഗ്രൗണ്ട്-ട്രൂത്ത് ഡാറ്റാസെറ്റ് (ground-truth dataset) ആവശ്യമാണ്. ഏത് സ്രോതസ്സ് രേഖകൾ വരണമെന്ന് നിങ്ങൾക്ക് അറിയാവുന്ന ചോദ്യങ്ങൾ തയ്യാറാക്കുക. വ്യത്യസ്ത കൺകറൻസി ലെവലുകളിൽ ആ ചോദ്യങ്ങൾ റൺ ചെയ്യുകയും പ്രതീക്ഷിച്ച ചങ്ക്സുകൾ ടോപ്പ്-k റിസൾട്ടുകളിൽ വരുന്നുണ്ടോ എന്ന് പരിശോധിക്കുകയും ചെയ്യുക. ക്വറി ഡ്യൂറേഷൻ മാത്രമല്ല, ഹിറ്റ് റേറ്റ് (hit rate) കൂടി ട്രാക്ക് ചെയ്യുക. നിങ്ങളുടെ ടോപ്പ്-അഞ്ച് ചങ്ക്സുകൾ പ്രധാന സ്രോതസ്സ് പൂർണ്ണമായും വിട്ടുപോവുകയാണെങ്കിൽ, LLM ഉണരുന്നതിന് മുമ്പ് തന്നെ നിങ്ങളുടെ റിട്രീവൽ പൈപ്പ്ലൈൻ പരാജയപ്പെട്ടു എന്നാണ് അർത്ഥം.
നിങ്ങൾ എഡ്ജുകൾ (edges) സ്ട്രെസ്സ് ടെസ്റ്റ് ചെയ്യുകയും വേണം. കോർപ്പസസിൽ ഉത്തരം ഇല്ലാത്ത ക്വറികൾ സമർപ്പിക്കുക. ഒന്നിലധികം ഡൊമെയ്നുകളിലേക്ക് മാപ്പable ആയ അവ്യക്തമായ ചോദ്യങ്ങൾ സമർപ്പിക്കുക. നിങ്ങളുടെ എംബെഡിംഗ് മോഡലിന്റെ ടോക്കൺ പരിധി കവിഞ്ഞുള്ള നീളമുള്ള ചോദ്യങ്ങൾ സമർപ്പിക്കുകയും അവ നിശബ്ദമായി മുറിച്ചുമാറ്റപ്പെടുന്നത് (truncated) ശ്രദ്ധിക്കുകയും ചെയ്യുക. റിട്രീവൽ ലെയർ എന്താണ് തിരികെ നൽകുന്നത് എന്ന് നിരീക്ഷിക്കുക. ഓരോ സാഹചര്യത്തിലും, കടന്നുപോയ മില്ലിസെക്കൻഡുകളേക്കാൾ പരാജയത്തിന്റെ രീതിയാണ് (failure mode) കൂടുതൽ പ്രധാനം.
മോഡൽ നിശബ്ദമായി തളരുമ്പോൾ
ചങ്ക്സുകൾ LLM-ൽ എത്തിക്കഴിഞ്ഞാൽ, സാധാരണ ലോഡ് ടെസ്റ്റിംഗ് കള്ളം പറഞ്ഞു കൊണ്ടിരിക്കുന്നു