本文根据9月21日云栖大会—《大模型在大数据智能运维的应用实践》实录整理而成，演讲信息如下：

演讲人：张颖莹 阿里云智能集团算法专家

主要内容：

1. 大模型带给大数据智能运维的机遇与挑战

2. 基于RAG的智能问答

3. 基于Multi-Agent的智能诊断

4. 大模型应用部署工程架构

大家好，我是张颖莹，来自阿里云计算平台事业部，目前主要是负责大数据智能运维算法团队，从我加入这个团队开始，我们已经在智能运维这个方向上深耕了八年的时间，这个过程积累了很多有趣而且有价值的应用场景，而毫无疑问大模型的浪潮给智能运维这个领域带来了一股更强大的推动力，所以很高兴今天有机会来和大家分享我们最新的一些结合大模型的实践。 首先我会从大数据运维的业务背景出发，向大家展示大数据运维人员的日常工作究竟面临着怎样的挑战？我们又应该如何选择业务切入点才能真正抓住大模型带来的机遇。接着在第二和第三部分，我会结合两个非常经典业务场景，智能问答和智能诊断，来给大家分享我们是如何提升大模型在实际落地当中的效果，最后我们也会为大家来揭示我们所搭建的这套大模型应用背后，究竟依赖了怎样的工程架构？

01大模型带给大数据智能运维的机遇与挑战

接下来就让我们进入第一部分，我们计算平台整合了阿里云的大数据以及 AI 相关的能力，并且以产品化的方式支撑了集团内部以及云上各行各业客户的核心业务场景。这里我列举了其中几个典型的产品，他们所支撑的场景也和大家日常生活息息相关。比如 Maxcompute，它主要负责大规模海量数据的离线计算，大家网购之后在手机上追踪的菜鸟物流数据就依赖于它的定时产出，而在一些智能驾驶的场景当中，系统会对司机的危险驾驶行为进行实时的监控告警，这些追求实效性的数据往往就依赖于向 Flink 这样的实时大数据处理系统，而我们日常在手机淘宝搜索一些商品关键词时，Hologres 则会在底层去进行实时交互式分析，为我们提供精准的搜索推荐结果。随着大模型的发展，大家对模型的训练和推理需求也有了爆发式的增长，机器学习模型相关的训练、微调和在线服务都可以在机器学习 PAI 平台上进行。

不难看出，这些平台的上层支撑了大量用户的核心业务，并且客户对于云服务产商服务能力的要求在不断提高，精细化运维在逐渐成为一个趋势，而这些平台的底座所对应的则是超大规模的计算集群，这些集群不仅是全球化部署的，而且无时不刻都在产生海量的数据。因此要做好这些产品的运维工作并不是一件容易的事，传统的人肉运维很容易让运维人员沦为背锅侠的角色，因此我们计算平台也设置了一支专门的运维中台研发团队，也就是我所在的团队来负责这些大数据产品的统一运维管控。我们也一直坚持利用 AI+数据+工程的手段来提升运维效率。毫无疑问，大模型技术的发展给我们的智能运维工具箱又增添了一把利器。

接下来我们就来讨论一下，大模型究竟给智能运维带来了哪些机遇。

我们都知道大模型在2022年随着 Chatgpt 的发布迎来了爆发式的发展，其中大模型自然的交互方式、丰富的知识储备，以及一定的推理能力，甚至是自我反思和优化的潜力都让大家感到非常惊艳。考虑到大模型所拥有的这些特长，再结合我们前面提到的大数据运维的两个痛点问题，也就是精细化运维趋势，以及海量数据的全面分析需求，我们想到了两个适合大模型与智能运维结合的落地场景，一个是用户智能答疑，另一个则是平台智能诊断。

当然，直接将一个大模型基座应用在答疑或者诊断场景会面临着很多问题。首当其冲的就是幻觉问题，这面向用户的答疑场景中可能会带来严重的误导作用。第二个问题就是大模型本身的知识更新是非常缓慢的，这就可能导致我的平台已经升级，但大模型的知识储备可能还是针对前一个版本的。如果我们选择直接对大模型进行微调，又需要花费比较高昂的成本，其中包括高质量的数据和大量的算力。

02 基于 RAG 的智能问答

为了解决我们前面提到的这些挑战，我们首先在大模型智能答疑的场景中引入了检索增强生成的方法。

检索增强生成也称为 RAG 是指我们借助外部的向量数据库，根据用户问题检索最相关的参考内容，将这部分信息作为额外的知识提供给大模型，生成对应的答案。这种方式相对于让大模型直接生成答案的方式，就好比是从闭卷考试转化成了开卷考试，使得大模型回答可以更加有理有据，减少我们前面提到的幻觉问题。

