MLOps — Книга с рецепти, глава 1

Здравейте на всички! Аз съм CV-разработчик в КРОК. Вече три години реализираме проекти в областта на CV. През това време сме направили какво ли не, например: наблюдавали шофьори, за да се уверим, че по време на шофиране не пият, не пушат, не говорят по телефона, а гледат на пътя, а не на сънищата или облаците; фиксирали сме любители на шофирането по специализирани ленти и заемащи няколко места на паркинга; следели сме за това работниците да носят каски, ръкавици и т.н.; идентифицирали сме служител, който иска да влезе в обекта; преброили сме всичко, което е възможно.

И защо това казвам?

В процеса на реализация на проектите натрупахме опит, много опит, с част от проблемите вие или сте запознати, или ще се запознаете в бъдеще.

Моделираме ситуация

Представете си, че сме в млада компания "N", чиято дейност е свързана с ML. Работим по проект в сферата на ML (DL, CV) и поради някакви причини се прехвърляме на друга работа, изобщо правим пауза и после се връщаме към нашата или чужда невронна мрежа.

1. Настъпва моментът на истината, трябва да си спомним на какво сме спирали, какви хиперпараметри сме опитвали и най-вече, до какви резултати те са довели. Може да има безброй варианти за това как всеки е съхранявал информацията за всички пускания: в главата, в конфигурации, в бележник, в работна среда в облака. Аз съм виждал вариант, при който хиперпараметрите са били съхранявани под формата на коментирани редове в кода, общо взето полет на фантазия. А сега си представете, че се връщате не към вашия проект, а към проекта на човек, който е напуснал компанията и в наследство ви е останал код и модел с име model_1.pb. За да завършим картината и да предадем цялата болка, да си представим, че вие сте и начинаещ специалист.
2. Продължаваме напред. За да стартираме кода, е необходимо да създадем среда за работа, необходима и на всички, които ще работят с него. Често се случва така, че и средата не е оставена в наследство по някакви причини. Това също може да се окаже нетривиална задача. Не е ли жалко да губим време за този етап?
3. Обучаваме модел (например, детектор на автомобили). Достигаме момента, в който той става много добър — време е да запазим резултата. Нека го наречем car_detection_v1.pb. След това обучаваме още един — car_detection_v2.pb. Няколко време по-късно нашите колеги или ние самите обучаваме отново и отново, използвайки различни архитектури. В крайна сметка се формира куп артефакти, информация за които трябва внимателно да се събира (но, ще го направим по-късно, защото имаме по-приоритетни задачи).
4. Е, това е всичко! Имаме модел! Можем да започваме обучението на следващия модел, да разработваме архитектура за решение на нова задача или можем да отидем да пием чай? А кой ще направи деплойването?

Идентифицираме проблемите

Работата по проект или продукт е труд на много хора. С времето хората напускат и идват, проектите стават все повече, а самите проекти стават по-сложни. Така или иначе, ситуациите от описания цикъл (и не само) в различни комбинации ще се срещат от итерация на итерация. Всичко това води до загуба на време, объркване, нерви, а възможно — недоволство от страна на клиента и в крайна сметка — до пропуснати пари. Макар че обикновено стъпваме по стари грабли, мисля, че никой не иска да изпитва тези моменти отново и отново.

И така, преминахме през един цикъл на разработка и виждаме, че има проблеми, които трябва да бъдат решени. За това е необходимо:

• удобно да се съхраняват резултатите от работата;
• да направим процеса на привличане на нови служители прост;
• да улесним процеса на разгръщане на средата за разработка;
• да настроим процеса на версиониране на моделите;
• да имаме удобен начин за валидиране на моделите;
• да намерим инструмент за управление на състоянието на моделите;
• да намерим начин за доставка на моделите в продукция.

Явно е необходимо да измислим работен процес, който да позволява лесно и удобно управление на този жизнен цикъл? Тази практика има име MLOps

MLOps, или DevOps за машинно обучение, позволява на екипите от специалисти по обработка и анализ на данни и ИТ специалисти да си сътрудничат, както и да увеличават темповете на разработка и разгръщане на модели чрез мониторинг, проверка и система за управление на моделите на машинно обучение.

Можете да прочетете, какво мислят по всичко това хората от Google. От статията е ясно, че MLOps е доста обемна тема.

В следващата си статия ще опиша само част от процеса. За реализацията ще използвам инструмента MLflow, тъй като е open-source проект, за свързването е необходимо малко количество код и има интеграция с популярни ml-фреймворкове. Можете да потърсите в интернет и други инструменти, като Kubeflow, SageMaker, Trains и т.н., и евентуално да подберете този, който най-добре отговаря на вашите нужди.

"Изграждаме" MLOps на примера с инструмента MLFlow

