A retail company runs a Foundry-hosted chat deployment on model version 2 in production, serving live customer traffic. The team wants to switch to model version 3, which tests better in evaluation, but wants to catch any regression in real customer conversations before committing all traffic to it. Which deployment approach best satisfies this?
Select an answer to reveal the explanation.
Short Explanation
Picture rolling out a new engine to a fleet of delivery trucks: you would not swap every truck overnight, and you would not trust it just because it passed a bench test. You would put it in a few trucks, watch how it does on real routes, and expand from there. That is the move here, standing up a second, parallel deployment and slowly increasing the share of real customer traffic it handles while watching for trouble, so a regression shows up on a small slice of customers instead of everyone at once. Flipping every customer over in one shot throws away any chance to catch a problem early. Trusting only the lab-style evaluation scores ignores how the model behaves on the actual, messy mix of real conversations. And poking at it by hand in a playground only tests what the tester happens to think of, never the live production path itself.
Full Explanation
The correct answer is C. Standing up a parallel deployment on version 3 and routing a small, increasing share of live traffic to it lets the team compare real customer outcomes against version 2 and catch a regression before it affects everyone, which is the staged, evidence-based rollout the scenario calls for. Option A is incorrect because cutting over all traffic at once removes any chance to detect a regression before every customer is affected, exactly the risk the team wants to avoid. Option B is incorrect because offline evaluation scores, however good, do not capture how the model behaves on the specific mix of real customer conversations this deployment receives; only live traffic testing can catch that. Option D is incorrect because manual playground testing only exercises prompts the tester thinks to try; it cannot substitute for observing behavior across genuine, high-volume customer traffic, and it never actually validates the production path.