Regras do machine learning:

Práticas recomendadas para engenharia de ML

Martin Zinkevich

O objetivo deste documento é ajudar pessoas com um conhecimento básico sobre machine learning e machine learning aproveitar as práticas recomendadas do Google sobre machine learning. Ela apresenta um estilo para aprendizado de máquina, semelhante ao Guia de estilo do Google para C++. e outros guias populares de programação prática. Se você participou de uma aula em machine learning, ou criou ou trabalhou em um modelo aprendido de máquina, tem o histórico necessário para ler este documento.

Martin Zinkevich apresenta 10 regras favoritas dele do machine learning. Continue lendo para conhecer as 43 regras.

Terminologia

Os termos a seguir aparecerão repetidamente na nossa discussão sobre eficácia machine learning:

  • Instância: o item sobre o qual você quer criar previsão. Por exemplo, a instância pode ser uma página da Web em que você classificar como "sobre gatos" ou "não sobre gatos".
  • Rótulo: uma resposta para uma tarefa de previsão, seja a resposta produzida por uma um sistema de machine learning ou a resposta certa nos dados de treinamento. Para 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. Para exemplo, uma página da Web pode ter um recurso "contém a palavra 'gato'".
  • Coluna de elementos: é um conjunto de elementos relacionados, como o conjunto de todos os elementos possíveis países onde os usuários podem viver. Um exemplo pode ter um ou mais atributos presentes em uma coluna de atributo. "Coluna de atributo" é a terminologia específica do Google. Uma coluna de atributo é chamada de "namespace" no sistema VW (no Yahoo/Microsoft) ou 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 os exemplos e usam o modelo para fazer previsões.
  • Métrica: um número importante. Pode ou não ser otimizado diretamente.
  • Objetivo: uma métrica que seu algoritmo está tentando otimizar.
  • Pipeline: a infraestrutura em torno de um algoritmo de machine learning. Inclui a coleta dos dados do front-end e os colocá-los em dados de treinamento treinamento de 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 em um anúncio.

Visão geral

Para criar produtos incríveis:

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

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

  1. Verifique se o pipeline está sólido de ponta a ponta.
  2. Comece com um objetivo razoável.
  3. Adicione recursos de senso comum de forma simples.
  4. Certifique-se de que seu pipeline permaneça sólido.

Essa abordagem funcionará bem para um longo período de tempo. Abandonar essa abordagem somente quando não houver mais truques simples para avançar ainda mais. A complexidade aumenta as versões futuras.

Depois que você acabar com os truques simples, o machine learning de última geração poderá você estará no seu futuro. Consulte a seção sobre 3a fase projetos de machine learning.

Esse documento está organizado da seguinte maneira:

  1. A primeira parte deve ajudar você a entender se este é o momento certo para criar um sistema de machine learning.
  2. A segunda parte é sobre a implantação o primeiro pipeline.
  3. A terceira parte é sobre o lançamento e iterar ao adicionar novos atributos ao pipeline, como avaliar modelos e desvio entre treinamento e disponibilização.
  4. O parte final é sobre o que fazer quando chegar a uma estabilização.
  5. Depois, há uma lista de trabalhos relacionados e um apêndice com algumas 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 machine learning.

O machine learning é legal, mas requer dados. Teoricamente, é possível pegar os dados de um problema diferente e ajustar o modelo para um novo produto, mas isso provavelmente terá um desempenho inferior heurística. Se você acha que o machine learning dará 100% de aumento, e uma heurística vai dar 50% até aqui.

Por exemplo, se você estiver classificando aplicativos em um mercado de aplicativos, você pode usar o taxa de instalação ou número de instalações como heurística. Se você detectar spam, filtrar editores que já enviaram spam antes. Não tenha medo de usar imagens edição também. Se precisar classificar contatos, classifique os usados mais recentemente mais alta (ou até mesmo classificada em ordem alfabética). Se o machine learning não for absolutamente necessário para seu produto, não o utilize até que tenha dados.

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

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

  1. É mais fácil conseguir a permissão dos usuários do sistema desde o início.
  2. Se você acha que algo pode ser uma preocupação no futuro, é melhor obter dados históricos agora.
  3. Se você projeta seu sistema com a instrumentação métrica em mente, algumas coisas é melhor para para você no futuro. Especificamente, você não quer se encontrar strings nos registros para instrumentar suas métricas.
  4. Você perceberá o que as coisas mudam e o que permanece igual. Por exemplo: suponha que você queira otimizar diretamente os usuários ativos por um dia. No entanto, durante as primeiras manipulações do sistema, você pode notar que alterações drásticas da experiência do usuário não alteram visivelmente isso métrica.

A equipe do Google Plus mede a expansão a cada leitura, novos compartilhamentos por leitura, +1s por leitura, comentários/leituras, comentários por usuário, novos compartilhamentos por usuário etc. que eles usam no cálculo da qualidade de uma postagem no momento da veiculação. Além disso, um estrutura de experimento, na qual é possível agrupar usuários em buckets e agregar estatísticas por experimento, é importante. Consulte Regra no 12.

Ao coletar métricas com mais liberdade, você pode ter uma visão mais ampla do seu sistema. Notou algum problema? Adicione uma métrica para monitorá-la. Estou empolgado com algumas mudança quantitativa na última versão? Adicione uma métrica para monitorá-la.

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

Uma heurística simples pode usar seu produto. Uma heurística complexa sem manutenção. Depois de ter os dados e uma ideia básica do que você está tentando para realizar, passe para o machine learning. Como na maior parte da engenharia de software, tarefas, você deve estar constantemente atualizando sua abordagem, seja uma heurística ou um modelo aprendido de máquina, e vai descobrir que modelo aprendido por máquina é mais fácil de atualizar e manter (consulte Regra no 16).

Fase I do ML: primeiro pipeline

Concentre-se na infraestrutura do sistema para seu primeiro pipeline. Embora seja divertido pensar em todo o machine learning imaginativo que você pretende fazer, será difícil descobrir o que está acontecendo se você não confiar primeiro em seu pipeline.

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

