A helpdesk platform processes 50,000 incoming support tickets per day and only needs to sort each one into one of six predefined categories, such as billing or password reset. The team compares options in the Azure AI Foundry model catalog and finds a small, low-cost model already meets the accuracy target for this sorting task in benchmark tests. What should the team do?
Select an answer to reveal the explanation.
Short Explanation
Picture two toolboxes: one with a giant power drill, one with a simple screwdriver. If the job is turning a small screw fifty thousand times a day, reaching for the giant drill every time just burns more electricity for the same result. The catalog's benchmark numbers already told the team the screwdriver, the small model, gets this simple six-way sorting job done at the accuracy they need, so paying more per call for a bigger model buys nothing extra here. Grabbing the biggest model out of habit sounds cautious but at this volume it is just wasted spend on capability the task never asked for. Running two big models and blending their guesses doubles the cost and adds complexity for a task that was never that hard to begin with. And picking a model because it is the newest release ignores the one thing that actually matters: whether it hits the accuracy bar on this exact job, which is what the benchmark comparison already answered.
Full Explanation
The correct answer is C. When a benchmark shows that a small, inexpensive model already meets the accuracy bar for a simple, well-defined task like sorting tickets into six categories, deploying that model minimizes cost per call across 50,000 daily requests without sacrificing the quality the team actually needs; the model catalog's benchmark data exists precisely to support this kind of size-to-task matching. Option A is incorrect because model size does not automatically translate into safety or reliability for a narrow classification task, and paying for a larger model's extra capacity when it is not needed just inflates cost at high volume for no measurable benefit. Option B is incorrect because running two large models and averaging their outputs roughly doubles inference cost and adds latency and complexity, which is a poor trade for a task the benchmarks already show a single small model handles adequately. Option D is incorrect because release date says nothing about a model's fitness for a specific task; ignoring the catalog's benchmark comparisons in favor of recency abandons the evidence the team already gathered.