RAG 项目从 0 到 1 踩坑：多数团队卡在检索质量，附可复用的评估清单与分层 Prompt 库

很多团队搭完RAG Demo效果不错，一上真实业务就翻车：换个说法、多版本文档、内容歧义，回答就开始胡说八道。反复调参几周依然不稳定，本质问题不在模型，而在检索质量。本文梳理RAG检索全链路的7个高频坑点，提供一套可直接上手的检索质量评估框架与分层Prompt体系，帮你从源头解决RAG落地难题。

最近半年接触了十多个内部知识库、企业文档问答、行业资料问答类 RAG 项目，发现一个非常扎心的共性：

很多团队兴冲冲搭完向量库、接入大模型，Demo 演示看着效果不错，一上真实业务就翻车。用户提问稍微换个说法、文档存在多版本、内容有歧义，回答就开始胡说八道、答非所问、漏关键信息。

很多人第一反应：换更强的大模型、调高 chunk 分片大小、换 embedding 模型。反复调参几周，效果依然不稳定。本质问题根本不在模型，而在检索质量。

RAG 的核心逻辑是：先找对资料，再让模型基于资料回答。检索环节拿到的是垃圾片段，后面再好的 Prompt 和大模型，都很难挽回结果。以我接触的项目来看，绝大多数卡在检索这一关。

本文不讲花哨的架构，聚焦落地视角：梳理 RAG 检索全链路高频坑点、一套可直接上手的检索质量评估框架、配套的 Prompt 体系。文章里思路、方法、判断标准全部公开；文中展示的是样例清单和精简 Prompt，完整可直接导入使用的评估打分表、多场景 Prompt 库打包整理好了，文末会说明获取方式。

一、先纠正一个误区：检索 ≠ 向量相似度匹配

刚上手做 RAG 的产品，很容易陷入一个认知陷阱：

只要向量相似度分数高，代表检索出来的片段就是对的。

这是所有坑的源头。

向量相似度，衡量的只是「文本语义相近程度」，不等于内容和用户问题相关、不等于信息准确、不等于片段包含答案。

举几个业务里真实遇到的场景：

用户问【2025 年项目验收标准】，库里面有【2023 年验收标准】，两段文档描述句式高度相似，向量分很高，检索优先召回旧版本文档；
用户问报销审批流程，文档里多处出现”审批”关键词，向量召回一堆无关制度，只是词语相近；
一份方案分上下两篇，答案分散在两个 chunk，单次检索只召回其中一段，信息残缺；
文档里存在正反两种描述（注意事项、禁止条款），模型拿到片段只看半句，反向理解规则。

向量检索擅长语义模糊匹配，但是它没有”业务事实判断能力”。只靠向量检索做召回，就是把正确性交给概率。

成熟落地的 RAG，检索一定是混合模式：向量检索 + 关键词检索 + 业务规则过滤 + 重排。而评估检索质量，也不能只看相似度分数。

产品小结： Demo 阶段纯向量可以跑通；面向企业内部、合规、业务问答场景，只做向量检索等于埋雷。

二、RAG 检索全链路，7 个高频踩坑点（产品最容易忽略）

我按从上游到下游的顺序整理。很多坑不是算法坑，是产品需求定义、文档治理、验收标准缺失带来的。

坑 1：文档入库前不做治理，脏数据直接灌入向量库

很多团队拿到一堆文档直接切片入库：重复文档、多版本共存、扫描件 OCR 乱码、附件截图无文字、表格被切碎、页眉页脚冗余信息。检索不稳定的根源，往往在入库源头。

产品要先定义文档准入规范：哪些文档是有效源、旧版本怎么标记淘汰、表格怎么拆、冗余内容怎么清洗。不是所有文档，都适合放进知识库。

坑 2：Chunk 分片策略一刀切，固定长度分片

网上教程最喜欢说 chunk 512、overlap 100。真实业务里，合同、流程制度、技术方案、FAQ，适合的分片规则完全不一样：

FAQ：短文本，小分片更合适；
合同条款：不能把一条完整条款拦腰切断；
数据表格：强行截断会丢失行列关联关系。

固定分片尺寸，会把完整语义切碎，检索拿到残缺片段。

坑 3：没有 Query 改写模块，直接拿原始用户问题去检索

用户提问五花八门：口语化、省略主语、指代提问、多问题合并。

例：上文聊了合同有效期，用户接着问”那最晚什么时候提交？”——直接拿这句话检索，缺少上下文，召回结果必然跑偏。

Query 改写的目标：补全指代、拆分多问题、改写为适合检索的标准问句，是检索上游非常低成本、收益极高的环节。

坑 4：召回排序只看向量分，缺少重排（Rerank）环节

这个坑其实覆盖了召回和重排两层问题：

召回层： 向量返回 Top5、Top10，排序是按向量分，不是按”和问题相关性”排序，高分片段里混杂着相似但无关内容；
重排层： 重排模型的作用就是二次打分，优先保留真正包含答案的片段，过滤掉语义相似但无关的噪声。

很多团队省掉重排，看似省成本，本质是把噪声交给大模型去分辨，幻觉概率大幅上升。

坑 5：检索评估只做正向 case，不做负向 case 测试

测试的时候，大家习惯性拿自己知道答案的问题去试，效果看着很好。但是很少去测：不存在答案的问题、问已作废规则、跨领域无关问题。

缺少负向样本测试，上线后遇到知识库没有答案的问题，模型强行编造内容。

坑 6：检索结果没有溯源边界控制，Prompt 没有强约束

