How to choose a model — and why it isn't the first decision
The right direction
If even the strong model fails, you've discovered cheaply that the problem isn't model choice but task definition, data, or prompt. If it succeeds, you have a quality baseline, and now you can go down and find the point where quality drops below your bar.
Four axes
Quality on your task — not on public tables that test other tasks.
Cost per operation — driven mainly by the text going in, not out.
Speed — critical in a live interface, almost irrelevant in background processing.
Where the data runs — a question of regulation and risk, not of quality.
When to train
Almost always not, and not at the start. Prompt improvement, good examples, and connecting to the right information source solve most gaps. Fine-tuning is worth considering when you have thousands of quality examples and the goal is to lower cost or response time.
Going deeper
Wrap the model call in one layer you control, so swapping a vendor is a config change. And keep a log per call — model, prompt version, text amounts and time — or questions like “when did quality drop” become unanswerable.