iFood: plataforma de recomendação e inferência

01 · CONTEXTO E PROBLEMA

Recomendar na home de um app de delivery

O iFood recebe milhares de acessos simultâneos e, a cada acesso, o aplicativo carrega dezenas de conteúdos, entre restaurantes, pratos, mercados e produtos, para orientar a escolha de quem pede. Os sistemas de recomendação que atendem esse ambiente em tempo real precisam suportar uma carga elevada com alta disponibilidade e resiliência.

O custo é o problema central. Segundo o time, mesmo um modelo simples, como uma fatoração de matriz, pode exigir um grande número de máquinas para servir recomendações em tempo real. Além disso, os clientes mudam de preferência conforme o contexto, como localização e hora do dia, e isso exige esforço extra por modelo e serviço, aumentando o custo. A pergunta do time é como escalar dezenas de modelos diferentes e combiná-los com o contexto do cliente.

A resposta do iFood é pré-indexar as predições de múltiplos modelos, o que permite combiná-las com outras fontes de informação em tempo real.

02 · INGESTÃO

Do candidato à predição guardada

A plataforma é uma arquitetura de microsserviços separados em dois domínios, Ingestão e Servidor. Começamos pela Ingestão, que produz as predições antes de qualquer acesso do cliente.

1. O pipeline de geração de candidatos filtra o que é relevante e deixa os candidatos em arquivos no S3.

2. Os candidatos são processados por múltiplos modelos no SageMaker, que usa Batch Transform para escalar as predições.

3. A saída das predições é escrita em múltiplos arquivos no S3.

4. A criação dos arquivos dispara a função Lambda Feature Publisher, que lê as predições.

5. O Feature Publisher publica as predições em um tópico Kafka.

6. O Feature Consumer consome o tópico e insere as predições no Personalization Store.

Um fluxo prévio de geração de candidatos filtra as entidades relevantes para cada contexto. O mesmo pipeline seleciona os clientes que devem ser atualizados diariamente e um conjunto reduzido de restaurantes para cada um.

Cada modelo tem treino e predição automatizados de forma independente com o SageMaker Pipelines, e o Batch Transform escala as predições. As mensagens passam por um tópico Kafka, uma fila de mensagens que desacopla quem gera as predições de quem as grava.

O consumidor em Go lê dezenas de milhões de mensagens do tópico e grava no Personalization Store, um banco NoSQL que mantém cerca de dezena de bilhões de predições.

03 · SERVIDOR

Ler o que já está pronto e reordenar na hora

O Personalization Store usa um esquema bem particionado para garantir escalabilidade na leitura. É essa leitura que o servidor faz a cada sessão do aplicativo.

1. O servidor recebe todas as chamadas do aplicativo.

2. Para cada usuário, o servidor recupera as predições dos vários modelos guardadas no Personalization Store.

3. A resposta é enriquecida com as predições pré-calculadas e passa por modelos de ordenação aplicados na hora.

4. A arquitetura permite combinar as predições com outras fontes de informação em tempo real.

04 · PLATAFORMA DE ML

Como os modelos chegam à produção

Outro post da AWS, cujo título fala em centenas de modelos, descreve o outro lado do problema. Antes, cientistas de dados criavam modelos em notebooks e os publicavam em serviços, e as equipes de engenharia tinham dificuldade para integrá-los aos sistemas de produção. Para superar isso, o iFood construiu uma plataforma interna de ML.

Nessa plataforma, a ML Go! é responsável por implantar pipelines e endpoints do SageMaker. Veja o caminho do código até a predição.

1. O fluxo começa com o pipeline de CI/CD da ML Go! enviando os artefatos de código de treino e implantação.

2. Cada modelo disponível para implantação é registrado automaticamente no Model Registry, com versionamento e rastreio.

3. Em casos de predição em lote, o pipeline cria um job de batch transform.

4. Em inferência em tempo real, o pipeline implanta o modelo em um endpoint.

5. O Gateway é uma abstração única para conectar com endpoints e jobs do SageMaker.

Na arquitetura mais recente, a separação de responsabilidades dentro dos endpoints, com o recurso Inference Components, torna a veiculação mais rápida e eficiente.

05 · RESULTADOS E TRADE-OFFS

O que o iFood reporta e o que perguntar

O iFood reporta 6x mais escalabilidade, de 500 para mais de 3000 requisições por segundo. Reporta também economia de cerca de 50% nos custos para servir conteúdos na home, já que a maior parte da informação está pré-indexada, e melhoria de cerca de 10% na conversão das listas.