基于TinyMce富文本编辑器的客服自研知识库的技术探索和实践｜得物技术

客服知识库是一个集中管理和存储与客服相关的信息和资源的系统，在自研知识库上线之前，得物采用的承接工具为第三方知识库系统。伴随着业务的发展，知识的维护体量、下游系统的使用面临的问题愈发明显，而当前的第三方采购系统，已经较难满足内部系统间高效协作的诉求，基于以上业务诉求，我们自研了一套客服知识库。

以下是经过调研后列出的多款富文本编辑器综合对比情况：

• 自研知识库要求富文本编辑器具备表格的编辑能力，由于Quill不支持表格编辑能力（借助表格插件可以实现该能力，但经过实际验证，插件提供的表格编辑能力不够丰富，使用体验也较差），被首先被排除。

• wangEditor体验过程中发现标题和列表（有序、无序）列表两个功能互斥，体验不太好，而这两个功能都是自研知识库刚需功能，也被排除。

• Lexical是facebook推出的一款编辑器，虽功能很丰富，但相较于CKEditor和TinyMCE，文档不够完善，社区活跃性较低，插件不成熟，故优先选择CKEditor和TinyMCE。

CKEditor和TinyMCE经过对比，由于当前正在使用的第三方知识库采用的是TinyMCE编辑器，选择TinyMC在格式兼容上会更友好，对新老知识库的迁移上更有利。且TinyMCE在功能丰富度上略占优势，故最终选择TinyMCE作为本系统文档知识库的编辑器。

基于表单，使用表单某字段填充内容，编辑器始终作为表单的一部分。内部采用了iframe沙箱隔离，将编辑内容与页面进行隔离。

※ 优势

样式隔离好。

※ 劣势

由于使用iframe，性能会差点，尤其对于多实例编辑器。

将编辑视图与阅读视图合二为一，当其被点击后，元素才会被编辑器替换。而不是编辑器始终可见，不能作为表单项使用。内容会从它嵌入的页面继承CSS样式表。

※ 优势

性能相对较好，页面的编辑视图与阅读视图合二为一，提供了无缝的体验，实现了真正的所见即所得。

※ 劣势

样式容易受到页面样式的影响。

为了对知识文档做更细颗粒度的解析，客服知识库采用了结构化段落的设计思想，每个段落都会有一个唯一标志，且支持对文档的每个段落单独设置标签，这样在后期的知识检索、分类时，便可以精确定位到知识文档的具体段落，如下图所示。

知识文档编辑页面

客服知识库的主要应用场景如下：

基于传统的ES检索能力，用于知识库的检索，检索要使用的知识，且可以直接在工作台打开对应的知识并浏览，并可以定位、滚动到具体的知识段落。同时还会高亮显示知识文档中匹配到的搜索关键字。

※ RAG出话

辅助客服了解用户的真实意图，可用于客服作业时的参考。

原理阐述：RAG是一种结合了检索和生成技术的人工智能系统。它是大型语言模型的一种，但特别强调检索和生成的结合。RAG的最主要的工作流程包括：

• 检索阶段：系统会根据用户的查询，从客服知识库中检索出相关信息。这些信息可能包括知识库内容、订单信息和商品信息等。

• 生成阶段：RAG使用检索到的信息来增强其生成过程。这意味着，生成模型在生成文本时，会考虑到检索到的相关信息，以生成更准确、更相关的回答。你可以直接将搜索到的内容返回给用户也可以通过LLM模型结合后生成给用户。

※ 答案推荐

可以根据用户搜索内容、上下文场景（如订单信息、商品信息）辅助客服更高效的获取答案。

流程示意：

※ 联网搜索

当RAG出话由于拒识没有结果时，便尝试进行联网搜索给出结果，可作为RAG能力失效后的补充能力。

原理阐述：底层使用了第三方提供的联网问答Agent服务。在进行联网搜索之前，会对用户的查询信息进行风控校验，风控校验通过后，再进行【指定意图清单】过滤，仅对符合意图的查询才可以进行联网搜索。

在新老知识迁移的过程中，由于老知识库中的图片链接的域名是老知识库的域名，必须要有老知识库的登录台信息，才能在新知识库中访问并渲染。为了解决这个问题，我们对用户粘贴的动作进行了监听，并对复制内容的图片链接进行了替换。

