મોટાભાગના RAG ટ્યુટોરિયલ્સ ડેમો પર જ પૂરા થઈ જાય છે. તમે ટોકન કાઉન્ટ દ્વારા ચંકિંગ કરો છો, બધું વેક્ટર ડેટાબેઝમાં નાખો છો, અને કામ પૂરું સમજી લો છો. જ્યારે કોઈ યુઝર ક્લીન FAQ માં "રિટર્ન પોલિસી શું છે?" એવું પૂછે ત્યારે આ કામ કરે છે. પરંતુ જ્યારે કોઈ અડધો કોન્ટ્રાક્ટ પેસ્ટ કરીને ત્રીજા ક્લોઝ (clause) વિશે પૂછે, અથવા જ્યારે કોઈ ડેવલપર ડોક્યુમેન્ટેશન સર્ચમાં કોઈ અસ્પષ્ટ એરર કોડ ટાઈપ કરે, ત્યારે આ પદ્ધતિ નિષ્ફળ જાય છે.

ફિક્સ્ડ ટોકન વિન્ડોઝ કાયદાકીય કરારોને અધવચ્ચેથી કાપી નાખે છે. મોટા ચંક્સ API રેફરન્સને પેરાગ્રાફના ઘોંઘાટ નીચે દબાવી દે છે. સૌથી ખરાબ બાબત એ છે કે, ધીમું રિટ્રીવલ યુઝર્સને મોડેલ જનરેટ કરવાનું શરૂ કરે તે પહેલાં જ ક્વેરી છોડવા મજબૂર કરે છે. અમે આ કઠિન રીતે શીખ્યા છીએ. જ્યારે અમે અમારા રિટ્રીવલ લેયરને માત્ર આશા પરથી બદલીને માપન (measurement) પર લાવ્યા, ત્યારે અમે લેટન્સીમાં 40% ઘટાડો કર્યો અને રિકોલને 95% સુધી પહોંચાડ્યો. અહીં બરાબર શું બદલાયું તે જાણો.

સ્માર્ટ ચંકિંગ (Smart Chunking)

ચંક સાઈઝ વિશે મેજિક નંબર તરીકે વિચારવાનું બંધ કરો. 512-ટોકન વિન્ડો કાયદાકીય દસ્તાવેજ માટે બિનઅર્થપૂર્ણ છે જ્યાં એક સિંગલ ક્લોઝ અનેક પેરાગ્રાફમાં ફેલાયેલ હોય છે, અને તે API ડોક્સ માટે પણ એટલું જ નકામું છે જ્યાં ફંક્શન સિગ્નેચર અને તેનું બે-લાઇનનું વર્ણન સાથે રહેવું જોઈએ. અમે સ્ટ્રક્ચર-અવેર સ્પ્લિટિંગ (structure-aware splitting) અપનાવ્યું.

કાયદાકીય લખાણ માટે, રિકર્સિવ ચંકિંગ (recursive chunking) દસ્તાવેજની હાયરાર્કીનું સન્માન કરે છે. ક્લોઝ અકબંધ રહે છે. API ડોક્યુમેન્ટેશન માટે, અમે ફંક્શન-અવેર સ્પ્લિટિંગનો ઉપયોગ કરીએ છીએ જે સિગ્નેચર્સ, પેરામીટર્સ અને ઉદાહરણોને એટમિક યુનિટ્સ તરીકે સાથે રાખે છે. સપોર્ટ ટિકિટ્સ અને વાતચીત ડેટા માટે સેમેન્ટિક બાઉન્ડ્રીઝની જરૂર હોય છે, જે મનસ્વી કેરેક્ટર કાઉન્ટને બદલે વિષય બદલાય ત્યાં સ્પ્લિટ થાય છે. પરિણામ એ છે કે દરેક ચંક ઉપયોગી હોવા માટે પૂરતો કોન્ટેક્સ્ટ ધરાવે છે પરંતુ એટલો વધારે નથી કે તે સિગ્નલને નબળું પાડે. તમારા એમ્બેડિંગ મોડેલ પાસે મર્યાદિત એટેન્શન બજેટ છે. તેનો સમજદારીપૂર્વક ઉપયોગ કરો.

હાઇબ્રિડ રિટ્રીવલ (Hybrid Retrieval)

વેક્ટર સર્ચ વૈચારિક રીતે સમાન સામગ્રી શોધવામાં શ્રેષ્ઠ છે. જો તમે ધીમી ડેટાબેઝ ક્વેરી વિશે પૂછશો, તો તે પરફોર્મન્સ ટ્યુનિંગ ગાઇડ્સ બતાવશે. પરંતુ જો તમે "Error 0x80070057" વિશે પૂછશો, તો સેમેન્ટિક સર્ચ અસંબંધિત ક્ષેત્રમાં જતું રહેશે કારણ કે ડેન્સ એમ્બેડિંગ્સ એક્ઝેક્ટ મેચને સારી રીતે હેન્ડલ કરી શકતા નથી. બીજી તરફ, BM25 ચોક્કસ સ્ટ્રિંગ્સ અને દુર્લભ શબ્દોને પકડી લે છે, છતાં તેને ખબર નથી હોતી કે "latency" અને "slow response time" નો અર્થ એક જ છે.

