Alapkonfiguráció Microsoft Foundry-csevegés referenciaarchitektúrája

Öntödei eszközök

Azure App Service

Azure Monitor

Microsoft Foundry

Öntödei ügynöki szolgáltatás

A vállalati csevegőalkalmazások lehetővé teszik az alkalmazottak számára, hogy természetes nyelvi beszélgetéseken keresztül kommunikálják az AI-ügynököket. Ezek az alkalmazások olyan nyelvi modelleket használnak, mint az OpenAI GPT-modellek és a nyílt forráskódú fejlesztői készletek, például az Microsoft Agent Framework. Ezek a csevegőalkalmazások általában a következő összetevőkből állnak:

• Egy nagyobb nagyvállalati alkalmazásba integrált csevegő felhasználói felület (UI). Más üzleti funkciók mellett beszélgetési élményt is biztosít a felhasználóknak.

• Olyan adattárak, amelyek a felhasználói lekérdezések szempontjából releváns, tartományspecifikus információkat tartalmaznak.

• A tartományspecifikus adatokra hivatkozó nyelvi modellek releváns válaszokat eredményeznek.

• Tartós vezénylési definíció vagy hosszú élettartamú ügynök, amely felügyeli az adatforrások, a nyelvi modellek és a felhasználó közötti interakciókat.

Ez a cikk egy alaparchitektúrát biztosít a vállalati csevegőalkalmazások Foundry és Azure OpenAI-modellek használatával történő létrehozásához és üzembe helyezéséhez. Ez az architektúra egy, az Foundry Agent Service szolgáltatásban tárolt parancssori ügynököt használ, de támogatja az üzemeltetett ügynököket is. A parancssori ügynököt deklaratív módon határozza meg az utasítások, a modell kiválasztása és a csatlakoztatott eszközök segítségével, és az Agent Service kezeli annak üzemeltetését. Az ügynök megkapja a felhasználói üzeneteket, majd lekérdezi az adattárakat a nyelvi modell alapadatainak lekéréséhez.

A chat felület a baseline Azure App Service webalkalmazás útmutatásait követi arról, hogyan telepítsünk biztonságos, zónaredundáns és magas rendelkezésre állású webalkalmazást az App Service-en. Ebben az architektúrában az App Service a Azure szolgáltatásplatform (PaaS) megoldásával kommunikál a magánvégpontokon keresztüli virtuális hálózati integráción keresztül. A csevegőfelület architektúrájában az App Service privát végponton keresztül kommunikál az ügynökkel. Ez az architektúra letiltja az Foundry portálhoz és az ügynökökhöz való nyilvános hozzáférést.

Fontos

Ez a cikk nem ismerteti az alapszintű App Service-webalkalmazás-architektúra összetevőit vagy architektúra-döntéseit. A csevegőfelületet tartalmazó webalkalmazás üzemeltetésére vonatkozó útmutatásért tekintse meg ezt a cikket.

Ez az architektúra a Foundry Agent Service standard ügynökbeállításával biztosítja a nagyvállalati szintű biztonságot, megfelelőséget és ellenőrzést. Ebben a konfigurációban saját (BYO) virtuális hálózatot hoz létre a hálózatelkülönítéshez, és saját Azure erőforrásokat a csevegés és az ügynök állapotának tárolásához. Az alkalmazásösszetevők privát végpontokon keresztül férnek hozzá Azure szolgáltatásokhoz, az ügynökök pedig privát hálózati kapcsolaton keresztül férnek hozzá a számítási feladatok tulajdonában lévő MCP-kiszolgálókhoz. Ez a megközelítés biztosítja, hogy az adatforgalom a számítási feladat virtuális hálózatán belül maradjon. Az ügynökök kimenő forgalma szigorúan az Azure Firewallon keresztül halad, ami kikényszeríti a kimenő forgalmi szabályokat.

Jótanács

A Foundry Agent Service referencia-implementációja egy alapszintű, végpontok közötti csevegési implementációt mutat be a Azure. Ez alapként szolgál az egyéni megoldások fejlesztéséhez, miközben az élesítési fázis felé halad.

Architecture

A diagram részletes Azure architektúrát mutat be az AI-megoldások üzembe helyezéséhez. A bal oldalon egy felhasználó Azure Application Gateway keresztül csatlakozik egy webalkalmazási tűzfalhoz, amely egy virtuális hálózat része. Ez az átjáró privát DNS-zónákhoz van csatolva, és Azure DDoS Protection védi. Az átjáró alatt a privát végpontok olyan szolgáltatásokhoz csatlakoznak, mint az App Service, a Azure Key Vault és a Azure Storage, amelyeket az ügyfélalkalmazások üzembe helyezéséhez használnak. Az App Service-t identitással kezelik, és három zónára terjed ki. Az Application Insights és Azure Monitor monitorozást biztosítanak, és Microsoft Entra ID kezeli a hitelesítést. A virtuális hálózat jobb oldalon több alhálózatot tartalmaz: App Service-integráció, privát végpont, Foundry-integráció, Azure AI-ügynökintegráció, Azure Bastion, jump box, buildügynökök és Azure Firewall. Minden alhálózat adott végpontokat vagy szolgáltatásokat üzemeltet, például tárolót, Foundryt, Azure AI Keresés és Azure Cosmos DB, amelyek privát végpontokon keresztül csatlakoznak. A hálózatból kimenő forgalom áthalad a Azure Firewall az internetes források eléréséhez. A jobb szélen egy külön mező jelöli a Foundryt, amely tartalmaz egy erőforrást és egy projektet. A felügyelt identitások csatlakoztatják az Foundry Agent Service-t az Foundry-projekthez, amely viszont hozzáfér egy Azure OpenAI-modellhez. A diagram számozott köröket használ a logikai folyamat jelzésére. Bemutatja, hogy a felhasználó hogyan lépi át a hálózatot, hogyan kommunikál a különböző végpontokkal, és végül hogyan csatlakozik az Foundry- és tárolási szolgáltatásokhoz, egyértelműen csoportosított és címkézett függőségekkel.

Töltse le az architektúra Visio fájlját.

Workflow

1. Egy alkalmazásfelhasználó csevegőfelülettel kommunikál. A kérések Azure Application Gateway haladnak át. Azure Web Application Firewall ellenőrzi ezeket a kéréseket, mielőtt továbbítanák azokat a háttérbeli App Service-példánynak.

2. Amikor a webalkalmazás felhasználói lekérdezést vagy utasítást kap, meghívja a célként létrehozott ügynököt. A webalkalmazás az ügynökvégpontokkal az Microsoft Ügynök-keretrendszeren keresztül kommunikál. A keretrendszer meghívja a kiszolgálóoldali ügynökdefiníciót az OpenAI-kompatibilis Responses API-val. Az ügyfél HTTP-hívása ugyanaz marad, függetlenül attól, hogy az ügynök melyik támogatott modellt használja. A webalkalmazás privát végponton keresztül hívja meg az ügynököt, és a felügyelt identitás használatával hitelesíti az Foundryt.

3. Az ügynök a rendszerkérés utasításai alapján dolgozza fel a felhasználó kérését. A felhasználó szándékának teljesítéséhez az ügynök egy konfigurált nyelvi modellel és csatlakoztatott eszközökkel rendelkezik. Ebben az architektúrában az eszközök közé tartozik az adatok földelésére szolgáló Azure AI Keresés eszköz és a webes adatok webes keresőeszköze.

4. Az ügynök egy privát végponton keresztül csatlakozik az Azure AI Keresés szolgáltatáshoz az AI Search eszközt használva a magánhálózaton belül.

5. A legtöbb külső eszköz, például a nyilvános MCP-kiszolgálók vagy az egyéni API-eszközök felé irányuló kérelmek az Azure Firewallon keresztül haladnak ellenőrzés és a kimenő forgalomra vonatkozó szabályzatok érvényesítése céljából. A privát MCP-kiszolgálókra vagy API-kra irányuló kérések a virtuális hálózaton belül maradnak.

6. Az ügynök csatlakozik a konfigurált nyelvi modellhez, és átadja a releváns kontextust.

7. Mielőtt az ügynök visszaadja a választ a felhasználói felületre, megőrzi a kérést, a létrehozott választ és az eszközhívás részleteit a beszélgetésben. Ez a Azure Cosmos DB tárolt beszélgetési objektum a teljes interakciós előzményt beszélgetési elemekként (üzenetek, eszközhívások és eszközkimenetek) tárolja. Ez az előzmény támogatja a környezetérzékeny interakciókat, és lehetővé teszi, hogy a felhasználók a korábbi környezet elvesztése nélkül folytatják a beszélgetéseket az ügynökkel.

   A Foundry API-k támogatják a több egyidejű, környezettől elkülönített beszélgetést kezelő felhasználói élmények fejlesztését.

Components

Ez az architektúra az alapvető Foundry-csevegési referenciaarchitektúrára épül. Ez az architektúra több Azure szolgáltatást vezet be a megbízhatóságra, a biztonságra és a működési vezérlésre vonatkozó vállalati követelmények kezelésére. Az alábbi összetevők mindegyike egy adott szerepet játszik egy éles vállalati csevegési megoldásban:

• A Foundry Agent Service egy natív felhőbeli futtatókörnyezet, amely lehetővé teszi az intelligens ügynökök biztonságos és autonóm működését. Ebben az architektúrában az Foundry Agent Service egy felügyelt futtatókörnyezetet biztosít a parancssori ügynökök számára, és integrálható Azure szolgáltatásokkal. A következő feladatokat ellátó ügynököket üzemelteti és kezeli:

  • Felhasználói kérések feldolgozása
  • Eszközökre és más ügynökökre irányuló hívások vezénylésére
  • Tartalombiztonság kényszerítése
  • Integrálás vállalati identitással, hálózatkezeléssel és megfigyelhetőséggel

  A standard ügynökbeállítás biztosítja a hálózatelkülönítést, és szabályozza az adattárolást. Dedikált Azure erőforrásokat biztosít az ügynökállapothoz, a csevegési előzményekhez és a fájltároláshoz, de a Foundry Agent Service kizárólag ezeket kezeli. A számítási feladat más alkalmazásösszetevői nem használhatják ezeket a szükséges erőforrásokat.

  • Azure Cosmos DB NoSQL egy globálisan elosztott dokumentumadatbázis-szolgáltatás. Ebben az architektúrában az előfizetésén belül üzemeltetik a számítási feladat memóriaadatbázisát, az úgynevezett enterprise_memory. Ez az adatbázis tárolja az ügynök működési állapotát, beleértve a csevegéseket és az ügynökdefiníciókat. Ez a kialakítás biztosítja, hogy a csevegési előzmények és az ügynökkonfiguráció elkülönítése, naplózása és kezelése az adatszabályozási követelményeknek megfelelően történjen. Az Foundry Agent Service kezeli az adatbázist, gyűjteményeit és adatait.

  • Azure Storage strukturálatlan adatok felhőalapú tárolási szolgáltatása. Ebben az architektúrában dedikált tárterületet biztosít a csevegések során feltöltött fájlokhoz. A fiók előfizetésben való üzemeltetése részletes hozzáférés-vezérlési, naplózási képességeket és az adattárolási vagy adatmegőrzési szabályzatoknak való megfelelést biztosítja. Az Foundry Agent Service kezeli a tárolók és az adatok életciklusát ezeken a tárolókon belül.

  • Az AI Search egy felügyelt keresési megoldás, amely keresési képességeket biztosít. Ebben az architektúrában az Foundry Agent Service az AI Search használatával tárolja az ügynökkel folytatott beszélgetések során a Fájlkeresés eszközzel feltöltött fájlok kereshető, darabolt indexét. Az AI Search emellett adattömböt tartalmazó statikus fájlokat is tárol, amelyeket tudásforrásként ad hozzá az ügynök létrehozásakor. Ezek a fájlok az összes ügynökhívásban elérhetők maradnak. Az Foundry Agent Service kezeli az indexet, sémát és adatokat, és saját adattömbkezelési stratégiát és lekérdezési logikát használ.

• Az Application Gateway egy webes forgalom terheléselosztó és alkalmazáskézbesítési vezérlő. Ebben az architektúrában biztonságos, skálázható belépési pontként szolgál a csevegőfelületre irányuló ÖSSZES HTTP- és HTTPS-forgalomhoz. A Transport Layer Security (TLS) leállítását és útvonalalapú útválasztást is biztosít. Az Application Gateway elosztja a kérelmeket a rendelkezésre állási zónák között, ami támogatja a webalkalmazási szint magas rendelkezésre állását és teljesítményét. A háttérrendszere az alkalmazáskódot üzemeltető App Service-példány.

  • Azure Web Application Firewall egy natív felhőszolgáltatás, amely megvédi a webalkalmazásokat a gyakori webes biztonsági résektől. Ebben az architektúrában integrálva van az Application Gatewayrel, hogy megvédje a csevegés felhasználói felületét a gyakori webes biztonsági résekkel és támadásokkal szemben. Ellenőrzi és szűri a HTTP-kéréseket, amely biztonsági réteget biztosít a nyilvános alkalmazások számára.

  • Azure Key Vault egy felhőszolgáltatás, a titkos kulcsok, kulcsok és tanúsítványok biztonságos tárolására és elérésére. Ebben az architektúrában biztonságosan tárolja és kezeli az Application Gateway által igényelt TLS-tanúsítványokat. A Key Vault központosított tanúsítványkezelése támogatja az automatizált rotációt, a naplózást és a szervezeti biztonsági szabványoknak való megfelelést. Ez az architektúra nem igényel tárolt kulcsokat vagy más titkos kulcsokat.

• Azure Virtual Network a magánhálózatok alapvető építőeleme Azure. Ebben az architektúrában minden összetevő számára biztosít hálózati elkülönítést, hogy megfeleljen a biztonsági és megfelelőségi követelményeknek. Amikor erőforrásokat helyez el egy privát virtuális hálózatban, szabályozhatja a kelet-nyugati és az észak-déli forgalmat, szegmentálást kényszeríthet ki, magánforgalomban tarthatja a forgalmat, és ellenőrizheti a bejövő és kimenő folyamatokat.

• Azure Private Link egy hálózati szolgáltatás, amely privát kapcsolatot biztosít egy virtuális hálózatról Azure PaaS-szolgáltatásokhoz. Ebben az architektúrában az összes PaaS-szolgáltatást, például a Azure Cosmos DB, a Storage, az AI Search és az Foundry Agent Service szolgáltatást magánvégpontokon keresztül csatlakoztatja a virtuális hálózathoz. Private Link segít biztosítani, hogy minden adatforgalom a Azure gerincén maradjon, ami kiküszöböli a nyilvános internetnek való kitettséget, és csökkenti a támadási felületet.

• Azure Firewall egy felügyelt, felhőalapú hálózati biztonsági szolgáltatás. Ebben az architektúrában a virtuális hálózat összes kimenő (kimenő) forgalmát ellenőrzi és szabályozza. Teljes tartománynevet (FQDN)-alapú szabályokat is kikényszerít, így csak a jóváhagyott célhelyek érhetők el. Ez a konfiguráció segít megelőzni az adatok kiszivárgását, és teljesíteni a hálózati biztonságra vonatkozó követelményeket.

• A Azure DNS a névfeloldást biztosító dns-tartományok üzemeltetési szolgáltatása. Ebben az architektúrában a virtuális hálózathoz társított privát DNS-zónákat biztosít. Kezeli a névfeloldást magánvégpontok esetén, amely biztosítja, hogy a szolgáltatásközi kommunikáció magánhálózati IP-címeket használjon és a hálózat határain belül maradjon.

• Azure Storage strukturálatlan és strukturált adatok felhőalapú tárolási szolgáltatása. Ebben az architektúrában támogatja a biztonságos, automatizált üzembehelyezési munkafolyamatokat, és elkülöníti az alkalmazás-összetevőket a számítási erőforrásoktól. A webalkalmazás kódját ZIP-fájlként tárolja az App Service-be való üzembe helyezéshez.

Modell és eszköz kiválasztása

Az Foundry Agent Service nem működik az Foundry-modellkatalógusban szereplő összes modellel. A katalógus felsorolja azokat a modelleket, amelyeket az Foundry-platform üzembe helyezhet, de a parancssori ügynök csak olyan részhalmazt használhat, amelyet az Foundry Agent Service ellenőriz ügynökhasználatra.

Mielőtt egy modell mellett dönt, győződjön meg arról, hogy telepítheti a saját Foundry-régiójában, és hogy a Foundry Agent Service támogatja. Az Foundry portálon tallózhat az ügynök által támogatott modellekre szűrt modellkatalógusban , vagy programozott módon lekérdezheti egy régió modelljeit.

az cognitiveservices model list --location <location> --query "[?model.capabilities.agentsV2=='true']"

A Foundry Agent Service által támogatott modell nem feltétlenül támogatja minden ügynökképességet. Az eszközök rendelkezésre állása a modelltől és az üzembe helyezési régiótól is függ. Ebben az architektúrában az ügynök az AI Search eszközt és a webes keresőeszközt használja, és nem minden támogatott modell működik az egyes eszközökkel. A teljes kompatibilitási mátrixért tekintse meg az eszköztámogatást régió és modell szerint.

Az Foundry Agent Service nem mindig utasít el nem támogatott kombinációt az ügynök definiálásakor. Amikor a REST API-val hoz létre egy parancssori ügynököt, egy nem támogatott modell vagy eszköz kiválasztása átadhatja az ügynök létrehozását, majd váratlan viselkedést vagy futásidejű hibát okozhat, amikor az ügynök meghívja a modellt vagy eszközt.

Alternatives

Ez az architektúra több összetevőt is tartalmaz, amelyeket más Azure szolgáltatásokkal vagy megközelítésekkel helyettesíthet a számítási feladat funkcionális és nem funkcionális követelményeitől függően. Fontolja meg a következő alternatívákat és kompromisszumoket.

Csevegés orchesztrációja

Jelenlegi megközelítés: Ez az architektúra az Foundry Agent Service-t használja az ügynök végrehajtási folyamatainak végrehajtására, beleértve a földelési adatok csatlakoztatott eszközökkel való lekérését, az AI-modellek meghívását, valamint az ügynök rendszerszintű utasításai és beszélgetési előzményei alapján a konzisztens válasz viselkedésének kikényszerítését. A Foundry Agent Service kód nélküli, nemdeterminista vezénylést biztosít a beszélgetési AI-számítási feladatokhoz. Kezeli a csevegési kérelmeket, a beszélgetés állapotát, az eszközhívást, a tartalombiztonságot és az identitással, a hálózatkezeléssel és a megfigyelhetőséggel való integrációt. A szolgáltatás támogatja a beszélgetési környezet és az ügynökállapot megőrzését egy előre definiált adatmodellen keresztül, amelyet az előfizetésen belüli adatbázisba helyeznek üzembe.

Alternatív megközelítés: Egyéni végrehajtási logikát implementálhat egy üzemeltetett ügynökben, amely a saját determinisztikus, kódalapú ügynök-vezénylési logikája, amely egy Tárolóban fut az Foundry Agent Service szolgáltatásban. Egy üzemeltetett ügynöknek implementálnia kell az Foundry futtatókörnyezeti szerződését , hogy a platform meghívhassa azt. A szerződést SDK-adapterrel vagy a szerződés saját implementálásával teljesíti, és az ügynök saját logikáját egy olyan keretrendszerrel hozza létre, mint az Ügynök-keretrendszer. Ezt a kódot tárolórendszerképként kell üzembe helyeznie, amelyet ön hoz létre és küld le Azure Container Registry saját tulajdonában és irányításában.

Ebben az esetben az ügynökkód kezeli a vezénylést, és hogy a platform mit kezel, attól függ, hogy az ügynök milyen protokollt tesz közzé.

• A Válaszok protokollal a platform kezeli a beszélgetések előzményeit és a munkamenetek életciklusát, a kód pedig növeli a szerződés végrehajtási viselkedését.

• Az Invocations protokoll használatával a kód közvetlenül kezeli a munkamenet állapotát, és a platform nem biztosít beszélgetési előzményeket.

Minden üzemeltetett ügynök egy dedikált végpontútvonalat kap az üzembe helyezéskor, amely saját útválasztási, hozzáférés-vezérlési és monitorozási hatókörrel rendelkezik.

Az üzemeltetett ügynököket vegye figyelembe a parancssori ügynökök helyett, ha a számítási feladathoz az alábbi képességek közül legalább egy szükséges:

• Az Foundry Agent Service által nem támogatott modellek használata vagy a szolgáltatás által nem közzétett eszközökkel való integráció

• Az ügynök végrehajtási útvonalának részletes, determinisztikus vezérlése, beleértve az explicit vezénylési mintákat, a külső rendszereket vagy eszközöket, a gyors tervezést, a több ügynökkel való kapcsolatot vagy az emberi beavatkozást a cikluson belül

• Összetett üzleti folyamatokat kezelő meglévő kódbázisok vagy kódtárak újrafelhasználása

• Ügynökkód naplózása, ellenőrzése vagy tanúsítása biztonsági, megfelelőségi vagy szabályozási célból

• Ügynökönkénti identitás és végpontelkülönítés, így az ügynökök különböző projektekbe való elkülönítése nélkül hatókörbe helyezheti a minimális jogosultságú hozzáférést, a hozzáférés-vezérlést és a figyelést az egyes ügynökök között.

• Az ügynök futásidejének finomhangolása, beleértve az egyes ügynök-munkamenetek tesztkörnyezetéhez tartozó processzor- és memóriafoglalást

• A Foundry Agent Service natív beszélgetési állapota mellett egy külön adatbázisban tárolt kiterjesztett memória is található.

A üzemeltetett ügynökök továbbra is az Foundry által felügyelt számítási eszközökön futnak, így a platform továbbra is kezeli a skálázást és az alapvető futtatókörnyezetet. A saját üzemeltetésű orchesztráció egy további lépés, amelyben Ön a vezénylési réteget az Ön által üzemeltetett számítási infrastruktúrán futtatja, a Foundry Agent Service-en kívül. Saját infrastruktúra futtatásakor Ön felel a futtatókörnyezet minden jellemzőjéért, kapacitásáért és biztonságáért.

Alkalmazásréteg összetevői

Kurzív megközelítés: A csevegőfelületi felület webhelye az App Service Web Apps szolgáltatásában található, amely egy felügyelt, méretezhető platformot biztosít a webalkalmazásokhoz. Web Apps natív módon integrálható Azure hálózati és biztonsági funkciókkal.

Alternatív megközelítés: Az alkalmazásszint üzemeltetéséhez használhat más Azure felügyelt számítási platformokat, például Azure Container Apps vagy Azure Kubernetes Service (AKS).

Fontolja meg ezt az alternatívát, ha a számítási feladat megfelel az alábbi feltételek bármelyikének:

• Egy másik számítási platform jobban támogatja bizonyos használati eseteket, és a szolgáltatások ezen a platformon való áthelyezése javíthatja a költséghatékonyságot és egyszerűsítheti a műveleteket

• Az alkalmazás kifinomultabb skálázást, vezénylést vagy egyéni hálózatkezelést igényel

Az App Service továbbra is a webalkalmazások és API-k egyszerűsége szempontjából előnyben részesített lehetőség.

Alapadatok (tudástár) tárolása

Jelenlegi megközelítés: Ez az architektúra az AI Search-t használja elsődleges adattárként a tudás alapozásához. Az AI Search vektorkeresési és szemantikai rangsorolási képességeit használja.

Alternatív megközelítés: Más adatplatformokat is használhat a tudás megalapozásához, például Azure Cosmos DB, Azure SQL Database vagy egyéb online tranzakciófeldolgozási (OLTP-) adattárakat. Az adatplatform a meglévő adattulajdontól, az adatfrissítési követelményektől és a lekérdezési követelményektől függ.

Fontolja meg ezt az alternatívát, ha a számítási feladat megfelel az alábbi feltételek bármelyikének:

• A meglévő tranzakciós vagy üzemeltetési adatbázisban már kezelheti alapismereteit

• Szüksége van többmodelles vagy SDK-támogatásra, amely nem érhető el az AI Search funkcióban.

• Speciális adatforrásokkal vagy örökölt rendszerekkel kell integrálnia

A vektoros keresés általában jellemző a lekérés-kiegészítésű generálásra (RAG), de nem mindig szükséges. További információ: A Azure szolgáltatás létrehozása vektorkereséshez. Mielőtt kiválaszt egy adattárat, értékelje ki a számítási feladat adathozzáférési mintáit, késését és méretezhetőségét.

Ügyfél által felügyelt csevegési előzmények

Kurzív megközelítés: Ez az architektúra szolgáltatás által felügyelt beszélgetéseket használ az Foundry Agent Service-ben a csevegési előzmények Azure Cosmos DB való megőrzéséhez. A szolgáltatás többfordulós és munkamenetek közötti folytonosságot biztosít anélkül, hogy az ügyfélnek kezelnie kellene az állapotot, és automatikusan kontextusként biztosítja a teljes beszélgetést a válaszgenerálás során.

Alternatív megközelítés: Az ügyfélalkalmazás a beszélgetési előzményeket kezeli ahelyett, hogy delegálja azt az ügynökszolgáltatásba. Minden válasz állapotmentesen jön létre, és az ügyfél a korábbi válaszok kimeneti elemeit a későbbi kérések bemeneteként továbbítja.

Fontolja meg az ügyfél által felügyelt beszélgetések előzményeit, ha a számítási feladat megfelel az alábbi feltételek valamelyikének:

• Nulla adatmegőrzés. A megfelelőségi vagy szabályozási követelmények tiltják a beszélgetési tartalmak kiszolgálóoldali megőrzését.

• Egyéni környezet ablakvezérlője. Mielőtt elküldené őket a modellnek, szelektíven bele kell foglalnia, ki kell zárnia, össze kell foglalnia, vagy helyileg le kell tömörítenie a korábbi köröket.

• Több, független munkamenet-szemantikával rendelkező UX-csatorna. Ugyanazt az ügynököt különböző alkalmazások (webes, mobil, hang) használják, amelyek mindegyikének saját munkamenet-kezelési, tárolási és adatmegőrzési szabályzatra van szüksége.

Ez a megközelítés az állapotmegőrzés, a környezetkezelés, a beszélgetési adatok szabályozása és a munkamenet-elkülönítés felelősségét az alkalmazáskódra helyezi át. Mivel a beszélgetési állapot egy saját adattárban található, saját biztonsági mentési, replikációs és visszaállítási folyamatokat kell alkalmaznia.

Figyelembe kell venni a környezetablak korlátait és a HTTP-kérések hasznos adatméretének növelését a beszélgetési elemek továbbítása során. A többfordulós megbízhatóság érdekében használjon állandó tárolót, például Azure Cosmos DB vagy a meglévő alkalmazásadatbázist a memóriabeli állapot helyett.

Előre definiált ügynök vagy dinamikusan létrehozott ügynök

Jelenlegi megközelítés: A referencia-implementáció egy statikusan definiált ügynököt használ, amely a Foundryben mikroszolgáltatásként van üzembe helyezve. Az ügynök logikája és adatforrásai az üzembe helyezéskor vannak konfigurálva, és a következő alkalmazáskiadásig változatlanok maradnak. Ez a megközelítés akkor működik jól, ha az ügynökök viselkedése és az adatforrások stabilak és vezérelve vannak a DevOps-folyamatokon keresztül.

Alternatív megközelítés: Az Foundry SDK-k használatával dinamikusan hozhat létre vagy módosíthat ügynököket futásidőben. Ez a módszer lehetővé teszi, hogy az alkalmazás igény szerint példányosítsa az ügynököket, módosítsa a rendszerkéréseket, vagy újrakonfigurálja a kapcsolatokat a felhasználói környezet vagy az üzleti logika alapján.

Vegye figyelembe a dinamikus ügynököket, ha a számítási feladathoz a következő képességek szükségesek:

• Személyre szabott ügynöki viselkedés vagy adatforrások minden felhasználóhoz vagy munkamenethez

• Az ügynökkonfiguráció gyakori vagy programozott módosítása

• Rövid élettartamú, környezetspecifikus ügynöktámogatás speciális felhasználói élményekhez

A dinamikus ügynökkezelés növeli a rugalmasságot, de az életciklus-kezelés terheit is növeli. Győződjön meg arról, hogy megfelelő vezérlőkkel rendelkezik az ügynökök létrehozásához, módosításához és törléséhez.

Válassza ki az ügynöki megközelítést, amely megfelel a munkaterhelés felhasználói élmény követelményeinek.

Egyetlen ügynök vagy többügynökös orkesztráció

