Inteligência de Varejo em Tempo Real: Criando Recomendações de E-Commerce com Lakebase e AI Search no Databricks

A oportunidade: Personalização como motor de receita

Cada segundo que um comprador passa em um aplicativo de e-commerce de moda gera um fluxo de sinais de intenção — buscas, visualizações de produtos, adições à lista de desejos, interações com o carrinho. As plataformas que convertem esses sinais em recomendações de produtos relevantes em tempo real são as que vencem. Referências do setor mostram que uma personalização eficaz pode aumentar as taxas de conversão em 10–30% e elevar significativamente o valor médio do pedido.

No entanto, criar um sistema de recomendação em nível de produção continua sendo um dos desafios mais difíceis de engenharia de ML. Isso exige ingestão de dados em tempo real, engenharia de features complexa, múltiplos modelos de ML trabalhando em conjunto e uma infraestrutura de serving que responda em milissegundos — tudo isso mantendo o inventário, a localização e as regras de negócios sincronizados.

Este blog apresenta uma arquitetura de referência completa para criar um sistema como esse no Databricks, com base em uma implementação real para uma grande plataforma de e-commerce de moda na Ásia que atende a mais de 1 milhão de usuários ativos mensais em um catálogo de mais de 100.000 SKUs.

Visão geral do sistema: A arquitetura em resumo

A arquitetura segue uma abordagem de plataforma unificada onde cada componente — da ingestão ao serving — roda no Databricks, governado pelo Unity Catalog.

Arquitetura geral do sistema:

Ingestão de dados: Do clickstream ao lakehouse em segundos

A plataforma ingere aproximadamente 1.000 eventos por segundo — visualizações de produtos, buscas, ações de adicionar ao carrinho, compras e metadados de sessão. Lakeflow Connect’s Zerobus Ingest fornece a espinha dorsal de ingestão, gravando eventos diretamente em tabelas Delta do Unity Catalog sem a necessidade de um message broker autogerenciado.

Uma distinção arquitetural importante: os dados de clickstream fluem pelo Zerobus para o lakehouse para computação de features offline e treinamento de modelo, mas durante a inferência em tempo real (Caminho B), os sinais do usuário na sessão — o que o comprador está navegando neste exato momento — são enviados diretamente como parte do payload da requisição da API para o endpoint de Model Serving. Isso ignora completamente o armazenamento do lakehouse durante o caminho de inferência, garantindo que o contexto em tempo real esteja disponível sem sofrer com latência de ingestão.

O Zerobus aceita dados de qualquer cliente produtor padrão do Kafka (Java, Python, Go) por meio de uma alteração simples de configuração — aponte o servidor de bootstrap para o endpoint do Zerobus, e os registros serão gravados na tabela Delta de destino. Para equipes que já executam infraestrutura do Kafka, o Structured Streaming com Declarative Pipelines oferece um caminho alternativo com a mesma arquitetura downstream.

Os dados fluem para uma arquitetura medalhão:

Camada Bronze — Fluxos de eventos brutos do tipo append-only e dados de referência:

• Sinais do usuário:
  • Comportamentais: sequências de navegação, consultas de busca, padrões de tempo de permanência, histórico de cliques
  • Transacionais: frequência de compra, valor médio do pedido, taxa de devolução, distribuição de gastos por categoria
  • Preferências: itens na lista de desejos, buscas salvas, afinidade com marcas, preferências de tamanho
  • Demográficos: faixa etária, cluster de localização, tipo de dispositivo, nível de engajamento no aplicativo
• Sinais do item:
  • Catálogo: hierarquia de categorias, marca, faixa de preço, material, colares, sazonalidade
  • Desempenho: taxa de conversão, proporção de visualização para carrinho, taxa de devolução, avaliação média
  • Visuais: embeddings de imagem (capturando semelhança de estilo além dos atributos de texto)
  • Novidade: dias desde a listagem, velocidade de tendências, trajetória de estoque
• Sinais de contexto:
  • Temporais: hora do dia, dia da semana, proximidade do dia de pagamento, períodos de festivais/promoções
  • Geográficos: cidade do usuário, centro de distribuição mais próximo, preferências regionais de estilo
  • Ambientais: clima (influencia as preferências de categoria), eventos locais
  • Sessão: intenção de navegação atual (inferida a partir do comportamento na sessão)

