Fine-tuning 与 RAG 选型决策

「我们要不要微调模型？」「RAG 和 Fine-tuning 有什么区别？」这是 AI 产品立项时最常遇到的技术路线抉择。选错了，轻则浪费几个月工期，重则产品能力上限被彻底锁死。本文给你一套可操作的决策框架。

---

1. 三种增强路径的本质区别

在具体决策之前，先建立清晰的概念模型：

基础大模型（Base LLM）
    │
    ├── Prompt Engineering（提示工程）
    │   ├── 修改：输入文本
    │   ├── 代价：零成本，即时生效
    │   └── 局限：受上下文窗口限制，能力天花板固定
    │
    ├── RAG（检索增强生成）
    │   ├── 修改：运行时注入知识
    │   ├── 代价：知识库建设 + 检索系统
    │   └── 局限：检索质量决定上限，增加延迟
    │
    └── Fine-tuning（微调）
        ├── 修改：模型权重
        ├── 代价：数据标注 + 训练费用 + 维护成本
        └── 局限：训练数据即上限，知识有截止日期

核心记忆：RAG 是「给模型查字典」，Fine-tuning 是「改变模型的大脑」。

---

2. 决策框架：什么时候用哪种方案

2.1 首先：能不能用 Prompt Engineering 解决？

在走向 RAG 或 Fine-tuning 之前，先穷尽 Prompt Engineering 的潜力。90% 被认为「需要微调」的需求，其实是 Prompt 没写好。

判断节点：如果认真调试 Prompt 2 周后仍然无法满足需求，再考虑 RAG 或 Fine-tuning。

2.2 选型决策树

需求分析
    │
    ▼
问题1：是否需要使用私有/最新/大量的外部知识？
    │
    ├── 是 → 考虑 RAG
    │       │
    │       └── 问题2：知识库规模多大？更新频率如何？
    │               ├── 规模大、频繁更新 → RAG（必须）
    │               └── 规模小、很少更新 → RAG 或直接塞进 Prompt
    │
    └── 否 → 问题3：是否需要改变模型的行为/风格/能力？
                │
                ├── 是 → Fine-tuning
                │       前提：有足够高质量训练数据（>500条）
                │
                └── 否 → Prompt Engineering 已够用

2.3 详细对比表

---

3. RAG 深度解析

3.1 RAG 工作流程

离线阶段（知识库建设）：
文档 → 文本切分 → Embedding 向量化 → 存入向量数据库

在线阶段（检索生成）：
用户问题 → Embedding → 向量检索（Top-K 相似片段） → 拼接 Prompt → LLM 生成

3.2 Embedding 模型选型

中文场景首选 BGE-M3 或 Qwen-Embedding，效果显著优于 OpenAI 的 Embedding 模型。

3.3 向量数据库选型

给 PM 的建议：先用 Chroma 或 pgvector 快速验证，规模上来后再迁移。

3.4 文本切分策略（Chunking）

这是 RAG 质量的关键，也是最容易被忽视的环节：

黄金法则：Chunk 太小 → 语义不完整；Chunk 太大 → 噪音太多，检索精度下降。通常 512-1024 Token + 10% 重叠是较好的起点。

3.5 RAG 效果评估

RAG 质量评估四要素（RAGAS 框架）：
├── 上下文相关性（Context Relevancy）：检索到的内容是否和问题相关？
├── 上下文召回率（Context Recall）：正确答案是否被检索到了？
├── 答案忠实度（Faithfulness）：生成的答案是否基于检索内容而非幻想？
└── 答案相关性（Answer Relevancy）：答案是否真正回答了问题？

---

4. Fine-tuning 深度解析

4.1 Fine-tuning 适用场景（必须同时满足）

1. 独特的输出风格或格式：标准 Prompt 无法稳定实现（如特定公司的写作风格）
2. 足够的高质量数据：至少 500-1000 条标注样本，越多越好
3. 长期稳定的需求：一次性需求不值得微调
4. 对延迟/成本有要求：微调后可以用更小模型达到更好效果

典型适合 Fine-tuning 的场景：

• 医疗/法律/金融领域的专业问答（大量专业术语和固定格式）
• 企业特定风格的内容生成（品牌一致性）
• 结构化信息抽取（高精度 JSON 输出）
• 特定语言的低资源翻译

4.2 Fine-tuning 流程

第一步：数据准备（占总工期 60%）

// OpenAI Fine-tuning 数据格式（JSONL）
{"messages": [
  {"role": "system", "content": "你是一个专业的合同审查助手"},
  {"role": "user", "content": "这份合同的付款条款有什么风险？\n[合同内容...]"},
  {"role": "assistant", "content": "该付款条款存在以下风险：\n1. 付款周期过长（90天）..."}
]}

数据质量检查清单：

• 输出风格一致（避免多人标注导致风格混乱）
• 覆盖各类边缘情况（不只有正常样本）
• 无错误信息（错误样本比没有样本更糟糕）
• 训练/验证集按 9:1 拆分

第二步：选择 Fine-tuning 方法

第三步：评估与迭代

评估维度：

1. 自动化指标：BLEU、ROUGE（文本相似度）
2. GPT-4 作为评判：让强模型评估输出质量（LLM-as-a-Judge）
3. 人工评估：A/B 测试，盲评基础模型 vs 微调模型

4.3 Fine-tuning 成本估算

以 OpenAI Fine-tuning API 为例：

训练成本 = 训练 Token 数 × 单价
         = 1000条样本 × 平均500 Token × $8/M tokens
         ≈ $4（训练本身很便宜！）

隐性成本（往往更大）：
- 数据标注：1000条 × 15分钟/条 × 人力成本 = 数万元人民币
- 迭代调试：通常需要 3-5 轮
- 模型维护：每季度补充新数据重训

---

5. 混合方案（RAG + Fine-tuning）

最成熟的 AI 产品往往同时使用两种技术：

Fine-tuning 负责：
├── 教模型「怎么说」（格式、风格、角色扮演）
└── 教模型「行业专业知识的理解框架」

RAG 负责：
├── 提供「说什么」（最新的、具体的知识）
└── 提供可溯源的证据

实战案例：法律 AI 助手

---

6. 真实案例分析

案例一：客服 Bot 选型（某电商平台）

需求：回答商品问题、处理退换货咨询

错误路径：团队最初认为需要微调，花了 3 个月收集数据。

正确方案：

1. RAG：接入商品知识库、政策文档
2. Prompt Engineering：规范回答格式和边界
3. 结果：2 周上线，准确率 87%，省去了微调的所有成本

教训：产品知识是动态的，微调无法处理频繁更新，RAG 才是正解。

案例二：代码审查工具（某 SaaS 公司）

需求：按公司代码规范审查 PR，给出具体修改建议

正确方案：Fine-tuning

• 原因：公司代码规范是专有的，无法通过 Prompt 完整描述（Prompt 太长影响速度和成本）
• 数据：收集历史 Code Review 评论 2000 条，标注规范违规类型
• 效果：微调后 GPT-3.5 的准确率超过 Zero-shot GPT-4

关键：数据质量 > 数据数量

---

核心要点

1. 先 Prompt，后 RAG，最后 Fine-tuning：这是成本递增的顺序，也应该是尝试的顺序
2. 知识密集 → RAG，行为改变 → Fine-tuning：这是选型的根本原则
3. RAG 的瓶颈在 Chunking 和 Embedding：80% 的 RAG 质量问题来自数据预处理
4. Fine-tuning 的成本在数据标注：计划时要把人工成本算进去
5. 混合方案是成熟产品的标配：两种技术相互补充，不是非此即彼