Primero, usamos nuestro proyecto. principal rama para almacenar la definición del problema, la documentación, la descripción de datos y la estructura del proyecto. Esto sirve como un espacio para la colaboración y el debate.
CONSEJO: Comenzando por definir claramente el problema empresarial, determinar el resultado deseado, identificar los valores o etiquetas objetivo y cómo se obtienen, y establecer métricas y requisitos de evaluación, podemos garantizar un inicio exitoso de nuestro proyecto y proporcionar un lugar para la incorporación y la colaboración.
También podemos usarlo para seguimiento experimentos, donde se combinan los resultados de sus experimentos. Por ejemplo, flujo de ml La carpeta mlruns se puede fusionar allí para este propósito. Cualquier colaborador puede consultar esta rama y ejecutar la interfaz de usuario.
Alternativamente, el seguimiento se puede realizar en otra sucursal.
Comenzar de esta manera es muy simple y, a medida que las necesidades cambian con el tiempo, es posible actualizar a un servidor MLflow o una plataforma de seguimiento como Weights and Biases con cambios mínimos.
Estas son ramas del proyecto, que incluyen principalmente archivos de datos, documentación y scripts de transformación, y permanecer activo. Puede pensar en ellos como depósitos de S3, pero en lugar de cargarlos y descargarlos, verifica una rama y sus archivos están allí.
Se recomienda siempre comprometerse (cargar) con el crudo rama. Estos crean una fuente de verdad, un lugar nunca editado ni eliminado, por lo que siempre podemos rastrear de dónde provienen y pasan los datos. También permite crear nuevos flujos fácilmente, auditoría e institutriz.
💡 Si agrega un mensaje de confirmación de dónde provienen los datos, puede obtener una observabilidad aún más granular de sus datos.
Puedes usar otro limpio rama donde solo existen datos limpios. Por ejemplo, imágenes rotas o archivos de texto vacíos que se cargaron en el rama cruda no aparecen en el limpio rama.
A dividir La rama donde se dividen los datos para capacitación, validación y pruebas puede garantizar que todos los equipos y colaboradores trabajen en el mismo campo de juego.
Este enfoque ayuda a prevenir la fuga de datos y permite una colaboración e ingeniería de funciones más sólidas. Minimizar la posibilidad de que se incluyan ejemplos del conjunto de pruebas en las etapas de capacitación reduce el riesgo de introducir sesgos. Además, tener todos los colaboradores en la misma división garantiza resultados consistentes e imparciales en un experimento.
En un proyecto de clasificación anterior, formé parte de un equipo de contribuyentes individuales donde cada persona manejaba todo el proceso desde cero; Cada uno de nosotros había utilizado diferentes porcentajes de división de datos y semillas, lo que llevó a modelos más débiles en producción debido a errores y sesgos en los datos.
💡 Consejo de aprendizaje automático: las mejores prácticas de desarrollo de modelos en tres fases
Utilizamos los conjuntos de datos de “entrenamiento” y “validación” para entrenar y optimizar los hiperparámetros del modelo. Luego usamos train plus validation como conjunto de entrenamiento para entrenar nuestro modelo sintonizado y evaluarlo con el conjunto de datos de prueba. sólo una vez. Por último, entrenamos el modelo con todos los datos y lo guardamos como nuestro modelo.
Estas ramas son activo sucursales para entrenamiento e inferencia. Aquí puede ejecutar su entrenamiento, guardar su modelo, puntos de control y tarjeta de modelo, ejecutar pruebas, crear y probar la imagen de Docker, confirmar todo al final de un ciclo de entrenamiento y luego Etiqueta. Deberían ser capaces de manejar la recuperación de nuevos datos y el reentrenamiento. Aquí es donde tiene lugar la automatización.
⚠️ No se escribe ningún código en estas ramas.
Esto garantiza que un modelo esté acoplado con los datos con los que se entrenó, el código utilizado para entrenarlo y ejecutarlo en producción (incluida la ingeniería de funciones) y las métricas de resultados. Todos estos componentes se combinan en una única “instantánea” unificada. Cada vez que revisas una etiqueta, todas las piezas necesarias para ese modelo están presentes.
💡 Consejo: Al elegir el nombre de la etiqueta con anticipación, puede agregar información de seguimiento durante el entrenamiento como parámetro. Esto garantiza que siempre pueda recuperar la “instantánea” del código de datos del modelo dados los datos de seguimiento utilizando cualquier herramienta de seguimiento.
Después del entrenamiento, solo los datos de seguimiento se fusionan (copian) en su principal sucursal para seguimiento.
En el caso más simple, puede ser un archivo de texto JSON que contiene los hiperparámetros y los resultados de la evaluación. Este archivo luego se agrega a una lista en el principal rama. En el caso de MLflow, implica copiar los experimentos del carpeta mlruns hacia principal rama.
Estas ramas son para desarrollo de código y exploración de datos, entrenando con datos pequeños o muestreados hasta que tenga un programa de trabajo. Mientras desarrolla, puede utilizar todas las mejores prácticas de Git. Sin embargo, sólo diríjase a un establesucursal cuando no se requieren más cambios en el código, incluso si se obtienen datos adicionales. Estas ramas Debería incluir el código de inferencia, el servidor, el Dockerfile y las pruebas.
Siempre hay al menos una rama de desarrollo que permanece activadonde se fusionan todas las funciones nuevas, correcciones de errores y otros cambios.
💡 Los ingenieros de ML y MLOps pueden colaborar en los aspectos de capacitación e inferencia.
Por ejemplo, puedes crear un desarrollador/modelo sucursal donde desarrollas una base modelo. Esta puede ser la clase más popular para la clasificación o la media/mediana para la regresión. La atención se centra en configurar el código y al mismo tiempo comprender a fondo sus datos.
Cuando es estable y pasan las pruebas, nos expandimos a establo/modelo donde entrenamos y confirmamos el modelo, el código y los datos juntos en forma remota y etiqueta ese compromiso. Esto es rápido y fácil de compartir y permitirá a los equipos de DevOps, backend y frontend iniciar el desarrollo e intercambiar comentarios. También facilitará la validación de los requisitos recién descubiertos en un entorno del mundo real lo antes posible.
A continuación, desarrollamos el modelo sobre el desarrollador/modelo ramificar a un modelo sencillo como la regresión lineal, y cuando esté listo y las pruebas pasen, podemos fusionarlo para establo/modelo donde entrenamos, comprometemos y etiquetamos un lanzamiento para pinchar.
Este enfoque le brinda la libertad de mejorar incrementalmente su modelo mientras preserva el contexto completo de los modelos anteriores en la rama estable.
A partir de este punto tenemos tres opciones:
- Podemos volver a entrenar cuando llegan más datos extrayendo datos a la rama estable.
- Podemos empezar experimentación usando ingeniería de características en el desarrollo/regresión lineal rama.
- Podemos crear un nuevo desarrollo/nuevo-enfoque rama para modelos más sofisticados.
En el monitoreo de modelos nos preocupamos por la distribución de datos, los valores atípicos y las distribuciones de predicción.
En el supervisión rama, guardamos los datos consultados, la etiqueta de confirmación y la predicción del modelo de prod como archivos.
💡 Puede utilizar varias ramas de monitoreo para cada entorno: desarrollo, estable y producción.
Podemos configurar alertas sobre confirmaciones de datos para probar deriva en cualquier distribución de características, valores atípicos, calibración prueba de cordura y guarda el código de alertas; esto permite soluciones más avanzadas, como un modelo de detección de valores atípicos, ya que también podemos guardar el modelo en esta rama.
Por lo general, esta rama podría pertenecer a otro proyecto que esté desacoplado del código responsable de crear los registros de monitoreo, así como de los datos y el modelo que los generó.
La ciencia y el análisis de datos es otro aspecto del proyecto que a menudo se separa en un proyecto diferente. Aquí es donde se recopilan el código de análisis y los datos no relacionados con la capacitación de los científicos de datos.
Un científico de datos puede verificar y extraer datos del supervisión rama para ejecutar análisis, pruebas A/B y otros experimentos en línea y fuera de línea. También pueden utilizar datos de la crudo sucursal para estos efectos.
Los ejemplos en línea son más sencillos, ya que cada grupo de experimentos corresponde a una rama.
💡 Consejo: experimentos comunes en línea:
prueba directa– Comparando el modelo actual 99% versus un modelo candidato 1%.
Prueba retrospectiva — después de fusionar un nuevo modelo, mantener el 1% en el modelo anterior para validar el efecto esperado a la inversa.
Tener la etiqueta del modelo como parámetro en los datos de monitoreo le ayuda a identificar cada cambio en la posible causa de la métrica.