O primeiro modelo fornece o maior impulso para o seu produto, por isso não é necessário para ser chique. No entanto, você vai se deparar com muito mais problemas de infraestrutura do que aqueles o que esperar. Antes que alguém possa usar seu novo sistema de machine learning, você precisa para determinar:

  • Como fornecer exemplos para seu algoritmo de aprendizado.
  • O primeiro ponto sobre o que é "bom" e "ruim" significam para seu sistema.
  • Como integrar o modelo ao aplicativo. É possível aplicar o modelo ativo ou pré-computar o modelo off-line em exemplos 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 talvez você queira classificar as mensagens de chat ativas.

Ao escolher recursos simples, fica mais fácil garantir que:

  • os atributos chegam ao algoritmo de aprendizado corretamente.
  • O modelo aprende pesos razoáveis.
  • Os atributos chegam ao seu modelo corretamente no servidor.

Quando você tiver um sistema que faça essas três coisas de forma confiável, a maior parte do trabalho. O modelo simples oferece métricas de base e uma comportamento de referência que pode ser usado para testar modelos mais complexos. Algumas equipes visam para uma resposta "neutra" primeiro lançamento: um lançamento que diminui explicitamente a prioridade ganhos de machine learning para não se distrair.

Regra no 5: teste a infraestrutura de maneira independente do machine learning.

Garantir que a infraestrutura possa ser testada e que as partes de aprendizado o sistema é encapsulado para que você possa testar tudo ao redor. Especificamente:

  1. Testar a entrada de dados no algoritmo. Verifique se as colunas de atributo que devem ser preenchidas. Onde a privacidade permitir, manualmente inspecionar a entrada do algoritmo de treinamento. Se possível, verifique estatísticas no pipeline em comparação com estatísticas para os mesmos dados processados em outro lugar.
  2. Testar a extração de modelos do algoritmo de treinamento. Certifique-se de que o no ambiente de treinamento gera a mesma pontuação que o modelo no ambiente de veiculação (consulte Regra no 37).

O machine learning tem um elemento de imprevisibilidade, então não deixe de testar o código para criar exemplos no treinamento e na disponibilização e em que um modelo fixo pode ser carregado e usado durante a disponibilização. Além disso, é importante para entender seus dados: consulte Conselhos práticos para análise de conjuntos de dados grandes e complexos.

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

Geralmente, criamos um pipeline copiando outro já existente (por exemplo, programação cult carga ), e o pipeline antigo descarta os dados necessários para o novo. Por exemplo, o pipeline de "Postagens interessantes" do Google+. descarta postagens mais antigas (porque está tentando classificar as postagens novas). Esse pipeline foi copiado para uso no stream do Google Plus, no qual as postagens mais antigas ainda são significativos, mas o pipeline ainda estava descartando postagens antigas. Outra comum é registrar apenas os dados que foram vistos pelo usuário. Assim, esses dados são inútil 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 em Google Play. Na página inicial de apps do Google Play, foi criado um novo pipeline que também continham exemplos da página de destino do Play Games sem nenhum recurso para sem ambiguidade sobre a origem de cada exemplo.

Regra no 7: transforme heurística em atributos ou trate-os externamente.

Normalmente, os problemas que o machine learning tenta resolver não são totalmente novo. Existe um sistema de classificação, ou qualquer problema que você esteja tentando resolver. Isso significa que há vários e heurística. Essas mesmas heurísticas podem aumentar quando ajustadas com o machine learning. Sua heurística deve ser minuciosamente para informações que eles possuem, por dois motivos. Primeiro, a transição para um modelo do sistema aprendido será mais suave. Em segundo lugar, geralmente essas regras contêm a intuição sobre o sistema que você não quer jogar fora. Há quatro maneiras de usar uma heurística atual:

  • Pré-processar usando a heurística. Se o recurso for incrível, essa é uma opção. Por exemplo, se, em um filtro de spam, o remetente já foi colocado na lista de proibições, não tente reaprender o que está na "lista negra" significa. Bloquear a mensagem. Essa abordagem faz mais sentido em código binário tarefas de classificação.
  • Criar um atributo. É ótimo criar atributos diretamente da heurística. Por exemplo, se você usar uma heurística para calcular uma pontuação de relevância para uma consulta é possível incluir a pontuação como o valor de um atributo. Mais tarde, pode querer usar técnicas de aprendizado de máquina para manipular o valor Por exemplo, converter o valor em um de um conjunto finito de valores ou combiná-los com outros atributos), mas comece usando o valor bruto o valor produzido pela heurística.
  • Extraia as entradas brutas da heurística. Se houver uma heurística para apps que combina o número de instalações, o número de caracteres na o texto e o dia da semana, então considere separar essas partes, e inserir essas informações no aprendizado separadamente. Algumas técnicas que se aplicam aos conjuntos aqui (consulte Regra no 40).
  • Modifique o rótulo. Essa é uma opção quando você sente que a heurística captura informações que não estão contidas no marcador. Por exemplo: se quiser maximizar o número de downloads, mas também quiser de alta qualidade, talvez a solução seja multiplicar o rótulo pelo número médio de estrelas que o app recebeu. Há uma margem de manobra aqui. Consulte "Seu primeiro objetivo".

Atente-se ao aumento da complexidade ao usar heurísticas em um ML sistema. Usar 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 obter o mesmo efeito.

Monitoramento

Em geral, pratique uma boa higiene 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 seu sistema.

Quanto o desempenho será prejudicado se você tiver um modelo de um dia? Uma semana idosas? Um quarto de idade? Essas informações podem ajudar você a entender as prioridades do seu monitoramento. Se você perder produtos significativos a qualidade se o modelo não for atualizado faz sentido ter um engenheiro monitorando continuamente. A maioria dos anúncios de serviço têm novas publicidades para lidar todos os dias e devem ser atualizadas diariamente. Por exemplo, se o modelo de ML de A Pesquisa do Google Play não está atualizada, ele pode ter uma impacto negativo em menos de um mês. Alguns modelos para a seção "Postagens interessantes" O Google Plus não tem identificador de postagem no modelo, então eles podem exportar esses modelos com pouca frequência. Outros modelos que têm identificadores de postagem são atualizado 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 no 9: detecte problemas antes de exportar modelos.

