Take a car insurance pricing model, the kind of tool that's been doing this job since the 1970s, and instead of feeding it a tidy row of numbers, rewrite that same row as a sentence. Driver age, region, vehicle power, bonus-malus score (an insurer's shorthand for a driver's claims history), all of it, poured into a fixed text template that reads like an underwriting checklist. Then run that text through a large language model (LLM), grab the embedding it produces, a single numeric vector standing in for the whole passage, and hand that to the old pricing model in place of the features an actuary would normally hand-build.That's what two researchers did in a preprint posted in June 2026, not yet peer-reviewed. It worked. The embedding-fed version predicted claim frequency better than the industry-standard model, at least when there wasn't much data to go on. Give it more data, though, and the advantage got fuzzy rather than disappearing outright. Which model won started depending on details like the exact embedding model and how many dimensions were kept.That fuzziness is the whole point of this piece. Nobody won cleanly here, and that's more useful than either side winning. What follows is three real head-to-heads, drawn from insurance pricing, time series forecasting, and the making of GPT-3 itself. Each one tests an assumption people carry about LLMs and classical machine learning, and each turns on a different, nameable reason one approach came out ahead. Line them up and you get something better than "LLMs are just chatbots" or "AI is eating everything." You get an actual answer to when to reach for which tool.Insurance Pricing Shows What Scarce Data Does to a Constrained ModelThat preprint is by Christopher Blier-Wong and Derek Kusmenko, tested on French motor third-party liability data. The old workhorse it went up against is called a generalized linear model, or GLM, a statistical technique that's still what most insurers use to predict claim frequency and set prices. Think of it as regression's more flexible cousin, built to handle counts and probabilities instead of just plain numbers. Actuaries like it for a specific reason. It's transparent, and you can audit what every coefficient is doing.That transparency comes with a real limitation, and it's the crux of this whole result. A GLM adds up the effect of each variable separately, so it can only account for combinations of risk factors if an actuary explicitly builds those combinations in by hand. Consider an 18-year-old driving a high-powered car in a dense city. Each of those three facts carries some risk on its own, but together they may be far riskier than the sum of the parts. A GLM won't see that unless someone thought to construct the interaction term.This is where the embedding earns its keep. Because the transformer's attention mechanism lets every token's representation depend on the other tokens around it, the vector encoding "18 years old" is shaped by the vehicle and location sitting next to it in the prompt. Those combinations arrive pre-baked in the embedding, and the GLM can use them without anyone hand-specifying a single interaction. Worth being precise about what is and isn't happening here. The paper is explicit that the embedding "contains no new fields." It's a re-encoding of the exact same variables, not a smuggling-in of outside knowledge about drivers. When data is scarce, that automatic interaction structure is worth more than what a GLM can wring out of a thin dataset on its own. As data grows, flexible models get enough observations to find those patterns themselves, and the paper's own numbers show the advantage stops being clear-cut.None of this has shipped in a real insurance product, and it hasn't been peer-reviewed, so treat it as an early signal rather than settled science. The researchers also flag a governance catch. Their prompt-sensitivity check found the pipeline reacts to any field appended outside the template, which means controlled prompts aren't optional if you'd want to deploy something like this.Time Series Forecasting Shows the Input Representation Decides the OutcomeDoes bolting an LLM onto a forecasting problem, predicting sensor readings, demand curves, anything sequential, actually help? Mingtian Tan and colleagues put this to the test at NeurIPS 2024 by taking existing LLM-based forecasters, ripping out the LLM piece, and swapping in a bare attention layer, the raw building block LLMs are made of, with none of the language pretraining. Performance held steady. Often it got better. They pushed further and found the pretrained LLMs weren't just unnecessary. They performed no better than models trained from scratch, missed the sequential dependencies that actually matter in time series data, and gave no boost at all in few-shot settings, the cases with barely any training data.That reads like an open-and-shut case against LLMs for this kind of work, until you look at Amazon's Chronos. It's built on the T5 language model family, and it forecasts well. The difference isn't that Chronos avoided language-model machinery. It's what Chronos did to the input. Rather than handing the model numbers and hoping its text-trained instincts transfer, the team converted time series values into a fixed vocabulary of tokens through scaling and quantization, which rounds continuous readings into a limited set of buckets, then trained on those tokens with the same cross-entropy loss a language model uses. The representation was rebuilt for numeric data, and only then did the borrowed architecture pay off. Google's TimesFM makes the point from the other direction. It's a forecasting transformer with no language-model ancestry at all, and it still beats classical tools like ARIMA (a long-standing time series forecasting method) while running at a fraction of a general LLM's size.Then there's Uber, whose production forecasting stack sidesteps LLMs entirely. Its engineering blog describes a mix that spans classical statistical methods like ARIMA and Holt-Winters alongside machine learning approaches including recurrent neural networks, their LSTM variant built to hold on to longer patterns, and gradient boosting. Deep learning is very much in the toolkit. Language models aren't. Uber's own engineers go further, writing that classical and machine learning methods "are not that different from each other," separated mainly by whether you want something simple and interpretable or complex and flexible.So the lesson isn't "LLMs fail at forecasting." It's narrower and more useful. What decides the outcome is whether the model was actually built for the shape of your data. Bolt a pretrained LLM onto a forecaster and its language-trained reasoning contributes nothing. Rebuild the input representation for numbers first, as Chronos did, and the same underlying architecture starts earning its place.InstructGPT Shows How You Train Can Beat How Big You BuildThe third head-to-head isn't LLM versus classical model at all. It's LLM versus LLM, and it still knocks over a pretty common assumption about what makes these systems good.GPT-3, 175 billion parameters, was trained the ordinary way for its era. Guess the next word, over and over, across a mountain of internet text. That's a fine way to build something that keeps a sentence going, but it doesn't guarantee the model actually does what you asked. OpenAI's InstructGPT took a version of that same model, shrunk to 1.3 billion parameters, roughly 100 times smaller, and put it through an extra round of training. Humans graded its answers for helpfulness and accuracy, and the model was tuned with reinforcement learning to chase what people actually liked. That technique has a name, RLHF, short for reinforcement learning from human feedback.When people compared the two models' answers side by side, they picked the tiny RLHF-trained one over the giant raw one most of the time. Same architecture, no extra parameters, just a second training pass aimed squarely at what humans wanted.This doesn't break the well-worn rule that bigger models tend to perform better. It just proves that rule has company. Scale is one lever. How you train the thing is another. Here, the second lever did more work than the first.The Pattern Underneath All ThreeStrip away the specifics and none of these three stories is really about whether something is an LLM or "classical" machine learning. Each one hinges on a condition you could check before writing a line of code, which makes them useful in a way that opinions about AI aren't. So when you hit your own version of this choice, ask three questions.Is your data thin, and is your current model structurally unable to find the patterns you need without hand-holding? That was the insurance case. An embedding handed a GLM the variable interactions it can't discover by itself, and that mattered most when there wasn't enough data for anything to learn them from scratch. Expect the advantage to narrow as your data grows, the way theirs did.Is the task numeric or sequential rather than language-shaped? If so, has the model you're eyeing had its input representation rebuilt for that kind of data, or is it a chatbot wearing a new hat? A pretrained language model bolted onto a forecaster added nothing at all. The same architecture, fed a purpose-built numeric tokenization, worked.And is the gain you're chasing really about size, or about one specific behavior you want reinforced? A focused round of training beat a model 100 times its size, which is worth sitting with before you reach for the biggest thing available.The line between LLMs and classical machine learning isn't parked in one place. It moves, the same way it moved for that insurance model the moment its training data ran thin, and these three cases are just where it happens to sit right now.ReferencesBlier-Wong, C. and Kusmenko, D., "Semantic insurance pricing with large language models" (2026): https://arxiv.org/abs/2606.29371Tan, M. et al., "Are Language Models Actually Useful for Time Series Forecasting?" NeurIPS 2024: https://arxiv.org/abs/2406.16964Google Research, "A decoder-only foundation model for time-series forecasting" (TimesFM): https://research.google/blog/a-decoder-only-foundation-model-for-time-series-forecasting/ ; paper: https://arxiv.org/abs/2310.10688Amazon Science, "Chronos: Learning the Language of Time Series": https://www.amazon.science/publications/chronos-learning-the-language-of-time-seriesUber Engineering, "Introduction to Forecasting": https://www.uber.com/blog/forecasting-introduction/Ouyang, L. et al., "Training language models to follow instructions with human feedback" (InstructGPT, 2022): https://arxiv.org/abs/2203.02155Brown, T. et al., "Language Models are Few-Shot Learners" (GPT-3, 2020): https://arxiv.org/abs/2005.14165Kaplan, J. et al., "Scaling Laws for Neural Language Models" (2020): https://arxiv.org/abs/2001.08361