maskinintelligens.se

Verktygslåda / MLflow

MLflow

MLflow loggar körningar, parametrar och mått, och håller ett register över vilken modellversion som är i drift. Det gör det möjligt att i efterhand svara på vad modellen gjorde vid en viss tidpunkt. Det blir ett krav i allt fler sammanhang.

Python, med gränssnitt för fler språk

Frågan kommer alltid till slut. Vilken modell körde i mars, vad tränades den på, och varför gav den det där utfallet?

Utan spårbarhet är svaret en gissning byggd på någons minne och en mapp med filnamn som slutar på _final_v2_ny.

Vad som är värt att använda

Experimentloggning. Varje träningskörning sparar parametrar, mått och artefakter. Det gör att man kan gå tillbaka och se vad som faktiskt prövades, i stället för att lita på anteckningar.

Modellregister. Versioner med stadier: under utveckling, i drift, avvecklad. Det är den del som betyder mest i praktiken, eftersom den ger ett entydigt svar på vilken version som är den skarpa.

Modellpaketering. En modell sparas med sina beroenden och kan laddas likadant oavsett var den körs. Det tar bort en av de vanligaste orsakerna till att något fungerar lokalt och inte i drift.

Vad man inte behöver

Hela MLflow-plattformen med server och databas är överdrivet för de flesta uppdrag. Loggning till en lokal katalog eller en enkel delad lagringsplats räcker långt och kan sättas upp på en förmiddag.

Rekommendationen är att börja där. Behovet av en central server uppstår när flera team ska dela register, inte innan.

Varför det hör ihop med granskning

När jag gör en modellgranskning är den första frågan alltid om det går att reproducera den utvärdering som redovisats.

Finns MLflow-loggar tar det en timme. Saknas de blir granskningen till stor del en rekonstruktion, och en betydande del av fynden handlar då om att ingen längre vet vad som gjordes. Det är ett resultat i sig, men ett dyrare sätt att nå det.

Det knyter också an till AI-förordningens dokumentationskrav, där spårbarhet över tid är just det som ska kunna visas.