Muitos sistemas de machine learning têm uma etapa em que você exporta o modelo para disponibilização. Se houver um problema com um modelo exportado, será um problema problema.

Faça verificações de integridade antes de exportar o modelo. Especificamente, verifique se que o desempenho do modelo é razoável com dados retidos. Ou, se você tiver continuar com os dados, não exporte um modelo. Muitas equipes modelos de implantação contínua verificam a área abaixo da Curva ROC (ou AUC) antes da exportação. Problemas com modelos que não foram exportados exigem uma alerta por e-mail, mas os problemas em um modelo voltado ao usuário podem exigir uma página. Muito melhor esperar e ter certeza antes de afetar os usuários.

Regra no 10: fique atento a falhas silenciosas.

Esse problema ocorre mais em sistemas de machine learning do que em outros específicos de cada tipo de sistema. Suponha que uma tabela específica que está sendo mesclada não tenha que estão sendo atualizados. O sistema de machine learning vai se ajustar, e o comportamento vão continuar sendo boas, degradando gradualmente. Às vezes, você encontra em tabelas há meses desatualizadas. Uma simples atualização melhora o desempenho. mais do que qualquer outro lançamento naquele trimestre! A cobertura de uma o atributo pode mudar devido a alterações na implementação: por exemplo, uma coluna de atributo poderia ser preenchida em 90% dos exemplos e repentinamente cair para 60% exemplos. O Google Play já tinha uma tabela desatualizada por seis meses e com atualização só a tabela aumentou a taxa de instalação em 2%. Se você acompanha estatísticas os dados, bem como inspecionar manualmente os dados de vez em quando, é possível reduzir esse tipo de falha.

Regra no 11: atribuir 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ê achar que a pessoa que entende que uma coluna de atributos está saindo, certifique-se de que alguém tenha a informações imprecisas ou inadequadas. Embora muitas colunas de atributos tenham nomes descritivos, é bom para ter uma descrição mais detalhada do que é o recurso, de onde ele e como se espera que ele ajude.

Seu primeiro objetivo

Existem muitas métricas ou medições do sistema que são importantes para você, mas seu algoritmo de machine learning geralmente exige um único objetivo, número que o algoritmo está "tentando" precisa ser otimizada. Eu distinguo aqui entre objetivos e métricas: uma métrica é qualquer número que seu sistema relatórios, o que pode ou não ser importante. Consulte também Regra no 2.

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

Você quer ganhar dinheiro, deixar seus usuários felizes e tornar o mundo um lugar Há inúmeras métricas com as quais você se preocupa e deve avaliar todos (consulte a Regra no 2). No entanto, no início do processo de machine learning, você notará que todas elas aumentam, e aqueles que você não otimiza diretamente. Por exemplo, suponha que você se importa com o número de cliques e o tempo gasto no site. Se você otimizar para o número de cliques, é provável que o tempo gasto aumente.

Por isso, mantenha a simplicidade e não pense muito em equilibrar métricas diferentes. quando você ainda pode facilmente aumentar todas as métricas. Não aceitar esta regra também não confunda seu objetivo com a integridade definitiva sistema (consulte Regra no 39). E, se você perceber que está aumentando o número métrica otimizada, mas decidindo não lançar, pode ser que alguma revisão objetiva obrigatório.

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. Você acha que sabe, mas, você analisa os dados e a análise lado a lado do sistema antigo e do novo ML você percebe que quer ajustar o objetivo. Além disso, uma equipe diferente os membros muitas vezes não conseguem chegar a um acordo sobre o verdadeiro objetivo. O objetivo do ML deve ser algo que seja fácil de medir e que seja um substituto para o “verdadeiro” objetivo. Na verdade, muitas vezes não existe "verdadeiro" objetivo (consulte Regra no 39). Então, treinar o objetivo de ML simples e considerar ter uma "camada de política" na parte superior que permite adicionar lógica adicional (espera-se que seja muito simples) para fazer a classificação final.

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

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

No início, evite modelar efeitos indiretos:

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

Efeitos indiretos geram ótimas métricas e podem ser usados durante testes A/B e durante o lançamento de negócios.

Por fim, não tente fazer o machine learning descobrir:

  • O usuário está satisfeito com o uso do 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?

Todos eles são importantes, mas também incrivelmente difíceis de medir. 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 voltará amanhã. Na medida do bem-estar com a integridade da empresa, o julgamento humano é necessário para conectar objetivo de machine learning com a natureza do produto que você está vendendo e 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 motivada por um modelo probabilístico. Cada previsão é interpretável como um probabilidade ou um valor esperado. Isso facilita a depuração deles do que os modelos que usam objetivos (perda zero um, várias perdas de articulação e assim por diante) que tentam para otimizar diretamente a acurácia ou o desempenho da classificação. Para exemplo, se as probabilidades no treinamento se desviarem das probabilidades previstas lado a lado ou inspecionando o sistema de produção, esse desvio poderia para revelar um problema.

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

Com modelos simples, é mais fácil lidar com ciclos de feedback (consulte Regra no 36). Geralmente, usamos essas previsões probabilísticas para tomar uma decisão. Por exemplo, classificação postagens com valor esperado decrescente (ou seja, probabilidade de clique/download/etc.). No entanto, na hora de escolher qual modelo usar, decisão é mais importante do que a probabilidade dos dados de acordo com o modelo (consulte Regra no 27).

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

A classificação de qualidade é uma bela arte, mas a filtragem de spam é uma guerra. Os sinais que que você usa para determinar postagens de alta qualidade se tornarão óbvias para quem usa seu sistema, e ele ajustará suas postagens para ter essas propriedades. Assim, a classificação da qualidade deve se concentrar na classificação do conteúdo que é postado de forma fé. Você não deve desconsiderar o aluno na classificação de qualidade para classificar spam altamente. Da mesma forma, "conteúdo potencialmente ofensivo" conteúdo deve ser tratado separadamente da Qualidade Classificação. A filtragem de spam é outra história. Você deve esperar que o os recursos que você precisa gerar mudam constantemente. Muitas vezes, serão regras óbvias que você colocará no sistema (se uma postagem tiver mais de três votos de spam, não recuperar, etc.). Qualquer modelo aprendido terá sejam atualizados diariamente, se não mais rápido. A reputação do criador conteúdo terá um grande papel.