Jelenlegi megközelítés: Ez a referenciaarchitektúra egyetlen ügynököt használ, amely hozzáfér az összes szükséges eszközhöz a felhasználói interakciók hatékony kezeléséhez.

Alternatív megközelítés: Több specializált ügynököt vezényelhet, ahol minden ügynök adott tartományokra összpontosít, különböző modelleket használ, vagy különböző eszközökhöz fér hozzá.

Fontolja meg a többtényezős megközelítést, ha a számítási feladat a következő jellemzőket mutatja:

• A kérelmek több szakterületre is kiterjednek, például pénzügyi elemzésre, jogi felülvizsgálatra és műszaki megvalósításra. A specializált ügynökök mélyebb, pontosabb válaszokat nyújtanak a saját tartományaikban.

• Az információkhoz eltérő engedélyszintek szükségesek. Egy emberierőforrás-ügynök hozzáférhet az alkalmazottak adataihoz, míg az ügyfélszolgálati ügynök csak a termékinformációkhoz fér hozzá. A többtényezős architektúrák az ügynök szintjén támogatják a részletes biztonsági határokat.

• A különböző lekérdezési interakciók különböző modellek előnyeit élvezhetik. Az egyszerűsített modell egyszerű kérdéseket kezel, míg egy hatékonyabb modell összetett érvelési feladatokat dolgoz fel. Ez a módszer a költségeket és a késést is optimalizálja.

• A csevegési élmény az üzleti folyamatok előtereként szolgál, amelyek szekvenciális vagy párhuzamos lépéseket igényelnek, és amelyekhez különböző szakemberekre van szükség.

A többtényezős megközelítések koordinációs összetettséghez és nagyobb késéshez vezetnek az ügynökök közötti kommunikáció miatt. A szigorú hozzáférés-elkülönítési követelmények nélküli, jól definiált forgatókönyvek esetében egyetlen ügynök, amely egyetlen modellt és megfelelő eszközöket használ, megfelel a követelményeknek.

Az Foundry Agent Service szabványos protokollokkal támogatja az ügynökök külső ügynökökhöz és eszközökhöz való csatlakoztatását. A Model Context Protocol (MCP) kiszolgálókon üzemeltetett eszközökhöz és más ügynökökhöz az Ügynök–Ügynök (A2A) végpontokon keresztül csatlakozhat. A nyilvános MCP-kiszolgálóvégpontok tűzfalszabályokat igényelnek a kimenő forgalomhoz. A privát MCP-kiszolgálóvégpontokhoz a standard ügynök beállítása szükséges privát hálózatkezeléssel és dedikált alhálózattal. Konfigurálja a megfelelő hitelesítést minden végponthoz.

További információ a több koordinált ügynök implementálásáról: AI-ügynökök vezénylési mintái. Ez a cikk a szekvenciális, egyidejű, csoportos csevegési, átadási és magentic vezénylési megközelítéseket ismerteti. A Foundry Agent Service-ben implementálhat néhány mintát. Más mintákhoz saját üzemeltetésű vezénylésre van szükség egy olyan SDK-val, mint az Agent Framework.

Megfontolások

Ezek a szempontok implementálják a Azure Well-Architected-keretrendszer alappilléreit, amelyek a számítási feladatok minőségének javítása érdekében használható vezérelvek. További információ: Well-Architected Framework.

Alkalmazza ezt az architektúrát és a AI számítási feladatokat Azure tervezési útmutatóra a számítási feladat tervezési fázisában.

Reliability

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információ: Megbízhatóságitervezési felülvizsgálati ellenőrzőlistája.

Az Alapszintű App Service-webalkalmazás-architektúra a zónaredundanciára összpontosít a főbb regionális szolgáltatások esetében. A rendelkezésre állási zónák fizikailag különálló helyek egy régión belül, amelyek redundanciát biztosítanak, amikor két vagy több példányt helyez üzembe rajtuk. Ha az egyik zóna állásidőt tapasztal meg, előfordulhat, hogy a régió többi zónája érintetlenek maradhatnak. Az architektúra Azure szolgáltatások példányait és konfigurációit is elosztja a rendelkezésre állási zónák között. További információért lásd: Zónaredundáns, magas rendelkezésre állású alap webalkalmazás.

Ez a szakasz az App Service alaparchitektúrájában nem szereplő összetevők, különösen a Foundry és az AI Search megbízhatóságát ismerteti.

Zónaredundancia az orchestration rétegben

A vállalati üzemelő példányok általában zónaredundanciát igényelnek a zónaszintű hibák miatti szolgáltatáskimaradás kockázatának minimalizálása érdekében. A Azure a zónaredundancia azt jelenti, hogy olyan erőforrásokat használ, amelyek támogatják a a rendelkezésre állási zónákat és legalább három példányt helyeznek üzembe, vagy platformszintű redundanciát aktiválnak, ha a közvetlen példányvezérlés nem érhető el.

Ebben az architektúrában a Foundry üzemelteti az Foundry Agent Service képességet. Az ügynök megbízhatósága a Foundry Agent Service függőségeinek rendelkezésre állásától függ, amelyek az Azure Cosmos DB, a Storage és az AI Search. A Foundry Agent Service kezeli a szolgáltatásokon belüli adatokat, de ön konfigurálja azok megbízhatóságát az előfizetésében.

A vezénylési réteg zónaredundanciáinak eléréséhez kövesse az alábbi javaslatokat:

• Támogassa a zónaredundanciát az Azure Cosmos DB NoSQL-fiókban. Ez a konfiguráció több zónában biztosítja a szinkron adatreplikálást, ami csökkenti az adatvesztés vagy az állásidő kockázatát egy zóna meghibásodása esetén.

  Fontolja meg a globális eloszlást is, hogy enyhítse az Azure Cosmos DB belüli regionális kimaradásokat.

• Használjon zónaredundáns tárolót (ZRS) a Storage-fiókjához. A nagyobb rugalmasság érdekében használjon georedundáns tárolást (GZRS), amely egyesíti a zónákat és a regionális redundanciát.

• Konfigurálja az AI Search-példányt legalább három replikával. Ez a konfiguráció biztosítja, hogy a szolgáltatás a replikákat a régió egyedi zónái között ossza el.

Ha az ügynök integrálva van más számítási feladatokra vonatkozó függőségekkel, például egyéni eszközkapcsolatokkal vagy külső adatforrásokkal, győződjön meg arról, hogy ezek a függőségek megfelelnek a rendelkezésre állási és redundanciakövetelményeknek. Bármely egyzónás vagy nem redundáns függőség alááshatja a vezénylési réteg általános megbízhatóságát.

Az Foundry portál, az adatsík API-k és az Öntödei ügynök szolgáltatás képessége nem biztosít közvetlen vezérlőket a zónaredundanciához.

Megbízhatóság az Foundry-modell üzemeltetésében

Az Foundry szolgáltatásként (MaaS) üzemeltetett modelleket kínál számos üzembe helyezési lehetőséggel. Ezek a lehetőségek elsősorban a kvóta- és átviteli sebesség kezelését támogatják, nem pedig a régión belüli hagyományos magas rendelkezésre állást. A standard modelltelepítések egyetlen régióban működnek, és nem támogatják a rendelkezésre állási zónákat. A több adatközpont rendelkezésre állásának eléréséhez globális vagy adatzónás modell üzembe helyezését kell használnia.

Vállalati csevegési forgatókönyvek esetén helyezzen üzembe egy kiépített adatzónát és az adatzóna standard modelljét is. Konfigurálja a túlcsordulást a felesleges forgalom vagy hibák kezelésére. Ha a számítási feladat nem igényel alacsony késést vagy szigorú földrajzi adatok tartózkodási helyét és feldolgozását, használja a globális üzembe helyezéseket a maximális rugalmasság érdekében.

Az Foundry nem támogatja a fejlett terheléselosztási vagy feladatátvételi mechanizmusokat, például a körforgásos útválasztást vagy az áramkör-megszakítást a modelltelepítésekhez. Ha részletes redundanciát és feladatátvételi vezérlést igényel egy régión belül, a modell hozzáférési logikáját a felügyelt szolgáltatáson kívül kell üzemeltetnie. Létrehozhat például egy egyéni átjárót Azure API Management használatával. Ez a megközelítés lehetővé teszi egyéni útválasztási, állapot-ellenőrzési és feladatátvételi stratégiák implementálását. Ez azonban növeli a működési összetettségét, és az összetevő megbízhatóságáért a csapatra hárítja a felelősséget.

Az átjáró-előtérbeli modelleket egyéni API-alapú eszközökként is elérhetővé teheti az ügynök számára. További információért lásd: Az Azure OpenAI több telepítéséhez vagy példányához használjon átjárót.

Megbízhatóság a nagyvállalati tudást kereső AI-keresésben

Az AI Search üzembe helyezése a Standard tarifacsomag vagy annál magasabb szintű használatával egy olyan régióban, amely támogatja a rendelkezésre állási zónákat. Konfiguráljon legalább három replikát, hogy a szolgáltatás a példányokat külön rendelkezésre állási zónák között ossza el. Ez a konfiguráció rugalmasságot biztosít a zónaszintű hibákhoz, és támogatja a keresési műveletek magas rendelkezésre állását.

A számítási feladat replikáinak és partícióinak optimális számának meghatározásához használja az alábbi módszereket:

• Az AI-keresés monitorozása beépített metrikák és naplók használatával. A lekérdezés késésének, szabályozásának és erőforrás-használatának nyomon követése.

• A replikák megfelelő számának meghatározásához használjon monitorozási metrikákat, naplókat és teljesítményelemzést. Ez a megközelítés segít elkerülni a nagy lekérdezési mennyiség, az elégtelen partíciók vagy az indexkorlátozások miatti lefojtást.

• Az indexelési megbízhatóság biztosításához kerülje az időszakos indexelési vagy indexelési hibák miatti fennakadásokat. Az adatok integritásának ellenőrzése után érdemes lehet offline indexbe indexelni, és az élő indexről az újraépített indexre cserélni.

Megbízhatóság az Azure Firewall

Azure Firewall az architektúra kritikus kimenőforgalom-vezérlési pontja, de egyetlen meghibásodási pontot jelöl az összes kimenő forgalom esetében. A kockázat csökkentése érdekében telepítsen Azure Firewall minden rendelkezésre állási zónában a régióban. Ez a konfiguráció segít fenntartani a kimenő kapcsolatot, ha egy zóna elérhetetlenné válik.

Ha a számítási feladat nagy mennyiségű egyidejű kimenő kapcsolatot igényel, konfigurálja a Azure Firewall több nyilvános IP-címmel. Ez a módszer több IP-címelőtag között osztja el a forráshálózati címfordítási (SNAT-) kapcsolatokat, ami csökkenti az SNAT-portok kimerülésének kockázatát. Az SNAT kimerülése időszakos vagy teljes kimenő kapcsolatvesztést okozhat az ügynökök és más számítási feladatok összetevői számára, ami a funkciók leállását vagy a teljesítmény romlását eredményezheti.

Az SNAT-portok használatának és a tűzfal állapotának figyelése. Ha csatlakozási hibákat vagy átviteli sebességproblémákat észlel, tekintse át a tűzfal metrikáit és naplóit az SNAT-kimerültség vagy egyéb szűk keresztmetszetek azonosításához és kezeléséhez.

Az Foundry Agent Service függőségeinek elkülönítése hasonló számítási feladatok összetevőitől

A megbízhatóság maximalizálása és a hibák robbanási sugarának minimalizálása érdekében szigorúan elkülönítheti az Foundry Agent Service függőségeit az ugyanazon Azure szolgáltatásokat használó számítási feladatok egyéb összetevőitől. Ne ossza meg az AI Search, Azure Cosmos DB vagy Storage-erőforrásokat az ügynökszolgáltatás és más alkalmazásösszetevők között. Ehelyett helyezzen üzembe dedikált példányokat az ügynök szolgáltatás szükséges függőségeihez.

Ez az elkülönítés két fő előnnyel jár:

• Egyetlen számítási feladatszakasz hibáit vagy teljesítménycsökkenését tartalmazza, ami megakadályozza a nem kapcsolódó alkalmazásfunkciók kaszkádolt hatásait.

• Lehetővé teszi a célzott üzemeltetési folyamatok, például a biztonsági mentés, a visszaállítás és a feladatátvétel alkalmazását. Ezek a folyamatok összhangban vannak az erőforrásokat használó számítási feladat folyamatának rendelkezésre állási és helyreállítási követelményeivel.

Ha például a csevegő felhasználói felület alkalmazásának tranzakciós állapotot kell tárolnia Azure Cosmos DB, állítson be egy külön Azure Cosmos DB fiókot és adatbázist erre a célra ahelyett, hogy újrahasználja a Foundry Agent Service által kezelt fiókot vagy adatbázist. Még akkor is, ha a költségek vagy a működési egyszerűség motiválja az erőforrás-megosztást, a nem kapcsolódó számítási feladatok funkcióit érintő megbízhatósági esemény kockázata meghaladja a legtöbb vállalati forgatókönyv lehetséges megtakarítását.

Fontos

Ha költség- vagy üzemeltetési okokból az ügynök függőségeivel együtt helyez el számítási feladatspecifikus adatokat, soha ne használja közvetlenül a rendszer által felügyelt adatokat, például gyűjteményeket, tárolókat vagy indexeket, amelyeket az Foundry Agent Service hoz létre. Ezek a belső megvalósítási részletek nincsenek dokumentálva, és értesítés nélkül megváltozhatnak. A közvetlen hozzáférés megszakíthatja az ügynökszolgáltatást, vagy adatvesztést okozhat. Mindig használja az Foundry Agent Service adatsík API-jait adatkezeléshez, például az elfeledtetéshez való jog (RTBF) kéréseinek teljesítéséhez. A mögöttes adatokat kezelje úgy, hogy nem nyúl hozzájuk, és csak figyelje őket.

Többrégiós kialakítás

Ez az architektúra rendelkezésre állási zónákat használ a magas rendelkezésre álláshoz egyetlen Azure régióban. Ez nem többrégiós megoldás. Nem rendelkezik a regionális rugalmassághoz és vészhelyreállításhoz szükséges alábbi kritikus elemekkel:

• Globális bejövő forgalom és forgalom útválasztása
• DNS-kezelés hibatűréshez
• Adatreplikációs vagy elkülönítési stratégiák régiók között
• Aktív-aktív, aktív-passzív vagy aktív-hideg megjelölés
• Regionális feladatátvételi és feladat-visszavételi folyamatok a helyreállítási idő célkitűzéseinek (KPO-k) és a helyreállítási pont célkitűzéseinek (RRP-k) teljesítéséhez
• A fejlesztői élmények régióhoz való elérhetőségének vizsgálata, beleértve az Foundry portált és az adatsík API-kat

Ha a számítási feladat üzleti folytonosságot igényel, ha regionális leállás történik, további összetevőket és üzemeltetési folyamatokat kell megterveznie és implementálnia ezen az architektúrán túl. Konkrétan a terheléselosztást és a feladatátvételt kell kezelnie az egyes architektúrarétegeken, beleértve a következő területeket:

• Az adateszközök és a háttéradattárak alapozása
• Modell üzemeltetési és következtetési végpontjai
• A vezénylési vagy ügynökréteg
• Felhasználói felületi forgalom és DNS-belépési pontok

Emellett gondoskodnia kell arról is, hogy a megfigyelhetőség, a monitorozás és a tartalombiztonsági vezérlők továbbra is működőképesek és egységesek maradjanak a régiók között.

Ez az alaparchitektúra nem rendelkezik többrégiós képességekkel, ezért a regionális kimaradások valószínűleg szolgáltatásvesztést okoznak a számítási feladaton belül.

Katasztrófa utáni helyreállítás

A csevegőarchitektúrák állapotalapú összetevőket tartalmaznak, ezért terveznie kell a katasztrófa utáni helyreállításra. Ezek a számítási feladatok általában memóriatárolót igényelnek az aktív vagy szüneteltetett csevegésekhez. Emellett szükség van a kiegészítő adatok, például dokumentumok vagy képek tárolására is, amelyek hozzáadva vannak a csevegésekhez. Az ügynök vezénylési rétege a beszélgetési folyamatokra jellemző állapotot is fenntarthatja. Ebben az architektúrában a Foundry Agent Service Azure Cosmos DB, Storage és AI Search használatával tartja fenn a működési és tranzakciós állapotot. Ennek az állapotnak az életciklusa és az összetevők közötti összekapcsolása határozza meg a DR-stratégiát és a helyreállítási műveleteket.

A Foundry Agent Service nem biztosít beépített dr. képességeket. Nem rendelkezik az állapot replikálására, biztonsági mentések létrehozására vagy időponthoz kötött visszaállítások végrehajtására alkalmas képességekkel. A helyreállítás rekonstrukcióval történik, nem replikák előállítása helyett. Az incidensek végleg eltávolíthatják az ügynököket, beszélgetéseket és tudásadatokat. Tervezze meg az állapotalapú tartalom teljes állapotvesztésének lehetőségét, és ennek megfelelően állítsa be a helyreállítási elvárásokat az érdekelt felekkel.

Az alábbi kompenzáló vezérlők az Foundry Agent service DR útmutatója alapján csökkentik az adatvesztés valószínűségét és hatókörét, de nem szüntetik meg azt.

• Azure Cosmos DB: Kapcsolja be az adatbázis folyamatos biztonsági mentésétenterprise_memory, amely ügynökdefiníciókat és csevegéseket is tartalmaz. A folyamatos biztonsági mentés lehetővé teszi a visszaállítást egy adott időpontra (PITR) a megőrzési időszakon belül bármely időpontra, amely az előző hét napot jelenti. Rendszeresen tesztelje a visszaállítási folyamatot annak ellenőrzéséhez, hogy megfelel-e az RTO-nak, és hogy a visszaállított adatok elérhetők maradnak-e az ügynökszolgáltatás számára. Mindig térjen vissza ugyanarra a fiókra és adatbázisra.

• AI-keresés: Az AI Search nem rendelkezik beépített visszaállítási képességekkel, és nem támogatja a közvetlen indexkezelést. Adatvesztés vagy sérülés esetén forduljon a Microsoft ügyfélszolgálatahoz segítségért az elérhető index-visszaállítási lehetőségekkel kapcsolatban. Ez a korlátozás jelentősen befolyásolhatja az RTO-t. Ha a csevegés felhasználói felülete nem támogatja a fájlfeltöltéseket, és nincsenek olyan ügynökei, amelyek statikus fájlokat használnak tudásként, előfordulhat, hogy nincs szüksége DR-csomagra az AI Search használatához.

  Tartsa fenn a vállalat alapozó tudásának különálló, rendszeresen frissített igazságforrását. Szükség esetén ez az eljárás biztosítja az indexek újraépítését.

• Raktározás: Ha georedundáns tárfiókja van, használja az ügyfél által felügyelt feladatátvételt a Foundry Agent Service által használt blobtárolókhoz. Ez a beállítás lehetővé teszi az átkapcsolást regionális kiesés esetén. Ha csak ZRS-t használ, forduljon Microsoft ügyfélszolgálatához az adatok visszaállításához. Ez a folyamat meghosszabbíthatja az RTO-t. Az AI Searchhöz hasonlóan, ha a csevegőfelület nem támogatja a fájlfeltöltéseket, és nincsenek olyan ügynökei, amelyek statikus fájlokat használnak tudásként, előfordulhat, hogy nem kell dr. csomag a blobtárolókhoz.

• Tranzakciós konzisztencia: Ha a feladat állapottárolója Azure AI-ügynök azonosítókra, például beszélgetési azonosítókra vagy ügynökazonosítókra hivatkozik, koordinálja a helyreállítást az összes releváns adattárban. A függőségek csak egy részhalmazának visszaállítása árva vagy inkonzisztens adatokat eredményezhet. Tervezze meg a DR-folyamatokat, hogy fenntartsa a hivatkozási integritást a munkaterhelés és az ügynöki szolgáltatás állapota között.

• Ügynökdefiníciók és -konfiguráció: Ügynökök definiálása kódként. Ügynökdefiníciók, kapcsolatok, rendszerkérések és paraméterek tárolása a forrásvezérlőben. Ez a gyakorlat lehetővé teszi az ügynökök ismételt üzembe helyezését egy jól ismert konfigurációból, ha elveszíti a vezénylési réteget. Kerülje az ügynökkonfiguráció nyomon nem követett módosítását az Foundry portálon vagy az adatsík API-in keresztül. Ez a megközelítés biztosítja, hogy az üzembe helyezett ügynökök reprodukálhatóak maradjanak.

• Öntödei projektek: A projekt identitásához használjon felhasználó által hozzárendelt felügyelt identitást. Ha a projektet véletlenül törölték, a felhasználó által hozzárendelt felügyelt identitás lehetővé teszi a meglévő szerepkör-hozzárendelések újrafelhasználását a projekt és a kapacitásgazda újbóli létrehozásakor. Ez a megközelítés csökkenti a projektfüggőségekkel való koordinációt a helyreállítás során.

A Foundry Agent Szolgáltatás függőségeihez kiegészítő megelőző intézkedésként adjon hozzá egy törlés erőforrás-zárolást az egyes szolgáltatásokhoz. Ez a gyakorlat segít megvédeni az AI Search, a Azure Cosmos DB és a Storage katasztrofális állapotvesztését.

Mielőtt éles környezetbe telepítené, hozzon létre egy helyreállítási útmutatót, mely mind az alkalmazás-, mind az ügynök által kezelt állapotban bekövetkező hibákat kezeli.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.

Ez az architektúra kibővíti az alapvető Foundry-csevegés referenciaarchitektúrájában létrehozott biztonsági alapokat. Az alaparchitektúrához hozzáad egy hálózati biztonsági peremet az azonosítási perem mellett. Hálózati szempontból az Application Gateway az egyetlen internetes erőforrás. Elérhetővé teszi a csevegőfelület-alkalmazást a felhasználók számára. Identitás szempontjából a csevegés felhasználói felületének hitelesítenie és engedélyeznie kell a kéréseket. Ha lehetséges, felügyelt identitások használatával hitelesítheti az alkalmazásokat Azure szolgáltatásokhoz.

Identitás- és hozzáférés-kezelés

Ez az architektúra elsősorban rendszer által hozzárendelt felügyelt identitásokat használ a szolgáltatások közötti hitelesítéshez. Felhasználó által hozzárendelt felügyelt identitásokat is használhat. Mindkét esetben alkalmazza a következő alapelveket:

• Identitások elkülönítése erőforrás és függvény szerint. Hozzon létre különálló felügyelt identitásokat a következő összetevőkhöz:

  • Az Foundry-erőforrás
  • Minden egyes Foundry-projekt
  • A webalkalmazás
  • Application Gateway
  • Bármely egyéni vezénylő vagy integrációs kód

• Hozzárendelési korlátozások használata (előzetes verzió). Csak Microsoft.CognitiveServices/accounts/projects a Foundry-projektidentitások, Microsoft.Web/sites a webalkalmazási identitások és Microsoft.Network/applicationGateways az Application Gateway-identitások esetében engedélyezett. Állítsa az elkülönítési hatókört a következőre Regional, és hozzon létre egy külön identitáskészletet az egyes üzembehelyezési régiókhoz.

• Csak akkor rendeljen identitást egy Azure erőforráshoz, ha az erőforrásnak ügyfélként kell hitelesítenie magát egy másik Azure szolgáltatásban.

• Használjon célhoz illő identitástípusokat. Ahol lehetséges, használjon számítási feladat-identitásokat alkalmazásokhoz és automatizáláshoz, és használjon ügynökidentitásokat az AI-ügynökökhöz.

Öntödei erőforrások megosztása és elkülönítése

Ez az architektúra egy dedikált Foundry-erőforrást helyez üzembe egyetlen éles munkaterheléshez. A teljes mértékben izolált számítási feladatok topológiája az éles számítási feladatokhoz ajánlott topológia. Az Foundry-erőforrás a benne futó összes rendszer hálózati határa és identitáshatára. Egy dedikált erőforrás elkülöníti a számítási feladat megfelelőségi hatókörét, a robbanási sugarat és a kvótát a nem kapcsolódó számítási feladatoktól és az éles üzem előtti környezetektől. Ez a választás tiszteletben tartja a közzétett AI-platformmegosztási döntési útmutatót, amely azt javasolja, hogy éles számítási feladatonként alapértelmezés szerint egyetlen AI-platformpéldányt hozzon létre.

A teljesen izolált topológia a megosztott Foundry-erőforrásban közösen elhelyezett számítási feladatokhoz képest nagyobb beállítási és kezelési többletterheléssel jár. Ez az architektúra a legtöbb éles számítási feladathoz szükséges szegmentálásért és független hozzáférés-vezérlésért, kvótáért és költséghatárokért cserébe elfogadja ezt a kompromisszumot.

Connections

A kapcsolatok határozzák meg, hogy egy Foundry-erőforrás vagy egy adott projekt hogyan hitelesít és használ külső függőséget. Ha lehetséges, hozzon létre kapcsolatokat a projekt szintjén. Távolítsa el a nem használt kapcsolatokat. Az Microsoft Entra ID-alapú hitelesítést részesítse előnyben minden kapcsolat esetében.

Ha egy kapcsolat nem támogatja a Microsoft Entra ID, meg kell adnia egy titkos kulcsot, például egy API-kulcsot. Ezeket a titkos kulcsokat egy dedikált, saját üzemeltetésű Azure kulcstartóban tárolhatja. Konfiguráljon egy Azure Key Vault kapcsolatot az Foundry-erőforráshoz, hogy a szolgáltatás elolvashassa és megírhassa az általa kezelt titkos kulcsokat.

Ezt a kulcstárat csak a Foundryhez használja. Ne ossza meg más számítási feladatok összetevőivel. Az erőforrásban lévő összes projekt minden, a Microsoft Entra ID-től eltérő kapcsolata ebben a trezorban tárolja a titkait. Más számítási feladatok összetevőinek nem kell hozzáférniük ezekhez a titkos kulcsokhoz az Foundry képességeinek használatához. Ne adjon olvasási vagy írási engedélyeket ezen a tárolón más összetevőknek, hacsak nincs egyértelmű működési követelménye, vagy nem fogadja el a kompromisszumot.

Ez az architektúra két API-kulcsalapú kapcsolatot tartalmaz: az Application Insights for Foundry metrikákat és a webes keresőeszközt. Az architektúra külső HTTP-végpontokat ( például MCP-kiszolgálókat vagy OpenAPI által definiált API-kat) hívó eszközökkel való kiterjesztésekor minden eszköz hozzáad egy projektkapcsolatot, amely a hitelesítési hitelesítő adatait tartalmazza.

McP-kiszolgáló csatlakoztatásakor korlátozza az elérhető eszközöket a használatával allowed_tools. A nagy kockázatú műveletek, például az adatok írására vagy az erőforrások módosítására szolgáló eszközök jóváhagyásának megkövetelése és naplózása, valamint az eszköz nevének és argumentumainak ellenőrzése jóváhagyás előtt. További információkért tekintse meg az MCP ajánlott eljárásait.

Ha ügyfél által felügyelt kulcsokat használ a titkosításhoz, az ügyfél által kezelt kulcsokat és a kapcsolati titkos kulcsokat is tárolhatja ugyanabban a dedikált tárolóban, ha a biztonsági szabályozási szabályzatok lehetővé teszik a titkosítási kulcsok és titkos kódok áthelyezését.

Az Foundry Portal alkalmazotti hozzáférése

Amikor az alkalmazottakat beilleszti a Foundry projektekbe, rendelje hozzá a szerepkörükhöz szükséges minimális engedélyeket. A Microsoft Entra ID-csoportok és az Azure szerepköralapú hozzáférés-vezérlés (Azure RBAC) használatával biztosíthatja a feladatok elkülönítését. Megkülönbözteti például az ügynökfejlesztőket az adattudósoktól, akik finomhangolási feladatokat végeznek. De értse meg a korlátozásokat és kockázatokat. Személy hozzárendelése a Foundry beépített szerepköreihez és Azure RBAC-szerepkörökhöz, például:

Személyiség	Beépített szerepkör	Scope
Öntödei erőforrás-kezelő	Öntödei fiók tulajdonosa	Öntödei erőforrás
Ügynökfejlesztő vagy adatelemző	Foundry User a Foundry-projekten, valamint Olvasó a Foundry-erőforráson	Foundry-projekt és Foundry-erőforrás

Az egyes beépített szerepkörök engedélyeit és további vállalati leképezési példákat a Role-alapú hozzáférés-vezérlés Microsoft Foundry című témakörben találja.

