Az OpenAI végpontok közötti csevegés referenciaarchitektúrája

A vállalati csevegőalkalmazások képessé teszik az alkalmazottakat beszélgetési interakciókon keresztül. Ez különösen igaz a nagy nyelvi modellek, például az OpenAI GPT-modelljei és a Meta LLaMA-modelljeinek folyamatos fejlődése miatt. Ezek a csevegőalkalmazások a csevegés felhasználói felületéből, a felhasználó lekérdezéseihez kapcsolódó tartományspecifikus információkat tartalmazó adattárakból, a nagy nyelvi modellekből (LLM-ekből) állnak, amelyek a tartományspecifikus adatokon keresztül releváns választ hoznak létre, valamint egy vezénylőből, amely felügyeli az összetevők közötti interakciót.

Ez a cikk az Azure OpenAI nagy nyelvi modelljeit használó vállalati csevegőalkalmazások létrehozásához és üzembe helyezéséhez nyújt alapkonfigurációs architektúrát. Az architektúra az Azure Machine Tanulás (AML) parancssori folyamatát használja, hogy végrehajtható folyamatokat hozzon létre, amelyek a munkafolyamatot a bejövő kérésekből az adattárakba vezénylik, hogy földelési adatokat kérjenek le az LLM-ekhez, valamint minden más Python-logikát is. A végrehajtható folyamat egy felügyelt online végpont mögötti Azure Machine Tanulás számítási fürtön van üzembe helyezve.

Az egyéni csevegőfelület (UI) üzemeltetése az alkalmazásszolgáltatások alapszintű webalkalmazás-útmutatóját követi egy biztonságos, zónaredundáns és magas rendelkezésre állású webalkalmazás üzembe helyezéséhez a Azure-alkalmazás Services szolgáltatásban. Ebben az architektúrában az App Service privát végpontokon keresztüli virtuális hálózati integráción keresztül kommunikál az Azure PaaS-szolgáltatásokkal. Hasonlóképpen, a csevegési felhasználói felület App Service kommunikál a felügyelt online végponttal a privát végponton keresztüli folyamathoz, és az Azure Machine Tanulás munkaterület nyilvános hozzáférése le van tiltva.

A machine Tanulás munkaterület felügyelt virtuális hálózat elkülönítésével van konfigurálva, amely minden kimenő kapcsolatot jóvá kell hagyni. Ezzel a konfigurációval létrejön egy felügyelt virtuális hálózat, valamint a felügyelt privát végpontok, amelyek lehetővé teszik a privát erőforrásokhoz, például az Azure Storage, az Azure Container Registry és az Azure OpenAI munkahelyhez való kapcsolódást. Ezeket a privát kapcsolatokat a folyamat létrehozása és tesztelése során, valamint az Azure Machine-Tanulás számítási Tanulás üzembe helyezett folyamatok használják.

Architektúra

1. ábra: Alapszintű csevegési architektúra az OpenAI használatával

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

Összetevők

Az architektúra számos összetevője megegyezik az alapkonfigurációs App Services-webalkalmazás erőforrásaival, mivel az ebben az architektúrában üzemeltetett csevegőfelület az alapszintű App Service-webalkalmazás architektúráját követi. Az ebben a szakaszban kiemelt összetevők a csevegési folyamatok, az adatszolgáltatások és az LLM-eket közzétevő szolgáltatások létrehozásához és vezényléséhez használt összetevőkre összpontosítanak.

• Az Azure Machine Tanulás egy felügyelt felhőszolgáltatás, amely gépi tanulási modellek betanítása, üzembe helyezése és kezelése gombra szolgál. Ez az architektúra az Azure Machine Tanulás számos más funkcióját használja a nagy nyelvi modelleken alapuló AI-alkalmazások végrehajtható folyamatainak fejlesztésére és üzembe helyezésére:
  • Az Azure Machine Tanulás parancssori folyamat egy olyan fejlesztési eszköz, amellyel olyan folyamatokat hozhat létre, értékelhet és helyezhet üzembe, amelyek összekapcsolják a felhasználói kéréseket, a Python-kódon keresztüli műveleteket és az LLM-ekhez irányuló hívásokat. A parancssori folyamat ebben az architektúrában a parancssor, a különböző adattárak és az LLM közötti folyamatokat vezénylő rétegként használatos.
  • A felügyelt online végpontok lehetővé teszik egy folyamat valós idejű következtetésre történő üzembe helyezését. Ebben az architektúrában a csevegőfelület PaaS-végpontjaként használják őket az Azure Machine Tanulás által üzemeltetett parancssori folyamatok meghívásához.
• Az Azure Storage a gyors folyamatfejlesztéshez szükséges folyamat forrásfájljainak megőrzésére szolgál.
• Az Azure Container Registry lehetővé teszi a tárolólemezképek és -összetevők magánregisztrációs adatbázisban való összeállítását, tárolását és kezelését minden típusú tárolótelepítéshez. Ebben az architektúrában a folyamatok tárolórendszerképekként vannak csomagolva, és az Azure Container Registryben vannak tárolva.
• Az Azure OpenAI egy teljes körűen felügyelt szolgáltatás, amely REST API-hozzáférést biztosít az Azure OpenAI nagy nyelvi modelljeihez, beleértve a GPT-4, a GPT-3.5-Turbo és a Beágyazási modellek készletét. Ebben az architektúrában a modellhozzáférés mellett olyan gyakori vállalati funkciók hozzáadására is használható, mint a virtuális hálózat és a privát kapcsolat, a felügyelt identitástámogatás és a tartalomszűrés.
• Az Azure AI Search egy felhőalapú keresési szolgáltatás, amely támogatja a teljes szöveges keresést, a szemantikai keresést, a vektorkeresést és a hibrid keresést. Az Azure AI Search az architektúra része, mivel ez egy gyakori szolgáltatás, amelyet a csevegőalkalmazások mögötti folyamatokban használnak. Az Azure AI Search a felhasználói lekérdezésekhez releváns adatok lekérésére és indexelésére használható. A parancssori folyamat implementálja a RAG-mintát , amely a lekérdezésből kinyeri a megfelelő lekérdezést , lekérdezi az AI Search szolgáltatást, és az eredményeket az Azure OpenAI-modell alapadataiként használja.

Azure Machine Tanulás parancssori folyamat

