How to Fine-Tune an LLM: An End-to-End Guide

如何微调大语言模型：全流程指南

A hands-on guide to fine-tuning LLMs for the real world. 这是一份面向真实应用场景的大语言模型（LLM）微调实战指南。

Why fine-tune?

为什么要进行微调？

Let me provide a real, personal example. We fine-tuned a 7B parameter model which completely blows foundation models out of the water, but just for this very narrow subtask: Filling out synoptic reporting templates for breast cancer. This is a hellishly difficult task with complex input formats, branching logic, and fields that must appear in a strict order. The LLM needs to discern which of 40 different histologic subtypes trigger which branch of field subsets, perfectly, without hallucination. It’s near impossible to define in a conditional table. One wrong field, and the entire output is invalidated. 让我举一个真实的个人案例。我们微调了一个 7B 参数的模型，它在处理一个非常细分的子任务时，表现完全碾压了基础模型：填写乳腺癌的概要报告模板。这是一项极其困难的任务，涉及复杂的输入格式、分支逻辑以及必须严格排序的字段。LLM 需要准确判断 40 种不同的组织学亚型分别触发哪种字段分支，且不能出现任何幻觉。这几乎不可能通过条件表来定义。只要错一个字段，整个输出就作废了。

When we used aggressive system prompts along with some light RAG, our accuracy (with Claude Opus 4.6) was ~35%. We had to include the entire body of the template in the context, along with a detailed guide when/where to use which field. Roughly 30k tokens, per call. The result? Omitted fields here, unnecessary subsections there, hallucinations, etc. which means that a human would need to manually read and edit the entire document. A no-go. 当我们使用强力系统提示词（System Prompts）配合轻量级 RAG 时，（使用 Claude Opus 4.6 的）准确率仅为 35% 左右。我们必须将整个模板内容放入上下文，并附带详细的字段使用指南。每次调用大约消耗 3 万个 Token。结果呢？这里漏掉字段，那里多出不必要的子部分，还有幻觉等等，这意味着人类必须手动阅读并编辑整个文档。这完全行不通。

After fine-tuning a Mistral 7B model (with QLoRA), our accuracy jumped to ~98%. I was stunned on how effective it actually was. 在微调了 Mistral 7B 模型（使用 QLoRA）后，我们的准确率跃升至约 98%。我被它的实际效果震惊了。

Prompt + RAG: ███████░░░░░░░░░░░░ 35%
QLoRA: ███████████████████░ 98%

We got an improvement of 63 percentage points and completely eliminated our API costs (for this task). Our initial cost estimates for running this at the scale we needed (with the frontier model) would have been ~$320,000. We got there for free.* 我们实现了 63 个百分点的提升，并完全消除了（该任务的）API 成本。我们最初估算以所需规模运行该任务（使用前沿模型）的成本约为 32 万美元。而我们现在几乎零成本实现了目标。*

*Not including the price for fine-tuning, running a local model (which we already do at scale), or measuring the energy usage per API call. *不包括微调成本、运行本地模型（我们已在大规模运行）的成本，或计算每次 API 调用的能耗。

That’s why you fine-tune. Despite the common belief, RAG + System prompts will not solve fine-tuning problems, and they’re everywhere. 这就是为什么要进行微调的原因。尽管人们普遍认为 RAG + 系统提示词可以解决问题，但它们并不能解决微调所针对的那些痛点，而这些痛点无处不在。

When to fine-tune

何时进行微调

❓Do I actually need to fine-tune?❓ ❓我真的需要微调吗？❓

Perhaps. Look for one of the following fine-tuning patterns: 也许吧。请参考以下几种适合微调的场景：

Rigid, Highly Specific Formatting Requirements 刚性且高度特定的格式要求 You need the LLM to output specific formats which are very complex and unforgiving to the occasional hallucination, like a missed or added field. Some notable examples: 你需要 LLM 输出非常复杂且对偶尔出现的幻觉（如漏填或多填字段）零容忍的特定格式。一些典型的例子包括：

Legacy Enterprise Documents: Large companies often have deeply ingrained, idiosyncratic templates with countless conditional branches. 遗留企业文档： 大型企业通常拥有根深蒂固、独有的模板，包含无数条件分支。
Court/Legal Documents: where each jurisdiction has its own format and template. These forms obviously weren’t part of the LLMs input data, and need to be introduced as new knowledge. 法院/法律文件： 每个司法管辖区都有自己的格式和模板。这些表格显然不在 LLM 的训练数据中，需要作为新知识引入。
Medical Forms: They’re complex, often contain redundant information and need to be just right. 医疗表格： 它们很复杂，通常包含冗余信息，且必须绝对准确。

Cost constraints 成本限制 Thousands (or tens of thousands) of tokens in a system prompt which runs on every single API call for every customer inquiry. At scale, that’s real money and latency. A fine-tuned model that has internalized those patterns needs neither. 在每次客户咨询的 API 调用中，系统提示词都要消耗数千甚至数万个 Token。在大规模应用下，这意味着真金白银的成本和延迟。而一个已经内化了这些模式的微调模型，则无需这些开销。

