सहायक वास्तुकला जो कंपनी डेटा से बात करती है

लाभ:

• एंड-टू-एंड एंटरप्राइज़ RAG असिस्टेंट के घटकों और डेटा प्रवाह को डिज़ाइन करना
• बहु-स्रोत डेटा (विकी, टिकट, पीडीएफ, डेटाबेस) को एक ही सहायक में संयोजित करना
• स्केलेबिलिटी, कैशिंग और विलंबता के लिए वास्तुशिल्प निर्णय लें

पिछली इकाइयों में, हमने भागों को एक-एक करके सीखा: एम्बेडिंग, वेक्टर डेटाबेस, चंकिंग, पुनर्प्राप्ति। आइए अब इन्हें संयोजित करें और एक सहायक का एंड-टू-एंड आर्किटेक्चर बनाएं जो आपकी अपनी कंपनी के डेटा से बात करता है। लक्ष्य यह है कि कोई कर्मचारी पूछे, "हमारी छुट्टी नीति क्या है?" एक ऐसी प्रणाली जहां लोग प्रश्न पूछ सकते हैं, उत्तर वास्तविक आंतरिक दस्तावेज़ों, उद्धरणों पर आधारित होते हैं और कई डेटा स्रोतों को जोड़ते हैं। यह इकाई संपूर्ण आर्किटेक्चर, डेटा प्रवाह और उत्पादन स्तर के निर्णयों को संसाधित करती है।

अंत-से-अंत घटक

एक कॉर्पोरेट RAG सहायक में दो अलग-अलग लाइनें होती हैं। इंडेक्सिंग लाइन (ऑफ़लाइन) डेटा तैयार करती है; क्वेरी लाइन (ऑनलाइन) प्रश्न का उत्तर देती है।

अनुक्रमण पंक्ति घटक:

1. कनेक्टर्स: कनेक्टर्स जो स्रोतों से डेटा खींचते हैं - विकी, टिकट सिस्टम, फ़ाइल स्टोर, डेटाबेस, ईमेल।
2. सामान्यीकरण: विभिन्न प्रारूपों (पीडीएफ, HTML, DOCX) को साफ पाठ में परिवर्तित करना; शीर्ष लेख/पाद लेख की सफ़ाई.
3. चंकिंग + मेटाडेटा: चंकिंग और टैगिंग (स्रोत, दिनांक, प्राधिकारी)।
4. एम्बेडिंग + लोडिंग: वेक्टर डेटाबेस में वेक्टर और मेटाडेटा लिखना।

क्वेरी पाइपलाइन घटक:

1. क्वेरी प्रीप्रोसेसिंग: पुनर्लेखन, विकेंद्रीकरण।
2. पुनर्प्राप्ति: हाइब्रिड खोज + मेटाडेटा फ़िल्टर + पुनः रैंकिंग।
3. शीघ्र निर्माण: टेम्पलेट में संदर्भ + प्रश्न + निर्देश रखना।
4. पीढ़ी: मॉडल + स्रोतों से ग्राउंडेड (प्रासंगिक) उत्तर।
5. पोस्ट-प्रोसेसिंग: उद्धरण स्वरूपण, सुरक्षा जांच, लॉगिंग।

टिप: इंडेक्सिंग लाइन को क्वेरी लाइन से भौतिक रूप से अलग करें। अनुक्रमण धीमा और आवधिक है (रात भर बैचों में चलता है); जांच का दायरा हल्का और तत्काल होना चाहिए। दो पंक्तियों को मिलाने से उपयोगकर्ता को प्रतीक्षा करते समय भारी प्रसंस्करण करना पड़ता है।

डेटा प्रवाह को विज़ुअलाइज़ करना

[अनुक्रमण - ऑफ़लाइन] संसाधन → सामान्यीकरण → चंक + मेटाडेटा → एंबेड → वेक्टर डीबी (विकी, टिकट, पीडीएफ, डीबी) [क्वेरी - ऑनलाइन] उपयोगकर्ता प्रश्न → प्री-प्रोसेसिंग → पुनर्प्राप्ति (हाइब्रिड + फ़िल्टर + रीरैंक) → प्रॉम्प्ट (संदर्भ + प्रश्न + निर्देश) → मॉडल → उत्तर+स्रोत → उपयोगकर्ता

मल्टी-सोर्स डेटा का संयोजन

वास्तविक कंपनियों में, उत्तर एक जगह नहीं रुकता। "ग्राहक को रिफंड कैसे जारी करें?" प्रश्न का उत्तर सहायता लेख (प्रक्रिया), टिकट इतिहास (वास्तविक उदाहरण) और पॉलिसी पीडीएफ (नियम) दोनों में पाया जा सकता है। सहायक को उन सभी को एक पूल में खोजना चाहिए।