MLFlow е платформа с отворен код за управление на жизнения цикъл на ml модели (https://mlflow.org/).

MLflow включва четири компонента:

• MLflow Tracking — решава въпросите за записване на резултати и параметри, които водят до този резултат;
• MLflow Project — позволява опаковане на код и неговото възпроизвеждане на всяка платформа;
• MLflow Models — отговаря за разполагане на модели в продукция;
• MLflow Registry — позволява съхранение на модели и управление на състоянието им в централизирано хранилище.

MLflow оперира с две сущности:

• изпълнение — това е пълен цикъл на обучение, параметри и метрики, по които искаме да регистрираме;
• експеримент — това е "тема", с която са обединени изпълнения.

Всички стъпки от примера са реализирани на операционната система Ubuntu 18.04.

1. Разгръщане на сървър

За да можем лесно да управляваме проекта си и да получаваме цялата необходима информация, ще разгърнем сървър. MLflow tracking server има два основни компонента:

• backend store — отговаря за съхранение на информацията за регистрираните модели (поддържа 4 СУБД: mysql, mssql, sqlite и postgresql);
• artifact store — отговаря за съхранение на артефакти (поддържа 7 варианта за съхранение: Amazon S3, Azure Blob Storage, Google Cloud Storage, FTP сървър, SFTP сървър, NFS, HDFS).

Като artifact store за простота да вземем sftp сървър.

• създаване на група

  $ sudo groupadd sftpg

• добавяне на потребител и задаване на парола

  $ sudo useradd -g sftpg mlflowsftp
  $ sudo passwd mlflowsftp 

• коригираме няколко настройки за достъп

  $ sudo mkdir -p /data/mlflowsftp/upload
  $ sudo chown -R root.sftpg /data/mlflowsftp
  $ sudo chown -R mlflowsftp.sftpg /data/mlflowsftp/upload

• добавяне на няколко реда в /etc/ssh/sshd_config

  Match Group sftpg
   ChrootDirectory /data/%u
   ForceCommand internal-sftp

• рестартиране на услугата

  $ sudo systemctl restart sshd

Като backend store да вземем 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
# Създайте нов потребител: mlflow_user
[postgres@user_name~]$ createuser --interactive -P
Въведете името на ролята, която искате да добавите: mlflow_user
Въведете паролата за новата роля: mlflow
Въведете я отново: mlflow
Трябва ли новата роля да бъде суперпотребител? (y/n) n
Трябва ли новата роля да може да създава бази данни? (y/n) n
Трябва ли новата роля да може да създава нови роли? (y/n) n
# Създайте база данни mlflow_bd, притежавана от mlflow_user
$ createdb -O mlflow_user mlflow_db

За да стартирате сървъра, е необходимо да инсталирате следните Python пакети (препоръчвам да създадете отделно виртуално окружение):

pip install mlflow
pip install pysftp

Стартираме нашия сървър

$ 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_port

2. Добавяме следенето

За да не загубим резултатите от нашите тренировки, бъдещите поколения разработчици да разберат какво всъщност се е случило, а по-старшите колеги и вие да можете спокойно да анализирате процеса на обучение, е необходимо да добавим следене. Под следенето се разбира запазването на параметри, метрики, артефакти и всякаква допълнителна информация за стартирането на обучението, в нашия случай, на сървъра.

За пример, създадох малък проект в github на Keras за сегментация на всичко в COCO датасет. За добавяне на следенето, създадох файл mlflow_training.py.

Ето редовете, в които се случва най-интересното:

def run(self, epochs, lr, experiment_name):
        # получаване на id на експеримента, създаване на експеримент в негово отсъствие
        remote_experiment_id = self.remote_server.get_experiment_id(name=experiment_name)
        # създаване на "run" и получаване на неговото id
        remote_run_id = self.remote_server.get_run_id(remote_experiment_id)

        # указваме, че искаме да запазим резултатите на отдалечен сървър
        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)

Тук self.remote_server е малка обвивка над методите mlflow.tracking. MlflowClient (направих го за удобство), с помощта на които създавам експеримент и стартиране на сървъра. След това посочвам къде трябва да се записват резултатите от стартирането (mlflow.set_tracking_uri(self.tracking_uri)). Свързвам автоматично логване mlflow.keras.autolog(). В момента MLflow Tracking поддържа автоматично логване за TensorFlow, Keras, Gluon XGBoost, LightGBM и Spark. Ако не намерите своя фреймуърк или библиотека, можете винаги да логвате явно. Стартираме обучението. Регистрираме таговете и входните параметри на отдалечения сървър.

Няколко реда и вие, както и всички желаещи, имате достъп до информация за всички стартирания. Яко, нали?

3. Оформяме проекта

Сега ще направим така, че стартирането на проекта да е по-лесно от всякога. За целта ще добавим файл MLproject и conda.yaml в корена на проекта.
MLproject

name: flow_segmentation
conda_env: conda.yaml

