મોટાભાગની એન્જિનિયરિંગ ટીમો retrieval-augmented generation સાથે એક જ પ્રકારના અવરોધનો સામનો કરે છે. તેઓ ટ્યુટોરિયલ પ્લેબુકને અનુસરે છે: દસ્તાવેજોને પાંચસો બાર અથવા એક હજાર ચોવીસ ટોકન્સના નિશ્ચિત ચંક્સ (chunks) માં વિભાજિત કરવા, તેમને સિંગલ એમ્બેડિંગ મોડેલ દ્વારા પસાર કરવા અને સાદા top-k લુકઅપ સાથે વેક્ટર ડેટાબેઝને કોલ કરવો. સ્લાઇડ ડેકમાં, આ બધું મજબૂત લાગે છે. પરંતુ પ્રોડક્શનમાં, તે નિષ્ફળ જાય છે.
નિશ્ચિત ચંક્સ (Fixed chunks) સામગ્રીની પરવા કરતા નથી. તેઓ કાયદાકીય કરારને વાક્યની વચ્ચેથી જ વિભાજિત કરી દેશે, જેનાથી જવાબદારીના ક્લોઝ (liability clauses) બે અસંબંધિત ટેક્સ્ટના ટુકડાઓમાં લટકતા રહી જશે. તેઓ આખા API એન્ડપોઇન્ટનું વર્ણન એક એવા વિશાળ ચંકમાં નાખી દેશે કે જે એટલો મોટો હશે કે તમારા યુઝરે પૂછેલ ચોક્કસ પેરામીટર અવાજ (noise) માં ડૂબી જશે. અને જ્યારે રિટ્રાઇવલ ધીમું હોય, ત્યારે લેટન્સી (latency) નો દરેક મિલિસેકન્ડ સીધી યુઝર એક્સપિરિયન્સ પર અસર કરે છે. અમે આ કઠિન રીતે શીખ્યા. પછી અમે અમારા રિટ્રાઇવલ લેયરને તોડી નાખ્યું અને તેને ફરીથી બનાવ્યું. 'Recall at ten' માં અમારો સ્કોર 78% થી વધીને 95% થઈ ગયો. લેટન્સી વધી નહીં, પણ ઘટી ગઈ.
કોપી-પેસ્ટ RAG સાથેની સમસ્યા
સ્ટાન્ડર્ડ RAG સ્ટેક એક પ્રકારનું ડિફોલ્ટ સેટિંગ બની ગયું છે. નાના ચંક્સ, એક એમ્બેડિંગ મોડેલ, વેક્ટર સર્ચ, બસ થઈ ગયું. આ અભિગમ ડેમોમાં સફળ રહે છે કારણ કે ડેમોમાં સ્વચ્છ પ્રશ્નો અને વ્યવસ્થિત દસ્તાવેજોનો ઉપયોગ થાય છે. પ્રોડક્શન ડેટા ક્યારેય વ્યવસ્થિત હોતો નથી.
કાયદાકીય દસ્તાવેજોનું માળખું પદાનુક્રમિત (hierarchical) હોય છે. સેક્શનમાં સબ-સેક્શન હોય છે. સબ-સેક્શનમાં ક્લોઝ હોય છે. જો તમે તેને માત્ર ટોકન કાઉન્ટરથી કાપશો, તો તમે તે સંબંધોને જ નષ્ટ કરી દેશો જેના પર મોડેલને તર્ક (reasoning) કરવા માટે જરૂર છે. API ડોક્યુમેન્ટેશનનું પણ માળખું હોય છે, પરંતુ તે અલગ હોય છે. એક ફંક્શન સિગ્નેચર, તેના પેરામીટર્સ, તેનું રિટર્ન વેલ્યુ અને ઉપયોગનું ઉદાહરણ મળીને એક તાર્કિક એકમ બનાવે છે. તેને નિશ્ચિત ટોકન વિન્ડોમાં દબાણ કરવાથી કાં તો ઉદાહરણ કપાઈ જશે અથવા ચંકમાં અસંબંધિત ફંક્શન્સ ભરાઈ જશે. સપોર્ટ ટિકિટો અસ્તવ્યસ્ત, વાતચીત જેવી અને અચાનક વિષય બદલાતી હોય તેવી હોય છે. વિકિ (Wikis) વ્યાપક અને ક્રોસ-રેફરન્સ્ડ હોય છે. એક જ ચંકિંગ વ્યૂહરચના આ બધા માટે કામ કરી શકતી નથી, છતાં ટીમો નિયમિતપણે તે જ અમલમાં મૂકે છે. અમે એવું દેખાડવાનું બંધ કર્યું કે તે શક્ય છે.
વ્યૂહાત્મક ચંકિંગ: પદ્ધતિને સામગ્રી સાથે મેળવો
અમે કન્ટેન્ટ-અવેર (content-aware) ચંકિંગ તરફ વળ્યા. કાયદાકીય દસ્તાવેજો માટે, અમે રિકર્સિવ ચંકિંગનો ઉપયોગ કરીએ છીએ જે દસ્તાવેજના પદાનુક્રમનું સન્માન કરે છે. તે ક્લોઝને અકબંધ રાખે છે અને સેક્શન વચ્ચેના પેરેન્ટ-ચાઇલ્ડ સંબંધોને જાળવી રાખે છે. API ડોક્યુમેન્ટેશન માટે, અમે ફંક્શન-અવેર ચંકિંગ બનાવ્યું છે જે દરેક ફંક્શન અથવા એન્ડપોઇન્ટને એક સીમા (boundary) તરીકે ગણે છે. જો પેરામીટરનું વર્ણન લાંબું હોય, તો ચંક ટોકન લિમિટને બદલે તે ફંક્શનની આસપાસ વિસ્તરે છે. સપોર્ટ ટિકિટો માટે, અમે સેમેન્ટિક ચંકિંગનો ઉપયોગ કરીએ છીએ જે કુદરતી વિષયની સીમાઓને ઓળખે છે. જ્યારે ગ્રાહક અચાનક બિલિંગની ફરિયાદમાંથી ટેકનિકલ બગ પર જાય છે, ત્યારે વિભાજન તે વળાંક પર થાય છે. વિકિ અને અનસ્ટ્રક્ચર્ડ નોલેજ બેઝ માટે, અમે એજન્ટિક ચંકિંગનો ઉપયોગ કરીએ છીએ જ્યાં એક લાઇટવેઇટ LLM ટેક્સ્ટનું મૂલ્યાંકન કરે છે અને નક્કી કરે છે કે અર્થપૂર્ણ સીમા ક્યાં હોવી જોઈએ. કેરેક્ટર સ્પ્લિટ કરતા આ સેટઅપ કરવામાં ધીમું છે, પરંતુ તે કામ કરતા રિટ્રાઇવલ અને માત્ર અંદાજ લગાવતા રિટ્રાઇવલ વચ્ચેનો તફાવત છે.
હાઇબ્રિડ રિટ્રાઇવલ: શા માટે માત્ર વેક્ટર સર્ચ પૂરતું નથી
વેક્ટર સર્ચ અર્થ સમજે છે, પરંતુ તે ચોક્કસ મેચ ચૂકી શકે છે. જો યુઝર ERR_CONNECTION_RESET_0x5F3 જેવો એરર કોડ પેસ્ટ કરે છે, તો સેમેન્ટિક સિમિલારિટી તેને સામાન્ય નેટવર્ક એરર વિશે ચર્ચા કરતા ફકરાઓ કરતા નીચે રેટ કરી શકે છે. બીજી તરફ, BM25 ચોક્કસ સ્ટ્રિંગ્સ શોધી કાઢે છે પરંતુ વૈચારિક સંબંધો (conceptual relatedness) ચૂકી જાય છે. તમારે બંનેની જરૂર છે.
અમે વેક્ટર સર્ચ અને BM25 સમાંતર રીતે ચલાવીએ છીએ. પછી અમે પરિણામોને Reciprocal Rank Fusion, અથવા RRF સાથે જોડીએ છીએ, જે બે અલગ-અલગ સર્ચ સ્પેસના સ્કોર્સને એક જ સ્કેલમાં લાવ્યા વગર નોર્મલાઇઝ કરે છે. ફ્યુઝન પછી, અમે ટોપ ઉમેદવારોને cross-encoder reranker દ્વારા મોકલીએ છીએ. આ થોડી લેટન્સી ઉમેરે છે, પરંતુ ચોકસાઈમાં (precision) નોંધપાત્ર વધારો થાય છે. રિરૅન્કર ક્વેરી અને દરેક ઉમેદવારને સાથે વાંચે છે અને સુસંગતતા સ્કોર (relevance score) આપે છે જે પ્રારંભિક એમ્બેડિંગની કોસાઇન સિમિલારિટી કરતા ઘણો વધુ સચોટ હોય છે. વ્યવહારમાં, આ સંયોજન એવા ચોક્કસ એરર કોડ્સ પકડી લે છે જે શુદ્ધ વેક્ટર સર્ચ ચૂકી જાય છે, જ્યારે કીવર્ડ સર્ચ અવગણી શકે તેવા વૈચારિક રીતે સંબંધિત ટ્રબલશૂટિંગ સ્ટેપ્સ પણ સામે લાવે છે.
ક્વેરી એક્સપાન્શન: ઇન્ડેક્સ સુધી પહોંચતા પહેલા યુઝર ઇનપુટને સુધારવું
યુઝર્સ સંપૂર્ણ સર્ચ ક્વેરી લખતા નથી. તેઓ 'મારું છેલ્લું ડિપ્લોય શા માટે નિષ્ફળ ગયું અને હું તેને કેવી રીતે રોલબેક કરી શકું?' જેવા મલ્ટી-હોપ પ્રશ્નો પૂછે છે, જેના માટે જ્ઞાનના બે અલગ-અલગ સ્ત્રોતો શોધવા અને તેમને જોડવા જરૂરી છે. અથવા તેઓ અસ્પષ્ટ પ્રશ્નો પૂછે છે જે ઇન્ડેક્સ સાથે બરાબર મેચ થતા નથી.
We transform queries before searching. A multi-hop question gets broken into sub-questions. A vague intent gets expanded into multiple specific search queries. We found that expanding one user query into five distinct search queries can move recall from seventy-eight percent to ninety-six percent. This is not about prompting the LLM harder. It is about giving the retrieval system more shots at finding the right context. Each generated query captures a different angle or terminology, and the merged results paint a complete picture.
Bayesian Optimization: Stop Guessing
Once you have multiple chunking strategies, hybrid retrieval, and query expansion, you face a new problem. There are too many knobs. Chunk size, overlap percentage, vector weight versus BM25 weight, reranking thresholds, and top-k values all interact in nonlinear ways. Manual tuning becomes a guessing game.
We stopped guessing. We treat the