定制大模型的三种方式——Prompt、RAG、Fine-tuning 怎么选

问题放在前边：如果我有一个具体需求，该用什么方式来让模型满足它？

一、为什么需要”定制”模型

通用大模型（GPT-4o、Claude、通义千问）是在互联网公开数据上训练的，开箱即用有几个明显的限制：

●不知道你公司内部的知识（产品文档、规章制度、历史数据）

●不了解你的业务场景和专业术语

●说话风格和你的品牌调性可能不符

●对于高度专业化的任务效果有限

当通用能力不够时，主流方案有三种：Prompt Engineering、RAG、Fine-tuning

二、三种方式分别是什么

Prompt Engineering（提示词工程）

核心思路：不改变模型本身，通过精心设计输入来引导模型输出符合预期的结果。

┌──────────────┐         ┌──────────────┐
│  精心设计的   │  ─────▶ │   通用大模型   │  ─────▶ 符合预期的输出
│   Prompt     │         │  （不变）     │
└──────────────┘         └──────────────┘

类比：同一个员工，大家给他不同的工作说明书，他的输出就不同。不需要”换”一个员工，只需要写好说明书。

普通调用：
  用户：帮我写一封邮件
  结果：生成一封通用邮件，风格随机

加了 Prompt Engineering：
  System: 你是极技 AI 的客服专员，语气专业友好，
          邮件结尾必须包含客服热线 400-xxx-xxxx，
          不超过 150 字。
  用户：帮我写一封感谢用户续费的邮件
  结果：符合品牌风格、有固定结构、长度受控的邮件

RAG（检索增强生成）

核心思路：不改变模型，但在每次调用前，先从外部知识库里检索相关内容，动态注入 Prompt，让模型”临时学到”你的私有知识。

类比：开卷考试。考生（模型）没变，但每次答题前先翻到相关资料页，回答就会更准确。

RAG 的完整流程上节课讲过了，这里不重复。关键是：知识存在外部，随时可以更新，不需要重新训练模型。

Fine-tuning（微调）

核心思路：在已有大模型的基础上，用自己的数据继续训练，改变模型的权重参数，让模型”内化”新的知识或行为模式。

┌──────────────┐                    ┌──────────────────┐
│  通用大模型   │  + 你的训练数据 ──▶  │  定制化微调模型     │
│  （基座）     │  （问答对/示例）      │  （权重已改变）    │
└──────────────┘                    └──────────────────┘

类比：给员工做专项培训，培训完他的能力本身发生了变化，不需要每次都带着参考资料。

Fine-tuning 需要什么：大量高质量的标注训练数据（通常数百到数千条问答对）、较高的计算资源（GPU）、专业的 ML 工程知识、持续的维护成本（数据更新要重新训练）。

三、三种方式全面对比

维度	Prompt Engineering	RAG	Fine-tuning
实现难度	低	中	高
开发成本	极低	中等	高
知识更新	即时生效	即时生效	需重新训练
知识容量	受上下文窗口限制	理论无限	烘焙进参数（有限）
模型是否改变	否	否	是
可解释性	高（能看到 Prompt）	高（能看到检索到的内容）	低（黑盒）
适合场景	行为控制、格式约束	私有知识问答	风格迁移、专业术语内化

四、什么时候用哪种

决策流程

你的需求是什么？
│
├─ 控制模型的行为、风格、格式？
│   → 用 Prompt Engineering 就够了
│
├─ 需要模型知道你的私有/实时知识？
│   │
│   ├─ 知识量大、会频繁更新？
│   │   → 用 RAG
│   │
│   └─ 知识量小、相对固定？
│       → 也可以直接塞进 System Prompt（最简单）
│
└─ 需要模型从根本上改变说话风格或掌握高度专业技能？
    │
    ├─ 有大量标注数据 + 有 GPU 资源 + 有 ML 工程师？
    │   → 考虑 Fine-tuning
    │
    └─ 以上条件不具备？
        → 先用 Prompt + RAG 组合，通常已经够用

典型场景对应

场景	推荐方案	原因
让模型用公司口吻回复	Prompt Engineering	只是行为约束，Prompt 就能搞定
企业内部知识库问答	RAG	文档多、会更新，必须用 RAG
实时查询数据库回答	RAG + Tool Calling	数据是动态的，需要实时查询
模型回答某垂直领域专业问题	RAG（优先）或 Fine-tuning	先试 RAG，不够再考虑微调
训练一个特定语言风格的模型	Fine-tuning	风格需要内化，RAG 解决不了
医疗/法律等高度专业场景	RAG + Fine-tuning 组合	双管齐下，知识+能力都要提升

五、几个常见误区

“Fine-tuning 比 RAG 效果一定更好”

不一定。Fine-tuning 的效果高度依赖训练数据的质量和数量。

对于”让模型知道公司内部知识”这类需求，RAG 的效果往往优于 Fine-tuning，因为：RAG 能精确引用原文、知识更新即时生效、来源可追溯。Fine-tuning 的知识是黑盒，而且可能在原有知识上产生混淆。

“Prompt Engineering 只是入门手段，后面要换掉”

不对。Prompt Engineering 是贯穿始终的基础能力。

即使用了 RAG 或 Fine-tuning，Prompt 依然决定了模型如何利用这些知识。好的 Prompt 是 AI 应用质量的地基，永远不会过时。

“数据不多，Fine-tuning 没用”

基本正确。Fine-tuning 需要足够多且高质量的训练样本。

数据量少时（几十条），Fine-tuning 不仅效果差，还可能导致过拟合——模型死记硬背，泛化能力变差。这种情况用 Prompt + RAG 效果反而更好。

可能有人花了大量时间准备了 100 条训练数据做 Fine-tuning，结果效果不如一个写得好的 System Prompt。

六、实际项目中的组合使用

三种方式并不互斥，生产系统中常常组合使用：

典型的企业智能客服架构：

用户问题
    │
    ├─ Prompt Engineering：
    │   定义客服身份、回答风格、禁止话题
    │
    ├─ RAG：
    │   检索产品手册、FAQ、政策文档
    │
    ├─ Tool Calling：
    │   查询订单状态、用户账户信息
    │
    └─ （可选）Fine-tuning：
        如果需要模型深度理解行业术语