4,871 lecturas

Pruebas de datos para canalizaciones de aprendizaje automático mediante Deepchecks, DagsHub y GitHub Actions

por Eryk Lewinson2022/05/16

Demasiado Largo; Para Leer

Usar herramientas como DagsHub, DVC, MLFlow y GitHub Actions para crear un proyecto ML/DL completo. Intentaremos resolver un problema de clasificación binaria de imágenes utilizando imágenes de dos videojuegos clásicos.

Companies Mentioned

featured image - Pruebas de datos para canalizaciones de aprendizaje automático mediante Deepchecks, DagsHub y GitHub Actions

Hace bastante tiempo que experimenté combinando dos de mis intereses: la ciencia de datos y los videojuegos. Para un pequeño proyecto personal, extraje imágenes de dos de mis juegos favoritos de GameBoy ( Super Mario Land 2: 6 Golden Coins y Wario Land: Super Mario Land 3 ) y construí un clasificador de imágenes que detecta de qué juego proviene una imagen. ¡Fue muy divertido!

Pero este proyecto prácticamente nunca dejó un Jupyter Notebook 🙈 Y aunque personalmente me gustan los Notebooks como una herramienta de narración para una narrativa estructurada (y algo de experimentación ad-hoc), tal configuración tiene bastantes limitaciones. Para empezar, construir cualquier proyecto ML/DL es un proceso iterativo, a menudo con docenas o cientos de experimentos. Cada uno de ellos preprocesa los datos de forma ligeramente diferente, agrega algunas funciones nuevas, utiliza un modelo diferente y sus hiperparámetros, etc.

¿Cómo rastrear todo eso? Podríamos crear una hoja de cálculo y anotar manualmente todos los detalles. Pero estoy seguro de que se volvería muy molesto y engorroso después de unas pocas iteraciones. Y si bien esto podría funcionar para algunos de los puntos que he mencionado, no resolvería el problema con los datos. Simplemente no podemos rastrear datos y sus transformaciones tan fácilmente en una hoja de cálculo.

Es por eso que esta vez me gustaría abordar este proyecto de manera diferente, es decir, usar las herramientas disponibles para tener un proyecto debidamente versionado (que incluya datos) con seguimiento de experimentos y algunas verificaciones de cordura de los datos. Suena mucho mejor que el seguimiento de experimentos en una hoja de cálculo, ¿verdad?

En este artículo, le mostraré cómo usar herramientas como DagsHub, DVC, MLFlow y GitHub Actions para crear un proyecto ML/DL completo. Cubriremos los siguientes temas:

introducción al proyecto,
configurar un repositorio con DagsHub,
versionando los datos con DVC,
seguimiento de experimentos con MLFlow,
configurando verificaciones automáticas de cordura de datos usando GitHub Actions y Deepchecks.

¡Vamos a saltar directamente a eso!

Descripción del Proyecto

Como ya mencioné en la introducción, intentaremos resolver un problema de clasificación de imágenes binarias. Cuando trabajé anteriormente en este proyecto, comparé el rendimiento de un modelo de regresión logística con el de una red neuronal convolucional. En este proyecto, implementaremos este último usando keras .

A continuación puede encontrar un ejemplo de las imágenes con las que trabajaremos.

No entraré en muchos detalles en términos de obtener los datos, procesarlos, construir la CNN o incluso evaluar los modelos, ya que ya los he cubierto bastante en el pasado. Si está interesado en esas partes, consulte mis artículos anteriores:

Parte I que describe cómo obtener los datos, preprocesarlos y entrenar una regresión logística y una CNN en keras ,
Parte II que describe el entrenamiento de una CNN en PyTorch.

