Prompt、RAG 与微调怎样选择

# Prompt、RAG 与微调怎样选择

本篇目标

分清 Prompt、RAG、工具调用和微调分别改变什么,根据知识、行为、数据实时性和成本问题选择最小有效方案。

定位问题根因选择改进手段组合多种方案避免过早微调

# 先记住一句话

Prompt 主要说明任务,RAG 提供外部知识,工具获取或修改真实状态,微调改变模型行为模式;先判断缺的是规则、知识、能力还是系统执行,再选择方案。

# 四种手段分别改变什么

手段 主要解决 不擅长解决
Prompt 任务目标、规则、示例和输出要求不清 大量实时或私有知识
RAG 模型缺少可检索的外部知识和来源 真实写操作和严格计算
工具调用 查询实时状态、执行计算或业务动作 单独改善语言风格
微调 稳定行为、格式、风格或领域任务模式 自动获得持续更新的事实

这些方案不是互斥关系。一个客服系统可以先用 Prompt 定义回答原则,用 RAG 查产品文档,用工具查订单状态,再用微调提高特定分类任务的稳定性。

# 什么时候先改 Prompt

适合先改 Prompt 的问题包括:

  • 任务目标和成功标准没有说清;
  • 输入字段含义不明确;
  • 缺少正反例;
  • 输出格式或拒答条件不清楚;
  • 同一条规则在多个位置互相冲突。

Prompt 调整成本低、反馈快,应先建立基线。但 Prompt 不能强制数据库权限,也不能让模型知道没有提供的私有数据。

# 什么时候使用 RAG

当答案依赖大量、经常更新或需要引用的外部资料时,适合 RAG:

  • 企业知识库和产品手册;
  • 法规、版本文档和内部流程;
  • 用户自己的笔记;
  • 需要指出来源的事实问答。

RAG 的关键不是把所有文档塞进上下文,而是检索最相关且有权限的证据。完整工程还要处理解析、分片、召回、重排、引用和检索评测。

# 什么时候使用工具调用

当任务需要真实世界状态或确定性执行时,应使用工具:

  • 查询实时库存、订单和账户状态;
  • 执行数据库检索、计算器或代码;
  • 创建工单、发送消息或更新记录;
  • 获取模型训练数据中不存在的当前信息。

模型只负责提出工具调用请求,宿主应用校验权限、参数和业务规则后才执行。工具结果必须明确返回给模型,不能把模型想调用当作已经成功。

# 什么时候考虑微调

微调适合已经有稳定任务定义、足够高质量样本,并且 Prompt 与示例仍无法稳定达到目标的场景,例如:

  • 固定标签体系的大规模分类;
  • 特定格式或风格需要长期稳定;
  • 领域表达和术语模式非常固定;
  • 需要用更小模型达到可接受质量以降低成本。

微调之前至少应有基线评测集。否则训练完成后也无法判断是否真正提高,或是否只记住了训练样本。

# 微调不适合解决什么

  • 每天变化的价格、政策和库存;
  • 需要逐条引用来源的知识问答;
  • 数据库中的用户私有状态;
  • 应由权限和程序规则保证的行为;
  • 只有少量、质量不稳定的示例;
  • 根因其实是输入缺失或检索失败的问题。

知识经常变化时优先使用 RAG 或工具;规则能写清时先改 Prompt;只有稳定行为模式仍学不好时再评估微调。

# 一个实用决策顺序

结果不理想
  ↓
任务和输出要求是否清楚?
  否 → 先改 Prompt、Schema 和示例
  是 ↓
是否缺少外部或最新知识?
  是 → RAG 或查询工具
  否 ↓
是否需要读取真实状态或执行动作?
  是 → 工具调用与服务端校验
  否 ↓
是否有大量高质量样本,且问题是稳定行为模式?
  是 → 评估微调
  否 → 重新检查模型选择、输入和评测标准
1
2
3
4
5
6
7
8
9
10
11
12
13
14

每加一层都要重新运行同一评测集,比较质量、延迟、费用和失败路径。

# Few-shot 和微调有什么区别

Few-shot 是在 Prompt 中给少量示例,模型参数不变,修改快但会占用上下文。微调使用训练数据更新模型参数,准备和验证成本更高,但可以把稳定行为模式学进模型。

先用 Few-shot 验证任务是否能被示例说明清楚,再判断规模、质量和成本是否值得微调。

# 项目面试怎样表达

遇到模型效果问题,我先按根因选择方案:规则和格式不清先改 Prompt 与 Schema;缺企业知识用带权限和引用的 RAG;需要实时数据或写操作交给工具和服务端校验;只有任务稳定、有足够高质量样本,并且前面方案仍达不到目标时才考虑微调。每一步都用同一评测集比较质量、延迟和成本。

# 高频面试题与回答

1. RAG 和微调有什么区别?参考答案

RAG 在推理时检索外部资料并放进上下文,适合经常更新、私有或需要引用的知识;微调会用训练数据更新模型参数,更适合稳定行为、格式或领域任务模式。知识更新问题通常不应只靠微调。

2. 为什么不建议一开始就微调?参考答案

很多问题其实来自任务描述不清、缺少外部知识或输入链路错误,这些用 Prompt、RAG 或工具更容易修复。微调需要高质量数据和评测基线,成本更高,而且不能自动解决实时知识和权限问题。

3. 工具调用和 RAG 有什么区别?参考答案

RAG 主要检索资料作为回答证据,工具调用可以查询实时状态、执行计算或产生写操作。两者都由应用提供外部能力,但工具执行必须经过真实权限和参数校验,不能只靠 Prompt。

4. Few-shot 和微调怎样选择?参考答案

Few-shot 把少量示例放进上下文,适合快速验证和经常调整的任务;微调会更新参数,适合已有大量稳定高质量样本的重复任务。通常先用 Few-shot 建立效果和评测基线,再判断微调是否值得。

# 接下来学什么

下一篇进入 LLM 项目阅读实战,沿真实调用链检查 Prompt、模型、数据、错误、费用和评测分别放在哪里。

# 参考资料