On this page
Classical ML vs LLMs: when each wins
The last few years have made "AI" and "large language model" sound like synonyms. They are not, and confusing them is expensive. A gradient-boosted tree trained on three years of your sales history will out-forecast a language model, cost a fraction of a fils per prediction, run in milliseconds inside your own network, and produce a feature-importance chart your finance director can argue with. A language model does none of that well, because forecasting is not a language problem.
The dividing line is the shape of the input. If your input is a table — numbers, dates, categories, identifiers — classical machine learning is almost always the right tool. If it is prose, a scanned document, a support ticket or a contract, you need something that understands language, and that is where LLMs earn their cost.
| Dimension | Classical ML | Large language models |
|---|---|---|
| Input shape | Structured rows and columns | Unstructured text, documents, images |
| Typical tasks | Forecasting, scoring, ranking, anomaly detection | Extraction, summarising, classification of prose, drafting |
| Training data | Your historical records; needs labels | Pre-trained; often works with few or no examples |
| Cost per prediction | Negligible | Meaningful at volume; per-token pricing |
| Latency | Milliseconds | Hundreds of milliseconds to seconds |
| Explainability | Feature importance, partial dependence | Weak; the reasoning shown is not the mechanism |
| Determinism | Same input, same output | Varies unless tightly constrained |
| Runs on your own hardware | Easily | Possible with open-weight models; heavier |
The strongest production systems usually combine both. A language model reads a supplier invoice and pulls out line items; a classical model then decides whether those numbers are anomalous. Each tool does the part it is good at, and the expensive component is only invoked once per document rather than once per row.
Demand forecasting
Forecasting is where machine learning most reliably pays for itself, because the errors already cost you money — you simply are not counting them. Overstock ties up working capital and ends in markdowns. Understock loses sales you never see. Both are absorbed silently into normal operations.
A useful forecast needs enough history to observe each seasonal pattern more than once, which in the Gulf usually means two to three years so the model can learn Ramadan and Eid effects, the summer slowdown, and the difference between the school calendar in Dubai and in Riyadh. These are not noise; they are the dominant signal in many retail and food categories, and a model that has seen only one Ramadan cannot separate the effect from that year's other events.
The improvement over a spreadsheet is rarely spectacular in percentage terms. The value is in what it unlocks: less safety stock for the same service level, fewer emergency purchase orders, a better position with suppliers. Forecasting also depends on the systems around it, which is why it usually sits alongside ERP and data analytics rather than standing alone.
Fraud and anomaly detection
Fraud detection is unusual because you rarely have many confirmed examples to learn from, and the pattern changes deliberately in response to your defences. This makes it a poor fit for pure supervised learning and a good fit for hybrids: deterministic rules catch known patterns cheaply, and an unsupervised model flags transactions that do not resemble normal behaviour.
The same machinery applies well beyond payments. Unusual meter readings, a machine drawing more current than its peers, a picking pattern that suggests shrinkage, an expense claim that does not fit the claimant's history — all are anomaly detection with a different label. Our IoT work often ends up here: once sensors are streaming, the next question is which readings deserve attention.
The hard part is not the model. It is the threshold. Every anomaly system produces a queue, and that queue must be staffed. Too sensitive, and your team drowns in false positives, stops reading the alerts, and the system is dead within a month. Set the threshold by how many investigations your team can complete in a day, not by whatever maximised a score during development.
Document extraction
Document extraction is the clearest early win for most organisations, because the manual process is visible, tedious and already measured. Invoices, purchase orders, delivery notes, contracts, KYC packs and claim forms arrive as PDFs or photographs, and somebody retypes them into a system.
Modern models handle this well, including mixed Arabic and English documents and the awkward reality of a phone photo of a crumpled delivery note. The realistic target is not full automation. It is straight-through processing for the majority of clean documents, with the remainder routed to a human — who now reviews a pre-filled form rather than typing from scratch.
The lesson from our ERP-integrated ZATCA e-invoicing work is that extraction accuracy matters less than what happens next. A field that flows into a validated invoice pipeline is worth something; a field that lands in a spreadsheet somebody must still check is worth very little. For Saudi e-invoicing specifically, the structural requirements are covered in our ZATCA e-invoicing solution and our Saudi Arabia page.
Churn and retention
Churn models are widely built and frequently useless, for a specific reason: they predict something you cannot act on in time. A model that tells you a subscriber will lapse next month, when the decision was made six weeks ago after a bad support experience, is an accurate historian rather than a useful tool.
A churn model earns its place when three things hold. The prediction arrives early enough for an intervention to plausibly work. Someone owns that intervention and can execute it. And it is tested against a holdout group, so you learn whether it helps rather than assuming it does. Without the third, you cannot distinguish a successful retention programme from customers who were never going to leave.
Ask the action question before the model question. If you had a perfect prediction tomorrow morning, who receives it, what do they do, and how would you know it worked? If that has no answer, the model will not have one either.
The data you actually need
The most common reason a machine learning project stalls has nothing to do with modelling: the historical record does not support the question. Volume is the least of it.
- An honest target. The thing you want to predict must have been recorded in the past, consistently, and mean the same thing throughout. "Churned" defined differently by two teams produces a model that predicts the definition, not the behaviour.
- Point-in-time correctness. Every input must have been knowable at prediction time. Training on a field that is only populated after the outcome produces a model with excellent test scores that collapses in production. This leakage is the single most common cause of a demo that never survives contact with real traffic.
- Enough history to see the cycle twice. Seasonality cannot be learned from a single occurrence.
- Coverage of the cases you care about. A fraud model trained only on fraud you already caught learns to catch fraud you already catch.
- A path to production data. If a feature exists in a warehouse export but is not available live at inference, it cannot be used, however predictive it looks.
This is why our engagements begin with a short, unglamorous look at the data before anyone proposes a model. It is quicker to discover in two weeks that the target variable is unusable than in six months. Where the platform needs work first, that becomes a business intelligence or custom application conversation instead — a legitimate outcome, not a failure.
Why accuracy is the wrong headline metric
Accuracy is the percentage of predictions that were right. It is intuitive, quotable, and misleading in almost every business context worth modelling.
The problem is imbalance. If one transaction in a thousand is fraudulent, a model that approves everything is 99.9 per cent accurate. If two per cent of customers lapse each month, predicting that nobody lapses scores 98 per cent. Accuracy rewards ignoring the rare event that is the entire reason for the project.
What matters instead is precision and recall at the threshold you will actually operate at, and the cost attached to each type of error. Those costs are rarely symmetric. Missing a fraudulent transaction might cost several thousand dirhams; wrongly declining a good customer costs an apology and possibly a relationship. Once each error has a currency value, choosing a threshold stops being a modelling debate and becomes an arithmetic one — the point at which the business can meaningfully participate.
Headline percentage error is similarly weak for forecasting. Being ten per cent under on a fast-moving item that stocks out is a different event from being ten per cent over on something with a two-year shelf life. Weight the metric by what the error costs.
MLOps, monitoring and drift
A model is not a deliverable. It is a component with an expiry date that nobody prints on the box.
The world the model learned moves on. You launch products it never saw. Pricing changes. A competitor opens nearby. A fraud ring finds a new technique. The model keeps returning confident predictions throughout, because nothing in it knows the ground has shifted. This is drift, and in our experience it kills deployed models far more often than any flaw in the original training.
Handling it needs unremarkable engineering rather than research: version the training data and the model together so a prediction can be traced to what produced it; monitor input distributions so you notice when incoming data stops resembling the training set; track live performance against outcomes as they arrive; keep the previous model deployable so a bad release is a rollback rather than an incident. This sits on ordinary cloud infrastructure — the same AWS or Azure foundations as the rest of your platform, with region chosen for residency rather than habit.
The organisational half matters just as much. Somebody must own the model after launch. A model without an owner degrades silently, and the first sign is usually a business number moving the wrong way for reasons nobody connects to the model for months.
How Inovsion helps
We are a software engineering company that builds machine learning into working systems, not a research lab. That shapes what we do and what we decline to do.
Engagements typically start with a short data assessment: can your history answer the question, what would the prediction be worth if it were perfect, and who would act on it. That assessment sometimes concludes machine learning is not the answer yet — that better instrumentation, a cleaner pipeline or a straightforward rules engine gets most of the value sooner. We would rather say that in week two than bill for six months of modelling on data that cannot support it.
Where the data does support it, we build the model and the system around it: the pipeline, the API, the interface the team uses, the monitoring, the retraining schedule, and the integration into whatever ERP, CRM or operational platform the prediction must reach in order to matter. That integration is the difference between a model and a result, and it is most of the effort.
- Delivery across the region. Teams working with clients in the UAE, Saudi Arabia and India, familiar with regional data residency expectations and with mixed Arabic and English data.
- Systems, not notebooks. Our background is production software — ERP, CRM, mobile and IoT — so models land inside systems people already use.
- Sensor and telemetry experience. ClueMaster, our IoT platform for managing escape rooms across multiple locations, is the kind of estate where anomaly detection has an obvious home.
- Compliance-sensitive pipelines. Our ERP-integrated ZATCA e-invoicing solution means we build document and validation flows where being approximately right is not acceptable.
- Honest scoping. Where a rules engine wins, we will tell you, and we will build the rules engine.
You can see delivered work on our portfolio, or read the related guides on machine learning development and AI development.
Frequently asked questions
How much data do we need before machine learning is worth trying?
It depends on the problem, not on a universal row count. Demand forecasting typically needs two to three years of history so the model can see seasonality and Ramadan or Eid effects more than once. Fraud and anomaly detection can work with far fewer confirmed cases, because unsupervised and rules-plus-model hybrids do not need thousands of labelled frauds. Document extraction often needs only a few hundred labelled examples per document type. The more useful question is whether the outcome you want to predict was recorded reliably in the past.
Should we use an LLM or a classical machine learning model?
Use classical models when the input is structured, numeric and repetitive, and the output is a number or a class — forecasting, churn, credit scoring, anomaly detection. They are cheaper, faster and easier to explain. Use large language models when the input is unstructured language or documents, or when the task requires reading and summarising. Many production systems use both: an LLM reads the invoice, a classical model decides whether the numbers look suspicious.
Why is accuracy a poor headline metric?
Because accuracy hides class imbalance and cost asymmetry. If one transaction in a thousand is fraudulent, a model that flags nothing is 99.9 per cent accurate and completely useless. What matters is precision and recall at the operating threshold your team can actually staff, and the money value of each error type. A false negative that lets fraud through and a false positive that annoys a good customer are rarely worth the same.
What is model drift and how do you handle it?
Drift is the gradual divergence between the world the model was trained on and the world it now runs in — new products, new pricing, changed customer behaviour, a new fraud technique. It is handled by monitoring input distributions and prediction distributions in production, tracking live performance against outcomes as they arrive, and scheduling retraining. In our experience drift, not the original modelling, is what quietly kills most deployed models.
Can machine learning models run on our own infrastructure for data residency?
Yes. Classical models are small and can run inside your own network or region with no external calls, which suits regulated data in the UAE and Saudi Arabia. Language models are heavier, but regional cloud options in the UAE and Saudi Arabia, or self-hosted open-weight models, allow processing to stay within a chosen jurisdiction. The residency requirement should be confirmed for your sector and data type before the architecture is fixed.
How long does a first machine learning project usually take?
Typically a few weeks to establish whether the data supports the prediction at all, and a few months to reach a monitored production deployment with a workflow around it. The modelling is rarely the slow part. Getting reliable access to historical data, agreeing what the target variable actually means, and building the human process around the prediction take most of the calendar time.
Have a prediction problem worth testing?
Tell us what you would do differently if you knew the answer a week earlier. We will tell you honestly whether your data can support it.