Ola a todos! Son un programador de CV en CROC. Levamos 3 anos implementando proxectos no ámbito do CV. Durante este tempo, fixemos moitas cousas, por exemplo: vixíamos aos condutores para que mentres conducían non bebesen, non fumasen, non falasen por teléfono, mirasen a estrada e non os soños nin as nubes. ; Gravamos persoas que circulan por carrís dedicados e ocupan varias prazas de aparcamento; garantiu que os traballadores levasen cascos, luvas, etc.; identificou un empregado que quere entrar nas instalacións; Contamos todo o que puidemos.
Para que estou facendo todo isto?
No proceso de implementación de proxectos, atopamos problemas, moitos problemas, algúns dos problemas cos que está familiarizado ou cos que se familiarizará no futuro.
Imos simular a situación
Imaxinemos que conseguimos un traballo nunha empresa nova "N", cuxas actividades están relacionadas co ML. Traballamos nun proxecto de ML (DL, CV), despois por algún motivo cambiamos a outro traballo, normalmente tomamos un descanso e volvemos á neurona propia ou allea.
Chega o momento da verdade, cómpre lembrar dalgún xeito onde paraches, que hiperparámetros probaches e, o máis importante, a que resultados levaron. Pode haber moitas opcións para quen gardou información sobre todos os lanzamentos: na cabeza, configuracións, bloc de notas, nun ambiente de traballo na nube. Vin unha opción cando se almacenaban hiperparámetros como liñas comentadas no código, en xeral, un voo de fantasía. Agora imaxina que non volveches ao teu proxecto, senón ao proxecto dunha persoa que deixou a empresa e que herdaches un código e un modelo chamado model_1.pb. Para completar a imaxe e transmitir toda a dor, imaxinemos que tamén es un especialista principiante.
Adiante. Para executar o código, nós e todos os que traballen con el necesitamos crear un ambiente. A miúdo ocorre que por algún motivo non o deixaron como herdanza nosa. Isto tamén pode converterse nunha tarefa non trivial. Non queres perder o tempo neste paso, non?
Adestramos un modelo (por exemplo, un detector de coches). Chegamos ao punto no que se fai moi bo: é hora de gardar o resultado. Chamémoslle car_detection_v1.pb. Despois adestramos outro: car_detection_v2.pb. Tempo despois, os nosos compañeiros ou nós mesmos ensinamos cada vez máis, utilizando diferentes arquitecturas. Como resultado, fórmanse unha morea de artefactos, sobre os cales hai que recoller minuciosamente información (pero farémolo máis adiante, porque polo momento temos máis asuntos prioritarios).
OK, todo rematou agora! Temos un modelo! Podemos comezar a adestrar o seguinte modelo, a desenvolver unha arquitectura para resolver un novo problema, ou podemos ir tomar un té? E quen vai despregar?
Identificación de problemas
Traballar nun proxecto ou produto é traballo de moitas persoas. E co paso do tempo, a xente vai e vén, hai máis proxectos, e os propios proxectos vólvense máis complexos. Dun xeito ou doutro, as situacións do ciclo descrito anteriormente (e non só) en determinadas combinacións daranse de iteración en iteración. Todo isto resulta en tempo perdido, confusión, nervios, posiblemente insatisfacción dos clientes e, en definitiva, diñeiro perdido. Aínda que todos adoitamos seguir o mesmo vello anciño, creo que ninguén quere revivir estes momentos unha e outra vez.
Polo tanto, pasamos por un ciclo de desenvolvemento e vemos que hai problemas que hai que resolver. Para iso necesitas:
almacenar convenientemente os resultados do traballo;
simplificar o proceso de implicación de novos empregados;
simplificar o proceso de implantación dun ambiente de desenvolvemento;
configurar o proceso de versión do modelo;
ter un xeito cómodo de validar modelos;
atopar unha ferramenta modelo de xestión do estado;
atopar unha forma de entregar modelos á produción.
Ao parecer, é necesario elaborar un fluxo de traballo que che permita xestionar de xeito sinxelo e cómodo este ciclo de vida? Esta práctica chámase MLOps
MLOps, ou DevOps para a aprendizaxe automática, permite que os equipos de ciencia de datos e TI colaboren e aumenten o ritmo de desenvolvemento e implantación de modelos mediante a supervisión, validación e goberno dos modelos de aprendizaxe automática.
Podes lerQue pensan os mozos de Google sobre todo isto? Do artigo queda claro que MLOps é unha cousa bastante voluminosa.
Máis adiante no meu artigo describirei só unha parte do proceso. Para a implementación, usarei a ferramenta MLflow, porque... Este é un proxecto de código aberto, é necesaria unha pequena cantidade de código para conectarse e hai integración con frameworks ml populares. Podes buscar en Internet outras ferramentas, como Kubeflow, SageMaker, Trains, etc., e quizais atopar unha que mellor se adapte ás túas necesidades.
"Construír" MLOps usando o exemplo de uso da ferramenta MLFlow
MLFlow é unha plataforma de código aberto para a xestión do ciclo de vida dos modelos ml (https://mlflow.org/).
MLflow inclúe catro compoñentes:
Seguimento de MLflow: abarca os problemas de rexistro de resultados e parámetros que levaron a este resultado;
Proxecto MLflow: permítelle empaquetar código e reproducilo en calquera plataforma;
MLflow Models - responsable da implantación de modelos na produción;
Rexistro MLflow: permítelle almacenar modelos e xestionar o seu estado nun repositorio centralizado.
MLflow opera en dúas entidades:
o lanzamento é un ciclo completo de formación, parámetros e métricas polos que queremos rexistrarse;
Un experimento é un "tema" que funciona xunto.
Todos os pasos do exemplo están implementados no sistema operativo Ubuntu 18.04.
1. Implementa o servidor
Para que poidamos xestionar facilmente o noso proxecto e recibir toda a información necesaria, implantaremos un servidor. O servidor de seguimento MLflow ten dous compoñentes principais:
Backend store - responsable de almacenar información sobre modelos rexistrados (soporta 4 DBMS: mysql, mssql, sqlite e postgresql);
tenda de artefactos: responsable de almacenar artefactos (admite 7 opcións de almacenamento: Amazon S3, Azure Blob Storage, Google Cloud Storage, servidor FTP, servidor SFTP, NFS, HDFS).
A medida que o tenda de artefactos Para simplificar, tomemos un servidor sftp.
crear un grupo
$ sudo groupadd sftpg
engadir un usuario e establecer un contrasinal para el
Match Group sftpg
ChrootDirectory /data/%u
ForceCommand internal-sftp
reiniciar o servizo
$ sudo systemctl restart sshd
A medida que o tenda de backend Tomemos 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_db
Para iniciar o servidor, cómpre instalar os seguintes paquetes de Python (recomendo crear un entorno virtual separado):
Para que os resultados da nosa formación non se perdan, as xeracións futuras de desenvolvedores entendan o que estaba a suceder, e para que os compañeiros máis vellos e ti poidas analizar con calma o proceso de aprendizaxe, necesitamos engadir un seguimento. O seguimento significa gardar parámetros, métricas, artefactos e calquera información adicional sobre o inicio do adestramento, no noso caso, no servidor.
Por exemplo, creei un pequeno proxecto en github en Keras para segmentar todo o que hai Conjunto de datos COCO. Para engadir o seguimento, creei un ficheiro mlflow_training.py.
Estas son as liñas onde suceden as cousas máis interesantes:
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)
Aquí self.remote_server é un pequeno envoltorio sobre os métodos mlflow.tracking. MlflowClient (fíxeno por comodidade), coa axuda do cal creo un experimento e executo no servidor. A continuación, indico onde se deben combinar os resultados do lanzamento (mlflow.set_tracking_uri(self.tracking_uri)). Active o rexistro automático mlflow.keras.autolog(). Actualmente MLflow Tracking admite o rexistro automático para TensorFlow, Keras, Gluon XGBoost, LightGBM, Spark. Se non atopou o seu marco ou biblioteca, sempre pode iniciar sesión de forma explícita. Comezamos a adestrar. Rexistra etiquetas e parámetros de entrada no servidor remoto.
Un par de liñas e ti, como todo o mundo, tes acceso á información sobre todos os lanzamentos. Xenial?
3. Elaboramos o proxecto
Agora imos facilitar o lanzamento do proxecto. Para iso, engade o ficheiro MLproject e conda.yaml á raíz do proxecto.
MLproxecto
Ambiente: no meu caso, conda_env indica que Anaconda se usa para executar e a descrición da dependencia está no ficheiro conda.yaml;
Puntos de entrada: indica que ficheiros e con que parámetros podemos executar (todos os parámetros rexístranse automaticamente ao comezar o adestramento)
Podes usar Docker como ambiente de execución; para obter máis detalles, consulta documentación.
4. Comecemos a adestrar
Clonamos o proxecto e imos ao directorio do proxecto:
git clone https://github.com/simbakot/mlflow_example.git
cd mlflow_example/
Para executalo é necesario instalar bibliotecas
pip install mlflow
pip install pysftp
Porque no exemplo que uso conda_env, Anaconda debe estar instalado no teu ordenador (pero podes evitar isto instalando ti mesmo todos os paquetes necesarios e xogando cos parámetros de inicio).
Todos os pasos preparatorios están completados e podemos comezar a poñer en marcha a formación. Desde a raíz do proxecto:
$ mlflow run -P epochs=10 -P categories=cat,dog -P tracking_uri=http://server_host:server_port .
Despois de introducir o comando, crearase automaticamente un ambiente conda e comezará o adestramento.
No exemplo anterior, pasei o número de épocas para o adestramento, as categorías nas que queremos segmentar (podes ver a lista completa aquí) e o enderezo do noso servidor remoto.
No ficheiro MLproject pódese atopar unha lista completa de posibles parámetros.
Aquí vemos unha lista de todos os experimentos (arriba á esquerda), así como información sobre as carreiras (centro). Podemos ver información máis detallada (parámetros, métricas, artefactos e algunha información adicional) para cada lanzamento.
Para cada métrica podemos observar o historial de cambios
Eses. Polo momento, podemos analizar os resultados nun modo "manual" e tamén pode configurar a validación automática mediante a API de MLflow.
6. Rexistrar o modelo
Despois de ter analizado o noso modelo e de decidir que está listo para a batalla, procedemos a rexistralo, para iso seleccionamos o lanzamento que necesitamos (como se mostra no parágrafo anterior) e baixamos.
Despois de darlle un nome ao noso modelo, ten unha versión. Se gardas outro modelo co mesmo nome, a versión actualizarase automaticamente.
Para cada modelo, podemos engadir unha descrición e seleccionar un dos tres estados (Producción, Produción, Arquivado); posteriormente, mediante a API, podemos acceder a estes estados, o que, xunto coa versión, proporciona flexibilidade adicional.
Tamén temos fácil acceso a todos os modelos
e as súas versións
Como no parágrafo anterior, todas as operacións pódense realizar mediante a API.
7. Implementa o modelo
Nesta fase, xa temos un modelo adestrado (keras). Un exemplo de como podes usalo:
Aquí self.registry é de novo un pequeno envoltorio sobre mlflow.tracking.MlflowClient, por comodidade. A cuestión é que accedo a un servidor remoto e busco alí un modelo co nome especificado e a última versión de produción. A continuación, descargo o artefacto localmente no cartafol ./model e constrúo o modelo desde este directorio mlflow.keras.load_model(local_path). Agora podemos usar o noso modelo. Os desenvolvedores de CV (ML) poden mellorar facilmente o modelo e publicar novas versións.
En conclusión
Presentei un sistema que permite:
almacenar centralmente información sobre modelos de ML, progreso da formación e resultados;
implementar rapidamente un ambiente de desenvolvemento;
supervisar e analizar o avance dos traballos sobre modelos;
é conveniente versionar e xestionar o estado dos modelos;
É doado implementar os modelos resultantes.
Este exemplo é un xoguete e serve como punto de partida para construír o teu propio sistema, que pode incluír a automatización da avaliación de resultados e o rexistro de modelos (puntos 5 e 6, respectivamente) ou engadirás versións de conxuntos de datos, ou quizais algo máis? O punto que intentaba dicir é que necesitas MLOps como un todo, MLflow é só un medio para un fin.
Escribe que problemas atopaches que non mostrei?
Que engadirías ao sistema para que satisfaga as túas necesidades?
Que ferramentas e enfoques utilizas para resolver todos ou parte dos problemas?
A nosa empresa organiza periodicamente varios eventos para especialistas en TI, por exemplo: o 8 de xullo ás 19:00, hora de Moscova, haberá unha reunión de CV en formato en liña, se estás interesado, podes participar, inscrición. aquí .