अंतिम समीक्षा: जून 2026
NCP-AAI परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
एक जटिल वर्कफ़्लो के लिए एक agent और मल्टी-agent सिस्टम के बीच चयन करना।
टूल के साथ एक सिंगल agent को डिफ़ॉल्ट करें। मल्टीपल agents में तभी विभाजित करें जब टास्क की सीमाएं अलग हों, context ओवरफ्लो हो, या विभिन्न मॉडल टियर विभिन्न सब-टास्क के लिए उपयुक्त हों।
क्यों: प्रत्येक जोड़ा गया agent विलंबता (latency), त्रुटि सतह (error surface), और ऑर्केस्ट्रेशन लागत को कई गुना बढ़ा देता है; अधिकांश वर्कलोड एक अच्छी तरह से तैयार किए गए agent के साथ सफल होते हैं।
ऑर्केस्ट्रेटर को विषम सब-टास्क को विशेषज्ञों को भेजना होगा।
एक पर्यवेक्षक agent का उपयोग करें जो लक्ष्य को विघटित करता है, अपने स्वयं के प्रॉम्प्ट और टूल के साथ कार्यकर्ता agents को रूट करता है, और परिणामों को एकत्रित करता है।
क्यों: केंद्रीकृत नियंत्रण स्थिति को सुसंगत रखता है और निर्णय सीमा को ऑडिट करने योग्य बनाता है, बनाम एक स्वतंत्र झुंड।
agent फ़्लो में सशर्त शाखाएँ, लूप और समानांतर फ़ैन-आउट हैं।
वर्कफ़्लो को एक फ्री-फॉर्म लूप के बजाय नोड्स और किनारों के एक स्पष्ट ग्राफ़ के रूप में मॉडल करें, ताकि नियंत्रण प्रवाह नियतात्मक (deterministic) और फिर से शुरू करने योग्य हो।
क्यों: एक ग्राफ़ शाखाओं को परीक्षण योग्य बनाता है और आपको विफलता के बाद किसी भी नोड से चेकपॉइंट और रीप्ले करने देता है।
आने वाले अनुरोध प्रकार और लागत में व्यापक रूप से भिन्न होते हैं।
सिस्टम को एक हल्के router agent से जोड़ें जो इरादे को वर्गीकृत करता है और सबसे सस्ते सक्षम डाउनस्ट्रीम agent या टूल को भेजता है।
क्यों: रूटिंग तुच्छ अनुरोधों के लिए फ्रंटियर-मॉडल लागत का भुगतान करने से बचाती है और प्रति पथ चिंताओं को अलग करती है।
कई agents को सामान्य वर्कफ़्लो स्थिति को पढ़ना और लिखना चाहिए।
एजेंटों के बीच पूरी प्रतिलेख (transcript) पास करने के बजाय, सत्र द्वारा कुंजीबद्ध एक साझा स्टोर (की-वैल्यू या डॉक्यूमेंट) में स्थिति को बाहरी बनाएं।
क्यों: एक साझा स्टोर context वृद्धि को सीमित करता है और agents में स्थिति की भिन्न प्रतियों को रोकता है।
क्षैतिज स्केल-आउट के लिए agents को डिज़ाइन करना।
agent कंप्यूट को stateless रखें; बातचीत और मेमोरी को बाहरी रूप से बनाए रखें ताकि कोई भी प्रतिकृति (replica) किसी भी अनुरोध को उठा सके।
क्यों: Stateless नोड्स सफाई से स्वतः स्केल करते हैं और इन-फ्लाइट काम खोए बिना पॉड रीस्टार्ट से बचते हैं।
एक सब-agent या टूल वर्कफ़्लो के बीच में विफल हो जाता है।
रीट्राय/बैकऑफ़ के साथ आइडेंपोटेंट (idempotent) चरणों को डिज़ाइन करें, साइड इफेक्ट्स के लिए क्षतिपूर्ति क्रियाएं, और जब रीट्राय समाप्त हो जाएं तो एक फ़ॉलबैक पथ या मानव हस्तक्षेप की सुविधा प्रदान करें।
क्यों: Agentic सिस्टम आंशिक रूप से विफल होते हैं; रिकवरी को एक प्रथम-श्रेणी की डिज़ाइन चिंता होनी चाहिए, न कि एक afterthought।
सब-agents को अलग-अलग टीमों द्वारा विकसित किया जाता है।
प्रत्येक agent के इनपुट/आउटपुट कॉन्ट्रैक्ट को एक टाइप किए गए schema के रूप में परिभाषित करें और agents को स्थिर इंटरफेस के पीछे सेवाओं के रूप में मानें।
क्यों: स्पष्ट अनुबंध agents को स्वतंत्र रूप से विकसित होने और अलगाव में यूनिट-टेस्ट होने देते हैं।
कठिन कार्यों पर agent आउटपुट गुणवत्ता असंगत है।
एक आलोचक/प्रतिबिंब चरण जोड़ें जो मसौदे की समीक्षा मानदंडों के खिलाफ करता है और लौटने से पहले एक सीमित पुनः प्रयास को ट्रिगर करता है।
क्यों: स्व-आलोचना सस्ते में त्रुटियों को पकड़ती है, लेकिन runaway लूप और लागत से बचने के लिए पुनरावृत्तियों को सीमित करें।
agent को बाहरी API, डेटाबेस या फ़ाइलों के साथ इंटरैक्ट करना चाहिए।
क्षमताओं को टाइप किए गए फ़ंक्शन/टूल परिभाषाओं के रूप में उजागर करें; मॉडल एक टूल कॉल उत्सर्जित करता है, आपका कोड उसे निष्पादित करता है और परिणाम लौटाता है, फिर लूप जारी रहता है।
क्यों: संरचित टूल कॉलिंग फ्री-टेक्स्ट निर्देशों को पार्स करने की तुलना में अधिक विश्वसनीय और ऑडिट करने योग्य है।
agent को फिर से कार्य करने से पहले टिप्पणियों के बारे में सोचना चाहिए।
एक ReAct लूप लागू करें: मॉडल एक विचार उत्पन्न करता है, एक टूल का चयन करता है, अवलोकन प्राप्त करता है, और एक स्टॉप शर्त पूरी होने तक दोहराता है।
क्यों: तर्क और कार्रवाई को इंटरलीव करने से डिबगिंग के लिए श्रृंखला उजागर होती है और मल्टी-स्टेप सटीकता में सुधार होता है।
मॉडल टूल आर्गुमेंट का दुरुपयोग करता है या hallucinate करता है।
सटीक टूल विवरण लिखें, आर्गुमेंट प्रकारों और enums को सीमित करें, और प्रति टूल एक या दो उपयोग उदाहरण प्रदान करें।
क्यों: अधिकांश टूल-कॉल त्रुटियाँ अस्पष्ट schemas से उत्पन्न होती हैं; विवरण टूल के लिए प्रॉम्प्ट है।
डाउनस्ट्रीम कोड को agent से विश्वसनीय JSON की आवश्यकता है।
जेनरेशन को JSON schema (संरचित आउटपुट) तक सीमित करें, न कि फ्री टेक्स्ट को पार्स करने तक, और उपयोग से पहले validate करें।
क्यों: Schema-constrained डिकोडिंग नाजुक regex पार्सिंग और साइलेंट फ़ॉर्मेट ड्रिफ्ट को समाप्त करता है।
NVIDIA स्टैक पर एक प्रोडक्शन agent बनाना।
एजेंटों, टूल और वर्कफ़्लो को संयोजित करने के लिए NeMo Agent Toolkit का उपयोग करें, NIM-served बैकएंड को मॉडल कॉल को वायर करें।
क्यों: टूलकिट agent प्लंबिंग को मानकीकृत करता है और NVIDIA सर्विंग के साथ मूल रूप से एकीकृत होता है।
एक टूल एक त्रुटि लौटाता है या टाइम आउट हो जाता है।
त्रुटि को टूल परिणाम के रूप में मॉडल पर वापस लौटाएं ताकि वह पुनः प्रयास कर सके, आर्गुमेंट को समायोजित कर सके, या एक वैकल्पिक पथ चुन सके।
क्यों: एजेंट को विफलताओं को सामने लाने से रिकवरी सक्षम होती है; उन्हें निगलने से agent अंधा हो जाता है।
एक चरण में कई स्वतंत्र टूल कॉल की आवश्यकता होती है।
जब मॉडल इसका समर्थन करता है और कॉल में कोई ऑर्डरिंग निर्भरता नहीं होती है, तो समानांतर में टूल कॉल जारी करें, फिर परिणामों को मर्ज करें।
क्यों: समानांतर निष्पादन मल्टी-सोर्स लुकअप जैसे फैन-आउट काम के लिए वॉल-क्लॉक विलंबता को कम करता है।
एक विशेषज्ञ क्षमता वर्कफ़्लो में पुनः प्रयोज्य होनी चाहिए।
एक सब-agent को एक सिंगल टूल इंटरफ़ेस के पीछे लपेटें ताकि पैरेंट इसे किसी अन्य टूल की तरह इनवोक कर सके।
क्यों: सब-एजेंटों को टूल के रूप में मानना कंपोजीशन को एक समान रखता है और आंतरिक जटिलता को छुपाता है।
agent कार्य से भटक जाता है या बाधाओं को अनदेखा करता है।
एक संक्षिप्त सिस्टम प्रॉम्प्ट में भूमिका, अनुमत टूल, आउटपुट प्रारूप और कठोर बाधाओं को पिन करें; अंत के पास महत्वपूर्ण नियमों को दोहराएं।
क्यों: एक टाइट सिस्टम प्रॉम्प्ट agent व्यवहार पर सबसे सस्ता, सबसे अधिक प्रभावकारी नियंत्रण है।
यह मापना कि क्या किसी agent ने मल्टी-स्टेप कार्य को सही ढंग से हल किया है।
एक लेबल किए गए सेट के खिलाफ अंतिम उत्तर और trajectory – टूल-कॉल सटीकता, चरण क्रम, और अनावश्यक क्रियाएं – दोनों का मूल्यांकन करें।
क्यों: टूटी हुई trajectory से एक सही उत्तर नाजुक होता है; trajectory स्कोरिंग गुप्त विफलताओं को पकड़ती है।
ओपन-एंडेड agent आउटपुट के लिए कोई ग्राउंड-ट्रुथ लेबल मौजूद नहीं हैं।
आउटपुट को स्कोर करने के लिए एक रूब्रिक के साथ एक LLM-as-judge का उपयोग करें, जिसे एक छोटे मानव-लेबल वाले नमूने के खिलाफ कैलिब्रेट किया गया हो।
क्यों: जज मॉडल मूल्यांकन को स्केल करते हैं, लेकिन उन्हें कैलिब्रेट किया जाना चाहिए अन्यथा वे अपना स्वयं का पूर्वाग्रह एन्कोड करते हैं।
आपको प्रत्येक रिलीज से पहले regressions को पकड़ने की आवश्यकता है।
एक निश्चित परिदृश्य सूट के साथ एक ऑफ़लाइन eval हार्नेस बनाएं जो हर बदलाव पर चलता है और पास थ्रेशोल्ड पर डिप्लॉयमेंट को नियंत्रित करता है।
क्यों: Agentic व्यवहार प्रॉम्प्ट या मॉडल परिवर्तनों के साथ सूक्ष्मता से बदलता है; एक regression सूट सुरक्षा जाल है।
agent गलत टूल या गलत आर्गुमेंट चुनता है।
टूल-चयन परिशुद्धता/रिकॉल और आर्गुमेंट वैधता को स्टैंडअलोन मेट्रिक्स के रूप में ट्रैक करें, न कि केवल एंड-टास्क सफलता के रूप में।
क्यों: टूल-कॉल लेयर को अलग करने से पता चलता है कि विफलताएं चयन से आती हैं या schema से।
परिवर्तन के बाद Eval पास दर गिर गई।
विफल मामलों की पूर्ण trajectories का निरीक्षण करें, विफलता मोड को क्लस्टर करें, और पहले प्रमुख क्लस्टर को ठीक करें।
क्यों: एग्रीगेट स्कोर मूल कारण को छिपाते हैं; प्रति-ट्रेस क्लस्टरिंग वास्तविक दोष को उजागर करती है।
agent कम प्रदर्शन करता है और आपको इसे सुधारना चाहिए।
पहले प्रॉम्प्ट और टूल विवरणों को दोहराएं; केवल तभी एक बड़े मॉडल या फाइन-ट्यूनिंग पर आगे बढ़ें जब प्रॉम्प्ट परिवर्तन स्थिर हो जाएं।
क्यों: प्रॉम्प्ट पुनरावृत्ति तेज़ और सस्ती है; मॉडल स्वैप लागत बढ़ाते हैं और साक्ष्य-आधारित होने चाहिए।
दो agent डिज़ाइनों की तुलना करना जो दोनों सटीकता लक्ष्यों को पास करते हैं।
मूल्यांकन में प्रति-कार्य लागत और p95 विलंबता जोड़ें ताकि सस्ता, तेज़ डिज़ाइन टाई जीत सके।
क्यों: उत्पादन व्यवहार्यता सटीकता प्लस लागत प्लस विलंबता है, न कि केवल सटीकता।
उत्पादन में agents के लिए मॉडल अनुमान (inference) प्रदान करना।
मॉडल को NIM माइक्रोसर्विसेज के रूप में डिप्लॉय करें, agents को बिल्ट-इन बैचिंग के साथ एक मानकीकृत, GPU-त्वरित अनुमान एंडपॉइंट प्रदान करें।
क्यों: NIM एक स्थिर API के पीछे अनुकूलित अनुमान को पैक करता है ताकि agents को सर्विंग आंतरिकों का प्रबंधन न करना पड़े।
agent ट्रैफ़िक अस्थिर और अप्रत्याशित है।
एजेंटों और सर्विंग को कंटेनराइज़ करें, Kubernetes पर चलाएं, और समझदार न्यूनतम/अधिकतम सीमाओं के साथ समवर्तीता या GPU उपयोग पर स्वतः स्केल करें।
क्यों: ऑटोस्केलिंग स्पाइक्स को अवशोषित करता है जबकि न्यूनतम प्रतिकृतियां (min replicas) महत्वपूर्ण पथ पर कोल्ड-स्टार्ट विलंबता से बचती हैं।
लोड के तहत GPU अनुमान लागत बहुत अधिक है।
हार्डवेयर जोड़ने से पहले प्रति-GPU-सेकंड टोकन बढ़ाने के लिए NIM लेयर पर डायनेमिक/कंटीन्यूअस बैचिंग सक्षम करें।
क्यों: बैचिंग GPU उपयोगिता में नाटकीय रूप से सुधार करता है; पहले नोड्स को स्केल करना क्षमता बर्बाद करता है।
एजेंट असीमित समानांतर टूल और मॉडल कॉल लॉन्च करते हैं।
एक क्यू के साथ प्रति-agent और वैश्विक समवर्तीता सीमाएं लागू करें ताकि सिस्टम लोड के तहत gracefully डिग्रेड हो।
क्यों: असीमित फैन-आउट GPU और डाउनस्ट्रीम कोटा को समाप्त कर देता है, जिससे विफलताएं होती हैं।
एक agent अनुमान वर्कलोड के लिए GPU हार्डवेयर का चयन करना।
मॉडल फुटप्रिंट और विलंबता लक्ष्यों के अनुसार आकार दें — स्थापित बड़े मॉडलों के लिए H100, Blackwell जहां मेमोरी बैंडविड्थ और रीजनिंग थ्रूपुट हावी होते हैं।
क्यों: मॉडल से हार्डवेयर का मिलान अंडर-प्रोविजनिंग और निष्क्रिय क्षमता के लिए भुगतान दोनों से बचाता है।
एक नए agent या मॉडल संस्करण को सुरक्षित रूप से शिप करना।
एक छोटे ट्रैफ़िक स्लाइस को canary के माध्यम से रोल आउट करें, लाइव मेट्रिक्स की तुलना baseline से करें, फिर आगे बढ़ें या रोल बैक करें।
क्यों: agent व्यवहार परिवर्तनों की ऑफ़लाइन पूरी तरह से भविष्यवाणी करना मुश्किल है; canary ब्लास्ट रेडियस को सीमित करता है।
लंबी agent श्रृंखलाओं में अनुरोधों के लटकने का जोखिम होता है।
प्रति-चरण और एंड-टू-एंड टाइमआउट बजट निर्धारित करें; अधिक होने पर रद्द करें और फ़ॉलबैक करें।
क्यों: बजट के बिना एक धीमा टूल एक GPU स्लॉट को पिन कर सकता है और अन्य अनुरोधों को भूखा रख सकता है।
कार्य के लिए कई परस्पर निर्भर चरणों की आवश्यकता होती है।
एक योजना-और-निष्पादित पैटर्न का उपयोग करें: पहले एक स्पष्ट योजना उत्पन्न करें, फिर चरणों को निष्पादित करें, जब कोई धारणा टूट जाए तो पुनः योजना बनाएं।
क्यों: पहले से योजना बनाने से भटकना कम होता है और टूल कॉल खर्च करने से पहले मान्य करने के लिए एक चेकपॉइंट मिलता है।
विघटन की गुणवत्ता bottleneck है।
Nemotron रीजनिंग मॉडल को योजना चरण पर रूट करें जबकि निष्पादन के लिए सस्ते मॉडल का उपयोग करें।
क्यों: रीजनिंग-ग्रेड कंप्यूट को वहां खर्च करें जहां यह मायने रखता है — योजना पर — न कि हर नियमित सब-स्टेप पर।
agent को एक लंबे सत्र में तथ्यों को याद रखना चाहिए।
हाल के मोड़ को वर्किंग context में रखें; मांग पर पुनः प्राप्त किए गए दीर्घकालिक मेमोरी स्टोर में टिकाऊ तथ्यों को बनाए रखें।
क्यों: सब कुछ context में डालने से लागत और विलंबता बढ़ जाती है और अंततः विंडो ओवरफ्लो हो जाती है।
agent मेमोरी को कैसे स्टोर किया जाए, यह चुनना।
एपिसोडिक इंटरेक्शन हिस्ट्री को semantic तथ्यों से अलग स्टोर करें; समानता से semantic मेमोरी, recency/session से एपिसोडिक मेमोरी को पुनः प्राप्त करें।
क्यों: विभिन्न एक्सेस पैटर्न के लिए विभिन्न स्टोर्स की आवश्यकता होती है; एक ही बकेट दोनों के लिए खराब प्रदर्शन करता है।
एक लंबी चलने वाली बातचीत context सीमा के करीब पहुंचती है।
पुराने मोड़ों को एक संक्षिप्त चल रहे सारांश में सारांशित करें और raw इतिहास को छोड़ दें, केवल हाल के verbatim मोड़ों को रखें।
क्यों: रोलिंग सारांश टोकन लागत को सीमित करते हुए और ट्रंकेशन त्रुटियों से बचते हुए निरंतरता बनाए रखता है।
agent को निजी एंटरप्राइज़ डेटा में उत्तरों को आधारित करना चाहिए।
agent को एक vector स्टोर पर एक पुनर्प्राप्ति टूल दें ताकि वह यह तय कर सके कि कब और क्या पुनर्प्राप्त करना है, बजाय हमेशा context को prepend करने के।
क्यों: Agentic पुनर्प्राप्ति केवल तभी fetch करती है जब आवश्यकता हो, टोकन और अप्रासंगिक context को कम करती है।
NVIDIA पर एक उच्च गुणवत्ता वाली पुनर्प्राप्ति पाइपलाइन बनाना।
त्वरित, उत्पादन-ग्रेड RAG के लिए NeMo Retriever एंबेडिंग और रीरैंकिंग NIM माइक्रोसर्विसेज का उपयोग करें।
क्यों: NeMo Retriever GPU पर कुशलता से परोसे गए ट्यून किए गए एंबेडिंग/रीरैंक मॉडल प्रदान करता है।
शुद्ध vector खोज सटीक-मिलान और कीवर्ड प्रश्नों को चूक जाती है।
घने vector खोज को sparse/कीवर्ड पुनर्प्राप्ति के साथ मिलाएं और विलय किए गए उम्मीदवारों को पुनर्व्यवस्थित करें।
क्यों: हाइब्रिड पुनर्प्राप्ति सटीक शब्दों (आईडी, कोड) को पुनर्प्राप्त करती है जिन्हें embeddings धुंधला कर देते हैं।
पुनः प्राप्त किए गए chunks बहुत मोटे या बहुत खंडित हैं।
मामूली ओवरलैप के साथ semantic सीमाओं पर chunk करें और मेटाडेटा संलग्न करें; आकार को एंबेडिंग मॉडल और क्वेरी प्रकार के अनुसार ट्यून करें।
क्यों: Chunk की granularity सीधे पुनर्प्राप्ति प्रासंगिकता को संचालित करती है; दोनों चरम grounding को कम करते हैं।
agent इंडेक्स से बासी जानकारी लौटाता है।
स्रोत परिवर्तनों पर इंक्रीमेंटल री-इंडेक्सिंग को पाइपलाइन करें और recency-aware रैंकिंग के लिए टाइमस्टैम्प के साथ डॉक्यूमेंट्स को स्टैम्प करें।
क्यों: ताजगी हैंडलिंग के बिना, RAG आत्मविश्वास से उत्तरों को पुराने डेटा में आधारित करता है।
agent रीजनिंग के लिए एक मॉडल बैकएंड का चयन करना।
रीजनिंग लोड के अनुसार आकार का एक Nemotron मॉडल चुनें और मानकीकृत एंडपॉइंट के लिए इसे NIM के माध्यम से परोसें।
क्यों: Nemotron रीजनिंग वेरिएंट agentic योजना और टूल उपयोग के लिए ट्यून किए गए हैं; NIM सर्विंग को मानकीकृत करता है।
एक agentic आवश्यकता को सही NVIDIA घटक पर मैप करना।
ऑर्केस्ट्रेशन के लिए NeMo Agent Toolkit, सर्विंग के लिए NIM, RAG के लिए NeMo Retriever, सुरक्षा के लिए NeMo Guardrails, और रीजनिंग के लिए Nemotron का उपयोग करें।
क्यों: यह जानना कि कौन सा घटक किस चिंता का मालिक है, एक आवर्ती परीक्षा और डिज़ाइन निर्णय है।
NVIDIA पर एक एंड-टू-एंड agentic एप्लिकेशन को असेंबल करना।
agent लेयर के पीछे अलग-अलग NIM माइक्रोसर्विसेज (LLM, embedding, rerank, guardrails) को संयोजित करें, प्रत्येक को स्वतंत्र रूप से स्केल करें।
क्यों: माइक्रोसर्विसेज डीकंपोजिशन प्रत्येक क्षमता को अपने आप स्केल और वर्जन करने देता है।
डेटा रेजिडेंसी नियम बाहरी API को डेटा भेजने से रोकते हैं।
अपने स्वयं के GPU इंफ्रास्ट्रक्चर पर NIM माइक्रोसर्विसेज को सेल्फ-होस्ट करें ताकि मॉडल और डेटा सीमा के भीतर रहें।
क्यों: NIM की पोर्टेबल पैकेजिंग ऑन-प्रेम डिप्लॉयमेंट का समर्थन करती है जो रेजिडेंसी आवश्यकताओं को पूरा करती है।
एक प्रोडक्शन agent दुर्व्यवहार करता है और आपको इसका निदान करना होगा।
प्रत्येक मॉडल कॉल, टूल कॉल और निर्णय को कैप्चर करते हुए वितरित ट्रेस उत्सर्जित करें, फिर विफल trajectory का एंड-टू-एंड निरीक्षण करें।
क्यों: agent विफलताएं मल्टी-स्टेप होती हैं; पूर्ण ट्रेस के बिना आप यह पता नहीं लगा सकते कि रीजनिंग कहां गलत हुई।
agent टोकन खर्च और विलंबता समय के साथ बढ़ती जाती है।
प्रति agent और प्रति टूल टोकन, लागत और p95 विलंबता को ट्रैक करें, थ्रेशोल्ड उल्लंघन पर अलर्ट के साथ।
क्यों: प्रॉम्प्ट और ट्रैफ़िक के विकसित होने पर लागत और विलंबता चुपचाप बढ़ती जाती है; मेट्रिक्स इसे जल्दी पकड़ लेते हैं।
कोड परिवर्तनों के बिना गुणवत्ता धीरे-धीरे घटती है।
उत्पादन नमूनों के खिलाफ eval सूट को लगातार चलाएं और baseline से मीट्रिक ड्रिफ्ट पर अलर्ट करें।
क्यों: डेटा और अपस्ट्रीम-मॉडल ड्रिफ्ट रिलीज़ के बीच गुणवत्ता को अदृश्य रूप से कम करते हैं।
agent को विषय पर बने रहना चाहिए और असुरक्षित अनुरोधों को अस्वीकार करना चाहिए।
agent के चारों ओर इनपुट, आउटपुट, सामयिक (topical) और संवाद (dialog) rails के साथ NeMo Guardrails लागू करें।
क्यों: प्रोग्रामेबल rails मॉडल के स्वयं के व्यवहार से स्वतंत्र, और उसके एक बैकस्टॉप के रूप में नीति लागू करते हैं।
अविश्वसनीय सामग्री पुनर्प्राप्त या टूल डेटा के माध्यम से agent को हाईजैक कर सकती है।
सभी बाहरी सामग्री को अविश्वसनीय मानें, इसे निर्देशों से अलग करें, और टूल प्राधिकरण को सीमित करें ताकि इंजेक्ट किए गए कमांड escalate न हो सकें।
क्यों: इंजेक्शन agent की शक्ति का शोषण करता है; बचाव न्यूनतम-विशेषाधिकार प्लस निर्देश/डेटा पृथक्करण है।
agent विनियमित या व्यक्तिगत डेटा को संभालता है।
मॉडल कॉल से पहले PII को redact या tokenize करें और agent क्रियाओं और टूल इनवोकेशन के छेड़छाड़-प्रूफ ऑडिट लॉग लिखें।
क्यों: अनुपालन में जोखिम को कम करना और यह साबित करना दोनों शामिल हैं कि agent ने क्या किया।
agent भुगतान या विलोपन जैसे उच्च-जोखिम वाले कार्य कर सकता है।
अपरिवर्तनीय या उच्च-प्रभाव वाले टूल कॉल से पहले एक मानव अनुमोदन गेट डालें, पुष्टि होने तक वर्कफ़्लो को रोकें।
क्यों: रिवर्सिबल चरणों के लिए स्वायत्तता ठीक है; महत्वपूर्ण कार्यों के लिए लूप में एक मानव की आवश्यकता होती है।
agent अनिश्चित है या बार-बार एक कार्य में विफल रहता है।
एक आत्मविश्वास/विफलता सीमा परिभाषित करें जो अनुमान लगाने के बजाय पूर्ण context के साथ एक मानव तक बढ़ जाती है।
क्यों: उच्च-दांव वाले काम पर एक आत्मविश्वासी गलत उत्तर को graceful handoff मात देता है।
हितधारक agent के आउटपुट पर अविश्वास करते हैं।
agent के तर्क सारांश, स्रोतों और उपयोग किए गए टूल को सामने लाएं ताकि मानव निर्णयों की समीक्षा और उन्हें ओवरराइड कर सकें।
क्यों: व्याख्यात्मकता विश्वास बनाती है और अक्सर निरीक्षण और ऑडिट के लिए आवश्यक होती है।