基础 RAG 上线后常见的失效点有哪些？分别怎么解决？
简化版
基础 RAG（向量检索 Top-k → 拼 Prompt → 生成）一拿真实企业资料去问，常见四个失效点，而且全都出在检索环节：①专有名词、型号、编号搜不到，用混合检索（向量 + BM25）+ RRF 融合；②答案检索到了却排在后面被忽略，用重排（Cross-Encoder）精排；③用户问法和文档写法对不上，多轮对话里还有「那它呢」这种指代，用查询改写（多查询扩展、指代消解、HyDE）；④片段太小答不全、太大找不准，用父子分块，小块用来找、大块用来答。每个解法都有耗时和成本，开不开要靠评测数据决定。
详细版
| 失效点 | 典型现象 | 根因 | 解法 | 代价 |
|---|---|---|---|---|
| 专有名词搜不到 | 问「GTE3000 保修多久」，文档写「GTE-3000」，检索不到 | 向量是语义压缩，丢掉精确字符 | 混合检索：向量 + BM25，RRF 按名次融合 | 多一路检索 |
| 答案排在后面 | 正确片段排第 4，模型被前 3 段带偏 | 向量比的是整体语义像不像，不是能不能回答 | 重排：问题和片段一起交叉编码打分 | 多一次模型调用，通常是最慢的一步 |
| 问法和写法对不上 | 问「能装在自己机房吗」，文档写「私有化部署」；「那超期了呢」没有信息量 | 口语和文档腔差距大，多轮问题缺主语 | 查询改写：多查询扩展、指代消解、HyDE | 多一次模型调用，多查询还会让检索次数翻倍 |
| 片段大小两难 | 200 字答不全，1000 字找不准 | 检索要小块、生成要大块，要求相反 | 父子分块：子块检索、父块回填 | 上下文变长，输入 Token 增加 |
另外，新旧版本资料同时被检索出来这类「范围太大」的问题，用元数据过滤限定知识库、文档和片段类型。
完整版教学
一、基础 RAG 的天花板在检索
基础 RAG 的在线链路只有五步：
用户问题
→ Embedding 模型编码成向量
→ 向量库按余弦相似度取最近的 5 条片段
→ 5 条片段拼成 context，套进回答模板
→ 大模型生成答案这条链路能跑通，也能回答一部分问题，但检索质量决定了答案质量的上限：正确的那段没被捞上来，模型再强也变不出来，要么老实说找不到，要么开始编。所以基础 RAG 的四个典型失效点，全部出在检索环节，而不是生成环节。
记忆钩子：先问「资料捞上来没有」，再问「模型答得好不好」。四个失效点都是第一个问题。
二、失效点一：专有名词、型号、编号搜不到
知识库里写着「GTE-3000 系列工控机质保时长为 24 个月」，用户问「GTE3000 保修多久」，基础 RAG 大概率检索不到。
原因在于向量模型做的是语义压缩：一句话被压成 1024 个浮点数，保留的是「这句话在讲什么」，精确的字符信息在压缩中丢失了。对模型来说，GTE-3000 和 GTE3000 是两个陌生的字符串，编码出的向量并不一定接近。产品型号、订单编号、错误码、版本号、专业缩写都有同样的问题：信息藏在字符本身，不在语义里。
关键词检索 BM25 正好相反，它统计词频和稀有度，GTE3000 这种全库只出现几次的词一旦匹配上就是极强的信号；但它听不懂「保修」和「质保」是一回事。两者互补，所以解法是混合检索：两路一起召回，再用 RRF 按名次融合。中文场景还要注意分词：型号 GTE3000 最好额外拆出 gte 和 3000，和文档里的 GTE-3000 才能对得上。
三、失效点二：答案检索到了，却排在后面
问「售后退款要多久到账」，检索回来 5 段：
第 1 段 退换货政策总则（提到退款，没说时长）
第 2 段 售后服务承诺（提到到账，说的是维修件）
第 3 段 常见问题目录（标题里全是关键词）
第 4 段 退款审核通过后 3 到 5 个工作日原路退回 ← 真正的答案
第 5 段 发票开具说明答案检索到了，但排在第 4 位。模型对长上下文开头和结尾的注意力更高，中间的内容最容易被忽略（Lost in the Middle），前 3 段又都在谈退款、售后，很容易把模型带偏。
根因是向量检索用的是双塔结构：问题和片段各自独立编码再算距离，编码片段时模型并不知道用户会问什么，只能判断「整体像不像」。重排换成交叉编码，把问题和片段拼在一起让模型直接打分，判断的是「这段能不能回答这个问题」，准得多，但也慢得多，所以只能用在粗筛之后：
混合检索粗筛 10～20 条 → 重排精排出前 3～4 条 → 交给模型生成四、失效点三：用户的问法和文档的写法对不上
这个失效点有两种表现。
同一件事，两种说法。 文档写「本产品支持私有化部署，可交付于客户自有服务器环境」，用户问「能装在我们自己机房吗」。一个问题只有一种问法，同一件事却有十种写法，用一个问题去撞一份文档，命中率天然就低。
多轮对话里的指代。 用户先问「GTE-3000 的保修期是多久」，再问「那超期了呢」。第二句拿去检索，送进向量模型的只有 5 个字，没有型号、没有主题词，检索结果基本是随机的。
对应的三种查询改写：
| 改写方式 | 做法 | 适合 |
|---|---|---|
| 多查询扩展 | 把问题改写成 3～4 个说法不同、意思相同的问题，各自检索再融合 | 用户问法多样、文档表述固定 |
| 指代消解 | 带上对话历史，把当前问题补全成独立完整的问题 | 多轮对话，第二轮之后必开 |
| HyDE | 先让模型写一段假答案，拿假答案去检索 | 问题很短、口语和文档腔差距大 |
HyDE 的核心洞察是：问题和答案在语义空间里未必靠得近，但答案和答案一定靠得近。假答案的内容可能不对，但它的用词和句式像文档，用来找真文档比口语问题有效。
五、失效点四：片段大小的两难
同一份制度手册，切成 200 字和 1000 字，问答效果各有各的问题：
切 200 字 检索很准，能精确定位到那一条规定
但「依据前条规定」这类句子失去了前文，答案不完整
切 1000 字 上下文完整，模型能答全
但一段里塞了五六条规定，语义被稀释，该命中的命不中检索要小块（语义集中，向量更「纯」），生成要大块（上下文完整），用一个尺寸满足两个相反的要求，做不到，这不是参数没调好，而是单一片段这个结构本身的限制。父子分块把两件事拆开：比如父块 1200 字、子块 300 字，只有子块参与检索，命中后把它所属的父块交给模型。
六、还有一类问题：检索范围太大
知识库里同时有 2024 版和 2026 版的报销制度，问「报销标准」，两版都被检索出来，模型把两套标准混在一起回答。这不是切分或排序的问题，而是检索范围没有收住。解法是元数据过滤：向量表里冗余知识库、文档、片段类型等字段，检索时把过滤条件和向量排序写在同一条查询里，只在指定范围内找。
七、每个解法都有代价，开不开看数据
四个解法不是免费的：
| 手段 | 额外开销 |
|---|---|
| 混合检索 | 多一路检索，BM25 在内存里算时还要读候选片段 |
| 重排 | 多一次模型调用，粗筛条数越多越慢 |
| 查询改写 | 多一次模型调用；多查询扩展让检索次数乘以查询条数 |
| 父子分块 | 交给模型的上下文变长，输入 Token 增加 |
所以「全部打开」不一定是对的选择。正确的做法是用同一套评测集、同一批问题，分别跑「纯向量基线」和加了各项手段的策略，看召回、精度、忠实度这些指标提升了多少、单次耗时多了多少，再结合业务场景取舍：内部知识库问答多等两秒换来明显更准的答案值得，实时客服可能就不值得。
八、常见误区与追问
- 误区：答案不对，先换更强的大模型。 四个典型失效点都出在检索环节，正确片段没有被捞上来或者排得太靠后，换模型解决不了。
- 误区：专有名词搜不到，把 Top-k 调大就能捞到。 向量检索对精确字符不敏感，调大 Top-k 只会引入更多噪声，要补一路关键词检索。
- 误区：检索到了正确片段，答案就一定对。 片段排在中间容易被模型忽略，还可能被前面的相似片段带偏，需要重排把它提到前面。
- 误区：片段大小调到一个合适的值就能兼顾。 检索要小块、生成要大块，两个要求方向相反，单一尺寸无解，要用父子分块拆开。
- 误区：四个手段全打开效果最好。 每一项都在用耗时和成本换准确率，要用评测数据证明提升，再按场景决定开哪几项。
- 追问：重排为什么不能直接对全库做？ 交叉编码要把问题和每个片段拼在一起过一遍模型，全库扫描的成本不可接受，只能对粗筛后的十几条做精排。
- 追问：多轮对话的第二个问题为什么不能直接拿去检索？ 「那超期了呢」这类问题缺主语、缺主题词，编码出的向量指向不明，必须先结合历史补全成独立问题。
九、加强记忆
基础 RAG 的上限由检索决定，四个失效点全在检索环节，按「字、序、话、块」记：字——型号编号靠字符不靠语义，向量认不出，补 BM25 做混合检索、RRF 按名次融合；序——向量比的是整体像不像，答案排在中间被忽略，用重排交叉编码精排；话——用户口语和文档腔对不上、多轮问题缺主语，用多查询扩展、指代消解、HyDE 改写；块——检索要小块、生成要大块，用父子分块让子块找、父块答。另外，新旧版本混在一起属于范围太大，用元数据过滤收住。每个手段都有耗时和成本，开不开要拿评测集上的分数和耗时说话。
项目实战落地
项目里怎么做的
《AI Agentic RAG高级企业知识库平台》就是按这四个失效点组织的：先用基础 RAG 把链路跑通，再专门用一章拆解四个失效点，之后每个失效点对应一项能力，全部做成检索策略表 retrieval_strategy 里的开关：
| 失效点 | 项目里的开关 |
|---|---|
| 专有名词搜不到 | vector_enabled、bm25_enabled、rrf_k：向量 + BM25 双路召回，RRF 融合；中文分词额外拆开字母数字连写的型号 |
| 答案排在后面 | rerank_enabled、rerank_top_n：接入百炼 gte-rerank-v2 重排 |
| 问法对不上 | query_rewrite_enabled、rewrite_type：多查询扩展、指代消解、HyDE 三选一 |
| 片段大小两难 | parent_recall_enabled：配合「父子分块」切分策略做父块回填 |
项目预置了三套策略：「基线-纯向量检索」「进阶-混合检索」「完整-混合检索加重排加改写」。召回对比调试台能把最多四套策略并排跑同一个问题；同一批评测用例上，基线的综合分是 0.7988，完整策略是 0.9616。
为什么这样取舍
- 每项能力都做成开关。 全部关掉就退化成基础 RAG，逐项打开就能看到每一项到底带来多少提升，而不是凭感觉说「变好了」。
- 先有基线再加手段。 没有纯向量这条基线，就没法证明后面任何一项优化有效。
面试官还会追问
- 这些手段都打开不是最好吗？项目里怎么判断该开哪几项？
- 一次检索里，查询改写、双路召回、RRF、重排、父块回填、阈值过滤这几步的先后顺序为什么这样排？
- 同一个问题，怎么直观地看出四套策略各自召回了什么、差在哪一步？
学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。