为什么很多企业知识库 Demo 能用，上线后却没人用
概要
企业知识库项目最常见的错觉是：上传几份文档，问几个预先准备好的问题，模型回答得像模像样，于是大家认为项目已经完成了大半。
但 Demo 能回答，不等于系统有人用；有人试用，也不等于能够进入真实业务流程。
我参与过企业智能问数、卡片检索和诊断报告类 AI 应用的设计与交付。实践中真正困难的部分通常不是“把向量数据库接上”，而是让知识、检索、权限、评测和业务动作形成一个可以长期运营的闭环。
本文总结企业知识库从 Demo 走向生产时最容易忽略的五个问题。
一、Demo 验证的是技术链路，用户需要的是任务结果
一个典型知识库 Demo 的链路是：
这条链路只能证明系统“可以根据文档回答问题”。真实用户的任务却往往是：
- 找到某个指标对应的权威口径；
- 对比不同区域或时间段的数据；
- 定位原始材料、页签和责任人；
- 生成一份可以继续编辑或提交的报告；
- 根据答案触发查询、审批或诊断动作。
如果系统最终只返回一段聊天文本，用户仍然需要自己核对来源、复制内容、寻找页面并完成后续操作。相比原来的搜索和业务系统，它不一定更省时间。
因此，设计知识库前应该先问：用户要完成什么任务，而不是用户可能会问什么问题。
二、召回“相关内容”不等于找到“正确答案”
向量召回擅长寻找语义相似内容，但企业知识中经常存在大量“看起来相似、业务含义不同”的资料：
- 同一指标存在集团、区域、产品线等不同口径；
- 同一制度存在多个历史版本；
- 相同名称在不同组织中含义不同；
- 一个问题同时包含时间、区域、对象和统计口径等约束。
只依靠语义相似度，很容易召回一段“相关但不适用”的内容。
我更倾向于将企业检索拆成多阶段流程：
这里最有价值的往往不是某个模型参数，而是企业自己的维度体系、指标字典、版本规则和权限模型。
三、没有可验证来源，回答越流畅风险越高
企业用户很少愿意仅凭一段自然语言回答做决策。他们通常还需要知道：
- 答案来自哪份材料；
- 材料是否仍然有效；
- 引用的是哪个章节或数据行；
- 自己是否有权限查看原文；
- 当多个来源冲突时，以哪个为准。
所以生产级知识库至少应该提供：
- 文档名称、版本、更新时间和责任人；
- 可点击的段落级引用或业务页面定位；
- 权限过滤后的原文片段；
- “没有足够证据”时明确拒答；
- 对数字、日期和关键结论进行结构化校验。
知识库的目标不是让模型“永远有话说”，而是让用户知道哪些内容可信、哪些内容需要人工确认。
四、没有评测闭环，优化只能靠感觉
很多团队上线前只准备十几个演示问题。演示问题通常由开发人员编写，表达标准、答案明确，无法代表真实用户。
更有效的方式是建立持续扩充的评测集：
| 评测维度 | 关注点 |
|---|---|
| 意图识别 | 是否理解用户真正想完成的任务 |
| 维度解析 | 时间、区域、指标、口径是否正确 |
| 召回质量 | 正确材料是否进入候选结果 |
| 答案忠实度 | 结论是否有来源支持 |
| 业务可用性 | 用户是否能直接完成下一步操作 |
| 拒答能力 | 信息不足时是否避免编造 |
线上出现 Bad Case 后，不要只修改 Prompt。先判断问题属于数据、切分、元数据、召回、权限、编排还是生成，再针对对应环节优化。
五、知识库必须有人运营
知识不是一次性导入的静态资产。组织架构、制度、产品、指标口径和业务数据都会变化。如果没有明确的运营机制，系统会快速积累：
- 已失效但仍能被召回的旧文档；
- 重复或互相冲突的内容；
- 无法确定责任人的资料；
- 长期没有访问的低价值知识；
- 用户频繁提问但知识库始终缺失的主题。
生产系统应该建立最基本的治理机制：知识负责人、有效期、版本状态、访问统计、用户反馈和缺口补充流程。
从 Demo 到可用系统的检查清单
上线前可以用下面的问题做一次快速检查：
- 用户能否通过系统直接完成一项业务任务？
- 回答是否包含可核验的来源和版本？
- 检索是否理解时间、区域、对象和业务口径？
- 权限是否在召回前生效，而不是生成答案后再遮挡？
- 是否有覆盖真实表达的评测集？
- Bad Case 能否定位到具体链路环节？
- 谁负责知识更新、下线和冲突处理？
如果这些问题大部分没有答案，项目还只是一个技术 Demo。
结语
企业知识库的核心竞争力不是“接入了哪个大模型”，而是能否把可信知识嵌入真实任务，并且持续评测和运营。
我目前接受少量企业知识库、智能问数、自动报告和 AI 工作流的远程技术评估与 PoC 合作。对于已有 Demo 但使用效果不理想的项目，也可以先从一次链路诊断开始，梳理数据、检索、评测和业务集成问题。