Fine-tuning, only when the evidence says so.
Most teams that ask for a fine-tuned model don't need one — better retrieval or a sharper prompt gets there for a fraction of the cost. We start every engagement by testing that assumption against your data, and only move to training when the evidence says so.
What we deliver
- A written recommendation: fine-tune, RAG, or prompt-only — with the evidence behind it
- Dataset curation and labeling support, built from what you already have
- LoRA/QLoRA training on our GPUs or yours, with checkpoints you keep
- An evaluation harness that benchmarks the tuned model against the untuned baseline
Fine-tune, or something cheaper?
The honest diagnostic we run before recommending anything — most engagements resolve in the first column.
Fine-tuning is likely worth it when
- You need a consistent output format, tone, or structure that prompting can't hold reliably at scale
- The task is narrow and repetitive — classification, extraction, or a fixed workflow — with hundreds of labeled examples
- You want a smaller, cheaper model to match a larger one's accuracy on one specific job
- Your domain vocabulary or house style is dense enough that a general model keeps drifting from it
Retrieval or prompting wins when
- The knowledge changes often — a fine-tuned model goes stale the day your documents update; RAG doesn't
- You need answers grounded in specific, citable sources rather than a model's learned generalization
- You don't yet have enough labeled examples to train on — under a few hundred is usually too thin
- The task is broad or one-off, where a better prompt or a bigger base model gets you most of the way there
How the engagement runs
1. Baseline & diagnostic
We run your real tasks through the base model first and measure where it actually falls short — the diagnostic that tells us whether fine-tuning is even the right tool.
2. Dataset curation
We turn what you have — transcripts, tickets, documents, past outputs — into a clean, deduplicated training set, and flag the gaps before they become wasted training runs.
3. LoRA/QLoRA training
Parameter-efficient fine-tuning on an open-weight base model, run on our hardware or yours, with checkpoints and training logs you own.
4. Evaluation & handover
The tuned model is benchmarked against the baseline on your own eval set, not a generic leaderboard, then deployed with monitoring and a documented retraining path.
Engagement tiers
Each tier stands on its own — stop after the Feasibility Sprint if that's what the evidence says.
| Tier | Scope | Duration | Investment |
|---|---|---|---|
| Feasibility Sprint | Baseline evals on your data, a written fine-tune / RAG / prompt-only recommendation, and the dataset gap list | 2 weeks | from $1,500 |
| Pilot Model | Dataset curation, LoRA/QLoRA training, an eval harness, and a benchmark against the un-tuned baseline | 4–6 weeks | from $6,000 |
| Production Rollout | Deployment on your hardware, monitoring, a retraining loop, and team handover | 8–12 weeks | from $15,000 |
Prices are starting points; final scope is confirmed after the Feasibility Sprint.
Common questions
How do I know if I need fine-tuning or just RAG?
If the honest answer is unclear, that's what the Feasibility Sprint is for. Rule of thumb: RAG wins when the knowledge changes often or answers need to cite a specific source; fine-tuning wins when you need a narrow, repeatable task done in a consistent format. Most requests that start as "we need a fine-tuned model" turn out to be retrieval problems — we'd rather tell you that in week one than in month three.
How much data do we need?
For LoRA/QLoRA on a narrow task, a few hundred well-labeled examples is often enough to see a real lift. Under that, the training run tends to memorize noise rather than learn the pattern — the Feasibility Sprint tells you where you stand before you commit to the Pilot.
Do you train on our data, or send it to a third party?
Training runs on our GPUs or yours, on open-weight base models — your data and the resulting weights never go to a third-party fine-tuning API. That matters most for teams already running RAG on-prem for the same reason.
What happens to the model after training?
You keep the checkpoints. Production Rollout includes deployment on your own hardware with monitoring and a documented retraining path, so refreshing the model as your data changes doesn't require calling us back for every update.
Can we start with the Feasibility Sprint and stop there?
Yes — and for a meaningful share of engagements, that is the right outcome. If the evidence says RAG or a better prompt solves it, you leave with that recommendation and the dataset gap list, not a sales pitch for the next tier.
Proven in regulated industries
The same diagnostic-first approach we use across compliance-heavy fields — see how it lands in yours.
Not sure which tier fits?
Book a 30-minute discovery call. We'll run the fine-tune-vs-RAG diagnostic on your actual workflow before recommending anything.