DoorDash’s DSG Paper Makes Search Grounding a Control Plane, Not a Model Checkbox

“The model has search” is a seductive product checkbox and a lousy production architecture. It is fine for demos. It is less fine when you need to know which provider was queried, how many results came back, whether the answer was cached, why latency spiked, whether the output still obeys your schema, and why your bill just developed a personality. DoorDash’s Decoupled Search Grounding paper is valuable because it makes search grounding a control plane instead of a magic feature hidden inside the model call.

The paper’s core argument is not that native search is bad. In fact, native search wins on some freshness-sensitive tasks. The argument is that native search is a bundle: provider choice, retrieval depth, cost, caching, fallback, context formatting, telemetry, and output style are all hidden behind the model-provider boundary. That is convenient until the system matters. DSG moves grounding into an MCP-compatible gateway where those decisions become explicit, measurable, and swappable.

That is the production-shaped idea. A serious agent stack should not treat retrieval as a side effect of generation. Search is infrastructure. It needs routing, cache policy, source normalization, telemetry, contracts, and cost controls. If grounding sits behind a stable interface, the reasoning model becomes more interchangeable. That matters in a world where teams are routing across GPT, Claude, Gemini, Qwen, DeepSeek, and local models depending on latency, cost, privacy, and task difficulty.

Native search is convenient; invisible bundles are expensive

DSG evaluates across five frontier models: GPT-4o, GPT-4o-mini, Gemini 2.5 Flash, Gemini 2.5 Pro, and Claude Sonnet 4. Public benchmark coverage includes SimpleQA with 1,000 questions, FreshQA with 500, and HotpotQA with 1,000. The production-style QIU workload includes Retail with 7,988 examples and Tail Synthetic with 2,335. The gateway normalizes providers such as Serper, BrightData, Firecrawl, and Exa through adapters, while exposing retrieval depth, exact caching, semantic caching, fallback, and telemetry for provider, cache outcome, latency, and cost.

The numbers are the kind engineers can actually use. On SimpleQA, native search averages 87.7% accuracy at $20.00 per 1,000 queries. DSG with BrightData reaches 86.1% at $1.80 per 1,000 queries — about 91% lower search cost for a 1.6-point accuracy tradeoff. DSG with Serper lands at 83.3% for $0.67 per 1,000 queries, a cheaper point on the frontier. On FreshQA, native search leads: 72.6% average accuracy versus 68.0% for DSG+BrightData and 67.3% for DSG+Serper. That is an important result because it keeps the paper honest. Sometimes the bundled provider is better.

The production workload is where the control-plane argument gets stronger. On QIU Retail, DSG+Serper reaches 93.90% versus 93.40% for native search while dropping cost from $7.90 to $0.110 per 1,000 queries. On Tail Synthetic, DSG reaches 87.79% versus 87.62% at $0.146 per 1,000 queries, more than 98% below native search cost. Warm-cache replay with GPT-4o and DSG+BrightData reaches a 99.4% cache hit rate and cuts average latency from 4,570ms to 1,465ms, a 68% reduction.

The most interesting bug is not cost, though. It is Search-Induced Verbosity. In HotpotQA diagnostics, an affected Claude Sonnet 4 native-search run began answers with “Based on the search results...” in 78.1% of predictions. Among exact-match failures, 62.3% still contained the correct answer as a substring. That is a very production kind of failure: the answer is semantically present, but the contract is broken. A parser, entity-only field, routing label, boolean, or schema validator does not care that the model was trying to be helpful.

This is why “just prompt it harder” is often the wrong fix. If native search injects evidence in a format that changes the generation style, you need a boundary where retrieval output is structured, logged, and separately testable. The model should receive normalized source-aware context, not an opaque provider experience that may drag presentation habits along with facts. Concision is not an aesthetic preference when the downstream system expects a specific artifact.

For builders, the action list is boring and valuable. Put search behind a stable tool interface. Log provider, query, result count, source URLs, cache hits, latency, and cost. Separate recency-sensitive queries from static factoids. Add TTLs so caching does not become a stale hallucination amplifier. Evaluate correctness and cost together. A 1.6-point accuracy gain may be worth 11× cost for high-stakes current events and ridiculous for low-risk catalog questions. The point is to decide, not inherit the decision from a model vendor.

The MCP angle is strategic. Native model features are sticky by design; every provider wants its search, memory, code execution, and agent tools to live inside its API boundary. A decoupled grounding layer gives platform teams leverage. It does not make every provider better. It makes the choice explicit. That is model arbitrage in the useful sense: not chasing a leaderboard every week, but separating reasoning from infrastructure so the system can route intelligently.

The caveat is that decoupling moves work onto your platform team. Someone must maintain adapters, cache rules, source rendering, telemetry, evals, and vendor terms. Third-party search providers can change pricing, indexing, latency, and availability. DSG does not remove operational complexity; it drags it into daylight. For serious agent workloads, that is usually the trade you want. Convenience ships the prototype. Control keeps the invoice and the parser from surprising you later.

Sources: arXiv, Model Context Protocol, SimpleQA, Google Search grounding docs