Projetos de ML exigem equipes com membros que têm uma variedade de habilidades, e responsabilidades relacionadas ao machine learning. Essas são as formas mais comuns papéis encontrados em equipes de ML típicas:
Papel | Conhecimento e habilidades | Principal entrega |
---|---|---|
Gerente de produtos de ML | Gerentes de produto de ML têm um profundo conhecimento dos pontos fortes dessa tecnologia e o processo de desenvolvimento de ML. Eles alinham problemas de negócios até soluções de ML, conduzindo com a equipe de ML, usuários finais, e outras partes interessadas. Eles criar a visão do produto, definir casos de uso e e planejar e priorizar projetos. |
Documento de requisitos do produto (PRD, na sigla em inglês). |
Gerente de engenharia | Os gerentes de engenharia atingem as metas de negócios definindo, comunicando e alcançar as prioridades da equipe. Assim como o ML gerentes de produtos, eles alinham soluções de ML aos problemas de negócios. Eles definem expectativas claras para os membros da equipe, conduzir avaliações de desempenho e ajudar na carreira e e desenvolvimento profissional. |
Projetar documentos, 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, prototipar modelos e ajudar na interpretabilidade do modelo. | Relatórios e visualizações de dados que respondem a perguntas de negócios por meio de análises estatísticas. |
Engenheiros de ML | Os engenheiros de ML projetam, criam, colocam em produção e gerenciam modelos de ML. Eles são engenheiros de software competentes com um profundo conhecimento de ML e práticas recomendadas. | Modelo implantado com qualidade de previsão suficiente para atender às necessidades metas. |
Engenheiro de dados | Os engenheiros de dados criam pipelines de dados para armazenar, agregar e processar grandes quantidades de dados. Eles desenvolvem a infraestrutura e sistemas de coleta e transformação de dados brutos em formatos úteis para treinamento e disponibilização de modelos. Engenheiros de dados são responsável pelos dados em todo o processo de desenvolvimento de ML. | Pipelines de dados totalmente produzidos com o monitoramento e e alertas. |
Engenheiro de operações para desenvolvedores (DevOps) | Os engenheiros de DevOps desenvolvem, implantam, escalonam e monitoram a infraestrutura de disponibilização para modelos de ML. | Um processo automatizado para disponibilização, monitoramento, teste e alerta de o comportamento de um modelo. |
Projetos de ML bem-sucedidos têm equipes em cada função bem representados. Em equipes menores, os indivíduos precisarão lidar responsabilidades de vários cargos.
Estabelecer práticas de equipe
Como os papéis, as ferramentas e os frameworks variam muito no ML é fundamental estabelecer práticas comuns por meio de excelente documentação de processos. Por exemplo, um engenheiro pode considerar que apenas os dados certos são suficientes para começar a treinar um modelo, enquanto um engenheiro mais responsável valida que o conjunto de dados é anonimizado corretamente e documente seus metadados e procedência. Garantir que os engenheiros compartilhem definições comuns para processos e padrões de design reduz a confusão e aumenta a velocidade da equipe.
Documentação do processo
Documentos de processos devem definir as ferramentas, a infraestrutura e os processos que a equipe que serão usadas no desenvolvimento de ML. Documentos de processo bons ajudam a alinhar conteúdo novo e atual com os membros da equipe. Ele deve responder aos seguintes tipos de perguntas:
- Como os dados são gerados para o modelo?
- Como examinamos, validamos e visualizamos os dados?
- Como modificamos um atributo ou rótulo de entrada nos dados de treinamento?
- Como personalizamos o pipeline de geração, treinamento e avaliação de dados?
- Como faço para mudar a arquitetura do modelo para acomodar mudanças na entrada atributos ou rótulos?
- Como conseguimos exemplos de teste?
- Que métricas usaremos para julgar a qualidade do modelo?
- Como lançamos nossos modelos para produção?
- Como saberemos se há algo de errado com o modelo?
- De quais sistemas upstream dependem nossos modelos?
- Como posso tornar meu SQL sustentável e reutilizável?
Mais possíveis perguntas
ModeloPosso treinar modelos em diferentes conjuntos de dados no mesmo pipeline, como para ajustes?
Como adiciono um novo conjunto de dados de teste ao pipeline?
Como faço para verificar a previsão do modelo em um exemplo feito manualmente?
Como encontrar, examinar e visualizar exemplos em que o modelo fez erros?
Como determino qual recurso foi o mais responsável por um determinado previsão?
Como entender quais recursos têm o maior impacto em previsões em uma determinada amostra?
Como calcular ou traçar previsões de modelo em um conjunto de dados escolhido ou amostra?
Como calcular métricas padrão para as previsões do meu modelo em uma no conjunto de dados escolhido?
Como desenvolver e computar métricas personalizadas?
Como comparo meu modelo a outros modelos off-line?
Posso realizar uma meta-análise de várias avaliações de modelo em uma única ambiente de desenvolvimento de software?
Posso comparar o modelo atual com o de 10 meses atrás?
Acho que criei um bom modelo. Como faço para lançá-lo na produção?
Como posso verificar se meu novo modelo está sendo executado corretamente na produção?
É possível conseguir o histórico das avaliações de modelo ao longo do tempo?
Como vou saber se há algo de errado com o modelo?
Recebi uma página/bug mencionando algo sobre o modelo. O que devo fazer?
Como personalizar a geração/treinamento/avaliação de dados? pipeline?
Quando e como devo criar um pipeline completamente novo?
Preciso de SQL para gerar alguns dados. Onde devo colocar?
Como funciona a disponibilização do nosso modelo? Há um diagrama?
De quais sistemas upstream depende meu modelo conhece?
Não consigo descobrir alguma coisa. Com quem (e como) devo entrar em contato?
Observação importante
O que constitui as "práticas recomendadas de ML" podem diferir entre empresas, equipes indivíduos. Para por exemplo, alguns membros da equipe podem considerar os Colabs experimentais como o principal entrega, enquanto outros vão querer trabalhar em R. Alguns podem ter uma paixão por e engenharia de software, alguém acha que o monitoramento é o mais importante mas outra pessoa está ciente das boas práticas de produção de atributos, mas quer usar o Scala. Todos estão "certos" de sua própria perspectiva e se conduzida corretamente, a mistura será potente. Se não, pode ser uma bagunça.
Estabelecer as ferramentas, processos e infraestrutura que a equipe usará antes escrever uma linha de código pode ser a diferença entre a falha do projeto depois com dois anos ou um lançamento trimestral antes do previsto.
Avaliações de desempenho
Devido à ambiguidade e à incerteza inerentes ao ML, os gerentes de pessoas precisam definir expectativas claras e definir entregas com antecedência.
Ao determinar expectativas e entregas, considere como elas serão avaliado se um projeto ou abordagem não foi bem-sucedida. Em outras palavras, é importante que o desempenho de um membro da equipe não esteja diretamente ligado ao no sucesso do projeto. Por exemplo, não é incomum que membros da equipe gastem e semanas investigando soluções que não funcionam. Mesmo nesses casos de uso diferentes, pelo código de alta qualidade, pela documentação completa e pelo e colaboração devem contribuir positivamente para sua avaliação.