മിക്ക RAG ട്യൂട്ടോറിയലുകളും ഡെമോയിൽ അവസാനിക്കുന്നു. നിങ്ങൾ ടോക്കൺ എണ്ണം കണക്കാക്കി വിവരങ്ങളെ ചങ്കുകളാക്കുന്നു (chunking), അവയെല്ലാം ഒരു വെക്റ്റർ ഡാറ്റാബേസിലേക്ക് നിറയ്ക്കുന്നു, എന്നിട്ട് അത് കഴിഞ്ഞു എന്ന് കരുതുന്നു. ഒരു ഉപയോക്താവ് "റിട്ടേൺ പോളിസി എന്താണ്?" എന്ന് ഒരു ക്ലീൻ FAQ-യിൽ ചോദിക്കുമ്പോൾ ഇത് പ്രവർത്തിക്കും. എന്നാൽ ഒരാൾ പകുതി കരാർ (contract) പേസ്റ്റ് ചെയ്ത് മൂന്നാമത്തെ ക്ലോസിനെക്കുറിച്ച് ചോദിക്കുമ്പോഴോ, അല്ലെങ്കിൽ ഒരു ഡെവലപ്പർ ഡോക്യുമെന്റേഷൻ സെർച്ചിൽ ഒരു അപൂർവ്വമായ എറർ കോഡ് ടൈപ്പ് ചെയ്യുമ്പോഴോ ഇത് പരാജയപ്പെടുന്നു.

നിശ്ചിത ടോക്കൺ വിൻഡോകൾ നിയമപരമായ കരാറുകളെ വാചകത്തിന്റെ ഇടയിൽ വെച്ച് മുറിച്ചു മാറ്റുന്നു. വലിയ ചങ്കുകൾ API റഫറൻസുകളെ അനാവശ്യമായ വിവരങ്ങൾക്കിടയിൽ കുഴിച്ചുമൂടുന്നു. എല്ലാറ്റിലുമുപരി, സാവധാനത്തിലുള്ള റിട്രീവൽ (retrieval) കാരണം മോഡൽ ഉത്തരം നൽകി തുടങ്ങുന്നതിന് മുമ്പ് തന്നെ ഉപയോക്താക്കൾ തിരച്ചിൽ ഉപേക്ഷിക്കുന്നു. ഞങ്ങൾ ഇത് കഠിനമായ അനുഭവത്തിലൂടെയാണ് പഠിച്ചത്. ഞങ്ങളുടെ റിട്രീവൽ ലെയറിനെ വെറും പ്രതീക്ഷകളിൽ നിന്ന് കൃത്യമായ അളവുകോലുകളിലേക്ക് മാറ്റിയപ്പോൾ, ലേറ്റൻസി (latency) നാൽപ്പത് ശതമാനം കുറയ്ക്കാനും റീക്കോൾ (recall) തൊണ്ണൂറ്റഞ്ച് ശതമാനമായി ഉയർത്താനും ഞങ്ങൾക്ക് കഴിഞ്ഞു. ഞങ്ങൾ വരുത്തിയ മാറ്റങ്ങൾ ഇതാ.

Smart Chunking

ചങ്ക് സൈസിനെ (chunk size) ഒരു മാന്ത്രിക സംഖ്യയായി കാണുന്നത് നിർത്തുക. ഒരു സിംഗിൾ ക്ലോസ് ഒന്നിലധികം പാരഗ്രാഫുകളിലായി വ്യാപിച്ചു കിടക്കുന്ന ഒരു നിയമപരമായ രേഖയ്ക്ക് 512-ടോക്കൺ വിൻഡോ കൊണ്ട് പ്രയോജനമില്ല; അതുപോലെ ഒരു ഫംഗ്ഷൻ സിഗ്നേച്ചറും അതിന്റെ രണ്ട് വരി വിവരണവും ഒരുമിച്ച് ഇരിക്കേണ്ട API ഡോക്യുമെന്റേഷനും ഇതിൽ അത്ര ഫലപ്രദമല്ല. ഞങ്ങൾ സ്ട്രക്ചർ-അവയർ സ്പ്ലിറ്റിംഗിലേക്ക് (structure-aware splitting) മാറി.

