ai-agents-for-beginners

Microsoft Foundry सह स्केलेबल एजंट्स स्थापित करणे

स्केलेबल एजंट्स स्थापित करणे

या कोर्सच्या आतापर्यंत तुम्ही अशा एजंट्स तयार केले आहेत जे तुमच्या लॅपटॉपवर, नोटबुकमध्ये चालतात, az login आणि काही पर्यावरण चल भूमिका (environment variables) द्वारे चालित. शिकण्यासाठी हा बरोबर मार्ग आहे. हजारो ग्राहक 3 वाजता सकाळी अवलंबून असलेल्या एजंट चालवण्याचा तो बरोबर मार्ग नाही.

हा धडा “माझ्या मशीनवर चालते” आणि “उत्पादनात विश्वासार्ह आणि किफायतशीर चालते” यामधील अंतराबद्दल आहे. आम्ही हा अंतर बंद करतो Microsoft Foundry आणि Microsoft Foundry Agent Service वापरून, आणि आम्ही एक खरा ग्राहक सेवा एजंट तयार करतो ज्यामध्ये टूल्स, शोध, मेमरी, मूल्यमापन, आणि मॉनिटरिंग असते.

परिचय

हा धडा खालील बाबींचा समावेश करेल:

शिकण्याचे उद्दिष्टे

हा धडा पूर्ण केल्यानंतर, तुम्हाला कसे माहित असेल:

पूर्वअट

हा धडा गृहित धरतो की तुम्ही आधीचे धडे पूर्ण केले आहेत आणि ते समजता:

तुम्हाला खालील गोष्टीही आवश्यक असतील:

प्रोटोटाईप ते उत्पादन: प्रत्यक्ष काय बदलते

प्रोटोटाईप एजंट आणि उत्पादन एजंट यांचा कोअर लूप सारखा असतो — विचार करा, टूल्स कॉल करा, प्रतिसाद द्या. जे बदलते ते त्या लूपच्या आजूबाजूला असलेल्या सर्व गोष्टी. मॉडेल उत्पादन एजंटचा कदाचित 20% असतो; बाकी 80% ही ऑपरेशनल रचना असते.

बाब प्रोटोटाईप उत्पादन
होस्टिंग तुमच्या नोटबुकमध्ये चालते होस्टेड सेवा म्हणून चालते, आवृत्ती देण्यात येते आणि रोल आउट केली जाते
ओळख तुमचा az login टोकन स्कोप केलेले RBAC सह व्यवस्थापित ओळख
स्थिती इन-मेमरी, रीस्टार्टवर गमावले जाते बाह्यीकृत (थ्रेड स्टोर, मेमरी सेवा)
अपयश तुम्हाला ट्रेसबॅक दिसतो पुनःप्रयत्न, फॉलबॅक, डेड-लेटर, अलर्ट्स
खर्च “थोडेसे पैसे” विनंतीनिहाय ट्रॅक केले, रूट केलेले, कॅश केलेले, बजेट केलेले
गुणवत्ता आउटपुट डोळ्यांनी तपासता प्रत्येक प्रकाशनाच्या अगोदर स्वयंचलित मूल्यमापन केलेले
विश्वास प्रत्येक क्रियेस मान्यता देता धोरण + जोखमीच्या क्रियांसाठी मानवी-इन-द-लूप

हा तक्ता लक्षात ठेवा. खालील प्रत्येक विभाग या पंक्तींपैकी एकाशी जुळतो.

एजंट प्रतिष्ठापन नमुने

तुम्ही तीन नमुने वापराल, अनेकदा संयोजनात.

1. क्लायंट-होस्टेड एजंट्स

एजंट ऑब्जेक्ट तुमच्या अ‍ॅप्लिकेशन प्रक्रियेच्या आत असतो. तुमचा कोड थेट मॉडेल प्रदाता कॉल करतो; विचार लूप तुमच्या सेवेत चालतो. हेच प्रत्येक मागील धड्यात झाले आहे.

2. होस्टेड एजंट्स (Foundry Agent Service)

