By Sai Gita, especialista em Engenharia de Big Data e Ciência de Dados.

A Arquitetura Rendezvous proposto por Ted Dunning e Ellen Friedman em seu livro sobre Logística de aprendizado de máquina foi uma solução maravilhosa que encontrei para um problema arquitetônico específico no qual estava trabalhando. Eu estava procurando um padrão de design ou padrão arquitetônico testado e comprovado que me ajudasse a executar os modelos Challenger e Champion juntos de maneira sustentável e com suporte. A arquitetura rendezvous era significativamente mais útil no mundo do big data porque você está lidando com dados pesados ​​e grandes pipelines.

A capacidade de executar modelos Challenger e Champion juntos em todos os dados é uma necessidade muito genuína no aprendizado de máquina, onde o desempenho do modelo pode variar com o tempo e onde você deseja continuar melhorando o desempenho de seus modelos para algo sempre melhor.

Portanto, antes de me aprofundar nessa arquitetura, gostaria de esclarecer alguns dos jargões que usei acima. O que é um modelo Champion? O que é um modelo Challenger? O que é o desvio do modelo e por que ele ocorre? Em seguida, podemos examinar a própria arquitetura do rendezvous e os problemas que ela resolve.

Deriva do Modelo

Depois de colocar seu modelo em produção, presumir que ele sempre terá um bom desempenho é um erro. Na verdade, é dito - “No momento em que você coloca um modelo em produção, ele começa a degradar. "(Observe, na maioria das vezes 'atuação'em ML é usado para significar desempenho estatístico - seja exatidão, precisão, recall, sensibilidade, especificidade ou qualquer que seja a métrica apropriada para o seu caso de uso).

Por que isso acontece? O modelo é treinado em alguns dados anteriores. Ele tem um desempenho excelente para qualquer dado com as mesmas características. No entanto, com o passar do tempo, as características reais dos dados podem continuar mudando, e o modelo não está ciente dessas mudanças. Isso causa desvio do modelo, ou seja, degradação no desempenho do modelo.

Por exemplo, você treinou um modelo para detectar e-mail de spam versus e-mail de spam. O modelo funciona bem quando implantado. Com o tempo, os tipos de spam continuam se transformando e, portanto, a precisão da previsão diminui. Isso é chamado deriva do modelo.

O desvio do modelo pode acontecer por causa de um deriva de conceito ou um deriva de dados. Não estou entrando nisso hoje, então nos bastará entender que o desempenho de um modelo não permanece constante. Portanto, precisamos monitorar continuamente o desempenho de um modelo. Na maioria das vezes, é melhor treinar novamente o modelo com dados mais recentes com mais frequência ou provavelmente com base em um nível de limite na degradação do desempenho.

Às vezes, mesmo o retreinamento do modelo não melhora ainda mais o desempenho. Isso implicaria que você teria que entender as mudanças nas características do problema e passar por todo o processo de análise de dados, criação de recursos e construção de modelo com modelos mais apropriados.

Este ciclo pode ser reduzido se você puder trabalhar com modelos Challenger, mesmo quando temos um modelo em produção atualmente. Este é um processo de melhoria contínua de aprendizado de máquina e é muito necessário.

Modelos campeão-desafiador

Normalmente, o modelo em produção é chamado de Campeão modelo. E qualquer outro modelo que parece funcionar bem em seus testes menores e está pronto para entrar em produção é um desafiador modelo. Esses modelos Challenger foram propostos porque presumimos que há uma chance de que tenham um desempenho melhor do que o modelo Champion. Mas como o provamos?

Um modelo Champion normalmente é executado em todos os dados de entrada para fornecer as previsões. No entanto, em quais dados o modelo Challenger é executado?

Existem duas maneiras de testar os modelos Challenger. O caso ideal seria rodar o modelo Challenger em paralelo com o modelo Champion em todos os dados e comparar os resultados. Isso realmente provaria que o modelo Challenger pode ter um desempenho melhor ou não. No entanto, isso parece proibitivo, especialmente no mundo do big data e, portanto, o Challenger é sempre testado em um subconjunto dos dados de entrada. Uma vez que parece ter um bom desempenho, ele é gradualmente implementado em mais e mais dados, quase como um teste alfa-beta.

Como você deve estar ciente, no teste alfa-beta, uma pequena porcentagem de usuários ou dados de entrada, neste caso, é enviada por meio de um novo teste ou pipeline do Challenger, e o restante passa pelo pipeline original do Champion. Esse tipo de teste alfa-beta é bom para alguns aplicativos, mas claramente não é muito impressionante no mundo do aprendizado de máquina. Você não está comparando os modelos nos mesmos dados e, portanto, raramente pode dizer com confiança que um é melhor do que o outro para todos os dados. Pode haver surpresas ocultas assim que você implementá-lo para todos os dados, e o desvio do modelo pode começar mais cedo do que o esperado.