entry_points:
  main:
    parameters:
        categories: {help: 'списък с категории от coco dataset'}
        epochs: {type: int, help: 'брой епохи в обучението'}

        lr: {type: float, default: 0.001, help: 'скорост на обучение'}
        batch_size: {type: int, default: 8}
        model_name: {type: str, default: 'Unet', help: 'Unet, PSPNet, Linknet, FPN'}
        backbone_name: {type: str, default: 'resnet18', help: 'напр. resnet18, resnet50, mobilenetv2 ...'}

        tracking_uri: {type: str, help: 'адреса на сървъра'}
        experiment_name: {type: str, default: 'My_experiment', help: 'име на отдалечен и локален експеримент'}
    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 има няколко свойства:

• Name — името на вашия проект;
• Environment — в моя случай conda_env указва, че за стартиране се използва Anaconda и описанието на зависимостите се съдържа във файла conda.yaml;
• Entry Points — указва кои файлове и с какви параметри можем да стартираме (всички параметри при стартиране на обучението се логват автоматично)

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.0

Като среда за изпълнение можете да използвате docker; за повече информация се обърнете към документацията.

4. Запускаме обучението

Клонирайте проекта и преминете в директорията на проекта:

git clone https://github.com/simbakot/mlflow_example.git
cd mlflow_example/

За стартиране е необходимо да инсталирате библиотеките

pip install mlflow
pip install pysftp

Тъй като в примера използвам conda_env, на вашия компютър трябва да бъде инсталирана Anaconda (но и това може да бъде заобиколено, като инсталирате всички необходими пакети сами и експериментирате с параметрите за стартиране).

Всички подготвителни стъпки са завършени и можем да пристъпим към стартиране на обучението. От корена на проекта:

$ mlflow run -P epochs=10 -P categories=cat,dog -P tracking_uri=http://server_host:server_port .

След въвеждане на командата ще се създаде автоматично conda обкръжение и ще стартира обучението.
В примера по-горе зададох брой на епохите за обучение, категориите, на които искаме да сегментираме (пълният списък може да бъде видян тук.) и адреса на нашия отдалечен сървър.
Пълният списък на възможните параметри може да бъде видян в файла MLproject.

5. Оценяваме резултатите от обучението

След приключване на обучението можем да отидем в браузъра на адреса на нашия сървър http://server_host:server_port

Тук виждаме списък на всички експерименти (вляво горе), а също и информация за старта (в средата). Можем да видим по-подробна информация (параметри, метрики, артефакти и допълнителна информация) за всеки старт.

По всяка метрика можем да наблюдаваме историята на промените.

Т.е. в момента можем да анализираме резултатите в "ръчен" режим, също така можете да настроите и автоматична валидация с помощта на MLflow API.

6. Регистрираме модела

След като анализирахме нашия модел и решихме, че е готов за употреба, започваме с регистрацията му, за което избираме нужния ни старт (както е показано в предишната точка) и отиваме на долу.

След като дадем име на нашия модел, той получава версия. При запазване на друга модел с това име, версията автоматично ще се увеличи.

За всеки модел можем да добавим описание и да изберем едно от трите състояния (Staging, Production, Archived), впоследствие можем чрез api да се обърнем към тези състояния, което в съчетание с версионирането дава допълнителна гъвкавост.

Разполагаме и с удобен достъп до всички модели

и техните версии.

Както в предишната точка, всички операции могат да се извършат с помощта на API.

7. Деплойваме модела

На този етап вече разполагаме с обучен (keras) модел. Пример за това как можем да го използваме:

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 result

Тук self.registry отново е малка обвивка над mlflow.tracking.MlflowClient за удобство. Същността е, че се свързвам с отдалечен сървър и търся там модел с указаното име, при това, най-новата версия в продукция. След това изтеглям артефакта локално в папка .\/model и изграждам модела от тази директория mlflow.keras.load_model(local_path). Сега можем да използваме модела си. Разработчиците на CV (ML) могат спокойно да се занимават с подобряване на модела и публикуване на нови версии.

В заключение

Представих система, която позволява:

• централизирано съхранение на информация за ML модели, напредък и резултати от обучението;
• бързо разгръщане на среда за разработка;
• следене и анализ на напредъка по моделите;
• удобно управление на версиите и състоянието на моделите;
• лесно деплойване на получените модели.

Този пример е учебен и служи като отправна точка за изграждане на собствената ви система, която, възможно е, да включва автоматизация на оценката на резултатите и регистрацията на модели (п.5 и п.6 съответно) или може да добавите версиониране на наборите от данни, или нещо друго? Опитвах се да предам идеята, че ви е необходим MLOps като цяло, MLflow е просто средство за постигане на целта.

Напишете какви проблеми, с които сте се сблъсквали, не съм отразил?
Какво бихте добавили в системата, за да покривате вашите нужди?
Какви инструменти и подходи използвате, за да решите всички или част от проблемите?

P.S. Оставям няколко линка:
github проект — https://github.com/simbakot/mlflow_example
MLflow — https://mlflow.org/
Моя работна поща за въпроси — ikryakin@croc.ru

В нашата компания периодично се провеждат различни събития за ИТ специалисети, например: на 8 юли в 19:00 по московско време ще се проведе онлайн митап относно CV, ако сте заинтересувани, можете да участвате, регистрацията е отворена. тук. .

Източник: habr.com