आत्मविश्वासाने दिलेले उत्तर हे उत्तर न मिळण्यापेक्षाही अधिक वाईट का असू शकते

तुम्ही तुमचे अंतर्गत चॅटबॉट तयार करण्याचे काम पूर्ण करता. तुम्ही त्यात कंपनीची प्रत्येक HR पॉलिसी, इंजिनिअरिंग स्पेसिफिकेशन आणि ऑनबोर्डिंग डॉक्युमेंट फीड करता. एक नवीन कर्मचारी क्लायंट डिनरसाठीच्या प्रवास खर्चाच्या मर्यादेबद्दल विचारतो. बॉट त्वरित प्रतिसाद देतो. तो स्वतःबद्दल खात्रीशीर वाटतो. तो सांगितलेली मर्यादा प्रति व्यक्ती $७५ आहे.

प्रत्यक्ष पॉलिसीमध्ये $५० असे म्हटले आहे. बॉटने हे उत्तर स्वतःहून तयार केले आहे. त्याने तुमची फाईल्स कधीच उघडली नाहीत. त्याने केवळ अंदाज लावला, जो त्याच्या अनेक वर्षांपूर्वीच्या ट्रेनिंग डेटातील पॅटर्नवर आधारित होता. खाजगी कागदपत्रांवर (private documents) रॉ लार्ज लँग्वेज मॉडेल्स (raw large language models) चालवण्याचे हे कडू वास्तव आहे. त्यांना तुमच्या अंतर्गत ज्ञानाचा कोणताही प्रवेश (access) नसतो. जेव्हा त्यांना आवश्यक असलेली तथ्ये त्यांच्या ट्रेनिंग वेट्सच्या (training weights) बाहेर असतात, तेव्हा ते अज्ञान स्वीकारण्याऐवजी ती तथ्ये बनावटपणे तयार करतात. प्रत्यक्ष वापरामध्ये (production), हे मनोरंजक न राहता एक मोठी जबाबदारी किंवा धोका (liability) बनू लागते.

Retrieval-Augmented Generation, किंवा RAG, हे नेमके हेच सोडवण्यासाठी बनवले गेले आहे. मॉडेलला सर्व काही लक्षात ठेवण्यास सांगण्याऐवजी, तुम्ही त्याला माहिती शोधू देता.

अंदाजाकडून वाचनाकडे

एका रॉ LLM ला अशा एका हुशार सहकाऱ्याप्रमाणे समजा ज्याला फोटोग्राफिक मेमरी आहे, पण तो तुमच्या कंपनीत सामील होण्यापूर्वीच सोडून गेला आहे. ते प्रभावी गद्य लिहू शकतात, तार्किक कोडी सोडवू शकतात आणि संकल्पना सोप्या भाषेत समजावून सांगू शकतात. मात्र, त्यांना गेल्या तिमाहीतील API बदलांबद्दल विचारले, तर ते केवळ पटण्यासारखे काहीतरी बनावट सांगतील. त्यांच्याकडे दुसरा कोणताही पर्याय नसतो.

RAG त्या सहकाऱ्याला फाईलिंग कॅबिनेटचा प्रवेश देते. जेव्हा वापरकर्ता प्रश्न विचारतो, तेव्हा सिस्टम तो प्रश्न आंधळेपणाने मॉडेलकडे फेकत नाही. ती प्रथम संबंधित कागदपत्रे शोधते (retrieves), त्यांना प्रॉम्प्टमध्ये संदर्भ (context) म्हणून समाविष्ट करते आणि त्यानंतरच मॉडेलला ते वाचून प्रतिसाद देण्यास सांगते. मॉडेल तथ्ये आठवण्याकडून (recalling) प्रत्यक्ष समोर असलेल्या तथ्यांचे आकलन (comprehending) करण्याकडे वळते.

ही प्रक्रिया दोन स्पष्ट भागांत विभागली गेली आहे: ऑफलाइन पायाभरणी (offline groundwork) आणि ऑनलाइन प्रतिसाद (online response).

टप्पा १: तयारीचा टप्पा (ऑफलाइन)

कोणीही प्रश्न टाईप करण्याच्या खूप आधी, तुम्हाला तुमचा विस्कळीत कागदपत्रांचा संग्रह एका शोधण्यायोग्य ज्ञानकोशात (searchable knowledge base) रूपांतरित करावा लागेल. ही पायाभरणी तुमचा RAG सिस्टम यशस्वी होईल की शांतपणे अपयशी ठरेल हे ठरवते.

