Regras do machine learning:

Práticas recomendadas para engenharia de ML

Martin Zinkevich (em inglês)

O objetivo deste documento é ajudar as pessoas com conhecimento básico sobre machine learning a aproveitar as práticas recomendadas do Google em machine learning. Ele apresenta um estilo de machine learning, semelhante ao Guia de estilo do Google C++ e outros guias famosos de programação prática. Se você já cursou ou aprendeu ou criou um modelo de machine learning, você tem o conhecimento necessário para ler este documento.

Martin Zinkevich apresenta 10 das regras favoritas de aprendizado de máquina. Continue lendo para saber mais sobre as 43 regras.

Terminologia

Os termos a seguir serão abordados várias vezes em nossa discussão sobre machine learning eficaz:

  • Instância: o que você quer que faça uma previsão. Por exemplo, a instância pode ser uma página da Web que você quer classificar como "sobre gatos" ou "não sobre gatos".
  • Identificador: uma resposta para uma tarefa de previsão, a resposta produzida por um sistema de machine learning ou a resposta certa fornecida nos dados de treinamento. Por exemplo, o rótulo de uma página da Web pode ser "sobre gatos".
  • Atributo: uma propriedade de uma instância usada em uma tarefa de previsão. Por exemplo, uma página da Web pode ter um recurso "contém a palavra 'gato'".
  • Coluna de recursos: um conjunto de recursos relacionados, como o conjunto de todos os países onde os usuários podem estar. Um exemplo pode ter um ou mais atributos presentes em uma coluna. "Coluna de atributo" é uma terminologia específica do Google. Uma coluna de atributo é chamada de "namespace" no sistema VW (no Yahoo/Microsoft) ou em um campo.
  • Exemplo: uma instância (com os recursos dela) e um rótulo.
  • Modelo: uma representação estatística de uma tarefa de previsão. Você treina um modelo com exemplos e o usa para fazer previsões.
  • Métrica: um número que importa para você. Pode ou não ser diretamente otimizado.
  • Objetivo: uma métrica que seu algoritmo está tentando otimizar.
  • Pipeline: a infraestrutura ao redor de um algoritmo de machine learning. Isso inclui coletar os dados do front-end, colocá-los em arquivos de dados de treinamento, treinar um ou mais modelos e exportá-los para produção.
  • Taxa de cliques: a porcentagem de visitantes de uma página da Web que clicam em um link em um anúncio.

Visão geral

Para criar ótimos produtos:

de machine learning, como o engenheiro de qualidade que você conhece, e não o especialista em machine learning que você não é.

Na verdade, a maioria dos problemas é de engenharia. Mesmo com todos os recursos de um ótimo especialista em machine learning, a maioria dos ganhos vem de ótimos recursos, e não de algoritmos de machine learning. A abordagem básica é:

  1. Verifique se o pipeline é de ponta a ponta.
  2. Comece com um objetivo razoável.
  3. Adicione recursos de senso comum de uma forma simples.
  4. Verifique se o pipeline permanece estável.

Essa abordagem funcionará bem por um longo período. Avance dessa abordagem somente quando não houver mais truques simples para levar você mais longe. A adição de complexidade diminui as próximas versões.

Depois de terminar os truques simples, o machine learning moderno pode estar no seu futuro. Consulte a seção sobre projetos de machine learning na Fase III.

Este documento é organizado da seguinte maneira:

  1. A primeira parte vai ajudar você a entender se esse é o momento certo para criar um sistema de machine learning.
  2. A segunda parte é sobre a implantação do seu primeiro pipeline.
  3. A terceira parte é sobre o lançamento e a iteração ao adicionar novos atributos ao pipeline, como avaliar modelos e o desvio de treinamento/exibição.
  4. A última parte é sobre o que fazer quando você chega a um platô.
  5. Em seguida, há uma lista de trabalhos relacionados e um apêndice com um pouco de experiência sobre os sistemas geralmente usados como exemplos neste documento.

Antes do machine learning

Regra 1: não tenha medo de lançar um produto sem o aprendizado de máquina.

O machine learning é legal, mas exige dados. Teoricamente, é possível extrair dados de um problema diferente e ajustar o modelo para um novo produto, mas isso provavelmente vai ter um desempenho inferior heurístico. Se você acha que o machine learning vai proporcionar 100% de aumento, uma heurística vai chegar em 50%.

Por exemplo, se você classificar apps em um mercado de apps, poderá usar a taxa de instalação ou o número de instalações como heurística. Se você estiver detectando spam, filtre os editores que já enviaram spam. Não tenha medo de usar a edição humana. Se você precisar classificar os contatos, escolha o mais recente (ou até mesmo em ordem alfabética). Se o machine learning não for absolutamente necessário para seu produto, não o use até que você tenha dados.

Regra 2: primeiro crie e implemente métricas.

Antes de formalizar o que o sistema de machine learning vai fazer, monitore o máximo possível no sistema atual. Faça isso pelos seguintes motivos:

  1. É mais fácil receber permissão dos usuários do sistema com antecedência.
  2. Se você acha que algo pode ser uma preocupação no futuro, é melhor receber dados históricos agora.
  3. Se você projetar seu sistema com a instrumentação de métricas em mente, as coisas vão funcionar melhor para você no futuro. Especificamente, você não quer usar strings em registros para instrumentar suas métricas.
  4. Você vai perceber o que muda e o que permanece igual. Por exemplo, suponha que você queira otimizar usuários ativos em um dia. No entanto, durante as primeiras manipulações do sistema, você pode notar que mudanças drásticas da experiência do usuário não alteram visivelmente essa métrica.

A equipe do Google Plus mede a expansão por leitura, os compartilhamentos por leitura, os +1s por leitura, os comentários/leitura, os comentários por usuário, os novos compartilhamentos por usuário etc., que são usados para calcular os benefícios de uma postagem no momento da veiculação. É importante observar que é importante ter um framework de experimento, em que é possível agrupar usuários em buckets e agregar estatísticas por experimento. Consulte Regra 12.

Ao ser mais livre ao coletar métricas, você pode ter uma visão mais ampla do seu sistema. Notou um problema? Adicione uma métrica para monitorá-la. Gostou de alguma mudança quantitativa na última versão? Adicione uma métrica para monitorá-la.

Regra 3: escolha o machine learning em vez de uma heurística complexa.

Uma heurística simples pode fazer com que seu produto seja exibido. Uma heurística complexa não pode ser mantida. Quando você tiver dados e uma ideia básica do que está tentando realizar, siga para o machine learning. Como na maioria das tarefas de engenharia de software, você vai querer atualizar constantemente sua abordagem, seja um modelo heurístico ou aprendido pela máquina e vai descobrir que é mais fácil atualizar e manter o modelo aprendido pela máquina (consulte a Regra 16).

Fase I de ML: seu primeiro pipeline

Concentre-se na infraestrutura do sistema do seu primeiro pipeline. Embora seja divertido pensar sobre todo o machine learning de criação que você vai fazer, será difícil descobrir o que está acontecendo se você não confiar primeiro no seu pipeline.

Regra 4: mantenha o primeiro modelo simples e garanta a infraestrutura certa.

