微调 vs. 提示工程：生产级 LLM 的决策框架

大多数团队在微调的时机上不是太早就是太晚。过早进行微调的团队会花费数周时间在训练管道上，结果却发现一个更好的系统提示就能解决问题。而等待太久的团队则在数百万个重复任务上运行昂贵的 70B 推理，同时接受着一个微调后的 7B 模型能以十分之一的成本击败的准确性。

决策的关键不在于哪种技术“更好”。而在于根据你的具体限制条件——数据量、延迟预算、准确性要求以及任务定义的稳定性——选择合适的工具。下面将介绍如何进行思考。

为什么提示工程应该赢得第一轮

默认的选择几乎总是提示工程，这并非因为它更强大，而是因为它能为你提供最快的反馈循环。在你了解微调是否值得之前，你需要明白你的基线在哪里失效——这需要通过真实的提示运行真实的例子。

提示工程在训练侧的边际成本为零。你可以在数小时内迭代，测试数十种提示变体，并加入少量示例，而无需触及你的基础设施。现代前沿模型（GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro）能力足够强，一个精心制作且包含良好示例的提示通常能让你达到目标质量的 80%。

当你遇到提示更改无法修复的系统性故障时，就到了转折点。如果你在不同的提示变体中看到相同类别的错误反复出现，那就是一个信号。提示工程可以调整模型做什么；但它无法改变模型知道什么或其基本行为方式。

提示工程达到瓶颈的常见信号：

• 领域术语持续被误用：模型知道“CAR”是汽车，而不是临床不良反应。
• 长对话中的格式漂移：模型开始时表现良好，但在 2,000 个 token 后失去了结构。
• 对专有概念的幻觉：模型编造出关于你内部系统听起来 plausible 的细节。
• 规模化时的一致性问题：在提示没有改变的情况下，相同的查询返回不同质量的输出。

微调究竟改变了什么

微调修改的是模型的权重，而不仅仅是它的指令。这是一个有意义的区别：模型“内置”的行为发生了变化，而不仅仅是在上下文中被告知要做什么。

实际意义：

一致性显著提高。 微调后的模型无需在每次调用时被提醒就能遵循格式和行为规则。这在高吞吐量的生产系统中至关重要，你每分钟可能发出数千次调用。

上下文窗口压力减轻。 每个提示中复杂的少量示例会增加 token 数量，从而增加延迟和成本。微调后的模型已经内化了这些示例。你可以将提示缩短，有时能缩短 50-70%，同时保持同等的输出质量。

系统性错误得到纠正。 如果你的基础模型始终为特定区域返回错误的货币格式，无论多少提示都无法可靠地解决。微调可以将这种纠正“固化”到权重中。

领域知识可以被注入。 对于专业领域——临床医学、专利法、量化金融——在特定领域语料库上进行微调有助于模型在该上下文中进行更准确的推理。提示工程可以引导模型指向领域概念；微调则使它们成为模型“原生”的一部分。

关键在于：你需要数据。对于生产结果而言，实际最低要求是大约 1,000 个高质量的标注示例。而对于技术领域有意义的准确性提升，你可能需要 10,000 到 50,000 个示例。

决策的经济学

成本框架的重要性超出了大多数团队的认知。

微调的初始成本高，边际成本低。 在 H100 集群上对 7B 参数模型进行全面微调的成本可能超过 50,000 美元。而在 RTX 4090 上对同一模型进行 QLoRA（量化低秩适应）的成本约为 1,500 美元。训练成本是一次性的。将适配器合并到基础模型后的推理成本不变。

提示的初始成本为零，边际成本高。 你的提示中每增加一个 token，每次调用都会产生费用。一个 2,000 个 token 的系统提示在大量使用时会迅速累积成本。如果你每月运行 1,000 万次推理，一个能让你将提示从 2,000 个 token 降至 300 个 token 的微调模型，每年可能为你节省六位数的开支。

盈亏平衡计算：估算你每月的推理量，计算当前依赖大量提示的方法与使用精简提示的微调版本之间的每次调用成本差异，并向前推算。对于大多数每月达到数百万次推理的生产系统，微调在几周内就能收回成本。

还有一种不太明显的成本：模型蒸馏。在 70B 模型（或前沿模型）的输出上微调 7B 模型，可以让你得到一个在特定任务上表现更接近“老师”的小模型。7B 模型的推理成本比 70B 模型便宜 10 倍。如果你的任务明确且重复性高，这通常是投资回报率最高的微调场景。

