Ontwerpen ter ondersteuning van levenscyclus van basismodellen

Basismodellen zijn versieafhankelijkheden die u in uw AI-workload gebruikt. Elk basismodel heeft een levenscyclus die moet worden overwogen. Net als codebibliotheken en andere afhankelijkheden in uw workload ontvangen basismodellen secundaire versie-updates die prestatieverbeteringen en optimalisaties bieden. Grote versie-updates introduceren substantiële wijzigingen in mogelijkheden, prestaties of de versheid van trainingsgegevens. In de loop van de tijd zijn basismodellen mogelijk afgeschaft vanwege obsolcentie of de hostvoorkeuren van uw model die buiten uw controle vallen.

U moet uw workload zodanig ontwerpen dat deze de gedocumenteerde levenscycli van de modellen die u als afhankelijkheden kiest, ondersteunt. Als u de levenscyclus van de modellen niet in overweging neemt, kunt u onnodig riskante upgrades uitvoeren, niet-geteste gedragswijzigingen introduceren, onnodige downtime van werkbelastingen veroorzaken of storingen ervaren vanwege de manier waarop uw hostingplatform end-of-life-modellen afhandelt.

Een workload die is ontworpen ter ondersteuning van de levenscyclus van de modellen, maakt het eenvoudiger om te experimenteren en veilig te migreren naar nieuwe basismodellen wanneer ze de marketplace binnenkomen.

Typen modelupdates

Het bereik van de modelupdate in uw generatieve AI-oplossing kan drastisch variëren, van een upgrade voor een kleine revisiewijziging tot het kiezen van een nieuwe modelfamilie. Er zijn verschillende redenen waarom u ervoor kunt kiezen om het model in uw oplossing te upgraden. De volgende tabel bevat verschillende updatebereiken, samen met een voorbeeld en voordelen van het maken van deze upgrade.

Zoals u in de tabel kunt zien, zijn de voordelen van het overstappen naar een nieuw model doorgaans een combinatie van de volgende factoren:

• Prestaties, zoals snelheid en latentie

• Capaciteit, zoals doorvoer die wordt gemeten in transacties per minuut

• Beschikbaarheid van quotum

• Kostenefficiëntie

• Regionale beschikbaarheid

• Multimodale mogelijkheden

• Bijgewerkte trainingskennis

• Fouten opgelost

• Specialisatie of despecialisatie om beter af te stemmen op uw gebruikssituatie.

• Het voorkomen van werkbelastinguitval als gevolg van levenscyclusbeheer voor modelhostingsystemen

Model voor pensioen gedrag

Het buitengebruikstellingsgedrag van modellen is afhankelijk van uw strategie voor modelimplementatie. Er zijn drie belangrijke strategieën voor het implementeren van modellen. Het is belangrijk om te begrijpen hoe elke strategie de uitfasering van versies afhandelt.

• MaaS-oplossingen (model as a service) zijn vooraf getrainde modellen die beschikbaar worden gesteld als API's die schaalbaarheid en een eenvoudige integratie bieden. Ze hebben te maken met een afweging van mogelijk hogere kosten en minder controle over modellen. Voorbeelden van MaaS-oplossingen zijn modellen die zijn geïmplementeerd in Azure OpenAI in Foundry-modellen en -modellen uit de modelcatalogus die is geïmplementeerd als serverloze API's.

• MaaP-oplossingen (model als platform) zijn modellen die binnen een groter platform worden geïmplementeerd en beheerd, zoals modellen uit de Azure-modelcatalogus die is geïmplementeerd in beheerde compute. Deze oplossing biedt meestal meer controle over modellen, maar vereist meer beheer dan MaaS-oplossingen.

• Zelfhostingmodellen zijn modellen die zijn geïmplementeerd in uw eigen infrastructuur. Deze implementatie biedt maximale controle over modellen, maar vereist aanzienlijke verantwoordelijkheid voor infrastructuur, beheer en onderhoud.

Zowel MaaS- als MaaP-strategieën in Azure-bronmodellen uit de Foundry-modelcatalogus. Modellen in de modelcatalogus volgen een levenscyclus waarin modellen zijn afgeschaft en vervolgens buiten gebruik worden gesteld. U moet plannen voor deze eventualiteiten in uw workload.

Wanneer u zelf-hostmodellen gebruikt of beheerde berekeningen gebruikt, behoudt u volledige controle en hoeft u geen modellen bij te werken. Maar misschien wilt u een levenscyclus van een model repliceren voor de toegevoegde voordelen die een nieuwer model kan opleveren voor uw workload.

