Fine-Tuning in Practice: 5 Real-World Examples

Fine-tuning a general-purpose language model for a specific domain is not a research exercise. It is a practical engineering decision with measurable outcomes. These five examples show what the decision looks like in practice: what problem prompted the work, what the dataset approach looked like, and what results practitioners have achieved.

The common thread across all five examples is not the domain. It is the pattern: a general model that performs adequately on broad tasks but fails to meet the precision standard of a specialized workflow. In each case, fine-tuning solved a problem that prompt engineering alone could not reliably address.

Example 1: Legal Contract Understanding

Legal language has properties that make general-purpose models unreliable for contract work. The vocabulary is precise and jurisdiction-specific. A clause that creates a "best efforts" obligation in US common law is materially different from the same language in an English law contract. General models trained on broad internet text do not internalize these distinctions at the level that legal teams require.

The ContractNLI dataset (Koreeda and Manning, 2021) formalized this problem. It defines 17 clause-level hypothesis labels across NDA documents and establishes a benchmark for document-level natural language inference. Models fine-tuned on this data learn to classify not just whether a clause is present, but what category of obligation or permission it creates and whether it is consistent with a defined standard.

The dataset approach that works in practice combines two sources: a public labeled dataset like ContractNLI to establish baseline performance, and a set of organization-specific documents reviewed by experienced counsel to capture the particular contract styles your firm actually uses. Without the organization-specific examples, a model will perform well on the benchmark but poorly on the actual documents it encounters.

Instruction format matters here. For clause extraction, the training examples should frame each task as a structured extraction: "Extract all limitation-of-liability clauses from the following contract section and classify each as capped, uncapped, or proportional." The output should be structured JSON, not prose, so that downstream systems can process it programmatically. This framing also makes evaluation straightforward: you can compare structured outputs directly against ground truth labels without ambiguity.

A practical constraint legal teams often discover late: training data quality matters more than quantity in legal fine-tuning. A law firm that tried to accelerate labeling by using junior associates without quality review ended up with a model that learned inconsistent categorizations and performed worse than the baseline. The LIMA finding (Zhou et al. 2023, arXiv:2305.11206) applies here: 500 examples reviewed by an experienced attorney will consistently outperform 5,000 examples reviewed by someone who cannot evaluate their accuracy.

Example 2: Medical Question Answering

Healthcare is the domain where the cost of model error is highest. A general model asked about drug interactions will often give a plausible-sounding answer that is either incomplete, outdated, or incorrect in a clinically significant way. The problem is not that the model lacks intelligence. It is that the model was not trained to privilege clinical accuracy over fluency, and it has no mechanism to express appropriate uncertainty when it approaches the edge of its training distribution.

Medical fine-tuning addresses both problems. When a model is trained on high-quality clinical Q&A pairs, it learns not just the correct answers but the register, structure, and level of specificity appropriate for clinical communication. It learns that dosing recommendations require qualification by patient population, renal function, and drug interaction risk. It learns that diagnostic criteria should be sourced to named classifications (DSM-5, ICD-11) rather than stated as general principles.

The MEDFIT-LLM project (Rao, Jaggi, Naidu, IEEE RMKMATE 2025, DOI:10.1109/RMKMATE64574.2025.11042816) demonstrates this for small language models specifically. The research fine-tuned four models (Gemma 2 9B, LLaMA 3.2 3B, Mistral 7B, and Qwen2 7B) on a curated dataset of 6,444 healthcare question-answer pairs using LoRA. The finding that even a 3B parameter model achieves strong domain performance after fine-tuning is significant for healthcare organizations that cannot use cloud APIs due to HIPAA constraints: a fine-tuned small model running on-premise can outperform a general large model on clinical tasks while keeping patient data within organizational boundaries.

The dataset construction approach in medical fine-tuning requires physician involvement at two stages: question curation (ensuring the questions represent real clinical ambiguity, not textbook trivia) and answer review (ensuring answers are clinically defensible and appropriately hedged where uncertainty exists). Datasets built without physician review at both stages tend to produce models with high benchmark scores that fail in practical deployment, because benchmark questions are different in character from the questions real clinicians ask.