此外对于大模型知识更新慢的问题，引入了检索增强之后，我们只需要定期更新向量知识库即可，这比重新训练模型的成本就小多了。一个标准的 RAG 流程通常包含知识构建、知识检索和答案生成三个阶段，目前阿里云的很多 RAG 相关产品都具备比较完整的解决方案，因此想要快速搭建起这样一套 RAG 问答系统并非难事。但是想让这套系统在真实的业务场景当中答疑效果更上一层楼，我们依然需要结合自己的业务特点做一些因地制宜的改进。因此接下来我会重点分享一下我们在知识构建和知识检索阶段做的一些算法优化。

首先是知识构建阶段，大数据答疑场景的知识基本都来源于产品和技术文档。这些文档和多数程序员的思维方式很像，都是高度结构化的，大标题下还会细分若干子标题。如果我们采用简单的切片方法，无论是按照固定长度或者是特定格式来切片，都容易丢失掉大标题和小标题之间的内在主题关联，所以我们采用了一个多粒度的知识抽取框架。

我们首先利用大模型对全文进行总结，然后将全文摘要作为背景知识，进一步对各个一级标题下的内容进行总结。接着我们将一级标题的摘要和二级标题下拆分的文档块一起，利用基于 Qwen 微调过的 Doc2QA 算法抽取出对话形式的知识。之所以要将文档抽取成对话形式的知识，是因为它更加符合我们答疑场景中用户提问的特点，因此可以提升后续的检索质量。完成了知识抽取之后，我们就可以将它向量化之后存储到某个向量数据库中。

这里我们选择的是 OpenSearch。其中内置了多个行业的专业词表、并且提供很多高效的检索和排序算法能力。而且它还针对用户的不同需求提供了不同的版本，既能满足快速搭建基础 RAG 系统的需求，同时它重开放的能力也支持我们进行一些个性化的开发。

完成了知识的储备后，接下来就到了知识检索这个关键环节。在真实的问答场景中，用户的问题可能非常简短和模糊，因此我们首先需要对用户的问题进行语义扩充和改写。接着我们会采用向量检索和稀疏检索结合的多路召回策略，在圈定了一定范围的语料后，再使用重排算法进一步提升语料排序的精度。

这几个环节，Opensearch 中都内置了丰富且高效算法策略供用户选择， 这套方案也可以应对大多数的用户提问， 但是依然存在着部分疑难问题，我们完全无法检索到相关语料，这时候该怎么办呢？通过对业务问题进行分析，我们发现其中主要的原因在于我们前面的语料切分和知识构建环节，每篇文档都是独立进行切分的，而忽略了文档当中存在的引用关系，这就导致我们提取的知识中损失了文档之间的关联信息。

要解决这些疑难问题，我们需要更加充分的利用文档与文档之间的这种关联关系来提升 RAG 的检索效果，因此我们设计了一套 RAG On Graph 的算法。不同于微软前端时间开源的 GraphRAG，考虑到构建成本和知识迭代的速度，我们并没有引入知识图谱的概念，而是直接利用产品文档的天然目录结构来构建关联树，这颗关联树自顶向下分别是各层目录下内容的总结，矩形的叶子节点代表着对应文档路径下的语料切片，同时我们还维护了和矩形叶子结点的关联文档，包括上下文和引用关系。

针对于朴素方案无法回答的疑难问题，我们首先检索出若干候选的的矩形叶子节点，并且根据文档路径从完整关联树当中过滤出子图，在这个子图上，我们利用相似度算法自顶向下地进一步筛选出最相关的矩形叶子结点。之所以采用自顶向下的筛选方式，是因为它比较符合我们人工阅读技术文档的思维方式，通常我们会先挑选主题相关的目录，再层层往下找到我们关心的知识。最终，我们会把挑选出的矩形叶子节点语料以及它的关联知识全部都输入给大模型，使得我们的大模型可以在拥有更加完整视角的基础上做出更好的回答。

聊完了知识构建和知识检索，在答案的生成阶段，我们主要针对 prompt 进行了一些设计和优化，主要从有效性、准确性、和安全性几个维度进行考虑。比如相关的论文表明，大模型对于在 prompt 前面和尾部的内容会更加敏感。因此我们对于 prompt 当中内容的排序和位置做了一定的设计。

此外，在朴素的 RAG 链路当中，大模型容易将超链接和代码也作为生成内容的一部分，这可能导致出现无效链接和错误代码。因此我们针对超链接和代码片段做了专门的索引，确保大模型最终生成的内容当中不会对超链接和代码片段进行随意的篡改。