एजंट Microsoft Foundry मध्ये संसाधन म्हणून नोंदणीकृत असतो. Foundry विचार लूप होस्ट करतो, थ्रेड्स साठवतो, सामग्री सुरक्षा आणि RBAC लागू करतो, आणि एजंट Foundry पोर्टलमध्ये दिसतो. तुमच्या अ‍ॅप्लिकेशनमध्ये एक हलका क्लायंट बनतो जो थ्रेड्स तयार करतो आणि प्रतिसाद वाचतो.

3. एजंट वर्कफ्लोज

अनेक एजंट्स (आणि टूल्स) एका ग्राफमध्ये संयोजित केले जातात ज्यामध्ये स्पष्ट नियंत्रण प्रवाह असतो — अनुक्रमिक चरण, शाखा, मानवी मंजुरी नोड्स, आणि टिकाऊ चेकपॉइंट जे थांबवू आणि पुन्हा सुरू करू शकतात. हा Microsoft Agent Framework वर्कफ्लोज क्षमतेचा उत्पादन स्केलवर वापर आहे.

flowchart TB
    subgraph P1[क्लायंट-होस्टेड]
        A1[तुमच्या अॅप प्रक्रिया] --> M1[मॉडेल प्रदाता]
    end
    subgraph P2[होस्टेड एजंट]
        A2[थिन क्लायंट] --> F2[फाउंड्री एजंट सेवा]
        F2 --> M2[मॉडेल + टूल्स + थ्रेड स्टोअर]
    end
    subgraph P3[एजंट कार्यप्रवाह]
        A3[ऑर्केस्ट्रेटर] --> S1[ट्रायज एजंट]
        S1 --> S2[रिझोल्वर एजंट]
        S2 --> H[मानवी मंजुरी नोड]
        H --> S3[क्रिया एजंट]
    end

Microsoft Foundry वरील एजंट जीवनचक्र

एजंट प्रतिष्ठापित करणे एकदा केल्यावर push सारखे नसते. ते एक लूप आहे, आणि ते सॉफ्टवेअर प्रकाशन चक्रासारखे दिसते कारण तेच आहे.

flowchart LR
    Create[तयार करा / लेखक] --> Version[आवृत्ती]
    Version --> Evaluate[ऑफलाइन मूल्यांकन करा]
    Evaluate -->|द्वार पार केला| Deploy[होस्ट केलेले तैनात करा]
    Evaluate -->|द्वार अयशस्वी| Create
    Deploy --> Observe[ऑनलाइन निरीक्षण करा]
    Observe --> Improve[अयशस्वी गोळा करा]
    Improve --> Create
    Deploy --> Retire[जुनी आवृत्ती निवृत्त करा]

मुख्य कल्पना, धडा 10 मधून आली आहे: ऑफलाइन मूल्यमापन ही गेट आहे, न की नंतरची विचारणा. नवीन एजंट आवृत्ती जेव्हाच पाठवली जाते जेव्हा ती तुमच्या मूल्यमापन निकषांवर उगम करते. ऑनलाइन निरीक्षण नंतर वास्तविक अपयशं ऑफलाइन चाचणी सेटमध्ये परत पाठवते. हा पूर्ण लूप आहे.

स्केलिंग धोरणे

एजंट स्केल करणे हे स्टेटलेस वेब API स्केल करण्यापासून वेगळे आहे, कारण प्रत्येक विनंती एकाधिक महागडे मॉडेल आणि टूल कॉल ट्रिगर करू शकते. चार तंत्रे जास्त भार वाहतात.

स्टेटलेस विनंती हाताळणी. तुमच्या प्रक्रियेतील मेमरीमध्ये कोणतीही प्रति-वापरकर्ता स्थिती ठेऊ नका. संवाद थ्रेड्स Foundry थ्रेड स्टोर किंवा मेमरी सेवेत जतन करा जेणेकरून कोणतीही उदाहरण कोणतीही विनंती हाताळू शकेल. हेच तुम्हाला आडवे स्केल मिळवायला मदत करतो — उदाहरणे जोडा, कोणत्याहीच चिकट सत्रांशिवाय.