A vállalati csevegőalkalmazások háttérrendszere általában az alábbi folyamathoz hasonló mintát követ:

• A felhasználó egy egyéni csevegőfelületen (UI) ad meg egy kérdést
• Ezt a kérést az interfészkód küldi el a háttérbe
• A felhasználói szándékot (kérdést vagy irányelvet) a rendszer a háttérrendszerből nyeri ki
• (nem kötelező) A háttér határozza meg a felhasználói kérés szempontjából releváns adatokat tartalmazó adattár(ok)t
• A háttér lekérdezi a releváns adattár(ok)t
• A háttérrendszer elküldi a szándékot, a vonatkozó földelési adatokat és a kérésben megadott előzményeket az LLM-nek.
• A háttérrendszer visszaadja az eredményt, hogy megjeleníthető legyen a felhasználói felületen

A háttér bármilyen nyelven implementálható, és üzembe helyezhető különböző Azure-szolgáltatásokban. Ebben az architektúrában az Azure Machine Tanulás parancssori folyamat lett kiválasztva, mert leegyszerűsített felületet biztosít a parancssorok, a háttéradattárak és az LLM-ek közötti vezénylést, tesztelést és üzembe helyezést lehetővé tevő folyamatok létrehozásához, teszteléséhez és üzembe helyezéséhez.

Hálózatkezelés

Az identitásalapú hozzáférés mellett a hálózati biztonság az alapkonfiguráció végpontok közötti csevegőarchitektúrájának középpontjában áll az OpenAI használatával. Magas szinten a hálózati architektúra a következőket biztosítja:

• Egyetlen biztonságos belépési pont a csevegés felhasználói felületének forgalmához
• A hálózati forgalom szűrve van
• Az átvitel alatt lévő adatok végpontok közötti titkosítása TLS használatával történik
• Az adatkiszivárgás minimalizálható az Azure-ban a Private Link használatával történő forgalom megtartásával
• A hálózati erőforrások logikailag vannak csoportosítva és elkülönítve egymástól a hálózat szegmentálásán keresztül

Hálózati folyamatok

2. ábra: Az alapszintű teljes körű csevegési architektúra hálózati folyamatai az OpenAI használatával

A diagram két folyamatával foglalkozik az alkalmazásszolgáltatások alapkonfigurációs webalkalmazása: 1. a bejövő folyamat a végfelhasználótól a csevegés felhasználói felületére és a 2-esre. Az App Service-ből az Azure PaaS-szolgáltatásokba történő folyamat. A folyamatokkal kapcsolatos részletekért tekintse meg ezt a cikket. Ez a szakasz az Azure Machine Tanulás online végpontfolyamatára összpontosít. Az alábbiakban az alapszintű App Service-webalkalmazásban futó csevegési felhasználói felületről az Azure Machine Tanulás compute-ban üzembe helyezett folyamatra vonatkozó folyamatot részletezi:

1. Az App Service által üzemeltetett csevegőfelületről érkező hívás egy privát végponton keresztül irányítja át az Azure Machine Tanulás online végpontra.
2. Az online végpont átirányítja a hívást az üzembe helyezett folyamatot futtató kiszolgálóra. Az online végpont terheléselosztóként és útválasztóként is működik.
3. Az üzembe helyezett folyamat által igényelt Azure PaaS-szolgáltatások hívásait a rendszer felügyelt privát végpontokon keresztül irányítja át.

Bejövő forgalom az Azure Machine Tanulás

Ebben az architektúrában az Azure Machine Tanulás-munkaterület nyilvános hozzáférése le van tiltva, és a hozzáférés privát hozzáféréssel történhet, mivel az az Azure Machine Tanulás-munkaterület konfigurációjának privát végpontját követi. Valójában a privát végpontok az architektúra egészében az identitásalapú biztonság kiegészítésére szolgálnak. Ha például engedélyezi az App Service-ben üzemeltetett csevegőfelületnek, hogy olyan PaaS-szolgáltatásokhoz csatlakozzon, amelyek nincsenek közzétéve a nyilvános interneten, beleértve az Azure Machine Tanulás végpontjait is.

Privát végponthoz való hozzáférésre is szükség van az Azure Machine Tanulás-munkaterülethez való csatlakozáshoz a folyamat létrehozásához.

3. ábra: Hálózati folyamatok egy Azure Machine-Tanulás parancssori folyamat szerzője számára

Az ábra egy parancssori folyamatot ábrázoló szerzőt mutat be, aki az Azure Bastionon keresztül csatlakozik egy virtuálisgép-ugrómezőhöz. Ebből a jump boxból a szerző csatlakozhat a Machine Tanulás Workspace-hez egy privát végponton keresztül, ugyanabban a hálózatban, mint a jump box. Csatlakozás a virtuális hálózathoz való hozzáférés expressRoute- vagy VPN-átjárókkal és virtuális hálózatok közötti társviszony-létesítéssel is megvalósítható.

Folyamat az Azure Machine Tanulás felügyelt virtuális hálózatról az Azure PaaS-szolgáltatásokba

Javasoljuk, hogy az Azure Machine Tanulás munkaterület felügyelt virtuális hálózatok elkülönítésére legyen konfigurálva olyan konfigurációval, amely minden kimenő kapcsolatot jóvá kell hagyni. Ez az architektúra ezt a javaslatot követi. Kétféle jóváhagyott kimenő szabály létezik. A szükséges kimenő szabályok a megoldás működéséhez szükséges erőforrásokra vonatkoznak, például az Azure Container Registryre és az Azure Storage-ra. A felhasználó által definiált kimenő szabályok olyan egyéni erőforrásokra vonatkoznak, mint például az Azure OpenAI vagy az Azure AI Search, amelyeket a munkafolyamat használni fog. A felhasználó által definiált kimenő szabályok konfigurálása az Ön feladata, míg a szükséges kimenő szabályok a felügyelt virtuális hálózat létrehozásakor vannak konfigurálva.

A kimenő szabályok lehetnek privát végpontok, szolgáltatáscímkék vagy teljes tartománynevek külső nyilvános végpontokhoz. Ebben az architektúrában az Olyan Azure-szolgáltatásokhoz való kapcsolódás, mint az Azure Container Registry, az Azure Storage, az Azure Key Vault, az Azure OpenAI szolgáltatás és az Azure AI Search privát kapcsolaton keresztül csatlakozik. Bár ebben az architektúrában nem, néhány gyakori művelet, amely fQDN kimenő szabály konfigurálását igényelheti, egy pipcsomag letöltése, egy GitHub-adattár klónozása, az alaptároló lemezképének letöltése külső tárházakból.

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

