Most teams build their first retrieval system the same way: slice every document into fixed 512 token chunks, push them

મોટાભાગની ટીમો તેમની પ્રથમ રીટ્રીવલ સિસ્ટમ એક જ રીતે બનાવે છે: દરેક દસ્તાવેજને ફિક્સ્ડ 512-ટોકન ચંક્સમાં કાપી નાખવા, તેને વેક્ટર ડેટાબેઝમાં મોકલવા અને એમ્બેડિંગ મોડલ બધું કામ કરી લેશે તેવી આશા રાખવી. આ આશા તમને ડેમોમાં તો સફળ કરી શકે છે, પરંતુ વાસ્તવિક વપરાશકર્તાઓ સાથેના ઉપયોગમાં તે ટકી શકતી નથી.

પ્રોડક્શનમાં, જ્યારે તમે કોઈ જવાબદારીની કલમને તેના અપવાદોથી અલગ કરી દો છો, ત્યારે કાનૂની કરાર નિષ્ફળ જાય છે. જ્યારે કોડ સેમ્પલ તેના ફંક્શન સિગ્નેચરથી અલગ થઈ જાય છે, ત્યારે API ડોક્યુમેન્ટેશન નકામું બની જાય છે. જ્યારે તમે કોઈ એક ફરિયાદને તેની વાતચીતના ઇતિહાસમાંથી અલગ કરી દો છો, ત્યારે કસ્ટમર સપોર્ટ થ્રેડ માત્ર અવાજ (noise) બની જાય છે. સમસ્યા ભાગ્યે જ પાઇપલાઇનના અંતે રહેલા લેંગ્વેજ મોડલની હોય છે. સમસ્યા એ છે કે તમે તેને કેવો ડેટા આપો છો.

અમે આ કઠિન અનુભવ દ્વારા શીખ્યા છીએ. અમારું પ્રારંભિક રીટ્રીવલ લેયર પ્રમાણભૂત લાગતું હતું પરંતુ તેનું વર્તન અસ્થિર હતું. તેથી અમે તેને એક સરળ વિચાર સાથે ફરીથી બનાવ્યું: રીટ્રીવલને જાદુ તરીકે નહીં, પણ એક માપણીપાત્ર ઇન્ફ્રાસ્ટ્રક્ચર તરીકે ગણો. અહીં બરાબર શું બદલાયું અને કેવી રીતે અમે 95th-percentile લેટન્સીને 850 ms થી ઘટાડીને 320 ms કરીને, રિકોલને 95 ટકા સુધી પહોંચાડ્યો તેની વિગત છે.

ફિક્સ્ડ-ચંકનો જાળ

સમાન ટોકન કાઉન્ટ કોડ કરવા અને સમજાવવા માટે સરળ છે. આ સુવિધા એક મૂળભૂત સત્યને છુપાવે છે: દસ્તાવેજોનું પોતાનું એક માળખું હોય છે. જ્યારે તમે તે માળખાને અવગણો છો, ત્યારે તમે મહત્વની માહિતી (signal) ને નષ્ટ કરો છો.

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

અમે ચંક સાઈઝને માત્ર અંદાજિત હાયપરપેરામીટર તરીકે લેવાનું બંધ કર્યું. અમે તેને દસ્તાવેજના પ્રકાર અને તેની અંદરના ઇન્ફોર્મેશન આર્કિટેક્ચર વચ્ચેના મેપિંગ એક્સરસાઇઝ તરીકે જોવાનું શરૂ કર્યું.

તમારા ચંકિંગને ડેટા સાથે મેળવો

આનો ઉકેલ કોઈ એક સંપૂર્ણ ચંક સાઈઝ નથી. ઉકેલ એ ત્રણ અલગ-અલગ ડેટા આકાર માટે તૈયાર કરેલી ત્રણ અલગ-અલગ વ્યૂહરચનાઓ છે.

કાનૂની દસ્તાવેજો (Legal documents) હવે રિકર્સિવ સ્પ્લિટિંગમાંથી પસાર થાય છે. અલ્ગોરિધમ પહેલા સૌથી મોટી કુદરતી સીમાઓ શોધે છે—સેક્શન, પછી સબ-સેક્શન, અને પછી નંબરવાળી કલમો—અને જ્યારે જરૂરી હોય ત્યારે જ નાના સ્પ્લિટ્સનો ઉપયોગ કરે છે. આનાથી ટર્મિનેશન ક્લોઝ તેની શરતો સાથે જોડાયેલ રહે છે. રીટ્રીવલ સ્ટેપ સંપૂર્ણ લોજિકલ યુનિટ્સ જુએ છે, જે મોડલ દ્વારા ખૂટતા અપવાદોની કાલ્પનિક માહિતી બનાવવાની શક્યતાને નોંધપાત્ર રીતે ઘટાડે છે.

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

