LLM Training & Fine-Tuning Services

For a language model that fits your domain and Turkish tasks, we compare prompting, retrieval (RAG) and fine-tuning by measurement, and train the model when it is justified.

What is LLM training, and when is fine-tuning needed?

LLM training means further training a large language model with additional data so it fits a particular domain, language or task better. In practice, organisations rarely need to train a model from scratch; what they need is fine-tuning an existing base model, so it learns a specific format, terminology or decision rule from your examples. Pre-training from scratch requires enormous data and compute and is rarely the right choice for a business project.

Fine-tuning is not the answer to every problem either. If knowledge must stay current and cite sources, RAG fits better; often a well-designed prompt with examples is enough to start. That is why we begin with a base model and a test set that represents the real task, and move to training only when simpler routes fall short. From Ankara, Hatson Tech develops language model solutions adapted to Turkish tasks for organisations across Türkiye.

Which method fits when?

Method	When it fits	Watch out for
Prompt design and examples	The task is clear and the model is already close	Long prompts raise cost and latency
RAG	Knowledge changes and sources must be cited	Quality depends on retrieval and data preparation
Fine-tuning (LoRA)	Format, tone, classification or domain language must be consistent	Needs good labelled examples and an evaluation set
Full fine-tuning	A very specialised task with large data and hardware	High cost and maintenance
Training a small model	A narrow task, low latency, on-device or in-house	Limited general knowledge and reasoning
Pre-training from scratch	Almost never in a business project	Enormous data and compute

We compare RAG and fine-tuning in RAG vs fine-tuning, and cover the cost side in the economics of fine-tuning.

What are LoRA and QLoRA?

LoRA (low-rank adaptation) is a fine-tuning method that freezes the model's billions of parameters and adds small "adapter" layers made of far fewer parameters. The LoRA paper shows that this greatly reduces the number of trained parameters and the memory needed. QLoRA compresses the base model to 4-bit precision and applies LoRA on top, so fine-tuning a large model can fit on a single powerful GPU. The practical result for organisations: fine-tuning no longer has to be a large infrastructure project, and separate adapters can be trained for different tasks on the same base model.

How is fine-tuning done?

Define the task and success measure: Inputs, expected outputs, acceptable errors and costly error examples are written down.
Set aside an evaluation set: A test set that represents real use and is never seen in training. For Turkish, it should include spelling and inflection variants, abbreviations and mixed terminology.
Measure the baseline: The chosen base model is tested with prompts and examples. Often this step shows that fine-tuning is not needed.
Prepare the data: Data rights and personal data are checked, and duplicates and conflicting labels are cleaned (data preparation).
Run a small experiment: A candidate model is trained with LoRA on limited data and a short run, then compared with the base model on the same test set.
Decide and scale: The gain is weighed against cost and latency; if it is enough, data and training are scaled up.
Deploy and monitor: The model version, training data and evaluation result are recorded; tests re-run whenever data or the base model changes.

Example: classifying support requests

Suppose a company wants to sort incoming support requests into 12 categories and has 3,000 labelled past requests. Of these, 600 are set aside for evaluation and never used in training. A baseline with a general model, a prompt and examples reaches 78 percent accuracy on the test set, with most errors between two similar categories. Using the remaining 2,400 examples, a smaller model is fine-tuned with LoRA and reaches 91 percent on the same 600 requests. Because the small model runs in-house, request data does not leave the organisation and the cost per request falls.

The decision is not based on the accuracy gap alone: when categories change, the model needs retraining, and that maintenance effort is counted. The numbers in this example are hypothetical; real results differ for every dataset and are only known by measuring.

Turkish LLMs and local LLMs

Because of its agglutinative structure, inflection and corporate language mixed with English terms, Turkish challenges models more than English does. A model's general benchmark score does not show how well it handles Turkish in your task, so we compare models on your own Turkish test set (Turkish AI and NLP). A local LLM runs on the organisation's own servers instead of a cloud API. With open-weight models and LoRA adapters, data can stay inside the organisation and cost can stay predictable. We compare the options in our articles on open and closed models, small language models and in-house AI.

Evaluation and quality

A fine-tuned model is only as reliable as its evaluation set. We report results not just as overall accuracy but by category, by costly error type and side by side with the base model. When the model or data changes, the same tests run again; if there is a regression, the new version does not ship. We describe our approach in AI evaluation.

Data rights, security and privacy

Information taught to a model cannot easily be removed later. So if training data contains personal data, masking or removal happens before training, and the purpose and legal basis for using the data are set up front. Training and inference can run in-house, in a private cloud or in the cloud; the choice affects cost, latency and transfer rules under KVKK, Türkiye's data protection law.

What drives cost and timeline?

How clear the task is and whether an evaluation set already exists.
The amount and quality of labelled data, and any labelling needed.
The size of the base model and the training method (LoRA, QLoRA, full fine-tuning).
Hosting: a cloud API, a private cloud or in-house GPUs.
Latency and concurrency expectations.
How often the model will need retraining.

What to bring to a scoping call

A clear task, sample inputs and expected outputs, known failure examples, expected volume, data sensitivity and hosting constraints are enough to begin. The decision to train a model is made after the baseline measurement and data review.

Frequently asked questions

What is LLM training?

It is further training a large language model with additional data so it fits a particular domain, language or task better. In business projects this usually means fine-tuning an existing base model, not training from scratch.

What is fine-tuning?

Further training an existing language model on your examples so it learns a specific format, terminology or decision rule. RAG fits when knowledge must stay current; fine-tuning fits when consistent behaviour and format are needed.

What is LoRA fine-tuning?

LoRA freezes the model's main parameters and adds small adapter layers with few parameters. It greatly reduces the number of trained parameters and memory needed; with QLoRA, large models can be fine-tuned on a single powerful GPU.

How much data does fine-tuning need?

It depends on the task. Narrow format or classification tasks can often start with hundreds to a few thousand good examples. We measure the real need with a small experiment and a held-out test set; data quality matters more than quantity.

Can a local LLM run on our own servers?

Yes. Open-weight models and LoRA adapters can run on your own servers or in a private cloud, so data does not leave the organisation; the hardware needed depends on model size and load.

Which LLM should we choose for Turkish?

General benchmark scores do not show Turkish performance on your task. We compare candidate models on your own Turkish test set for accuracy, cost and latency, and choose from there.