Az architektúra hálózata külön alhálózatokkal rendelkezik a következőkhöz:

• Application Gateway
• App Service-integrációs összetevők
• Privát végpontok
• Azure Bastion
• Jump box virtuális gép
• Betanítás – ebben az architektúrában nem használható modellbetanításhoz
• Pontozás

Minden alhálózat rendelkezik egy hálózati biztonsági csoporttal, amely az alhálózatok bejövő és kimenő forgalmát is a szükségesre korlátozza. Az alábbi táblázat az alapterv által az egyes alhálózatokhoz hozzáadott NSG-szabályok egyszerűsített nézetét mutatja be. A tábla megadja a szabály nevét és függvényét.

Minden más forgalom kifejezetten megtagadva.

A virtuális hálózatok szegmentálásának és biztonságának megvalósításakor vegye figyelembe az alábbi szempontokat.

• Engedélyezze a DDoS-védelmet a virtuális hálózat számára egy olyan alhálózattal, amely egy nyilvános IP-címmel rendelkező application gateway része.
• Ha lehetséges, adjon hozzá egy NSG-t minden alhálózathoz. A legszigorúbb szabályokat kell használnia, amelyek teljes körű megoldást tesznek lehetővé.
• Használjon alkalmazásbiztonsági csoportokat. Az alkalmazásbiztonsági csoportok lehetővé teszik az NSG-k csoportosítását, így egyszerűbbé téve a szabályok létrehozását összetett környezetekben.

Tartalomszűrés és visszaélések monitorozása

Az Azure OpenAI szolgáltatás tartalmaz egy tartalomszűrési rendszert , amely besorolási modellek együttesét használja a potenciálisan káros tartalmak meghatározott kategóriáinak észlelésére és megelőzésére mind a bemeneti kérésekben, mind a kimeneti befejezésekben. A potenciálisan káros tartalmak kategóriái közé tartozik a gyűlölet, a szexuális, az önsértés, az erőszak, a trágárság és a jailbreak (az LLM korlátainak megkerülésére tervezett tartalom). Konfigurálhatja annak szigorúságát, hogy mit szeretne szűrni az egyes kategóriák tartalmaira, a lehetőségek pedig alacsonyak, közepesek vagy magasak. Ez a referenciaarchitektúra szigorú megközelítést alkalmaz. A beállításokat a követelményeknek megfelelően kell módosítania.

A tartalomszűrés mellett az Azure OpenAI szolgáltatás visszaélésfigyelési funkciókat is megvalósít. A visszaélések monitorozása egy aszinkron művelet, amely az ismétlődő tartalmak és/vagy viselkedések olyan példányainak észlelésére és enyhítésére szolgál, amelyek a szolgáltatás olyan használatára utalnak, amely megsértheti az Azure OpenAI magatartási kódexét. Kérheti a visszaélések monitorozása és az emberi felülvizsgálat alóli mentességet, például ha az adatok nagyon érzékenyek, vagy ha vannak olyan belső szabályzatok vagy alkalmazandó jogi szabályozások, amelyek megakadályozzák az adatok visszaélésészlelés céljából történő feldolgozását.

Megbízhatóság

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. Redundanciát biztosítanak egy régión belül a támogató szolgáltatásokhoz, ha két vagy több példány van üzembe helyezve rajtuk. Ha az egyik zóna állásidőt tapasztal, előfordulhat, hogy a régió többi zónája továbbra sem változik. Az architektúra emellett biztosítja az Azure-szolgáltatások elegendő példányát és ezen szolgáltatások konfigurálását a rendelkezésre állási zónák közötti elterjesztéshez. Tekintse át az útmutatót az alapkonfigurációban .

Ez a szakasz az app service-alapkonfigurációban nem szereplő összetevők, például az Azure Machine Tanulás, az Azure OpenAI és az Azure AI Search szempontjából foglalkozik a megbízhatóságtal.

Zónaredundancia folyamattelepítésekhez

A vállalati üzemelő példányok általában legalább zonális redundanciát igényelnek. Ennek az Azure-ban való eléréséhez az erőforrásoknak támogatniuk kell a rendelkezésre állási zónákat , és legalább az erőforrás példányait üzembe kell helyeznie, vagy engedélyeznie kell a platformtámogatást, ha a példányvezérlés nem érhető el. Az Azure Machine Tanulás compute jelenleg nem nyújt támogatást a rendelkezésre állási zónákhoz. Az adatközpontszintű katasztrófa AML-összetevőkre gyakorolt lehetséges hatásának csökkentése érdekében különböző régiókban kell fürtöket létrehozni, valamint terheléselosztót üzembe helyezni a hívások ezen fürtök közötti elosztásához. Az állapotellenőrzések segítségével biztosíthatja, hogy a hívások csak a megfelelően működő fürtökre legyenek irányítva.

A parancssori folyamatok üzembe helyezése nem korlátozódik az Azure Machine Tanulás számítási fürtökre. A végrehajtható folyamat tárolóalapú alkalmazásként bármely olyan Azure-szolgáltatásban üzembe helyezhető, amely kompatibilis a tárolókkal. Ilyen lehetőségek például az Azure Kubernetes Service (AKS), az Azure Functions, az Azure Container Apps (ACA) és a Azure-alkalmazás Service. Mindegyik szolgáltatás támogatja a rendelkezésre állási zónákat. A többrégiós üzembe helyezés további összetettsége nélkül, a gyors folyamatvégrehajtáshoz szükséges zónaredundancia eléréséhez a folyamatokat az egyik ilyen szolgáltatásban kell üzembe helyeznie.

Az alábbi egy alternatív architektúra, amelyben a parancssori folyamatok üzembe vannak helyezve Azure-alkalmazás szolgáltatásban. Az App Service-t ebben az architektúrában használják, mert a számítási feladat már használja a csevegési felhasználói felületen, és nem járna előnyökkel, ha új technológiát vezetne be a számítási feladatba. Az AKS-szel tapasztalattal rendelkező számítási feladatokért felelős csapatoknak érdemes megfontolni az adott környezetben való üzembe helyezést, különösen akkor, ha az AKS-t a számítási feladat más összetevőihez használják.