Az Foundry portál számos műveletet futtat a szolgáltatás identitásának használatával, nem pedig az alkalmazott identitásával. Ennek eredményeképpen a korlátozott Azure RBAC-szerepkörrel rendelkező alkalmazottak láthatják a bizalmas adatokat, például csevegéseket, ügynökdefiníciókat és konfigurációkat. Ez az Öntödei portál kialakítása véletlenül megkerülheti a kívánt hozzáférési korlátozásokat, és a tervezettnél több információt tehet közzé.

A jogosulatlan hozzáférés kockázatának csökkentése érdekében korlátozza a portál használatát éles környezetben olyan alkalmazottak számára, akiknek nyilvánvaló operatív igényük van. A legtöbb alkalmazott esetében vonja vissza vagy tiltsa le az Foundry portálhoz való hozzáférést éles környezetben. Ehelyett használjon automatizált üzembehelyezési folyamatokat és infrastruktúrát kódként (IaC) az ügynök- és projektkonfiguráció kezeléséhez.

Kezelje az új projektek létrehozását egy Öntödei erőforrásban kiemelt műveletként. A portálon létrehozott projektek nem öröklik automatikusan a meglévő hálózati biztonsági vezérlőket, például a privát végpontokat vagy a hálózati biztonsági csoportokat (NSG-k). Ezekben a projektekben az új ügynökök megkerülik a kívánt biztonsági szegélyt. A projektlétrehozás kényszerítése kizárólag ellenőrzött, auditálható IaC-folyamatokon keresztül.

Öntödei projektszerepkör-hozzárendelések és kapcsolatok

Az Foundry Agent Service standard módban való használatához a projektnek adat- és vezérlősík-engedélyekkel kell rendelkeznie az Foundry Agent Service függőségeihez. A projekt felügyelt identitásának emelt szintű szerepkör-hozzárendelésekkel kell rendelkeznie a tárfiókon, az AI Search-ben és az Azure Cosmos DB-fiókban. Ezek az engedélyek szinte teljes hozzáférést biztosítanak ezekhez az erőforrásokhoz, beleértve az adatok olvasásának, írásának, módosításának vagy törlésének lehetőségét. A minimális jogosultsági hozzáférés fenntartásához elkülönítse a számítási feladat erőforrásait az Foundry Agent Service függőségeitől.

Egyetlen Foundry-projekt összes ügynöke ugyanazzal a felügyelt identitással rendelkezik. Ha a számítási feladat több olyan ügynököt használ, amely különböző erőforráskészletekhez való hozzáférést igényel, kövesse a minimális jogosultság elvét, és hozzon létre egy külön Foundry-projektet minden egyes különálló ügynök-hozzáférési mintához. Ez az elkülönítés lehetővé teszi, hogy csak a minimálisan szükséges engedélyeket rendelje hozzá az egyes projektek felügyelt identitásához, ami csökkenti a túlzott vagy nem szándékos hozzáférés kockázatát. Ez a megosztottidentitás-modell az ebben az architektúrában használt promptügynökökre vonatkozik. Az üzembe helyezett üzemeltetett ügynökök ehelyett saját Microsoft Entra ügynökidentitást kapnak az üzembe helyezéskor, így a hozzáférési minták különböző projektekbe való elkülönítése nélkül biztosíthatja és naplózhatja az eszközökhöz és az alsóbb rétegbeli erőforrásokhoz való hozzáférést ügynökenként.

Ha kapcsolatokat hoz létre külső erőforrásokhoz a Foundryben, Microsoft Entra ID-alapú hitelesítést használjon, ha elérhető. Ez a megközelítés szükségtelenné teszi az előre felosztott titkos kulcsok fenntartását. Minden egyes kapcsolat hatókörét úgy állítsuk be, hogy csak a tulajdonos projekt használhassa. Ha több projekt is hozzáférést igényel ugyanahhoz az erőforráshoz, hozzon létre egy külön kapcsolatot az egyes projektekben ahelyett, hogy egyetlen kapcsolatot osztanának meg a projektek között. Ez a gyakorlat szigorú hozzáférési határokat kényszerít ki, és megakadályozza, hogy a jövőbeli projektek örökölhessék a nem igényelt hozzáférést.

Ne hozzon létre kapcsolatokat az Foundry-erőforrás szintjén, mert az erőforrásszintű kapcsolatok az erőforrás összes jelenlegi és jövőbeli projektére vonatkoznak. Véletlenül széles körű hozzáférést biztosíthatnak az erőforrásokhoz, megsérthetik a minimális jogosultsági elveket, és növelhetik a jogosulatlan adatexpozíció kockázatát. Csak projektszintű kapcsolatokat hozhat létre.

Konverzációk izolálása

Az Foundry Agent Service nem kényszeríti ki a felhasználónkénti hitelesítést a beszélgetéseken. Az alkalmazáskiszolgáló azonosítója olyan projektszintű hitelesítő adatokkal rendelkezik, amelyekkel az azonosító megadásával bármely beszélgetésből tud olvasni vagy írni. Ha a csevegőfelületi alkalmazás ellenőrzés nélkül közvetlenül átad egy ügyfél által megadott beszélgetési azonosítót az Agent Service-nek, a felhasználó hozzáférhet vagy beszúrhat üzeneteket egy másik felhasználó beszélgetésébe. Ez egy hibás objektumszintű engedélyezési biztonsági rés.

Az alkalmazáskiszolgálónak a beszélgetés tulajdonjogát kell kikényszerítenie. Ne bízzon meg az ügyfél beszélgetésazonosítóiban. Minden kérésnél ellenőrizze, hogy a hitelesített felhasználóé-e a hivatkozott beszélgetés, mielőtt továbbítanák a kérést az Agent Service-nek.

A üzemeltetett ügynökök felhasználónkénti munkamenet-elkülönítési modellt kínálnak, de ez az architektúra topológiája határozza meg, hogy alkalmazható-e. A webalkalmazás minden bejelentkezett felhasználó nevében meghívja az ügynököt saját számítási feladattal, így a platform egyetlen hívó identitást lát, és nem tudja megkülönböztetni az egyik végfelhasználót a másiktól. Ebben a mintában az alkalmazáskiszolgáló továbbra is a megbízhatósági határ marad, és a korábban ismertetett módon kell kikényszerítenie a beszélgetés tulajdonjogát.

Az elkülönítés akkor válik alkalmazhatóvá, ha az üzemeltetett ügynök végpontjára irányuló kérés nem csak az alkalmazás identitását, hanem a végfelhasználó identitását hordozza. A hívó közvetlenül a saját Microsoft Entra jogkivonatával hitelesít, vagy az alkalmazáskiszolgáló átadja a végfelhasználó stabil azonosítóját a platformnak. Amikor a kérelem azonosítja a végfelhasználót, a platform a beszélgetéseket, a munkameneteket, a tárolt adatokat és a munkamenetenkénti $HOME fájlrendszert a kérelem identitására hatókörli. Amikor minden hívó saját identitást jelenít meg, az elválasztja az egyik felhasználó adatait a másiktól. Delegált identitások esetén a platform nem választja el az egyik delegált felhasználót a másiktól, így a korábban ismertetett alkalmazás-kiszolgáló kényszerítés továbbra is érvényes.

Amikor az alkalmazáskiszolgáló végfelhasználói identitásokat delegál, a felhasználónkénti ügynöki munkamenetek megnyitása helyett számos felhasználót csoportosíthat az ügynöki munkamenetek egy meghatározott csoportjába. A platform előfizetésenként és régiónként korlátozza az egyidejű ügynökmunkamenetek számát, és ebbe a korlátba csak azok az ügynökmunkamenetek számítanak bele, amelyek aktívan dolgoznak fel egy kérelmet. Amikor a felhasználók megosztanak egy ügynök-munkamenetet, a platform továbbra is elkülöníti az egyes felhasználók beszélgetési állapotát, de az ügynöktároló által tárolt adatok( például fájlok, adatbázissorok vagy gyorsítótár) nem lesznek automatikusan particionálva. A kódnak az adatokat mind az ügynök munkamenete, mind a végfelhasználó identitása alapján kell kulcsolnia. Ellenkező esetben az ugyanabban a közös munkamenetben lévő felhasználók elolvashatják egymás tárolt adatait. A leképezési stratégiákról és erről a felhasználónkénti particionálásról lásd: Több felhasználó multiplexelése egy üzemeltetett ügynökmenetben.

Tartalombiztonság

Az üzembe helyezésben lévő minden modellhez hozzá kell rendelni egy tartalomszűrő szabályzatot, amely a promptokat és a modellválaszokat káros tartalom szempontjából szűri.

Értékelje ki az alapértelmezett Microsoft által felügyelt szabályzatot a számítási feladat tartalombiztonsági követelményei alapján. Ha az alapértelmezett küszöbértékek nem felelnek meg ezeknek a követelményeknek, egyéni tartalomszűrő házirendet kell létrehoznia, és az üzembe helyezéshez kell kötnie. A szabályzatot kódként kezelheti az infrastruktúra többi része mellett, hogy a tartalombiztonsági konfiguráció a különböző környezetekben is vezérelve és konzisztens maradjon.

hálózat

Az identitásalapú hozzáférés mellett ez az architektúra hálózati titoktartást is igényel.

A hálózat kialakítása a következő biztosítékokat tartalmazza:

• Egyetlen biztonságos belépési pont az összes csevegési felhasználói felület forgalmához, amely minimalizálja a támadási felületet

• Szűrt bejövő és kimenő hálózati forgalom NSG-k, webalkalmazási tűzfal, felhasználó által megadott útvonalak (UDR-ek) és Azure Firewall szabályok kombinációjával

• Az átvitel alatt álló adatok végpontok közötti titkosítása TLS használatával

• Hálózati adatvédelem Private Link használatával az összes Azure PaaS-szolgáltatáskapcsolathoz

• A hálózati erőforrások logikai szegmentálása és elkülönítése, dedikált alhálózatokkal az egyes fő összetevők csoportosításához a részletes biztonsági szabályzatok támogatásához

Hálózati folyamatok

A diagram az alapszintű csevegési architektúrához hasonlít. Tartalmazza az Azure OpenAI-architektúrát és három számozott hálózati folyamatot. A bejövő folyamat és az App Service-ből Azure PaaS-szolgáltatásokba irányuló folyamat az alapkonfigurációs App Service-webarchitektúrából lesz átmásolva. Az Foundry-ügynök szolgáltatás folyamata egy nyilat jelenít meg a privát virtuális hálózat Foundry privát végpontjáról, amely a Foundry Agent Service szolgáltatásra mutat. Az Foundry Agent Service folyamatban a második számozott nyíl azt mutatja, hogy a magánhálózati Azure AI-ügynök virtuális felületéről érkező hívások hogyan haladnak át a privát végpontokon. A harmadik számozott nyíl egy nyilat jelenít meg a virtuális felületről egy Azure Firewall mezőre, amely azt jelzi, hogy az internetre irányuló összes hívás ezen a tűzfalon keresztül halad át.

A baseline App Service webalkalmazás architektúrája a felhasználótól a csevegés felhasználói felületére irányuló bejövő folyamatot, valamint az App Service-ből a Azure PaaS-szolgáltatásokba irányuló folyamatot ismerteti. Ez a szakasz az ügynökök interakcióira összpontosít.

Amikor a csevegőfelület kommunikál az Foundryben üzembe helyezett ügynökkel, a következő hálózati folyamatok történnek:

1. Az App Service által üzemeltetett csevegőfelület https-kéréseket kezdeményez egy privát végponton keresztül az Foundry adatsík API-végpontjához.

2. Amikor az ügynök hozzáfér Azure PaaS-szolgáltatásokhoz, például szolgáltatásfüggőségekhez, egyéni tudástárakhoz vagy egyéni eszközökhöz, a delegált alhálózat egybérlős adatproxyja HTTPS-kéréseket küld ezeknek a szolgáltatásoknak a privát végpontjainak.

3. Amikor az ügynök hozzáfér a virtuális hálózaton kívüli erőforrásokhoz, beleértve az internetes API-kat vagy a külső szolgáltatásokat, az adatproxy átirányítja ezeket a HTTPS-kéréseket a delegált alhálózatról a Azure Firewall keresztül.

A privát végpontok kulcsfontosságú biztonsági vezérlőként szolgálnak ebben az architektúrában az identitásalapú biztonság kiegészítésével. Mivel ez az architektúra privát végpontokat és UDR-eket használ a virtuális hálózaton, nem támogatja az Foundry-projektek hálózati biztonsági szegélyképességét .

Hozzáférés a Foundryhez

Ez az architektúra letiltja az Foundry adatsíkhoz való nyilvános hozzáférést azáltal, hogy csak a Foundry privát kapcsolatán keresztül engedélyezi a forgalmat. Az Foundry portál nagy részét a portál webhelyén keresztül érheti el, de minden projektszintű funkcióhoz hálózati hozzáférés szükséges. A portál az Foundry-erőforrás adatsík api-jaira támaszkodik, amelyek csak privát végpontokon keresztül érhetők el. Ennek eredményeképpen a fejlesztőknek és az adatszakértőknek jump boxon, társhálózaton, Azure ExpressRoute kapcsolaton vagy helyek közötti VPN-kapcsolaton keresztül kell hozzáférniük a portálhoz.

Az ügynök adatsíkjával folytatott minden programozott interakciónak ezeket a privát végpontokat is használnia kell. Ilyenek például a webalkalmazásból vagy a modell következtetését meghívó külső vezénylési kódból érkező hívások. A privát végpontok nem a projekt szintjén, hanem az erőforrás szintjén vannak definiálva, így az erőforrás összes projektje azonos végpontokkal és hálózati expozícióval rendelkezik. A hálózati hozzáférést nem lehet projektszinten szegmentálni.

A konfiguráció támogatásához állítsa be a DNS-t a következő Foundry FQDN API-végpontokhoz:

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

Az alábbi ábra bemutatja, hogyan csatlakozik egy AI-fejlesztő a Azure Bastion egy virtuális gép (VM) jump boxjához. Ebből a jump boxból a szerző hozzáférhet a projekthez az Foundry portálon egy privát végponton keresztül ugyanabban a hálózatban.

Egy nyíl az ügynök szerzőjétől az Azure Bastion-ra, a jump box-ra, a Foundry portál privát végpontjára, majd a Foundry projektbe mutat, amely a Foundry Agent Service szolgáltatást tartalmazza. Az Foundry-projektben egy nyíl mutat a Azure AI-ügynök integrációs alhálózatának virtuális felületére. A végső nyíl a virtuális felületről a három Foundry Agent Service-függőség privát végpontjára mutat. Ezek a függőségek az AI Search, a Azure Cosmos DB és a Storage.

Az Foundry-ügynök alhálózatából érkező forgalom szabályozása

Ez az architektúra átirányítja a kimenő (kimenő) hálózati forgalmat az Foundry Agent Service képességből egy delegált alhálózaton keresztül a virtuális hálózaton belül.

A promptügynökök esetében egy egybérlős adatproxy fut ebben a delegált alhálózatban, és az ügynök nevében kezeli az összes kimenő kapcsolatot. Az Foundry Agent Service minden projekthez egy adatproxyt helyez üzembe, és a projekt összes parancssori ügynöke megosztja azt. Az adatproxy az ügynök szükséges szolgáltatásfüggőségeinek és az ügynök által használt legtöbb külső tudásforrásnak vagy eszközkapcsolatnak a kimenő pontja.

Az üzemeltetett ügynökök esetében a vezérlési pont eltolódik: minden üzemeltetett ügynök munkamenete olyan számításban fut, amely dedikált hálózati adapterrel rendelkezik ebben az alhálózatban, így az ügynök saját kimenő forgalma közvetlenül ezen a felületen halad át, nem pedig az adatproxyn keresztül, bár az eszközhívások továbbra is az adatproxyn keresztül haladnak.

Ennek a kimenő útvonalnak a kényszerítésével teljes mértékben szabályozhatja a kimenő forgalmat. Részletes NSG-szabályokat, egyéni útválasztást és DNS-vezérlést alkalmazhat a szolgáltatást elhagyó összes ügynökforgalomra. Ez a kialakítás segít csökkenteni az adatkiszivárgási kísérleteket a vezénylési logikából.

Az ügynökszolgáltatás a virtuális hálózat DNS-konfigurációjával oldja fel a privát végpontrekordokat és a szükséges külső teljes tartományneveket. Ez a beállítás biztosítja, hogy az ügynök kérései DNS-naplókat generálnak, amelyek támogatják a naplózást és a hibaelhárítást.

Az ügynök kimenő alhálózatához csatolt NSG blokkolja az összes bejövő forgalmat, mert nem fordulhat elő jogszerű bejövő forgalom. A kimenő NSG-szabályok csak a virtuális hálózaton belüli privát végpont alhálózatokhoz és az internethez kötött forgalom 443-ás TCP-portjához engedélyezik a hozzáférést. Az NSG tagadja az összes többi forgalmat.

Az internetes forgalom további korlátozása érdekében ez az architektúra egy UDR-t alkalmaz az alhálózatra, amely az összes HTTPS-forgalmat Azure Firewall keresztül irányítja. A tűzfal szabályozza, hogy az ügynök mely teljes tartományneveket érheti el HTTPS-kapcsolatokon keresztül. Ha például az ügynök openAPI-eszközdefiníción keresztül csatlakozik egy nyilvános MCP-kiszolgálóhozhttps://contoso.com/mcp, vagy külső API-t hív meg, konfiguráljon Azure Firewall, hogy engedélyezze a forgalmat az alhálózat 443-es portján lévő adott teljes tartománynevek felé, és győződjön meg arról, hogy az NSG engedélyezi ezt a forgalmat.

Az ügynök futtatókörnyezetéhez a saját platformfüggőségeihez is kimenő hozzáférésre van szükség, nem csak az ügynökök által használt teljes tartománynevekhez. Engedélyezze a AzureActiveDirectory szolgáltatáscímkét, hogy az ügynöki számítási erőforrás hitelesíthesse magát. A külső végpontokat elérő hosztolt ügynök megköveteli, hogy ezeket a teljes tartományneveket (FQDN-eket) engedélyezze a tűzfalában. Erre a forgalomra ne alkalmazza a TLS-ellenőrzést Azure Firewall. Az ellenőrzés során használt tanúsítvány megszakíthatja az ügynökök kapcsolatait.

Megjegyzés:

Nem minden, az ügynökökhöz csatlakoztatott tudáseszköz halad át ezen az alhálózaton. A webes keresőeszköz például meghívja azokat a hívásokatapi.bing.microsoft.com, amelyeket várhatóan az alhálózat 443-es portjának engedélyezésével fog Azure Firewall keresztül irányítani. Az Agent Service azonban egy belső mechanizmuson keresztül hívja meg ezt az eszközt, amely teljes egészében áthalad a kimenő alhálózaton. Tesztelje a számítási feladathoz tartozó összes beépített tudás- és eszközkapcsolatot annak ellenőrzéséhez, hogy azok megfelelnek-e a hálózati kimenőforgalom-vezérlési szabályzatoknak.

A számítási feladat tulajdonában lévő MCP-kiszolgálók elérése

Ha a munkaterheléséhez privát MCP-kiszolgálót üzemeltet, hozzon létre egy dedikált MCP-alhálózatot ugyanabban a virtuális hálózatban, mint az ügynök-alhálózat. Engedélyezze a 443-as és 31443-es kimenő TCP-portokat az ügynök alhálózatáról az MCP-alhálózatra, és engedélyezze az MCP-alhálózaton a megfelelő bejövő forgalmat. Konfigurálja a privát DNS-t úgy, hogy a Container Apps-környezet alapértelmezett vagy egyéni tartománya a virtuális hálózaton belüli statikus IP-címére oldódjon fel. Ebben a topológiában az MCP-kiszolgálókra irányuló ügynökhívások privát címzést használnak, és a virtuális hálózaton belül maradnak. A megvalósítással kapcsolatos útmutatásért tekintse meg az ügynökök csatlakoztatása a Model Context Protocol-kiszolgálókhoz című témakört.

Feltéve, hogy az MCP-kiszolgálót a Container Apps üzemelteti, az MCP alhálózat NSG-jének engedélyeznie kell a szükséges Container Apps hálózati forgalmat is. Irányítsa a munkaterhelés MCP-kiszolgálóinak internetre irányuló forgalmát az Azure Firewallon keresztül.

Virtuális hálózatok szegmentálása és biztonsága

Ez az architektúra úgy szegmentálta a virtuális hálózatot, hogy minden fő összetevőcsoportot hozzárendel a saját alhálózatához. Minden alhálózat rendelkezik egy dedikált NSG-vel, amely a bejövő és kimenő forgalmat csak az összetevő által igényeltre korlátozza.

Az alábbi táblázat összefoglalja az egyes alhálózatok NSG- és tűzfalkonfigurációját.

Használat vagy alhálózat neve	Bejövő forgalom (NSG)	Kimenő forgalom (NSG)	UDR–tűzfal	Tűzfal kimenő szabályai
Privát végpontok snet-privateEndpoints	Virtuális hálózat	Nem engedélyezett forgalom	Igen	Nem engedélyezett forgalom
Application Gateway snet-appGateway	Csevegő felhasználói felület felhasználói forrás IP-címei, például a nyilvános internet és a szolgáltatáshoz szükséges források	Privát végpont alhálózata és a szolgáltatáshoz szükséges elemek	Nem	-
App szolgáltatás snet-appServicePlan	Nem engedélyezett forgalom	Privát végpontok és Azure Monitor	Igen	Az Azure Monitor-hoz
Öntödei Ügynök Szolgáltatás snet-agentsEgress	Nem engedélyezett forgalom	Privát végpontok, MCP-alhálózat és internet	Igen	Csak olyan nyilvános teljes tartománynevek, amelyek használatát engedélyezi az ügynököknek
Privát MCP-kiszolgálók snet-mcpServers	Az Foundry Agent Service alhálózatából származó 443-s és 31443-os TCP-portok és a gazdagéphez szükséges források	kötelező bejegyzések a szolgáltatáshoz	Igen	A platformhoz szükséges FQDN-ek és kizárólag azok a nyilvános FQDN-ek, amelyeket az MCP-kiszolgálók igényelnek
Jump box virtuális gépek snet-jumpBoxes	Azure Bastion alhálózat	Privát végpontok és az internet	Igen	A virtuális gép igénye szerint
Ügynökök létrehozása snet-buildAgents	Azure Bastion alhálózat	Privát végpontok és az internet	Igen	A virtuális gép igénye szerint
Azure Bastion AzureBastionSubnet	Lásd: NSG-hozzáférés és Azure Bastion	Lásd: NSG-hozzáférés és Azure Bastion	Nem	-
Azure Firewall AzureFirewallSubnet AzureFirewallManagementSubnet	Nincs NSG	Nincs NSG	Nem	-

Ez a kialakítás kifejezetten tagadja az összes többi forgalmat, akár az NSG-szabályokon keresztül, akár alapértelmezés szerint az Azure Firewall.

Amikor hálózati szegmentációt és biztonságot valósít meg ebben az architektúrában, kövesse az alábbi javaslatokat:

• Helyezzen üzembe egy Azure DDoS Protection tervet az Application Gateway nyilvános IP-címén a mennyiségi támadások csökkentése érdekében.

• Csatoljon egy NSG-t minden azt támogató alhálózathoz. Alkalmazza a lehető legszigorúbb szabályokat a szükséges funkciók megzavarása nélkül.

• Alkalmazzon kényszerített bújtatást az összes támogatott alhálózatra, hogy a kimenő tűzfal az összes kimenő forgalmat megvizsgálhassa. Használjon kényszerített bújtatást olyan alhálózatokon is, ahol nem várható kimenő forgalom. Ez a módszer részletes védelmi mértéket ad hozzá, amely védelmet nyújt az alhálózat szándékos vagy véletlen visszaélése ellen.

Webalkalmazási tűzfal finomhangolása

A csevegőalkalmazások gyakran olyan tartalmakat hoznak létre, amelyek hamis pozitívákat eredményeznek a WAF által kezelt szabályokban. A felhasználói kérések és modellválaszok gyakran tartalmaznak kódrészleteket, SQL-utasításokat vagy HTML-töredékeket. A csevegési tartalom számos felügyelt szabálykategóriában hamis pozitív értékeket válthat ki, beleértve a távoli kódvégrehajtást, a helyi fájlbefoglalást és a fenyegetésfelderítési szabályokat. Többfordulós beszélgetések esetén az OWASP anomáliadekód mindaddig halmozódik fel az üzenetek között, amíg a WAF HTTP 403-as hibával nem blokkolja a kérést, ami azt jelenti, hogy a blokkolás spontán jelenhet meg, amikor a beszélgetések hosszabbak lesznek.

Ennek megoldásához hangolja a WAF-szabályzatot úgy, hogy a csevegési üzeneteket tartalmazó kérelem törzsmezőjére vonatkozó kizárásokat hoz létre. Hatókörkizárások az érintett szabálycsoportokra a szabályok globális letiltása helyett. Azt is ellenőrizze, hogy a kérelem törzsének ellenőrzési korlátai megfelelnek-e a csevegési interakciókban jellemző hasznos teher méretének.

Szabályozás szabályzaton keresztül

A számítási feladat biztonsági alapkonfigurációjához való igazodáshoz Azure Policy és hálózati szabályzatokkal győződjön meg arról, hogy minden számítási feladat erőforrása megfelel a követelményeknek. A szabályzaton keresztüli platformautomatizálás csökkenti a biztonsági konfiguráció eltérésének kockázatát, és segít csökkenteni a manuális érvényesítési tevékenységeket.

Fontolja meg a következő típusú biztonsági szabályzatok implementálását az architektúra megerősítése érdekében:

• Kapcsolja ki a kulcsalapú vagy más helyi hitelesítési módszereket az olyan szolgáltatásokban, mint az Foundry-eszközök és a Key Vault.

• A hálózati hozzáférési szabályok, a privát végpontok és az NSG-k explicit konfigurációjának megkövetelése.

• Titkosítást igényel, például ügyfél által felügyelt kulcsokat.

• Korlátozhatja az erőforrások létrehozását, például a régiók vagy erőforrástípusok korlátozását.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésére és a működési hatékonyság javítására összpontosít. További információt a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistájában talál.

Ez a preconfigured becslés a Azure díjkalkulátorban csak az architektúra összetevőit tartalmazza, így a használatnak megfelelően testre szabhatja. A forgatókönyv legdrágább összetevői a Azure Cosmos DB, az AI Search és a DDoS Protection. Egyéb jelentős költségek közé tartozik a csevegés felhasználói felületének kiszámítása és az Application Gateway. Optimalizálja ezeket az erőforrásokat a költségek csökkentése érdekében.

Öntödei Ügynökségi Szolgáltatás

A standard üzembe helyezés használatakor saját Azure-előfizetésében kell beállítania és kezelnie a szolgáltatás függőségeit.

Az alábbi javaslatok ismertetik, hogyan optimalizálhatók a szükséges szolgáltatások költségei:

• A Foundry Agent Service kezeli a kérelemegységek (RU) elosztását az Azure Cosmos DB-n. A hosszú távú költségek csökkentése érdekében vásároljon fenntartott kapacitást Azure Cosmos DB számára. Hangolja össze a foglalásokat a várt használati időtartammal és mennyiséggel. A fenntartott kapacitás előzetes elkötelezettséget igényel, és nem rugalmas, ha a számítási feladat használati mintái jelentősen megváltoznak.

• Ha a csevegési forgatókönyv nem igényel fájlfeltöltést, zárja ki ezt a funkciót az alkalmazásban. Ebben az esetben alkalmazza a következő konfigurációs módosításokat:

  • Használjon helyileg redundáns tárolási (LRS) szintet a Storage-fiókhoz.

  • Az AI Search konfigurálása egyetlen replikával a javasolt három replika helyett.

• Rendszeresen törölje a nem használt ügynököket és a hozzájuk kapcsolódó beszélgetéseket az SDK- vagy REST API-k használatával. Az elavult ügynökök és beszélgetések továbbra is tárterületet használnak, és növelhetik a költségeket az Azure Cosmos DB, a tárhelyszolgáltatás és az AI Search során.

• Kapcsolja ki a számítási feladathoz nem szükséges függő erőforrások funkcióit, például az alábbi funkciókat:

  • A szemantikai rangsoroló az AI Searchben

  • Az Azure Cosmos DB átjáró- és többrégiós írási képességei

• A régiók közötti sávszélesség-díjak elkerülése érdekében helyezzen üzembe Azure Cosmos DB, Storage és AI Search szolgáltatást ugyanabban a Azure régióban, mint a Foundry Agent Service.