哪怕检索到正确片段，如果 Prompt 写得太松，模型依然会脱离原文自由发挥。很多 Prompt 只写”基于文档回答问题”，约束力度不够。

合规类、企业制度类问答，必须严格限制：找不到答案就如实说不知道，禁止推演、禁止脑补。

坑 7：没有持续迭代机制，检索效果是一次性验收

文档持续新增、业务规则持续更新，Embedding、检索权重、重排阈值都需要持续调优。很多项目上线等于优化结束，没有定期抽样评估检索集，随着知识库膨胀，效果慢慢衰减。

三、核心干货：一套可复用的检索质量评估清单

重点来了：怎么判断检索好不好？不靠感觉，靠标准化打分。这套清单，我在好几个内部 RAG 项目用来做验收、版本对比，产品、算法、测试可以对齐标准。

评估方式： 抽样一批测试问句（建议总量不少于 50 条，其中负向 case——无答案、已作废、跨领域——占比不低于 20%，指代与歧义 case 占比不低于 20%），每条问题对检索召回结果打分，满分 10 分。

检索质量评估打分项（公开样例版）

相关性（3 分）：召回片段是否和用户问题主题相关，无大量无关噪声
信息完备性（2 分）：答案需要的关键信息，是否全部包含在召回片段内，没有缺项
正确性（2 分）：召回的是最新有效版本，没有召回作废、过期、冲突文档
无冗余（1 分）：没有大量重复内容，不占用上下文窗口
可区分性（1 分）：知识库无答案时，不会强行召回近似但错误内容
排序合理性（1 分）：最相关、包含答案的片段排在靠前位置

打分参考：

9~10 分：检索优秀，稳定拿到正确完整素材；
7~8 分：合格，少量瑕疵，配合 Prompt 约束可以稳定回答；
＜7 分：检索不合格，优先优化检索链路，不要去调生成 Prompt。

配套记录字段（清单里）：问题原文、Query 改写后、召回文档列表、每段摘要、打分、问题类型、缺陷备注、优化方向。

产品重要提醒： 只要检索打分长期低于 7 分，不要在生成侧死磕 Prompt。检索是瓶颈，上游不修好，下游努力都是治标。

四、配套：分层 Prompt 库设计（适配 RAG 不同环节）

很多人把所有逻辑塞进一个 Prompt，耦合严重，不好迭代。我习惯拆成 4 类 Prompt，各司其职，按需启用：

1. Query 改写 Prompt（检索上游）

角色：你是查询改写专家，基于历史对话和当前用户问题，生成适合知识库检索的标准查询。要求：

1. 补全指代、省略信息，消除歧义；

2. 如果用户同时问多个问题，拆成独立检索问句；

3. 保留专有名词、编号、版本号等关键信息；

4. 不要额外回答用户问题，只输出改写后的检索词/问句列表。

2. 检索后重排辅助 Prompt（可选，小预算没有 Rerank 模型时用）

给定用户问题和下面多条文档片段，请判断每一条片段和问题的相关性，只输出【高相关 / 低相关 / 无关】，简短标注理由。

3. 主回答 Prompt（核心生成 Prompt，强防幻觉）

你是企业知识库问答助手，只能严格依据【参考文档】里提供的信息回答用户问题。

规则：

① 如果参考文档中没有对应答案、信息不足、互相冲突，直接回复：当前知识库暂无相关内容，无法解答；禁止猜测、推演、编造；

② 回答优先引用原文表述，不要自行引申出新规则；

③ 如果有多条冲突信息，需要指出文档冲突，不要自行选择一个结论；

④ 回答结尾标注信息来源（文档名称 + 章节/条款号）；

⑤ 不要超出文档范围回答。

参考文档：{retrieve_context}

用户问题：{query}

4. 摘要提炼 Prompt（长片段压缩，节省上下文窗口）

对下面文档片段做精简摘要，保留关键数字、规则、条件、边界，删除修饰语句，不要丢失关键约束。

说明： 上面是基础版本，实际业务还会衍生：FAQ 专用 Prompt、合同解读 Prompt、技术文档问答 Prompt 等，不同场景约束强度不一样。

五、落地推进节奏：产品怎么安排迭代优先级

给产品一份落地顺序，避免团队眉毛胡子一把抓：

第一阶段：文档治理规范先行（产品 + 业务/运营）：清理脏数据，定义文档版本机制；
第二阶段：分片策略 + 混合检索（算法 + 产品）：不要一刀切；搭建向量 + 关键词混合检索；
第三阶段：Query 改写 + 重排（算法）：补齐检索上游改写，接入 Rerank；
第四阶段：检索评估集（产品 + 测试主导，算法配合）：每次版本变更，跑一遍抽样评估；
第五阶段：分层 Prompt 优化（产品 + 算法）：做生成侧约束；
长期： 持续扩充测试 case，定期回流线上 Bad Case，反哺检索策略。

很多团队顺序搞反了：先调 Prompt、调模型参数，最后才回头治理文档和检索，白白浪费大量时间。

六、写在最后

RAG 不是一个可以开箱即用的工具，它是一套数据 + 检索 + 提示词的组合系统。

大模型的能力大家都很容易拿到，拉开项目效果差距的地方，恰恰是这种偏工程、偏细节、偏枯燥的检索质量管控。Demo 好看很简单，业务稳定可用很难。

判断一个 RAG 项目能不能上线，先放下生成效果，先看检索能不能稳定拿到正确的原文片段。检索过关，问题就解决大半。

本文由 @EVE的星球原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自作者提供