Why DoorDash, Instacart, and Uber Eats Integrated LLMs Into Search Three Different Ways

Three food delivery giants tackled the exact same problem around the exact same time, using roughly the same research playbook, and walked away with three architectures that barely resemble each other. That's the interesting part of this story — not that LLMs improved search, but that "add an LLM" turned out to mean wildly different things depending on what you already had running in production.

DoorDash kept it conservative. They already had a knowledge graph mapping dish types, dietary flags, cuisines, and flavors, so they used LLMs to enrich that graph offline and to chop up queries into chunks at runtime — "small," "no-milk," "vanilla ice cream" — each chunk then getting matched against a shortlist of maybe 100 existing taxonomy concepts pulled via nearest-neighbor search. The LLM never invents a label; it picks from a pre-approved menu. That constraint is clever precisely because it flips typical RAG usage: instead of injecting context into a generator, DoorDash uses retrieval to define the entire output space. Result: a 30% lift in carousel trigger rates, with the runtime itself staying almost entirely classical.

Instacart went the opposite direction and consolidated a mess. Before this, they were running a FastText classifier, a separate rewrite engine, and standalone models for spell-check, tagging, and aisle classification — each with its own pipeline, each starving on rare queries. Their fix layers three techniques: RAG for context, similarity filters as guardrails, and a fine-tuned Llama-3-8B for anything genuinely hard. The system splits by query frequency — common searches get served from an offline cached pipeline, while the long tail hits the fine-tuned model live, under 300ms, thanks to H100s and adapter merging. Query rewrite coverage jumped from 50% to over 95%, and complaints about bad tail-query results got cut in half. Telling detail: when they first tried an off-the-shelf model on the query "protein," it returned chicken and beef. Instacart's actual shoppers meant protein powder. General world knowledge doesn't automatically know your users.

Uber Eats had the hardest problem — multiple verticals, multiple markets, dozens of languages — and threw out the most infrastructure to solve it. They replaced a patchwork of per-vertical BERT embeddings with a single two-tower system where both towers run on a fine-tuned Qwen model. Queries get embedded live; documents get pre-embedded offline into a billion-scale HNSW index, because running a full LLM on every document at query time just isn't affordable. To make that economical, they lean on Matryoshka Representation Learning to serve 256-dimension embeddings instead of 1,536 with under 0.3% recall loss, plus int7 quantization and geographic pre-filtering. Tuning one ANN parameter alone cut latency by 34%.

Line the three up and a pattern falls out immediately. DoorDash's LLM sits mostly offline, on the edges. Instacart's sits in the middle, doing query understanding while retrieval stays classical. Uber Eats put the LLM at the center as the literal embedding engine for everything. None of that was really a model choice — it was determined by whatever infrastructure each company had already sunk years into. DoorDash had a graph worth feeding. Instacart had five brittle models worth merging. Uber Eats had two-tower retrieval worth upgrading. The real design question was never which LLM to use — it was where in the stack an LLM actually earns its keep.