Em algum nível, a saída desses dois sistemas terá que ser integrada. Manter em mente, filtrar spam nos resultados de pesquisa deve ser mais agressivo do que filtrar 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 do ML: engenharia de atributos

Na primeira fase do ciclo de vida de um sistema de machine learning, questões importantes são colocar os dados de treinamento no sistema de aprendizagem, instrumentadas e criar uma infraestrutura de disponibilização. Depois você tem um sistema funcional de ponta a ponta com testes de unidade e sistema instrumentados, Início da Fase II.

Na segunda fase, há muitas coisas fáceis de conseguir. Há uma variedade recursos óbvios que podem ser inseridos no sistema. Assim, o segundo do machine learning envolve extrair o maior número possível de atributos e combinando-as de maneira intuitiva. Durante essa fase, todas as métricas devem ainda estão aumentando. Haverá muitos lançamentos, e este é um ótimo momento para e chamar muitos engenheiros que possam juntar todos os dados que você precisa para a criar um sistema de aprendizagem realmente incrível.

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

Não espere que o modelo em que você está trabalhando será o último que que você vai lançar ou até mesmo de parar de lançar modelos. Assim, considere se a complexidade que você adiciona com esse lançamento vai diminuir futuros lançamentos. Muitas equipes lançaram um modelo por trimestre ou mais para 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 recursos antigos de novas maneiras.
  • Você está ajustando o objetivo.

Independentemente disso, dar um pouco de amor ao modelo pode ser bom: analisar os dados Alimentar o exemplo pode ajudar a encontrar novos sinais, além de indicadores antigos Então, ao criar seu modelo, pense em como é fácil adicionar ou 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 duas ou três cópias em execução paralelamente. Por fim, não se preocupe com se o atributo 16 de 35 chega a essa versão do pipeline. Você vai obtê-lo no próximo trimestre.

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

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

Se você usa um sistema externo para criar um recurso, lembre-se de que o sistema tem seu próprio objetivo. O objetivo do sistema externo pode ser fraco correlacionado com seu objetivo atual. Se você capturar um snapshot do ambiente no sistema, ele poderá ficar desatualizado. Se você atualizar os recursos da esses significados podem mudar. Se você usa um sistema externo para fornecer um recurso, saiba que essa abordagem requer muito cuidado.

O principal problema com modelos fatorados e profundos é que eles são não convexo. Portanto, não há garantia de que a solução ideal aproximado ou encontrado, e os mínimos locais encontrados em cada iteração podem ser diferente. Com essa variação, é difícil julgar se o impacto de uma mudança no sistema é significativa ou aleatória. Ao criar um modelo sem atributos avançados, você pode ter um excelente desempenho de referência. Depois disso é alcançado, é possível tentar abordagens mais esotéricas.

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

Muitas vezes, um sistema de machine learning é uma pequena parte de um cenário muito maior. Para Por exemplo, se você imaginar que uma postagem pode ser usada no "Postagens interessantes", muitas pessoas marcará com +1, compartilhará de novo ou comentará em uma postagem antes que ela seja exibida na seção "O que há Quente. Se você fornecer essas estatísticas ao aluno, ele poderá promover novas postagens que não tem dados no contexto de otimização. O canal "Assistir a seguir" do YouTube pode usar o número de visualizações ou exibições (número de vezes que um vídeo foi assistido após outro foi assistiram) a partir da pesquisa do YouTube. Também é possível usar avaliações dos usuários. Por fim, se você tiver uma ação do usuário que está usando como um rótulo, ver que a ação no documento em um contexto diferente pode ser uma ótima . Todos esses recursos permitem que você traga novos conteúdos para o contexto. Observe que não se trata de personalização: descubra se alguém gosta da conteúdo nesse contexto primeiro e, em seguida, descubra quem gosta mais ou menos dele.

Regra no 19: use recursos muito específicos sempre que possível.

Com muitos dados, é mais simples aprender milhões de recursos simples do que um recursos complexos. Identificadores de documentos que estão sendo recuperados e consultas canonizadas não fornecem muita generalização, mas alinham suas a classificação com seus rótulos nas consultas de cabeçalho. Portanto, não tenha medo de grupos de atributos em que cada atributo se aplica a uma fração muito pequena dos dados, mas e a cobertura geral está acima de 90%. Você pode usar a regularização para eliminar atributos que se aplicam a poucos exemplos.

Regra no 20: combinar e modificar os elementos existentes para criar novos recursos de maneiras compreensíveis.

Há várias maneiras de combinar e modificar atributos. Aprendizado de máquina como o TensorFlow, é possível pré-processar os dados usando transformações. As duas abordagens mais padrão são as "discretizações" e "cruzes".

A discretização consiste em tomar um atributo contínuo e criar muitas atributos distintos. Considere um atributo contínuo, como idade. Você pode crie um atributo "1" quando a idade for menor que 18 anos, outro atributo 1 quando a idade estiver entre 18 e 35 anos etc. Não pense demais nos limites Histogramas: quantis básicos são a parte mais importante do impacto.

Os cruzamentos combinam duas ou mais colunas de atributos. Uma coluna de atributos, na biblioteca terminologia, é um conjunto de atributos homogêneos, (por exemplo, {male, female}, {US, Canadá, México} etc.). Uma cruz é uma nova coluna de atributo com atributos em por exemplo, {male, female} × {EUA,Canadá, México}. Essa nova coluna de atributo conterá o recurso (masculino, Canadá). Se você usa o TensorFlow e diga ao TensorFlow para criar esse cruzamento para você, esse atributo (masculino, Canadá) vai estar presente em exemplos que representam canadenses do sexo masculino. Observe que o tempo gasto quantidades de dados para aprender modelos com cruzamentos de três, quatro ou mais colunas de atributos.

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

