「怎么让 AI 更懂我们的业务？」——这是每个团队都会问的问题。答案不是「哪个最好」，而是「你的场景适合哪个」。

三种方案一览

微调 (Fine-tuning)RAG长上下文
做什么重新训练模型参数检索文档塞给模型把全部内容塞进窗口
知识更新需要重新训练更新索引即可换内容即可
前期成本高（数据 + 算力 + 人力）中（搭建检索管线）低（直接用）
运行成本低（推理时无额外开销）中（Embedding + 检索）高（Token 按量计费）
擅长改风格/格式/行为模式基于文档问答少量文档的深度理解
不擅长注入大量新事实需要推理的任务大量文档 / 频繁更新

微调：改「性格」和「习惯」

微调适合的不是「让模型知道新事实」，而是 改变模型的行为模式：

✅ 适合微调:
  - 让模型按你公司的格式写报告
  - 让模型学会特定的分类体系
  - 让模型用特定的语气/style 回复

❌ 不适合微调:
  - 注入 1000 页产品文档（用 RAG）
  - 需要实时更新的数据（用 RAG + API）
  - 偶尔用一次的场景（用 Prompt 就行）

微调的真实成本：

  • 准备高质量训练数据（至少几百到几千条）
  • GPU 训练费用（几百到几千美元）
  • 持续维护：模型升级后要重新微调

RAG：最通用的方案

上一篇详细讲了 RAG，这里只补充 选型建议：

文档量 < 100 页、更新不频繁 → 简单 RAG 就够
文档量 > 1000 页、多数据源   → RAG + 混合检索 + Rerank
需要实时数据                 → RAG + Agent 调 API

RAG 是目前 投入产出比最高 的方案，90% 的企业 AI 应用应该从这里开始。

长上下文：简单但贵

把文档直接塞进模型的上下文窗口：

"以下是我们的产品手册（3 万字），请基于手册回答用户问题……"

优点：实现最简单，不需要搭建检索系统。 缺点：

  • 贵：3 万字 ≈ 5000+ Token，每次提问都要重新输入
  • 慢：处理长上下文比短文本慢很多
  • 精度不一定更好：研究表明模型对长文本中间部分的关注度会下降（「Lost in the Middle」问题）

适合场景：

  • 文档少（< 50 页）且固定
  • 原型验证阶段，快速试效果
  • 需要模型对全文做复杂推理（比如对比分析）

决策流程

开始
  ↓
需要改变模型的输出风格/格式？
  是 → 考虑微调
  否 ↓
需要基于特定文档/数据回答？
  是 → 文档量大吗？
         是 → RAG
         否（< 50 页）→ 长上下文 或 RAG 都行
  否 ↓
需要实时/动态数据？
  是 → Agent + API
  否 → 好的 Prompt 就够了

实际项目中的组合

真实产品很少只用一种方案：

客服机器人 = RAG（FAQ 文档）+ Agent（查订单 API）+ 微调（统一回复风格）
代码助手   = RAG（代码库索引）+ 长上下文（当前文件）+ Agent（执行命令）

小结

  • Prompt 优先：能用 Prompt 解决的不上 RAG
  • RAG 其次：需要私有数据时的默认选择
  • 长上下文：文档少、快速验证时用
  • 微调最后：确实需要改行为模式时再考虑

下一篇：模型的「感官」升级——多模态 AI。