4. ábra: Alternatív végpontok közötti csevegési architektúra az OpenAI-val, amely parancssori folyamatokat helyez üzembe Azure-alkalmazás Szolgáltatásokban

A diagram az architektúra szempontjából figyelemre méltó területekre van számozott:

1. A folyamatok továbbra is az Azure Machine Tanulás parancssori folyamatában jönnek létre, és az Azure Machine Tanulás hálózati architektúra nem változik. A folyamatkészítők továbbra is privát végponton keresztül csatlakoznak a munkaterület szerzői felületéhez, a felügyelt privát végpontok pedig az Azure-szolgáltatásokhoz való csatlakozásra szolgálnak a folyamatok tesztelése során.
2. Ez a pontozott vonal azt jelzi, hogy a tárolóalapú végrehajtható folyamatok le lesznek küldve az Azure Container Registrybe (ACR). A diagram nem jeleníti meg azokat a folyamatokat, amelyek tárolóba helyezik a folyamatokat, és leküldik az ACR-be.
3. Egy másik webalkalmazás is üzembe van helyezve ugyanabban az App Service-csomagban, amely már üzemelteti a csevegőfelületet. Az új Web App üzemelteti a tárolóalapú parancssori folyamatot, amely ugyanazon az App Service-csomagon van, amely már legalább három példányon fut, és a rendelkezésre állási zónák között oszlik el. Ezek az App Service-példányok privát végponton keresztül csatlakoznak az ACR-hez a parancssori folyamat tárolójának lemezképének betöltésekor.
4. A folyamatvégrehajtáshoz a parancssori folyamattárolónak csatlakoznia kell az összes függő szolgáltatáshoz. Ebben az architektúrában, amely az Azure AI Search és az Azure OpenAI szolgáltatás lenne. A csak az AML által felügyelt privát végpont alhálózatán közzétett PaaS-szolgáltatásokat most már a virtuális hálózaton is el kellérhetővé tenni, hogy az App Service-ből látóvonalat lehessen létrehozni.

Azure OpenAI – megbízhatóság

Az Azure OpenAI jelenleg nem támogatja a rendelkezésre állási zónákat. Az adatközpontszintű katasztrófa lehetséges hatásának az Azure OpenAI-ban történő modelltelepítésekre gyakorolt lehetséges hatásának csökkentése érdekében az Azure OpenAI-t több régióban is üzembe kell helyezni, valamint egy terheléselosztót kell üzembe helyezni a hívások régiók közötti elosztásához. Az állapotellenőrzések segítségével biztosíthatja, hogy a hívások csak a megfelelően működő fürtökre legyenek irányítva.

Több példány hatékony támogatása érdekében javasoljuk, hogy a fájlok finomhangolását, például egy georedundáns Azure Storage-fiókon kívülre helyezi. Ez régiónként minimalizálja az Azure OpenAI szolgáltatásban tárolt állapotot. A finomhangolást példányonként kell elvégezni a modell üzembe helyezésének üzemeltetéséhez.

Fontos a percenkénti jogkivonatok (TPM) és a percenkénti kérelmek (RPM) tekintetében a szükséges átviteli sebesség monitorozása, hogy elegendő TPM-t rendeljen a kvótához az üzemelő példányok igényeinek kielégítéséhez, és megakadályozza a telepített modellek hívásainak szabályozását. Az olyan átjárók, mint az Azure API Management (APIM) üzembe helyezhetők az OpenAI-szolgáltatás(ok) előtt, és konfigurálhatók újrapróbálkozáshoz átmeneti hibák és szabályozás esetén. Az APIM kapcsolatcsoport-megszakítóként is használható, hogy megakadályozza, hogy a szolgáltatás túlterhelje a hívásokat, és túllépje a kvótát.

Azure AI Search – megbízhatóság

Az Azure AI Search standard tarifacsomaggal vagy annál magasabb szintű üzembe helyezése olyan régióban, amely támogatja a rendelkezésre állási zónákat , és három vagy több replikát helyez üzembe. A replikák automatikusan egyenletesen oszlanak el a rendelkezésre állási zónák között.

A replikák és partíciók megfelelő számának meghatározásához tekintse meg az alábbi útmutatást:

• Kövesse az útmutatást az Azure AI Search monitorozásához.
• Monitorozási metrikák, naplók és teljesítményelemzés használatával határozza meg a replikák megfelelő számát, hogy elkerülje a lekérdezésalapú szabályozást és a partíciókat az indexalapú szabályozás elkerülése érdekében.

Azure Machine Tanulás – megbízhatóság

Ha az Azure Machine Tanulás felügyelt online végpont mögötti számítási fürtökre helyezi üzembe az üzembe helyezést, vegye figyelembe a skálázásra vonatkozó alábbi útmutatást:

• Kövesse az útmutatást az online végpontok automatikus skálázásához, hogy elegendő kapacitás álljon rendelkezésre az igények kielégítéséhez. Ha a használati jelek nem elég időszerűek a kipukkanási használat miatt, fontolja meg a túlterjedést annak érdekében, hogy ne legyen túl kevés példány rendelkezésre álló megbízhatósági hatása.
• Fontolja meg a skálázási szabályok létrehozását olyan üzembehelyezési metrikák alapján, mint a CPU-terhelés és a végpontmetrikák, például a kérelmek késése.
• Egy aktív éles üzembe helyezéshez legalább három példányt kell üzembe helyezni.
• Kerülje a használatban lévő példányok üzembe helyezését. Ehelyett helyezzen üzembe egy új üzembe helyezést, és helyezze át a forgalmat, miután az üzembe helyezés készen áll a forgalom fogadására.

Biztonság

Ez az architektúra egy hálózatot és egy identitásbiztonsági szegélyt is implementál. Hálózati szempontból az egyetlen dolog, amelyet az internetről elérhetővé kell tenni, az az App Gatewayen keresztüli csevegés felhasználói felülete. Identitás szempontjából a csevegés felhasználói felületének hitelesítenie és engedélyeznie kell a kéréseket. A felügyelt identitások lehetőség szerint az Alkalmazások Azure-szolgáltatásokban való hitelesítésére szolgálnak.

