Regras do machine learning:

Práticas recomendadas para engenharia de ML

Martin Zinkevich (em inglês)

Este documento destina-se a ajudar quem tem um conhecimento básico de machine learning a aproveitar as práticas recomendadas do Google nessa área. Ele apresenta um estilo para machine learning, semelhante ao Guia de estilo do Google C++ e outros guias conhecidos de programação prática. Se você participou de uma aula sobre machine learning ou criou ou trabalhou em um modelo de aprendizado de máquina, já tem o conhecimento necessário para ler este documento.

Martin Zinkevich apresenta as 10 regras de machine learning que ele mais gosta. Continue lendo para conhecer as 43 regras.

Terminologia

Os seguintes termos são mencionados repetidamente na nossa discussão sobre machine learning eficaz:

  • Instância: o elemento sobre o qual você quer fazer 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".
  • Rótulo: uma resposta para uma tarefa de previsão, que pode ser 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".
  • Recurso: 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 possíveis em que os usuários podem residir. Um exemplo pode ter um ou mais atributos presentes em uma coluna de atributo. "Coluna de recursos" é a terminologia específica do Google. Uma coluna de atributos é chamada de "namespace" no sistema VW (no Yahoo/Microsoft) ou como 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 depois o usa para fazer previsões.
  • Métrica: um número que importa para você. Pode ser otimizado diretamente ou não.
  • Objetivo: uma métrica que seu algoritmo está tentando otimizar.
  • Pipeline: a infraestrutura que envolve um algoritmo de machine learning. Inclui a coleta dos dados do front-end, a inclusão deles em arquivos de dados de treinamento, o treinamento de um ou mais modelos e a exportação deles 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.

Informações gerais

Para criar ótimos produtos:

o machine learning como o grande engenheiro que você é, não o grande especialista em machine learning que você não é.

A maioria dos problemas que você enfrentará são, na verdade, problemas de engenharia. Mesmo com todos os recursos de um grande especialista em machine learning, a maioria dos ganhos vem de ótimos recursos, não ótimos algoritmos de machine learning. A abordagem básica é:

  1. Certifique-se de que seu pipeline esteja sólido de ponta a ponta.
  2. Comece com um objetivo razoável.
  3. Adicione recursos de senso comum de maneira simples.
  4. Confira se o pipeline continua sólido.

Essa abordagem funcionará bem por um longo período. Desvie dessa abordagem somente quando não houver mais truques simples para chegar mais longe. Essa complexidade torna as versões futuras mais lentas.

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

Este documento é organizado da seguinte maneira:

  1. A primeira parte ajuda a entender se é o momento certo para criar um sistema de machine learning.
  2. A segunda parte é sobre a implantação do primeiro pipeline.
  3. A terceira parte trata de iniciar e iterar enquanto adiciona novos recursos ao pipeline, como avaliar modelos e o desvio de treinamento/disponibilização.
  4. A parte final é sobre o que fazer quando você atingir um patamar.
  5. Em seguida, há uma lista de trabalhos relacionados e um apêndice com um histórico sobre os sistemas comumente usados como exemplos neste documento.

Antes do machine learning

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

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 terá um desempenho inferior à heuristics básica. Se você acha que o machine learning dará um impulso de 100%, uma heurística vai garantir 50% do caminho.

Por exemplo, se você estiver classificando apps em um marketplace, use a taxa ou o número de instalações como heurística. Se estiver detectando spam, filtre os editores que já enviaram spam antes. Não tenha medo de usar a edição humana. Se você precisar classificar contatos, classifique aqueles que foram usados mais recentemente com o maior valor (ou até mesmo em ordem alfabética). Se o aprendizado de máquina não for absolutamente necessário para seu produto, não o utilize até que tenha dados.

Regra no 2: primeiro, projete e implemente as métricas.

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

  1. É mais fácil obter permissão dos usuários do sistema no início.
  2. Se você acha que algo pode ser uma preocupação no futuro, é melhor conseguir dados históricos agora.
  3. Se você projetar seu sistema com a instrumentação métrica em mente, as coisas funcionarão melhor para você no futuro. Especificamente, você não quer se preocupar com strings nos 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 diretamente os usuários ativos por um dia. No entanto, durante as manipulações iniciais 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, compartilhamentos por leitura, mais um por leitura, comentários/leitura, comentários por usuário, compartilhamentos por usuário etc. que ela usa para calcular a qualidade de uma postagem no momento da exibição. Além disso, é importante ter um framework de experimento, em que é possível agrupar usuários em buckets e agregar estatísticas por experimento. Consulte a Regra no 12.

Ao ser mais livre na coleta de métricas, você pode ter uma visão mais ampla do seu sistema. Notou algum problema? Adicione uma métrica para fazer o acompanhamento. Animado com as mudanças quantitativas na última versão? Adicione uma métrica para fazer o acompanhamento.

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

Uma heurística simples pode divulgar seu produto. Não é possível manter uma heurística complexa. Depois de ter dados e uma ideia básica do que você está tentando realizar, passe para o machine learning. Como na maioria das tarefas de engenharia de software, convém atualizar constantemente sua abordagem, seja ela um modelo heurístico ou aprendido por máquina. Você descobrirá que é mais fácil atualizar e manter esse modelo (consulte a Regra no 16).

Fase I do ML: seu primeiro pipeline

Concentre-se na infraestrutura do sistema para seu primeiro pipeline. É divertido pensar em todo o aprendizado de máquina imaginativo que você vai fazer, mas será difícil descobrir o que está acontecendo se você não confiar no seu pipeline.

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