मॉडेल रूटिंग. प्रत्येक विनंतीसाठी तुमचा सर्वात सामर्थ्यशाली (आणि सर्वात महागडा) मॉडेल नको असतो. सोप्या विनंत्यांसाठी — हेतू वर्गीकरण, लहान तथ्यात्मक उत्तरं — लहान, जलद मॉडेलला रूट करा, आणि मोठा मॉडेल खरं विचार करण्यासाठी राखून ठेवा. Foundry चा मॉडेल राऊटर हे तुमच्यासाठी करू शकतो, किंवा तुम्ही स्वतः एक हलका वर्गीकार तयार करू शकता. तुम्ही लॅबमध्ये DIY आवृत्ती तयार कराल.

प्रतिसाद कॅशिंग. अनेक समर्थन प्रश्न जवळजवळ डुप्लिकेट असतात (“माझा पासवर्ड कसा रीसॅड करावा?”). सामान्य प्रश्नांची उत्तरे कॅश करा आणि मॉडेलवर पूर्णपणे हिट न करता त्यांना सर्व्ह करा. अगदी थोडकष्ठी कॅश हिट रेटही महत्वाचेपणाुळे खर्च आणि विलंब कमी करतो.

समसामयिकता आणि बॅकप्रेशर. मॉडेल प्रदात्यांच्या दरमर्यादा असतात. तुमची समसामयिकता मर्यादित ठेवा, एक्स्पोनेंशियल बॅकऑफसह पुनःप्रयत्न वापरा, आणि सावधपणाने अयशस्वी व्हा (थांबवलेल्या “आम्ही त्यावर काम करत आहोत” प्रतिसादाने 500 च्या तुलनेत जास्त चांगले).

flowchart LR
    Q[वापरकर्ता विचारणा] --> C{कॅश हिट?}
    C -->|होय| R[कॅश केलेली उत्तरे परत करा]
    C -->|नाही| Router{गुंतागुंत?}
    Router -->|सोपी| SLM[लहान मॉडेल]
    Router -->|गुंतागुंतीची| LLM[मोठे मॉडेल]
    SLM --> Out[प्रतिसाद]
    LLM --> Out
    Out --> Store[कॅश + ट्रेस]

उत्पादनातील निरीक्षणक्षमता

तुम्ही काय पाहू शकत नाही ते तुम्ही ऑपरेट करू शकत नाही. धडा 10 मध्ये वर्णन केल्याप्रमाणे, Microsoft Agent Framework मूळतः OpenTelemetry ट्रेसेस उत्सर्जित करतो — प्रत्येक मॉडेल कॉल, टूल वापर, आणि समन्वय चरण एक स्पॅन बनतो. उत्पादनात तुम्ही त्या स्पॅन्स Microsoft Foundry (किंवा कोणत्याही OTel-योग्य बॅकेंड) कडे निर्यात करता, ज्यामुळे तुम्हाला खालील बाबी करता येतात:

from agent_framework.observability import get_tracer

tracer = get_tracer()

with tracer.start_as_current_span("support_request") as span:
    span.set_attribute("customer.tier", "enterprise")
    span.set_attribute("routed.model", "gpt-5-nano")
    # एजंट अंमलबजावणी ह्या स्पॅनमध्ये आपोआप ट्रेस केली जाते

customer.tier आणि routed.model सारखे गुणधर्म ट्रेसेसच्या भिंतीला उत्तरे देणाऱ्या प्रश्नांमध्ये रूपांतर करतात (“एंटरप्राइझ ग्राहक खूप वेळा लहान मॉडेलकडे रूट होत आहेत का?”).

खर्च ऑप्टिमायझेशन

उत्पादन एजंटमधील खर्च मुख्यतः टोकन्समुळे होतो. परिणामांच्या अनुक्रमे तीन लीव्हर:

  1. मॉडेल योग्य आकाराचे ठेवा. छोटा मॉडेल जो तुमचा मूल्यमापन गेट पार करतो, तो नेहमीच मोठ्या मॉडेलपेक्षा स्वस्त असतो जो देखील पास होतो. मोठ्या मॉडेलच्या काळजीऐवजी छोटा मॉडेल पुरेसा आहे हे सिद्ध करण्यासाठी मूल्यमापन वापरा.
  2. कठीणीनुसार रूट करा. वर सांगितल्याप्रमाणे — मोठ्या मॉडेलसाठी केवळ ज्या विनंत्यांना मोठ्या मॉडेलचे चिंतन आवश्यक आहे त्यासाठी मोठा खर्च करा.
  3. उग्रपणे कॅश करा. सर्वात स्वस्त मॉडेल कॉल तो आहे जो तुम्ही कधीच करत नाही.

