Before 2023, if you wanted a model to predict something, you had to build one. Gather data, pick features, choose an algorithm, train it, validate it, deploy it. That’s real work, and it’s work most business teams couldn’t do without a data scientist.
Then LLMs showed up and could apparently do “AI stuff” without any of that. Ask ChatGPT if a transaction looks fraudulent, and it’ll give you an opinion. Ask it to score a lead, and it’ll score the lead. Ask it to forecast next quarter’s revenue from a spreadsheet, and it’ll produce a number with total confidence. It feels like the model-building step just evaporated.
It didn’t evaporate. It got hidden, and hidden is worse than absent because now nobody’s watching it.
What LLMs Are Actually Good At
Large language models are exceptional at tasks that involve language: understanding unstructured text, summarizing, extracting entities, classifying intent, generating drafts, translating, answering questions against a document. They’re pattern-matchers over language and, increasingly, over reasoning chains expressed in language. That’s an enormous and genuinely new capability.
What they are not is a replacement for a purpose-built machine learning model trained on your labeled historical data to predict a specific outcome. Churn. Fraud. Demand. Credit risk. Propensity to buy. Equipment failure. These are exactly the problems that classical ML has been solving accurately, cheaply, and explainably for years.
Where I See Teams Get This Wrong
Using an LLM as a classifier over structured, numeric data
If your input is rows and columns you have a tabular ML problem. Tabular data is one domain where LLMs still routinely lose to gradient boosted trees, and they lose by a lot on cost and latency. A trained XGBoost model scoring a customer costs you microseconds and fractions of a cent. An LLM call to do the same thing costs 500-2,000 milliseconds and real money per call, and you’re paying that on every single row, every single day.
Using an LLM for forecasting
I’ve seen teams paste a CSV of monthly sales into a prompt and ask for next quarter’s number. The LLM will confidently give you one. It has no concept of seasonality, trend decomposition, or confidence intervals unless you build all of that into the prompt yourself, at which point you’ve just badly reimplemented a time series model in natural language.
Treating “confidence: high” as a probability
This one bites people hardest. When an LLM says it’s “highly confident,” that’s not a calibrated probability the way a logistic regression model’s output is. It’s a token the model generated because it was statistically likely given the prompt. A real classifier gives you a number you can threshold, monitor for drift, and back-test against ground truth. An LLM’s stated confidence is closer to a vibe than a metric, and treating it like one in a risk model is how you end up explaining a bad decision to compliance.
No reproducibility
Ask the same tabular ML model the same input twice, you get the same output, every time. Ask an LLM the same question twice and you can get subtly different phrasing or worse, a different answer. If your prediction has to be audit-defensible six months from now that’s a real problem, not a hypothetical one.
Cost at scale
Run the math for a client scoring 2 million transactions a day for fraud risk. A trained model in Snowflake or Databricks scores that batch for a few dollars in compute. Running the same volume through an LLM API (even a cheap one) could be north of $15,000 a day. Ouch.
Where the LLM Actually Belongs in That Same Workflow
None of this means LLMs don’t belong near your ML pipeline. They’re often the best tool for the parts around the prediction. For example:
Turning a customer support ticket into structured features your churn model can consume. Summarizing why a model flagged an account, in plain English, for the account manager who has to make the call. Generating the narrative explanation that goes with a credit decision. Extracting entities from an unstructured contract before your risk model scores the deal. Answering “why did this happen” questions against your documentation after the numeric model has already made the prediction.
That’s a legitimate architecture; a trained ML model makes the prediction, and an LLM handles the language layer around it. What doesn’t work is collapsing both jobs into one prompt and hoping the LLM quietly does statistics on the side.
A Simple Test Before You Reach for an LLM
Ask yourself two questions. First, is the output a structured prediction (a number, a category bucket, a score) derived from structured, historical, labeled data? If yes, that’s an ML model’s job, not an LLM’s. Second, could you explain the decision using a feature importance chart or a coefficient table instead of a paragraph of generated text? If the answer is yes, you already know what tool you need.
If instead you’re working with messy unstructured text, need something summarized, or need to reason across a document, the LLM is exactly the right call. The test isn’t “is this an AI problem?” Almost everything is called an AI problem now. The test is what kind of AI problem it actually is.
Bottom Line
The line between an LLM problem and an ML problem hasn’t disappeared just because LLMs got good enough to fake answering both. If the input is structured and historical and the output needs to be a calibrated, explainable, cheap, reproducible prediction, train a model for it. Save the LLM for the language work it’s actually built for; things like understanding, summarizing, explaining, and generating text around the prediction your real model already made.
Match the tool to the problem, not the hype to the budget.
Leave a Reply