DoorDash, Instacart e Uber Eats integram LLMs em busca de formas distintas

O problema

Buscar "algo saudável para uma noite chuvosa" em um app de delivery há cinco anos retornava resultados aleatórios, porque a busca por palavras-chave trata os termos como tokens isolados, não como intenção. Os modos de falha incluem sinônimos ("soda" vs. "refrigerante"), erros de digitação, abreviações ("gf pizza" = pizza sem glúten), ambiguidade entre idiomas ("pan" é pão em espanhol e panela em inglês) e a cauda longa de queries raras que modelos especializados não conseguem cobrir.

DoorDash: LLM offline, runtime clássico

A DoorDash já possuía um grafo de conhecimento com atributos estruturados (tipo de prato, preferência dietética, culinária, sabor). A estratégia foi usar LLMs para enriquecer esse grafo offline e, em runtime, apenas segmentar queries em chunks que mapeiam para campos do grafo. A recuperação em si continua keyword e graph-driven.

O diferencial é o uso de RAG como guardrail: para cada segmento da query, uma busca por vizinhos mais próximos retorna os 100 conceitos mais próximos da taxonomia existente, e o LLM é forçado a escolher dessa lista - nunca inventa labels. Resultado: ~30% de aumento na taxa de disparo de carrosséis de pratos populares.

Instacart: LLM na camada de entendimento da query

O sistema anterior da Instacart era fragmentado: FastText para classificação, engine separada para rewrites, modelos independentes para correção ortográfica e tagging. A manutenção era pesada e queries raras sofriam.

A solução tem três camadas: (1) context engineering com RAG puxando dados de conversão e catálogo para o prompt; (2) filtros de similaridade semântica como pós-processamento; (3) fine-tuning de Llama-3-8B em dados proprietários para as tarefas mais avançadas.

A arquitetura divide head queries (pipeline offline com RAG e cache) de tail queries (modelo fine-tuned em tempo real, latência < 300ms com adapter merging e GPUs H100). Cobertura de query rewrite subiu de 50% para 95%+, com precisão acima de 90%. Para os 2% piores queries (cauda fria), scroll depth caiu 6% e reclamações caíram pela metade.

Uber Eats: LLM como backbone de embedding

A Uber Eats opera em múltiplos verticais (restaurantes, grocery, retail), mercados e idiomas. O setup anterior tinha modelos BERT separados por vertical. A solução foi uma arquitetura two-tower com Qwen fine-tuned como backbone de embedding em ambas as torres: a query tower roda online, a document tower pré-embeda bilhões de documentos offline em índice HNSW.

Otimizações de escala incluem Matryoshka Representation Learning (256 dims em produção com < 0,3% de perda de recall vs. 1.536 dims), quantização escalar int7 (latência pela metade) e pré-filtros por hexágono/cidade/tipo de fulfillment. Juntas, essas escolhas tornam viável usar um LLM fine-tuned como substrato de recuperação em produção.

Padrão geral

Posicionando as três em um eixo de "profundidade do LLM no runtime": DoorDash à esquerda (LLM offline, runtime clássico), Instacart no meio (LLM no entendimento da query, recuperação downstream tradicional), Uber Eats à direita (LLM como modelo de embedding de cada query e documento).

A posição de cada uma foi determinada pela infraestrutura pré-existente, não pela escolha do modelo. Três tradeoffs universais sobreviveram: sistemas híbridos são o padrão; conhecimento de mundo do modelo pré-treinado é apenas um ponto de partida (contexto de domínio precisa ser injetado via RAG, fine-tuning ou ambos); e guardrails são parte essencial de todo sistema LLM em produção.