Dela via

GenAIOps för MLOps-utövare

  • Artikel

Den här artikeln ger vägledning till arbetsbelastningsteam som har befintliga investeringar i maskininlärningsåtgärder (MLOps) och vill utöka dessa investeringar till att omfatta generativ AI i arbetsbelastningen. För att operationalisera en generativ AI-arbetsbelastning måste du utöka dina MLOps-investeringar med Generative AI Ops (GenAIOps, som ibland kallas LLMOps). Den här artikeln beskriver tekniska mönster som är gemensamma för både traditionella maskininlärnings- och generativa AI-arbetsbelastningar och specifika mönster för generativ AI. Artikeln hjälper dig att förstå var du kan tillämpa befintliga investeringar i operationalisering och var du behöver utöka dessa investeringar.

Planering och implementering av en MLOps och GenAIOps är en del av ett kärndesignområde inom AI-arbetsbelastningar i Azure. Information om varför dessa arbetsbelastningar behöver särskilda åtgärder finns i MLOps och GenAIOps för AI-arbetsbelastningar i Azure i Azure Well-Architected Framework.

Generativa AI-tekniska mönster

Generativa AI-arbetsbelastningar skiljer sig från traditionella maskininlärningsarbetsbelastningar på några sätt:

  • Fokusera på generativa modeller. Traditionella maskininlärningsarbetsbelastningar fokuserar på att träna nya modeller som tränas för att utföra specifika uppgifter. Generativa AI-arbetsbelastningar använder generativa modeller som kan hantera en bredare mängd olika användningsfall och i vissa fall är multimodala.

  • Fokusera på att utöka modellerna. Den viktigaste tillgången i traditionell maskininlärning är den distribuerade modellen. Åtkomst till modellen ges till klientkoden i ett eller flera arbetsflöden, men arbetsflödet är inte en del av MLOps-processen. Med generativa AI-lösningar är en viktig aspekt av lösningen uppmaningen som tillhandahålls till den generativa modellen. Uppmaningen måste vara sammansatt och kan innehålla data från ett eller flera datalager. Systemet som samordnar logiken, anropar till de olika serverdelarna, genererar prompten och anrop till den generativa modellen är en del av det generativa AI-system som du måste styra med GenAIOps.

Även om vissa generativa AI-lösningar använder traditionella maskininlärningsmetoder som modellträning och finjustering, introducerar de alla nya mönster som du bör standardisera. Det här avsnittet innehåller en översikt över de tre breda kategorierna av tekniska mönster för generativa AI-lösningar:

  • Förträning och finjustering
  • Promptkonstruktion
  • Hämtningsförhöjd generation (RAG)

Språkmodeller för träning och finjustering

För närvarande använder många generativa AI-lösningar befintliga grundläggande språkmodeller som inte kräver finjustering före användning. Vissa användningsfall kan dock dra nytta av att finjustera en grundmodell eller träna en ny generativ AI-modell, till exempel en liten språkmodell (SLM).

Att träna en ny SLM och finjustera en generativ grundmodell är logiskt sett samma processer som att träna traditionella maskininlärningsmodeller. Dessa processer bör använda dina befintliga MLOps-investeringar.

Promptkonstruktion

Prompt engineering innehåller alla processer som ingår i genereringen av en fråga som skickas som indata till en generativ modell. Det finns vanligtvis en orkestrerare som styr ett arbetsflöde som genererar prompten. Orchestrator kan anropa valfritt antal datalager för att samla in information, till exempel jordningsdata, och tillämpa den logik som krävs för att generera den mest effektiva prompten. Orchestrator distribueras sedan som en API-slutpunkt som används av klientkoden i ett intelligent program.

Följande diagram visar en arkitektur för framställning av promptar.

diagram som visar en arkitektur för snabbteknik.

Den här kategorin av tekniska mönster kan hantera många användningsfall, inklusive:

  • Klassificering.
  • Översättning.
  • Sammanfattning.
  • Hämtningsförhöjd generation, som beskrivs i nästa avsnitt.

Hämtningsförhöjd generation

RAG (Retrieval Augmented Generation) är ett arkitekturmönster som använder prompt engineering för att införliva domänspecifika data som grunddata för en språkmodell. Språkmodellen tränas mot en specifik uppsättning data. Din arbetsbelastning kan kräva att du resonerar över data som är specifika för ditt företag, dina kunder eller din domän. I RAG-lösningar efterfrågas dina data och resultaten tillhandahålls till språkmodellen som en del av prompten, vanligtvis via ett orkestreringslager.

