微调 (Fine-tuning)、检索增强生成 (RAG) 和普通提示 (prompting) 分别为大语言模型 (LLMs) 解决不同类别的难题。选错工具会浪费 GPU 算力、推高云端账单，且依然无法为用户提供正确的答案。以下是一个分步框架，旨在帮助开发者决定哪种工具最适合其用例，以及在需要时如何将它们结合使用。
三种杠杆
| 变化内容 | 工作原理 | 典型用途 |
|---|---|---|
| RAG | 在推理时向模型上下文添加外部事实 | 更新价格、提取最新的政策文档、引用私有数据 |
| Fine-tuning | 调整模型的内部权重以改变风格、格式或可重复的行为 | 一致的语气、复杂的输出结构、高吞吐量的分类任务 |
| Prompting | 通过清晰的指令和示例来塑造模型的即时响应 | 通用推理、快速原型设计、在几天内交付功能 |
在任何项目的开始，核心问题是：缺口是知识层面的，还是行为层面的？ 知识缺口意味着模型根本没有正确的知识；行为缺口意味着它知道事实，但无法以你需要的方式表达出来。
当问题是知识缺口时 —— 选择 RAG
如果模型产生幻觉、返回过时的数字或无法指出来源，问题在于信息缺失或陈旧。RAG 通过在运行时将正确的文档或数据点拉入提示词中来解决这一问题。
- 当事实频繁变化时使用 RAG —— 例如库存水平、市场价格或监管表格。
- 当你必须为合规或审计目的提供引用或可追溯性时使用。
- 用于无法暴露给公共模型的私有语料库；检索层可以将数据保留在你的防火墙之后。
更新文档很容易，重新训练模型很难。
当问题是行为缺口时 —— 进行微调
如果模型已经掌握了正确的事实，但交付的格式、语气错误或结构不一致，则需要塑造其内部行为。微调会重写模型的权重，使所需的风格成为默认设置。
- 非常适合品牌特定的语调、法律语言或任何必须遵循严格模板的输出。
- 适用于高容量、重复性的任务，例如批量分类，因为每次调用产生的少量提示词成本累积起来会非常可观。
- 可以缩短提示词，减少 Token 使用量，从而降低推理成本。
一个常见的错误是仅仅为了教模型事实而进行微调。这会浪费计算资源，且仍会让模型容易受到未来数据漂移的影响。事实属于检索层；微调属于行为层。
当问题是指令缺口时 —— 从提示开始
提示工程是测试模型是否能解决任务的最廉价、最快的方法。清晰的指令、少样本 (few-shot) 示例和思维链 (chain-of-thought) 提示通常可以在不改变模型的情况下弥补差距。
- 在投入更昂贵的解决方案之前，用它来探索“好的”答案是什么样的。
- 将其应用于重推理任务、头脑风暴或任何需要快速周转的场景。
- 如果你可以通过精心设计的提示词获得满意的结果，就可以避免数据收集、模型训练或检索流水线的开销。
如果你还没有尝试过清晰的提示和少量示例，那么你还没有准备好投资微调或 RAG 基础设施。
决策流程
根据以下清单评估你的用例。遇到第一个“是”时停止，并应用该技术。如果符合多个条件，请叠加解决方案。
- 你是否尝试过使用明确的指令和少样本 (few-shot) 示例进行提示？ 否 → 从提示开始。
- 失败是否源于事实缺失或过时，或者你需要引用来源？ 是 → 添加 RAG 层。
- 失败是否源于风格、格式不一致，或者需要高吞吐量、可重复的输出？ 是 → 微调模型。
当知识和行为缺口同时存在时，请结合 RAG 和微调：先检索正确的事实，然后让微调后的模型以所需的风格进行呈现。
衡量成功
不要依赖“感觉”。构建一个包含核心输入和预期输出的小型、具有代表性的评估集。将同一套评估集应用于每种候选方案——仅提示词 (prompt only)、提示词 + RAG、提示词 + 微调 (fine-tune)，或全栈方案。对比准确率、引用质量、Token 成本和延迟。数据会告诉你哪一层真正增加了价值，而哪一层只是不必要的开销。
及早选择正确的杠杆可以节省时间、金钱并减少挫败感。先从提示词入手；当事实性信息成为瓶颈时，加入检索 (retrieval)；当行为模式成为瓶颈时，进行微调 (fine-tune)。通过测量和迭代，你就能避免“在错误的问题上堆砌 GPU 算力”这一常见陷阱。