Camada Silver — Limpa, organizada em sessões e enriquecida:

• Comportamento do usuário organizado em sessões (sequências de navegação, tempos de permanência, padrões de interação)
• Features de produtos limpas (atributos normalizados, hierarquias de categorias)
• Sinais de engajamento agregados (contagem de visualizações de 7 dias, pontuações de tendências, índices de popularidade)
• Matrizes de interação usuário-produto (sinais de feedback implícito)

Camada Gold — Tabelas de features prontas para o modelo e conjuntos de dados de treinamento:

• Vetores de features do usuário (embeddings comportamentais, perfis de preferência, clusters demográficos)
• Vetores de features do item (embeddings de produtos, codificações de atributos)
• Conjuntos de dados de treinamento (pares de interação rotulados para treinamento de modelo)
• Listas de recomendações pré-computadas (geradas em lote, armazenadas para busca rápida)

As features são atualizadas em cadências diferentes: as agregações comportamentais são atualizadas diariamente por meio de Databricks Workflows agendados, enquanto o catálogo completo de produtos é sincronizado semanalmente. Os embeddings de usuários e itens são recomputados diariamente para capturar a evolução das preferências e o novo inventário. O Databricks Feature Store gerencia tanto as features offline (para treinamento) quanto as features online (para serving), garantindo a consistência entre treinamento e serving — as mesmas definições de features usadas durante o treinamento do modelo ficam automaticamente disponíveis no momento da inferência por meio de tabelas online do Lakebase.

O Unity Catalog governa cada camada — fornecendo linhagem desde o evento bruto de clickstream até a previsão final entregue ao aplicativo, com controle de acesso refinado que garante a proteção de PII enquanto as features agregadas fluem livremente para o treinamento do modelo.

Serving em tempo real: Dois caminhos para respostas de baixa latência

A arquitetura de serving oferece dois caminhos complementares, cada um otimizado para diferentes padrões de interação. O Caminho A lida com as superfícies previsíveis e de alto volume, onde a pré-computação é viável e ideal. O Caminho B lida com as superfícies dinâmicas e sensíveis ao contexto da sessão, onde a intenção imediata do usuário deve moldar a resposta em tempo real.

Caminho A — Recomendações em lote pré-computadas (< 2 dígitos de ms)

O Caminho A atende à maioria das superfícies de recomendação — carrosséis da página inicial, classificações de páginas de categoria, campanhas de e-mail e notificações push. Essas superfícies compartilham uma característica comum: a identidade do usuário e o tipo de superfície são conhecidos com antecedência, de modo que os resultados podem ser computados previamente.

Um job em lote noturno, orquestrado pelo Databricks Workflows, executa o funil completo de 3 etapas offline para cada usuário ativo. Ele recupera os embeddings de usuário mais recentes, executa consultas ANN em lote no índice de itens do AI Search para gerar candidatos, atribui pontuações a eles com o modelo LightGBM usando features da camada Gold e aplica regras de negócios (pontuação de inventário, proximidade de entrega, diversidade, impulsionamento promocional). O resultado — uma lista de produtos classificados top-N por usuário (normalmente de 50 a 100 itens por superfície) — é gravado em tabelas online do Lakebase, indexadas por ID do usuário e tipo de superfície.

No momento do serving, o aplicativo realiza uma busca simples de chave-valor: user_id + surface → lista de produtos classificados. Sem inferência de modelo, sem busca vetorial, sem montagem de features — apenas uma leitura direta do Lakebase.

Como o job em lote é executado todas as noites, o Caminho A reflete os sinais e o estado do inventário do dia anterior. Para a maioria das superfícies, esse nível de atualização é mais do que suficiente — as preferências de longo prazo e as afinidades com marcas evoluem ao longo de dias, não de minutos — e novos produtos que receberam seus embeddings iniciais aparecerão nas recomendações em até 24 horas.

Caminho B — Pontuação em tempo real sensível à sessão (< 2 dígitos de ms)

O Caminho B é ativado quando o contexto de recomendação só existe no momento da solicitação — "Itens semelhantes" em uma página de detalhes do produto, sugestões de "Complete o visual" ou resultados de busca reordenados dinamicamente que se adaptam conforme o usuário navega.

