Aprendizaxe da máquina industrial: 10 principios de deseño
Hoxe en día, cada día créanse novos servizos, aplicacións e outros programas importantes que permiten crear cousas incribles: desde software para controlar un foguete SpaceX ata interactuar cunha caldeira da habitación contigua a través dun teléfono intelixente.
E, ás veces, todo programador novato, xa sexa un principiante apaixonado ou un Full Stack ou Data Scientist común, tarde ou cedo decátase de que hai certas regras para programar e crear software que simplifican moito a vida.
Neste artigo, describirei brevemente 10 principios de como programar a aprendizaxe automática industrial para que poida integrarse facilmente nunha aplicación/servizo, baseado na metodoloxía de aplicacións de 12 factores. . A miña iniciativa é aumentar a conciencia desta técnica, que pode axudar a moitos desenvolvedores e persoas de ciencia de datos.
Este artigo é un prólogo dunha serie de artigos sobre Machine Learning industrial. Neles falarei aínda máis sobre como facer un modelo e poñelo en produción, crear unha API para el, así como exemplos de varias áreas e empresas que teñen ML incorporado nos seus sistemas.
Principio 1: un código base
Algúns programadores nas primeiras etapas, por preguiza de descubrilo (ou por algún motivo propio), esquécense de Git. Ou ben esquecen completamente a palabra, é dicir, lánzanse ficheiros uns aos outros na unidade/só botan texto/envían as pombas, ou non pensan no seu fluxo de traballo e comprometen cada un á súa propia rama e despois ao mestre.
Este principio establece: ten unha base de código e moitas implementacións.
Git pódese utilizar tanto na produción como na investigación e desenvolvemento (I+D), nos que non se usa con tanta frecuencia.
Por exemplo, na fase de I+D podes deixar commits con diferentes métodos e modelos de procesamento de datos, para despois seleccionar o mellor e seguir traballando máis facilmente con el.
En segundo lugar, na produción isto é algo insubstituíble: terás que mirar constantemente como cambia o teu código e saber que modelo deu os mellores resultados, que código funcionou ao final e que pasou que fixo que deixase de funcionar ou comece a producir resultados incorrectos. . Para iso están os compromisos!
Tamén podes crear un paquete do teu proxecto, colocándoo, por exemplo, en Gemfury, e despois simplemente importando funcións del para outros proxectos, para non reescribilos 1000 veces, pero sobre iso máis tarde.
Principio 2: Declarar e illar con claridade as dependencias
Cada proxecto ten diferentes bibliotecas que importas desde fóra para aplicalas nalgún lugar. Tanto se se trata de bibliotecas Python, como de bibliotecas doutros idiomas para varios fins ou de ferramentas do sistema, a túa tarefa é:
- Declara claramente as dependencias, é dicir, un ficheiro que conterá todas as bibliotecas, ferramentas e as súas versións que se usan no teu proxecto e que deben instalarse (por exemplo, en Python pódese facer mediante Pipfile ou requirements.txt. A ligazón que permite entender ben: )
- Illa dependencias específicamente para o teu programa durante o desenvolvemento. Non queres cambiar constantemente as versións e reinstalar, por exemplo, Tensorflow?
Deste xeito, os desenvolvedores que se unirán ao teu equipo no futuro poderán familiarizarse rapidamente coas bibliotecas e as súas versións que se usan no teu proxecto, e tamén terás a oportunidade de xestionar as propias versións e bibliotecas instaladas para un determinado programa. proxecto, o que axudará a evitar a incompatibilidade das bibliotecas ou das súas versións.
A súa aplicación tampouco debería depender das ferramentas do sistema que se poidan instalar nun sistema operativo específico. Estas ferramentas tamén deben ser declaradas no manifesto de dependencias. Isto é necesario para evitar situacións nas que a versión das ferramentas (así como a súa dispoñibilidade) non coincida coas ferramentas do sistema dun sistema operativo en particular.
Así, aínda que curl se poida usar en case todos os ordenadores, aínda debes declaralo en dependencias, xa que ao migrar a outra plataforma pode que non estea ou a versión non será a que necesitabas orixinalmente.
Por exemplo, o teu requirements.txt pode verse así:
# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0
# testing requirements
pytest>=5.3.2,<6.0.0
# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0
# fetching datasets
kaggle>=1.5.6,<1.6.0
Principio 3: Configuracións
Moitos escoitaron historias de varios desenvolvedores que cargaron accidentalmente código a GitHub en repositorios públicos con contrasinais e outras claves de AWS, e espertaron ao día seguinte cunha débeda de 6000 dólares ou mesmo de 50000 dólares.
Por suposto, estes casos son extremos, pero moi significativos. Se almacenas as túas credenciais ou outros datos necesarios para a configuración dentro do código, estás a cometer un erro e creo que non hai que explicar por que.
Unha alternativa a isto é almacenar configuracións en variables de ambiente. Podes ler máis sobre as variables de ambiente .
Exemplos de datos que normalmente se almacenan en variables de ambiente:
- Nomes de dominio
- URL/URI de API
- Claves públicas e privadas
- Contactos (correo, teléfonos, etc.)
Deste xeito, non tes que cambiar constantemente o código se as túas variables de configuración cambian. Isto axudaralle a aforrar tempo, esforzo e diñeiro.
Por exemplo, se usa a API de Kaggle para realizar probas (por exemplo, descargar o software e executar o modelo a través del para comprobar cando se executa o modelo funciona ben), as claves privadas de Kaggle, como KAGGLE_USERNAME e KAGGLE_KEY, deberían ser almacenadas en variables de ambiente.
Principio 4: Servizos de terceiros
A idea aquí é crear o programa de forma que non haxa diferenzas entre os recursos locais e de terceiros en termos de código. Por exemplo, pode conectar tanto MySQL local como outros de terceiros. O mesmo ocorre con varias API como Google Maps ou Twitter API.
Para desactivar un servizo de terceiros ou conectar outro, só tes que cambiar as claves na configuración nas variables de ambiente, do que falei no parágrafo anterior.
Así, por exemplo, en lugar de especificar a ruta aos ficheiros con conxuntos de datos dentro do código cada vez, é mellor usar a biblioteca pathlib e declarar a ruta aos conxuntos de datos en config.py, de xeito que non importa o servizo que utilice (para exemplo, CircleCI), o programa puido descubrir o camiño aos conxuntos de datos tendo en conta a estrutura do novo sistema de ficheiros no novo servizo.
Principio 5. Construír, lanzar, tempo de execución
Moitas persoas en Data Science consideran útil mellorar as súas habilidades de escritura de software. Se queremos que o noso programa falle o menos posible e funcione sen fallos o maior tempo posible, debemos dividir o proceso de lanzamento dunha nova versión en 3 etapas:
- Etapa asembleas. Transformas o teu código básico con recursos individuais nun chamado paquete que contén todo o código e os datos necesarios. Este paquete chámase montaxe.
- Etapa liberación — aquí conectamos a nosa configuración á montaxe, sen a cal non poderiamos lanzar o noso programa. Agora esta é unha versión completamente lista para o lanzamento.
- A continuación vén o escenario cumprimento. Aquí liberamos a aplicación executando os procesos necesarios da nosa versión.
Este sistema para lanzar novas versións dun modelo ou de todo o pipeline permítelle separar os roles entre administradores e desenvolvedores, permítelle rastrexar versións e evita paradas non desexadas do programa.
Para a tarefa de lanzamento, creáronse moitos servizos diferentes nos que pode escribir procesos para executarse nun ficheiro .yml (por exemplo, en CircleCI isto é config.yml para soportar o propio proceso). Wheely é xenial para crear paquetes para proxectos.
Podes crear paquetes con diferentes versións do teu modelo de aprendizaxe automática e, a continuación, empaquetalos e consultar os paquetes necesarios e as súas versións para usar as funcións que escribiches desde alí. Isto axudarache a crear unha API para o teu modelo e o teu paquete pódese aloxar en Gemfury, por exemplo.
Principio 6. Executar o seu modelo como un ou máis procesos
Ademais, os procesos non deberían ter datos compartidos. É dicir, os procesos deben existir por separado, e todo tipo de datos deben existir por separado, por exemplo, en servizos de terceiros como MySQL ou outros, dependendo do que necesites.
É dicir, definitivamente non paga a pena almacenar datos dentro do sistema de ficheiros do proceso, se non, isto pode levar a borrar estes datos durante a próxima versión/cambio de configuracións ou transferencia do sistema no que se executa o programa.
Pero hai unha excepción: para os proxectos de aprendizaxe automática, podes almacenar unha caché de bibliotecas para non reinstalalas cada vez que lances unha nova versión, se non se realizaron bibliotecas adicionais nin se fixeron cambios nas súas versións. Deste xeito, reducirás o tempo que leva lanzar o teu modelo na industria.
Para executar o modelo como varios procesos, pode crear un ficheiro .yml no que especifique os procesos necesarios e a súa secuencia.
Principio 7: reciclabilidade
Os procesos que se executan na súa aplicación modelo deberían ser fáciles de iniciar e deter. Así, isto permitirá implementar rapidamente cambios de código, cambios de configuración, escalar de forma rápida e flexible e evitar posibles avarías da versión de traballo.
É dicir, o seu proceso co modelo debería:
- Minimizar o tempo de inicio. Idealmente, o tempo de inicio (desde o momento en que se emitiu o comando de inicio ata o momento en que o proceso entra en funcionamento) non debería ser superior a uns segundos. A caché da biblioteca, descrita anteriormente, é unha técnica para reducir o tempo de inicio.
- Rematar correctamente. É dicir, a escoita no porto de servizo está realmente suspendida e non se procesarán as novas solicitudes enviadas a este porto. Aquí tes que establecer unha boa comunicación cos enxeñeiros de DevOps ou comprender como funciona ti mesmo (preferiblemente, por suposto, este último, pero a comunicación debe manterse sempre, en calquera proxecto!)
Principio 8: Implementación/Integración continua
Moitas empresas usan unha separación entre os equipos de desenvolvemento e implantación de aplicacións (poñendo a aplicación dispoñible para os usuarios finais). Isto pode ralentizar moito o desenvolvemento do software e avanzar na súa mellora. Tamén estraga a cultura DevOps, onde o desenvolvemento e a integración se combinan, grosso modo.
Polo tanto, este principio indica que o seu ambiente de desenvolvemento debe estar o máis próximo posible ao seu ambiente de produción.
Isto permitirá:
- Reduce o tempo de liberación en decenas de veces
- Reducir o número de erros debido á incompatibilidade do código.
- Isto tamén reduce a carga de traballo do persoal, xa que os desenvolvedores e as persoas que implementan a aplicación son agora un só equipo.
As ferramentas que che permiten traballar con isto son CircleCI, Travis CI, GitLab CI e outras.
Podes engadir rapidamente o modelo, actualizalo e lanzalo de inmediato, mentres que será doado, en caso de fallos, volver moi rapidamente á versión de traballo, para que o usuario final nin sequera o note. Isto pódese facer de xeito especialmente sinxelo e rápido se tes boas probas.
Minimizar as diferenzas!!!
Principio 9. Os teus rexistros
Os rexistros (ou "Rexistros") son eventos, normalmente rexistrados en formato de texto, que ocorren dentro da aplicación (fluxo de eventos). Un exemplo sinxelo: "2020-02-02 - nivel do sistema - nome do proceso". Están deseñados para que o programador poida ver literalmente o que está a suceder cando se está a executar o programa. Ve o progreso dos procesos e comprende se é como pretendía o propio desenvolvedor.
Este principio indica que non debes almacenar os teus rexistros dentro do teu sistema de ficheiros; só debes "saír" a pantalla, por exemplo, facelo na saída estándar do sistema. E deste xeito será posible controlar o fluxo no terminal durante o desenvolvemento.
Significa isto que non hai que gardar os rexistros en absoluto? Por suposto que non. A túa aplicación simplemente non debería facelo, deixalo a servizos de terceiros. A túa aplicación só pode reenviar rexistros a un ficheiro ou terminal específico para a súa visualización en tempo real, ou reenvialos a un sistema de almacenamento de datos de propósito xeral (como Hadoop). A súa propia aplicación non debería almacenar nin interactuar cos rexistros.
Principio 10. Proba!
Para a aprendizaxe automática industrial, esta fase é extremadamente importante, xa que cómpre entender que o modelo funciona correctamente e produce o que querías.
As probas pódense crear mediante pytest e probar cun pequeno conxunto de datos se tes unha tarefa de regresión/clasificación.
Non esquezas establecer a mesma semente para os modelos de aprendizaxe profunda para que non produzan resultados diferentes constantemente.
Esta foi unha breve descrición dos 10 principios e, por suposto, é difícil usalos sen probar e ver como funcionan, polo que este artigo é só un prólogo dunha serie de artigos interesantes nos que desvelarei como crear modelos de aprendizaxe de máquinas industriais, como integralos nos sistemas e como estes principios poden facilitarnos a vida a todos.
Tamén tentarei usar principios interesantes que calquera pode deixar nos comentarios se o desexa.
Fonte: www.habr.com