Your own environment
An open model with a LoRA adapter runs on your infrastructure, so data never leaves the company perimeter.
Fine-tuning models for company needs
Learn when fine-tuning and LoRA add value beyond prompts and RAG, how to prepare datasets and measure model quality before and after deployment.
Our clients
Clients and partners
How we choose the method: prompt -> RAG -> fine-tuning
Use the cheaper method first, and fine-tune only when its limits are proven
Lower-cost methods
Prompt and rulesdays
RAG on your documentsknowledge base with source links
Verification
Evals on real tasksquality metrics on a validation set
If the limit is proven
LoRA fine-tuning for an open modeldataset from your data
When fine-tuning is justified, and when it is not
When it is justified
- The model should speak in your domain's terminology and style: legal phrasing, technical regulations, industry jargon.
- Classification, extraction, and labeling on your data, where prompts and RAG consistently fail to reach the required accuracy.
- You need a stable response format for integration: the model must answer strictly by schema, not however it turns out.
- The model runs locally in a closed environment, and it is important to squeeze quality out of a compact open model.
When it is not needed
- Knowledge changes every week, so fresh facts are a RAG task, not a model weights task.
- If there are too few real examples, fine-tuning on dozens of input-to-answer pairs will not measurably improve quality.
- The task can be solved with a prompt or a few in-context examples, so the cheaper method has not been exhausted yet.
- If you need a universal chat without a measurable quality metric, there is no basis for defining an acceptance criterion.
What we do: datasets, LoRA adapters, metrics
-
01
Process breakdown and evals
We define the task and build a validation set of real examples. We measure the baseline quality of the prompt and RAG, which becomes the starting point.
-
02
dataset from operational data
We collect and clean input-to-reference-answer pairs from documents, conversations, and business systems. Personal data is anonymized before being passed to the model.
-
03
LoRA fine-tuning for an open model
Adapters instead of full fine-tuning: faster and cheaper, the process is reproducible, and the dataset and weights remain the company's property.
-
04
Measure before and after
The same metric on the same validation set. Improvement on evals is the acceptance criterion, not a subjective "it looks better."
-
05
Production handoff
The model is deployed in your environment, and your team gets a process for updating the dataset and retraining it again - without depending on us.
Assess where AI can deliver impact in your process
Where the model lives: your environment and Federal Law 152
LLM gateway for GDPR
If part of the traffic goes to external models, LLM gateway anonymizes personal data before it reaches the model and returns the real values in the response.
RAG alongside, not instead
Fine-tuning handles style, format, and domain skills; fresh facts are retrieved by RAG knowledge base with a source link.
Cases
AI implementation cases
Custom Akeneo modules for delivery
Learn more
OSNO-VA: AI accountant
- Built an AI platform
AI ingredient recognition by barcode
- Processing sped up from 30 minutes to 2 per batch of 10 images
- Recognition accuracy for composition is 80-95%
FAQ
Frequently asked questions about model fine-tuning
Do we need fine-tuning right away?
Almost never. Start with the prompt, then RAG - fine-tuning is introduced only when their limits have been proven on evals, meaning measured on a control set, not assumed. It is the cheapest way to avoid spending budget on a task that can be solved with a couple of examples in context.
When is fine-tuning justified?
When the model needs to speak in your domain's terminology and style - legal wording, technical regulations, industry jargon. When classification, extraction, or labeling on your data consistently falls short of the required accuracy. When you need a stable response format for integration, not whatever comes out. And when the model runs locally in a closed environment and it is important to squeeze quality out of a compact open model.
When is it definitely not needed?
When knowledge changes every week: fresh facts are a RAG task, not a model-weights task. When there are too few working examples: quality will not measurably improve on just dozens of input-to-answer pairs. And when you want a "chat about everything" without a measurable metric, there is simply no basis for defining an acceptance criterion.
Where does the dataset come from, and what happens to personal data?
We collect and clean input-to-reference-answer pairs from your documents, conversations, and business systems. Personal data is anonymized before being sent to the model. If part of the traffic goes to external models, anonymization is handled by an LLM gateway, which restores the real values in the response.
Who owns the result?
We use LoRA adapters for open models: this is cheaper than full fine-tuning and reproducible, while the dataset and weights remain the company's property. Along with the model, the team gets a process for updating the dataset and retraining it so they can continue without us.
How is the work accepted?
By measuring before and after: the same metric on the same control set used to evaluate the prompt and RAG. Improvement on evals is the acceptance criterion, not a subjective "it got better," and it is defined before the project starts.
Process-by-process AI automation
One process - one price - payment after delivery
Fine-tuning is also an AI implementation process: we define the acceptance criterion before launch as quality metrics on a validation set, and payment is due after the process is accepted. See the pricing reference on the page pricing and payment models; calculate the economics for your volumes in AI implementation calculator.
- Acceptance criterion defined before launch
- Payment after acceptance
- The dataset and weights are yours
