提示词工程和rag的区别

很多刚接大模型的开发者会卡在一个选择题上：模型答得不对，是该回去改提示词，还是该上一套检索？这篇不绕概念，只讲两种手段各自能管住什么、什么时候不管用，以及怎么判断你当前这个问题到底归谁管。

模型答得不对的时候，很多入门开发者第一反应是「是不是该上一套检索」。这两种手段管的事其实不一样：提示词工程管的是模型怎么说话、按什么格式说、什么情况下该闭嘴；检索管的是模型原本不知道的东西从哪来。判断标准很简单——答案在你脑子里、只是模型没按你的要求讲出来，那是提示词问题；答案在文档里、模型压根没见过，那才轮到检索上场。

把这件事想清楚，能省掉大量无用的搭建工作。下面按「各管什么」「怎么划边界」「先做哪一步」「配合时的坑」四段拆开讲，每段都给判断口径和可执行动作，你对着自己手头的场景套一遍就知道该往哪使劲。

一个管表达，一个管事实来源

提示词工程

解决模型会不会用你给的信息、按你要的格式说话；约束语气、角色、输出结构、边界条件，但不引入新知识。

RAG

解决模型知道它原本不知道什么；把外部资料检索回来塞进上下文，让回答有出处、内容能更新。

判断口径

答案在你脑子里、只是模型没按你要的方式讲，是提示词问题；答案在文档里、模型压根没见过，是检索问题。

三问定边界：先别急着搭检索

很多人一上来就搭向量库，结果发现九成问题其实靠改提示词就解决了，剩下那点知识缺口根本撑不起一套检索链路的运维成本。先按下面三个问题过一遍，能过滤掉大部分不该上检索的场景。

1. 第一问：这个知识模型本身有没有？常识、通用写法、语言转换类的活，靠提示词就够。判断方法：把资料从上下文里拿掉，如果模型裸答的水平你还能接受，就不用上检索。
2. 第二问：资料多久变一次？常年不动的可以写进系统指令或提示词模板；更新频繁、体量又大的，才值得做入库和检索流程。验证方法：记录这批资料最近改动的频率，改动少的别硬上。
3. 第三问：答错了代价大不大？需要给出处、需要可追溯的场景才刚需检索；写文案、改措辞这类容错高的，提示词调稳就够。判断标准：出错的后果是否涉及对外承诺或合规。

• 资料总量很小（几页纸）、延迟又敏感的场景，硬上向量库反而拖慢首字，不适用
• 模型本身已经能答对的领域，上检索只是多一层故障点，收益接近零
• 没有任何标注或评测手段时，先别上检索，因为你无法判断召回准不准
• 团队没有维护索引和更新流程的人手时，提示词方案的可维护性更高

落地顺序：先调提示词，再考虑检索

顺序搞反了很常见：先搭了检索，发现效果不好，回头再改提示词，最后两边的改动互相掩盖，谁都说不清是哪一步起了作用。稳妥的做法是按下面的步骤走，每一步都留下可对比的记录。

1. 第一步：先跑模型裸答记录哪些是「不会」，哪些是「不听话」。这两类问题后面走的路径完全不同，混在一起记等于白记。
2. 第二步：把「不听话」的部分用提示词修掉包括输出格式、拒答边界、字段结构。这步不做完，检索回来的资料也会被同样的毛病带歪。
3. 第三步：确有知识缺口再补检索先确认切片粒度和召回质量，再谈要不要加更复杂的链路，别一开始就堆架构。
4. 第四步：上线后分开记日志把「检索没命中」和「提示词失效」分成两类指标，否则出了问题分不清是谁的责任。

两者配合时最容易踩的坑

提示词和检索一起上线之后，问题往往不是出在某一方不够强，而是两边互相干扰。下面这几条是最常见的互相踩坑，配着排查顺序看会更快定位。

• 检索片段不是越多越好，塞太多会挤掉指令权重，模型开始忽略格式要求；先定上下文预算再定召回条数
• 提示词里要写清「资料里没有就直说」，否则模型会把无关片段硬凑成答案
• 评测要分开做：一套用例测召回准不准，另一套测给定正确资料后回答对不对，混在一起没法定位
• 上线后回归测试别只看最终回答，检索链路的改动和提示词改动要能分别回滚
• 版本记录要分开存，否则一次改完说不清是变好还是变坏

真要把这套组合调稳，评测用例是关键。没有自己的用例集，就只能凭感觉判断「这次好像好一点」，而感觉在两类改动混在一起时基本不可靠。建议先攒一批覆盖常见问法的用例，再分别测检索和生成两段。