A hálózatbiztonságról a hálózatkezelési szakaszban volt szó. Ez a szakasz az identitás- és hozzáférés-kezelést, valamint a kulcsforgatással és az Azure OpenAI-modell finomhangolásával kapcsolatos biztonsági szempontokat ismerteti.

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

Az alábbi útmutató kiterjeszti az identitás- és hozzáférés-kezelési útmutatót az App Service alapkonfigurációjában:

• Szükség esetén hozzon létre külön felügyelt identitásokat a következő AML-erőforrásokhoz:
  • Munkaterület – a folyamat létrehozása és kezelése során használatos
  • Számítási példány – folyamatok teszteléséhez használatos
  • Online végpont – az üzembe helyezett folyamat által használt, felügyelt online végponton történő üzembe helyezés esetén
• Identitás-hozzáférési vezérlők implementálása a csevegés felhasználói felületéhez a Microsoft Entra ID használatával

Azure Machine Tanulás RBAC-szerepkörök

Az Azure Machine Tanulás-munkaterülethez való hozzáférés kezeléséhez öt alapértelmezett szerepkör használható: AzureML adattudós, AzureML Számítási operátor, Olvasó, Közreműködő és Tulajdonos. Az alapértelmezett szerepkörök mellett van egy AzureML-munkaterület Csatlakozás ion titkos kódolvasója és egy AzureML-beállításjegyzék-felhasználó, amely hozzáférést biztosít a munkaterület erőforrásaihoz, például a munkaterület titkos kulcsaihoz és a beállításjegyzékhez.

Ez az architektúra a legkevésbé jogosultsági elvet követi, mivel csak a fenti identitásokhoz rendel szerepköröket, ahol szükség van rájuk. A szerepkör-hozzárendelések a következők:

Kulcsrotálás

Ebben az architektúrában két szolgáltatás működik, amelyek kulcsalapú hitelesítést használnak: az Azure OpenAI és az Azure Machine Tanulás felügyelt online végpontot. Mivel kulcsalapú hitelesítést használ ezekhez a szolgáltatásokhoz, fontos:

• Tárolja a kulcsot egy biztonságos tárolóban, például az Azure Key Vaultban, hogy igény szerint hozzáférhessen az engedélyezett ügyfelektől (például a parancssori folyamat tárolóját üzemeltető Azure Web Apphoz).
• Kulcsforgatási stratégia implementálása. Ha manuálisan elforgatja a kulcsokat, létre kell hoznia egy kulcslejárati szabályzatot, és az Azure Policy használatával monitoroznia kell, hogy a kulcs elforgatva lett-e.

OpenAI-modell finomhangolása

Ha az Implementációban az OpenAI-modellek finomhangolását hajtja végre, vegye figyelembe az alábbi útmutatást:

• Ha betanítási adatokat tölt fel a finomhangoláshoz, fontolja meg az ügyfél által felügyelt kulcsok használatát az adatok titkosításához.
• Ha betanítási adatokat tárol egy tárolóban, például az Azure Blob Storage-ban, fontolja meg egy ügyfél által felügyelt kulcs használatát az adattitkosításhoz, egy felügyelt identitást az adatokhoz való hozzáférés szabályozásához, valamint egy privát végpontot az adatokhoz való csatlakozáshoz.

Teljesítmény hatékonysága

A teljesítménybeli hatékonyság lehetővé teszi, hogy a számítási feladatok hatékonyan méretezhetők legyenek a felhasználók igényei szerint. További információ: A teljesítményhatékonysági pillér áttekintése.

Ez a szakasz az Azure Search, az Azure OpenAI és az Azure Machine Tanulás szempontjából ismerteti a teljesítményhatékonyságot.

Azure Search – teljesítményhatékonyság

Kövesse az útmutatást az Azure AI Search teljesítményének elemzéséhez.

Azure OpenAI – teljesítményhatékonyság

• Annak meghatározása, hogy az alkalmazás kiosztott átviteli sebességet igényel-e, vagy a megosztott üzemeltetési (használati) modellt fogja használni. A kiosztott átviteli sebesség fenntartott feldolgozási kapacitást biztosít az OpenAI-modellek üzembe helyezéséhez, ami kiszámítható teljesítményt és átviteli sebességet biztosít a modellek számára. Ez a számlázási modell ellentétben áll a megosztott üzemeltetési (fogyasztási) modellel, amely a legjobb erőfeszítés, és zajos szomszéd vagy más stresszorok lehetnek kitéve a platformon.
• A kiosztott átviteli sebesség esetében figyelnie kell a kiépítés által felügyelt kihasználtságot

Azure Machine Tanulás – teljesítményhatékonyság

Az Azure Machine Tanulás online végpontokon való üzembe helyezés esetén:

• Kövesse az online végpontok automatikus méretezésével kapcsolatos útmutatást, hogy a túlzott túlterjedés nélkül, különösen az alacsony kihasználtságú időszakokban is szorosan igazodjon az igényekhez.
• Válassza ki a megfelelő virtuálisgép-termékváltozatot az online végponthoz a teljesítménycélok teljesítéséhez. Az optimális konfiguráció érdekében tesztelni szeretné az alacsonyabb példányszám és a nagyobb termékváltozatok teljesítményét, illetve a nagyobb példányszám és a kisebb termékváltozatok teljesítményét.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: A költségoptimalizálási pillér áttekintése.

A forgatókönyvre vonatkozó díjszabási példa megtekintéséhez használja az Azure díjkalkulátorát. A példát testre kell szabnia a használatnak megfelelően, mivel ez a példa csak az architektúra összetevőit tartalmazza. A forgatókönyv legdrágább összetevői a csevegőfelület és a parancssori folyamat számítása és az Azure AI Search, ezért érdemes optimalizálni ezeket az erőforrásokat, hogy a lehető legtöbb költséggel járjon.

Compute

Az Azure Machine Tanulás parancssori folyamat több lehetőséget is támogat a végrehajtható folyamatok üzemeltetésére. A lehetőségek közé tartoznak az Azure Machine Tanulás felügyelt online végpontjai, az Azure Kubernetes Service, a Azure-alkalmazás Service és az Azure Container Service. Mindegyik beállítás saját számlázási modellel rendelkezik. A számítási lehetőségek kiválasztása hatással van a megoldás teljes költségére.

Azure OpenAI

