夜雨聆风你的 AI 知识库为什么总是"答非所问"？
——一个搜索算法打工人的 RAG 故障排查手册
---
开头先讲个真实的场景
某中型制造业公司，老板花了快 60 万做了一个"AI 知识问答系统"：接入了最新的大模型、买了向量数据库、找了外包团队定制了前端，上线时还开了内部发布会。
运营团队去食堂调研，得到的反馈高度一致：
> "问它报销流程，它给我返了一段十年前的规章。"
>
> "让它查某型号的参数，它信心满满地编了一个不存在的数值。"
>
> "还不如在群里 @ 一下老王来得快。"
---
先说结论
做了 8 年搜索和排序，看过不下 50 个企业 RAG 系统的案例，我可以很负责任地说一句：
**AI 知识库"答非所问"，绝大多数情况下不是模型的问题。**
从工程实战里看，RAG 系统的故障大致是这样分布的：
约 70% 来自数据层和检索层（数据本身、切分、向量化、召回、重排） 约 20% 来自 Prompt 和上下文组装（怎么把召回的内容喂给模型） 只有约 10% 真的和大模型本身的能力有关
下面我把这条流水线上最常出问题的 7 个环节拆给你看。这是我自己内部做诊断时用的清单，你也可以照着自查。
---
01 数据质量：你喂给系统的原料本身就是坏的
知识库里同时塞着 v1、v2、v3 的文档，没做去重和版本管理 PDF 解析质量差——表格结构丢失、图片里的文字完全读不到、双栏排版被错误地按行拼接 内部术语和缩写没有归一化（"北京仓"、"京仓"、"BJ Warehouse" 在系统眼里是三个东西） 过期内容没设置归档策略，新老政策混在一起被召回
---
02 文档切分：切得太大或太碎
盲目按固定长度切分（比如"每 512 token 一段"） 不考虑语义边界——小节标题和内容被分开、表格被切成两半、代码块从中间断掉 对所有文档类型用同一套切分策略
结构化切分：按章节 / 小节 / 段落的自然边界切 多粒度索引：同一份文档建 "细粒度段落 + 粗粒度章节" 两套索引，召回时先粗后细 父子块关系：召回的是子块，但喂给模型的是父块的上下文
这一步做得好不好，直接决定了 Top-K 召回的质量天花板。
---
03 向量模型：你用的 Embedding 和你的业务根本不在一个语义空间
直接拿通用 Embedding 模型（bge、m3e、text2vec 等）去处理专业领域（医疗、金融、法律、制造业） 中英文混合语料用了单语模型 从未在自己的业务语料上做过适配或微调
用业务语料做对比学习微调（难负例挖掘） 构建业务查询-文档对齐的评测集，定期测 Embedding 的召回命中率 如果预算有限，至少做领域适配（domain adaptation）
---
04 检索策略：只靠向量检索是在漏召回
只用向量检索，不做混合检索（Hybrid Retrieval） 没有关键词检索（BM25）兜底——而很多时候用户的 query 就是明确的关键词（如"2024 差旅标准"） 没用上元数据过滤（时间、部门、文档类型、机密等级）
多路召回 + 融合：
Vector Recall：语义相似召回 BM25 / 关键词 Recall：精确词匹配 Metadata Filter：先用业务属性过滤掉不相关的大头 RRF 或加权融合 多路结果
这一步做好之后，通常召回命中率（Recall@20）能从 60% 提升到 85% 以上。
---
05 重排（Reranking）：Top-1 准确率低得可怕
压根没做 Rerank，直接把召回 Top-5 丢给模型 做了 Rerank 但选了通用的弱模型 Rerank 模型和召回模型的"口味"打架
用专门的 Cross-Encoder Rerank 模型（bge-reranker-v2、Cohere Rerank 等） 对召回的 Top-50 做精排，输出 Top-3 或 Top-5 给大模型 定期用 bad case 反推、评估 Rerank 的 NDCG@3
Rerank 这一步在搜索系统里价值极高，很多团队做完了立刻就有可感知的效果提升。
---
06 Prompt 和上下文组装：把一堆段落乱堆给模型
直接把召回的段落拼在一起塞进 Prompt，没有结构化标注 没有引用机制（模型无法告诉用户"我是根据第几段说的"） 没有冲突处理逻辑（两段说法相反的上下文同时出现时，模型就乱说） System Prompt 太弱，没严格约束"只基于给定上下文回答，不知道就说不知道"
```
System: 你只能基于下列上下文回答。
每一条回答都必须标注引用的段落编号。
如果上下文无法支撑结论，请直接回答"根据现有资料无法确定"。
Context:
[1] 来源: 员工手册 v3.2, 第 4.2 节
内容: ...
[2] 来源: 财务报销制度 2024 版, 第 3 章
内容: ...
User query: ...
```
关键动作包括：
每段上下文带 source id + 出处 + 章节 强制模型在回答末尾列出引用 建立 abstain 机制：无把握就拒绝回答，而不是幻觉
---
07 评测体系：没评测就是在瞎调
没有固定的评测集 只看总体准确率，不分维度 从不做 bad case 归因分析（到底是召回挂了、Rerank 挂了、还是生成挂了）
构建 100-300 条代表性评测集（覆盖高频场景、长尾场景、边界场景） 分维度评测：召回命中率 Recall@K、Rerank Top-1 准确率、回答准确率、引用准确率、幻觉率 每次迭代跑一遍评测集，生成对比报告 对每一条 bad case 做归因：到底挂在 7 个环节中的哪一环
**一句话：RAG 系统没有评测体系，就像开车不看仪表盘——你不知道自己是在进步还是在退步。**
---
给你的自检清单：企业 RAG 健康度体检（10 个 Yes / No）
如果下列问题中，你的 "Yes" 少于 6 个，你的知识库系统大概率有明显优化空间：
你知道自己的 **Recall@20 命中率**是多少吗？ 你有没有一个**固定的评测集**，每次改动后都跑一遍？ 你是否做了**混合检索**（Vector + BM25 + Metadata）？ 你是否用了**专业的 Rerank 模型**对 Top-20 做精排？ 你的 Embedding 模型是否**在业务语料上做过适配**？ 你的文档切分是否考虑了**语义边界和表格结构**？ 每个召回段落是否带了**来源编号和章节信息**？ 回答里是否有**引用标注**，可以让用户跳转到原文校验？ 遇到上下文冲突或信息不足时，系统是否有**拒绝回答机制**？ 你有没有定期做 **bad case 归因**，区分是召回挂了还是生成挂了？
---
结尾：免费帮 3 家公司做一次诊断
写这篇文章的初衷，是最近帮几个朋友公司看他们的 AI 知识库，发现这些问题实在太普遍了——几乎每一家都在重复同样的几种坑。
当前系统在上述 7 个环节的健康度打分 明确定位问题最严重的 2-3 个环节 给出短期（2 周内可落地）和中期（1-2 个月）的优化路径 附评测集搭建方法和基线指标建议
已经上线了 AI 知识库 / 问答系统，但效果不达预期的团队 正在规划 RAG 项目，想先避坑的团队 企业内部有知识管理、客服、培训等场景需求
愿意提供一定量的真实 query 和召回日志（可脱敏） 能有一次 60 分钟的沟通会议 案例可脱敏后用于分享（不涉及公司名和具体业务数据）
---
关于我 · 关于 TAO AI LAB
搜索算法 + 排序系统 + 大模型应用，搬了 8 年砖。
做过电商、内容、信息流三种场景的搜索和排序，现在专注在企业级 RAG 和 AI 应用的诊断与优化上。
其他渠道：
小红书：TAO AI LAB（轻量内容） 即刻：TaoTao.搜索AI算法打工人（日常思考）
欢迎关注本公众号（TAO AI LAB）获取更多深度内容。
---
*如果这篇文章对你有帮助，欢迎转发给同样在做 AI 知识库的朋友。*
*下一篇预告：《企业 RAG 系统的评测集怎么构建？一份 100 条 eval set 的搭建手册》*
