Model registry: proč firmy potřebují systém řízení AI modelů

Při vývoji strojového učení obvykle vznikají desítky nebo stovky variant modelu. Liší se trénovacími daty, algoritmem, parametry, zdrojovým kódem, rychlostí, náklady i kvalitou výsledků.

Dokud jde pouze o experiment, lze část tohoto kontextu udržovat v notebooku, repozitáři nebo v hlavě vývojáře.

V okamžiku, kdy model začne ovlivňovat skutečný firemní proces, však musí organizace odpovědět na konkrétní otázky:

• Která verze modelu právě běží?
• Z jakých dat vznikla?
• Jak byla otestována?
• Kdo ji schválil?
• Ve kterých aplikacích se používá?
• Jaká má známá omezení?
• Co se změnilo oproti předchozí verzi?
• Lze vadnou verzi rychle stáhnout a nahradit?
• Kdo odpovídá za její další provoz?

Právě tuto provozní mezeru řeší model registry.

Co je model registry

Model registry je centrální systém pro evidenci a správu modelů v průběhu jejich životního cyklu.

Jejím úkolem není pouze uchovávat soubor obsahující natrénovaný model. Propojuje konkrétní modelový artefakt s informacemi potřebnými pro jeho pochopení, validaci, schválení, nasazení, monitoring a případné vyřazení.

Typická model registry eviduje:

• název a účel modelu,
• jednotlivé verze,
• modelové artefakty,
• původ modelu,
• použité datasety a trénovací běhy,
• výsledky evaluací,
• metadata a dokumentaci,
• schvalovací stav,
• vlastníka,
• produkční nasazení,
• historii změn.

MLflow ji popisuje jako centralizované úložiště, API a uživatelské rozhraní pro správu životního cyklu modelů. Podporuje verzování, lineage, aliasy, metadata a návaznost na experiment, ze kterého model vznikl.[1]

Podobné komponenty nabízejí také AWS SageMaker, Microsoft Azure Machine Learning a Google Vertex AI.[2][3][4]

To ukazuje důležitou skutečnost:

Proč nestačí model uložit jako soubor

Představme si soubor nazvaný fraud_detection_model_v12.pkl.

Z názvu lze odhadnout, že jde o dvanáctou variantu modelu pro detekci podvodů. Samotný soubor ale neříká:

• zda jde o dvanáctý experiment, nebo dvanáctou produkční verzi;
• z jaké verze dat model vznikl;
• který commit zdrojového kódu byl použit;
• jaké proměnné model očekává;
• jakých výsledků dosáhl;
• zda prošel nezávislou validací;
• kdo povolil jeho nasazení;
• zda se stále někde nepoužívá starší verze.

Název souboru není systém řízení.

Model registry zajišťuje, aby model nebyl pouze technickým artefaktem, ale identifikovatelným, dohledatelným a spravovaným produkčním aktivem.

Dva významy, které je nutné rozlišovat

Pojem model registry se dnes nachází na průsečíku dvou souvisejících disciplín.

1. Technická model registry

V MLOps jde především o správu modelových artefaktů a jejich verzí.

Odpovídá například na otázky:

• Jaká verze modelu je produkční?
• Který experiment ji vytvořil?
• Kde se nachází její artefakt?
• Jaké má technické parametry?
• Kterou verzi má aplikace načíst?
• Jak lze provést rollback?

Tuto podobu používají MLflow a hlavní cloudové ML platformy.

2. Enterprise model inventory

V model risk managementu a AI governance je záběr širší.

Evidence se nesoustředí pouze na soubor modelu, ale také na:

• obchodní účel,
• vlastníka,
• kritičnost modelu,
• povolené a zakázané použití,
• použité datové zdroje,
• validační stav,
• známá omezení,
• závislost na dodavateli,
• historii incidentů,
• datum příští kontroly,
• plán vyřazení.

