Toepassingsontwerp voor AI-workloads in Azure

Er zijn veel keuzes waarmee u rekening moet houden wanneer u een toepassing met AI-functies maakt. Uw unieke functionele en niet-functionele vereisten, zoals of de use-case traditionele machine learning, generatieve, deterministische of een combinatie van AI-typen is, helpt u bij het verfijnen van beslissingen op hoog niveau over uw ontwerp. U kunt deze keuzes overwegen wanneer u overstapt van ontwerpgebieden op hoog niveau naar ontwerpgebieden op lager niveau.

Zoals besproken in het Aan de slag artikel, of u nu uw eigen model wilt bouwen of een vooraf samengesteld model wilt gebruiken, is een van de eerste belangrijke beslissingen die u moet nemen. Houd rekening met de volgende punten wanneer u een vooraf samengesteld model gebruikt:

• Catalogusbronnen. Verken opslagplaatsen zoals de Hugging Face Model Hub, TensorFlow Hub en de azure AI Foundry-portalmodelcatalogus 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 het hosten en inferentieplatformvoor begeleiding bij het kiezen van een hostingplatform.

In dit artikel worden algemene ontwerpgebieden en factoren beschreven die u moet overwegen wanneer u beslissingen neemt over technologie en benadering.

Aanbevelingen

De volgende tabel bevat een overzicht van de aanbevelingen in dit artikel.

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 en gebruikersverificatie, moeten in een container worden geplaatst. Deze aanpak maakt onafhankelijke implementatie en schaalaanpassing mogelijk en faciliteert efficiëntere updates en onderhoud.

• 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 om versieconflicten te voorkomen en om consistent gedrag in verschillende implementatieomgevingen te garanderen.

• pijplijnen voor gegevensverwerking. Alle gegevensverwerkingstaken die voorafgaan aan of volgen van modeldeductie, zoals het opschonen van gegevens, transformatie 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 en cachelagen, kunnen ook profiteren van containerisatie. Door deze services te containeriseren, kunt u versieconsistentie behouden en eenvoudiger schalen en beheren van deze onderdelen.

AI-onderdelen colocate met andere workloadonderdelen

Er zijn verschillende goede redenen om uw AI-componenten samen met andere workloadcomponenten te positioneren, maar er zijn afwegingen die hiermee gepaard gaan. U kunt ervoor kiezen om om de volgende redenen onderdelen te koppelen:

• Latentiegevoeligheid. Co-locate AI-componenten met andere services, zoals API-hosting, wanneer lage vertraging belangrijk is. Als u bijvoorbeeld realtime deductie nodig hebt 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.

• gegevensbijheid. Wanneer AI-modellen regelmatig toegang nodig hebben tot specifieke datasets, zoals een zoekindex, kan het samenvoegen van deze componenten de prestaties verbeteren en de overhead van gegevensoverdracht verminderen om de verwerking en inferentie te versnellen.

• Resourcegebruik. Als specifieke 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.

compromis. Er zijn compromissen waarmee rekening moet worden gehouden wanneer u besluit of u onderdelen wilt coloceren. Mogelijk verliest u de mogelijkheid om onafhankelijk onderdelen te implementeren of te schalen. U kunt ook het risico op storingen verhogen door de potentiële explosiestraal van incidenten te vergroten.

Het gebruik van orchestrators evalueren in generatieve AI-oplossingen

Een orchestrator beheert een werkstroom door de communicatie tussen de verschillende onderdelen van de AI-oplossing te coördineren 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 nabewerking.

• voorwaardelijke logica. Beslissingen, zoals routeringsresultaten naar verschillende modellen, moeten dynamisch worden gemaakt op basis van modeluitvoer.

• Schaalbeheer en middelenbeheer. U moet resourcetoewijzing voor toepassingen met een hoog volume beheren met behulp van modelschaalaanpassing die is gebaseerd op aanvraag.

• 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 een orchestrator essentieel. De orchestrator stuurt 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 bieden contextgebonden functionaliteit. Ze delen veel kenmerken met microservices en voeren taken uit in combinatie met een orchestrator. De orchestrator kan taken aanbieden aan een groep agenten, of agenten kunnen capaciteiten registreren bij de orchestrator. Met beide methoden kan de orchestrator dynamisch bepalen hoe de query tussen de agents moet worden verdeeld en gerouteerd.

