Fluxo do Projeto de Ciência de Dados para Startups

Um cientista de dados assume nosso processo

Shay Palachy Blocked Unblock Seguir Seguindo 3 de janeiro

Recentemente fui perguntado por uma startup que estou consultando para dar minha opinião sobre a estrutura e o fluxo de projetos de ciência de dados, o que me fez pensar sobre o que os torna únicos. Tanto os gerentes quanto as equipes diferentes em uma startup podem achar as diferenças entre um projeto de ciência de dados e um desenvolvimento de software não intuitivo e confuso. Se não for declarado e explicado explicitamente, essas diferenças fundamentais podem causar mal-entendidos e confrontos entre o cientista de dados e seus pares.

Respectivamente, pesquisadores vindos da academia (ou grupos de pesquisa altamente orientados para a pesquisa) podem ter seus próprios desafios ao chegar a uma startup ou a uma empresa menor. Eles podem achar difícil incorporar novos tipos de insumos, como necessidades de produtos e negócios, infra-estrutura mais rígida e restrições de computação e feedback de clientes, em seu processo de pesquisa e desenvolvimento.

O objetivo deste post, então, é apresentar o fluxo de projeto característico que identifiquei no processo de trabalho tanto de meus colegas quanto de mim nos últimos anos. Espero que isso ajude os cientistas de dados e as pessoas que trabalham com eles a estruturar projetos de ciência de dados de uma maneira que reflita sua singularidade.

O fluxo foi construído com pequenas startups em mente, onde uma pequena equipe de cientistas de dados (geralmente de um a quatro) executam projetos de curto e médio porte liderados por uma única pessoa por vez. Equipes maiores ou aquelas em startups de aprendizado de máquina em primeiro lugar, de tecnologia profunda, ainda podem achar isso uma estrutura útil, mas os processos lá são mais longos e estruturados diferentemente em muitos casos.

Figura 1: Fluxo do Projeto de Ciência de Dados para Startups

Eu dividi o processo em três aspectos que são executados em paralelo: produto, ciência de dados e engenharia de dados. Em muitos casos (incluindo a maioria dos lugares onde trabalhei), pode não haver um engenheiro de dados para executar essas tarefas. Neste caso, o cientista de dados é geralmente encarregado de trabalhar com desenvolvedores para ajudá-lo com esses aspectos (ou eles mesmos, se ele for o mais raro de todos os animais de Deus: o Full Stack Data Scientist! ???). Assim, você pode substituir o engenheiro de dados por cientista de dados sempre que for mencionado , dependendo do seu ambiente.

No eixo do tempo, dividi o processo em quatro fases distintas:

  1. Escopo
  2. Pesquisa
  3. Desenvolvimento (modelo)
  4. Desdobramento, desenvolvimento

Vou tentar guiá-lo através de cada um deles, em ordem.

1. A fase de definição do escopo

Definir o escopo de um projeto de ciência de dados é crucial mais do que em qualquer outro tipo de projeto.

1.1. Necessidade do produto

Um projeto deve sempre começar com uma necessidade de produto (mesmo se a ideia original fosse técnica ou teórica), uma necessidade validada até certo ponto por pessoas de sucesso de produtos / negócios / clientes. A pessoa do produto deve ter uma ideia de como esse recurso deve (mais ou menos) acabar, e se os clientes existentes ou novos estarão dispostos a pagar por ele (ou se evitará assinaturas de churn / drive / vendas de outros produtos / etc).

Uma necessidade de produto não é uma definição completa do projeto, mas pode ser declarada como um problema ou desafio; por exemplo, “nossos clientes precisam entender como gastam seus orçamentos” ou “não conseguimos que nossos usuários mais antigos continuem tomando o remédio; isso aumenta a rotatividade ” ou “ os clientes pagarão mais por um produto que também pode prever horários de pico nos aeroportos em que operam ” .

1.2. Ideação inicial da solução

