Dela via


LLM:er och Azure OpenAI i RAG-mönster (Retrieval Augmented Generation) (förhandsversion)

Viktigt

Detta är en förhandsversion. Den här informationen avser en funktion i förhandsversionen som kan ändras väsentligt innan den släpps. Microsoft lämnar inga garantier, uttryckligen eller underförstått, med avseende på informationen som visas här.

Den här artikeln innehåller ett exempel på hur stora språkmodeller (LLM:er) och Azure OpenAI används i samband med RAG-mönstret (Retrieval Augmented Generation). Den undersöker specifikt hur man kan tillämpa dessa tekniker i suveräna landningszoner och samtidigt beakta viktiga skyddsmekanismer.

Scenario

Ett vanligt scenario är att använda LLM:er för att hålla konversationer med hjälp av dina egna data via RAG-mönstret (Retrieval Augmented Generation) Det här mönstret gör att du kan dra nytta av LLM:erna för att generera svar baserat på dina specifika data utan att någon finjustering av modellen krävs. Detta underlättar en smidig integrering av LLM:er i dina befintliga affärsprocesser eller befintliga lösningar.

Cloud for Sovereignty – AI- och LLM-referensarkitektur

Microsoft Cloud for Sovereignty innehåller en referensarkitektur som illustrerar en typisk RAG-arkitektur (Retrieval Augmented Generation) i en suverän landningszon (SLZ, Sovereign Landing Zone). Den innehåller en översikt över vanliga och rekommenderade teknikval för implementering, terminologi, teknikprinciper, vanliga konfigurationsmiljöer och sammansättning av tillämpliga tjänster.

Referensarkitektur för AI- och LLM-konfigurationer med suveräna skyddsräcken.

Ladda ner en utskrivbar PDF-fil med det här referensarkitekturdiagrammet.

De viktigaste faserna/dataflödena är följande:

Landningszoner för program

I hanteringsgruppshierarkin placeras dessa tjänster i en prenumeration i en icke-konfidentiell hanteringsgrupp.

Datakällor och omvandlingspipelines

Datakällor och omvandlingspipelines finns ofta inom en organisation för verksamhetsområdesåtgärder. När du integrerar LLM-program, till exempel RAG-implementeringar, med befintliga data, blir dessa nya arbetsbelastningar.

För att säkerställa dataflödeskontroll rekommenderar referensarkitekturen datadomänanpassade datalandningszoner för datakällor, och placerar dataomvandlingspipelines nära dessa källor för att skapa dataprodukter som används av LLM-program. Den här metoden säkerställer exakt hantering av data som tillhandahålls för den LLM-baserade lösningen, som är separat värdbaserad.

Datatransformationskomponenter använder olika tekniker och tjänster för att omvandla data till ett format som kan sökas och användas av en LLM-baserad applikation genom semantisk sökning eller vektorsökning för jordningsändamål. Dessa pipelines kan fungera på egen hand eller använda AI-tjänster, till exempel Azure AI-tjänster eller Azure OpenAI, för att transformera data för att placeras i en vektorsökning eller semantisk sökdatabas.

När du använder AI-tjänster gör nätverkspeering dem alltid tillgängliga (via hubben eller direkt) via deras privata slutpunkter. Av styrnings-, säkerhets- och regelefterlevnadsorsaker har komponenterna för dataomvandling befogenhet att avgöra vilka data och i vilket format som ska tillhandahållas åt en sökdatabas för LLM-arbetsbelastningen.

Dataomvandlingskomponenter kan använda olika slags datakällor för att erbjuda data med det optimala resultatet för de sökdatabaser som LLM-arbetsbelastningen bygger på. Dessa datakällor kan vara SQL-databaser, datasjöar eller till och med virtuella datorer som är värd för anpassade datalösningar, beroende på kundmiljön.

Datakällor ska inte vara tillgängliga direkt med Orchestrator-appen, utan dessa resurser ska i stället bara vara tillgängliga inifrån det virtuella nätverkets privata gränser. Detta medför en direkt integrering av Microsoft Azure Virtual Network (till exempel i fallet med VM:er), Private Link-tjänster eller Virtual Network-tjänsteslutpunkter (endast om Private Link- eller Virtual Network-integrering inte är tillgängligt).

AI och LLM-relaterade komponenter bör vara värdbaserade som arbetsbelastningar i den egna prenumerationen inom hanteringsgruppen Corp eller Online (beroende på om offentlig åtkomst krävs eller inte). Komponenterna är följande:

