Personalised models with your data · when RAG isn't enough
We design and implement LLM fine-tuning (Llama, Mistral, Claude, GPT) for enterprise cases where RAG and prompt engineering don't give the quality, latency or cost you need. With own datasets, rigorous evaluation and deployment in European cloud or on-premise.
We publish this list to qualify together if we fit. If not, we save you time.
We measure current performance with base model + RAG + prompting. If it doesn't reach, we confirm fine-tuning helps. Analyse quality and size of available dataset.
Cleaning, deduplication, augmentation if applicable. Train/val/test split. Evaluation rubric definition with domain experts. Objective baseline.
Fine-tuning on GPUs (cloud or own). Iteration with hyperparameters and dataset variants. Blind evaluation against baseline. Regression detection.
Deployment in your infra (on-prem with Ollama/vLLM, or managed cloud). Production quality monitoring, drift alerts, retraining plan.
Invented cases with metrics consistent with our real ranges.
Model specialised in Spanish tax jurisprudence with firm's own format. On-premise to comply with professional secrecy. Prior RAG reached 82; with fine-tuning we reach 94.
GPT-5 API replaced by Mistral 7B fine-tuned with 8,000 historical labelled applications. Performance equivalent to 1/3 cost per token, sub-500ms latency.
Dataset of 3,500 technical sheets with engineer-labelled fields. Fine-tune Qwen 2.5 32B on-prem. Reduces human review and accelerates cataloguing.
Short answer: almost always RAG + prompt engineering + few-shot reach sufficient results with much less cost and complexity. Fine-tuning only pays off when: (1) you've exhausted RAG + prompting and don't reach required quality, (2) volume is so high that reducing cost per token with smaller model pays back in months, (3) you have clean dataset of 500+ examples representing the real task well.
If you're in early AI phase in your company (pilot, first months), 99% of the time the answer is "not yet". Fine-tuning is an optimisation, not a starting point.
Depends on task and base model. Ranges we see working: 500-2,000 examples for format/style/tone tasks with LoRA on large models (Llama 70B). 3,000-10,000 examples for tasks where the model needs to "learn" new knowledge or complex schemas.
More important than volume is quality. 1,000 clean expert-labelled examples beat 20,000 noisy examples. Before increasing dataset, increase quality.
If you don't have labelled data, consider synthetic data: generating examples with large model and refining with human. Moderate cost and usually works well for bootstrap.
Both are possible. Fine-tune on open-source (Llama, Mistral, Qwen) has advantages: total control, on-premise deployment, portability, no usage limits. Predictable operating cost.
Fine-tune on Claude via Bedrock or GPT via OpenAI API has advantages: managed infrastructure, superior base quality on many tasks, simpler update to new versions. Trade-off: operating cost depends on provider, less control, more lock-in.
Our per-case recommendation: for tasks where frontier quality is critical and volume isn't massive, fine-tune the commercial model. For high volume or on-premise/regulatory requirements, fine-tune open-source.
Yes, each base model is different and the fine-tune is tied to the specific model. When a new better base comes out, decide: keep current fine-tune (cheap but may fall behind), redo fine-tune on new base (moderate cost, better quality), or return to prompting + RAG on new base (often new base without fine-tune already matches old with fine-tune).
Strategic recommendation: fine-tune is a moment-specific optimisation. Every 12-18 months reassess if it still makes sense or if the new base model already justifies replacing. Document dataset and evaluation well — it'll save you months when it's time to retrain.
Free 30-min diagnosis with architecture, timing and budget estimate for your specific case.