最后，为了确保我们生成的内容安全合规，我们还在生成结果的最后增加了一定的敏感词检测机制，防止一些恶意使用大模型的行为。除了前面所提到的几项技术外，我们也在关注一些前沿的学术研究成果，并且在实际工作中进行尝试，比如引文自动生成，以及如何通过引入反思机制来进一步提升结果可靠性等等。

目前我们的整套方案已经在阿里集团内部各个大数据计算产品的答疑群，大数据技术服务助手钉钉机器人以及各个大数据产品的开发页面均已上线，持续地在为集团内部数万名大数据AI开发者提供了7乘24小时的智能答疑服务。

到这里，我们已经帮助运维人员解决了面向用户答疑的痛点问题，但是对于大数据运维同学来说，悬着的心还只能放下一半，平台整体稳定性的保障依然占据着他们大量的时间精力。而且不同于用户答疑场景，很多问题存在固定的标准答案。对于平台诊断来说，即使存在一个排查问题的流程，要想真正诊断出问题根因，依然需要结合数据具体问题具体分析。因此在这个问题上， 我们就需要引入一些新的技术框架，让大模型变得更加灵活。

03基于 Multi－Agent 的智能诊断

在解决这个问题之前，我们首先可以回忆一下日常出现平台稳定性问题时，运维人员是如何工作的。通常我们会成立一个故障应急小组，小组中会有比较明确的分工，每个模块的负责人分别去排查各自模块的问题，并且和上下游模块做一些沟通，并给出各自的结论。最终由故障的整体应急负责人来对整个故障进行信息汇总和总结。

我们希望基于大模型构建的平台诊断系统也能模拟出这样一个故障应急团队，首先需要让大模型具备更高的主观能动性，也就是更加地拟人化，因此我们引入了 Agent 智能体的概念。一个标准的智能体通常至少会包含三个模块，也就是 Memory，Tools 和Planning。其中，Memory 主要是用来存放长短期记忆，Tools 是这个 Agent 所能够调用的工具集，而 Planning 则决定了 Agent 的思维方式。

除此之外，对于一个故障应急小组，内部的分工非常重要，并且每个角色都应该具备自己的专业性和特长。所以单一的智能体是不够的我们引入了多智能体的框架，按照系统模块，赋予了Agent不同的角色，他们就好比是现实中各个模块的专家，我们还设置了系统Agent，来充当故障应急负责人的角色。

完成了角色设定之后，接下来我们就要来丰富 Agent 的装备库了。我们的装备库中主要包括核心工具和某些角色特有的自定义工具，这里主要为大家介绍具备通用性的核心工具。第一个是指标异常检测，我们对运维场景中常见的异常类型进行了梳理和总结，并定义了五种典型异常，包括均值变化，方差变化，尖峰深谷、断崖式下跌和趋势预警，这种梳理不仅能帮助我们更加全面地发现异常，而且可以将异常模式的描述也作为工具的输出，从而给大模型更多的信息。

除了指标之外，日志也是运维场景中最核心的数据之一。因此我们的第二个工具就是针对日志的异常检测。对于日志分析来说，最大的挑战就是日志的庞大体量。因此我们引入了高性能的聚类算法，利用离线阶段的聚类结合专家经验构建知识库，而实时在线聚类的结果则转化成曲线进行异常检测，最终把存在异常的日志模式和知识库中匹配到的专家经验一起作为工具分析结果提供给大模型。这两个工具都是为了帮助大模型更加高效地分析数据，而我们的第三个核心工具则是帮助大模型更好地从历史经验中学习，我们将历史故障的数值特征和文本特征都存储在数据库中，利用相似度算法挑选出与本次故障最为相似的历史故障，并将对应的排障经验作为背景知识提供给大模型，辅助大模型进行决策。

到这里，我们已经完成了单个 Agent 的角色设定和能力建设，接下来的问题是， 这些专家 Agent 如何进行协同呢？一些开源的 Multi-Agent 框架通常会内置一些标准的工作流，但这些工作流在我们的场景中都存在着一些弊端。比如顺序执行的工作流，会导致上游的节点因为存在信息不对称，从而得出一些片面的结论，进而影响到下游节点的决策，形成误差累积效应。而在层次结构中，尽快存在一个顶层节点来对所有信息进行总结，但下层的各个节点之间并没有交流，依然难以避免片面结论。而圆桌讨论的模式看似大家可以进行充分的信息交换，但这在大模型框架下，可能会导致讨论过于发散，难以在有限的时间内达成统一结论的问题。