É aqui que o cientista de dados, juntamente com o responsável pelo produto, o engenheiro de dados e qualquer outra parte interessada, apresenta diferentes esboços para possíveis soluções. Isso significa tanto a abordagem geral (por exemplo, clustering não supervisionado vs classificação baseada em árvore reforçada vs inferência probabilística) e os dados a serem usados (por exemplo, essa tabela específica de nosso banco de dados ou algum comportamento específico do usuário que ainda não monitoramos ou salvamos, ou uma fonte de dados externa).

Isso geralmente também envolve algum nível de exploração de dados. Você não pode ir muito fundo aqui, mas qualquer promissor “fruto fácil” pode ajudar a orientar a ideação.

O cientista de dados deve liderar esse processo e geralmente é responsável por fornecer a maioria das ideias de solução, mas eu recomendo que você use todos aqueles que participam do processo de ideação de solução; Tive a sorte de obter as melhores ideias de soluções para um projeto entregue a mim por um desenvolvedor de back-end, o CTO ou o responsável pelo produto. Não assuma que origens diferentes, e menos orientadas pela teoria, invalidem as pessoas de participarem dessa fase; as mentes e pontos de vista adicionais são sempre valiosos.

1.3. Preparação de dados e acessibilidade

A equipe agora deve ter uma boa ideia dos dados que esperamos que sejam usados para explorar possíveis soluções (ou pelo menos o primeiro desses conjuntos de dados ou fontes). Assim, o processo de fornecer acesso a dados e prepará-lo para exploração e uso deve começar já, em paralelo com as próximas fases.

Isso pode levar a despejar grandes conjuntos de dados de bancos de dados de produção em suas contrapartes de preparação / exploração ou para armazenamento mais frio (por exemplo, armazenamento de objetos) se a disponibilidade de tempo não for crítica na fase de pesquisa. Por outro lado, isso pode significar extrair grandes despejos de dados do armazenamento muito frio de volta para a tabela ou para o formato do documento para permitir consultas rápidas e cálculos complexos. Seja qual for o caso, essa fase é necessária para a fase de pesquisa começar e freqüentemente acaba levando mais tempo do que o esperado, e então é o momento certo para iniciá-la.

1.4. Escopo e KPIs

Esta fase é sobre decidir em conjunto sobre o escopo e os KPIs do projeto.

Os KPIs devem ser definidos primeiro em termos de produto, mas com muito mais detalhes do que antes; por exemplo, com relação às três necessidades de produtos mencionadas anteriormente, elas podem se tornar "os clientes agora podem usar um painel com estatísticas de CTR e projeção por categoria" ou "dias de medicina perdidos por usuários com mais de 65 anos serão reduzidos em pelo menos 10% nos próximos dois dias trimestres ” , ou “ os clientes receberão previsões semanais de horários de pico em seus aeroportos com granularidade de pelo menos uma hora e aproximação de pelo menos ± 50% ” .

Esses KPIS devem então ser traduzidos para métricas de modelo mensuráveis. Com sorte, essas serão métricas muito difíceis, como “prever a CTR esperada de um anúncio com aproximação de pelo menos X% em pelo menos Y% dos casos, para qualquer anúncio que seja executado por pelo menos um fraco e por qualquer cliente com mais de dois meses de dados históricos ” . Em alguns casos, no entanto, métricas mais suaves terão que ser usadas, como “o tempo necessário para a exploração do tópico usando as consultas expandidas geradas será reduzido e / ou a qualidade do resultado será aprimorada, quando comparada às consultas originais” . Isto é especialmente verdadeiro quando os modelos são destinados a auxiliar alguma função humana complexa.

Tecnicamente, até mesmo essas métricas podem ser definidas de maneira muito estrita (e, na pesquisa acadêmica, geralmente são), mas dependendo dos recursos e das restrições de tempo, podemos resolvê-las aproximando-as usando o feedback humano. Nesse caso, cada iteração de feedback pode demorar mais e, normalmente, tentaremos encontrar métricas adicionais que nos guiem na maioria das próximas iterações de pesquisa, com o feedback mais caro sendo obtido apenas uma vez a cada poucas iterações ou em alterações significativas.