Americké regulatorní pokyny pro model risk management používají pojem model inventory jako soubor informací potřebných k pochopení rizik jednotlivých modelů i celého modelového portfolia.[5]

Technická registry a enterprise inventory nemusí být vždy jeden systém.

Technická registry může být napojena na vývojové a deployment pipeline. Enterprise inventory může být součástí governance platformy, risk systému nebo interního registru.

Ve vyspělé organizaci by však měly tvořit propojený celek.

Co má model registry evidovat

Základní záznam lze rozdělit do šesti vrstev:

Identita

Model potřebuje stabilní název a jasně vymezený účel. Například:

Obecné označení typu „AI pro obchod“ nestačí. Bez konkrétního účelu nelze určit vhodné metriky, přijatelné riziko ani hranice použití.

Původ

Model lineage popisuje řetězec, ze kterého model vznikl:

• trénovací běh,
• verzi datasetu,
• použitý kód,
• parametry,
• knihovny,
• výpočetní prostředí,
• autora,
• datum vytvoření.

Bez lineage lze model možná znovu načíst, ale nelze jej spolehlivě reprodukovat ani vysvětlit jeho původ.

Evaluace

Nestačí uvést jednu hodnotu přesnosti. Podle účelu mohou být důležité například:

• přesnost,
• precision a recall,
• míra falešně pozitivních výsledků,
• stabilita mezi skupinami dat,
• robustnost,
• latence,
• provozní náklady,
• vysvětlitelnost,
• bezpečnostní testy.

Registry má zachytit nejen to, který model byl vybrán, ale také podle jakých podmínek byl přijat.

Schválení

Verze modelu může být například:

• experimentální,
• kandidátní,
• čekající na validaci,
• schválená,
• produkční,
• nahrazovaná,
• archivovaná,
• zakázaná.

Záznam má zároveň uvádět, kdo provedl technickou kontrolu, kdo schválil obchodní použití a kdo za model odpovídá.

Nasazení

Registry musí ukazovat, kde se daná verze používá. Může jít například o:

• online API,
• dávkové zpracování,
• mobilní aplikaci,
• interní rozhodovací systém,
• zařízení na hraně sítě,
• několik regionů nebo prostředí.

Pokud se objeví kritická chyba, firma musí rychle určit všechny procesy a aplikace, kterých se problém týká.

Provoz

Registrace nekončí nasazením. Záznam by měl být propojen s informacemi o:

• výkonu v produkci,
• změnách vstupních dat,
• poklesu kvality,
• incidentech,
• výjimkách,
• omezeních,
• rekalibracích,
• nahrazení nebo vyřazení modelu.

Model, který byl vhodný při nasazení, nemusí být vhodný navždy.

Jak vypadá životní cyklus modelu

Typický proces má několik kroků:

1. Experimentování: tým zkouší různé datasety, algoritmy a konfigurace.
2. Výběr kandidáta: jedna nebo více variant splní základní kritéria.
3. Registrace: kandidát je zapsán jako nová verze v model registry.
4. Evaluace a validace: model je porovnán s požadavky a současnou produkční verzí.
5. Schválení: oprávněná osoba nebo pipeline povolí jeho použití.
6. Nasazení: schválená verze je uvolněna do testovacího nebo produkčního prostředí.
7. Monitoring: sleduje se výkon, kvalita dat, náklady a odchylky.
8. Nahrazení nebo rollback: nová verze převezme provoz, případně se systém vrátí ke starší.
9. Vyřazení: nepoužívaná verze je archivována, ale její historie zůstává dohledatelná.

Model registry tedy není pasivní archiv.

Je to kontrolní bod mezi experimentem a produkčním provozem.

Co model registry není

Model registry je součást širšího prostředí. Nenahrazuje několik dalších systémů.

Experiment tracking

Eviduje všechny vývojové pokusy, jejich parametry a výsledky.

Model registry

