A marketing team uses one Foundry-hosted GPT model deployment for two tasks: drafting creative tagline ideas and answering factual questions about return policy from grounded content. They want the same deployed model to produce varied, imaginative taglines but consistent, literal answers for policy questions. What should they adjust between the two calls to achieve this?
Select an answer to reveal the explanation.
Short Explanation
Think of temperature as a creativity dial on the same model. Crank it up and the assistant starts riffing, tossing out fresh, sometimes surprising phrasing — perfect for tagline brainstorming. Turn it down and the same model gets literal and steady, sticking close to the facts you fed it, which is exactly what you want when someone asks about the return policy. The trap answers all reach for bigger tools to solve a small dial problem. Swapping model sizes between the two tasks changes cost and general capability, not how random a single answer is. Cranking up content filtering changes what gets blocked for safety, not how playful the wording sounds. And retraining the model before every request is slow, expensive, and solves a knowledge problem, not a tone-and-randomness problem you can fix with one setting.
Full Explanation
The correct answer is B. The team needs different behavior from two calls to the same deployed model, and temperature is a per-request parameter that controls how much randomness the model injects into its output — raising it produces more varied, imaginative taglines, while lowering it produces more literal, consistent answers grounded in the return policy. This lets one deployment serve both needs without any redeployment. Option A is incorrect because context window size determines how much text a model can process at once, not how creative or deterministic its output is. Option C is incorrect because adding a stricter content filter changes what gets blocked for safety reasons, not how varied or literal the wording is — a tagline and a policy answer can both pass the same filter. Option D is incorrect because retraining the model on more documents before every call is a heavy, slow step meant to change what the model knows, not a lightweight way to control randomness on a single request, and it would not by itself make the tagline output more imaginative or the policy output more literal.