Finalmente, o escopo é especialmente importante aqui porque os projetos de pesquisa tendem a se arrastar e a expandir-se naturalmente em tamanho e escopo à medida que surgem novas possibilidades durante a pesquisa ou quando uma abordagem examinada atende apenas parcialmente às demandas.

Limite de escopo 1: acho mais produtivo limitar o escopo explicitamente; Por exemplo, se você decidiu que um modelo baseado em Bandido Multi-Armado é a abordagem mais promissora para começar, você pode definir o escopo do projeto para uma única iteração de desenvolvimento de modelo de duas ou três semanas, implantando o modelo independentemente de sua precisão. (desde que seja mais de 60%, por exemplo). Então, se a melhoria na precisão é valiosa (em alguns casos, pode ser menos), o desenvolvimento de um segundo modelo pode ser considerado como um projeto separado.

Limitação de escopo 2: Outra variação na limitação de escopo é usar graus crescentes de complexidade; por exemplo, o primeiro projeto pode ter como objetivo implantar um modelo que precise fornecer apenas um conjunto bastante grande de candidatos com variações de texto e de cor do anúncio para que as pessoas do seu próprio sucesso de cliente possam trabalhar com ele; o segundo pode tentar construir um modelo que forneça um conjunto menor de sugestões que o cliente possa ver ele mesmo; e um projeto final pode tentar um modelo que destaque uma única opção, classificando-o abaixo um pouco mais e adicionando projeções de CTR e alcance demográfico para cada variação.

Isso já é um grande afastamento da engenharia de software, na qual normalmente os componentes são iterados para aumentar a escala e não a complexidade.

No entanto, a função de valor de métrica para produto pode ser uma função de etapa, o que significa que qualquer modelo que desempenhe sob algum valor X não tem uso para o cliente; nesses casos, preferiremos iterar até que esse limite seja suprimido. No entanto, embora esse X possa ser muito alto em alguns casos, acredito que tanto os profissionais quanto os cientistas de dados tendem a superestimar a altura dessa etapa; É muito fácil afirmar que qualquer coisa com 95% de precisão (por exemplo) não fornece nenhum valor e não pode ser vendida. Em muitos casos, no entanto, o exame cuidadoso eo desafio das suposições do produto podem levar a produtos muito valiosos que podem não ser tão exigentes tecnicamente (pelo menos na primeira iteração do produto).

1.5. Aprovação de escopo e KPIs

Por fim, o responsável pelo produto precisa aprovar o escopo e os KPIs definidos. É tarefa do cientista de dados certificar-se de que todos entendam as implicações do escopo – o que foi incluído e priorizado – e a relação entre os KPIs dos produtos e as métricas mais difíceis que o guiarão durante o desenvolvimento do modelo, incluindo até que ponto carta aproxima-se da primeira. Declarar isso explicitamente pode evitar casos em que os consumidores dos modelos que estão sendo desenvolvidos – produtos e pessoas de negócios – entendem apenas durante ou após o desenvolvimento do modelo que a métrica errada foi otimizada.

Comentários gerais sobre o escopo

Em muitos lugares essa fase é ignorada, com o cientista de dados ansioso para começar a investigar os dados e explorar documentos interessantes sobre possíveis soluções; na minha experiência, isso é quase sempre para o pior. Ignorar essa fase pode resultar em longas semanas ou meses gastos no desenvolvimento de modelos interessantes que acabam não respondendo a uma necessidade real ou falhando em um KPI muito específico que poderia ter sido explicitamente definido com alguma premeditação.

2. A Fase de Pesquisa

2.1. Exploração de dados