En vanlig RAG-implementering är att dela upp dina dokument i segment och lagra dem i ett vektorlager tillsammans med metadata. Med vektorlager, till exempel Azure AI Search, kan du utföra både text- och vektorlikhetssökningar för att returnera kontextuellt relevanta resultat. RAG-lösningar kan också använda andra datalager för att returnera grunddata.

Följande diagram illustrerar en RAG-arkitektur:

diagram som visar en RAG-arkitektur.

Utöka MLOps för generativa tekniska AI-mönster

Det här avsnittet beskriver följande viktiga aspekter av de inre och yttre loopfaserna för de generativa tekniska AI-mönstren och hjälper dig att förstå var du kan tillämpa dina befintliga MLOps-investeringar och var du behöver utöka dem:

DataOps

Både MLOps och GenAIOps tillämpar grunderna i DataOps för att skapa utökningsbara och reproducerbara arbetsflöden som säkerställer att data rensas, transformeras och formateras korrekt för experimentering och utvärdering. Arbetsflödesåtergivning och dataversionshantering är viktiga funktioner i DataOps för alla tekniska mönster. Datakällor, typer och avsikter är mönsterberoende.

Träning och finjustering

Det här tekniska mönstret bör fullt ut dra nytta av de befintliga DataOps-investeringar som du gjorde som en del av MLOps-implementeringen. Med reproducerbarhet och dataversionshantering kan du experimentera med olika funktionstekniker, jämföra de olika modellernas prestanda och återskapa resultat.

RAG och prompt engineering

Avsikten med data i RAG-lösningar är att tillhandahålla grunddata som presenteras för språkmodellen som en del av en prompt. RAG-lösningar kräver ofta bearbetning av stora dokument till en samling av högerstora, semantiskt relevanta segment och bevarar dessa segment i ett vektorlager. Mer information finns i Designa och utveckla en RAG-lösning . Med reproducerbarhet och dataversionshantering för RAG-lösningar kan du experimentera med olika segmenterings- och inbäddningsstrategier, jämföra prestanda och återställa till tidigare versioner.

Datapipelines för segmentering av dokument är inte en del av DataOps i traditionella MLOps, så du måste utöka din arkitektur och dina åtgärder. Datapipelines kan läsa data från olika källor som innehåller både strukturerade och ostrukturerade data. De kan också skriva transformerade data till olika mål. Du måste utöka arkitekturen så att den inkluderar de datalager som du använder för jordning av data. Vanliga datalager för dessa mönster är vektorlager som AI Search.

Precis som med träning och finjustering kan du använda Azure Machine Learning-pipelines eller andra verktyg för datapipelines för att orkestrera segmenteringsstegen. Du kan dra nytta av promptflöden i Azure Machine Learning-pipelines för att bearbeta och berika dina data på ett konsekvent och reproducerbart sätt. Du måste också utöka dina åtgärder för att upprätthålla färskheten och giltigheten för sökindexen i dina datalager.

Experimenterande

Experimentering, som är en del av den inre loopen, är den iterativa processen att skapa, utvärderaoch förfina din lösning. I följande avsnitt beskrivs experimentering för de vanliga generativa tekniska AI-mönstren.

Träning och finjustering

När du finjusterar en befintlig språkmodell eller tränar en liten språkmodell kan du dra nytta av dina aktuella MLOps-investeringar. Till exempel tillhandahåller Azure Machine Learning-pipelines en verktygslåda för att utföra experiment effektivt och effektivt. Med dessa pipelines kan du hantera hela finjusteringsprocessen, från förbearbetning av data till modellträning och utvärdering.

RAG och prompt engineering

Experimentering med snabbteknik och RAG-arbetsbelastningar kräver att du utökar dina MLOps-investeringar. För dessa tekniska mönster slutar arbetsbelastningen inte med modellen. Arbetsbelastningen kräver en orkestrerare, som är ett system som kan köra logik, anropa datalager för nödvändig information som jordningsdata, generera prompter, samtalsspråkmodeller med mera. Datalager och index i butikerna är också en del av arbetsbelastningen. Du måste utöka dina åtgärder för att styra de här aspekterna av arbetsbelastningen.