Azure OpenAI Service kapslar in verksamheten för LLM:er som GPT och textinbäddningar som Ada, vilket gör dem tillgängliga via standard-API:er som tillhandahålls av Azure OpenAI till Orchestrator-appen.

En Orchestrator-app fungerar som frontend med ett API- eller UX-baserat gränssnitt, och orkestrerar de olika steg som krävs för att skapa RAG-baserade upplevelser. Ofta är det en webbapp eller ett webb-API. Stegen är vanligtvis följande:

  • ta fram data från semantiska sökmotorer för prompt-grundning
  • ta fram data från datakällor för att prompt-grundning
  • korrekt kedjekoppla olika förfrågningar till LLM:en

Orchestrator-appen underhåller historiken för de begäranden som skickas och svar som tas emot för att säkerställa att Azure-tjänsten OpenAI jordas baserat på tidigare interaktioner. I en chattliknande upplevelse såsom ChatGPT eller Bing Chat upprätthåller eller cachelagrar Orchestrator-programmet historiken för konversationssessionen, detta så att den beaktas i konversationsflödet av LLM-tjänstens serverdel.

I en onlinemiljö bör Orchestrator-appens slutpunkt vara den enda som tillhandahålls via en offentlig slutpunkt skyddad av en brandvägg för webbaserade program och DDoS-skyddstjänster. Om Orchestrator är värdbaserad i Corp-miljö och inte har offentliga slutpunkter, är den antingen värdbaserad i en tjänst som är direkt integrerad i det virtuella nätverket, till exempel virtuella datorer eller VM Scale Sets, eller använder tjänster som stöder Private Link- eller Virtual Network-tjänstslutpunkter, vilket är fallet för Azure App Services.

Search Services tillhandahåller data från olika datakällor i ett format som är optimerat för effektiv användning för snabb jordning av LLM-tjänster. Microsoft använder en kombination av vektorisering och semantisk sökning för att få bästa möjliga resultat för prompt-grundning baserat på söktjänster, med stöd av Azure AI-sökning. Om du använder semantisk rangordning blir sökrelevansen betydligt bättre genom att använda språkförståelse för att rangordna sökresultat. Det förbättrar användarupplevelsen för RAG-program, eftersom prompt-grundningen blir mer exakt med bättre sökresultat från söktjänsten innan en förfrågan skickas till LLM.

En kombination av AI-tjänster kan användas för att skapa anpassade upplevelser för slutanvändare via Orchestrator, eller för att optimera datainmatningsprocesser. Anta att du använder en Formigenkänning-tjänst som Azure AI Document Intelligence för att extrahera strukturerad information från formulär och effektivt bearbeta och sammanfatta användarindata. Denna tjänst kan sedan samarbeta med en LLM för att sammanfatta det viktigaste från dessa igenkända formulärindata. Ett annat scenario är att använda en dokumentigenkänningstjänst för att konvertera dokument i olika format, till exempel PDF-filer eller Word-dokument, till text. Därefter kan en LLM-textinbäddningstjänst vektorisera den igenkända texten för ytterligare analys.

Private Link-tjänster distribueras för alla komponenter så att alla tjänster endast är tillgängliga i den privata miljön. Det enda undantaget kan vara Orchestrator-appen, som om den är värdbaserad i en Online-landningszon kan erbjudas offentligt bakom en Web Application Firewall eller jämförbar service.

Infrastrukturkomponenter

Infrastrukturkomponenter kan lagras antingen som en del av arbetsbelastningen eller centralt i en hubb eller identitetsprenumeration.

Den centrala infrastrukturen i en suverän landningszonsimplementering är Platform Connectivity Hub, som är ett virtuellt nätverk som tillhandahålls av alla distributioner av suverän landningszon. Den placeras i anslutningsprenumerationen i plattformshanteringsgruppen.

Delade nätverkskomponenter placeras i det virtuella hubbnätverket. Dessa komponenter inkluderar som regel följande:

  • ExpressRoute-kretsar eller VPN-gatewayer för anslutning till företagsnätverket för ett företag, en byrå eller en organisation.

  • Brandväggar kan implementeras med hjälp av enheter eller en kombination av Azure brandväggserbjudanden, inklusive Web Application Firewall. Dessa lösningar möjliggör trafikinspektion, filtrering och vidarebefordran.

  • DDoS-skyddskomponenter för att skydda arbetsbelastningar från distribuerade överbelastningsattacker.

  • Privat DNS zoner för alla typer av tjänster som används i hela det virtuella datacenterlandskapet som implementeras med landningszoner.

  • Virtual Network-peering för att ansluta virtuella nätverk med olika arbetsbelastningar, till exempel datakällor, transformering och LLM-komponenter via hubbnätverket.

  • Principer styr trafikflödet genom hubbens brandväggar där det behövs.