मूल्यमापन दरवाजे आणि खर्च नियंत्रण दोन वेगवेगळ्या दृष्टीकोनातून पहिल्यासारखेच तंत्र आहेत: मूल्यमापन तुम्हाला गुणवत्तेचा पाया सांगतो, रूटिंग आणि कॅशिंग तुम्हाला त्या पायाच्या खर्चाजवळ ठेवतात.

एंटरप्राइझ प्रतिष्ठापन विचार

प्रशासन. होस्टेड एजंट्स Foundry ची RBAC, सामग्री सुरक्षा, आणि ऑडिट लॉगिंग वारसा म्हणून मिळवतात. प्रत्येक एजंटला जास्तीतजास्त कमी हक्क असलेली व्यवस्थापित ओळख द्या — ज्ञान आधार वाचन फक्त, टिकेटिंग API चा स्कोप केलेला प्रवेश, आणि काही नाही.

मानवी-इन-द-लूप. काही क्रियांना थेट स्वयंचलित करणे फार महत्त्वाचे नसते — रिफंड देणे, खाते हटवणे, कायदेशीर टीमकडे पाठवणे. Microsoft Agent Framework मंजुरी-आवश्यक टूल्सना समर्थन देतो: एजंट क्रिया प्रस्तावित करतो, अंमलबजावणी थांबते, मानवी मंजुरी किंवा नाकारणी होते, आणि वर्कफ्लो पुन्हा सुरू होते. तुम्ही धडा 6 मध्ये या प्राथमिक गोष्टी पाहिल्या; येथे तुम्ही ते प्रतिष्ठापित करता.

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

flowchart TB
    subgraph Dev[विकास आर्किटेक्चर]
        D1[नोटबुक] --> D2[एजंट फ्रेमवर्क]
        D2 --> D3[मॉडेल प्रदायक]
        D2 --> D4[स्थानिक साधने]
    end
    subgraph Deploy[तैनाती आर्किटेक्चर]
        E1[सीआय पाईपलाइन] --> E2[मूल्यांकन गेट]
        E2 -->|उत्तीर्ण| E3[फाउंड्री एजंट सेवा]
        E3 --> E4[आवृत्ती असलेला होस्टेड एजंट]
    end
    subgraph Run[रनटाइम आर्किटेक्चर]
        F1[ग्राहक अ‍ॅप] --> F2[होस्टेड एजंट]
        F2 --> F3[मॉडेल राऊटर]
        F2 --> F4[अॅझ्योर AI शोध RAG]
        F2 --> F5[मेमरी सेवा]
        F2 --> F6[MCP साधने]
        F2 --> F7[OTel -> फाउंड्री ट्रेसिंग]
        F2 --> F8[मानवी मंजुरी]
    end

हे तीन आकृत्या — विकास, प्रतिष्ठापन, रनटाइम — हे एजंट आयुष्याच्या तीन टप्प्यावरील एकच एजंट आहेत. पुढील लॅब तुम्हाला ते तयार करण्यासाठी मार्गदर्शन करेल.

हातोडीसाठी लॅब: उत्पादनासाठी तयार ग्राहक सेवा एजंट

code_samples/16-python-agent-framework.ipynb उघडा आणि सुरवंशापासून पूर्ण करा. तुम्ही एक Contoso ग्राहक सेवा एजंट तयार कराल ज्यात प्रत्येक उत्पादन चिंता जोडलेली आहे:

  1. टूल कॉलिंग — ऑर्डर स्थिती पहा आणि समर्थन तिकिटे उघडा.
  2. RAG — ज्ञान आधारातून धोरण प्रश्नांची उत्तरे द्या (Azure AI Search, मेमरीमध्ये ‘fallback’ म्हणून जेणेकरून नोटबुक शोध संसाधनाशिवायही चालेल).
  3. मेमरी — संभाषणातील फेर्‍यांमध्ये ग्राहक लक्षात ठेवा.
  4. मॉडेल रूटिंग — एक क्लिष्टता वर्गीकार प्रत्येक विनंती लहान किंवा मोठ्या मॉडेलकडे मार्गदर्शन करतो.
  5. प्रतिसाद कॅशिंग — पुन्हा विचारलेल्या प्रश्नांना कॅशमधून सेवा द्या.
  6. मानवी मंजुरी — निश्चित मर्यादेपेक्षा जास्त रिफंडसाठी मानवी स्वाक्षरीचा थांबा.
  7. मूल्यमापन पाईपलाइन — एक लहान ऑफलाइन चाचणी संच एजंटच्या गुणांकनासाठी आणि प्रकाशन गेट म्हणून काम करतो.
  8. निरीक्षणक्षमता — प्रत्येक विनंतीच्या भोवती OpenTelemetry ट्रेसिंग.