અમે બંનેને સમાંતર (parallel) ચલાવીએ છીએ અને તેને Reciprocal Rank Fusion (RRF) સાથે મર્જ કરીએ છીએ. RRF સરળ અને અસરકારક છે. તે દરેક પદ્ધતિમાંથી રેન્ક્ડ લિસ્ટ લે છે અને તેમની પોઝિશનના આધારે ડોક્યુમેન્ટ્સને સ્કોર આપે છે, જેનાથી બંને સિસ્ટમમાંથી મજબૂત ઉમેદવારોને યોગ્ય તક મળે છે. ફ્યુઝન પછી, અમે સંયુક્ત પરિણામો પર cross-encoder reranker ચલાવીએ છીએ અને ફક્ત ટોપ પાંચ પરિણામો જ આપીએ છીએ. રેરન્કર લગભગ 50 મિલીસેકન્ડની લેટન્સી ઉમેરે છે પરંતુ તેનાથી અમારો રિકોલ 15% સુધર્યો છે. જનરેશન ક્વોલિટીમાં આ ફાયદો આ લેટન્સી કરતા અનેકગણો વધારે છે.

ક્વેરી એક્સપાન્શન (Query Expansion)

યુઝર્સ ક્વેરી કરવામાં ખૂબ જ નબળા હોય છે. તેઓ શબ્દો ટૂંકા કરે છે, સ્પેલિંગમાં ભૂલ કરે છે, અથવા એક લાંબા વાક્યમાં ત્રણ પ્રશ્નો પૂછી નાખે છે. જો તમે બરાબર તે જ સર્ચ કરશો જે તેમણે ટાઈપ કર્યું છે, તો તમે તે ડોક્યુમેન્ટ્સ ચૂકી જશો જેની તેમને ખરેખર જરૂર છે.

હવે અમે ઇન્ડેક્સ પર પહોંચતા પહેલા દરેક ક્વેરીને ટ્રાન્સફોર્મ કરીએ છીએ. પ્રથમ, અમે સમાનાર્થી અને વૈકલ્પિક શબ્દોને આવરી લેવા માટે મૂળ પ્રશ્નના અનેક નવા રૂપો (rephrased versions) બનાવીએ છીએ. બીજું, અમે જટિલ પ્રશ્નોને નાના પેટા-પ્રશ્નોમાં વિભાજિત કરીએ છીએ. "ઇન્ટરનેશનલ કસ્ટમર્સ માટે રિફંડ કેમ નિષ્ફળ જઈ રહ્યું છે અને હું તેને કેવી રીતે ઠીક કરી શકું?" જેવી ક્વેરી બે અલગ સર્ચમાં બદલાઈ જાય છે: એક ઇન્ટરનેશનલ રિફંડ નિષ્ફળતા વિશે અને બીજું તેના નિવારણના પગલાં વિશે. માત્ર ક્વેરી એક્સપાન્શનથી જ અમારો રિકોલ 78% થી વધીને 94% થયો છે. પાઠ સ્પષ્ટ છે: યુઝરના પ્રથમ ડ્રાફ્ટ પર વિશ્વાસ ન કરો. તેમને મદદ કરો.

અનુમાન કરવાનું બંધ કરો, સર્ચ કરવાનું શરૂ કરો

ચંક સાઈઝ, ઓવરલેપ ટકાવારી, top-k cutoff, અને reranker ડેપ્થ એવી રીતે એકબીજા સાથે જોડાયેલા છે કે તેને હાથથી ટ્યુન કરવું અશક્ય છે. અમે 256 ટોકન્સ 512 કરતા સારા છે કે નહીં તે ચર્ચા કરવામાં ઘણો સમય બગાડ્યો, જ્યારે ઓવરલેપ સેટિંગને અવગણ્યું જે ખરેખર સુસંગતતા (coherence) બગાડી રહ્યું હતું.

અમે અંતર્જ્ઞાન (intuition) ને બદલે Bayesian optimization નો ઉપયોગ કર્યો. ગ્રીડ સર્ચને બદલે, જે સ્પષ્ટપણે ખરાબ વિસ્તારો પર કમ્પ્યુટ પાવર વેડફે છે, Bayesian પદ્ધતિઓ શું કામ કરે છે તેનું સંભવિત મોડેલ (probabilistic model) બનાવે છે અને લેટન્સી ઘટાડતા રિકોલને મહત્તમ કરે તેવા Pareto frontier ને સક્રિયપણે શોધે છે. અમારા સ્ટેક માટે, તેનો અર્થ ચંક સાઈઝ, ઓવરલેપ અને top-k નું એવું ચોક્કસ સંયોજન શોધવું હતો જે અમારા લેટન્સી બજેટને અસર કર્યા વિના આપણને 95% રિકોલ આપે. અલગ-અલગ ઉપયોગના કિસ્સાઓ તે ફ્રન્ટિયર પર અલગ-અલગ બિંદુઓ પર પહોંચ્યા. ગ્રાહક-સંબંધિત ચેટબોટ્સ માટે ઝડમને પ્રાધાન્ય આપવામાં આવ્યું. આંતરિક કાયદાકીય સંશોધન માટે રિકોલને પ્રાધાન્ય આપવામાં આવ્યું. ઓટોમેટેડ ઓપ્ટિમાઇઝેશન અમને કોન્ફિગ ફાઇલોના મેન્યુઅલ કોપી-પેસ્ટિંગ વગર બંને સેવાઓ આપવા દે છે.

પરિણામો

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