我前阵子去一个企业做调研，碰到了件事。那个公司的知识管理负责人带我参观他们的「知识库」。几万份文档。产品手册、培训资料、项目复盘、SOP、最佳实践，应有尽有。他挺自豪的。我看了半天，问了一个问题。如果一个新员工入职，他想了解「我们怎么做客户提案」，他需要多久能找到他想要的东西？他沉默了一下。「看运气。」这就是问题。很多企业的知识库，本质上是一个文档坟场。东西都在里面，但找不到。不是因为没有文档，是因为文档之间没有关联，没有结构，没有人能一下子看懂该看哪一份。你存了一万份文档，跟没存有什么区别？然后 AI 来了。很多人说，有了 AI 就简单了，把文档全丢进去，让 AI 回答不就行了？我试过。说实话，一开始我也觉得这玩意牛逼。你问一个问题，AI 直接给你答案，不用翻文档了。但用了一段时间之后，我发现了一个问题。AI 回答的准确度，取决于它「理解」了多少。你丢进去一堆 PDF，AI 能读到文字，但它不一定理解这些文字之间的关系。它不知道这份 SOP 是上个月刚更新的，那份已经作废了。它不知道这个产品文档是 V1 版本的，V2 版本在另一个文件夹里。它不知道这个项目的最佳实践，其实只适用于特定场景，不能照搬到所有项目。文字它都能读到。但理解，是另一回事。说真的，这块我踩过坑。最早做知识库项目的时候，我也觉得，「把文档喂给 AI 不就完了」。结果呢？员工问「我们公司的报价策略是什么」，AI 从三份不同时期的文档里各摘了一段拼在一起。看着挺像回事，但拼出来的是一个四不像。因为三份文档，对应的是三个不同阶段的报价策略。旧的还在库里，新的已经上线了，中间的过渡版本也没删。AI 不知道哪个是最新的。它只是觉得，这三份文档里都有「报价策略」这几个字，都相关，都给你看看。这叫知识检索。不叫知识理解。
01
什么才叫知识理解？我后来慢慢想明白了。知识理解，不是 AI 能读到你的文档。而是 AI 能回答你的问题，而且回答的是对的、是新的、是适合你的场景的。要做到这个，需要三件事。第一，知识要有结构不是「文件夹套文件夹」那种结构。是概念之间的关系。比如「报价策略」这个概念，下面关联了哪些文档，哪个是最新的，哪些是历史版本，适用场景是什么。这不是 AI 能自动从一堆 PDF 里猜出来的。这是需要人去设计的。第二，知识要有版本不是文件版本号那种。是时间线跟索引AI 需要知道，这份知识是什么时候产生的，什么时候更新的，什么时候过期的。过期的知识，要么标记为历史参考，要么直接归档。不能让它跟最新知识混在一起，让 AI 去猜该用哪个。第三，知识要有场景标签同样的知识，对不同的人来说，用法不一样。销售看报价策略，关心的是「我能给到什么折扣」。项目经理看报价策略，关心的是「这个报价对应的交付范围是什么」。老板看报价策略，关心的是「利润率够不够」。知识库不是把知识存起来就完了。是要让 AI 知道，谁在问，他关心什么，他需要什么。坦率的讲，这个思路跟传统的知识管理完全不一样。传统知识管理，核心是「存」。存得越多越好，分得越细越好。AI 时代的知识管理，核心是「用」。存不是目的，让 AI 能准确回答问题是目的。存了十万份文档，AI 回答不准，等于零。存了一千份文档，AI 回答又准又快，那这一千份就是真资产。回到开头那个例子。那个知识管理负责人说，「看运气」。我问他，你们花多少钱做的这个知识库？他说，几十万。几十万，买了一个「看运气」。我有时候觉得，这大概是企业里最贵的俄罗斯轮盘了。所以我做知识库项目的时候，思路完全反过来了。不是先问「你们有多少文档」。是先问「你们最常被问到的问题是什么」。从问题出发，反推需要哪些知识。然后把这些知识结构化，标注版本，打上场景标签。最后才让 AI 去理解。AI 理解的不是文档。AI 理解的是知识之间的关系。说到这个，我想起一个特别有意思的案例。一个企业，他们的知识库里有几百份产品文档。但真正被员工高频问到的，只有十几个问题：
谁该为知识库负责？顺着这个思路再聊聊。很多人觉得，知识库是 IT 部门的事。不是。知识库是业务部门的事。因为只有业务部门知道，什么知识是真正有用的，什么知识已经过时了，什么知识只适用于特定场景。IT 部门能做的是搭平台、接 AI、做检索。但知识本身的结构、版本、场景标签，只有业务部门能定义。所以做知识库，不能是 IT 部门闷头搞。得是业务部门主导，IT 部门配合。否则搞出来的东西，跟那个「看运气」的知识库，没什么区别。
夜雨聆风
