सहाय्यक आर्किटेक्चर जे कंपनी डेटाशी बोलतात

नफा:

• एंड-टू-एंड एंटरप्राइझ RAG असिस्टंटचे घटक आणि डेटा फ्लो डिझाइन करणे
• एकाच सहाय्यकामध्ये बहु-स्रोत डेटा (विकी, तिकीट, पीडीएफ, डेटाबेस) एकत्र करणे
• स्केलेबिलिटी, कॅशिंग आणि लेटन्सीसाठी आर्किटेक्चरल निर्णय घ्या

मागील युनिट्समध्ये, आम्ही भाग एक एक करून शिकलो: एम्बेडिंग, वेक्टर डेटाबेस, चंकिंग, पुनर्प्राप्ती. आता हे एकत्र करूया आणि तुमच्या स्वतःच्या कंपनीच्या डेटाशी बोलणाऱ्या असिस्टंटचे एंड-टू-एंड आर्किटेक्चर बनवू. कर्मचाऱ्याने "आमचे रजा धोरण काय आहे?" एक अशी प्रणाली जिथे लोक प्रश्न विचारू शकतात, उत्तरे वास्तविक अंतर्गत दस्तऐवज, उद्धरणांवर आधारित असतात आणि एकाधिक डेटा स्रोत एकत्र करतात. हे युनिट संपूर्ण आर्किटेक्चर, डेटा प्रवाह आणि उत्पादन स्तरावरील निर्णयांवर प्रक्रिया करते.

एंड-टू-एंड घटक

कॉर्पोरेट RAG असिस्टंटमध्ये दोन स्वतंत्र ओळी असतात. इंडेक्सिंग लाइन (ऑफलाइन) डेटा तयार करते; क्वेरी लाइन (ऑनलाइन) प्रश्नाचे उत्तर देते.

अनुक्रमणिका रेखा घटक:

1. कनेक्टर: कनेक्टर जे स्त्रोतांकडून डेटा खेचतात — विकी, तिकीट प्रणाली, फाइल स्टोअर, डेटाबेस, ईमेल.
2. सामान्यीकरण: विविध स्वरूपांचे (पीडीएफ, एचटीएमएल, डीओसीएक्स) मजकूर स्वच्छ करण्यासाठी रूपांतरित करणे; शीर्षलेख / तळटीप साफ करणे.
3. चंकिंग + मेटाडेटा: चंकिंग आणि टॅगिंग (स्रोत, तारीख, अधिकार).
4. एम्बेडिंग + लोडिंग: वेक्टर डेटाबेसमध्ये वेक्टर आणि मेटाडेटा लिहिणे.

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

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

टीप: इंडेक्सिंग लाइनला क्वेरी लाइनपासून भौतिकरित्या वेगळे करा. अनुक्रमणिका मंद आणि नियतकालिक आहे (रात्रभर बॅचमध्ये चालते); चौकशीची ओळ हलकी आणि तात्काळ असावी. वापरकर्ता प्रतीक्षा करत असताना दोन ओळींचे मिश्रण केल्याने जड प्रक्रिया करणे भाग पडते.

डेटा फ्लो व्हिज्युअलायझिंग

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

मल्टी-सोर्स डेटा एकत्र करणे

वास्तविक कंपन्यांमध्ये, उत्तर एकाच ठिकाणी थांबत नाही. "ग्राहकाला परतावा कसा जारी करायचा?" प्रश्नाचे उत्तर मदत लेख (कार्यपद्धती), तिकीट इतिहास (वास्तविक उदाहरणे) आणि पॉलिसी PDF (नियम) या दोन्हीमध्ये मिळू शकते. सहाय्यकाने त्या सर्वांचा एकाच पूलमध्ये शोध घ्यावा.

गंभीर मुद्दा: एकाच वेक्टर स्टोअरमध्ये संसाधने एकत्र करताना, प्रत्येक शार्डमध्ये `स्रोत_टूर` मेटाडेटा असणे आवश्यक आहे. त्यामुळे तुम्ही ते सर्व शोधू शकता आणि आवश्यक असल्यास ते फिल्टर करू शकता, जसे की "फक्त अधिकृत धोरणे आणा". तसेच, विविध स्त्रोतांमध्ये विश्वासार्हतेचे वेगवेगळे स्तर आहेत: अधिकृत धोरण > मदत लेख > कर्मचाऱ्याची तिकीट नोट. तुम्ही हे प्राधान्य री-रँकिंग किंवा प्रॉम्प्टमध्ये निर्दिष्ट करू शकता.

स्त्रोत

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

विश्वास

अद्यतन वारंवारता

पॉलिसी PDF

अधिकृत नियम

उच्च

मासिक

मदत लेख

