ChatOps智能问答技术在运维服务领域的应用探索与实践 .pdfVIP

在智能交互领域，ChatOps基于DevOps协作模式，是人工智能技术和新型工作

理念相结合的产物，其以沟通平台为中心，通过与机器人产生对话和交互，使

开发人员只需在聊天窗口即可完成DevOps所承载的工作。以运维工作为例，

ChatOps围绕一线和二线员工运维数据获取难、使用难、信息不通畅、信息支

撑手段匮乏等痛点，可助力打造数据赋能的智能运维问答机器人，构建低成

本、高效率的共享服务模式，实现公开透明、上下文共享、移动友好以及

DevOps文化打造等一系列目标。对此，笔者团队基于农业银行一体化生产运维

平台，创新构建了新一代智能运维问答机器人，旨在为AIOps和DevOps能够更

好融合添加助力、搭建桥梁，以及为有相似建设需求的金融同业提供可借鉴、

可拓展的实践案例。

一、基于ChatOps的多轮对话方案设计

一般而言，多轮对话常用于任务型智能问答场景，使用者带着明确的目的而

来，希望得到满足特定限制条件的信息或服务(如查询信息、订票、找电影、购

买商品等)。实际上，用户需求可能很简单也可能很复杂，甚至需要通过多轮陈

述，在对话过程中不断修改、完善自身需求。简言之，多轮对话更像是一个决

策过程，需要智能运维机器人在对话过程中不断根据当前状态决策下一步应该

采取的最优动作，从而有效辅助使用者完成信息或服务获取。在此过程中，意

图识别是智能问答自然语言理解(NLU)中的一个必要步骤，它通过分类方法支持

将query分配到相应的意图种类，最大优点是可以有效缩小检索范围，大幅提

升问题匹配的准确度，因此对于特定领域的问答系统有着非常重要的作用。

聚焦智能运维领域，由于专业领域的特殊性和用户习惯的差异性，运维人员通

常并不会遵循纯自然语言的输入规律来提出问题，而智能运维机器人也很难理

解一个具体的服务目录、项目名称或某个运维工具代表了什么含义。针对上述

难点，为构建一个具备良好可扩展性和专业领域理解能力的智能运维机器人，

笔者团队自研实现了两种不同的多轮对话场景，并着重解决了两者间存在的语

序冲突等问题。在此基础上，根据用户对特定领域机器人提问的特性，笔者团

队还基于NLU的对话能力进一步实现了基于检索的智能问答意图识别，同时解

决了跨平台的语义冲突等问题。

二、基于状态机的多轮对话应用实践

为实现“轻量级”的多轮交互，笔者团队创新设计了引导式的对话模式，即通

过语音客服，辅助使用者输入指定关键字来进一步获取回答或查询更多信息。

1.基于Redis的存储结构

鉴于智能问答具有“短、平、快”等特征，笔者团队最终选定了Redis作为存

放多轮对话临时答案的缓存机制，该方法既能确保对话维持在高响应速率，也

能自由控制临时答案的存在期限。在该存储结构中，本轮答案和下轮答案均以

json方式存储，可输入的关键词是“键(Key)”，其余元素构成“值

(Value)”。多轮对话答案存储模型如图1所示。

图1多轮对话答案存储模型

在上述存储结构中，为避免出现刷新Redis时更新域无法控制的情况，笔者团

队选择将输入值存放在同一个键值对下，以确保更新缓存时答案的一致性和完

整性。举例来说，本轮次设置用户的快捷输入为“1、2、3”，输入“1”进入

的下一轮次快捷输入为“1”和“2”，那么在输入“1”刷新缓存时，快捷输入

值“1”和“2”的缓存键值会被同步更新，但输入“3”的缓存键值依然保留

着，这意味着用户即使进入到下一轮次，仍可以输入上一轮次中的部分快捷键

获取上一轮次答案。

2.对话状态机模型设计

实现多轮对话的核心在于智能运维机器人需要时刻了解用户的当前状态，知道

用户何时进入了多轮对话，又在何时选择退出。对此，笔者团队选择基于状态

机原理来实现多轮对话场景。本地多轮对话状态模型如图2所示。

图2本地多轮对话状态模型

总体来说，基于对话状态机原理的设计思想如下：智能运维机器人前端设置全

局变量，默认用户状态为单轮对话状态，表示用户当前未进入多轮对话。当用

户的提问命中了多轮会话后，根据场景特点，如后续轮次大于1，则用户状态

进入多轮初始状态，表示用户正处于多轮对话，且还可有下一轮对话；如后续

只有一轮次，则用户状态进入多轮结尾状态，表示用户正处于本多轮对话场景

的最后一轮。基于该模式，可以使答案模板与缓存机制的交互次数趋于最小

化，从而尽可能减少性能上的开销。在上述流程中，当用户提问进入多轮状态

后，智能运维机器人首先需要区分该场景是否还存在下一轮对