O primeiro modelo oferece o maior impulso para seu produto, portanto, ele não precisa ser sofisticado. No entanto, haverá muitos outros problemas de infraestrutura do que o esperado. Para que seu novo sistema de machine learning sofisticado possa ser usado, é preciso determinar o seguinte:

  • Como ver exemplos para seu algoritmo de aprendizado.
  • Primeiro, entenda o que significa "bom" e "ruim" para seu sistema.
  • Como integrar o modelo ao aplicativo. É possível aplicar o modelo ao vivo ou pré-calcular o modelo em exemplos off-line e armazenar os resultados em uma tabela. Por exemplo, você pode querer pré-classificar páginas da Web e armazenar os resultados em uma tabela, mas quer classificar mensagens de chat ao vivo.

Escolher recursos simples facilita o seguinte:

  • Os recursos alcançam o algoritmo de aprendizado corretamente.
  • O modelo aprende pesos razoáveis.
  • Os recursos chegam ao modelo no servidor corretamente.

Quando você tem um sistema que faz essas três coisas de forma confiável, já fez a maior parte do trabalho. Seu modelo simples fornece métricas de valor de referência e um comportamento de referência que pode ser usado para testar modelos mais complexos. Algumas equipes visam um primeiro lançamento "neutro": um primeiro lançamento que diminui de maneira explícita os ganhos de aprendizado de máquina para evitar distrações.

Regra 5: testar a infraestrutura de maneira independente do machine learning

Verifique se a infraestrutura é testável e se as partes de aprendizado do sistema estão encapsuladas para que você possa testar tudo ao redor. Especificamente:

  1. Testar a entrada de dados no algoritmo Verifique se as colunas de atributos que precisam ser preenchidas estão preenchidas. Sempre que a privacidade permitir, inspecione manualmente a entrada no seu algoritmo de treinamento. Se possível, verifique as estatísticas no pipeline em comparação com as estatísticas dos mesmos dados processados em outro lugar.
  2. Teste a remoção de modelos do algoritmo de treinamento. Verifique se o modelo no ambiente de treinamento tem a mesma pontuação do modelo no ambiente de exibição. Consulte a Regra 37.

O machine learning tem um elemento de imprevisibilidade. Portanto, faça testes para o código para criar exemplos em treinamento e disponibilização e para carregar e usar um modelo fixo durante a disponibilização. Além disso, é importante entender seus dados. Consulte Orientação prática para análise de conjuntos de dados grandes e complexos.

Regra 6: tenha cuidado com a queda de dados ao copiar pipelines.

Em geral, criamos um pipeline copiando um pipeline atual (ou seja, programação de culto de carga e o pipeline antigo descarta os dados necessários para o novo pipeline). Por exemplo, o pipeline do Google Plus, "What's Hot", descarta postagens mais antigas (porque está tentando classificar novas postagens). Este pipeline foi copiado para ser usado no Google Plus Stream, em que as postagens mais antigas ainda são significativas, mas o pipeline ainda estava descartando postagens antigas. Outro padrão comum é registrar apenas dados que foram vistos pelo usuário. Portanto, esses dados são desnecessários se queremos modelar por que uma determinada postagem não foi vista pelo usuário, porque todos os exemplos negativos foram descartados. Ocorreu um problema semelhante no Google Play. Ao trabalhar na página inicial dos apps do Google Play, foi criado um novo pipeline que também continha exemplos da página de destino do Play Games sem nenhum recurso para remover a ambiguidade da origem de cada exemplo.

Regra 7: transforme a heurística em atributos ou os processe externamente.

Normalmente, os problemas que o machine learning está tentando resolver não são completamente novos. Já existe um sistema de classificação, classificação ou qualquer outro problema que você esteja tentando resolver. Isso significa que há várias regras e heurísticas. Essas mesmas heurísticas podem ajudar você a melhorar com o machine learning. Sua heurística precisa ser minada por qualquer informação por dois motivos. Primeiro, a transição para um sistema aprendido por máquina será mais suave. Segundo, essas regras costumam ter muita intuição sobre o sistema que você não quer descartar. Há quatro maneiras de usar uma heurística atual:

  • Pré-processamento usando a heurística. Se o recurso é incrivelmente incrível, essa é uma opção. Por exemplo, se em um filtro de spam, o remetente já estiver na lista de proibições, não tente reaprender o que "colocado na lista de proibições" significa. Bloquear a mensagem. Essa abordagem faz mais sentido nas tarefas de classificação binária.
  • Criar um atributo. Criar um recurso diretamente da heurística é ótimo. Por exemplo, se você usar uma heurística para calcular uma pontuação de relevância para um resultado de consulta, inclua a pontuação como o valor de um atributo. Posteriormente, é possível usar técnicas de machine learning para massagem no valor (por exemplo, converter o valor em um de um conjunto finito de valores discretos ou combiná-lo com outros atributos), mas começar usando o valor bruto produzido pela heurística.
  • Extrair as entradas brutas da heurística. Se houver uma heurística para apps que combine o número de instalações, o número de caracteres no texto e o dia da semana, considere separar esses elementos e alimentar essas entradas no aprendizado separadamente. Algumas técnicas que se aplicam a ensembles se aplicam aqui (consulte Regra 40).
  • Modifique o rótulo. Essa é uma opção quando você acha que a heurística captura informações que não estão contidas no rótulo. Por exemplo, se você estiver tentando maximizar o número de downloads, mas também quiser conteúdo de qualidade, talvez a solução seja multiplicar o rótulo pelo número médio de estrelas que o app recebeu. Há muita margem aqui. Consulte Seu primeiro objetivo.

Esteja atento à complexidade adicional ao usar a heurística em um sistema de ML. O uso de heurísticas antigas no novo algoritmo de machine learning pode ajudar a criar uma transição suave, mas pense se há uma maneira mais simples de conseguir o mesmo efeito.

Monitoramento

Em geral, pratique a boa higiene, como tornar os alertas acionáveis e ter uma página de painel.

Regra 8: conheça os requisitos de atualização do seu sistema.

Qual vai ser a redução do desempenho se você tiver um modelo com um dia? Há uma semana? Um quarto de idade? Essas informações podem ajudar você a entender as prioridades do monitoramento. Se você perder uma qualidade significativa de um produto se o modelo não for atualizado por um dia, é recomendável que o engenheiro o observe continuamente. A maioria dos sistemas de veiculação de anúncios tem novos anúncios todos os dias e precisa ser atualizado diariamente. Por exemplo, se o modelo de ML para a Pesquisa do Google Play não for atualizado, ele poderá ter um impacto negativo em menos de um mês. Alguns modelos da seção "Em alta" do Google Plus não têm um identificador de postagem no modelo. Por isso, eles podem exportar esses modelos com pouca frequência. Outros modelos que têm identificadores de postagem são atualizados com muito mais frequência. Além disso, a atualização pode mudar com o tempo, principalmente quando colunas de atributos são adicionadas ou removidas do modelo.

Regra 9: detectar problemas antes de exportar modelos.

Muitos sistemas de machine learning têm um estágio em que você exporta o modelo para exibição. Se há um problema com um modelo exportado, ele é um problema para o usuário.

Faça verificações de integridade antes de exportar o modelo. Especificamente, verifique se o desempenho do modelo é razoável em dados retidos. Ou, se você tiver preocupações relacionadas aos dados, não exporte um modelo. Muitas equipes que implantam modelos continuamente verificam a área sob a curva ROC (ou AUC) antes de exportar. Problemas em modelos que não foram exportados exigem um alerta por e-mail, mas os problemas em um modelo voltado ao usuário podem exigir uma página. Portanto, espere antes de impactar os usuários.

