A helpdesk platform needs to classify thousands of incoming tickets per minute into 'billing', 'technical', or 'account' categories. Latency and per-call cost matter more than nuanced reasoning. The team is choosing between a small efficient model and a large flagship model in the Foundry model catalog. Which should they deploy for this task?
Select an answer to reveal the explanation.
Short Explanation
When the job is simple — sort this ticket into billing, technical, or account — you do not need the biggest, most capable model in the catalog. A smaller model can nail that kind of narrow sorting task just fine, and it will answer faster and cost less per call, which adds up fast at thousands of tickets a minute. The wrong turns here assume bigger is always better or that model size gates other features. Bigger models are not automatically more accurate on a task this simple, and they cost more without buying you anything here. Content filtering is a setting you turn on for a deployment regardless of model size, not a large-model exclusive. And every deployment, big or small, gets billed by the token — the point of choosing the smaller model is that those tokens cost less and arrive faster, not that they escape billing altogether.
Full Explanation
The correct answer is C. Categorizing support tickets into a small, fixed set of labels is a narrow, well-defined task that does not require the deep reasoning or broad world knowledge of a flagship model. A smaller model in the Foundry catalog can handle this classification accurately while responding faster and at lower per-call cost, which matters when processing thousands of tickets per minute. Option A is incorrect because larger models are not universally more accurate; on narrow, high-volume classification tasks a well-suited smaller model often performs comparably while adding unnecessary latency and cost. Option B is incorrect because content filtering is a platform-level configuration applied to a deployment, not a capability restricted to large models — small models support it too. Option D is incorrect because Azure applies per-token billing to both small and large model deployments; the smaller model's advantage here is lower cost per token and faster response time, not an exemption from usage-based billing.