मार्गदर्शन

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

async def handle_support_request(query: str, customer_id: str) -> str:
    # 1. शक्य तितक्या वेळेस कॅशेमधून सेवा द्या.
    cached = response_cache.get(normalize(query))
    if cached:
        return cached

    # 2. खर्च नियंत्रणासाठी गुंतागुंतीनुसार मार्गदर्शन करा.
    model = "gpt-5-nano" if is_simple(query) else "gpt-5-mini"

    # 3. निरीक्षणासाठी एजंटला ट्रेस स्पॅनमधून चालवा.
    with tracer.start_as_current_span("support_request") as span:
        span.set_attribute("routed.model", model)
        span.set_attribute("customer.id", customer_id)
        response = await support_agent.run(query, model=model)

    # 4. कॅश करा आणि परत करा.
    response_cache.set(normalize(query), response.text)
    return response.text

प्रकाशनाचे दरवाजे असं दिसतात:

async def evaluation_gate(agent, test_cases, threshold: float = 0.8) -> bool:
    passed = 0
    for case in test_cases:
        result = await agent.run(case["input"])
        if score_response(result.text, case["expected"]) >= 0.8:
            passed += 1
    pass_rate = passed / len(test_cases)
    print(f"Evaluation pass rate: {pass_rate:.0%} (gate: {threshold:.0%})")
    return pass_rate >= threshold  # गेट पास झाल्यासच तैनात करा

प्रत्येक ओळ वाचा — नोटबुक प्राथमिक गोष्टी खूप लहान ठेवतो जेणेकरून काहीही फ्रेमवर्क कॉल मागे लपलेले नसावे.

प्रतिष्ठापित एजंटची स्मोक चाचणी करून पडताळणी करणे

वरचं मूल्यमापन गेट तुमच्या एजंट ऑब्जेक्टविरुद्ध ऑफलाइन चालवते. एजंट होस्टेड एजंट म्हणून प्रतिष्ठापित झाल्यावर, तुम्हाला अजून एक, अगदी स्वस्त तपासणी करायला हवी: प्रतिष्ठापित एंडपॉइंट खरोखर प्रतिसाद देत आहे का?

“यशस्वी” प्रतिष्ठापन फक्त कंट्रोल प्लेनने व्याख्या स्वीकारली हे सिद्ध करते — ते एजंट प्रतिसाद देतो हे सिद्ध करत नाही. हरवलेले अवलंबित्व, खराब मॉडेल रूटिंग, किंवा कालबाह्य कनेक्शन “हिरव्या” प्रतिष्ठापनाला परत काहीही न देणारी ठेवू शकते. स्मोक चाचणी हे काही सेकंदांत पकडते, प्रत्येक प्रतिष्ठापनावर, पूर्ण मूल्यमापनाच्या खर्चाशिवाय.

या रिपॉझिटरीमध्ये AI Smoke Test GitHub Action वर आधारित वापरायला तयार स्मोक-चाचणी पाईपलाइन आहे:

- name: Smoke-test hosted agent
  uses: JFolberth/ai-smoketest@v1
  with:
    project_endpoint: $
    agent_name: ContosoSupportAgent
    tests_file: tests/lesson-16-smoke-tests.json