O aplicativo de e-commerce envia sinais da sessão atual — itens visualizados nos últimos minutos, consultas de busca ativas, conteúdo do carrinho e padrões de tempo de permanência — diretamente como payload da solicitação para o endpoint de Model Serving via REST API. O endpoint executa o funil completo de 3 etapas de forma síncrona em um único ciclo de solicitação-resposta:

• Etapa 1 — Recuperação de candidatos em tempo real O endpoint transforma os sinais da sessão em um embedding de consulta — seja o embedding do item do produto que está sendo visualizado ou um embedding de usuário combinado que funde o perfil de preferência de longo prazo (do Lakebase) com o comportamento na sessão, dando mais peso aos sinais recentes. Esse embedding é enviado para o Databricks AI Search, que realiza uma recuperação híbrida: busca de similaridade ANN combinada com filtros rígidos de metadados (elegibilidade de categoria, inventário regional, limites mínimos de estoque). Itens fora de estoque ou inelegíveis nunca entram no conjunto de candidatos. O AI Search retorna de 200 a 500 candidatos em uma única viagem de ida e volta na rede. Para superfícies sensíveis à sessão, o endpoint calcula um embedding de consulta combinado — unindo o embedding de preferência de longo prazo pré-calculado do usuário (recuperado do Lakebase) com um embedding de sessão derivado de itens visualizados recentemente, ponderado para sinais recentes para capturar a intenção imediata. Essa combinação é uma computação leve realizada dentro do endpoint, não uma chamada de modelo separada
• Etapa 2 — Montagem de recursos e pontuação Os IDs dos itens candidatos disparam buscas pontuais (point lookups) nas tabelas online do Lakebase, recuperando features pré-calculadas do usuário (agregados comportamentais, segmento demográfico, sensibilidade ao preço) e features do item (taxa de conversão, pontuação de tendência, dias desde a listagem). As features de contexto em tempo real (hora do dia, dispositivo, localização, promoções ativas) são derivadas diretamente do payload da solicitação. O endpoint constrói vetores de features para cada par usuário-candidato — incluindo features cruzadas (cross features), como afinidade usuário-categoria e sobreposição de preferência de marca — e os passa para o modelo de pontuação LightGBM, que prevê a probabilidade de conversão em uma única chamada de inferência em lote sem recursos de GPU.
• Etapa 3 — Regras de negócios e reordenamento A lista pontuada passa por uma camada de reordenamento (re-ranking) determinística: a pontuação sensível ao inventário reduz a prioridade de estoques em baixa, a pontuação de proximidade de entrega favorece armazéns mais próximos para um atendimento mais rápido, a injeção de diversidade evita a dominância de marcas ou categorias na lista final e o impulsionamento promocional destaca itens alinhados com campanhas ativas. A lista reordenada é truncada para o tamanho solicitado (normalmente de 10 a 20 itens) e retornada como resposta da API.

As regras de negócios são baseadas em configuração — pesos promocionais, limites de diversidade e pontos de corte de inventário são lidos de uma tabela de configuração gerenciada no momento da disponibilização (serving time), permitindo que as equipes comerciais ajustem as regras sem implantar o modelo novamente.

O endpoint é implementado como um MLflow PyFunc model personalizado que orquestra o pipeline de várias etapas internamente — consultando o AI Search, realizando buscas no Lakebase, executando a inferência do LightGBM e aplicando regras de negócios em uma única chamada predict().

Uma estratégia de fallback garante a resiliência: se o caminho em tempo real exceder seu limite de latência, o sistema se adapta de forma suave para fornecer itens populares armazenados em cache ou as recomendações pré-calculadas do usuário do Caminho A.

Como lidar com o problema de início do zero (cold start)

Todo sistema de recomendação deve lidar com dois cenários de início do zero (cold start):

Novos usuários (sem histórico de navegação): Quando um usuário acessa pela primeira vez, o sistema constrói um embedding de usuário padrão a partir dos sinais demográficos disponíveis — localização, tipo de dispositivo, contexto de cadastro e quaisquer preferências declaradas. Esse embedding é usado para a busca ANN no índice de itens, posicionando efetivamente o novo usuário dentro de um cluster comportamental de dados demográficos semelhantes. Conforme o usuário interage, seu embedding converge rapidamente para suas preferências reais.

