Os projetos de ML exigem equipes com membros que tenham uma variedade de habilidades, conhecimentos e responsabilidades relacionadas ao aprendizado de máquina. Estes são os papéis mais comuns em equipes de ML típicas:
| Papel | Conhecimentos e habilidades | Resultado principal |
|---|---|---|
| Gerente de produtos de ML | Os gerentes de produtos de ML têm um conhecimento profundo dos pontos fortes e fracos do ML e do processo de desenvolvimento de ML. Eles alinham problemas de negócios a soluções de ML trabalhando diretamente com a equipe de ML, usuários finais e outras partes interessadas. Eles criam a visão do produto, definem casos de uso e requisitos e planejam e priorizam projetos. |
Documento de requisitos do produto (PRD, na sigla em inglês). |
| Gerente de engenharia | Os gerentes de engenharia alcançam as metas de negócios definindo, comunicando e cumprindo as prioridades da equipe. Assim como os gerentes de produto de ML, eles alinham as soluções de ML aos problemas de negócios. Eles definem expectativas claras para os membros da equipe, conduzem avaliações de desempenho e ajudam no desenvolvimento de carreira e profissional. |
Documentos de design, planos de projeto e avaliações de desempenho. |
| Cientista de dados | Os cientistas de dados usam análises quantitativas e estatísticas para extrair insights e valor dos dados. Eles ajudam a identificar e testar recursos, modelos de protótipo e a interpretabilidade do modelo. | Relatórios e visualizações de dados que respondem a perguntas de negócios por meio de análise estatística. |
| Engenheiros de ML | Os engenheiros de ML projetam, criam, colocam em produção e gerenciam modelos de ML. Eles são engenheiros de software fortes com um profundo entendimento das tecnologias de ML e das práticas recomendadas. | Modelo implantado com qualidade de previsão suficiente para atender às metas de negócios. |
| Engenheiro de dados | Engenheiros de dados criam pipelines de dados para armazenar, agregar e processar grandes quantidades de dados. Eles desenvolvem a infraestrutura e os sistemas para coletar e transformar dados brutos em formatos úteis para treinamento e fornecimento de modelos. Os engenheiros de dados são responsáveis pelos dados em todo o processo de desenvolvimento de ML. | Pipelines de dados totalmente produzidos com o monitoramento e os alertas necessários. |
| Engenheiro de operações de desenvolvimento (DevOps) | Os engenheiros de DevOps desenvolvem, implantam, dimensionam e monitoram a infraestrutura de disponibilização de modelos de ML. | Um processo automatizado para exibir, monitorar, testar e alertar sobre o comportamento de um modelo. |
Projetos de ML bem-sucedidos têm equipes com cada função bem representada. Em equipes menores, os indivíduos precisam lidar com as responsabilidades de várias funções.
Estabelecer práticas de equipe
Como as funções, ferramentas e frameworks variam muito no desenvolvimento de ML, é fundamental estabelecer práticas comuns com uma excelente documentação de processo. Por exemplo, um engenheiro pode achar que apenas coletar os dados certos é suficiente para começar a treinar um modelo, enquanto um engenheiro mais responsável vai validar se o conjunto de dados está anonimizado corretamente e documentar os metadados e a procedência dele. Garantir que os engenheiros compartilhem definições comuns de processos e padrões de design reduz a confusão e aumenta a velocidade da equipe.
Documentação do processo
Os documentos de processo devem definir as ferramentas, a infraestrutura e os processos que a equipe vai usar para o desenvolvimento de ML. Documentos de processo bons ajudam a alinhar os membros novos e atuais da equipe. Elas precisam responder aos seguintes tipos de perguntas:
- Como os dados são gerados para o modelo?
- Como examinamos, validamos e visualizamos os dados?
- Como modificar um atributo ou rótulo de entrada nos dados de treinamento?
- Como personalizar o pipeline de geração, treinamento e avaliação de dados?
- Como mudar a arquitetura do modelo para acomodar mudanças nos rótulos ou recursos de entrada?
- Como podemos conseguir exemplos de testes?
- Quais métricas vamos usar para avaliar a qualidade do modelo?
- Como lançamos nossos modelos em produção?
- Como saberemos se algo está errado com nosso modelo?
- De quais sistemas upstream nossos modelos dependem?
- Como faço para manter e reutilizar meu SQL?
Mais perguntas possíveis
ModeloPosso treinar modelos em diferentes conjuntos de dados no mesmo pipeline, como para ajustes?
Como adiciono um novo conjunto de dados de teste ao meu pipeline?
Como verificar a previsão do modelo em um exemplo criado manualmente?
Como encontrar, examinar e visualizar exemplos em que o modelo cometeu erros?
Como determinar qual recurso foi mais responsável por uma determinada previsão?
Como posso entender quais atributos têm mais impacto nas previsões de uma determinada amostra?
Como faço para calcular ou representar graficamente as previsões do modelo em um conjunto de dados ou amostra escolhidos?
Como calcular as métricas padrão para as previsões do modelo em um conjunto de dados escolhido?
Como desenvolver e calcular métricas personalizadas?
Como comparar meu modelo com outros modelos off-line?
Posso realizar uma meta-análise para várias avaliações de modelo em um único ambiente de desenvolvimento?
Posso comparar o modelo atual com o de 10 meses atrás?
Acho que criei um bom modelo. Como posso lançar na produção?
Como verificar se o novo modelo está sendo executado corretamente na produção?
Posso acessar o histórico de avaliações de modelos ao longo do tempo?
Como saber quando algo está errado com o modelo?
Recebi uma página/bug mencionando algo sobre o modelo. O que devo fazer?
Como posso personalizar o pipeline de geração/treinamento/avaliação de dados?
Quando e como devo criar um pipeline completamente novo?
Preciso de SQL para gerar alguns dados. Onde devo colocar?
Como funciona a veiculação do modelo? Há um diagrama?
De quais sistemas upstream meu modelo depende que eu deveria conhecer?
Não consigo descobrir o que fazer. Com quem (e como) devo entrar em contato?
Observação importante
O que constitui as "práticas recomendadas de ML" pode variar entre empresas, equipes e indivíduos. Por exemplo, alguns membros da equipe podem considerar o Colabs experimental como o principal entregável, enquanto outros podem querer trabalhar no R. Alguns podem ter paixão pela engenharia de software, outros podem achar que o monitoramento é a coisa mais importante, e outros podem conhecer boas práticas de produção de recursos, mas querem usar o Scala. Todos estão "certos" do ponto de vista deles, e se forem direcionados corretamente, a mistura será uma potência. Caso contrário, pode ser uma bagunça.
Estabelecer as ferramentas, os processos e a infraestrutura que a equipe vai usar antes de escrever uma linha de código pode ser a diferença entre o fracasso do projeto após dois anos ou o lançamento com sucesso um trimestre antes do previsto.
Avaliações de desempenho
Devido à ambiguidade e incerteza inerentes ao ML, os gerentes de pessoas precisam definir expectativas claras e definir os resultados com antecedência.
Ao determinar as expectativas e os resultados, considere como eles serão avaliados se um projeto ou abordagem não tiver sucesso. Em outras palavras, é importante que a performance de um membro da equipe não esteja diretamente conectada ao sucesso do projeto. Por exemplo, não é incomum que os membros da equipe passem semanas investigando soluções que não funcionam. Mesmo nesses casos, o código de alta qualidade, a documentação completa e a colaboração eficaz devem contribuir positivamente para a avaliação.