इस पेज पर
कल्पना करें कि प्रोडक्ट कैटलॉग सोमवार को बदलता है. असिस्टेंट के प्रॉम्प्ट में अभी भी शुक्रवार की सूची है. टीम प्रॉम्प्ट अपडेट करती है. पुरानी सूची की दूसरी कॉपी मॉडल प्रशिक्षण में उपयोग हुए उदाहरणों में है. अब असिस्टेंट एक ही सत्र में एक वर्तमान और एक पुराना उत्तर देता है.
यह उदाहरण की विफलता है, लेकिन उसका तरीका आम है: एक तथ्य के कई घर बन गए हैं.
प्रॉम्प्ट, खोज और मॉडल वज़न पर चर्चा उपयोगी सीमा खींचती है. प्रॉम्प्ट असिस्टेंट को व्यवहार बताता है. खोज किसी विशेष काम में वर्तमान और उद्धृत की जा सकने वाली जानकारी लाती है. मॉडल अनुकूलन स्थिर पैटर्न सिखा सकता है. इन्हें सीढ़ी मानना, जिसमें पहले प्रॉम्प्ट, फिर खोज, और उत्तर गलत रहे तो फ़ाइन-ट्यूनिंग हो, तथ्यात्मक त्रुटि का गलत निदान करता है.
प्रॉम्प्ट कमज़ोर कैटलॉग है
प्रॉम्प्ट आकर्षक हैं क्योंकि बदलना आसान है. एक पैराग्राफ़ जोड़ें और अगला अनुरोध उसे ले जाएगा. इस सुविधा में दो लागतें छिपी हैं. तथ्य हर कॉल के साथ भेजा जाता है, तब भी जब वह प्रासंगिक नहीं. और बड़ा प्रॉम्प्ट यह जानना कठिन बनाता है कि मॉडल ने नियम की कौन सी कॉपी इस्तेमाल की.
“कैम्पेन भेजने से पहले पूछें” जैसा टिकाऊ निर्देश एजेंट के पास रहना चाहिए. इस स्टोर के वर्तमान कस्टम फ़ील्ड की सूची नहीं. अकाउंट एडमिन एट्रिब्यूट जोड़ दे तो वह बदल सकती है. टेनेंट के बीच अलग हो सकती है. एक वर्कस्पेस को दिखाई दे और दूसरे के लिए निषिद्ध हो सकती है.
Brevo कनेक्टर गाइड बताती है कि संपर्क सिंक के लिए फ़ील्ड की परिभाषाएं क्यों महत्वपूर्ण हैं. डेस्टिनेशन अकाउंट में एट्रिब्यूट घोषित न हो तो नाम के आधार पर सही दिखने वाला मैप अपेक्षित फ़ील्ड नहीं बना सकता. एजेंट को प्रशिक्षण से सामान्य फ़ील्ड सूची याद करने के बजाय अकाउंट का वर्तमान अनुबंध देखना चाहिए.
उपयोगी खोज परिणाम इतना छोटा हो कि उसे परखा जा सके. उसे बताना चाहिए कि वह किस अकाउंट या टेनेंट पर लागू है, कब पढ़ा गया और किस कार्य या फ़ील्ड के बारे में है. दो लौटे अंश असहमत हों तो सिस्टम अधिक सुगम वाक्य वाले अंश को चुपचाप न चुने, बल्कि टकराव दिखाए. सही अगला कदम नई खोज या समीक्षा हो सकता है, प्रॉम्प्ट को और ज़ोर से लिखना नहीं.
तथ्य को उसके दायरे के साथ खोजें
उपयोगी ज्ञान रिकॉर्ड में पाठ से अधिक होता है. स्रोत, संस्करण या खोज समय, अकाउंट का दायरा और उसे हटाने या बदलने का स्पष्ट तरीका चाहिए. एक व्यापारी अकाउंट में मिली फ़ील्ड परिभाषा दूसरे के लिए सार्वभौमिक नियम नहीं बननी चाहिए.
तब संपर्क एट्रिब्यूट का सवाल सबसे छोटा उत्तरदायी अंश खोज सकता है: फ़ील्ड नाम, प्रकार और वह अकाउंट जहां मौजूद है. उत्तर उस स्रोत की ओर जा सकता है. मैपिंग विफल हो तो टीम पूछ सकती है कि तथ्य पुराना था, गलत अकाउंट का परिणाम मिला या मॉडल ने सही अंश गलत समझा.
ये अलग सुधार हैं. टेनेंट सीमा पार करने वाला खोज फ़िल्टर प्रॉम्प्ट बदलने से ठीक नहीं होगा. किसी ने एट्रिब्यूट की परिभाषा खोजी ही नहीं तो बड़ा मॉडल उसे भरोसे से नहीं दे सकता.
MCP परिचय बताता है कि एजेंट टूल से कैसे पूछ सकता है. टूल संबंधित अनुबंध लौटाए, जबकि एप्लिकेशन लागू करे कि उसे कौन देख सकता है. “दूसरे टेनेंट की जानकारी न बताएं” जैसा पाठ सीमित दायरे की क्वेरी का विकल्प नहीं है.
यह बंटवारा सुधार को भी तेज़ करता है. डेस्टिनेशन फ़ील्ड का नाम बदले तो स्कीमा स्रोत अपडेट करें और प्रभावित मैपिंग अमान्य करें. एजेंट स्थिर निर्देश बार-बार गलत समझे तो निर्देश बदलें या लक्षित प्रशिक्षण जांचें. गलत अकाउंट चुनने के कारण उत्तर गलत हो तो मॉडल वज़न बदलना कारण तक नहीं पहुंचेगा. हर त्रुटि वर्ग का अलग स्वामी और सुधार मार्ग है.
- टिकाऊ निर्देश
असिस्टेंट कैसे व्यवहार करे
- दायरे वाली खोज अकाउंट · संस्करण · समय
अभी क्या सच है
- मैपिंग निर्णय
इस काम में वर्तमान तथ्य इस्तेमाल करें
- नियंत्रित लिखाई
कोड अनुमति और दायरा जांचता है
पैटर्न स्थिर होने के बाद ही सिखाएं
उचित आपत्ति है: “तथ्य बार-बार उपयोग होता है तो छोटे मॉडल को क्यों न सिखाएं?” दोहराव अकेला पर्याप्त नहीं. मॉडल अपडेट के बीच तथ्य सही रहना चाहिए और मॉडल को संदर्भ अलग करने का तरीका चाहिए.
वर्गीकरण की स्थिर शैली आगे चलकर प्रशिक्षण के योग्य हो सकती है. विक्रेता के वर्तमान फ़ील्ड की सूची अच्छी उम्मीदवार नहीं. कम बदलने पर भी एक पुराना उत्तर बहुत से रिकॉर्ड पर गलत मैपिंग लागू कर सकता है. तथ्य वहां रखें जहां व्यक्ति उसे देख और सुधार सके.
स्रोत चर्चा हर तर्क त्रुटि का हल खोज से निकालने के ख़िलाफ़ भी चेताती है. मॉडल दो प्रासंगिक दस्तावेज़ ठीक से न मिला सके तो पचास और दस्तावेज़ जोड़कर तर्क करना नहीं सिखेगा. पहले पूछें क्या सही अंश आया. फिर पूछें क्या उस पर निर्णय सही था.
इंटीग्रेशन बनाने वाले के लिए सुधार क्रम है: गलत दावा पहचानें; खोजा हुआ फ़ील्ड या API अंश देखें; अकाउंट और संस्करण जांचें; ज़रूरत हो तो स्रोत या खोज सुधारें; निर्णय फिर परखें. मॉडल बदलने पर उसके बाद ही विचार करें.
लागत एक वास्तविक ज्ञान परत संभालने की है: स्रोत अपडेट, पहुंच जांच और उद्धरण. लाभ है ऐसा तथ्य जिसे एक जगह सुधारा जा सके.
बदलते अनुबंध को मॉडल के भूलने का इंतज़ार नहीं करना चाहिए.
अक्सर पूछे जाने वाले प्रश्न
एजेंट प्रॉम्प्ट में क्या होना चाहिए?
व्यवहार और सीमाओं के छोटे, टिकाऊ निर्देश रखें. बदलते कैटलॉग, टेनेंट-विशिष्ट फ़ील्ड सूची या विक्रेता के वर्तमान नियम ज़रूरत पड़ने पर अनुमत स्रोत से खोजे जाने चाहिए.
वर्तमान दस्तावेज़ पर मॉडल को फ़ाइन-ट्यून क्यों न करें?
फ़ाइन-ट्यूनिंग बदलते तथ्य को ऐसे वज़न में बैठा सकती है जिन्हें देखना और अपडेट करना कठिन है. पहले सुनिश्चित करें कि निर्णय के समय सही दस्तावेज़ खोजा और उद्धृत किया गया था.
गलत तथ्यात्मक उत्तर कैसे सुधारें?
स्रोत दस्तावेज़, उसका संस्करण, खोज फ़िल्टर और लौटाया गया अंश देखें. मॉडल बदलने से पहले तथ्य या खोज का रास्ता सुधारें.