Toepassingsontwerp voor AI-workloads in Azure
Er zijn veel opties die u kunt overwegen bij het bouwen van een toepassing met AI-functies. Uw unieke functionele en niet-functionele vereisten helpen u bij het verfijnen van beslissingen op hoog niveau over uw ontwerp, zoals of de use-case traditionele machine learning, generatief, deterministisch of een combinatie van AI-typen is. Wanneer u overstapt van ontwerpgebieden op hoog niveau naar ontwerpgebieden op lager niveau, zijn er verschillende opties die u onderweg kunt overwegen.
Zoals besproken in het artikel Aan de slag , is het kiezen of u uw eigen model wilt bouwen of een vooraf samengesteld model wilt gebruiken een van de eerste belangrijke beslissingen die u moet nemen. Houd bij het kiezen van een vooraf samengesteld model rekening met de volgende punten:
Catalogusbronnen. Verken opslagplaatsen zoals Hugging Face Model Hub, TensorFlow Hub of azure AI Foundry Portal-modelcatalogus om vooraf getrainde modellen te vinden. Deze platforms bieden een uitgebreide catalogus met modellen voor verschillende taken.
Licentieverlening. Zorg ervoor dat de licentievoorwaarden van het model passen bij uw beveiligings-, nalevings- en toepassingsdoelen, met name als u van plan bent de toepassing te distribueren of te integreren met andere services.
Belangrijke onderdelen. Bekijk de architectuur, trainingsgegevens, prestaties en licenties van het model om te bepalen of deze zijn afgestemd op uw taak of domein.
Zie Overwegingen voor modelhostingplatforms voor hulp bij het kiezen van een hostingplatform.
In dit artikel worden veel algemene ontwerpgebieden en factoren besproken waarmee u rekening moet houden bij het nemen van belangrijke beslissingen over technologie en benadering.
Aanbevelingen
Hier volgt een samenvatting van de aanbevelingen in dit artikel.
| Aanbeveling | Beschrijving |
|---|---|
| Prioriteit geven aan oplossingen buiten de plank. | Wanneer dit praktisch is, kunt u PaaS-oplossingen (Platform as a Service) gebruiken om workloadfuncties te verwerken. Gebruik waar mogelijk vooraf gebouwde en vooraf getrainde modellen om de operationele en ontwikkelingslast voor uw workload- en operationele teams te minimaliseren. |
| Abstracte functies en mogelijkheden van de client. | Houd de client zo dun mogelijk door back-endservices te ontwerpen om kruislingse problemen zoals snelheidsbeperking en failoverbewerkingen af te handelen. |
| Toegang tot de gegevensarchieven blokkeren. | Code in het AI-systeem mag uw gegevensarchieven niet rechtstreeks raken. Routeer alle gegevensaanvragen via een API-laag. De API's moeten worden gebouwd voor de specifieke taak die nodig is. |
| Isoleer uw modellen. | Net als de gegevensarchieven gebruikt u een API-laag om te fungeren als een gateway voor aanvragen voor het model. Sommige PaaS-oplossingen, zoals Azure OpenAI Service en Azure Machine Learning, maken hiervoor gebruik van SDK's. Veel hulpprogramma's, zoals PromptFlow, bevatten systeemeigen ondersteuning voor het doorgeven van API's aan de service. |
| Ontwerponderdelen die onafhankelijk kunnen worden geïmplementeerd. | AI-modellen, gegevenspijplijnen, front-endonderdelen en microservices, zoals gegevensvoorverwerking, functieextractie en deductie, moeten onafhankelijk kunnen worden geïmplementeerd om de flexibiliteit, schaalbaarheid en operabiliteit van uw workload te optimaliseren. |
Onderdelen containeriseren
Overweeg containerisatie als onderdeel van uw ontwerpstrategie om ervoor te zorgen dat uw onafhankelijk te implementeren onderdelen volledig zelfstandig zijn en uw implementaties stroomlijnen. De volgende onderdelen moeten in een container worden geplaatst:
Microservices: afzonderlijke microservices die specifieke functies van de toepassing verwerken, zoals gegevensverwerking, modeldeductie of gebruikersverificatie, moeten in een container worden geplaatst. Deze aanpak maakt onafhankelijke implementatie en schaling mogelijk, waardoor efficiëntere updates en onderhoud worden vergemakkelijkt.
AI-modellen: AI-modellen containeriseren om ervoor te zorgen dat alle afhankelijkheden, bibliotheken en configuraties worden gebundeld. Deze benadering isoleert de modelomgeving van het hostsysteem, voorkomt versieconflicten en zorgt voor consistent gedrag in verschillende implementatieomgevingen.
Pijplijnen voor gegevensverwerking: alle gegevensverwerkingstaken die voorafgaan aan of volgen van modeldeductie, zoals gegevens opschonen, transformeren en functieextractie, moeten in een container worden geplaatst. Deze aanpak verbetert de reproduceerbaarheid en vereenvoudigt het beheer van afhankelijkheden.
Infrastructuurservices: Services die ondersteuning bieden voor infrastructuur, zoals databases of cachelagen, kunnen ook profiteren van containerisatie. Deze aanpak helpt de consistentie van versies te behouden en vereenvoudigt het schalen en beheren van deze onderdelen.
AI-onderdelen colocate met andere workloadonderdelen
Er zijn verschillende goede redenen om uw AI-onderdelen samen te voegen met andere workloadonderdelen, maar er zijn compromissen met dit. Redenen waarom u een punt kunt colocate zijn:
Latentiegevoeligheid: Colocate AI-onderdelen met andere services, zoals API-hosting, wanneer lage latentie belangrijk is. Als bijvoorbeeld realtime deductie is vereist om de gebruikerservaring te verbeteren, kan het plaatsen van AI-modellen dicht bij de API de tijd minimaliseren die nodig is om resultaten op te halen.
Gegevensnabijheid: wanneer AI-modellen regelmatig toegang nodig hebben tot specifieke gegevenssets, zoals een zoekindex, kunnen de prestaties verbeteren en de overhead van gegevensoverdracht verminderen voor snellere verwerking en deductie.
Resourcegebruik: als bepaalde onderdelen aanvullende resourcebehoeften hebben, zoals CPU en geheugen, kan de toewijzing ervan het resourcegebruik optimaliseren. Een model dat aanzienlijke berekeningen vereist, kan bijvoorbeeld resources delen met een service die tegelijkertijd lagere eisen heeft.
Afweging. Er zijn compromissen met colocatieonderdelen die moeten worden overwogen. Mogelijk verliest u de mogelijkheid om onafhankelijk onderdelen te implementeren of te schalen. U kunt ook het risico op storing verhogen door de potentiële straal van incidenten te vergroten.
Het gebruik van orchestrators evalueren in generatieve AI-oplossingen
Een orchestrator beheert de werkstroom die de communicatie tussen de verschillende onderdelen van de AI-oplossing coördineert die anders moeilijk te beheren zijn in complexe workloads. U wordt aangeraden een orchestrator in uw ontwerp in te bouwen als uw workload een van de volgende kenmerken heeft:
Complexe werkstromen: De werkstroom omvat meerdere stappen, zoals voorverwerking, modelketens of postverwerking.
Voorwaardelijke logica: Beslissingen moeten dynamisch worden genomen op basis van modeluitvoer, zoals routeringsresultaten naar verschillende modellen.
Schalen en resourcebeheer: u moet resourcetoewijzing voor toepassingen met een groot volume beheren met behulp van modelschalen op basis van vraag.
Statusbeheer: u moet de status en het geheugen van gebruikersinteracties beheren.
Gegevens ophalen: u moet vergrotingsgegevens uit de index kunnen ophalen.
Overwegingen voor het gebruik van meerdere modellen
Wanneer uw workload meerdere modellen gebruikt, is het essentieel om een orchestrator te gebruiken. De orchestrator is verantwoordelijk voor het routeren van gegevens en aanvragen naar het juiste model op basis van de use-case. Plan de gegevensstroom tussen modellen, zodat uitvoer van het ene model kan fungeren als invoer voor een ander model. Planning kan betrekking hebben op gegevenstransformatie- of verrijkingsprocessen.
Indeling en agents
Voor generatieve AI-workloads kunt u overwegen om een agentgebaseerd, ook wel agentisch genoemd, te gebruiken bij uw ontwerp om uitbreidbaarheid toe te voegen aan uw indeling. Agents verwijzen naar contextgebonden functionaliteit, waarbij veel kenmerken van microservicestijlen worden gedeeld die taken uitvoeren in combinatie met een orchestrator. De orchestrator kan taken adverteren naar een groep agents of agents, kan mogelijkheden registreren bij de orchestrator. Met beide benaderingen kan de orchestrator dynamisch bepalen hoe de query moet worden verdeeld en gerouteerd tussen de agents.
Agentische benaderingen zijn ideaal wanneer u een gemeenschappelijk UI-oppervlak hebt met meerdere, veranderende functies die in die ervaring kunnen worden aangesloten om meer vaardigheden en grondgegevens in de loop van de tijd aan de stroom toe te voegen.
Voor complexe workloads met veel agents is het efficiënter om agents in staat te stellen dynamisch samen te werken in plaats van een orchestrator te gebruiken om taken op te splitsen en toe te wijzen.
Communicatie tussen de orchestrator en agents moet een patroon in de onderwerpwachtrij volgen, waarbij agents abonnees zijn van een onderwerp en de orchestrator taken via een wachtrij verzendt.
Het gebruik van een agentische benadering werkt het beste met een indelingspatroon in plaats van een choreograafpatroon.
Zie Overwegingen voor het indelingsplatform voor meer informatie.
Het gebruik van API-gateways evalueren
API-gateways, zoals Azure API Management, abstracte functies van API's die afhankelijkheden tussen de aanvragende service en de API loskoppelen. API-gateways bieden de volgende voordelen voor AI-workloads:
Meerdere microservices: Ze helpen u bij het beheren van meerdere EINDPUNTEN van AI-modellen en u moet consistent beleid afdwingen, zoals frequentiebeperking en verificatie.
Verkeersbeheer: Ze helpen u om apps met veel verkeer efficiënt te beheren door aanvragen te beheren, reacties in de cache op te bergen en belastingen te distribueren.
Beveiliging: Ze bieden gecentraliseerd toegangsbeheer, logboekregistratie en bedreigingsbeveiliging voor de API's achter de gateway.
Profiteer van ontwerppatronen voor AI-toepassingen
Er zijn verschillende algemene ontwerppatronen die zijn vastgesteld in de branche voor AI-toepassingen die u kunt gebruiken om uw ontwerp en implementatie te vereenvoudigen. Deze ontwerppatronen zijn onder andere:
Modelvermeniging: Dit ontwerppatroon omvat het combineren van voorspellingen van meerdere modellen om de nauwkeurigheid en robuustheid te verbeteren, waardoor de zwakke punten van afzonderlijke modellen worden beperkt.
Microservicesarchitectuur: het scheiden van onderdelen in onafhankelijk te implementeren services verbetert de schaalbaarheid en onderhoudbaarheid, zodat teams tegelijkertijd aan verschillende onderdelen van de toepassing kunnen werken.
Gebeurtenisgestuurde architectuur: Door gebruik te maken van gebeurtenissen om acties te activeren, kunnen onderdelen en realtime verwerking worden losgekoppeld, waardoor het systeem sneller reageert en kan worden aangepast aan veranderende gegevens.
RAG-patroon- en segmenteringsstrategieën
Het RAG-patroon (Retrieval-Augmented Generation) combineert generatieve modellen met ophaalsystemen, waardoor het model toegang heeft tot externe kennisbronnen voor verbeterde context en nauwkeurigheid. Zie de reeks rag-oplossingen ontwerpen en ontwikkelen voor uitgebreide richtlijnen over dit patroon. Er zijn twee RAG-benaderingen:
Just-In-Time: Met deze aanpak worden relevante informatie dynamisch opgehaald op het moment van een aanvraag, zodat de meest recente gegevens altijd worden gebruikt. Het is nuttig in scenario's waarvoor realtime context is vereist, maar kan latentie veroorzaken.
Vooraf berekend (in cache): deze methode omvat het ophalen van cacheresultaten, waardoor reactietijden worden verminderd door vooraf berekende gegevens te leveren. Het is geschikt voor scenario's met hoge vraag waarbij consistente gegevens kunnen worden opgeslagen, maar mogelijk niet de meest recente informatie weerspiegelen, wat leidt tot mogelijke relevantieproblemen.
Wanneer u een RAG-patroon gebruikt, is een goed gedefinieerde segmenteringsstrategie essentieel om de prestatie-efficiëntie van uw workload te optimaliseren. Begin met de richtlijnen in de reeks rag-oplossingen ontwerpen en ontwikkelen. Aanvullende aanbevelingen die u moet overwegen, zijn:
Implementeer een dynamische segmenteringsstrategie waarmee segmentgrootten worden aangepast op basis van gegevenstype, querycomplexiteit en gebruikersvereisten. Dit kan de efficiëntie en het behoud van de context verbeteren.
Neem feedbacklussen op om segmenteringsstrategieën te verfijnen op basis van prestatiegegevens.
Bewaar gegevensherkomst voor segmenten door metagegevens en unieke id's te onderhouden die teruggaan naar de groundingbron. Duidelijke herkomstdocumentatie helpt ervoor te zorgen dat gebruikers inzicht hebben in de oorsprong van de gegevens, de transformaties en hoe deze bijdraagt aan de uitvoer.
Wanneer ontwerppatronen worden gebruikt
Overweeg het gebruik van deze ontwerppatronen wanneer uw use-case voldoet aan een van de voorwaarden:
Complexe werkstromen: bij het omgaan met complexe werkstromen of interacties tussen meerdere AI-modellen, kunnen patronen zoals RAG of microservices helpen bij het beheren van complexiteit en het garanderen van duidelijke communicatie tussen onderdelen.
Schaalbaarheidsvereisten: Als de vraag op uw toepassing fluctueert, kunnen afzonderlijke onderdelen onafhankelijk worden geschaald met behulp van een patroon zoals microservices, waardoor verschillende belastingen kunnen worden aangepast zonder dat dit van invloed is op de algehele systeemprestaties.
Gegevensgestuurde toepassingen: Als uw toepassing uitgebreide gegevensverwerking vereist, kan een gebeurtenisgestuurde architectuur realtime responsiviteit en efficiënte gegevensverwerking bieden.
Notitie
Kleinere toepassingen of POC's profiteren doorgaans niet van een van deze ontwerppatronen en moeten worden gebouwd met een simplistisch ontwerp. Als u beperkingen voor resources (budget, tijd of aantal) hebt, is het gebruik van een simplistisch ontwerp dat later kan worden geherstructureerd een betere benadering dan het aannemen van een complex ontwerppatroon.
De juiste frameworks en bibliotheken kiezen
De keuze van frameworks en bibliotheken is nauw verbonden met toepassingsontwerp, wat niet alleen van invloed is op de architectuur, maar ook op prestaties, schaalbaarheid en onderhoudbaarheid. Ontwerpvereisten kunnen daarentegen frameworkkeuzen beperken, waardoor er een dynamische interactie tussen de twee ontstaat. Het gebruik van de Semantic Kernel SDK (SK) moedigt bijvoorbeeld vaak een op microservices gebaseerd ontwerp aan waarbij elke agent of functionaliteit wordt ingekapseld binnen een eigen service. Factoren waarmee u rekening moet houden bij het kiezen van frameworks en bibliotheken zijn:
Toepassingsvereisten: De specifieke vereisten van de toepassing, zoals realtime verwerking of batchverwerking, kunnen de keuze van framework beperken. Als de toepassing bijvoorbeeld lage latentie vereist, is mogelijk een framework met asynchrone mogelijkheden vereist.
Integratiebehoeften: Het ontwerp kan specifieke integraties met andere systemen of services vereisen. Als een framework geen ondersteuning biedt voor de benodigde protocollen of gegevensindelingen, kan het nodig zijn om het ontwerp te herzien of een ander framework te selecteren.
Teamexpertise: De vaardighedenset van het ontwikkelteam kan frameworkkeuzen beperken. Een ontwerp dat afhankelijk is van een minder vertrouwd framework kan leiden tot een grotere ontwikkeltijd en complexiteit, waardoor een selectie van een vertrouwder hulpprogramma wordt gevraagd.
Een strategie ontwerpen voor identiteiten, autorisatie en toegang
Over het algemeen moet u identiteit, autorisatie en toegang benaderen op dezelfde manier als u normaal gesproken toepassingen ontwerpt. U moet een id-provider, zoals Microsoft Entra ID, gebruiken om deze gebieden zoveel mogelijk te beheren. Er zijn echter unieke uitdagingen voor veel AI-toepassingen die speciale aandacht nodig hebben. Het behouden van toegangsbeheerlijsten (ACL's) via het systeem is soms lastig of zelfs onmogelijk zonder nieuwe ontwikkeling te introduceren.
Bekijk de richtlijnen in de beveiligde multitenant RAG-oplossing voor meer informatie over het toevoegen van metagegevens voor beveiligingsbeperkingen aan documenten en segmenten. Dit bijsnijden kan worden gebaseerd op beveiligingsgroepen of vergelijkbare organisatieconstructies.
Houd rekening met de niet-functionele vereisten
Mogelijk hebt u niet-functionele vereisten voor uw workload die lastig zijn vanwege factoren die inherent zijn aan AI-technologieën. Veelvoorkomende niet-functionele vereisten en hun uitdagingen zijn:
Latentie van modeldeductie/time-outs: AI-toepassingen vereisen vaak realtime of bijna realtime antwoorden. Ontwerpen voor lage latentie is van cruciaal belang, waarbij modelarchitectuur, gegevensverwerkingspijplijnen en hardwarebronnen worden geoptimaliseerd. Het implementeren van cachingstrategieën en het garanderen van efficiënt laden van modellen zijn ook essentieel om time-outs te voorkomen en tijdige reacties te bieden.
Token- of aanvraagdoorvoerbeperkingen: veel AI-services leggen limieten op voor het aantal tokens of de doorvoer van aanvragen, met name bij het gebruik van cloudmodellen. Ontwerpen voor deze beperkingen vereist zorgvuldig beheer van invoergrootten, batchaanvragen indien nodig en mogelijk het implementeren van snelheidsbeperkings- of wachtrijmechanismen voor het beheren van gebruikersverwachtingen en het voorkomen van serviceonderbrekingen.
Scenario's voor kosten en terugstorting: het ontwerpen voor kostentransparantie omvat het implementeren van gebruikstracerings- en rapportagefuncties waarmee organisaties kosten nauwkeurig kunnen toewijzen op verschillende afdelingen. Terugstortingsbeheer wordt normaal gesproken verwerkt door een API-gateway, zoals Azure API Management.