What is the key property that distinguishes shadow deployment from a standard A/B test for LLMs?

**Shadow deployment** is a way to test a new model (the challenger) against the one already in production (the incumbent) using real user traffic. Every incoming request is sent to both models. The incumbent's answer is the only one returned to the user. The challenger's answer is captured and stored for evaluation later. The defining property is zero user exposure. Users never see the challenger's output, so even if the challenger is buggy or worse, no real user is harmed. That is what makes option A correct. The other options describe things shadow deployment does not do. It is not slower for the user, because the incumbent's response is served immediately and independently of the challenger. It does not use synthetic traffic, it mirrors the real production stream. And it does not auto-promote the challenger, promotion is always a separate human or policy decision. The trade-off is cost and signal. You pay for two model calls on every request, roughly doubling inference cost. And because the challenger's output is never shown, you get quality and latency data but no real user feedback like clicks or thumbs-up.

**Shadow deployment** mirrors real production traffic to a challenger model while serving only the incumbent's response to users. That single property defines it: real traffic, zero user exposure. The challenger generates a full response for every mirrored request. That response is logged, not served. You then evaluate it offline against the incumbent. You score latency, cost, format validity, refusal rate, and quality via an LLM judge or human review. The user-facing path is untouched, so a broken challenger harms nobody. Contrast this with A/B testing and canary. Both A/B and canary actually serve the challenger to some users. That exposes those users to potentially worse output. The upside is they collect real user-feedback signals: clicks, thumbs, conversion, retention. Shadow cannot collect any of those, because nobody ever sees the challenger. The two costs are real. First, you run inference twice on every shadowed request, so spend roughly doubles. Second, the missing user-feedback signal means shadow is a pre-flight check, not a final verdict. The standard pattern is to shadow first to de-risk obvious regressions, then graduate to a small canary or A/B slice to capture true user response.