Ao trabalhar com texto, há duas alternativas. O mais draconiano é o produto escalar. Na forma mais simples, um produto escalar simplesmente conta o número de palavras em comum entre a consulta e o documento. Esse recurso pode ser com discretização. Outra abordagem é a interseção: assim, teremos um atributo que está presente apenas se a palavra "pônei" está no documento e no consulta, e outro recurso que está presente apenas se a palavra "o" está em o documento e a 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 da aprendizagem estatística sobre as nível apropriado de complexidade para um modelo, mas essa regra é basicamente que você precisa saber. Tive conversas em que as pessoas estavam duvidosas tudo pode ser aprendido com mil exemplos, ou que você jamais precisam de mais de um milhão de exemplos, porque eles ficam presos 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 você tem 1.000 exemplos rotulados, use um produto escalar entre e recursos de consulta, TF-IDF, e meia dúzia de outros equipamentos altamente incorporados atributos de machine learning. 1.000 exemplos, uma dúzia de recursos.
  2. Se você tiver um milhão de exemplos, cruze o documento e a consulta colunas de atributos, usando regularização e possivelmente seleção de atributos. Você terá milhões de recursos, mas com a regularização terão menos. Dez milhões de exemplos, talvez cem mil recursos.
  3. Se você tiver bilhões ou centenas de bilhões de exemplos, poderá as colunas de atributo com tokens de documento e consulta, usando a seleção de atributos e regularização. Você terá 1 bilhão de exemplos e 10 milhões atributos de machine learning. A teoria da aprendizagem estatística raramente define limites apertados, mas um ótimo ponto de partida.

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

Regra no 22: limpe os recursos que você não usa mais.

Recursos não utilizados geram débitos técnicos. Se você achar que não está usando uma recurso e se a combinação dele com outros recursos não estiver funcionando, fora da sua infraestrutura. Você quer manter sua infraestrutura limpa para para que os recursos mais promissores possam ser testados o mais rápido possível. Se necessário, alguém poderá sempre adicionar o atributo.

Considere a 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 seus usuários têm alguma personalização recursos, isso não será muito eficaz.

Ao mesmo tempo, alguns recursos podem ser superados. Por exemplo, se Você tem um atributo que cobre apenas 1% dos dados, mas 90% dos exemplos que tenham a característica sejam positivas, será um ótimo recurso a ser adicionado.

Análise humana do sistema

Antes de passarmos 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 ciência, mas há vários antipadrões que ele ajuda a evitar.

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

Talvez essa seja a maneira mais fácil de uma equipe ficar presa. Embora existam muitos benefícios para a fishfooding (usar um protótipo dentro de sua equipe) e dogfood (usando um protótipo na sua empresa), os funcionários devem olhar se o desempenho está correto. Uma mudança que é obviamente ruim não deve ser usado, qualquer coisa que pareça razoavelmente próxima da produção deve ser foram testados mais a fundo, seja pagando pessoas leigas para responder a perguntas plataforma de crowdsourcing ou por meio de um experimento ao vivo com usuários reais.

Há duas razões para isso acontecer. O primeiro é que você está muito perto o código-fonte. Talvez você esteja procurando um aspecto específico das postagens ou esteja simplesmente muito emocionalmente envolvido (por exemplo, viés de confirmação). O segundo é que seu tempo é precioso demais. Considere o custo de nove engenheiros em um de uma hora de reunião e pense em quantas etiquetas humanas foram contratadas para comprar plataforma de crowdsourcing.

Se você realmente quiser receber feedback dos usuários, use a experiência do usuário metodologias. Criar personas de usuário (uma descrição na Esboçar experiências do usuário) no início de um processo e fazer testes de usabilidade (uma está na obra de Steve Krug, Não me faça pensar) mais tarde. Perfis de usuários envolvem a criação de um usuário hipotético. Por exemplo, se sua equipe é totalmente masculina, pode ajudar a projetar uma persona de usuário feminina de 35 anos (completa recursos) e analisar os resultados que ele gera em vez de 10 resultados para Homens de 25 a 40 anos. Trazer pessoas reais para observar a reação delas nos testes de usabilidade do seu site (local ou remotamente) também pode trazer em uma perspectiva hierárquica.

Regra no 24: meça o delta entre modelos.

Uma das medidas mais fáceis e, às vezes, mais úteis que você pode fazer qualquer usuário já viu o novo modelo é calcular o quão diferentes os novos resultados vêm da produção. Por exemplo, se você tiver um problema de classificação, executar os dois modelos em uma amostra de consultas em todo o sistema e analisar o tamanho da diferença simétrica dos resultados (ponderado pela classificação posição). Se a diferença for muito pequena, você poderá perceber isso sem executar um experimento que haverá pouca mudança. Se a diferença for muito grande, convém ter certeza de que a alteração é boa. Análise consultas em que a diferença simétrica é alta pode ajudar você a entender qualitativamente como foi a mudança. No entanto, certifique-se de que o sistema esteja o estábulo. Certifique-se de que um modelo, em comparação com ele mesmo, tenha uma baixa (o ideal é zero) diferença simétrica.

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 chave questão é o que você faz com essa previsão. Se você o usa para classificar documentos, a qualidade da classificação final importa mais do que previsão em si. Se você prever a probabilidade de um documento ser spam e ter um limite sobre o que está bloqueado, a precisão do que é permitido nos assuntos mais. Na maioria das vezes, esses dois itens devem estar um acordo: quando não concordarem, provavelmente terá um pequeno ganho. Assim, se há alguma mudança que melhora a perda de registros, mas prejudica o desempenho no sistema, procure outro recurso. Quando isso começar a acontecer com mais frequência, é hora de rever o objetivo do seu modelo.

Regra no 26: procure padrões nos erros medidos e crie novos atributos.

Imagine que você está vendo um exemplo de treinamento em que o modelo estava "errado". Em um 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 abaixo do que um negativo. O ponto mais importante é que este é um exemplo sistema de machine learning sabe que algo deu errado e gostaria de corrigir se receber oportunidade. Se você der ao modelo um recurso que permita corrigir o erro, o modelo vai tentar usá-la.

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