Breedte van verandering voor modelupdates

U moet evalueren hoe een modelupdate van invloed is op uw workload, zodat u de overgang van het oude model naar het nieuwe model kunt plannen. De mate van workloadwijziging is afhankelijk van de functionele en niet-functionele verschillen tussen de oude en nieuwe modellen. In het diagram ziet u een vereenvoudigde chatarchitectuur met genummerde secties waarin gebieden worden gemarkeerd waarop een modelupdate mogelijk effect heeft.

Houd voor elk van deze gebieden rekening met downtime die wordt veroorzaakt door updates en hoe u aanvragen verwerkt die door het systeem worden verwerkt. Als er onderhoudsvensters beschikbaar zijn voor uw workload, gebruikt u deze vensters wanneer het wijzigingsbereik groot is. Als er geen onderhoudsvensters beschikbaar zijn, kunt u wijzigingen in deze gebieden aanpakken om de functionaliteit en serviceniveaudoelstellingen van uw workload te behouden tijdens de modelupdate.

1. Het model: De voor de hand liggende wijziging is van het model zelf. U implementeert het nieuwe model met behulp van de gekozen strategie voor modelimplementatie. U moet afwegingen tussen in-place upgrades en side-by-side implementatie evalueren.

   Wanneer u overstapt op een nieuwe modelrevisie van een nauwkeurig afgestemd model, moet u de nieuwe modelversie opnieuw afstemmen voordat u deze gebruikt. Wanneer u bijwerkt om een ander model te gebruiken, moet u bepalen of het afstemmen vereist is.

2. De modelconfiguratie: Wanneer u het basismodel in uw AI-oplossing bijwerkt, moet u mogelijk hyperparameters of configuraties aanpassen om de prestaties voor de architectuur en mogelijkheden van het nieuwe model te optimaliseren. Als u bijvoorbeeld overschakelt van een model op basis van een transformator naar een terugkerend neuraal netwerk, kunnen verschillende leersnelheden en batchgrootten nodig zijn om optimale resultaten te bereiken.

3. De prompt: Wanneer u basismodellen in uw workload wijzigt, moet u mogelijk systeemprompts in uw orchestrators of agents aanpassen om af te stemmen op de sterke punten en mogelijkheden van het nieuwe model.

   Naast het bijwerken van de modelconfiguratie is het bijwerken van de prompt een van de meest voorkomende wijzigingen wanneer u modellen bijwerkt. Wanneer u een nieuw model evalueert, zelfs voor een kleine update van een versie, test de wijzigingen in de prompt als het niet voldoet aan uw vereisten. Deze aanpak zorgt ervoor dat u prestatieproblemen kunt oplossen voordat u andere wijzigingen verkent. U moet de prompt adresseren wanneer u overstapt op nieuwe modellen. Het is ook waarschijnlijk dat u op de prompt moet ingaan wanneer u grote wijzigingen aanbrengt.

4. De indelingslogica: Voor sommige modelupdates, met name wanneer u gebruikmaakt van nieuwe functies, moet u wijzigingen aanbrengen in de indelings- of agentlogica.

   Als u uw model bijvoorbeeld bijwerkt naar GPT-4 om te profiteren van functie-aanroepen, moet u de indelingslogica wijzigen. Uw oude model heeft een resultaat geretourneerd dat u aan de aanroeper kunt terugsturen. Bij het aanroepen van functies retourneert de aanroep van het model een functie die door de orkestlogica moet worden aangeroepen. In Azure is het gebruikelijk om indelingslogica te implementeren in Foundry Agent Service of met behulp van op code gebaseerde oplossingen zoals het Microsoft Agent Framework, Semantic Kernel of LangChain die worden gehost in Azure.

5. De grondgegevens: Voor sommige modelupdates en grootschalige wijzigingen moet u mogelijk veranderingen aanbrengen in uw grond- of fijn-afstemmingsgegevens of in de manier waarop u die gegevens ophaalt.

   Wanneer u bijvoorbeeld overstapt van een gegeneraliseerd model naar een domeinspecifiek model, zoals een model dat is gericht op financiën of geneeskunde, hoeft u mogelijk geen domeinspecifieke grondgegevens meer door te geven aan het model. Een ander voorbeeld is wanneer een nieuw model een groter contextvenster kan verwerken. In dit scenario wilt u mogelijk andere relevante segmenten ophalen of de grootte van uw segmenten afstemmen. Voor meer informatie, zie Ontwerp en ontwikkel een retrieval-augmented generation (RAG) oplossing.