तुमचा एजंट डिप्लॉय झाल्यावर, Actions टॅबमधून तो चालवा, तुमचा Foundry प्रोजेक्ट एंडपॉइंट आणि एजंट नाव दिलेले असावे. फेडरेटेड ओळखीसाठी Foundry प्रोजेक्ट स्कोपमध्ये Azure AI User भूमिका आवश्यक आहे. लेयर्सना एका पिरॅमिडसारखा विचार करा: स्मोक चाचण्या (पोहोचता येते का आणि प्रतिसाद देतो का?) प्रत्येक डिप्लॉयवर चालतात, ऑफलाइन मूल्यांकन (पुरेसे चांगले का ते पाठवायला?) प्रमोशनपूर्वी चालते, आणि ऑनलाइन मूल्यांकन (खऱ्या वापरात कसे चालले आहे?) सतत चालू असते.

ज्ञान तपासणी

असाइनमेंटकडे जाण्यापूर्वी तुमची समज तपासा.

1. साधारणतः उत्पादन एजंटचा कितपत भाग “मॉडेल” आहे, आणि उरलेले काय आहे?

उत्तर मॉडेल सिस्टमचा अल्पसंख्यक भाग असतो — बहुधा सुमारे 20% म्हटले जाते. उरलेले म्हणजे ऑपरेशनल कंकाल: होस्टिंग आणि वर्शनिंग, ओळख आणि RBAC, बाह्यीकृत स्थिती, अपयश हाताळणी, खर्च ट्रॅकिंग, मूल्यांकन, आणि मानव-इन-द-लूप नियंत्रण. उत्पादनाकडे जाणे म्हणजे सर्व काही *विचार करण्याच्या लूपच्या भोवताली* बांधणे होय.

2. तुम्ही कधी Hosted Agent निवडाल आणि कधी क्लायंट-होस्टेड एजंट?

उत्तर जेव्हा तुम्हाला बिल्ट-इन टिकाऊपणा (थ्रेड्स जे सतत राहतायेत आणि पुन्हा सुरू होऊ शकतात), निरीक्षणक्षमता, सामग्री सुरक्षा, आणि RBAC असलेलं व्यवस्थापित रनटाईम हवं असेल, आणि तुम्ही reasoning लूपवर कमी-स्तर नियंत्रण थोडंसं दिलं तरी कमी ऑपरेशनल क्षेत्र मिळवू इच्छित असाल तेव्हा Hosted Agent योग्य आहे. क्लायंट-होस्टेड तेव्हा प्राधान्य आहे जेव्हा तुम्हाला reasoning लूपवर पूर्ण नियंत्रण हवं किंवा एजंटला विद्यमान बॅकएंडमध्ये एम्बेड करत असाल.

3. स्केलेबल एजंट त्याच्या स्वतःच्या प्रोसेस मेमरीत स्टेटलेस का असावा लागतो?

उत्तर म्हणजे कोणत्याही इंस्टन्सला कोणतंही विनंती हाताळता येईल, ज्यामुळे हरीजॉन्टल स्केलिंग स्टिकी सेशन्सशिवाय शक्य होते. प्रति-युजर संभाषण स्थिती थ्रेड स्टोअर किंवा मेमरी सेवेमध्ये बाह्यीकृत केली जाते. जर स्थिती प्रोसेस मेमरीमध्ये असती, तर रीस्टार्टच्या वेळी ती गमावली जाईल आणि लोड मुक्तपणे वितरित करता येणार नाही.

4. मॉडेल राउटिंग कोणती समस्या सोडवते, आणि मूल्यांकनाशी त्याचा काय संबंध आहे?

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

5. “मूल्यांकन दरवाजा” म्हणजे काय आणि तो जीवनचक्रात कुठे असतो?

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

6. उत्पादनात MCP सर्व्हरला का अविश्वसनीय सीमा म्हणून वागवले पाहिजे?

उत्तर कारण ते बाह्य अवलंबित्व आहे ज्यात तुमचा एजंट कॉल करतो. तुम्ही त्याची आवृत्ती पिन केली पाहिजे, स्कोप केलेल्या ओळखीने चालवले पाहिजे, त्याच्या आउटपुटची मान्यता करावी, रेट-लिमिट करावी, आणि कधीच त्याला सिक्रेट्स उघड करू नयेत — हाच नियम तुम्ही कोणत्याही तृतीय-पक्ष अवलंबित्वावर वापरता. त्याचे आउटपुट तुमच्या एजंटच्या विचारसरणीत जातात, म्हणून न तपासलेला विश्वास एक सुरक्षा धोका आहे.