നിയമപരമായ ടെക്സ്റ്റുകൾക്കായി, റിക്കഴ്‌സീവ് ചങ്കിംഗ് (recursive chunking) ഡോക്യുമെന്റിന്റെ ശ്രേണി (hierarchy) മാനിക്കുന്നു. ക്ലോസുകൾ തകരാതെ നിലനിൽക്കുന്നു. API ഡോക്യുമെന്റേഷനായി, സിഗ്നേച്ചറുകളും പാരാമീറ്ററുകളും ഉദാഹരണങ്ങളും ഒരുമിച്ച് നിലനിർത്തുന്ന ഫംഗ്ഷൻ-അവയർ സ്പ്ലിറ്റിംഗ് (function-aware splitting) ഞങ്ങൾ ഉപയോഗിക്കുന്നു. സപ്പോർട്ട് ടിക്കറ്റുകൾക്കും സംഭാഷണ ഡാറ്റയ്ക്കും സെമാന്റിക് ബൗണ്ടറികൾ (semantic boundaries) ആവശ്യമാണ്; അതായത് അനാവശ്യമായ ക്യാരക്ടർ എണ്ണത്തിന് പകരം വിഷയം മാറുന്നിടത്ത് വേണം വിഭജിക്കാൻ. ഇതിന്റെ ഫലമായി, ഓരോ ചങ്കും ആവശ്യമായ കോൺടെക്സ്റ്റ് (context) നൽകുന്നുണ്ടെങ്കിലും അത് അമിതമായി വിവരങ്ങളെ കലർത്തുന്നില്ല. നിങ്ങളുടെ എംബെഡിംഗ് മോഡലിന് പരിമിതമായ അറ്റൻഷൻ ബഡ്ജറ്റ് മാത്രമേയുള്ളൂ. അത് വിവേകപൂർവ്വം ഉപയോഗിക്കുക.

Hybrid Retrieval

ആശയപരമായി സമാനമായ ഉള്ളടക്കം കണ്ടെത്തുന്നതിൽ വെക്റ്റർ സെർച്ച് മികച്ചുനിൽക്കുന്നു. ഡാറ്റാബേസ് ക്വറികൾ പതുക്കെയാണെന്ന് ചോദിച്ചാൽ അത് പെർഫോമൻസ് ട്യൂണിംഗ് ഗൈഡുകൾ നൽകും. എന്നാൽ "Error 0x80070057" എന്ന് ചോദിച്ചാൽ, ഡെൻസ് എംബെഡിംഗുകൾക്ക് (dense embeddings) കൃത്യമായ മാച്ചുകൾ കൈകാര്യം ചെയ്യാൻ പ്രയാസമായതിനാൽ സെമാന്റിക് സെർച്ച് അപ്രസക്തമായ മേഖലകളിലേക്ക് വഴിമാറുന്നു. മറുവശത്ത്, BM25 കൃത്യമായ സ്ട്രിംഗുകളും അപൂർവ്വ പദങ്ങളും കണ്ടെത്തുന്നതിൽ മിടുക്കനാണ്, എന്നാൽ "latency", "slow response time" എന്നിവ ഒരേ അർത്ഥമാണെന്ന് അതിന് അറിയില്ല.

