很多团队搭完RAG Demo效果不错，一上真实业务就翻车：换个说法、多版本文档、内容歧义，回答就开始胡说八道。反复调参几周依然不稳定，本质问题不在模型，而在检索质量。本文梳理RAG检索全链路的7个高频坑点，提供一套可直接上手的检索质量评估框架与分层Prompt体系，帮你从源头解决RAG落地难题。 最近半年接触了十多个内部知识库、企业文档问答、行业资料问答类 RAG 项目，发现一个非常扎心的共性： 很多团队兴冲冲搭完向量库、接入大模型，Demo 演示看着效果不错，一上真实业务就翻车。用户提问稍微换个说法、文档存在多版本、内容有歧义，回答就开始胡说八道、答非所问、漏关键信息。 很多人第一反应：换更强的大模型、调高 chunk 分片大小、换 embedding 模型。反复调参几周，效果依然不稳定。本质问题根本不在模型，而在检索质量。 RAG 的核心逻辑是：先找对资料，再让模型基于资料回答。检索环

很多团队搭完RAG Demo效果不错，一上真实业务就翻车：换个说法、多版本文档、内容歧义，回答就开始胡说八道。反复调参几周依然不稳定，本质问题不在模型，而在检索质量。本文梳理RAG检索全链路的7个高频坑点，提供一套可直接上手的检索质量评估框架与分层Prompt体系，帮你从源头解决RAG落地难题。 最近半年接触了十多个内部知识库、企业文档问答、行业资料问答类 RAG 项目，发现一个非常扎心的共性： 很多团队兴冲冲搭完向量库、接入大模型，Demo 演示看着效果不错，一上真实业务就翻车。用户提问稍微换个说法、文档存在多版本、内容有歧义，回答就开始胡说八道、答非所问、漏关键信息。 很多人第一反应：换更强的大模型、调高 chunk 分片大小、换 embedding 模型。反复调参几周，效果依然不稳定。本质问题根本不在模型，而在检索质量。 RAG 的核心逻辑是：先找对资料，再让模型基于资料回答。检索环节拿到的是垃圾片段，后面再好的 Prompt 和大模型，都很难挽回结果。以我接触的项目来看，绝大多数卡在检索这一关。 本文不讲花哨的架构，聚焦落地视角：梳理 RAG 检索全链路高频坑点、一套可直接上手的检索质量评估框架、配套的 Prompt 体系。文章里思路、方法、判断标准全部公开；文中展示的是样例清单和精简 Prompt，完整可直接导入使用的评估打分表、多场景 Prompt 库打包整理好了，文末会说明获取方式。 一、先纠正一个误区：检索 ≠ 向量相似度匹配 刚上手做 RAG 的产品，很容易陷入一个认知陷阱： 只要向量相似度分数高，代表检索出来的片段就是对的。 这是所有坑的源头。 向量相似度，衡量的只是「文本语义相近程度」，不等于内容和用户问题相关、不等于信息准确、不等于片段包含答案。 举几个业务里真实遇到的场景： 用户问【2025 年项目验收标准】，库里面有【2023 年验收标准】，两段文档描述句式高度相似，向量分很高，检索优先召回旧版本文档； 用户问报销审批流程，文档里多处出现”审批”关键词，向量召回一堆无关制度，只是词语相近； 一份方案分上下两篇，答案分散在两个 chunk，单次检索只召回其中一段，信息残缺； 文档里存在正反两种描述（注意事项、禁止条款），模型拿到片段只看半句，反向理解规则。 向量检索擅长语义模糊匹配，但是它没有”业务事实判断能力”。只靠向量检索做召回，就是把正确性交给概率。 成熟落地的 RAG，检索一定是混合模式：向量检索 + 关键词检索 + 业务规则过滤 + 重排。而评估检索质量，也不能只看相似度分数。 产品小结： Demo 阶段纯向量可以跑通；面向企业内部、合规、业务问答场景，只做向量检索等于埋雷。 二、RAG 检索全链路，7 个高频踩坑点（产品最容易忽略） 我按从上游到下游的顺序整理。很多坑不是算法坑，是产品需求定义、文档治理、验收标准缺失带来