专栏名称: arXiv每日学术速递
跟踪计算机视觉、人工智能、机器学习、NLP、语音识别、量化金融等热门方向学术信息
目录
相关文章推荐
科技兽  ·  苹果推送 iOS 18.0.1 ... ·  2 天前  
科技兽  ·  苹果推送 iOS 18.0.1 ... ·  2 天前  
INSIGHT视界  ·  关于公众号进行账号迁移的说明 ·  3 天前  
花果科技  ·  iPhone SE 4,预计明年初发布! ·  4 天前  
SOLO Beijing  ·  今晚 SOLO|Dawn Late ... ·  1 周前  
SOLO Beijing  ·  今晚 SOLO|Dawn Late ... ·  1 周前  
51好读  ›  专栏  ›  arXiv每日学术速递

首个数据代码完全开源! 受区块链启发的大模型多智能体协作根因分析框架

arXiv每日学术速递  · 公众号  · 区块链 科技自媒体  · 2024-09-25 11:43

正文

导读

本篇文章为大家介绍由北航带来的被EMNLP 2024 findings 接收的工作:基于大模型的系统根因分析框架,mABC: Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture(受区块链启发的多智能体协作根因分析框架)。


论文链接:

https://arxiv.org/abs/2404.12135

Repo链接:

https://github.com/knediny/mABC


Introduction

本文探讨了云原生技术中微服务架构日益复杂化所带来的系统稳定性和效率维护方面的挑战。为了解决警报事件的根本原因分析(RCA)和解决问题,本文提出了一种创新的框架——基于区块链启发的多智能体协作根本原因分析框架(mABC),以彻底改革人工智能运维(AIOps)领域。在该框架中,基于强大的大型语言模型(LLMs)的多个智能体通过区块链启发式投票来达成最终协议,遵循智能体工作流程提供的任务和查询的标准化处理过程。具体来说,从智能体工作流程中派生出的七个专业智能体根据其专业知识和LLMs的内在软件知识,通过协作形成去中心化链,为根本原因分析提供有价值的见解。为避免LLMs中潜在的不稳定性问题,并充分利用去中心化结构的透明和平等优势,mABC采用了受区块链治理原则启发的决策过程,同时考虑每个智能体的贡献指数和专业指数。在公共基准AIOps挑战数据集和我们创建的火车票数据集上的实验结果表明,与以前的强基线相比,mABC在准确识别根本原因和制定有效解决方案方面表现优异。消融研究进一步突显了mABC中每个组件的重要性,智能体工作流程、多智能体和区块链启发式投票对于实现最佳性能至关重要。mABC提供了一种全面自动化的微服务架构根本原因分析和解决方案,并在AIOps领域相比现有基线取得了显著的改进。

图1:微服务架构的根因分析示例。每个节点对应于系统中的特定服务(例如,登录、注册)。边 B->I 表示服务I 依赖于服务 B 提供的信息。警报事件发生在节点A 上,而警报事件根本原因节点为I,故障传播路径为 I->G->D->A,其中挑战循环依赖关系为H->E->L->H。


mABC Overview

mABC的从警报开始到根本原因分析的总体流程。

图2:mABC的从警报开始到根本原因分析的总体流程。1) 由于微服务架构中的访问功能阻塞或监控系统警报而出现警报事件。2)Alert Receiver转发并选择优先级最高的警报事件。3) Process Scheduler将未完成的根本原因分析划分为子任务,由 Data Detective、Dependency Explorer、Probability Oracle和Fault Mapper处理各种请求。4) Solution Engineer参考以前的成功案例制定根本原因解决方案。


Agent Workflow

两种不同的代理工作流

图3:两种不同的代理工作流。代理工作流允许所有代理根据既定的方法有效完成任务。对于需要实时数据或额外信息的问题,激活“ReAct答案工作流”,该工作流涉及思考、行动和观察的迭代周期,直到得到令人满意的答案。相反,当不需要外部工具时,系统默认使用“直接答案工作流”,即直接根据提供的提示来制定响应。


Agent Description

警告接收器: 负责接收和分类警告事件,根据事件的紧急性和影响范围进行排序,并将最高优先级的警告传递给流程调度器。


流程调度器: 接收来自警告接收器的信息,启动一个综合的处理流程,包括数据收集、依赖性分析、概率评分等,同时协调各个专门的代理进行任务。


数据侦探: 负责从指定的节点收集数据,包括但不限于平均延迟、流量、错误率、资源饱和度和并发用户数。数据收集后,通过数据分析工具进一步加工处理,以便于理解和决策。