• Kerülje a számítási feladatokra vonatkozó adatok áthelyezését ugyanabban a Azure Cosmos DB vagy AI Search-erőforrásokban, amelyeket a Foundry Agent Service használ. Bizonyos esetekben megoszthatja ezeket az erőforrásokat, hogy csökkentse a nem használt kapacitást az RU-kban vagy a keresési egységekben, ezáltal csökkentve a költségeket. Csak a megbízhatósági, biztonsági és teljesítménybeli kompromisszumok alapos kockázatértékelése után vegye figyelembe az erőforrás-megosztást.

Ügynöki ismeretek és eszközök

Az Foundry Agent Service nem meghatározott módon futtatja az ügynök logikáját. Meghívhat csatlakoztatott eszközöket, például tudáslekérdezési eszközöket, egyéni API-eszközöket vagy más ügynököket minden kéréshez, még akkor is, ha az eszköz nem releváns a felhasználói lekérdezés szempontjából. Ez a viselkedés szükségtelen hívásokat eredményezhet külső API-khoz vagy adatforrásokhoz, növelheti az egyes tranzakciók költségeit, és kiszámíthatatlan használati mintákat eredményezhet, amelyek bonyolítják a költségvetés előrejelzését.

A költségek szabályozásához és a kiszámítható viselkedés fenntartásához alkalmazza a következő stratégiákat:

• Csak azokat az eszközöket csatlakoztassa, amelyeket a legtöbb ügynökhívás valószínűleg használni fog. Kerülje a ritkán szükséges vagy az egyes hívásokhoz magas költségekkel járó eszközök csatlakoztatását, hacsak nem nélkülözhetetlenek.

• Tervezzen és finomítsa a rendszerkérést, hogy utasítsa az ügynököt a szükségtelen vagy redundáns külső hívások minimalizálására. A rendszerkérésnek arra kell irányítania az ügynököt, hogy csak a legrelevánsabb kapcsolatokat használja az egyes kérésekhez.

• Az Öntödei metrikák és naplók segítségével figyelheti az ügynök által meghívott eszközöket, azok gyakoriságát és a kapcsolódó költségeket. Rendszeresen tekintse át ezeket az adatokat a váratlan használati minták vagy költségnövekedések azonosításához, és szükség szerint módosítsa a rendszerkérést.

• Vegye figyelembe, hogy a nemdeterminisztikus meghívás megnehezítheti a költség-előrejelzést, különösen akkor, ha használatalapú API-kkal integrálódik. Ha kiszámítható költségekre van szüksége, fontolja meg a vezénylő önkiszolgáló üzemeltetését determinisztikus kód használatával.

Azure OpenAI-modellek

Modelltelepítések a Foundryben a MaaS-megközelítést használják. A költségek elsősorban a használattól vagy az előre kiosztott foglalástól függenek.

Az architektúra használati modell költségeinek szabályozásához használja az alábbi módszerek kombinációját:

• Ügyfelek vezérlése. A használati modellben az ügyfélkérések okozzák a legtöbb költséget, ezért önnek kell irányítania az ügynökök viselkedését.

  A szükségtelen használat csökkentése érdekében hajtsa végre a következő műveleteket:

  • Hagyja jóvá az összes modellfogyasztót. Ne tegye közzé a modelleket olyan módon, amely korlátlan hozzáférést tesz lehetővé.

  • Érvényesítse a tokenek számára vonatkozó korlátozásokat minden egyes válasz esetében. Amikor az alkalmazás választ generál, állítsa be a max_output_tokens értéket a modell által generált tokenek számának korlátozásához. truncation A beállítással szabályozhatja, hogy mennyi beszélgetési előzmény lép be a modell környezeti ablakába minden egyes turnön.

  • Optimalizálja a parancssori bemenet és a válasz hosszát. A hosszabb kérések több tokeneket használnak fel, ami növeli a költségeket. Olyan kérések, amelyek nem rendelkeznek elegendő szövegkörnyezettel, csökkentik a modell hatékonyságát. Tömör utasításokat hozhat létre, amelyek elegendő kontextust biztosítanak ahhoz, hogy a modell hasznos választ adjon. Győződjön meg arról, hogy optimalizálja a válaszhossz korlátját.

    Ez a vezérlési szint csak saját üzemeltetésű vezénylésben érhető el. Az Foundry Agent Service nem biztosít elegendő konfigurációt a funkció támogatásához.

• Válassza ki az ügynökhöz megfelelő modellt. Válassza ki a legkevésbé költséges modellt, amely megfelel az ügynök követelményeinek. Kerülje a magasabb költségű modellek használatát, hacsak nem nélkülözhetetlenek. A referencia-implementáció például egy GPT-5 sorozatú modellt használ, amely megfelel a forgatókönyv követelményeinek.

• A használat figyelése és kezelése. A Microsoft Cost Management és a modellhasználati metrikák használatával nyomon követheti a tokenhasználatot, költségvetéseket állíthat be, és riasztásokat hozhat létre az anomáliákhoz. Rendszeresen tekintse át a használati mintákat, és szükség szerint módosítsa a kvótákat vagy az ügyfélhozzáférést.

• Használja a megfelelő üzembehelyezési típust. Használjon használatalapú díjszabást a kiszámíthatatlan számítási feladatokhoz, és válassza a kiosztott átviteli kapacitást, ha a használat stabil és kiszámítható. A két lehetőség kombinálása megbízható alapkonfiguráció létrehozásakor.

• A játszótér használatának korlátozása. A nem tervezett gyártási költségek elkerülése érdekében korlátozza az Foundry játszótér használatát csak az előgyártási környezetekre.

• Gondosan tervezze meg a finomhangolást és a képgenerálást. Ezek a funkciók különböző számlázási modellekkel rendelkeznek. Óránként vagy kötegenként számlázzák őket. A használat ütemezése a számlázási időközökhöz igazodva és a pazarlás elkerülése érdekében.

Hálózati biztonsági erőforrások

Ez az architektúra Azure Firewall igényel kimenőforgalom-vezérlési pontként. A költségek optimalizálásához használja az alapszintű Azure Firewall, kivéve, ha a számítási feladatok többi összetevője speciális funkciókat igényel. A magasabb szintek költséggel járnak, ezért csak akkor használja őket, ha szüksége van a képességeikre. Az alapszintű szint kiválasztása előtt győződjön meg arról, hogy a korlátozások megfelelnek a számítási feladatnak. Az alapszintű szint korlátozza az átviteli sebességet, és korlátozott fenyegetésfelderítési képességekkel rendelkezik.

Ha a szervezet Azure célzónát használ, érdemes lehet megosztott tűzfalat és elosztott szolgáltatásmegtagadási (DDoS) erőforrásokat használni a költségek elhalasztásához vagy csökkentéséhez. A hasonló biztonsági és teljesítménykövetelményekkel rendelkező számítási feladatok kihasználhatják a megosztott erőforrások előnyeit. Győződjön meg arról, hogy a megosztott erőforrások nem jelentenek biztonsági vagy működési kockázatot. Megosztott erőforrásokat használó példáért tekintse meg az architektúra kezdőzóna-verzióját.

Felhőhöz készült Microsoft Defender

Az architektúra kapcsolódó erőforrásainak lefedéséhez használja az alábbi Cloud Workload Protection-csomagokat.

Terv	Előny
Szerverekhez készült Microsoft Defender	Észleli a biztonsági réseket, és figyeli a fájlintegritást, hogy megakadályozza a magas jogosultságú jump boxokat és az ügynököket abban, hogy fenyegetésvektorokká váljanak.
Microsoft Defender az App Service-hez	Naplókat, gazdagépeket és felügyeleti felületeket figyel a csevegés felhasználói felületének összetevőihez.
Azure Cosmos DB-hez készült Microsoft Defender	Figyeli az adatbázis-interakciókat a csevegési adatokhoz és az ügynökdefiníciókhoz való esetleges visszaélés vagy jogosulatlan hozzáférés jelei esetén.
Microsoft Defender AI-szolgáltatásokhoz	Riasztások az ügynökkérelmek és válaszok alapján történő feltörési kísérletekről vagy adatszivárgásról. Ha a szervezet Microsoft Purview használ, ez a csomag a Microsoft Purview adatbiztonságiállapot-kezelés AI-hoz (AI-hez készült DSPM) integrációját is biztosítja.

Ha a szervezet biztonsági információ- és eseménykezelési (SIEM) megoldást vagy Microsoft Purview használ, győződjön meg arról, hogy az ilyen adattárakba replikált ügyféladatok, például a kérések és válaszok olyan régióban találhatók, amely megfelel a számítási feladat adatelkülönülönülési követelményeinek.

Működési kiválóság

Az Operational Excellence azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben működtetik. További információ: Működési kiválóságitervezési felülvizsgálati ellenőrzőlistája.

Az alábbi működési kiválósági útmutató nem tartalmazza az előtérbeli alkalmazáselemeket, amelyek változatlanok maradnak az alapkonfigurációban magas rendelkezésre állású zónaredundáns webalkalmazás-architektúrával.

A kísérletezési, tesztelési és éles környezetek tervezésekor alakítson ki külön és elszigetelt Foundry-erőforrásokat, beleértve a függőségeket is.

Ügynöki számítástechnika

Microsoft kezeli az Foundry Agent Service REST API-k kiszolgáló nélküli számítási platformját és a vezénylés implementálási logikáját. Egy hosztolt ügynök a saját vezénylési kódját futtatja ezen a Foundry által felügyelt számítási környezeten. A saját üzemeltetésű orchestráció még nagyobb ellenőrzést biztosít a futtatási jellemzők és a kapacitás felett, de a platform folyamatos üzemeltetési feladatait közvetlenül Önnek kell kezelnie. Értékelje ki a megközelítése korlátait és felelősségeit, hogy megértse, mely második napi műveleteket kell végrehajtania az orchestration réteg támogatásához.

Az állapotkezelési felelősség a protokollkonfigurációt követi, nem a számítási megközelítést. Az ügynökök és az üzemeltetett ügynökök egyaránt támogatják a szolgáltatás által felügyelt beszélgetéseket, ahol a platform megőrzi a csevegési előzményeket, vagy az ügyfél által felügyelt beszélgetéseket, ahol a kód továbbviszi az állapotot. A saját üzemeltetésű orchesztráció mindig a saját állapotát kezeli. A csevegési előzmények és az ügynökkonfiguráció tartós tárolói minden esetben az előfizetésben találhatók, így Öné a tartósság, a biztonsági mentés és a helyreállítás.

Ügynök-interakciós SDK

Használja az Microsoft Agent Framework futtatókörnyezeti SDK-t az ügyfélalkalmazásban az üzenetek ügynököknek való küldéséhez, a beszélgetések kezeléséhez és a válaszok feldolgozásához. Az Agent Framework támogatja a C# és a Python. Ha az ügyfélalkalmazás javaScriptet vagy Java igényel, használja közvetlenül az Foundry SDK-t ezekhez a futtatókörnyezeti interakciókhoz.

Az Foundry SDK-t az ügyfél SDK-jának választásától függetlenül használhatja a platformkezelési műveletekhez. A központilag felügyelt ügynökdefiníciók létrehozása és verziószámozása CI-/CD-folyamatokban és IaC-folyamatokban, nem az ügyfélalkalmazás kódjában található.

Az Agent Framework és a Foundry integrálásáról további információt az Microsoft Agent Framework Foundry szolgáltató című témakörben talál.

Megfigyelés

Az alapvető architektúrához hasonlóan ez az architektúra diagnosztikai adatokat küld az összes szolgáltatásból a számítási feladat Log Analytics munkaterületére. A konfiguráció minden szolgáltatáshoz rögzíti az összes elérhető naplókategóriát, kivéve az App Service-t. Előfordulhat, hogy éles környezetben nem minden naplókategóriára van szükség. Előfordulhat például, hogy az App Service csevegési felhasználói felületi alkalmazása csak AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogs és AppServiceAuthenticationLogs szükséges. A naplóstreamek finomhangolása az üzemeltetési igényeknek megfelelően.

Értékelje ki az architektúrában található erőforrásokhoz tartozó egyéni riasztásokat, például az Azure Monitor alapszintű riasztásokat. Vegye figyelembe a következő riasztásokat:

• AI Search-riasztások
• AI-szolgáltatásokra vonatkozó riasztások
• Web Apps riasztások

A tokenek használatának monitorozása a modelltelepítések során. Ebben az architektúrában a Foundry az Application Insights integrációján keresztül követi nyomon a jogkivonatok használatát.

A jump boxok és a buildügynök virtuális gépei magas jogosultsági szintű helyen találhatók, amely közvetlen hálózati hozzáférést biztosít ezeknek a virtuális gépeknek az architektúra összes összetevőjének adatsíkjához. Győződjön meg arról, hogy ezek a virtuális gépek elegendő naplót bocsátanak ki ahhoz, hogy megjeleníthessék, hogy a felhasználók mikor férnek hozzá hozzájuk, ki fér hozzá hozzájuk, és hogy mit csinálnak rajtuk a felhasználók.

Ügynök verziószámozása és életciklusa

Kezelje az egyes ügynököket önállóan üzembe helyezhető egységként a csevegési számítási feladaton belül, kivéve, ha kifejezetten úgy tervezi meg az alkalmazást, hogy a futtatókörnyezetben dinamikusan hozzon létre és töröljön ügynököket. Ezek az ügynökök életciklus-kezelési követelményekkel rendelkeznek, hasonlóan a számítási feladat többi mikroszolgáltatásához.

A szolgáltatáskimaradások elkerülése érdekében az alábbi megközelítések végrehajtásával biztosítsa az ügynökök biztonságos és szabályozott üzembe helyezését:

• Ügynökök definiálása kódként. Mindig tárolja az ügynökdefiníciókat, kapcsolatokat, rendszerkéréseket és konfigurációs paramétereket a forrásvezérlőben. Ez a gyakorlat biztosítja a nyomon követhetőséget és a reprodukálhatóságot. Kerülje a nem követett módosításokat az Foundry portálon keresztül.

• Az ügynök üzembe helyezésének automatizálása. Használja a számítási feladat folyamatos integrációs és folyamatos üzembehelyezési (CI/CD) folyamatait. A Foundry SDK-k segítségével hozhat létre, tesztelhet és helyezhet üzembe ügynök-szoftvermódosításokat a hálózatra csatlakoztatott buildügynökök által.

  Részesítse előnyben az önállóan üzembe helyezhető ügynök-pipeline-eket kisebb, növekményes módosításokhoz. Ügyeljen azonban arra, hogy a folyamatok kellő rugalmasságot biztosítsanak ahhoz, hogy az alkalmazáskóddal együtt üzembe helyezhesse őket, ha összehangolt frissítésekre van szükség. A módszer támogatásához lazán párosítsa a csevegő felhasználói felület kódját és a csevegőügynököket, hogy az egyik összetevő módosítása ne igényeljen egyidejű módosításokat a másikon.

• Tesztelés éles környezet előtt. Ügynök viselkedésének, kéréseinek és kapcsolatainak ellenőrzése az előkészületi környezetekben. Automatizált és manuális tesztek kombinációjával észlelhetők a regressziók, a biztonsági problémák és az ügynök viselkedésének nem szándékos változásai.

  Az Foundry Agent Service-ben definiált ügynökök nem meghatározott módon viselkednek, ezért meg kell határoznia, hogyan mérheti és tarthatja fenn a kívánt minőségi szintet. Hozzon létre és futtasson egy tesztcsomagot, amely a valós felhasználói kérdésekre és forgatókönyvekre adott ideális válaszokat ellenőrzi.

• Ügynökök verzióinak kezelése és nyomkövetés. Rendeljen hozzá egyértelmű verzióazonosítókat az egyes ügynökökhöz. Tartson nyilvántartást az aktív ügynökverziókról és azok függőségeiről, például a modellekről, adatforrásokról és eszközökről. Helyezzen üzembe új ügynökverziókat a meglévő verziók mellett a felhasználók vagy munkamenetek fokozatos bevezetésének, visszaállításának és szabályozott migrálásának támogatásához.

  A Foundry natív módon támogatja a nem módosítható ügynökverziókat. Minden alkalommal, amikor módosít egy ügynökdefiníciót, a Foundry létrehoz egy új verzió pillanatképet, amely megőrzi a korábbi konfigurációt. Használja ezt a beépített verzióelőzményt naplózási nyomvonalakhoz és visszaállítási célokhoz.

  Az üzemeltetett ügynökök esetében a frissítés elküldése többet jelent, mint egy konfigurációs pillanatkép létrehozása. Először létre kell hoznia és fel kell töltenie egy konténerképet, és a Foundry-ügynök verziója erre hivatkozik. A visszagördülés csak az ügynökvégpont verzióválasztóját egy korábbi verzióra irányítja vissza, újraépítés és új lemezkép nélkül. A jelen szakasz korábbi, forráskövetési, tesztelési és CI/CD-eljárásai mind a parancssori, mind a üzemeltetett ügynökökre érvényesek. Mivel Ön írja egy üzemeltetett ügynök kódját, ez egy olyan plusz lépést jelent, amely a prompt ügynököknél nincs: egy helyi buildelési és hibakeresési ciklust ehhez a végrehajtható kódhoz, mielőtt az belépne ezekbe a megosztott pipeline-okba.

  Nem minden futtatókörnyezeti változathoz van szükség új verzióra. A strukturált bemenetek paraméterezik az ügynökdefiníciókat. Az ügyfél kéréskor adja meg a tényleges értékeket, így egyetlen ügynökverzió képes felhasználóspecifikus vagy környezetspecifikus konfigurációkat kiszolgálni újra üzembe helyezés nélkül.

  Megjegyzés:

  A strukturált bemeneteket az utasításszövegre korlátozhatja, például beszúrhat egy felhasználónevet a rendszer parancssorába. Kerülje az eszközvégpont-tulajdonságok, például az MCP-kiszolgáló URL-címeinek sablonozását. A sablonalapú eszközvégpontok lehetővé teszik, hogy a hívó ügyfél átirányítsa az ügynököt tetszőleges külső szolgáltatásokra futásidőben, ami aláássa az architektúra statikus szabályozási helyzetét. A tűzfal teljes tartománynevét engedélyező lista továbbra is blokkolja a nem jóváhagyott célhelyeket, de maga az ügynökdefiníció már nem dokumentálja, hogy az ügynök mely végpontokat szeretné elérni.

• Modellverziók rögzítése és szabályozása. Az ügynök viselkedése az általa meghívott modellverziótól függ, ezért a modelltelepítést tekintse a változáskezelési folyamat részének. Állítsa be az üzembe helyezés verziófrissítési beállítását úgy, hogy ne frissítse automatikusan. Ez a beállítás megakadályozza, hogy egy automatikus modellfrissítés módosítsa az ügynök válaszait, mielőtt ellenőrizné az új verziót a tesztkészlettel.

• Hozzáférés-vezérlés és felhasználói szintű adatelkülönítés kényszerítése. Ebben az architektúrában a csevegő felhasználói felület alkalmazásrétege a végfelhasználók és az ügynökök közötti hozzáférési határ. A Foundry projekt API privát végpontok mögött helyezkedik el, és nem érhető el közvetlenül a felhasználók számára. Az alkalmazáskódnak a Microsoft Entra ID-n keresztül kell hitelesítenie a végfelhasználókat, továbbá minden egyes beszélgetést és a hozzájuk tartozó adatokat azonosítania kell a hitelesített személyazonosság alapján.

  Ha projektszintű API-kat használ, akkor a Foundry-projektben Foundry User szerepkörrel rendelkező bármely identitás interakcióba léphet a projekt összes ügynökével. Az alkalmazás hitelesítési és engedélyezési rétege, nem pedig a Foundry RBAC projektje kényszeríti ki, hogy mely felhasználók férhetnek hozzá az ügynökökhöz és beszélgetésekhez. A munkamenet-kezelést úgy tervezheti meg, hogy megakadályozza a felhasználók közötti adathozzáférést, és alkalmazza a számítási feladat adatszabályozási és adatmegőrzési szabályzatait az alkalmazás által tárolt beszélgetési adatokra.

• Tervezze meg a fokozatos bevezetést és a visszaállást. A Foundry nem nyújt beépített támogatást az ügynökök kék-zöld vagy kanári telepítéseihez. Ha ezekre az üzembehelyezési mintákra vagy a felhasználók szabályozott migrálására van szükség az ügynökverziók között, implementáljon egy útválasztási réteget, például egy API-átjárót vagy egy egyéni útválasztót az ügynök API előtt. Ez az útválasztási réteg lehetővé teszi a forgalom növekményes áthelyezését az ügynökverziók között, figyelheti az effektust, és készenlétben teljes váltást hajthat végre.

• Az ügynök eltávolításának koordinálása. Az ügynökök eltávolításakor koordinálja a folyamatot az alkalmazás állapotkezelési és felhasználói élményre vonatkozó követelményeivel. Az aktív csevegések megfelelő kezelése. A számítási feladat működési követelményeitől függően áttelepítheti a munkameneteket, rögzítheti a felhasználókat a régi ügynökverzióban, vagy új munkameneteket kérhet a felhasználóktól.

Teljesítményhatékonyság

A teljesítményhatékonyság azt jelenti, hogy a számítási feladat hatékonyan képes méretezni a felhasználói igényeket. További információ: Teljesítményhatékonyságtervezési felülvizsgálati ellenőrzőlistája.

Ez a szakasz az AI Search, a modelltelepítések, az MCP-kiszolgáló alhálózata és a Foundry teljesítményhatékonyságával foglalkozik.

Teljesítményhatékonyság az AI-keresésben

Az Foundry Agent Service-ben nem szabályozhatja az indexek számára küldött konkrét lekérdezéseket, mert az ügynökök kód nélküliek. A teljesítmény optimalizálásához koncentráljon arra, hogy mit szabályozhat az indexben. Figyelje meg, hogy az ügynök általában hogyan keresi le az indexet, és útmutatást nyújt az AI Search teljesítményének elemzéséhez és optimalizálásához.

Ha az indexkiszolgáló-finomhangolás önmagában nem oldja meg az összes szűk keresztmetszetet, fontolja meg az alábbi lehetőségeket:

• Cserélje le az AI Search közvetlen kapcsolatát egy ön által birtokolt API-val való kapcsolatra. Ez az API képes implementálni az ügynök lekérési mintáira optimalizált kódot.

• A vezénylési réteg újratervezésével saját vezénylési kódot futtathat, akár üzemeltetett ügynökként az Foundry által felügyelt számításban, akár saját üzemeltetésű vezénylésként, hogy a lekérdezéseket saját vezénylőkódjában definiálhassa és optimalizálhassa.

Teljesítményhatékonyság a modelltelepítésekben

• Határozza meg, hogy az alkalmazásnak kiosztott átviteli sebességre van-e szüksége, vagy használhatja-e a megosztott (használati) modellt. A kiosztott átviteli sebesség fenntartott kapacitást és kiszámítható késést biztosít, amely támogatja a szigorú szolgáltatási szintű célkitűzésekkel (SLO-kkal) rendelkező éles számítási feladatokat. A fogyasztási modell legjobb erőfeszítés-alapú szolgáltatást biztosít, és zajos szomszédok hatásait tapasztalhatja.

• Figyelje a provisionált használat kezelését, hogy elkerülje a túlméretezést vagy alulméretezést.

• Válasszon ki egy olyan beszélgetési modellt, amely megfelel a következtetés késésére vonatkozó követelményeknek.

• A hálózati késés minimalizálása érdekében helyezzen üzembe modelleket ugyanabban az adatrégióban, mint az ügynökök.

Azure AI-ügynök teljesítménye

Azure AI-ügynökök kiszolgáló nélküli számítási háttérrendszeren futnak, amely nem támogatja az egyéni teljesítményhangolást. Az ügynöktervezéssel azonban javíthatja a teljesítményt:

• Csökkentse a csevegőügynökhöz csatlakoztatott eszközök számát. Minden további kapcsolat megnövelheti az ügynökhívások teljes futásidejét, mivel az ügynök minden kéréshez meghívhatja az összes konfigurált eszközt.

• Az Azure Monitor és az Application Insights használatával nyomon követheti az ügynökök hívási idejét, az eszközök késését és a hibaarányokat. Rendszeresen tekintse át ezeket a metrikákat a lassú eszközkapcsolatok azonosításához.

• A tervezési rendszer vezérli az ügynököt arra, hogy hatékonyan használja a kapcsolatokat. Utasíthatja például az ügynököt, hogy csak szükség esetén kérdezi le a földelő adateszközöket, vagy kerülje a redundáns eszközmeghívásokat.

• Figyelheti azokat a szolgáltatási korlátokat vagy kvótákat, amelyek hatással lehetnek a teljesítményre a csúcshasználat során. Figyelje meg az olyan szabályozási mutatókat, mint a HTTP 429 vagy 503 válaszok, annak ellenére, hogy a kiszolgáló nélküli számítás automatikusan skálázódik.

MCP-kiszolgáló alhálózati kapacitása

Ez az architektúra egy dedikált /24 alhálózatot foglal le, amely a(z) Microsoft.App/environments számára van delegálva, így később üzembe helyezhet egy belső Azure Container Apps, munkaterhelési profilokat használó környezetet, amely MCP-kiszolgálókat futtat az ügynökök képességeinek bővítéséhez.

Öntödei ügynök alhálózati kapacitása

Az Foundry-ügynök alhálózatának helyet kell adnia az ügynökinfrastruktúra számára. A(z) Microsoft.App/environments számára van delegálva, és /24 CIDR-tartományt kell használnia. Ez a méret tartalmazza az adatproxyt, az alhálózat-delegálás által fenntartott címeket. A Foundry minden projekthez egy dedikált adatproxyt helyez üzembe, és minden proxy a forgalommal együtt skálázódik, ezért minél több a projekt és minél nagyobb a terhelés, annál több alhálózati IP-cím fogy. Ha üzemeltetett ügynököket vezet be, a platform minden egyidejűleg aktív ügynök-munkamenetet a saját számításában futtat, amely egy alhálózati IP-címet használ. Az ügynök-munkamenet az a izolált tesztkörnyezet, amelyet a platform a felhasználó kéréseinek feldolgozására hoz létre. A platform az első kéréskor létrehoz egy ügynökmunkamenetet. Mivel ez az architektúra szolgáltatás által felügyelt beszélgetéseket használ, a platform az ügynök munkamenetét a beszélgetéshez köti, és később újra felhasználja. A különálló egyidejű beszélgetések külön ügynök-munkamenetet használnak fel a saját számításaikban. Az ügynök-munkamenetek csak a számítás során használnak alhálózati IP-címet, ezért az alhálózatot az egyidejűleg futó ügynök-munkamenetek maximális számához méretezi, nem pedig az üzembe helyezhető ügynökök számához.

Az új üzemeltetett ügynök változatának üzembe helyezése ideiglenesen további IP-címeket használ, mivel a régi és az új változatok párhuzamosan futnak a bevezetés során. Az alhálózatok méretezéséről és az IP-foglalásokról az Foundry Agent Service hálózatkezelésének részletes ismertetése című témakörben olvashat. Egy Foundry-erőforrás nem tudja megosztani az ügynökalhálózatát egy másik Foundry-erőforrással, bár ha a számítási feladathoz több Foundry-erőforrásra van szükség, ugyanazon a virtuális hálózaton osztozhatnak.

A forgatókönyv üzembe helyezése

A referencia-implementáció üzembe helyezéséhez és futtatásához kövesse az üzembe helyezési útmutatót a Foundry Agent Service csevegési alapkonfigurációjának implementálásában.

A referencia-implementáció csevegőfelületi alkalmazása alapszintű, és bemutatja, hogyan kommunikálhat az ügynökvégpontokkal. A csevegés felhasználói felületének fejlettebb felhasználói felületére vonatkozó példákért tekintse meg az Foundry-ügynök webalkalmazás-adattárát.

Közreműködők

Microsoft fenntartja ezt a cikket. A következő közreműködők írták ezt a cikket.

Fő szerzők:

• Rob Bagby | Fő tartalomfejlesztő – Azure minták és Gyakorlatok
• Chad Kittel | Vezető szoftvermérnök – Azure minták és Gyakorlatok

Egyéb közreműködők:

• Raouf Aliouat | Vezető szoftvermérnök
• Freddy Ayala | Felhőmegoldás-tervező
• Prabal Deb | Fő szoftvermérnök
• Ritesh Modi | Fő szoftvermérnök
• Ryan Pfalz | Vezető műszaki programmenedzser

A nem nyilvános LinkedIn profilok megtekintéséhez jelentkezzen be a LinkedIn.

Következő lépés

• Baseline Foundry csevegőarchitektúra egy Azure célzónában

Kapcsolódó erőforrások

