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

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

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多

在智能交互领域,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,则用户状态进入多轮初始状态,表示用户正处于多轮对话,且还可有下一轮对话;如后续只有一轮次,则用户状态进入多轮结尾状态,表示用户正处于本多轮对话场景的最后一轮。基于该模式,可以使答案模板与缓存机制的交互次数趋于最小化,从而尽可能减少性能上的开销。在上述流程中,当用户提问进入多轮状态后,智能运维机器人首先需要区分该场景是否还存在下一轮对话,如果当前已为最后一个轮次,那么仅需要向用户返回本轮答案即可;如果当前对话仍存在更多轮次,那在获取到本轮答案之后,还要把下轮答案也放到缓存中。本地多轮对话程序流程如图3所示。

图3本地多轮对话程序流程

3.多轮对话异步加载

在前述方法中,对于下一轮次需要调起外部联机接口的场景,预先加载答案不仅会使性能压力都集中在前一轮次,且不能保证用户一定会选择进入下一轮次,这使得提前缓存略显冗

文档评论(0)

丹青 + 关注
实名认证
文档贡献者

锄禾日当午 汗滴禾下土

1亿VIP精品文档

相关文档