Document loaders हे तुमचे सुरुवातीचे बिंदू आहेत. हे कनेक्टर्स PDFs, Notion वर्कस्पेस, SharePoint फोल्डर्स, वेब पेजेस आणि अंतर्गत विकीमधून रॉ टेक्स्ट खेचून आणतात. येथेच खरी अडचण येते. एक लोडर Word डॉक्युमेंटमधून स्वच्छ मजकूर काढू शकतो, परंतु स्कॅन केलेल्या PDF वर अडकू शकतो, जी प्रत्यक्षात केवळ एक इमेज असते आणि त्यात मजकूर लेयर नसतो. लोडर रिकामी स्ट्रिंग (empty string) परत करतो, तुमचा डेटाबेस काहीही साठवत नाही आणि तुमच्या वापरकर्त्याला नंतर कोणतीही पूर्वसूचना न देता "मला माहित नाही" असा प्रतिसाद मिळतो. तुमच्या लोडरने प्रत्यक्षात काय काढले आहे याची नेहमी पडताळणी करा. पाइपलाइनवर विश्वास ठेवण्यापूर्वी प्रत्येक स्त्रोतातील काही कागदपत्रांची तपासणी (spot checks) करा.

त्यानंतर text splitting येते, ज्याला 'चंकिंग' (chunking) असेही म्हणतात. तुम्ही ८० पानांची सुरक्षा पॉलिसी एकाच वेळी प्रॉम्प्टमध्ये टाकू शकत नाही; यामुळे तुम्ही कॉन्टेक्स्ट लिमिट्स (context limits) ओलांडाल आणि महत्त्वाचा संदेश गोंधळात (noise) हरवून जाईल. त्याऐवजी, तुम्ही कागदपत्रांचे तुकडे (chunks) करता. योग्य आकार निवडणे हीच खरी युक्ती आहे. खूप लहान तुकडे, जसे की एक वाक्य, अनेकदा महत्त्वाचा संदर्भ गमावतात. "सर्व विनंत्यांना मॅनेजरने मंजूर करणे आवश्यक आहे" असा तुकडा वाचताना, हा नियम केवळ आंतरराष्ट्रीय प्रवासाला लागू होतो हे सांगणे विसरू शकतो. पूर्ण प्रकरणे यांसारखे खूप मोठे तुकडे, एम्बेडिंग (embedding) सौम्य करतात आणि शोध प्रक्रियेत (retrieval) गोंधळ निर्माण करतात कारण ते एकाच वेळी पंधरा वेगवेगळ्या विषयांवर भाष्य करतात. व्यवहारात, अनेक टीम्स ३०० ते ५०० टोकन्सच्या दरम्यानच्या तुकड्यांपासून सुरुवात करतात, ज्यामध्ये ५० टोकन्सचा ओव्हरलॅप (overlap) असतो जेणेकरून दोन तुकड्यांमध्ये विभागलेली वाक्ये विस्कळीत होणार नाहीत. तुमच्या कंटेंटनुसार यात बदल करा. API डॉक्युमेंटेशनमध्ये लहान तुकडे चालतात. कायदेशीर करारांमध्ये (Legal contracts) अटी आणि शर्तींचे तर्क (conditional logic) टिकवून ठेवण्यासाठी अनेकदा मोठ्या तुकड्यांची आवश्यकता असते.

एकदा तुकडे झाले की, प्रत्येक भागाचे embedding मध्ये रूपांतर केले जाते. याचा अर्थ असा की मजकूर अशा मॉडेलमधून फिरवला जातो जे अंकांची एक यादी, म्हणजेच एक 'व्हेक्टर' (vector) आउटपुट देते, जे त्या तुकड्याचा अर्थ (semantic meaning) दर्शवते. या गणितीय अवकाशात (mathematical space) समान कल्पना एकमेकांच्या जवळ येतात. "401k matching policy" आणि "retirement contribution rules" हे "401k matching policy" आणि "office printer setup" पेक्षा एकमेकांच्या अधिक जवळ असतील. हे व्हेक्टर्स vector database मध्ये साठवले जातात, जसे की Pinecone, Weaviate, किंवा Chroma सारखा ओपन-सोर्स पर्याय. व्हेक्टर स्टोअर हे केवळ माहिती साठवण्याचे ठिकाण नाही. ते 'अप्रोक्सिमेट निअरस्ट-नेबर सर्च' (approximate nearest-neighbor search) साठी ऑप्टिमाइझ केलेले इंडेक्स आहे, ज्यामुळे तुम्हाला लाखो कागदपत्रांमधूनही काही मिलीसेकंदात सर्वात संबंधित तुकडे शोधता येतात.

टप्पा २: थेट मार्ग (ऑनलाइन)

When a user finally asks, "What is our travel reimbursement policy for client dinners?", the live pipeline kicks in.

The