6. Hardware: Voor modellen die in MaaP worden uitgevoerd, is voor een modelwijziging mogelijk nieuwe hardware vereist. Alleen specifieke reken-SKU's zijn ingeschakeld voor modellen uit de catalogus. Hardware kan ook worden afgeschaft. Hiervoor moet u het model uitvoeren op nieuwe hardware.

Ontwerp voor verandering

U zult waarschijnlijk modellen in uw workload bijwerken. Als u de MaaS-implementatiestrategie in Azure gebruikt, worden modellen buiten gebruik gesteld en moet u een upgrade uitvoeren naar een nieuwere versie. U kunt er ook voor kiezen om over te stappen op verschillende modellen of modelversies om te profiteren van nieuwe functies, lagere prijzen of verbeterde prestaties. In beide gevallen moet uw architectuur ondersteuning bieden voor het bijwerken van het model dat door uw generatieve AI-workload wordt gebruikt.

In de vorige sectie werd de verschillende breedte van verandering besproken. Volg de juiste machine learning-bewerkingen (MLOps), gegevensbewerkingen (DataOps) en generatieve AI-bewerkingen (GenAIOps) om geautomatiseerde pijplijnen te bouwen en te onderhouden voor het verfijnen van modellen, prompts te ontwikkelen, het wijzigen van hyperparameters en het beheren van orkestratielogica.

Updates voor de hyperparameters en prompts zijn gebruikelijk in de meeste modelupdates. Omdat deze wijzigingen zo gebruikelijk zijn, moet uw architectuur een beheerd wijzigingsmechanisme voor deze gebieden ondersteunen. Een belangrijke overweging is dat prompts en hyperparameters zijn ontworpen voor specifieke modelversies. U moet ervoor zorgen dat de prompts en hyperparameters altijd worden gebruikt met het juiste model en de juiste versie.

Geautomatiseerde pijplijnen

Implementeer geautomatiseerde pijplijnen om de verschillende aspecten van uw generatieve AI-toepassing te testen en te evalueren:

• MLOps: Volg de Azure MLOps-richtlijnen voor het bouwen van pijplijnen voor het afstemmen van modellen, indien van toepassing.

• GenAIOps: Implementeer GenAIOps-pijplijnen om wijzigingen in het model, modelhypparameters, prompt- en indelingslogica te testen en evalueren.

• DataOps: Implementeer DataOps-pijplijnen om wijzigingen in uw RAG-grondgegevens te testen en te evalueren.

U moet om de volgende redenen pijplijnen implementeren:

• Om u te helpen bij uw iteratieve ontwikkeling en experimenten (binnenste lus)
• Uw generatieve AI-oplossing veilig implementeren en operationeel maken (buitenste lus)

Gebruik indien mogelijk dezelfde basislijngegevens die u met de productietoepassing gebruikt om de wijzigingen in uw generatieve AI-toepassing te testen. Deze aanpak is mogelijk niet mogelijk als de bijgewerkte toepassing gebruikmaakt van nieuwe modelfuncties waarvoor een wijziging in de gegevens is vereist.

Overwegingen voor architectuur

In basisarchitecturen, zoals de volgende architectuur, roept de client het model rechtstreeks aan met de juiste promptversie en configuratie. Als er wijzigingen in de prompt zijn, wordt er een nieuwe client geïmplementeerd met de nieuwe prompt en wordt het nieuwe model aanroepen. Het koppelen van de prompt-, configuratie- en modelversies is geen uitdaging.

Productiearchitecturen zijn niet eenvoudig. Over het algemeen implementeert u een orchestrator of agent waarvan de verantwoordelijkheid is om de stroom van de interacties tussen elke kennisdatabase en de modellen te beheren. Uw architectuur kan ook een of meer abstractielagen implementeren, zoals een router of een gateway:

• Router: Een router stuurt verkeer naar verschillende orchestrator-implementaties. Een router is handig in implementatiestrategieën zoals blauw-groene implementaties, waarbij u ervoor kunt kiezen om een specifiek percentage verkeer te routeren naar een nieuwe orchestratorversie als onderdeel van uw veilige implementatieprocedures. Dit onderdeel kan ook worden gebruikt voor A/B-tests of verkeersspiegeling om geteste, maar niet-gevalideerde wijzigingen met productieverkeer te evalueren.

