Prozkoumání architektury řešení

Dokončeno

Pojďme revidovat architekturu operací strojového učení (MLOps), abychom pochopili účel toho, čeho se snažíme dosáhnout.

Představte si, že společně s týmem pro vývoj datových věd a softwaru jste se dohodli na následující architektuře pro trénování, testování a nasazení modelu klasifikace diabetes:

Diagram architektury operací strojového učení

Poznámka:

Diagram je zjednodušená reprezentace architektury MLOps. Pokud chcete zobrazit podrobnější architekturu, prozkoumejte různé případy použití v akcelerátoru řešení MLOps (v2).

Architektura zahrnuje:

  1. Nastavení: Vytvořte všechny potřebné prostředky Azure pro řešení.
  2. Vývoj modelů (vnitřní smyčka):Prozkoumejte a zpracujte data pro trénování a vyhodnocení modelu.
  3. Kontinuální integrace: Zabalte a zaregistrujte model.
  4. Nasazení modelu (vnější smyčka): Nasaďte model.
  5. Průběžné nasazování: Otestujte model a propagujte ho do produkčního prostředí.
  6. Monitorování: Monitorování výkonu modelu a koncového bodu

Tým datových věd zodpovídá za vývoj modelů. Tým pro vývoj softwaru zodpovídá za integraci nasazeného modelu s webovou aplikací, kterou používají lékaři k vyhodnocení, jestli má pacient cukrovku. Zodpovídáte za převzetí modelu od vývoje modelů po nasazení modelu.

Očekáváte, že tým datových věd bude neustále navrhovat změny skriptů použitých k trénování modelu. Kdykoli dojde ke změně trénovacího skriptu, musíte model znovu natrénovat a znovu nasadit model do existujícího koncového bodu.

Chcete týmu datových věd umožnit experimentovat, aniž by se dotknul kódu připraveného pro produkční prostředí. Chcete také zajistit, aby všechny nové nebo aktualizované kódy automaticky prošly odsouhlasenou kontrolou kvality. Po ověření kódu pro trénování modelu použijete aktualizovaný trénovací skript k trénování nového modelu a jeho nasazení.

Abyste mohli sledovat změny a ověřit kód před aktualizací produkčního kódu, je nutné pracovat s větvemi. Souhlasili jste s týmem datových věd, že pokaždé, když chce udělat změnu, vytvoří větev funkce, která vytvoří kopii kódu a provede změny kopie.

Každý datový vědec může vytvořit větev funkcí a pracovat tam. Jakmile kód aktualizuje a chce, aby tento kód byl novým produkčním kódem , bude muset vytvořit žádost o přijetí změn. V žádosti o přijetí změn se zobrazí ostatním, co navrhované změny jsou, a ostatním uživatelům umožníte tyto změny zkontrolovat a prodiskutovat.

Pokaždé, když se vytvoří žádost o přijetí změn, chcete automaticky zkontrolovat, jestli kód funguje a jestli kvalita kódu odpovídá standardům vaší organizace. Jakmile kód projde kontrolou kvality, musí vedoucí datový vědec zkontrolovat změny a schválit aktualizace před sloučením žádosti o přijetí změn a odpovídajícím způsobem aktualizovat kód v hlavní větvi.

Důležité

Nikdo by neměl být nikdy povolený nasdílení změn do hlavní větve. Pokud chcete zabezpečit kód, zejména produkční kód, budete chtít vynutit, aby se hlavní větev aktualizovala jenom prostřednictvím žádostí o přijetí změn, které je potřeba schválit.