• A számítási feladatok Azure
• Azure OpenAI-modellek
• Védőkorlátok és vezérlők
• AI-ügynökök vezénylési mintái

A vállalati csevegőalkalmazások lehetővé teszik az alkalmazottak számára, hogy természetes nyelvi beszélgetéseken keresztül kommunikálják az AI-ügynököket. Ezek az alkalmazások olyan nyelvi modelleket használnak, mint az OpenAI GPT-modellek és a nyílt forráskódú fejlesztői készletek, például az Microsoft Agent Framework. Ezek a csevegőalkalmazások általában a következő összetevőkből állnak:

• Egy nagyobb nagyvállalati alkalmazásba integrált csevegő felhasználói felület (UI). Más üzleti funkciók mellett beszélgetési élményt is biztosít a felhasználóknak.

• Olyan adattárak, amelyek a felhasználói lekérdezések szempontjából releváns, tartományspecifikus információkat tartalmaznak.

• A tartományspecifikus adatokra hivatkozó nyelvi modellek releváns válaszokat eredményeznek.

• Tartós vezénylési definíció vagy hosszú élettartamú ügynök, amely felügyeli az adatforrások, a nyelvi modellek és a felhasználó közötti interakciókat.

Ez a cikk egy alaparchitektúrát biztosít a vállalati csevegőalkalmazások Foundry és Azure OpenAI-modellek használatával történő létrehozásához és üzembe helyezéséhez. Ez az architektúra egy, az Foundry Agent Service szolgáltatásban tárolt parancssori ügynököt használ, de támogatja az üzemeltetett ügynököket is. A parancssori ügynököt deklaratív módon határozza meg az utasítások, a modell kiválasztása és a csatlakoztatott eszközök segítségével, és az Agent Service kezeli annak üzemeltetését. Az ügynök megkapja a felhasználói üzeneteket, majd lekérdezi az adattárakat a nyelvi modell alapadatainak lekéréséhez.

A chat felület a baseline Azure App Service webalkalmazás útmutatásait követi arról, hogyan telepítsünk biztonságos, zónaredundáns és magas rendelkezésre állású webalkalmazást az App Service-en. Ebben az architektúrában az App Service a Azure szolgáltatásplatform (PaaS) megoldásával kommunikál a magánvégpontokon keresztüli virtuális hálózati integráción keresztül. A csevegőfelület architektúrájában az App Service privát végponton keresztül kommunikál az ügynökkel. Ez az architektúra letiltja az Foundry portálhoz és az ügynökökhöz való nyilvános hozzáférést.

Fontos

Ez a cikk nem ismerteti az alapszintű App Service-webalkalmazás-architektúra összetevőit vagy architektúra-döntéseit. A csevegőfelületet tartalmazó webalkalmazás üzemeltetésére vonatkozó útmutatásért tekintse meg ezt a cikket.

Ez az architektúra a Foundry Agent Service standard ügynökbeállításával biztosítja a nagyvállalati szintű biztonságot, megfelelőséget és ellenőrzést. Ebben a konfigurációban saját (BYO) virtuális hálózatot hoz létre a hálózatelkülönítéshez, és saját Azure erőforrásokat a csevegés és az ügynök állapotának tárolásához. Az alkalmazásösszetevők privát végpontokon keresztül férnek hozzá Azure szolgáltatásokhoz, az ügynökök pedig privát hálózati kapcsolaton keresztül férnek hozzá a számítási feladatok tulajdonában lévő MCP-kiszolgálókhoz. Ez a megközelítés biztosítja, hogy az adatforgalom a számítási feladat virtuális hálózatán belül maradjon. Az ügynökök kimenő forgalma szigorúan az Azure Firewallon keresztül halad, ami kikényszeríti a kimenő forgalmi szabályokat.

Jótanács

A Foundry Agent Service referencia-implementációja egy alapszintű, végpontok közötti csevegési implementációt mutat be a Azure. Ez alapként szolgál az egyéni megoldások fejlesztéséhez, miközben az élesítési fázis felé halad.

Architecture

A diagram részletes Azure architektúrát mutat be az AI-megoldások üzembe helyezéséhez. A bal oldalon egy felhasználó Azure Application Gateway keresztül csatlakozik egy webalkalmazási tűzfalhoz, amely egy virtuális hálózat része. Ez az átjáró privát DNS-zónákhoz van csatolva, és Azure DDoS Protection védi. Az átjáró alatt a privát végpontok olyan szolgáltatásokhoz csatlakoznak, mint az App Service, a Azure Key Vault és a Azure Storage, amelyeket az ügyfélalkalmazások üzembe helyezéséhez használnak. Az App Service-t identitással kezelik, és három zónára terjed ki. Az Application Insights és Azure Monitor monitorozást biztosítanak, és Microsoft Entra ID kezeli a hitelesítést. A virtuális hálózat jobb oldalon több alhálózatot tartalmaz: App Service-integráció, privát végpont, Foundry-integráció, Azure AI-ügynökintegráció, Azure Bastion, jump box, buildügynökök és Azure Firewall. Minden alhálózat adott végpontokat vagy szolgáltatásokat üzemeltet, például tárolót, Foundryt, Azure AI Keresés és Azure Cosmos DB, amelyek privát végpontokon keresztül csatlakoznak. A hálózatból kimenő forgalom áthalad a Azure Firewall az internetes források eléréséhez. A jobb szélen egy külön mező jelöli a Foundryt, amely tartalmaz egy erőforrást és egy projektet. A felügyelt identitások csatlakoztatják az Foundry Agent Service-t az Foundry-projekthez, amely viszont hozzáfér egy Azure OpenAI-modellhez. A diagram számozott köröket használ a logikai folyamat jelzésére. Bemutatja, hogy a felhasználó hogyan lépi át a hálózatot, hogyan kommunikál a különböző végpontokkal, és végül hogyan csatlakozik az Foundry- és tárolási szolgáltatásokhoz, egyértelműen csoportosított és címkézett függőségekkel.

Töltse le az architektúra Visio fájlját.

Workflow

1. Egy alkalmazásfelhasználó csevegőfelülettel kommunikál. A kérések Azure Application Gateway haladnak át. Azure Web Application Firewall ellenőrzi ezeket a kéréseket, mielőtt továbbítanák azokat a háttérbeli App Service-példánynak.

2. Amikor a webalkalmazás felhasználói lekérdezést vagy utasítást kap, meghívja a célként létrehozott ügynököt. A webalkalmazás az ügynökvégpontokkal az Microsoft Ügynök-keretrendszeren keresztül kommunikál. A keretrendszer meghívja a kiszolgálóoldali ügynökdefiníciót az OpenAI-kompatibilis Responses API-val. Az ügyfél HTTP-hívása ugyanaz marad, függetlenül attól, hogy az ügynök melyik támogatott modellt használja. A webalkalmazás privát végponton keresztül hívja meg az ügynököt, és a felügyelt identitás használatával hitelesíti az Foundryt.

3. Az ügynök a rendszerkérés utasításai alapján dolgozza fel a felhasználó kérését. A felhasználó szándékának teljesítéséhez az ügynök egy konfigurált nyelvi modellel és csatlakoztatott eszközökkel rendelkezik. Ebben az architektúrában az eszközök közé tartozik az adatok földelésére szolgáló Azure AI Keresés eszköz és a webes adatok webes keresőeszköze.

4. Az ügynök egy privát végponton keresztül csatlakozik az Azure AI Keresés szolgáltatáshoz az AI Search eszközt használva a magánhálózaton belül.

5. A legtöbb külső eszköz, például a nyilvános MCP-kiszolgálók vagy az egyéni API-eszközök felé irányuló kérelmek az Azure Firewallon keresztül haladnak ellenőrzés és a kimenő forgalomra vonatkozó szabályzatok érvényesítése céljából. A privát MCP-kiszolgálókra vagy API-kra irányuló kérések a virtuális hálózaton belül maradnak.

6. Az ügynök csatlakozik a konfigurált nyelvi modellhez, és átadja a releváns kontextust.

7. Mielőtt az ügynök visszaadja a választ a felhasználói felületre, megőrzi a kérést, a létrehozott választ és az eszközhívás részleteit a beszélgetésben. Ez a Azure Cosmos DB tárolt beszélgetési objektum a teljes interakciós előzményt beszélgetési elemekként (üzenetek, eszközhívások és eszközkimenetek) tárolja. Ez az előzmény támogatja a környezetérzékeny interakciókat, és lehetővé teszi, hogy a felhasználók a korábbi környezet elvesztése nélkül folytatják a beszélgetéseket az ügynökkel.

   A Foundry API-k támogatják a több egyidejű, környezettől elkülönített beszélgetést kezelő felhasználói élmények fejlesztését.

Components

Ez az architektúra az alapvető Foundry-csevegési referenciaarchitektúrára épül. Ez az architektúra több Azure szolgáltatást vezet be a megbízhatóságra, a biztonságra és a működési vezérlésre vonatkozó vállalati követelmények kezelésére. Az alábbi összetevők mindegyike egy adott szerepet játszik egy éles vállalati csevegési megoldásban:

• A Foundry Agent Service egy natív felhőbeli futtatókörnyezet, amely lehetővé teszi az intelligens ügynökök biztonságos és autonóm működését. Ebben az architektúrában az Foundry Agent Service egy felügyelt futtatókörnyezetet biztosít a parancssori ügynökök számára, és integrálható Azure szolgáltatásokkal. A következő feladatokat ellátó ügynököket üzemelteti és kezeli:

  • Felhasználói kérések feldolgozása
  • Eszközökre és más ügynökökre irányuló hívások vezénylésére
  • Tartalombiztonság kényszerítése
  • Integrálás vállalati identitással, hálózatkezeléssel és megfigyelhetőséggel

  A standard ügynökbeállítás biztosítja a hálózatelkülönítést, és szabályozza az adattárolást. Dedikált Azure erőforrásokat biztosít az ügynökállapothoz, a csevegési előzményekhez és a fájltároláshoz, de a Foundry Agent Service kizárólag ezeket kezeli. A számítási feladat más alkalmazásösszetevői nem használhatják ezeket a szükséges erőforrásokat.

  • Azure Cosmos DB NoSQL egy globálisan elosztott dokumentumadatbázis-szolgáltatás. Ebben az architektúrában az előfizetésén belül üzemeltetik a számítási feladat memóriaadatbázisát, az úgynevezett enterprise_memory. Ez az adatbázis tárolja az ügynök működési állapotát, beleértve a csevegéseket és az ügynökdefiníciókat. Ez a kialakítás biztosítja, hogy a csevegési előzmények és az ügynökkonfiguráció elkülönítése, naplózása és kezelése az adatszabályozási követelményeknek megfelelően történjen. Az Foundry Agent Service kezeli az adatbázist, gyűjteményeit és adatait.

  • Azure Storage strukturálatlan adatok felhőalapú tárolási szolgáltatása. Ebben az architektúrában dedikált tárterületet biztosít a csevegések során feltöltött fájlokhoz. A fiók előfizetésben való üzemeltetése részletes hozzáférés-vezérlési, naplózási képességeket és az adattárolási vagy adatmegőrzési szabályzatoknak való megfelelést biztosítja. Az Foundry Agent Service kezeli a tárolók és az adatok életciklusát ezeken a tárolókon belül.

  • Az AI Search egy felügyelt keresési megoldás, amely keresési képességeket biztosít. Ebben az architektúrában az Foundry Agent Service az AI Search használatával tárolja az ügynökkel folytatott beszélgetések során a Fájlkeresés eszközzel feltöltött fájlok kereshető, darabolt indexét. Az AI Search emellett adattömböt tartalmazó statikus fájlokat is tárol, amelyeket tudásforrásként ad hozzá az ügynök létrehozásakor. Ezek a fájlok az összes ügynökhívásban elérhetők maradnak. Az Foundry Agent Service kezeli az indexet, sémát és adatokat, és saját adattömbkezelési stratégiát és lekérdezési logikát használ.

• Az Application Gateway egy webes forgalom terheléselosztó és alkalmazáskézbesítési vezérlő. Ebben az architektúrában biztonságos, skálázható belépési pontként szolgál a csevegőfelületre irányuló ÖSSZES HTTP- és HTTPS-forgalomhoz. A Transport Layer Security (TLS) leállítását és útvonalalapú útválasztást is biztosít. Az Application Gateway elosztja a kérelmeket a rendelkezésre állási zónák között, ami támogatja a webalkalmazási szint magas rendelkezésre állását és teljesítményét. A háttérrendszere az alkalmazáskódot üzemeltető App Service-példány.

  • Azure Web Application Firewall egy natív felhőszolgáltatás, amely megvédi a webalkalmazásokat a gyakori webes biztonsági résektől. Ebben az architektúrában integrálva van az Application Gatewayrel, hogy megvédje a csevegés felhasználói felületét a gyakori webes biztonsági résekkel és támadásokkal szemben. Ellenőrzi és szűri a HTTP-kéréseket, amely biztonsági réteget biztosít a nyilvános alkalmazások számára.

  • Azure Key Vault egy felhőszolgáltatás, a titkos kulcsok, kulcsok és tanúsítványok biztonságos tárolására és elérésére. Ebben az architektúrában biztonságosan tárolja és kezeli az Application Gateway által igényelt TLS-tanúsítványokat. A Key Vault központosított tanúsítványkezelése támogatja az automatizált rotációt, a naplózást és a szervezeti biztonsági szabványoknak való megfelelést. Ez az architektúra nem igényel tárolt kulcsokat vagy más titkos kulcsokat.

• Azure Virtual Network a magánhálózatok alapvető építőeleme Azure. Ebben az architektúrában minden összetevő számára biztosít hálózati elkülönítést, hogy megfeleljen a biztonsági és megfelelőségi követelményeknek. Amikor erőforrásokat helyez el egy privát virtuális hálózatban, szabályozhatja a kelet-nyugati és az észak-déli forgalmat, szegmentálást kényszeríthet ki, magánforgalomban tarthatja a forgalmat, és ellenőrizheti a bejövő és kimenő folyamatokat.

• Azure Private Link egy hálózati szolgáltatás, amely privát kapcsolatot biztosít egy virtuális hálózatról Azure PaaS-szolgáltatásokhoz. Ebben az architektúrában az összes PaaS-szolgáltatást, például a Azure Cosmos DB, a Storage, az AI Search és az Foundry Agent Service szolgáltatást magánvégpontokon keresztül csatlakoztatja a virtuális hálózathoz. Private Link segít biztosítani, hogy minden adatforgalom a Azure gerincén maradjon, ami kiküszöböli a nyilvános internetnek való kitettséget, és csökkenti a támadási felületet.

• Azure Firewall egy felügyelt, felhőalapú hálózati biztonsági szolgáltatás. Ebben az architektúrában a virtuális hálózat összes kimenő (kimenő) forgalmát ellenőrzi és szabályozza. Teljes tartománynevet (FQDN)-alapú szabályokat is kikényszerít, így csak a jóváhagyott célhelyek érhetők el. Ez a konfiguráció segít megelőzni az adatok kiszivárgását, és teljesíteni a hálózati biztonságra vonatkozó követelményeket.

• A Azure DNS a névfeloldást biztosító dns-tartományok üzemeltetési szolgáltatása. Ebben az architektúrában a virtuális hálózathoz társított privát DNS-zónákat biztosít. Kezeli a névfeloldást magánvégpontok esetén, amely biztosítja, hogy a szolgáltatásközi kommunikáció magánhálózati IP-címeket használjon és a hálózat határain belül maradjon.

• Azure Storage strukturálatlan és strukturált adatok felhőalapú tárolási szolgáltatása. Ebben az architektúrában támogatja a biztonságos, automatizált üzembehelyezési munkafolyamatokat, és elkülöníti az alkalmazás-összetevőket a számítási erőforrásoktól. A webalkalmazás kódját ZIP-fájlként tárolja az App Service-be való üzembe helyezéshez.

Modell és eszköz kiválasztása

Az Foundry Agent Service nem működik az Foundry-modellkatalógusban szereplő összes modellel. A katalógus felsorolja azokat a modelleket, amelyeket az Foundry-platform üzembe helyezhet, de a parancssori ügynök csak olyan részhalmazt használhat, amelyet az Foundry Agent Service ellenőriz ügynökhasználatra.

Mielőtt egy modell mellett dönt, győződjön meg arról, hogy telepítheti a saját Foundry-régiójában, és hogy a Foundry Agent Service támogatja. Az Foundry portálon tallózhat az ügynök által támogatott modellekre szűrt modellkatalógusban , vagy programozott módon lekérdezheti egy régió modelljeit.

az cognitiveservices model list --location <location> --query "[?model.capabilities.agentsV2=='true']"

A Foundry Agent Service által támogatott modell nem feltétlenül támogatja minden ügynökképességet. Az eszközök rendelkezésre állása a modelltől és az üzembe helyezési régiótól is függ. Ebben az architektúrában az ügynök az AI Search eszközt és a webes keresőeszközt használja, és nem minden támogatott modell működik az egyes eszközökkel. A teljes kompatibilitási mátrixért tekintse meg az eszköztámogatást régió és modell szerint.

Az Foundry Agent Service nem mindig utasít el nem támogatott kombinációt az ügynök definiálásakor. Amikor a REST API-val hoz létre egy parancssori ügynököt, egy nem támogatott modell vagy eszköz kiválasztása átadhatja az ügynök létrehozását, majd váratlan viselkedést vagy futásidejű hibát okozhat, amikor az ügynök meghívja a modellt vagy eszközt.

Alternatives

Ez az architektúra több összetevőt is tartalmaz, amelyeket más Azure szolgáltatásokkal vagy megközelítésekkel helyettesíthet a számítási feladat funkcionális és nem funkcionális követelményeitől függően. Fontolja meg a következő alternatívákat és kompromisszumoket.

Csevegés orchesztrációja

Jelenlegi megközelítés: Ez az architektúra az Foundry Agent Service-t használja az ügynök végrehajtási folyamatainak végrehajtására, beleértve a földelési adatok csatlakoztatott eszközökkel való lekérését, az AI-modellek meghívását, valamint az ügynök rendszerszintű utasításai és beszélgetési előzményei alapján a konzisztens válasz viselkedésének kikényszerítését. A Foundry Agent Service kód nélküli, nemdeterminista vezénylést biztosít a beszélgetési AI-számítási feladatokhoz. Kezeli a csevegési kérelmeket, a beszélgetés állapotát, az eszközhívást, a tartalombiztonságot és az identitással, a hálózatkezeléssel és a megfigyelhetőséggel való integrációt. A szolgáltatás támogatja a beszélgetési környezet és az ügynökállapot megőrzését egy előre definiált adatmodellen keresztül, amelyet az előfizetésen belüli adatbázisba helyeznek üzembe.

Alternatív megközelítés: Egyéni végrehajtási logikát implementálhat egy üzemeltetett ügynökben, amely a saját determinisztikus, kódalapú ügynök-vezénylési logikája, amely egy Tárolóban fut az Foundry Agent Service szolgáltatásban. Egy üzemeltetett ügynöknek implementálnia kell az Foundry futtatókörnyezeti szerződését , hogy a platform meghívhassa azt. A szerződést SDK-adapterrel vagy a szerződés saját implementálásával teljesíti, és az ügynök saját logikáját egy olyan keretrendszerrel hozza létre, mint az Ügynök-keretrendszer. Ezt a kódot tárolórendszerképként kell üzembe helyeznie, amelyet ön hoz létre és küld le Azure Container Registry saját tulajdonában és irányításában.

Ebben az esetben az ügynökkód kezeli a vezénylést, és hogy a platform mit kezel, attól függ, hogy az ügynök milyen protokollt tesz közzé.

• A Válaszok protokollal a platform kezeli a beszélgetések előzményeit és a munkamenetek életciklusát, a kód pedig növeli a szerződés végrehajtási viselkedését.

• Az Invocations protokoll használatával a kód közvetlenül kezeli a munkamenet állapotát, és a platform nem biztosít beszélgetési előzményeket.

Minden üzemeltetett ügynök egy dedikált végpontútvonalat kap az üzembe helyezéskor, amely saját útválasztási, hozzáférés-vezérlési és monitorozási hatókörrel rendelkezik.

Az üzemeltetett ügynököket vegye figyelembe a parancssori ügynökök helyett, ha a számítási feladathoz az alábbi képességek közül legalább egy szükséges:

• Az Foundry Agent Service által nem támogatott modellek használata vagy a szolgáltatás által nem közzétett eszközökkel való integráció

• Az ügynök végrehajtási útvonalának részletes, determinisztikus vezérlése, beleértve az explicit vezénylési mintákat, a külső rendszereket vagy eszközöket, a gyors tervezést, a több ügynökkel való kapcsolatot vagy az emberi beavatkozást a cikluson belül

• Összetett üzleti folyamatokat kezelő meglévő kódbázisok vagy kódtárak újrafelhasználása

• Ügynökkód naplózása, ellenőrzése vagy tanúsítása biztonsági, megfelelőségi vagy szabályozási célból

• Ügynökönkénti identitás és végpontelkülönítés, így az ügynökök különböző projektekbe való elkülönítése nélkül hatókörbe helyezheti a minimális jogosultságú hozzáférést, a hozzáférés-vezérlést és a figyelést az egyes ügynökök között.

• Az ügynök futásidejének finomhangolása, beleértve az egyes ügynök-munkamenetek tesztkörnyezetéhez tartozó processzor- és memóriafoglalást

• A Foundry Agent Service natív beszélgetési állapota mellett egy külön adatbázisban tárolt kiterjesztett memória is található.

A üzemeltetett ügynökök továbbra is az Foundry által felügyelt számítási eszközökön futnak, így a platform továbbra is kezeli a skálázást és az alapvető futtatókörnyezetet. A saját üzemeltetésű orchesztráció egy további lépés, amelyben Ön a vezénylési réteget az Ön által üzemeltetett számítási infrastruktúrán futtatja, a Foundry Agent Service-en kívül. Saját infrastruktúra futtatásakor Ön felel a futtatókörnyezet minden jellemzőjéért, kapacitásáért és biztonságáért.

Alkalmazásréteg összetevői

Kurzív megközelítés: A csevegőfelületi felület webhelye az App Service Web Apps szolgáltatásában található, amely egy felügyelt, méretezhető platformot biztosít a webalkalmazásokhoz. Web Apps natív módon integrálható Azure hálózati és biztonsági funkciókkal.

Alternatív megközelítés: Az alkalmazásszint üzemeltetéséhez használhat más Azure felügyelt számítási platformokat, például Azure Container Apps vagy Azure Kubernetes Service (AKS).

Fontolja meg ezt az alternatívát, ha a számítási feladat megfelel az alábbi feltételek bármelyikének:

• Egy másik számítási platform jobban támogatja bizonyos használati eseteket, és a szolgáltatások ezen a platformon való áthelyezése javíthatja a költséghatékonyságot és egyszerűsítheti a műveleteket

• Az alkalmazás kifinomultabb skálázást, vezénylést vagy egyéni hálózatkezelést igényel

Az App Service továbbra is a webalkalmazások és API-k egyszerűsége szempontjából előnyben részesített lehetőség.

Alapadatok (tudástár) tárolása

Jelenlegi megközelítés: Ez az architektúra az AI Search-t használja elsődleges adattárként a tudás alapozásához. Az AI Search vektorkeresési és szemantikai rangsorolási képességeit használja.

Alternatív megközelítés: Más adatplatformokat is használhat a tudás megalapozásához, például Azure Cosmos DB, Azure SQL Database vagy egyéb online tranzakciófeldolgozási (OLTP-) adattárakat. Az adatplatform a meglévő adattulajdontól, az adatfrissítési követelményektől és a lekérdezési követelményektől függ.

Fontolja meg ezt az alternatívát, ha a számítási feladat megfelel az alábbi feltételek bármelyikének:

• A meglévő tranzakciós vagy üzemeltetési adatbázisban már kezelheti alapismereteit

• Szüksége van többmodelles vagy SDK-támogatásra, amely nem érhető el az AI Search funkcióban.

• Speciális adatforrásokkal vagy örökölt rendszerekkel kell integrálnia

A vektoros keresés általában jellemző a lekérés-kiegészítésű generálásra (RAG), de nem mindig szükséges. További információ: A Azure szolgáltatás létrehozása vektorkereséshez. Mielőtt kiválaszt egy adattárat, értékelje ki a számítási feladat adathozzáférési mintáit, késését és méretezhetőségét.

Ügyfél által felügyelt csevegési előzmények

Kurzív megközelítés: Ez az architektúra szolgáltatás által felügyelt beszélgetéseket használ az Foundry Agent Service-ben a csevegési előzmények Azure Cosmos DB való megőrzéséhez. A szolgáltatás többfordulós és munkamenetek közötti folytonosságot biztosít anélkül, hogy az ügyfélnek kezelnie kellene az állapotot, és automatikusan kontextusként biztosítja a teljes beszélgetést a válaszgenerálás során.

Alternatív megközelítés: Az ügyfélalkalmazás a beszélgetési előzményeket kezeli ahelyett, hogy delegálja azt az ügynökszolgáltatásba. Minden válasz állapotmentesen jön létre, és az ügyfél a korábbi válaszok kimeneti elemeit a későbbi kérések bemeneteként továbbítja.

Fontolja meg az ügyfél által felügyelt beszélgetések előzményeit, ha a számítási feladat megfelel az alábbi feltételek valamelyikének:

• Nulla adatmegőrzés. A megfelelőségi vagy szabályozási követelmények tiltják a beszélgetési tartalmak kiszolgálóoldali megőrzését.

• Egyéni környezet ablakvezérlője. Mielőtt elküldené őket a modellnek, szelektíven bele kell foglalnia, ki kell zárnia, össze kell foglalnia, vagy helyileg le kell tömörítenie a korábbi köröket.

• Több, független munkamenet-szemantikával rendelkező UX-csatorna. Ugyanazt az ügynököt különböző alkalmazások (webes, mobil, hang) használják, amelyek mindegyikének saját munkamenet-kezelési, tárolási és adatmegőrzési szabályzatra van szüksége.

Ez a megközelítés az állapotmegőrzés, a környezetkezelés, a beszélgetési adatok szabályozása és a munkamenet-elkülönítés felelősségét az alkalmazáskódra helyezi át. Mivel a beszélgetési állapot egy saját adattárban található, saját biztonsági mentési, replikációs és visszaállítási folyamatokat kell alkalmaznia.

Figyelembe kell venni a környezetablak korlátait és a HTTP-kérések hasznos adatméretének növelését a beszélgetési elemek továbbítása során. A többfordulós megbízhatóság érdekében használjon állandó tárolót, például Azure Cosmos DB vagy a meglévő alkalmazásadatbázist a memóriabeli állapot helyett.

Előre definiált ügynök vagy dinamikusan létrehozott ügynök

Jelenlegi megközelítés: A referencia-implementáció egy statikusan definiált ügynököt használ, amely a Foundryben mikroszolgáltatásként van üzembe helyezve. Az ügynök logikája és adatforrásai az üzembe helyezéskor vannak konfigurálva, és a következő alkalmazáskiadásig változatlanok maradnak. Ez a megközelítés akkor működik jól, ha az ügynökök viselkedése és az adatforrások stabilak és vezérelve vannak a DevOps-folyamatokon keresztül.

Alternatív megközelítés: Az Foundry SDK-k használatával dinamikusan hozhat létre vagy módosíthat ügynököket futásidőben. Ez a módszer lehetővé teszi, hogy az alkalmazás igény szerint példányosítsa az ügynököket, módosítsa a rendszerkéréseket, vagy újrakonfigurálja a kapcsolatokat a felhasználói környezet vagy az üzleti logika alapján.

Vegye figyelembe a dinamikus ügynököket, ha a számítási feladathoz a következő képességek szükségesek:

• Személyre szabott ügynöki viselkedés vagy adatforrások minden felhasználóhoz vagy munkamenethez

• Az ügynökkonfiguráció gyakori vagy programozott módosítása

• Rövid élettartamú, környezetspecifikus ügynöktámogatás speciális felhasználói élményekhez

A dinamikus ügynökkezelés növeli a rugalmasságot, de az életciklus-kezelés terheit is növeli. Győződjön meg arról, hogy megfelelő vezérlőkkel rendelkezik az ügynökök létrehozásához, módosításához és törléséhez.

Válassza ki az ügynöki megközelítést, amely megfelel a munkaterhelés felhasználói élmény követelményeinek.

Egyetlen ügynök vagy többügynökös orkesztráció

Jelenlegi megközelítés: Ez a referenciaarchitektúra egyetlen ügynököt használ, amely hozzáfér az összes szükséges eszközhöz a felhasználói interakciók hatékony kezeléséhez.