Um pipeline alfa-beta típico seria assim:

Os dados são divididos entre os dois pipelines com base em alguns critérios, como a categoria de um produto. Essa divisão de dados continua aumentando para o Challenger conforme a confiança no desempenho do modelo do Challenger cresce.

Do ponto de vista de um cientista de dados, isso não é ideal. O ideal seria poder rodar o modelo Challenger em paralelo por todos os dados junto com o modelo Champion. Como eu disse antes, isso é muito caro.

Considere o pior cenário. Se você deseja que eles sejam executados em paralelo, é necessário configurar dois pipelines de dados que percorram todas as etapas de forma independente.

Seria algo parecido com isto:

Isso tem enormes implicações de engenharia e, portanto, implicações de tempo para o mercado. O custo disso pode ficar proibitivo com o tempo.

Algumas das principais implicações são o tempo e o esforço em construir esses pipelines repetidamente, sem ter certeza de que o modelo Challenger realmente funcionará conforme o esperado. O processo de CI / CD, as implantações, o monitoramento, os mecanismos de autenticação, etc., são alguns a serem mencionados. Além disso, o outro custo é em torno da infraestrutura que precisa ser duplamente provisionada.

Considerando que esses pipelines são pipelines de big data, isso se torna ainda mais significativo. Muito em breve, você percebe que este não é um modelo escalonável. Certamente temos que ver como podemos nos afastar de pipelines paralelos ou mesmo do método de teste alfa-beta.

Como corolário, o melhor cenário seria quando podemos reutilizar muitos dos pipelines de dados. A ideia é minimizar a quantidade que se tem para desenvolver e implantar novamente na produção. Isso também garantiria a otimização do uso da infraestrutura. Esta é uma linha de pensamento sobre como otimizar.

Melhor ainda seria poder apenas conecte o modelo Challenger, e o resto do pipeline é reproduzido como se nada tivesse mudado. Não seria fantástico? E é isso que é possível graças ao Arquitetura Rendezvous.

Arquitetura Rendezvous

A arquitetura Rendezvous, conforme escrito no livro, é inclinada para ML com dados menores. Eu o ajustei para atender às necessidades do mundo de big data e pipelines associados, conforme mostrado no diagrama abaixo: (As referências ao livro e outro artigo são fornecidas abaixo na seção de referências)

Deixe-me agora explicar seção por seção desta arquitetura.

1 parte:

Isso consiste no pipeline de dados padrão para receber dados de entrada, limpá-los, prepará-los e criar os recursos necessários. Deve ser apenas um pipeline para cada modelo a ser implantado. Os dados preparados devem manter uma interface padrão que tenha todos os recursos que podem ser necessários naquele domínio, independentemente do modelo em mãos. (Eu entendo que isso nem sempre é possível e pode precisar de ajustes graduais ao longo do tempo. Mas podemos lidar com essa peça isoladamente, quando necessário.)

2 parte:

Essa é uma infraestrutura de mensagens como o Kafka, que entra em jogo trazendo o sentido de assincronicidade. Os dados preparados como recursos são publicados no barramento de mensagens. Agora, cada modelo escuta esse barramento de mensagem e dispara, executando a si mesmo com os dados preparados. Esse barramento de mensagem é o que permite uma arquitetura plug-and-play aqui.

3 parte:

Esta é a parte em que todos os modelos são implantados um por um. Um novo modelo Challenger pode ser implantado e feito para ouvir o barramento de mensagens e, conforme os dados fluem, ele pode ser executado. Qualquer número de modelos pode ser implantado aqui e não apenas um modelo Challenger! Além disso, o requisito de infra é apenas para o modelo extra rodar. Nem os pipelines pré-modelo nem os pipelines pós-modelo precisam ser desenvolvidos ou implantados separadamente.

Como você pode ver na figura, você pode ter muitos modelos desafiadores, desde que o cientista de dados os veja maduros o suficiente para serem testados em relação aos dados reais.

Além disso, existe um modelo especial denominado modelo chamariz. A fim de garantir que cada um dos processos do modelo não seja sobrecarregado com persistência, os dados preparados também são lidos pelo que é chamado de modelo isca, cujo único trabalho é ler os dados preparados e persistir. Isso ajuda para fins de auditoria, rastreamento e depuração quando necessário.

4 parte:

Todos esses modelos novamente geram suas previsões ou pontuações em outro barramento de mensagem, não trazendo nenhuma dependência entre eles. Além disso, novamente, isso desempenha um papel importante em garantir a conectividade de um modelo sem interromper qualquer outra coisa no pipeline.

A partir daí, o processo de encontro seleciona as pontuações e decide o que precisa ser feito, conforme descrito na Parte 5.