Du kan experimentera med flera dimensioner för att få fram tekniska lösningar, inklusive olika instruktioner, personas, exempel, begränsningar och avancerade tekniker som snabblänkning. När du experimenterar med RAG-lösningarkan du experimentera med ytterligare områden:

  • Segmenteringsstrategi
  • Vad och hur man berikar bitar
  • Din inbäddningsmodell
  • Konfiguration av ditt sökindex
  • Vilka sökningar som ska utföras (vektor, fulltext, hybrid och så vidare)

Som beskrivs i DataOpsär reproducerbarhet och dataversionshantering nyckeln till experimentering. Med ett bra experimenteringsramverk kan du lagra indata, till exempel ändringar i hyperparametrar eller uppmaningar, tillsammans med utdata som ska användas när du utvärdera experimentet.

Precis som i din befintliga MLOps-miljö kan du dra nytta av ramverk som Azure Machine Learning-pipelines. Azure Machine Learning-pipelines har funktioner som stöder indexering genom att integrera med vektorlager som AI Search. Din GenAIOps-miljö kan dra nytta av dessa pipelinefunktioner och kombinera dem med promptflödesfunktioner som hanterar snabbteknik och anpassad förbearbetningslogik.

Utvärdering och experimentering

Utvärdering är nyckeln i den iterativa experimenteringsprocessen för att skapa, utvärdera och förfina din lösning. Utvärderingen av dina ändringar ger den feedback som du behöver för att göra dina förbättringar eller verifiera att den aktuella iterationen uppfyller dina krav. I följande avsnitt beskrivs utvärdering i experimenteringsfasen för de vanliga generativa tekniska AI-mönstren.

Träning och finjustering

För utvärdering av finjusterade eller tränade generativa AI-modeller bör du dra nytta av dina befintliga MLOps-investeringar. Om du till exempel använder Azure Machine Learning-pipelines för att samordna din maskininlärningsmodellträning kan du använda samma utvärderingsfunktioner för att finjustera grundläggande språkmodeller eller träna nya små språkmodeller. Dessa funktioner omfattar komponenten Evaluate Model, som beräknar utvärderingsmått av branschstandard för specifika modelltyper och jämför resultat mellan modeller.

RAG och prompt engineering

Du måste utöka dina befintliga MLOps-investeringar för att utvärdera generativa AI-lösningar. Du kan använda verktyg som prompt flow, vilket tillhandahåller ett ramverk för utvärdering. Med promptflöde kan team definiera anpassad utvärderingslogik genom att ange kriterier och mått för att utvärdera prestanda för olika promptvarianter och stora språkmodeller (LLM). Med den här strukturerade metoden kan du jämföra olika konfigurationer sida vid sida, till exempel hyperparameter eller arkitekturvariationer, för att identifiera den optimala konfigurationen för specifika uppgifter.

Jobb i promptflödet samlar automatiskt in- och utdata under hela experimentprocessen för att skapa en omfattande försöksprotokoll. Du kan få insikter och identifiera lovande konfigurationer som kan ge information om framtida iterationer genom att analysera dessa data. Du kan påskynda utvecklingen av dina generativa AI-lösningar genom att använda snabbflöden för att utföra effektiva och systematiska experiment.

Experimenteringsprocessen är densamma oavsett användningsfall för din generativa AI-lösning. Dessa användningsfall omfattar klassificering, sammanfattning, översättning och till och med RAG. Den viktiga skillnaden är de mått som du använder för att utvärdera de olika användningsfallen. Följande är några mått, baserat på användningsfall, att överväga.

  • Översättning: BLEU
  • Sammanfattning: ROUGE. BLEU, BERTScore, METEOR
  • Klassificering: Precision, träffsäkerhet, noggrannhet, korsentropi
  • RAG: Groundedness, Relevancy

Kommentar

Mer information om hur du utvärderar språkmodeller och RAG-lösningar finns i LLM-utvärdering från slutpunkt till slutpunkt-.

I allmänhet utökar generativa AI-lösningar ansvaret för maskininlärningsteamet från träningsmodeller till att uppmana till teknik och hantering av grunddata. Eftersom snabbteknik och RAG-experimentering och utvärdering inte nödvändigtvis kräver dataforskare kan du frestas att använda andra roller, till exempel programvarutekniker och datatekniker, för att utföra dessa funktioner. Du kommer att uppleva utmaningar om du utelämnar dataforskare från experimentprocessen med snabb teknik och RAG-lösningar. Andra roller tränas inte ofta på att vetenskapligt utvärdera resultaten, som många dataforskare är. Läs den sjudelade artikelserien Designa och utveckla en RAG-lösning för att få en förståelse för komplexiteten i att utforma generativa AI-lösningar.