ഞങ്ങൾ ഇവ രണ്ടും സമാന്തരമായി പ്രവർത്തിപ്പിക്കുകയും Reciprocal Rank Fusion (RRF) ഉപയോഗിച്ച് അവയെ സംയോജിപ്പിക്കുകയും ചെയ്യുന്നു. RRF ലളിതവും ഫലപ്രദവുമാണ്. ഇത് ഓരോ രീതിയിൽ നിന്നുമുള്ള റാങ്ക് ചെയ്ത ലിസ്റ്റുകൾ എടുക്കുകയും അവയുടെ സ്ഥാനത്തിന്റെ അടിസ്ഥാനത്തിൽ ഡോക്യുമെന്റുകൾക്ക് സ്കോർ നൽകുകയും ചെയ്യുന്നു. സംയോജനത്തിന് ശേഷം, ഞങ്ങൾ സംയോജിത ഫലങ്ങളിൽ ഒരു ക്രോസ്-എൻകോഡർ റീറാംക്കർ (cross-encoder reranker) പ്രവർത്തിപ്പിക്കുകയും മികച്ച അഞ്ച് ഫലങ്ങൾ മാത്രം നൽകുകയും ചെയ്യുന്നു. റീറാംക്കർ ഏകദേശം അൻപത് മില്ലിസെക്കൻഡ് ലേറ്റൻസി കൂട്ടുമെങ്കിലും ഞങ്ങളുടെ റീക്കോൾ പതിനഞ്ച് ശതമാനം മെച്ചപ്പെടുത്തി. ജനറേഷൻ ഗുണനിലവാരത്തിൽ ഇത് പലമടങ്ങ് ലാഭമുണ്ടാക്കുന്നു.

Query Expansion

ഉപയോക്താക്കൾ ക്വറികൾ നൽകുന്നതിൽ അത്ര മിടുക്കരല്ല. അവർ വാക്കുകൾ ചുരുക്കുന്നു, തെറ്റായി എഴുതുന്നു, അല്ലെങ്കിൽ മൂന്ന് ചോദ്യങ്ങൾ ഒരൊറ്റ നീണ്ട വാചകത്തിൽ ചോദിക്കുന്നു. അവർ ടൈപ്പ് ചെയ്തത് അതേപടി തിരഞ്ഞാൽ, അവർക്ക് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ഡോക്യുമെന്റുകൾ നിങ്ങൾക്ക് ലഭിക്കില്ല.

ഇപ്പോൾ ഞങ്ങൾ ഓരോ ക്വറിയും ഇൻഡക്സിലേക്ക് എത്തുന്നതിന് മുമ്പ് മാറ്റം വരുത്തുന്നു. ഒന്നാമതായി, പര്യായപദങ്ങളും മറ്റ് രീതിയിലുള്ള പ്രയോഗങ്ങളും ഉൾക്കൊള്ളുന്നതിനായി ഒറിജിനൽ ചോദ്യത്തിന്റെ ഒന്നിലധികം പതിപ്പുകൾ ഞങ്ങൾ നിർമ്മിക്കുന്നു. രണ്ടാമതായി, സങ്കീർണ്ണമായ ചോദ്യങ്ങളെ ചെറിയ ഉപചോദ്യങ്ങളായി വിഭജിക്കുന്നു. "അന്താരാഷ്ട്ര ഉപഭോക്താക്കൾക്ക് റീഫണ്ട് പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്, അത് എങ്ങനെ പരിഹരിക്കാം?" എന്ന ക്വറി രണ്ട് വ്യത്യസ്ത തിരച്ചിലുകളായി മാറുന്നു: ഒന്ന് അന്താരാഷ്ട്ര റീഫണ്ട് പരാജയങ്ങളെക്കുറിച്ചും മറ്റൊന്ന് പരിഹാര മാർഗങ്ങളെക്കുറിച്ചും. ക്വറി എക്സ്പാൻഷൻ മാത്രം ഞങ്ങളുടെ റീക്കോൾ എഴുപത്തിയെട്ട് ശതമാനത്തിൽ നിന്ന് തൊണ്ണൂറ്റിയാല് ശതമാനമായി ഉയർത്തി. പാഠം ലളിതമാണ്: ഉപയോക്താവിന്റെ ആദ്യ ഡ്രാഫ്റ്റിനെ മാത്രം വിശ്വസിക്കരുത്. അവരെ സഹായിക്കുക.

Stop Guessing, Start Searching

