ML or LLM: which one your problem actually needs
The large language model is now the default reach for every task. Many operational problems are served better, cheaper, and more reliably by classical machine learning.
The language model has become the answer to questions no one asked it. A team has a forecasting need, a scoring need, an anomaly to catch, and the first instinct is to prompt a model built to write sentences. Sometimes that fits. Often it is the wrong tool applied with confidence, and the cost surfaces later as latency, spend, and answers that shift when they should hold. The distinction worth keeping is old and unglamorous: some problems are prediction on structured data, and some are work on messy language. They call for different machinery.
Where classical ML fits
Classical machine learning is the right tool when the input is your own structured data and the output is a prediction or a class. Demand forecasting, churn, fraud and anomaly detection, routing, lead and risk scoring: these are numeric problems with a defined answer. A trained model returns that answer in milliseconds, at a fraction of the cost, and returns the same answer for the same input every time. It can also be explained, which matters when a decision has to be defended to a regulator, a customer, or an auditor. If your task is a number or a label drawn from columns you already hold, this is the machinery you want.
Where an LLM earns its place
The language model is the right tool when the input is unstructured language and some variation in the output is acceptable. Summarising a long thread, pulling fields out of a free-text form, drafting a first reply, answering a question against a set of documents: these are jobs where the input is prose, not columns, and where no single output is the only correct one. Here the model's flexibility is the entire point. It handles phrasing it has never seen and produces something usable without a rulebook for every case. That same flexibility turns into a liability the moment you need one exact answer, repeated.
The tradeoffs, named plainly
A call to a language model costs more and takes longer than a lookup against a trained model, and at operational volume that gap compounds. It is also non-deterministic: the same input can yield different wording, and now and then a different meaning. The failure mode that catches teams out is the confident wrong answer, fluent and plausible and incorrect, far harder to spot than a blank or an error. Classical ML fails more visibly and more predictably. Neither property is good or bad on its own; each is a fit for some tasks and a hazard for others.
A test you can apply
Two questions settle most cases. First, is the input structured numbers or unstructured language. Rows and columns point to classical ML; free text points to a language model. Second, does the task need the same answer every time it sees the same input. If it does, you want the determinism of a trained model, not the variance of a generative one. Where the two questions disagree, the second usually wins: a task on language that still demands one fixed answer is a signal to constrain the model tightly, or to reach for something else.
In practice most working systems use both, and the design skill is drawing the seam. Classical ML makes the decision, quietly and consistently. The language model handles the language around it, the explanation, the summary, the reply. Choose by the shape of the problem, not by whichever tool is in fashion this year.