title: " AI排查RAG召回差 | Chunk和Rerank" category: 人工智能 tags:

很多人做企业知识库，第一反应是：

模型回答不好，是不是模型不够强？

不一定。

RAG 系统回答差，更多时候不是生成模型的问题。

而是：

根本没召回正确资料。
召回了但片段太碎。
召回了过期文档。
过滤条件把正确文档排除了。
Rerank 没把关键证据排前面。
答案没有引用证据。

这类问题非常适合用 AI 排查。

但要把 RAG 链路拆开。

1. RAG 先看三件事

用户 query。
召回片段。
最终答案。

如果最终答案错，先不要怪模型。

先问：

正确答案所在文档有没有进入召回结果？
进入了第几名？
片段是否完整？
模型有没有引用它？

这四个问题决定排查方向。

2. 给 AI 的 RAG 排错包

【用户问题】
- query：
- 预期答案：
- 业务场景：

【召回结果】
- top_k：
- 每个 chunk 的文档名、分数、内容摘要：
- 是否包含正确答案：

【Rerank】
- rerank 后排序：
- 分数：
- 被提到前面的片段：

【最终答案】
- 模型回答：
- 引用证据：
- 是否胡编：

【配置】
- chunk size：
- overlap：
- embedding 模型：
- filter 条件：
- 权限过滤：

【边界】
- 不把用户隐私和内部机密原文外发
- 先分析召回，不先换大模型

3. 常见根因一：Chunk 切得太碎

如果 chunk 太小，模型看到的是：

半句话。
缺上下文。
只看到结论，看不到条件。

比如制度文档里写：

试用期员工不适用该假期政策。

如果切分把“试用期员工”切到上一段，答案就会错。

AI 可以审查：

当前 chunk 是否包含完整问答语义。
是否缺标题、章节、前置条件。

修复：

按标题切分。
保留章节路径。
增加 overlap。
把表格行和表头一起保留。

4. 常见根因二：过滤条件错

企业知识库常有权限过滤：

department = sales
tenant_id = xxx
doc_status = published
language = zh

如果过滤条件错，正确文档根本进不来。

这不是模型问题。

是检索条件问题。

让 AI 看：

query。
filter。
正确文档 metadata。
召回结果 metadata。

Prompt：

请判断正确文档是否被 filter 排除了。
如果是，请指出具体 metadata 条件，而不是建议换模型。

5. 常见根因三：没有 Rerank

Embedding 召回的 top_k 里可能有正确片段。

但排在第 9 名。

生成模型只看前 3 个。

答案就错。

解决：

增加 top_k。
加 rerank。
让答案模型看到 rerank 后前 N 条。
记录正确证据排名。

Fable 5 可以帮你审查：

哪些 query 需要 rerank。
哪些 query 是精确关键词。
哪些 query 是语义问答。

6. 4SAPI 分工

RAG 系统里不同模型分工：

阶段 模型
Query 改写 中低成本模型
Embedding 专用向量模型
Rerank Rerank 模型
答案生成 中高能力模型
复杂失败分析 Fable 5
日志总结 低成本模型

4SAPI 记录：

query_id
embedding_model
rerank_model
answer_model
top_k
hit_rank
answer_has_citation
cost

7. 做一个小型 RAG 评测集

不要只凭一次问答判断 RAG 好坏。

建议先做 20-50 条小评测集。

每条包含：

问题。
标准答案。
正确文档。
正确 chunk。
必须出现的证据。
不应该出现的错误答案。

然后记录：

正确 chunk 是否召回。
正确 chunk 排名。
最终答案是否引用证据。
答案是否完整。
是否出现幻觉。

让 AI 帮你分析评测结果：

请根据这批 RAG 评测记录，按失败类型聚类。
区分：未召回、召回排名低、证据冲突、答案没引用证据、文档过期。
每类给一个代表问题和修复建议。

这类分析用 Fable 5 很合适。

因为它需要看多个失败案例里的共同模式。

8. 引用检查很重要

企业知识库不要只看答案对不对。

还要看：

答案是否能指回证据。
证据是否真的支持结论。
引用的文档是否过期。
引用是否越权。

可以让模型每次回答后再跑一个轻量检查：

请检查答案中的每个关键结论是否被引用片段支持。
输出：支持 / 部分支持 / 不支持。
不要补充新知识，只基于给定证据判断。

这个检查不一定要用 Fable 5。

中等模型就能做。

但如果是法务、财务、医疗、企业制度这类高风险知识库，建议 Fable 5 或人工复核。

9. 排查样例：正确文档在第 8 名

一个很常见的 RAG 事故是：

正确文档其实召回了，但排得太后。

比如用户问：

4SAPI 项目预算超过 80% 后会不会自动停用？

召回结果里：

第 1 名：模型价格说明。
第 2 名：Key 创建教程。
第 3 名：调用日志字段。
第 8 名：预算告警和停用策略。

如果答案模型只看前 3 条，它就可能编一个“会自动停用”或者“不会自动停用”。

这时不要急着换 Fable 5。

先让 AI 分析：

为什么正确 chunk 排在第 8 名？
query 是否需要改写？
chunk 标题是否缺失？
metadata 是否没有标 budget？
rerank 是否把“价格”误认为“预算”？

修复可能是：

给预算文档补标题路径。
把“预算、额度、用量、停用、告警”加入同义词。
top_k 从 5 提到 20，再 rerank 到 5。
答案模型只允许基于 rerank 后证据回答。

4SAPI 在这里可以记录答案模型，但 RAG 系统自己也要记录：

query_rewrite
retrieved_doc_ids
hit_rank
rerank_top_ids
answer_citation_ids

当你有了这些字段，Fable 5 才能做真正的链路诊断，而不是凭最终答案猜原因。

10. AI Prompt

你是 RAG 召回质量排查助手。

请根据用户问题、预期答案、召回片段、rerank 排序、最终答案和检索配置，判断问题属于：
1. 文档未入库
2. chunk 切分不合理
3. embedding 召回差
4. filter 或权限条件错误
5. rerank 缺失或排序错误
6. 答案模型没有使用证据
7. 文档过期或冲突

要求：
- 不要先建议换更贵模型。
- 先判断正确证据是否被召回。
- 每个结论引用 chunk 或 metadata 证据。

11. 总结

RAG 回答差，先看召回。

不要先换模型。

AI 排查 RAG，关键是把链路拆成：

query -> retrieve -> filter -> rerank -> answer -> citation

4SAPI 可以把各阶段模型、成本和效果记录下来。

Fable 5 适合做复杂失败分析。

一句话：

模型没看到正确证据，再强也会答偏。