Spravuje vybrané modely a verze, které mají provozní význam.

Model monitoring

Sleduje chování modelu po nasazení.

Model hub nebo katalog

Pomáhá objevovat modely, které jsou dostupné k použití.

AI system inventory

Eviduje celé AI systémy, jejich použití, vlastníky, data, dodavatele a rizika.

Tyto vrstvy se mohou nacházet v jedné platformě, ale řeší odlišné otázky.

Co mění generativní AI

Tradiční model registry vznikaly především pro modely, které firma sama trénovala.

U generativní AI často firma nevlastní modelové váhy ani neřídí trénování. Používá externí foundation model přes API a nad ním staví vlastní aplikaci.

Chování takové aplikace neurčuje pouze model. Výsledek ovlivňuje také:

• systémový prompt,
• parametry modelu,
• znalostní báze,
• embedding model,
• retrieval logika,
• dostupné nástroje,
• oprávnění agenta,
• guardrails,
• následné zpracování výstupu.

U RAG systému může změna dokumentů nebo retrieval pipeline ovlivnit chování stejně zásadně jako výměna jazykového modelu.

Řízenou jednotkou proto už není pouze verze modelu, ale spíše:

Moderní model registry se tím rozšiřuje směrem k evidenci AI komponent, agentů a celých systémových konfigurací.

Externí model neodstraňuje odpovědnost

Při použití externího modelu má firma méně informací a menší technickou kontrolu. Poskytovatel může změnit:

• model nebo jeho chování,
• dostupné verze,
• cenu,
• limity,
• bezpečnostní filtry,
• podmínky zpracování dat.

Záznam externího modelu by proto měl obsahovat alespoň:

• poskytovatele,
• označení modelu,
• způsob přístupu,
• používanou verzi nebo endpoint,
• datum zavedení,
• zpracovávané datové kategorie,
• známá omezení,
• cenu,
• záložní model,
• postup při ukončení služby.

To, že firma model netrénovala, neznamená, že jej nemusí řídit.

Naopak: u proprietárního modelu může být evidence ještě důležitější, protože organizace nemá přístup ke všem informacím o jeho konstrukci, datech a interních změnách.

Model registry a AI governance

Model registry sama nezajistí odpovědné používání AI. Poskytuje však infrastrukturu, bez níž je governance obtížně proveditelná.

Pomáhá doložit:

• jaká verze byla použita,
• jak byla testována,
• kdo ji schválil,
• kde byla nasazena,
• jaká měla omezení,
• kdy byla změněna,
• zda byla později nahrazena.

EU AI Act nepřikazuje organizacím používat produkt nazvaný „model registry“.[6]

U regulovaných AI systémů však pracuje s řízením rizik, technickou dokumentací, záznamy, lidským dohledem, monitoringem a odpovědností během životního cyklu systému.

Model registry může být jednou z technických vrstev, které tyto procesy podporují.

Je však nutné rozlišovat samotný model a celý AI systém.

Model registry může evidovat modelové komponenty. Právní, bezpečnostní a obchodní posouzení se zpravidla vztahuje na konkrétní AI systém a způsob jeho použití.

Kdy firma model registry skutečně potřebuje

Komplexní technickou registry nepotřebuje každá organizace.

Firma používající pouze několik hotových SaaS aplikací bude pravděpodobně potřebovat hlavně AI system inventory a pravidla pro dodavatele.

Model registry začíná být důležitá zejména tehdy, když organizace:

• sama vyvíjí nebo dolaďuje modely;
• provozuje několik verzí stejného modelu;
• používá modely v důležitých rozhodovacích procesech;
• potřebuje formální validaci a schvalování;
• musí zajistit reprodukovatelnost;
• potřebuje rychlý rollback;
• používá více cloudů nebo deployment prostředí;
• buduje větší množství RAG aplikací a agentů;
• podléhá přísnějším požadavkům auditu nebo model risk managementu.

