一个团队收到任务：“让我们的AI更好地处理特定用例。”他们有几种做法：编写更好的提示词；构建RAG系统，向模型提供相关数据；根据所在领域的示例微调模型。
这些方法不能互换，它们解决的是不同问题。选择错误时，你可能耗费三个月和一笔预算进行微调，而真正需要的只是更好的提示词；也可能在微调更简单的情况下构建复杂的RAG基础设施；还可能在模型根本无法完成所需任务时继续纠结提示词。
本文提供一个选择框架，介绍各种方法何时适用、何时应当组合、各自的实际成本，以及生产环境中通常会成功或失败的做法。
每种方法究竟做什么
可以清晰地区分为：
提示词改变模型收到的要求。 你向模型提供更好的指令、示例、格式要求和上下文。模型本身没有变化，改变的是输入。
RAG改变模型看到的数据。 查询时检索相关信息并将其加入提示词。模型无需接受相关训练，就能获得新鲜、具体、动态的数据。
微调改变模型掌握的知识或行为方式。 你使用示例训练模型，修改其权重。模型本身会得到更新。
它们解决不同问题：
- 指令缺口： 如果要求得当，模型能够完成任务。→ 提示词。
- 知识缺口： 模型需要自己不具备的信息。→ RAG。
- 能力缺口： 即使有良好的提示词和上下文，模型也无法可靠完成任务。→ 微调。
知道自己面对哪种缺口，问题就解决了一半。
诊断缺口
当AI无法满足需要时，先问：
一个聪明的人如果只拿到这份提示词，能否完成任务？
如果能 → 属于指令缺口，更好的提示词应该可以解决。
如果不能，向他提供相关参考资料后，能否完成？
如果能 → 属于知识缺口，RAG可以解决。
如果不能，经过大量练习并获得反馈后，能否完成？
如果能 → 属于能力缺口，微调或许可以解决。
如果仍然不能 → 这项任务或许不适合用LLM解决，应重新考虑问题本身。
大多数“AI不好用”的问题都属于指令缺口——更好的提示词即可解决。其次常见的是知识缺口。真正的能力缺口占比最小，却最难解决。
提示词：被低估的手段
提示词成本最低、速度最快，也最常是正确答案。然而团队往往跳过它，直接采用RAG或微调。
只用提示词就能做到：
- 改变语气、格式和长度。
- 应用推理模式（思维链、自我批评）。
- 编码约束（做X，不做Y）。
- 编码政策和防护措施。
- 适应特定用例（不同功能使用不同提示词）。
- 通过少样本示例提高一致性。
仅靠提示词无法做到：
- 让模型知道它原本不知道的事实。
- 让小模型表现得像大模型。
- 从深层次根本改变模型的声音或风格。
- 加快模型推理。
一个合理的原则是：先尝试提示词，至少迭代一周，再考虑RAG或微调。大多数时候，你会发现提示词足以解决问题。
提示词工程投入
集中迭代提示词一周，就能取得显著改进。典型曲线如下：
- 第1天：建立基线，结果一般。
- 第2–3天：调整结构，改进格式，明确指令，取得大幅提升。
- 第4–5天：加入示例和边缘情况，覆盖失败模式。
- 第6–7天：调整语气、约束和细节，完成最后10%的改进。
一周后，你基本已经挖掘出提示词能带来的大部分价值。如果仍不满意，问题很可能属于知识或能力缺口。
优秀提示词是什么样
一份优秀的提示词通常包含：
- 明确的角色和任务。
- 具体的格式要求。
- 1–5个有代表性的示例（如有需要）。
- 明确的约束（该做什么、不该做什么）。
- 边缘情况处理。
- 输出Schema。
通常为5–10个段落。不能太短（规定不足），也不能太长（模型会失去重点）。
RAG：解决知识问题
以下情况适合使用RAG：
- 模型需要自己不具备的事实信息。
- 信息会变化（实时数据、近期事件、特定账户数据）。
- 信息是你的领域或组织特有的。
- 你需要引用或可验证的依据。
以下情况不适合：
- 问题属于指令层面，而不是知识层面。
- 数据很少，可以直接放入提示词。
- 你需要模型以不同方式做事，而不仅仅是知道不同的内容。
实际成本
RAG系统是一项真正的工程项目：
- 构建： 一套严肃的系统需要4–12周（摄取、分块、嵌入、检索、重排序、评估）。
- 运营： 持续更新索引、监测质量、修复问题。
- 基础设施： 向量数据库、嵌入API成本、重排序成本。中等规模系统通常为每月€200–2000。
- 单次查询成本： 高于只使用提示词（还需嵌入、检索和更大的上下文）。通常为经典API调用成本的2–5倍。
对于合适的问题，这非常值得。但与提示词相比，它是一笔不小的投入。
RAG质量需要逐步提升
第一周搭建出的RAG系统通常只有60–70%的质量。要达到生产级质量（85%以上），还需再投入1–2个月：改进分块、加入重排序、修复失败模式、构建评估。
应为此做好计划。不要在第一周就上线，否则用户会非常不满。
微调：当提示词和RAG仍不够时
以下情况适合使用微调：
- 存在明确的能力缺口——即使有良好的提示词和上下文，模型仍无法可靠完成任务。
- 你拥有一批高质量训练示例——极窄范围的LoRA最少需要几百个，更可靠的通用行为通常需要1,000个以上。各项技术的确切门槛请参阅微调文章。
- 你需要一致且范围明确的行为（特定风格、特定输出格式、特定领域）。
- 推理成本或延迟很重要（微调后的小模型可能比通用大模型更便宜）。
以下情况不适合：
- 数据变化频繁（微调模型很快会过时）。
- 尚未充分尝试提示词和RAG。
- 没有良好的评估（无法判断微调是否有效）。
- 任务需要非常新的信息（微调只是一个快照）。
- 你试图教授事实（RAG更适合、更可靠，也能提供引用）。
微调类型
全量微调： 更新模型的全部权重。能力最强、成本最高，需要大量算力，通常只由基础模型实验室使用。
LoRA（低秩适应）： 仅训练一小部分权重，成本低得多。对于范围明确的任务，效果往往可与全量微调竞争。
QLoRA： 量化LoRA，成本更低。大规模应用时质量较低，但足以应对许多任务。
提示词调优 / 前缀调优： 规模更小，只训练软提示词。成本最低，能力有限。
指令微调： 训练模型遵循指令。通常在基础模型层面完成，很少适合最终用户。
RLHF / DPO / KTO： 使用偏好数据（回答A与回答B）对齐模型。改变行为的能力很强，但很难做好。
2026年，大多数开展微调的团队会在强大的基础模型之上使用LoRA。对于多数用例，它在成本和能力之间取得了合适平衡。
实际成本
微调成本取决于方法和规模。以使用5,000–10,000个示例对中等规模开放模型进行LoRA微调为例，典型成本如下：
- 数据准备： 1–4周，通常是工作量最大的部分，包括筛选、清理和格式化示例。
- 训练： 几小时到几天，取决于数据集大小和基础设施，算力成本为€100–2000。
- 评估： 1–2周。构建评估套件，比较微调模型与基础模型。
- 迭代： 通常需要1–3轮，才能达到生产就绪状态。
- 部署： 使用托管API（OpenAI fine-tuning、Anthropic、Vertex）会比较直接，自托管则需要更多工作。
- 维护： 数据更新、基础模型更新或用例变化时需要重新训练。
总计：6–12周工作，算力成本€1K–€20K（取决于规模），并需要持续维护。
这是一笔重大投入，务必确认值得。
微调擅长的场景
微调具有明显优势的具体场景：
严格的格式要求。 输出必须始终遵循特定schema或风格。提示词能做到95%，微调能提高到99%。
专业领域。 医学术语、法律措辞、内部DSL代码。微调可以教授模型你的特定表达方式。
个性 / 声音。 在数千次交互中保持一致声音。提示词可能漂移，微调则会将其固化。
延迟 / 成本优化。 微调后的7B模型可以处理你的特定任务，成本和速度可能优于通用70B模型。在高调用量下，这会带来回报。
行为安全。 微调模型，使其拒绝特定事项或加入具体防护措施，可能比基于提示词的防护措施更稳健。
微调何时会失败
微调效果令人失望的常见原因：
数据不足。 使用100个示例微调通常不会有太大帮助。极窄范围的LoRA有时只需几百个示例；要获得可靠的通用行为，应准备1,000个以上高质量示例。
数据质量差。 输入是垃圾，输出也是垃圾。不一致的低质量示例会产生不一致的低质量模型。
灾难性遗忘。 针对狭窄任务进行重度微调可能损害通用能力。模型更擅长你的任务，却不再擅长其他任务。
知识过时。 微调模型只是一个快照。新信息需要重新训练。对于动态领域，这是一项永久成本。
基础模型的进步超过微调收益。 基础模型已经进步到无需微调也能胜过原来的微调模型。此时你维护的是基于过时模型的微调版本。
评估问题。 没有可靠评估，就不知道微调带来了帮助、损害还是毫无影响。许多“成功”的微调只是安慰剂式胜利。
组合模式
在生产环境中，最好的系统会将三者结合。
组合1：提示词 + RAG（最常见）
这是知识密集型应用的默认方案。
- 精心设计的提示词规定指令、格式和约束。
- RAG提供最新的具体信息。
- 不进行微调，依靠强大的基础模型。
这是2026年最常见的生产模式，适用于大多数用例。
组合2：微调模型 + RAG
适用于同时需要行为专业化和动态知识的情况。
- 通过微调确定声音、格式和领域特征。
- 通过RAG提供最新信息。
- 由提示词进行编排。
例如，针对特定公司的客服声音微调模型，同时对最新政策和文档使用RAG。微调负责保持一致声音，RAG负责不断变化的知识。
组合3：为特定任务使用专用微调模型
对系统的不同环节分别使用不同微调模型。
- 用于路由的分类微调模型。
- 用于摘要的微调模型。
- 用于生成客户回复的微调模型。
- 每个模型都更小、更快、更专门。
适合需要考虑规模和成本优化的场景。每个微调模型做好自己的狭窄任务，由编排层调用它们。
组合4：微调路由器 + 通用模型
对路由器进行微调，使其能够可靠地对查询分类。分类后，再将查询发送给通用模型执行实际任务。
微调模型小、快且职责单一。成本高昂的通用工作由保持最新的通用模型完成。
这样既有经济性（微调模型很小），又有能力（由通用模型处理困难任务）。
决策框架
实用的决策流程：
问题1：当前模型配合优秀提示词，能否解决这个问题？
如果能：编写提示词，迭代一周，然后上线。
如果不能，进入问题2。
问题2：问题是否涉及模型不具备的知识？
如果是：构建RAG，投入数月时间，使其达到生产级质量，并配合优秀提示词使用。
如果不是，进入问题3。
问题3：问题是否与一致的格式、狭窄领域或特定行为有关？
如果是，并且你至少有几百个（最好1,000个以上）高质量示例：进行微调，并结合提示词，必要时也结合RAG。
如果没有这些示例：投入资源收集示例，或者在微调前继续尝试改进提示词 / RAG。
问题4：你是否完成了评估工作，能够确定哪种方法确实有帮助？
每一步都要问这个问题。没有评估，就只是在猜测。
生产实例
以下是几个现实中的组合：
示例1：AI客户支持
设置： 一家SaaS公司的AI客服处理一级咨询。
组成：
- 使用强提示词规定语气、格式和升级政策。
- 对最新文档、政策和工单历史使用RAG。
- 根据公司特定的声音和升级模式进行轻量微调（从历史工单中筛选1,500个示例）。
结果： 自主处理65%的工单。微调负责一致的声音，RAG保证准确性，提示词负责政策。
示例2：法律文档审查
设置： 一款法律科技产品审查合同风险。
组成：
- 使用详细提示词规定检查内容（法律类别、严重程度量表）。
- 对相关判例法和先例使用RAG。
- 不进行微调；由推理模型完成繁重工作。
结果： 纯提示词 + RAG效果很好，因为模型已经接受过法律训练。微调只能带来小幅帮助，投入不划算。
示例3：自定义DSL的代码补全
设置： 一款拥有自有DSL的专业数据工具。
组成：
- 使用带示例的提示词。
- 不使用RAG（DSL足够小，可以放入上下文）。
- 使用10,000个DSL示例进行LoRA微调。
结果： 微调必不可少。没有微调，模型无法可靠生成有效DSL。仅靠提示词和上下文并不够。
示例4：公司内部助手
设置： 面向公司员工的通用助手。
组成：
- 使用强大的系统提示词（声音、行为、拒绝规则）。
- 对公司wiki、Slack和文档使用RAG。
- 不进行微调；公司的“声音”由提示词捕捉。
结果： RAG + 提示词可以处理大多数用例。公司的风格并没有独特到需要通过微调塑造声音。
我们看到的错误
以下是一些资源错配模式：
错误1：一开始就采用微调。 团队听到“我们应该微调自己的模型”，便从这里开始。90%的情况下，提示词 + RAG会更快、更便宜，效果也一样好。
错误2：该用RAG时却跳过。 团队编写复杂提示词，“提醒”模型本应在查询时直接检索的公司信息。直接检索更好。
错误3：没有评估就微调。 “我们微调过了，现在更好。”却没有指标。微调往往毫无作用，甚至造成损害。没有评估，你无法得知。
错误4：微调模型过时。 6个月前GPT-4仍是最佳模型时完成的微调，如今无需微调的前沿模型已经胜过这个旧微调模型。领域发展时，需要重新评估微调模型。
错误5：试图通过微调灌输事实。 团队希望通过微调让模型“了解我们公司”。这种方法效果不好——模型会记住一些事实，同时又编造其他事实。RAG负责事实，微调负责行为。
错误6：提示词迭代时间不够。 两天的提示词迭代只是起点，两周后才能得到真正的答案。
错误7：提示词足以解决，却过度设计RAG。 有时把一份5万token的公司文档直接放入提示词，比RAG更简单，尤其对于小型语料库。
成本和工作量比较
以下是一项典型中型项目的粗略比较：
| 方法 | 工作量 | 成本（一次性） | 成本（单次查询） | 维护 |
|---|---|---|---|---|
| 提示词 | 1–2周 | 极少 | 基础API成本 | 低 |
| RAG | 6–12周 | 基础设施设置（约€1K–5K） | 基础成本的2–5倍 | 中等（摄取、评估） |
| 微调（LoRA） | 6–12周 | 训练算力（约€500–5K） | 基础成本（若模型较小，通常更便宜） | 高（数据、重新训练、评估） |
| 提示词 + RAG | 8–14周 | 基础设施 | 基础成本的2–5倍 | 中等 |
| 三者结合 | 12–20周 | 合计 | 不定 | 高 |
正确选择取决于你的问题和资源。对于大多数团队，提示词 + RAG是理想平衡点——可以显著提升能力，又不必承担完整的微调投入。
要点总结
提示词、RAG和微调解决的是不同问题。要做出正确选择，必须诚实诊断：这是指令缺口、知识缺口，还是能力缺口？
合理的尝试顺序如下：
- 提示词（迭代1–2周）。成本最低、速度最快，也最常足够。
- 如果存在明确的知识缺口，就使用 RAG。投入较大，但边界明确。
- 如果存在提示词 + RAG无法消除的明确能力缺口，就进行微调。成本最高，应最后使用。
- 成熟的生产系统采用组合方案。
成功的团队会诚实判断自己面对哪种缺口，并严谨开展评估。没有评估，就无法判断哪种方法有效；有了评估，路径通常会变得清晰。
大多数“我们需要微调自己的模型”项目，经过仔细分析后都应该改为“我们需要编写更好的提示词并加入RAG”。把微调留给真正需要它的情况。
最终，你会以更快的速度、更低的成本构建更好的系统，而这正是交付生产AI应有的目标。