Alternatív megközelítés: Több specializált ügynököt vezényelhet, ahol minden ügynök adott tartományokra összpontosít, különböző modelleket használ, vagy különböző eszközökhöz fér hozzá.

Fontolja meg a többtényezős megközelítést, ha a számítási feladat a következő jellemzőket mutatja:

• A kérelmek több szakterületre is kiterjednek, például pénzügyi elemzésre, jogi felülvizsgálatra és műszaki megvalósításra. A specializált ügynökök mélyebb, pontosabb válaszokat nyújtanak a saját tartományaikban.

• Az információkhoz eltérő engedélyszintek szükségesek. Egy emberierőforrás-ügynök hozzáférhet az alkalmazottak adataihoz, míg az ügyfélszolgálati ügynök csak a termékinformációkhoz fér hozzá. A többtényezős architektúrák az ügynök szintjén támogatják a részletes biztonsági határokat.

• A különböző lekérdezési interakciók különböző modellek előnyeit élvezhetik. Az egyszerűsített modell egyszerű kérdéseket kezel, míg egy hatékonyabb modell összetett érvelési feladatokat dolgoz fel. Ez a módszer a költségeket és a késést is optimalizálja.

• A csevegési élmény az üzleti folyamatok előtereként szolgál, amelyek szekvenciális vagy párhuzamos lépéseket igényelnek, és amelyekhez különböző szakemberekre van szükség.

A többtényezős megközelítések koordinációs összetettséghez és nagyobb késéshez vezetnek az ügynökök közötti kommunikáció miatt. A szigorú hozzáférés-elkülönítési követelmények nélküli, jól definiált forgatókönyvek esetében egyetlen ügynök, amely egyetlen modellt és megfelelő eszközöket használ, megfelel a követelményeknek.

Az Foundry Agent Service szabványos protokollokkal támogatja az ügynökök külső ügynökökhöz és eszközökhöz való csatlakoztatását. A Model Context Protocol (MCP) kiszolgálókon üzemeltetett eszközökhöz és más ügynökökhöz az Ügynök–Ügynök (A2A) végpontokon keresztül csatlakozhat. A nyilvános MCP-kiszolgálóvégpontok tűzfalszabályokat igényelnek a kimenő forgalomhoz. A privát MCP-kiszolgálóvégpontokhoz a standard ügynök beállítása szükséges privát hálózatkezeléssel és dedikált alhálózattal. Konfigurálja a megfelelő hitelesítést minden végponthoz.

További információ a több koordinált ügynök implementálásáról: AI-ügynökök vezénylési mintái. Ez a cikk a szekvenciális, egyidejű, csoportos csevegési, átadási és magentic vezénylési megközelítéseket ismerteti. A Foundry Agent Service-ben implementálhat néhány mintát. Más mintákhoz saját üzemeltetésű vezénylésre van szükség egy olyan SDK-val, mint az Agent Framework.

Megfontolások

Ezek a szempontok implementálják a Azure Well-Architected-keretrendszer alappilléreit, amelyek a számítási feladatok minőségének javítása érdekében használható vezérelvek. További információ: Well-Architected Framework.

Alkalmazza ezt az architektúrát és a AI számítási feladatokat Azure tervezési útmutatóra a számítási feladat tervezési fázisában.

Reliability

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információ: Megbízhatóságitervezési felülvizsgálati ellenőrzőlistája.

Az Alapszintű App Service-webalkalmazás-architektúra a zónaredundanciára összpontosít a főbb regionális szolgáltatások esetében. A rendelkezésre állási zónák fizikailag különálló helyek egy régión belül, amelyek redundanciát biztosítanak, amikor két vagy több példányt helyez üzembe rajtuk. Ha az egyik zóna állásidőt tapasztal meg, előfordulhat, hogy a régió többi zónája érintetlenek maradhatnak. Az architektúra Azure szolgáltatások példányait és konfigurációit is elosztja a rendelkezésre állási zónák között. További információért lásd: Zónaredundáns, magas rendelkezésre állású alap webalkalmazás.

Ez a szakasz az App Service alaparchitektúrájában nem szereplő összetevők, különösen a Foundry és az AI Search megbízhatóságát ismerteti.

Zónaredundancia az orchestration rétegben

A vállalati üzemelő példányok általában zónaredundanciát igényelnek a zónaszintű hibák miatti szolgáltatáskimaradás kockázatának minimalizálása érdekében. A Azure a zónaredundancia azt jelenti, hogy olyan erőforrásokat használ, amelyek támogatják a a rendelkezésre állási zónákat és legalább három példányt helyeznek üzembe, vagy platformszintű redundanciát aktiválnak, ha a közvetlen példányvezérlés nem érhető el.

Ebben az architektúrában a Foundry üzemelteti az Foundry Agent Service képességet. Az ügynök megbízhatósága a Foundry Agent Service függőségeinek rendelkezésre állásától függ, amelyek az Azure Cosmos DB, a Storage és az AI Search. A Foundry Agent Service kezeli a szolgáltatásokon belüli adatokat, de ön konfigurálja azok megbízhatóságát az előfizetésében.

A vezénylési réteg zónaredundanciáinak eléréséhez kövesse az alábbi javaslatokat:

• Támogassa a zónaredundanciát az Azure Cosmos DB NoSQL-fiókban. Ez a konfiguráció több zónában biztosítja a szinkron adatreplikálást, ami csökkenti az adatvesztés vagy az állásidő kockázatát egy zóna meghibásodása esetén.

  Fontolja meg a globális eloszlást is, hogy enyhítse az Azure Cosmos DB belüli regionális kimaradásokat.

• Használjon zónaredundáns tárolót (ZRS) a Storage-fiókjához. A nagyobb rugalmasság érdekében használjon georedundáns tárolást (GZRS), amely egyesíti a zónákat és a regionális redundanciát.

• Konfigurálja az AI Search-példányt legalább három replikával. Ez a konfiguráció biztosítja, hogy a szolgáltatás a replikákat a régió egyedi zónái között ossza el.

Ha az ügynök integrálva van más számítási feladatokra vonatkozó függőségekkel, például egyéni eszközkapcsolatokkal vagy külső adatforrásokkal, győződjön meg arról, hogy ezek a függőségek megfelelnek a rendelkezésre állási és redundanciakövetelményeknek. Bármely egyzónás vagy nem redundáns függőség alááshatja a vezénylési réteg általános megbízhatóságát.

Az Foundry portál, az adatsík API-k és az Öntödei ügynök szolgáltatás képessége nem biztosít közvetlen vezérlőket a zónaredundanciához.

Megbízhatóság az Foundry-modell üzemeltetésében

Az Foundry szolgáltatásként (MaaS) üzemeltetett modelleket kínál számos üzembe helyezési lehetőséggel. Ezek a lehetőségek elsősorban a kvóta- és átviteli sebesség kezelését támogatják, nem pedig a régión belüli hagyományos magas rendelkezésre állást. A standard modelltelepítések egyetlen régióban működnek, és nem támogatják a rendelkezésre állási zónákat. A több adatközpont rendelkezésre állásának eléréséhez globális vagy adatzónás modell üzembe helyezését kell használnia.

Vállalati csevegési forgatókönyvek esetén helyezzen üzembe egy kiépített adatzónát és az adatzóna standard modelljét is. Konfigurálja a túlcsordulást a felesleges forgalom vagy hibák kezelésére. Ha a számítási feladat nem igényel alacsony késést vagy szigorú földrajzi adatok tartózkodási helyét és feldolgozását, használja a globális üzembe helyezéseket a maximális rugalmasság érdekében.

Az Foundry nem támogatja a fejlett terheléselosztási vagy feladatátvételi mechanizmusokat, például a körforgásos útválasztást vagy az áramkör-megszakítást a modelltelepítésekhez. Ha részletes redundanciát és feladatátvételi vezérlést igényel egy régión belül, a modell hozzáférési logikáját a felügyelt szolgáltatáson kívül kell üzemeltetnie. Létrehozhat például egy egyéni átjárót Azure API Management használatával. Ez a megközelítés lehetővé teszi egyéni útválasztási, állapot-ellenőrzési és feladatátvételi stratégiák implementálását. Ez azonban növeli a működési összetettségét, és az összetevő megbízhatóságáért a csapatra hárítja a felelősséget.

Az átjáró-előtérbeli modelleket egyéni API-alapú eszközökként is elérhetővé teheti az ügynök számára. További információért lásd: Az Azure OpenAI több telepítéséhez vagy példányához használjon átjárót.

Megbízhatóság a nagyvállalati tudást kereső AI-keresésben

Az AI Search üzembe helyezése a Standard tarifacsomag vagy annál magasabb szintű használatával egy olyan régióban, amely támogatja a rendelkezésre állási zónákat. Konfiguráljon legalább három replikát, hogy a szolgáltatás a példányokat külön rendelkezésre állási zónák között ossza el. Ez a konfiguráció rugalmasságot biztosít a zónaszintű hibákhoz, és támogatja a keresési műveletek magas rendelkezésre állását.

A számítási feladat replikáinak és partícióinak optimális számának meghatározásához használja az alábbi módszereket:

• Az AI-keresés monitorozása beépített metrikák és naplók használatával. A lekérdezés késésének, szabályozásának és erőforrás-használatának nyomon követése.

• A replikák megfelelő számának meghatározásához használjon monitorozási metrikákat, naplókat és teljesítményelemzést. Ez a megközelítés segít elkerülni a nagy lekérdezési mennyiség, az elégtelen partíciók vagy az indexkorlátozások miatti lefojtást.

• Az indexelési megbízhatóság biztosításához kerülje az időszakos indexelési vagy indexelési hibák miatti fennakadásokat. Az adatok integritásának ellenőrzése után érdemes lehet offline indexbe indexelni, és az élő indexről az újraépített indexre cserélni.

Megbízhatóság az Azure Firewall

Azure Firewall az architektúra kritikus kimenőforgalom-vezérlési pontja, de egyetlen meghibásodási pontot jelöl az összes kimenő forgalom esetében. A kockázat csökkentése érdekében telepítsen Azure Firewall minden rendelkezésre állási zónában a régióban. Ez a konfiguráció segít fenntartani a kimenő kapcsolatot, ha egy zóna elérhetetlenné válik.

Ha a számítási feladat nagy mennyiségű egyidejű kimenő kapcsolatot igényel, konfigurálja a Azure Firewall több nyilvános IP-címmel. Ez a módszer több IP-címelőtag között osztja el a forráshálózati címfordítási (SNAT-) kapcsolatokat, ami csökkenti az SNAT-portok kimerülésének kockázatát. Az SNAT kimerülése időszakos vagy teljes kimenő kapcsolatvesztést okozhat az ügynökök és más számítási feladatok összetevői számára, ami a funkciók leállását vagy a teljesítmény romlását eredményezheti.

Az SNAT-portok használatának és a tűzfal állapotának figyelése. Ha csatlakozási hibákat vagy átviteli sebességproblémákat észlel, tekintse át a tűzfal metrikáit és naplóit az SNAT-kimerültség vagy egyéb szűk keresztmetszetek azonosításához és kezeléséhez.

Az Foundry Agent Service függőségeinek elkülönítése hasonló számítási feladatok összetevőitől

A megbízhatóság maximalizálása és a hibák robbanási sugarának minimalizálása érdekében szigorúan elkülönítheti az Foundry Agent Service függőségeit az ugyanazon Azure szolgáltatásokat használó számítási feladatok egyéb összetevőitől. Ne ossza meg az AI Search, Azure Cosmos DB vagy Storage-erőforrásokat az ügynökszolgáltatás és más alkalmazásösszetevők között. Ehelyett helyezzen üzembe dedikált példányokat az ügynök szolgáltatás szükséges függőségeihez.

Ez az elkülönítés két fő előnnyel jár:

• Egyetlen számítási feladatszakasz hibáit vagy teljesítménycsökkenését tartalmazza, ami megakadályozza a nem kapcsolódó alkalmazásfunkciók kaszkádolt hatásait.

• Lehetővé teszi a célzott üzemeltetési folyamatok, például a biztonsági mentés, a visszaállítás és a feladatátvétel alkalmazását. Ezek a folyamatok összhangban vannak az erőforrásokat használó számítási feladat folyamatának rendelkezésre állási és helyreállítási követelményeivel.

Ha például a csevegő felhasználói felület alkalmazásának tranzakciós állapotot kell tárolnia Azure Cosmos DB, állítson be egy külön Azure Cosmos DB fiókot és adatbázist erre a célra ahelyett, hogy újrahasználja a Foundry Agent Service által kezelt fiókot vagy adatbázist. Még akkor is, ha a költségek vagy a működési egyszerűség motiválja az erőforrás-megosztást, a nem kapcsolódó számítási feladatok funkcióit érintő megbízhatósági esemény kockázata meghaladja a legtöbb vállalati forgatókönyv lehetséges megtakarítását.

Fontos

Ha költség- vagy üzemeltetési okokból az ügynök függőségeivel együtt helyez el számítási feladatspecifikus adatokat, soha ne használja közvetlenül a rendszer által felügyelt adatokat, például gyűjteményeket, tárolókat vagy indexeket, amelyeket az Foundry Agent Service hoz létre. Ezek a belső megvalósítási részletek nincsenek dokumentálva, és értesítés nélkül megváltozhatnak. A közvetlen hozzáférés megszakíthatja az ügynökszolgáltatást, vagy adatvesztést okozhat. Mindig használja az Foundry Agent Service adatsík API-jait adatkezeléshez, például az elfeledtetéshez való jog (RTBF) kéréseinek teljesítéséhez. A mögöttes adatokat kezelje úgy, hogy nem nyúl hozzájuk, és csak figyelje őket.

Többrégiós kialakítás

Ez az architektúra rendelkezésre állási zónákat használ a magas rendelkezésre álláshoz egyetlen Azure régióban. Ez nem többrégiós megoldás. Nem rendelkezik a regionális rugalmassághoz és vészhelyreállításhoz szükséges alábbi kritikus elemekkel:

• Globális bejövő forgalom és forgalom útválasztása
• DNS-kezelés hibatűréshez
• Adatreplikációs vagy elkülönítési stratégiák régiók között
• Aktív-aktív, aktív-passzív vagy aktív-hideg megjelölés
• Regionális feladatátvételi és feladat-visszavételi folyamatok a helyreállítási idő célkitűzéseinek (KPO-k) és a helyreállítási pont célkitűzéseinek (RRP-k) teljesítéséhez
• A fejlesztői élmények régióhoz való elérhetőségének vizsgálata, beleértve az Foundry portált és az adatsík API-kat

Ha a számítási feladat üzleti folytonosságot igényel, ha regionális leállás történik, további összetevőket és üzemeltetési folyamatokat kell megterveznie és implementálnia ezen az architektúrán túl. Konkrétan a terheléselosztást és a feladatátvételt kell kezelnie az egyes architektúrarétegeken, beleértve a következő területeket:

• Az adateszközök és a háttéradattárak alapozása
• Modell üzemeltetési és következtetési végpontjai
• A vezénylési vagy ügynökréteg
• Felhasználói felületi forgalom és DNS-belépési pontok

Emellett gondoskodnia kell arról is, hogy a megfigyelhetőség, a monitorozás és a tartalombiztonsági vezérlők továbbra is működőképesek és egységesek maradjanak a régiók között.

Ez az alaparchitektúra nem rendelkezik többrégiós képességekkel, ezért a regionális kimaradások valószínűleg szolgáltatásvesztést okoznak a számítási feladaton belül.

Katasztrófa utáni helyreállítás

A csevegőarchitektúrák állapotalapú összetevőket tartalmaznak, ezért terveznie kell a katasztrófa utáni helyreállításra. Ezek a számítási feladatok általában memóriatárolót igényelnek az aktív vagy szüneteltetett csevegésekhez. Emellett szükség van a kiegészítő adatok, például dokumentumok vagy képek tárolására is, amelyek hozzáadva vannak a csevegésekhez. Az ügynök vezénylési rétege a beszélgetési folyamatokra jellemző állapotot is fenntarthatja. Ebben az architektúrában a Foundry Agent Service Azure Cosmos DB, Storage és AI Search használatával tartja fenn a működési és tranzakciós állapotot. Ennek az állapotnak az életciklusa és az összetevők közötti összekapcsolása határozza meg a DR-stratégiát és a helyreállítási műveleteket.

A Foundry Agent Service nem biztosít beépített dr. képességeket. Nem rendelkezik az állapot replikálására, biztonsági mentések létrehozására vagy időponthoz kötött visszaállítások végrehajtására alkalmas képességekkel. A helyreállítás rekonstrukcióval történik, nem replikák előállítása helyett. Az incidensek végleg eltávolíthatják az ügynököket, beszélgetéseket és tudásadatokat. Tervezze meg az állapotalapú tartalom teljes állapotvesztésének lehetőségét, és ennek megfelelően állítsa be a helyreállítási elvárásokat az érdekelt felekkel.

Az alábbi kompenzáló vezérlők az Foundry Agent service DR útmutatója alapján csökkentik az adatvesztés valószínűségét és hatókörét, de nem szüntetik meg azt.

• Azure Cosmos DB: Kapcsolja be az adatbázis folyamatos biztonsági mentésétenterprise_memory, amely ügynökdefiníciókat és csevegéseket is tartalmaz. A folyamatos biztonsági mentés lehetővé teszi a visszaállítást egy adott időpontra (PITR) a megőrzési időszakon belül bármely időpontra, amely az előző hét napot jelenti. Rendszeresen tesztelje a visszaállítási folyamatot annak ellenőrzéséhez, hogy megfelel-e az RTO-nak, és hogy a visszaállított adatok elérhetők maradnak-e az ügynökszolgáltatás számára. Mindig térjen vissza ugyanarra a fiókra és adatbázisra.

• AI-keresés: Az AI Search nem rendelkezik beépített visszaállítási képességekkel, és nem támogatja a közvetlen indexkezelést. Adatvesztés vagy sérülés esetén forduljon a Microsoft ügyfélszolgálatahoz segítségért az elérhető index-visszaállítási lehetőségekkel kapcsolatban. Ez a korlátozás jelentősen befolyásolhatja az RTO-t. Ha a csevegés felhasználói felülete nem támogatja a fájlfeltöltéseket, és nincsenek olyan ügynökei, amelyek statikus fájlokat használnak tudásként, előfordulhat, hogy nincs szüksége DR-csomagra az AI Search használatához.

  Tartsa fenn a vállalat alapozó tudásának különálló, rendszeresen frissített igazságforrását. Szükség esetén ez az eljárás biztosítja az indexek újraépítését.

• Raktározás: Ha georedundáns tárfiókja van, használja az ügyfél által felügyelt feladatátvételt a Foundry Agent Service által használt blobtárolókhoz. Ez a beállítás lehetővé teszi az átkapcsolást regionális kiesés esetén. Ha csak ZRS-t használ, forduljon Microsoft ügyfélszolgálatához az adatok visszaállításához. Ez a folyamat meghosszabbíthatja az RTO-t. Az AI Searchhöz hasonlóan, ha a csevegőfelület nem támogatja a fájlfeltöltéseket, és nincsenek olyan ügynökei, amelyek statikus fájlokat használnak tudásként, előfordulhat, hogy nem kell dr. csomag a blobtárolókhoz.

• Tranzakciós konzisztencia: Ha a feladat állapottárolója Azure AI-ügynök azonosítókra, például beszélgetési azonosítókra vagy ügynökazonosítókra hivatkozik, koordinálja a helyreállítást az összes releváns adattárban. A függőségek csak egy részhalmazának visszaállítása árva vagy inkonzisztens adatokat eredményezhet. Tervezze meg a DR-folyamatokat, hogy fenntartsa a hivatkozási integritást a munkaterhelés és az ügynöki szolgáltatás állapota között.

• Ügynökdefiníciók és -konfiguráció: Ügynökök definiálása kódként. Ügynökdefiníciók, kapcsolatok, rendszerkérések és paraméterek tárolása a forrásvezérlőben. Ez a gyakorlat lehetővé teszi az ügynökök ismételt üzembe helyezését egy jól ismert konfigurációból, ha elveszíti a vezénylési réteget. Kerülje az ügynökkonfiguráció nyomon nem követett módosítását az Foundry portálon vagy az adatsík API-in keresztül. Ez a megközelítés biztosítja, hogy az üzembe helyezett ügynökök reprodukálhatóak maradjanak.

• Öntödei projektek: A projekt identitásához használjon felhasználó által hozzárendelt felügyelt identitást. Ha a projektet véletlenül törölték, a felhasználó által hozzárendelt felügyelt identitás lehetővé teszi a meglévő szerepkör-hozzárendelések újrafelhasználását a projekt és a kapacitásgazda újbóli létrehozásakor. Ez a megközelítés csökkenti a projektfüggőségekkel való koordinációt a helyreállítás során.

A Foundry Agent Szolgáltatás függőségeihez kiegészítő megelőző intézkedésként adjon hozzá egy törlés erőforrás-zárolást az egyes szolgáltatásokhoz. Ez a gyakorlat segít megvédeni az AI Search, a Azure Cosmos DB és a Storage katasztrofális állapotvesztését.

Mielőtt éles környezetbe telepítené, hozzon létre egy helyreállítási útmutatót, mely mind az alkalmazás-, mind az ügynök által kezelt állapotban bekövetkező hibákat kezeli.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.

Ez az architektúra kibővíti az alapvető Foundry-csevegés referenciaarchitektúrájában létrehozott biztonsági alapokat. Az alaparchitektúrához hozzáad egy hálózati biztonsági peremet az azonosítási perem mellett. Hálózati szempontból az Application Gateway az egyetlen internetes erőforrás. Elérhetővé teszi a csevegőfelület-alkalmazást a felhasználók számára. Identitás szempontjából a csevegés felhasználói felületének hitelesítenie és engedélyeznie kell a kéréseket. Ha lehetséges, felügyelt identitások használatával hitelesítheti az alkalmazásokat Azure szolgáltatásokhoz.

Identitás- és hozzáférés-kezelés

Ez az architektúra elsősorban rendszer által hozzárendelt felügyelt identitásokat használ a szolgáltatások közötti hitelesítéshez. Felhasználó által hozzárendelt felügyelt identitásokat is használhat. Mindkét esetben alkalmazza a következő alapelveket:

• Identitások elkülönítése erőforrás és függvény szerint. Hozzon létre különálló felügyelt identitásokat a következő összetevőkhöz:

  • Az Foundry-erőforrás
  • Minden egyes Foundry-projekt
  • A webalkalmazás
  • Application Gateway
  • Bármely egyéni vezénylő vagy integrációs kód

• Hozzárendelési korlátozások használata (előzetes verzió). Csak Microsoft.CognitiveServices/accounts/projects a Foundry-projektidentitások, Microsoft.Web/sites a webalkalmazási identitások és Microsoft.Network/applicationGateways az Application Gateway-identitások esetében engedélyezett. Állítsa az elkülönítési hatókört a következőre Regional, és hozzon létre egy külön identitáskészletet az egyes üzembehelyezési régiókhoz.

• Csak akkor rendeljen identitást egy Azure erőforráshoz, ha az erőforrásnak ügyfélként kell hitelesítenie magát egy másik Azure szolgáltatásban.

• Használjon célhoz illő identitástípusokat. Ahol lehetséges, használjon számítási feladat-identitásokat alkalmazásokhoz és automatizáláshoz, és használjon ügynökidentitásokat az AI-ügynökökhöz.

Öntödei erőforrások megosztása és elkülönítése

Ez az architektúra egy dedikált Foundry-erőforrást helyez üzembe egyetlen éles munkaterheléshez. A teljes mértékben izolált számítási feladatok topológiája az éles számítási feladatokhoz ajánlott topológia. Az Foundry-erőforrás a benne futó összes rendszer hálózati határa és identitáshatára. Egy dedikált erőforrás elkülöníti a számítási feladat megfelelőségi hatókörét, a robbanási sugarat és a kvótát a nem kapcsolódó számítási feladatoktól és az éles üzem előtti környezetektől. Ez a választás tiszteletben tartja a közzétett AI-platformmegosztási döntési útmutatót, amely azt javasolja, hogy éles számítási feladatonként alapértelmezés szerint egyetlen AI-platformpéldányt hozzon létre.

A teljesen izolált topológia a megosztott Foundry-erőforrásban közösen elhelyezett számítási feladatokhoz képest nagyobb beállítási és kezelési többletterheléssel jár. Ez az architektúra a legtöbb éles számítási feladathoz szükséges szegmentálásért és független hozzáférés-vezérlésért, kvótáért és költséghatárokért cserébe elfogadja ezt a kompromisszumot.

Connections

A kapcsolatok határozzák meg, hogy egy Foundry-erőforrás vagy egy adott projekt hogyan hitelesít és használ külső függőséget. Ha lehetséges, hozzon létre kapcsolatokat a projekt szintjén. Távolítsa el a nem használt kapcsolatokat. Az Microsoft Entra ID-alapú hitelesítést részesítse előnyben minden kapcsolat esetében.

Ha egy kapcsolat nem támogatja a Microsoft Entra ID, meg kell adnia egy titkos kulcsot, például egy API-kulcsot. Ezeket a titkos kulcsokat egy dedikált, saját üzemeltetésű Azure kulcstartóban tárolhatja. Konfiguráljon egy Azure Key Vault kapcsolatot az Foundry-erőforráshoz, hogy a szolgáltatás elolvashassa és megírhassa az általa kezelt titkos kulcsokat.

Ezt a kulcstárat csak a Foundryhez használja. Ne ossza meg más számítási feladatok összetevőivel. Az erőforrásban lévő összes projekt minden, a Microsoft Entra ID-től eltérő kapcsolata ebben a trezorban tárolja a titkait. Más számítási feladatok összetevőinek nem kell hozzáférniük ezekhez a titkos kulcsokhoz az Foundry képességeinek használatához. Ne adjon olvasási vagy írási engedélyeket ezen a tárolón más összetevőknek, hacsak nincs egyértelmű működési követelménye, vagy nem fogadja el a kompromisszumot.

Ez az architektúra két API-kulcsalapú kapcsolatot tartalmaz: az Application Insights for Foundry metrikákat és a webes keresőeszközt. Az architektúra külső HTTP-végpontokat ( például MCP-kiszolgálókat vagy OpenAPI által definiált API-kat) hívó eszközökkel való kiterjesztésekor minden eszköz hozzáad egy projektkapcsolatot, amely a hitelesítési hitelesítő adatait tartalmazza.

McP-kiszolgáló csatlakoztatásakor korlátozza az elérhető eszközöket a használatával allowed_tools. A nagy kockázatú műveletek, például az adatok írására vagy az erőforrások módosítására szolgáló eszközök jóváhagyásának megkövetelése és naplózása, valamint az eszköz nevének és argumentumainak ellenőrzése jóváhagyás előtt. További információkért tekintse meg az MCP ajánlott eljárásait.

Ha ügyfél által felügyelt kulcsokat használ a titkosításhoz, az ügyfél által kezelt kulcsokat és a kapcsolati titkos kulcsokat is tárolhatja ugyanabban a dedikált tárolóban, ha a biztonsági szabályozási szabályzatok lehetővé teszik a titkosítási kulcsok és titkos kódok áthelyezését.

Az Foundry Portal alkalmazotti hozzáférése

Amikor az alkalmazottakat beilleszti a Foundry projektekbe, rendelje hozzá a szerepkörükhöz szükséges minimális engedélyeket. A Microsoft Entra ID-csoportok és az Azure szerepköralapú hozzáférés-vezérlés (Azure RBAC) használatával biztosíthatja a feladatok elkülönítését. Megkülönbözteti például az ügynökfejlesztőket az adattudósoktól, akik finomhangolási feladatokat végeznek. De értse meg a korlátozásokat és kockázatokat. Személy hozzárendelése a Foundry beépített szerepköreihez és Azure RBAC-szerepkörökhöz, például:

Személyiség	Beépített szerepkör	Scope
Öntödei erőforrás-kezelő	Öntödei fiók tulajdonosa	Öntödei erőforrás
Ügynökfejlesztő vagy adatelemző	Foundry User a Foundry-projekten, valamint Olvasó a Foundry-erőforráson	Foundry-projekt és Foundry-erőforrás

Az egyes beépített szerepkörök engedélyeit és további vállalati leképezési példákat a Role-alapú hozzáférés-vezérlés Microsoft Foundry című témakörben találja.

Az Foundry portál számos műveletet futtat a szolgáltatás identitásának használatával, nem pedig az alkalmazott identitásával. Ennek eredményeképpen a korlátozott Azure RBAC-szerepkörrel rendelkező alkalmazottak láthatják a bizalmas adatokat, például csevegéseket, ügynökdefiníciókat és konfigurációkat. Ez az Öntödei portál kialakítása véletlenül megkerülheti a kívánt hozzáférési korlátozásokat, és a tervezettnél több információt tehet közzé.

