RAG落地复盘：让企业知识库真正可用的五件事

很多团队的 RAG 项目停留在"PPT 可用"阶段：Demo 完美，生产拉胯。

我们的知识库问答项目迭代了九个月，检索准确率从 58% 提升到 89%。这篇文章复盘真正起作用的五件事——都是不起眼的脏活累活。

第一件事：文档清洗比算法重要

我们的知识库里有 Word、PDF、扫描件、PPT，还有各种带批注的历史版本。直接灌进向量库的结果是：检索回来一堆"目录页"和"页眉页脚"。

清洗管道我们做了四层：

1. 格式归一：统一转 Markdown，保留标题层级
2. 结构识别：表格单独抽取，QA 对独立成块
3. 去噪：删除页眉页脚、水印文字、审批流信息
4. 版本对齐：同一文档只保留最新生效版本，旧版本标记 deprecated

仅做文档清洗，检索准确率就提升了 11 个百分点。垃圾进，垃圾出，向量数据库救不了脏数据。

第二件事：分块没有银弹，但要先定策略

网上流行各种"最佳 chunk 大小"，实测结论是：分块策略必须跟着文档类型走。

• 政策类文档：按章节分块，保留完整条款
• FAQ 类：一个 QA 对一个 chunk
• 操作手册：按步骤序列分块，块间保留顺序元数据

我们的分块器会先识别文档类型，再选择对应策略，而不是一把 chunk_size=512 走天下。

第三件事：混合检索是必选项

纯向量检索对精确匹配很弱——用户搜"2024年3月修订的报销制度"，向量检索可能召回一堆语义相似但日期错误的内容。

我们最终的方案是 BM25 + 向量检索双路召回，再用 RRF（Reciprocal Rank Fusion）融合，再加一层基于元数据（部门、日期、文档类型）的过滤。这套组合拳让"精确查找类"问题的准确率提升了 17 个点。

第四件事：给检索结果做"质检"

上线后我们发现一个隐蔽问题：检索明明是对的，但答案引用时张冠李戴。解决方案是给 LLM 的生成阶段加约束：

• 每句话标注来源 chunk
• 生成后校验引用与原文的一致性
• 不一致的部分标记为"低置信"，前端弱化展示

第五件事：建立 badcase 闭环

RAG 是运营型系统，不是交付型项目。我们配了专职同学每周分析 badcase，归因到"清洗问题/分块问题/检索问题/生成问题"四类，分别回流到对应环节。没有闭环的 RAG 会以每月 2-3 个百分点的速度劣化——知识库在更新，而你的系统在变笨。

一张图总结

脏文档 → [清洗管道] → 结构化语料 → [类型感知分块] → 索引
                                                         ↓
用户问题 → [查询改写] → 混合检索(BM25+向量) → RRF融合 → 重排 → 生成(带引用) → 质检
     ↑______________________ badcase 周报闭环 ______________________|

RAG 的技术门槛在降低，数据治理和持续运营的能力才是护城河。