Megosztás a következőn keresztül:

Az Azure AI Foundry csevegési referenciaarchitektúrája alapkonfigurációja

Azure OpenAI Service
Azure AI services
Azure App Service
Azure Monitor

A vállalati csevegőalkalmazások az AI-ügynökökkel folytatott beszélgetési interakciók révén segíthetik az alkalmazottakat. Ez a képesség egyre erősebb a nyelvi modellek, például az OpenAI GPT-modelljei és az olyan vezénylési SDK-k, mint a Szemantikus Kernel folyamatos fejlődésének köszönhetően. 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ésekhez kapcsolódó, tartományspecifikus információkat tartalmaznak.

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

  • Egy vezénylő vagy ügynök, amely felügyeli az adatforrások, a nyelvi modellek és a végfelhasználó közötti interakciókat.

Ez a cikk egy alaparchitektúrát biztosít a vállalati csevegőalkalmazások létrehozásához és üzembe helyezéséhez az Azure AI Foundry és az Azure OpenAI használatával a Foundry-modellekben. Ez az architektúra egyetlen, az Azure AI Foundry Agent Service-ben üzemeltetett ügynököt használ. Az ügynök megkapja a felhasználói üzeneteket, majd lekérdezi az adattárakat a nyelvi modell alapadatainak lekéréséhez.

A csevegőfelület az Azure App Service-webalkalmazás alapkonfigurációját követi, amely bemutatja, hogyan helyezhet üzembe biztonságos, zónaredundáns és magas rendelkezésre állású webalkalmazásokat az App Service-ben. Ebben az architektúrában az App Service szolgáltatásként (PaaS) kommunikál az Azure-platformmal 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. Az Azure AI Foundry portálhoz és az ügynökökhöz való nyilvános hozzáférés le van tiltva.

Fontos

Ez a cikk nem ismerteti az alapkonfigurációs App Service-webalkalmazás-architektúrából származó összetevőket vagy architektúra-döntéseket. A csevegőfelületet tartalmazó webalkalmazás üzemeltetéséről szóló architekturális útmutatásért olvassa el ezt a cikket.

Ez az architektúra a Foundry Agent Service standard ügynökbeállításával teszi lehetővé a nagyvállalati szintű biztonságot, megfelelőséget és ellenőrzést. Ebben a konfigurációban saját hálózatot hoz a hálózatelkülönítéshez, valamint saját Azure-erőforrásait a csevegés és az ügynökállapot tárolásához. Az alkalmazásösszetevők és az Azure-szolgáltatások közötti minden kommunikáció privát végpontokon keresztül történik, ami 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ő szabályokat.

Jótanács

Az Foundry Agent Service referencia-implementációja egy alapkonfigurációt mutat be az Azure-beli csevegéshez. Ez alapként szolgál az egyéni megoldások fejlesztéséhez, miközben az éles környezet felé halad.

Építészet

Az Azure AI Foundryt használó alapszintű, végpontok közötti csevegési architektúrát bemutató ábra.

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

Munkafolyamat

  1. Egy alkalmazásfelhasználó csevegőfelülettel kommunikál. A kérések átirányítása az Azure Application Gatewayen keresztül történik. Az Azure Web Application Firewall ellenőrzi ezeket a kéréseket, mielőtt továbbítanák őket a háttérbeli App Service-nek.

  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 Azure AI Agent SDK-val kommunikál az ügynökkel. 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 Azure AI 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 modellt és csatlakoztatott eszközöket és tudástárakat használ.

  4. Az ügynök egy privát végponton keresztül csatlakozik a magánhálózat tudástárához (Azure AI Search).

  5. Külső tudástárakra vagy eszközökre, például a Wikipédiára vagy a Bingre irányuló kérések az Azure Firewallon való ellenőrzésre és a kimenő szabályzatok érvényesítésére.

  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 a betekintett tudástárak listáját egy dedikált memóriaadatbázisban . Ez az adatbázis fenntartja a teljes beszélgetési előzményeket, amely lehetővé teszi 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.

    Az Azure AI Foundry API-k támogatják olyan felhasználói élmények fejlesztését, amelyek több egyidejű, környezettől elkülönített beszélgetést kezelnek.

