提示词、RAG、微调怎么选
先判断问题出在哪一层，再决定改提示词、接 RAG、做微调，还是拆工作流。
不要一上来就问“该不该微调”。先问：模型为什么没做好？
同样是答案差，原因可能完全不同。任务没说清，改提示词；缺公司资料，做 RAG；输出风格长期不稳定，再考虑微调；任务本身需要查资料、算东西、审结果，就要拆成工作流。选错方向，会把时间烧在错误的地方。
先用这张表定位问题
| 你看到的现象 | 更可能的问题 | 先选什么 | 不该先做什么 |
|---|---|---|---|
| 回答方向跑偏，格式忽长忽短 | 任务和输出标准没说清 | Prompt Engineering | 微调 |
| 引用不存在，缺公司制度或最新政策 | 模型没有可靠资料 | RAG / 知识库检索 | 继续堆提示词 |
| 一批固定任务总是语气不对、格式不稳 | 行为习惯没对齐 | SFT / 少量微调 / 示例库 | 只靠一句系统提示 |
| 拒答边界、排序偏好、推荐口径不对 | 偏好和安全策略没调好 | 偏好优化、规则、评估集 | 只换更大的模型 |
| 要查资料、调用工具、比较多份文件 | 任务流程太复杂 | 工作流 + 工具 + 检索 + 校验 | 让模型一次性裸答 |
| 算数、代码执行、表格统计总出错 | 需要工具而不是语言预测 | 计算器、代码执行、结构化工具 | 让模型“认真算” |
Prompt Engineering 适合什么
适合把任务说清楚。比如客服回复、摘要、改写、分类、结构化抽取。它解决的是“模型不知道你要什么格式、什么口径、什么边界”。
一个好提示词通常会写清：
- 输入是什么，哪些字段可信；
- 输出要什么结构；
- 不确定时怎么处理；
- 哪些内容不能编；
- 给一两个正例和反例。
但提示词不能凭空制造资料，也不能稳定替代训练。它像给临时工写任务单，不像给人重新上岗培训。
RAG 适合什么
适合让模型基于外部资料回答。比如公司制度问答、合同条款解释、产品文档助手、研报检索、知识库客服。
RAG 的关键不是“多塞点文档”，而是四件事：
- 文档来源可信；
- 切片方式不会把上下文切碎；
- 检索能命中真正相关内容；
- 回答能引用回原文。
如果资料本身错了、旧了、权限乱了，RAG 会把错误更快送到模型面前。
微调适合什么
微调适合让模型稳定学会一类表达习惯或任务模式。比如固定的法律摘要格式、客服语气、代码风格、行业标签体系。
它不适合当资料库。你不该为了“让模型知道本周新政策”去微调。政策会变，应该放进可更新的知识库。
微调前最好先有三样东西：
- 足够稳定的任务定义；
- 高质量样例数据；
- 能判断好坏的评估集。
没有评估集就微调，基本是在黑箱里砸钱。
偏好优化适合什么
SFT、RLHF、DPO、PPO 这组词经常和微调混在一起。普通读者先记住：它们处理的是“模型更应该偏向哪种回答”。
比如：
- 遇到危险请求该拒到什么程度；
- 两个答案都对时，哪个更符合产品口径；
- 推荐结果应该保守还是激进；
- 长答案和短答案怎样取舍。
这不是补知识，而是调行为。
工作流适合什么
如果任务本身包含多个步骤，就不要逼模型一次完成。把它拆开：先检索，再提取，再比较，再生成，再校验。
典型例子：
- 审合同：先抽条款，再找风险，再引用原文，再给修改建议；
- 写研报：先查资料，再筛来源，再列证据，再写正文；
- 数据分析：先跑代码，再解释结果，而不是让模型心算；
- Agent 任务：先规划，再调用工具，再检查结果。
一个实用判断顺序
- 先改提示词：任务、输入、输出、边界是否说清楚。
- 再看资料：是否缺最新、私有、可引用的知识。
- 再拆流程：是否需要工具、检索、计算、审核。
- 再考虑微调：是否有稳定任务和好数据。
- 最后看偏好优化：是否要长期改变模型行为。
多数产品问题死在前 3 步，还没轮到微调。