Az Azure OpenAI egy fogyasztásalapú szolgáltatás, és mint minden használatalapú szolgáltatás esetében, a kínálati igények szabályozása az elsődleges költségkontroll. Ehhez az Azure OpenAI szolgáltatásban a következő módszerek kombinációját kell alkalmaznia:

• Ügyfelek vezérlése. Az ügyfélkérések a használati modell elsődleges költségforrásai, mivel az ügyfél viselkedésének szabályozása kritikus fontosságú. Minden ügyfélnek a következőnek kell lennie:
  • Hagyja jóvá. Kerülje a szolgáltatás olyan módon történő felfedését, amely támogatja az ingyenes hozzáférést. Korlátozza a hozzáférést mind a hálózati, mind az identitásvezérlők (kulcs vagy RBAC) használatával.
  • Legyen önkontraszt. Megkövetelheti az ügyfelektől, hogy használják az API-hívások által kínált jogkivonat-korlátozó korlátozásokat, például max_tokens és max_completions.
  • Használjon kötegelést, ahol praktikus. Tekintse át az ügyfeleket, és győződjön meg arról, hogy megfelelően kötegelik a kéréseket.
  • 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, de a megfelelő környezetből hiányzó kérések nem segítik a modelleket a jó eredmények eléréséhez. Tömör utasításokat hozhat létre, amelyek elegendő kontextust biztosítanak ahhoz, hogy a modell hasznos választ adjon. Hasonlóképpen, győződjön meg arról, hogy optimalizálja a válaszhossz korlátját.
• Az Azure OpenAI-játszótér használatának szükség szerint és a gyártás előtti példányokon kell lennie, így ezek a tevékenységek nem járnak termelési költségekkel.
• Válassza ki a megfelelő AI-modellt. A modell kiválasztása nagy szerepet játszik az Azure OpenAI teljes költségében is. Minden modell rendelkezik erősségekkel és gyengeségekkel, és egyedileg árazva vannak. Ha a használati esethez a megfelelő modellt használja, meggyőződhet arról, hogy nem függesz túl egy drágább modellen, ha egy kevésbé költséges modell elfogadható eredményeket ad. Ebben a csevegési referencia-implementációban a GPT 3.5-turbo a GPT-4-hez képest lett kiválasztva, hogy a modell üzembe helyezési költségeinek nagyságrendjét megtakarítani lehessen, miközben elegendő eredményt érjünk el.
• A számlázási töréspontok ismertetése – A finomhangolás óránként történik. A leghatékonyabban érdemes az óránként rendelkezésre álló idő nagy részét kihasználni a finomhangolási eredmények javítása érdekében, miközben elkerülheti, hogy csak a következő számlázási időszakba csúszzon. Hasonlóképpen, a képgenerálásból származó 100 kép költsége megegyezik az 1 kép költségével. Maximalizálja az ártörési pontokat az előnyére.
• A számlázási modellek ismertetése – Az Azure OpenAI egy kötelezettségvállalásalapú számlázási modellben is elérhető a kiosztott átviteli sebesség ajánlatán keresztül. Ha már rendelkezik kiszámítható használati mintákkal, értékelje ki az elővásárlási számlázási modellre való váltást, ha az a használati mennyiségnél költséghatékonyabbnak számít.
• Kiépítési korlátok beállítása – Győződjön meg arról, hogy az összes kiépítési kvóta csak olyan modellekhez van lefoglalva, amelyek várhatóan a számítási feladat részét képezik modellenként. A már üzembe helyezett modellek átviteli sebessége nem korlátozódik erre a kiépített kvótára, miközben a dinamikus kvóta engedélyezve van. Vegye figyelembe, hogy a kvóta nem felel meg közvetlenül a költségeknek, és a költségek eltérhetnek.
• Használatalapú fizetéses használat monitorozása – Használatalapú fizetés esetén figyelje a jogkivonatok percenkénti (TPM) és a percenkénti kérések (RPM) használatát . Ezekkel az információkkal tájékoztathatja az architekturális tervezési döntéseket, például a használandó modelleket, valamint optimalizálhatja a parancssori méreteket.
• Kiosztott átviteli sebesség használatának figyelése – Ha kiosztott átviteli sebességet használ, monitorozza a kiépítés által felügyelt kihasználtságot, hogy biztosan ne használja ki a megvásárolt kiosztott átviteli sebességet.
• Költségkezelés – Kövesse a költségkezelési funkciók OpenAI-val való használatával kapcsolatos útmutatást a költségek monitorozásához, a költségek kezeléséhez költségvetések beállításához, valamint riasztások létrehozásához, amelyek értesítik az érintetteket a kockázatokról vagy a rendellenességekről.

Nagyméretű nyelvi modellműveletek (LLMOps)

Az Azure OpenAI-alapú csevegőmegoldások üzembe helyezésének, mint ez az architektúra, követnie kell az LLMOps parancssori folyamatának útmutatását az Azure DevOps és a GitHub használatával. Emellett figyelembe kell vennie a CI/CD és a hálózat által védett architektúrák ajánlott eljárásait is. Az alábbi útmutató az LLMOps-javaslatok alapján foglalkozik a folyamatok és azok kapcsolódó infrastruktúrájának megvalósításával. Ez az üzembe helyezési útmutató nem tartalmazza az előtérbeli alkalmazáselemeket, amelyek nem változnak az alapkonfiguráció magas rendelkezésre állású zónaredundáns webalkalmazás-architektúrában leírtaktól.

Fejlesztés

Az Azure Machine Tanulás parancssori folyamat böngészőalapú szerzői élményt nyújt az Azure Machine Tanulás Studióban vagy egy VS Code-bővítményen keresztül. Mindkét beállítás fájlként tárolja a folyamatkódot. Az Azure Machine Tanulás Studio használatakor a fájlok egy Azure Storage-fiókban vannak tárolva. A VS Code használatakor a fájlok a helyi fájlrendszerben lesznek tárolva.

Az együttműködésen alapuló fejlesztés ajánlott eljárásainak betartása érdekében a forrásfájlokat egy online forráskódtárban, például a GitHubon kell tartani. Ez a megközelítés megkönnyíti az összes kódmódosítás nyomon követését, a folyamatkészítők közötti együttműködést, valamint az üzembehelyezési folyamatokkal való integrációt, amelyek tesztelik és ellenőrzik az összes kódmódosítást.

