Onde o resultado é alimentado como a semente de um glorioso LSTM empilhado bidirecional com uma pitada de atenção.
Após o treinamento, você obtém uma precisão de 99,99% e está pronto para enviá-lo à produção.
Mas então você percebe que as restrições de produção não permitirão que você faça inferência usando esta fera. Você precisa que a inferência seja feita em menos de 200 milissegundos.
Em outras palavras, você precisa cortar metade das camadas, desistir de usar convoluções e não vamos começar sobre o caro LSTM…
Se você pudesse tornar esse modelo incrível mais rápido!
Às vezes você pode
Aqui no Avance Network nós fizemos. Bem, não exatamente ... Deixe-me explicar.
Um de nossos modelos precisa prever a CTR (Taxa de cliques) de um item, ou seja, a probabilidade de o usuário gostar de uma recomendação de artigo e clicar nela.
O modelo tem várias modalidades como entrada, cada uma passa por uma transformação diferente. Alguns deles são:
- características categóricas: estas são incorporadas a uma representação densa
- image: os pixels são passados por camadas convolucionais e totalmente conectadas
- texto: após ser tokenizado, o texto é passado por um LSTM que é seguido por atenção própria
Essas modalidades processadas são então passadas por camadas totalmente conectadas para aprender as interações entre as modalidades e, finalmente, são passadas por uma camada MDN .
Como você pode imaginar, este modelo é lento.
Decidimos insistir no poder preditivo do modelo, em vez de aparar componentes, e criamos uma solução de engenharia.
Coloque-me em cache se puder
Vamos nos concentrar no componente da imagem. A saída deste componente é uma representação aprendida da imagem. Em outras palavras, dada uma imagem, o componente de imagem gera uma incorporação.
O modelo é determinístico, portanto, dada a mesma imagem, resultará na mesma incorporação. Isso é caro, para que possamos armazená-lo em cache. Deixe-me elaborar como implementamos.
A arquitetura (do cache, não do modelo)
- Utilizamos um banco de dados Cassandra como cache, que mapeia o URL de uma imagem para sua incorporação.
- O serviço que consulta Cassandra é chamado EmbArk (Embedding Archive, incorreto , é claro ). É um servidor gRPC que obtém uma URL de imagem de um cliente e recupera a incorporação do Cassandra. Na falta de cache, o EmbArk envia uma solicitação assíncrona para incorporar essa imagem. Por que assíncrono? Porque precisamos que o EmbArk responda com o resultado o mais rápido possível. Como não pode esperar a imagem ser incorporada, ele retorna uma incorporação especial de OOV (Fora do Vocabulário).
- O mecanismo assíncrono que escolhemos usar é o Kafka - uma plataforma de streaming usada como fila de mensagens.
- O próximo link é o KFC (Kafka Frontend Client) - um consumidor Kafka que implementamos para passar mensagens de forma síncrona para o serviço de incorporação e salvar as incorporações resultantes no Cassandra.
- O serviço de incorporação é chamado Retina. Ele obtém um URL de imagem do KFC, faz o download, o pré-processa e avalia as camadas convolucionais para obter a incorporação final.
- O balanceamento de carga de todos os componentes é feito usando o Linkerd .
- EmbArk, KFC, Retina e Linkerd são executados no Docker e são orquestrados pelo Nomad . Isso nos permite escalar facilmente cada componente como acharmos melhor.
Essa arquitetura foi usada inicialmente para imagens. Depois de provar seu valor, decidimos usá-lo também para outros componentes, como texto.
O EmbArk também se mostrou uma boa solução para transferência de aprendizado . Digamos que acreditamos que o conteúdo da imagem tenha um bom sinal para prever a CTR. Assim, um modelo treinado para classificar o objeto em uma imagem como Inception seria valioso para nossas necessidades. Podemos carregar o Inception no Retina, dizer ao modelo que pretendemos treinar que queremos usar a incorporação do Inception, e é isso.
Não apenas que o tempo de inferência foi aprimorado, mas também o processo de treinamento. Isso é possível apenas quando não queremos treinar de ponta a ponta, pois os gradientes não podem retropropagar pelo EmbArk.
Portanto, sempre que você usa um modelo em produção, deve usar o EmbArk, certo? Bem, nem sempre ...
Ressalvas
Existem três suposições bastante estritas aqui.
1. Incorporar OOV para novos insumos não é grande coisa
Não nos magoa que, pela primeira vez que vemos uma imagem, não teremos sua incorporação.
No nosso sistema de produção, tudo bem, pois a CTR é avaliada várias vezes para o mesmo item durante um curto período de tempo. Criamos listas de itens que desejamos recomendar a cada poucos minutos; portanto, mesmo que um item não consiga entrar na lista por causa de uma previsão de CTR não ideal, ele será incluído no próximo ciclo.
2. A taxa de novos insumos é baixa
É verdade que em Taboola temos muitos itens novos o tempo todo. Mas, em relação ao número de inferências que precisamos realizar para itens já conhecidos, não são muito.
3. Os casamentos não mudam frequentemente
Como os casamentos são armazenados em cache, contamos com o fato de que eles não mudam com o tempo. Se o fizerem, precisaremos executar a invalidação do cache e recalcular as incorporações usando o Retina. Se isso acontecesse muito, perderíamos a vantagem da arquitetura. Para casos como modelagem inicial ou de linguagem, essa suposição é válida, pois a semântica não muda significativamente ao longo do tempo.
Algumas considerações finais
Às vezes, o uso de modelos de última geração pode ser problemático devido às suas demandas computacionais. Ao armazenar em cache os resultados intermediários (incorporação), fomos capazes de superar esse desafio e ainda obter resultados de última geração.
Essa solução não é adequada para todos, mas se as três premissas mencionadas forem válidas para seu aplicativo, você pode considerar o uso de uma arquitetura semelhante.
Usando um paradigma de microsserviços, outras equipes da empresa puderam usar o EmbArk para outras necessidades que não a previsão de CTR. Uma equipe, por exemplo, usou o EmbArk para obter incorporações de imagem e texto para detectar duplicatas em itens diferentes. Mas vou deixar essa história para outro post ...