महत्वपूर्ण बिंदु: संसाधनों को एक वेक्टर स्टोर में संयोजित करते समय, प्रत्येक शार्ड में `source_tour` मेटाडेटा होना चाहिए। इसलिए आप उन सभी को खोज सकते हैं और यदि आवश्यक हो तो उन्हें फ़िल्टर कर सकते हैं, जैसे "केवल आधिकारिक नीतियां लाएँ"। इसके अलावा, विभिन्न स्रोतों में विश्वसनीयता के विभिन्न स्तर होते हैं: आधिकारिक नीति > सहायता लेख > एक कर्मचारी का टिकट नोट। आप इस प्राथमिकता को री-रैंकिंग या प्रॉम्प्ट में निर्दिष्ट कर सकते हैं।

स्रोत

सामग्री प्रकार

विश्वास

अद्यतन आवृत्ति

नीति पीडीएफ

आधिकारिक नियम

उच्च

मासिक

सहायता लेख

प्रक्रिया

मध्यम-उच्च

साप्ताहिक

टिकट इतिहास

असली नमूना

मध्यम

निरंतर

विकि

मिश्रित/वर्तमान नोट

परिवर्तनीय

निरंतर

स्केलेबिलिटी, कैश और विलंबता

उत्पादन में तीन मुद्दे सामने आते हैं। विलंबता: जब उपयोगकर्ता 2 सेकंड से अधिक प्रतीक्षा करता है तो अनुभव ख़राब हो जाता है। समाधान: उत्तर को स्ट्रीमिंग फॉर्म में प्रदर्शित करें - मॉडल लिखते ही इसे स्क्रीन पर डाल दिया जाता है। कैश: अक्सर पूछे जाने वाले प्रश्नों और दोहराए जाने वाले संदर्भों के लिए, कैश गति बढ़ाता है और लागत कम करता है। स्केल: जैसे-जैसे उपयोगकर्ता बढ़ता है, क्षैतिज रूप से पुनर्प्राप्ति और मॉडल कॉल को स्केल करने में सक्षम होना आवश्यक है।

लागत पक्ष पर अंगूठे का नियम: सबसे महंगा कदम आमतौर पर बड़े मॉडल में जाने वाले टोकन की संख्या है। इसलिए, पुनः रैंकिंग करके संदर्भ को 4 अच्छे भागों में कम करने से गुणवत्ता और लागत दोनों में सुधार होता है। एक सामान्य डिज़ाइन सरल वर्गीकरण या रूटिंग के लिए एक छोटे/तेज़ मॉडल का उपयोग करना है, और अंतिम उत्तर के लिए एक अधिक शक्तिशाली मॉडल (उदाहरण के लिए क्लाउड-ओपस-4-8) का उपयोग करना है।

सावधानी: अनुक्रमण को "एक बार करो, भूल जाओ" के रूप में सेट न करें। दस्तावेज़ बदले जाते हैं, हटाए जाते हैं, जोड़े जाते हैं। पुन: अनुक्रमणिका रणनीति स्थापित करें: बदले हुए दस्तावेज़ों का पता लगाएं और केवल उन्हें पुन: संसाधित करें। बासी सूचकांक एक उत्तर उत्पन्न करता है जो वर्तमान प्रतीत होता है लेकिन गलत है।

कमजोर वास्तुशिल्प/मजबूत वास्तुशिल्प

कमजोर (एकल स्क्रिप्ट, सब कुछ मिश्रित):

जब उपयोगकर्ता पूछता है: उस समय दस्तावेज़ पढ़ें, उन्हें टुकड़े-टुकड़े करें, उन्हें एम्बेड करें, उन्हें खोजें, उनका उत्तर दें। # समस्या: प्रत्येक प्रश्न के लिए सभी अनुक्रमण दोहराए जाते हैं; विलंब के सेकंड, # कोई स्रोत पृथक्करण नहीं, कोई फ़िल्टर नहीं, कोई ताज़ा नहीं।

शक्तिशाली (विभाजित पाइप + मेटाडेटा + कैश + स्ट्रीमिंग):

अनुक्रमण: बैच रात में चलता है, परिवर्तित दस्तावेज़ों को ताज़ा करता है। क्वेरी: लाइटवेट लाइन - प्री-प्रोसेसिंग → हाइब्रिड रिट्रीवल+फ़िल्टर → रीरैंक → प्रॉम्प्ट → मॉडल (स्ट्रीमिंग) → उद्धरण → लॉग। अक्सर पूछे जाने वाले प्रश्न और स्रोत कैश्ड हैं।

तीन मिनी मामले

केस 1 - भ्रमित लाइन, भारी विलंब। एक स्टार्टअप ने एक स्क्रिप्ट लिखी जो प्रत्येक प्रश्न के साथ पीडीएफ को पुन: संसाधित करती है; प्रत्येक उत्तर में औसतन 11 सेकंड का समय लगा। जब इंडेक्सिंग लाइन को अलग किया गया और डेटा को पहले वेक्टर स्टोर में स्थानांतरित किया गया, तो क्वेरी का समय घटकर 1.3 सेकंड हो गया और स्ट्रीमिंग के साथ, "पहला शब्द" 400 एमएस में दिखाई दिया।