Att tänka på

Referensarkitekturdiagrammet visar en representativ exempelarkitektur som omfattar typiska komponenter i en LLM RAG-baserad arbetsbelastning i kontexten för en suverän landningszon. Det finns flera saker att överväga som inte beskrivits i tidigare avsnitt.

Anpassning till principer från Välstrukturerat ramverk och Cloud Adoption Framework

I tidigare avsnitt nämns några anpassningsaspekter som är relaterade till Välstrukturerat ramverk (WAF) och Cloud Adoption Framework (CAF). Det är viktigt att notera att alla arkitekturbeslut helt och hållet bör anpassas till grundprinciperna för CAF- och Azure-landningszoner, CAF-analys i molnskala och WAF, inklusive WAF-perspektivet på Azure OpenAI.

Att hantera skyddsmekanismer är en standardprocedur i landingszonmiljöer, men andra överväganden måste göras inom flera områden för LLM- och AI-arbetsbelastningar. Det är bäst att följa standarderna för Azure Security Baseline-efterlevnad och baslinjepolicyinitiativ för suveränitet vid design och definition av infrastrukturen för arbetsbelastningsprenumerationen.

De viktigaste övervägandena att framhäva för LLM RAG-baserade program från dessa standarder är:

Val av datahemvist och region

Suveränitet har strikta krav på datahemvist, och kan därför komma att begränsa distributionerna till specifika Azure-regioner i en SLZ. Att välja en region för LLM-arbetsbelastningen begränsas av tillgängligheten till de tjänster som krävs:

  • Kontrollera att både Azure OpenAI och Azure AI-sökning är tillgängliga i din målregion där du är lagrar dina data och din arbetsbelastning av datahemvist och/eller närhetsorsaker. Dessutom är dessa tjänster viktiga, ur ett prestandaperspektiv, för slutanvändarens upplevelse av programmet.

  • När du sedan tittar på Azure OpenAI är tillgängligheten för respektive LLM-modell viktig eftersom inte alla modeller är lika tillgängliga i alla regioner.

  • Om datakällor eller andra kognitiva tjänster inte är tillgängliga i det angivna målområdet kanske du kan hitta och använda dem i en annan region i enlighet med kraven på datahemvist. Azure OpenAI Service och Azure AI-sökning måste dock finnas i samma region som Orchestrator-appen av prestandaskäl.

Nätverkande

Offentliga slutpunkter är inte tillåtna i Corp-miljöer. Därför måste alla tjänster vara inkapslade i ett virtuellt nätverk. Beroende på tjänsten kan den erbjuda direkta inkapslingsfunktioner som VM-datorer eller AKS-kluster, Private Link eller Virtual Network-tjänstslutpunkter. Virtual Network-tjänstslutpunkter bör när så är möjligt ersättas av Private Link.

Utöver inkapsling måste all offentlig åtkomst inaktiveras för alla tjänster. Slutligen ska policyefterlevnad med hjälp av Azure Policy aktiveras så att offentlig åtkomst aldrig kan aktiveras av misstag för tjänster där motsvarande avvisningsprinciper inte kan upprättas. Skyddsstrategin med flera nivåer är att aktivera motsvarande granskningsfunktioner för alla tjänster.

Kryptering i vila och under överföring

De flesta tjänster i Azure har stöd för funktioner för kryptering både i vila och vid överföring. Aktivera kryptering i vila och vid överföring för samtliga tjänster när det är tillgängligt. Aktivera den senaste TLS-versionen, för närvarande TLS 1.2, för kryptering vid överföring.

Hanterade identiteter

Använd hanterade identiteter för alla tjänster och kommunikation mellan tjänster för att undvika att hantera hemligheter för autentiseringsuppgifter.

Nyckelrotation i Key Vault

När säkerhetsresurser krävs, t.ex. certifikat, aktiverar du nyckelrotation för dessa hemligheter i Key Vault för att upprätthålla regelefterlevnad.

Säkerhetsgrupper för nätverk och program

