DoorDash, Instacart e Uber Eats reconstroem busca com LLMs

O problema

Busca por comida em apps de delivery quebra a busca por palavras-chave de múltiplas formas simultâneas: consultas subjetivas ("algo saudável para uma noite chuvosa"), sinônimos, erros de digitação, abreviações, mistura de idiomas e restrições compostas ("sanduíche de frango vegano" exige que "vegano" seja um filtro rígido, não apenas um sinal de similaridade). DoorDash, Instacart e Uber Eats reconstruíram seus sistemas de busca com LLMs na mesma janela de tempo, com base de pesquisa semelhante, mas chegaram a arquiteturas bastante distintas.

DoorDash: LLM na periferia do runtime

A empresa já possuía um grafo de conhecimento com atributos estruturados (tipo de prato, preferência dietética, cuisine, sabor). A estratégia foi usar LLMs offline para enriquecer esse grafo extraindo atributos de dados de SKU, e no runtime apenas para segmentar consultas em chunks que mapeiam de volta ao grafo. A recuperação em si permanece keyword e graph-driven.

Um detalhe importante: usam RAG como guardrail, não como gerador. Para cada segmento da consulta, uma busca por vizinhos mais próximos recupera os 100 conceitos taxonômicos mais próximos do grafo, e o LLM é instruído a escolher dessa lista - nunca a inventar labels. Resultado: ~30% de aumento na taxa de disparo de carrosséis de pratos populares.

Instacart: LLM na camada de entendimento da consulta

O sistema anterior era fragmentado: FastText para classificação, motor separado para reescrita, modelos individuais para correção ortográfica, tagging e classificação de corredor. A manutenção era pesada e consultas raras (long tail) sofriam.

A solução é em camadas: (1) context engineering com RAG puxando dados específicos da Instacart para o prompt; (2) guardrails de pós-processamento com filtros de similaridade semântica; (3) fine-tuning de Llama-3-8B em dados proprietários. 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, GPUs H100 e autoscaling). Cobertura de reescrita de consultas saltou de 50% para 95%+, com precisão acima de 90%.

Uber Eats: LLM como backbone de embedding

A complicação extra: múltiplos verticais (restaurantes, grocery, retail), múltiplos mercados e idiomas. A arquitetura é two-tower clássica, mas ambas as torres usam um Qwen fine-tuned como backbone de embedding. A torre de query roda online; a de documentos roda offline, pré-embedando bilhões de documentos em índice HNSW.

Otimizações que viabilizam a escala: Matryoshka Representation Learning (embeddings truncáveis para 256 dimensões com <0,3% de perda de recall), quantização escalar int7 (latência pela metade), e pré-filtros por hexágono, cidade e tipo de fulfillment. Juntas, essas escolhas reduzem latência em 34%, CPU em 17% e storage em ~50%.

O padrão

A posição de cada empresa no espectro "profundidade do LLM no runtime" foi determinada pela infraestrutura que já existia: DoorDash tinha grafo de conhecimento, então o ganho mais barato era enriquecê-lo; Instacart tinha modelos especializados difíceis de manter, então consolidou sob LLM; Uber Eats já tinha infraestrutura two-tower por vertical, então trocou o backbone por um LLM fine-tuned unificado.

Três tradeoffs universais sobreviveram em todas as arquiteturas: sistemas híbridos são o padrão (recuperação clássica ainda faz a maior parte do trabalho); 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.