Aprendizado de máquina industrial: 10 princípios de design
Hoje em dia, todos os dias, novos serviços, aplicativos e outros programas importantes são criados que permitem criar coisas incríveis: desde software para controlar um foguete SpaceX até interagir com uma chaleira na sala ao lado através de um smartphone.
E, às vezes, todo programador novato, seja ele um iniciante apaixonado ou um Full Stack ou Cientista de Dados comum, mais cedo ou mais tarde percebe que existem certas regras para programar e criar software que simplificam muito a vida.
Neste artigo, descreverei brevemente 10 princípios de como programar o aprendizado de máquina industrial para que ele possa ser facilmente integrado em um aplicativo / serviço, com base na metodologia App de 12 fatores proposta pela equipe do Heroku.... Minha iniciativa é aumentar o conhecimento desta técnica, que pode ajudar muitos desenvolvedores e pessoas da Ciência de Dados.
Este artigo é o prólogo de uma série de artigos sobre Aprendizado de Máquina Industrial. Neles, continuarei falando sobre como, de fato, fazer um modelo e executá-lo em produção, criar uma API para ele, além de exemplos de várias áreas e empresas que possuem ML embutido em seus sistemas.
Princípio 1. Uma base de código
Alguns programadores se esquecem do Git nos estágios iniciais por causa da preguiça de descobrir (ou por algum motivo). Eles se esquecem completamente da palavra, ou seja, jogam arquivos uns para os outros no drive / apenas jogam texto / mandam pombos, ou não pensam sobre seu fluxo de trabalho, e cada um se compromete com seu próprio branch e depois com o mestre.
Este princípio diz: tenha uma base de código e muitas implantações.
O Git pode ser usado tanto em produção quanto em pesquisa e desenvolvimento (P&D), onde é usado com menos frequência.
Por exemplo, na fase de P&D, você pode deixar commits com diferentes métodos e modelos de processamento de dados, a fim de escolher o melhor e continuar trabalhando facilmente com ele.
Em segundo lugar, na produção, isso é algo insubstituível - você precisará observar constantemente como seu código muda e saber qual modelo deu os melhores resultados, qual código funcionou no final e o que aconteceu, por causa do que parou de funcionar ou começou a emitir resultados incorretos. É para isso que servem os commits!
E também você pode criar um pacote do seu projeto colocando-o, por exemplo, no Gemfury, e então simplesmente importando funções dele para outros projetos, de modo a não reescrevê-los 1000 vezes, mas mais sobre isso depois.
Princípio 2. Declare e isole claramente as dependências
Cada projeto tem diferentes bibliotecas que você importa de fora para aplicá-las em algum lugar. Sejam bibliotecas Python ou bibliotecas de outras linguagens para diferentes fins ou ferramentas do sistema - sua tarefa é:
- dependencies, , , , , (, Python Pipfile requirements.txt. , : realpython.com/pipenv-guide)
- dependencies . , , Tensorflow?
Assim, os desenvolvedores que futuramente se juntarão à sua equipe poderão se familiarizar rapidamente com as bibliotecas e suas versões que são utilizadas em seu projeto, bem como você poderá controlar as versões e as próprias bibliotecas instaladas para um projeto específico, o que o ajudará a evitar incompatibilidade de bibliotecas ou de suas versões.
Seu aplicativo também não precisa depender de ferramentas de sistema que podem estar instaladas em um determinado sistema operacional. Essas ferramentas também devem ser declaradas no manifesto de dependências. Isso é necessário para evitar situações em que a versão das ferramentas (bem como sua disponibilidade) não corresponde às ferramentas do sistema de um determinado sistema operacional.
Assim, mesmo que curl possa ser usado em quase todos os computadores, você ainda deve declará-lo nas dependências, pois ao migrar para outra plataforma ele pode não existir ou a versão não será a que você originalmente precisava.
Por exemplo, seu requirements.txt pode ter a seguinte aparência:
# 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
Princípio 3. Configurações
Muitos já ouviram histórias em que vários desenvolvedores acidentalmente carregaram código para o GitHub em repositórios abertos com senhas e outras chaves da AWS, acordando no dia seguinte com uma dívida de $ 6.000, ou mesmo com todos os $ 50.000.
Claro, esses casos são extremos, mas muito reveladores. Se você armazena suas credenciais ou outros dados necessários para configuração dentro do código, está cometendo um erro e não vale a pena explicar o porquê.
Uma alternativa é armazenar configurações em variáveis de ambiente. Você pode ler mais sobre variáveis de ambiente aqui .
Exemplos de dados que geralmente são armazenados em variáveis de ambiente:
- Nomes de domínio
- URL / URI da API
- Chaves públicas e privadas
- Contatos (e-mail, telefones, etc.)
Dessa forma, você não precisa mudar constantemente o código se suas variáveis de configuração mudarem. Isso vai economizar tempo, esforço e dinheiro.
Por exemplo, se você usar a API Kaggle para realizar testes (por exemplo, você baixa e executa o modelo por meio dela para testar se o modelo funciona bem na inicialização), as chaves privadas do Kaggle, como KAGGLE_USERNAME e KAGGLE_KEY, devem ser armazenadas em variáveis de ambiente.
Princípio 4: Serviços de terceiros
A ideia aqui é projetar o programa de forma que não haja distinção entre recursos locais e de terceiros em termos de código. Por exemplo, você pode conectar MySQL local e de terceiros. O mesmo vale para várias APIs como Google Maps ou Twitter API.
Para desabilitar um serviço de terceiros ou conectar outro, basta alterar as chaves de configuração nas variáveis de ambiente, de que falei no parágrafo anterior.
Assim, por exemplo, em vez de especificar cada vez que o caminho para os arquivos com conjuntos de dados dentro do código, é melhor usar a biblioteca pathlib e declarar o caminho para os conjuntos de dados em config.py, de modo que não importa qual serviço você use (por exemplo, CircleCI), o programa conseguiu descobrir o caminho para os conjuntos de dados, levando em consideração a estrutura do novo sistema de arquivos no novo serviço.
Princípio 5. Construir, liberar, tempo de execução
Muitas pessoas da Data Science consideram útil aprender as habilidades de escrita de software. Se quisermos que nosso programa trave o menos possível e funcione sem problemas pelo maior tempo possível, precisamos dividir o processo de lançamento da nova versão em 3 fases:
- . , . .
- — config, . .
- . .
Esse sistema de liberação de novas versões de um modelo ou de todo o pipeline permite a divisão de funções entre administradores e desenvolvedores, permite rastrear versões e evita interrupções indesejadas do programa.
Para a tarefa de lançamento, muitos serviços diferentes foram criados nos quais você pode gravar processos para executar você mesmo em um arquivo .yml (por exemplo, em CircleCI é config.yml para suportar o próprio processo). Wheely é excelente na criação de pacotes para projetos.
Você poderá criar pacotes com diferentes versões de seu modelo de aprendizado de máquina e, em seguida, empacotá-los e consultar os pacotes necessários e suas versões para usar as funções que você escreveu a partir daí. Isso ajudará você a criar uma API para seu modelo, e seu pacote pode ser colocado no Gemfury, por exemplo.
Princípio 6. Executamos seu modelo como um ou vários processos
Além disso, os processos não devem ter dados compartilhados. Ou seja, os processos devem existir separadamente e todos os tipos de dados devem existir separadamente, por exemplo, em serviços de terceiros como MySQL ou outros, dependendo do que você precisa.
Ou seja, definitivamente não vale a pena armazenar dados dentro do sistema de arquivos do processo, caso contrário pode levar à limpeza desses dados na próxima liberação / alteração de configurações ou transferência do sistema em que o programa está sendo executado.
Mas há uma exceção: para projetos de aprendizado de máquina, você pode armazenar o cache da biblioteca de modo que não os reinstale sempre que iniciar uma nova versão, se nenhuma biblioteca adicional ou qualquer alteração em suas versões tiver sido feita. Assim, você reduzirá o tempo de lançamento de seu modelo no setor.
Para executar o modelo como vários processos, você pode criar um arquivo .yml no qual você apenas especifica os processos necessários e sua sequência.
Princípio 7: Reciclabilidade
Os processos que executam o modelo em seu aplicativo devem ser fáceis de iniciar e parar. Assim, permitirá que você implemente rapidamente mudanças de código, mudanças de configuração, dimensione com rapidez e flexibilidade e evite possíveis interrupções da versão de trabalho.
Ou seja, seu processo com um modelo deve:
- . ( , , ) . , — .
- . , , , . DevOps , , (, , , , !)
Princípio 8: Implantação / Integração Contínua
Muitas empresas usam a separação entre as equipes de desenvolvimento e implantação de aplicativos (disponibilizando o aplicativo para os usuários finais). Isso pode retardar muito o desenvolvimento de software e o progresso em direção a melhorá-lo. Isso também estraga a cultura DevOps, onde desenvolvimento e integração são praticamente combinados.
Portanto, esse princípio afirma que seu ambiente de desenvolvimento deve ser o mais próximo possível do ambiente de produção.
Isso permitirá:
- Reduza o tempo de liberação dez vezes
- Reduza o número de erros devido à incompatibilidade de código.
- Isso também reduz a carga sobre a equipe, já que os desenvolvedores e as pessoas que implantam o aplicativo agora são uma equipe.
As ferramentas que permitem que você trabalhe com isso são CircleCI, Travis CI, GitLab CI e outras.
Você pode fazer adições ao modelo rapidamente, atualizá-lo e iniciá-lo imediatamente, enquanto será fácil, em caso de falhas, retornar rapidamente à versão de trabalho sem que o usuário final perceba. Isso pode ser feito de maneira especialmente rápida e fácil se você tiver bons testes.
Minimize as diferenças !!!
Princípio 9. Seus registros
Logs (ou "Logs") são eventos registrados, geralmente em formato de texto, que ocorrem dentro do aplicativo (fluxo de eventos). Exemplo simples: "2020-02-02 - nível do sistema - nome do processo". Eles são projetados para que o desenvolvedor possa literalmente ver o que acontece quando o programa está sendo executado. Ele vê o andamento dos processos e entende se é como o próprio desenvolvedor pretendia.
Este princípio diz que você não deve armazenar seus logs dentro de seu sistema de arquivos - você só precisa "exibi-los", por exemplo, faça isso na saída padrão do sistema stdout. E assim o fluxo pode ser monitorado no terminal durante o desenvolvimento.
Isso significa que você não precisa salvar os logs? Claro que não. Acontece que seu aplicativo não deveria fazer isso - deixe isso para serviços de terceiros. Seu aplicativo só pode redirecionar os logs para um arquivo ou terminal específico para visualização ao vivo, ou redirecioná-lo para um sistema de armazenamento de uso geral (como Hadoop). Seu aplicativo em si não deve armazenar ou interagir com os logs.
Princípio 10. Teste!
Para o aprendizado de máquina industrial, esta fase é extremamente importante, pois você precisa entender que o modelo está funcionando corretamente e dá o que você deseja.
Os testes podem ser criados com o pytest e testados com um pequeno conjunto de dados se você tiver uma tarefa de regressão / classificação.
Não se esqueça de definir a mesma semente para modelos de aprendizado profundo, para que eles não produzam resultados diferentes constantemente.
Esta foi uma breve descrição de 10 princípios e, claro, é difícil usá-los sem tentar e ver como eles funcionam, então este artigo é apenas um prólogo para uma série de artigos interessantes nos quais revelarei como criar modelos de aprendizado de máquina industrial. como integrá-los aos sistemas e como esses princípios podem tornar a vida mais fácil para todos nós.
Também tentarei usar algumas diretrizes legais que alguém pode deixar nos comentários se quiser.