Regra 10: fique de olho nas falhas silenciosas.

Esse problema ocorre mais nos sistemas de machine learning do que em outros tipos de sistemas. Suponha que uma tabela específica que está sendo unida não esteja mais sendo atualizada. O sistema de aprendizado de máquina vai se ajustar e o comportamento continua sendo razoavelmente bom, com uma redução gradual. Às vezes, você encontra tabelas desatualizadas, e uma atualização simples melhora o desempenho mais do que qualquer outro lançamento naquele trimestre. A cobertura de um recurso pode mudar devido a mudanças na implementação: por exemplo, uma coluna de atributo pode ser preenchida em 90% dos exemplos e cair repentinamente em 60% dos exemplos. O Google Play já teve uma tabela desatualizada por seis meses, e a atualização dela gerou um aumento de 2% na taxa de instalação. Se você acompanha as estatísticas dos dados, além de inspecionar manualmente os dados de vez em quando, é possível reduzir esses tipos de falhas.

Regra 11: forneça a documentação e os proprietários das colunas de atributos.

Se o sistema for grande e houver muitas colunas de atributo, saiba quem criou ou está mantendo cada coluna de atributo. Se você achar que a pessoa que entende uma coluna de atributo está saindo, verifique se alguém tem as informações. Embora muitas colunas de atributos tenham nomes descritivos, é bom ter uma descrição mais detalhada do que são os atributos, de onde eles vieram e como podem ajudar.

Seu primeiro objetivo

Você tem muitas métricas ou medições sobre o sistema de seu interesse, mas seu algoritmo de machine learning geralmente exigirá um único objetivo, um número que seu algoritmo está "tentando" otimizar. Aqui, distingo entre objetivos e métricas: uma métrica é qualquer número que seu sistema informa, o que pode ou não ser importante. Veja também Regra 2.

Regra 12: não exagere no objetivo que você decidir otimizar diretamente.

Você quer ganhar dinheiro, deixar seus usuários satisfeitos e tornar o mundo um lugar melhor. Há toneladas de métricas importantes, e você deve medir todas elas (veja a Regra 2). No entanto, no início do processo de machine learning, você vai perceber que todos avançam, mesmo aqueles que você não otimiza diretamente. Por exemplo, suponha que você se importe com o número de cliques e o tempo gasto no site. Se você otimiza para o número de cliques, é provável que o tempo gasto aumente.

Portanto, mantenha a simplicidade e não se preocupe muito com o equilíbrio de métricas diferentes quando você ainda puder aumentar facilmente todas as métricas. Não considere essa regra muito longe: não confunda seu objetivo com a integridade final do sistema. Consulte a Regra 39. Se você precisar aumentar a métrica otimizada diretamente, mas decidir não lançar, talvez seja necessário fazer uma revisão objetiva.

Regra 13: escolha uma métrica simples, observável e atribuível para seu primeiro objetivo.

Muitas vezes, você não sabe qual é o objetivo real. Você acha que sabe, mas encontrando os dados e a análise lado a lado do sistema antigo e do novo, você percebe que quer ajustar o objetivo. Além disso, membros diferentes da equipe geralmente não podem chegar a um acordo sobre o verdadeiro objetivo. O objetivo de ML precisa ser algo fácil de medir e que seja um indicador do objetivo "verdadeiro". Na verdade, geralmente não há um objetivo "verdadeiro". Consulte a Regra#39. Portanto, treine no objetivo simples de ML e considere ter uma "camada de política" na parte de cima que permita adicionar outra lógica (esperamos que seja muito simples) para fazer a classificação final.

O mais fácil é modelar um comportamento do usuário que é diretamente observado e atribuído a uma ação do sistema:

  • O link classificado foi clicado?
  • O download do objeto classificado foi feito?
  • Este objeto classificado foi encaminhado/respondido/enviado por e-mail?
  • Este objeto classificado foi classificado?
  • Este objeto mostrado foi marcado como spam/pornografia/ofensivo?

Evite modelar efeitos indiretos primeiro:

  • O usuário visitou no dia seguinte?
  • Por quanto tempo o usuário visitou o site?
  • Quais foram os usuários ativos por dia?

Os efeitos indiretos geram ótimas métricas e podem ser usados durante os testes A/B e nas decisões de lançamento.

Por fim, não tente fazer o aprendizado de máquina descobrir:

  • O usuário está satisfeito com o produto?
  • O usuário está satisfeito com a experiência?
  • O produto está melhorando o bem-estar geral do usuário?
  • Como isso afeta a saúde geral da empresa?

Todos esses fatores são importantes, mas também são incrivelmente difíceis de medir. Em vez disso, use proxies: se o usuário estiver feliz, ele ficará no site por mais tempo. Se o usuário estiver satisfeito, ele a visitará novamente amanhã. Em termos de bem-estar e integridade da empresa, o julgamento humano é necessário para conectar qualquer objetivo de aprendizado de máquina à natureza do produto que você está vendendo e ao seu plano de negócios.

Regra 14: começar com um modelo interpretável facilita a depuração.

Regressão linear, regressão logística e regressão de Poisson são motivadas diretamente por um modelo probabilístico. Cada previsão é interpretável como uma probabilidade ou um valor esperado. Isso facilita a depuração do que os modelos que usam objetivos (perda de um, várias perdas da articulação etc.) que tentam otimizar diretamente a precisão ou o desempenho da classificação. Por exemplo, se as probabilidades de treinamento se desviarem das probabilidades lado a lado ou inspecionando o sistema de produção, esse desvio poderá revelar um problema.

Por exemplo, na regressão linear, logística ou de Poisson, há subconjuntos de dados em que a expectativa média prevista é igual ao rótulo médio (1 momento calibrado ou apenas calibrado). Isso é feito considerando que você não tem regularização e que seu algoritmo convergiu, e é aproximadamente verdadeiro de modo geral. Se você tiver um atributo que seja 1 ou 0 para cada exemplo, o conjunto de três exemplos em que esse recurso é 1 será calibrado. Além disso, se você tiver um atributo igual a um para cada exemplo, o conjunto de todos os exemplos será calibrado.

Com modelos simples, é mais fácil lidar com os loops de feedback (consulte a Regra 36). Normalmente, usamos essas previsões probabilísticas para tomar uma decisão, por exemplo, classificar postagens em valor esperado decrescente (por exemplo, probabilidade de clique/download/etc.). No entanto, lembre-se de que, quando se trata de escolher qual modelo usar, a decisão é mais importante do que a probabilidade dos dados fornecidos ao modelo (consulte Regra 27).

Regra 15: separar a filtragem de spam e a classificação de qualidade em uma camada da política.

A classificação de qualidade é uma arte, mas a filtragem de spam é uma guerra. Os indicadores que você usa para determinar as postagens de alta qualidade se tornarão óbvios para quem usa seu sistema, e eles ajustarão as postagens para terem essas propriedades. Assim, a classificação de qualidade deve se concentrar na classificação do conteúdo postado de boa-fé. Não transfira o classificador de qualidade para ter uma classificação alta de spam. Da mesma forma, o conteúdo de " potencialmente ofensivo" precisa ser tratado separadamente do Classificação de qualidade. A filtragem de spam é diferente. Os recursos que você precisa gerar serão sempre alterados. Muitas vezes, há regras óbvias que você coloca no sistema. Se uma postagem tiver mais de três votos como spam, não faça a recuperação etc. Qualquer modelo aprendido precisará ser atualizado diariamente, ou até mais rápido. A reputação do criador do conteúdo terá um papel importante.