依赖性探索器: 分析微服务架构内部节点之间的依赖关系。在接到流程调度器的请求后,根据全局拓扑和时间窗口内的调用数据,识别出与特定节点直接或间接相关的其他节点。


概率预测器: 评估不同节点的故障概率。这涉及到基于性能指标如响应时间、错误率或资源使用情况来评估每个节点的故障风险。


故障映射器: 负责更新和可视化故障网络(Fault Web),它展示了不同节点间的故障概率和连接。


解决方案工程师: 在确定故障根源分析和解决方案开发后,根据流程调度器提供的数据进行节点级或指标级分析,制定实际有效的解决策略。


区块链启发式投票机制

Agent Chain的投票流程

图4:Agent Chain的投票流程。为了减轻 LLM 的幻觉并避免陷入无休止的循环,我们设计了受区块链启发的投票,作为任何代理对任何问题的任何答案的反映。代理回答后,所有其他代理决定是否发起民意调查并通过加权投票获得结果。未启动民意调查过程或在民意调查中通过的答案由于获得代理的多数认可而被视为高质量,而未通过的答案将由作者代理重新生成以提高质量。MABC 中的代理尽管职责不同,但彼此透明且平等,并构成一个分散的结构代理链。此外,尽管代理链缺乏拜占庭容错系统的实现,但它对于由代理工作流驱动以避免产生虚假消息仍然非常强大。受去中心化最佳实践区块链治理准则的启发,我们选择链上治理,以允许参与者相互信任,并将决策权交给去中心化实体。这种机制通过所有代理的加权投票来审查每个答案,确保决策的去中心化和公正性。


投票流程

审查阶段:所有代理对答案进行审查,确保其准确性和适当性。


发起投票:如果某个代理认为答案需要进一步验证或改进,可以发起投票。


进行投票:所有代理在代理链上对答案进行投票,投票选项包括赞成、反对和弃权。


结果判定:根据投票结果决定答案是否被接受。如果答案未通过,提出答案的代理需要根据反馈重新生成答案。


投票权重和指数

投票的权重由两个主要指数决定:贡献指数 (w_c) 和专业指数 (w_e)。


贡献指数 (w_c):贡献指数:反映代理在系统中的活跃度和贡献度。通过参与投票和提议来增加,通过一定的衰减率来减少,以鼓励持续的贡献并防止权力集中。贡献指数的起始值为 1.0,通过参与投票和提议每次可以增加 0.1,衰减率在 0 到 0.03 之间,贡献指数的最大值设为 1.5。


专业指数 (w_e):反映代理在特定领域的专业水平。这个指数不会自动衰减,以反映代理累积的专业经验。当代理的投票结果与最终决定一致时,专业指数增加,否则减少。专业指数的起始值为 1.0,每次投票结果一致时增加 0.01,不一致时减少 0.01,专业指数的最大值设为 1.5。


投票结果的判定

投票的支持率和参与率是通过加权计算得到的。支持率是指投赞成票的代理权重与总权重的比例,参与率是指投赞成票和反对票的代理权重与总权重的比例。如果支持率和参与率达到预设的阈值(通常是 50%),则提案通过。

实验结果

主要实验结果

图5:mABC的主要实验结果


作者首先展现了Train-Ticket和AIOps两个评测集上的结果,在根因准确性(RA)和路径准确性(PA)上都表现出有效性。

图6:mABC的决策效率结果表现


作者其次展现了Train-Ticket和AIOps两个评测集在决策路径通过率(RA)和平均决策路径长度(APL)两个决策指标mABC的有效性。

图7:用于进行人类评分的问卷示例

图8:mABC的人类评估结果表现


作者最后展现了Train-Ticket和AIOps两个评测集在设计的问卷上人工评估的结果。


消融实验结果

各个组件的消融研究

图9: mABC的各个组件的消融研究

同时为了验证mABC的各个组件的有效性,作者对关键组件进行了消融实验。


Conclusion

在本文中,作者介绍了mABC,这是一个通过结合多智能体系统、LLM 和区块链投票来改善复杂 微服务架构 中警报事件解决能力的框架。我们还开发了火车票基准,这是 微服务架构中根因分析的开源数据集。AIOps 挑战和Train-Ticket数据集上的实验结果表明mABC在识别根本原因和提供解决方案方面的有效性,其中 Agent Workflow和投票机制至关重要。mABC增强了根本原因分析,提高了系统可靠性和运营效率。未来的工作将侧重于增强组件、整合更多数据源和改善代理协作,旨在使mABC成为 IT 运营必不可少的一部分。为推动开源社区的发展,相关微调和benchmark数据也将一并开源,敬请期待。