LLM-ek és Azure OpenAI a kiterjesztett RAG-generálási (RAG) lekérési mintában (előzetes verzió)

Fontos

Ez egy előnézeti funkció. Ez az információ egy kiadás előtti funkcióra vonatkozik, amely a kiadás előtt jelentősen módosítható. A Microsoft nem vállal kifejezett vagy törvényi garanciát az itt megjelenő információért.

Ez a cikk szemléltető példát mutat be a nagyméretű nyelvi modellek (LLM-ek) és az Azure OpenAI használatára a Retrieval Augmented Generation (RAG) minta kontextusában. Konkrétan azt vizsgálja, hogyan alkalmazhatja ezeket a technológiákat a szuverén leszállási zónákon belül, miközben figyelembe veszi a fontos védőkorlátokat.

Forgatókönyv

Gyakori forgatókönyv, hogy az LLM-ek használatával saját adatait használva folytatnak beszélgetéseket a Retrieval Augmented Generation (RAG) mintán keresztül. Ez a minta lehetővé teszi, hogy az LLM-ek érvelési képességeivel válaszokat generáljon az adott adatok alapján a modell finomhangolása nélkül. Megkönnyíti az LLM-ek zökkenőmentes integrációját a meglévő üzleti folyamatokba vagy megoldásokba.

Felhő a szuverenitásért – AI és LLM referenciaarchitektúra

Microsoft Cloud for Sovereignty egy referenciaarchitektúrát biztosít, amely egy tipikus kiterjesztett lekérési (RAG) architektúrát mutat be egy szuverén leszállási zónán (SLZ) belül. Áttekintést nyújt a gyakori és ajánlott megvalósítási technológiai lehetőségekről, a terminológiáról, a technológiai alapelvekről, a gyakori konfigurációs környezetekről és a vonatkozó szolgáltatások összetételéről.

Töltse le a referenciaarchitektúra diagramjának nyomtatható PDF-fájlját .

A fő szakaszok/adatfolyamok a következők:

Alkalmazási kezdőlapok

A felügyeleti csoport hierarchiájában ezek a szolgáltatások egy nem bizalmas felügyeleti csoporton belüli előfizetésbe kerülnek.

Adatforrások és átalakítási folyamatok

Az adatforrások és az átalakítási folyamatok gyakran léteznek a szervezeten belül az üzletági műveletekhez. Ha LLM-alkalmazásokat, például RAG-implementációkat integrál a meglévő adatokkal, azok új számítási feladatokká válnak.

Az adatfolyam-vezérlés biztosítása érdekében a referenciaarchitektúra adattartományhoz igazított adat-kezdőlapokat javasol az adatforrásokhoz, és az adatátalakítási folyamatokat ezekhez a forrásokhoz közel helyezi az LLM-alkalmazások által használt adattermékek létrehozásához . Ez a megközelítés biztosítja a külön üzemeltetett LLM-alapú megoldásba kiosztott adatok pontos kezelését.

Az adatátalakítási komponensek különböző technológiákat és szolgáltatásokat használnak az adatok olyan formátumba történő átalakítására, amelyet egy LLM-alapú alkalmazás szemantikai vagy vektoros kereséssel kereshet és használhat földelési célokra. Ezek a folyamatok önállóan is működhetnek, vagy AI-szolgáltatásokat, például Azure AI-szolgáltatásokat vagy Azure-t OpenAI használhatnak az adatok vektoros keresésbe vagy szemantikai keresési adatbázisba való átalakításához.

AI-szolgáltatások használatakor a hálózati társviszony-létesítés mindig elérhetővé teszi őket (a központon keresztül vagy közvetlenül) a privát végpontjaikon keresztül. Irányítási, biztonsági és megfelelőségi okokból az adatátalakítási összetevők jogosultak meghatározni, hogy milyen adatok és milyen formátumban legyenek megadva az LLM számítási feladat keresési adatbázisában.

Az adatátalakítási összetevők különböző típusú adatforrásokat használhatnak, hogy az LLM számítási feladatok által használt keresési adatbázisok számára optimális eredménnyel rendelkező adatokat kínáljanak. Ezek az adatforrások lehetnek SQL-adatbázisok, adattavak vagy akár egyéni adatmegoldásokat üzemeltető virtuális gépek az ügyfélkörnyezettől függően.