Para el enfoque v2 de esta tarea de clasificación de imágenes, utilizamos la siguiente estructura de proyecto:

 . ├── README.md ├── .github │ └── workflows │ └── data_validation.yml ├── data │ ├── processed │ │ ├── test │ │ │ ├── mario │ │ │ ── wario │ │ └── train │ │ ├── mario │ │ └── wario │ ├── raw │ │ ├── mario │ │ └── wario │ └── videos ├── data_validation.html ├── dvc.lock ├── dvc.yaml ├── metrics.csv ├── models ├── notebooks │ ├── 1_downloading_data.ipynb │ ├── 2_extracting_images.ipynb │ ├── 3_train_test_split.ipynb │ ├── 4_cnn_classifier.ipynb │ ├── 5_deepchecks.ipynb │ └── README.md ├── params.yml ├── requirements.txt └── src ├── config.py ├── create_train_test_split.py ├── extract_frames.py ├── get_videos.py ├── train.py ├── utils.py └── validate_data.py

Cubriremos todos los elementos a lo largo del artículo, pero por ahora podemos mencionar brevemente los siguientes:

todos los datos se almacenan en el directorio de data y cada subdirectorio almacena datos de diferentes etapas.
el directorio oculto .github es responsable de los flujos de trabajo de las acciones de GitHub.
el directorio de notebooks contiene cuadernos utilizados para la exploración, que no son relevantes para las funcionalidades del proyecto.
el directorio src contiene el código base completo del proyecto. Cada script cubre una parte diferente de la canalización.
requiremets.txt contiene la lista de bibliotecas necesarias para ejecutar el proyecto. la poetry podría funcionar igual de bien.

Definir una estructura de proyecto clara es definitivamente útil para mantener todo organizado y facilita la ejecución de experimentos que modifican solo partes de la tubería completa. Todavía hay bastantes cosas que podríamos agregar a la estructura, pero hagámoslo simple y concentrémonos en los otros elementos de la configuración del proyecto. Mencionaremos algunas posibles extensiones al final del artículo.

Configurar un repositorio con DagsHub

Como primer bloque de construcción de nuestro proyecto, usaremos DagsHub . En pocas palabras, es algo así como GitHub, pero hecho a medida para científicos de datos e ingenieros de ML (a diferencia de los ingenieros de software). En DagsHub podemos alojar y versionar fácilmente no solo nuestro código sino también nuestros datos, modelos, experimentos, etc.

Puede que estés pensando ahora "suena genial, pero tenemos que registrarnos en un servicio más y, además de eso, todo nuestro código base ya está en GitHub". Afortunadamente, eso no es un problema. Podemos migrar completamente un repositorio o, lo que es aún más conveniente, duplicar uno existente. De esta forma, podemos seguir trabajando con el repositorio de GitHub existente y se reflejará en tiempo real en DagsHub. Para este proyecto, utilizaremos la opción de creación de reflejo del repositorio: el repositorio principal de GitHub se reflejará en este en DagsHub .

Como puede ver en la imagen a continuación, la interfaz de usuario de DagsHub es muy similar a la de GitHub. De esta forma, no tenemos que aprender otra herramienta más desde cero, ya que todo parece muy familiar desde el principio. En la imagen a continuación, ya puede ver que hay algunas pestañas nuevas disponibles (experimentos, anotaciones) y las cubriremos más adelante. En la imagen, mostramos todos los archivos en el repositorio, pero podemos filtrarlos fácilmente, por ejemplo, para mostrar solo Notebooks o archivos rastreados con DVC.

No cubriremos todas las funcionalidades de DagsHub, pero también vale la pena mencionar que ofrece lo siguiente:

anotación de datos utilizando Label Studio totalmente integrado, una herramienta de código abierto para etiquetar datos estructurados y no estructurados.
comentando e iniciando discusiones en todo tipo de archivos.
comparación exhaustiva (incluidas las diferencias) de cualquier archivo que un científico de datos pueda querer usar. Siempre que los datos se almacenen en DagsHub, podemos comparar fácilmente cuadernos, tablas, archivos CSV, anotaciones, varios tipos de metadatos e incluso imágenes.

Versionado de datos con DVC