LoRA 和 QLoRA：为什么实践计算发生了变化

完整微调——更新所有模型参数——是研究界传统上处理这个问题的方式。但大型模型的完整微调需要巨大的 GPU 内存，可能覆盖通用能力（灾难性遗忘），并且为每个变体生成一个新的完整模型检查点。

参数高效微调 (PEFT) 方法改变了这一点。LoRA（低秩适应）冻结基础模型权重，并且只训练小型适配器矩阵——通常是原始参数的 0.1%。QLoRA 通过 4 位量化进一步扩展了 LoRA，将内存需求减少了 10-20 倍，使得在单个消费级 GPU 上微调 7B 模型或在单个 A100 上微调 70B 模型变得可行。

质量权衡是最小的：LoRA 和 QLoRA 能够恢复通过完整微调获得的 90-95% 的精度提升，同时显著降低了训练成本和时间。

操作优势持续累积：

• 适配器体积小（每个任务 6-8MB），可以进行版本控制、交换和独立部署
• 一个基础模型，多个适配器，支持多租户架构，让不同客户或用例在无需单独部署模型的情况下获得专业化行为
• 避免灾难性遗忘，因为冻结的基础权重保留了通用能力

如果两年前微调的“基础设施要求”让你望而却步，那么 PEFT 方法已经消除了大部分这些障碍。

RAG 的用武之地

微调和检索增强生成 (RAG) 经常被视为相互替代的方案。但它们并非如此——它们解决的是不同的问题。

微调在训练时改进模型的行为和知识。RAG 则在推理时让模型访问其训练数据中没有的信息。

界限在于时间新鲜度。微调适用于稳定的领域知识——专业术语、一致的输出格式、既定程序。RAG 则适用于会变化的信息：当前文档、实时数据、无法固化到权重中的用户特定上下文。

生产系统越来越多地同时使用这两种方法。一个法律 AI 可能会在一个判例法和法律推理模式语料库上进行微调，然后使用 RAG 为每个具体案件检索相关文件。微调提供了领域流畅性；RAG 提供了情境上下文。

一个实用的决策框架

按顺序回答以下问题：

1. 你有 1,000 多个带标签的示例吗？ 如果没有，微调为时尚早。专注于提示工程，并利用现有示例作为少样本演示。在你了解模型在哪里失败的同时，收集更多数据。

2. 提示工程是否遇到了瓶颈？ 首先，用提示工程交付一个产品。衡量它在哪里失败。只有在你能够描述你试图修复的系统性失败模式之后，才投资于微调。

3. 你的任务是否稳定且定义明确？ 微调一个不断变化的目标是昂贵且令人沮丧的。如果你的任务定义每周都在变化，那么重复训练的操作开销会让你筋疲力尽。提示工程适应得更快。

4. 你的推理量是多少？ 计算成本盈亏平衡点。对于每月推理量低于约 10 万次的任务，提示工程的总成本通常更低。每月推理量超过约 100 万次时，微调的经济效益通常占据主导。

5. 你的任务是否需要领域特定的准确性？ 在受监管的行业——临床、法律、金融——系统性错误不仅是质量问题，更是责任问题。微调通常能提供合规性所要求的一致性保证。

6. 你需要一个更小、更快的模型吗？ 如果你目前正在使用大型前沿模型来处理一个明确定义的任务，那么通过微调蒸馏到更小的模型是值得探索的。你将获得更低的延迟、更低的成本，并在需要时具备自托管的能力。

混合现实

从大型语言模型 (LLM) 中获得最大价值的团队并非只选择一种方法，而是将它们层叠使用。在专有数据和领域知识上微调基础模型，然后使用提示工程处理特定任务的变体。添加 RAG 以获取动态上下文。使用适配器从一个基础模型服务多个客户或用例。

这个决策框架在早期最为重要，那时你可能在你理解自己的失败模式之前就倾向于选择微调，或者当你因为训练基础设施看起来令人生畏而停留在次优的提示工程解决方案上时。

从提示开始。衡量它在哪里失败。当失败是系统性的、数据充足且经济效益可行时，进行微调。有了 LoRA 和 QLoRA，"经济效益可行" 的门槛比以往任何时候都低。

正确理解这一点的团队将微调视为一种“毕业”——当你确切地了解你在修复什么以及为什么提示工程无法修复它时，你才算“修成正果”。在此之前不行。