Novos produtos (sem dados de interação): Quando um novo SKU entra no catálogo, o sistema gera um embedding de item a partir de seus atributos — título, categoria, marca, faixa de preço e recursos visuais extraídos de imagens do produto. Esse embedding é usado para encontrar itens existentes semelhantes no espaço vetorial, e o novo produto herda as pontuações de recomendação iniciais de seus vizinhos mais próximos. Os novos produtos aparecem nas recomendações no próximo ciclo diário de lote.

Ciclo de vida do modelo e melhoria contínua

Os modelos são treinados novamente toda semana usando o Databricks Workflows, com rastreamento de experimentos e controle de versão gerenciados pelo MLflow. A plataforma suporta a implantação do tipo campeão/desafiante (champion/challenger) — novas versões do modelo são implantadas junto com o modelo de produção, com o tráfego sendo transferido gradualmente com base em métricas de desempenho online.

As principais métricas de ML monitoradas incluem:

• AUC-ROC — mede a capacidade do modelo de pontuação de distinguir entre itens com os quais um usuário irá ou não interagir
• NDCG@K (Normalized Discounted Cumulative Gain) — avalia se os itens mais relevantes aparecem no topo da lista ordenada
• Recall@K — mede qual fração de itens relevantes a etapa de geração de candidatos consegue recuperar com sucesso
• Log Loss — acompanha a calibração da previsão, garantindo que as pontuações de probabilidade de conversão permaneçam bem calibradas ao longo do tempo

Essas métricas do modelo são complementadas por KPIs de negócios — taxa de cliques (click-through rate), taxa de conversão e receita por sessão — que servem como a validação definitiva de que as melhorias do modelo se traduzem em impacto no mundo real.

A detecção automatizada de desvio (drift) sinaliza quando as distribuições de features ou as distribuições de pontuação de previsão se desviam das referências (baselines), acionando uma investigação ou um treinamento acelerado. Os logs de disponibilização (serving logs) são correlacionados de volta aos pipelines de treinamento por meio de identificadores no nível da solicitação, garantindo que o ciclo de feedback produza dados de treinamento limpos e sem vazamento (leakage) para a próxima iteração do modelo. Técnicas de treinamento sensíveis à posição garantem que o modelo aprenda a preferência real do usuário, em vez de artefatos de posição de exibição.

Resultados esperados

Esta arquitetura permite:

• respostas personalizadas na faixa de poucos milissegundos (baixo duplo dígito de ms) em escala, atendendo às expectativas de desempenho dos compradores modernos que priorizam o celular (mobile-first)
• Recomendações atualizadas diariamente que refletem o inventário mais recente, produtos em tendência e a evolução das preferências dos usuários
• Governança unificada desde o clickstream bruto até as previsões em produção, com linhagem completa e controle de acesso via Unity Catalog
• Experimentação rápida — novas variantes de modelo podem ser treinadas, avaliadas e implantadas em questão de dias, em vez de meses
• Simplicidade operacional — uma única plataforma substitui a colcha de retalhos de sistemas separados para ingestão, engenharia de features, treinamento e disponibilização (serving)
• Escalabilidade suave — de milhares a milhões de usuários sem a necessidade de reestruturar a arquitetura, aproveitando a computação sem servidor (serverless) e a infraestrutura gerenciada

Conclusão

A criação de um mecanismo de recomendação e classificação de nível de produção não exige mais a união de uma dúzia de sistemas especializados. Ao unificar a ingestão em tempo real (Zerobus), o gerenciamento de features (Feature Store + Lakebase), o treinamento de modelos (MLflow + Workflows), a recuperação de vetores (AI Search) e a disponibilização de baixa latência (Model Serving) em uma única plataforma governada, as equipes de e-commerce podem se concentrar no que realmente importa: entender seus clientes e entregar o produto certo no momento certo.

O resultado não é apenas um mecanismo de recomendação — é uma plataforma de personalização completa e pronta para produção que pode servir como a espinha dorsal inteligente de qualquer experiência de e-commerce.

Pronto para criar o seu próprio? Explore os Aceleradores de Solução de Mecanismo de Recomendação da Databricks, mergulhe na documentação do AI Search ou entre em contato com a equipe de conta da Databricks para um workshop de arquitetura.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original