Seguro que ya estás familiarizado con el concepto de versionar el código con Git. Desafortunadamente, GitHub no funciona tan bien con los datos, ya que tiene un límite de archivos de 100 MB. Esto significa que cargar un archivo binario (o un archivo de video en nuestro caso) ya puede exceder este límite. Además de eso, comparar diferentes versiones de conjuntos de datos de cualquier tipo tampoco es la experiencia más agradable. Es por eso que necesitamos otra herramienta para el trabajo.

DVC (control de versión de datos) es una biblioteca Python de código abierto que esencialmente tiene el mismo propósito que Git (incluso con la misma sintaxis), pero para datos en lugar de código. La idea de DVC es que mantenemos la información sobre diferentes versiones de nuestros datos en Git, mientras que los datos originales se almacenan en otro lugar (almacenamiento en la nube como AWS, GCS, Google Drive, etc.).

Tal configuración requiere un poco de conocimiento de DevOps. Afortunadamente, DagsHub puede ahorrarnos bastantes problemas, ya que cada cuenta de DagsHub viene con 10 GB de almacenamiento gratuito para DVC.

Primero, necesitamos instalar la biblioteca:

 pip install dvc

Luego, necesitamos instanciar un repositorio DVC:

 dvc init

Ejecutar este comando crea 3 archivos: .dvc/.gitignore , .dvc/config y .dvcignore . Puedes encontrar más información sobre lo que contienen aquí . Luego, necesitamos conectar nuestro repositorio DVC recién creado a DagsHub. Como hemos mencionado antes, al usar DagsHub no tenemos que configurar manualmente la conexión al almacenamiento en la nube. Lo único que tenemos que hacer es ejecutar los siguientes comandos en la terminal:

 dvc remote add origin https://dagshub.com/eryk.lewinson/mario_vs_wario_v2.dvc dvc remote modify origin --local auth basic dvc remote modify origin --local user XXXX dvc remote modify origin --local password XXXX

Para hacerlo aún más fácil, DagsHub nos proporciona todos aquellos en la pestaña Remoto . Solo tenemos que copiarlos y pegarlos en la terminal.

Habiéndonos conectado al control remoto DVC, asignamos los archivos mencionados anteriormente a Git:

 git add. git commit -m "Initialized DVC" git push

Gracias a la funcionalidad de duplicación, solo necesitamos enviar nuestros archivos a GitHub, ya que DagsHub sincronizará automáticamente todos los cambios desde allí.

Ahora es el momento de construir una canalización completa, donde DVC realiza un seguimiento de las salidas de datos intermedias. Para facilitar el proceso, creamos un archivo .py independiente para cada paso de la canalización. En nuestro caso, los pasos son los siguientes:

get_videos.py : descarga los videos de los dos juegos (juegos completos, de principio a fin) de YouTube. Los videos descargados se almacenan en el directorio de data/videos .
extract_frames.py : extrae las imágenes de los archivos de video mp4. La salida se almacena en el directorio data/raw .
create_train_test_split.py : divide las imágenes extraídas en conjuntos de entrenamiento y prueba. Las salidas de esta etapa se almacenan en el directorio data/processed .
train.py — entrena a la CNN para clasificar las imágenes. Envía el modelo entrenado al directorio de models y algunos otros archivos ( metrics.csv y params.yml ) al directorio raíz.

En base a esos pasos, podemos crear una canalización usando el dvc run . Para facilitar la lectura, los pasos se dividen en 4 partes, cada una de las cuales corresponde a una etapa separada de la canalización. En la práctica, no tiene que comprometerse y empujar después de cada paso. Lo hicimos por total transparencia y manejabilidad.

 dvc run -n get_videos -d src/config.py -o data/videos python src/get_videos.py git add data/.gitignore dvc.lock dvc.yaml git commit -m "added get_videos step" git push dvc push -r origin dvc run -n extract_frames -d src/config.py -d src/utils.py -d data/videos -o data/raw python src/extract_frames.py git add dvc.yaml dvc.lock data/.gitignore git commit -m "added extract_frames step" git push dvc push -r origin dvc run -n create_train_test_split -d src/config.py -d data/raw -o data/processed python src/create_train_test_split.py git add dvc.lock data/.gitignore dvc.yaml git commit -m "executed train_test_split stage" git push dvc push -r origin dvc run -n train -d src/config.py -d data/processed/ -o models -o metrics.csv -o params.yml python src/train.py git add dvc.lock data/.gitignore dvc.yaml git commit -m "executed train step" git push dvc push -r origin