I en suverän, säker miljö genomdrivs användning av Network Security Groups (NSG) och Application Security Groups (ASG). Säkerhetsgrupper som saknas leder till icke-kompatibla distributioner. De vanliga SSL-portarna är användbara för de flesta tjänster som LLM/RAG-arbetsbelastningen bygger på, eftersom de är baserade på HTTPS. Specifika portar krävs för datainmatning från källorna till sök- och vektordatabaserna. Offentliga IP:n tillåts inte i Corp-landningszoner. Alla tjänster måste vara tillgängliga enbart i det virtuella nätverket, vilket kräver användning av Private Link eller Virtual Network-tjänstslutpunkter för PaaS-tjänster.

Fler skyddsmekanismer för säkerhet och suveränitet

De viktigaste och mest uppenbara skyddsmekanismerna som beskrivs i tidigare avsnitt för din infrastruktur och programdesign är återanvändbara även utanför suveräna landningszoner eller Azure-landningszoner. Andra globala principer är knutna till centralt hanterade resurser, t.ex. Log Analytics-arbetsytor eller Microsoft Sentinel-distributioner i landningszoner på företagsskala. Under infrastruktur- och programdesignprocessen är det viktigt att du tar hänsyn till dessa centralt hanterade resurser. Om du försummar det kan det leda till ytterligare arbete och tid efter distributionen. Azures policyefterlevnadsfunktion kan identifiera resurser som inte är kompatibla efter distributionen. Dessutom tillhandahåller både suveräna landningszoner och Azure-landningszoner DeployIfNotExists-policyer för många resurser, vilket förenklar processen ytterligare.

Några exempel på sådana skyddsmekanismer är:

  • Aktivering av loggning till centralt hanterade Log Analytics-arbetsytor.

  • Integrering med Azure Security Center eller Microsoft Defender for Cloud.

  • Integrering med Säkerhetsinformation och händelsehantering-sviter (SIEM), till exempel Microsoft Sentinel.

  • Integrering med centralt hanterade brandväggar, brandväggar för webbprogram eller DDoS-skydd.

Det här är några exempel som du kan identifiera som krav efter den första distributionen. Vi rekommenderar att du testar distributionerna i en testlandningszon och iterativt integrerar skyddsmekanismerna i infrastrukturen och programkodbasen. Om det inte är helt möjligt kan många av skyddsmekanismerna hanteras efter distributionen med DeployIfNotExists-policyer.

Distribuera det här scenariot

För att kunna använda LLM:er (Large Language Models) och Azure OpenAI baserat på RAG-mönster (Retrieval Augmented Generation) i suveräna landningszoner måste du först distribuera och konfigurera en suverän landningszon (SLZ) och använda Sovereignty Baseline-policyinitiativ. För en detaljerad översikt över en SLZ och alla dess funktioner, se dokumentation om Sovereign landningszon på GitHub.

SLZ tillhandahåller en miljö med skyddsmekanismer med hjälp av principer och principuppsättningar, genomdrivning av säkerhet och enhetlig baslinjeinfrastruktur för distribution av arbetsbelastning och program. SLZ baseras på Azure Landing Zone och utökar det med skydd och säkerhetskontroller som är specifika för suveränitetskrav.

För att påskynda kundernas tid till värde samtidigt som det hjälper dem att uppfylla sina efterlevnadsmål innehåller Microsoft Cloud for Sovereignty färdiga arbetsbelastningsmallar som konsekvent kan distribueras och användas på ett repeterbart sätt. Arbetsbelastningsmallarna är anpassade till Suveränitetspolicyinitiativ på grundnivå, Cloud for Sovereignty-policyportföljen och Azure Landing Zone-standardpolicyer.

Information Assistenten handläggare mall

Mallen Information Assistenten handläggare ger en utgångspunkt för organisationer att bygga sin egen anpassade generativa AI-funktion för att utöka kraften i Azure OpenAI till organisationsanvändare och deras domändata utan att finjustera modellen. Du kan distribuera den i Cloud for Sovereignty och anpassa den efter referensarkitekturen och vägledningen i den här artikeln. Information Assistenten handläggare-mallen är kompatibel med omfånget för hanteringsgruppen Sovereign Landing Zone Online med hjälp av distributionskonfigurationen för säkert läge . Stöd för omfånget för företagshanteringsgruppen kommer snart.

Mallen handläggare är en kombination av kod, dokumentation och utbildningsresurser som tillhandahålls utan kostnad för kunder och partner och som kan hjälpa till att påskynda tiden till värde.

Mer information om hur du distribuerar och konfigurerar Information Assistenten finns i dokumentationen för mallen Information Assistenten handläggare på GitHub. Användningsfall som du kan uppnå med den här handläggare mallen finns i Information Assistenten Video.