We want a model trained on our company data. Is this the right service?

Usually not, and this is the most important thing on the page. When people say train it on our data they almost always mean answer from our data — and that is retrieval, which is faster to build, cheaper to run, keeps working when a document changes, and lets every answer cite its source. Fine-tuning teaches a model style and shape, not facts. We ask which of the two you actually want before quoting anything.

So when is fine-tuning genuinely the right call?

Four situations, and really only these four. When output has to sit in a specific house voice that prompting cannot reliably reproduce. When the volume is high enough that running a small specialised model instead of a large general one is a serious saving. When the output format is strict and a large model occasionally drifts out of it. And when speed matters enough that a smaller model wins, which is common in voice work.

How many examples do we need?

Realistically a few hundred to a couple of thousand, each one an input paired with the correct output. Quantity matters less than consistency — examples that disagree with each other teach the model to be inconsistent. If you have several thousand cleanly written past examples, this is a much shorter project than if we have to produce them.

What if the trained model turns out to be no better than a good prompt?

Then we tell you that, with the scores from both on the same test set, and you have saved the difference. It is a real outcome and it happens often enough that we build the baseline first specifically so it can happen early rather than at the end. A supplier who cannot report that result is a supplier whose results you cannot check.

Do we need our own GPUs or infrastructure?

Not if a hosted fine-tuning service can be used, which covers most cases and keeps the project inside the lower part of the range. If you need an open model running on your own infrastructure — usually for data residency reasons — that adds a separate infrastructure workstream with its own cost and its own ongoing maintenance.

Can we add new facts by training them in?

No, and attempting it is the expensive version of this mistake. Facts absorbed through training are held loosely and reproduced confidently, with no citation and no way to tell a correct one from an invented one. Facts belong in retrieval where they can be looked up, cited and updated. Training changes how the model writes, not what it knows.

AI & Machine Learning

Fine-tuning, once it is proved you need it

Training a model on your own examples so it writes in your voice, holds a strict output shape, or runs a specialist task cheaply — beginning with a measured baseline that often makes the training unnecessary.

From: $3,000–$30,000
Typical time: 4–12 weeks
Usually bought by: Data-rich clients

What this actually solves

There is a real version of this work and a much more common misunderstanding of it, and the first job is telling them apart. The real version looks like this — a company produces a particular kind of document constantly, in a voice and a structure that a compliance team or an editorial standard has fixed over years, and no amount of instruction gets a general model to reproduce it consistently. Or the same task runs at enormous volume, and moving it from a large general model to a small trained one is a serious change to the monthly cost. Or the output has to hold a rigid shape and occasional drift is unacceptable. Or it has to be fast, which matters most in anything conversational and live.

The misunderstanding is most of the enquiries we get. Train it on our data nearly always means answer questions using our data, and those are entirely different pieces of engineering. Training changes a model's style and its instincts about shape. It does not reliably install knowledge — facts learned that way are held loosely, produced with complete confidence, and cannot be traced back to a source or corrected without retraining. When a company's real need is answering from documents, retrieval does it better, sooner and more cheaply, and we will say so even though it is the smaller sale.

How the work runs

Build a baseline and score it. A properly written prompt, worked examples, and retrieval where the task involves documents — measured against a test set built from your own material. This step exists to try to make the rest of the project unnecessary, and it frequently succeeds. One to two weeks.
Assemble the dataset. Input and correct output for each example, drawn from your archive where you have one, written where you do not. Where examples must be produced, this is the bulk of the project rather than a preliminary. Two to four weeks.
Clean it, which is most of the work. Removing contradictory examples, examples from before a policy or format changed, examples that were unusual one-offs, and anything inconsistent with the standard you actually want reproduced. A single wrong example does more damage than ten right ones repair. One to two weeks.
Split, train, and hold the test set back. Training runs on one portion, evaluation on a portion the model has never seen. On a hosted fine-tuning service this stage is short; on your own infrastructure, using a low-rank adaptation approach that trains a small added layer rather than the whole model, it takes longer and costs more. Three to five days.
Compare against the baseline on the same test set. Same questions, same scoring, both models, side by side — including the case where the trained model is not better. The comparison is the deliverable. Three to five days.
Deploy and set up monitoring. Where it runs, what is logged, and how you would notice quality drifting over the following months. One week.