• Gateway: Het is gebruikelijk om om verschillende redenen via een proxy toegang tot AI-modellen te krijgen. U kunt bijvoorbeeld taken verdelen of failover inschakelen tussen meerdere back-endinstanties, aangepaste verificatie en autorisatie implementeren of logboekregistratie en bewaking voor uw modellen implementeren.

Vanwege de betrokken lagen van indirectie moet uw architectuur zijn ontworpen ter ondersteuning van het verzenden van specifieke versies van prompts naar specifieke modellen of modelversies. U kunt bijvoorbeeld een prompt in productie hebben, zoals prompt1, die is ontworpen voor een model, zoals model1. Als u een upgrade uitvoert naar model1.1, moet u mogelijk prompt1 bijwerken naar prompt2. In dit voorbeeld moet uw architectuur altijd prompt1 gebruiken met model1 en prompt2 met model1.1.

Router

In het volgende diagram ziet u een architectuur die gebruikmaakt van een router om aanvragen naar meerdere implementaties te routeren. Een ander voorbeeld van deze architectuur is Foundry en maakt gebruik van een beheerd online-eindpunt als router. En de verschillende versies van de orchestrator worden geïmplementeerd voor beheerde berekeningen.

In de volgende stroom wordt beschreven hoe verschillende implementaties van een orchestrator het juiste model aanroepen. Elke implementatie heeft een eigen versie van de modelconfiguratie en een prompt:

1. Een gebruiker geeft een aanvraag van een intelligente toepassing uit en die aanvraag wordt verzonden naar een router.

2. De router routeert naar Deployment 1 of Deployment 2 van de orchestrator, afhankelijk van de logica.

3. Elke implementatie heeft een eigen versie van de prompt en configuratie.

4. De orchestrator is geconfigureerd met het specifieke model en de specifieke versie. Deze informatie wordt gebruikt om het juiste model en de juiste versie rechtstreeks aan te roepen.

5. Omdat de specifieke versie van de prompt wordt geïmplementeerd samen met de orchestrator die is geconfigureerd met het specifieke model en de specifieke versie, wordt de juiste prompt verzonden naar de juiste modelversie.

Toegangspoort

In het volgende diagram ziet u een architectuur die gebruikmaakt van een router om aanvragen naar meerdere implementaties te routeren. In deze architectuur worden echter alle modelaanvragen via een gateway gerouteerd. Het is gebruikelijk om proxytoegang tot AI-modellen te verschaffen om verschillende redenen, waaronder load balancing, het inschakelen van failover tussen meerdere back-endinstanties in één regio of meerdere regio's, en het implementeren van een geprovisioneerde doorvoereenheid met een pay-as-you-go overloopstrategie.

In de volgende stroom wordt beschreven hoe verschillende implementaties van een orchestrator het juiste model aanroepen via een gateway. Elke implementatie heeft een eigen versie van de modelconfiguratie en een prompt:

1. Een gebruiker geeft een aanvraag van een intelligente toepassing uit en die aanvraag wordt verzonden naar een router.

2. De router routeert naar Implementatie 1 of Implementatie 2, afhankelijk van de logica.

3. Elke implementatie heeft een eigen versie van de prompt.

4. De orchestrator is geconfigureerd met het specifieke model en de specifieke versie. Deze informatie wordt gebruikt om een HTTP-header in te stellen die het juiste model en de juiste versie aanroept.

5. De orchestrator roept de gateway aan. De aanvraag bevat de HTTP-header die de naam en versie van het model aangeeft die moet worden gebruikt.

6. De gateway gebruikt de HTTP-header om de aanvraag naar het juiste model en de juiste versie te routeren. Het kan ook een configuratie toepassen die is gedefinieerd op de gateway.

Configuratie extern maken

Het Externe Configuratiewinkel cloudontwerppatroon is een efficiënte manier om het opslaan van prompts en configuratie te beheren. Voor sommige aspecten van modelwijzigingen kunt u de modelimplementatie mogelijk coördineren met de systeemprompt en configuratiewijzigingen als deze worden opgeslagen op een aanpasbare locatie buiten de code van uw orchestrator of agent. Deze aanpak werkt niet als u orkestratielogica hebt om aan te passen, maar is handig bij veel kleinere updates van het model binnen een beperkte scope.

Keuze van rekenkracht

