rag和微调、prompt的区别

很多人第一次搭 AI 功能，名字还没分清就先纠结「要不要微调」。结果拿着几十页文档去调模型，钱花了效果还不如把资料检索出来塞进上下文。这篇不讲原理，只给判断顺序：先问数据在不在手边、变不变、格式要求多严，再决定走哪条路；每条路什么时候不适用，也一并说清。

很多人第一次搭 AI 功能，名字还没分清就先纠结「要不要微调」。结果拿着几十页文档去调模型，钱花了，效果还不如把资料检索出来塞进上下文。其实这三条路改的东西根本不一样，判断顺序也不该从「哪个高级」入手。

这篇不讲原理，只给判断顺序：先问答案靠不靠你自己的资料、资料多久变一次、对输出格式和语气的要求有多严，再决定走哪条路。每条路什么时候不适用，也一并说清。

先分清三条路各自在改什么

提示词改的是「这次怎么问」，不动模型也不动数据，改完立刻生效；RAG 改的是「回答前拿到什么材料」，把外部资料检索出来拼进上下文，资料更新只要重新入库；微调改的是「模型自己的习惯」，把风格、格式、领域表达压进权重。三者不是互相替代，而是成本和确定性各不同。

按这四步问自己，路就出来了

1. 问知识来源答案只靠模型常识就能答，走提示词；答案依赖你自己的文档、库表、工单，先考虑 RAG。
2. 问变更频率资料每周都在动，RAG 更省事；规则和格式长期不变，提示词里写死也行。
3. 问要求类型要固定输出结构、固定语气、固定判断口径，先试提示词加结构化输出；效果不稳再考虑微调。
4. 问验证成本没有一批可复现的测试用例，三条路都别急着上，先攒用例。

这四步里最容易跳过的是第四步。没有测试集，你改完提示词、换完检索、训完模型，都只能说「感觉好点了」，出了问题也说不清是哪一层退化的。攒测试集这件事，越早做越省事。

RAG 的适用面与不适用面

• 适用：文档问答、内部知识库、客服话术、按权限过滤的资料检索，且回答需要能指回原文出处。
• 不适用：纯风格改写、纯格式转换、纯推理题，检索到的资料帮不上忙还白占上下文。
• 接入前先解决进料问题：扫描件、表格、乱码 PDF 直接入库，检索再准也答不对，先做清洗和切片。
• 检索效果差时先调切片、加关键词混合检索，别一上来就换模型。

还有一个常被忽略的边界：如果答案是「查库算出来的」，比如某条订单当前状态，RAG 也不合适，那是工具调用或直接查接口的活。判断标准是看答案来自文本还是来自实时系统。

微调什么时候才值得做

微调不是「让模型更懂我们行业」的万能钥匙。它的强项是压风格、压格式、压判断口径，让输出稳定到不需要每次都长篇解释。事实性知识仍然可能记错，该做的引用和兜底话术还是要留。

做之前先算清账：训练只是开始，后续每次底模升级都要重跑一遍，这部分人力要提前算进去。成本口径别凭印象，可以到 /compute/finetune 核对当时的对照说明。

落地的第一步永远是小规模对比

别在真实流量上做实验。先把一批真实问题固定成测试集，三条路线各跑一遍，人工打分记下来。关注四个指标：答对率、格式合格率、单次成本、首字延迟。权衡点因业务而异，价格与延迟基线可以到 /tools/speed-test 量当时的数字。

上线后留观测：把检索命中的片段、最终答案、耗时记进日志，出问题才有得复盘。方案要能退：检索挂了降级成纯提示词回答，模型换源时接口层不跟着改，挑框架可以参考 /stacks/frameworks 里的目录。