ചങ്ക് സൈസ്, ഓവർലാപ്പ് ശതമാനം, top-k കട്ട്ഓഫ്, റീറാംക്കർ ഡെപ്ത്ത് എന്നിവ കൈകൊണ്ട് ട്യൂൺ ചെയ്യാൻ കഴിയാത്ത രീതിയിൽ പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു. കോഹറൻസ് (coherence) നശിപ്പിക്കുന്ന ഓവർലാപ്പ് സെറ്റിംഗിനെ അവഗണിച്ചുകൊണ്ട്, 256 ടോക്കൺ ആണോ 512 ടോക്കൺ ആണോ നല്ലതെന്ന് ചർച്ച ചെയ്തുകൊണ്ട് ഞങ്ങൾ ഒരുപാട് സമയം കളഞ്ഞു.

ഞങ്ങൾ ഇൻറ്റ്യൂഷന് (intuition) പകരം ബേസിയൻ ഒപ്റ്റിമൈസേഷൻ (Bayesian optimization) ഉപയോഗിച്ചു. വ്യക്തമായും മോശമായ മേഖലകളിൽ കമ്പ്യൂട്ട് പാഴാക്കുന്ന ഗ്രിഡ് സെർച്ചിന് പകരം, ബേസിയൻ രീതികൾ എന്താണ് പ്രവർത്തിക്കുന്നത് എന്നതിനെക്കുറിച്ച് ഒരു പ്രോബബിലിസ്റ്റിക് മോഡൽ നിർമ്മിക്കുകയും ലേറ്റൻസി കുറയ്ക്കുന്നതോടൊപ്പം റീക്കോൾ പരമാവധിയാക്കുന്ന പാറെറ്റോ ഫ്രോണ്ടിയർ (Pareto frontier) സജീവമായി തേടുകയും ചെയ്യുന്നു. ഞങ്ങളുടെ സ്റ്റാക്കിന് (stack), ലേറ്റൻസി ബഡ്ജറ്റ് മറികടക്കാതെ തൊണ്ണൂറ്റഞ്ച് ശതമാനം റീക്കോൾ നൽകുന്ന ചങ്ക് സൈസ്, ഓവർലാപ്പ്, top-k എന്നിവയുടെ കൃത്യമായ കോമ്പിനേഷൻ കണ്ടെത്താൻ ഇത് സഹായിച്ചു. വ്യത്യസ്ത ഉപയോഗ സാഹചര്യങ്ങൾ ആ ഫ്രോണ്ടിയറിലെ വ്യത്യസ്ത പോയിന്റുകളിൽ എത്തിച്ചേർന്നു. കസ്റ്റമർ ഫേസിംഗ് ചാറ്റ്ബോട്ടുകൾ വേഗതയ്ക്ക് മുൻഗണന നൽകി. ഇന്റേണൽ ലീഗൽ റിസർച്ച് റീക്കോളിന് മുൻഗണന നൽകി. ഓട്ടോമേറ്റഡ് ഒപ്റ്റിമൈസേഷൻ കോൺഫിഗറേഷൻ ഫയലുകൾ മാനുവലായി കോപ്പി-പേസ്റ്റ് ചെയ്യാതെ തന്നെ ഇവ രണ്ടിനും സേവനം നൽകാൻ ഞങ്ങളെ അനുവദിച്ചു.

The Results

The numbers speak plainly. Our Recall@10 climbed from seventy-eight percent to ninety-five percent. The p95 latency dropped from 850 milliseconds to 320 milliseconds. And because the model was finally receiving relevant context instead of noise, the hallucination rate fell from twelve percent to three percent. Better retrieval does not just make answers faster. It makes them true.

What to Do Next

If you are rebuilding your retrieval layer, start here:

  • Chunk by document structure, not token count. Match your splitting strategy to the shape of your data.
  • Use hybrid retrieval. Combine vector search and BM25, merge with Reciprocal Rank Fusion, and rerank before you generate.
  • Expand queries for better coverage. Rephrase and decompose before the search ever runs.
  • Build a golden dataset for testing. You cannot optimize what you do not measure.
  • Optimize parameters with automated tools. Bayesian search will find better settings than your gut.

Retrieval is not a configuration file you set once and forget. It is infrastructure, and infrastructure deserves the same rigor as production code: tests, measurements, and continuous optimization. Treat it that way, and your RAG system stops being a demo and starts being a product.

Optional learning community: GyaanSetu AI