Skip to content

Machine-learning data preparation

The work before training: cleaning, structuring and checking datasets so a model has something honest to learn from.

This is the least visible of the three services and the one that most often decides whether a model works. It covers everything between the data you have and a dataset a model can be trained on honestly: cleaning, structuring, splitting, checking, and documenting what was done.

The reason it matters is that broken datasets do not fail loudly. They produce evaluation numbers that look fine and a model that disappoints in production, which is the most expensive way to find out.

What the work covers

Four kinds of task, usually in this order, though an audit often sends us back a step.

Cleaning and preprocessing
Normalising formats, encodings and units; resolving records that describe the same thing twice; deciding what to do about missing fields rather than silently dropping the rows.
Dataset creation
Assembling a dataset that represents the problem, including the awkward cases. A set built only from easy examples trains a model that is confident exactly where it should not be.
Quality assurance
Re-checking labels against the guideline, measuring agreement, and reporting what the dataset can and cannot support.
Data augmentation
Expanding coverage where classes are thin, with attention to whether the augmentation is teaching a real invariance or just an artefact of how it was generated.

What we look for

The recurring faults. Every one of these produces a model that scores better in evaluation than it behaves in production, which is why they are worth finding before training rather than after.

Split contamination
The same record, or a near-duplicate of it, present in both training and test. The most common cause of an evaluation score that cannot be reproduced in production, and the easiest to miss because nothing looks wrong.
Label noise
Items labelled inconsistently, usually because the guideline was ambiguous rather than because anyone was careless. It sets a ceiling on achievable accuracy that no model change can lift.
Class imbalance
A rare class with too few examples to learn from, sitting behind an overall accuracy figure that looks acceptable because the common class dominates it.
Taxonomy drift
A label set whose meaning changed partway through collection, so early and late records use the same name for different things. Invisible in aggregate, corrosive in training.
Distribution shift
Training data collected under conditions the deployment will not see: one camera, one season, one document template, one writing style.
Missing provenance
Records with no trace of where they came from or when. It makes a dataset impossible to audit later and, where the data concerns people, difficult to defend.

How an audit runs

A dataset audit is usually the cheapest useful thing we can do for a project, and it can be done before any labelling is commissioned.

  1. Inventory

    What exists, in what formats, with what labels, and how much of it. Frequently the first useful output, because the answer is often not what the project assumed.

  2. Structural checks

    Duplicates, near-duplicates, leakage across splits, encoding damage, records that are technically valid and semantically empty.

  3. Label checks

    A sample re-labelled blind against the guideline and compared, so label noise gets a number instead of an opinion.

  4. Findings

    Written up with severity and what each fault would cost if left alone. You decide what to fix; we will say which items we think matter most.

  5. Remediation

    The agreed fixes, applied with a record of every change rather than a silently overwritten dataset.

What you get back

The cleaned dataset with its splits, the guideline it was checked against, and a written record of what changed and why. The record is the part people underestimate: without it, the next person cannot tell a deliberate decision from an accident, and the dataset slowly becomes untrustworthy.

Where we find something that cannot be fixed by cleaning, such as a class that simply has too few real examples, that goes in the findings as a limitation rather than being papered over with augmentation.

Where the data lives

Processing inside Swiss borders is available on request rather than by default, because it depends on which tools a project needs and where the people doing the work are. Ask when you scope the project and we will confirm in writing what is possible for your data before anything moves.

If a project has no residency constraint, saying so early usually widens what we can offer and shortens the setup.

Questions we get asked

Can you audit a dataset without doing the remediation?

Yes, and it is often the sensible first step. The audit tells you whether the dataset can support the model you want. Some projects take the findings and fix things internally, which is a good outcome.

How do you find near-duplicates across a large dataset?

By similarity rather than exact matching, because exact-match deduplication misses the cases that matter: the same document reformatted, the same photograph resized, the same record entered twice with a different identifier. Those are precisely the ones that leak across a split.

Is synthetic data or augmentation a substitute for real examples?

Sometimes for invariances you can describe, such as rotation or lighting. Rarely for a class that is genuinely rare, because augmenting five examples produces variations of five examples rather than knowledge of the class. We will say which case you are in.

Do you work with personal or regulated data?

It depends on the data and the regime, and it is a scoping conversation rather than a yes or no on a web page. Bring the constraint early: it changes who can touch the data, which tools are usable, and where processing can happen.

The others

Most projects touch more than one of these. One partner across all of them means the labelling, the preparation and the application are not three vendors blaming each other.

Data annotation and model feedback

Human-labelled training data across text, image, video, audio and 3D, and the feedback layer for language models: preference data, written demonstrations, rubric scoring, red-teaming.

AI application development

Custom AI-driven applications, taken from concept through to deployment by the team that labelled the data.

Synthetic data generation

Rendered training data built in 3D instead of collected and labelled: for classes that are rare, expensive to photograph, or cannot leave the building.

Tell us what needs labelling.