Teach the model your domain — then prove it got better.
We fine-tune open and hosted models on your own curated data, and we hold every version to a scored evaluation suite. No launch happens because a demo looked good; it happens because the numbers moved on a test set you agreed to.
Fine-tuning changes the model. Evaluation tells you if it helped.
Fine-tuning continues a pre-trained model's training on examples of your own work, so it absorbs your terminology, format, and house style rather than being reminded of them in every prompt. Evaluation is the other half of the job: a fixed set of test cases, scored the same way every run, that shows whether version four is genuinely better than version three or just different.
Data curation
Collect, clean, and label real examplesMethod choice
Full SFT, LoRA, or preference tuningTraining
Runs tracked, checkpoints keptEvaluation
Scored on a held-out golden setDeployment
Shipped behind a versioned endpointMonitoring
Live scoring and drift alertsFine-tuning isn't always the right answer
It's the most expensive of the three levers, so we check the cheaper two first — and say so if they're enough.
Try prompting first
If the model can already do the task and just needs clearer instructions or a few examples, prompt engineering gets you there in days, not weeks — and costs nothing to change later.
Then try retrieval
If the gap is missing knowledge — your policies, product data, recent records — RAG fixes it without touching model weights, and stays current when the source documents change.
Fine-tune for behaviour
When the gap is how the model behaves — output format, tone, domain reasoning, or consistency across thousands of calls — that lives in the weights, and tuning is the tool that reaches it.
Four methods, matched to the problem
Which one we reach for depends on how much data you have, how much you can spend on compute, and whether the target is knowledge, format, or judgement.
Supervised Fine-tuning (SFT)
The workhorse. We assemble prompt-and-ideal-response pairs from your real work, clean out the contradictions, and train the model to reproduce that pattern. Quality of examples matters far more than quantity — a few thousand good pairs beat fifty thousand noisy ones.
LoRA & Parameter-Efficient Tuning
Instead of retraining billions of weights, we freeze the base model and train small adapter layers alongside it. Training costs a fraction of full fine-tuning, adapters are a few megabytes, and you can keep several — one per task or per client — and swap them at request time.
Preference Tuning (DPO / RLHF)
Some qualities are easier to judge than to write down. Here your reviewers pick the better of two answers, and the model learns from those choices — which is how you shape tone, refusal behaviour, and the sense of what a "good" answer looks like in your context.
Distillation & Compression
Once a large model performs well on your task, we use its outputs to train a much smaller one. The student keeps most of the quality at a fraction of the latency and cost — which is what makes high-volume or on-device deployment affordable.
"It feels better" is not a result
Most fine-tuning projects go wrong in the same place: the team tests a handful of prompts by hand, agrees the output looks nicer, and ships. Two months later nobody can say whether the model improved, and the next change is a coin flip.
We build the evaluation set before the first run, keep it frozen, and report every version against it. When a change makes something worse, you find out in the report — not from a customer.
Discuss Your Use Case →How we measure whether a model is actually better
Every tuned version is scored the same way, on the same cases, and the results sit in one place your team can open.
Golden datasets
A frozen set of real cases with reviewed correct answers, built with your subject-matter experts. It's the yardstick every version is held to.
Task metrics
Exact-match, F1, or structured-output validity where the answer is checkable, so a large part of scoring runs automatically on every commit.
LLM-as-judge
For open-ended answers, a scoring model rates each response against a written rubric — calibrated against human ratings first, so the scores mean something.
Retrieval evals
Where a RAG layer is involved, we score faithfulness, context relevance, and answer groundedness separately — so you know whether a failure was retrieval or generation.
Safety & red-teaming
Adversarial prompts, prompt-injection attempts, and PII leakage checks run as part of the suite — because tuning can quietly weaken a base model's guardrails.
Regression suites
The cases you've already fixed get pinned as tests. Any future version that breaks one fails the run, so improvements don't quietly undo each other.
The stack behind our tuning and eval work
Pick a category to see what we build with and why it's in the stack.
From baseline to a version you can trust
Five stages, each ending in a number you can compare against the one before it.
Baseline & eval set
We score the untuned model first and build the golden set with your experts.
Data curation
Assemble, de-duplicate, and review the training pairs — the step that decides the outcome.
Training runs
Several configurations, tracked and versioned, compared on the same held-out set.
Evaluation report
Scores, failure examples, safety checks, and a plain recommendation on whether to ship.
Ship & monitor
Versioned rollout with live scoring, so regressions surface in the dashboard, not in support tickets.
Not sure whether your model needs tuning or better prompts?
Send us the task and a handful of outputs you're unhappy with. We'll tell you which of the three levers will fix it, what data you'd need, and what the evaluation would look like — before any training starts.
Start a Project →Questions teams ask us before starting
Don't see your question here? Send it over and we'll answer it directly.
Fewer examples than most teams expect, but they have to be good ones. A focused format or tone change often lands with 500 to 2,000 reviewed pairs; broader domain reasoning wants several thousand. Contradictory examples hurt more than missing ones, so curation time usually outweighs collection time.
If the gap is missing knowledge, RAG fixes it and stays current when your documents change. If the gap is behaviour — output format, tone, domain reasoning, consistency across thousands of calls — that lives in the weights and fine-tuning is the right tool. Plenty of systems end up using both.
It can, and that's called catastrophic forgetting. We guard against it by mixing in general examples, favouring adapter-based methods that leave the base weights untouched, and keeping general-capability checks in the evaluation suite so a regression shows up in the report.
A frozen golden dataset built with your experts, automatic metrics where answers are checkable, an LLM judge scored against a written rubric for open-ended cases, safety and prompt-injection checks, and a regression set of every bug you've already fixed.
Only after it's been calibrated. We score a sample by hand first and compare it against the judge's ratings; if they don't line up, the rubric gets rewritten before the judge is used for anything that matters. It's a cost-saving tool, not a replacement for human review.