《ChatOps智能问答技术在运维服务领域的应用探索与实践.docx》由会员分享，可在线阅读，更多相关《ChatOps智能问答技术在运维服务领域的应用探索与实践.docx（12页珍藏版）》请在课桌文档上搜索。
1、在智能交互领域，ChatOps基于DeVoPS协作模式，是人工智能技术和新型工作理念相结合的产物，其以沟通平台为中心，通过与机器人产生对话和交互，使开发人员只需在聊天窗口即可完成DevOps所承载的工作。以运维工作为例，ChatOps围绕一线和二线员工运维数据获取难、使用难、信息不通畅、信息支撑手段匮乏等痛点，可助力打造数据赋能的智能运维问答机器人，构建低成本、高效率的共享服务模式，实现公开透明、上下文共享、移动友好以及DeVoPS文化打造等一系列目标。对此，笔者团队基于农业银行一体化生产运维平台，创新构建了新一代智能运维问答机器人，旨在为AlOPS和DevOps能够更好融合添加助力、搭建桥梁
2、，以及为有相似建设需求的金融同业提供可借鉴、可拓展的实践案例。一、基于ChatOPS的多轮对话方案设计一般而言，多轮对话常用于任务型智能问答场景，使用者带着明确的目的而来，希望得到满足特定限制条件的信息或服务(如查询信息、订票、找电影、购买商品等)。实际上，用户需求可能很简单也可能很复杂，甚至需要通过多轮陈述，在对话过程中不断修改、完善自身需求。简言之，多轮对话更像是一个决策过程，需要智能运维机器人在对话过程中不断根据当前状态决策下一步应该采取的最优动作，从而有效辅助使用者完成信息或服务获取。在此过程中，意图识别是智能问答自然语言理解(NLU)中的一个必要步骤，它通过分类方法支持将query分
3、配到相应的意图种类，最大优点是可以有效缩小检索范围，大幅提升问题匹配的准确度，因此对于特定领域的问答系统有着非常重要的作用。聚焦智能运维领域，由于专业领域的特殊性和用户习惯的差异性，运维人员通常并不会遵循纯自然语言的输入规律来提出问题，而智能运维机器人也很难理解一个具体的服务目录、项目名称或某个运维工具代表了什么含义。针对上述难点，为构建一个具备良好可扩展性和专业领域理解能力的智能运维机器人，笔者团队自研实现了两种不同的多轮对话场景，并着重解决了两者间存在的语序冲突等问题。在此基础上，根据用户对特定领域机器人提问的特性，笔者团队还基于NLU的对话能力进一步实现了基于检索的智能问答意图识别，同时
4、解决了跨平台的语义冲突等问题。二、基于状态机的多轮对话应用实践为实现“轻量级”的多轮交互，笔者团队创新设计了引导式的对话模式，即通过语音客服，辅助使用者输入指定关键字来进一步获取回答或查询更多信息。1 .基于Redis的存储结构鉴于智能问答具有“短、平、快”等特征，笔者团队最终选定了RediS作为存放多轮对话临时答案的缓存机制，该方法既能确保对话维持在高响应速率，也能自由控制临时答案的存在期限。在该存储结构中，本轮答案和下轮答案均以json方式存储，可输入的关键词是“键(Key)”，其余元素构成“值(Value)w0多轮对话答案存储模型如图1所示。值（Vabe）图1多轮对话答案存储模型在上述存
5、储结构中，为避免出现刷新RediS时更新域无法控制的情况，笔者团队选择将输入值存放在同一个键值对下，以确保更新缓存时答案的一致性和完整性。举例来说，本轮次设置用户的快捷输入为“1、2、3”，输入“1”进入的下一轮次快捷输入为“1”和“2”，那么在输入“1”刷新缓存时，快捷输入值“1”和“2”的缓存键值会被同步更新，但输入“3”的缓存键值依然保留着，这意味着用户即使进入到下一轮次，仍可以输入上一轮次中的部分快捷键获取上一轮次答案。2 .对话状态机模型设计实现多轮对话的核心在于智能运维机器人需要时刻了解用户的当前状态，知道用户何时进入了多轮对话，又在何时选择退出。对此，笔者团队选择基于状态机原理来
6、实现多轮对话场景。本地多轮对话状态模型如图2所示。未触发 多轮对话图2本地多轮对话状态模型总体来说，基于对话状态机原理的设计思想如下：智能运维机器人前端设置全局变量，默认用户状态为单轮对话状态，表示用户当前未进入多轮对话。当用户的提问命中了多轮会话后，根据场景特点，如后续轮次大于L则用户状态进入多轮初始状态，表示用户正处于多轮对话，且还可有下一轮对话；如后续只有一轮次，则用户状态进入多轮结尾状态，表示用户正处于本多轮对话场景的最后一轮。基于该模式，可以使答案模板与缓存机制的交互次数趋于最小化，从而尽可能减少性能上的开销。在上述流程中，当用户提问进入多轮状态后，智能运维机器人首先需要区分该场景是
7、否还存在下一轮对话，如果当前己为最后一个轮次，那么仅需要向用户返回本轮答案即可；如果当前对话仍存在更多轮次，那在获取到本轮答案之后，还要把下轮答案也放到缓存中。本地多轮对话程序流程如图3所示。图3本地多轮对话程序流程3 .多轮对话异步加载在前述方法中，对于下一轮次需要调起外部联机接口的场景，预先加载答案不仅会使性能压力都集中在前一轮次，且不能保证用户一定会选择进入下一轮次，这使得提前缓存略显冗余。此外，部分联机接口对时效性要求较高，实时检索结果也始终在动态变化。基于以上考虑，笔者团队对存储结构进行了优化，允许通过异步加载的方式返回结果，即本轮次下用户输入某个快捷键后，智能运维机器人才会调起对应
8、的接口返回本轮次答案。支持异步加载的多轮对话答案存储模型如图4所示。值(Vabe)图4支持异步加载的多轮对话答案存储模型4 .多机制并行的冲突解决策略在试点推广智能运维机器人的过程中，为避免出现会话被“覆盖”的情况，笔者团队进一步优化了本地多轮对话的存储结构，即在键值对中“值”的最外层增加了字段“答案类型”。对于触发了间接回答的情况，将提前在RediS中缓存更新键值对，将答案类型预置为“外部”，而对于答案类型等同于“外部”的缓存，则会跳过对本地答案的解析，从而可有效避免两种多轮对话并存的情况下相同快捷键被其中一种机制拦截的冲突问题。三、基于检索的智能问答意图识别通过分析试点推广阶段的用户行为发
9、现，由于智能机器人大多服务于特定领域，因此用户在提问中往往会带有一些专业领域术语，且提问方式也大多为文字输入而非语音交流，用户提问很少是完整的主谓宾句式，动宾结构或者纯名词更为常见。针对这一问题，笔者团队最初选择在聊天界面的前端设置引导问题来提升命中功能型会话的概率，但随着机器人服务渠道的不断扩展，当业务拓展到CS架构（类似微信、畅聊）中的某个服务号时，由于整体框架能力的限制，己无法再通过设置引导的方式来提升直接回答的命中率，需要进一步挖掘用户习惯，让机器人的理解能力更加贴合本专业领域。1.基于词典和规则的意图识别面向专业领域的会话内容，笔者团队首先明确了希望被直接检索的短语场景，包括服务目录
10、编号、变更单号、应用名称、用户名、IP地址、专业术语等，之后即是根据每个场景的短语特性来决定检索方式。最终，笔者团队重点选择了三种本地检索方法，其优劣势对比见表1。表I本地检索方法对比词表规则字符小解析方法描述通过漏表的直接匹配来获取杳询意图.词表可理解为字典项，将所有字典项提前缓存,检索时优先兀配：通过定时作业更新词表利用正则表达式来解决一些比较符合规则的提问解析字符串是否符合特定规律,如以特定短谙开头或结尾等优点实现简单,速度快，能够准确匹配到病频词对于符合规则的代沏能够精准匹配，不消耗系统内存规则简小.不消耗系统内存I缺点需要建上比较大的词典,并需要及时更新适用于规则性较强的query存
11、在一定的用户学习成本-适用场景应用名称、用户名等服务目录编号、变更单号、IP地址、手机号等谛听关键字检索2 .模块间检索顺序基于本文实践的模块间检索顺序如图5所示。当对话用户发出请求时，智能运维机器人首先会判断用户当前状态，并在多轮情况下优先进入缓存查找答案；在非多轮情况下，优先匹配正则表达式及字符串解析，匹配成功后进入对应模块并返回内容；否则继续检索词表，进入缓存查找相关字典项，匹配成功后进入对应模块并返回内容；如果以上均未匹配成功，则会调起普通智能问答接口，触发智能运维机器人的识别逻辑进行兜底回复。图5模块间检索顺序3 .语义冲突解决方案在集成了传统FAQ对话、任务型对话和本地基于检索的意
12、图识别后，由于不同场景下命中的关键字有重合，笔者团队曾遇到过两种语义冲突问题：一是本地检索与任务型对话词槽冲突，即在任务型对话的词槽澄清环节，用户输入的应用名称将会被本地检索直接拦截，导致智能运维机器人在返回配置信息后，依然处于等待任务型对话的词槽澄清状态，此时用户输入的其他问题将无法被正常识别。二是FAQ与任务型对话词槽冲突，即由于部分系统别名与词槽中配置的系统别名完全一致，导致原本用户希望通过别名进行单轮对话，但最终却被智能运维机器人认为应该进入任务型多轮对话。针对上述难题，笔者团队通过优化模块间的检索顺序，有效解决了语义冲突问题。具体而言，在根据用户输入频率调整本地检索模块顺序的基础上，
13、将会拦截任务型词槽的本地检索（应用编号、全名）下沉到FAQ型返回逻辑中，截断知识库答案再调起本地检索API,解决了本地检索与任务型对话的词槽冲突，并通过将系统别名的检索放在最外层之前，解决了FAQ与任务型对话的词槽冲突。四、应用效果与经验总结面向任务型对话场景，笔者团队以查询工具接入状态为例，通过自然语言输入触发了案例场景。当用户输入应用名称时，首先模糊匹配应用系统全称，从而有效提高了词槽匹配准确性，其次是在词槽填充完毕后，利用自定义的模拟报文来实现智能运维机器人对执行本地APl的精准控制，并根据本地模板统一封装答案。针对本地多轮对话，笔者团队以检索应用配置信息为试点场景，并在该场景同样运用了
14、基于词表的检索能力。此外，笔者团队还针对各服务渠道（包括无状态位的无条件Redis检索和优化后基于状态机的Redis检索）的对话能力表现开展了性能测试。各渠道本地多轮对话优化前后性能对比见表2o表2各渠道本地多轮对话优化前后性能对比渠道无条件redis响应优化后响应平台端1.85s1.22s移动端1.2s1.01s畅聊端1.74s1.14s基于智能运维问答机器人的应用探索与实践，笔者团队总结梳理了如下经验:一是技术发展始终紧密贴合用户需求变化，即坚持以极简的交互方式和强大的后端逻辑，来打造紧密贴合运维自动化领域的服务模式。截至目前，智能运维问答机器人已服务用户近2000人，问答轮次超过1500
15、0轮，服务渠道从最早的WEB端扩展到如今的WEB端、移动端、畅聊端，并支持持续观察、分析用户需求。二是根据不同渠道的特征选取不同的对话方式。例如，对于可提供引导的服务渠道，推荐使用任务型多轮问答实现特定任务；对于受到限制或无法给出联想X可扩展性智能机器人用后比墟力中枢云本地APl r r IAl应用配置 I I变更实施信息I i I工具捶入台炼I I IIOPS-Web Sl语义匹配URL解析:PC 网页fit?e I:天相发道焦皆I个能力中枢，变特各个服务建道 一灵活应对增道易用性ri i I /MM L:二二二二;响应报文解析:BMas I I直橹茶JB 间接茶案1，1 IIiiI XX9
16、SfiMh 1关债节点拦 1 一一 一一一一 I 一一 一一一I极荷的用户,入.符合用户天才慎零学习成本籁入联想i a然修宫联想i定IM化酸也可推广性松横会一功能组件御松,台， ta件变更对其他模 块影峋最低LA 灵犀一智能问答图6多渠道智能问答能力集成架构五、未来展望一tttt,不仅适用 TiittfM,可推广 W金RL曾耀等JC他 颁缱Al机BJ人的服务渠道，推荐引入意图识别来提升问答效率；对于现有平台无法满足客户需求的服务渠道，推荐参照本地多轮对话机制，基于状态机原理和缓存机制实现任务型对话的“平替”。三是尽可能保持生产和测试语料库一致。针对场景间因语义冲突而引发的问题，笔者团队采用了以
17、一个后端对应多个前端的技术架构，即始终把所有能力集成在一个通用后端接口，开展控制准入，以便快速应对不断拓展的前端服务渠道，并始终保持体验一致的对话表现能力。多渠道智能问答能力集成架构如图6所示。谛听-全文检索在智能问答领域，当前用户对于纯机器人的交互方式仍处于尝试和观望阶段。后续，笔者团队将继续践行ChatOPS理念，努力解锁更多的创新技术点，实现“因数而智、化智为能”。笔者团队拟通过XML语言来不断优化答案的存储结构，同时进一步探索消息主动推送、特殊渠道图片或附件推送、多关键词检索等方式，以及当下流行的基于机器学习的意图识别、基于知识图谱的知识库结构等研究方向，并尝试在更多的运维场景中引入智能运维问答机器人，助力构建智能、高效、低成本的智能运维模式，力争为金融业人工智能应用引入更多创新实践，为AlOPS在运维领域落地提供更好的基础支撑。
