ML-livscykelhantering med MLflow

Den här artikeln beskriver hur MLflow används i Databricks för livscykelhantering för maskininlärning. Den innehåller också exempel som introducerar varje MLflow-komponent och länkar till innehåll som beskriver hur dessa komponenter hanteras i Azure Databricks.

ML-livscykelhantering i Databricks tillhandahålls av hanterad MLflow. Azure Databricks tillhandahåller en fullständigt hanterad och värdbaserad version av MLflow som är integrerad med företagssäkerhetsfunktioner, hög tillgänglighet och andra Azure Databricks-arbetsytefunktioner som hantering av experiment och körningar samt registrering av ändringar i notebook-filer.

Förstagångsanvändare bör börja med Komma igång med MLflow-experiment, som visar de grundläggande API:erna för MLflow-spårning.

Vad är MLflow?

MLflow är en plattform med öppen källkod för hantering av maskininlärningslivscykeln från början till slut. Den har följande primära komponenter:

• Spårning: Gör att du kan spåra experiment för att registrera och jämföra parametrar och resultat.
• Modeller: Gör att du kan hantera och distribuera modeller från en mängd olika ML-bibliotek till en mängd olika modellhanterings- och slutsatsdragningsplattformar.
• Projekt: Gör att du kan paketera ML-kod i ett återanvändbart, reproducerbart formulär för att dela med andra dataforskare eller överföra till produktion.
• Modellregister: Gör att du kan centralisera ett modellarkiv för att hantera modellers fullständiga livscykelstegsövergångar: från mellanlagring till produktion, med funktioner för versionshantering och anteckningar. Databricks tillhandahåller en hanterad version av modellregistret i Unity Catalog.
• Modellservering: Gör att du kan vara värd för MLflow-modeller som REST-slutpunkter. Databricks tillhandahåller ett enhetligt gränssnitt för att distribuera, styra och köra frågor mot dina hanterade AI-modeller.

MLflow kan användas med Java, Python, R och REST-API:er.

MLflow-data krypteras av Azure Databricks med hjälp av en plattformshanterad nyckel. Kryptering med kundhanterade nycklar för hanterade tjänster stöds inte.

MLflow-spårning

MLflow på Azure Databricks erbjuder en integrerad upplevelse för att spåra och skydda träningskörningar för maskininlärning och djupinlärningsmodeller.

• Spåra modellutveckling med MLflow
• Automatisk loggning av Databricks

Modelllivscykelhantering

MLflow Model Registry är en centraliserad modelllagringsplats och ett användargränssnitt och en uppsättning API:er som gör att du kan hantera hela livscykeln för MLflow-modeller. Databricks tillhandahåller en värdbaserad version av MLflow Model Registry i Unity Catalog. Unity Catalog tillhandahåller centraliserad modellstyrning, åtkomst mellan arbetsytor, ursprung och distribution. Mer information om hur du hanterar modelllivscykeln i Unity Catalog finns i Hantera modelllivscykel i Unity Catalog.

Om arbetsytan inte är aktiverad för Unity Catalog kan du använda arbetsytans modellregister.

Modellregisterbegrepp

• Modell: En MLflow-modell som loggats från ett experiment eller en körning som loggas med någon av modellsmakens mlflow.<model-flavor>.log_model metoder. När en modell har loggats kan du registrera den med modellregistret.
• Registrerad modell: En MLflow-modell som har registrerats med modellregistret. Den registrerade modellen har ett unikt namn, versioner, modell härkomst och andra metadata.
• Modellversion: En version av en registrerad modell. När en ny modell läggs till i modellregistret läggs den till som version 1. Varje modell som är registrerad på samma modellnamn ökar versionsnumret.
• Modellalias: Ett alias är en föränderlig, namngiven referens till en viss version av en registrerad modell. Vanliga användningar av alias är att ange vilka modellversioner som distribueras i en viss miljö i dina modellträningsarbetsflöden eller för att skriva slutsatsdragningsarbetsbelastningar som riktar sig mot ett visst alias. Du kan till exempel tilldela "Champion"-aliaset för din registrerade modell "Bedrägeriidentifiering" till den modellversion som ska hantera merparten av produktionstrafiken och sedan skriva slutsatsdragningsarbetsbelastningar som riktar sig mot det aliaset (det vill säga göra förutsägelser med hjälp av "Champion"-versionen).
• Modellsteg (endast arbetsytemodellregister): En modellversion kan tilldelas en eller flera steg. MLflow tillhandahåller fördefinierade steg för vanliga användningsfall: None, Staging, Production och Archived. Med rätt behörighet kan du överföra en modellversion mellan faser eller begära en modellfasövergång. Modellversionssteg används inte i Unity Catalog.
• Beskrivning: Du kan kommentera en modells avsikt, inklusive en beskrivning och all relevant information som är användbar för teamet, till exempel algoritmbeskrivning, använd datauppsättning eller metodik.

Exempelnotebook-filer

Ett exempel som illustrerar hur du använder modellregistret för att skapa ett maskininlärningsprogram som förutspår den dagliga utdatan för en vindkraftspark finns i följande:

• Exempel på modeller i Unity Catalog
• Exempel på arbetsytemodellregister

Modelldistribution

Databricks Model Serving tillhandahåller ett enhetligt gränssnitt för att distribuera, styra och fråga AI-modeller. Varje modell som du hanterar är tillgänglig som ett REST-API som du kan integrera i ditt webb- eller klientprogram.

Modellservering stöder servering:

• Anpassade modeller. Det här är Python-modeller som paketeras i MLflow-format. De kan registreras antingen i Unity Catalog eller i arbetsytans modellregister. Exempel är scikit-learn, XGBoost, PyTorch och Hugging Ansiktstransformatormodeller.
• Toppmoderna öppna modeller som görs tillgängliga av Foundation Model-API:er. Dessa modeller är utvalda grundmodellarkitekturer som stöder optimerad slutsatsdragning. Basmodeller som Llama-2-70B-chat, BGE-Large och Mistral-7B är tillgängliga för omedelbar användning med prissättning för betala per token och arbetsbelastningar som kräver prestandagarantier och finjusterade modellvarianter kan distribueras med etablerat dataflöde.
• Externa modeller. Det här är modeller som finns utanför Databricks. Exempel är grundmodeller som OpenAI:s GPT-4, Anthropics Claude och andra. Slutpunkter som hanterar externa modeller kan styras centralt och kunderna kan upprätta hastighetsbegränsningar och åtkomstkontroller för dem.

Du kan också distribuera MLflow-modeller för offline-slutsatsdragning, se Distribuera modeller för batchinferens.