कार्यपद्धती

मध्यम-उच्च

साप्ताहिक

तिकीट इतिहास

वास्तविक नमुना

मध्यम

सतत

विकी

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

चल

सतत

स्केलेबिलिटी, कॅशे आणि लेटन्सी

उत्पादनात तीन मुद्दे वेगळे आहेत. विलंब: जेव्हा वापरकर्ता 2 सेकंदांपेक्षा जास्त वेळ थांबतो तेव्हा अनुभव खराब होतो. उपाय: प्रवाह स्वरूपात उत्तर प्रदर्शित करा — मॉडेल लिहित असताना ते स्क्रीनवर ओतले जाते. कॅशे: वारंवार विचारले जाणारे प्रश्न आणि पुनरावृत्ती संदर्भांसाठी, कॅशे गती वाढवते आणि खर्च कमी करते. स्केल: वापरकर्ता जसजसा वाढतो, तसतसे पुनर्प्राप्ती आणि मॉडेल कॉल्स क्षैतिजरित्या मोजण्यात सक्षम असणे आवश्यक आहे.

खर्चाच्या बाजूने थंबचा नियम: सर्वात महाग पायरी म्हणजे सामान्यतः मोठ्या मॉडेलवर जाणाऱ्या टोकनची संख्या. म्हणून, पुन्हा रँकिंग करून संदर्भ 4 चांगल्या भागांपर्यंत कमी केल्याने गुणवत्ता आणि किंमत दोन्ही सुधारतात. साध्या वर्गीकरणासाठी किंवा राउटिंगसाठी लहान/जलद मॉडेल वापरणे आणि अंतिम उत्तरासाठी अधिक शक्तिशाली मॉडेल (उदा. क्लॉड-ऑपस-4-8) वापरणे हे सामान्य डिझाइन आहे.

खबरदारी: "हे एकदा करा, विसरा" असे अनुक्रमणिका सेट करू नका. कागदपत्रे बदलली, हटवली, जोडली. री-इंडेक्सिंग स्ट्रॅटेजी तयार करा: बदललेले दस्तऐवज शोधा आणि फक्त त्यावरच प्रक्रिया करा. शिळा निर्देशांक एक उत्तर तयार करतो जे वर्तमान दिसते परंतु चुकीचे आहे.

कमकुवत आर्किटेक्चर / मजबूत वास्तुकला

कमकुवत (एकल स्क्रिप्ट, सर्वकाही मिश्रित):

जेव्हा वापरकर्ता विचारतो: त्या क्षणी कागदपत्रे वाचा, त्यांचे तुकडे करा, त्यांना एम्बेड करा, त्यांना शोधा, त्यांना उत्तर द्या. # समस्या: प्रत्येक प्रश्नासाठी सर्व अनुक्रमणिका पुनरावृत्ती केली जाते; काही सेकंदांचा विलंब, # स्रोत वेगळे नाही, फिल्टर नाही, रिफ्रेश नाही.

शक्तिशाली (स्प्लिट पाईप्स + मेटाडेटा + कॅशे + स्ट्रीमिंग):

अनुक्रमणिका: बॅच रात्री चालते, बदललेले दस्तऐवज रीफ्रेश करते. क्वेरी: लाइटवेट लाइन — प्री-प्रोसेसिंग → हायब्रिड रिट्रीव्हल+फिल्टर → रँक → प्रॉम्प्ट → मॉडेल (स्ट्रीमिंग) → उद्धरण → लॉग. वारंवार विचारले जाणारे प्रश्न आणि स्त्रोत कॅश केलेले आहेत.

तीन मिनी केसेस

केस 1 - गोंधळलेली ओळ, खूप विलंब. स्टार्टअपने एक स्क्रिप्ट लिहिली जी प्रत्येक प्रश्नासह पीडीएफची पुनर्प्रक्रिया करते; प्रत्येक उत्तराला सरासरी 11 सेकंद लागले. जेव्हा इंडेक्सिंग लाइन विभक्त केली गेली आणि डेटा पूर्वी वेक्टर स्टोअरमध्ये हस्तांतरित केला गेला, तेव्हा क्वेरी वेळ 1.3 सेकंदांपर्यंत कमी झाला आणि स्ट्रीमिंगसह, "प्रथम शब्द" 400 ms मध्ये दिसला.

केस 2 - खूप संसाधने, चुकीचे प्राधान्य. एका सपोर्ट असिस्टंटने पॉलिसी पीडीएफ आणि जुन्या तिकीट नोटांना समान वजन दिले; मॉडेलने काहीवेळा अधिकृत नियम म्हणून दोन वर्षांपूर्वीच्या कर्मचाऱ्याचे चुकीचे रेटिंग सादर केले. जेव्हा source_tour मेटाडेटा आणि "विवादाच्या बाबतीत अधिकृत धोरण विचारात घ्या" सूचना प्रॉम्प्टमध्ये जोडल्या गेल्या, तेव्हा खोट्या-प्राधान्य त्रुटी 89% ने कमी झाल्या.