Összetevők

Ez az architektúra az Azure AI Foundry egyszerű csevegési referenciaarchitektúrájá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 biztosítja a csevegések vezénylési rétegét. 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 koordinálása
    • 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, amelyeket a Foundry Agent Service kizárólag felügyel. A számítási feladat más alkalmazásösszetevői nem használhatják ezeket a szükséges erőforrásokat.

    • Az Azure Cosmos DB for NoSQL az előfizetésen belül üzemelteti a számítási feladat memóriaadatbázisát.enterprise_memory Ez az adatbázis tárolja az ügynök működési állapotát, beleértve a csevegési szálakat é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.

    • Egy dedikált Azure Storage-fiók tárolja a csevegések során feltöltött fájlokat. 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.

    • Egy dedikált AI Search-példány az ügynökkel folytatott beszélgetésekből származó feltöltött fájlok kereshető, darabolt indexét tárolja. Emellett olyan statikus fájlokat is tárol, amelyeket az ügynök létrehozásakor tudásforrásként adnak hozzá. 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 biztonságos, méretezhető belépési pontként szolgál a csevegő felhasználói felületre irányuló ÖSSZES HTTP- és HTTPS-forgalomhoz. Transport Layer Security (TLS) leállást és útvonalalapú útválasztást biztosít. Emellett a kérelmeket a rendelkezésre állási zónák között is elosztja, amely 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.

    • Az Azure Web Application Firewall 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.

    • Az Azure Key Vault biztonságosan tárolja és kezeli az Application Gateway által igényelt TLS-tanúsítványokat. A Key Vault központi 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.

  • Az Azure Virtual Network minden összetevőhöz biztosítja a hálózatelkülönítést. 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 engedélyezheti a bejövő és kimenő folyamatok ellenőrzését. Ez a beállítás segít megfelelni a biztonsági és megfelelőségi követelményeknek.

  • Az Azure Private Link az összes PaaS-szolgáltatást, például az Azure Cosmos DB-t, a Storage-t, az AI Search-t és az Foundry Agent Service-t privát végpontokon keresztül csatlakoztatja a virtuális hálózathoz. Ez a megközelítés biztosítja, hogy az összes adatforgalom az 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.

  • Az Azure Firewall ellenőrzi és szabályozza a virtuális hálózatról kimenő (kimenő) forgalmat. Teljes tartománynevet (FQDN)-alapú szabályokat kényszerít ki, í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.

  • Az Azure DNS privát dns-zónákat biztosít a virtuális hálózathoz. Ez a funkció lehetővé teszi a privát végpontok névfeloldását, ami 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.

  • A Storage zip-fájlként tárolja a webalkalmazás kódját az App Service-ben való üzembe helyezéshez. Ez a módszer 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.

Alternatívák

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 vezénylése

Jelenlegi megközelítés: Ez az architektúra a Foundry Agent Service-t használja a csevegési folyamatok vezénylésére, beleértve az adatok tudásbázisból való lekérését és az Azure OpenAI-modellek meghívását. A Foundry Agent Service kód nélküli, nemdeterminista vezénylést biztosít. Kezeli a csevegési kérelmeket, a szálkezelést, 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. Natív memóriaadatbázis-megoldást biztosít.

Alternatív megközelítés: A vezénylési réteget olyan keretrendszerek használatával üzemeltetheti, mint a Szemantikus Kernel vagy a LangChain. Ezekkel a keretrendszerekkel determinisztikus, kódalapú csevegési folyamatokat és egyéni vezénylési logikát valósíthat meg.

Fontolja meg ezt az alternatívát, ha a számítási feladathoz a következő képességek szükségesek:

  • Részletes, determinisztikus vezérlés a vezénylési sorrend, az eszközhívás vagy a gyors tervezés felett

  • Integrálás egyéni üzleti logikával vagy külső rendszerekkel, amelyeket a Foundry Agent Service natív módon nem támogat

  • Speciális ügyfélkérések útválasztása kísérletezéshez vagy biztonságos üzembe helyezési eljárásokhoz

  • Egyéni memóriaadatbázis-megoldás, amely eltér a natív Foundry Agent Service-megoldástól

