Intelai
Pick the Simplest Model That Clears Your Threshold
Model selection is not a menu of algorithms. Set the threshold first, then take the simplest model that meets it, because that is the one you can defend.
The standard advice on model selection is a menu. Fraud detection, try logistic regression or XGBoost. Time series, try Prophet or an LSTM. Natural language, try BERT.
The menu is not wrong. It is just not where the decision is made. By the time you are comparing algorithms, four constraints have already eliminated most of the options, and the survivor is usually the boring one.
Constraints eliminate before accuracy does
Ask these in order. Each one removes candidates, and the order matters because the first two are not negotiable.
Authorization. Where can this run? If the data is CUI, the model has to sit inside an authorized boundary, which removes most hosted APIs and a good part of the open-source ecosystem that assumes you can call out. A model you cannot deploy is not a candidate, however well it scores.
Data. How many labeled examples do you have, and do you have them for the thing you actually want to predict? Two thousand labeled rows and a clean feature set is a different problem from forty examples and a hope. Deep models need more data than a gradient-boosted tree does to beat it, and below a few thousand rows the tree usually wins.
Explainability. Who has to accept the output, and what do they need to see? A denial that a caseworker has to justify in writing is a different artifact from a ranking that nobody inspects. If the answer is "a person has to explain it to an affected party," that constraint alone puts you in a model class.
Latency and cost. Per request or per batch, at what volume, on whose hardware. This is where the fancy option usually dies, because the incremental accuracy does not survive the bill.
Only after those four do you get to the interesting question: which of the two remaining approaches is more accurate on your data.
The threshold is the real decision
Before you evaluate anything, write the number that decides. Not "high accuracy." A specific trade.
For a classifier: "Recall of at least 0.90 at precision no lower than 0.70." For a regressor: "Mean absolute error under $400 on a claim, because that is the amount a reviewer would catch anyway." For a ranking: "The right answer in the top three, 80% of the time, since a human reviews three."
The threshold does three jobs. It stops the evaluation from becoming an argument about taste. It tells you when to stop improving the model. And it gives the person who signs the authorization something to hold, which matters more in a regulated setting than a marginal gain in a metric.
If you cannot state the threshold, you are not ready to select a model. You are ready to collect requirements.
A table to start from, not to end at
| Problem | First thing to try | Reach for more when | What you give up |
|---|---|---|---|
| Yes/no decision on tabular data | Logistic regression with a handful of features | The simple model is under the threshold and the gap is not noise | Nothing much. This is the most defensible model you can ship. |
| Classification on tabular data | Gradient-boosted trees | You have image, text, or sequence inputs | Ease of explanation, though feature attribution helps |
| Continuous prediction | Linear model with sensible features | Error is dominated by interactions you can name | Simplicity, and some of the audit story |
| Forecasting a series | Seasonal baseline, then a standard forecasting library | You have many related series or long histories | Interpretability, setup time |
| Rare events | A simple anomaly score with a human review step | You have enough labeled positives to train on | Coverage. You catch less, and you explain why. |
| Text classification | Fine-tuned small encoder | The task needs reasoning over long context | Latency, cost, and sometimes accuracy on edge cases |
| Image inspection | A pretrained convolutional model | The defect is subtle, or the images are unusual | Compute, and the ability to run on cheap hardware |
The right-hand column is the one people skip. Complexity is not free at deployment. It shows up as a monitoring surface, a retraining schedule, a class of failure nobody on the team has seen before, and a harder conversation with an assessor.
The operational bill arrives later
A model is not a deliverable. It is a component with a maintenance schedule.
A gradient-boosted tree can be retrained in minutes on a laptop and its inputs can be listed in a table. A fine-tuned language model needs a GPU, a versioning scheme, an evaluation harness, and somebody who can tell whether a new checkpoint is better or just different. Both are fine choices. Only one of them fits an organization with no machine learning team.
The question I ask before recommending anything more complex than a tree: who retrains this in eighteen months, and how will they know it drifted? If there is no name, the answer is the simpler model, because the simpler model degrades in ways a person can see.
A model that is 3% less accurate and can be explained, monitored, and retrained by the team that owns it beats a better model that nobody can operate.
What the choice is actually about
Model selection is a documentation exercise wearing a technical costume. You are deciding what evidence you will have when someone asks why the system produced this output, and how you will know it is still working a year from now.
Pick the simplest model that clears the threshold. Write down the threshold, the data it was measured on, and the date. Then spend the time you saved on the part that actually fails: the labels, the data pipeline, and the process for acting on the output.