મોટાભાગના RAG પ્રોટોટાઇપ્સ અંદરથી એકસરખા જ દેખાય છે. કોઈ વ્યક્તિ પાઇપલાઇનમાં એક PDF નાખે છે, ટેક્સ્ટને વ્યવસ્થિત 512-ટોકન ચંક્સમાં વિભાજિત કરે છે, તેને વેક્ટર ડેટાબેઝમાં નાખે છે, અને કામ પૂરું થયું એમ માની લે છે. એક સામાન્ય ડેમો માટે, આ પ્રભાવશાળી લાગી શકે છે. પરંતુ પ્રોડક્શનમાં, તે નિષ્ફળ જાય છે.
એક ફિક્સ્ડ ચંક (Fixed chunk) ને તેનાથી કોઈ ફરક પડતો નથી કે તે ક્યાંથી વિભાજિત થાય છે. તે કાનૂની કરારને 'ઇન્ડેમ્નિટી ક્લોઝ' (indemnity clause) ની વચ્ચેથી કાપી નાખશે. તે પાંચ અસંબંધિત API એન્ડપોઇન્ટ્સને એક જ કોન્ટેક્સ્ટ વિન્ડોમાં ભરી દેશે અને મોડેલને અસ્પષ્ટ માહિતી (noise) થી ભરી દેશે. તે તમને જરૂરી કરતાં વધુ ફ્રેગમેન્ટ્સ રિટ્રીવ કરવા માટે મજબૂર કરશે, જેનાથી લેટન્સી (latency) વધશે અને ટોકન્સનો બગાડ થશે. તેનું પરિણામ અડધા જવાબ, ભ્રમણાઓ (hallucinations) અને હતાશ થયેલા વપરાશકર્તાઓ છે.
અમે અમારા રિટ્રીવલ લેયરને મૂળમાંથી તોડીને ફરીથી બનાવ્યું. તેનું પરિણામ એક એવી સિસ્ટમ તરીકે આવ્યું જેણે લેટન્સીમાં 40 ટકા ઘટાડો કરીને 95 ટકા રિકોલ (recall) હાંસલ કર્યો. અમે તે બરાબર કેવી રીતે કર્યું તે અહીં છે.
પ્રોડક્શનમાં ફિક્સ્ડ ચંક્સ (Fixed Chunks) કેમ નિષ્ફળ જાય છે
512-ટોકન ડિફોલ્ટ એ કોઈ ડિઝાઇન પસંદગી નથી. તે પ્રારંભિક એમ્બેડિંગ મોડેલ કોન્ટેક્સ્ટ વિન્ડોઝ અને લાઇબ્રેરીના ડિફોલ્ટ સેટિંગ્સનું પરિણામ છે. તેને અમલમાં મૂકવું સરળ છે પરંતુ તેના પર નિર્ભર રહેવું જોખમી છે.
દસ્તાવેજો સમાન હોતા નથી. એક કાનૂની ક્લોઝ કોઈપણ સ્પષ્ટ વિરામ વગર સાતસો ટોકન સુધી લાંબો હોઈ શકે છે. જો તમે તેને પાંચસો બાર ટોકન પર કાપો છો, તો તમે બે અપૂર્ણ ફ્રેગમેન્ટ્સ બનાવો છો. જ્યારે કોઈ વકીલ અથવા કમ્પ્લાયન્સ ઓફિસર જવાબદારીની મર્યાદા (liability caps) વિશે પૂછે છે, ત્યારે સિસ્ટમ માત્ર અડધી જવાબદારી જ રિટ્રીવ કરે છે. લેંગ્વેજ મોડેલ ખૂટતા અડધા ભાગ વિશે ભ્રમણા (hallucinate) કરે છે, અથવા તો વધુ ખરાબ રીતે, તે એમ કહે છે કે આવી કોઈ મર્યાદા છે જ નહીં.
API ડોક્યુમેન્ટેશનમાં તેનાથી વિપરીત સમસ્યા જોવા મળે છે. પાંચસો-ટોકનનો ચંક આખા મોડ્યુલને ગળી શકે છે: ઓથેન્ટિકેશન હેડર્સ, એરર કોડ્સ, રેટ લિમિટ્સ અને વેબહુક સ્કીમાસ. જ્યારે ડેવલપર AUTH_4027 ને કેવી રીતે હેન્ડલ કરવું તે પૂછે છે, ત્યારે રિટ્રીવર અસંબંધિત ફંક્શન્સનું મિશ્રણ રજૂ કરે છે. મોડેલ પાસે તે બધાને ભેગા કરીને સામાન્ય માહિતી આપવા સિવાય બીજો કોઈ વિકલ્પ રહેતો નથી.
ખરાબ ચંકિંગ લેટન્સી (latency) પણ વધારે છે. નબળા ફ્રેગમેન્ટ્સનો અર્થ એ છે કે તમારે કોઈ વિષયને આવરી લેવા માટે મોટા 'top-k' ની જરૂર પડશે. વધુ ચંક્સ એટલે લાંબા પ્રોમ્પ્ટ્સ. લાંબા પ્રોમ્પ્ટ્સ એટલે ધીમી જનરેશન અને વધુ ખર્ચ. વપરાશકર્તાનો અનુભવ ખરાબ બને છે.
ચંકને દસ્તાવેજ મુજબ અનુરૂપ બનાવો
અમે ટોકન્સ ગણવાનું બંધ કર્યું અને સામગ્રી વાંચવાનું શરૂ કર્યું. યોગ્ય ચંકિંગ વ્યૂહરચના સ્ત્રોતની રચના પર આધારિત છે.
કાનૂની દસ્તાવેજો (Legal documents) માટે ક્લોઝ-અવેર (clause-aware) સીમાઓ સાથે રિકર્સિવ કેરેક્ટર ચંકિંગની જરૂર હોય છે. સ્પ્લિટર પદાનુક્રમ (hierarchy) નું સન્માન કરે છે: તે પહેલા સેક્શન હેડર્સ શોધે છે, પછી નંબરવાળા ફકરાઓ, અને પછી કુદરતી વાક્ય વિરામ શોધે છે. તે ક્યારેય સબ-ક્લોઝને અલગ નથી પાડતું કે કોઈ જવાબદારીવાળા વાક્યને ચંક્સ વચ્ચે વિભાજિત કરતું નથી. જ્યારે તમે વળતર (indemnification) વિશેનો ફકરો રિટ્રીવ કરો છો, ત્યારે તમને આખો ક્લોઝ, તેની મર્યાદા અને અપવાદો મળે છે.
API ડોક્યુમેન્ટેશન માટે સ્ટ્રક્ચર-અવેર (structure-aware) ચંકિંગ જરૂરી છે. અમે ટોકન બજેટને બદલે ફંક્શન ડેફિનેશન દ્વારા પાર્સ કરીએ છીએ. દરેક ચંકમાં સંપૂર્ણ ફંક્શન સિગ્નેચર, તેના પેરામીટર વર્ણનો અને તેની તરત જ બાજુમાં રહેલી એરર હેન્ડલિંગ નોંધો હોય છે. જો ડેવલપર કોઈ ચોક્કસ મેથડ શોધે છે, તો તેમને આખો કોન્ટ્રાક્ટ મળે છે, નહીં કે કોઈ અસ્પષ્ટ વિભાજનમાં ફસાયેલું ફ્રેગમેન્ટ.
સપોર્ટ ટિકિટ્સ (Support tickets) અસ્પષ્ટ અને નોન-લીનિયર હોય છે. એક થ્રેડ બગ રિપોર્ટથી શરૂ થઈ શકે છે, તેમાં વર્કઅરાઉન્ડ (workaround) હોઈ શકે છે, અને અંતે ઇન્ટરનલ એસ્કેલેશન નોટ સાથે સમાપ્ત થઈ શકે છે. સિમેન્ટિક ચંકિંગ (Semantic chunking) વાક્યો વચ્ચે એમ્બેડિંગ સમાનતા માપીને વિષયના ફેરફારને ઓળખે છે. અમે માત્ર કુદરતી વિષયવસ્તુની સીમાઓ પર જ વિભાજનની મંજૂરી આપીએ છીએ, જેથી લોગિન નિષ્ફળતા વિશેની વાતચીત બિલિંગ સાયકલ વિશેની વાતચીતથી અલગ રહે.
વિકિ (Wikis) સૌથી અઘરા હતા. તેઓ વ્યાપક, ક્રોસ-લિંક્ડ અને અસ્તવ્યસ્ત રીતે સંગઠિત હોય છે. અમે એજન્ટિક ચંકિંગ (agentic chunking) નો ઉપયોગ કર્યો, જ્યાં એક લાઇટવેઇટ LLM પેજ વાંચે છે અને વિષયની સુસંગતતાના આધારે વિભાજન નક્કી કરે છે. તે ઇન્જેસ્ટિયન (ingestion) સમયે થોડો વધુ ખર્ચાળ છે, પરંતુ પરિણામી ચંક્સ સ્વયં-નિર્ભર અને રિટ્રીવલ માટે તૈયાર હોય છે. ડિપ્લોયમેન્ટની શ્રેષ્ઠ પદ્ધતિઓ વિશેનું પેજ મનસ્વી ટેક્સ્ટ બ્લોક્સને બદલે તાર્કિક એકમોમાં વિભાજિત થાય છે: પ્રી-ફ્લાઇટ ચેક્સ, રોલબેક પ્રક્રિયાઓ અને મોનિટરિંગ સેટઅપ.
હાઇબ્રિડ રિટ્રીવલ (Hybrid Retrieval): કીવર્ડ્સ અને વેક્ટર્સ સાથે મળીને
ડેન્સ વેક્ટર સર્ચ અર્થ સમજે છે. પરંતુ તે ચોક્કસ સ્ટ્રિંગ્સ (exact strings) શોધવામાં નબળું છે. જો વપરાશકર્તા AUTH_4027 જેવો ચોક્કસ એરર કોડ અથવા "Stark Industries" જેવું ગ્રાહકનું નામ શોધે છે, તો વેક્ટર એમ્બેડિંગ્સ લક્ષ્ય ચૂકી શકે છે કારણ કે તેઓ કન્સેપ્ચ્યુઅલ સામ્યતા માટે ઓપ્ટિમાઇઝ કરે છે, કેરેક્ટર-લેવલની ચોકસાઈ માટે નહીં.
BM25 દ્વારા કરવામાં આવતી શુદ્ધ કીવર્ડ સર્ચમાં તેનાથી વિપરીત ખામી છે. તે AUTH_4027 ચોક્કસપણે શોધી લેશે, પરંતુ તે "authorization failure" અને "login denied" વચ્ચેના વૈચારિક જોડાણને ચૂકી જશે.
We run both in parallel. BM25 and vector search operate independently over the same corpus. Their result lists are merged using Reciprocal Rank Fusion, which reorders candidates by balancing their positional ranks. You do not need calibrated weights. You simply get the precision of exact match and the intuition of semantic search in a single ranked list.
Then we add a cross-encoder reranker. This is a separate model that scores each passage against the original query, producing a relevance signal far finer than either retriever alone. It adds about 50 milliseconds of latency. It increases recall by 15 percent. If you care about answer quality, that trade is non-negotiable.
Query Expansion: Fix the Search Before It Starts
Bad queries are the dirty secret of every retrieval system. Users do not write like your embedding space. They type "it broke." They paste truncated stack traces. They use internal jargon your index has never seen.
We transform the query before it ever touches the index. First, we expand a single query into three to five diverse search terms. If the original is "payment failed," we also search for "transaction error," "billing declined," and "charge unsuccessful