AI实施那些事01—企业知识库到底该按部门创建，还是按业务来创建？
这个男人来自千祥约 6 分钟如果你正在创建企业级的知识库，通常很快就会碰到一个问题：知识库到底怎么组织？
一般来说，最稳妥的方式肯定是按部门分。比如风险管理部一个库，运营管理部一个库，产品部一个库，科技部再来一个，也可以是一个小组一个库。知识管理可以遵循“谁拥有，谁管理，谁负责”的原则。
但等到真正做 AI 应用的时候，事情就没那么顺了。
比如，我们一家银行想做一个贷款预审批助手。它既要知道产品的准入条件，也要了解风险部的授信规则，还得参考运营部的办理流程和最新的相关制度。这些资料在好几个部门的知识库里，那这个助手到底应该用哪个库？
有一种方法是直接把这几个库都接上。如果资料不多、应用不多的时候，这么做就能解决问题。
但随着知识库越来越多、业务越来越复杂，新的麻烦也会跟着出现：风险部可能有几千份文件，贷款预审批只需要其中一部分；运营部的流程覆盖很多业务，也不是全部都适用；不同产品、不同客群，适用的条件还可能不一样。把库接上，只是让 AI 有机会找到资料。至于这件事应该用哪些资料、哪些不能用，还是得有人想清楚。而且整个部门的知识库全部开放给某个应用，不管怎么说都不是一件严谨的事情。
部门把知识管好了，和业务能把知识用好，中间其实还有一段距离。
管知识和用知识，想的不是同一件事
站在风险部的角度，建知识库时最关心的是什么？
制度有没有收齐，内容是不是准确，谁负责审核，什么时候更新，哪些人有权看。这些事情，都需要熟悉业务、掌握资料的人来负责。
但站在贷款预审批助手的角度，它关心的是另一组问题：
判断一笔业务，需要哪些条件？该参考哪些制度？办理流程是什么？有没有特殊情况？
它不会因为资料分属不同部门，就把一次业务判断拆成几次互不相干的回答。
一个客户经理要给客户解释贷款要求，他想知道的是这笔业务怎么办，而不是先研究银行内部哪个部门负责哪一份文件。
所以，企业知识管理里一直存在着两种不同的逻辑：
管的时候，按责任归属；用的时候，围绕具体的事。
过去靠人去跨部门找资料、问同事，这个矛盾还能被人的沟通能力补上。现在希望 AI 接手一部分工作，我们就得把这件事设计清楚。
如果改成按业务建库呢？
既然按部门建不方便使用，那干脆按业务建，行不行？
贷款预审批一个库，客户经理助手一个库，贷后管理一个库，合规检查再建一个库。每个应用需要什么，就把什么资料放进去。
但很快你就会发现，同一份制度，被放到了好几个地方。等制度调整了，风险部更新一遍，贷款助手那边要更新，客户经理助手那边也要更新。哪个地方忘了，就可能继续用旧内容。
再往后，每增加一个应用，都要找人重新整理一遍资料。做应用的人在忙着收集，管知识的人在忙着配合，却很难知道到底还有多少份副本在外面流转。
另一种办法，是在最开始就设计一套特别完整的分类，把部门、产品、业务、场景全考虑进去。可这又把一个很难的任务交给了知识管理员：你不仅要把今天的资料管好，还得提前猜到明年会出现哪些应用。
我觉得，这个要求有点为难人了。
业务是不断变化的。今天想做贷款预审批，明天想做营销活动助手，后天又要支持一个新的合规检查任务。
我们没必要在建知识库的第一天，就把未来所有用法都想完。
给知识两种组织方式
后来我们在AIS 里采用了“知识库＋知识空间”的双层架构设计。
名字听起来像是多加了一层，背后的想法其实很朴素。
知识库：继续负责把知识管好，风险部维护授信规则，产品部维护产品资料，运营部维护办理流程。资料该由谁审核、什么时候更新、哪个版本有效，仍然有明确的责任人。 知识空间：则围绕一件具体的事，把需要的知识组织起来。
还是贷款预审批的例子。业务负责人可以建立一个“贷款预审批”空间，再由相关人员在授权范围内，把适用的产品条件、授信规则、办理流程组织进来。
这些知识有各自的来源和维护责任，又能共同服务于一个业务主题。
这跟企业做项目很像。做一个项目，需要产品、技术、运营、法务共同参与。通常不需要先把这些人都调到同一个部门，而是围绕任务建立协作关系。
知识也可以这样。
同一份制度，可以服务贷款预审批，也可以服务客户经理助手。不同业务需要的组合不一样，但没必要因此反复建设整套知识底座。
我觉得这个设计最有意思的地方，是它改变了“谁来决定、什么时候决定”。
知识管理员负责把自己掌握的知识维护好。
等到业务真的发生，再由了解这件事的人，决定需要哪些知识、应该怎样组织。
不用让管知识的人提前猜所有用法，也不用让做应用的人每次从头整理。
当然，跨部门组合也有边界。把知识引入一个空间，需要相应的授权；加入空间，也不意味着能看到来源部门的全部资料。
协作要更方便，责任和权限也得清楚。
还有个容易忽略的问题：源头更新了，业务怎么办？
说到这里，有人可能会觉得，知识空间就是把几个库里的资料引用到一起。
如果只做到这一步，还不够。
真正用起来后，很快会遇到一个问题：源头的知识更新了，正在使用它的业务，要不要立刻跟着变？
直觉上，当然是越新越好，但实际业务里，得看情况。
查询今天的产品价格，需要使用当前生效的价格。价格已经调整了，还给客户报旧价，肯定有问题。
可如果是在复盘一个已经结束的项目，我们需要保留当时的合同、需求和技术规范。拿今天的版本替换掉历史依据，反而没法解释当时为什么那么做。
还有一些制度调整，带着生效日期和过渡安排。正在办理的业务适用哪一版，需要根据规则判断，不能只看哪个文件更新得晚。
因此，知识空间还需要明确自己与源知识之间的关系：是保留当时的副本，是固定一个版本并接收变更通知，还是跟随当前有效的最新版。
这个选择背后，是业务对稳定性、时效性和追溯的不同要求。
这里当然不是让业务人员自行决定要不要遵守新制度。恰恰相反，是要把制度的适用范围、生效时间和切换责任落到具体业务里。
知识在源头更新了，哪些业务会受影响，谁要确认，什么时候切换，都应该有章可循。
这样，知识才算真正进入了业务，而不只是被放进了另一个文件夹。
建知识库，不必一次解决所有问题
这些年做企业知识库，我越来越觉得，很多建设上的纠结，是因为我们想让一套结构承担太多任务。
既要方便部门维护，又要适合各种业务使用；既要长期稳定，又要随时适应新应用。
最后，分类越分越细，目录越来越复杂，使用的人却还是不知道该去哪里找。
把管理和使用分成两个层次，事情反而容易理顺。
先让每份知识有明确的维护者，再让业务围绕自己的任务组织知识。底层相对稳定，上面的使用方式可以不断变化。
这个思路也不只适用于 Agent。
新员工培训、客户项目交付、营销活动准备，都需要跨部门组织资料。人需要这样的工作环境，AI 也需要。
这也是我们设计知识空间时最想解决的问题：让已经沉淀下来的知识，更容易进入正在发生的工作。
谁掌握知识，谁负责把它维护好；谁要把事情办成，谁来组织需要的知识。
至于企业知识库到底该按部门建，还是按业务建，我现在的答案是：给这两件事，各自合适的位置。
以往文章：