Az adatforrások nem érhetők el közvetlenül az Orchestrator alkalmazással, hanem ezek az erőforrások csak a virtuális hálózat privát határain belül érhetők el. Ez a Virtual Network (például a virtuális gépekhez), a Private Link szolgáltatások vagy a Virtual Network szolgáltatásvégpontok közvetlen integrációját Microsoft Azure írja elő (csak akkor, ha Private Link vagy közvetlen Virtual Network integráció nem érhető el).

AI és LLM-hez kapcsolódó összetevők

Az AI-val és az LLM-mel kapcsolatos összetevőket számítási feladatokként kell üzemeltetni a saját előfizetésükben a Corp vagy az Online felügyeleti csoportban (attól függően, hogy szükséges-e nyilvános hozzáférés vagy sem). Ezek az összetevők a következők:

Az Azure OpenAI Service beágyazza az LLM-ek, például a GPT és a szövegbeágyazások, például az Ada műveleteit, így az Azure OpenAI által az Orchestrator alkalmazáshoz biztosított szabványos API-kon keresztül érhetők el.

Az Orchestrator-alkalmazások előtérként működnek egy API- vagy UX-alapú felülettel, és vezényli a RAG-alapú élmények létrehozásához szükséges különböző lépéseket. Gyakran webalkalmazás vagy webes API. Ezek a lépések általában a következők:

• Adatok lekérése szemantikai keresőmotorokból a gyors földelés érdekében
• Adatok lekérése adatforrásokból azonnali földelés céljából
• A különböző kérések helyes láncolása az LLM-hez

Az Orchestrator alkalmazás megőrzi az elküldött kérések és a kapott válaszok előzményeit, hogy az Azure-szolgáltatás OpenAI a korábbi interakciók alapján földelje meg. Például egy csevegésszerű élményben, például a ChatGPT-ben vagy a Bing Chatben az Orchestrator alkalmazás karbantartja vagy gyorsítótárazza a beszélgetési munkamenet előzményeit, hogy az LLM szolgáltatás háttérrendszere figyelembe vegye azt a beszélgetési folyamatban.

Online környezetben az Orchestrator-alkalmazás végpontjának kell lennie az egyetlennek, amelyet egy Web Application Firewall és DDoS Protection szolgáltatások által védett nyilvános végponton keresztül biztosítanak. Ha nyilvános végpontok nélküli vállalati környezetben üzemelteti , az Orchestrator vagy egy olyan szolgáltatásban üzemel, amely közvetlenül integrálva van a Virtual Network, például Virtual Machines vagy VM Scale Sets, vagy olyan szolgáltatásokat használ, amelyek támogatják Private Link vagy Virtual Network szolgáltatásvégpontokat, mint a Azure App Services.

A Search Services különböző adatforrásokból származó adatokat biztosít az LLM-szolgáltatások gyors földeléséhez optimalizált formátumban. A Microsoft a vektorizálás és a szemantikai keresés kombinációját javasolja a keresési szolgáltatásokon alapuló azonnali földelés legjobb eredményének eléréséhez, amelyet az Azure AI Search támogat. A szemantikai rangsorolás használata mérhetően javítja a keresés relevanciáját azáltal, hogy a nyelvi megértés segítségével rangsorolja a keresési eredményeket. Ez javítja a RAG alkalmazások felhasználói élményét, mivel a gyors földelés pontosabbá válik a keresési szolgáltatás jobb keresési eredményei révén, mielőtt kérést küldene az LLM-nek.

Az AI-szolgáltatások kombinációjával testreszabott élményeket hozhat létre a végfelhasználók számára az Orchestratoron keresztül, vagy optimalizálhatja az adatbetöltési folyamatokat. Képzelje el, hogy egy űrlapfelismerő szolgáltatást, például az Azure AI Document Intelligence-t használ a strukturált információk űrlapokból való kinyeréséhez, valamint a felhasználói bemenetek hatékony feldolgozásához és összegzéséhez. Ez a szolgáltatás ezután együttműködhet egy LLM-mel, hogy összefoglalja a felismert űrlapbemenetek legfontosabb megállapításait. Egy másik forgatókönyv egy dokumentumfelismerő szolgáltatás használata a különböző formátumú dokumentumok, például PDF-ek vagy Word-dokumentumok szöveggé alakításához. Ezt követően egy LLM szövegbeágyazási szolgáltatás vektorizálhatja ezt a felismert szöveget további elemzés céljából.