Aqui é onde a diversão começa! A principal vantagem de ter essa fase iniciada após o escopo é que nossa exploração agora pode ser guiada pelos KPIs reais e métricas de modelo que decidimos.

Como sempre, há um equilíbrio a ser atingido aqui entre exploração e exploração; mesmo tendo em mente KPIs claros, é valioso explorar alguns caminhos aparentemente não relacionados até certo ponto.

Até agora, o conjunto inicial de dados requeridos deveria ter sido disponibilizado pela engenharia de dados. No entanto, algumas deficiências nos dados explorados geralmente serão descobertas durante essa fase, e fontes de dados adicionais podem ser adicionadas ao conjunto de trabalho. O engenheiro de dados deve estar preparado para isso.

Finalmente, embora separados da literatura e da fase de revisão da solução, eles geralmente são feitos em paralelo ou alternados entre eles.

2.2. Revisão de literatura e soluções

Tanto a literatura acadêmica quanto o código e as ferramentas existentes são revisados nesta fase. O equilíbrio é novamente importante; tanto entre exploração e exploração, quanto entre mergulhar nas complexidades do material e extrair conclusões e possíveis usos rapidamente.

No caso da literatura acadêmica, a escolha de quão profundo entrar em aspectos como provas formais e literatura anterior depende muito das restrições de tempo e do contexto do projeto: Estamos construindo uma base forte para uma capacidade central da empresa ou planejando uma solução para um problema único? Planejamos publicar nosso trabalho sobre o assunto em um trabalho acadêmico? Você está planejando se tornar o especialista da equipe no tópico?

Por exemplo, considere o caso em que um cientista de dados embarcando em um projeto para ajudar o departamento de vendas a prever melhor o rendimento da geração de leads ou churn sente que ele tem apenas uma compreensão superficial da teoria dos processos estocásticos, na qual muitas soluções comuns para esses problemas são construídas. A resposta apropriada a esse sentimento pode ser muito diferente; se ele trabalha para uma empresa de comércio de algo, ele definitivamente deveria estar mergulhando nessa teoria, provavelmente até mesmo fazendo um curso on-line sobre o assunto; Se, por outro lado, ele trabalha para uma empresa de imagens médicas focada na detecção automática de tumores em radiografias de fígado, eu diria que ele deve encontrar rapidamente uma solução aplicável e seguir em frente.

No caso do código e das implementações, a profundidade do entendimento a ser buscado depende de aspectos técnicos, alguns dos quais podem ser descobertos apenas mais tarde no processo, mas muitos deles também podem ser previstos com antecedência.

Por exemplo, se o ambiente de produção oferecer suporte apenas à implementação do código Java e Scala para usos de backend e se espera que a solução seja fornecida em uma linguagem JVM, o cientista de dados precisará aprofundar as implementações baseadas em Python que ele encontrou mesmo durante essa pesquisa fase, como avançar com eles na fase de desenvolvimento do modelo implica traduzi-los para uma linguagem JVM.

Finalmente, esta fase deve ser feita, tendo em mente que não apenas a direção da pesquisa escolhida (ou algumas direções) deve ser apresentada ao resto da equipe, mas uma breve revisão do campo e todas as soluções examinadas devem acompanhar o processo. escolha feita, explicando as vantagens e desvantagens de cada direção e as justificativas para a escolha feita.

2.3. Verificação de validade técnica

Agora, com uma sugestão na mesa para uma possível solução, o engenheiro de dados e qualquer engenheiro envolvido precisam estimar, com a ajuda do cientista de dados, a forma e a complexidade dessa solução em produção. Tanto as necessidades do produto quanto a estrutura e as características da solução sugerida devem ajudar a determinar o armazenamento de dados adequado, o processamento no fluxo versus o lote, a capacidade de dimensionar (horizontalmente e verticalmente) e uma estimativa aproximada do custo.

