Formats
- Chat-format JSONL that common open-source and hosted tuning tools accept
- Preference data as prompt, chosen, and rejected JSONL
- Evaluation set as JSONL with slice metadata
Teach a small model your work with five thousand right examples.
We write the task down precisely, build training examples from your records and your experts' judgment, freeze an evaluation set before anything is trained, and run a baseline fine-tune so you see the measured difference. The dataset is yours, and it works with whichever model you choose.
The training run is the cheap part now. The file is not.
Fine-tuning has become routine. Adapter methods such as LoRA train a small model on a single GPU, and every major cloud will tune a model from an uploaded file. What remains expensive, and what decides the result, is that file. Gartner predicts that by 2027 organizations will use small, task-specific models at least 3× as often as general-purpose LLMs, and in that world the difference between two companies' models is mostly the data each one brings.
Quality beats volume more often than teams expect. The LIMA study fine-tuned a 65B-parameter model on only 1,000 carefully chosen examples and concluded that a model learns most of its knowledge in pretraining; a small, well-built set teaches it how to respond. For a narrow business task, a few thousand examples that cover the hard cases usually teach more than a hundred thousand that repeat the easy ones.
We build that set, and we prove it worked on cases the model never saw.
Four weeks, in order
The order matters. The evaluation set is frozen before a single training example is written.
Write the task specification (week 1)
Inputs, outputs, schema, what a correct answer looks like, what is out of scope, and how ambiguous cases are handled, with worked examples. Your process owner signs it. It becomes the rubric for everything that follows.
Freeze the evaluation set (week 1)
We set aside held-out cases stratified by type and difficulty, with answers verified by your experts, and decontaminate them against every training source. Nothing from this set is used for training.
Build the training examples (weeks 2–3)
We mine examples from records where the outcome is documented, have experts write demonstrations for gaps and rare cases, and, where licenses allow, distill drafts from a larger model that an expert then corrects or rejects one by one.
Add preference pairs where judgment matters (week 3)
For tasks where tone, caution, or reasoning matters more than format, reviewers produce chosen and rejected responses for the same prompt, with the reason, ready for DPO.
Run the baseline and report (week 4)
We fine-tune one or two open-weight models in the 1B–8B range with LoRA in your environment and compare them against your current approach on the frozen set, with per-slice accuracy and a reading of the failures.
What goes into the training file
| Component | What it is | When we use it |
|---|---|---|
| Examples mined from records | Real inputs paired with the outcome your business recorded | When outcomes are documented and your experts trust them |
| Expert demonstrations | A credentialed reviewer writes the response they would sign | Gaps, rare cases, and procedures newer than your records |
| Distilled examples | A larger model drafts; an expert corrects or rejects each one | To scale volume once the specification is stable and licenses permit |
| Preference pairs | Chosen and rejected responses to the same prompt, with the reason | When judgment, tone, or safety matters more than format |
| Decline and escalate examples | Inputs the model should refuse, flag, or hand to a person | Out-of-scope requests, missing information, regulated advice |
| Held-out evaluation set | Expert-verified cases never used in training | Always |
Distillation is a shortcut with terms attached
Drafting training data with a large hosted model can be fast and good. But some providers' terms restrict using outputs to train other models, and distilled data inherits the teacher's mistakes with full confidence. We check the teacher model's license before using it, record which examples were distilled, and have an expert review every distilled example before it enters the set.
The sprint at a glance
You provide
- Records with outcomes: decisions, coded charts, approved letters, resolved tickets
- Two to four hours a week from a process owner or senior practitioner
- Your deployment constraints: model size, latency, and where it must run
We deliver
- A task specification signed off by your process owner
- Up to 5,000 reviewed training examples, with preference pairs where useful
- A frozen evaluation set with expert-verified answers and a scoring script
- A baseline fine-tune comparison, with adapter weights if you want them
Quality gates
- Evaluation set frozen and decontaminated before training data is built
- Every example traced to its source record or author in the manifest
- A second reviewer on at least 10% of examples, with agreement reported
- Distilled examples individually reviewed before inclusion
Turnaround
Four weeks
Team
An ML engineer, an annotation lead, and credentialed reviewers from your domain
Starts at
$16,500
Four weeks: a task specification, up to 5,000 reviewed training examples, a held-out evaluation set, and a baseline fine-tune comparison.
A fixed-scope sprint
Fine-tuning dataset sprint
Starts at
$16,500
Four weeks: a task specification, up to 5,000 reviewed training examples, a held-out evaluation set, and a baseline fine-tune comparison.
Request a scoped quoteGPU time for the baseline runs in your cloud account and is estimated before we start. Larger datasets, multiple tasks, and iterative retraining are quoted from the sprint's measured cost per example.
Questions about fine-tuning data
Which model should we fine-tune?
We're model-neutral and have no vendor to favor. Most of our sprints target open-weight models from 1B to 8B parameters because they can run in your environment at a predictable cost. The baseline compares two or three candidates on your evaluation set, so the choice rests on measured results.
How many examples do we actually need?
We find out rather than guess. We train on growing subsets, such as 500, 1,000, 2,500, and 5,000 examples, and plot accuracy on the frozen set. If the curve is still climbing at the top, more data pays. If it's flat, better data, usually more hard cases, is what helps.
Should we fine-tune or build retrieval?
Fine-tuning teaches behavior: format, vocabulary, and decision patterns. Retrieval supplies facts that change. Many systems use both, with a small tuned model reading context from a document pipeline.
Who owns the dataset and the weights?
You do. Everything we deliver is yours, and we delete our working copies within 30 days of project close, with a written deletion record.
Can the fine-tuning run inside our environment?
Yes, and by default it does. We use GPUs in your cloud account or on your hardware, and give you the cost estimate before anything runs.
Keep reading
Bring us one messy data source and one question.
Tell us what the data is and what you want a model to do with it. A data engineer, not a salesperson, will reply within one business day with questions and a proposed first step.