Fine-Tuning in Practice

Fine-tuning means taking a pre-trained model and continuing its training on your own examples, so the behaviour you want stops being something you ask for in every prompt and becomes the model's default. The dominant form is supervised fine-tuning (SFT): you supply prompt → ideal-response pairs, and the training process nudges the weights until the model's outputs match your ideals. Azure OpenAI, Azure AI Foundry, and open-weight stacks all expose this as a managed job — you upload a JSONL dataset, the service trains, and you get a new model deployment.

LoRA and parameter-efficient tuning

Retraining all of a model's billions of parameters is expensive and produces a full-size copy per customer. Parameter-efficient fine-tuning (PEFT) avoids that; the technique to know is LoRA (Low-Rank Adaptation). LoRA freezes the base weights and trains small adapter matrices alongside them — typically well under 1% of the parameter count. The result is a lightweight adapter file you can attach to (or detach from) the shared base model. This is why hosted fine-tuning is affordable, why one GPU can serve many customised variants, and why "LoRA" is a safe one-word answer to "how would you fine-tune this without a GPU cluster?"

What fine-tuning is good for — and not

Fine-tuning excels at behaviour: consistent output format (always emit this exact JSON schema), style and tone (your organisation's voice), domain vocabulary (clinical or legal phrasing used correctly), and reliably following complex conventions without a 2,000-token system prompt on every call — which also cuts per-request cost and latency.

What it is not good for is injecting knowledge. Fine-tuning does not reliably teach the model new facts, and it cannot cite where an answer came from — the training data dissolves into the weights. Volatile information baked in today is stale tomorrow, and the only fix is another training run. Knowledge problems belong to RAG, which is exactly why the LyraLearn Tutor retrieves lesson content instead of being tuned on it.

Data, evaluation, and catastrophic forgetting

Plan for hundreds to a few thousand high-quality examples — quality dominates quantity, and a few hundred excellent pairs beat ten thousand scraped ones. Curating that dataset is usually the real cost of the project.

Two disciplines are non-negotiable. First, evaluate before and after: run a held-out eval set against the base model, then against the tuned one, and only promote if the numbers improve — otherwise you cannot prove the tuning did anything. Second, watch for catastrophic forgetting: aggressive tuning on a narrow dataset can degrade the general capabilities the base model shipped with. Your eval suite must therefore include general-purpose checks, not just your target task. Keep the base deployment available so rollback is a config change, not a rescue mission.