Private Link szolgáltatások minden összetevőhöz telepítve vannak, így minden szolgáltatás csak a privát környezetben érhető el. Az egyetlen kivétel az Orchestrator alkalmazás lehet, amely online kezdőlapon üzemeltetve nyilvánosan kínálható webalkalmazási tűzfal vagy hasonló szolgáltatások mögött.

Infrastruktúra-összetevők

Az infrastruktúra-összetevők a számítási feladat részeként vagy központilag is üzemeltethetők egy központban vagy identitás-előfizetésben.

A szuverén kezdőlap implementációjának központi infrastruktúra-összetevője a Platform Connectivity Hub, amely egy virtuális hálózat , amelyet minden szuverén kezdőlap telepítés biztosít. A platform felügyeleti csoportján belüli kapcsolati előfizetésbe kerül .

A megosztott hálózati összetevők a központi virtuális hálózatba kerülnek. Ezek az összetevők általában a következők:

• ExpressRoute-áramkörök vagy VPN-átjárók egy vállalat, ügynökség vagy szervezet vállalati hálózatához való csatlakozáshoz.

• A tűzfalak berendezések vagy Azure Firewall ajánlatok kombinációjával valósíthatók meg, beleértve a Web Application Firewallt is. Ezek a megoldások lehetővé teszik a forgalom ellenőrzését, szűrését és útvonaltervezését.

• DDoS-védelmi összetevők a számítási feladatok elosztott szolgáltatásmegtagadási támadások elleni védelméhez.

• Privát DNS-zónák a teljes virtuális adatközpont-környezetben használt összes szolgáltatástípushoz, a célzónákkal megvalósítva.

• Virtual Network társviszony-létesítés különböző számítási feladatok, például adatforrások, átalakítás és LLM-összetevők virtuális hálózatainak összekapcsolásához a központi hálózaton keresztül.

• A szabályzatok szükség esetén szabályozzák a központ tűzfalain keresztüli forgalmat.

Szempontok

A referenciaarchitektúra-diagram egy reprezentatív példaarchitektúrát mutat be, amely egy LLM RAG-alapú számítási feladat tipikus összetevőit tartalmazza egy szuverén kezdőlap kontextusában. Számos szempontot kell szem előtt tartani, amelyeket az előző szakaszok nem tárgyaltak.

Igazodás a Well-Architected Framework és a Cloud Adoption Framework alapelveivel

Az előző szakaszokban röviden megemlítettük a Well-Architected Framework (WAF) és a Cloud Adoption Framework (CAF) néhány igazítási szempontját. Fontos megjegyezni, hogy minden architekturális döntésnek teljes mértékben igazodnia kell a CAF és az Azure Landing Zones , a CAF felhőszintű elemzése és aWAF alapelveihez, beleértve az Azure OpenAI WAF-perspektíváját is.

A védőkorlátokkal kapcsolatos infrastruktúra-tervezési szempontok

Bár a védőkorlátok kezelése szabványos eljárás a célzónás környezetekben, az LLM és az AI számítási feladatok esetében több területen más szempontokat is figyelembe kell venni. A számítási feladatok előfizetésének infrastruktúrájának megtervezése és meghatározása során a legjobb, ha követi az Azure biztonsági alapkonfigurációjának megfelelőségét és a szuverenitási alapkonfiguráció kezdeményezési szabványait .

Az LLM RAG alapú alkalmazások legfontosabb szempontjai ezekből a szabványokból:

Adattárolás és régió kiválasztása

A szuverenitás szigorú követelményeket ír elő az adattárolásra vonatkozóan, ezért korlátozhatja az üzembe helyezéseket egy SLZ adott Azure-régióira. Az LLM számítási feladatok régiójának kiválasztását a szükséges szolgáltatások rendelkezésre állása korlátozza:

• Ellenőrizze, hogy az Azure OpenAI és az Azure AI Search egyaránt elérhető-e a célrégióban, ahol az adatokat és a számítási feladatokat üzemelteti az adatok tárolási helye és/vagy közelsége miatt. Emellett ezek a szolgáltatások teljesítmény szempontjából fontosak a végfelhasználó alkalmazással kapcsolatos élménye szempontjából.