A jogosulatlan hozzáférés kockázatának csökkentése érdekében korlátozza a portál használatát éles környezetben olyan alkalmazottak számára, akiknek nyilvánvaló operatív igényük van. A legtöbb alkalmazott esetében vonja vissza vagy tiltsa le az Foundry portálhoz való hozzáférést éles környezetben. Ehelyett használjon automatizált üzembehelyezési folyamatokat és infrastruktúrát kódként (IaC) az ügynök- és projektkonfiguráció kezeléséhez.

Kezelje az új projektek létrehozását egy Öntödei erőforrásban kiemelt műveletként. A portálon létrehozott projektek nem öröklik automatikusan a meglévő hálózati biztonsági vezérlőket, például a privát végpontokat vagy a hálózati biztonsági csoportokat (NSG-k). Ezekben a projektekben az új ügynökök megkerülik a kívánt biztonsági szegélyt. A projektlétrehozás kényszerítése kizárólag ellenőrzött, auditálható IaC-folyamatokon keresztül.

Öntödei projektszerepkör-hozzárendelések és kapcsolatok

Az Foundry Agent Service standard módban való használatához a projektnek adat- és vezérlősík-engedélyekkel kell rendelkeznie az Foundry Agent Service függőségeihez. A projekt felügyelt identitásának emelt szintű szerepkör-hozzárendelésekkel kell rendelkeznie a tárfiókon, az AI Search-ben és az Azure Cosmos DB-fiókban. Ezek az engedélyek szinte teljes hozzáférést biztosítanak ezekhez az erőforrásokhoz, beleértve az adatok olvasásának, írásának, módosításának vagy törlésének lehetőségét. A minimális jogosultsági hozzáférés fenntartásához elkülönítse a számítási feladat erőforrásait az Foundry Agent Service függőségeitől.

Egyetlen Foundry-projekt összes ügynöke ugyanazzal a felügyelt identitással rendelkezik. Ha a számítási feladat több olyan ügynököt használ, amely különböző erőforráskészletekhez való hozzáférést igényel, kövesse a minimális jogosultság elvét, és hozzon létre egy külön Foundry-projektet minden egyes különálló ügynök-hozzáférési mintához. Ez az elkülönítés lehetővé teszi, hogy csak a minimálisan szükséges engedélyeket rendelje hozzá az egyes projektek felügyelt identitásához, ami csökkenti a túlzott vagy nem szándékos hozzáférés kockázatát. Ez a megosztottidentitás-modell az ebben az architektúrában használt promptügynökökre vonatkozik. Az üzembe helyezett üzemeltetett ügynökök ehelyett saját Microsoft Entra ügynökidentitást kapnak az üzembe helyezéskor, így a hozzáférési minták különböző projektekbe való elkülönítése nélkül biztosíthatja és naplózhatja az eszközökhöz és az alsóbb rétegbeli erőforrásokhoz való hozzáférést ügynökenként.

Ha kapcsolatokat hoz létre külső erőforrásokhoz a Foundryben, Microsoft Entra ID-alapú hitelesítést használjon, ha elérhető. Ez a megközelítés szükségtelenné teszi az előre felosztott titkos kulcsok fenntartását. Minden egyes kapcsolat hatókörét úgy állítsuk be, hogy csak a tulajdonos projekt használhassa. Ha több projekt is hozzáférést igényel ugyanahhoz az erőforráshoz, hozzon létre egy külön kapcsolatot az egyes projektekben ahelyett, hogy egyetlen kapcsolatot osztanának meg a projektek között. Ez a gyakorlat szigorú hozzáférési határokat kényszerít ki, és megakadályozza, hogy a jövőbeli projektek örökölhessék a nem igényelt hozzáférést.

Ne hozzon létre kapcsolatokat az Foundry-erőforrás szintjén, mert az erőforrásszintű kapcsolatok az erőforrás összes jelenlegi és jövőbeli projektére vonatkoznak. Véletlenül széles körű hozzáférést biztosíthatnak az erőforrásokhoz, megsérthetik a minimális jogosultsági elveket, és növelhetik a jogosulatlan adatexpozíció kockázatát. Csak projektszintű kapcsolatokat hozhat létre.

Konverzációk izolálása

Az Foundry Agent Service nem kényszeríti ki a felhasználónkénti hitelesítést a beszélgetéseken. Az alkalmazáskiszolgáló azonosítója olyan projektszintű hitelesítő adatokkal rendelkezik, amelyekkel az azonosító megadásával bármely beszélgetésből tud olvasni vagy írni. Ha a csevegőfelületi alkalmazás ellenőrzés nélkül közvetlenül átad egy ügyfél által megadott beszélgetési azonosítót az Agent Service-nek, a felhasználó hozzáférhet vagy beszúrhat üzeneteket egy másik felhasználó beszélgetésébe. Ez egy hibás objektumszintű engedélyezési biztonsági rés.

Az alkalmazáskiszolgálónak a beszélgetés tulajdonjogát kell kikényszerítenie. Ne bízzon meg az ügyfél beszélgetésazonosítóiban. Minden kérésnél ellenőrizze, hogy a hitelesített felhasználóé-e a hivatkozott beszélgetés, mielőtt továbbítanák a kérést az Agent Service-nek.

A üzemeltetett ügynökök felhasználónkénti munkamenet-elkülönítési modellt kínálnak, de ez az architektúra topológiája határozza meg, hogy alkalmazható-e. A webalkalmazás minden bejelentkezett felhasználó nevében meghívja az ügynököt saját számítási feladattal, így a platform egyetlen hívó identitást lát, és nem tudja megkülönböztetni az egyik végfelhasználót a másiktól. Ebben a mintában az alkalmazáskiszolgáló továbbra is a megbízhatósági határ marad, és a korábban ismertetett módon kell kikényszerítenie a beszélgetés tulajdonjogát.

Az elkülönítés akkor válik alkalmazhatóvá, ha az üzemeltetett ügynök végpontjára irányuló kérés nem csak az alkalmazás identitását, hanem a végfelhasználó identitását hordozza. A hívó közvetlenül a saját Microsoft Entra jogkivonatával hitelesít, vagy az alkalmazáskiszolgáló átadja a végfelhasználó stabil azonosítóját a platformnak. Amikor a kérelem azonosítja a végfelhasználót, a platform a beszélgetéseket, a munkameneteket, a tárolt adatokat és a munkamenetenkénti $HOME fájlrendszert a kérelem identitására hatókörli. Amikor minden hívó saját identitást jelenít meg, az elválasztja az egyik felhasználó adatait a másiktól. Delegált identitások esetén a platform nem választja el az egyik delegált felhasználót a másiktól, így a korábban ismertetett alkalmazás-kiszolgáló kényszerítés továbbra is érvényes.

Amikor az alkalmazáskiszolgáló végfelhasználói identitásokat delegál, a felhasználónkénti ügynöki munkamenetek megnyitása helyett számos felhasználót csoportosíthat az ügynöki munkamenetek egy meghatározott csoportjába. A platform előfizetésenként és régiónként korlátozza az egyidejű ügynökmunkamenetek számát, és ebbe a korlátba csak azok az ügynökmunkamenetek számítanak bele, amelyek aktívan dolgoznak fel egy kérelmet. Amikor a felhasználók megosztanak egy ügynök-munkamenetet, a platform továbbra is elkülöníti az egyes felhasználók beszélgetési állapotát, de az ügynöktároló által tárolt adatok( például fájlok, adatbázissorok vagy gyorsítótár) nem lesznek automatikusan particionálva. A kódnak az adatokat mind az ügynök munkamenete, mind a végfelhasználó identitása alapján kell kulcsolnia. Ellenkező esetben az ugyanabban a közös munkamenetben lévő felhasználók elolvashatják egymás tárolt adatait. A leképezési stratégiákról és erről a felhasználónkénti particionálásról lásd: Több felhasználó multiplexelése egy üzemeltetett ügynökmenetben.

Tartalombiztonság

Az üzembe helyezésben lévő minden modellhez hozzá kell rendelni egy tartalomszűrő szabályzatot, amely a promptokat és a modellválaszokat káros tartalom szempontjából szűri.

Értékelje ki az alapértelmezett Microsoft által felügyelt szabályzatot a számítási feladat tartalombiztonsági követelményei alapján. Ha az alapértelmezett küszöbértékek nem felelnek meg ezeknek a követelményeknek, egyéni tartalomszűrő házirendet kell létrehoznia, és az üzembe helyezéshez kell kötnie. A szabályzatot kódként kezelheti az infrastruktúra többi része mellett, hogy a tartalombiztonsági konfiguráció a különböző környezetekben is vezérelve és konzisztens maradjon.

hálózat

Az identitásalapú hozzáférés mellett ez az architektúra hálózati titoktartást is igényel.

A hálózat kialakítása a következő biztosítékokat tartalmazza:

• Egyetlen biztonságos belépési pont az összes csevegési felhasználói felület forgalmához, amely minimalizálja a támadási felületet

• Szűrt bejövő és kimenő hálózati forgalom NSG-k, webalkalmazási tűzfal, felhasználó által megadott útvonalak (UDR-ek) és Azure Firewall szabályok kombinációjával

• Az átvitel alatt álló adatok végpontok közötti titkosítása TLS használatával

• Hálózati adatvédelem Private Link használatával az összes Azure PaaS-szolgáltatáskapcsolathoz

• A hálózati erőforrások logikai szegmentálása és elkülönítése, dedikált alhálózatokkal az egyes fő összetevők csoportosításához a részletes biztonsági szabályzatok támogatásához

Hálózati folyamatok

A diagram az alapszintű csevegési architektúrához hasonlít. Tartalmazza az Azure OpenAI-architektúrát és három számozott hálózati folyamatot. A bejövő folyamat és az App Service-ből Azure PaaS-szolgáltatásokba irányuló folyamat az alapkonfigurációs App Service-webarchitektúrából lesz átmásolva. Az Foundry-ügynök szolgáltatás folyamata egy nyilat jelenít meg a privát virtuális hálózat Foundry privát végpontjáról, amely a Foundry Agent Service szolgáltatásra mutat. Az Foundry Agent Service folyamatban a második számozott nyíl azt mutatja, hogy a magánhálózati Azure AI-ügynök virtuális felületéről érkező hívások hogyan haladnak át a privát végpontokon. A harmadik számozott nyíl egy nyilat jelenít meg a virtuális felületről egy Azure Firewall mezőre, amely azt jelzi, hogy az internetre irányuló összes hívás ezen a tűzfalon keresztül halad át.

A baseline App Service webalkalmazás architektúrája a felhasználótól a csevegés felhasználói felületére irányuló bejövő folyamatot, valamint az App Service-ből a Azure PaaS-szolgáltatásokba irányuló folyamatot ismerteti. Ez a szakasz az ügynökök interakcióira összpontosít.

Amikor a csevegőfelület kommunikál az Foundryben üzembe helyezett ügynökkel, a következő hálózati folyamatok történnek:

1. Az App Service által üzemeltetett csevegőfelület https-kéréseket kezdeményez egy privát végponton keresztül az Foundry adatsík API-végpontjához.

2. Amikor az ügynök hozzáfér Azure PaaS-szolgáltatásokhoz, például szolgáltatásfüggőségekhez, egyéni tudástárakhoz vagy egyéni eszközökhöz, a delegált alhálózat egybérlős adatproxyja HTTPS-kéréseket küld ezeknek a szolgáltatásoknak a privát végpontjainak.

3. Amikor az ügynök hozzáfér a virtuális hálózaton kívüli erőforrásokhoz, beleértve az internetes API-kat vagy a külső szolgáltatásokat, az adatproxy átirányítja ezeket a HTTPS-kéréseket a delegált alhálózatról a Azure Firewall keresztül.

A privát végpontok kulcsfontosságú biztonsági vezérlőként szolgálnak ebben az architektúrában az identitásalapú biztonság kiegészítésével. Mivel ez az architektúra privát végpontokat és UDR-eket használ a virtuális hálózaton, nem támogatja az Foundry-projektek hálózati biztonsági szegélyképességét .

Hozzáférés a Foundryhez

Ez az architektúra letiltja az Foundry adatsíkhoz való nyilvános hozzáférést azáltal, hogy csak a Foundry privát kapcsolatán keresztül engedélyezi a forgalmat. Az Foundry portál nagy részét a portál webhelyén keresztül érheti el, de minden projektszintű funkcióhoz hálózati hozzáférés szükséges. A portál az Foundry-erőforrás adatsík api-jaira támaszkodik, amelyek csak privát végpontokon keresztül érhetők el. Ennek eredményeképpen a fejlesztőknek és az adatszakértőknek jump boxon, társhálózaton, Azure ExpressRoute kapcsolaton vagy helyek közötti VPN-kapcsolaton keresztül kell hozzáférniük a portálhoz.

Az ügynök adatsíkjával folytatott minden programozott interakciónak ezeket a privát végpontokat is használnia kell. Ilyenek például a webalkalmazásból vagy a modell következtetését meghívó külső vezénylési kódból érkező hívások. A privát végpontok nem a projekt szintjén, hanem az erőforrás szintjén vannak definiálva, így az erőforrás összes projektje azonos végpontokkal és hálózati expozícióval rendelkezik. A hálózati hozzáférést nem lehet projektszinten szegmentálni.

A konfiguráció támogatásához állítsa be a DNS-t a következő Foundry FQDN API-végpontokhoz:

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

Az alábbi ábra bemutatja, hogyan csatlakozik egy AI-fejlesztő a Azure Bastion egy virtuális gép (VM) jump boxjához. Ebből a jump boxból a szerző hozzáférhet a projekthez az Foundry portálon egy privát végponton keresztül ugyanabban a hálózatban.

Egy nyíl az ügynök szerzőjétől az Azure Bastion-ra, a jump box-ra, a Foundry portál privát végpontjára, majd a Foundry projektbe mutat, amely a Foundry Agent Service szolgáltatást tartalmazza. Az Foundry-projektben egy nyíl mutat a Azure AI-ügynök integrációs alhálózatának virtuális felületére. A végső nyíl a virtuális felületről a három Foundry Agent Service-függőség privát végpontjára mutat. Ezek a függőségek az AI Search, a Azure Cosmos DB és a Storage.

Az Foundry-ügynök alhálózatából érkező forgalom szabályozása

Ez az architektúra átirányítja a kimenő (kimenő) hálózati forgalmat az Foundry Agent Service képességből egy delegált alhálózaton keresztül a virtuális hálózaton belül.

A promptügynökök esetében egy egybérlős adatproxy fut ebben a delegált alhálózatban, és az ügynök nevében kezeli az összes kimenő kapcsolatot. Az Foundry Agent Service minden projekthez egy adatproxyt helyez üzembe, és a projekt összes parancssori ügynöke megosztja azt. Az adatproxy az ügynök szükséges szolgáltatásfüggőségeinek és az ügynök által használt legtöbb külső tudásforrásnak vagy eszközkapcsolatnak a kimenő pontja.

Az üzemeltetett ügynökök esetében a vezérlési pont eltolódik: minden üzemeltetett ügynök munkamenete olyan számításban fut, amely dedikált hálózati adapterrel rendelkezik ebben az alhálózatban, így az ügynök saját kimenő forgalma közvetlenül ezen a felületen halad át, nem pedig az adatproxyn keresztül, bár az eszközhívások továbbra is az adatproxyn keresztül haladnak.

Ennek a kimenő útvonalnak a kényszerítésével teljes mértékben szabályozhatja a kimenő forgalmat. Részletes NSG-szabályokat, egyéni útválasztást és DNS-vezérlést alkalmazhat a szolgáltatást elhagyó összes ügynökforgalomra. Ez a kialakítás segít csökkenteni az adatkiszivárgási kísérleteket a vezénylési logikából.

Az ügynökszolgáltatás a virtuális hálózat DNS-konfigurációjával oldja fel a privát végpontrekordokat és a szükséges külső teljes tartományneveket. Ez a beállítás biztosítja, hogy az ügynök kérései DNS-naplókat generálnak, amelyek támogatják a naplózást és a hibaelhárítást.

Az ügynök kimenő alhálózatához csatolt NSG blokkolja az összes bejövő forgalmat, mert nem fordulhat elő jogszerű bejövő forgalom. A kimenő NSG-szabályok csak a virtuális hálózaton belüli privát végpont alhálózatokhoz és az internethez kötött forgalom 443-ás TCP-portjához engedélyezik a hozzáférést. Az NSG tagadja az összes többi forgalmat.

Az internetes forgalom további korlátozása érdekében ez az architektúra egy UDR-t alkalmaz az alhálózatra, amely az összes HTTPS-forgalmat Azure Firewall keresztül irányítja. A tűzfal szabályozza, hogy az ügynök mely teljes tartományneveket érheti el HTTPS-kapcsolatokon keresztül. Ha például az ügynök openAPI-eszközdefiníción keresztül csatlakozik egy nyilvános MCP-kiszolgálóhozhttps://contoso.com/mcp, vagy külső API-t hív meg, konfiguráljon Azure Firewall, hogy engedélyezze a forgalmat az alhálózat 443-es portján lévő adott teljes tartománynevek felé, és győződjön meg arról, hogy az NSG engedélyezi ezt a forgalmat.

Az ügynök futtatókörnyezetéhez a saját platformfüggőségeihez is kimenő hozzáférésre van szükség, nem csak az ügynökök által használt teljes tartománynevekhez. Engedélyezze a AzureActiveDirectory szolgáltatáscímkét, hogy az ügynöki számítási erőforrás hitelesíthesse magát. A külső végpontokat elérő hosztolt ügynök megköveteli, hogy ezeket a teljes tartományneveket (FQDN-eket) engedélyezze a tűzfalában. Erre a forgalomra ne alkalmazza a TLS-ellenőrzést Azure Firewall. Az ellenőrzés során használt tanúsítvány megszakíthatja az ügynökök kapcsolatait.

Megjegyzés:

Nem minden, az ügynökökhöz csatlakoztatott tudáseszköz halad át ezen az alhálózaton. A webes keresőeszköz például meghívja azokat a hívásokatapi.bing.microsoft.com, amelyeket várhatóan az alhálózat 443-es portjának engedélyezésével fog Azure Firewall keresztül irányítani. Az Agent Service azonban egy belső mechanizmuson keresztül hívja meg ezt az eszközt, amely teljes egészében áthalad a kimenő alhálózaton. Tesztelje a számítási feladathoz tartozó összes beépített tudás- és eszközkapcsolatot annak ellenőrzéséhez, hogy azok megfelelnek-e a hálózati kimenőforgalom-vezérlési szabályzatoknak.

A számítási feladat tulajdonában lévő MCP-kiszolgálók elérése

Ha a munkaterheléséhez privát MCP-kiszolgálót üzemeltet, hozzon létre egy dedikált MCP-alhálózatot ugyanabban a virtuális hálózatban, mint az ügynök-alhálózat. Engedélyezze a 443-as és 31443-es kimenő TCP-portokat az ügynök alhálózatáról az MCP-alhálózatra, és engedélyezze az MCP-alhálózaton a megfelelő bejövő forgalmat. Konfigurálja a privát DNS-t úgy, hogy a Container Apps-környezet alapértelmezett vagy egyéni tartománya a virtuális hálózaton belüli statikus IP-címére oldódjon fel. Ebben a topológiában az MCP-kiszolgálókra irányuló ügynökhívások privát címzést használnak, és a virtuális hálózaton belül maradnak. A megvalósítással kapcsolatos útmutatásért tekintse meg az ügynökök csatlakoztatása a Model Context Protocol-kiszolgálókhoz című témakört.

Feltéve, hogy az MCP-kiszolgálót a Container Apps üzemelteti, az MCP alhálózat NSG-jének engedélyeznie kell a szükséges Container Apps hálózati forgalmat is. Irányítsa a munkaterhelés MCP-kiszolgálóinak internetre irányuló forgalmát az Azure Firewallon keresztül.

Virtuális hálózatok szegmentálása és biztonsága

Ez az architektúra úgy szegmentálta a virtuális hálózatot, hogy minden fő összetevőcsoportot hozzárendel a saját alhálózatához. Minden alhálózat rendelkezik egy dedikált NSG-vel, amely a bejövő és kimenő forgalmat csak az összetevő által igényeltre korlátozza.

Az alábbi táblázat összefoglalja az egyes alhálózatok NSG- és tűzfalkonfigurációját.

Használat vagy alhálózat neve	Bejövő forgalom (NSG)	Kimenő forgalom (NSG)	UDR–tűzfal	Tűzfal kimenő szabályai
Privát végpontok snet-privateEndpoints	Virtuális hálózat	Nem engedélyezett forgalom	Igen	Nem engedélyezett forgalom
Application Gateway snet-appGateway	Csevegő felhasználói felület felhasználói forrás IP-címei, például a nyilvános internet és a szolgáltatáshoz szükséges források	Privát végpont alhálózata és a szolgáltatáshoz szükséges elemek	Nem	-
App szolgáltatás snet-appServicePlan	Nem engedélyezett forgalom	Privát végpontok és Azure Monitor	Igen	Az Azure Monitor-hoz
Öntödei Ügynök Szolgáltatás snet-agentsEgress	Nem engedélyezett forgalom	Privát végpontok, MCP-alhálózat és internet	Igen	Csak olyan nyilvános teljes tartománynevek, amelyek használatát engedélyezi az ügynököknek
Privát MCP-kiszolgálók snet-mcpServers	Az Foundry Agent Service alhálózatából származó 443-s és 31443-os TCP-portok és a gazdagéphez szükséges források	kötelező bejegyzések a szolgáltatáshoz	Igen	A platformhoz szükséges FQDN-ek és kizárólag azok a nyilvános FQDN-ek, amelyeket az MCP-kiszolgálók igényelnek
Jump box virtuális gépek snet-jumpBoxes	Azure Bastion alhálózat	Privát végpontok és az internet	Igen	A virtuális gép igénye szerint
Ügynökök létrehozása snet-buildAgents	Azure Bastion alhálózat	Privát végpontok és az internet	Igen	A virtuális gép igénye szerint
Azure Bastion AzureBastionSubnet	Lásd: NSG-hozzáférés és Azure Bastion	Lásd: NSG-hozzáférés és Azure Bastion	Nem	-
Azure Firewall AzureFirewallSubnet AzureFirewallManagementSubnet	Nincs NSG	Nincs NSG	Nem	-

Ez a kialakítás kifejezetten tagadja az összes többi forgalmat, akár az NSG-szabályokon keresztül, akár alapértelmezés szerint az Azure Firewall.

Amikor hálózati szegmentációt és biztonságot valósít meg ebben az architektúrában, kövesse az alábbi javaslatokat:

• Helyezzen üzembe egy Azure DDoS Protection tervet az Application Gateway nyilvános IP-címén a mennyiségi támadások csökkentése érdekében.

• Csatoljon egy NSG-t minden azt támogató alhálózathoz. Alkalmazza a lehető legszigorúbb szabályokat a szükséges funkciók megzavarása nélkül.

• Alkalmazzon kényszerített bújtatást az összes támogatott alhálózatra, hogy a kimenő tűzfal az összes kimenő forgalmat megvizsgálhassa. Használjon kényszerített bújtatást olyan alhálózatokon is, ahol nem várható kimenő forgalom. Ez a módszer részletes védelmi mértéket ad hozzá, amely védelmet nyújt az alhálózat szándékos vagy véletlen visszaélése ellen.

Webalkalmazási tűzfal finomhangolása

A csevegőalkalmazások gyakran olyan tartalmakat hoznak létre, amelyek hamis pozitívákat eredményeznek a WAF által kezelt szabályokban. A felhasználói kérések és modellválaszok gyakran tartalmaznak kódrészleteket, SQL-utasításokat vagy HTML-töredékeket. A csevegési tartalom számos felügyelt szabálykategóriában hamis pozitív értékeket válthat ki, beleértve a távoli kódvégrehajtást, a helyi fájlbefoglalást és a fenyegetésfelderítési szabályokat. Többfordulós beszélgetések esetén az OWASP anomáliadekód mindaddig halmozódik fel az üzenetek között, amíg a WAF HTTP 403-as hibával nem blokkolja a kérést, ami azt jelenti, hogy a blokkolás spontán jelenhet meg, amikor a beszélgetések hosszabbak lesznek.

Ennek megoldásához hangolja a WAF-szabályzatot úgy, hogy a csevegési üzeneteket tartalmazó kérelem törzsmezőjére vonatkozó kizárásokat hoz létre. Hatókörkizárások az érintett szabálycsoportokra a szabályok globális letiltása helyett. Azt is ellenőrizze, hogy a kérelem törzsének ellenőrzési korlátai megfelelnek-e a csevegési interakciókban jellemző hasznos teher méretének.

Szabályozás szabályzaton keresztül

A számítási feladat biztonsági alapkonfigurációjához való igazodáshoz Azure Policy és hálózati szabályzatokkal győződjön meg arról, hogy minden számítási feladat erőforrása megfelel a követelményeknek. A szabályzaton keresztüli platformautomatizálás csökkenti a biztonsági konfiguráció eltérésének kockázatát, és segít csökkenteni a manuális érvényesítési tevékenységeket.

Fontolja meg a következő típusú biztonsági szabályzatok implementálását az architektúra megerősítése érdekében:

• Kapcsolja ki a kulcsalapú vagy más helyi hitelesítési módszereket az olyan szolgáltatásokban, mint az Foundry-eszközök és a Key Vault.

• A hálózati hozzáférési szabályok, a privát végpontok és az NSG-k explicit konfigurációjának megkövetelése.

• Titkosítást igényel, például ügyfél által felügyelt kulcsokat.

• Korlátozhatja az erőforrások létrehozását, például a régiók vagy erőforrástípusok korlátozását.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésére és a működési hatékonyság javítására összpontosít. További információt a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistájában talál.

Ez a preconfigured becslés a Azure díjkalkulátorban csak az architektúra összetevőit tartalmazza, így a használatnak megfelelően testre szabhatja. A forgatókönyv legdrágább összetevői a Azure Cosmos DB, az AI Search és a DDoS Protection. Egyéb jelentős költségek közé tartozik a csevegés felhasználói felületének kiszámítása és az Application Gateway. Optimalizálja ezeket az erőforrásokat a költségek csökkentése érdekében.

Öntödei Ügynökségi Szolgáltatás

A standard üzembe helyezés használatakor saját Azure-előfizetésében kell beállítania és kezelnie a szolgáltatás függőségeit.

Az alábbi javaslatok ismertetik, hogyan optimalizálhatók a szükséges szolgáltatások költségei:

• A Foundry Agent Service kezeli a kérelemegységek (RU) elosztását az Azure Cosmos DB-n. A hosszú távú költségek csökkentése érdekében vásároljon fenntartott kapacitást Azure Cosmos DB számára. Hangolja össze a foglalásokat a várt használati időtartammal és mennyiséggel. A fenntartott kapacitás előzetes elkötelezettséget igényel, és nem rugalmas, ha a számítási feladat használati mintái jelentősen megváltoznak.

• Ha a csevegési forgatókönyv nem igényel fájlfeltöltést, zárja ki ezt a funkciót az alkalmazásban. Ebben az esetben alkalmazza a következő konfigurációs módosításokat:

  • Használjon helyileg redundáns tárolási (LRS) szintet a Storage-fiókhoz.

  • Az AI Search konfigurálása egyetlen replikával a javasolt három replika helyett.

• Rendszeresen törölje a nem használt ügynököket és a hozzájuk kapcsolódó beszélgetéseket az SDK- vagy REST API-k használatával. Az elavult ügynökök és beszélgetések továbbra is tárterületet használnak, és növelhetik a költségeket az Azure Cosmos DB, a tárhelyszolgáltatás és az AI Search során.

• Kapcsolja ki a számítási feladathoz nem szükséges függő erőforrások funkcióit, például az alábbi funkciókat:

  • A szemantikai rangsoroló az AI Searchben

  • Az Azure Cosmos DB átjáró- és többrégiós írási képességei

• A régiók közötti sávszélesség-díjak elkerülése érdekében helyezzen üzembe Azure Cosmos DB, Storage és AI Search szolgáltatást ugyanabban a Azure régióban, mint a Foundry Agent Service.