Em algum nível, a saída desses dois sistemas vai precisar ser integrada. Lembre-se de que a filtragem de spam nos resultados da pesquisa provavelmente será mais agressiva do que a filtragem de spam em mensagens de e-mail. Isso é feito considerando que você não tem regularização e que seu algoritmo convergiu. Em geral, é verdadeiro. Além disso, é uma prática padrão remover o spam dos dados de treinamento do classificador de qualidade.

Fase 2 do ML: engenharia de atributos

Na primeira fase do ciclo de vida de um sistema de machine learning, os problemas importantes são colocar os dados de treinamento no sistema de aprendizado, obter as métricas de interesse instrumentadas e criar uma infraestrutura de exibição. Depois de um sistema de ponta a ponta funcionando com testes de unidade e de sistema instrumentados, a Fase II começa.

Na segunda fase, há uma grande quantidade de frutas fáceis de preparar. Existem diversos atributos óbvios de recursos que podem ser inseridos no sistema. Assim, a segunda fase do machine learning envolve extrair o máximo possível de atributos e combiná-los de maneiras intuitivas. Durante essa fase, todas as métricas ainda devem estar aumentando. Haverá muitos lançamentos, e esse é um ótimo momento para aproveitar vários engenheiros que conseguem reunir todos os dados necessários para criar um sistema de aprendizado realmente incrível.

Regra 16: planejar o lançamento e a iteração.

Não espere que o modelo em que você está trabalhando agora seja o último a ser lançado ou que você nunca vai parar de lançar modelos. Portanto, considere se a complexidade que você está adicionando com esse lançamento deixará os lançamentos futuros mais lentos. Muitas equipes lançaram um modelo por trimestre ou mais por anos. Há três motivos básicos para lançar novos modelos:

  • Você está criando novos recursos.
  • Você está ajustando a regularização e combinando atributos antigos de novas maneiras.
  • Você está ajustando o objetivo.

Mesmo assim, dar um pouco de amor a um modelo pode ser bom: observar os dados que alimentam o exemplo ajuda a encontrar novos indicadores e os antigos, quebrados. Portanto, ao criar seu modelo, pense em como é fácil adicionar, remover ou recombinar atributos. Veja como é fácil criar uma nova cópia do pipeline e verificar a exatidão dele. Pense se é possível ter duas ou três cópias em execução em paralelo. Por fim, não se preocupe se o recurso 16 de 35 chegar a essa versão do pipeline. Você verá no próximo trimestre.

Regra 17: comece com atributos observados e informados diretamente em vez de aprendidos.

Esse pode ser um assunto controverso, mas evita muitos riscos. Primeiro, vamos descrever o que é um atributo aprendido. Ele é gerado por um sistema externo (como um sistema de clustering não supervisionado) ou pelo próprio aluno (por exemplo, por um modelo fatorado ou aprendizado profundo). Ambos podem ser úteis, mas podem ter muitos problemas, então eles não devem estar no primeiro modelo.

Se você usa um sistema externo para criar um recurso, lembre-se de que ele tem um objetivo próprio. O objetivo do sistema externo pode estar correlacionado facilmente com o objetivo atual. Se você capturar um snapshot do sistema externo, ele poderá ficar desatualizado. Se você atualizar os recursos do sistema externo, o significado pode mudar. Se você usa um sistema externo para fornecer um recurso, esteja ciente de que essa abordagem exige muito cuidado.

O principal problema com modelos fatorados e profundos é que eles não são convexos. Assim, não há garantia de que uma solução ideal possa ser aproximada ou encontrada, e o mínimo local encontrado em cada iteração pode ser diferente. Essa variação dificulta avaliar se o impacto de uma mudança no sistema é significativo ou aleatório. Ao criar um modelo sem recursos profundos, você pode ter um desempenho de referência excelente. Depois que esse grupo de referência for alcançado, você poderá testar abordagens mais esotéricas.

Regra 18: explorar recursos de conteúdo que generalizam os contextos.

Muitas vezes, um sistema de machine learning é uma parte menor de uma imagem muito maior. Por exemplo, se você imaginar uma postagem que possa ser usada no Hot, muitas pessoas vão compartilhar com +1, compartilhar ou comentar em uma postagem antes que ela seja exibida no What's Hot. Se você fornecer essas estatísticas ao aluno, ele poderá promover novas postagens para as quais não tem dados no contexto da otimização. O canal YouTube "Assistir a seguir" pode usar o número de visualizações ou co visualizações, ou seja, quantas vezes um vídeo foi assistido após o vídeo de outro, a partir da pesquisa do YouTube. Também é possível usar classificações explícitas de usuários. Por fim, se você tem uma ação do usuário que usa como rótulo, ver essa ação no documento em um contexto diferente pode ser um ótimo recurso. Todos esses recursos permitem trazer conteúdo novo para o contexto. Observe que isso não se trata de personalização: descubra se alguém gosta do conteúdo nesse contexto primeiro e, em seguida, descubra quem gosta mais ou menos.

Regra 19: use recursos muito específicos quando puder.

Com toneladas de dados, é mais simples aprender milhões de recursos simples do que alguns recursos complexos. Os identificadores de documentos que estão sendo recuperados e as consultas canônicas não fornecem muita generalização, mas alinham sua classificação com os rótulos nas consultas principais. Assim, não tenha medo de grupos de recursos em que cada um deles se aplica a uma fração muito pequena dos seus dados, mas a cobertura geral é superior a 90%. É possível usar a regularização para eliminar os atributos que se aplicam a poucos exemplos.

Regra 20: combine e modifique atributos existentes para criar novos atributos de uma forma compreensível.

Há várias maneiras de combinar e modificar atributos. Sistemas de machine learning, como o TensorFlow, permitem pré-processar seus dados com transformações. As duas abordagens mais padrão são "discretizações" e "cruzamentos".

A discretização consiste em usar um atributo contínuo e criar vários atributos discretos dele. Considere um atributo contínuo, como idade. Você pode criar um atributo 1 quando a idade for inferior a 18 anos, outro atributo que é 1 quando a idade estiver entre 18 e 35 anos etc. Não pense demais sobre os limites desses histogramas: os quantis básicos terão a maior parte do impacto.

Os cruzamentos combinam duas ou mais colunas de atributos. Uma coluna de atributo, na terminologia do TensorFlow, é um conjunto homogêneo de atributos, por exemplo, {male, female}, {US, Canada, Mexico} etc. Uma cruz é uma nova coluna de atributo com atributos em, por exemplo, {male, female} × {US,Canada, México}. Essa nova coluna de atributo incluirá o atributo (masculino, Canadá). Se você usa o TensorFlow e diz ao TensorFlow para criar essa cruz para você, esse recurso (masculino, Canadá) estará presente em exemplos que representam canadenses. Observe que são necessárias quantidades enormes de dados para aprender modelos com três, quatro ou mais colunas de atributos base.

As cruzes que produzem colunas de atributos muito grandes podem sofrer overfitting. Por exemplo, imagine que você esteja fazendo algum tipo de pesquisa e tenha uma coluna de atributo com palavras na consulta e uma coluna de atributo com palavras no documento. É possível combiná-los com um cruzamento, mas você terá muitos recursos. Consulte a Regra 21.

