Uber Eats Reduz Staleness de Features de 24 Horas para Segundos Com Ranking Listwise

Uber Eats substituiu seu ranker DeepCVR pointwise por um modelo generativo listwise que marca uma lista inteira de candidatos em um forward pass único. Também reduziu feature staleness de 24 horas para segundos. Staff ML Engineer Yicheng Chen e colegas detalharam as mudanças no blog de engenharia da Uber.

A arquitetura anterior marcava um comerciante por chamada de inferência. O novo modelo Generative Recommender ingere um array de lojas candidatas e produz scores ranqueados para todas em um pass único. Isso reduz o compute por loja para aproximadamente 1/T do original, onde T é o número de lojas alvo. Em tamanhos típicos de candidate set, essa é uma redução de uma ordem de magnitude na carga de inferência do ranker.

O modelo é um híbrido dual-path. Um path DCNv2 trata features esparsas de alta dimensionalidade e estatísticas densas de comerciante. Um segundo path executa um transformer-based sequence encoder sobre um log cronológico de ações do usuário usando multi-head self-attention. Os dois paths convergem antes do scoring final, com a store alvo anexada à sequência do usuário para que o transformer modele a relação entre comportamento passado e o candidato específico.

A camada de feature em tempo real roda em uma plataforma interna chamada Next Personalization Platform. FeatureExtractors — funções Java puras — são invocadas por um serviço de Feature Store online. Os mesmos FeatureExtractors são replay offline via Apache Spark para gerar dados de treinamento, impondo online-offline parity. A atualização de features melhorou de lag em batch de 24 horas para alguns segundos.

Usuários cold-start viram os maiores ganhos. Vetores de features anteriores eram esparsos ou obsoletos; atualização subsecond significa que um click único na sessão atual reformata o ranking antes do carregamento da página. O time executa monitoramento contínuo via sampled feature logging para detectar drift antes de degradar a qualidade do modelo.

Uber não divulgou latências p50/p99 para o transformer encoder em serving, tamanho da frota GPU, números de A/B test lift (pedidos por usuário, click-through rate, GMV), ou comparação de custo-por-inferência entre modelos antigos e novos. O argumento de eficiência listwise é matematicamente sólido mas números de produção empíricos validariam em outras escalas.

Adicionar um transformer sequence encoder ao serving hot path introduz latência variável vinculada ao sequence length. Complexidade de attention escala quadraticamente com sequence length a menos que masked ou truncated. Uber não descreve o sequence length cap, estratégia de masking, ou tratamento de usuários com históricos muito longos sem estourar orçamentos de latência.

O padrão mais portável aqui: o modelo de parity do FeatureExtractor — uma função Java chamada identicamente em Feature Store online e replay Spark offline. Se seu time mantém lógica de feature separada para treinamento e serving, é aí que vaza qualidade do modelo.