Hei alle sammen! Jeg er CV-utvikler hos CROC. Vi har gjennomført prosjekter innen CV i 3 år nå. I løpet av denne tiden gjorde vi mange ting, for eksempel: vi overvåket sjåfører slik at de ikke drakk, ikke røykte, ikke snakket i telefon, så på veien og ikke på drømmer eller på skyene mens de kjørte. ; Vi registrerte folk som kjører i dedikerte kjørefelt og tar opp flere parkeringsplasser; sørget for at arbeiderne brukte hjelmer, hansker osv.; identifisert en ansatt som ønsker å gå inn i anlegget; Vi telte alt vi kunne.
Hva gjør jeg alt dette for?
I prosessen med å gjennomføre prosjekter treffer vi støt, mange støt, noen av problemene du enten er kjent med eller vil bli kjent med i fremtiden.
La oss simulere situasjonen
La oss forestille oss at vi fikk jobb i et ungt selskap "N", hvis aktiviteter er relatert til ML. Vi jobber med et ML-prosjekt (DL, CV), så bytter vi av en eller annen grunn til en annen jobb, tar vanligvis en pause og går tilbake til vår egen eller andres nevron.
- Sannhetens øyeblikk kommer, du må på en eller annen måte huske hvor du stoppet, hvilke hyperparametre du prøvde og, viktigst av alt, hvilke resultater de førte til. Det kan være mange alternativer for hvem som har lagret informasjon på alle lanseringer: i hodet, konfigurasjoner, notisblokk, i et arbeidsmiljø i skyen. Jeg så tilfeldigvis et alternativ når hyperparametere ble lagret som kommenterte linjer i koden, generelt sett en fantasi. Tenk deg nå at du ikke returnerte til prosjektet ditt, men til prosjektet til en person som forlot selskapet og du arvet en kode og en modell kalt model_1.pb. For å fullføre bildet og formidle all smerten, la oss forestille oss at du også er en nybegynnerspesialist.
- Gå videre. For å kjøre koden må vi og alle som skal jobbe med den skape et miljø. Det hender ofte at de av en eller annen grunn ikke forlot ham som vår arv. Dette kan også bli en ikke-triviell oppgave. Du vil ikke kaste bort tid på dette trinnet, gjør du?
- Vi trener en modell (for eksempel en bildetektor). Vi kommer til det punktet hvor det blir veldig bra - det er på tide å lagre resultatet. La oss kalle det car_detection_v1.pb. Så trener vi en til - car_detection_v2.pb. En tid senere underviser kollegene våre eller vi selv mer og mer ved å bruke forskjellige arkitekturer. Som et resultat dannes det en haug med gjenstander, informasjon om hvilke må samles møysommelig (men vi vil gjøre dette senere, for foreløpig har vi flere prioriterte saker).
- OK, det er over nå! Vi har en modell! Kan vi begynne å trene neste modell, utvikle en arkitektur for å løse et nytt problem, eller kan vi ta en te? Og hvem skal utplassere?
Identifisere problemer
Å jobbe med et prosjekt eller produkt er arbeidet til mange mennesker. Og over tid går folk og kommer, det er flere prosjekter, og prosjektene i seg selv blir mer komplekse. På en eller annen måte vil situasjoner fra syklusen beskrevet ovenfor (og ikke bare) i visse kombinasjoner oppstå fra iterasjon til iterasjon. Alt dette resulterer i bortkastet tid, forvirring, nerver, muligens kundemisnøye, og til slutt tapte penger. Selv om vi alle vanligvis følger den samme gamle raken, tror jeg at ingen ønsker å gjenoppleve disse øyeblikkene om og om igjen.
Så vi har gått gjennom en utviklingssyklus og vi ser at det er problemer som må løses. For å gjøre dette trenger du:
- lagre arbeidsresultater enkelt;
- gjøre prosessen med å involvere nye ansatte enkel;
- forenkle prosessen med å distribuere et utviklingsmiljø;
- konfigurere modellversjonsprosessen;
- ha en praktisk måte å validere modeller på;
- finne en modell for statlig styringsverktøy;
- finne en måte å levere modeller til produksjon.
Tilsynelatende er det nødvendig å komme opp med en arbeidsflyt som lar deg enkelt og bekvemt administrere denne livssyklusen? Denne praksisen kalles MLOps
MLOps, eller DevOps for maskinlæring, lar datavitenskap og IT-team samarbeide og øke tempoet i modellutvikling og distribusjon gjennom overvåking, validering og styring for maskinlæringsmodeller.
Du kan Hva synes Google-gutta om alt dette? Fra artikkelen er det klart at MLOps er en ganske omfangsrik ting.
Videre i artikkelen min vil jeg beskrive bare en del av prosessen. For implementering vil jeg bruke MLflow-verktøyet, fordi... Dette er et åpen kildekode-prosjekt, en liten mengde kode kreves for å koble til og det er integrasjon med populære ml-rammeverk. Du kan søke på Internett etter andre verktøy, som Kubeflow, SageMaker, Tog osv., og kanskje finne et som passer bedre for dine behov.
"Bygge" MLO-er ved å bruke eksemplet med bruk av MLFlow-verktøyet
MLFlow er en åpen kildekode-plattform for livssyklusadministrasjon av ml-modeller ().
MLflow inkluderer fire komponenter:
- MLflow Tracking - dekker problemene med registrering av resultater og parametere som førte til dette resultatet;
- MLflow Project - lar deg pakke kode og reprodusere den på hvilken som helst plattform;
- MLflow Models - ansvarlig for å distribuere modeller til produksjon;
- MLflow Registry - lar deg lagre modeller og administrere deres tilstand i et sentralisert depot.
MLflow opererer på to enheter:
- lansering er en full syklus av trening, parametere og beregninger som vi ønsker å registrere oss etter;
- Et eksperiment er et "emne" som går sammen.
Alle trinnene i eksemplet er implementert på operativsystemet Ubuntu 18.04.
1. Distribuer serveren
For at vi enkelt skal kunne administrere prosjektet vårt og motta all nødvendig informasjon, vil vi distribuere en server. MLflow-sporingsserver har to hovedkomponenter:
- backend store - ansvarlig for å lagre informasjon om registrerte modeller (støtter 4 DBMSer: mysql, mssql, sqlite og postgresql);
- artefaktlager - ansvarlig for lagring av artefakter (støtter 7 lagringsalternativer: Amazon S3, Azure Blob Storage, Google Cloud Storage, FTP-server, SFTP-server, NFS, HDFS).
Som gjenstandsbutikk For enkelhets skyld, la oss ta en sftp-server.
- opprette en gruppe
$ sudo groupadd sftpg - legg til en bruker og angi et passord for ham
$ sudo useradd -g sftpg mlflowsftp $ sudo passwd mlflowsftp - justere et par tilgangsinnstillinger
$ sudo mkdir -p /data/mlflowsftp/upload $ sudo chown -R root.sftpg /data/mlflowsftp $ sudo chown -R mlflowsftp.sftpg /data/mlflowsftp/upload - legg til noen linjer i /etc/ssh/sshd_config
Match Group sftpg ChrootDirectory /data/%u ForceCommand internal-sftp - starte tjenesten på nytt
$ sudo systemctl restart sshd
Som backend butikk La oss ta postgresql.
$ sudo apt update
$ sudo apt-get install -y postgresql postgresql-contrib postgresql-server-dev-all
$ sudo apt install gcc
$ pip install psycopg2
$ sudo -u postgres -i
# Create new user: mlflow_user
[postgres@user_name~]$ createuser --interactive -P
Enter name of role to add: mlflow_user
Enter password for new role: mlflow
Enter it again: mlflow
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
# Create database mlflow_bd owned by mlflow_user
$ createdb -O mlflow_user mlflow_dbFor å starte serveren må du installere følgende python-pakker (jeg anbefaler å lage et eget virtuelt miljø):
pip install mlflow
pip install pysftpLa oss starte serveren vår
$ mlflow server
--backend-store-uri postgresql://mlflow_user:mlflow@localhost/mlflow_db
--default-artifact-root sftp://mlflowsftp:mlflow@sftp_host/upload
--host server_host
--port server_port2. Legg til sporing
For at resultatene av treningen vår ikke skal gå tapt, fremtidige generasjoner av utviklere skal forstå hva som skjedde, og for at eldre kamerater og deg rolig skal kunne analysere læringsprosessen, må vi legge til sporing. Sporing betyr å lagre parametere, beregninger, artefakter og eventuell tilleggsinformasjon om starten av treningen, i vårt tilfelle, på serveren.
For eksempel opprettet jeg en liten på Keras for å segmentere alt som er inne . For å legge til sporing opprettet jeg en fil mlflow_training.py.
Her er linjene der de mest interessante tingene skjer:
def run(self, epochs, lr, experiment_name):
# getting the id of the experiment, creating an experiment in its absence
remote_experiment_id = self.remote_server.get_experiment_id(name=experiment_name)
# creating a "run" and getting its id
remote_run_id = self.remote_server.get_run_id(remote_experiment_id)
# indicate that we want to save the results on a remote server
mlflow.set_tracking_uri(self.tracking_uri)
mlflow.set_experiment(experiment_name)
with mlflow.start_run(run_id=remote_run_id, nested=False):
mlflow.keras.autolog()
self.train_pipeline.train(lr=lr, epochs=epochs)
try:
self.log_tags_and_params(remote_run_id)
except mlflow.exceptions.RestException as e:
print(e)Her er self.remote_server en liten innpakning over mlflow.tracking-metodene. MlflowClient (jeg laget det for enkelhets skyld), ved hjelp av det lager jeg et eksperiment og kjører det på serveren. Deretter angir jeg hvor lanseringsresultatene skal slås sammen (mlflow.set_tracking_uri(self.tracking_uri)). Jeg aktiverer automatisk logging mlflow.keras.autolog(). For øyeblikket støtter MLflow Tracking automatisk logging for TensorFlow, Keras, Gluon XGBoost, LightGBM, Spark. Hvis du ikke har funnet rammeverket eller biblioteket ditt, kan du alltid logge eksplisitt. Vi begynner å trene. Registrer tagger og inngangsparametere på den eksterne serveren.
Et par linjer og du, som alle andre, har tilgang til informasjon om alle lanseringer. Kul?
3. Vi trekker opp prosjektet
La oss nå gjøre det enkelt å starte prosjektet. For å gjøre dette, legg til MLproject- og conda.yaml-filen til prosjektroten.
ML-prosjekt
name: flow_segmentation
conda_env: conda.yaml
entry_points:
main:
parameters:
categories: {help: 'list of categories from coco dataset'}
epochs: {type: int, help: 'number of epochs in training'}
lr: {type: float, default: 0.001, help: 'learning rate'}
batch_size: {type: int, default: 8}
model_name: {type: str, default: 'Unet', help: 'Unet, PSPNet, Linknet, FPN'}
backbone_name: {type: str, default: 'resnet18', help: 'exampe resnet18, resnet50, mobilenetv2 ...'}
tracking_uri: {type: str, help: 'the server address'}
experiment_name: {type: str, default: 'My_experiment', help: 'remote and local experiment name'}
command: "python mlflow_training.py
--epochs={epochs}
--categories={categories}
--lr={lr}
--tracking_uri={tracking_uri}
--model_name={model_name}
--backbone_name={backbone_name}
--batch_size={batch_size}
--experiment_name={experiment_name}"MLflow Project har flere egenskaper:
- Navn - navnet på prosjektet ditt;
- Miljø - i mitt tilfelle indikerer conda_env at Anaconda brukes til å kjøre og avhengighetsbeskrivelsen er i conda.yaml-filen;
- Entry Points - indikerer hvilke filer og med hvilke parametere vi kan kjøre (alle parametere logges automatisk når trening starter)
conda.yaml
name: flow_segmentation
channels:
- defaults
- anaconda
dependencies:
- python==3.7
- pip:
- mlflow==1.8.0
- pysftp==0.2.9
- Cython==0.29.19
- numpy==1.18.4
- pycocotools==2.0.0
- requests==2.23.0
- matplotlib==3.2.1
- segmentation-models==1.0.1
- Keras==2.3.1
- imgaug==0.4.0
- tqdm==4.46.0
- tensorflow-gpu==1.14.0Du kan bruke docker som kjøretidsmiljø, se for mer informasjon .
4. La oss begynne å trene
Vi kloner prosjektet og går til prosjektkatalogen:
git clone https://github.com/simbakot/mlflow_example.git
cd mlflow_example/For å kjøre må du installere biblioteker
pip install mlflow
pip install pysftpFordi i eksemplet jeg bruker conda_env, må Anaconda være installert på datamaskinen din (men du kan komme deg rundt dette ved å installere alle nødvendige pakker selv og leke med lanseringsparametrene).
Alle forberedende trinn er fullført og vi kan begynne å starte opplæringen. Fra prosjektroten:
$ mlflow run -P epochs=10 -P categories=cat,dog -P tracking_uri=http://server_host:server_port .Etter å ha lagt inn kommandoen vil et conda-miljø automatisk opprettes og treningen starter.
I eksemplet ovenfor passerte jeg antall epoker for trening, kategoriene vi ønsker å segmentere i (du kan se hele listen ) og adressen til vår eksterne server.
En fullstendig liste over mulige parametere finner du i MLproject-filen.
5. Vurder læringsresultater
Etter fullført opplæring kan vi gå i nettleseren til adressen til serveren vår
Her ser vi en liste over alle forsøk (øverst til venstre), samt informasjon om kjøringer (midt). Vi kan se mer detaljert informasjon (parametere, beregninger, artefakter og litt tilleggsinformasjon) for hver lansering.
For hver beregning kan vi observere endringshistorikken
De. For øyeblikket kan vi analysere resultatene i en "manuell" modus, og du kan også sette opp automatisk validering ved hjelp av MLflow API.
6. Registrer modellen
Etter at vi har analysert modellen vår og bestemt at den er klar for kamp, fortsetter vi med å registrere den, for dette velger vi lanseringen vi trenger (som vist i forrige avsnitt) og går ned.
Etter at vi har gitt modellen vår et navn, har den en versjon. Hvis du lagrer en annen modell med samme navn, vil versjonen automatisk oppgraderes.
For hver modell kan vi legge til en beskrivelse og velge en av tre tilstander (Staging, Production, Archived); deretter, ved å bruke API, kan vi få tilgang til disse tilstandene, som sammen med versjonsstyring gir ekstra fleksibilitet.
Vi har også enkel tilgang til alle modeller
og deres versjoner
Som i forrige avsnitt, kan alle operasjoner gjøres ved hjelp av API.
7. Distribuer modellen
På dette stadiet har vi allerede en trent (keras) modell. Et eksempel på hvordan du kan bruke det:
class SegmentationModel:
def __init__(self, tracking_uri, model_name):
self.registry = RemoteRegistry(tracking_uri=tracking_uri)
self.model_name = model_name
self.model = self.build_model(model_name)
def get_latest_model(self, model_name):
registered_models = self.registry.get_registered_model(model_name)
last_model = self.registry.get_last_model(registered_models)
local_path = self.registry.download_artifact(last_model.run_id, 'model', './')
return local_path
def build_model(self, model_name):
local_path = self.get_latest_model(model_name)
return mlflow.keras.load_model(local_path)
def predict(self, image):
image = self.preprocess(image)
result = self.model.predict(image)
return self.postprocess(result)
def preprocess(self, image):
image = cv2.resize(image, (256, 256))
image = image / 255.
image = np.expand_dims(image, 0)
return image
def postprocess(self, result):
return resultHer er self.registry igjen en liten innpakning over mlflow.tracking.MlflowClient, for enkelhets skyld. Poenget er at jeg får tilgang til en ekstern server og ser etter en modell der med det angitte navnet, og siste produksjonsversjon. Deretter laster jeg ned artefakten lokalt til ./model-mappen og bygger modellen fra denne katalogen mlflow.keras.load_model(local_path). Nå kan vi bruke modellen vår. CV (ML) utviklere kan enkelt forbedre modellen og publisere nye versjoner.
i konklusjonen
Jeg presenterte et system som tillater:
- sentralt lagre informasjon om ML-modeller, treningsfremgang og resultater;
- raskt distribuere et utviklingsmiljø;
- overvåke og analysere fremdriften i arbeidet med modeller;
- det er praktisk å versjonere og administrere tilstanden til modellene;
- Det er enkelt å distribuere de resulterende modellene.
Dette eksemplet er et leketøy og fungerer som et utgangspunkt for å bygge ditt eget system, som kan inkludere automatisering av evaluering av resultater og registrering av modeller (henholdsvis punkt 5 og 6) eller du vil legge til versjonering av datasett, eller kanskje noe annet ? Poenget jeg prøvde å komme med er at du trenger MLOps som en helhet, MLflow er bare et middel til et mål.
Skriv hvilke problemer du støtt på som jeg ikke viste?
Hva vil du legge til systemet for å få det til å dekke dine behov?
Hvilke verktøy og tilnærminger bruker du for å løse alle eller deler av problemene?
PS Jeg legger igjen et par linker:
github prosjekt -
MLflow -
Min jobb-e-post for spørsmål - [e-postbeskyttet]
Vårt firma arrangerer med jevne mellomrom ulike arrangementer for IT-spesialister, for eksempel: 8. juli kl. 19:00 Moskva-tid vil det være et CV-møte i et online format, hvis du er interessert, kan du delta, registrering .
Kilde: www.habr.com