चार महिने एका Retrieval-Augmented Generation (RAG) पाइपलाइनला Jupyter notebook मधून थेट लाइव्ह सर्व्हिसमध्ये रूपांतरित केल्यानंतर, लेखकाने पाच अशा ठोस निवडी सांगितल्या आहेत ज्यांनी एका साध्या डेमोला खरोखर वापरकर्त्यांवर विश्वास ठेवता येईल अशा सिस्टममध्ये बदलले. हा फरक आकड्यांमध्ये दिसून येतो: मजकूर विभागण्याच्या (text splitting) पद्धतीत केलेल्या एका साध्या बदलामुळे रिट्रिव्हल हिट रेट (retrieval hit rate) ६१% वरून ८३% पर्यंत वाढला, आणि २०० वास्तविक क्वेरीजच्या एका मर्यादित इव्हॅल्युएशन सेटमुळे आता ग्राहकांपर्यंत पोहोचण्यापूर्वीच बहुतेक रिग्रेशन्स (regressions) पकडल्या जातात.
Why it matters
RAG डेमो प्रभावी दिसतात – ते काही सेकंदात एखादा परिच्छेद शोधतात आणि एक संभाव्य उत्तर देतात. परंतु प्रोडक्शनमध्ये (production), तीच पद्धत अनेकदा जुनी माहिती, चुकून आलेले एरर कोड किंवा अपूर्ण वाक्ये देते, ज्यामुळे वापरकर्त्याचा विश्वास कमी होतो. अडथळा सहसा लँग्वेज मॉडेलमध्ये नसतो; तो मजकूर कसा स्वीकारला जातो (ingested), इंडेक्स केला जातो आणि सर्व्ह केला जातो यामध्ये असतो. पाइपलाइन योग्यरित्या तयार करणे म्हणजे एक उत्पादन जे मूल्य वाढवते आणि एक उत्पादन जे ओझे बनते, यामधील फरक असू शकतो.
1. Stop using fixed-size chunks
अनेक प्रोटोटाइप्स प्रत्येक दस्तऐवजाचे ५१२-टोकनच्या ब्लॉक्समध्ये तुकडे करतात. हे लहान मजकुरासाठी काम करते पण तांत्रिक मॅन्युअल्स, सपोर्ट थ्रेड्स आणि कोड स्निपेट्सचे तुकडे करते. यामुळे वाक्ये विभागली जातात, हेडलाईन्स गायब होतात आणि रिट्रिव्हल इंजिन वापरकर्त्याला अपेक्षित असलेला संदर्भ (context) शोधू शकत नाही.
अर्थपूर्ण घटक (semantic units) टिकवून ठेवण्यासाठी स्ट्रक्चर-अवेअर चंकिंगचा (structure-aware chunking) वापर करा—म्हणजेच हेडलाईन्स, संवादाच्या सीमा किंवा कोड फेन्सेसवर तुकडे करा. लेखकाच्या सिस्टममध्ये, केवळ यामुळेच संबंधित परिच्छेद शोधणाऱ्या क्वेरीजचा प्रमाण ६१% वरून ८३% पर्यंत वाढले. ही सुधारणा डेटा-फॉर्मॅटमधील बदलामुळे झाली आहे; मूळ मॉडेल तेच राहिले आहे.
2. Use hybrid search
शुद्ध वेक्टर सर्च (embedding-based similarity) सारख्या अर्थाचे परिच्छेद शोधण्यात उत्कृष्ट आहे, परंतु एरर कोड, व्हर्जन नंबर किंवा विशिष्ट तांत्रिक शब्दांसारख्या अचूक आयडेंटिफायर्सच्या बाबतीत ते अडखळते. "ERR-XXXX" सारखा एरर कोड शोधणाऱ्या वापरकर्त्याला असा परिच्छेद मिळू शकतो जो अर्थाच्या दृष्टीने सारखा असेल पण त्यात तो कोड नसेल.
हायब्रिड सर्च एका डेंस वेक्टर इंडेक्सला पारंपारिक BM25 इंडेक्सशी (term-frequency आधारित) जोडते. दोन्ही स्कोअरना वेटेज देऊन, सिस्टम अशा गोष्टी शोधते ज्या अर्थाच्या दृष्टीने जवळ आहेत आणि वापरकर्त्याने टाईप केलेले अचूक शब्दही त्यात आहेत. प्रोडक्शनसाठी, हायब्रिड सर्च ही एक मूलभूत आवश्यकता आहे, केवळ एक अतिरिक्त सुविधा नाही.
3. Handle stale data
कालबाह्य किंमतींचे तक्ते, पॉलिसी दस्तऐवज किंवा फर्मवेअर रिलीज नोट्स विश्वासार्हता झपाट्याने नष्ट करतात. इंडेक्स ताजा ठेवण्यासाठी तीन व्यावहारिक पावले:
- प्रत्येक दस्तऐवजाला व्हर्जन स्टॅम्प किंवा टाइमस्टॅम्प लावा.
- स्कोअरिंग दरम्यान 'recency boost' लागू करा जेणेकरून नवीन गोष्टी जुन्या प्रतींपेक्षा वर येतील.
- सोर्स सिस्टममधील बदल घेण्यासाठी दररोज रात्री 'incremental re-indexing' चालवा.
हे उपाय सिस्टिमला गेल्या तिमाहीत वैध असलेली किंमत किंवा आधीच बदललेली पॉलिसी दाखवण्यापासून वाचवतात.
4. Rerank instead of upgrading models
एम्बेडिंग मॉडेल अपग्रेड केल्याने गुणवत्तेत फक्त थोडीच वाढ होते, तर क्रॉस-एनकोडर री-रँकर (cross-encoder reranker) जोडल्याने कमी खर्चात खूप मोठी सुधारणा मिळते.
प्रोडक्शन फ्लो हायब्रिड सर्च वापरून २० स्वस्त उमेदवार (candidates) शोधतो आणि नंतर सर्वोत्तम पाच निवडण्यासाठी त्यांना री-रँकरमधून पाठवतो. ही दोन-टप्प्यांची पद्धत पूर्ण मॉडेल अपग्रेडच्या तुलनेत खूप कमी खर्चात मोठी गुणवत्ता सुधारणा देते.
5. Build a real evaluation set
तुम्ही मोजू शकत नाही तो बदल सुधारू शकत नाही. लेखकाने २०० वास्तविक वापरकर्ता क्वेरीजचा एक टेस्ट सूट तयार केला आहे, ज्यामध्ये प्रत्येक क्वेरीसोबत तज्ज्ञांनी तयार केलेले उत्तर जोडलेले आहे. प्रत्येक कोड बदल या सूटवर तपासला जातो; कोणताही रिग्रेशन तैनात करण्यापूर्वीच पकडला जातो.
जेव्हा एखादा वापरकर्ता चुकीच्या उत्तराची तक्रार करतो, तेव्हा ती क्वेरी त्वरित इव्हॅल्युएशन सेटमध्ये जोडा, ज्यामुळे वास्तविक जगातील त्रुटी भविष्यातील सुरक्षा कवच बनतात. प्रत्येक तयार केलेल्या उत्तराचे सतत लॉगिंग केल्यामुळे इव्हॅल्युएशन लूप चालू राहतो आणि सिस्टम प्रत्यक्ष वापराशी सुसंगत राहते.
The production pipeline in practice
- Ingest: स्ट्रक्चर-अवेअर चंकिंग हेडलाईन्स, कोड ब्लॉक्स आणि संवादाचे टप्पे टिकवून ठेवते.
- Index: डेंस एम्बेडिंग्ज आणि BM25 टर्म स्टॅटिस्टिक्स दोन्ही साठवा.
- Retrieve: हायब्रिड सर्च अर्थाची समानता आणि अचूक शब्द जुळवून २० उमेदवार परत करते.
- Rerank: क्रॉस-एनकोडर या यादीला सर्वात आशादायक पाच परिच्छेदांपर्यंत मर्यादित करते.
- Generate: LLM ला अंतिम उत्तर तयार करण्यासाठी हे टॉप चंक्स आणि त्यांचे मेटाडेटा प्राप्त होतात.
- Evaluate: प्रत्येक प्रतिसाद लॉग केला जातो; त्रुटी २००-क्वेरी टेस्ट सेटमध्ये परत पाठवल्या जातात.
Stakes and trade-offs
एक सुव्यवस्थित पाईपलाईन 'hallucinations' कमी करते, उत्तराची सुसंगतता सुधारते आणि गरजेपेक्षा जास्त क्षमता असलेल्या मॉडेल्सचा खर्च कमी करते. याचा फायदा म्हणजे वापरकर्त्यांचे वाढलेले समाधान आणि कमी झालेला सपोर्टचा खर्च. या पायऱ्यांकडे दुर्लक्ष केल्यास एक अस्थिर सेवा मिळते, ज्यामुळे ब्रँडवरील विश्वास कमी होतो आणि खर्चिक आपत्कालीन उपाययोजना कराव्या लागतात.
पुढे काय पाहावे
जसजसे ओपन-सोर्स एम्बेडिंग्स आणि वेक्टर डेटाबेस प्रगत होत आहेत, तसतसे “dense” आणि “sparse” रिट्रिव्हलमधील फरक धूसर होत जाईल, परंतु सिमेंटिक आणि अचूक मॅचिंग एकत्र करण्याचे तत्त्व कायम राहील.
मुख्य निष्कर्ष: RAG सिस्टममध्ये लँग्वेज मॉडेल हा क्वचितच मुख्य अडथळा (choke point) असतो. खरी मेहनत तुम्ही मूळ मजकूर कसा स्लाईस, इंडेक्स आणि समोर आणता यावर अवलंबून असते. हे निर्णय योग्य घेतल्यास एक आकर्षक डेमो एका विश्वासार्ह उत्पादनात रूपांतरित होतो.