Agentische benaderingen zijn ideaal wanneer u een gemeenschappelijk UI-oppervlak hebt met meerdere, veranderende functies die kunnen worden aangesloten op de ervaring om meer vaardigheden en grondgegevens toe te voegen aan de stroom in de loop van de tijd.

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 ontrukken functies aan API's, waardoor afhankelijkheden tussen de aanroepende service en de API worden losgekoppeld. API-gateways bieden de volgende voordelen voor AI-workloads:

• Meerdere microservices. Gateways helpen u bij het beheren van meerdere AI-modeleindpunten wanneer u consistent beleid moet afdwingen, zoals frequentiebeperking en verificatie.

• Verkeersmanagement. Met gateways kunt u apps met veel verkeer efficiënt beheren door aanvragen te beheren, antwoorden in de cache op te slaan en het verkeer te verdelen.

• Security. Gateways bieden gecentraliseerd toegangsbeheer, logboekregistratie en bedreigingsbeveiliging voor de API's achter de gateway.

Ontwerppatronen voor AI-toepassingen gebruiken

Er zijn verschillende algemene ontwerppatronen vastgesteld in de branche voor AI-toepassingen. U kunt ze gebruiken om uw ontwerp en implementatie te vereenvoudigen. Deze ontwerppatronen zijn onder andere:

• model dat lijkt op. Dit ontwerppatroon omvat het combineren van voorspellingen van meerdere modellen om de nauwkeurigheid en robuustheid te verbeteren door de zwakke punten van afzonderlijke modellen te beperken.

• Microservices-architectuur. Het scheiden van onderdelen in onafhankelijk te implementeren services verbetert de schaalbaarheid en onderhoudbaarheid. Hiermee kunnen teams tegelijkertijd aan verschillende onderdelen van de toepassing werken.

• gebeurtenisgestuurde architectuur. Door gebeurtenissen te gebruiken om acties te activeren, kunnen losgekoppelde onderdelen en realtime verwerking het systeem responsief en aanpasbaarder maken aan veranderende gegevens.

RAG-patroon- en segmenteringsstrategieën

Het patroon Retrieval-Augmented Generation (RAG) combineert generatieve modellen met ophaalsystemen, waardoor het model toegang heeft tot externe kennisbronnen voor verbeterde context en nauwkeurigheid. Zie de Ontwerp en ontwikkel een RAG-oplossing artikelenreeks voor uitgebreide richtlijnen over dit patroon. Er zijn twee RAG-benaderingen:

• Just-In-Time-. Met deze methode worden relevante informatie dynamisch opgehaald op het moment van een aanvraag om ervoor te zorgen dat de meest recente gegevens altijd worden gebruikt. Het is nuttig in scenario's waarvoor realtimecontext is vereist, maar het kan latentie veroorzaken.

• Vooraf berekende (gecache). Deze methode omvat het ophalen van cacheresultaten om reactietijden te verminderen door vooraf berekende gegevens te leveren. Het is geschikt voor scenario's met hoge vraag waarbij consistente gegevens kunnen worden opgeslagen. De gegevens weerspiegelen mogelijk niet de meest recente informatie, wat kan leiden tot relevantieproblemen.

Wanneer u een RAG-patroon gebruikt, is een goed gedefinieerde segmenteringsstrategie essentieel voor het optimaliseren van de prestatie-efficiëntie van uw workload. Begin met de richtlijnen in de Ontwerp en ontwikkel een RAG-oplossing reeks. Hier volgen enkele aanvullende aanbevelingen om rekening mee te houden:

• Implementeer een dynamische segmenteringsstrategie waarmee segmentgrootten worden aangepast op basis van gegevenstype, querycomplexiteit en gebruikersvereisten. Dit kan de efficiëntie en het behoud van 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 ervan en hoe het bijdraagt aan de uitvoer.

Wanneer ontwerppatronen worden gebruikt

Overweeg het gebruik van deze ontwerppatronen wanneer uw use-case voldoet aan de voorwaarde die wordt beschreven:

• Complexe werkstromen. Wanneer u complexe werkstromen of interacties tussen meerdere AI-modellen hebt, kunnen patronen zoals RAG of microservices helpen bij het beheren van complexiteit en zorgen voor duidelijke communicatie tussen onderdelen.