O primeiro modelo é a melhor opção para seu produto, então não precisa ser sofisticado. Mas você vai encontrar muito mais problemas de infraestrutura do que o espera. Antes que qualquer pessoa possa usar seu novo sistema de machine learning, você precisa determinar:

  • Como ver exemplos para seu algoritmo de aprendizado.
  • Um primeiro corte do que significa "bom" e "ruim" para seu sistema.
  • Como integrar o modelo ao aplicativo. É possível aplicar o modelo ativo ou pré-computá-lo em exemplos off-line e armazenar os resultados em uma tabela. Por exemplo, talvez você queira pré-classificar páginas da Web e armazenar os resultados em uma tabela, mas também classificar mensagens de chat em tempo real.

Quando você escolhe recursos simples, fica mais fácil garantir que:

  • Os atributos alcançam seu algoritmo de aprendizado corretamente.
  • O modelo aprende pesos razoáveis.
  • Os atributos alcançam seu modelo no servidor corretamente.

Com um sistema que faz essas três coisas de forma confiável, você já fez a maior parte do trabalho. O modelo simples oferece métricas de referência e um comportamento básico que pode ser usado para testar modelos mais complexos. Algumas equipes visam um primeiro lançamento "neutro: um primeiro que reduz explicitamente a prioridade dos ganhos do aprendizado de máquina para evitar distração".

Regra no 5: testar a infraestrutura independentemente 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 inserção de dados no algoritmo. Verifique se as colunas de atributos que precisam ser preenchidas estão preenchidas. Quando a privacidade permitir, inspecione manualmente a entrada no 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. Testar a extração de modelos do algoritmo de treinamento. Verifique se o modelo no ambiente de treinamento dá a mesma pontuação que o modelo no ambiente de serviço (consulte a Regra no 37).

O machine learning tem um elemento de imprevisibilidade. Portanto, faça testes do código para criar exemplos no treinamento e na disponibilização e se é possível carregar e usar um modelo fixo durante a disponibilização. Além disso, é importante entender seus dados: consulte Dicas práticas para a análise de conjuntos de dados grandes e complexos.

Regra no 6: ter cuidado com dados descartados ao copiar pipelines.

Muitas vezes, criamos um pipeline copiando um pipeline existente (ou seja, programação cargo cult) e o pipeline antigo descarta os dados necessários para o novo. Por exemplo, o pipeline do recurso Postagens interessantes do Google Plus descarta postagens mais antigas, porque ele tenta classificar postagens novas. Esse pipeline foi copiado para usar no stream do Google Plus, em que postagens mais antigas ainda são significativas, mas o pipeline ainda descartava postagens antigas. Outro padrão comum é registrar apenas os dados que foram vistos pelo usuário. Assim, esses dados são inúteis se quisermos modelar por que uma determinada postagem não foi vista pelo usuário, porque todos os exemplos negativos foram descartados. Um problema semelhante ocorreu no Google Play. Durante o trabalho na página inicial de 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 desambiguar a origem de cada exemplo.

Regra no 7: transformar a heurística em atributos ou tratá-las externamente.