Complex Instructions and Combinatorial Explosions 复杂指令与组合爆炸 System prompts work with simple constraints, but they often break down when rules overlap. If your task involves a massive decision tree (e.g., “If A, do B, but if C and A, do D, unless E is present…”), you may hit the limits of in-context learning. In our case, our combinatorial space exploded with rules that couldn’t reasonably be encoded into a table. Also, remember, context degrades with length. A system prompt with 50 different rules is likely to omit one here or there, invalidating the entire output. 系统提示词适用于简单的约束，但当规则重叠时往往会失效。如果你的任务涉及庞大的决策树（例如：“如果 A 则 B，但如果 C 和 A 则 D，除非存在 E……”），你可能会触及上下文学习的极限。在我们的案例中，组合空间因规则过多而爆炸，无法合理地编码进表格。此外，请记住，上下文会随着长度增加而退化。一个包含 50 条不同规则的系统提示词很可能会遗漏其中某一条，从而导致整个输出失效。

Custom Tone 自定义语调 This isn’t relevant to us, but worth a mention. If you require a specific “brand voice” for your customer service agent, fine-tuning often works better than using system prompts. Also relevant: you need to add a system prompt to every single customer interaction to maintain a specific voice or tone. If your “brand voice” prompt is 2,000 tokens, the costs can add up quickly. 这虽然与我们无关，但值得一提。如果你需要为客服代理设定特定的“品牌语调”，微调通常比使用系统提示词效果更好。此外，你需要为每一次客户互动添加系统提示词来维持特定的语调。如果你的“品牌语调”提示词长达 2000 个 Token，成本会迅速累积。

When to use RAG

何时使用 RAG

A rule of thumb most practitioners use: RAG mostly augments the model’s knowledge. Fine-tuning mostly affects the output behavior. 大多数从业者遵循的经验法则是：RAG 主要用于增强模型的知识，而微调主要用于改变模型的输出行为。

I say mostly, because full fine-tuning can definitely add new knowledge to an LLM, and RAG can (and is often used to) modify the default behavior of an LLM. It’s not black and white, so use your best judgement. 我之所以说“主要”，是因为全量微调确实可以为 LLM 增加新知识，而 RAG 也可以（且经常被）用来修改 LLM 的默认行为。这不是非黑即白的，请根据实际情况做出判断。

Where RAG might be a better choice: 在以下情况下，RAG 可能是更好的选择：

Your knowledge base changes frequently. 你的知识库经常变动。
You only need to augment the behavior rarely. 你只需要偶尔增强行为。
The model needs access to documents, policies, or facts that evolve over time. 模型需要访问随时间演变的文档、政策或事实。
You only have a few hundred high quality training examples. 你只有几百个高质量的训练样本。
You can reliably modify the behavior with a small system prompt. 你可以通过简短的系统提示词可靠地修改行为。

Working solutions tend to end up as a mixture of both. We didn’t completely eliminate system prompts or RAG, we just greatly reduced our reliance on them. 有效的解决方案往往是两者的结合。我们并没有完全摒弃系统提示词或 RAG，只是大大降低了对它们的依赖。

Now, let’s dive into the math so we can understand the mechanics of fine-tuning. 现在，让我们深入探讨数学原理，以理解微调的机制。

The mathematical intuition behind LoRA/QLoRA

LoRA/QLoRA 背后的数学直觉

Before covering any of the mathematical detail of LoRA (Low Rank Adaptation), and its derivatives, conceptually grouped together as “Parameter Efficient Fine Tuning (PEFT)”, we need to understand what fine-tuning actually is doing under the hood. 在介绍 LoRA（低秩自适应）及其衍生技术（在概念上统称为“参数高效微调 (PEFT)”）的数学细节之前，我们需要理解微调在底层到底做了什么。

🤔 Why take time to understand the math behind LoRA/QLoRA 🤔 为什么要花时间理解 LoRA/QLoRA 背后的数学？

Understanding the math behind LoRA is critical to understand if it’s the right strategy for the task at hand. It’s the dividing factor between people who truly understand why/when to fine-tune vs why/when to RAG. I’d recommend not copy-pasting the training script and using the defaults provided, which might work for you right out of the box. Instead, develop a mathematical intuition for what’s happening here. That way, debugging becomes less guess work and more precision engineering. 理解 LoRA 背后的数学对于判断它是否适合当前任务至关重要。这是区分“真正理解为何/何时微调与为何/何时使用 RAG”的分水岭。我建议不要只是复制粘贴训练脚本并使用默认设置，虽然它们可能开箱即用。相反，你应该建立对底层逻辑的数学直觉。这样，调试过程将不再是盲目猜测，而是精密工程。