Estás listo para implementar. Si solo implementar un modelo fuera tan fácil como presionar un botón rojo grande Cuando implementas, deseas que tu canalización se ejecute, se actualice y se publique sin problemas. Estas necesidades conducen a los requisitos y las soluciones que se analizan en esta página.
Cómo probar actualizaciones de modelos con entrenamiento reproducible
No hay duda de que quieres seguir mejorando el predictor de la apariencia de tu unicornio. Supongamos que refactorizas el código de ingeniería de atributos para la función de “hora del día”. ¿Cómo se prueba que el código sea correcto? Decides volver a entrenar tu modelo y ver si obtienes el mismo resultado. El entrenamiento de tu modelo no es reproducible. Para seguir prediciendo las apariencias de los unicornios, debes seguir investigando. Descubre que puedes lograr la reproducibilidad si sigues estos pasos:
Genera de forma determinista el generador de números al azar (RNG). Para obtener más información, consulta aleatorización en la generación de datos del curso Preparación de datos e ingeniería de atributos en AA.
Inicializa los componentes del modelo en un orden fijo para asegurarte de que los componentes obtengan el mismo número aleatorio del RNG en cada ejecución. Por lo general, las bibliotecas de AA controlan este requisito de forma automática.
Promedio de varias ejecuciones del modelo
Usa el control de versión, incluso para las iteraciones preliminares, de modo que puedas identificar el código y los parámetros cuando investigues el modelo o la canalización.
Incluso después de seguir estos pasos, podrías tener otras fuentes de no determinismo.
Prueba actualizaciones del modelo para especificaciones y llamadas a la API
Después de actualizar tu modelo a Unicorn Predictor 2.0, debes probar el modelo nuevo para verificar que sea correcto y algorítmico, junto con los cambios en las llamadas a la API. Analicemos cómo.
Prueba de llamadas a la API
¿Cómo se prueban las actualizaciones de las llamadas a la API? Por supuesto, podría volver a entrenar su modelo, pero eso requiere mucho tiempo. En su lugar, escribe una prueba de unidades para generar datos de entrada aleatorios y ejecutar un solo paso de descenso de gradientes. Deseas que el paso se complete sin errores de entorno de ejecución.
Prueba de corrección algorítmica
Un modelo no solo debe predecir de forma correcta, sino que lo hace porque es acertadamente algorítmico, no tiene suerte. Por ejemplo, si el 99% de los correos electrónicos no son spam, la clasificación de todo el correo electrónico como no es spam obtiene un 99% de exactitud por azar. Por lo tanto, debes verificar que el modelo sea correcto. Sigue estos pasos:
- Entrena tu modelo para algunas iteraciones y verifica que la pérdida disminuya.
- Entrena tu algoritmo sin regularización. Si tu modelo es lo suficientemente complejo, memorizará los datos de entrenamiento y tu pérdida de entrenamiento será cercana a 0.
- Prueba subcomputaciones específicas de tu algoritmo. Por ejemplo, puedes probar que una parte de tu RNN se ejecute una vez por elemento de los datos de entrada.
Escribir pruebas de integración para componentes de canalización
En una canalización de AA, los cambios en un componente pueden causar errores en otros. Verifica que los componentes funcionen juntos mediante la escritura de una prueba que ejecute toda la canalización de extremo a extremo. Este tipo de prueba se denomina prueba de integración.
Además de ejecutar pruebas de integración de forma continua, debes ejecutarlas cuando envíes modelos nuevos y versiones de software nuevas. La lentitud de la ejecución de toda la canalización dificulta las pruebas de integración continua. Para ejecutar pruebas de integración más rápido, entrena en un subconjunto de los datos o con un modelo más simple. Los detalles dependen de tu modelo y tus datos. Para obtener una cobertura continua, debes ajustar las pruebas más rápidas a fin de que se ejecuten con cada versión nueva del modelo o software. Mientras tanto, tus pruebas lentas se ejecutarían de manera continua en segundo plano.
Valida la calidad del modelo antes de la publicación
Antes de enviar una nueva versión del modelo a producción, prueba estos dos tipos de degradaciones de calidad:
Degradación repentina: un error en la versión nueva podría causar una calidad mucho menor. Valida las versiones nuevas mediante la comparación de su calidad con la versión anterior.
Degradación lenta: la prueba de degradación repentina puede no detectar una degradación lenta en la calidad del modelo en varias versiones. En su lugar, asegúrate de que las predicciones de tu modelo en un conjunto de datos de validación cumplan con un umbral fijo. Si tu conjunto de datos de validación se desvía de los datos activos, actualízalo y asegúrate de que tu modelo siga cumpliendo con el mismo umbral de calidad.
Validar la compatibilidad de la infraestructura modelo antes de la entrega
Si el modelo se actualiza más rápido que el servidor, tendrá dependencias de software diferentes a las del servidor, lo que podría causar incompatibilidades. Asegúrate de que las operaciones que usa el modelo estén presentes en el servidor mediante la etapa de pruebas del modelo en una versión de zona de pruebas del servidor.