Insights

Three pieces on the parts of applied machine learning that quietly decide whether a project succeeds. Written by the people doing the work.

Evaluation9 min read

Why your model's accuracy is probably meaningless

A classifier that predicts the majority class on an imbalanced dataset can report 97 percent accuracy while being entirely useless. This is not an edge case. It is the default state of most business datasets, where the event you care about, fraud, churn, machine failure, is rare by definition.

The problem with a single number

Accuracy answers one question: what fraction of predictions were correct. When ninety seven percent of your transactions are legitimate, predicting 'legitimate' every time scores ninety seven percent and catches no fraud at all. The metric is not lying. It is answering a question nobody should have asked.

What to ask instead

For a rare event, precision and recall carry the information. Precision asks: of the cases we flagged, how many were real. Recall asks: of the real cases, how many did we catch. These trade against each other, and the correct balance is a business decision, not a technical one. A fraud team with capacity to investigate fifty cases a day needs high precision. A cancer screening programme needs recall, because the cost of a miss is not symmetric with the cost of a false alarm.

The interval nobody prints

A metric computed on a test set of two hundred examples has an uncertainty of several percentage points. Reporting 94.2 percent implies a precision the data cannot support. We report intervals because the alternative is to convey false confidence, and a decision made on false confidence is worse than one made on acknowledged ignorance.

If you take one thing from this: ask what the model scores on the class you actually care about, and ask for the interval.

Data7 min read

The target variable is hiding in your features

Leakage is the most expensive failure in applied machine learning, and it is almost always discovered after deployment, when the model that scored 0.98 in development scores 0.61 in production.

What leakage looks like

A churn model with a feature called days_since_last_login, computed after the customer churned. A loan default model that includes the collections_flag, which is only set once the loan has defaulted. A hospital readmission model containing a discharge code assigned at readmission. In each case the model has been handed the answer and rewarded for repeating it.

Why it survives review

Because it produces exactly the result everyone hoped for. A model that scores 0.98 does not attract scrutiny. Nobody investigates good news. The check has to be structural: before modelling, every feature is examined for whether it could have been known at the moment the prediction would need to be made. That question, asked once per column, prevents most of this.

The temporal discipline

Split by time, not at random. If your test set contains data from before your training set, you are asking the model to predict the past from the future, which it will do very well and which teaches you nothing. Real deployment always predicts forward. Evaluation should too.

Before any modelling, ask of every feature: would I have known this at prediction time? Most leakage dies to that one question.

Language models6 min read

Most problems do not need a fine tune

Clients arrive asking to fine tune a large language model. In the overwhelming majority of cases the correct answer is retrieval over their documents, careful prompting, and an evaluation harness, at a fraction of the cost and with far better traceability.

What fine tuning is actually for

Fine tuning teaches a model a style, a format, or a narrow behaviour. It is poor at teaching facts, and facts are usually what the client wants. A fine tuned model asked about your product catalogue will confidently invent products, because it has learned the shape of your answers rather than their content.

Retrieval, and citing sources

Retrieval augmented generation puts the relevant document in front of the model at question time. The model summarises what it can see, and can be made to cite it. When it has nothing relevant it can be made to say so, which a fine tuned model cannot do because it does not know what it does not know. Traceability is the point: a business answer that cannot be traced to a source is not usable in a regulated setting.

Measure the hallucination rate

Before deployment, run the system against questions whose answers are known and questions whose answers are absent from the corpus. Count how often it invents. That number exists whether or not you measure it, and it belongs in your risk register either way.

Try retrieval first. Fine tune only when you have measured retrieval and can name what it fails at.

On this writing

Written by practitioners, not a content team

Every article here was written by someone who has made the mistake it describes. None of it is generated. If you disagree with something on this page, we would like to hear it.

Argue with us

Next step

Send us your data problem. We will tell you whether it is one.

A working data scientist reads every enquiry. You will get an honest read on whether your data can support the model you have in mind, before anyone quotes you a number.

Talk to a scientist Read the case studies