A nagyvállalati fejlesztéshez a VS Code bővítményt és a parancssori SDK/CLI-t kell használnia a fejlesztéshez. A parancssori folyamat szerzői létrehozhatják és tesztelhetik a folyamataikat a VS Code-ból, és integrálhatják a helyileg tárolt fájlokat az online forrásvezérlő rendszerrel és folyamatokkal. Bár a böngészőalapú élmény kiválóan alkalmas feltáró jellegű fejlesztésre, némi munkával integrálható a forrásvezérlő rendszerrel. A folyamatmappa letölthető a panel folyamatlapjáról Files , kibontva és leküldve a forrásvezérlő rendszerbe.

Értékelés

A csevegőalkalmazásokban használt folyamatokat ugyanúgy kell tesztelnie, mint a többi szoftverösszetevőt. Az LLM-kimenetek esetében nehéz egyetlen "helyes" választ megadni és érvényesíteni, de a válaszok kiértékeléséhez maga az LLM is használható. Fontolja meg az LLM-folyamatok következő automatizált kiértékelését:

• Besorolás pontossága: Kiértékeli, hogy az LLM "helyes" vagy "helytelen" pontszámot ad-e, és összesíti az eredményeket a pontossági osztályzat létrehozásához.
• Koherencia: Kiértékeli, hogy egy modell előrejelzett válaszában milyen jól vannak megírva a mondatok, és hogyan kapcsolódnak koherensen egymáshoz.
• Fluency: Felméri a modell előrejelzett válaszát a nyelvhelyességi és nyelvi pontosságára vonatkozóan.
• Alapozottság a környezethez: Kiértékeli, hogy a modell előrejelzett válaszai milyen jól alapulnak az előre konfigurált környezeten. Még ha az LLM válaszai helyesek is, ha azokat nem lehet érvényesíteni az adott kontextusban, akkor az ilyen válaszok nem lesznek megalapozottak.
• Relevancia: Kiértékeli, hogy a modell előrejelzett válaszai mennyire összhangban vannak a feltett kérdéssel.

Vegye figyelembe az alábbi útmutatást az automatizált értékelések implementálásakor:

• Pontszámokat hozhat létre az értékelésekből, és egy előre meghatározott sikerküszöbön méri őket. Ezekkel a pontszámokkal jelentheti a tesztátvételt/feladatokat a folyamatokban.
• Néhány ilyen teszthez előre konfigurált adatbevitelre van szükség a kérdések, a környezet és az alapigazságok esetében.
• Adjon meg elegendő kérdés-válasz párot, hogy a tesztek eredményei megbízhatóak legyenek, és legalább 100-150 pár ajánlott. Ezeket a kérdés-válasz párokat az "arany adatkészletnek" nevezzük. Az adathalmaz méretétől és tartományától függően nagyobb sokaságra lehet szükség.
• Ne használjon LLM-eket az arany adathalmazban lévő adatok létrehozásához.

Üzembehelyezési folyamat

5. ábra: Folyamat központi telepítésének kérése

1. A parancssori mérnök/adatelemző megnyit egy szolgáltatáságat, ahol az adott feladaton vagy szolgáltatáson dolgoznak. A parancssori mérnök/adatelemző a VS Code parancssori folyamatával iterálja a folyamatot, rendszeresen véglegesíti a módosításokat, és a módosításokat a szolgáltatáságba küldi.

2. A helyi fejlesztés és kísérletezés befejezése után a parancssori mérnök/adatelemző megnyitja a szolgáltatáságból a főágba irányuló lekéréses kérelmet. A lekéréses kérelem (PR) elindít egy PR-folyamatot. Ez a folyamat gyors minőségi ellenőrzéseket futtat, amelyeknek tartalmazniuk kell a következőket:

   • Kísérletezési folyamatok végrehajtása
   • Konfigurált egységtesztek végrehajtása
   • A kódbázis összeállítása
   • Statikus kódelemzés

3. A folyamat tartalmazhat olyan lépést, amelyhez legalább egy csapattagnak manuálisan jóvá kell hagynia a kérelemkérést az egyesítés előtt. A jóváhagyó nem lehet a véglegesítő, és gyors folyamattudással és a projektkövetelmények ismeretével rendelkezik. Ha a kérelem nincs jóváhagyva, az egyesítés le lesz tiltva. Ha a lekéréses kérelem jóváhagyásra került, vagy nincs jóváhagyási lépés, a szolgáltatáságat a főágba egyesíti a program.

4. A fő egyesítés aktiválja a fejlesztési környezet buildelési és kiadási folyamatát. Ezek konkrétan a következők:

   a. A CI-folyamat az egyesítésből a Főbe aktiválódik. A CI-folyamat végrehajtja a PR-folyamatban végrehajtott összes lépést, és a következő lépéseket:

   • Kísérletezési folyamat
   • Kiértékelés-folyamat
   • Regisztrálja a folyamatokat az Azure Machine Tanulás Registryben a változások észlelésekor

   b. A CD-folyamat a CI-folyamat befejezése után aktiválódik. Ez a folyamat a következő lépéseket hajtja végre:

   • Üzembe helyezi a folyamatot az Azure Machine Tanulás Registryből egy Azure Machine Tanulás online végpontra
   • Az online végpontot célzó integrációs tesztek futtatása
   • Az online végpontot megcélzó füsttesztek futtatása

5. A jóváhagyási folyamat beépül a kiadás-előléptetési folyamatba – jóváhagyás után a 4.a lépésben leírt CI & CD-folyamatok. & 4.b. ismétlődik, és a tesztkörnyezetet célozza meg. Az a. és b. lépések ugyanazok, kivéve, hogy a felhasználói elfogadási tesztek a tesztkörnyezetben végzett füsttesztek után futnak.

6. A 4.a lépésben leírt CI & CD-folyamatok. & 4.b. futtatva előlépteti a kiadást az éles környezetbe a tesztkörnyezet ellenőrzése és jóváhagyása után.

7. Az élő környezetbe való kiadás után a teljesítménymetrikák monitorozásával és az üzembe helyezett LLM kiértékelésével kapcsolatos operatív feladatokra kerül sor. Ez magában foglalja, de nem korlátozódik a következőkre:

   • Adateltolódások észlelése
   • Az infrastruktúra megfigyelése
   • Költségek kezelése
   • A modell teljesítményének kommunikálása az érdekelt felekkel