Como puede ver en los archivos comprometidos, DVC guarda las etapas de canalización en dos archivos: dvc.yaml (almacenado en un formato legible por humanos) y un dvc.lock (prácticamente ilegible). Al crear la tubería, usamos los siguientes comandos de DVC:

-n - el nombre del escenario,
-d - la dependencia del escenario,
-o - la salida del escenario.

A continuación, puede ver cómo se ve la canalización en el archivo YAML.

 stages: get_videos: cmd: python src/get_videos.py deps: - src/config.py outs: - data/videos extract_frames: cmd: python src/extract_frames.py deps: - data/videos - src/config.py - src/utils.py outs: - data/raw create_train_test_split: cmd: python src/create_train_test_split.py deps: - data/raw - src/config.py outs: - data/processed train: cmd: python src/train.py deps: - data/processed/ - src/config.py outs: - metrics.csv - models - params.yml

DVC rastreará automáticamente todos los directorios y archivos bajo las outs .

Además de eso, DagsHub ofrece una vista previa visual de la canalización de DVC. Puede encontrarlo en la lista de archivos del repositorio. Como puede ver a continuación, hace que sea mucho más fácil comprender toda la canalización que leer el archivo dvc.yml .

Habiendo definido toda la canalización de DVC, podemos usar el comando dvc repro para reproducir la canalización completa o parcial mediante la ejecución de las etapas definidas en dvc.yml .

Por último, vale la pena mencionar que podemos acceder e inspeccionar todos los datos almacenados con DVC en DagsHub, incluidos algunos metadatos. Puedes ver un ejemplo a continuación.

Seguimiento de experimentos con MLFlow

El siguiente punto en nuestra lista de deseos para este proyecto es el seguimiento de experimentos. Para hacerlo, utilizaremos otra biblioteca de código abierto: MLFlow (MLFlow Tracking, para ser precisos). Con las funcionalidades de MLFlow registraremos bastantes detalles sobre nuestros experimentos, comenzando con el nombre pasando por los hiperparámetros del modelo y terminando con las puntuaciones correspondientes.

Similar a DVC, también necesitamos un servidor para alojar MFLow. Y al igual que antes, eso también lo facilita DagsHub. Podemos encontrar los detalles necesarios para la autenticación en la pestaña Remoto en nuestro repositorio de DagsHub. Después de configurar el control remoto MLFlow, todos nuestros experimentos se registrarán en la pestaña Experimentos en nuestro repositorio de DagsHub.

En el siguiente script, puede ver cómo implementar el seguimiento con MLFlow. Es una versión abreviada del script de entrenamiento completo, que excluye algunos elementos no estrictamente relevantes (creación de generadores de datos, definición de la arquitectura de las NN, etc.). Sin embargo, mencionaremos algunas cosas sobre la implementación de MLFlow:

en las líneas 7 a 9 nos conectamos al control remoto MLFlow provisto por DagsHub,
en la línea 13 usamos el registrador automático TensorFlow de MLFlow. Es un método conveniente que nos ahorra el esfuerzo manual de especificar todos los hiperparámetros potenciales y otras especificaciones del modelo. Existen tales registradores automáticos para casi todas las bibliotecas ML/DL relevantes. Consulte aquí para obtener una lista.
en la línea 19 indicamos que estamos iniciando una ejecución de MLFlow: la biblioteca rastreará las cosas (especificadas manualmente o recogidas por el registrador automático) dentro del contexto de la ejecución (indicado mediante la instrucción with ).
en las líneas 45–54 registramos manualmente algunos parámetros (tamaño de las imágenes, tasa de aprendizaje y número de épocas) y métricas (pérdida y precisión del conjunto de prueba). Si bien esto no era necesario explícitamente (ya que estamos usando el registrador automático), queríamos mostrar ambos enfoques.

 from config import PROCESSED_IMAGES_DIR, MODELS_DIR import os import tensorflow.keras import mlflow from dagshub import dagshub_logger mlflow.set_tracking_uri("https://dagshub.com/eryk.lewinson/mario_vs_wario_v2.mlflow") os.environ['MLFLOW_TRACKING_USERNAME'] = USER_NAME os.environ['MLFLOW_TRACKING_PASSWORD'] = PASSWORD if __name__ == "__main__": mlflow.tensorflow.autolog() IMG_SIZE = 128 LR = 0.001 EPOCHS = 10 with mlflow.start_run(): training_set, valid_set, test_set = get_datasets(validation_ratio=0.2, target_img_size=IMG_SIZE, batch_size=32) model = get_model(IMG_SIZE, LR) print("Training the model...") model.fit(training_set, validation_data=valid_set, epochs = EPOCHS) print("Training completed.") print("Evaluating the model...") test_loss, test_accuracy = model.evaluate(test_set) print("Evaluating completed.") # dagshub logger with dagshub_logger() as logger: logger.log_metrics(loss=test_loss, accuracy=test_accuracy) logger.log_hyperparams({ "img_size": IMG_SIZE, "learning_rate": LR, "epochs": EPOCHS }) # mlflow logger mlflow.log_params({ "img_size": IMG_SIZE, "learning_rate": LR, "epochs": EPOCHS }) mlflow.log_metrics({ "test_set_loss": test_loss, "test_set_accuracy": test_accuracy, }) print("Saving the model...") model.save(MODELS_DIR) print("done.")

Como una pequeña ventaja, vale la pena mencionar que existe una forma alternativa y más liviana de rastrear experimentos: usar Git y DagsHub. Para hacerlo, tenemos que usar la biblioteca dagshub . En las líneas 36 a 43, mostramos cómo registrar algunas métricas e hiperparámetros usando la biblioteca dagshub .

El registrador dagshub crea dos archivos en el directorio raíz del proyecto (a menos que se especifique lo contrario): metrics.csv y params.yml . Estos son los dos archivos que indicamos en el último paso de nuestra tubería DVC como salidas del script train.py . Cuando enviamos esos dos archivos a git, DagsHub los reconocerá automáticamente y colocará sus valores en la pestaña Experimentos . Podemos ubicarlos claramente cuando observamos los experimentos marcados con la etiqueta Git en la columna de origen.

La mayor ventaja de usar el cliente dagshub es que esos experimentos son completamente reproducibles: siempre que usemos DVC para rastrear datos, podemos cambiar al estado del proyecto al momento de terminar un experimento con un solo git checkout . Tal cosa también es posible con MLFlow, pero no tan simple.

También puede escribir su propio registrador personalizado que combine lo mejor de los dos enfoques para el seguimiento de experimentos. Puede encontrar un ejemplo aquí .

Eso sería todo con respecto a los detalles de la implementación del seguimiento de experimentos. Pasando a inspeccionar algunos resultados, la siguiente imagen presenta el estado en el que aún se estaba ejecutando un experimento llamado anquilostomiasis del sueño : vemos la precisión y la pérdida actualizadas a medida que se entrena el modelo.

En la pestaña Experimentos , podemos marcar las variantes que queremos comparar y pulsar el botón comparar .

En la siguiente imagen, vemos algunos de los hiperparámetros rastreados por MLFlow. Como habrás adivinado, vemos muchos hiperparámetros porque estamos usando el registrador automático TensorFlow de MLFlow. Al final de la lista, también puede ver el hiperparámetro que agregamos manualmente: img_size . Después de eso, podemos ver las métricas relevantes.

Los dos experimentos analizados difieren en dos hiperparámetros: el número de épocas y el tamaño de imagen considerado (el tamaño de la imagen cuadrada que se pasa a la primera capa de la NN). También puede ver los valores de los hiperparámetros y las precisiones del conjunto de entrenamiento correspondiente en el siguiente gráfico de coordenadas paralelas.