સપોર્ટ અને વાતચીતનો ડેટા (Support and conversational data) સેમેન્ટિક ચંકિંગનો ઉપયોગ કરે છે. ટોકન્સ ગણવાને બદલે, અમે ટોપિક અથવા ઇન્ટેન્ટમાં આવતા ફેરફારોને જોઈએ છીએ. જો કોઈ ગ્રાહક ત્રીજા મેસેજમાં બગનું વર્ણન કરે છે અને સાતમા મેસેજમાં સ્ટેક ટ્રેસ પેસ્ટ કરે છે, તો અમે મેસેજ ઇન્ડેક્સને બદલે અર્થ (meaning) મુજબ ચંક કરીએ છીએ. રીટ્રીવલ લેયર પછી કોઈ એકલવ વાક્યને બદલે સમસ્યાનો સંપૂર્ણ પ્રવાહ રિટર્ન કરે છે.

માત્ર વેક્ટર સર્ચ કેમ નિષ્ફળ જાય છે

સંપૂર્ણ ચંક્સ પણ શુદ્ધ વેક્ટર સર્ચમાં નિષ્ફળ જાય છે. ડેન્સ એમ્બેડિંગ્સ અર્થ અને સમાનાર્થી શબ્દોને પકડવામાં ઉત્તમ છે, પરંતુ ચોક્કસ સ્ટ્રિંગ્સ બાબતે તેઓ અસ્પષ્ટ હોય છે. જો કોઈ એન્જિનિયર ચોક્કસ એરર કોડ ERR_CONNECTION_REFUSED માટે સર્ચ કરે છે, તો વેક્ટર સિમિલારિટી ડઝનબંધ વૈચારિક પડોશીઓ રિટર્ન કરી શકે છે અને રૅન્ક ચૌદમાં દબાયેલ ચોક્કસ મેચને ચૂકી શકે છે.

BM25 સાથેના કીવર્ડ સર્ચમાં તેની વિરુદ્ધ સમસ્યા છે. તે ચોક્કસ ટોકન્સ શોધે છે પરંતુ સેમેન્ટિક ઇન્ટેન્ટ ચૂકી જાય છે. "મારું ડેટાબેઝ કેમ ડાઉન છે" પૂછનાર યુઝર ક્યારેય એવા દસ્તાવેજ સાથે મેચ થશે નહીં જેમાં "troubleshooting connection timeouts" લખ્યું હોય.

અમે હવે બંનેનો ઉપયોગ કરીએ છીએ. વેક્ટર અને કીવર્ડ પરિણામોને Reciprocal Rank Fusion માં મોકલવામાં આવે છે, જે કેલિબ્રેટેડ સ્કોર્સની જરૂરિયાત વિના બંને

વપરાશકર્તાઓ આદર્શ સર્ચ ક્વેરીઝ લખતા નથી. તેઓ અધૂરી લોગ લાઇન પેસ્ટ કરે છે. તેઓ “it’s broken” (તે બગડી ગયું છે) એવું લખે છે. તેઓ એવા શબ્દો (jargon) વાપરે છે જે તમારા ડોક્યુમેન્ટેશનમાં ક્યારેય વપરાયા નથી. જો તમે કાચી ક્વેરી પર વિશ્વાસ કરો છો, તો તમે માત્ર ઘોંઘાટ (noise) પર વિશ્વાસ કરી રહ્યા છો.

અમે હવે દરેક આવતી ક્વેરીને રિટ્રીવલ લેયર (retrieval layer) પર મોકલતા પહેલા ત્રણ થી પાંચ વિવિધતાઓમાં વિસ્તૃત કરીએ છીએ. એક વેરિએશન સીધું પેરાફ્રેઝિંગ (paraphrase) હોઈ શકે છે. બીજું કદાચ એક કાલ્પનિક આદર્શ ડોક્યુમેન્ટ ટાઇટલ હોઈ શકે છે. ત્રીજું વેરિએશન વાતચીત દરમિયાન વપરાતા વધારાના શબ્દોને દૂર કરીને માત્ર ટેકનિકલ કીવર્ડ્સને અલગ તારવે છે. દરેક વેરિએન્ટને એમ્બેડ (embed) કરવામાં આવે છે અને તેના પર સર્ચ કરવામાં આવે છે. ત્યારબાદ અમે કેન્ડિડેટ પૂલ્સને ડુપ્લીકેટમાંથી મુક્ત કરીએ છીએ અને મર્જ કરીએ છીએ.

આ મફત નથી. તે વધારાના એમ્બેડિંગ કોલ્સ માટે પૈસા ખર્ચાય છે અને થોડા મિલિસેકન્ડનો સમય લાગે છે. પરંતુ રિકોલ (recall) પર તેની અસર નાટકીય હતી: ક્વેરીઝને રિટ્રીવલ પહેલા વિસ્તૃત કરીને અમે 78 ટકાથી 96 ટકા સુધી પહોંચ્યા. કારણ કે બહેતર રિટ્રીવલ જનરેશન વિન્ડોને નાની કરે છે અને મોડેલને સાચા સંદર્ભ (context) સાથે જોડે છે, જેનાથી અંતે અમારો ખર્ચ ઘટ્યો. રિટ્રીવલ સ્ટેપ થોડું મોંઘું હોવું એ લાંબા અને ભ્રામક (hallucinated) જનરેશન સ્ટેપ કરતા સસ્તું છે.

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

એકવાર અમારી પાસે યોગ્ય ચંકિંગ (chunking), હાઇબ્રિડ રિટ્રીવલ અને ક્વેરી એક્સપાન્શન આવી ગયા પછી પણ, અમે એક જટિલ સમસ્યાનો સામનો કરી રહ્યા હતા. ચંક સાઈઝ, ચંક ઓવરલેપ, top-k રિટ્રીવલ ડેપ્થ, રેરન્કર કટઓફ્સ અને ફ્યુઝન વેટ્સ - આ બધું એકબીજા સાથે જોડાયેલું છે. મેન્યુઅલ ગ્રીડ સર્ચ કરવામાં અઠવાડિયાઓ લાગત અને તેમ છતાં પણ તે શ્રેષ્ઠ પરિણામ આપી શક્યું હોત નહીં.

અમે આ સ્પેસને એક્સપ્લોર કરવા માટે Bayesian optimization નો ઉપયોગ કર્યો. દરેક કોમ્બિનેશનનું સંપૂર્ણ પરીક્ષણ કરવાને બદલે, સર્ચ અલ્ગોરિધમ એવું માનીને ચાલે છે કે કયા કોન્ફિગરેશન સારું પ્રદર્શન કરી શકે છે અને ધીમે ધીમે તે સંભવિત ક્ષેત્રો પર ધ્યાન કેન્દ્રિત કરે છે.

આ આઉટપુટ કોઈ એક પરફેક્ટ સેટિંગ નથી. તે પસંદગીઓનું એક Pareto frontier છે. એક છેડે, અમારી પાસે અમારા હાઇ-થ્રુપુટ API સપોર્ટ એન્ડપોઇન્ટ માટે ઓપ્ટિમાઇઝ કરેલ લિન (lean) કોન્ફિગરેશન છે: ઝડપી ઇન્ફરન્સ, મધ્યમ રિકોલ અને શક્ય તેટલો ઓછો લેટન્સી (latency). બીજા છેડે, લીગલ રિવ્યુ માટે એક એગ્રેસિવ કોન્ફિગરેશન છે: ઊંડું રિટ્રીવલ, ભારે રેરન્કિંગ અને વધુ ઓવરલેપ, જે ચોકસાઈ માટે થોડા મિલિસેકન્ડનો ત્યાગ કરે છે. કારણ કે આ ફ્રન્ટિયર સ્પષ્ટ છે, તેથી અમે "એક જ સાઈઝ બધા માટે" (one size fits all) એવું માનવાને બદલે પ્રોડક્ટ માટે યોગ્ય પોઈન્ટ પસંદ કરી શકીએ છીએ.

આંકડા ખરેખર કેવા દેખાય છે

આ ફેરફારોએ સિસ્ટમને એક નાજુક પ્રોટોટાઇપમાંથી માપન કરી શકાય તેવા પ્રોડક્શન પાઇપલાઇનમાં બદલી નાખી.

Recall at ten 78 ટકાથી વધીને 95 ટકા થયો. તેનો અર્થ એ છે કે જ્યારે અમારા કોર્પસમાં સાચો જવાબ હોય છે, ત્યારે અમે વીસમાંથી ઓગણીસ વખત તેને શોધી લઈએ છીએ.

95th percentile પર લેટન્સી 850 ms થી ઘટીને 320 ms થઈ ગઈ. હાઇબ્રિડ સ્ટેક કાગળ પર ભારે લાગે છે, પરંતુ સ્માર્ટ ઇન્ડેક્સિંગ, નાના રેરન્કર્સ અને જરૂર પડે ત્યારે જ એગ્રેસિવ ચંક્સ આપવાની ક્ષમતાએ આખી સિસ્ટમને ઝડપી બનાવી દીધી.

Hallucination rate — જેનું ટ્રેકિંગ માનવ એનોટેટર્સ દ્વારા ગોલ્ડન ડેટાસેટ પર કરવામાં આવ્યું હતું — તે 12 ટકાથી ઘટીને 3 ટકા થયો. જ્યારે મોડેલને સંપૂર્ણ અને સુસંગત સંદર્ભ મળે છે, ત્યારે તે તથ્યોની ખોટી રીતે રચના કરવાનું બંધ કરી દે છે.

પ્રતિ ક્વેરી ખર્ચ $0.008 થી ઘટીને $0.005 થયો. બહેતર રિટ્રીવલ એટલે ટૂંકા, વધુ ફોકસ કરેલા LLM પ્રોમ્પ્ટ્સ અને ઓછા રિકવરી પ્રયાસો. ક્વેરી એક્સપાન્શન પર થતો વધારાનો એમ્બેડિંગ ખર્ચ જનરેશનમાં થતી બચત સામે નહિવત છે.

ગોલ્ડન ડેટાસેટ બનાવો અને રિટ્રીવલને કોડની જેમ ગણો

જો તમે આમાંથી કંઈક શીખતા હોવ, તો તે માપનનું શિસ્ત (discipline of measurement) હોવું જોઈએ. અમે વાસ્તવિક પ્રશ્નો અને વેરિફાઇડ જવાબના લોકેશનનો એક નાનો ગોલ્ડન ડેટાસેટ બનાવ્યો છે. કોઈપણ ફેરફાર પ્રોડક્શનમાં આવે તે પહેલાં, તે તે ડેટાસેટ પર ટેસ્ટ કરવામાં આવે છે. રિકોલ અને લેટન્સીનું રીઅલ-ટાઇમમાં મોનિટરિંગ કરવામાં આવે છે, માત્ર નોટબુકમાં જોઈને અંદાજ નથી લગાવવામાં આવતો.

રિટ્રીવલ એ માત્ર રિસર્ચ ડેમો નથી. તે ઇન્ફ્રાસ્ટ્રક્ચર છે. તે તમારા બાકીના સ્ટેકની જેમ જ યુનિટ ટેસ્ટ, રિગ્રેશન બેન્ચમાર્ક અને ઓટોમેટેડ ઓપ્ટિમાઇઝેશનને પાત્ર છે. ચંકિંગ ડોક્યુમેન્ટ સ્ટ્રક્ચર મુજબ કરો, ટોકન પર આધારિત અંધશ્રદ્ધા મુજબ નહીં. વેક્ટર અને કીવર્ડ સર્ચને રેરન્કર સાથે જોડો. તમારા વપરાશકર્તાઓ ખરેખર જે ક્વેરી લખે છે તેને વિસ્તૃત કરો. પછી તમારા અંતર્જ્ઞાન (intuition) ને બદલે સર્ચ અલ્ગોરિધમને સેટિંગ્સ ટ્યુન કરવા દો.

અમે જે પાઇપલાઇનનું વર્ણન કર્યું છે તે માત્ર સૈદ્ધાંતિક નથી. તમે મૂળ લેખ અહીં વાંચી શકો છો, અને જો તમે આ બાબતોમાં રસ ધરાવતા સમુદાય સાથે રિટ્રીવલ એન્જિનિયરિંગ વિશે ચર્ચા કરવા માંગતા હોવ, તો GyaanSetu AI group ખુલ્લો છે.