Üzembe helyezési útmutató

Az Azure Machine Tanulás-végpontok lehetővé teszik a modellek üzembe helyezését oly módon, hogy rugalmasan lehessen kiadni az éles környezetben. A modell legjobb teljesítményének és minőségének biztosítása érdekében vegye figyelembe az alábbi stratégiákat:

• Kék/zöld üzemelő példányok: Ezzel a stratégiával biztonságosan üzembe helyezheti a webszolgáltatás új verzióját a felhasználók vagy kérések egy korlátozott csoportjában, mielőtt az összes forgalmat az új üzembe helyezésre irányítanák.
• A/B tesztelés: Nem csak a kék/zöld környezetek hatékonyak a módosítások biztonságos bevezetéséhez, hanem új viselkedés üzembe helyezésére is használhatók, amelyek lehetővé teszik a felhasználók egy részhalmazának, hogy értékeljék a változás hatását.
• A folyamat parancssori folyamatának részét képező Python-fájlok szöszítését is belefoglalhatja. A linting ellenőrzi a stílussztenderdeknek, hibáknak, a kód összetettségének, a nem használt importálásoknak és a változók elnevezésének megfelelőségét.
• Amikor a folyamatot a hálózat által elkülönített Azure Machine-Tanulás-munkaterületen helyezi üzembe, egy saját üzemeltetésű ügynököt használva telepíthet összetevőket az Azure-erőforrásokba.
• Az Azure Machine Tanulás modellregisztrációs adatbázisát csak akkor kell frissíteni, ha a modell módosul.
• Az LLM-et, a folyamatokat és az ügyfél felhasználói felületét lazán kell összekapcsolni. Frissítések a folyamatokra, és az ügyfél felhasználói felülete a modell befolyásolása nélkül és fordítva is létrehozható és használható.
• Több folyamat fejlesztésekor és üzembe helyezésekor minden folyamatnak saját életciklussal kell rendelkeznie, ami lazán összekapcsolt élményt tesz lehetővé a kísérletezéstől az éles környezetig tartó folyamatok előmozdítása során.

Infrastruktúra

Az alapkonfigurációjú Azure OpenAI végpontok közötti csevegési összetevők üzembe helyezésekor a kiépített szolgáltatások némelyike alapvető és állandó az architektúrán belül, míg a többi összetevő inkább rövid élettartamú, a létezésük pedig egy üzembe helyezéshez kötődik.

Alapvető összetevők

Az architektúra egyes összetevői olyan életciklussal léteznek, amely túlmutat az egyes parancssori folyamatokon vagy a modellek üzembe helyezésén. Ezeket az erőforrásokat általában egyszer helyezi üzembe a számítási feladatokkal kapcsolatos csapat az alapszintű üzembe helyezés részeként, és a parancssori folyamatok vagy modelltelepítések új, eltávolított vagy frissítésektől eltekintve megmarad.

• Azure Machine Learning-munkaterület
• Azure Storage-fiók az Azure Machine Tanulás-munkaterülethez
• Azure Container Registry
• Azure AI Keresés
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Azure Virtual Machine a jump boxhoz

Rövid élettartamú összetevők

Egyes Azure-erőforrások szorosabban kapcsolódnak az adott parancssori folyamatok tervezéséhez, lehetővé téve, hogy ezek az erőforrások az összetevő életciklusához legyenek kötve, és rövid élettartamúvá váljanak ebben az architektúrában. Ezekre hatással van a számítási feladat fejlődése, például a folyamatok hozzáadása vagy eltávolítása, illetve új modellek bevezetése. Ezek az erőforrások újra létrejönnek, és a korábbi példányok el lesznek távolítva. Ezen erőforrások némelyike közvetlen Azure-erőforrás, néhány pedig adatsík-megnyilvánulás a bennük található szolgáltatáson belül.

• Az Azure Machine Tanulás modellregisztrációs adatbázisában lévő modellt módosítani kell a CD-folyamat részeként.
• A tárolórendszerképet a CD-folyamat részeként frissíteni kell a tárolóregisztrációs adatbázisban.
• Egy Azure Machine Tanulás végpont akkor jön létre, amikor a rendszer parancssori folyamatot helyez üzembe, ha az üzembe helyezés nem létező végpontra hivatkozik. A végpontot frissíteni kell a nyilvános hozzáférés kikapcsolásához.
• Az Azure Machine Tanulás végpont üzembe helyezései frissülnek egy folyamat üzembe helyezésekor vagy törlésekor.
• Új végpont létrehozásakor az ügyfél felhasználói felületéhez tartozó Key Vaultot frissíteni kell a végpont kulcsával.

Figyelés

A diagnosztika minden szolgáltatáshoz konfigurálva van. Az Azure Machine Tanulás és Azure-alkalmazás Service ki nem minden szolgáltatása az összes napló rögzítésére van konfigurálva. Az Azure Machine Tanulás diagnosztikát úgy konfigurálták, hogy rögzítse azokat az auditnaplókat, amelyek mind olyan erőforrásnaplók, amelyek rögzítik az ügyfelek adataival vagy a szolgáltatás beállításaival folytatott interakciókat. Azure-alkalmazás Szolgáltatás az AppServiceHTTPLogs, az AppServiceConsoleLogs, az AppServiceAppLogs és az AppServicePlatformLogs rögzítésére van konfigurálva.

A forgatókönyv üzembe helyezése

A referencia-implementáció üzembe helyezéséhez és futtatásához kövesse az OpenAI végpontok közötti referencia-implementáció lépéseit.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

• Rob Bagby | Minták és eljárások – Microsoft
• Freddy Ayala | Felhőmegoldás-tervező – Microsoft
• Prabal Deb | Vezető szoftvermérnök – Microsoft
• Raouf Aliouat | Szoftvermérnök II . – Microsoft
• Ritesh Modi | Vezető szoftvermérnök – Microsoft
• Ryan Pfalz | Vezető megoldástervező – Microsoft

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

Következő lépések

További információ az Azure OpenAI-ról

Kapcsolódó erőforrások

• Azure OpenAI
• Azure OpenAI nagy nyelvi modellek
• Azure Machine Tanulás parancssori folyamat
• Munkaterület által felügyelt virtuális hálózat elkülönítése
• Privát végpont konfigurálása egy Azure Machine Learning-munkaterület számára
• Tartalomszűrés