Ao trabalhar com texto, há duas alternativas. O mais dramático é o produto pontual. Um produto de ponto na forma mais simples conta o número de palavras em comum entre a consulta e o documento. Em seguida, esse atributo pode ser discretizado. Outra abordagem é uma interseção: assim, teremos um atributo presente se e somente se a palavra "pônei" estiver no documento e na consulta, e outro recurso se estiver presente se e somente a palavra "o" estiver no documento e na consulta.

Regra 21: o número de pesos de atributos que você pode aprender em um modelo linear é aproximadamente proporcional à quantidade de dados que você tem.

Há resultados fascinantes de teoria de aprendizagem em relação ao nível apropriado de complexidade para um modelo, mas essa regra é basicamente tudo o que você precisa saber. Tenho conversas em que as pessoas estão em dúvida de que algo pode ser aprendido com mil exemplos ou que você precisaria de mais de um milhão de exemplos, porque eles ficam presos em um determinado método de aprendizado. O segredo é dimensionar seu aprendizado para o tamanho dos seus dados:

  1. Se você estiver trabalhando em um sistema de classificação de pesquisa e houver milhões de palavras diferentes nos documentos e na consulta e tiver 1.000 exemplos rotulados, use um produto de ponto entre os atributos de documentos e consultas, o TF-IDF, e dezenas de outros atributos de engenharia humana. 1.000 exemplos, uma dúzia de atributos.
  2. Se você tiver um milhão de exemplos, cruze o documento e consulte as colunas de atributos usando regularização e, possivelmente, seleção de atributos. Isso fornecerá milhões de atributos, mas com a regularização você terá menos. Dez milhões de exemplos, talvez centenas de milhares de atributos.
  3. Se você tiver bilhões ou centenas de bilhões de exemplos, poderá cruzar as colunas de atributo com tokens de documentos e consultas usando a seleção e regularização de atributos. Você vai ter um bilhão de exemplos e 10 milhões de atributos. A teoria do aprendizado estatístico raramente apresenta limites, mas oferece ótimas orientações para um ponto de partida.

No final, use a Regra 28 para decidir quais recursos usar.

Regra 22: limpe os recursos que você não está mais usando.

Atributos não utilizados criam dívida técnica. Se você descobrir que não está usando um recurso e que combiná-lo com outros recursos não está funcionando, remova-o da infraestrutura. Você quer manter sua infraestrutura limpa para que os recursos mais promissores sejam testados o mais rápido possível. Se necessário, outra pessoa pode adicionar novamente o recurso.

Lembre-se da cobertura ao considerar quais recursos adicionar ou manter. Quantos exemplos são cobertos pelo recurso? Por exemplo, se você tiver alguns recursos de personalização, mas apenas 8% dos usuários tiverem recursos de personalização, isso não vai ser muito eficaz.

Ao mesmo tempo, alguns recursos podem estar acima do peso. Por exemplo, se você tem um recurso que abrange apenas 1% dos dados, mas 90% dos exemplos que o contêm são positivos, então é um recurso excelente para adicionar.

Análise humana do sistema

Antes de avançar para a terceira fase do machine learning, é importante se concentrar em algo que não é ensinado em nenhuma classe de machine learning: como analisar e melhorar um modelo atual. Isso é mais uma arte do que uma ciência, mas existem vários antipadrões que podem ajudar a evitar isso.

Regra 23: você não é um usuário final típico.

Essa talvez seja a forma mais fácil de ficar para trás. Embora existam muitos benefícios em se alimentar (usando um protótipo na sua equipe) e foodfood (usando um protótipo na sua empresa), os funcionários devem verificar se o desempenho está correto. Embora uma mudança que obviamente seja ruim não possa ser usada, qualquer coisa que pareça razoavelmente próxima da produção deve ser testada ainda mais, seja pagando leigos para responder a perguntas em uma plataforma de crowdsourcing ou por meio de um experimento ao vivo em usuários reais.

Há dois motivos para isso acontecer. A primeira é que você está muito perto do código. Talvez você esteja procurando uma determinada característica das postagens ou tenha um envolvimento emocional demais (por exemplo, viés de confirmação). O segundo é que seu tempo é muito valioso. Considere o custo de nove engenheiros sentados em uma reunião de uma hora e pense em quantos rótulos humanos contratados que compram em uma plataforma de crowdsourcing.

