蒋炜-蚂蚁集团 OpsGPT 落地实践和技术开源

蚂蚁集团OpsGPT落地实践和技术开源 蒋炜（首之） 蚂蚁集团高级算法专家 5+年专注于AIOps领域，负责蚂蚁AIOps建设，从监控、应急到变更、容量领域的风险防控、效率提升、成本节约；10+篇相关专利，在ICSE、SoCC、ACL等顶会发表多篇论文。目前主要从事LLM+Ops方向，包括Ops领域垂类大模型以及结合Agent技术的产品应用 01OpsGPT项目起源 目02OpsGPT落地探索 contents 录03OpsGPT未来演进 04OpsGPT技术开源 PART01 OpsGPT项目起源 AIOps建设 围绕监控、应急、容量、变更、资金、基础设施6大核心领域建设AI智能化&自动化能力，实现风险降低、效率提升、成本节约 时序、拓扑、日志等结构/半结构化数据 单场景单模型、基础模型在于问题的抽象通用 场景模型：领域算法模型，单场景服务基础模型：通用基座模型，多场景赋能 OpsGPT定义 时序大模型？ 智能告警、资源规划… 日志大模型？ 业务布控、Error布控… •更多重人力投入场景围绕非结构化数据，人更擅长语言交流/文档记录/代码编写 •时序/日志这种单来源数据分析交互性存疑，“可解释问题”更大的分析模型仍然无法求解 •现有能力具备不错的情况下，继续使用，更应考虑进一步拓展智能化&自动化边界 Ops领域垂类LLM PART02 OpsGPT落地探索 OpsGPT演进 2023.03 项目规划 2023.04 方案设计1.0 •垂类模型 •工具学习 2023.07 方案迭代2.0 •Code+ 2023.10 方案迭代3.0 •检索增强 •技术开源 2024.02 方案迭代4.0 •事理图谱 复杂多步骤推理 ， 站在当前视角，通过定制微调可以解决单步骤任务、单步骤工具使用，但实际现实中的场景是复杂多步骤的，面向专业领域LLM只能给出泛泛而谈的答案（包括ChatGPT），面向C端用户完全没有问题，面向B/P端专业场景没有用处，尤其是Ops这种严谨、专业、私有领域。LLM能逐步协助人来解决问题ORAgent能实际解决问题，核心在于PLANNER。 •严谨：逻辑严谨，容错率低 •专业：专业领域，过程追溯 •私有：知识私有，环境私有 从仿生学出发 “不同领域专家核心竞争力在于行业的长久沉淀，面向专业领域复杂问题的处理经验，即Planner”大模型的劣势 •大模型在多步推理的弱势，面向专业复杂问题无法处理 •大模型在多步推理的不可控性/不可解释-NextToken 人面向专业复杂事务处理具备丰富的经验 •自我的摸索，多路交互探索，最终形成一条成功路径存于脑中 •老人带新人，口头传述/文档记录=>教会新人面向问题该如何处理 参考人的经验具备模式，我们期望通过DevOpsEKG（EventicKnowledgeGraph），从多源数据中获取复杂问题处理经验并结构化存储于EKG中，结合通过LLM+EKG实现现实领域复杂问题处理。 OpsGPT4.0架构 围绕EKG，协同LLM、Agent框架演进 多步推理-EKG推理 图谱推理 •游走推理：针对用户Query，确认用户意图并指导操作 •更新推理：针对用户Query指引实现图谱数据自动更新 •修正推理：LLM修正图谱中存在的节点缺失/错误/冗余 •探索推理：LLM多路探索推理，成功路径图谱节点沉淀 •+FunctionCall，面向平台/用户Query，流程自动化执行 多步推理-EKG构建 应急经验沉淀文档 结构事理图谱数据 多源原始数据 数据加工处理 结构知识提取 结构知识融合 结构知识存储 可视编辑 权限管控 以往SOP的实现通过人工操作/代码编写，现在可通过交互式增删改语义节点（SemanticFunction）实现；就像以往学习Python等语言来编程，每套语言有自己的规则范式，大模型出来后，我们期望让大模型实现所有，但就目前现状看，我们更应该抽象一层，定义一套新的语言来保障高可用性，即面向过程的语言编写。 单步任务-所需Tool OpsGPT 平台工具 数据工具 从大模型的劣势出发 •大模型缺少实时信息=>查询Tool •大模型缺少环境交互=>操作Tool •大模型事实问答薄弱=>RAG增强 •大模型多模分析薄弱=>AI小模型 模型工具 自身问答 •大模型数值计算薄弱=>沙箱环境 路由选择 操作执行信息查询多模分析 搜索工具 沙箱环境 事实问答数值计算单步任务 在线选择VS离线修正 单步任务–Tool接入 API接入 API选择 参数填充 API调用 结果解析 API规范结构定义 平台使用方VS平台提供方GAP 通用基础能力 基础知识问答 OpsGPT能力范畴 需要什么能力？ 风险单步任务系分文档分析、脚本自动编写、配置变更校验… 通用基础能力图谱构建推理、工具选择填参、信息抽取总结 本质：单步任务+信息提炼 定制 评估 模型 评估 人工 评估 如何评价优劣？ 风险单步任务 OpsGPT模型构建 更懂运维专业领域下游任务更易拓展 运维专属任务通用基础能力 规则处理+模型筛选词表拓展+SST加训SFT微调+DPO对齐 领域数据收集处理通用基础模型加训多任务微调对齐 外部 内部 •代码~11G •文档~5G •代码~9G •文档~11G 过程数据VS结果数据 PART03 OpsGPT未来演进 根据需要可添加介绍说明也可删除 产品演进 各产品集成 LLM能力嵌入原有各产品平台，用户按照原有信息获取/操作习惯到各平台操作 --单平台各自定制界面改变 浏览器插件 提供浏览器插件，用户到原有信息获取/操作平台，多种操作交互模式 --单平台统一能力界面改变 大产品统一 用户无需到各产品操作，统一产品，通过对话即可实现所有信息查询/操作 --统一产品界面多功能集成 技术演进 动线采集 现有EKG的构建更多的依赖人工输入，可拓展性较弱，参照WebGPT，能否实现人的操作行为自动化采集+数据清洗 探索推理 不可预估、没有参考事件的发生，大模型如何能利用好现有信息，自动探索推理，并将成功探索路径图谱沉淀 多模对齐 现有多模态的诉求，通过ToolLearning实现，能否直接让OpsGPT能比较好的理解时序、图像等其他模态数据 信息提取 现在单场景定制微调提升信息提取的准确性，能否围绕DevOps领域提供好信息提取基座，无需微调直接使用 系统理解 如何让LLM理解大型业务系统，而不是停留在片段级的代码理解和生成，只有理解大型系统的业务逻辑，可能Dev+Ops的范式才能真正变革 PART04 OpsGPT技术开源 根据需要可添加介绍说明也可删除 为什么要做开源 资源短缺 训练资源短缺，如何尽可能地提供统一基座（Base +Chat），方便各场景直接使用OR微调即可满足 需求 角度更多 大模型核心在于场景的定义，并在此基础上数据的构建和积累，各方多角度问题定义，数据贡献积累，完善统一基座 行业标准 NLP、CV的发展离不开业界标准的Benchmark，有了问题的定义以及目标，才能不断催生技术的迭代演进 开源项目简介 DevOpsModel DevOps垂直领域基座模型（Base+Chat），方便直接使用OR微调使用 https://github.com/codefuse-ai/CodeFuse-DevOps-Model DevOpsEval DevOps领域大模型专属评测集，包含知识问答、领域任务和通用任务 https://github.com/codefuse-ai/codefuse-devops-eval DevOpsChatBot 产品应用，围绕Agent（Multi-Agent交互、ToolLearning、RAG）结合KG等技术 https://github.com/codefuse-ai/codefuse-chatbot Thanks 高效运维社区DevOps时代 荣誉出品 THANKS 感谢大家观看