7. उत्पादन एजंटच्या खर्चावर सहसा कोणता एक बदल सर्वात जास्त परिणाम करतो, आणि का?

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

8. customer.tier आणि routed.model सारख्या स्पॅन अॅट्रीब्यूट्सचे निरीक्षणक्षमता मध्ये काय महत्त्व आहे?

उत्तर ते कच्च्या ट्रेसेसना उत्तरदायी व्यवसाय प्रश्नांमध्ये बदलतात. अॅट्रीब्यूट्स नसल्यास तुम्हाला फक्त स्पॅन्सची भिंत दिसते; अॅट्रीब्यूट्स असल्यास तुम्ही विचारू शकता "एंटरप्राइज ग्राहक खूप वेळा लहान मॉडेलकडे राऊट होत आहेत का?" किंवा "कोणता मॉडेल आमच्या सर्वाधिक संथ विनंत्यांना हाताळतो?" अॅट्रीब्यूट्स तुमच्या ऑपरेशन्ससाठी महत्त्वाच्या परिमाणांनुसार टेलिमेट्री कशी विभागायची ते ठरवतात.

असाइनमेंट

लॅबमधील ग्राहक समर्थन एजंट घेऊन तो एका विशिष्ट परिस्थितीसाठी मजबूत करा: SaaS कंपनीसाठी सदस्यता बिलिंग समर्थन एजंट.

तुमच्या सबमिशनमध्ये असावं:

  1. साधनं बदला बिलिंग-संबंधित साधनांमध्ये: get_subscription_status, get_invoice, आणि issue_credit (50 डॉलर्सपेक्षा जास्त क्रेडिटसाठी मानवी मंजुरी आवश्यक).
  2. तीन RAG दस्तऐवज जोडा ज्यात कंपनीची रिफंड धोरण, बिलिंग चक्र, आणि रद्द करण्याची धोरण यांचा समावेश असेल.
  3. मूल्यांकन संच वाढवा किमान आठ प्रकरणांपर्यंत, ज्यात किमान दोन प्रकरणे मानवी मंजुरीचा मार्ग सक्रिय करतात, आणि तुमचा मूल्यांकन दरवाजा योग्य प्रकारे पास किंवा फेल होतो याची पुष्टी करा.
  4. एक खर्च अहवाल जोडा: एजंटद्वारे दहा मिश्रित चौकशा चालवल्यानंतर, किती विनंत्या लहान मॉडेलकडे, किती मोठ्या मॉडेलकडे, आणि किती कॅशेमधून सेव्ह केल्या गेल्या हे छापून दाखवा.

कोणता मॉडेल-राउटिंग नियम तुम्ही निवडला आणि त्याला प्रत्यक्ष ट्रॅफिकसह कसा मान्य कराल याची एक छोटी परिच्छेद (मार्कडाऊन सेलमध्ये) लिहा. कोणताही एकच बरोबर उत्तर नाही — तुम्हाला उत्पादनाच्या गोष्टी coherent रीतीने जोडल्या गेल्याबद्दलच मूल्यांकन केले जाईल.

सारांश

या धड्यात तुम्ही एजंटला प्रोटोटाइपमधून उत्पादनात Microsoft Foundry वापरून नेले:

पुढील धडा उलटा प्रवास करतो: एजंट्सना क्लाउडमध्ये वाढवण्याऐवजी, तुम्ही त्यांना खाली आणाल, एका विकसक मशीनवर पूर्णपणे लोकली चालवाल.

अतिरिक्त साधने

मागील धडा

कंप्यूटर वापरणारे एजंट तयार करणे (CUA)

पुढील धडा

स्थानिक AI एजंट तयार करणे

अस्वीकरण: हा दस्तऐवज AI भाषांतर सेवा Co-op Translator चा वापर करून अनुवादित केला आहे. जरी आम्ही अचूकतेसाठी प्रयत्न करतो, तरी कृपया लक्षात घ्या की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेची कमतरता असू शकते. मूळ दस्तऐवज त्याच्या मूळ भाषेत अधिकृत स्रोत मानला पाहिजे. महत्त्वाची माहिती असल्यास, व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराच्या वापरामुळे उद्भवणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थलावणीसाठी आम्ही जबाबदार नाही.

This site is open source. Improve this page.