Normalmente, os problemas que o machine learning está tentando resolver não são completamente novos. Já existe um sistema de classificação ou classificação, ou qualquer problema que você esteja tentando resolver. Isso significa que há um monte de regras e heurística. Essas mesmas heurísticas podem aumentar o desempenho quando ajustadas com machine learning. Sua heurística deve ser minerada por qualquer informação que elas tenham, por dois motivos. Primeiro, a transição para um sistema aprendido por máquina será mais suave. Segundo, geralmente essas regras contêm muita intuição sobre o sistema que você não quer descartar. Há quatro maneiras de usar uma heurística existente:

  • Fazer o pré-processamento usando a heurística. Se o recurso for incrivelmente incrível, essa é uma opção. Por exemplo, se o remetente já foi adicionado à lista de proibições em um filtro de spam, não tente reaprender o que significa "lista de proibições". Bloquear a mensagem. Essa abordagem faz mais sentido em tarefas de classificação binária.
  • Criar um atributo. É ótimo criar um atributo diretamente a partir da heurística. Por exemplo, se você usar uma heurística para calcular a pontuação de relevância de um resultado de consulta, poderá incluir a pontuação como o valor de um atributo. Mais tarde, é possível usar técnicas de machine learning para manipular o valor, por exemplo, converter o valor em um conjunto finito de valores discretos ou combiná-lo com outros atributos. No entanto, comece usando o valor bruto gerado pela heurística.
  • Extraia 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 essas partes e alimentar essas entradas no aprendizado separadamente. Algumas técnicas que se aplicam a conjuntos são aplicadas aqui (consulte a Regra no 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 no momento. Por exemplo, se você está tentando maximizar o número de downloads, mas também quer 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 de manobra aqui. Consulte Seu primeiro objetivo.

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

Monitoramento

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

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

Quanto o desempenho será prejudicado se você tiver um modelo com um dia? Tem uma semana? Um quarto de idade? Essas informações podem ajudar você a entender as prioridades do seu monitoramento. Se você perder a qualidade significativa do produto se o modelo não for atualizado por um dia, faz sentido que um engenheiro o acompanhe continuamente. A maioria dos sistemas de veiculação de anúncios tem novos anúncios para processar todos os dias e precisa ser atualizado diariamente. Por exemplo, se o modelo de ML da 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 "Postagens interessantes" no Google Plus não têm um identificador de postagem, então eles podem exportar esses modelos com pouca frequência. Outros modelos que têm identificadores de postagens são atualizados com muito mais frequência. Observe também que a atualização pode mudar com o tempo, especialmente 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 disponibilização. Se houver um problema com um modelo exportado, ele será voltado ao usuário.

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

Regra no 10: fique atento a falhas silenciosas.

Esse é um problema que ocorre mais para sistemas de machine learning do que para outros tipos de sistemas. Suponha que uma tabela específica que está sendo mesclada não esteja mais sendo atualizada. O sistema de machine learning vai se ajustar, e o comportamento vai continuar razoavelmente bom, diminuindo gradualmente. Às vezes, você encontra tabelas que estão meses desatualizadas, e uma atualização simples melhora a performance mais do que qualquer outro lançamento desse 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 repentinamente cair para 60% deles. O Google Play já teve uma tabela que ficava obsoleta por seis meses, e atualizar a tabela por si só aumentou a taxa de instalação em 2%. Se você rastrear as estatísticas dos dados e inspecionar os dados manualmente de vez em quando, poderá reduzir esses tipos de falhas.

Regra no 11: fornecer proprietários e documentação às colunas de atributos.

Se o sistema for grande e houver muitas colunas de atributos, saiba quem criou ou está mantendo cada coluna de atributo. Se você descobrir que a pessoa que entende uma coluna de atributo está saindo, certifique-se de que alguém tenha as informações. Embora muitas colunas de atributos tenham nomes descritivos, é bom ter uma descrição mais detalhada do que é o atributo, de onde ele veio e como deve ajudar.

Seu primeiro objetivo

Você tem muitas métricas ou medições sobre o sistema que são importantes para você, mas seu algoritmo de aprendizado de máquina geralmente exigirá um único objetivo, um número que o algoritmo está "tentando" otimizar. Aqui, eu diferencia objetivos e métricas: uma métrica é qualquer número que seu sistema informa, que pode ou não ser importante. Consulte também a Regra no 2.

Regra no 12: não pense demais sobre qual objetivo você quer otimizar diretamente.

Você quer ganhar dinheiro, deixar seus usuários felizes e fazer do mundo um lugar melhor. Há inúmeras métricas importantes para você, e é preciso medir todas elas (consulte a regra no 2). No entanto, no início do processo de machine learning, você perceberá que todos eles estão evoluindo, mesmo aqueles que não foram otimizados diretamente. Por exemplo, suponha que você se importe com o número de cliques e o tempo gasto no site. Se você otimizar para o número de cliques, o tempo gasto provavelmente aumentará.

Portanto, mantenha a simplicidade e não pense muito sobre o balanceamento de métricas diferentes, quando ainda é possível aumentar todas elas com facilidade. Não leve muito a sério essa regra: não confunda seu objetivo com a integridade final do sistema (consulte a Regra no 39). Além disso, se você aumentar a métrica otimizada diretamente, mas decidir não lançar, poderá ser necessário fazer uma revisão objetiva.

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

Muitas vezes, você não sabe qual é o verdadeiro objetivo, mas acha que sabe, mas, ao olhar para os dados e a análise lado a lado do seu antigo sistema e do novo sistema de ML, percebe que quer ajustar o objetivo. Além disso, diferentes membros da equipe muitas vezes não podem concordar sobre o verdadeiro objetivo. O objetivo de ML precisa ser algo fácil de medir e ser um substituto do objetivo "verdadeiro". Na verdade, muitas vezes não há objetivo "verdadeiro" (consulte a Regra no 39). Portanto, treine o objetivo de ML simples e considere ter uma "camada de políticas" na parte de cima que permita adicionar outra lógica (espera-se que seja uma lógica muito simples) para fazer a classificação final.

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

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

Evite modelar efeitos indiretos no começo:

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

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

Por fim, não tente fazer com que o machine learning descubra:

  • 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 afetará a saúde geral da empresa?

Elas são importantes, mas também extremamente difíceis de mensurar. Em vez disso, use proxies: se o usuário estiver satisfeito, ele permanecerá no site por mais tempo. Se o usuário estiver satisfeito, ele acessará novamente amanhã. Quanto ao bem-estar e à saúde da empresa, é necessário o julgamento humano para conectar qualquer objetivo aprendido pela máquina à natureza do produto que você está vendendo e ao seu plano de negócios.

Regra no 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 os torna mais fáceis de depurar do que modelos que usam objetivos (perda zero um, várias perdas de articulação e assim por diante) que tentam otimizar diretamente a precisão ou o desempenho da classificação. Por exemplo, se as probabilidades no treinamento forem diferentes das previstas lado a lado ou pela inspeção do 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 (um momento calibrado ou apenas calibrado). Isso é verdadeiro, supondo que você não tenha regularização e que seu algoritmo tenha converido, e é aproximadamente verdadeiro em 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 1 para cada exemplo, o conjunto de todos os exemplos será calibrado.

Com modelos simples, é mais fácil lidar com loops de feedback. Consulte a Regra no 36. Com frequência, usamos essas previsões para tomar uma decisão, como classificar postagens em valor esperado decrescente (ou seja, probabilidade de clique/download/etc.). No entanto, quando se trata de escolher qual modelo usar, a decisão importa mais do que a probabilidade dos dados considerando o modelo (consulte a Regra no 27).

Regra no 15: separar filtros de spam e classificação de qualidade em uma camada de políticas.

A classificação de qualidade é uma arte, mas a filtragem de spam é uma guerra. Os indicadores usados para determinar postagens de alta qualidade se tornarão óbvios para aqueles que usam seu sistema, e eles vão ajustar as postagens para ter essas propriedades. Assim, sua classificação de qualidade precisa se concentrar na classificação do conteúdo postado de boa fé. Não desconsidere o aluno da classificação de qualidade por classificar spam altamente. Da mesma forma, o conteúdo "picante" precisa ser tratado separadamente da classificação de qualidade. A filtragem de spam é uma história diferente. Você precisa esperar que os recursos que precisa gerar mudem constantemente. Muitas vezes, haverá regras óbvias que você insere no sistema (se uma postagem tiver mais de três votos de spam, não a recupere etc.). Qualquer modelo aprendido vai precisar ser atualizado diariamente, ou até mais rápido. A reputação do criador do conteúdo terá um papel muito 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. Além disso, é uma prática padrão remover spam dos dados de treinamento para o classificador de qualidade.

Fase II de ML: engenharia de atributos

Na primeira fase do ciclo de vida de um sistema de machine learning, as questões importantes são colocar os dados de treinamento no sistema de aprendizado, ter todas as métricas de interesse instrumentadas e criar uma infraestrutura de disponibilização. Depois que você tiver um sistema completo com testes de unidade e sistema instrumentados, a Fase II começa.

Na segunda fase, há muitos resultados fáceis. Há diversos recursos óbvios que podem ser inseridos no sistema. Assim, a segunda fase do machine learning envolve reunir o máximo possível de recursos e combiná-los de maneira intuitiva. Durante essa fase, todas as métricas ainda devem estar subindo. Haverá muitos lançamentos, e esse é um ótimo momento para puxar muitos engenheiros que possam reunir todos os dados necessários para criar um sistema de aprendizado verdadeiramente incrível.

Regra no 16: planeje 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ê pare de lançar modelos. Portanto, considere se a complexidade que você está adicionando com esse lançamento vai atrasar lançamentos futuros. Muitas equipes lançaram um modelo por trimestre ou mais por anos. Existem três motivos básicos para lançar novos modelos:

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

Independentemente disso, é bom dar um pouco de carinho ao modelo: examinar a alimentação de dados no exemplo pode ajudar a encontrar novos sinais, assim como os antigos e corrompidos. Portanto, ao criar seu modelo, pense em como é fácil adicionar, remover ou recombinar atributos. Pense em como é fácil criar uma nova cópia do pipeline e verificar se ele está correto. Pense se é possível ter duas ou três cópias sendo executadas em paralelo. Por fim, não se preocupe se o recurso 16 de 35 está incluído nessa versão do pipeline. Você receberá no próximo trimestre.

Regra no 17: comece com os atributos observados e informados em vez dos recursos aprendidos.

Esse pode ser um ponto controverso, mas evita muitas armadilhas. Primeiro, vamos descrever o que é um atributo aprendido. Ele é gerado por um sistema externo (como um sistema de cluster não supervisionado) ou pelo próprio aprendiz (por exemplo, por meio de um modelo fatorado ou aprendizado profundo). Ambos podem ser úteis, mas podem ter muitos problemas, por isso não devem estar no primeiro modelo.

Se você usa um sistema externo para criar um recurso, lembre-se de que ele tem o próprio objetivo. O objetivo do sistema externo pode ter uma correlação fraca apenas com o objetivo atual. Se você capturar um snapshot do sistema externo, ele poderá ficar desatualizado. Se você atualizar os recursos no sistema externo, os significados poderão mudar. Se você usa um sistema externo para fornecer um recurso, saiba que essa abordagem exige muito cuidado.

O principal problema com modelos fatorados e profundos é que eles não são convexos. Portanto, não há garantia de que uma solução ideal seja aproximada ou encontrada, e os mínimos locais encontrados em cada iteração podem ser diferentes. Essa variação torna difícil julgar se o impacto de uma alteração no sistema é significativo ou aleatório. Ao criar um modelo sem recursos profundos, você pode conseguir um desempenho de referência excelente. Depois que esse valor de referência for alcançado, tente abordagens mais esotéricas.

Regra no 18: explorar com recursos de conteúdo que se generalizam entre contextos.

Muitas vezes, o sistema de machine learning é uma pequena parte de um cenário muito maior. Por exemplo, se você imaginar uma postagem que possa ser usada na seção "Postagens interessantes", muitas pessoas marcarão com +1, compartilharem de novo ou comentarem uma postagem antes que ela seja exibida nas Postagens interessantes. Se você fornecer essas estatísticas ao aluno, ele poderá promover novas postagens sem dados no contexto em que estiver otimizando. O canal "Assistir a seguir" do YouTube pode usar o número de visualizações ou as exibições conjuntas (conta quantas vezes um vídeo foi assistido após outro) a partir da pesquisa do YouTube. Você também pode usar classificações explícitas dos usuários. Por fim, se você estiver usando uma ação de usuário como um rótulo, ver essa ação no documento em um contexto diferente pode ser um ótimo recurso. Todos esses recursos permitem que você coloque novos conteúdos no contexto. Não se trata de personalização: primeiro descubra se alguém gosta do conteúdo nesse contexto e depois descubra quem mais ou menos gosta.

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

Com muitos 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. Portanto, não tenha medo de grupos de recursos em que cada um se aplica a uma fração muito pequena dos dados, mas a cobertura geral está acima de 90%. É possível usar a regularização para eliminar os recursos que se aplicam a poucos exemplos.

Regra no 20: combinar e modificar os recursos atuais para criar novos recursos de formas compreensíveis para as pessoas.

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

A discretização consiste em pegar um recurso contínuo e criar muitos recursos discretos a partir dele. Considere um atributo contínuo, como a idade. É possível criar um atributo 1 quando a idade é menor que 18 anos, outro atributo como 1 quando a idade está entre 18 e 35 anos etc. Não pense demais nos limites desses histogramas: os quantis básicos causarão a maior parte do impacto.

Os cruzamentos combinam duas ou mais colunas de atributos. Na terminologia do TensorFlow, uma coluna de atributos é um conjunto de atributos homogêneos (por exemplo, {male, female}, {US, Canada, Mexico} etc). Um cruzamento é uma nova coluna de atributos com atributos, por exemplo, {male, female} × {US,Canada, Mexico}. Essa nova coluna de atributo conterá o atributo (masculino, Canadá). Se você estiver usando o TensorFlow e solicitar que ele crie esse cruzamento para você, esse recurso (masculino, Canadá) estará presente em exemplos que representam homens canadenses. São necessários grandes volumes de dados para aprender modelos com cruzamentos de três, quatro ou mais colunas de atributos básicos.

Cruzamentos que produzem colunas de atributos muito grandes podem sofrer overfitting. Por exemplo, imagine que você está fazendo algum tipo de pesquisa e tem uma coluna de elementos com palavras na consulta e uma coluna de atributo com palavras no documento. Você pode combiná-las com um cruzamento, mas acabará com muitos atributos (consulte a Regra no 21).

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

Regra no 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 da teoria de aprendizagem estatística sobre o nível apropriado de complexidade de um modelo, mas essa regra é basicamente tudo que você precisa saber. Tive conversas em que as pessoas ficaram em dúvida de que tudo pode ser aprendido com mil exemplos ou que você precisaria de mais de um milhão de exemplos, porque elas ficavam presas em um determinado método de aprendizado. A chave é dimensionar seu aprendizado de acordo com 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 escalar entre recursos de documento e consulta, TF-IDF e meia dúzia de outros atributos altamente projetados por humanos. mil exemplos, uma dúzia de recursos.
  2. Se você tiver um milhão de exemplos, cruze as colunas de recurso de consulta e documento usando a regularização e, possivelmente, a seleção de atributos. Isso oferecerá milhões de recursos, mas, com a regularização, você terá menos. Dez milhões de exemplos, talvez cem mil atributos.
  3. Se você tiver bilhões ou centenas de bilhões de exemplos, poderá cruzar as colunas de atributos com tokens de documento e consulta usando a seleção e a regularização de atributos. Você terá um bilhão de exemplos e 10 milhões de recursos. A teoria da aprendizagem estatística raramente oferece limites rígidos, mas fornece ótimas orientações como ponto de partida.

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

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

Recursos não utilizados geram dívida técnica. Se você perceber que um recurso não está sendo usado e que a combinação com outros recursos não está funcionando, remova-o da infraestrutura. Você quer manter sua infraestrutura limpa para que os recursos mais promissores possam ser testados o mais rápido possível. Se necessário, alguém pode sempre adicionar seu recurso de volta.

Tenha a cobertura em mente ao considerar quais recursos adicionar ou manter. Quantos exemplos são abrangidos pelo recurso? Por exemplo, se você tiver alguns recursos de personalização, mas apenas 8% dos usuários tiverem esses recursos, não será muito eficaz.

Ao mesmo tempo, alguns recursos podem superar seu peso. Por exemplo, se você tiver um atributo que cobre apenas 1% dos dados, mas 90% dos exemplos que o incluem forem positivos, será ótimo adicioná-lo.

Análise humana do sistema

Antes de passar para a terceira fase do machine learning, é importante focar em algo que não é ensinado em nenhuma aula de machine learning: como analisar um modelo existente e melhorá-lo. Isso é mais uma arte do que uma ciência, e ainda assim existem vários antipadrões que ajuda a evitar.

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

Essa talvez seja a maneira mais fácil de uma equipe se atrapalhar. Há muitos benefícios na prática de fishfood (usando um protótipo dentro da equipe) e na dogfood (usando um protótipo na sua empresa), mas os funcionários precisam verificar se o desempenho está correto. Embora uma mudança obviamente ruim não deva ser usada, qualquer item que pareça razoavelmente próximo da produção precisa ser testado mais a fundo, seja pagando leigos para responder a perguntas em uma plataforma de crowdsourcing ou por meio de um experimento em tempo real com usuários reais.

Há duas razões para isso. A primeira é que você está muito perto do código. Talvez você esteja procurando um aspecto específico das postagens ou esteja apenas emocionalmente envolvido (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ê realmente quiser receber feedback do usuário, use as metodologias de experiência do usuário. Crie personas de usuário (uma descrição está em Como esboçar experiências do usuário de Bill Buxton) no início de um processo e faça o teste de usabilidade (uma descrição está em Don't Make Me Think, de Steve Krug) mais tarde. Personas de usuário envolvem a criação de um usuário hipotético. Por exemplo, se toda a sua equipe for masculina, pode ser útil criar uma persona de usuário feminina de 35 anos (completo com recursos de usuário) e analisar os resultados gerados, em vez de 10 resultados para homens de 25 a 40 anos. Trazer pessoas reais para assistir à reação delas ao seu site (local ou remotamente) nos testes de usabilidade também pode trazer uma nova perspectiva.

Regra no 24: medir o delta entre os modelos.

Uma das medições mais fáceis e, por vezes, mais úteis que você pode fazer antes de qualquer usuário ver seu novo modelo é calcular a diferença entre os novos resultados e a 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 observe o tamanho da diferença simétrica dos resultados (ponderada pela posição da classificação). Se a diferença for muito pequena, será possível perceber sem realizar um experimento que haverá poucas mudanças. Se a diferença for muito grande, a melhor opção é ter certeza de que a mudança é boa. Analisar consultas em que a diferença simétrica é alta pode ajudar você a entender qualitativamente como foi a alteração. No entanto, verifique se o sistema é estável. Confira se um modelo, quando comparado com ele mesmo, tem uma diferença simétrica baixa (de preferência zero).

Regra no 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 pergunta-chave é o que você faz com essa previsão. Se você o usa para classificar documentos, a qualidade da classificação final é mais importante do que a própria previsão. Se você prever a probabilidade de um documento ser spam e, em seguida, tiver um corte no que está bloqueado, a precisão do que é permitido será mais importante. Na maioria das vezes, essas duas coisas devem estar de acordo: quando elas não concordam, provavelmente terá um pequeno ganho. Portanto, se houver alguma mudança que melhore a perda de registros, mas degrade o desempenho do sistema, procure outro recurso. Quando isso começar a acontecer com mais frequência, será hora de revisitar o objetivo do seu modelo.

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

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

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

Depois de ter exemplos de que o modelo errou, procure tendências que estejam fora do seu conjunto de recursos atual. Por exemplo, se o sistema parecer estar rebaixando postagens mais longas, adicione o comprimento da postagem. Não seja muito específico sobre os recursos que você adiciona. Se você quiser adicionar o comprimento da postagem, não tente adivinhar o que significa “longo”, basta adicionar vários recursos e o modelo permitir descobrir o que fazer com eles (consulte a Regra no 21). Essa é a maneira mais fácil de conseguir o que você quer.

Regra no 27: tente quantificar o comportamento indesejável observado.

Alguns membros da equipe começarão a ficar frustrados com as propriedades do sistema de que não gostam, que não são capturadas pela função de perda existente. Nesse momento, eles precisam fazer o que for necessário para transformar as garras em números sólidos. Por exemplo, se eles acharem que muitos "apps de gag" estão sendo exibidos na Pesquisa do Google Play, podem solicitar que avaliadores humanos identifiquem esses apps. É possível usar dados rotulados por humanos nesse caso, 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 é medir primeiro, otimizar depois.

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

Imagine que você tem um novo sistema que analisa cada doc_id eexact_query e, em seguida, calcula a probabilidade de clique de cada documento para cada consulta. Você descobre que o comportamento dele é quase idêntico ao sistema atual tanto lado a lado quanto no teste A/B. Portanto, devido à simplicidade, você o inicia. No entanto, você vai perceber que nenhum app novo está sendo exibido. Por quê? Como seu sistema mostra apenas um documento baseado no próprio histórico com essa consulta, não há como saber que um novo documento precisa ser exibido.

A única maneira de entender como um sistema funcionaria a longo prazo é treinando-o apenas com dados adquiridos quando o modelo estava ativo. Isso é muito difícil.

Desvio de treinamento/disponibilização

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

  • Uma discrepância entre a forma como você lida com dados nos pipelines de treinamento e disponibilização.
  • Uma mudança nos dados entre o treinamento e a veiculação.
  • Um ciclo de feedback entre o modelo e o algoritmo.

Observamos os sistemas de machine learning de produção no Google com desvio de treinamento/disponibilização que afeta negativamente o desempenho. A melhor solução é monitorá-lo explicitamente para que as alterações no sistema e nos dados não introduzam um desvio desnotado.

Regra no 29: a melhor maneira de garantir que você treine como você atende é salvar o conjunto de atributos usados no momento da disponibilização e, em seguida, direcionar esses atributos para um registro para usá-los no momento do treinamento.

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

Regra no 30: dados de amostra de peso importante, não os descarte arbitrariamente!

Quando você tem muitos dados, há a tentação de pegar os arquivos de 1 a 12 e ignorar os arquivos de 13 a 99. Isso não está certo. Os dados que nunca foram mostrados ao usuário podem ser descartados, mas a ponderação de importância é melhor para o restante. Ponderação de importância significa que, se você decidir usar o exemplo X com uma probabilidade de 30%, dê a ele uma ponderação de 10/3. Com a ponderação de importância, todas as propriedades de calibragem discutidas na Regra no 14 ainda são válidas.

Regra no 31: cuidado: se você mesclar dados de uma tabela no momento de treinamento e disponibilização, os dados na tabela podem mudar.

Digamos que você mescle IDs de documentos a uma tabela que contenha recursos para esses documentos (como número de comentários ou cliques). Entre o tempo de treinamento e a disponibilização, os atributos na tabela podem ser alterados. A previsão do modelo para o mesmo documento pode diferir entre o treinamento e a disponibilização. A maneira mais fácil de evitar esse tipo de problema é registrar os atributos no momento da exibição (consulte a Regra no 32). Se a tabela estiver mudando apenas lentamente, você também poderá criar um snapshot da tabela a cada hora ou diariamente para receber dados razoavelmente próximos. Isso ainda não resolve completamente o problema.

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

O processamento em lote é diferente do processamento on-line. No processamento on-line, você precisa lidar com cada solicitação quando ela chega (por exemplo, é preciso fazer uma pesquisa separada para cada consulta). Já no processamento em lote, é possível combinar tarefas (por exemplo, fazer uma mesclagem). Na hora de disponibilização, você faz processamento on-line, enquanto o treinamento é uma tarefa de processamento em lote. No entanto, há algumas ações que podem ser feitas para reutilizar o código. Por exemplo, é possível criar um objeto específico para o sistema, em que o resultado de consultas ou junções possa ser armazenado de maneira legível e os erros possam ser testados facilmente. 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 específico do seu sistema e o formato esperado pelo sistema de machine learning. Isso elimina uma fonte de desvio de treinamento/disponibilização. Como resultado, tente não usar duas linguagens de programação diferentes entre o treinamento e a disponibilização. Essa decisão tornará quase impossível você compartilhar código.

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

Em geral, meça o desempenho de um modelo com base nos dados coletados após os dados usados para treinamento, porque isso reflete melhor o que o sistema fará na produção. Se você produzir um modelo com base nos dados até 5 de janeiro, faça um teste com base nos dados a partir de 6 de janeiro. Você espera que o desempenho não seja tão bom com os novos dados, mas não deve ser radicalmente pior. Como pode haver efeitos diários, talvez você não preveja a taxa média de cliques ou de conversão, mas a área abaixo da curva, que representa a probabilidade de dar ao exemplo positivo uma pontuação maior que o negativo, deve estar razoavelmente próxima.

Regra no 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 por dados muito limpos.

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

Mas essa abordagem introduz um viés de amostragem. É possível coletar dados mais limpos se, em vez disso, você rotular 1% de todo o tráfego como "retido" durante a exibição e enviar todos os exemplos ao usuário. Agora, o filtro está bloqueando pelo menos 74% dos exemplos negativos. Esses exemplos podem se tornar seus dados de treinamento.

Se o filtro estiver bloqueando 95% dos exemplos negativos ou mais, essa abordagem se tornará menos viável. Mesmo assim, se você quiser avaliar o desempenho da veiculação, crie uma amostra ainda menor (por exemplo, 0,1% ou 0,001%). Dez mil exemplos é suficiente para estimar o desempenho com muita precisão.

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

Quando você muda de forma radical o algoritmo de classificação para que resultados diferentes sejam exibidos, significa que os dados que o algoritmo vai ver no futuro foi alterado de forma eficaz. Esse tipo de distorção vai aparecer, e é necessário projetar o modelo com base nele. Há várias abordagens diferentes. Essas abordagens são maneiras de favorecer os dados que seu modelo já viu.

  1. ter maior regularização em recursos que abrangem mais consultas do que aqueles que estão ativados para apenas uma consulta; Dessa forma, o modelo favorecerá os recursos específicos de uma ou algumas consultas em vez de recursos que generalizam a todas as consultas. Essa abordagem pode ajudar a evitar que resultados muito conhecidos vazem para consultas irrelevantes. Observe que isso é o oposto do conselho mais convencional de ter mais regularização em colunas de atributos com valores mais exclusivos.
  2. Só permite que os atributos tenham pesos positivos. Assim, qualquer bom atributo é melhor que um "desconhecido".
  3. não têm recursos somente para documentos. Esta é uma versão extrema do 1. Por exemplo, mesmo que um determinado app seja um download conhecido, independente do que seja a consulta, não convém mostrá-lo em todos os lugares. Não ter recursos somente de documentos torna isso simples. O motivo pelo qual você não quer mostrar um app famoso em todos os lugares tem a ver com a 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 "raivado", mas essa certa não era a intenção. Mostrar um desses apps pode melhorar a taxa de download, mas deixar as necessidades do usuário insatisfeitas.

Regra no 36: evite ciclos 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 será clicado com mais frequência, e você terá certeza de que ele será mais clicado. Uma maneira de lidar com isso é adicionar recursos de posicionamento, ou seja, recursos sobre a posição do conteúdo na página. Você treina o modelo com recursos posicionais e ele aprende a ponderar, por exemplo, o atributo "1a posição" pesado. Assim, o modelo atribui menos peso a outros fatores para exemplos com "1stposition=true". Em seguida, na disponibilização, você não atribui o atributo posicional a nenhuma instância ou fornece a elas o mesmo atributo padrão, porque você pontua os candidatos antes de decidir a ordem em que eles serão mostrados.

É importante manter os atributos posicionais separados do restante do modelo por causa dessa assimetria entre treinamento e teste. O ideal é que o modelo seja a soma de uma função dos atributos posicionais e uma função dos outros atributos. Por exemplo, não cruze os recursos posicionais com nenhum recurso do documento.

Regra no 37: medir os desvios no treinamento/disponibilização.

Há várias coisas que podem causar distorção 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 nos dados de validação. Em geral, isso sempre existirá e nem sempre é ruim.
  • A diferença entre o desempenho nos dados não incluídos e nos dados do dia seguinte. Novamente, isso sempre existirá. Ajuste a regularização para maximizar o desempenho do dia seguinte. No entanto, grandes quedas no desempenho entre dados de validação e dados 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 do "dia seguinte" e nos dados ativos. Se você aplicar um modelo a um exemplo nos dados de treinamento e ao mesmo exemplo na disponibilização, ele fornecerá exatamente o mesmo resultado (consulte a Regra no 5). Portanto, uma discrepância aqui provavelmente indica um erro de engenharia.

Fase III do ML: crescimento lento, refinamento da 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 vantagens e desvantagens entre as métricas: vai notar um aumento e outras caem em alguns experimentos. É aqui que tudo fica interessante. Como os ganhos são mais difíceis de alcançar, o aprendizado de máquina precisa ficar mais sofisticado. Uma ressalva: esta seção tem mais regras para o azul do céu azul do que as seções anteriores. Vimos muitas equipes passarem por momentos felizes das fases I e Fase II do machine learning. Depois que a Fase III for atingida, as equipes precisam encontrar seu próprio caminho.

Regra no 38: não perca tempo em novos recursos se objetivos desalinhados se tornarem o problema.

À medida que suas medições se estabilizarem, sua equipe começará a analisar problemas que estão fora do escopo dos objetivos do seu sistema atual de machine learning. Conforme afirmado anteriormente, se as metas do produto não forem cobertas pelo objetivo algorítmico atual, será necessário alterar o objetivo ou as metas do produto. Por exemplo, é possível otimizar cliques, marcações com mais um ou downloads, mas tomar decisões de lançamento com base, em parte, em avaliadores humanos.

Regra no 39: as decisões de lançamento são um substituto para as metas de produtos de longo prazo.

Alice tem uma ideia de reduzir a perda logística da previsão de instalações. Ela adiciona um recurso. A perda logística cai. Ao fazer um experimento em tempo real, ela observa um aumento na taxa de instalação. No entanto, quando ela vai para uma reunião de análise do lançamento, alguém ressalta que o número de usuários ativos por dia cai 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, e apenas alguns deles podem ser diretamente otimizados com ML.

A verdade é que o mundo real não é de masmorras e dragões: não há "pontos de hit" que identifiquem a integridade do seu produto. A equipe precisa usar as estatísticas coletadas para tentar prever com eficácia a qualidade do sistema no futuro. Eles precisam se preocupar com o engajamento, os usuários ativos por um dia (DAU), os 30 DAU, a receita e o retorno do investimento do anunciante. Essas métricas, que podem ser medidas em testes A/B, são apenas uma representação para metas de longo prazo: satisfação de usuários, aumento de usuários, satisfação de parceiros e lucro, que, mesmo assim, podem ser considerados proxies para ter um produto útil e de alta qualidade e uma empresa próspera daqui a cinco anos.

As únicas decisões de lançamento fáceis são quando todas as métricas melhoram (ou pelo menos não pioram). Se a equipe tiver que escolher entre um algoritmo sofisticado de aprendizado de máquina e uma heurística simples, se a heurística simples funcionar melhor em todas essas métricas, ela precisará escolher a heurística. Além disso, não há uma classificação explícita de todos os valores de métricas possíveis. Considere especificamente os dois cenários a seguir:

Experimental Usuários ativos por dia Receita/dia
A 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 estar em conflito com o comportamento racional. No entanto, as previsões de mudanças nas métricas podem ou não ser bem-sucedidas. Portanto, há um grande risco envolvido em qualquer uma das mudanças. Cada métrica cobre algum risco que preocupa a equipe.

Além disso, nenhuma métrica abrange a preocupação final da equipe, "onde meu produto estará daqui a cinco anos"?

Por outro lado, os indivíduos tendem a favorecer um objetivo que possa otimizar diretamente. A maioria das ferramentas de machine learning prefere esse tipo de ambiente. Um engenheiro que lança novos recursos pode ter um fluxo constante de lançamentos nesse ambiente. Existe um tipo de machine learning, o aprendizado multiobjetivo, que começa a resolver esse problema. Por exemplo, é possível formular um problema de satisfação de restrições que tenha limites inferiores em cada métrica e otimize alguma combinação linear de métricas. No entanto, mesmo assim, nem todas as métricas são facilmente enquadradas como objetivos de machine learning: se alguém clicou em um documento ou um app foi instalado, isso significa que o conteúdo foi mostrado. No entanto, é muito mais difícil descobrir por que um usuário visita seu site. A maneira de prever o sucesso futuro de um site como um todo é completa por IA: tão difícil quanto a visão computacional ou o processamento de linguagem natural.

Regra no 40: mantenha os conjuntos simples.

Os modelos unificados que recebem 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 apenas com a entrada de outros modelos ou um modelo base que tenha muitos recursos, mas não ambos. Se você tiver modelos sobre outros modelos treinados separadamente, combiná-los pode resultar em mau comportamento.

Use um modelo simples para ensembling que use apenas a saída dos modelos "base" como entradas. Você também quer aplicar propriedades nesses modelos de ensemble. Por exemplo, um aumento na pontuação produzida por um modelo base não pode 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, imponha que um aumento na probabilidade prevista de um classificador subjacente não diminua a probabilidade prevista do conjunto.

Regra no 41: quando a performance estiver estável, procure adicionar novas fontes de informação qualitativamente em vez de refinar os indicadores atuais.

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

É hora de começar a criar 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. Usar entidades wikidata ou algo interno da sua empresa (como o Mapa de informações do Google). Use o aprendizado profundo. Comece a ajustar suas expectativas sobre o retorno esperado do investimento e expanda seus esforços de acordo. Como em qualquer projeto de engenharia, você precisa ponderar o benefício de adicionar novos recursos em relação ao custo do aumento da complexidade.

Regra no 42: não espere que diversidade, personalização ou relevância estejam tão correlacionadas com a popularidade quanto você pensa.

Diversidade em um conjunto de conteúdo pode significar muitas coisas, sendo a diversidade da fonte do conteúdo uma das mais comuns. A personalização implica que cada usuário recebe os próprios resultados. Relevância: significa que os resultados de uma consulta específica são mais apropriados para essa consulta do que qualquer outra. Assim, todas essas três propriedades são definidas como diferentes do comum.

O problema é que o comum tende a ser difícil de superar.

Se o sistema estiver medindo cliques, tempo gasto, visualizações, marcações com +1, compartilhamentos etc., a popularidade do conteúdo é medida. As equipes às vezes tentam aprender um modelo pessoal com diversidade. Para personalizar, eles adicionam recursos que permitiriam ao sistema personalizar (alguns recursos que representam o interesse do usuário) ou diversificar (recursos que indicam se esse documento tem algum recurso em comum com outros documentos retornados, como autor ou conteúdo) e descobrir 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 sejam valiosas. Conforme mencionado na regra anterior, é possível fazer o pós-processamento para aumentar a diversidade ou a relevância. Se os objetivos de longo prazo aumentarem, você poderá 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 no 43: seus amigos tendem a ser os mesmos em produtos diferentes. Seus interesses tendem a não ser.

As equipes do Google ganharam muito esforço ao adotar um modelo que prevê a proximidade de uma conexão em um produto e fazê-lo funcionar bem em outro. Seus amigos são quem eles são. Por outro lado, vi várias equipes lutando com recursos de personalização em divisões de produtos. Sim, parece que deve funcionar. Por enquanto, não parece que ele funciona. O que às vezes funcionou é usar 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 de atividade do usuário em dois produtos pode ser indicativa por si só.

Existem muitos documentos sobre machine learning 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, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsi, Danwals DISPs Além disso, graças a Kristen Lefevre, Suddha Basu e Chris Berg, que ajudaram com uma versão anterior. Quaisquer erros, omissões ou (arfada!) opiniões impopulares são minhas.

Apêndice

Existem diversas referências a produtos do Google neste documento. Para oferecer mais contexto, farei 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 canal "Assistir a seguir" e da página inicial do YouTube usam modelos de ML para classificar as recomendações de vídeos. O canal "Assistir a seguir" recomenda vídeos para assistir depois daquele que estiver em reprodução, enquanto a página inicial recomenda vídeos aos usuários que navegam na página inicial.

Visão geral do Google Play

O Google Play tem muitos modelos que resolvem diversos problemas. Pesquisa do Google Play, recomendações personalizadas da página inicial do Google Play e apps "Os usuários também instalaram" usam aprendizado de máquina.

Visão geral do Google Plus

O Google Plus usou o aprendizado de máquina em várias situações: classificar postagens no "stream" de postagens vistas pelo usuário, classificar as postagens "mais populares" (postagens que são muito populares no momento), classificar as pessoas que você conhece etc. O Google Plus fechou todas as contas pessoais em 2019 e foi substituído pelo Google Currents para contas empresariais em 6 de julho de 2020.