První implementace nemusí být rozsáhlá. Musí však vytvořit jeden autoritativní zdroj pravdy a být propojena se skutečným procesem nasazování.

Registry, kterou lze obejít tím, že vývojář nahraje jiný model přímo do produkce, neřídí skutečný provoz. Pouze dokumentuje jeho idealizovanou verzi.

Nejčastější chyby

Registry se změní v odkladiště experimentů

Pokud se do ní automaticky uloží každý pokus, rychle se zaplní stovkami variant bez provozního významu.

Od evidence všech experimentů slouží experiment tracking. Do registry mají vstupovat modely, které se staly kandidátem na validaci, nasazení nebo další řízené použití.

Model nemá konkrétního vlastníka

Technický tým model vytvořil, ale nikdo neodpovídá za jeho obchodní účel, správné použití a další provoz.

Registr bez odpovědnosti se mění v katalog souborů.

Chybí vazba na data a kód

Firma eviduje modelový artefakt, ale neví, z jakého datasetu a kódu vznikl.

Takový model nelze spolehlivě reprodukovat ani vysvětlit.

Schválení je pouze formální

Model je označen jako schválený, ale není jasné:

• kdo jej schválil,
• podle jakých kritérií,
• pro jaký účel,
• na jak dlouhou dobu,
• co má schválení zneplatnit.

Registry není propojena s nasazením

Model se sice zaregistruje, ale produkční tým může nasadit libovolný artefakt mimo schvalovací proces.

Registry pak eviduje jinou realitu, než jaká skutečně běží.

Evidence nahrazuje řízení

Detailní metadata sama o sobě neurčí, zda je model vhodný, bezpečný nebo obchodně přínosný.

Model registry dokáže vynutit a zaznamenat proces. Nedokáže sama nahradit rozhodování, odpovědnost a skutečný dohled.

Závěr

Model registry řeší základní provozní otázku:

Bez registry mohou modely existovat jako izolované soubory, API endpointy a experimenty.

S registry se z nich stávají spravovaná aktiva s dohledatelným původem, odpovědností a životním cyklem.

Její hlavní přínosy jsou:

• verzování,
• lineage a reprodukovatelnost,
• řízené schvalování,
• vazba na produkční nasazení,
• možnost rollbacku,
• evidence vlastníků a odpovědnosti,
• podpora auditu a governance.

V tradičním machine learningu byl hlavním objektem řízení samotný model.

V generativní AI je model pouze jednou součástí širší konfigurace zahrnující prompty, data, nástroje a oprávnění. Model registry se proto postupně mění z technického úložiště na řídicí vrstvu podnikové AI.

Firma totiž nepotřebuje pouze vědět, jaký model používá.

Potřebuje být schopna vysvětlit, jak vzniká chování její AI.

Časté otázky

Zdroje a další čtení

1. MLflow: ML Model Registry. Referenční open-source implementace: verzování, lineage, aliasy a návaznost na experiment. mlflow.org
2. Amazon Web Services: SageMaker Model Registry. Model groups, verze a schvalovací stavy napojené na deployment pipeline. docs.aws.amazon.com
3. Microsoft: Register and work with models in Azure Machine Learning. Registrace modelů, verzování a správa v rámci workspace. learn.microsoft.com
4. Google Cloud: Vertex AI Model Registry. Centrální přehled modelů a jejich verzí napříč nasazeními. cloud.google.com
5. Federal Reserve: SR 26-2 — Revised Guidance on Model Risk Management. Aktualizované americké pokyny k řízení modelového rizika (nahrazují SR 11-7 a SR 21-8). federalreserve.gov
6. Nařízení (EU) 2024/1689 — Artificial Intelligence Act. Základní text evropské regulace AI: řízení rizik, dokumentace, záznamy a lidský dohled. eur-lex.europa.eu

Článek má informační charakter a nepředstavuje právní stanovisko.