为了应对前面提到的问题，我们结合业务场景的特点，设计了一套模拟神经网络反馈机制的工作流。首先我们根据模块间的拓扑和依赖关系，设置了各个模块 Agent 的单项工作流，按照这个方向执行的推理过程我们称为前向反馈。在此基础之上，我们还增加了后向反馈机制，也就是允许某个模块 Agent 在获得了其他模块的信息之后，更新自己的结论。最终，每个模块更新之后的结果都会汇总到系统 Agent 中，进行全面的总结推理，并给出最终结论。

目前我们的诊断能力已经整合到了大数据产品的异常处置流程中，在诊断完成之后，SRE可以在异常处置页面看到系统 Agent 给出的诊断结论，以及辅助大模型进行决策推理的历史相似异常。当然我们还可以看到每个模块 Agent 的分析结果，点击详情还可以看到具体的指标和日志情况，可以给运维人员的故障排查提供关键信息总结和决策支持。

04大模型应用部署工程架构

无论是面向用户的智能答疑还是平台诊断，大模型服务的时效性和稳定性都非常关键，因此一套合理的工程架构也是保障大模型应用效果的重要基础。

可以看到在整个框架的最底层是数据层，我们为运维场景中指标、日志、拓扑、文档、事件等等不同形态的数据安排了最合适的存储方式，在数据层之上，则是我们核心的算法服务层和大模型服务层。其中算法服务层主要承载通用的基础算法能力，比如我们前面提到的指标异常检测和日志异常检测等等，这些算法服务的训练、推理和计算可以基于机器学习平台 PAI 和实时计算 Flink 进行构建，并且根据实效性的需要和算法本身的运行性能，选择部署成触发式或者是常驻式的，之后这些算法能力就可以绑定到 Agent 上作为工具进行调用。

当然除了工具管理之外，在大模型服务层我们还需要对 Prompt、工作流进行管理。同时我们前面提到的各种模块 Agent 本质上只是一种抽象类，具体到某个集群某一次的诊断，我们都需要将这些抽象的 Agent 进行实例化，并且每次的调用都需要具备可观测能力，方便我们进行排查。如果涉及到人和大模型的提问交互，我们还需要对对话进行管理，维护大模型的短期记忆，而长期记忆则更多依赖 RAG 进行。

有了这样一套工程框架之后，我们的开发和部署流程就变得非常容易。首先工具的开发和 Agent 的开发可以解耦开来，团队之前积累的算法能力可以方便进行复用，提升开发效率。同时 Agent 的开发我们采用了本地开发+云端部署的模式，语法与 Langchain 兼容，所以算法开发者可以在本地用 Langchain 进行调试，然后无缝部署到我们的框架中。同时我们还构建了可视化的界面，用户可以在页面上完成智能体的角色设定、思维链设置以及工具和实例化参数的管理。

最后为了防止大模型的运行过程变成一个黑盒，我们也构建了比较全面的可观测能力。既包括每个 Agent 自身的工具调用和思维链可观测，以及多 Agent 之间的工作流执行可观测，同时如果涉及人机交互，我们还设置了对话的可观测。右边的这幅图就展示了，在平台智能诊断中，我们可以查看每个 Agent 单个工具的输入输出，这样在大模型推理结果不符合预期的时候，可以方便算法和工程同学进行问题排查，不断提升大模型应用的效果。

05总结和展望

最后，我们对今天的分享进行一下快速的总结。我们首先从大数据运维的背景出发，探讨了大模型给智能运维带来的机遇以及落地过程中的挑战。接着我们结合智能问答和智能诊断两个真实的业务场景，给大家详细介绍了我们是如何利用 RAG 和 Multi-Agent 框架来提升大模型的落地效果，并且还和大家分享了我们背后的工程架构设计。大模型在问答和诊断场景创造的业务价值，也让我们对大模型与智能运维结合这个方向有了更多的期待。而想要获得更好的应用效果，我们还需要在以下几个方面持续进行能力的提升。

首先是更强大的模型基座，无论是在多模态数据的理解还是推理稳定性方面，都会对应用效果带来重要影响。

其次是更自然的人机交互。为了避免大模型应用成为黑盒，并且希望它少走弯路，那么人的适时反馈就很重要，所以我们需要更加自然和多样化的人机交互形式。

第三，我们需要更加灵活的工作流编排能力，来适应复杂的业务场景。最后就是更加敏捷的大模型开发和运维流程，可以让大模型的效果提升可以更加地自动化。大模型的发展速度可以用日新月异来形容，我相信他可以给智能运维这个领域带来更多突破性的进展，也期待后续有更多的成果和大家交流分享。