gabrielmoreira माइक्रोसफ्ट फाउन्ड्रीसँग स्केलेबल एजेन्टहरूको परिनियोजन
पाठ १६ – स्केलेबल एजेन्टहरूको परिनियोजन को लागि सहायक कौशल। यसलाई प्रयोग गरेर एक सिक्ने व्यक्तिलाई एउटा एजेन्टलाई प्रोटोटाइपबाट स्केलेबल, अवलोकनीय उत्पादन परिनियोजनमा सार्न मद्दत गर्नुहोस्। हरेक सिफारिसलाई पाठ्यक्रम सामग्री र चलाउने नोटबुकमा आधारित गर्नुहोस्; फाउन्ड्री API हरू आविष्कार नगर्नुहोस्।
ट्रिगरहरू
जब सिक्ने व्यक्तिले चाहन्छन् तब यो कौशल सक्रिय गर्नुहोस्:
- एजेन्टलाई माइक्रोसफ्ट फाउन्ड्रीमा होस्ट गरिएको एजेन्ट रूपमा परिनियोजन गर्नुहोस् र यो संस्करण/अवलोकनीय बनाएर राख्नुहोस्।
- क्लाइन्ट-होस्टेड, होस्टेड-एजेन्ट, र एजेन्ट-वर्कफ्लो परिनियोजन ढाँचाहरू बीच छान्नुहोस्।
- ढिलाइ र लागत नियन्त्रण गर्न मोडेल राउटिङ, प्रतिक्रिया क्यासिङ, वा सीमित समवर्तीता थप्नुहोस्।
- नराम्रो एजेन्ट संस्करण पठाउन नदिनको लागि मूल्यांकन गेट थप्नुहोस्।
- उच्च जोखिम कार्यहरूको लागि मानव-इन-द-लूप अनुमति चरण थप्नुहोस्।
- उत्पादन अवलोकनयोग्यताका लागि एजेन्टमा OpenTelemetry ट्रेसिङ इन्स्ट्रुमेन्ट गर्नुहोस्।
- परिनियोजित एजेन्टलाई छिटो पोस्ट-डिप्लो गेटको रूपमा स्मोक-टेस्ट गर्नुहोस्।
मुख्य मानसिक मोडल
उत्पादन एजेन्ट प्रायः मोडेलको वरिपरि सञ्चालनात्मक हाडजोर्नी हो (~८०%), मोडेल आफैँ होइन। हरेक सिफारिसलाई निम्न चासोहरूमध्ये एकमा नक्सांकन गर्नुहोस्:
| चासो | प्रोटोटाइप → उत्पादन |
|---|---|
| होस्टिङ | नोटबुक → संस्करण गरिएको होस्टेड सेवा |
| पहिचान | तपाईंको az login → व्यवस्थापित पहिचान + स्कोप गरिएको RBAC |
| अवस्था | इन-मेमोरी → बाह्य थ्रेड/मेमोरी स्टोर |
| असफलता | ट्रेसब्याक → पुनः प्रयासहरू, फ्यालब्याकहरू, चेतावनीहरू |
| लागत | "केही सेन्ट" → ट्र्याक गरिएको, राउट गरिएको, क्यास गरिएको, बजेट गरिएको |
| गुणस्तर | आँखा हाल्ने → स्वचालित मूल्यांकन गेट |
| विश्वास | तपाईंले अनुमोदन गर्नुभयो → नीति + मानव-इन-द-लूप |
परिनियोजन ढाँचाहरू (एक छान्नुहोस्, वा संयोजन गर्नुहोस्)
१. क्लाइन्ट-होस्टेड — कारणहरू मिल्ने लूप तपाईंको प्रक्रियामा चल्छ। अधिकतम नियन्त्रण; तपाईं स्केलिङ/अवस्था हकदार हुनुहुन्छ। २. होस्टेड एजेन्ट (फाउन्ड्री एजेन्ट सेवा) — फाउन्ड्रीले लूप होस्ट गर्छ, थ्रेडहरू भण्डारण गर्छ, RBAC/सामग्री सुरक्षा लागू गर्छ, एजेन्टलाई पोर्टलमा देखाउँछ। कम नियन्त्रण, धेरै कम सञ्चालन सतह। ३. एजेन्ट वर्कफ्लो — धेरै एजेन्टहरू/उपकरणहरू ग्राफमा संयोजित गरिन्छ जसमा शाखाहरू, अनुमति नोडहरू, र टिकाउ चेकप्वाइन्टहरू हुन्छन्।
जीवनचक्र (एजेन्ट पठाउने लूप)
create → version → evaluate (gate) → deploy hosted → observe online → collect failures → repeat.
अफलाइन मूल्यांकन गेट हो, पछि सोच्ने कुरा होइन — एउटा संस्करण पठाइँदैन
जबसम्म यो थ्रेसहोल्ड पार गर्दैन। अनलाइन अवलोकनीयताले वास्तविक असफलताहरूलाई अफलाइन परीक्षण सेटमा फिर्ता पठाउँछ।
स्केलिङ र लागत लीभर (प्राथमिकता अनुसार)
१. मोडेललाई सही आकार दिनुहोस् — मूल्यांकन गेट पास गर्ने सबैभन्दा सानो मोडेल प्रयोग गर्नुहोस्। २. जटिलताअनुसार राउट गर्नुहोस् — साधारण अनुरोधको लागि सानो/छिटो मोडेल, वास्तविक कारणको लागि ठूलो मोडेल (DIY क्लासिफायर वा फाउन्ड्री मोडेल राउटर)। ३. क्यास — मोडेल कल बिना नै नजिकका दोहोरिने अनुरोधहरू सेवा गर्नुहोस्। ४. स्टेटलेस डिजाइन + सीमित समवर्तीता — अवस्था बाह्य गर्नुहोस्; ब्याकअफसहित पुनः प्रयास गर्नुहोस्।
पुन:उत्पादन गर्न मुख्य ढाँचाहरू
सिक्ने व्यक्तिलाई नोटबुकबाट यी तर्फ निर्देशित गर्नुहोस्
16-python-agent-framework.ipynb:
- अनुरोध ह्यान्डलर: क्यास → जटिलताअनुसार राउट → ट्रेस स्प्यान → चलाउनुहोस् → क्यास।
- मूल्यांकन गेट: अफलाइन परीक्षण सेट स्कोर गर्नुहोस्;
pass_rate >= thresholdफर्काउनुहोस् र मात्र सत्य भएमा परिनियोजन गर्नुहोस्। - मानव अनुमोदन: ठूला फिर्तीहरू जस्ता कार्यहरूको लागि
@tool(approval_mode="always_require")। - ट्रेसिङ: प्रत्येक अनुरोधलाई
tracer.start_as_current_span(...)मा र्याप गर्नुहोस् रrouted.model,customer.idजस्ता विशेषताहरू सेट गर्नुहोस्।
परिनियोजित एजेन्टलाई स्मोक-टेस्ट गर्नुहोस्
परिनियोजन पछि, अन्तिम बिन्दु साँच्चिकै जवाफ दिन्छ कि भनी प्रमाणित गर्नुहोस् (हरियो परिनियोजन अझै पनि
मौन हुन सक्छ)। AI स्मोक टेस्ट
क्रियालाई .github/workflows/smoke-test.yml मार्फत प्रयोग गर्नुहोस्
र क्याटलग tests/ मा छ। रनरले प्रत्येक
प्रॉम्प्टलाई POST {project_endpoint}/agents/{agent_name}/endpoint/protocols/openai/responses मा पठाउँछ
र जवाफ टेक्स्टमा दावी गर्छ। पहिचानलाई फाउन्ड्री परियोजना दायरामा Azure AI User भूमिका आवश्यक छ;
टोकनको दर्शक https://ai.azure.com/ हुनुपर्छ।
गेटहरू तह दिनुहोस्: स्मोक टेस्ट (पुग्न योग्य/प्रतिक्रिया दिने, हरेक परिनियोजन) → अफलाइन मूल्यांकन (पठाउनका लागि पर्याप्त राम्रो, प्रवर्द्धनअघि) → अनलाइन मूल्यांकन (जंगलीमा कस्तो छ, निरन्तर)।
उद्यम नियन्त्रणहरू
- RBAC: प्रत्येक होस्टेड एजेन्टलाई न्यूनतम अधिकारसहित व्यवस्थापित पहिचान दिनुहोस्।
- उत्पादनमा MCP: हरेक MCP सर्भरलाई अविश्वसनीय सीमा रूपमा व्यवहार गर्नुहोस् — संस्करण पिन गर्नुहोस्, यसको पहिचान स्कोप गर्नुहोस्, आउटपुटहरू प्रमाणित गर्नुहोस्, दर-सीमा लगाउनुहोस्, कहिल्यै गोप्य कुरा नखोल्नुहोस्।
सहायकको लागि गार्डरेइलहरू
- कोर्सभरि प्रयोग गरिएको क्यानोनिकल
FoundryChatClient(...)+provider.as_agent(...)ढाँचा रोज्नुहोस्। - तपाईंले प्रमाणित नगरेका प्रत्यक्ष-Azure परिणामहरूको वाचा नगर्नुहोस्; परिनियोजन पुष्टि गर्न स्मोक-टेस्ट कार्यप्रवाह सिफारिस गर्नुहोस्।
- मूल्यांकन र लागत सल्लाह सँगसँगै राख्नुहोस्: मूल्यांकनले गुणस्तरको आधार तय गर्छ, राउटिङ/क्यासिङले लागतलाई सोही आधार नजिक राख्छ।
अस्वीकरण: यो दस्तावेज़ AI अनुवाद सेवा Co-op Translator प्रयोग गरेर अनुवाद गरिएको हो। हामी सही हुन प्रयास गर्छौं, तर कृपया जानकार हुनुस् कि स्वचालित अनुवादमा त्रुटिहरू वा अशुद्धताहरू हुन सक्छन्। मूल दस्तावेज़ यसको मूल भाषामा आधिकारिक स्रोत मानिनुपर्छ। महत्वपूर्ण जानकारीका लागि व्यावसायिक मानव अनुवाद सिफारिस गरिन्छ। यस अनुवादको प्रयोगबाट उत्पन्न कुनै पनि गलत बुझाइ वा त्रुटिको लागि हामी जिम्मेवार छैनौं।