• Másodszor, az Azure OpenAI megtekintésekor fontos a megfelelő LLM-modellek rendelkezésre állása, mivel nem minden modell érhető el egyformán az összes régióban.

• Ha az adatforrások vagy más kognitív szolgáltatások nem érhetők el a kijelölt célrégióban, előfordulhat, hogy az adattárolási követelményeknek megfelelően egy másik régióban is megkeresheti és működtetheti őket. Az Azure-szolgáltatásnak OpenAI és az Azure AI Searchnek azonban teljesítménybeli okokból ugyanabban a régióban kell lennie, mint az Orchestrator-alkalmazásnak.

Hálózatkezelés

A nyilvános végpontok nem engedélyezettek a vállalati környezetekben. Ezért minden szolgáltatást be kell ágyazni egy virtuális hálózatba. A szolgáltatástól függően közvetlen beágyazási képességeket kínálhat, például virtuális gépeket vagy AKS-fürtöket, Private Link vagy Virtual Network szolgáltatásvégpontokat. Virtual Network szolgáltatásvégpontokat lehetőség szerint le kell cserélni Private Link.

A beágyazás mellett a nyilvános hozzáférést minden szolgáltatáshoz le kell tiltani. Végül engedélyezni kell a szabályzatok kényszerítését Azure Policy, hogy a nyilvános hozzáférést soha ne lehessen véletlenül engedélyezni olyan szolgáltatásokhoz, ahol a megfelelő megtagadási szabályzatok nem hozhatók létre. A mélyreható védelmi stratégia az, hogy minden szolgáltatáshoz engedélyezze a megfelelő naplózási képességeket.

Titkosítás inaktív és átvitel közben

Az Azure legtöbb szolgáltatása támogatja az átvitel közbeni és az inaktív állapotban lévő titkosítási képességeket is. Engedélyezze az inaktív és átviteli titkosítást az összes szolgáltatásban, ha elérhető. Engedélyezze a legújabb TLS-verziót, jelenleg a TLS 1.2-t az átviteli titkosításhoz.

Felügyelt identitások

Felügyelt identitások használata az összes szolgáltatáshoz és a szolgáltatások közötti kommunikációhoz, hogy elkerülje a hitelesítő adatok titkos kulcsainak kezelését.

Kulcsrotáció a Key Vaultban

Ha biztonsági eszközökre, például tanúsítványokra van szükség, engedélyezze a kulcsrotációt ezekhez a titkos kulcsokhoz Key Vault a megfelelőség fenntartása érdekében.

Hálózati és alkalmazásbiztonsági csoportok

Szuverén, biztonságos környezetben a hálózati biztonsági csoportok (NSG) és az alkalmazásbiztonsági csoportok (ASG) használata kötelező. A hiányzó biztonsági csoportok nem megfelelő telepítésekhez vezetnek. A szokásos SSL-portok a legtöbb olyan szolgáltatáshoz hasznosak, amelyekre az LLM/RAG számítási feladatok támaszkodnak, mivel HTTPS-alapúak. A forrásokból a keresési és vektoros adatbázisokba való adatbetöltéshez speciális portokra van szükség. A nyilvános IP-címek nem engedélyezettek a vállalati kezdőlapokban. Minden szolgáltatásnak csak a Virtual Network kell elérhetőnek lennie, amihez Private Link vagy Virtual Network szolgáltatásvégpontok használata szükséges a PaaS-szolgáltatásokhoz.

Több biztonság és szuverenitás védőkorlát

Az infrastruktúra és az alkalmazások kialakításának korábbi szakaszaiban ismertetett legfontosabb és legnyilvánvalóbb védőkorlátok a szuverén vagy az Azure-beli kezdőlapokon kívül is újrafelhasználhatók. Más globális szabályzatok központilag felügyelt erőforrásokhoz, például Log Analytics-munkaterületekhez vagy Microsoft Sentinel-üzemelő példányokhoz vannak kötve nagyvállalati szintű kezdőlapokban. Az infrastruktúra és az alkalmazások tervezési folyamata során kulcsfontosságú figyelembe venni ezeket a központilag felügyelt erőforrásokat. Ennek elmulasztása további erőfeszítéseket és időt eredményezhet a telepítés után. Szerencsére az Azure szabályzatmegfelelőségi funkciója képes azonosítani a nem megfelelő erőforrásokat az üzembe helyezés után. Emellett a szuverén és az Azure-beli kezdőlapok is számos erőforráshoz biztosítanak DeployIfNotExists-szabályzatokat, ami tovább egyszerűsíti a folyamatot.