Genom att investera i generativa AI-lösningar kan du minska trycket från dina datavetenskapsresurser. Programvaruingenjörernas roll utökas i dessa lösningar. Programvarutekniker är till exempel bra resurser för att hantera orkestreringsansvaret i generativa AI-lösningar, och de är skickliga på att konfigurera utvärderingsmåtten i verktyg som promptflöde. Det är viktigt att dataexperter granskar det här arbetet. De har utbildning och erfarenhet för att förstå hur experimenten utvärderas korrekt.

Distribution

Vissa generativa AI-lösningar omfattar distribution av anpassade tränade modeller eller finjustering av befintliga modeller, men andra inte. För generativa AI-lösningar måste du inkludera ytterligare uppgifter för att distribuera orkestreringsverktyg och eventuella datalager. I följande avsnitt beskrivs distribution för vanliga generativa tekniska AI-mönster.

Träning och finjustering

Du bör använda dina befintliga MLOps-investeringar, med några möjliga justeringar, för att distribuera generativa AI-modeller och finjustera grundmodeller. Om du till exempel vill finjustera en stor språkmodell i Azure OpenAI måste du se till att dina tränings- och valideringsdatauppsättningar är i JSONL-format och att du måste ladda upp data via ett REST-API. Du måste också skapa ett finjusteringsjobb. Om du vill distribuera en tränad liten språkmodell kan du dra nytta av dina befintliga MLOps-investeringar.

RAG och prompt engineering

För RAG och prompt engineering finns det ytterligare problem, inklusive orkestreringslogik, ändringar i datalager som index och scheman samt ändringar i datapipelinelogik. Orkestreringslogik kapslas vanligtvis in i ramverk som promptflöde, semantisk kernel eller LangChain. Du kan distribuera orkestratorn till olika beräkningsresurser, inklusive resurser som du för närvarande kan distribuera anpassade modeller till. Se Azure OpenAI slut-till-slut-chattarkitektur för exempel på hur du distribuerar promptflöde till antingen onlineslutpunkter som hanteras av Azure Machine Learning eller till Azure App Service. För att distribuera till App Service paketar Azure OpenAI-chattarkitekturen flödet och dess beroenden som en container, en metod som ökar portabiliteten och konsekvensen i olika miljöer.

Distributioner av ändringar av databasresurser, till exempel ändringar i datamodeller eller index, är nya uppgifter som måste hanteras i GenAIOps. En vanlig praxis när du arbetar med stora språkmodeller är att använda en gateway framför LLM.

Många generativa AI-arkitekturer som använder plattformsbaserade språkmodeller, som de som hanteras från Azure OpenAI, innehåller en gateway som Azure API Management. Gatewayanvändningsfallen omfattar belastningsutjämning, autentisering och övervakning. Gatewayen kan spela en roll i distributionen av nyligen tränade eller finjusterade modeller, så att du kan distribuera nya modeller progressivt. Med hjälp av en gateway, tillsammans med modellversionshantering, kan du minimera risken när du distribuerar ändringar och återställa till tidigare versioner när problem uppstår.

Distributioner av element som är specifika för generativ AI, till exempel orkestreraren, bör följa lämpliga operativa procedurer, till exempel:

  • Rigorös testning, inklusive enhetstester.
  • Integreringstester.
  • A/B-tester
  • Helhetstester.
  • Distributionsstrategier, till exempel kanariebaserade eller blå/gröna distributioner.

Eftersom distributionsansvaret för generativa AI-program sträcker sig bortom modelldistributionen kan du behöva ytterligare jobbroller för att hantera distribution och övervakning av saker som användargränssnittet, orkestratorn och datalager. De här rollerna är ofta anpassade till DevOps-teknikers kompetensuppsättningar.

Slutsatsdragning och övervakning

Slutsatsdragning är processen att skicka indata till en tränad och distribuerad modell, vilket sedan genererar ett svar. Du bör övervaka både traditionella maskininlärnings- och generativa AI-lösningar ur tre perspektiv: driftövervakning, inlärning från produktion och resurshantering.

Driftövervakning

Driftövervakning är processen för att observera systemets pågående åtgärder, inklusive dataåtgärder (DataOps) och modellträning. Den här typen av övervakning söker efter avvikelser, inklusive fel, ändringar i felfrekvenser och ändringar i bearbetningstiderna.

