解析CIFS|太平洋保险集团王辉：大模型技术在运维领域的应用
2025-04-10
各位嘉宾、各位同仁：
大家上午好！我是来自太保集团的王辉，今天很荣幸为大家分享我们集团通过大模型在智能运维领域的思考与探索。在介绍这个话题之前，我想先简单讲讲我们集团在大模型领域的实践。我们早在 2022 年就开始运用大模型开展审计场景方面的应用。2023 年，我们提出了数字劳动力整体战略。目前，在自有算力，包括大模型平台和场景应用上，我们也取得了诸多实践成果与突破。目前，我们已有 100 多个场景在大模型应用方面开展了实践。针对运营领域，我们从去年开始探索。因为在传统模型领域，我们虽已做过一些尝试，但仍存在许多痛点未能解决。大模型出现后，我们发现其在运维领域有很大潜力，能够帮助我们解决不少问题，于是便开启了在运维领域的探索。目前，我正牵头多个团队，在运维领域加大模型技术的融合，开展场景探索。
我们的分享主要分为三块内容：
01 运维场景分析
IT运维需求分析
整个运维阶段涵盖的内容繁多，且涉及各个阶段，从故障预防、发现、定位、恢复到最后的知识沉淀，不断循环，以提升整体运维能力。
传统AI在Ops领域的使用方向
在这个阶段，传统 AI Ops 领域已进行了大量尝试。例如，通过趋势神经网络和深度学习算法，预测未来容量告警趋势；针对大量无效告警，运用传统模型结合知识图谱能力，更快地进行根因定位。
运维需要大模型能力
那么，为什么我们还需要大模型呢？我们认为，在一些简单的、无需复杂思考的领域，通过传统规则就可以尝试解决问题。然而，运维场景需要整合众多知识以及复杂的关系，而大模型恰恰能够在这方面提升解决问题的能力。大模型具备自然语言理解能力、强大的知识学习能力以及复杂的判断能力。结合运维的痛点来看，运维涉及的跨知识领域众多，涵盖各个层次，从数据中心层的 L1 到 L5，再到应用层。尤其是大型机构，其操作变更数量庞大，风险靠人力很难有效管控。如何理顺这些关系，借助决策引擎和大模型的思考能力快速发现隐患，包括后续的告警处理，通过大模型的复杂思考能力结合调用链关系实现快速定位，这都是大模型能够在该领域发挥作用之处。
我们梳理出，集团内部有数千份操作手册，还积累了几百份操作文档。这些内容，无论是通过 RAG 能力，还是大模型本身的微调能力，都可以将其融入大模型，使其掌握更多知识。
02 大模型与智能体技术
说到大模型，就不得不提智能体，自去年以来，智能体的概念异常火爆。
大模型将成为颠覆式的技术创新
先来看大模型，从 2023 年至今，大模型的能力基本上每三个月就能提升一倍。刚才许多专家和领导都提到了 DeepSeek，我认为它在一定程度上颠覆了之前那些缺乏慢思考能力的模型，解决了很多实际问题。就像我们在业务场景探索时，之前集成了各种指标库、指引库，当将其迁移到 DeepSeekR1 上后，即便不使用我们自己的 Agent 框架和指引库，准确率也能达到较好的效果。
大模型Agent是什么
再说说 Agent，Agent 这个概念早在 20 世纪 80 年代就已提出。早期的 Agent 主要用于接收指令并执行一些具体任务。而大模型 Agent，我认为它既可以具备简单 Agent 的能力，也可以具备复杂 Agent 的能力。复杂 Agent 必然具备强大的规划思考能力以及自我反思决策能力，能够不断迭代优化自身的判断。自 2024 年 Agent 技术兴起后，其火爆程度远超之前的多模态模型。而且，随着 Agent 的出现，许多基于 Agent 的应用如雨后春笋般一夜之间大量涌现。
AI Agent与Prompt工程
接下来看看大模型和智能运维在技术领域的情况。
其一，基于基础模型 + prompt 的方式，能够实现简单场景的应用。目前，在众多行业领域，尤其是在智能实践和智能运维领域，这是应用最快、最容易实现的方法。其二，结合编排能力，也就是我们所说的低代码、Agent 框架。通过 Agent 框架进行工具集成，Agent 平台通常会自带 API 集成以及传统工具集成功能，利用 function code 能力调用各种工具，并通过前端大模型的规划，生成各种子任务去执行。此时，结合调用链和 Agent，就形成了一个简单的 Agent。而复杂 Agent，我认为在未来是非常必要的。Model Agent 将结合大参数量模型、小参数量模型、传统模型、已有的内部 API 以及各种工具，形成复杂任务的解决方案。
大模型技术发展
这是去年我在一个论坛上了解到的情况，当然今年可能会有所变化。最初，我们更多地是对模型进行调优，基于开源模型注入大量自己的数据，采用 SFT 的方式进行专业领域的优化。但随着 RAG 能力的成熟以及模型能力本身的提升，从数据中我们可以看到，RAG 的使用率急剧上升（如图中不同颜色所示），Prompt 的使用率在下降，Agent 的应用也在不断增加，而 Fine-tuning 调优随着模型能力的提升逐步减少。因为很多问题通过基模加 promote 就可以解决。这是目前的现状。不过，随着 R1 的出现，我们认为模型能力将进一步增强，所以通过 prompt 加基模或许能解决大部分问题。但对于专业领域，尤其是像需要私域支持的智能运维领域，可能仍需要 FTA 调优才能达到较高的准确率。
在运维领域，运用大模型主要有三种模式：
嵌入模式：在某个功能环节使用大模型，可能是智能体，也可能是模型调用。
Copilot 模式（助手模式）：在实践过程中，这种模式相对容易实现。通过内部接口，结合能力识别或意图识别查询，该模式在主动场景中的应用较多。完全智能体模式，即 Model Agent 模式：通过大模型自主规划任务，只需向其下达指令，它就能拆解任务，并调用注入的各种能力或插件执行固定任务。这也是我们今年计划开展的工作。Copilot 模式我们在 2024 年已进行实践，在智能体模式中，我们解决了一个关键问题，即内部调用的安全性和调用准确度问题。通过现在所说的 MCP 注册能力，以及类似安全网关的措施来保障安全，确保执行的可靠性。最后一种模式短期内落地可能相对困难，前两种相对简单一些。
03 大模型运维场景建设
再和大家分享一下我们在大模型运维场景的建设情况。
大语言智能运维领域产品的发展
我们主要是结合自身痛点以及行业实践情况，同时调研了外部在智能运维领域表现出色的厂商。我们发现，这些厂商的实践主要集中在几个领域：第一是知识问答和知识查询，通过知识库能力，能够快速变现，解决业务痛点，大多数厂商在这个领域都做得不错；第二是代码生成，这也是较为普遍的应用；第三是信息查询、运维报告以及流程自动化。流程自动化是通过自动化编排能力实现一些复杂工程，相对来说难度较大，而前三个场景目前在行业内的实践较多。
运维大语言、模型(“懂运维的大语言模型” )
在运维领域应用大模型也面临一些挑战及解决方案。在实践过程中，我们遇到了一些问题。其一，运维对错误的容忍度较低，存在大模型幻觉问题。我们通过 RAG 能力，结合工程手段以及编写一些规则库来保证准确率。其二，数据标识和数据语料量大，标注困难。目前，我们考虑采用自己标注或做 QA 对模式进行训练，但尚未选定具体使用哪种模型。因为目前在行业内，针对运维领域表现特别出色的模型较少，专门用于运维领域的模型评测以及推荐使用的大模型也不多，这部分工作我们会在后续推进。其三，关于 model Agent 调用工具的准确度问题，我们也在思考解决方案。目前，我们结合新出现的一种模式 ——MCP（类似于服务网关），结合 function code 以及模型调用 API 的能力集成。我们认为，通过这种方式，一方面可以解决调用准确度问题，另一方面也能解决调用安全问题，目前我们正在探索中。实际上，对于 function code 调用问题，我们也进行了研究。如果一个 Agent 要调用数百个以上的 API，对模型幻觉会带来较大挑战。所以，我们可能会将其拆分成不同的 Agent，分别执行不同的 API 调用，或者将调用数量维持在几十个以内，这样准确率相对更可控。
这就是我们所说的 RAG。我认为 RAG 在业务场景中，比如在太保的许多业务场景以及运维领域，包括我们的手册、产品文档、变更等方面，都有很大的应用空间。这是我们的 RAG 建设路径，应该具有一定的通用性。大家可能也都在进行类似的工作，包括梳理需要哪些文档。目前梳理出，仅厂商的产品文档，每个专业就有大几千份，再加上我们自己积累的变更手册或问题处理手册，也有大几百份。对这些文档进行预处理后，通过向量化模型集成到向量数据库中。向量化模型和向量数据库属于我们集团统一中台能力建设的范畴，并且在知识库领域也进行了相关完善，包括整个知识库的权限管控等方面的能力建设。
介绍完 RAG 能力后，通过大模型调用 RAG，输入准确的语料数据、向量化数据，以 promote 的方式输入到大模型中，经过分析后输出参考结果，这就是 RAG 的能力。对于整个 Agent，最初在业务开发阶段，我们自研了一套 Agent 框架，主要建设了一些规则库、指引库，以及注册了一些 API。通过规则库和指引库指导模型，结合 function code 的描述能力，来调用具体执行哪些操作。但现在看来，图中展示的整个 Agent 框架更加完善，并且具备了一些反思能力。在之前的实践中，我们也曾尝试运用反思能力，但更多的是通过 bad case 知识库，采用 SFT 模式训练模型，在实践过程中，这种方式的效果相对较好。
接下来讲讲几个应用场景。
第一个落地较快、相对复杂度较低的场景是知识问答。在运维过程中，将我们之前提到的所有产品文档、变更手册，通过 Chatbot 模式，在遇到问题时检索知识库。在传统领域，知识库主要通过关键字检索和文档定位的方式，但这种方式在效率和准确率方面，不如大模型的表现。
第二个场景是代码自动生成。在我们的实践中，如果只是让开源模型或代码模型简单编写脚本，还是可行的。但要在研发团队中推广工程化能力，就需要一个具备工程化能力的代码助手。因为这不仅涉及模型能力，还需要集成许多周边能力，辅助开发工具。不过，在运维能力方面，通过简单的代码模型生成脚本，基本可以解决一些小问题。
第三个场景是信息查询。这也是去年试点工作的重点。在运维或变更过程中，通过信息查询找到现有关系，生成变更方案或排查变更问题。该场景在安全可控方面相对可靠，并且可以将我们已有的 seems（音）工具 API 集成进来，通过生成规则，结合 function code 能力传入参数，将用户指令信息转化为用户所需信息。例如，查询主机监控信息以及其上具体的应用等，这些在我们的配置信息中都可以查到。
第四个场景是故障诊断和报告生成。我们在告警领域进行了初步尝试，尚未对模型进行专门训练，采用的是通用模型，之前主要使用 72B 模型。将告警信息、提前定义好的规则信息以及知识图谱信息作为 prompt 输入，但效果准确度不高。我们认为这可能是由于模型对运维知识领域的训练不足。目前，我们打算切换到 DeepSeek，借助其深度思考能力和已有能力进行分析。虽然 DeepSeek 在 R1 中擅长分析问题，但在运维知识领域可能仍有所欠缺，目前还不能给出很好的建议，但能提供一些参考。
第五个场景是流程自动化。这是我们今年计划试点的 Model Agent 应用场景，主要目标是让其自动生成变更方案，甚至实现自动执行，达成全流程自动化，真正实现 AI 运维能力。不过，这个场景存在一定难度。首先，需要打通周边所有自动化工具，包括监控接口，并找到合适的模型，使其能够理解我们的意图，调用相应接口完成任务。而且，这个流程相对较长，首先要分析变更期望达到的效果，在前端需要采集大量信息，才有可能生成变更方案。并且，在实施之前，可能需要在 UAT 环境或开发测试环境进行验证。整个流程可能需要多个 Agent 同时协作。目前，我们考虑通过 R1 进行任务规划，规划完成后生成各种专项 Agent，通过 Agent 协作的方式得到结果，再将结果反馈到规划模型中，以便进一步执行。目前，我们的工作还停留在生成变更方案参考阶段，并且需要结合我们自己的 ITSM 工具，生成变更方案并协助推进变更流程，但在真正执行时，可能仍需要人工参与，这是我们目前的想法。
下面看看我们去年在一些领域的实践情况。主要是开展知识问答，将大量已有知识融入 RAG 知识库，并通过前端页面实现。在知识库中，我们实现了租户级管理能力，包括知识库完善和用户权限管理等功能。这是一个简单的 Agent，通过 prompt 优化实现。我们结合了行业内的 prompt 优化工程化能力，关联知识库，通过全局配置实现，并且可以选择多种模型，目前提供了一些开源模型和闭源模型，通过 API 方式对外提供服务，这就是知识库的建设过程。去年，我们还实现了简单 Agent，具备了 Seems 和 CMDB（音）的简单查询能力。
最后讲讲大模型从训练到在智能运维领域落地的过程。目前，基模能力在通用知识方面表现良好，但在运维领域的垂直知识方面仍有所欠缺。我们尚未找到一个能够完全解决运维问题的大模型，所以可能还需要进行 SFT 微调，结合 prompt 工程和知识库，来实现真正的场景落地。
展望未来，我们看到传统 AI Ops 模型在运维领域，如告警监控、根因定位等方面已取得一定成效。但对于一些复杂知识，比如告警信息，如果不借助知识图谱和传统知识学习，其准确率能否进一步提高，我认为在大模型领域有望得到更好的实践。另外，通过 Model Agent 编排，实现运维端到端的落地，也是我们期望达成的场景。
最后总结一下，我们认为无论是在业务领域还是智能运维领域，大模型都是一种新质生产力。随着新质生产力能力的不断提升，以及各个场景之间的协作，未来在我们的场景中必将百花齐放，各个行业都将涌现出具有独特优势的应用。
今天我的分享就到这里。谢谢大家！