Néhány példa az ilyen védőkorlátokra:

• A központilag felügyelt Log Analytics-munkaterületekre való bejelentkezés aktiválása.

• Integráció az Azure Security Centerrel vagy a Microsoft Defender for Clouddal.

• Integráció biztonsági információ- és eseménykezelési (SIEM) csomagokkal, például a Microsoft Sentinellel.

• Integráció központilag felügyelt tűzfalakkal, webalkalmazási tűzfalakkal vagy DDoS-védelemmel.

Ez csak néhány védőkorlát, amelyet a kezdeti üzembe helyezés után követelményként azonosíthat. Javasoljuk, hogy tesztelje az üzemelő példányokat egy teszt kezdőlapon, és iteratív módon integrálja a védőkorlátok teljesítését az infrastruktúra és az alkalmazás kódbázisába. Ha ez nem teljesen lehetséges, a védőkorlátok közül sok az üzembe helyezés után a DeployIfNotExists szabályzatokkal kezelhető.

A forgatókönyv üzembe helyezése

A szuverén kezdőlapokon belüli nagyméretű nyelvi modellek (LLM-ek) és az OpenAI Azure kihasználásához a szuverén kezdőlapokon belüli kiterjesztett lekérési (RAG) mintán alapuló Azure először üzembe kell helyeznie és konfigurálnia kell egy szuverén kezdőlapot (SLZ), és alkalmaznia kell a szuverenitási alapkonfiguráció szabályzatkezdeményezéseit. Az SLZ és annak összes képességének részletes áttekintését a GitHub szuverén kezdőlapjának dokumentációjában találja.

Az SLZ olyan környezetet biztosít, amely szabályzatok és szabályzatkészletek, biztonsági kényszerítés és konzisztens alapkonfiguráció-infrastruktúra révén kínál védelmet a számítási feladatok és alkalmazások üzembe helyezéséhez. Az SLZ az Azure kezdőzónákon alapul, és kibővíti azt védőkorlátokkal és a szuverenitási követelményeknek megfelelő biztonsági ellenőrzésekkel.

Az ügyfelek értékteremtési idejének felgyorsítása és a megfelelőségi célok elérésének elősegítése érdekében használatra Microsoft Cloud for Sovereignty kész számítási feladatsablonokat tartalmaz, amelyek következetesen üzembe helyezhetők és megismételhető módon működtethetők. A számítási feladatok sablonjai igazodnak a szuverenitási alapkonfiguráció szabályzatkezdeményezéseihez , a felhő a szuverenitáshoz szabályzatportfólióhoz ésaz Azure kezdőlap alapértelmezett szabályzataihoz .

Információs asszisztens ügynöksablon

Az információs asszisztens ügynöksablon kiindulópontot biztosít a szervezetek számára, hogy saját egyéni generatív AI-képességeket hozzanak létre, hogy a modell finomhangolása nélkül kiterjesszék az Azure OpenAI hatékonyságát a szervezeti felhasználókra és a tartományi adataikra. Üzembe helyezheti a Cloud for Sovereign szolgáltatásban, és igazíthatja a cikkben található referenciaarchitektúrához és útmutatáshoz. Az információs asszisztens ügynöksablonja kompatibilis a szuverén kezdőlap online felügyeleti csoportjának hatókörével a biztonságos módú telepítési konfiguráció használatával. Hamarosan megjelenik a vállalati felügyeleti csoport hatókörének támogatása.

Az ügynöksablon kód, dokumentáció és oktatási források kombinációja, amelyeket ingyenesen biztosítanak az ügyfeleknek és a partnereknek, és amelyek segíthetnek felgyorsítani az értékteremtési időt.

Az információs asszisztens üzembe helyezésével és konfigurálásával kapcsolatos további információkért tekintse meg az információs asszisztens ügynöksablonjának dokumentációját a GitHubon. Az ügynöksablonnal elérhető használati eseteket lásd: Információs asszisztens videója.