What a neural network is, in plain terms

Why this matters

• Understanding what a contractor is actually billing for: labelling data, training, or a finished model
• Separating tasks where a neural network beats people and scripts from those an ordinary program handles
• Asking about the error rate and how it is measured, rather than about the model's architecture

What is a neural network, in plain terms

A new hire in a complaints department is rarely handed a two-hundred-page rulebook. Instead, five hundred resolved cases land on the desk. By the end of the week the new hire is sorting fresh letters into folders unaided, though unable to put the rule into words.

A neural network is tuned much the same way. Inside sits a large table of numbers, fitted to the examples: a case is shown, the answer is compared with the correct one, the numbers are nudged. Repeat a few million times.

Hence the defining property. There are no rules inside, only settings derived from examples. So a neural network performs confidently on anything resembling its training data and stumbles on the rare case.

The comparison with the brain has circulated in articles since the forties: McCulloch and Pitts published their paper on nervous activity in 1943, Rosenblatt his perceptron in 1958. For an adoption decision it offers nothing: what has to be counted is examples, errors and hours.

How it works

1. Examples with ready answers are collected. A thousand invoices, each with its fields filled in: supplier, date, amount, line items. This stage eats most of the project timeline.
2. The model works through the examples and adjusts its weights. The weights are those numbers inside. Every error nudges them towards the correct answer.
3. Quality is checked on a held-out portion. There is no single rule for its size: a typical split is 60/20/20; on large volumes the held-out portion is trimmed to 10% or 5%; on small ones up to 30% goes to testing. If accuracy there is noticeably lower, the model has memorised the sample instead of learning.
4. The model answers on live data. This mode is called inference, and that is where the money goes in day-to-day operation.
5. Errors are collected and fed back into training. Operator corrections accumulate and become new labelled data. The method is covered in the piece on fine-tuning.

For text, models are now rarely trained from scratch. A large language model that has already read the internet is taken and tuned with an instruction and a dozen examples. The first five steps then compress into a single evening.

An example from practice

The figures below are an estimated benchmark for a company of this profile, not a report on an actual rollout. Each comes with its method, so it can be repeated on other data.

A wholesale company receives roughly 3,000 order requests a month by email and messenger. Processing one takes six minutes: pull the item codes, check them against the price list, create the deal. The measurement method is simple — a stopwatch on forty consecutive requests, two weeks, three managers, take the median.

Six minutes across 3,000 requests is 300 hours a month. That is the price of the task, the figure against which any contractor's proposal is compared.

Next comes the share of requests where the model fills every field without corrections. On standard forms, after 500 examples have been labelled, the benchmark is 70–85%. It is verified on a held-out hundred requests, by hand, field by field. The remaining 15–30% go to a person, and the time spent on those barely falls.

Savings are calculated from the first share: 300 hours × 0.75 ≈ 225 hours a month. Then comes the question of where those hours go. Until that answer is written down, the savings stay on paper.

What this gives a business

• Tasks involving text and images become countable. Processing a letter, a scan, a handwritten note used to be measured only in people. Now it has a price per operation.
• Peak load stops depending on hiring. The model processes a thousand requests a day as readily as a hundred. People stay on the exceptions.
• Quality becomes a number. The share of correct fields is measured on a held-out sample before launch. The threshold is set by the business: for example, the share of incorrect amounts no higher than 1%.
• Knowledge stops living in one person's head. Labelling examples extracts the rules from experienced staff and pins them down. That part of the work pays for itself even without a model.

When this can be skipped

Where the rules are already written down and do not change, an ordinary program is cheaper. Validating a tax ID against a formula, calculating a discount from a table, routing along a fixed grid — all of this is solved in code, runs without errors and needs no labelled data.

The second case is small volume. At a hundred documents a month, labelling and setup cost more than the hours saved. Here the first move is to tidy up the forms and templates, and part of the work disappears on its own.

The third is a process everyone performs differently. Standardise first, automate second. Process readiness is quickly assessed by a checklist.

What to check

First: what data the model was tested on. The answer "there was a demo on three documents" means nothing. What is needed is a held-out sample of the company's own documents, excluded from training, and the share of correct fields for each document type.

Second: what happens to errors. A model's errors differ from a person's: it will confidently enter a plausible but wrong amount. So amounts, payment details and access rights are checked by ordinary code after the model, rather than left to its judgement.

Third: who owns the labelled data. Labelled examples are an asset that survives a change of contractor and a change of model. Rights to them are fixed in the contract before work begins, along with the export format.