Por último, podemos profundizar aún más en el análisis de varias métricas de rendimiento de los experimentos.

Como el objetivo de esta parte era solo mostrar las funcionalidades del seguimiento de MLFlow, no dedicaremos más tiempo a analizar los resultados de los experimentos.

Automatización de verificaciones de cordura de datos con GitHub Actions y Deepchecks

Como último paso de nuestro proyecto, nos gustaría crear verificaciones de cordura automatizadas para nuestros datos. Ilustremos eso con un ejemplo hipotético que podría aplicarse a nuestro proyecto. En un videojuego como los considerados (el género de los plataformas de desplazamiento lateral), la gran mayoría del tiempo se dedica a intentar terminar algún nivel o simplemente a explorar. Vemos a nuestro personaje principal corriendo y haciendo cosas (principalmente saltando).

Sin embargo, como en todos los juegos, también hay otras pantallas (menús, transición en blanco y negro o pantallas de carga, créditos finales, etc.). Podríamos argumentar que no deberían incluirse en los datos. Así que imaginemos que revisamos manualmente las imágenes y eliminamos las que consideramos inadecuadas para nuestra muestra de datos. Esto podría generar una pregunta: ¿nuestras acciones cambiaron significativamente algo en los datos, por ejemplo, el equilibrio de clases? ¿O tal vez introdujimos algún otro sesgo?

Eso también podría ser muy relevante cuando algunas de nuestras transformaciones de datos implican recortar las imágenes: podríamos cortar algunos HUD (jerga de juegos, pantalla de visualización frontal o simplemente la barra de estado *) * de una clase y mantenerlos allí para la otra. Esto llevaría a crear un clasificador que simplemente verifica si ese píxel en particular tiene un valor de X y luego decide con confianza de qué juego proviene la imagen.

Para exactamente ese escenario, sería genial tener algunos controles de cordura de datos automatizados. Mostraremos cómo crearlos usando GitHub Actions y Deepchecks. Pero primero, necesitamos responder algunas preguntas de ayuda.

¿Qué son las acciones de GitHub?

GitHub Actions es una herramienta utilizada para automatizar flujos de trabajo de software. Por ejemplo, los ingenieros de software usan GitHub Actions para automatizar acciones como fusionar sucursales, manejar problemas, ejecutar pruebas de aplicaciones o unidades, etc.

Sin embargo, eso no significa que sean inútiles para los científicos de datos. Podemos usar GitHub Actions para muchas cosas, que incluyen:

automatizando procesos ETL,
comprobar si el modelo actual debe ser reentrenado o no,
desplegando un nuevo modelo,
ejecutar verificaciones automáticas de sanidad de datos.

Algunas cosas a tener en cuenta sobre las acciones de GitHub:

admite los principales lenguajes de programación utilizados para la ciencia de datos: Python, R, Julia, etc.
es gratis para repositorios públicos y ofrece 2000 minutos/mes para repositorios privados (para las cuentas gratuitas de GitHub),
funciona muy bien con los principales proveedores de la nube,
correos electrónicos automatizados cada vez que falla el flujo de trabajo,
Las máquinas de GitHub Action no son adecuadas para tareas computacionalmente muy pesadas, por ejemplo, entrenar modelos de aprendizaje profundo.

¿Qué es Deepchecks?

En resumen, deepchecks es una biblioteca Python de código abierto para probar modelos y datos de ML/DL. La biblioteca puede ayudarnos con diversas necesidades de prueba y validación a lo largo de nuestros proyectos: podemos verificar la integridad de los datos, inspeccionar las distribuciones, confirmar divisiones de datos válidas (por ejemplo, la división de entrenamiento/prueba) y evaluar el rendimiento de nuestro modelo. ¡y más!

Acciones de GitHub + Comprobaciones profundas

En este punto, es hora de combinar los dos componentes básicos para generar automáticamente un informe de validez de datos cada vez que implementamos algunos cambios en el código base.