One practical finding from medical fine-tuning: the model needs negative examples as well as positive ones. Training examples that show the model how to respond when a question exceeds its reliable knowledge boundary ("This question requires evaluation of specific patient context that I cannot assess") are as important as examples showing correct clinical answers. Models trained only on correct-answer examples learn to answer confidently even when they should defer.

"In healthcare, a fine-tuned small model running on-premise can outperform a general large model on clinical tasks while keeping patient data within organizational boundaries. The tradeoff between capability and compliance is smaller than most teams assume."

Example 3: Code Generation and Completion

Code fine-tuning is the domain where the evidence is most direct. Chen et al. (2021) published one of the clearest demonstrations of fine-tuning value by taking GPT-3 (a general language model with essentially zero code capability) and fine-tuning it on 159 GB of code from public GitHub repositories to produce Codex. The resulting model could solve 28.8% of novel programming problems on a single attempt, a capability that the base model entirely lacked.

The practical application for most organizations is narrower and more achievable. You do not need to build the next Codex. You need a model that knows your internal framework well enough to suggest correct boilerplate without requiring the developer to look up the documentation every time. That task requires a small amount of high-quality training data: examples of correct usage of internal APIs paired with docstrings describing what the code does.

The training data format that works well for code fine-tuning is the instruction-completion pair where the instruction is the docstring or function signature and the completion is the correct implementation. For internal APIs, the most valuable examples are the patterns that appear frequently but are not publicly documented. A new developer spending three hours learning how your team's authentication middleware works translates directly into training examples that will save every subsequent developer three hours.

A specific pattern that has proved valuable in enterprise code fine-tuning: include examples that demonstrate not just correct usage but correct error handling. A model that knows how to call your internal payment processing API but does not know which exceptions to catch and how to handle them will produce code that works in happy-path testing and fails in production. Including error-handling examples in training data requires more effort from senior engineers during dataset curation but substantially improves the usefulness of generated code.

Test generation is a related use case where fine-tuning delivers clear ROI. A model fine-tuned on your codebase can generate test cases for new code that follow your team's testing conventions, use your internal testing utilities, and cover the edge cases that your senior engineers would think to write. The baseline for comparison is not "a model that generates perfect tests" but "developers writing tests manually while under deadline pressure," a baseline that fine-tuned models consistently exceed on coverage metrics.

Example 4: Customer Support and Brand Voice

Customer support is the use case where fine-tuning's advantage over prompt engineering is most practically important. The fundamental problem with using a system prompt alone to enforce brand voice and policy accuracy is that a long, detailed system prompt consumes context window space on every request and still fails to capture the thousands of edge cases that an experienced support agent handles by instinct.

The dataset construction approach for customer support starts with your existing response history. Most organizations have years of customer interaction logs, and those logs contain a natural distribution of inquiry types, edge cases, and policy questions. The filtering task is to select the top-quality responses: the ones that were marked positively by customers, escalated least often, and most accurately reflected policy at the time they were written.

A critical quality consideration: customer support training data tends to become outdated quickly. Responses that correctly stated return policy or pricing from two years ago may now be incorrect. The labeling process must include a review of response accuracy against current policy, not just a review of response quality. A fine-tuned model that has internalized outdated policies will produce authoritative-sounding incorrect answers at scale.

The instruction format that works for customer support is the full inquiry-response pair, not just the response. The model needs to see the full customer message, including the emotional tone, the specific product mentioned, and any account context provided, to learn how response tone should adapt to inquiry type. A frustrated customer who has already contacted support twice needs a different opening than a first-time inquiry about returns. These nuances are learned from examples, not from instructions in a system prompt.

Tone calibration is where fine-tuning provides the most durable advantage over prompt engineering. The model learns from hundreds of examples what "warm but professional" means in practice for this specific brand, across all the situations where that standard needs to be applied differently. The system-prompt approach requires the prompt author to anticipate every situation where tone might drift. The fine-tuned approach learns from the examples themselves.