• schaalbaarheidsvereisten. Als de vraag op uw toepassing fluctueert, kunnen afzonderlijke onderdelen onafhankelijk worden geschaald door een patroon zoals microservices, zodat ze kunnen worden aangepast aan verschillende belastingen zonder dat dit van invloed is op de algehele systeemprestaties.

• gegevensgestuurde toepassingen. Als uw toepassing uitgebreide gegevensverwerking vereist, kan een gebeurtenisgestuurde architectuur realtime reactiesnelheid en efficiënte gegevensverwerking bieden.

De juiste frameworks en bibliotheken kiezen

De keuze aan frameworks en bibliotheken is nauw verbonden met het toepassingsontwerp. Ze zijn van invloed op prestaties, schaalbaarheid en onderhoudbaarheid. Ontwerpvereisten kunnen uw frameworkkeuzen echter beperken. Het gebruik van de Semantische Kernel SDK moedigt bijvoorbeeld vaak een op microservices gebaseerd ontwerp aan waarbij elke agent of functie is ingekapseld binnen een eigen service. Houd rekening met deze factoren wanneer u frameworks en bibliotheken kiest:

• Vereisten voor aanvragen. De vereisten van de toepassing, zoals realtime verwerking of batchverwerking, kunnen de keuze van het framework beperken. Als de toepassing bijvoorbeeld lage latentie vereist, moet u mogelijk een framework gebruiken met asynchrone mogelijkheden.

• Integratiebehoeften. Het ontwerp vereist mogelijk specifieke integraties met andere systemen of services. Als een framework de benodigde protocollen of gegevensindelingen niet ondersteunt, moet u mogelijk het ontwerp herzien of een ander framework kiezen.

• Teamexpertise. De vaardighedenset van het ontwikkelteam kan frameworkkeuzes beperken. Een ontwerp dat afhankelijk is van een minder vertrouwd framework kan leiden tot een grotere ontwikkeltijd en complexiteit, dus u kunt een vertrouwder hulpprogramma gebruiken.

Een strategie ontwerpen voor identiteiten, autorisatie en toegang

Over het algemeen moet u identiteit, autorisatie en toegang benaderen op dezelfde manier als wanneer u normaal gesproken toepassingen ontwerpt. U moet een id-provider, zoals Microsoft Entra ID, gebruiken om deze gebieden zoveel mogelijk te beheren. Veel AI-toepassingen hebben echter unieke uitdagingen waarvoor speciale overwegingen nodig zijn. Het is soms lastig of zelfs onmogelijk om toegangsbeheerlijsten (ACL's) via het systeem te behouden zonder nieuwe ontwikkeling.

Zie Gids voor het ontwerpen van een veilige multitenant RAG-afleidingsoplossing om te leren hoe u metadata voor beveiligingssnoeiing aan documenten en delen kunt toevoegen. Dit bijsnijden kan worden gebaseerd op beveiligingsgroepen of vergelijkbare organisatieconstructies.

Overweeg niet-functionele vereisten

Uw workload heeft mogelijk niet-functionele vereisten die uitdagingen opleveren vanwege factoren die inherent zijn aan AI-technologieën. Hieronder volgen enkele veelvoorkomende niet-functionele vereisten en hun uitdagingen:

• latentie van modeldeductie/time-outs. AI-toepassingen vereisen vaak realtime of bijna realtime antwoorden. Ontwerpen voor lage latentie is cruciaal. Het omvat het optimaliseren van modelarchitectuur, pijplijnen voor gegevensverwerking en hardwarebronnen. 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 aanvraagbeperkingen voor doorvoer. Veel AI-services leggen limieten op voor het aantal tokens of de doorvoer van aanvragen, met name met cloudmodellen. Ontwerpen voor deze beperkingen vereist zorgvuldig beheer van invoergrootten, batchverwerking van aanvragen indien nodig en mogelijk implementatie van mechanismen voor snelheidsbeperking of wachtrijen om de verwachtingen van gebruikers te beheren en serviceonderbrekingen te voorkomen.

• scenario's voor kosten en terugstortingen. Ontwerpen voor kostentransparantie omvat het implementeren van gebruikstracking- en rapportagefuncties waarmee terugstortingsmodellen mogelijk worden gemaakt. Met deze functies kunnen organisaties kosten nauwkeurig toewijzen tussen afdelingen. Terugstortingsbeheer wordt doorgaans verwerkt door een API-gateway, zoals Azure API Management-.

Volgende stap