A saját üzemeltetésű vezénylés növeli a működési összetettséget, és megköveteli a számítás, a skálázás és a biztonság kezelését.

Alkalmazásréteg összetevői

Jelenlegi 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ások számára. A Web Apps natív módon integrálható az Azure hálózati és biztonsági funkcióival.

Alternatív megközelítés: Az alkalmazásszint üzemeltetéséhez használhat más Azure-beli felügyelt számítási platformokat is, például az Azure Container Appst vagy az Azure Kubernetes Service-t (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.

Adatok (tudástár) őrzése

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 az Azure Cosmos DB-t, az Azure SQL Database-t vagy más 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

  • Többmodelles vagy SDK-támogatást igényel, amely nem érhető el az AI Searchben

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

A vektoros keresés gyakori a lekéréses kiterjesztett generációhoz, de nem mindig szükséges. További információ: Azure-szolgáltatás kiválasztá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.

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 mikroszolgáltatásként van üzembe helyezve az Azure AI Foundryben. 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 Azure AI Agent SDK használatával dinamikusan hozhat létre vagy módosíthat ügynököket futtatókörnyezetben. Ez a módszer lehetővé teszi az alkalmazás számára az ügynökök igény szerinti példányosítását, a rendszerkérések módosítását vagy a kapcsolatok újrakonfigurálását 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 a számítási feladat felhasználói élményére vonatkozó követelményeknek megfelelő ügynöki megközelítést.

Megfontolások

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek készlete. További információ: Microsoft Azure Well-Architected Framework.

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

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információkért tekintse meg a Megbízhatósági terv felülvizsgálati ellenőrzőlistát.

Az alapkonfigurációs App Service-webalkalmazás-architektúra a fő regionális szolgáltatások zonális redundanciájával foglalkozik. 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, előfordulhat, hogy a régió más régióira nem lesz hatással. Az architektúra emellett elosztja az Azure-szolgáltatások példányait és konfigurációit a rendelkezésre állási zónák között. További információ: Alapkonfiguráció magas rendelkezésre állású zónaredundáns webalkalmazás.

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

Zónaredundancia a vezénylési rétegben

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

Ebben az architektúrában az Azure AI Foundry üzemelteti az Foundry Agent Service szolgáltatást. Az ügynök megbízhatósága az Öntödei ügynök szolgáltatás függőségeitő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éteghez tartozó zonális redundancia eléréséhez kövesse az alábbi javaslatokat:

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ő tudástárakkal, 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 AI Foundry portál, az adatsík API-k és az Foundry Agent Service képessége nem biztosít közvetlen vezérlőket a zónaredundanciához.

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

Az Azure AI 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últerhelést a túlterjedt forgalom vagy hibák kezeléséhez. 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 Azure AI Foundry nem támogatja a fejlett terheléselosztási vagy feladatátvételi mechanizmusokat, például a ciklikus időszeleteléses útválasztást vagy a kapcsolatcsoporttöré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 az 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 vagy tudástárakként is elérhetővé teheti az ügynök számára. További információ: Átjáró használata több Azure OpenAI-példány vagy -példány előtt.

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 szabályozását.

  • 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 Firewallban

Az 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ítse az Azure Firewallt a régió összes rendelkezésre állási zónájá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 az Azure Firewallt 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éget tapasztal, tekintse át a tűzfal metrikáit és naplóit az SNAT kimerülésének vagy egyéb szűk keresztmetszeteinek 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, az Azure Cosmos DB vagy a Storage erőforrásait az ügynökszolgáltatás és más alkalmazásösszetevők között. Ehelyett dedikált példányokat kell kiosztaniuk az ügynökszolgá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 meghibásodásait 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 az erőforrásokat használó számítási feladat folyamatának konkrét rendelkezésre állási és helyreállítási követelményeihez vannak hangolva.

Ha például a csevegő felhasználói felület alkalmazásának tranzakciós állapotot kell tárolnia az Azure Cosmos DB-ben, akkor erre a célra külön Azure Cosmos DB-fiókot és adatbázist kell kiépítenie 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 visszavonásra kerülnek, és értesítés nélkül vá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 az adatfeldolgozáshoz, és a mögöttes adatokat csak átlátszatlanként és monitorozással kezelje.

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ón belül. 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 feladatátvételhez
  • 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 régió rendelkezésre állásának vizsgálata a fejlesztői élményekhez, beleértve az Azure AI 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:

  • Adatok földelése (tudástárak)
  • 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ési architektúrák állapotalapú összetevőket tartalmaznak, ezért a dr. Ezek a számítási feladatok általában memóriatárolót igényelnek az aktív vagy szüneteltetett csevegésekhez. Emellett a csevegési szálakhoz hozzáadott kiegészítő adatok, például dokumentumok vagy képek tárolására is szükség van. 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 az Azure Cosmos DB, a Storage és az AI Search használatával megőrzi 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.

Az Foundry Agent Service esetében győződjön meg arról, hogy az összes függőséget konzisztens időpontra állíthatja vissza. Ez a megközelítés segít fenntartani a tranzakciós integritást a három külső függőség között.

Az alábbi javaslatok az egyes szolgáltatásokra vonatkozó DR-hez szólnak:

  • Azure Cosmos DB: Engedélyezze a folyamatos biztonsági mentést az enterprise_memory adatbázishoz. Ez a beállítás egy hétnapos RPO-val biztosítja az időponthoz kötött visszaállítást (PITR), amely ügynökdefiníciókat és csevegési szálakat tartalmaz. 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álatához az indexek helyreállításához. 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. Ez a gyakorlat biztosítja, hogy szükség esetén újraépítse az indexeket.

  • 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 a feladatátvétel kezdeményezését egy regionális kimaradás során. Ha csak zónaredundáns tárolást használ, forduljon a Microsoft ügyfélszolgálatához az adatok visszaállításához. Ez a folyamat kibővítheti az RTO-t. Az AI Search szolgáltatáshoz 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, akkor előfordulhat, hogy nincs szüksége blobtárolók dr. csomagjára.

  • Tranzakciós konzisztencia: Ha a számítási feladat állapottárolója Azure AI-ügynökazonosítókra, például szálazonosí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 számítási feladat és az ügynökszolgá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 AI Foundry portálon vagy az adatsík API-ján keresztül. Ez a megközelítés biztosítja, hogy az üzembe helyezett ügynökök reprodukálhatóak maradjanak.

Mielőtt éles környezetbe lép, hozzon létre egy helyreállítási runbookot, amely az alkalmazás tulajdonában lévő és az ügynök által birtokolt állapotban előforduló hibákra is megoldást nyújt.

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 kiterjeszti az Azure AI Foundry egyszerű csevegési referenciaarchitektúrájában létrehozott biztonsági alapokat. Az elsődleges különbség a hálózati biztonsági szegély hozzáadása az alapszintű architektúrából származó identitáshatár 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 az Azure-szolgáltatásokban.

Ez a szakasz a kulcsforgatás és az Azure OpenAI-modell finomhangolásával kapcsolatos hálózatkezelési és biztonsági szempontokat ismerteti.

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. Különálló felügyelt identitások kiépítése a következő összetevőkhöz:

    • Az Azure AI Foundry-fiók
    • Minden Egyes Azure AI Foundry-projekt
    • A webalkalmazás
    • Bármely egyéni vezénylő vagy integrációs kód

  • 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.

Az Azure AI Foundry Portál alkalmazotti hozzáférése

Amikor az alkalmazottakat Azure AI Foundry-projektekbe készíti, rendelje hozzá a szerepkörükhöz szükséges minimális engedélyeket. A feladatok elkülönítésének kikényszerítéséhez használja a Microsoft Entra azonosítócsoportokat és a szerepköralapú hozzáférés-vezérlést (RBAC). Megkülönbözteti például az ügynökfejlesztőket az adattudósoktól, akik finomhangolási feladatokat végeznek. Azonban vegye figyelembe a korlátozásokat és kockázatokat.

Az Azure AI 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 RBAC-szerepkörökkel rendelkező alkalmazottak láthatják a bizalmas adatokat, például a csevegési szálakat, az ügynökdefiníciókat és a konfigurációt. Ez az AI Foundry 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örnyezetekben olyan alkalmazottak számára, akiknek egyértelmű működési igényük van. A legtöbb alkalmazott esetében tiltsa le vagy tiltsa le az Azure AI 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.

Az Új projektek létrehozása az Azure AI Foundry-fiókban kiemelt műveletként kezelhető. A portálon létrehozott projektek nem öröklik automatikusan a meglévő hálózati biztonsági vezérlőket, például privát végpontokat vagy hálózati biztonsági csoportokat (NSG-k). És a projektek új ügynökei 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.

Azure AI Foundry-projektszerepkör-hozzárendelések és kapcsolatok

Az Foundry Agent Service standard módban való használatához a projektnek rendszergazdai 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 Storage-fiókban, az AI Searchben é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 AI 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, a minimális jogosultság elve megköveteli, hogy minden egyes különböző ügynök hozzáférési mintájához külön Azure AI Foundry-projektet hozzon létre. 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.

Ha külső erőforrásokhoz létesít kapcsolatot az Azure AI Foundryben, akkor használja a Microsoft Entra ID-alapú hitelesítést, ha van ilyen. Ez a megközelítés szükségtelenné teszi az előre felosztott titkos kulcsok fenntartását. Az egyes kapcsolatok hatóköre, 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 Azure AI Foundry-fiók szintjén. Ezek a kapcsolatok a fiókban lévő összes jelenlegi és jövőbeli projektre 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 részesítsen előnyben.

Kapcsolatteremtés

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 definiált útvonalak (UDR- é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 a 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

Az Alapszintű App Service webalkalmazás-architektúrából és az Foundry Agent Service hálózatkezelési folyamatából származó két hálózati folyamatot bemutató ábra.

Az alapszintű App Service-webalkalmazás-architektúra felvázolja 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 az Azure PaaS-szolgáltatásokba irányuló folyamatot. Ez a szakasz az ügynökök interakcióira összpontosít.

Amikor a csevegőfelület kommunikál az Azure AI Foundryben üzembe helyezett ügynökkel, a következő hálózati folyamatok következnek be:

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

  2. Amikor az ügynök hozzáfér az 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, HTTPS-kéréseket küld a delegált alhálózatról ezeknek a szolgáltatásoknak a privát végpontjaira.

  3. Amikor az ügynök hozzáfér a virtuális hálózaton kívüli erőforrásokhoz, beleértve az internetalapú API-kat vagy a külső szolgáltatásokat, a https-kérelmeket a delegált alhálózatról az Azure Firewallon keresztül kell irányítania.

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.

Bejövő forgalom az Azure AI Foundrybe

Ez az architektúra letiltja az Azure AI Foundry adatsíkhoz való nyilvános hozzáférést azáltal, hogy csak privát kapcsolaton keresztül engedélyezi a forgalmat az Azure AI Foundry számára. Az Azure AI 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 AI Foundry-fiók 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 adatelemzőknek jump boxon, társhálózaton, ExpressRoute-on vagy helyek közötti VPN-kapcsolaton keresztül kell hozzáférniük a portálhoz.

Az ügynök adatsíkjával való minden programozott interakciónak, például a webalkalmazásból vagy a külső vezénylési kódból a modellkövetkeztetés meghívása során, ezeket a privát végpontokat is használnia kell. A privát végpontok a fiók szintjén vannak definiálva, nem a projekt szintjén. Ezért a fiókon belüli összes projekt ugyanazt a végpontkészletet használja. A hálózati hozzáférés projektszinten nem szegmentelhető, és minden projekt azonos hálózati expozícióval rendelkezik.

A konfiguráció támogatásához állítsa be a DNS-t a következő Azure AI 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ő az Azure Bastionon keresztül egy virtuális gép (VM) jump boxjához. Ebből a jump boxból a szerző hozzáférhet a projekthez az Azure AI Foundry portálon egy privát végponton keresztül ugyanabban a hálózatban.

Egy diagram, amely bemutatja, hogyan csatlakozik egy felhasználó egy jump box virtuális géphez az Azure Bastionon keresztül.

Forgalom szabályozása az Azure AI Foundry-ügynök alhálózatáról

Ez az architektúra az Összes kimenő (kimenő) hálózati forgalmat átirányítja az Foundry Agent Service képességből egy delegált alhálózaton keresztül a virtuális hálózaton belül. Ez az alhálózat szolgál egyetlen kimenő pontként az ügynök szükséges három szolgáltatásfüggőségéhez, valamint az ügynök által használt külső tudásbázisokhoz vagy eszközkapcsolatokhoz. Ez a kialakítás segít csökkenteni az adatkiszivárgási kísérleteket a vezénylési logikából.

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.

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 Azure Firewallon keresztül irányítja az összes HTTPS-forgalmat. 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öknek csak a Bing nyilvános API-kkal kell elérnie a Földelést , konfigurálja az Azure Firewallt, hogy engedélyezze a forgalmat api.bing.microsoft.com a 443-as porton ebből az alhálózatból. A rendszer minden más kimenő célhelyet elutasít.

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
Alkalmazási átjáró
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 -
Alkalmazásszolgáltatás
snet-appServicePlan		 Nem engedélyezett forgalom Privát végpontok és Azure Monitor Igen Az Azure Monitorba
Öntödei Ügynökségi Szolgáltatás
snet-agentsEgress		 Nem engedélyezett forgalom Privát végpontok és az internet Igen Csak olyan nyilvános teljes tartománynevek, amelyek használatát engedélyezi az ügynököknek
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ény 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ény 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 NSG-szabályokon keresztül, akár alapértelmezés szerint az Azure Firewallban.

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-csomagot 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.

Szabályozás szabályzaton keresztül

A számítási feladat biztonsági alapkonfigurációjához az Azure Policy és a hálózati szabályzatok használatával biztosíthatja, hogy minden számítási feladat erőforrása megfeleljen 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:

  • Tiltsa le a kulcsalapú vagy más helyi hitelesítési módszereket olyan szolgáltatásokban, mint az Azure AI-szolgáltatások é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 az 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 az Azure-díjszabási becslés egy díjszabási példát kínál ehhez az architektúrához. Ez a példa csak az architektúra összetevőit tartalmazza, ezért a használatnak megfelelően testre szabhatja. A forgatókönyv legdrágább összetevői az 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 ki kell építenie és kezelnie kell a szolgáltatás függőségeit a saját Azure-előfizetésében.

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

  • Az Foundry Agent Service kezeli a kérelemegységek (RU) lefoglalását az Azure Cosmos DB-ben. A hosszú távú költségek csökkentése érdekében vásároljon fenntartott kapacitást az Azure Cosmos DB-hez. A foglalások igazítása a várt használati időtartamhoz és kötethez. Ne feledje, hogy a fenntartott kapacitás előzetes elkötelezettséget igényel, és nem biztosít rugalmasságot, 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 azok kapcsolódó szálait az SDK vagy REST API-k használatával. Az elavult ügynökök és szálak továbbra is tárolót használnak, és növelhetik a költségeket az Azure Cosmos DB, a Storage és az AI Search esetében.

  • Tiltsa le a számítási feladathoz nem szükséges függő erőforrások funkcióit, például a következő funkciókat:

    • A szemantikai rangsoroló az AI Searchben
    • Az átjáró és a többrégiós írási képességek az Azure Cosmos DB-ben

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

  • Kerülje a számítási feladatokra vonatkozó adatok áthelyezését ugyanabban az Azure Cosmos DB- vagy AI Search-erőforrásban, amelyet a Foundry Agent Service használ. Bizonyos esetekben megoszthatja ezeket az erőforrásokat, hogy csökkentse a nem használt kapacitást a kérelemegységekben vagy a keresési egységekben, ami csökkenti 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. Minden kéréshez meghívhat bármely csatlakoztatott tudástárat, eszközt vagy más ügynököt, még akkor is, ha az erőforrás 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 a tudástárakat, eszközöket vagy ügynököket csatlakoztassa, amelyeket valószínűleg a legtöbb ügynökhíváshoz használnak. Kerülje a ritkán szükséges vagy az egyes hívásokhoz magas költségekkel járó erőforrások csatlakoztatását, hacsak nem nélkülözhetetlenek.

  • Gondosan tervezzen és finomítsa a rendszerkérést, hogy az ügynök a szükségtelen vagy redundáns külső hívások minimalizálására utasítsa az ügynököt. 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 Azure AI Foundry telemetriával figyelheti, hogy mely külső API-khoz, tudástárakhoz vagy eszközökhöz fér hozzá az ügynök, milyen gyakran éri el őket, és milyen költségekkel jár. Rendszeresen tekintse át ezt a telemetriát 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 a forgalmi díjas API-kkal való integráció esetén. 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

Az Azure AI Foundry modelltelepítései 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. Az ügyfélkérések a legtöbb költséget a használati modellben hajtják, ezért az ügynök viselkedésének szabályozása kulcsfontosságú.

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

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

    • Kényszerítse ki a jogkivonat-korlátozó korlátozásokat, például max_tokens az ügynöklogikán keresztül.max_completions Ez a vezérlő csak saját üzemeltetésű vezénylésben érhető el. Az Foundry Agent Service nem támogatja ezt a funkciót.

    • Optimalizálja a parancssori bemenet és a válasz hosszát. A hosszabb kérések több jogkivonatot használnak fel, ami növeli a költségeket. Olyan kérések, amelyek nem rendelkeznek elegendő kö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 a GPT-4o-t használja egy drágább modell helyett, és megfelelő eredményeket ér el.

  • A használat figyelése és kezelése. A Microsoft Cost Management és a modell telemetriájának használatával nyomon követheti a jogkivonatok használatát, 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. További információ: Az Azure AI Foundry költségeinek megtervezése és kezelése.

  • Használja a megfelelő üzembehelyezési típust. Használatalapú fizetéses díjszabás használata kiszámíthatatlan számítási feladatokhoz, és ha a használat stabil és kiszámítható, váltson a kiosztott átviteli sebességre. 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 Azure AI 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

Ehhez az architektúrához az Azure Firewallra van szükség kimenőforgalom-vezérlési pontként. A költségek optimalizálásához használja az Azure Firewall alapszintű szintjét, 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.

Ha a szervezet Azure-beli célzónákat használ, fontolja meg a megosztott tűzfal és az elosztott szolgáltatásmegtagadási (DDoS-) erőforrások használatát 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. Ez az Azure-beli célzónában üzembe helyezett architektúra megosztott erőforrásokat használ.

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ó: Az operatív kiválóság tervezé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 hozzon létre különálló és elkülönített AI Foundry-erőforrásokat, beleértve a függőségeket is.

Ügynök számítása

A Microsoft teljes mértékben felügyeli az Azure AI Agent 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. A saját üzemeltetésű vezénylés nagyobb ellenőrzést biztosít a futtatókörnyezet jellemzői és kapacitása felett, de közvetlenül kell kezelnie a 2. nap műveleteit az adott platformon. Értékelje ki a megközelítés korlátait és felelősségi körét, hogy megértse, mely 2. napi műveleteket kell végrehajtania a vezénylési réteg támogatásához.

Mindkét megközelítésben kezelnie kell az állapottárolást, például a csevegési előzményeket és az ügynökkonfigurációt a tartósság, a biztonsági mentés és a helyreállítás érdekében.

Megfigyelés

Az alapvető architektúrához hasonlóan az összes szolgáltatás diagnosztikai adatai úgy van konfigurálva, hogy a számítási feladat Log Analytics-munkaterületére legyenek elküldve. Az App Service kivételével minden szolgáltatás rögzíti az összes naplót. Éles környezetben előfordulhat, hogy nem kell minden naplót rögzítenie. Előfordulhat például, hogy a csevegőfelület-alkalmazás csak AppServiceHTTPLogs, , AppServiceConsoleLogs, AppServiceAppLogsAppServicePlatformLogsés AppServiceAuthenticationLogs. Hangolja a naplóstreameket a működési igényeihez.

Az architektúra erőforrásainak egyéni riasztásai, például az Azure Monitor alapszintű riasztásaiban szereplő egyéni riasztások kiértékelése. Vegye figyelembe a következő riasztásokat:

A jogkivonatok használatának monitorozása a modelltelepítések során. Ebben az architektúrában az Azure AI Foundry nyomon követi a jogkivonatok használatát az Application Insightsba való integrációja révén.

A jump boxok és a buildügynök virtuális gépei magas jogosultsági szintű helyen találhatók, így ezek a virtuális gépek hálózati látóvonalat biztosítanak 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 megértsék, mikor használják őket, ki használja őket, és milyen műveleteket hajtanak végre.

Ü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 Azure AI 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. Az Azure AI-ügynök SDK-val hozhat létre, tesztelhet és helyezhet üzembe ügynökmódosításokat a hálózattal csatlakoztatott buildügynökökből.

    Előnyben részesítheti az önállóan üzembe helyezhető ügynökfolyamatokat 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ója és nyomon követése. Rendeljen hozzá egyértelmű verzióazonosítókat az egyes ügynökökhöz. Az ügynökverziók és függőségeik, például modellek, adatforrások és eszközök nyilvántartása. A felhasználók vagy munkamenetek fokozatos bevezetésének, visszaállításának és szabályozott migrálásának lehetővé tétele érdekében inkább helyezzen üzembe új ügynökverziókat a meglévők mellett.

  • Tervezze meg a feladat-visszavételt. Az Azure AI Foundry nem nyújt beépített támogatást az ügynökök kék-zöld vagy kanári üzemelő példányaihoz. Ha ezekre az üzembehelyezési mintákra van szüksége, 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 hatást, és készenlétben teljes átállást hajthat végre.

  • Koordináta-ügynök eltávolítá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ót a Teljesítményhatékonyság tervezési felülvizsgálati ellenőrzőlistájában talál.

Ez a szakasz az AI Search, a modelltelepítések és az Azure AI Foundry teljesítményhatékonyságával foglalkozik.

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ése a saját üzemeltetésű alternatíva használatára, 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, ami a szigorú szolgáltatási szintű célkitűzésekkel rendelkező éles számítási feladatok esetében fontos. A fogyasztási modell a legjobb munkamennyiséget biztosítja, és zajos szomszédhatások jelentkezhetnek.

  • Figyelheti a kiépítés által felügyelt használatot , hogy elkerülje a túlterjedést vagy az alulbontá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.

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

Az 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 továbbra is javíthatja a teljesítményt:

  • Csökkentse a csevegőügynökhöz csatlakoztatott tudástárak és 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 erőforrást.

  • 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- és tudástár késéseit, valamint a hibaarányokat. Rendszeresen tekintse át ezt a telemetriát a lassú tudás vagy eszközkapcsolatok azonosításához.

  • A tervezőrendszer kéri, hogy az ügynök hatékonyan használja a kapcsolatokat. Utasíthatja például az ügynököt, hogy csak szükség esetén kérdezze le a külső tudástárakat, 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 az 503 válaszok, annak ellenére, hogy a kiszolgáló nélküli számítás automatikusan skálázódik.

A forgatókönyv üzembe helyezése

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

Közreműködők

A 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 -eljárások
  • Chad Kittel | Fő szoftvermérnök – Azure-minták és gyakorlatok

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

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

Következő lépés