केस 2 - बहुत सारे संसाधन, गलत प्राथमिकता। एक सहायता सहायक ने पॉलिसी पीडीएफ और पुराने टिकट नोटों को समान महत्व दिया; मॉडल कभी-कभी किसी कर्मचारी की दो साल पहले की गलत रेटिंग को आधिकारिक नियम के रूप में प्रस्तुत करता है। जब source_tour मेटाडेटा और "संघर्ष के मामले में आधिकारिक नीति पर विचार करें" निर्देश को प्रॉम्प्ट में जोड़ा गया, तो झूठी-प्राथमिकता वाली त्रुटियां 89% कम हो गईं।

केस 3 - बासी सूचकांक। एक एचआर सहायक एक ऐसे सूचकांक के साथ काम कर रहा था जो 3 महीने से अपडेट नहीं किया गया था; छुट्टी की नीति बदल गई है, लेकिन सहायक पुराने दिनों की बात कह रहा था। जब दैनिक रिफ्रेश स्थापित किया गया, जो बदली हुई फ़ाइलों का पता लगाता है, तो वर्तमान-प्रतिक्रिया दर 70% से बढ़कर 99% हो गई।

सामान्य गलतियाँ

• अनुक्रमणिका और क्वेरी लाइनों का मिश्रण: उपयोगकर्ता के इंतजार के दौरान भारी प्रसंस्करण किया जाता है; देरी से विस्फोट होता है.
• स्रोत प्रकार को मेटाडेटा में न डालना: कोई प्राथमिकताकरण और फ़िल्टरिंग नहीं; अविश्वसनीय स्रोत आधिकारिक प्रतीत होता है।
• ताज़ा रणनीति स्थापित नहीं करना: सूचकांक पुराना हो जाता है; वर्तमान प्रतीत होने वाले गलत उत्तर उत्पन्न होते हैं।
• स्ट्रीमिंग छोड़ें: उपयोगकर्ता एक खाली स्क्रीन को देखता है; अनुमानित विलंब अधिक हो जाता है।
• प्रत्येक चरण में सबसे बड़े मॉडल का उपयोग करना: लागत अनावश्यक रूप से बढ़ जाती है; स्टीयरिंग को छोटे मॉडल पर छोड़ दें।

संक्षेप में

• कॉर्पोरेट RAG सहायक में दो अलग-अलग पंक्तियाँ होती हैं: ऑफ़लाइन अनुक्रमण और ऑनलाइन क्वेरी; उन्हें शारीरिक रूप से अलग करें.
• अनुक्रमण = कनेक्टर + सामान्यीकरण + खंड/मेटाडेटा + एंबेड/अपलोड; क्वेरी = प्री-प्रोसेस + रिट्रीवल + प्रॉम्प्ट + जेनरेट + पोस्ट-प्रोसेस।
• बहु-स्रोत डेटा को एक एकल भंडार में संयोजित किया जाता है, लेकिन source_type मेटाडेटा और ट्रस्ट प्राथमिकता संरक्षित रहती है।
• विलंबता के लिए स्ट्रीमिंग और कैश, लागत के लिए संदर्भ थ्रॉटलिंग और मॉडल चयन महत्वपूर्ण हैं।
• पुन: अनुक्रमणित किए बिना, सूचकांक पुराना हो जाता है; बदलते दस्तावेज़ों को नियमित रूप से पुन: संसाधित करें।

आवेदन कार्य

अपनी टीम के लिए एक सहायक का वास्तुशिल्प आरेख बनाएं। (1) कम से कम तीन वास्तविक डेटा स्रोतों की पहचान करें और प्रत्येक के लिए कनेक्टर की आवश्यकता, अद्यतन आवृत्ति और विश्वास स्तर लिखें। (2) बॉक्स-एरो आरेख के साथ अनुक्रमण और क्वेरी लाइनें अलग-अलग बनाएं। (3) "मैं इस सहायक में विलंबता और लागत को कहाँ कम करूँ?" प्रश्न पर कम से कम दो ठोस निर्णय लिखें। (4) अपनी ताज़ा रणनीति का एक वाक्य में वर्णन करें: किस संसाधन को पुन: अनुक्रमित किया जाएगा और कितनी बार?

जांच सूची

• [ ] मैं अनुक्रमण और क्वेरी लाइनें अलग-अलग और सही घटकों के साथ खींच सकता हूं।
• [ ] मैं मल्टी-सोर्स डेटा को source_type और ट्रस्ट प्राथमिकता के साथ जोड़ सकता हूं।
• [ ] मैं विलंबता के लिए स्ट्रीमिंग/कैश निर्णय और लागत के लिए मॉडल चयन कर सकता हूं।
• [ ] मैं जानता हूं कि पुन: अनुक्रमणिका रणनीति क्यों आवश्यक है।
• [ ] मैं इस बात को ध्यान में रखता हूं कि मेरे आर्किटेक्चर में सबसे महंगा कदम आमतौर पर टोकन होता है जो बड़े मॉडल को जाता है।