Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln kompletterar MLOps-arbetsflöden på Databricks genom att lägga till information som är specifik för LLMOps-arbetsflöden. Mer information finns i The Big Book of MLOps.
Hur ändras MLOps-arbetsflödet för LLM:er?
LLM-modeller är en klass av NLP-modeller (natural language processing) som avsevärt har överträffat sina föregångare både i storlek och prestanda i en mängd olika uppgifter, till exempel besvarandet av öppna frågor, sammanfattning och utförande av instruktioner.
Utveckling och utvärdering av LLM skiljer sig på några viktiga sätt från traditionella ML-modeller. Det här avsnittet sammanfattar kort några av de viktigaste egenskaperna för LLM:er och konsekvenserna för MLOps.
| Viktiga egenskaper för LLM:er | Implikationer för MLOps |
|---|---|
LLM:er är tillgängliga i många former.
|
Utvecklingsprocess: Projekt utvecklas ofta stegvis, från befintliga modeller från tredje part eller öppen källkod och slutar med anpassade finjusterade modeller. |
| Många LLM:er tar allmänna frågor och instruktioner för naturligt språk som indata. Dessa frågor kan innehålla noggrant utformade uppmaningar för att få fram önskade svar. |
Utvecklingsprocess: Att utforma textmallar för frågor mot LLM är ofta en viktig del i utvecklingen av nya LLM-pipelines. Paketering av ML-artefakter: Många LLM-pipelines använder befintliga LLM- eller LLM-serverslutpunkter. ML-logiken som utvecklats för dessa pipelines kan fokusera på promptmallar, agenter eller kedjor i stället för själva modellen. ML-artefakterna som paketeras och befordras till produktion kan vara dessa pipelines i stället för modeller. |
| Många LLM:er kan få frågor med exempel, kontext eller annan information som hjälper dig att besvara frågan. | Betjänande infrastruktur: När du utökar LLM-frågor med kontext kan du använda ytterligare verktyg, till exempel vektorindex, för att söka efter relevant kontext. |
| API:er från tredje part tillhandahåller proprietära modeller med öppen källkod. | API-styrning: Med centraliserad API-styrning kan du enkelt växla mellan API-leverantörer. |
| LLM:er är mycket stora djupinlärningsmodeller, som ofta sträcker sig från gigabyte till hundratals gigabyte. |
Infrastruktur för servering: LLM:er kan kräva GPU:er för realtidsmodellservering och snabb lagring för modeller som behöver läsas in dynamiskt. Kostnads-/prestandaavvägningar: Eftersom större modeller kräver mer beräkning och är dyrare att hantera kan det krävas tekniker för att minska modellstorleken och beräkningen. |
| LLM:er är svåra att utvärdera med hjälp av traditionella ML-mått eftersom det ofta inte finns något enda "rätt" svar. | Mänsklig feedback: Mänsklig feedback är avgörande för utvärdering och testning av LLM:er. Du bör införliva användarfeedback direkt i MLOps-processen, inklusive för testning, övervakning och framtida finjustering. |
Likheter mellan MLOps och LLMOps
Många aspekter av MLOps-processer ändras inte för LLM:er. Följande riktlinjer gäller till exempel även för LLM:er:
- Använd separata miljöer för utveckling, mellanlagring och produktion.
- Använd Git för versionskontroll.
- Hantera modellutveckling med MLflow och använd modeller i Unity Catalog för att hantera modelllivscykeln.
- Lagra data i en lakehouse-arkitektur med hjälp av Delta-tabeller.
- Din befintliga CI/CD-infrastruktur bör inte kräva några ändringar.
- MlOps modulära struktur förblir densamma, med pipelines för funktionalisering, modellträning, modellinferens och så vidare.
Referensarkitekturdiagram
I det här avsnittet används två LLM-baserade program för att illustrera några av justeringarna i referensarkitekturen för traditionella MLOps. Diagrammen visar produktionsarkitekturen för 1) ett RAG-program (retrieval augmented generation) med hjälp av ett API från tredje part och 2) ett RAG-program med hjälp av en finjusterad modell med egen värd. Båda diagrammen visar en valfri vektordatabas – det här objektet kan ersättas genom att fråga LLM direkt via slutpunkten Modellserver.
RAG med ett LLM-API från tredje part
Diagrammet visar en produktionsarkitektur för ett RAG-program som ansluter till ett LLM-API från tredje part med databricks externa modeller.
RAG med en finjusterad öppen källkod modell
Diagrammet visar en produktionsarkitektur för ett RAG-program som finjusterar en öppen källkod modell.
LLMOps-ändringar i MLOps-produktionsarkitektur
I det här avsnittet beskrivs de viktigaste ändringarna i MLOps-referensarkitekturen för LLMOps-program.
Modellhubben
LLM-applikationer använder ofta befintliga, förtränade modeller som valts från ett internt eller externt modellbibliotek. Modellen kan användas som den är eller finjusteras.
Databricks innehåller ett urval av högkvalitativa, förutbildade grundmodeller i Unity Catalog och i Databricks Marketplace. Du kan använda dessa förtränade modeller för att få åtkomst till toppmoderna AI-funktioner, vilket sparar tid och kostnader för att skapa egna anpassade modeller. Mer information finns i Hämta generativa AI- och LLM-modeller från Unity Catalog och Marketplace.
Vektorindex
Vissa LLM-program använder vektorindex för snabba likhetssökningar, till exempel för att tillhandahålla kontext- eller domänkunskaper i LLM-frågor. Databricks tillhandahåller en integrerad vektorsökningsfunktion som gör att du kan använda alla Delta-tabeller i Unity Catalog som ett vektorindex. Vektorsökningsindexet synkroniseras automatiskt med Delta-tabellen. Mer information finns i Vektorsökning.
Du kan skapa en modellartefakt som kapslar in logiken för att hämta information från ett vektorindex och tillhandahåller returnerade data som kontext till LLM. Du kan sedan logga modellen med modellsmaken MLflow LangChain eller PyFunc.
Finjustera LLM
Eftersom LLM-modeller är dyra och tidskrävande att skapa från grunden finjusterar LLM-program ofta en befintlig modell för att förbättra dess prestanda i ett visst scenario. I referensarkitekturen representeras finjustering och modelldistribution som distinkta Lakeflow-jobb. Att verifiera en finjusterad modell innan du distribuerar är ofta en manuell process.
Databricks tillhandahåller grundläggande modell finjustering, vilket gör att du kan använda dina egna data för att anpassa en befintlig LLM för att optimera dess prestanda för ditt specifika program. Mer information finns i Finjustering av grundmodell.
Modellbetjäning
I RAG med hjälp av ett API-scenario från tredje part är en viktig arkitekturändring att LLM-pipelinen gör externa API-anrop, från modellserveringsslutpunkten till interna eller externa LLM-API:er. Detta lägger till komplexitet, potentiell svarstid och ytterligare hantering av autentiseringsuppgifter.
Databricks tillhandahåller Mosaic AI Model Serving, som tillhandahåller ett enhetligt gränssnitt för att distribuera, styra och fråga AI-modeller. Mer information finns i Mosaik AI-modellservering.
Mänsklig feedback vid övervakning och utvärdering
Mänskliga feedbackslingor är viktiga i de flesta LLM-program. Mänsklig feedback bör hanteras som andra data, helst införlivade i övervakning baserat på direktuppspelning i nära realtid.
Granskningsappen Mosaic AI Agent Framework hjälper dig att samla in feedback från mänskliga granskare. För mer information, se använd granskningsappen för mänskliga granskningar av en gen AI-app (MLflow 2).