મોટાભાગના RAG ટ્યુટોરિયલ્સ નોટબુક પર જ પૂરા થઈ જાય છે. તેઓ થોડા વ્યવસ્થિત PDFs લોડ કરે છે, દર હજાર કેરેક્ટરમાં ટેક્સ્ટને વિભાજિત કરે છે, ફ્રેગમેન્ટ્સને વેક્ટર ડેટાબેઝમાં નાખે છે, અને તેને આર્કિટેક્ચર કહે છે. શુક્રવારની બપોરે, તે ડેમો પરફેક્ટલી ચાલે છે. પરંતુ પ્રોડક્શનમાં, એ જ પાઇપલાઇન શાંતિથી એક જવાબદારી (liability) માં બદલાઈ જાય છે.
રિટ્રીવલ સિસ્ટમમાં સાચો બોટલનેક (bottleneck) ભાગ્યે જ મોડલ અથવા પ્રોમ્પ્ટ હોય છે. તે ઇન્જેશન (ingestion) છે. RAG પાઇપલાઇન ફક્ત તે જ રિટ્રીવ કરી શકે છે જે તેને આપવામાં આવ્યું હોય, અને જો ફીડ ઘોંઘાટવાળું (noisy), જૂનું (stale) અથવા અધૂરું હોય, તો મોડલ આત્મવિશ્વાસ સાથે ખોટી માહિતી આપશે. જ્યારે વપરાશકર્તાઓ ફરિયાદ કરે છે કે બોટે 'હેલ્યુસિનેશન' (hallucinated) કર્યું છે, ત્યારે ભૂલ ઘણીવાર ડેટા પાઇપલાઇનમાં ઉપરના સ્તરે હોય છે જેનું કોઈ નજીકથી નિરીક્ષણ કરતું નથી.
વ્હાઇટબોર્ડ ટ્રેપ
આર્કિટેક્ચર ડાયાગ્રામ ઇન્જેશનને “Documents → Vector DB” લેબલવાળા એક સિંગલ એરો જેવું બતાવે છે. વાસ્તવિકતા વધુ જટિલ છે. સોર્સ સિસ્ટમ્સ જાણ કર્યા વગર બદલાય છે. HTML લેઆઉટનું રિડિઝાઇન થાય છે. URLs જનરિક લેન્ડિંગ પેજ પર રીડાયરેક્ટ થાય છે. JavaScript ફ્રેમવર્ક પ્રારંભિક HTTP રિસ્પોન્સ પછી કન્ટેન્ટ બદલી નાખે છે. ઇન્જેશનને વન-ટાઇમ સેટઅપ કાર્ય તરીકે ગણવું એ પહેલી ભૂલ છે. તે ડેટા એન્જિનિયરિંગની એક સતત ચાલતી સમસ્યા છે જેને કોઈપણ ETL પાઇપલાઇન જેટલી જ ચોકસાઈની જરૂર છે.
RAG નિષ્ફળતાઓ સામાન્ય રીતે ફીડ નિષ્ફળતાઓ કેમ હોય છે?
આ કલ્પના કરો: એક વપરાશકર્તા તમારા ઇન્ટરનલ આસિસ્ટન્ટને વર્તમાન રિફંડ પોલિસી વિશે પૂછે છે. મોડલ વેક્ટર સ્ટોર માંથી ટોપ ચંક (chunk) ખેંચે છે અને 30 દિવસનો સમયગાળો જણાવે છે. વાસ્તવિક પોલિસી ગયા ક્વાર્ટરમાં બદલાઈને 60 દિવસ થઈ ગઈ હતી. LLM એ ખોટો જવાબ બનાવ્યો નહોતો. તેણે ખરાબ ઇનપુટ પર વિશ્વાસ કર્યો હતો. રિટ્રીવલ લેયરે જૂનું પેજ આપ્યું હતું, અને કારણ કે એમ્બેડિંગ (embedding) અર્થપૂર્ણ રીતે (semantically) પૂરતું નજીક લાગતું હતું, તેથી મોડલે તેને સત્ય (ground truth) તરીકે ગણ્યું.
આ પેટર્ન સતત પુનરાવર્તિત થાય છે. જ્યારે કોર્પસ (corpus) નેવિગેશન ફૂટર્સ, ડુપ્લીકેટ પ્રેસ રિલીઝ અને ટેબલને અડધા ભાગમાં વિભાજિત કરતા ચંક્સથી ભરેલું હોય, ત્યારે ટીમો ટેમ્પરેચર (temperature) અને top-k ને ટ્વીક કરવામાં કલાકો બગાડે છે. જનરેશનને ઓપ્ટિમાઇઝ કરતા પહેલા, તમારું સિસ્ટમ શું જાણવા માટે સક્ષમ છે તેનું ઓડિટ કરો.
સાત ટ્રેપ્સ જે ઇન્જેશનને નષ્ટ કરે છે
1. પ્રથમ રન એક જૂઠ છે
તમારા પ્રારંભિક ક્રોલ (crawl) પર લીલું ચેકમાર્ક હોવાનો લગભગ કોઈ અર્થ નથી. પ્રોડક્શન ડેટા જીવંત હોય છે. ડોક્યુમેન્ટેશન પેજ રિફેક્ટર થાય છે, બ્લોગ પરમાલિંક્સ તૂટી જાય છે, અને સાઇટમેપ્સ શાંતિથી સેક્શન છોડી દે છે. જો તમે ફક્ત એ જ ચકાસો છો કે પાઇપલાઇન કોઈ ભૂલ વગર પૂર્ણ થઈ છે, તો તમે અંધારામાં વિમાન ઉડાવી રહ્યા છો. તમારે આઉટપુટને વેલિડેટ કરવાની જરૂર છે. તપાસો કે અપેક્ષિત દસ્તાવેજો હાજર છે, તેમનું માળખું હજુ પણ પાર્સ (parse) થાય છે, અને ટેક્સ્ટનું કુલ પ્રમાણ ઘટ્યું નથી કારણ કે કોઈ સોર્સે પરિણામોને અલગ રીતે પેજીનેટ (paginate) કરવાનું નક્કી કર્યું હોય.
2. ક્રોલિંગ એ ઇન્જેશન નથી
HTML ફેચ કરવું એ સરળ ભાગ છે. એક રો (raw) ક્રોલ બધું જ કેપ્ચર કરે છે: કૂકી બેનર્સ, "Related Articles" સાઇડબાર, એડ બ્લોક્સ અને ફૂટર કોપીરાઇટ નોટિસ. જો તમે તે રો HTML ને સીધું જ ચંક (chunk) કરો છો, તો ટેક્સ્ટના દરેક ટુકડા સાથે નેવિગેશન મેનૂના ટુકડાઓ પણ આવશે. જ્યારે વપરાશકર્તા API રેટ લિમિટ વિશે પૂછે છે, ત્યારે રિટ્રીવર એવો ચંક બતાવી શકે છે જે 40 ટકા સાઇડબાર લિંક્સ હોય. ક્લીન એક્સટ્રેક્શન (clean extraction) મહત્વનું છે. તમારે મુખ્ય કન્ટેન્ટ એરિયા ઓળખવો જોઈએ, બોઇલરપ્લેટ (boilerplate) દૂર કરવી જોઈએ અને દરેક પેજ પર પુનરાવર્તિત થતા એલિમેન્ટ્સને દૂર કરવા જોઈએ. અન્યથા તમે નોલેજ બેઝ નથી બનાવી રહ્યા, તમે વેબસાઇટના 'ક્રોમ' (UI elements) માટે સર્ચ એન્જિન બનાવી રહ્યા છો.
3. ચંકિંગ અર્થ તોડી નાખે છે
લગભગ દરેક ક્વિકસ્ટાર્ટ ગાઇડમાં ફિક્સ્ડ-સાઇઝ ચંકિંગ (fixed-size chunking) ડિફોલ્ટ છે, અને તે જોખમી છે. જો તમે દસ્તાવેજને ફક્ત કેરેક્ટર કાઉન્ટ દ્વારા વિભાજિત કરશો, તો તમે ટેબલને વચ્ચેથી કાપી નાખશો, નંબરવાળી પ્રક્રિયામાં સ્ટેપ 4 અને 5 ને અલગ કરી દેશો, અને બુલેટ પોઈન્ટ્સને તેમના હેડિંગ્સથી અલગ કરી દેશો. પ્રાઇસિંગ ટેબલનો માત્ર બીજો અડધો ભાગ ધરાવતો ચંક અર્થપૂર્ણ રીતે નકામો છે. સ્ટ્રક્ચર-અવેર ચંકિંગ (structure-aware chunking) મૂળ ફોર્મેટનું સન્માન કરે છે. હેડિંગ હાયરાર્કીને પાર્સ કરો. શક્ય હોય ત્યાં સુધી ટેબલને અકબંધ રાખો. સમાન H2 અથવા H3 હેઠળ પેરાગ્રાફની સીમાઓ પર વિભાજિત કરો. જો લિસ્ટ ટૂંકા હોય તો તેને સિંગલ ચંકની અંદર જ રાખો. ધ્યેય સમાન કદના બ્લોક્સ બનાવવાનો નથી, પરંતુ અર્થપૂર્ણ એકમો (coherent units of meaning) બનાવવાનો છે.
4. ફ્રેશનેસ (Freshness) ની સમસ્યા
આંતરિક વિકી (internal wiki) નો સ્ટેટિક સ્નેપશોટ એ સરળ મોડ છે. લાઈવ વેબમાંથી સતત ડેટા ઇન્જેસ્ટ (ingesting) કરવો મુશ્કેલ છે. તમારે જાણવું જરૂરી છે કે પેજ છેલ્લે ક્યારે મેળવવામાં આવ્યું હતું, ત્યારથી તેમાં કોઈ ફેરફાર થયો છે કે નહીં, અને તે માહિતી કેટલા સમય સુધી માન્ય રહેશે. જૂનો ડેટા (Stale data) એટલે હંમેશા દેખીતી રીતે જૂની તારીખ એવું નથી હોતું. ક્યારેક પેજ તેના લખાણમાં અપડેટ કરે છે પરંતુ તે જ URL રાખે છે, તેથી કન્ટેન્ટ હેશિંગ (content hashing) વગર તમારું સિસ્ટમ ક્યારેય તે બદલાવને નોંધશે નહીં. સ્ત્રોતની અસ્થિરતા (volatility) ના આધારે સ્પષ્ટ રિફ્રેશ નિયમો બનાવો. નાણાકીય ડેટા ફીડ માટે કદાચ દર કલાકે તપાસની જરૂર પડી શકે છે. કંપનીના 'અબાઉટ' (about) પેજ માટે કદાચ ત્રિમાસિક તપાસની જરૂર પડી શકે છે. ટાઇમસ્ટેમ્પ રેકોર્ડ કરો અને time-to-live મર્યાદાઓ સેટ કરો, ખાસ કરીને જો તમારું ડોમેન નિયમનકારી અથવા સુરક્ષા-મહત્વપૂર્ણ માર્ગદર્શન સાથે જોડાયેલું હોય જ્યાં જૂના તથ્યો વાસ્તવિક નુકસાન પહોંચાડી શકે છે.
5. ડુપ્લીકેટ પ્રદૂષણ (Duplicate Pollution)
વેબસાઇટ્સ પુનરાવર્તનથી ભરેલી હોય છે. સમાન પ્રોડક્ટ ડિસ્ક્રિપ્શન કેટેગરી પેજ, પ્રોડક્ટ પેજ અને પ્રમોશનલ લેન્ડિંગ પેજ પર દેખાય છે. સમાન પ્રેસ રિલીઝ /news/, /press/, અને /blog/ હેઠળ હોય છે. વેક્ટર સર્ચ આપમેળે ડુપ્લીકેટ દૂર (deduplicate) કરતું નથી. જો તમારા ડેટાબેઝમાં દસ લગભગ સમાન ચંક્સ (chunks) હોય, તો તેઓ તમારા top-k રિટ્રીવલમાં વિવિધ અને સુસંગત પરિણામોને નડે છે. એમ્બેડિંગ (embedding) પહેલાં તમારે કેનોનિકલ ટ્રેકિંગ અથવા કન્ટેન્ટ ડુપ્લીકેશનની જરૂર છે. જો બે ચંક્સ એક જ વાત કહેતા હોય, તો અધિકૃત સ્ત્રોત રાખો અને નકલો કાઢી નાખો. તમારા રિટ્રીવર પાસે મર્યાદિત સ્લોટ્સ છે. તેને વેડફવા ન દો.
6. ખૂટતો મેટાડેટા (Missing Metadata)
મેટાડેટા વગરનો વેક્ટર ડેટાબેઝ એ સંદર્ભ (context) ની કોઈ યાદશક્તિ વગરનું માત્ર એક ડેન્સ ટેક્સ્ટ સર્ચ એન્જિન છે. સ્માર્ટ રિટ્રીવલ ફિલ્ટરિંગ અને રેન્કિંગ સિગ્નલ્સ પર આધાર રાખે છે જે રો (raw) એમ્બેડિંગ્સ આપી શકતા નથી. સ્ત્રોત URL, કેપ્ચર તારીખ, દસ્તાવેજની શ્રેણી અને વર્ઝન નંબર સ્ટોર કરો. જો તમે API ડોક્યુમેન્ટેશન ઇન્જેસ્ટ કરો છો, તો વર્ઝનિંગ આવશ્યક છે. તેના વગર, એક ક્વેરી v1 અને v2 સ્પેક્સને એક જ જવાબમાં ભેળવી શકે છે. જો તમે HR પોલિસી ઇન્જેસ્ટ કરો છો, તો પ્રદેશ અથવા વિભાગ દ્વારા ટેગિંગ તમને મોડેલ સુધી પહોંચતા પહેલા જ પરિણામો ફિલ્ટર કરવા દે છે. મેટાડેટા ટેક્સ્ટ ડમ્પને એક ક્યુરેટેડ નોલેજ સિસ્ટમમાં ફેરવે છે.
7. JavaScript ગેપ્સ (JavaScript Gaps)
આધુનિક સાઇટ્સ તેમના કન્ટેન્ટને પ્રથમ HTML પેલોડમાં મોકલતી નથી. તેઓ એક સ્કેલેટન (skeleton) મોકલે છે અને તેને JavaScript કોલ્સ દ્વારા હાઇડ્રેટ (hydrate) કરે છે. એક બેઝિક HTTP રિક્વેસ્ટમાં લોડિંગ સ્પિનર અને લેઆઉટ શેલ સિવાય બીજું કંઈ દેખાશે નહીં. જો તમારું પાઇપલાઇન JavaScript એક્ઝિક્યુટ કરી શકતું નથી, તો તમે ખાલી પેજ અથવા આંશિક ફ્રેગમેન્ટ્સ ઇન્જેસ્ટ કરશો અને ક્યારેય સમજી શકશો નહીં કે કંઈક ખોટું છે. હેડલેસ બ્રાઉઝરનો ઉપયોગ કરવાથી રેન્ડરિંગની સમસ્યા ઉકેલાય છે પરંતુ નવી સમસ્યાઓ ઊભી થાય છે: વધુ મેમરી વપરાશ, ધીમો થ્રુપુટ અને બોટ ડિટેક્શન વોલ્સ. તમારા ટ્રેડ-ઓફ્સ (trade-offs) જાણીજોઈને પસંદ કરો, પરંતુ એવું માની ન લો કે દરેક સ્ત્રોત માટે સાદું curl પૂરતું છે.
એક વ્યવહારુ ઇન્જેસ્ટન ચેકલિસ્ટ (A Practical Ingestion Checklist)
જો તમે RAG ફીડ બનાવી રહ્યા હોવ અથવા તેની સમીક્ષા કરી રહ્યા હોવ, તો અહીંથી શરૂઆત કરો:
- સ્ત્રોત કવરેજ અને પેજીનેશનની ચકાસણી કરો. સાઇટમેપ કદાચ કોઈ કેટેગરીમાં ફક્ત પ્રથમ દસ લેખોની યાદી આપી શકે છે. ઊંડાણપૂર્વક ક્રોલ કરો અને ખાતરી કરો કે પેજીનેટેડ અથવા ડાયનેમિકલી લોડ થયેલ કન્ટેન્ટ ખરેખર કેપ્ચર કરવામાં આવ્યું છે.
- ચંકિંગ પહેલા બૉઇલરપ્લેટ દૂર કરો. નેવિગેશન, જાહેરાતો, ફૂટર્સ અને વારંવાર આવતા કાનૂની ડિસ્ક્લેમર્સ દૂર કરો. જો કોઈ શબ્દસમૂહ દરેક પેજ પર દેખાય છે, તો તે નોઈઝ (noise) છે.
- સ્ટ્રક્ચર-અવેર ચંકિંગનો ઉપયોગ કરો. હેડિંગ્સ, બુલેટ લિસ્ટ અને ટેબલ્સનું સન્માન કરો. કેરેક્ટર કાઉન્ટને બદલે સેમેન્ટિક બાઉન્ડ્રીઝ (semantic boundaries) પર વિભાજિત કરો.
- રિચ મેટાડેટા જોડો. URL, કેપ્ચર તારીખ, કન્ટેન્ટ કેટેગરી અને વર્ઝન સામેલ કરો. તમારા રિટ્રીવલ ક્વેરીઝમાં આ ફિલ્ડ્સ ફિલ્ટર કરી શકાય તેવા બનાવો.
- ડેટાની અસ્થિરતાના આધારે રિફ્રેશ ફ્રીક્વન્સી સેટ કરો. વધુ ફેરફાર થતા સ્ત્રોતોને વારંવાર રી-ક્રોલની જરૂર હોય છે. સ્ટેટિક આર્કાઇવ્સને નહીં.
- માત્ર જોબ સ્ટેટસ જ નહીં, પણ કોર્પસ (corpus) પર પણ નજર રાખો. એક પાઇપલાઇન કચરો (garbage) ઉત્પન્ન કરતી વખતે પણ કોડ ઝીરો સાથે એક્ઝિટ થઈ શકે છે. ડ્રિફ્ટ અને ગુણવત્તા માટે સ્ટોર કરેલા ચંક્સના સેમ્પલનું નિયમિત ઓડિટ કરો.
- વર્ઝનિંગ અને ડિલીશન માટે નિયમો નક્કી કરો. જ્યારે કોઈ સ્ત્રોત પેજ દૂર કરવામાં આવે, ત્યારે તેના ચંક્સ પણ ડિલીટ કરો. જ્યારે તે અપડેટ થાય, ત્યારે તેને ઓવરરાઈટ કરો અથવા વર્ઝન કરો. ઓર્ફેન્ડ ડેટા (Orphaned data) એ સાયલન્ટ કિલર છે.
એમ્બેડિંગ્સ વિશેની કડવી વાસ્તવિકતા (The Hard Truth About Embeddings)
કોઈ પણ એમ્બેડિંગ મોડેલ, તે ગમે તેટલું અદ્યતન હોય, ખૂટતા દસ્તાવેજને સુધારી શકતું નથી. જો તમારું ફીડ હજુ પણ ગયા વર્ષની નકલ ધરાવતું હોય, તો તે અનુમાન લગાવી શકતું નથી કે પેજ ગયા અઠવાડિયે અપડેટ કરવામાં આવ્યું હતું. તે ટેબલ રો (row) ના સંદર્ભનો અંદાજ લગાવી શકતું નથી જે ખરાબ ચંક બાઉન્ડરીને કારણે તેના હેડરથી અલગ પડી ગયું હોય. એમ્બેડિંગ્સ અર્થને કોમ્પ્રેસ કરે છે, પરંતુ જ્યાં ઇન્જેસ્ટન લેયર તેનો જાળવી રાખવામાં નિષ્ફળ ગયું હોય ત્યાં તેઓ અર્થનું સર્જન કરી શકતા નથી.
રિટ્રીવલની ગુણવત્તા ઇન્જેસ્ટન લેયરથી શરૂ થાય છે. તે લેયર નક્કી કરે છે કે તમારું RAG સિસ્ટમ એક ઉપયોગી સાધન છે કે તેની પાછળ વેક્ટર ડેટાબેઝ ધરાવતો માત્ર એક આત્મવિશ્વાસપૂર્ણ જૂઠું બોલનાર છે.
મુખ્ય તારણ (The Real Takeaway)
માત્ર પાઇપલાઇન ડેશબોર્ડ્સ દ્વારા ઇન્જેશન હેલ્થ માપવાનું બંધ કરો. ગ્રીન જોબ્સ અને ક્લીન લોગ્સ એ ક્લીન કોર્પસની ખાતરી આપતા નથી. ડેટાબેઝ ખોલો અને તમારા વપરાશકર્તાઓ જે વાસ્તવિક ચંક્સ મેળવશે તે વાંચો. જો ટેક્સ્ટ કોપીરાઈટ નોટિસ, વિભાજિત ટેબલ્સ અને જૂના પોલિસી પેજથી ભરેલું હોય, તો તમારી સમસ્યા LLM નથી. પહેલા ફીડ સુધારો. બાકી બધું કચરા પર કરવામાં આવતું ટ્યુનિંગ છે.