企业为什么做 RAG 知识库容易失败

Demo 好看，不等于能上线

企业做 RAG 知识库时，最常见的场景是：先拿一批 PDF、Word、网页资料做 Demo，上传之后能问答，现场效果不错，于是大家觉得项目快成了。

但真正上线后，问题会立刻出现：

• 同一个问题不同人问，答案不稳定。
• 引用来源不清楚，员工不敢相信。
• 文档版本混乱，旧制度和新制度一起被检索出来。
• 权限没有设计，敏感资料可能被不该看到的人问出来。
• 没有评测指标，无法判断系统到底有没有变好。
• 没有人负责持续更新，知识库很快过期。

这些问题不是换一个向量数据库就能解决的。

失败原因一：需求太泛

“我们想做一个企业知识库”不是一个合格需求。

合格需求应该更具体：

• 给谁用？
• 解决什么场景？
• 问题从哪里来？
• 答案需要多准确？
• 错了谁负责？
• 哪些资料能用，哪些资料不能用？
• 是否需要引用来源？
• 是否需要人工复核？

如果这些问题没问清楚，RAG 项目就会变成一个看似什么都能答、实际什么都不可靠的系统。

失败原因二：文档没有治理

RAG 的效果很大程度取决于文档质量。

很多企业的资料并不是“知识”，而是一堆文件：

• 文件名不规范。
• 版本不清楚。
• 同一件事有多个说法。
• 表格、图片、扫描件混在一起。
• 制度、通知、会议纪要没有层级。
• 过期内容没人标记。

如果不做文档治理，模型只是更快地把混乱暴露出来。

文档治理至少要包含：

• 文档分类。
• 版本管理。
• 权限分级。
• 元数据标注。
• 过期内容处理。
• 高频问题映射。

失败原因三：只看召回，不看答案

很多团队做 RAG 时，会把注意力放在向量检索、相似度、切片大小上。这些很重要，但不是全部。

用户最终看到的是答案，不是召回片段。

一个可上线的 RAG 系统，至少要评估：

• 有没有答对。
• 有没有引用来源。
• 有没有编造。
• 有没有遗漏关键条件。
• 有没有违反权限。
• 用户是否愿意继续用。

没有评测集，就没有持续优化。没有持续优化，知识库只能停留在 Demo。

失败原因四：没有运营机制

企业知识库不是一次性项目，而是持续运营系统。

上线后必须有人负责：

• 新文档进入。
• 旧文档下线。
• 高频问题整理。
• 错误答案修正。
• 用户反馈收集。
• 每月评测复盘。

如果没人运营，RAG 系统会随着业务变化慢慢失效。

正确的启动方式

我更建议企业先从一个小场景开始，而不是一上来做全公司知识库。

适合试点的场景：

• 客服常见问题。
• 销售产品资料。
• HR 制度问答。
• 项目交付文档。
• 内部 IT 支持。

试点目标也要清楚：

• 减少多少人工问答。
• 提高多少响应速度。
• 覆盖多少高频问题。
• 错误率控制在什么范围。
• 哪些答案必须人工确认。

这门课解决什么

“企业 RAG 知识库落地课”要解决的不是教你搭一个炫技 Demo，而是帮你判断：

• 这个项目该不该做。
• 应该从哪个场景开始。
• 文档该如何整理。
• 架构该如何设计。
• 效果该如何评估。
• 上线后该如何运营。

RAG 项目真正的难点不是技术组件，而是把企业知识变成可以被机器稳定使用、也能被人信任的系统。