શા માટે આત્મવિશ્વાસપૂર્ણ જવાબ ન હોવા કરતાં વધુ ખરાબ હોઈ શકે છે
તમે ઇન્ટરનલ ચેટબોટ બનાવવાનું પૂરું કરો છો. તમે તેમાં તમારી કંપનીની દરેક HR પોલિસી, એન્જિનિયરિંગ સ્પેસિફિકેશન અને ઓનબોર્ડિંગ ડોક્યુમેન્ટ્સ ફીડ કરો છો. એક નવો કર્મચારી ક્લાયન્ટ ડિનર માટેના ટ્રાવેલ એક્સપેન્સ લિમિટ વિશે પૂછે છે. બોટ તરત જ જવાબ આપે છે. તે ખૂબ જ આત્મવિશ્વાસ સાથે લાગે છે. તે જે લિમિટ જણાવે છે તે વ્યક્તિ દીઠ $75 છે.
વાસ્તવિક પોલિસી $50 કહે છે. બોટે જવાબ જાતે જ બનાવ્યો હતો. તેણે ક્યારેય તમારી ફાઇલો ખોલી નહોતી. તેણે ફક્ત વર્ષો પહેલા તેના ટ્રેનિંગ ડેટામાં છુપાયેલા પેટર્ન પરથી અનુમાન લગાવ્યું હતું. ખાનગી દસ્તાવેજો સામે રૉ (raw) લાર્જ લેંગ્વેજ મોડલ્સ ચલાવવાની આ કડવી વાસ્તવિકતા છે. તેમની પાસે તમારા આંતરિક જ્ઞાનની ઍક્સેસ હોતી નથી. જ્યારે તેમને જોઈતી માહિતી તેમના ટ્રેનિંગ વેટ્સ (training weights) ની બહાર હોય છે, ત્યારે તેઓ અજ્ઞાનતા સ્વીકારવાને બદલે ખોટી માહિતી બનાવે છે. પ્રોડક્શનમાં, આ બાબત રમુજી રહેવાને બદલે જોખમી બની જાય છે.
Retrieval-Augmented Generation, અથવા RAG, બરાબર આ સમસ્યાના ઉકેલ માટે બનાવવામાં આવ્યું છે. મોડલને બધું યાદ રાખવા કહેવાને બદલે, તમે તેને માહિતી શોધવા દો છો.
અનુમાન લગાવવાથી વાંચવા સુધી
એક રૉ LLM ને ફોટોગ્રાફિક મેમરી ધરાવતા એક તેજસ્વી સહકર્મી તરીકે વિચારો, પરંતુ તે વ્યક્તિ તમે કંપનીમાં જોડાયા તે પહેલાં જ કંપની છોડીને જતી રહી છે. તેઓ પ્રભાવશાળી લખાણ લખી શકે છે, લોજિકલ કોયડાઓ ઉકેલી શકે છે અને સંકલ્પનાઓને સરળ શબ્દોમાં સમજાવી શકે છે. જો તમે તેમને ગયા ક્વાર્ટરના API ફેરફારો વિશે પૂછશો, તો તેઓ ફક્ત કંઈક એવું બનાવશે જે સાંભળવામાં સાચું લાગે. તેમની પાસે બીજો કોઈ વિકલ્પ નથી.
RAG તે સહકર્મીને ફાઇલિંગ કેબિનેટની ઍક્સેસ આપે છે. જ્યારે વપરાશકર્તા પ્રશ્ન પૂછે છે, ત્યારે સિસ્ટમ પ્રશ્નને અંધાધૂંધ રીતે મોડલ પર ફેંકી દેતી નથી. તે પહેલાં સંબંધિત દસ્તાવેજો મેળવે છે (retrieve કરે છે), તેમને સંદર્ભ (context) તરીકે પ્રોમ્પ્ટમાં મૂકે છે, અને ત્યારપછી જ મોડલને વાંચવા અને જવાબ આપવા માટે કહે છે. મોડલ તથ્યો યાદ રાખવાથી બદલાઈને, તેની સામે રહેલા તથ્યોને સમજવા તરફ વળે છે.
આ પ્રવાહ સ્પષ્ટ રીતે બે ભાગમાં વહેંચાયેલો છે: ઓફલાઇન પાયાનું કામ અને ઓનલાઇન પ્રતિસાદ.
ફેઝ 1: તૈયારીનો તબક્કો (ઓફલાઇન)
કોઈ પણ પ્રશ્ન ટાઈપ કરે તે પહેલાં ઘણો સમય પહેલાં, તમારે તમારા અસ્તવ્યસ્ત દસ્તાવેજોના સંગ્રહને સર્ચેબલ નોલેજ બેઝમાં ફેરવવો પડશે. આ પાયાનું કામ નક્કી કરે છે કે તમારી RAG સિસ્ટમ સફળ થશે કે શાંતિથી નિષ્ફળ જશે.
Document loaders એ તમારો પ્રારંભિક બિંદુ છે. આ કનેક્ટર્સ PDFs, Notion વર્કસ્પેસ, SharePoint ફોલ્ડર્સ, વેબ પેજ અને ઇન્ટરનલ વિકિમાંથી રૉ ટેક્સ્ટ ખેંચી લાવે છે. અહીં જ વાસ્તવિકતાનો સામનો કરવો પડે છે. લોડર વર્ડ ડોક્યુમેન્ટમાંથી સાફ ટેક્સ્ટ કાઢી શકે છે, પરંતુ સ્કેન કરેલા PDF પર અટકી શકે છે જે ખરેખર માત્ર એક ઈમેજ છે જેમાં કોઈ ટેક્સ્ટ લેયર નથી. લોડર ખાલી સ્ટ્રિંગ રિટર્ન કરે છે, તમારો ડેટાબેઝ કંઈ જ સ્ટોર કરતો નથી, અને તમારા યુઝરને પાછળથી કોઈ ચેતવણી વગર "મને ખબર નથી" એવો જવાબ મળે છે. તમારા લોડર્સ ખરેખર શું કાઢ્યું છે તેની હંમેશા ચકાસણી કરો. પાઇપલાઇન પર વિશ્વાસ કરતા પહેલા દરેક સ્ત્રોતમાંથી કેટલાક દસ્તાવેજો પર સ્પોટ ચેક કરો.
હવે આવે છે text splitting, જેને ચંકિંગ (chunking) પણ કહેવામાં આવે છે. તમે એંસી પાનાની સિક્યુરિટી પોલિસીને એકસાથે પ્રોમ્પ્ટમાં ફીડ કરી શકતા નથી; તમે કોન્ટેક્સ્ટ લિમિટ ઓળંગી જશો અને સિગ્નલ અવાજમાં દબાઈ જશે. તેના બદલે, તમે દસ્તાવેજોને ચંક્સ (chunks) માં કાપો છો. યુક્તિ સાચું કદ પસંદ કરવામાં છે. ખૂબ નાના ચંક્સ, જેમ કે સિંગલ વાક્યો, ઘણીવાર મહત્વપૂર્ણ સંદર્ભ ગુમાવી દે છે. "તમામ વિનંતીઓને મેનેજર દ્વારા મંજૂર કરવી આવશ્યક છે" એવું વાંચતું ચંક એ જણાવવાનું ભૂલી જાય છે કે આ નિયમ ફક્ત આંતરરાષ્ટ્રીય મુસાફરી માટે જ લાગુ પડે છે. ખૂબ મોટા ચંક્સ, જેમ કે આખા પ્રકરણો, એમ્બેડિંગને નબળું પાડે છે અને રિટ્રાઇવલને મૂંઝવણમાં મૂકે છે કારણ કે તેઓ એકસાથે પંદર અલગ-અલગ વિષયોને આવરી લે છે. વ્યવહારમાં, ઘણી ટીમો 300 થી 500 ટોકન્સ વચ્ચેના ચંક્સ સાથે શરૂઆત કરે છે, જેમાં 50-ટોકનનો ઓવરલેપ હોય છે જેથી વિભાજન વચ્ચે ચાલતા વાક્યો બગડી ન જાય. તમારી સામગ્રીના આધારે આમાં ફેરફાર કરો. API ડોક્યુમેન્ટેશન નાના ચંક્સને સહન કરી શકે છે. લીગલ કોન્ટ્રાક્ટ્સમાં કન્ડિશનલ લોજિક જાળવી રાખવા માટે ઘણીવાર મોટા ચંક્સની જરૂર હોય છે.
એકવાર ચંક થયા પછી, દરેક ભાગને embedding માં રૂપાંતરિત કરવામાં આવે છે. આનો અર્થ એ છે કે ટેક્સ્ટને એક એવા મોડલ દ્વારા ચલાવવું જે નંબરોની યાદી, એટલે કે વેક્ટર (vector) આઉટપુટ આપે છે, જે ચંકના અર્થપૂર્ણ (semantic) અર્થનું પ્રતિનિધિત્વ કરે છે. સમાન વિચારો આ ગાણિતિક અવકાશમાં એકબીજાની નજીક આવે છે. "401k matching policy" અને "retirement contribution rules" એ "401k matching policy" અને "office printer setup" કરતા એકબીજાની વધુ નજીક હશે. આ વેક્ટર્સને vector database માં સ્ટોર કરવામાં આવે છે, જેમ કે Pinecone, Weaviate, અથવા Chroma જેવી ઓપન-સોર્સ વિકલ્પ. વેક્ટર સ્ટોર માત્ર કચરો નાખવાની જગ્યા નથી. તે અંદાજિત નજીકના પડોશી (approximate nearest-neighbor) સર્ચ માટે ઓપ્ટિમાઇઝ કરેલ ઇન્ડેક્સ છે, જે તમને લાખો દસ્તાવેજોમાં પણ મિલીસેકન્ડમાં સૌથી સુસંગત ચંક્સ શોધવામાં મદદ કરે છે.
ફેઝ 2: લાઈવ પાથ (ઓનલાઇન)
જ્યારે વપરાશકર્તા આખરે પૂછે છે, "ક્લાયન્ટ ડિનર માટે અમારી મુસાફરી ખર્ચ વળતરની નીતિ શું છે?", ત્યારે લાઈવ પાઇપલાઇન કાર્યરત થાય છે.
તે
