सहायक वास्तुकला जसले कम्पनी डाटासँग कुरा गर्छ

लाभ:

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

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

अन्त-देखि-अन्त घटकहरू

एक कर्पोरेट RAG सहायकमा दुई अलग लाइनहरू हुन्छन्। अनुक्रमणिका रेखा (अफलाइन) डेटा तयार गर्दछ; क्वेरी लाइन (अनलाइन) प्रश्नको जवाफ दिन्छ।

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

1. कनेक्टरहरू: कनेक्टरहरू जसले स्रोतहरू - विकी, टिकट प्रणाली, फाइल स्टोर, डाटाबेस, इमेलबाट डाटा तान्छन्।
2. सामान्यीकरण: पाठ सफा गर्न विभिन्न ढाँचाहरू (PDF, HTML, DOCX) रूपान्तरण गर्दै; हेडर/फुटर सफाई।
3. Chunking + मेटाडेटा: Chunking र ट्यागिङ (स्रोत, मिति, अधिकार)।
4. इम्बेडिङ + लोडिङ: भेक्टर डाटाबेसमा भेक्टर र मेटाडेटा लेख्दै।

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

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

सुझाव: अनुक्रमणिका रेखालाई क्वेरी रेखाबाट भौतिक रूपमा अलग गर्नुहोस्। अनुक्रमणिका ढिलो र आवधिक हुन्छ (ब्याचहरूमा रातभर चल्छ); सोधपुछको लाइन हल्का र तत्काल हुनुपर्छ। दुई रेखाहरू मिश्रण गर्दा प्रयोगकर्ताले पर्खँदा भारी प्रशोधन गर्न बाध्य पार्छ।

डाटा प्रवाह को दृश्य

[INDEXING - अफलाइन]संसाधनहरू → सामान्य बनाउनुहोस् → Chunk+Metadata → Embed → Vector DB (wiki, टिकट, PDF, DB)[QUERY - अनलाइन]प्रयोगकर्ता प्रश्न → पूर्व प्रशोधन → पुन: प्राप्ति (हाइब्रिड+फिल्टर+पुनःप्राप्ति) → प्रम्प्ट (सन्दर्भ+प्रश्न+निर्देशन → प्रयोग → अनुदेश)

बहु-स्रोत डेटा संयोजन

वास्तविक कम्पनीहरूमा, जवाफ एक ठाउँमा रोकिँदैन। "ग्राहकलाई फिर्ता रकम कसरी जारी गर्ने?" प्रश्नको जवाफ मद्दत लेख (प्रक्रिया), टिकट इतिहास (वास्तविक उदाहरणहरू), र नीति PDF (नियम) मा दुवै पाउन सकिन्छ। सहायकले ती सबैलाई एउटै पोखरीमा खोज्नुपर्छ।

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

स्रोत

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

भरोसा

फ्रिक्वेन्सी अपडेट गर्नुहोस्

नीति PDF

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

उच्च

मासिक

मद्दत लेख

प्रक्रिया

मध्यम-उच्च

साप्ताहिक

टिकट इतिहास

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

मध्यम

निरन्तर

विकि

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

चर

निरन्तर

स्केलेबिलिटी, क्यास र विलम्बता

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

लागत पक्षमा औंठाको नियम: सबैभन्दा महँगो चरण सामान्यतया ठूलो मोडेलमा जाने टोकनहरूको संख्या हो। त्यसकारण, पुन: श्रेणीकरण गरेर सन्दर्भलाई 4 राम्रो भागहरूमा घटाउँदा गुणस्तर र लागत दुवै सुधार हुन्छ। साधारण डिजाईन भनेको साधारण वर्गीकरण वा राउटिङको लागि सानो/छिटो मोडेल र अन्तिम जवाफको लागि थप शक्तिशाली मोडेल प्रयोग गर्नु हो (जस्तै claude-opus-4-8)।

सावधानी: अनुक्रमणिकालाई "यसलाई एकपटक गर्नुहोस्, बिर्सनुहोस्" भनेर सेटअप नगर्नुहोस्। कागजातहरू परिवर्तन, मेटाइएको, थपिएको छ। पुन: अनुक्रमणिका रणनीति स्थापना गर्नुहोस्: परिवर्तन गरिएका कागजातहरू पत्ता लगाउनुहोस् र तिनीहरूलाई मात्र पुन: प्रशोधन गर्नुहोस्। बासी अनुक्रमणिकाले एउटा जवाफ उत्पादन गर्छ जुन वर्तमान देखिन्छ तर गलत छ।

कमजोर वास्तुकला / बलियो वास्तुकला

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

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

शक्तिशाली (स्प्लिट पाइपहरू + मेटाडेटा + क्यास + स्ट्रिमिङ):

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

तीन मिनी केसहरू

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

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

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

सामान्य गल्तीहरू

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

संक्षेपमा

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

आवेदन कार्य

तपाईंको आफ्नै टोलीको लागि सहायकको वास्तुकला रेखाचित्र कोर्नुहोस्। (1) कम्तिमा तीन वास्तविक डेटा स्रोतहरू पहिचान गर्नुहोस् र प्रत्येकको लागि कनेक्टर आवश्यकता, अद्यावधिक फ्रिक्वेन्सी, र विश्वास स्तर लेख्नुहोस्। (२) बक्स-एरो रेखाचित्रको साथ अनुक्रमणिका र क्वेरी रेखाहरू अलग-अलग कोर्नुहोस्। (३) "मैले यस सहायकमा विलम्बता र लागत कहाँ घटाउन सक्छु?" प्रश्नमा कम्तिमा दुई ठोस निर्णयहरू लेख्नुहोस्। (४) तपाईको रिफ्रेस रणनीतिलाई एक वाक्यमा वर्णन गर्नुहोस्: कुन स्रोत पुन: अनुक्रमणिका हुनेछ र कति पटक?

चेकलिस्ट

• [ ] म अनुक्रमणिका र क्वेरी लाइनहरू अलग र सही कम्पोनेन्टहरू कोर्न सक्छु।
• [ ] म source_type र भरोसा प्राथमिकताको साथ बहु-स्रोत डेटा संयोजन गर्न सक्छु।
• [ ] म लागतको लागि विलम्बता र मोडेल चयनको लागि स्ट्रिमिङ/क्यास निर्णयहरू गर्न सक्छु।
• [ ] मलाई थाहा छ किन पुन: अनुक्रमणिका रणनीति आवश्यक छ।
• [ ] म दिमागमा राख्छु कि मेरो वास्तुकलामा सबैभन्दा महँगो चरण सामान्यतया टोकन हो जुन ठूलो मोडेलमा जान्छ।