Esta é uma verificação de importação para executar neste estágio porque alguns dados e engenharia de software podem começar em paralelo ao desenvolvimento de modelo e porque uma solução sugerida pode se mostrar inadequada ou muito cara em termos de engenharia, e em qual caso isso deve ser alcançado e lidou com o mais rapidamente possível. Quando questões técnicas são consideradas antes do início da validação do modelo, o conhecimento adquirido durante a fase de pesquisa pode ser usado para sugerir uma solução alternativa que possa se adequar melhor às restrições técnicas. Esse é outro motivo pelo qual a fase de pesquisa também deve resultar em uma visão geral do cenário da solução, e não apenas em uma única direção de solução.

2.4. Validação de escopo e KPIs

Novamente, o gerente de produto precisa aprovar que a solução sugerida, agora declarada em termos mais técnicos, atenda ao escopo e aos KPIs definidos. Possíveis critérios técnicos que geralmente têm implicações de produto facilmente detectáveis são o tempo de resposta (e sua relação com o tempo de computação), o frescor dos dados e às vezes os cálculos intermediários em cache (que estão relacionados à consulta e freqüência de computação de lote), dificuldade e custo custo) de adaptação de domínio para modelos específicos de domínio (domínios são mais frequentemente clientes, mas podem ser indústrias, idiomas, países e assim por diante) e compostabilidade de solução (p.ex. estruturas de dados e modelo permitem facilmente quebrar um modelo de país para baixo um modelo por região, ou compor vários desses modelos em um modelo por continente, embora muitos mais existam.

3. A Fase de Desenvolvimento

3.1. Desenvolvimento de modelo e estrutura de experimentos

A quantidade e complexidade de configuração necessária para o desenvolvimento do modelo depende muito da infraestrutura e da quantidade de suporte técnico disponível para o cientista de dados. Em locais menores, e em locais ainda não usados para apoiar projetos de pesquisa em ciência de dados, a configuração pode resumir ao cientista de dados abrindo um novo repositório de código e ativando um servidor Jupyter Notebook local, ou solicitando uma máquina de nuvem mais forte para executar cálculos.

Em outros casos, pode implicar a criação de código personalizado para funcionalidades mais complexas, como dados e versão de modelo ou rastreamento e gerenciamento de experimentos. Quando essa funcionalidade é fornecida por algum produto ou serviço externo (e mais e mais deles estão aparecendo nos dias de hoje), algumas configurações na forma de vincular fontes de dados, alocar recursos e configurar pacotes personalizados podem ser seguidas.

3.2. Desenvolvimento de modelos

Com a infraestrutura necessária, o desenvolvimento real do modelo pode começar a sério. A extensão do que é considerado o modelo a ser desenvolvido varia conforme a empresa e depende da relação e da divisão entre o modelo a ser fornecido pelo cientista de dados e o serviço ou recurso a ser implantado na produção. Os vários tipos de abordagens para essa divisão talvez possam ser capturados de alguma forma considerando um espectro.

Em uma extremidade do espectro está o caso onde tudo é o modelo : da agregação e pré-processamento de dados, através do treinamento de modelo (possivelmente periodicamente), implantação de modelo, serviço (possivelmente com escalonamento) e monitoramento contínuo. Na outra ponta, está o caso em que apenas a escolha do tipo de modelo e hiperparâmetros, e comumente também o pré-processamento avançado de dados e a geração de recursos, é pensada como o modelo .

A localização da sua empresa no espectro pode depender de vários fatores: a linguagem de pesquisa preferida dos cientistas de dados; bibliotecas relevantes e disponibilidade de código aberto; suportou linguagens de produção na empresa; a existência de um engenheiro de dados e desenvolvedores dedicados exclusivamente ao código relacionado à ciência de dados; e as capacidades técnicas e metodologia de trabalho de seus cientistas de dados.

No caso de um cientista de dados muito completo, combinado com suporte suficiente de um engenheiro de dados e desenvolvedores dedicados – ou, alternativamente, com infraestrutura existente suficiente dedicada à operação e automação de mapeamento e agregação de dados, serviço de modelo, dimensionamento e monitoramento (e possivelmente também versionamento) – a definição mais ampla para um modelo pode ser tomada, e uma solução de ponta a ponta pode ser usada durante a maioria das iterações no desenvolvimento de modelos.

Isso geralmente significa construir o pipeline completo primeiro, de fontes de dados até modelos atendidos escalonáveis, com espaços reservados simples para o pré-processamento de dados, geração de recursos e o próprio modelo. Em seguida, as iterações são feitas nas partes de ciência de dados, mantendo o contexto para o que está disponível e implantável na infraestrutura existente.

Essa abordagem de ponta a ponta pode levar mais tempo para ser configurada, e cada iteração nos tipos e parâmetros do modelo leva mais tempo para ser testada, mas economiza tempo depois pago na fase de produção.

Eu pessoalmente adoro isso, mas é complexo de implementar e manter, e nem sempre é apropriado. Nesse caso, algumas partes do início e do final do pipeline são deixadas para a fase de produção.

3.3. Teste modelo

Ao desenvolver o modelo, diferentes versões dele (e o pipeline de processamento de dados que o acompanha) devem ser continuamente testados em relação à métrica rígida predeterminada. Isso fornece uma estimativa aproximada do progresso e também permite que o cientista de dados decida quando o modelo parece estar funcionando bem o suficiente para garantir a verificação geral do KPI. Observe que isso pode ser enganoso, já que obter uma precisão de 50% a 70%, por exemplo, é muito mais fácil do que obter de 70% a 90%.

Figura 2: Falha no modelo implica em iteração, mas uma falha na abordagem pode enviar você de volta à pesquisa

Quando os testes mostram que um modelo está errado, geralmente investigamos isso e sua saída para guiar melhorias. Às vezes, no entanto, a lacuna no desempenho é muito grande, com variações diferentes das direções de pesquisa escolhidas, todas ficando aquém – uma falha de abordagem . Isso pode justificar uma mudança na direção da pesquisa, enviando o projeto de volta à fase de pesquisa. Esse é o aspecto dos projetos de ciência de dados que é mais difícil de aceitar: a possibilidade muito real de retrocesso.

Outro resultado possível da falha da abordagem é uma mudança no objetivo. Com sorte, pode ser menor em termos de produto, mas reafirmar o objetivo tecnicamente de maneira mais simples.

Por exemplo, em vez de tentar gerar um resumo de uma frase de um artigo, escolha a frase no artigo que melhor resume.

3.4. KPIs check

Se a métrica rígida predeterminada é o único KPI e captura exatamente todas as necessidades do produto, essa fase pode ser mais formal, quando o modelo final é apresentado e a fase de desenvolvimento é declarada. Isso geralmente não é o caso.

No caso mais comum, a métrica rígida é uma boa aproximação das necessidades reais do produto, mas não é perfeita. Essa fase é, portanto, uma oportunidade para garantir que as métricas mais brandas, que não podem ser verificadas automaticamente, também sejam satisfeitas. Isso é feito em conjunto com o sucesso do produto e do cliente. Se você puder checar adicionalmente o valor real para um cliente diretamente – por exemplo, quando estiver trabalhando com um parceiro de projeto – então é o melhor guia que você pode encontrar para suas iterações.

Por exemplo, digamos que estamos lidando com uma tarefa complexa, como extrair documentos relevantes, dada uma consulta, de um corpus enorme. A equipe pode ter decidido tentar aumentar a qualidade do conjunto de resultados, concentrando-se na variação de conteúdo e tópicos dos documentos retornados, pois os clientes sentem que os sistemas tendem a agrupar documentos bastante semelhantes nos principais resultados.

O desenvolvimento de modelos pode ter progredido com alguma métrica mensurável para variação de conteúdo no conjunto de resultados – cada modelo é pontuado pela variação dos 20 principais documentos que retorna, dado um conjunto de consultas de teste; talvez você meça a distância total entre os tópicos do documento em algum espaço vetorial tópico, ou apenas o número de tópicos exclusivos ou planicidade de distribuições significativas de palavras.

Mesmo quando o cientista de dados se instala em um modelo que melhore significativamente essa métrica, as pessoas de sucesso de produto e cliente devem definitivamente dar uma olhada nos resultados reais para uma amostra significativa das consultas de teste; eles podem encontrar problemas difíceis de quantificar, mas possíveis de resolver, como aumentar a variância dos resultados, aumentando alguns tópicos não relevantes recorrentes ou incluindo resultados sobre tópicos semelhantes, mas de fontes diferentes (por exemplo, artigos de notícias versus tweets, que usam uma linguagem muito diferente).

Quando a pessoa do produto está convencida de que o modelo responde aos objetivos declarados do projeto (em um grau satisfatório), a equipe pode avançar para a sua produção.

4. A fase de implantação

4.1. Configuração de Productization & Monitoring da Solução

Essa fase, como mencionado anteriormente, depende da abordagem tanto da pesquisa em ciência de dados quanto do modelo de serviço na empresa, bem como de vários fatores técnicos importantes.

Productization: Nos casos em que a linguagem de pesquisa pode ser usada na produção, essa fase pode implicar a adaptação do código do modelo para funcionar de maneira escalável; O quão simples ou complexo é esse processo depende tanto do suporte de computação distributiva para a linguagem de modelo quanto das bibliotecas específicas e código personalizado usado.

Quando a linguagem de pesquisa e produção é diferente, isso também pode envolver o código do modelo em um wrapper de linguagem de produção, compilá-lo para um binário de baixo nível ou implementar a mesma lógica na linguagem de produção (ou encontrar essa implementação).

A ingestão e o processamento de dados escalonáveis também precisam ser configurados, no caso (bastante comum) em que isso não fazia parte do modelo. Isso pode significar, por exemplo, transformar funções Python executadas em um único núcleo em um fluxo de dados de pipeline, ou em tarefas em lote que são executadas periodicamente. No caso de reutilização significativa de dados, uma camada de armazenamento em cache às vezes é configurada.

Monitoramento: Finalmente, uma maneira de monitorar continuamente o desempenho do modelo é configurada; em casos raros, quando a fonte de dados de produção é constante, isso pode ser ignorado com segurança, mas eu diria que na maioria dos casos você não pode ter certeza da estabilidade da distribuição de dados de origem. Configurar essa verificação de desempenho, portanto, pode nos ajudar a não apenas detectar problemas no modelo que poderíamos ter perdido durante o desenvolvimento e a produção, mas, mais importante, mudanças na distribuição de dados de origem acima da qual o modelo opera – comumente referido como mudança de covariável – que pode degradar, com o tempo, o desempenho de um modelo perfeitamente bom.

Tomemos, por exemplo, o caso em que nosso produto é um aplicativo que detecta marcas de pele e avalia se recomenda que o usuário consulte um médico de pele. Uma mudança de covariável pode acontecer em nossos dados quando um novo celular popular for lançado no mercado, equipado com uma câmera significativamente diferente das presentes em nossos dados.

4.2. Implantação de soluções

Se tudo estiver configurado corretamente, esse estágio pode resumir, esperançosamente, a pressionar um botão para implantar o novo modelo – e qualquer código que o atenda – ao ambiente de produção da empresa.

Implantação Parcial: É possível, no entanto, que, a fim de testar a eficácia do modelo (por exemplo, na redução da rotatividade, ou aumentar o gasto médio mensal por usuário), o modelo será implantado de forma que apenas parte do usuário / base de clientes é exposto a ele. Isso permite uma comparação direta do efeito em quaisquer KPIs mensuráveis entre os dois (ou mais) grupos na base de usuários.

Outra razão pela qual você pode não querer implantar o modelo para todos é se ele foi desenvolvido para atender às necessidades de um cliente específico ou de um grupo de clientes, ou se é um recurso premium ou parte de um plano específico. Como alternativa, o modelo pode ter algum elemento de personalização por usuário ou cliente; Às vezes, isso pode ser obtido com um modelo único que leva em conta as características do cliente, mas às vezes implica realmente treinar e implantar um modelo diferente para cada cliente.

Seja qual for o caso, todos esses cenários aumentam a complexidade da implantação do modelo e, dependendo da infraestrutura existente na empresa (por exemplo, se você já está implantando alguns dos recursos do produto em subconjuntos de clientes), eles podem exigir uma quantidade significativa de recursos adicionais. desenvolvimento por sua equipe de back-end.

Essa fase é ainda mais complexa quando o modelo é implantado em produtos finais, como telefones de usuário ou wearables, e nesse caso, a implantação do modelo só pode acontecer como parte da próxima atualização de aplicativo ou firmware implantada.

Gerando Bias: Finalmente, todos os casos de implantação parcial são realmente uma questão premente para a equipe de ciência de dados por outro motivo: isso naturalmente introduz desvios nos dados futuros que o modelo começará a acumular – o modelo começará a operar em dados por um subconjunto de usuários com características possivelmente únicas. Dependendo do produto e das características específicas, isso pode ter um grande impacto no desempenho do modelo na natureza e, possivelmente, em futuros modelos treinados em dados acumulados durante esse período.

Por exemplo, no caso da atualização do dispositivo, os usuários que atualizaram seus aplicativos / firmware anteriormente tendem a se enquadrar em determinada demografia (mais jovem, mais experiente em tecnologia, maior renda, etc.).

4.3. KPIs check

Eu adicionei outra verificação de KPIs aqui porque acho que uma solução não pode ser marcada como entregue antes de seu desempenho e o atendimento bem-sucedido das necessidades do produto e do cliente ter sido validado após a implantação e o uso real.

Isso pode significar examinar e analisar os dados resultantes algumas semanas após a implantação. No entanto, quando clientes reais estão envolvidos, isso também deve envolver pessoas que tenham sucesso no produto ou no cliente, sentadas com os clientes e tentando entender o impacto real que o modelo tem sobre o uso do produto.

4.4. Solução entregue

Usuários e clientes estão felizes. As pessoas do produto conseguiram construir ou adaptar o produto que desejavam ao redor do modelo. Foram realizadas. Brindes são torrados, vivas são aplaudidas e tudo está bem.

A solução é entregue e eu chamaria o projeto feito neste momento. No entanto, continua a viver de uma forma específica – manutenção.

Manutenção

Tendo configurado verificações de integridade e monitoramento de desempenho contínuo para o modelo, eles podem acionar breves explosões de trabalho no projeto.

Quando algo parece ser suspeito, geralmente começamos olhando para os dados (por exemplo, para desvios de covariáveis) e talvez simulando a resposta do modelo a vários casos que suspeitamos causar o problema. Os resultados dessas verificações podem nos enviar para qualquer coisa entre algumas horas de pequenas alterações de código e re-treinamento das iterações de desenvolvimento de modelo e modelo completo (como refletido na figura que abre este post), com casos severos às vezes envolvendo voltar ao fase de pesquisa para tentar direções completamente diferentes.

Palavras finais

Esta é uma sugestão para o fluxo de projetos de ciência de dados. É também muito específico, limitado em seu escopo – por uma questão de simplicidade e visibilidade – e obviamente não pode cobrir as muitas variações desse fluxo que existem na prática. Também representa minha experiência.

Por todas essas razões, eu adoraria ouvir seus comentários, insights e experiência de execução, liderança ou gerenciamento de projetos de ciência de dados, independentemente do seu tamanho e de qualquer tamanho da equipe de ciência de dados da qual você faz parte.