Fine tuning, evaluation and distillation, for the cases where a general model genuinely will not do. We will tell you plainly when yours is not one of them.
Fine tuning is the most over-prescribed answer in this field. It is frequently sold to teams whose real problem is retrieval, prompting or data quality, none of which fine tuning fixes. A tuned model built on a broken corpus is a faster way to be wrong.
We will say so before you spend anything. It costs us a project and saves you three.
There are real cases, and they have a shape. Fine tuning earns its cost when the task is narrow and repeated at volume, when the output format matters more than the reasoning, when the domain language is far from anything in the general training data, or when a smaller tuned model can do a hot path at a fraction of the cost and latency of a frontier model.
Most fine tuning enquiries end at one of these, and that is a good outcome.
If the model does not know a fact, tuning is the wrong tool, because tuning teaches behaviour and format far more reliably than it teaches facts. Facts belong in retrieval. We check that the cheap options are genuinely exhausted before recommending the expensive one.
Tuning on a few hundred examples that disagree with each other teaches the model to be inconsistent with confidence. Label quality dominates label quantity. Often the first real piece of work is agreeing what the correct output even is, which is a subject matter question rather than a technical one.
A held out evaluation set, built before tuning starts and never trained on. Without it you have a model that feels better to the person who built it. We build the evaluation harness first, on purpose, because it also tells you whether you needed to tune at all.
A tuned model is a fork. Base models improve, and a general model six months from now may beat your tuned one from today. That is a maintenance commitment, not a one off cost, and it should be a deliberate decision rather than a surprise.
A held out set with agreed correct answers, scored on the dimensions that matter for your task. It becomes the arbiter for every later decision and the thing that tells you when to stop.
Held out evaluation, scoring rubricsTurning your history into training examples: deduplication, leakage checks against the evaluation set, consistency passes, and stratification so rare but important cases are not drowned by common ones.
Dataset curation, leakage detectionLoRA and similar adapter methods rather than full fine tunes in most cases: far cheaper, far faster to iterate, and easy to roll back or swap per use case without retraining a base model.
LoRA, adapters, PEFTUsing a large model to generate supervision for a small one, so a hot path runs at a fraction of the cost and latency. This is often where the real return is, and it is frequently a better answer than tuning for quality.
Distillation, student modelsWhen data residency, latency or unit economics mean inference has to stay inside your own infrastructure, we handle serving, batching, quantisation and the autoscaling around it.
Self hosted inference, quantisationThe tuned model is checked against the evaluation set on every retrain, so a dataset change that improves one category and quietly breaks another is caught before release rather than in production.
Continuous evaluationA thirty minute call. Describe the task and we will tell you honestly whether tuning is the answer, or whether retrieval and prompting get you there for a fraction of the cost.