Primero, creamos un script que genera el informe de validez de datos con deepchecks . Usaremos la suite predeterminada de la biblioteca (en la jerga de deepchecks , esto corresponde a una colección de comprobaciones) utilizada para verificar la corrección de la división de tren/prueba. Actualmente, deepchecks proporciona suites para tareas tabulares y de visión por computadora, sin embargo, la compañía también está trabajando en una variante de NLP.

 from deepchecks.vision.simple_classification_data import load_dataset from deepchecks.vision.suites import train_test_validation from config import PROCESSED_IMAGES_DIR train_ds = load_dataset(PROCESSED_IMAGES_DIR, train=True, object_type="VisionData", image_extension="jpg") test_ds = load_dataset(PROCESSED_IMAGES_DIR, train=False, object_type="VisionData", image_extension="jpg") suite = train_test_validation() result = suite.run(train_ds, test_ds) result.save_as_html("data_validation.html")

Además, podríamos haber especificado una instancia de un modelo ajustado mientras usamos el método de run . Sin embargo, en el momento de escribir este artículo, deepchecks admite los modelos scikit-learn y PyTorch ajustados. Desafortunadamente, esto significa que nuestro keras CNN no funcionará. Pero esto probablemente cambiará en un futuro próximo, ya que deepchecks sigue siendo una biblioteca relativamente nueva y en constante desarrollo. Ejecutar el script dará como resultado la generación de un informe HTML en el directorio raíz.

Ahora es el momento de programar la ejecución de las comprobaciones de cordura. Afortunadamente, usar GitHub Actions es muy fácil. Solo tenemos que agregar un archivo .yaml al directorio .github/workflows . En este archivo .yaml , especificamos cosas como:

el nombre del flujo de trabajo
el desencadenante del flujo de trabajo: puede ser un cronograma cron o, como en nuestro caso, una solicitud push o pull a la rama principal
los permisos del flujo de trabajo
el sistema operativo donde se ejecutará el flujo de trabajo (Ubuntu, Windows o macOS): ¡se aplican diferentes precios en minutos a diferentes sistemas!
las variables env (utilizadas para almacenar secretos) a las que queremos acceder. Para usarlos, primero debemos definirlos en nuestro repositorio de GitHub. Para hacerlo, en el repositorio, vaya a Configuración > Seguridad > Secretos > Acciones.
los pasos que debe ejecutar el flujo de trabajo

 name: Data validation with deepchecks on: push: branches: [ main ] pull_request: branches: [ main ] permissions: write-all jobs: run_data_checks: runs-on: ubuntu-latest env: DVC_USERNAME: ${{ secrets.DVC_USERNAME }} DVC_PASSWORD: ${{ secrets.DVC_PASSWORD }} steps: - uses: actions/checkout@v3 - name: Set up Python 3.10 uses: actions/setup-python@v3 with: python-version: "3.10" - name: Install dependencies run: | python -m pip install --upgrade pip pip install -r requirements.txt - name: Get data run: | # dvc remote add origin https://dagshub.com/eryk.lewinson/mario_vs_wario_v2.dvc dvc remote modify origin --local auth basic dvc remote modify origin --local user $DVC_USERNAME dvc remote modify origin --local password $DVC_PASSWORD dvc pull create_train_test_split -r origin - name: Remove the old validation report run: rm -f data_validation.html - name: Validate data with deepchecks run: | python src/validate_data.py - name: Commit the validation report file uses: stefanzweifel/git-auto-commit-action@v4 with: commit_message: Added the data validation file - name: Create a comment uses: peter-evans/commit-comment@v1 with: body: | Please check the data_validation.html file for a full validation report.

El script ejecuta los siguientes pasos:

Configura una instancia de Python 3.10 en Ubuntu.
Instala las dependencias de los requirements.txt .
Extrae los datos de DVC; en este paso, debemos autenticarnos con el nombre de usuario y la contraseña (almacenados como secretos de GitHub Actions). Solo extraemos los datos de la etapa de canalización de DVC que genera la división de entrenamiento/prueba.
Elimina el archivo de validación anterior, si existe.
Ejecuta el script que genera el informe de validación de datos.
Confirma los archivos (usando una acción de plantilla: stefanzweifel/git-auto-commit-action@v4 ).
Agrega un comentario (usando una acción de plantilla: peter-evans/commit-comment@v1 ).

