RAG 在企业知识库中的实战：我们踩过的坑和填平的路

3月份帮一家集团客户搭企业知识库，上线第一个月，用户反馈里出现频率最高的一句话是：

"它回答得挺流畅，但我知道它错了。"

文档是自家文档，答案却对不上版本；制度问答引用的条款已经废止；合同审查漏掉了关键段落。老板问我们："不是把文档喂给大模型就行了吗？怎么这么多问题？"

这句话，我们几乎在每个 RAG（检索增强生成，Retrieval-Augmented Generation）项目里都听到过。

今天不讲理论，只讲我们踩过的四个坑，和每一条被填平的路。

一、第一个坑：文档进来就是脏的

现象：把几百份 PDF、Word、扫描件直接丢进知识库，答案经常"答非所问"。

原因：企业文档从来不是为机器准备的。制度文件的表格、合同里的夹行注释、扫描件的倾斜页面、老版本和新版本的混放——这些在"人工检索"时代靠人眼过滤掉的噪音，在 RAG 里会原样传给大模型。

填平的路，我们做了三件事：

1. 结构化解析，而不是"提取文字"：PDF 走版面分析（layout analysis），把标题、表格、页眉页脚分开处理；表格单独转成 Markdown 结构，而不是压成一段文字流。
2. 扫描件必须过 OCR + 版面还原：纯文字抽取会把多栏排版读成一锅粥，要按阅读顺序重组段落。
3. 入库前先做"元数据登记"：每个文档打上来源部门、版本号、生效日期、适用范围的标签。这是后面所有检索质量的地基，没有元数据的知识库，等于没有索引的图书馆。

二、第二个坑：分块"一刀切"

现象：按固定字符数切块（比如每 512 字一刀），结果一个完整条款被拦腰切断，检索时永远只能捞到"半句话"。

原因：固定长度分块（chunking）实现简单，但语义边界会被粗暴割裂。你问"请假超过 3 天的审批流程"，向量检索命中的却是"3 天"所在的半截段落，上下文缺失，答案自然残缺。

填平的路，核心是"按语义切，而不是按字数切"：

• 标题/段落感知分块：以文档结构（章节、条款、段落）为边界，先切大块，再按需要细分。
• 父子分块（Parent-Child Chunking）：检索用小块（命中精准），喂给模型用大块（上下文完整）。小块负责"找到"，大块负责"讲清"。
• 保留重叠窗口：相邻块之间保留少量重叠文本，避免边界内容被遗漏。

这个改动，单点命中率往往能提升 20%-40%，是所有坑里性价比最高的一步。

三、第三个坑：只靠向量检索，召回质量全靠运气

现象：用单一向量模型做相似度检索，问"报销流程"能查出来，问"差旅费怎么报"就查不到了——同一个意思，两种说法。

原因：纯向量检索擅长语义相近的匹配，但企业知识库里有大量精确匹配的需求：编号、型号、金额、法规条款。这些恰恰是向量模型的弱项；反过来，纯关键词检索又抓不住语义。

填平的路，是组合拳：

1. 混合检索（Hybrid Search）：向量召回 + 关键词召回（BM25）并行，各取所长。
2. 重排（Rerank）：召回 Top 50，用交叉编码器（cross-encoder）重排到 Top 10 再喂给模型。这一步通常能再提升 10-15 个百分点的答案准确率。
3. 分域检索：按元数据限定检索范围——问制度只搜制度库，问合同只搜合同库，别让无关内容进来干扰。

检索不是"越全越好"，而是"越准越好"。宁可靠后精确的 3 段，不要模糊相似的 10 段。

四、第四个坑：上线即终点，库是死的

现象：知识库上线那天效果不错，三个月后开始"胡说"——因为文档更新了，库没更新；业务变化了，答案还停在过去。

原因：企业知识是活的。制度改版、产品迭代、人事变动，都在持续发生。把 RAG 当成一次性交付物，是最大的认知误区。

填平的路，把它当产品运营：

• 建立更新管道：文档变更走版本管理，增量更新向量库，而不是整库重建。
• 建一套评测集（Eval Set）：沉淀 200-500 条真实业务问答，每次改版先跑评测集，答对率回落就回滚。
• 接反馈闭环：用户在答案下方点"不对"，反馈回流成新的标注数据，持续优化。

RAG 项目真正的分水岭，不在上线那天，而在上线后的第 90 天。

给你的判断标准：先做这三件事

如果你是今天要启动企业知识库的负责人，不必一步到位，先做三件事：

1. 先治理数据，再谈模型：把最高频使用的 50 份核心文档做结构化解析和元数据登记，比接入再强的模型都值钱。
2. 用 100 条真实问题定基线：上线前先答 100 个真实业务问题，记录答对率；之后每一次优化，都和这个基线比。
3. 把"引用"做成硬指标：要求每个答案必须带出处。没有引用的答案，再流畅也不算数——这是企业场景和 C 端聊天的本质区别。

这三件事，决定了一个知识库是"演示级"还是"生产级"。

这些坑，我们在不同客户的私有化环境里反复踩过、填平、再验证。企业 RAG 从来不是"文档丢进去、答案吐出来"的魔法，而是一套从解析、分块、检索到持续运营的工程体系。

而这套体系，恰好是我们团队日常在做的事：不做 demo，做能跑在核心业务上的工程。

JOTO 企业落地观察

• 企业知识库的元数据登记不是可选项，而是 RAG 检索精度的底层前提；缺乏部门、版本、生效日期等字段，意味着无法支撑制度类、合同类等强时效性场景的精准召回。
• 父子分块与重排机制的引入，本质是将 RAG 从“单次检索”转向“两级决策”：小块承担快速定位，大块保障语义完整性，这对智能体调用知识时的上下文稳定性至关重要。
• 评测集（Eval Set）的建立标志着知识库从项目交付进入产品化阶段；200–500 条真实业务问题构成的基线，是衡量每次模型或数据迭代是否真正带来业务价值的唯一客观标尺。
• 将用户“点不对”反馈自动回流为标注数据，使知识库具备自进化能力；这种闭环机制能否落地，取决于企业是否已建立轻量级的数据治理流程，而非仅依赖技术工具。