LLM's en Azure OpenAI in Retrieval Augmented Generation (RAG)-patroon (preview)

Belangrijk

Dit is een preview-functie. Deze informatie heeft betrekking op een pre-releasefunctie die aanzienlijk kan worden gewijzigd voordat deze wordt uitgebracht. Microsoft biedt geen enkele expliciete of impliciete garantie met betrekking tot de informatie die hier wordt verstrekt.

Dit artikel biedt een illustratief voorbeeld van het gebruik van Large Language Models (LLM's) en Azure OpenAI binnen de context van het Retrieval Augmented Generation (RAG)-patroon. Concreet onderzoekt het hoe u deze technologieën kunt toepassen binnen soevereine landingszones, waarbij ook belangrijke vangnetten worden overwogen.

Scenario

Een veelvoorkomend scenario is om LLM's te gebruiken om gesprekken aan te gaan met behulp van uw eigen gegevens via het Retrieval Augmented Generation (RAG)-patroon. Met dit patroon kunt u het redeneervermogen van LLM's benutten om antwoorden te genereren op basis van uw specifieke gegevens zonder dat u het model hoeft te verfijnen. Het vergemakkelijkt de naadloze integratie van LLM's in uw bestaande bedrijfsprocessen of oplossingen.

Cloud for Sovereignty - AI- en LLM-referentiearchitectuur

Microsoft Cloud for Sovereignty biedt een referentiearchitectuur die een typische Retrieval Augmented Generation (RAG)-architectuur illustreert binnen een soevereine landingszone (SLZ). Het biedt een overzicht van algemene en aanbevolen implementatietechnologiekeuzes, terminologie, technologieprincipes, gemeenschappelijke configuratieomgevingen en samenstelling van toepasselijke services.

Download een afdrukbare PDF van dit referentiearchitectuurdiagram.

De belangrijkste fasen/gegevensstroom zijn als volgt:

Toepassingslandingszones

In de beheergroephiërarchie worden deze services in een abonnement geplaatst binnen een niet-vertrouwelijke beheergroep.

Gegevensbronnen en transformatiepijplijnen

Er bestaan ​​vaak gegevensbronnen en transformatiepijplijnen binnen bedrijfstakactiviteiten. Wanneer u LLM-toepassingen, zoals RAG-implementaties, integreert met bestaande gegevens, worden het nieuwe workloads.

Om de controle van de gegevensstroom te kunnen garanderen, beveelt de referentiearchitectuur gegevensdomein-uitgelijnde landingszones voor gegevens voor gegevensbronnen aan en plaatst het gegevenstransformatiepijplijnen dicht bij die bronnen om gegevensproducten te creëren die worden gebruikt door LLM-toepassingen. Deze aanpak zorgt voor een nauwkeurig gegevensbeheer dat worden geleverd aan de op LLM gebaseerde oplossing, die afzonderlijk wordt gehost.

Gegevenstransformatiecomponenten maken gebruik van verschillende technologieën en services om gegevens om te zetten in een formaat dat door een LLM-gebaseerde applicatie kan worden doorzocht en gebruikt via semantisch of vectoronderzoek voor basisdoeleinden. Deze pijplijnen kunnen op zichzelf werken of gebruikmaken van AI-services, zoals Azure AI-services of Azure OpenAI, om de gegevens te transformeren zodat ze in een vectorzoek- of semantische zoekdatabase kunnen worden geplaatst.

Bij gebruik van AI-services zorgt netwerkpeering ervoor dat deze altijd beschikbaar zijn (via de hub of rechtstreeks) via hun privé-eindpunten. Om redenen van governance, beveiliging en compliance beschikken de componenten voor gegevenstransformatie over de bevoegdheid om te bepalen welke gegevens en in welke indeling aan een zoekdatabase worden geleverd voor de LLM-werklast.

Componenten voor gegevenstransformatie kunnen verschillende soorten gegevensbronnen gebruiken om gegevens met het optimale resultaat aan te bieden aan de zoekdatabases waar LLM-werklasten op vertrouwen. Deze gegevensbronnen kunnen SQL-databases, data lakes of zelfs virtuele machines zijn die aangepaste gegevensoplossingen hosten, afhankelijk van de klantomgeving.

Gegevensbronnen mogen niet rechtstreeks toegankelijk zijn voor de Orchestrator-app, maar in plaats daarvan mogen deze bronnen alleen beschikbaar zijn binnen de privégrenzen van het virtuele netwerk. Dit vereist directe integratie van Microsoft Azure Virtual Network (zoals bijvoorbeeld het geval is voor VM's), Private Link-services of Virtual Network-service-eindpunten (alleen als Private Link of directe Virtual Network-integratie niet beschikbaar is).

AI- en LLM-gerelateerde onderdelen

AI- en LLM-gerelateerde onderdelen moeten worden gehost als werklasten in hun eigen abonnement onder de beheergroep Corp of Online (afhankelijk van of publieke toegang vereist is of niet). Deze onderdelen zijn:

Azure OpenAI Service omvat de bewerkingen van LLM's zoals GPT en Text Embeddings zoals Ada, waardoor ze toegankelijk zijn via standaard-API's die door Azure OpenAI worden geleverd aan de Orchestrator-app.

Een Orchestrator-app fungeert als front-end met een API- of UX-gebaseerde interface en orkestreert de verschillende stappen die nodig zijn voor het bouwen van op RAG gebaseerde ervaringen. Vaak is het een webtoepassing of een web-API. Deze stappen omvatten doorgaans:

• gegevens uit semantische zoekmachines halen voor snelle onderbouwing
• gegevens uit gegevensbronnen halen voor snelle onderbouwing
• het correct koppelen van verschillende aanvragen aan de LLM

De Orchestrator-app houdt de geschiedenis bij van de verzonden verzoeken en ontvangen reacties, zodat de Azure OpenAI service wordt geaard op basis van eerdere interacties. In een chatachtige ervaring, zoals ChatGPT of Bing Chat, onderhoudt de Orchestrator-app bijvoorbeeld de geschiedenis van de gesprekssessie of slaat deze op in de cache, zodat deze wordt meegenomen in de gespreksstroom door de backend van de LLM-service.

In een Online-omgeving zou het eindpunt van de Orchestrator-app de enige moeten zijn die wordt aangeleverd via een openbaar eindpunt, beschermd door een Web Application Firewall en DDoS-beveiligingsservices. Indien gehost in een Corp-omgeving, zonder openbare eindpunten, wordt de Orchestrator gehost op een service die rechtstreeks is geïntegreerd in het virtuele netwerk, zoals virtuele machines of Virtual Machine Scale Sets of van services gebruikmaken die service-eindpunten van Private Link of Virtual Network ondersteunen, zoals het geval is voor Azure App Services.

Search Services biedt gegevens uit verschillende gegevensbronnen in een formaat dat is geoptimaliseerd voor efficiënt gebruik en dat LLM-diensten snel kan onderbouwen. Microsoft stelt een combinatie van vectorisatie en semantisch zoeken voor om de beste resultaten te bereiken voor snelle onderbouwing op basis van zoekservices, ondersteund door Azure AI Search. Het gebruik van semantische rangschikking verbetert de zoekrelevantie meetbaar door gebruik van taalbegrip voor de rangschikking van de zoekresultaten. Dit verbetert de gebruikerservaring van RAG-toepassingen, omdat de promptonderbouwing nauwkeuriger wordt door betere zoekresultaten van de zoekservice voordat een aanvraag naar de LLM wordt verzonden.

Een combinatie van AI-services kan worden gebruikt om aangepaste ervaringen voor eindgebruikers te creëren via de Orchestrator, of om processen voor gegevensopname te optimaliseren. Stelt u zich voor dat u een formulierherkenningsservice als Azure AI-documentinformatie gebruikt om gestructureerde informatie uit formulieren te extraheren en gebruikersinvoer efficiënt te verwerken en samen te vatten. Deze service kan vervolgens samenwerken met een LLM om de belangrijkste bevindingen uit de herkende formulierinvoer samen te vatten. Een ander scenario omvat het gebruik van een documentherkenningsservice om documenten in verschillende indelingen, zoals PDF's of Word-documenten, naar tekst te converteren. Vervolgens kan een LLM-tekstinsluitingsservice deze herkende tekst vectoriseren voor verdere analyse.

Privé koppelen-services worden voor alle componenten geïmplementeerd, zodat alle services alleen toegankelijk zijn binnen de privé omgeving. De enige uitzondering zou de Orchestrator-app kunnen zijn, die, als deze wordt gehost in een Online-landingszone, openbaar kan worden aangeboden achter een Web Application Firewall of vergelijkbare services.

Infrastructuuronderdelen

Onderdelen van infrastructuur kunnen worden gehost als onderdeel van de werklast, of centraal in een hub of identiteitsabonnement.

De centrale infrastructuurcomponent van een implementatie van een Sovereign Landing Zone is de Platformconnectiviteitshub, een virtueel netwerk dat wordt aangeboden bij elke inzet van een soevereine landingszone. Het wordt geplaatst in het connectiviteitsabonnement binnen de beheergroep platform.

Gedeelde netwerkcomponenten worden in het virtuele hubnetwerk geplaatst. Deze onderdelen omvatten doorgaans:

• ExpressRoute Circuits of VPN-gateways voor connectiviteit met het bedrijfsnetwerk van een bedrijf, agentschap of organisatie.

• Firewalls kunnen worden geïmplementeerd met behulp van apparaten of een combinatie van Azure Firewall-aanbiedingen, waaronder Web Application Firewall. Deze oplossingen maken verkeersinspectie, filtering en routering mogelijk.

• DDoS-beveiligingscomponenten voor het beschermen van workloads tegen DDoS-aanvallen.

• Privé-DNS-zones voor alle soorten services die worden gebruikt in het gehele virtuele datacenterlandschap, geïmplementeerd met landingszones.

• Virtuele netwerkpeering voor het verbinden van virtuele netwerken van verschillende workloads, zoals gegevensbronnen, transformatie en LLM-componenten via het hubnetwerk.

• Beleidsregels regelen waar nodig de verkeersstroom via de firewalls van de hub.

Overwegingen

Het referentiearchitectuur-diagram toont een representatieve voorbeeldarchitectuur met de typische onderdelen van een op LLM RAG gebaseerde werklast in de context van een soevereine landingszone. Er zijn verschillende overwegingen waarmee u rekening moet houden, die in de vorige secties niet zijn behandeld.

Afstemming met principes van Well-Architected Framework en Cloud Adoption Framework

In voorgaande paragrafen werden enkele afstemmingsaspecten met betrekking tot het Well-Architected Framework (WAF) en het Cloud Adoption Framework (CAF) kort genoemd. Het is belangrijk op te merken dat alle architecturale beslissingen volledig afgestemd moeten zijn met de kernprincipes van CAF- en Azure-landingszones, CAF-analyses op cloudschaal en de WAF, inclusief het WAF-perspectief op Azure OpenAI.

Overwegingen bij het ontwerp van de infrastructuur met betrekking tot vangnetten

Hoewel het omgaan met vangnetten een standaardprocedure in landingszoneomgevingen is, moeten er op verschillende gebieden andere overwegingen worden gemaakt voor LLM- en AI-werklasten. Het is het beste om de Naleving van de beveiligingsbasislijn van Azure en de Initiatiefnormen voor de beleidsbasislijn voor soevereiniteit te volgen tijdens het ontwerpen en definiëren van de infrastructuur voor het workloadabonnement.

De belangrijkste overwegingen die moeten worden benadrukt voor op LLM RAG gebaseerde toepassingen uit deze normen zijn:

Gegevenslocatie en regioselectie

Soevereiniteit stelt strenge eisen aan de gegevenslocatie, en beperkt implementaties mogelijk tot specifieke Azure-regio's in een SLZ. Het selecteren van een regio voor LLM-workloads wordt beperkt door de beschikbaarheid van de vereiste services:

• Controleer of Azure OpenAI en Azure AI Search beide beschikbaar zijn in uw doelregio waar u uw gegevens en uw workload host vanwege gegevenslocatie en/of nabijheidsredenen. Daarnaast zijn deze services vanuit prestatieperspectief belangrijk voor de eindgebruikerbeleving van de toepassing.

• Ten tweede: als we naar Azure OpenAI kijken, is de beschikbaarheid van de respectievelijke LLM-modellen belangrijk, omdat niet alle modellen in alle regio's in gelijke mate beschikbaar zijn.

• Als gegevensbronnen of andere cognitieve services niet beschikbaar zijn in de door u aangegeven doelregio, kunt u deze mogelijk in een andere regio vinden en gebruiken, in overeenstemming met uw vereisten voor gegevenslocatie. Om prestatieredenen moeten de Azure OpenAI-service en Azure AI Search zich echter in dezelfde regio bevinden als de Orchestrator-app.

Netwerken

Openbare eindpunten zijn niet toegestaan ​​in Bedrijfsomgevingen. Daarom moeten alle services worden ingekapseld in een virtueel netwerk. Afhankelijk van de service kan dit netwerk directe inkapselingsmogelijkheden bieden, zoals VM's of AKS-clusters, Private Link of Virtual Network-service-eindpunten. Virtual Network-service-eindpunten moeten waar mogelijk worden vervangen door Private Link.

Naast inkapseling moet de publieke toegang voor alle diensten worden uitgeschakeld. Ten slotte moet het afdwingen van beleid met Azure Policy worden ingeschakeld, zodat openbare toegang nooit per ongeluk kan worden ingeschakeld voor services waarbij het bijbehorende weigeringsbeleid niet kan worden gebouwd. Deze diepgaande verdedigingsstrategie is bedoeld om bijbehorende controlemogelijkheden voor alle services mogelijk te maken.

Versleuteling in rust en onderweg

De meeste services in Azure ondersteunen zowel versleuteling in rust als onderweg. Schakel versleuteling in rust en onderweg in voor alle services, indien beschikbaar. Schakel de nieuwste TLS-versie, momenteel TLS 1.2, in voor versleuteling onderweg.

Beheerde identiteiten

Gebruik beheerde identiteiten voor alle services en service-naar-service-communicatie om te voorkomen dat geheimen voor referenties worden beheerd.

Sleutelrotatie in Key Vault

Wanneer beveiligingsmiddelen als certificaten vereist zijn, schakelt u sleutelrotatie in voor die geheimen in Key Vault om de naleving te behouden.

Netwerk- en toepassingsbeveiligingsgroepen

In een soevereine, veilige omgeving wordt het gebruik van Network Security Groups (NSG) en Application Security Groups (ASG) afgedwongen. Ontbrekende beveiligingsgroepen leiden tot niet-conforme implementaties. De gebruikelijke SSL-poorten zijn handig voor de meeste services waarvan LLM/RAG-workloads afhankelijk zijn, omdat ze zijn gebaseerd op HTTPS. Er zijn specifieke poorten vereist voor gegevensopname van de bronnen naar de zoek- en vectordatabases. Openbare IP's zijn niet toegestaan ​​in Zakelijk-landingszones. Alle services moeten alleen toegankelijk zijn in het virtuele netwerk, waarvoor het gebruik van Private Link- of Virtual Network-service-eindpunten vereist is voor PaaS-diensten.

Meer vangnetten voor beveiliging en soevereiniteit

De belangrijkste en meest voor de hand liggende vangnetten die in eerdere paragrafen zijn behandeld voor uw infrastructuur- en toepassingsontwerp zijn herbruikbaar, zelfs buiten soevereine- of Azure-landingszones. Ander mondiaal beleid is gekoppeld aan centraal beheerde bronnen, zoals Log Analytics-werkruimten of Microsoft Sentinel-implementaties in landingszones op ondernemingsniveau. Tijdens uw infrastructuur- en toepassingsontwerpproces is het van cruciaal belang om rekening te houden met deze centraal beheerde bronnen. Als u dit nalaat, kan dit leiden tot extra inspanningen en tijd na de implementatie. Gelukkig kan de beleidsnalevingsfunctie van Azure na de implementatie niet-conforme bronnen identificeren. Bovendien bieden zowel soevereine- als Azure-landingszones DeployIfNotExists-beleid voor tal van bronnen leveren, waardoor het proces verder wordt vereenvoudigd.

Enkele voorbeelden van dergelijke vangnetten zijn:

• Activering van inloggen op centraal beheerde Log Analytics-werkruimtes.

• Integratie met Azure Security Center of Microsoft Defender voor Cloud.

• Suites voor integratie met beveiligingsinformatie en gebeurtenisbeheer (SIEM), zoals Microsoft Sentinel.

• Integratie met centraal beheerde firewalls, webatoepassingsfirewalls of DDoS-bescherming.

Dit zijn slechts enkele vangnetten die u na uw eerste implementatie als vereisten kunt beschouwen. We raden aan om uw implementaties te testen in een testlandingszone en iteratief een afhandeling van deze vangrails te integreren in uw infrastructuur en toepassingscodebase. Als dat niet helemaal mogelijk is, kunnen veel van deze vangnetten na de implementatie worden opgelost met DeployIfNotExists-beleid.

Implementeer dit scenario

Als u wilt profiteren van Large Language Models (LLM's) en Azure OpenAI gebaseerd op een Retrieval Augmented Generation (RAG)-patroon binnen soevereine landingszones, is het nodig dat u eerst een soevereine landingszone (SLZ) implementeert en configureert en een soeverein basisbeleid toepast. Voor een gedetailleerd overzicht van een SLZ en alle bijbehorende mogelijkheden gaat u naar de Documentatie over Soevereine landingszones op GitHub.

SLZ biedt een omgeving die vangnetten biedt via beleid en beleidssets, beveiligingshandhaving en een consistente basisinfrastructuur voor het implementeren van workloads en toepassingen. SLZ is gebaseerd op Azure-landingszones en breidt deze uit met vangrails en beveiligingscontroles die specifiek zijn voor soevereiniteitsvereisten.

Om de time-to-value van klanten te helpen versnellen en hen te helpen hun nalevingsdoelstellingen te behalen, bevat Microsoft Cloud for Sovereignty kant-en-klare workloadsjablonen die consistent en herhaalbaar kunnen worden geïmplementeerd en gebruikt. De workloadsjablonen zijn afgestemd op Basislijninitiatieven op het gebied van soevereiniteitsbeleid, Cloud for Sovereignty-beleidsportfolio en Standaardbeleid voor Azure-landingszone.

Informatie Assistent agent sjabloon

De sjabloon Informatie Assistent agent biedt organisaties een startpunt voor aanwijzen waarmee ze hun eigen generatieve AI-mogelijkheden kunnen bouwen. Zo kunnen ze de kracht van Azure OpenAI uitbreiden naar gebruikers in de organisatie en hun domeingegevens, zonder dat ze het model hoeven te verfijnen. U kunt het implementeren binnen de Cloud for Sovereignty en uitlijnen met de referentiearchitectuur en richtlijnen in dit artikel. De informatie Assistent agent-sjabloon is compatibel met de Sovereign Landing Zone Online beheergroepscope met behulp van de implementatieconfiguratie in de veilige modus. Ondersteuning voor de scope van de Corp managementgroep is binnenkort beschikbaar.

De sjabloon agent is een combinatie van code, documentatie en educatieve bronnen die gratis beschikbaar worden gesteld aan klanten en partners en die kunnen helpen de time-to-value te versnellen.

Voor meer informatie over het implementeren en configureren van Information Assistent raadpleegt u de documentatie van de Information Assistent agent-sjabloon op GitHub. Voor use cases die u met deze agent-sjabloon kunt realiseren, zie Informatie Assistent Video.