上线那天通常很热闹。
演示的时候问什么答什么，界面干净，回答流畅，领导点头。会后群里发了一轮截图，项目就算成功了。
三个月后再看后台，日活个位数，提问集中在最初那几天，之后再没有增长。半年后这个系统还挂在门户里，成了汇报材料上的一行字：已建成企业 AI 知识库。
没人删它，也没人真用。
先看几个不太好听的数字
这不是个别现象。行业内已经积累了足够多的样本。
员工每周大约有 20% 的工作时间花在找内部信息上，而企业搜索的首次成功率只有 10% 左右。也就是说，大部分人找了半天，第一次没找到，只能去问人。
Gartner 的判断是最多 50% 的生成式 AI 项目在概念验证之后被放弃。MIT 的一项调研结论更直接：95% 的生成式 AI 试点没有产生可测量的利润影响。
具体到知识库这一类项目，采用率在六个月内往往低于全体员工的 10%。这个数字和二十年前企业内部门户、知识管理系统的失败曲线几乎重合。
值得注意的不是「失败很多」，而是「失败方式一模一样」。说明这不是技术成熟度问题，是设计前提的问题。
大多数方案押在三个假设上，而企业知识三条都不成立
现在主流的做法是把文档切块、向量化、按相似度召回、交给大模型拼答案。这套流程本身不复杂，复杂的是它默认的三件事。
第一个假设：文档是自足的。一份三十页的员工手册，第五章的条款依赖第一章的定义。切块之后，这个依赖关系就断了。模型看到的是「看起来相关」的碎片，它不知道这块碎片的前提是被另一块碎片定义的。
第二个假设：语义相似就是相关。向量检索擅长找「说得像」的内容，但它不理解权威性。一份经董事会批准的制度，和一份中层随手写的备忘，在向量空间里没有区别。一份三年前的正确政策，和一份上周更新过的政策，也没有区别。
第三个假设：检索结果可以直接用。这个假设在企业环境里最危险，因为企业知识的价值恰恰在于「哪个版本现在有效」。
换句话说，通用检索优化的是「找到相关内容」，企业需要的是「找到当前有效、经过批准、适用于这个场景的那一份」。这两个目标不一样。
四个维度上，普通检索都是缺的
把问题拆细一点会更清楚。
出处。用户需要知道答案来自哪份文件、哪个版本、谁批准的。是现行制度还是已废止的旧规，是原始来源还是二手总结。向量库通常不保存这些信息，所以模型也不知道。
关系。文件不是孤立的。一份程序文件引用了某个标准，一份作业指导书属于某个工序，一份检验规范对应某个客户要求。这些关系承载了大量含义，而相似度检索表达不了关系。你问「这个流程是谁批准的」，它可能检索到流程文件本身，却找不到存在另一个系统里的审批记录。
时效。企业知识会变。向量库不天然知道哪份是最新的，也不天然知道旧版该不该继续被引用。你在元数据里加了时间戳也没用，因为默认的检索机制根本不用这个字段。结果就是系统很自信地引用两年前正确、现在错误的内容。
结构。有些知识天生是表格，有些是层级，有些是决策树。强行切成散文块，会把一张完整的报价表切成两半，检索回来只有上半张。
这四个缺陷不是靠换更大的向量库、换更好的 embedding 模型能解决的。因为它们不在检索精度这一层，在知识建模这一层。
数据质量是乘数，不是加数
还有一个更上游的问题：喂进去的东西本身是什么状态。
公开的企业文档，大部分不是为「回答问题」写的。汇报用的 PPT 是为了讲，存档用的 Word 是为了留，wiki 是三年前某个人写的、那人已经离职了，流程图是为了过审画的。
真正准确的版本，往往在几个老师傅脑子里。他们没有时间写，也没有动力写——把经验写下来，等于让自己变得可替代。
这就形成了一个残酷的乘数效应。同样的架构，跑在未经筛选的内容上，错误率会被放大；跑在整理过的内容上，表现会好很多。有数据治理研究给出的对比是：未筛选内容上的编造率达到 52%，而精选内容上接近零。
连最专业的团队也逃不掉这个规律。斯坦福 RegLab 和 HAI 对几款主流法律 AI 检索工具做过基准测试，幻觉率在 17% 到 33% 之间。这些产品由 LexisNexis、Thomson Reuters 这类公司开发，语料完全在自己手里，仍然做不到可靠。
所以问题不是「你的模型够不够强」，是「你的语料配不配被检索」。
信任是一次性的
这一点最容易被低估。
用户第一次得到一个自信但错误的答案，会去核实，然后发现不对。第二次再遇到，他会开始怀疑。第三次之后，他就不用了。
关键在于，AI 答错和答对的样子是一样的。都那么流畅，都那么有把握。一个会犯错但你知道它什么时候可能犯错的工具，是工具；一个会犯错但你不知道它什么时候在犯错的工具，是负债。
而用户不会给第二次机会。他不需要理解你的召回率从 72% 提到了 81%，他只知道上次问年假政策，答案引用的是去年的规定。
一个具体的、成本很低的改法
有个做法我很认同，而且不需要重做系统：给每份文档加两个字段，责任人和复审到期日。
过了复审日期的文档，自动从检索范围里隔离。宁可没有答案，也不给过期答案。
这一个动作解决的是时效问题，顺带解决了出处问题——因为有了责任人，就有了追溯路径。它把「知识库」从一堆静态文件，变成了一个有生命周期的东西。
再往上走，是先治理再索引。有个医疗机构的案例：在把内容迁进 AI 可用系统之前，先评估了 600TB 的文件共享数据,清掉了 245TB，也就是一亿多个冗余或无关文件。剩下的才进库。
顺序反过来的企业，通常是先建库，再发现答不准，然后往里加更多文档，指望用数量补质量。这条路走不通。
这件事和 ISO 9001:2026 撞在了一起
有意思的是，ISO 9001:2026 对组织知识的要求，恰好把这个话题从「技术选型」拉回了「管理」层面。
2015 版说知识要维护并提供，2026 版改成了三个动词：保留、应用、共享。同时把知识的目的从产品符合性扩展到了体系的预期结果。
三个动词对应三种完全不同的能力：
- 保留，解决的是人走了知识还在不在。这是文档化和继任安排的问题。
- 应用，解决的是日常决策里真的用上了没有。这是检索和分发的问题。
- 共享，解决的是该知道的人是不是都知道了。这是权限和触达的问题。
一个 AI 知识库，最多解决了「保留」的一部分，而且只解决了已经写成文字的那部分。它对「应用」的帮助取决于答案可不可信，对「共享」的帮助取决于权限设计。
所以指望用一个知识库项目去应付 7.1.6，大概率通不过。反过来，如果企业本来就有文件受控和复审机制，AI 只是加在它上面的一层查询界面，效果会好得多。
这也是一个顺序问题：先把知识的所有权、有效期、版本搞清楚，再谈能不能被检索。
如果现在要重启这个项目，我会这么做
四个动作，按顺序。
第一，砍掉「企业全领域问答」这个目标。这件事对 AI 来说是个死刑判决。法务问条款、客服问退货、销售问合同额、HR 问背调，这四类问题需要完全不同的知识源、检索方式和答案格式。硬塞进一个对话框，结果是四拨人都觉得「有点不对」，然后都不用了。
第二，选一个窄而痛的具体场景先做。比如检验规范的查询、客户投诉的历史处理办法、图纸的相似件检索。场景越窄，语料越干净，答准率越高，用户越愿意用。
第三，把治理做在索引之前。给文档定责任人、定复审周期、清掉作废版本、把外部文件清单对齐。这一步很土，没有演示效果，但它决定了后面所有事情的上限。
第四，把成功标准从「上线」改成「三个月后的活跃使用率和任务完成率」。如果三个月活跃用户低于 30%，就该认定这个场景选错了，而不是继续加预算。
CONTACT PLM 里那套围绕产品数据主线的做法，本质上也是同一个逻辑：先让数据有唯一来源和明确归属，再谈能不能被复用。知识管理和产品数据管理，犯的往往是同一个错误——以为把东西存起来就等于管好了。