DoorDash, Instacart e Uber Eats integramam LLMs em busca de três jeitos

O problema

Busca em apps de delivery de comida falha de formas específicas: sinônimos ("soda" vs. "soft drink"), erros de digitação, abreviações ("gf pizza" para gluten-free), ambiguidade entre idiomas ("pan" é pão em espanhol, mas panela em inglês) e consultas subjetivas como "algo saudável para uma noite chuvosa". Além disso, há o problema da cauda longa (consultas raras com poucos dados de treino) e o problema de restrições rígidas ("sanduíche de frango vegano" exige que o sistema entenda o "vegano" como filtro obrigatório, não apenas como preferência de ranking).

DoorDash: LLM offline, runtime clássico

DoorDash já possuía um grafo de conhecimento estruturado com atributos de itens (tipo de prato, dieta, culinária, marca, sabor). A estratégia foi usar LLMs offline para enriquecer esse grafo extraindo atributos de dados de SKU, e em runtime apenas para parsear a consulta em chunks que se conectam ao grafo.

Para a consulta "small no-milk vanilla ice cream", o LLM segmenta em três chunks: "small" (quantidade), "no-milk" (mapeado para o rótulo canônico "dairy-free") e "vanilla ice cream" (tipo de prato + sabor). Cada chunk vira um filtro ou preferência de ranking no grafo.

O diferencial é o uso de RAG como guardrail: para cada segmento, uma busca por vizinhos mais próximos recupera os 100 conceitos mais próximos da taxonomia existente, e o LLM é instruído a escolher apenas dessa lista - nunca inventar rótulos. Resultado: ~30% de aumento na taxa de disparo dos carrosséis de pratos populares.

Instacart: LLM na camada de entendimento da consulta

Instacart tinha múltiplos modelos especializados (FastText para classificação, engine de rewrites, correção ortográfica, tagging de consultas), cada um com pipeline próprio. A estratégia foi consolidar tudo sob LLMs com três camadas:

Context engineering: RAG injeta contexto específico do Instacart (categorias com maior conversão, histórico, detalhes do catálogo) no prompt.
Guardrails de pós-processamento: filtros de similaridade semântica descartam outputs que se afastam da consulta original.
Fine-tuning: Llama-3-8B fine-tunado com dados proprietários para tarefas mais avançadas.

A arquitetura separa consultas de cabeça (cache offline com RAG) de cauda longa (modelo fine-tunado em tempo real, latência < 300ms com GPUs H100 e adapter merging). Resultados: cobertura de rewrites subiu de 50% para 95%+, precisão acima de 90%, e redução de 6% na profundidade de scroll para consultas da cauda longa.

Uber Eats: LLM como backbone de embeddings

Uber Eats opera em múltiplos verticais (restaurantes, grocery, varejo), mercados e idiomas. A solução foi uma arquitetura two-tower onde ambas as torres usam um Qwen fine-tunado como backbone de embeddings. A torre de documentos roda offline (pré-embeddings de bilhões de documentos em índice HNSW), e a torre de consultas roda online em tempo real.

Otimizações críticas: Matryoshka Representation Learning (embeddings truncáveis para 256 dimensões com <0,3% de perda de recall), quantização escalar int7 (latência reduzida pela metade), e pré-filtros por região e tipo de fulfillment. Juntas, essas escolhas tornam viável usar um LLM fine-tunado como substrato de retrieval em escala.

O padrão

A posição de cada empresa no espectro de profundidade de integração foi determinada pela infraestrutura existente, não pela escolha do modelo. DoorDash tinha grafo de conhecimento → LLM enriquece o grafo. Instacart tinha modelos fragmentados → LLM consolida. Uber Eats já tinha two-tower por vertical → LLM vira backbone compartilhado.

Três tradeoffs universais: sistemas híbridos são o padrão (retrieval clássico ainda faz a maior parte do trabalho); conhecimento de mundo do modelo pré-treinado é só um ponto de partida (contexto de domínio precisa ser injetado via RAG ou fine-tuning); e guardrails são parte essencial de todo sistema LLM em produção.