• Kerülje a számítási feladatokra vonatkozó adatok áthelyezését ugyanabban a Azure Cosmos DB vagy AI Search-erőforrásokban, amelyeket a Foundry Agent Service használ. Bizonyos esetekben megoszthatja ezeket az erőforrásokat, hogy csökkentse a nem használt kapacitást az RU-kban vagy a keresési egységekben, ezáltal csökkentve a költségeket. Csak a megbízhatósági, biztonsági és teljesítménybeli kompromisszumok alapos kockázatértékelése után vegye figyelembe az erőforrás-megosztást.

Ügynöki ismeretek és eszközök

Az Foundry Agent Service nem meghatározott módon futtatja az ügynök logikáját. Meghívhat csatlakoztatott eszközöket, például tudáslekérdezési eszközöket, egyéni API-eszközöket vagy más ügynököket minden kéréshez, még akkor is, ha az eszköz nem releváns a felhasználói lekérdezés szempontjából. Ez a viselkedés szükségtelen hívásokat eredményezhet külső API-khoz vagy adatforrásokhoz, növelheti az egyes tranzakciók költségeit, és kiszámíthatatlan használati mintákat eredményezhet, amelyek bonyolítják a költségvetés előrejelzését.

A költségek szabályozásához és a kiszámítható viselkedés fenntartásához alkalmazza a következő stratégiákat:

• Csak azokat az eszközöket csatlakoztassa, amelyeket a legtöbb ügynökhívás valószínűleg használni fog. Kerülje a ritkán szükséges vagy az egyes hívásokhoz magas költségekkel járó eszközök csatlakoztatását, hacsak nem nélkülözhetetlenek.

• Tervezzen és finomítsa a rendszerkérést, hogy utasítsa az ügynököt a szükségtelen vagy redundáns külső hívások minimalizálására. A rendszerkérésnek arra kell irányítania az ügynököt, hogy csak a legrelevánsabb kapcsolatokat használja az egyes kérésekhez.

• Az Öntödei metrikák és naplók segítségével figyelheti az ügynök által meghívott eszközöket, azok gyakoriságát és a kapcsolódó költségeket. Rendszeresen tekintse át ezeket az adatokat a váratlan használati minták vagy költségnövekedések azonosításához, és szükség szerint módosítsa a rendszerkérést.

• Vegye figyelembe, hogy a nemdeterminisztikus meghívás megnehezítheti a költség-előrejelzést, különösen akkor, ha használatalapú API-kkal integrálódik. Ha kiszámítható költségekre van szüksége, fontolja meg a vezénylő önkiszolgáló üzemeltetését determinisztikus kód használatával.

Azure OpenAI-modellek

Modelltelepítések a Foundryben a MaaS-megközelítést használják. A költségek elsősorban a használattól vagy az előre kiosztott foglalástól függenek.

Az architektúra használati modell költségeinek szabályozásához használja az alábbi módszerek kombinációját:

• Ügyfelek vezérlése. A használati modellben az ügyfélkérések okozzák a legtöbb költséget, ezért önnek kell irányítania az ügynökök viselkedését.

  A szükségtelen használat csökkentése érdekében hajtsa végre a következő műveleteket:

  • Hagyja jóvá az összes modellfogyasztót. Ne tegye közzé a modelleket olyan módon, amely korlátlan hozzáférést tesz lehetővé.

  • Érvényesítse a tokenek számára vonatkozó korlátozásokat minden egyes válasz esetében. Amikor az alkalmazás választ generál, állítsa be a max_output_tokens értéket a modell által generált tokenek számának korlátozásához. truncation A beállítással szabályozhatja, hogy mennyi beszélgetési előzmény lép be a modell környezeti ablakába minden egyes turnön.

  • Optimalizálja a parancssori bemenet és a válasz hosszát. A hosszabb kérések több tokeneket használnak fel, ami növeli a költségeket. Olyan kérések, amelyek nem rendelkeznek elegendő szövegkörnyezettel, csökkentik a modell hatékonyságát. Tömör utasításokat hozhat létre, amelyek elegendő kontextust biztosítanak ahhoz, hogy a modell hasznos választ adjon. Győződjön meg arról, hogy optimalizálja a válaszhossz korlátját.

    Ez a vezérlési szint csak saját üzemeltetésű vezénylésben érhető el. Az Foundry Agent Service nem biztosít elegendő konfigurációt a funkció támogatásához.

• Válassza ki az ügynökhöz megfelelő modellt. Válassza ki a legkevésbé költséges modellt, amely megfelel az ügynök követelményeinek. Kerülje a magasabb költségű modellek használatát, hacsak nem nélkülözhetetlenek. A referencia-implementáció például egy GPT-5 sorozatú modellt használ, amely megfelel a forgatókönyv követelményeinek.

• A használat figyelése és kezelése. A Microsoft Cost Management és a modellhasználati metrikák használatával nyomon követheti a tokenhasználatot, költségvetéseket állíthat be, és riasztásokat hozhat létre az anomáliákhoz. Rendszeresen tekintse át a használati mintákat, és szükség szerint módosítsa a kvótákat vagy az ügyfélhozzáférést.

• Használja a megfelelő üzembehelyezési típust. Használjon használatalapú díjszabást a kiszámíthatatlan számítási feladatokhoz, és válassza a kiosztott átviteli kapacitást, ha a használat stabil és kiszámítható. A két lehetőség kombinálása megbízható alapkonfiguráció létrehozásakor.

• A játszótér használatának korlátozása. A nem tervezett gyártási költségek elkerülése érdekében korlátozza az Foundry játszótér használatát csak az előgyártási környezetekre.

• Gondosan tervezze meg a finomhangolást és a képgenerálást. Ezek a funkciók különböző számlázási modellekkel rendelkeznek. Óránként vagy kötegenként számlázzák őket. A használat ütemezése a számlázási időközökhöz igazodva és a pazarlás elkerülése érdekében.

Hálózati biztonsági erőforrások

Ez az architektúra Azure Firewall igényel kimenőforgalom-vezérlési pontként. A költségek optimalizálásához használja az alapszintű Azure Firewall, kivéve, ha a számítási feladatok többi összetevője speciális funkciókat igényel. A magasabb szintek költséggel járnak, ezért csak akkor használja őket, ha szüksége van a képességeikre. Az alapszintű szint kiválasztása előtt győződjön meg arról, hogy a korlátozások megfelelnek a számítási feladatnak. Az alapszintű szint korlátozza az átviteli sebességet, és korlátozott fenyegetésfelderítési képességekkel rendelkezik.

Ha a szervezet Azure célzónát használ, érdemes lehet megosztott tűzfalat és elosztott szolgáltatásmegtagadási (DDoS) erőforrásokat használni a költségek elhalasztásához vagy csökkentéséhez. A hasonló biztonsági és teljesítménykövetelményekkel rendelkező számítási feladatok kihasználhatják a megosztott erőforrások előnyeit. Győződjön meg arról, hogy a megosztott erőforrások nem jelentenek biztonsági vagy működési kockázatot. Megosztott erőforrásokat használó példáért tekintse meg az architektúra kezdőzóna-verzióját.

Felhőhöz készült Microsoft Defender

Az architektúra kapcsolódó erőforrásainak lefedéséhez használja az alábbi Cloud Workload Protection-csomagokat.

Terv	Előny
Szerverekhez készült Microsoft Defender	Észleli a biztonsági réseket, és figyeli a fájlintegritást, hogy megakadályozza a magas jogosultságú jump boxokat és az ügynököket abban, hogy fenyegetésvektorokká váljanak.
Microsoft Defender az App Service-hez	Naplókat, gazdagépeket és felügyeleti felületeket figyel a csevegés felhasználói felületének összetevőihez.
Azure Cosmos DB-hez készült Microsoft Defender	Figyeli az adatbázis-interakciókat a csevegési adatokhoz és az ügynökdefiníciókhoz való esetleges visszaélés vagy jogosulatlan hozzáférés jelei esetén.
Microsoft Defender AI-szolgáltatásokhoz	Riasztások az ügynökkérelmek és válaszok alapján történő feltörési kísérletekről vagy adatszivárgásról. Ha a szervezet Microsoft Purview használ, ez a csomag a Microsoft Purview adatbiztonságiállapot-kezelés AI-hoz (AI-hez készült DSPM) integrációját is biztosítja.

Ha a szervezet biztonsági információ- és eseménykezelési (SIEM) megoldást vagy Microsoft Purview használ, győződjön meg arról, hogy az ilyen adattárakba replikált ügyféladatok, például a kérések és válaszok olyan régióban találhatók, amely megfelel a számítási feladat adatelkülönülönülési követelményeinek.

Működési kiválóság

Az Operational Excellence azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben működtetik. További információ: Működési kiválóságitervezési felülvizsgálati ellenőrzőlistája.

Az alábbi működési kiválósági útmutató nem tartalmazza az előtérbeli alkalmazáselemeket, amelyek változatlanok maradnak az alapkonfigurációban magas rendelkezésre állású zónaredundáns webalkalmazás-architektúrával.

A kísérletezési, tesztelési és éles környezetek tervezésekor alakítson ki külön és elszigetelt Foundry-erőforrásokat, beleértve a függőségeket is.

Ügynöki számítástechnika

Microsoft kezeli az Foundry Agent Service REST API-k kiszolgáló nélküli számítási platformját és a vezénylés implementálási logikáját. Egy hosztolt ügynök a saját vezénylési kódját futtatja ezen a Foundry által felügyelt számítási környezeten. A saját üzemeltetésű orchestráció még nagyobb ellenőrzést biztosít a futtatási jellemzők és a kapacitás felett, de a platform folyamatos üzemeltetési feladatait közvetlenül Önnek kell kezelnie. Értékelje ki a megközelítése korlátait és felelősségeit, hogy megértse, mely második napi műveleteket kell végrehajtania az orchestration réteg támogatásához.

Az állapotkezelési felelősség a protokollkonfigurációt követi, nem a számítási megközelítést. Az ügynökök és az üzemeltetett ügynökök egyaránt támogatják a szolgáltatás által felügyelt beszélgetéseket, ahol a platform megőrzi a csevegési előzményeket, vagy az ügyfél által felügyelt beszélgetéseket, ahol a kód továbbviszi az állapotot. A saját üzemeltetésű orchesztráció mindig a saját állapotát kezeli. A csevegési előzmények és az ügynökkonfiguráció tartós tárolói minden esetben az előfizetésben találhatók, így Öné a tartósság, a biztonsági mentés és a helyreállítás.

Ügynök-interakciós SDK

Használja az Microsoft Agent Framework futtatókörnyezeti SDK-t az ügyfélalkalmazásban az üzenetek ügynököknek való küldéséhez, a beszélgetések kezeléséhez és a válaszok feldolgozásához. Az Agent Framework támogatja a C# és a Python. Ha az ügyfélalkalmazás javaScriptet vagy Java igényel, használja közvetlenül az Foundry SDK-t ezekhez a futtatókörnyezeti interakciókhoz.

Az Foundry SDK-t az ügyfél SDK-jának választásától függetlenül használhatja a platformkezelési műveletekhez. A központilag felügyelt ügynökdefiníciók létrehozása és verziószámozása CI-/CD-folyamatokban és IaC-folyamatokban, nem az ügyfélalkalmazás kódjában található.

Az Agent Framework és a Foundry integrálásáról további információt az Microsoft Agent Framework Foundry szolgáltató című témakörben talál.

Megfigyelés

Az alapvető architektúrához hasonlóan ez az architektúra diagnosztikai adatokat küld az összes szolgáltatásból a számítási feladat Log Analytics munkaterületére. A konfiguráció minden szolgáltatáshoz rögzíti az összes elérhető naplókategóriát, kivéve az App Service-t. Előfordulhat, hogy éles környezetben nem minden naplókategóriára van szükség. Előfordulhat például, hogy az App Service csevegési felhasználói felületi alkalmazása csak AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogs és AppServiceAuthenticationLogs szükséges. A naplóstreamek finomhangolása az üzemeltetési igényeknek megfelelően.

Értékelje ki az architektúrában található erőforrásokhoz tartozó egyéni riasztásokat, például az Azure Monitor alapszintű riasztásokat. Vegye figyelembe a következő riasztásokat:

• AI Search-riasztások
• AI-szolgáltatásokra vonatkozó riasztások
• Web Apps riasztások

A tokenek használatának monitorozása a modelltelepítések során. Ebben az architektúrában a Foundry az Application Insights integrációján keresztül követi nyomon a jogkivonatok használatát.

A jump boxok és a buildügynök virtuális gépei magas jogosultsági szintű helyen találhatók, amely közvetlen hálózati hozzáférést biztosít ezeknek a virtuális gépeknek az architektúra összes összetevőjének adatsíkjához. Győződjön meg arról, hogy ezek a virtuális gépek elegendő naplót bocsátanak ki ahhoz, hogy megjeleníthessék, hogy a felhasználók mikor férnek hozzá hozzájuk, ki fér hozzá hozzájuk, és hogy mit csinálnak rajtuk a felhasználók.

Ügynök verziószámozása és életciklusa

Kezelje az egyes ügynököket önállóan üzembe helyezhető egységként a csevegési számítási feladaton belül, kivéve, ha kifejezetten úgy tervezi meg az alkalmazást, hogy a futtatókörnyezetben dinamikusan hozzon létre és töröljön ügynököket. Ezek az ügynökök életciklus-kezelési követelményekkel rendelkeznek, hasonlóan a számítási feladat többi mikroszolgáltatásához.

A szolgáltatáskimaradások elkerülése érdekében az alábbi megközelítések végrehajtásával biztosítsa az ügynökök biztonságos és szabályozott üzembe helyezését:

• Ügynökök definiálása kódként. Mindig tárolja az ügynökdefiníciókat, kapcsolatokat, rendszerkéréseket és konfigurációs paramétereket a forrásvezérlőben. Ez a gyakorlat biztosítja a nyomon követhetőséget és a reprodukálhatóságot. Kerülje a nem követett módosításokat az Foundry portálon keresztül.

• Az ügynök üzembe helyezésének automatizálása. Használja a számítási feladat folyamatos integrációs és folyamatos üzembehelyezési (CI/CD) folyamatait. A Foundry SDK-k segítségével hozhat létre, tesztelhet és helyezhet üzembe ügynök-szoftvermódosításokat a hálózatra csatlakoztatott buildügynökök által.

  Részesítse előnyben az önállóan üzembe helyezhető ügynök-pipeline-eket kisebb, növekményes módosításokhoz. Ügyeljen azonban arra, hogy a folyamatok kellő rugalmasságot biztosítsanak ahhoz, hogy az alkalmazáskóddal együtt üzembe helyezhesse őket, ha összehangolt frissítésekre van szükség. A módszer támogatásához lazán párosítsa a csevegő felhasználói felület kódját és a csevegőügynököket, hogy az egyik összetevő módosítása ne igényeljen egyidejű módosításokat a másikon.

• Tesztelés éles környezet előtt. Ügynök viselkedésének, kéréseinek és kapcsolatainak ellenőrzése az előkészületi környezetekben. Automatizált és manuális tesztek kombinációjával észlelhetők a regressziók, a biztonsági problémák és az ügynök viselkedésének nem szándékos változásai.

  Az Foundry Agent Service-ben definiált ügynökök nem meghatározott módon viselkednek, ezért meg kell határoznia, hogyan mérheti és tarthatja fenn a kívánt minőségi szintet. Hozzon létre és futtasson egy tesztcsomagot, amely a valós felhasználói kérdésekre és forgatókönyvekre adott ideális válaszokat ellenőrzi.

• Ügynökök verzióinak kezelése és nyomkövetés. Rendeljen hozzá egyértelmű verzióazonosítókat az egyes ügynökökhöz. Tartson nyilvántartást az aktív ügynökverziókról és azok függőségeiről, például a modellekről, adatforrásokról és eszközökről. Helyezzen üzembe új ügynökverziókat a meglévő verziók mellett a felhasználók vagy munkamenetek fokozatos bevezetésének, visszaállításának és szabályozott migrálásának támogatásához.

  A Foundry natív módon támogatja a nem módosítható ügynökverziókat. Minden alkalommal, amikor módosít egy ügynökdefiníciót, a Foundry létrehoz egy új verzió pillanatképet, amely megőrzi a korábbi konfigurációt. Használja ezt a beépített verzióelőzményt naplózási nyomvonalakhoz és visszaállítási célokhoz.

  Az üzemeltetett ügynökök esetében a frissítés elküldése többet jelent, mint egy konfigurációs pillanatkép létrehozása. Először létre kell hoznia és fel kell töltenie egy konténerképet, és a Foundry-ügynök verziója erre hivatkozik. A visszagördülés csak az ügynökvégpont verzióválasztóját egy korábbi verzióra irányítja vissza, újraépítés és új lemezkép nélkül. A jelen szakasz korábbi, forráskövetési, tesztelési és CI/CD-eljárásai mind a parancssori, mind a üzemeltetett ügynökökre érvényesek. Mivel Ön írja egy üzemeltetett ügynök kódját, ez egy olyan plusz lépést jelent, amely a prompt ügynököknél nincs: egy helyi buildelési és hibakeresési ciklust ehhez a végrehajtható kódhoz, mielőtt az belépne ezekbe a megosztott pipeline-okba.

  Nem minden futtatókörnyezeti változathoz van szükség új verzióra. A strukturált bemenetek paraméterezik az ügynökdefiníciókat. Az ügyfél kéréskor adja meg a tényleges értékeket, így egyetlen ügynökverzió képes felhasználóspecifikus vagy környezetspecifikus konfigurációkat kiszolgálni újra üzembe helyezés nélkül.

  Megjegyzés:

  A strukturált bemeneteket az utasításszövegre korlátozhatja, például beszúrhat egy felhasználónevet a rendszer parancssorába. Kerülje az eszközvégpont-tulajdonságok, például az MCP-kiszolgáló URL-címeinek sablonozását. A sablonalapú eszközvégpontok lehetővé teszik, hogy a hívó ügyfél átirányítsa az ügynököt tetszőleges külső szolgáltatásokra futásidőben, ami aláássa az architektúra statikus szabályozási helyzetét. A tűzfal teljes tartománynevét engedélyező lista továbbra is blokkolja a nem jóváhagyott célhelyeket, de maga az ügynökdefiníció már nem dokumentálja, hogy az ügynök mely végpontokat szeretné elérni.

• Modellverziók rögzítése és szabályozása. Az ügynök viselkedése az általa meghívott modellverziótól függ, ezért a modelltelepítést tekintse a változáskezelési folyamat részének. Állítsa be az üzembe helyezés verziófrissítési beállítását úgy, hogy ne frissítse automatikusan. Ez a beállítás megakadályozza, hogy egy automatikus modellfrissítés módosítsa az ügynök válaszait, mielőtt ellenőrizné az új verziót a tesztkészlettel.

• Hozzáférés-vezérlés és felhasználói szintű adatelkülönítés kényszerítése. Ebben az architektúrában a csevegő felhasználói felület alkalmazásrétege a végfelhasználók és az ügynökök közötti hozzáférési határ. A Foundry projekt API privát végpontok mögött helyezkedik el, és nem érhető el közvetlenül a felhasználók számára. Az alkalmazáskódnak a Microsoft Entra ID-n keresztül kell hitelesítenie a végfelhasználókat, továbbá minden egyes beszélgetést és a hozzájuk tartozó adatokat azonosítania kell a hitelesített személyazonosság alapján.

  Ha projektszintű API-kat használ, akkor a Foundry-projektben Foundry User szerepkörrel rendelkező bármely identitás interakcióba léphet a projekt összes ügynökével. Az alkalmazás hitelesítési és engedélyezési rétege, nem pedig a Foundry RBAC projektje kényszeríti ki, hogy mely felhasználók férhetnek hozzá az ügynökökhöz és beszélgetésekhez. A munkamenet-kezelést úgy tervezheti meg, hogy megakadályozza a felhasználók közötti adathozzáférést, és alkalmazza a számítási feladat adatszabályozási és adatmegőrzési szabályzatait az alkalmazás által tárolt beszélgetési adatokra.

• Tervezze meg a fokozatos bevezetést és a visszaállást. A Foundry nem nyújt beépített támogatást az ügynökök kék-zöld vagy kanári telepítéseihez. Ha ezekre az üzembehelyezési mintákra vagy a felhasználók szabályozott migrálására van szükség az ügynökverziók között, implementáljon egy útválasztási réteget, például egy API-átjárót vagy egy egyéni útválasztót az ügynök API előtt. Ez az útválasztási réteg lehetővé teszi a forgalom növekményes áthelyezését az ügynökverziók között, figyelheti az effektust, és készenlétben teljes váltást hajthat végre.

• Az ügynök eltávolításának koordinálása. Az ügynökök eltávolításakor koordinálja a folyamatot az alkalmazás állapotkezelési és felhasználói élményre vonatkozó követelményeivel. Az aktív csevegések megfelelő kezelése. A számítási feladat működési követelményeitől függően áttelepítheti a munkameneteket, rögzítheti a felhasználókat a régi ügynökverzióban, vagy új munkameneteket kérhet a felhasználóktól.

Teljesítményhatékonyság

A teljesítményhatékonyság azt jelenti, hogy a számítási feladat hatékonyan képes méretezni a felhasználói igényeket. További információ: Teljesítményhatékonyságtervezési felülvizsgálati ellenőrzőlistája.

Ez a szakasz az AI Search, a modelltelepítések, az MCP-kiszolgáló alhálózata és a Foundry teljesítményhatékonyságával foglalkozik.

Teljesítményhatékonyság az AI-keresésben

Az Foundry Agent Service-ben nem szabályozhatja az indexek számára küldött konkrét lekérdezéseket, mert az ügynökök kód nélküliek. A teljesítmény optimalizálásához koncentráljon arra, hogy mit szabályozhat az indexben. Figyelje meg, hogy az ügynök általában hogyan keresi le az indexet, és útmutatást nyújt az AI Search teljesítményének elemzéséhez és optimalizálásához.

Ha az indexkiszolgáló-finomhangolás önmagában nem oldja meg az összes szűk keresztmetszetet, fontolja meg az alábbi lehetőségeket:

• Cserélje le az AI Search közvetlen kapcsolatát egy ön által birtokolt API-val való kapcsolatra. Ez az API képes implementálni az ügynök lekérési mintáira optimalizált kódot.

• A vezénylési réteg újratervezésével saját vezénylési kódot futtathat, akár üzemeltetett ügynökként az Foundry által felügyelt számításban, akár saját üzemeltetésű vezénylésként, hogy a lekérdezéseket saját vezénylőkódjában definiálhassa és optimalizálhassa.

Teljesítményhatékonyság a modelltelepítésekben

• Határozza meg, hogy az alkalmazásnak kiosztott átviteli sebességre van-e szüksége, vagy használhatja-e a megosztott (használati) modellt. A kiosztott átviteli sebesség fenntartott kapacitást és kiszámítható késést biztosít, amely támogatja a szigorú szolgáltatási szintű célkitűzésekkel (SLO-kkal) rendelkező éles számítási feladatokat. A fogyasztási modell legjobb erőfeszítés-alapú szolgáltatást biztosít, és zajos szomszédok hatásait tapasztalhatja.

• Figyelje a provisionált használat kezelését, hogy elkerülje a túlméretezést vagy alulméretezést.

• Válasszon ki egy olyan beszélgetési modellt, amely megfelel a következtetés késésére vonatkozó követelményeknek.

• A hálózati késés minimalizálása érdekében helyezzen üzembe modelleket ugyanabban az adatrégióban, mint az ügynökök.

Azure AI-ügynök teljesítménye

Azure AI-ügynökök kiszolgáló nélküli számítási háttérrendszeren futnak, amely nem támogatja az egyéni teljesítményhangolást. Az ügynöktervezéssel azonban javíthatja a teljesítményt:

• Csökkentse a csevegőügynökhöz csatlakoztatott eszközök számát. Minden további kapcsolat megnövelheti az ügynökhívások teljes futásidejét, mivel az ügynök minden kéréshez meghívhatja az összes konfigurált eszközt.

• Az Azure Monitor és az Application Insights használatával nyomon követheti az ügynökök hívási idejét, az eszközök késését és a hibaarányokat. Rendszeresen tekintse át ezeket a metrikákat a lassú eszközkapcsolatok azonosításához.

• A tervezési rendszer vezérli az ügynököt arra, hogy hatékonyan használja a kapcsolatokat. Utasíthatja például az ügynököt, hogy csak szükség esetén kérdezi le a földelő adateszközöket, vagy kerülje a redundáns eszközmeghívásokat.

• Figyelheti azokat a szolgáltatási korlátokat vagy kvótákat, amelyek hatással lehetnek a teljesítményre a csúcshasználat során. Figyelje meg az olyan szabályozási mutatókat, mint a HTTP 429 vagy 503 válaszok, annak ellenére, hogy a kiszolgáló nélküli számítás automatikusan skálázódik.

MCP-kiszolgáló alhálózati kapacitása

Ez az architektúra egy dedikált /24 alhálózatot foglal le, amely a(z) Microsoft.App/environments számára van delegálva, így később üzembe helyezhet egy belső Azure Container Apps, munkaterhelési profilokat használó környezetet, amely MCP-kiszolgálókat futtat az ügynökök képességeinek bővítéséhez.

Öntödei ügynök alhálózati kapacitása

Az Foundry-ügynök alhálózatának helyet kell adnia az ügynökinfrastruktúra számára. A(z) Microsoft.App/environments számára van delegálva, és /24 CIDR-tartományt kell használnia. Ez a méret tartalmazza az adatproxyt, az alhálózat-delegálás által fenntartott címeket. A Foundry minden projekthez egy dedikált adatproxyt helyez üzembe, és minden proxy a forgalommal együtt skálázódik, ezért minél több a projekt és minél nagyobb a terhelés, annál több alhálózati IP-cím fogy. Ha üzemeltetett ügynököket vezet be, a platform minden egyidejűleg aktív ügynök-munkamenetet a saját számításában futtat, amely egy alhálózati IP-címet használ. Az ügynök-munkamenet az a izolált tesztkörnyezet, amelyet a platform a felhasználó kéréseinek feldolgozására hoz létre. A platform az első kéréskor létrehoz egy ügynökmunkamenetet. Mivel ez az architektúra szolgáltatás által felügyelt beszélgetéseket használ, a platform az ügynök munkamenetét a beszélgetéshez köti, és később újra felhasználja. A különálló egyidejű beszélgetések külön ügynök-munkamenetet használnak fel a saját számításaikban. Az ügynök-munkamenetek csak a számítás során használnak alhálózati IP-címet, ezért az alhálózatot az egyidejűleg futó ügynök-munkamenetek maximális számához méretezi, nem pedig az üzembe helyezhető ügynökök számához.

Az új üzemeltetett ügynök változatának üzembe helyezése ideiglenesen további IP-címeket használ, mivel a régi és az új változatok párhuzamosan futnak a bevezetés során. Az alhálózatok méretezéséről és az IP-foglalásokról az Foundry Agent Service hálózatkezelésének részletes ismertetése című témakörben olvashat. Egy Foundry-erőforrás nem tudja megosztani az ügynökalhálózatát egy másik Foundry-erőforrással, bár ha a számítási feladathoz több Foundry-erőforrásra van szükség, ugyanazon a virtuális hálózaton osztozhatnak.

A forgatókönyv üzembe helyezése

A referencia-implementáció üzembe helyezéséhez és futtatásához kövesse az üzembe helyezési útmutatót a Foundry Agent Service csevegési alapkonfigurációjának implementálásában.

A referencia-implementáció csevegőfelületi alkalmazása alapszintű, és bemutatja, hogyan kommunikálhat az ügynökvégpontokkal. A csevegés felhasználói felületének fejlettebb felhasználói felületére vonatkozó példákért tekintse meg az Foundry-ügynök webalkalmazás-adattárát.

Közreműködők

Microsoft fenntartja ezt a cikket. A következő közreműködők írták ezt a cikket.

Fő szerzők:

• Rob Bagby | Fő tartalomfejlesztő – Azure minták és Gyakorlatok
• Chad Kittel | Vezető szoftvermérnök – Azure minták és Gyakorlatok

Egyéb közreműködők:

• Raouf Aliouat | Vezető szoftvermérnök
• Freddy Ayala | Felhőmegoldás-tervező
• Prabal Deb | Fő szoftvermérnök
• Ritesh Modi | Fő szoftvermérnök
• Ryan Pfalz | Vezető műszaki programmenedzser

A nem nyilvános LinkedIn profilok megtekintéséhez jelentkezzen be a LinkedIn.

Következő lépés

• Baseline Foundry csevegőarchitektúra egy Azure célzónában

Kapcsolódó erőforrások

• A számítási feladatok Azure
• Azure OpenAI-modellek
• Védőkorlátok és vezérlők
• AI-ügynökök vezénylési mintái