Voor MaaP-hosting zijn modellen vaak beperkt tot een subset van door de host geleverde rekenresources. Alle berekeningen zijn onderhevig aan quota, beschikbaarheidsbeperkingen en aankondigingen over het einde van de levensduur. Gebruik de routeringspatronen ter ondersteuning van de overgang naar nieuwe hardware wanneer uw huidige hardware niet meer wordt ondersteund of er beperkingen zijn die extra uitschalen voorkomen.

Een voorbeeld van een aankondiging van het einde van de levensduur is de NC A100 v4-serie rekenprocesaankondiging. Als u modellen op deze hardware host, moet u overstappen naar een andere ondersteunde SKU die niet eindigt en meer beschikbaarheid heeft. Deze overgang kan ook gelijktijdig een modelwijziging vereisen als de nieuwe SKU uw huidige model niet ondersteunt.

Aanbevelingen

• Voeg lagen van abstractie en indirectie toe om gecontroleerde wijzigingen in specifieke gebieden van uw workload mogelijk te maken. Deze gebieden omvatten de client, intelligente toepassings-API, indeling, modelhosting en grondkennis.

• Alle wijzigingen in modelversies, prompts, configuraties, indelingslogica en het ophalen van grondkennis moeten worden getest voordat ze in productie worden gebruikt. Zorg ervoor dat geteste combinaties in productie aan elkaar gekoppeld zijn, wat betekent dat ze nauw verbonden blijven wanneer ze worden geïmplementeerd. A/B-tests, taakverdeling en blauwgroene implementaties mogen geen onderdelen combineren om te voorkomen dat gebruikers niet worden blootgesteld aan niet-geteste combinaties.

• Nieuwe versies en nieuwe modellen testen en evalueren met behulp van geautomatiseerde pijplijnen. Vergelijk de resultaten met de resultaten van uw basislijn om ervoor te zorgen dat u de resultaten krijgt die u nodig hebt.

• Wees bewust van het bijwerken van modellen. Vermijd het gebruik van platformfuncties die automatisch productiemodellen upgraden naar nieuwe versies zonder de mogelijkheid om te testen. U moet weten hoe elke modelupdate van invloed is op uw workload. Als u de Foundry Models-API gebruikt, stelt u uw implementaties in met een specifieke versie en geeft u geen upgradebeleid op. Voor deze installatie is een handmatige upgrade vereist als er een nieuwe versie wordt uitgebracht. Voor Azure OpenAI stelt u implementaties in op Geen automatische upgrade om automatische upgrades uit te schakelen.

• Zorg ervoor dat uw waarneembaarheids- en logboekregistratieoplossing voldoende metagegevens verzamelt om waargenomen gedrag te correleren met de specifieke prompt, configuratie, model en betrokken oplossing voor het ophalen van gegevens. Met deze correlatie kunt u onverwachte regressies in systeemprestaties identificeren.

Samenvatting

Er zijn verschillende redenen om het fundamentele model bij te werken in uw generatieve workload. Deze redenen variëren van vereiste versie-upgrades wanneer modellen buiten gebruik worden gesteld van de beslissing om over te schakelen naar een ander model. Afhankelijk van het bereik van de modelupdate moet u mogelijk wijzigingen in het model implementeren en evalueren, waaronder wijzigingen in de prompt, modelconfiguratie, indelingslogica of gegevenspijplijn. Volg de richtlijnen voor MLOps, DataOps en GenAIOps om geautomatiseerde werkstromen te bouwen voor de verschillende aspecten van uw oplossing. Met geautomatiseerde werkstromen kunt u nieuwe versies testen, evalueren en implementeren. U moet er ook voor zorgen dat uw architectuur ondersteuning biedt voor het uitvoeren van meerdere versies van een orchestrator, waarbij elke versie zijn configuratie en promptversie koppelt aan een specifieke modelversie.

Uw architectuur moet updates voor nieuwe of verschillende modellen en eventuele noodzakelijke wijzigingen in de prompt- of modelconfiguratie ondersteunen, zonder dat er wijzigingen in de intelligente toepassing of de gebruikerservaring nodig zijn. Deze updates moeten worden ingekapseld binnen de juiste onderdelen en uw bewerkingen moeten het testen, evalueren en implementeren van deze wijzigingen automatiseren.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

• Ritesh Modi | Hoofdsoftware-ingenieur

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stap

• Afschaffingen en buitengebruikstelling van Azure OpenAI-modellen

Verwante middelen

• Basislijnreferentiearchitectuur voor Foundry-chat
• MLOps
• GenAIOps voor MLOps-beoefenaars