Después de enviar este archivo a GitHub, veremos nuestro nuevo flujo de trabajo en la pestaña Acciones .

Podemos profundizar más para ver todos los pasos del flujo de trabajo, junto con registros detallados. Esos definitivamente son útiles cuando algo sale mal y necesitamos depurar la canalización.

Una vez que finaliza el flujo de trabajo, podemos ver que el bot de GitHub publicó un comentario en nuestra confirmación.

Y ahora, la parte más interesante: podemos encontrar el informe data_validation.html en nuestro repositorio. Fue agregado y confirmado automáticamente por el bot de GitHub. Para tenerlo también localmente, solo tenemos que extraerlo del repositorio.

Por brevedad, presentamos solo algunas partes del informe de validación de datos. Afortunadamente para nosotros, la biblioteca también genera comentarios útiles sobre los cheques: qué son y qué buscar.

En la primera imagen podemos ver que las clases están perfectamente equilibradas. Esto no debería sorprendernos, dado que así fue exactamente como definimos las divisiones.

En la segunda imagen, podemos ver el diagrama de distribución del brillo de las imágenes sobre el tren y los conjuntos de prueba. Parece que la división fue exitosa, ya que son muy similares. Según la documentación, sería alarmante que la puntuación de Deriva (Distancia del motor de la tierra) fuera superior a 0,1.

Por último, nos fijamos en el Predictive Power Score del área de las imágenes. Como puede ver en los comentarios, la diferencia en el PPS no debe ser mayor a 0.2. Esa condición se cumple, ya que tenemos un PPS perfecto de 1 para todas las clases y conjuntos de datos. ¿Porqué es eso? Simplemente las imágenes de los dos videojuegos son de diferentes tamaños. Las imágenes del juego de Mario son de 160x144, mientras que las de Wario son de 320x288 (el doble de tamaño). Esto probablemente se deba al hecho de que los videos se grabaron con diferentes configuraciones de emulador (originalmente, los juegos eran para la misma consola, por lo que tenían el mismo tamaño de salida). Si bien esto significa que podemos usar el área de la imagen para predecir perfectamente la clase, ese no es el caso en el modelo real, ya que remodelamos las imágenes mientras las cargamos usando ImageDataGenerator .

Hay más

Ya hemos cubierto bastante en este artículo. Desde todo lo que reside en un solo Jupyter Notebook hasta un proyecto totalmente reproducible con control de versiones de datos y seguimiento de experimentos. Habiendo dicho eso, todavía hay algunas cosas que podríamos agregar a nuestro proyecto. Los que me vienen a la mente son:

poesía : para una mejor gestión de la dependencia.
hydra : una biblioteca utilizada para administrar archivos de configuración, es decir, acceder a parámetros almacenados en algún archivo de configuración desde dentro de un script de Python. Es útil para evitar la codificación rígida de ciertos valores.
compromiso previo : podríamos configurar un proceso para formatear automáticamente el código de Python con un formateador de elección (por ejemplo, blackk ), verificar el estilo y la calidad del código ( flake8 ), ordenar las listas de importación ( isort ), etc.
agregando pruebas unitarias para nuestras funciones personalizadas.

Terminando

En este artículo, demostramos un enfoque moderno para la creación de proyectos ML/DL con control de versiones de código y datos, seguimiento de experimentos y automatización de partes de las actividades, como la creación de informes de verificación del estado de los datos. Definitivamente requiere más trabajo que tener un solo Jupyter Notebook para todo, pero el esfuerzo extra vale la pena rápidamente.

En este punto*,* quería agradecer al soporte de DAGsHub por ayudarme con algunas preguntas.

Puede encontrar el código utilizado para este artículo en mi GitHub o DagsHub . Además, cualquier comentario constructivo es bienvenido. Puedes comunicarte conmigo en Twitter .