5 parte:

É aqui que surge o novo conceito de um Processo de encontro é apresentado, que tem dois subprocessos importantes. Um subprocesso imediato se encarrega de transmitir a saída correta do pipeline para um consumidor entre as muitas pontuações que recebeu, e o outro processo é persistir a saída de todos os modelos para posterior comparação e análise.

Portanto, alcançamos duas coisas aqui:

1. O melhor resultado é fornecido ao consumidor.
2. Todos os dados passaram por todos os modelos e, portanto, são totalmente comparáveis ​​em circunstâncias semelhantes em seu desempenho.

Como ele decide qual saída do modelo deve ser enviada? Isso pode ser baseado em vários critérios, como um subconjunto de dados deve ser sempre do Challenger e outro subconjunto deve ser sempre do Champion. Isso é quase como realizar o teste alfa-beta. No entanto, a vantagem aqui é que, embora pareça um teste alfa-beta para um consumidor, para o cientista de dados, todos os dados passaram por ambos os modelos e, portanto, eles podem comparar as duas saídas e entender qual está tendo melhor desempenho.

Outro critério pode ser que o resultado seja baseado no desempenho do modelo. Nesse caso, o processo de rendezvous espera que todos os modelos sejam concluídos e publicados no barramento de mensagem. Em seguida, ele busca a melhor métrica de desempenho e a envia como resultado.

Sim, outro critério pode ser o de tempo ou latência. Se precisarmos ter o resultado em, digamos, menos de 5 segundos, por exemplo, o processo espera por todos os resultados dos modelos, até 5 segundos, compara apenas esses e retorna os melhores dados. Mesmo que outro modelo volte no 6º segundo e possa ter um desempenho muito melhor, ele é ignorado, pois não atende aos critérios de latência.

Mas como esse processo sabe quais são os critérios a seguir para quais dados ou qual modelo? Isso pode ser colocado como parte dos dados de entrada no barramento de mensagem na Parte 2. Observe que o processo Rendezvous também está ouvindo essas mensagens e sabe o que fazer com a saída que corresponde a uma entrada. Poderia haver outras maneiras inteligentes também, mas esta é uma das maneiras propostas.

Conclusão

Ao introduzir a assincronicidade por meio de barramentos de mensagem, um nível de desacoplamento foi introduzido, trazendo a capacidade de modelos plug-and-play em um pipeline de dados rígido.

Ao introduzir o processo de rendezvous, a capacidade de selecionar entre várias saídas do modelo, persisti-los e compará-los foi introduzida. E com isso, agora não parece uma tarefa hercúlea introduzir ou dar suporte a qualquer número de novos modelos para o mesmo conjunto de dados.

Sumário

A arquitetura de rendezvous oferece grande flexibilidade em vários níveis.

1. Uma variedade de critérios pode ser usada para decidir qual pontuação, saída ou previsão pode ser enviada para fora do processo de previsão. Esses critérios podem ser baseados em latência, modelo de desempenho ou simples baseado em tempo.
2. Ele fornece a capacidade de definir e alterar esses critérios dinamicamente por meio do processo de rendezvous. Você pode levá-lo para outro nível, introduzindo um mecanismo de regras aqui.
3. Ele fornece a capacidade de fazer todos os dados passarem por todos os pipelines ou escolher apenas um subconjunto para passar por muitos pipelines. Por exemplo, se você tem produtos de mercearia e merchandising geral para os quais está fazendo uma previsão, os mantimentos podem passar por seus próprios modelos Champion e Challenger, enquanto mercadorias em geral, que normalmente vendem lentamente, podem ter seus próprios pipelines.
4. Ele também oferece a capacidade de executar muitos modelos de uma vez sem desenvolver ou reimplantar uma grande parte de um pipeline de big data. Além da economia de tempo e esforço, os custos de infraestrutura também são otimizados.

Referências

1. Logística de aprendizado de máquina por Ted Dunning; Ellen Friedman - 3º Capítulo sobre “A Arquitetura Rendezvous para Aprendizado de Máquina”
2. Um artigo sobre paradatascience.com"Arquitetura Rendezvous para Ciência de Dados em Produção”Por Jan Teichmann

Óptimo estado. Original. Republicado com permissão.

Bio: Sai Gita (@saigeethamn) é um arquiteto com experiência na criação de roteiros estratégicos e inovação com base nas necessidades da empresa e tecnologias de ponta. Um especialista em Big Data com conhecimento de Data Science que pode preencher a lacuna entre os dois mundos e trazer sucesso para qualquer iniciativa de grande volume de dados em sua empresa.

Relacionado:

• Adeus Big Data. Olá, Massive Data!
• O guia definitivo para o retreinamento de modelos
• O risco oculto da IA ​​e Big Data