केस 3 - शिळा निर्देशांक. एक एचआर सहाय्यक एका निर्देशांकासह काम करत होता जो 3 महिन्यांसाठी अद्यतनित केला गेला नव्हता; रजेचे धोरण बदलले, पण सहाय्यक जुने दिवस सांगत होते. जेव्हा दैनंदिन रिफ्रेश स्थापित केले गेले, जे बदललेल्या फायली शोधते, वर्तमान-प्रतिसाद दर 70% वरून 99% पर्यंत वाढला.

सामान्य चुका

• अनुक्रमणिका आणि क्वेरी ओळींचे मिश्रण करणे: वापरकर्ता प्रतीक्षा करत असताना जोरदार प्रक्रिया केली जाते; विलंब होतो.
• मेटाडेटामध्ये स्त्रोत प्रकार न टाकणे: प्राधान्य आणि फिल्टरिंग नाही; अविश्वासू स्रोत अधिकृत असल्याचे दिसते.
• रीफ्रेश धोरण स्थापित न करणे: निर्देशांक शिळा होतो; वर्तमानात दिसणारी चुकीची उत्तरे तयार केली जातात.
• प्रवाह वगळा: वापरकर्ता रिक्त स्क्रीनकडे पाहतो; समजलेला विलंब जास्त होतो.
• प्रत्येक टप्प्यावर सर्वात मोठे मॉडेल वापरणे: खर्च अनावश्यकपणे वाढतो; स्टीयरिंग लहान मॉडेलवर सोडा.

सारांशात

• कॉर्पोरेट RAG असिस्टंटमध्ये दोन स्वतंत्र ओळी असतात: ऑफलाइन अनुक्रमणिका आणि ऑनलाइन क्वेरी; त्यांना शारीरिकरित्या वेगळे करा.
• अनुक्रमणिका = कनेक्टर + सामान्यीकरण + भाग/मेटाडेटा + एम्बेड/अपलोड; क्वेरी = पूर्व-प्रक्रिया + पुनर्प्राप्ती + प्रॉम्प्ट + जनरेट + पोस्ट-प्रक्रिया.
• बहु-स्रोत डेटा एका रेपॉजिटरीमध्ये एकत्र केला जातो, परंतु source_type मेटाडेटा आणि विश्वास प्राधान्य जतन केले जाते.
• प्रलंबिततेसाठी प्रवाह आणि कॅशे, संदर्भ थ्रॉटलिंग आणि किमतीसाठी मॉडेल निवड महत्त्वपूर्ण आहेत.
• री-इंडेक्सिंग न करता, निर्देशांक शिळा होतो; बदलत्या कागदपत्रांची नियमितपणे प्रक्रिया करा.

अर्ज कार्य

तुमच्या स्वतःच्या टीमसाठी असिस्टंटचा आर्किटेक्चरल डायग्राम काढा. (1) किमान तीन वास्तविक डेटा स्रोत ओळखा आणि प्रत्येकासाठी कनेक्टरची आवश्यकता, अद्यतन वारंवारता आणि विश्वास पातळी लिहा. (2) बॉक्स-एरो डायग्रामसह अनुक्रमणिका आणि क्वेरी रेषा स्वतंत्रपणे काढा. (३) “मी या असिस्टंटमध्ये विलंबता आणि खर्च कोठे कमी करू?” प्रश्नाचे किमान दोन ठोस निर्णय लिहा. (4) तुमच्या रीफ्रेश धोरणाचे एका वाक्यात वर्णन करा: कोणते संसाधन पुन्हा अनुक्रमित केले जाईल आणि किती वेळा?

चेकलिस्ट

• मी स्वतंत्रपणे आणि योग्य घटकांसह अनुक्रमणिका आणि क्वेरी रेषा काढू शकतो.
• [ ] मी source_type आणि विश्वास प्राधान्यासह मल्टी-सोर्स डेटा एकत्र करू शकतो.
• मी लेटन्सीसाठी स्ट्रीमिंग/कॅशे निर्णय घेऊ शकतो आणि खर्चासाठी मॉडेल निवडू शकतो.
• [ ] मला माहित आहे की री-इंडेक्सिंग धोरण का आवश्यक आहे.
• [ ] मी लक्षात ठेवतो की माझ्या आर्किटेक्चरमधील सर्वात महाग पायरी म्हणजे सामान्यतः मोठ्या मॉडेलकडे जाणारे टोकन.