知识库内含有大量的图片，当我们打开一篇知识时，系统往往因为在短时间内加载、渲染大量的图片而陷入卡顿当中，无法对页面进行其他操作。这个问题在老知识库中尤为严重，也是研发新知识库过程中我们需要重点解决的问题。

我们对图片进行了懒加载处理：当打开一篇知识时，只加载和渲染可见视图以内的图片，剩余的图片只有滚动到可见视图内才开始加载、渲染。

由于我们要渲染的内容的原始数据是一段html字符串，一篇知识文档的最小可渲染单元是段落（结构化段落），而一个段落的内容大小事先是不知道的，因此传统的滚动加载方式在这里并不适用：比如当滚动到需要加载下一段落的位置时，如果该段落的内容特别大且包含较多图片时，依然会存在卡顿的现象。

我们采用正则匹配的方式，识别出知识文档的html中所有的 <img> 标签（将文档的html视作一段字符串），并给 <img> 标签插入 loading="lazy" 的属性，具备该属性的图片在到达可视视图内的时候才会加载图片资源并渲染，从而实现懒加载的效果，大大节省了知识文档初次渲染的性能开销。并且该过程处理的是渲染知识文档前的html字符串，而非真实的dom操作，所以不会带来重绘、重排等性能问题。

在知识模板列表页或者在创建新知识选择模板时，需要展示模板内容的缩略图，由于每个模板内容都不一样，同时缩略图中需要可以看到该模板靠前的内容，以便用户除了依靠模板标题之外还可以依靠一部分的模板内容选择合适的模板。

在保存知识模板前，通过截屏的方式保存一个模板的截图，上传截图到cdn并保存cdn链接，再对截图进行一定的缩放调整，即可作为模板的缩略图。

模板列表中缩略图展示效果：

新建知识时缩略图展示效果：

知识库采用了结构化段落的设计思想，技术实现上，每个段落都是一个独立的编辑器实例。这样实现带来一个弊端：使用编辑器的搜索和替换功能时，查找范围仅限于当前聚焦的编辑器，无法同时对所有编辑器进行查找和替换，增加了业务方的编辑费力度。

调研、扩展编辑器的查找/替换插件的源码，调度和联动多编辑器的查找/替换API从而实现全局范围内的查找/替换。

※ 插件源码剖析

通过对插件源码的分析，我们发现插件的查找/替换功能是基于4个基本的API实现的： find 、 replace 、 next 、 prev 、 done 。

※ 设计思路

通过在多个编辑器中加入一个调度器来控制编辑器之间的接力从而实现全局的查找/替换。同时扩展插件的API，辅助调度器在多编辑器之间进行调度。

※ 插件源码API扩展

1. hasMatched：判断当前编辑器是否匹配到关键字。

2. hasReachTop：判断当前编辑器是否已到达所查找关键字的最前一个。
   

3. hasReachBottom：判断当前编辑器是否已到达所查找关键字的最后一个。

4. current：滚动到编辑器当前匹配到的关键字的位置。

5. clearCurrentSelection：对编辑器当前匹配到的关键字取消高亮效果。

屏蔽插件自带的查找/替换的弹窗，实现一个支持全局操作的查找/替换的弹窗：使用了react-rnd组件库实现可拖拽弹窗，如下图所示：

※ 期望效果

当用户输入关键字并点击查找时，需要在文档中（所有编辑器中）标记出（加上特定的背景色）所有匹配到该关键字的文本，并高亮显示出第一个匹配文本。

※ 流程图

※ 期望效果

当用户点击「下一个」时，需要高亮显示下一个匹配结果并滚动到该匹配结果的位置。

※ 流程图

在新版客服知识库的研发和落地过程中，我们基于TinyMce富文本编辑器的基础上，进行了功能扩展和定制。这期间既有参考过同类产品（飞书文档、语雀）的方案，也有根据实际应用场景进行了创新。截止目前已完成1000+老知识库的顺利迁移，系统稳定运行。

自研过程中我们解决了老版知识库系统的卡顿和无法满足定制化需求的问题。并在这些基本需求得到满足的情况下，通过优化交互方式和知识文档的加载、渲染性能等方式进一步提升了使用体验。

后续我们会结合用户的反馈和实际使用需求进一步优化和扩展客服知识库的功能，也欢迎有同样应用场景的同学一起交流想法和意见。

往期回顾