મોટાભાગની ટીમો હજુ પણ તેમનું પ્રથમ રિટ્રીવલ પાઇપલાઇન (retrieval pipeline) એક જ રીતે બનાવે છે. તેઓ એક નિશ્ચિત ટોકન મર્યાદા પસંદ કરે છે, કદાચ 512, દસ્તાવેજોને સમાન બ્લોક્સમાં વિભાજિત કરે છે, અને તે બ્લોક્સને વેક્ટર ડેટાબેઝમાં ફીડ કરે છે. સરળ પ્રશ્નો ધરાવતા નાના ડેટાસેટ પર, આ જાદુઈ લાગે છે. પરંતુ પ્રોડક્શનમાં, તે નિષ્ફળ જાય છે.
જ્યારે કોઈ કલમ (clause) વાક્યની વચ્ચેથી કપાઈ જાય છે, ત્યારે કાનૂની કરારો અર્થહીન ટુકડાઓમાં વિભાજિત થઈ જાય છે. જો એક જ ચંક (chunk) ત્રણ અસંબંધિત ફંક્શન્સને સમાવી લે, તો API ડોક્યુમેન્ટેશન અસ્પષ્ટ માહિતીના મિશ્રણમાં ફેરવાઈ જાય છે. સેગમેન્ટ્સ વચ્ચે ઓવરલેપ વગર કસ્ટમર સપોર્ટ ટિકિટો તેમનો તમામ સંદર્ભ ગુમાવી દે છે. તેનું પરિણામ અનુમાનિત છે: વધેલી લેટન્સી (latency), નબળું રિકોલ (recall), અને એવા જવાબો જે જનરેટરને હેલ્યુસિનેટ (hallucinate) કરવા માટે મજબૂર કરે છે.
અમે અમારા રિટ્રીવલ લેયરને તોડી નાખ્યું અને તેને ફરીથી બનાવ્યું. તેનું પરિણામ રિકોલમાં 78 ટકાથી વધીને 95 ટકાનો ઉછાળો, લેટન્સીમાં 62 ટકાનો ઘટાડો, અને એક એવી પાઇપલાઇન હતી જે અંતે વીકેન્ડ હેક (weekend hack) ને બદલે વાસ્તવિક ઇન્ફ્રાસ્ટ્રક્ચરની જેમ કામ કરે છે. અહીં તે છે જે ખરેખર કામ કરી ગયું.
સ્માર્ટ ચંકિંગ: ટોકન્સ કરતાં સ્ટ્રક્ચરને મહત્વ આપો
પ્રથમ ભૂલ એ માનવીય છે કે દરેક દસ્તાવેજ એક જ ભાષા બોલે છે. 512-ટોકનનો ચંક敘ative ગદ્ય (narrative prose) માટે યોગ્ય છે અને અન્ય ક્યાંય નહીં. અમે એવી વ્યૂહરચના અપનાવી જે સ્ત્રોતની રચના (anatomy) ને માન આપે છે.
કાનૂની દસ્તાવેજો માટે, અમે રિકર્સિવ ચંકિંગ (recursive chunking) નો ઉપયોગ કરીએ છીએ. અલ્ગોરિધમ પહેલા સેક્શન અને આર્ટિકલ્સ જેવા ઉચ્ચ સ્તરીય સીમાઓ પર વિભાજિત કરવાનો પ્રયાસ કરે છે. જો સેક્શન હજુ પણ ઘણું લાંબું હોય, તો તે સબસેક્શન, પછી પેરાગ્રાફ અને પછી વાક્યો શોધે છે. આ કલમોના તાર્કિક નેસ્ટિંગને જાળવી રાખે છે. નોન-કમ્પીટ એગ્રીમેન્ટ (non-compete agreement) અકબંધ રહે છે. વ્યાખ્યાઓ ઇન્ડેમ્નિટી શરતોમાં ભળી જતી નથી.
API ડોક્યુમેન્ટેશન માટે સ્ટ્રક્ચર-અવેર ચંકિંગ (structure-aware chunking) જરૂરી છે. ફંક્શન સિગ્નેચર, તેની પેરામીટર ટેબલ અને તેનું એક્ઝામ્પલ રિક્વેસ્ટ સાથે હોવા જોઈએ. નિશ્ચિત ટોકન કાઉન્ટ પછી વિભાજિત કરવાથી ઘણીવાર પેરામીટર્સ એક ચંકમાં અને ઉદાહરણો બીજા ચંકમાં રહી જાય છે. તેના બદલે અમે ડોક્યુમેન્ટ ઓબ્જેક્ટ દ્વારા ચંકિંગ કરીએ છીએ. એક ચંકમાં સંપૂર્ણ એન્ડપોઇન્ટ અથવા એક સિંગલ ફંક્શન હોય છે. રિટ્રીવર પછી એક સ્વતંત્ર સંદર્ભ આપી શકે છે જે ખરેખર પ્રશ્નનો જવાબ આપે છે.
સપોર્ટ ટિકિટો કુદરતી રીતે સેમેન્ટિક ચંકિંગ (semantic chunking) માટે અનુકૂળ છે. ટોકન બોર્ડર પર કાપવાને બદલે, અમે વિષય ક્યાં બદલાય છે તે શોધીએ છીએ. એક ટિકિટ જે લોગિન ફરિયાદ સાથે શરૂ થાય છે અને બિલિંગ પ્રશ્ન તરફ વળે છે, તે બે સુસંગત ભાગોમાં વિભાજિત થાય છે. દરેક ભાગમાં જરૂરી મેટાડેટા હોય છે, અને મોડેલને હવે અંદાજ લગાવવો પડતો નથી કે વપરાશકર્તા ખરેખર કઈ સમસ્યા વિશે ચિંતિત છે.
ઇન્ટરનલ વિકિ (Internal wikis) વધુ અસ્તવ્યસ્ત હોય છે. તેમાં ગદ્ય, ટેબલ, ડાયાગ્રામ અને એમ્બેડેડ થ્રેડ્સનું મિશ્રણ હોય છે. આ માટે, અમે એજન્ટિક ચંકિંગ (agentic chunking) નો ઉપયોગ કરીએ છીએ. એક નાનું લેંગ્વેજ મોડેલ આગળ વાંચે છે અને નક્કી કરે છે કે થીમેટિકલી પૂર્ણ યુનિટ ક્યાં સમાપ્ત થાય છે. ઇન્જેશન (ingestion) સમયે તે થોડું વધુ ખર્ચાળ છે, પરંતુ તે દરેક નવા પેજ ફોર્મેટ માટે નિયમોને હાથથી ટ્યુન કરવાના માનવીય કામને દૂર કરે છે.
હાઇબ્રિડ રિટ્રીવલ: તમારા તમામ પાસાઓને આવરી લો
વેક્ટર સર્ચ અસ્પષ્ટ અર્થ (fuzzy meaning) પકડવામાં ઉત્તમ છે. સ્લો અપલોડ વિશે પૂછો અને તે લેટન્સી અને બેન્ડવિડ્થ વિશેના પેરાગ્રાફ ખુશીથી આપશે. પરંતુ તે ચોક્કસ મેચિંગ (exact matches) ને બગાડવા માટે જાણીતું છે. જો ડેવલપર ERR_CONNECTION_REFUSED એરર કોડ માટે સર્ચ કરે છે, તો ડેન્સ એમ્બેડિંગ્સ (dense embeddings) ઘણીવાર તેને સામાન્ય નોઈઝ તરીકે ગણશે.
BM25, ક્લાસિક કીવર્ડ અલ્ગોરિધમ, તેનાથી વિરુદ્ધ કામ કરે છે. તે ચોક્કસ સ્ટ્રિંગ્સ અને દુર્લભ શબ્દોને પકડી લે છે, છતાં તે સેમેન્ટિક સૂક્ષ્મતા (semantic nuance) ચૂકી જાય છે. કરાર પર સહી કરવા વિશેની ક્વેરી કદાચ 'executing the contract' તરીકે ટેગ કરેલ કન્ટેન્ટ ક્યારેય શોધી શકશે નહીં.