前言

机器人知识库必须有良好的分类能力便于了解、学习与前期的保护。

如若工作面对的是一个分类蹩脚的知识库，这将是一个可怕的场景。拿到一个用户发问后，假如是人类来依据知识库里的知识点来答复问题。他会发现这么几件事，同一个问题可能会有多个知识点同时含有相似的问题，而且每个知识点的答案还都不太一样，在比拟的时候易发现知识点都在不同的分类上面，整体的分类逻辑也令人摸不着头脑。

勾销分类也是不可行的，知识库有 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 都适宜作为知识点；另外，不同的产品知识库内可能会呈现局部通用类型的问题，该类问题到底应该依照产品分类去整顿还是对立纳入通用知识库里，该当联合业务场景来综合思考，抉择适合的形式。
在进行知识点整顿的时候，最好制订对立的命名标准，不便前面治理。

知识库规模越大，治理难度就越大，因而当数据增量到肯定水平的时候须要采取抽样检查或定期检查等形式来确保数据库的衰弱水平。例如查看有无生效知识点，有无漏网之鱼等等。

结语

尽管分类不影响成果，然而在搭建过程中对机器人和经营人员有很大帮忙。咱们来想一下，如果用户的问题保护人员都不晓得存在知识库的哪个局部，机器人能会吗？

大家能够在“吾来”尝试搭建实用于本人企业业务分类清晰的智能机器人，并将本人的机器人疾速利用。

文章 | 吾来产品团队

整顿校对 | 李明超 陈效

本文由 来也科技 吾来对话机器人平台 公布