--- title: "Classical ML still beats an LLM at forecasting demand" url: "https://hurukan.com/blog/classical-ml-still-beats-llms-at-forecasting" description: "Asking a chat model how much stock to order produces a fluent number, not a forecast. Demand forecasting is still a job for classical models, a baseline and a backtest." --- # Classical ML still beats an LLM at forecasting demand June 30, 2026·4 min read·Editorial team A planner seen from the side in a bright office overlooking tall warehouse racking, a monitor showing an abstract blue line chart with a shaded band, a printed spreadsheet and a pen on the desk A buyer pastes a year of monthly sales for one product into a chat assistant and asks how many units to order for next quarter. The answer is a single confident number with a reasonable explanation: there is some seasonality, a mild upward trend, and a safety margin has been added. The buyer places the order. The number may even be close. That is not the problem. The problem is that nobody knows how close it is likely to be, because nothing about it can be measured. There is no record of how this method would have performed last year, no error range, and no knowledge of the promotion planned for next month, the three weeks the item was out of stock, or the supplier’s new lead time. Forecasting demand is a statistical problem about numbers over time, with known structure: trend, seasonality, promotions, price changes, and stock-outs that hide real demand. Classical methods were built for that structure. Exponential smoothing, ARIMA-type models and gradient-boosted trees on well-chosen features are cheap to run, and above all their error can be measured on history before anyone trusts them. A general-purpose language model generates likely text. A number inside that text comes with no error bar and no backtest. ## Where asking a chat model goes wrong **No backtest.** You do not know how wrong the method would have been on last year’s data, so you cannot compare it with anything, including doing nothing clever at all. **Sales are not demand.** When the shelf was empty, sales were zero, and the demand was not. A model reading raw sales history learns lost demand as low demand. Forecasting pipelines handle stock-outs explicitly; a pasted table does not. **What fits in a prompt is not the history.** A real assortment is many items across many locations, with a hierarchy of categories that share patterns. That does not fit in a conversation, so the model forecasts each item in isolation from the little it was shown. **A different answer each time.** Language models sample their output. Ask twice and you may get two numbers, and there is no principled way to choose between them. **Explanations that sound right.** The model will mention seasonality whether or not the data has any, because forecasts usually mention seasonality. The explanation is a style, not an analysis. **Cost and speed at scale.** Running every item every week through a large model costs far more than a classical model that runs comfortably on ordinary hardware. ## Where each kind of model belongs **Classical models produce the numbers.** Start with naive baselines: the same period last year, and the average of recent periods. Then try exponential smoothing and a gradient-boosted model with features for price, promotions, calendar and stock-outs. Keep whichever beats the baselines on a backtest, and keep measuring it. **The language model gathers and explains.** It reads the supplier’s email announcing a longer lead time and turns it into a parameter. It turns the promotion plan written by sales into features the forecast can use. It explains a forecast to the buyer in plain words, and drafts the purchase order for approval. That is where language models are strong, as set out in [where language models earn their keep](https://hurukan.com/blog/where-language-models-earn-their-keep). **Time-series foundation models are a separate category.** Models pretrained specifically on time series are not chat assistants, and some of them are worth testing. Treat them like any other candidate: same baseline, same backtest, and keep them only if they win on your data. **A person decides the order.** The forecast, its uncertainty and the constraints (minimum order quantity, shelf life, budget) become a proposed purchase order. Someone accountable approves it. That chain is what Hurukan’s modules are designed around. Stock, reservations and counts in [Inventory and Logistics](https://hurukan.com/modules/inventory-and-logistics) supply the history and the stock-outs; [Procurement](https://hurukan.com/modules/procurement) turns a forecast into a proposed purchase order that waits for approval. The [Super Intelligence layer](https://hurukan.com/system/super-intelligence) routes each task to the right kind of model: a language model to read and draft, a forecasting model for the numbers. It is in build. A forecasting model of this kind is also a good example of a model that can run on your own hardware, as discussed in [small models on your own hardware](https://hurukan.com/blog/small-models-on-your-own-hardware). ## A test you can run today Take one product with at least two years of history. Hold back the most recent three months and pretend you do not know them. Forecast those three months three ways, using only the data before the holdout: 1. The same three months of the previous year. 2. The average of the three months just before the holdout. 3. Whatever your current method is, whether that is a planning tool, a spreadsheet or a chat assistant. Compare each forecast with what actually happened, using the average absolute error per month. If your current method does not beat both naive baselines, no model upgrade will help until that is understood. Whatever wins, you now have a number for how wrong it tends to be, and that number is what makes a forecast usable: it tells you how much safety stock to hold and how far to trust the next figure. - demand forecasting - machine learning - backtesting - procurement ## Keep reading - [One identity for people and agents: who may do what](https://hurukan.com/blog/one-identity-for-people-and-agents) - [The live state and the record: two memories of a company operating system](https://hurukan.com/blog/the-live-state-and-the-record-two-memories-of-a-company-operating-system)