Se você quer receber feedback de usuários, use as metodologias de experiência do usuário. Crie perfis de usuário (uma descrição está em Sketching User Experiences, de Bill Buxton) no início do processo e faça o teste de usabilidade (uma descrição está em Don't Make Me Think) de Steve Krug). Os perfis de usuário envolvem a criação de um usuário hipotético. Por exemplo, se sua equipe é toda masculina, pode ser útil criar um perfil de usuário de 35 anos com recursos para usuários e analisar os resultados gerados em vez de 10 para homens de 25 a 40 anos. Trazer as pessoas reais para assistir à reação do seu site (local ou remotamente) em testes de usabilidade também pode trazer uma nova perspectiva.

Regra 24: meça o delta entre modelos.

Uma das medições mais fáceis e, às vezes, mais úteis que você pode fazer antes de qualquer usuário analisar o novo modelo é calcular como os novos resultados são diferentes da produção. Por exemplo, se você tiver um problema de classificação, execute os dois modelos em uma amostra de consultas em todo o sistema e veja o tamanho da diferença simétrica dos resultados, ponderada pela posição de classificação. Se a diferença for muito pequena, é possível dizer sem realizar um experimento que haverá uma pequena mudança. Se a diferença for muito grande, então garanta que a mudança seja boa. Analisar as consultas em que a diferença simétrica é alta pode ajudar você a entender qualitativamente a mudança. No entanto, verifique se o sistema está estável. Verifique se um modelo comparado a ele tem uma diferença simétrica baixa (o ideal é zero).

Regra 25: ao escolher modelos, o desempenho utilitário supera o poder preditivo.

Seu modelo pode tentar prever a taxa de cliques. No entanto, no fim, a principal pergunta é o que você faz com essa previsão. Se você a estiver usando para classificar documentos, a qualidade da classificação final vai ser mais importante do que a própria previsão. Se você previu a probabilidade de um documento ser spam e, em seguida, estabelecer um limite para o que é bloqueado, a precisão do que é permitido é mais importante. Na maioria das vezes, as duas coisas precisam estar de acordo: quando não concordam, é provável que tenha um pequeno ganho. Assim, se houver uma alteração que melhora a perda de registro, mas degrada o desempenho do sistema, procure outro recurso. Quando isso começar a acontecer com mais frequência, é hora de revisitar o objetivo do modelo.

Regra 26: procurar padrões nos erros medidos e criar novos atributos.

Suponha que você veja um exemplo de treinamento de que o modelo recebeu "errado". Em uma tarefa de classificação, esse erro pode ser um falso positivo ou falso negativo. Em uma tarefa de classificação, o erro pode ser um par em que um positivo foi classificado como menor que um negativo. O ponto mais importante é que esse é um exemplo de que o sistema de machine learning sabe que houve um erro e quer corrigir se tiver a oportunidade. Se você fornecer ao modelo um recurso que permita corrigir o erro, o modelo tentará usá-lo.

Por outro lado, se você tentar criar um recurso com base em exemplos que o sistema não vê como erros, ele será ignorado. Por exemplo, suponha que, na Pesquisa de apps do Google Play, alguém pesquise "jogos sem custo financeiro". Suponha que um dos principais resultados seja um app gag menos relevante. Você cria um recurso para "apps gag". No entanto, se você estiver maximizando o número de instalações e as pessoas instalarem um app gag quando pesquisarem jogos sem custo financeiro, o recurso "apps gag" não terá o efeito desejado.

Quando tiver exemplos de que o modelo deu errado, procure tendências fora do conjunto de recursos atual. Por exemplo, se o sistema parece estar rebaixando as postagens mais longas, adicione a duração da postagem. Não seja muito específico sobre os recursos adicionados. Se você for adicionar o comprimento da postagem, não tente adivinhar o que significa isso, apenas adicione uma dúzia de recursos e o modelo vai descobrir o que fazer com eles (consulte a Regra 21). Essa é a maneira mais fácil de conseguir o que você quer.

Regra 27: tente quantificar o comportamento indesejado.

Alguns membros da equipe ficarão frustrados com as propriedades do sistema de que não gostam e que não forem capturadas pela função de perda atual. Neste ponto, ele deve fazer o que for necessário para transformar as manchas em números sólidos. Por exemplo, se eles pensarem que muitos "apps de gag" estão sendo exibidos na Pesquisa Google, eles podem ter avaliadores humanos identificando apps de gag. Nesse caso, é possível usar dados rotulados por humanos porque uma fração relativamente pequena das consultas representa uma grande fração do tráfego. Se os problemas forem mensuráveis, comece a usá-los como recursos, objetivos ou métricas. A regra geral é "meça primeiro, otimize depois".

Regra 28: comportamento idêntico de curto prazo não implica um comportamento idêntico de longo prazo.

Imagine que você tenha um novo sistema que analisa cada doc_id eexact_query e calcula a probabilidade de cliques de cada documento para cada consulta. Você descobre que o comportamento dele é quase idêntico ao do sistema atual em ambos os lados e nos testes A/B. Portanto, ele é iniciado pela simplicidade. No entanto, nenhum novo app está sendo exibido. Sabe por quê? Como o sistema mostra um documento apenas com base no histórico dele com essa consulta, não há como saber se um novo documento vai ser mostrado.

A única maneira de entender como esse sistema funciona a longo prazo é fazer com que ele seja treinado apenas com os dados adquiridos quando o modelo estava ativo. Isso é muito difícil.

Desvio de treinamento para exibição

O desvio de treinamento/exibição é uma diferença entre o desempenho durante o treinamento e o desempenho durante a disponibilização. Esse desvio pode ser causado por:

  • Há uma discrepância entre o processamento de dados nos pipelines de treinamento e de disponibilização.
  • Mudança nos dados entre o treinamento e a veiculação.
  • Um loop de feedback entre seu modelo e seu algoritmo.

Observamos sistemas de machine learning de produção no Google com desvio de serviço de treinamento que afeta negativamente o desempenho. A melhor solução é monitorá-la explicitamente, para que as alterações no sistema e nos dados não introduzam desvios despercebidos.

Regra 29: a melhor maneira de garantir o treinamento como será exibido é salvar o conjunto de atributos usados no momento da exibição e canalizar esses atributos em um registro para usá-los no momento do treinamento.

Mesmo que não seja possível fazer isso para todos os exemplos, faça isso para uma fração pequena, de modo que possa verificar a consistência entre a exibição e o treinamento (consulte Regra 37). As equipes que fizeram essa medição no Google às vezes ficaram surpresas com os resultados. A página inicial do YouTube mudou para os recursos de geração de registros no momento da exibição com melhorias significativas de qualidade e redução na complexidade do código, e muitas equipes estão mudando de infraestrutura conforme falamos.

Regra 30: dados de amostragem de importância, não os exclua arbitrariamente

Quando você tem dados demais, há uma tentação de selecionar os arquivos de 1 a 12 e ignorar os arquivos de 13 a 99. Isso não está certo. Embora os dados que nunca foram mostrados ao usuário possam ser descartados, a ponderação de importância é melhor para o restante. Ponderação de importância significa que, se decidir que vai fazer uma amostra do exemplo X com 30% de probabilidade, dê a ele um peso de 10/3. Com a ponderação de importância, todas as propriedades de calibração discutidas na Regra 14 ainda são válidas.

Regra 31: se você mesclar os dados de uma tabela no momento do treinamento e da disponibilização, os dados da tabela poderão ser alterados.

Digamos que você mescle IDs do documento com uma tabela contendo recursos para esses documentos (como número de comentários ou cliques). Entre o treinamento e o tempo de exibição, os atributos na tabela podem ser alterados. Dessa forma, a previsão do seu modelo para o mesmo documento pode ser diferente entre treinamento e disponibilização. A maneira mais fácil de evitar esse tipo de problema é registrar os atributos no momento da disponibilização (consulte a Regra 32 ). Se a tabela estiver sendo alterada lentamente, também é possível criar um snapshot da tabela por hora ou por dia para receber dados razoavelmente razoáveis. Observe que isso ainda não resolve o problema completamente.

Regra 32: reutilizar código entre o pipeline de treinamento e o pipeline de exibição sempre que possível.

O processamento em lote é diferente do processamento on-line. No processamento on-line, você precisa processar cada solicitação assim que ela chega (por exemplo, é necessário fazer uma pesquisa separada para cada consulta). Já no processamento em lote, é possível combinar tarefas (por exemplo, fazer uma mesclagem). No momento da disponibilização, você está realizando processamento on-line, enquanto o treinamento é uma tarefa de processamento em lote. No entanto, há algumas coisas que você pode fazer para reutilizar o código. Por exemplo, é possível criar um objeto específico para seu sistema em que o resultado de quaisquer consultas ou mesclagens possa ser armazenado de maneira legível e os erros possam ser testados com facilidade. Depois de coletar todas as informações, durante a disponibilização ou o treinamento, execute um método comum para fazer a ponte entre o objeto legível do usuário que é específico do sistema e o formato esperado pelo sistema de machine learning. Isso elimina uma fonte de desvio de treinamento/disponibilização. Como corolário, tente não usar duas linguagens de programação diferentes entre treinamento e disponibilização. Com isso, será quase impossível compartilhar o código.

Regra 33: se você produzir um modelo com base nos dados até 5 de janeiro, teste-o nos dados a partir de 6 de janeiro.

Em geral, meça o desempenho de um modelo nos dados coletados após os dados treinados, já que isso reflete melhor o que o sistema vai fazer na produção. Se você produzir um modelo com base nos dados até 5 de janeiro, teste o modelo nos dados de 6 de janeiro. Você vai esperar que o desempenho não seja tão bom quanto os novos dados, mas não pode ser radicalmente pior. Como pode haver efeitos diários, é possível não prever a taxa de cliques ou a taxa de conversão média, mas a área sob a curva, que representa a probabilidade de dar ao exemplo positivo uma pontuação maior do que um exemplo negativo, deve estar razoavelmente próxima.

Regra 34: na classificação binária para filtragem (como detecção de spam ou determinação de e-mails interessantes), faça pequenos sacrifícios de curto prazo no desempenho para dados muito limpos.

Em uma tarefa de filtragem, os exemplos marcados como negativos não são mostrados ao usuário. Digamos que você tenha um filtro que bloqueia 75% dos exemplos negativos na veiculação. Pode ser tentador coletar mais dados de treinamento das instâncias mostradas aos usuários. Por exemplo, se um usuário marcar um e-mail como spam que o filtro permite, talvez você queira aprender com ele.

No entanto, essa abordagem introduz um viés de amostragem. É possível coletar dados mais limpos se, em vez disso, você marcar 1% de todo o tráfego como "retido" e enviar todos os exemplos ocultos para o usuário. Agora, seu filtro está bloqueando pelo menos 74% dos exemplos negativos. Estes exemplos retidos podem se tornar seus dados de treinamento.

Se o filtro estiver bloqueando 95% ou mais dos exemplos negativos, essa abordagem vai ser menos viável. Mesmo assim, se você quiser medir o desempenho da disponibilização, poderá criar uma amostra mais colorida (por exemplo, 0,1% ou 0,001%). 10.000 exemplos são suficientes para estimar o desempenho com bastante precisão.

Regra 35: cuidado com o desvio inerente nos problemas de classificação.

Ao mudar o algoritmo de classificação de forma radical o suficiente para mostrar resultados diferentes, você mudou os dados que o algoritmo verá no futuro. Esse tipo de distorção vai aparecer, e você precisa criar o modelo com base nele. Há várias abordagens diferentes. Essas abordagens são todas as maneiras de favorecer os dados que seu modelo já viu.

  1. tenham uma regularização mais alta em recursos que abrangem mais consultas, em vez dos recursos que estão ativados em apenas uma consulta. Assim, o modelo favorece recursos específicos de uma ou algumas consultas em vez de recursos que generalizam para todas as consultas. Essa abordagem pode ajudar a evitar o vazamento de resultados muito comuns em consultas irrelevantes. Isso é o oposto do conselho mais convencional de ter mais regularização em colunas de atributos com valores mais exclusivos.
  2. Permitir que apenas atributos tenham pesos positivos. Assim, qualquer bom atributo será melhor do que um recurso "desconhecido".
  3. não têm recursos somente para documentos. Esta é uma versão extrema do no 1. Por exemplo, mesmo que um determinado app seja um download conhecido, independentemente da consulta, não convém aparecer em todos os lugares. A falta de recursos somente para documentos facilita o processo. O motivo pelo qual você não quer mostrar um app específico em alta em todos os lugares está relacionado à importância de tornar todos os apps desejados acessíveis. Por exemplo, se alguém pesquisar "app de observação de pássaros", poderá fazer o download de "pássaros raivosos", mas essa com certeza não é a intenção dele. Mostrar esse app pode melhorar a taxa de download, mas deixar as necessidades do usuário insatisfeitas.

Regra 36: evite loops de feedback com recursos de posicionamento.

A posição do conteúdo afeta drasticamente a probabilidade de o usuário interagir com ele. Se você colocar um app na primeira posição, ele vai receber mais cliques e você vai se convencer. Uma maneira de lidar com isso é adicionar recursos posicionais, ou seja, recursos sobre a posição do conteúdo da página. Você treina o modelo com atributos posicionais e ele aprende a ponderar, por exemplo, o atributo "1stposition" com frequência. Seu modelo dá menos peso a outros fatores, por exemplo, com "1stposition=true". Na exibição, não é necessário conceder às instâncias o recurso posicional, nem dar a elas o mesmo recurso padrão, porque você pontua os candidatos antes de decidir a ordem em que serão exibidos.

É importante manter os atributos posicionais um pouco separados do restante do modelo, devido a essa assimetria entre treinamento e teste. O ideal é que o modelo seja a soma de uma função dos atributos posicionais e uma função do restante dos atributos. Por exemplo, não faça o mesmo.

Regra 37: medir o desvio de treinamento/exibição.

Há diversos fatores que podem causar distorções no sentido mais geral. Além disso, você pode dividi-lo em várias partes:

  • A diferença entre o desempenho nos dados de treinamento e os dados de validação. Em geral, isso sempre existe e nem sempre é ruim.
  • A diferença entre o desempenho nos dados de validação e os dados de "dia seguinte". Isso sempre vai existir. Ajuste sua regularização para maximizar o desempenho no dia seguinte. No entanto, grandes quedas no desempenho entre os dados de validação e do dia seguinte podem indicar que alguns recursos são sensíveis ao tempo e, possivelmente, degradam o desempenho do modelo.
  • A diferença entre o desempenho nos dados de "dia seguinte" e dos dados ativos. Se você aplicar um modelo a um exemplo nos dados de treinamento e usar o mesmo exemplo na disponibilização, ele terá o mesmo resultado (consulte a Regra 5). Portanto, uma discrepância provavelmente indica um erro de engenharia.

Fase 3 do ML: crescimento lento, refinamento de otimização e modelos complexos

Haverá certas indicações de que a segunda fase está chegando ao fim. Primeiro, seus ganhos mensais começarão a diminuir. Você vai começar a ter compensações entre as métricas: vai notar um aumento e outros em alguns experimentos. É aí que fica interessante. Como os ganhos são mais difíceis de alcançar, o aprendizado de máquina precisa ficar mais sofisticado. Advertência: esta seção tem mais regras de céu azul do que as seções anteriores. Muitas equipes passaram pelos momentos positivos das fases 1 e 2 do machine learning. Quando a Fase III for alcançada, as equipes precisarão encontrar o próprio caminho.

Regra 38: não perca tempo com novos recursos se objetivos não alinhados se tornaram o problema.

À medida que a performance das medições é alcançada, a equipe começa a analisar problemas que estão fora do escopo dos objetivos atuais do seu sistema de machine learning. Como mencionado anteriormente, se as metas do produto não forem cobertas pelo objetivo algorítmico existente, será necessário alterar as metas de produtos ou o objetivo. Por exemplo, é possível otimizar cliques, marcações com +1 ou downloads, mas tomar decisões de lançamento com base em parte dos avaliadores humanos.

Regra 39: as decisões de lançamento são um indicador para as metas do produto a longo prazo.

Alice tem uma ideia sobre como reduzir a perda logística de previsões de instalações. Ela adiciona um recurso. A perda logística vai cair. Ao fazer um experimento ao vivo, ela vê o aumento da taxa de instalação. No entanto, ao participar de uma reunião de revisão de lançamento, alguém aponta que o número de usuários ativos por dia cai em 5%. A equipe decide não lançar o modelo. Alice está decepcionada, mas agora percebe que as decisões de lançamento dependem de vários critérios. Somente alguns deles podem ser otimizados diretamente usando ML.

A verdade é que o mundo real não é masmorras e dragões: não há "pontos de hit" que identifiquem a saúde do seu produto. A equipe precisa usar as estatísticas coletadas para tentar prever o desempenho do sistema no futuro. Ele precisa se preocupar com engajamento, usuários ativos por 1 dia (DAU), 30 DAU, receita e retorno do investimento do anunciante. Essas métricas mensuráveis nos testes A/B por si só são um indicador de metas mais duradouras: satisfação de usuários, aumento de usuários, satisfação de parceiros e lucro. Isso significa que ainda é possível usar proxies para ter um produto útil e de alta qualidade, além de uma empresa próspera daqui a cinco anos.

As únicas decisões fáceis são quando as métricas melhoram ou pelo menos não pioram. Se a equipe tiver a opção entre um algoritmo de machine learning sofisticado e uma heurística simples, se a heurística simples fizer um trabalho melhor em todas essas métricas, ela precisará escolher a heurística. Além disso, não há classificação explícita de todos os valores de métricas possíveis. Especificamente, considere estes dois cenários:

Experimento Usuários ativos por dia Receita/dia
R 1 milhão US$ 4 milhões
B 2 milhões US$ 2 milhões

Se o sistema atual for A, é improvável que a equipe mude para B. Se o sistema atual for B, é improvável que a equipe mude para A. Isso parece conflito com o comportamento racional. No entanto, as previsões de alteração de métricas podem ou não movimentar e, portanto, há um grande risco envolvido com qualquer uma das alterações. Cada métrica abrange algum risco com o qual a equipe está preocupada.

Além disso, nenhuma métrica abrange a principal preocupação da equipe: "Qual é o destino do meu produto daqui a cinco anos?"

Por outro lado, os indivíduos tendem a favorecer um objetivo que eles podem otimizar diretamente. A maioria das ferramentas de machine learning favorece esse ambiente. Um engenheiro que proíbe novos recursos pode conseguir um fluxo constante de lançamentos nesse ambiente. Há um tipo de machine learning, aprendizado de vários objetivos, que começa a resolver esse problema. Por exemplo, é possível formular um problema de satisfação de restrição que tenha limites menores em cada métrica e otimizar algumas combinações lineares de métricas. Mesmo assim, nem todas as métricas são facilmente enquadradas como objetivos de machine learning: se um documento clicar ou um app for instalado, é porque o conteúdo foi mostrado. No entanto, é muito mais difícil descobrir por que um usuário visita seu site. A forma de prever o sucesso futuro de um site como um todo é concluída por IA: tão difícil quanto a visão do computador ou o processamento de linguagem natural.

Regra 40: mantenha os conjuntos simples.

Os modelos unificados que usam atributos brutos e classificam o conteúdo diretamente são os modelos mais fáceis de depurar e entender. No entanto, um ensemble de modelos (um "modelo" que combina as pontuações de outros modelos) pode funcionar melhor. Para simplificar, cada modelo precisa ser um ensemble que aceite apenas a entrada de outros, ou um modelo de base precisa de muitos atributos, mas não de ambos. Se você tiver modelos em cima de outros modelos treinados separadamente, a combinação deles pode resultar em um mau comportamento.

Use um modelo simples para ensembling, que usa apenas a saída dos seus modelos "básicos" como entradas. Você também quer aplicar propriedades nesses modelos do ensemble. Por exemplo, um aumento na pontuação produzido por um modelo base não precisa diminuir a pontuação do conjunto. Além disso, é melhor que os modelos recebidos sejam semanticamente interpretáveis (por exemplo, calibrados) para que as alterações dos modelos subjacentes não confundam o modelo ensemble. Além disso, a aplicação do aumento na probabilidade prevista de um classificador subjacente não diminui a probabilidade prevista do conjunto.

Regra 41: durante a análise de desempenho, procure novas fontes de informação qualitativamente para adicionar em vez de refinar os indicadores existentes.

Você adicionou algumas informações demográficas sobre o usuário. Você adicionou algumas informações sobre as palavras no documento. Você passou pela exploração de modelos e ajustou a regularização. Você não viu um lançamento com uma melhoria de mais de 1% nas principais métricas em alguns trimestres. E agora?

É hora de começar a construir a infraestrutura para recursos radicalmente diferentes, como o histórico de documentos que esse usuário acessou no último dia, semana ou ano, ou dados de uma propriedade diferente. Use entidades do wikidata ou algo interno à sua empresa, como o Mapa de informações do Google. Use o aprendizado profundo. Comece a ajustar as expectativas sobre o retorno do investimento esperado e amplie os esforços. Como em qualquer projeto de engenharia, é preciso considerar a vantagem de adicionar novos atributos ao custo de maior complexidade.

Regra 42: não espere que a diversidade, a personalização ou a relevância sejam tão correlacionadas com a popularidade como você acha que são.

A diversidade em um conjunto de conteúdos pode significar muitas coisas, com a diversidade da origem do conteúdo sendo uma das mais comuns. A personalização implica que cada usuário recebe os próprios resultados. A relevância implica que os resultados para uma determinada consulta são mais apropriados para essa consulta do que qualquer outro. Portanto, essas três propriedades são definidas como diferentes do comum.

O problema é que ele costuma ser difícil de superar.

Se o sistema estiver medindo cliques, tempo gasto, smartwatches, marcações com +1, novos compartilhamentos etc., a popularidade do conteúdo vai ser medida. Às vezes, as equipes tentam aprender um modelo pessoal com diversidade. Para personalizá-los, eles adicionam recursos que permitem ao sistema personalizar (alguns recursos que representam o interesse do usuário) ou diversificam (recursos que indicam se este documento tem recursos em comum com outros documentos retornados, como autor ou conteúdo) e descobrem que esses recursos têm menos peso (ou às vezes um sinal diferente) do que o esperado.

Isso não significa que diversidade, personalização ou relevância não são valiosas. Como mencionado na regra anterior, é possível fazer o pós-processamento para aumentar a diversidade ou relevância. Se você notar que objetivos de longo prazo aumentam, é possível declarar que a diversidade/relevância é valiosa, além da popularidade. É possível continuar usando o pós-processamento ou modificar diretamente o objetivo com base na diversidade ou relevância.

Regra 43: seus amigos tendem a ser os mesmos em produtos diferentes. Seus interesses tendem a não ser.

As equipes do Google ganharam bastante tempo desde que adotaram um modelo para prever a proximidade de uma conexão em um produto e fazer com que ele funcionasse bem em outro. Seus amigos são quem eles são. Por outro lado, já assisti a várias equipes com dificuldade nos recursos de personalização em diferentes divisões de produtos. Sim, parece que deveria funcionar. Por enquanto, parece que não. Às vezes funcionamos usando dados brutos de uma propriedade para prever o comportamento em outra. Além disso, mesmo saber que um usuário tem um histórico em outra propriedade pode ajudar. Por exemplo, a presença da atividade do usuário em dois produtos pode indicar por conta própria.

Há muitos documentos sobre aprendizado de máquina no Google e externamente.

Agradecimentos

Graças a David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Andifa, Guilherme de Andrade Além disso, graças a Kristen Lefevre, Suddha Basu e Chris Berg, que ajudaram com uma versão anterior. Qualquer erro, omissão ou opinião confusa pode ser meu.

Apêndice

Há várias referências a produtos do Google neste documento. Para mais contexto, vou fornecer uma breve descrição dos exemplos mais comuns abaixo.

Visão geral do YouTube

O YouTube é um serviço de streaming de vídeo. As equipes do YouTube Watch Next e da página inicial do YouTube usam modelos de ML para classificar as recomendações. O canal "Assistir a seguir" recomenda vídeos para serem assistidos após a reprodução atual. Já a página inicial recomenda vídeos para usuários que navegam na página inicial.

Visão geral do Google Play

O Google Play tem muitos modelos que resolvem vários problemas. A pesquisa do Google Play, as recomendações personalizadas da página inicial do Google Play e os apps "Usuários também instalados" usam machine learning.

Visão geral do Google+

O Google+ usou machine learning em várias situações: classificando as postagens no fluxo de postagens vistas pelo usuário, classificando as postagens "demais" (muitos conhecidas no momento), classificando pessoas que você conhece, entre outros. O Google Plus encerrou todas as contas pessoais em 2019 e foi substituído pelo Google Currents para contas empresariais em 6 de julho de 2020.