Typical tooling is a hosted fine-tuning API where one fits, Together or Fireworks for open models, Axolotl or Unsloth where the adaptation is run directly, Hugging Face for dataset handling, and an evaluation harness written for your task specifically, because a generic benchmark tells you nothing about whether this model is good at your job.

What changes the quote

The state of your examples. Several thousand consistent, cleanly written past examples put this at the bottom of the range and turn it into a short project. Having to create the examples — deciding the standard, writing them, reviewing them — is where most of the upper range comes from, and it is a content project more than a technical one.

Where the model has to run. A hosted service is straightforward. An open model on your own infrastructure, usually required when data cannot leave your control, adds a whole infrastructure workstream and an ongoing maintenance responsibility that outlasts the project.

How many rounds it takes. The first trained model is rarely the final one. Each cycle of examine the failures, adjust the dataset, retrain and re-score is real time, and how many are needed depends on how tightly defined the target actually is.

Where these go wrong

Training starts without a baseline. Two weeks later there is a trained model that looks good, and not a single number showing it beats a well-written prompt. Very often it does not, and the company has bought an expensive answer to a question that a carefully constructed prompt already answered. The baseline is not preparation for this work — it is the thing that decides whether the work should happen.

Facts get trained in instead of looked up. The model produces a policy detail, a price or a specification that was in the training examples, states it with total confidence, and has no citation attached because there is nothing to cite. Worse, it will produce a plausible variant of it. Anything that must be correct and might change belongs in retrieval, where it can be checked and updated without retraining anything.

A dirty dataset is used because it is available. An export of every past document looks like a gift and is usually a trap — it spans a period when the format changed, contains one-off exceptions somebody made under pressure, and includes examples that were themselves below standard. The model learns all of it faithfully. Cleaning is the majority of the effort in this service, and any quote that treats it as a preliminary step has misunderstood the job.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

We want a model trained on our company data. Is this the right service?: Usually not, and this is the most important thing on the page. When people say train it on our data they almost always mean answer from our data — and that is retrieval, which is faster to build, cheaper to run, keeps working when a document changes, and lets every answer cite its source. Fine-tuning teaches a model style and shape, not facts. We ask which of the two you actually want before quoting anything.
So when is fine-tuning genuinely the right call?: Four situations, and really only these four. When output has to sit in a specific house voice that prompting cannot reliably reproduce. When the volume is high enough that running a small specialised model instead of a large general one is a serious saving. When the output format is strict and a large model occasionally drifts out of it. And when speed matters enough that a smaller model wins, which is common in voice work.
How many examples do we need?: Realistically a few hundred to a couple of thousand, each one an input paired with the correct output. Quantity matters less than consistency — examples that disagree with each other teach the model to be inconsistent. If you have several thousand cleanly written past examples, this is a much shorter project than if we have to produce them.
What if the trained model turns out to be no better than a good prompt?: Then we tell you that, with the scores from both on the same test set, and you have saved the difference. It is a real outcome and it happens often enough that we build the baseline first specifically so it can happen early rather than at the end. A supplier who cannot report that result is a supplier whose results you cannot check.
Do we need our own GPUs or infrastructure?: Not if a hosted fine-tuning service can be used, which covers most cases and keeps the project inside the lower part of the range. If you need an open model running on your own infrastructure — usually for data residency reasons — that adds a separate infrastructure workstream with its own cost and its own ongoing maintenance.
Can we add new facts by training them in?: No, and attempting it is the expensive version of this mistake. Facts absorbed through training are held loosely and reproduced confidently, with no citation and no way to tell a correct one from an invented one. Facts belong in retrieval where they can be looked up, cited and updated. Training changes how the model writes, not what it knows.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Fine-tuning & model customisation All AI & Machine Learning services