Example 5: Multilingual and Cross-Lingual Applications

Multilingual fine-tuning addresses two distinct problems that organizations encounter at different stages. The first is quality degradation in lower-resource languages: a general model that produces excellent English output may produce noticeably lower quality in Polish, Thai, or Swahili, because the pre-training distribution contains far more English text. Fine-tuning on target-language examples lifts performance toward the English baseline.

The second problem is domain-specific terminology in any language. A general model knows the common meanings of words in Spanish, but if you need it to handle Spanish-language medical documentation, it needs to learn the specific clinical terminology, abbreviations, and documentation conventions that Spanish-language healthcare systems use. These are not covered by general pre-training even when Spanish coverage is otherwise good.

The FLAN paper (Wei et al. 2022, arXiv:2109.01652) provides the most rigorous evidence for multilingual instruction fine-tuning. The researchers showed that fine-tuning on a mix of tasks that includes multilingual data substantially improves zero-shot cross-lingual transfer, meaning the model can generalize to languages it has limited training data for by learning the task structure in higher-resource languages first.

The practical implication: if you are building a multilingual customer-facing application and your budget allows fine-tuning in only two languages, choose the languages that represent your highest traffic and include a mix of examples that demonstrate the task structure clearly. The cross-lingual transfer effect means the model will generalize better to other languages than if it had been fine-tuned only on those two languages with no multilingual signal.

Data construction for multilingual fine-tuning benefits from a specific strategy: start with high-quality English examples, have them translated by professional translators who are domain experts in the target language, and then have native speakers of the target language review and correct the translations for natural language quality. Machine-translated training data teaches the model machine-translation patterns, not natural language patterns. The quality gap between human-translated and machine-translated training data is particularly large for domain-specific content where machine translation systems have limited training data.

What These Examples Have in Common

Looking across all five domains, three patterns stand out. First, fine-tuning consistently solves the problem of domain-specific precision at a level that prompt engineering cannot achieve reliably. The legal model that correctly classifies obligation types, the medical model that expresses appropriate clinical uncertainty, the code model that knows your internal API: these capabilities require internalized knowledge, not runtime instructions.

Second, the training data quality in all five examples was prioritized over quantity. Legal labeling was reviewed by experienced attorneys. Medical Q&A pairs were physician-reviewed. Code examples came from senior engineers who could evaluate correctness. The teams that cut corners on data review consistently reported worse model performance and more post-deployment corrections than teams that invested in quality at the labeling stage.

Third, all five teams used some form of parameter-efficient fine-tuning (LoRA or QLoRA) rather than full model fine-tuning. The cost and compute advantages of LoRA (Hu et al. 2021, arXiv:2106.09685) made the projects feasible for teams that could not access large GPU clusters. A 7B or 13B parameter model fine-tuned with QLoRA (Dettmers et al. 2023, arXiv:2305.14314) on a single GPU delivered results that justified the investment in every case.

Choosing Your First Domain

If your organization is considering a first fine-tuning project, these five examples suggest a practical selection framework. Choose a domain where you already have a large archive of high-quality human-generated examples (support logs, reviewed legal responses, code with associated tests), where you have a clear evaluation standard (correct answer is definable), and where the business cost of prompt-engineered errors is measurable.

Customer support is often the easiest starting domain for organizations new to fine-tuning: the data is already collected, the evaluation is relatively straightforward (resolution rate, escalation rate, customer satisfaction), and the volume of interactions creates a natural feedback loop for model improvement. Legal and medical domains have higher data quality requirements but also higher payoff for getting the precision right.

The next post in this series covers the other dimension of this decision: when fine-tuning is the right choice versus retrieval-augmented generation, and how to choose between them based on your specific constraints around data freshness, latency, and cost. Read: Fine-Tuning vs RAG: How to Choose.

Or if you are ready to build your first fine-tuning project, the free Fine-Tuning LLMs course walks through dataset preparation, LoRA configuration, and evaluation from scratch.