För modellträning och finjustering observerar du vanligtvis dataåtgärderna för bearbetning av funktionsdata, modellträning och finjustering. Övervakningen av dessa inre loopprocesser bör dra nytta av dina befintliga MLOps- och DataOps-investeringar.

För snabb teknik i generativa AI-lösningar har du ytterligare övervakningsproblem. Du måste övervaka de datapipelines som bearbetar grunddata eller andra data som används för att generera uppmaningar. Den här bearbetningen kan omfatta datalageråtgärder som att skapa eller återskapa index.

Att lära sig från produktion

En kritisk aspekt att övervaka under inferensstadiet är lärande från produktion. Övervakning för traditionella maskininlärningsmodeller spårar mått som noggrannhet, precision och återkallande. Ett viktigt mål är att undvika förutsägelseavvikelser. Lösningar som använder generativa modeller för att göra förutsägelser, till exempel med hjälp av en GPT-modell för klassificering, bör dra nytta av dina befintliga MLOps-övervakningsinvesteringar.

Lösningar som använder generativa modeller för att resonera över grunddata använder mått som grundning, fullständighet, användning och relevans. Målet är att säkerställa att modellen helt svarar på frågan och baserar svaret på dess kontext. Här måste du försöka förhindra problem som dataavvikelse. Du vill se till att grunddata och uppmaningen som du anger för modellen är maximalt relevanta för användarfrågan.

Lösningar som använder generativa modeller för icke-förebyggande uppgifter, till exempel RAG-lösningar, drar ofta nytta av mänsklig feedback från slutanvändare för att utvärdera användbarhetssentiment. Användargränssnitt kan samla in feedback som tummen upp eller ner, och du kan använda dessa data för att regelbundet utvärdera svaren.

Ett vanligt mönster för generativa AI-lösningar är att distribuera en gateway framför de generativa modellerna. Ett av de användningsfallen för gateway är att övervaka grundmodellerna. Du kan använda gatewayen för att logga indataprompter och utdata.

Ett annat viktigt område att övervaka för generativa lösningar är innehållssäkerhet. Målet är att moderera svar och identifiera skadligt eller oönskat innehåll. Azure AI Content Safety Studio är ett exempel på ett verktyg som du kan använda för att moderera innehåll.

Resurshantering

Generativa lösningar som använder modeller som exponeras som en tjänst, till exempel Azure OpenAI, har andra problem med resurshantering än modeller som du distribuerar själv. För modeller som exponeras som en tjänst bryr du dig inte om infrastrukturen. I stället bryr du dig om tjänstens dataflöde, kvot och begränsning. Azure OpenAI använder token för fakturering, begränsning och kvoter. Du bör övervaka kvotanvändningen för kostnadshantering och prestandaeffektivitet. Med Azure OpenAI kan du logga tokenanvändning.

Verktyg

Många MLOps-utövare har standardiserat en verktygslåda för att organisera olika aktiviteter för automatisering, spårning, distribution, experimentering och så vidare för att sammanfatta de vanliga problemen och implementeringsinformationen för dessa processer. En gemensam enhetlig plattform är MLflow. Innan du letar efter nya verktyg som stöder GenAIOps-mönster bör du granska dina befintliga MLOps-verktyg för att utvärdera dess stöd för generativ AI. MLflow stöder till exempel en mängd olika funktioner för språkmodeller.

MLOps- och GenAIOps-mognadsmodeller

Du kan ha använt MLOps-mognadsmodellen för att utvärdera mognaden för din aktuella maskininlärningsdrift och miljö. När du utökar dina MLOps-investeringar för generativa AI-arbetsbelastningar bör du använda Mognadsmodellen GenAIOps för att utvärdera dessa åtgärder. Du kan vara frestad att kombinera de två mognadsmodellerna, men vi rekommenderar att du mäter var och en separat. MLOps och GenAIOps utvecklas oberoende av varandra. Du kan till exempel vara på nivå fyra i MLOps-mognadsmodellen men på nivå ett för generativ AI.

Sammanfattning

När du börjar utöka dina MLOps-investeringar till att omfatta generativ AI är det viktigt att förstå att du inte behöver börja om. Du kan använda dina befintliga MLOps-investeringar för några av de generativa tekniska AI-mönstren. Finjustering av generativa modeller är ett bra exempel. Det finns områden med generativa AI-lösningar, till exempel snabbteknik och RAG, som är nya processer, så du måste utöka dina befintliga driftinvesteringar och få nya kunskaper.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg