前言
机器人知识库必须有良好的分类才能便于理解、学习与后期的维护。
如若工作面对的是一个分类糟糕的知识库，这将是一个可怕的场景。拿到一个用户提问后，假设是人类来根据知识库里的知识点来回答问题。他会发现这么几件事，同一个问题可能会有多个知识点同时含有类似的问题，而且每个知识点的答案还都不太一样，在比较的时候易发现知识点都在不同的分类下面，整体的分类逻辑也令人摸不着头脑。
取消分类也是不可行的，知识库有20个知识点以上的时候，就必须要通过分类进行管理，才能有效梳理，否则，面对体量大的知识库，每一次整理都是漫漫征途。不能想象每次工作都要分辨1个知识点与其他成千上万个知识点的关系。
所以，当知识点逐渐变多后，我们需要一些合理的方式来对知识点的分类进行组织和管理。知识点组织的结构梳理有助于在知识库搭建过程中，给知识库里的知识点一个方便归纳的方法论。
1.分类原则和系统操作
知识库分类是按照知识点的特点和根据业务系统求解问题的需要将知识分为若干类，而每一类又分为若干子分类。一般子分类是母分类的基础，母分类是子分类的概括，子分类之间互不相容，知识库分类的划分遵循MECE的原则。
MECE分析法，全称 Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并成为有效解决问题的方法。
在知识库界面左侧是机器人知识点分类页面，点击分类名称旁边的“+”符号，可以新建此分类的下一级分类，鼠标悬停在对应分类上时还会有“编辑”、“删除”按钮浮出。当鼠标变成小手“ ”形状，可以拖动当前分类，改变其隶属关系，注意不能拖动为其本身的下一级。
点击向右的小三角“ ▶ ”可以展开下一级分类，点击向下的小三角“ ▼ ”可以收起属于该分类下的所有分类。
PS：为保证分类随知识库导出和导入正常，请不要在知识点分类中使用“/”、“\”等符号。
2.分类方法简述
1.分类纵向划分方法
在知识库构建过程中主要按照最终用户参与时间顺序构建分类的方法叫知识库的纵向划分方法。
纵向划分目前看来是我们搭建知识库的主要方法，在终端类公司，当已经分配了单一的业务线之后，在单一知识库中，往往是根据最终用户的参与时间进行划分。
消费产品类公司一般会按照售前，售后来区分知识库，售前还可能细分意图为优惠、产品信息、物流选择、支付办法等，售后分为物流状态、质量问题、包装问题等情况。当然，不同公司对物流等规划不完全一致，也有些公司是根据产品是否到达用户手中确定的售前售后，可以根据具体情况和实际进行微调。
服务类项目也可参照对应逻辑进行区分，比如餐饮项目按照就餐前和就餐后，人事服务类可以按照员工入职、试用期、转岗、离职的流程进行区分。
2.分类横向划分方法
知识库的横向划分结构主要用在产品业务线较多的情况下，并且往往是针对次一级分类进行划分，比如公司售卖的不同产品，可能就属于孕期-产品分类-不同产品进行划分。
通常在具体的分类过程中，也会结合具体业务情况将纵向划分与横向划分结合起来进行梳理。不同公司的业务模式不同，需要根据自己的实际情况进行知识库结构的确定。
3.分类经验概述
在实践中，我们总结了如下的分类口诀，帮助大家记忆：
一条主线，其他靠边；出现重复，早做功夫。
“一条主线”是说首先确认知识点是否以用户生命周期的场景展开，针对这类知识点，一般以最终用户参与的时间顺序作为唯一主线进行。
“其他靠边”指如果分类下知识点不是随着用户的生命周期变更的，如小区地点，小区周边这样的信息不会随着时间变化而变化，此时这类知识点可以单独拿出来作为项目的基础信息。
“出现重复，早做功夫”如果在不同阶段会出现重复，有没有明显应归类的位置，我们一般将知识点放在场景中最早提问的地方。
如果有并行的情况，比如信用卡办理的项目，线下办理为主线，同时有APP、微信、小程序、支付宝等渠道作为副线，需要明确副线的占比。
如果副线中APP开办差异占比较大，微信、小程序等渠道差异不大，有以下解决方案：可以将APP渠道单独分类，在对应知识点下设计第二组答案，根据提问者带过来的标签，设计同一知识点根据属性实体等划分为不同答案组来进行个性化回复。
这个方案优点是可以直接根据用户提问的渠道做出最优的回答，但是需要APP渠道带属性接入或需要客户提供实体信息。
具体操作可以查看《什么样的回答才足够个性？吾来个性化回复举手参评》。
4.知识库分类实践
在实践中，根据知识库搭建是否有语料进行划分，我们有“从小到大”和“从大到小”的梳理方法。
何为从大到小呢？何为从小到大呢？其实二者的核心问题在于是否有语料，前者应该为无历史语料的场景下使用，后者则为有历史语料的情况下使用的。
1 从大到小
没有条件也要创造条件：业务框架
没有历史的语料情况下，我们普遍要依赖业务框架，那在没有业务框架情况下，首先要做的事情就是梳理业务框架，梳理好业务框架，往业务框架中不断地填充知识点及其相似问，用结构化的思想不断地界定知识库的边界，故为从大（业务框架）到小（知识点、相似问）：
第一步：用户群体分析
首先必不可少的是先确认机器人面对的用户群体有哪几类，分别是谁？先以外卖场景为例：
外卖行业智能客服的用户群体
第二步：用户行为分析
把用户行为作为落脚点去分析，如外卖行业的消费者，他的用户行为可以分为三大类：售前、售中、售后；那商家的用户行为可以分为3大类：未入驻商家、已入驻商家、商家账号注销；而骑手应该是：取餐、配送中、配送后；而后可以继续根据该逻辑扩充框架。
外卖行业智能客服的业务梳理大框架
可是当遇到业务场景之间无明显逻辑的时候应该怎么办呢？
第三步：产品功能分析
可以把现有产品的功能作为落脚点去分析，以支付宝的市民中心页面的办事大厅为例，可以将页面上的一个个业务当作框架的枝干：
支付宝-市民中心-办事大厅页面
根据以上产品功能梳理出来以下业务框架：
市民中心办事大厅业务框架
当我们梳理好业务框架，有了这么一棵树，接着就是要不断地往里面扩充知识点及其对应相似问，纳入对应的业务场景下；好比在树干（业务框架）上长出树枝（知识点），树枝上再不断地长出叶子（相似问）。
2 从小到大
充分利用尚方宝剑：历史语料
当有历史语料的情况下，我们可以通过一个个的用户query去提取核心内容，根据核心内容反推业务框架，故为从小（一个个用户query）到大（业务框架）。
如以下用户query：
1.你们的蜂蜜产品有什么优势？
2.蜂蜜枇杷露都有什么功效？
3.低血压可以吃哪款产品？
4.服用了蜂蜜枇杷露出现头晕症状？
5.蜂蜜枇杷露为什么会有白色沉淀物？
通过用户query提取核心内容：
1.你们的蜂蜜产品有什么优势？ ->售前问题-品牌优势
2.蜂蜜枇杷露都有什么功效？ ->售前问题-产品功效
3.低血压可以吃哪款产品？ ->售前问题-症状保健
4.服用了蜂蜜枇杷露出现头晕症状？ ->售后问题-服用症状
5.蜂蜜枇杷露为什么会有白色沉淀物？->售后问题-产品质量
当对一批用户问题进行了核心内容的提取，需要从整体角度上去看知识点的颗粒度，以及对应的业务场景、用户群体是否一致，如果不一致还需要调整；并且在知识库搭建完成上线后，需要密切关注用户交互数据，查看是否有漏网之鱼。
总的来说，搭建知识库需要从业务场景出发，优先解决高频问题；这样搭建的知识库，能够较好的应对风险并方便后续的维护优化。
Tips
颗粒度
我们将知识点包含范围的大小称作颗粒度。颗粒度大的知识点可以做适当拆分，主要利用知识点编辑卡片中的搜索相似问和添加为新知识点。相应地，知识点颗粒度过小，没什么人问，对用户没什么帮助并且意思相似又集中的，可以适当合并，应用的是相似问转移到已有知识点功能。
梳理知识库的几点原则
一切从业务场景出发，优先解决高频知识点，其次才是低频知识点与时效性较强的知识点；即使是在上线阶段也会不断添加新的知识点，因此在搭建初期应当首先考虑最高频、最痛点的知识点。
明确知识库边界，并不是所有的用户query都适合作为知识点；另外，不同的产品知识库内可能会出现部分通用类型的问题，该类问题到底应该按照产品分类去整理还是统一纳入通用知识库里，应当结合业务场景来综合考虑，选择合适的方式。
在进行知识点整理的时候，最好制定统一的命名规范，方便后面管理。知识库规模越大，管理难度就越大，因此当数据增量到一定程度的时候需要采取抽样检查或定期检查等方式来确保数据库的健康程度。例如查看有无失效知识点，有无漏网之鱼等等。
结语
虽然分类不影响效果，但是在搭建过程中对机器人和运营人员有很大帮助。我们来想一下，如果用户的问题维护人员都不知道存在知识库的哪个部分，机器人能会吗？
大家可以在“吾来”尝试搭建适用于自己企业业务分类清晰的智能机器人，并将自己的机器人快速应用。
文章 | 吾来产品团队
整理校对 | 李明超 陈效
本文由 来也科技 吾来对话机器人平台 发布