Quando você tiver exemplos de que o modelo cometeu um erro, procure tendências que sejam fora do conjunto de recursos atual. Por exemplo, se o sistema parece estar rebaixar postagens mais longas e adicionar o tamanho da postagem. Não seja muito específico sobre o recursos que você adicionar. Se você for adicionar comprimentos de postagem, não tente adivinhar ou seja, basta adicionar uma dúzia de atributos, e o modelo vai descobrir o que fazer com ele (consulte 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 de sua equipe começarão a ficar frustrados com as propriedades que não gostam e não são capturados pela função de perda atual. Em Nesse ponto, eles devem fazer o que for preciso para transformar as queixas em pontos fortes números grandes. Por exemplo, se ele achar que muitos "apps de gag" estão sendo mostrados na Pesquisa do Google Play, os revisores humanos podem identificar os apps de gag. Você pode usar dados rotulados por humanos de maneira viável nesse caso porque uma pequena das consultas representam uma grande fração do tráfego. Se as problemas sejam mensuráveis, então você pode começar a usá-los como recursos, objetivos ou métricas. A regra geral é medir primeiro, otimizar depois.

Regra no 28: lembre-se de que comportamentos idênticos em curto prazo não implicam comportamentos de longo prazo idênticos.

Imagine que você tem um novo sistema que analisa cada doc_id e exatamente_query, e calcula a probabilidade de clique para cada documento para cada consulta. Você descobre que seu comportamento é quase idêntico ao do sistema atual em ambos lado a lado e testes A/B, então, devido à simplicidade, você o lança. No entanto, você percebe que nenhum app novo está sendo mostrado. Por quê? Como seus mostra apenas um documento baseado em seu próprio histórico com aquela consulta, não há para saber que um novo documento deve ser mostrado.

A única maneira de entender como esse sistema funciona no longo prazo é ter ele é treinado apenas nos dados adquiridos quando o modelo estava ativo. Isso é muito difícil.

Desvio de treinamento para disponibilização

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

  • Uma discrepância entre o processamento de dados nos pipelines de treinamento e de disponibilização.
  • Uma alteração nos dados entre o momento de treinamento e o momento de disponibilização.
  • Um ciclo de feedback entre o modelo e o algoritmo.

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

Regra no 29: a melhor maneira de treinar da mesma forma que você faz é salvar o conjunto de atributos usado no momento da disponibilização e, em seguida, canalizar 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 isso para uma pequena fração, como para verificar a consistência entre a disponibilização e o treinamento (consulte Regra no 37). Equipes que fizeram isso de medição no Google às vezes ficavam surpresos com os resultados. Página inicial do YouTube mudou para recursos de geração de registros no momento da veiculação e redução da complexidade do código, e muitas equipes estão migrando a infraestrutura enquanto conversamos.

Regra no 30: dados de amostra de peso e importância; não os elimine arbitrariamente!

Quando você tem dados demais, há a tentação de pegar os arquivos de 1 a 12, e ignora os arquivos de 13 a 99. Isso não está certo. Embora os dados que foram nunca mostrada ao usuário pode ser descartada, a ponderação de importância é melhor para o descansar. A ponderação por importância significa que, se você decidir que vai exemplo X com uma probabilidade de 30%, então dê a ele um peso de 10/3. Com ponderação de importância, todas as propriedades de calibração discutidas Regra no 14 ainda se espera.

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

Digamos que você mescle IDs de documentos com uma tabela que contém recursos para esses documentos (como número de comentários ou cliques). Entre o momento do treinamento e da disponibilização, os atributos na tabela podem ser alteradas. A previsão do seu modelo para o mesmo documento pode e, em seguida, diferem no treinamento e na disponibilização. A maneira mais fácil de evitar isso problema é registrar os atributos no momento da disponibilização (consulte Regra no 32 ). Se a tabela for as mudanças são lentas, você também pode capturar um snapshot da tabela a cada hora ou diariamente para ter dados razoavelmente próximos. Observe que isso ainda não resolve completamente o problema.

Regra no 32: reutilize o 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 online, você precisa lidar com cada solicitação assim que ela chegar (por exemplo, é preciso fazer uma consulta para cada consulta), enquanto no processamento em lote, é possível combinar tarefas (por exemplo, fazer uma mesclagem). No momento da veiculação, você faz o processamento on-line, enquanto o treinamento é uma tarefa de processamento em lote. No entanto, há algumas coisas que você para reutilizar códigos. Por exemplo, é possível criar um objeto específico do seu sistema, onde o resultado de quaisquer consultas ou mesclagens pode ser armazenados de modo legível, e os erros podem ser testados com facilidade. Depois, Depois de coletar todas as informações, durante a exibição ou o treinamento, executar um método comum para fazer uma ponte entre o objeto legível por humanos que é específicas para seu sistema e em qualquer formato que o sistema de machine learning espera. Isso elimina uma fonte de desvio de treinamento/disponibilização. Como como resultado, tente não usar duas linguagens de programação diferentes no treinamento e disponibilização. Essa decisão vai tornar quase impossível você compartilhar o código-fonte.

Regra no 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, medir o desempenho de um modelo com os dados coletados após os dados com o qual você treinou o modelo, pois isso reflete melhor o que seu sistema fará em a produção. Se você produzir um modelo com base nos dados até 5 de janeiro, teste o modelo com os dados de 6 de janeiro. Você espera que o desempenho não será 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 o valor médio de cliques ou taxa de conversão, mas a área sob a curva, que representa a probabilidade de dar ao exemplo positivo uma pontuação maior do que uma negativa deve ser 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 para dados muito limpos.

Em uma tarefa de filtragem, os exemplos marcados como negativos não são mostrados para o usuário. Suponha que você tenha um filtro que bloqueie 75% dos exemplos negativos na veiculação. Talvez você fique tentado a extrair mais dados de treinamento instâncias mostradas aos usuários. Por exemplo, se um usuário marca um e-mail como spam que que o filtro deixa passar, talvez você queira aprender com isso.

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

Se o filtro estiver bloqueando 95% ou mais dos exemplos negativos, abordagem se torna menos viável. Mesmo assim, se você quiser medir a desempenho, é possível criar uma amostra ainda mais minúscula (por exemplo, 0,1% ou 0,001%). Dez mil exemplos é suficiente para estimar o desempenho com bastante precisão.

Regra no 35: cuidado com a distorção inerente dos problemas de classificação.

Quando você muda seu algoritmo de classificação de forma radical o suficiente para que resultados diferentes aparecer, você alterou efetivamente os dados que o algoritmo vai ver no futuro. Esse tipo de distorção vai aparecer, e você deve projetar um modelo em torno dele. Há várias abordagens diferentes. Essas abordagens são todas as maneiras de favorecer dados que seu modelo já viu.

  1. Têm maior regularização em recursos que abrangem mais consultas, em vez de os recursos que estão ativados para apenas uma consulta. Dessa forma, o modelo favorece atributos específicos de uma ou algumas consultas sobre atributos que generalizar para todas as consultas. Essa abordagem pode ajudar a evitar que os resultados vazem para consultas irrelevantes. Observe que ele é oposto ao aconselhamento mais convencional de aumentar a regularização nas colunas de atributos com valores mais exclusivos.
  2. Só permita que os atributos tenham pesos positivos. Assim, qualquer bom atributo será é melhor do que um atributo "desconhecido".
  3. não têm recursos apenas para documentos; Esta é a versão extrema do no 1. Para por exemplo, mesmo que um determinado aplicativo seja um download popular, independentemente do era não mostrar em todos os lugares. Não ter a opção "Somente documento" recursos simplificam isso. O motivo pelo qual você não quer mostrar um aplicativo popular em todos os lugares tem a ver com a importância de tornando todos os aplicativos desejados acessíveis. Por exemplo, se alguém pesquisar "aplicativo de observação de pássaros", eles podem fazer o download de "angrybirds", mas isso certamente não era a intenção deles. Mostrar esse app pode melhorar a taxa de download, mas deixam as necessidades do usuário insatisfeitas.

Regra no 36: evite ciclos de feedback com atributos de posicionamento.

A posição do conteúdo afeta drasticamente a probabilidade de o usuário interagir a ele. Se você colocar um aplicativo na primeira posição, ele será clicado com mais frequência, e você ficará convencido de que ele tem mais chances de ser clicado. Uma forma de lidar com isso é adicionar atributos de posicionamento, ou seja, atributos sobre a posição do o conteúdo da página. Você treina seu modelo com atributos de posicionamento aprende a ponderar, por exemplo, o atributo "1a posição" muito. Seu modelo Assim, outros fatores têm menos peso para exemplos com "1stposition=true". Na disponibilização, você não dá a nenhuma instância o atributo de posição ou dá a todos o mesmo recurso padrão, porque você pontua os candidatos antes de decidiram a ordem em que eles serão exibidos.

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

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

Há vários fatores que podem causar desvios 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 a validação dados. Em geral, isso sempre vai existir e nem sempre é ruim.
  • A diferença entre o desempenho nos dados não incluídos e o "próximo dia" dados. Novamente, isso sempre vai existir. Você deve ajustar sua regularização para maximizar o desempenho do dia seguinte. No entanto, quedas grandes no desempenho entre os dados de validação e os do dia seguinte pode indicar que alguns atributos são são sensíveis ao tempo e podem degradar o desempenho.
  • A diferença entre o desempenho no "dia seguinte" dados e os dados em tempo real dados. Se você aplicar um modelo a um exemplo nos dados de treinamento e a mesma exemplo na disponibilização, isso deve fornecer exatamente o mesmo resultado (consulte Regra no 5 ). Assim, 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. Em primeiro lugar, seus ganhos mensais começarão a diminuir. Você vai começar a ter as vantagens e desvantagens das métricas: haverá um aumento e outro de queda experimentos. É aqui que tudo fica interessante. Como os ganhos são mais difíceis alcançar, o machine learning precisa ficar mais sofisticado. Uma ressalva: isso tem mais regras de céu azul do que as seções anteriores. Vimos muitas equipes os momentos felizes das fases I e II do machine learning. Fase uma vez III foi alcançado, as equipes precisam encontrar seu próprio caminho.

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

À medida que suas medições estiverem estabilizadas, a equipe começará a analisar os problemas fora do escopo dos objetivos do seu sistema atual de machine learning. Conforme mencionado anteriormente, se as metas do produto não forem cobertas pelo algoritmo você precisa mudar seu objetivo ou as metas do produto. Para por exemplo, você pode otimizar cliques, sinais de adição ou downloads, mas decisões baseadas em classificação humana.

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

Alice tem uma ideia sobre como reduzir a perda logística da previsão de instalações. Ela adiciona um recurso. A perda logística cai. Quando ela faz um experimento ao vivo, tem um aumento na taxa de instalação. No entanto, quando ela vai para uma análise de lançamento, reunião, alguém salienta 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 otimizadas diretamente usando ML.

A verdade é que o mundo real não é uma masmorra ou dragão: não existem masmorras ou dragões pontos" identificar a integridade do produto. A equipe precisa usar estatísticas coletadas para tentar prever de forma eficaz a qualidade do sistema no futuro. Ele precisa se preocupar com o engajamento, usuários ativos por 1 dia (DAU), 30 DAU, a receita e o retorno do investimento do anunciante. Essas métricas que são e mensuráveis em testes A/B por si só são apenas um indicador objetivos: satisfazer usuários, aumentar usuários, satisfazer parceiros e lucro, que, mesmo assim, você poderia considerar proxies por ter um produto útil e de alta qualidade produto e uma empresa próspera daqui a cinco anos.

As únicas decisões fáceis de lançamento são quando todas as métricas ficam melhores (ou pelo menos não piorar). Se a equipe tiver uma escolha entre uma máquina sofisticada de machine learning e uma heurística simples, se ela fizer uma para trabalhar melhor em todas essas métricas, ele deve escolher a heurística. Além disso, há não há uma classificação explícita de todos os valores de métrica possíveis. Considere especificamente as dois cenários a seguir:

Experimento 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, então a equipe provavelmente não mudaria para A. Isso parece em conflito com o comportamento racional; No entanto, as previsões de mudanças métricas podem ou não se sair bem, e há um grande risco envolvido qualquer alteração. Cada métrica cobre algum risco com o qual a equipe está preocupada.

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

Por outro lado, indivíduos tendem a favorecer um objetivo que possam otimizar diretamente. A maioria das ferramentas de machine learning favorece esse ambiente. Um que trabalha com novos recursos pode obter um fluxo constante de lançamentos em um de nuvem. Existe um tipo de machine learning, aprendizado com vários objetivos, o que começa a resolver esse problema. Por exemplo, é possível formular problema de satisfação de restrição que tem limites inferiores em cada métrica, e otimiza alguma combinação linear de métricas. No entanto, mesmo assim, nem todos são facilmente enquadradas como objetivos de machine learning: se um documento for clicou ou se um app está instalado, é porque o conteúdo foi mostrado. Mas é muito mais difícil descobrir por que um usuário acessa seu site. Como prever o sucesso futuro de um site como um todo AI-complete: tão difícil quanto o computador processamento de linguagem natural ou de visão.

Regra no 40: mantenha os conjuntos simples.

Modelos unificados que absorvem atributos brutos e classificam o conteúdo diretamente são os modelos mais fáceis de depurar e entender. No entanto, um conjunto de modelos (uma "modelo" que combina as pontuações de outros modelos) pode funcionar melhor. Para manter simples, cada modelo deve ser um ensemble apenas com a entrada de outros modelos ou um modelo base com muitos recursos, mas não ambos. Se você tiver modelos em cima de outros modelos treinados separadamente e, em seguida, combiná-los pode resultar em mau comportamento.

Use um modelo simples para ensemble que use apenas a saída da sua "base" modelos 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 deve diminuir a pontuação do conjunto. Além disso, é melhor se os modelos recebidos semanticamente interpretáveis (por exemplo, calibrados) para que as alterações da os modelos não confundem o modelo de conjunto. Além disso, exija que um de aumento na probabilidade prevista de um classificador subjacente não diminuir a probabilidade prevista do ensemble.

Regra no 41: quando a performance estiver estagnada, procure novas fontes de informação qualitativamente novas para adicionar, 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ê consultou o modelo e ajustou a regularização. Você nunca viu um lançamento com mais do que uma melhoria de 1% nas suas principais métricas em alguns trimestres. E agora?

Chegou a hora de começar a criar uma infraestrutura para um ambiente totalmente diferente recursos, como o histórico de documentos que esse usuário acessou no último dia, semana ou ano, ou dados de outra propriedade. Usar wikidata (em inglês) entidades ou algo interno à empresa (como as Mapa do conhecimento). Usar profundidade o aprendizado. Comece a ajustar suas expectativas sobre o valor do retorno do investimento esperado e ampliar os esforços com base nisso. Como em qualquer de engenharia de dados, é preciso ponderar o benefício de adicionar novos atributos em comparação com o custo de maior complexidade.

Regra no 42: não espere que diversidade, personalização ou relevância tenham relação com a popularidade como você acha.

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

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

Se seu sistema estiver medindo cliques, tempo gasto, visualizações, +1s, novos compartilhamentos etc., você está medindo a popularidade do conteúdo. Equipes às vezes tentam aprender um modelo pessoal com diversidade. Para personalizar, ele adiciona recursos que permitem a personalização do sistema (alguns recursos que representam o interesse do usuário) ou diversificar (recursos que indicam se o documento tem recursos em comum com outros documentos retornados, como autor ou conteúdo), e perceber que esses recursos ganham menos peso (ou, às vezes, um sinal diferente) do que o esperado.

Isso não significa que a diversidade, a personalização ou a relevância não sejam valiosas. Conforme mencionado na regra anterior, você pode fazer o pós-processamento para aumentar diversidade ou relevância. Se você notar um aumento nos objetivos de longo prazo, declarar que a diversidade/relevância é valiosa, além da popularidade. Você pode continuar a usar o pós-processamento ou modificar diretamente o 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 força ao usar um modelo que prevê proximidade de uma conexão em um produto e fazer com que funcione bem em outro. Seus amigos são quem são. Por outro lado, observei várias equipes tem dificuldades com os recursos de personalização em diferentes produtos. Sim, ao que parece da forma que deveria funcionar. Por enquanto, não parece que sim. O que às vezes é usar dados brutos de uma propriedade para prever o comportamento em outra. Além disso, tenha em mente que 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 indicativo em si e 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, Jeremiah Harmsen e Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan e Su Lin Wu, Jaihui Liu, Fernando Pereira e Hrishikesh Aradhye, para muitas correções, sugestões e exemplos úteis para este documento. Além disso, graças a Kristen Lefevre, Suddha Basu e Chris Berg, que ajudaram com uma versão anterior. Qualquer um erros, omissões ou opiniões impopulares são minhas.

Apêndice

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

Visão geral do YouTube

O YouTube é um serviço de streaming de vídeo. Tanto o canal "Assista a seguir" do YouTube quanto a página inicial do YouTube As equipes de páginas usam modelos de ML para classificar recomendações de vídeos. Recomendações do canal "Assistir a seguir" vídeos para assistir depois do que está em reprodução, enquanto a Página inicial recomenda vídeos a usuários que navegam na página inicial.

Visão geral do Google Play

O Google Play tem muitos modelos que resolvem uma variedade de problemas. Pesquisa no Google Play, Google Play As recomendações personalizadas na página inicial e os apps "Os usuários também instalaram" usam machine learning.

Visão geral do Google+

O Google+ usou aprendizado de máquina em diversas situações: classificando postagens em o "stream" de postagens vistas pelo usuário, com a classificação "Postagens interessantes" posts (postagens que estão em alta), classificando as pessoas que você conhece etc. Google+ encerrou todas as contas pessoais em 2019 e foi substituída pelo Google Currents para contas empresariais em 6 de julho de 2020.