监控运维产出的海量数据常受数据质量波动、标注不足和链路上下文信息缺失等问题影响，这些挑战为 AIOps 的应用带来了不小的难题。伴随大模型的崛起，业界对其在多模态数据理解和处理上的能力抱以厚望，期待大模型能优化 AIOps 在数据理解、关联和交互体验上的表现。
在日前的《超级连麦. 数智大脑》x ArchSummit 直播中，阿里云 AIOps 架构师董善东博士、群核科技云原生观测 / 技术专家何碧宏、腾讯文档高级工程师张瀚元，聚焦企业在实际的业务场景中利用 AIOps 提升业务效能时遇到的挑战以及解决方案展开了深入交流，同时还探讨了大模型时代下 AIOps 的创新架构，以及大模型如何为 AIOps 带来新的变革和潜能等话题。
以下内容根据对话整理，篇幅有删减，点击链接可观看直播回放：https://www.infoq.cn/video/AQZtO8Le5MRkuyWq1yaP
ArchSummit 深圳大会议程已经上线，感兴趣的同学请锁定大会官网。
何碧宏：AIOps，即智能运维，是一种利用人工智能技术，包括算法和大模型，来自动执行和简化运维工作流程的技术方案。作为云原生观测和 SRE 团队，我们主要关注在稳定性保障方面的应用和价值。引入 AIOps 希望通过 AI 算法简化和自动化传统运维操作流程，并解决一些传统运维难以解决的问题。
一些场景，比如在传统手动配置中，我们经常遇到动态配置和告警规则配置的问题，例如设置多大的阈值合适。如果每个人都手动调整，工作量会非常大。因此，我们希望通过算法实现动态阈值的功能。此外，指标异常检测也是一项庞大的工作，需要识别每种指标的持续时间、波动大小等。我们希望通过算法实现智能检测功能。在容量评估方面，我们希望能够预测未来的流量，从而计算出未来的资源使用量和扩容时间。变更风险预测也是一个场景，希望通过算法或智能方式预测变更可能造成的影响，引导变更人员进行更有针对性的检测。此外，根因分析在微服务架构下尤为重要，底层服务故障可能导致连锁反应，根因定位策略复杂且思路繁多。我们也希望能通过 AI 算法进行归纳，智能定位根因。
我们公司是一家面向全球的 SaaS 服务提供商，专注于为企业服务。对于客户，尤其是重点客户的保障尤其重视，我们几乎需要快速回应和解决每一个工单客诉。在解读和复现客户提交的工单故障方面，我们通常需要投入大量人力。我们希望通过 AI 能力对重复性工单故障进行聚类、归类，并自动化解读，预先提供有用的分析信息，以提高技术支持和开发人员的效率。
我认为，无论传统运维还是 AIOps，都需要为效果负责。两者最终需要结合互补，以实现最佳效果。
张瀚元： 身为业务团队，我们所面临的痛点和问题，以及我们所站的角度、立场与理解可能跟何老师存在不少差异。我对 AIOps 的理解定义简单明了，即 AI 与 Ops 的结合。通过自动化和工程化手段，AIOps 能够帮助业务提升研发效能。
我的理解是，要在实现智能化之前，首先需要实现工程化。通过工程化手段，我们能够以较低成本实现智能运维。在低成本的工程化智能运维基础上，再进一步通过 AI 和大模型来提升效率，带来智能化的解决方案。
对于业务团队的成员，尤其是新成员来说，在海量的微服务场景下，整个系统的庞大架构难以理解，上手也相对困难。在这种情况下，基于工程化的方式推出 AIOps，可以帮助团队成员快速了解系统。例如，通过智能告警和智能链路分析，团队成员能够从宏观层面快速认识整个系统。在此基础上，再利用大模型和 AI 的基础，对系统进行更深层次的理解。我非常认同何老师的观点，无论是传统的 Ops 还是 AIOps，最终都要为业务效果负责。两者需要相互融合、相互补充，以实现为业务带来更大价值的目标。
张瀚元： 在进行 AIOps 时，我们团队比较关心的几个点包括：
人力成本： 如果每个业务团队都组建自己的 AI 或运维团队，对业务来说会是一个较大的负担和成本。我们首先考虑的是避免大量重复的人力成本投入。更好的做法可能是在整个部门或公司内拉通视角，寻求通用的解决方案，这样既可以降低成本，也可以让专业的人聚焦做专业的事。
AI 系统基础设施建设： 过去几年，我们主要精力放在了 AI 基础设施和监控可观测性基础设施的建设上。在完成底层可观测性基础设施的标准化建设后，我们在数据层面和标准协议层面有了良好的统一。实现这些统一后，我们再进一步建设上层的 AIOps 技术能力，这对我们整体规划来说是一种比较合理且高效的方式。
算法选择和模型优化： 前期我们会更关注成本和基础设施建设。随着时间的推移，我们未来可能会更加关心算法的选择和模型的优化。
何碧宏： 我们所关心的问题主要集中在以下几个方面：
首先是成本问题，特别是人力成本。 作为中小型企业，在人才资源上不如大公司丰富，人员流失问题也较为严重。因此，对于算法的可持续性以及整个算法解决方案的可持续性非常关键。另外，AI 算法相比传统程序在资源消耗上要高很多，这导致硬件成本和其他相关成本也相应提高。
其次，我们非常关注算法的实际效果，如准确率和召回率。在真实场景中，如何提升算法效率，以及算法的准确率和召回率是否存在上限问题，都是我们所关心的。系统和代码的变更或系统架构的调整可能会影响到原有分析，这就要求我们对算法、解决方案和数据进行相应的调整。在变更后，如何保证项目的可持续性，保持其“保鲜”，这也是我们关注的问题。
最后是实施过程中的问题：包括选择合适的算法和训练数据的规模与质量。数据质量对算法准确性的影响非常大，尤其是训练样本的质量以及噪音处理，这些都对准确率起着决定性作用。因此，如何以低成本实现数据的持续自动化清洗和样本数据的准备，也是我们非常关心的问题。
董善东博士： 作为云厂商的代表，我想补充一个可能业务团队或 SaaS 产品团队不太关注的问题，那就是如何保证 AIOps 算法模型服务的通用性。这是云厂商目前面临的一个较大问题和挑战。一方面，我们可能依赖于内部数据，或者根据某些客户的数据进行微调，从而得出一些在特定业务场景下运行良好的模型。但问题是如何提高这些模型的泛化性，使其能够跨不同行业、不同类型的客户进行复制和应用。遵循 Scaling Laws 这类规则是云厂商需要考虑的关键点。这意味着我们需要思考如何让 AIOps 算法不仅在特定场景下有效，而且能够广泛适用于各种不同的业务环境和客户需求，以实现更广泛的服务覆盖和更高效的资源利用。
何碧宏： 在数据方面，我们面临几个挑战：
首先，数据的持续标注和刷新是一个问题，这通常需要大量的人力劳动。
其次，我们在处理业务故障这类小数据问题时，由于故障发生的数量不多，原始样本数本身就很少。在这种情况下，如何通过算法提高故障定位的准确率，是一个需要解决的问题。
第三个问题是监控数据的多样性。指标、日志、调用链、警报等数据的格式可能各不相同。然而，在进行根因定位时，我们需要将这些不同格式的数据进行串联和融合分析，这也是一个具有挑战性的问题。
董善东博士： 在数据质量及其上下游标准问题上，我个人的体会非常深刻。
首先，数据质量对算法模型至关重要，有一句话说得好："垃圾进，垃圾出"。如果监控平台的稳定性不够，可能会导致数据未上报或数据缺失，即使再优秀的算法模型也难以应对这种情况，必然会带来干扰。
另一方面，数据的全面性和关联性也是一个问题。我们需要考虑数据如何可以有效地组织关联起来，输入给模型完整的上下文。在这方面，阿里云的实施经验主要是结合追踪（trace）内容，构建端到端的追踪点。从用户的单次请求开始，到访问的网关、后端接口，再到应用部署的服务器或机器资源，端到端地构建整个请求过程。然后基于这样一个确定性的追踪链路和拓扑，构建根因诊断的能力。
张瀚元： 数据是我们所有 AI 应用、包括 AIOps 和大模型的基石。没有数据，我们无法很好地完成工作。因此，我们前期非常关注数据模型和标准化 方面的工作。我们前期遇到的最大挑战是，腾讯内部存在不同的平台和组件，以及不同的数据模型和协议。所做的第一件事就是统一所有底层平台的数据模型和协议，使我们拥有统一的标准化模型。这样一来，整个系统的输入输出就完全可控且标准化。后续再进行上层建筑的建设时，就能达到事半功倍的效果。
第二个问题是私有化和 SaaS 场景中的挑战，特别是在私有化环境中，我们需要将整个系统部署到客户那里。一旦系统脱离公司的基础设施，其运行状态就会处于未知领域。我们如何确保在客户环境（B 端）和我们的 SaaS 环境（C 端）保持统一的架构，以及组件生态和接入系统的接入标准实现统一？如果不统一，势必会带来一致性的接入问题。接入标准不统一以及 BC 端系统架构不统一会带来很多问题，在这个过程中，我们进行了很多思考，并实现了 BC 端架构的完全统一，选择了社区生态完善、标准化的组件进行接入，并统一了接入标准。这样，无论是 C 端还是 B 端，在进行业务交付时，都能享受到标准化所赋予的长期优势。
董善东博士： 标准化确实是非常重要的议题，目前各种社区也在积极推动这方面的工作，构建接入标准。OT 生态非常丰富，不仅覆盖了指标、日志、trace 等，还可以通过 OT 这样的协议格式进行接入，同时也支持其他协议向 OT 协议转换。统一的标准协议对于构建系统确实至关重要，这样 AI 算法模型就可以更多地专注于模型本身，而不是底层的数据格式转换、数据清洗和对齐。
关于数据问题，我想补充一点，AIOps 场景目前是以任务驱动或场景需求驱动的。每个场景、每个任务可能都需要构建一个专属的算法模型，这个模型可能是基于专家经验规则的，也可能是端到端的 AI 模型。如何持续构建带标签的数据集，对于能否持续提升 AI 算法模型的效果非常关键。因为通常很难构建一个反映真实业务反馈的数据集。这时，如何提供一个接近真实反馈的数据集就显得尤为重要。另一方面，在 AIOps 场景下是否可以更多的利用无监督或自监督的方法，也是需要重点考虑的。通常依赖于有监督的算法模型，其天花板较低，短期效果可能会好一些，但因为获取高质量带标签的数据集的难度太大导致无法持续调优。
何碧宏： 这里，AIOps 与 DevOps 的一个区别是使用了 AI 技术，DevOps 可以与 AIOps 结合，实现更自动化和智能化，DevOps 可以朝着这个方向演进。智能变更是 DevOps 中一个非常适合结合 AI 的场景。例如，随着大模型的出现，可以在代码检测、代码缺陷自动发现等方面增加更多的智能。大模型的出现为 DevOps 带来了更多的能力，可以在整链路上实现更智能化的操作。这意味着，通过结合 AI 技术，DevOps 可以变得更加高效和智能，从而提升软件开发和运维的质量和效率。
董善东博士： 我的理解与何老师相同，我认为 AIOps 与 DevOps 并不冲突。AI 可以应用于传统的运维和 DevOps 各个阶段，构建智能化的能力。这使得无论是手工操作还是自动化脚本，都能变得更加智能，从而提高业务的准确率和分析效率。AI 的应用为 DevOps 带来了新的机遇，可以增强开发和运维流程的智能化水平。通过 AI 技术，可以自动化地检测代码缺陷、优化变更管理、提升系统监控和故障响应速度等，这些都是 AI 在 DevOps 中的实际应用场景。
何碧宏： 我们公司目前已经实施了一些智能化的实践，例如在每次代码提交后进行智能检测，以及在开发工具中自动生成测试用例。这些技术已经比较成熟，并且效果不错。虽然这些智能工具的准确率并非百分之百，但它们确实提供了很大帮助。在单元测试编写方面，智能工具显著提高了效率。此外，在测试领域，智能工具能够发现一些潜在问题，尽管对于非常资深的开发者来说，大模型的能力可能还有所不足，但对于保障基础代码质量而言，它们已经有效。
何碧宏： 上面提到过数据打标和持续性问题，简单介绍一下我们的一些体会和经验。最初，我们是自己手动打标和整理样本数据。后面，我们将数据打标工作融入到业务流程中，并通过流程严格要求，让用户帮助准确打标。例如，在警报处理人员处理警报时进行自动打标，填写的根因信息，对警告进行分类，标记是否与故障相关。这样，我们就能将这些数据存储起来，作为复盘或下一阶段训练的数据基础。
针对数据量大的问题，监控数据往往非常庞大，但很多数据实际上并不会被使用，或者对当前分析是无效的、浪费的。因此，我们选择对服务进行分类分级，如公司级核心服务、业务级核心服务、次核心服务和非核心服务，区分出最可能与故障相关的服务；同时也对指标进行分类，确定黄金指标、不同的用途。这样，我们就能明确哪些服务哪些指标作为核心分析指标，需要用到 AI 算法进行预测和分析，将 AI 用在最需要的地方。
对于业务故障小数据问题，我们将演练数据也进行采集。故障演练时，我们会记录故障表现、日志指标等，作为样本数据。这样就能多积累一些数据，帮助分析小数据故障，并结合传统专家经验，共同确定根因。
我们的系统是大型的微服务架构，底层系统故障引发的风暴故障，以及一些业务故障，定位难度很高，我们构建了全链路监控系统来解决这个问题。为了实现全链路监控，我们在指标、日志、调链等数据层面做了串联工作，并基于图数据库构建了全链路拓扑关系。给定任一 API，都能查到所有上下游相关信息，这对全链路分析非常有帮助。这在我们微服务底层故障的警报风暴的根因定位上发挥了巨大作用。我将在「ArchSummit 全球架构师峰会. 深圳站」上详细介绍这个系统的构建过程、解决方案以及实际应用情况。
何碧宏： 一般不建议新手来做这些工作。对于业务数据的梳理，需要业务专家来完成。系统监控的数据，也应该由专家团队来处理会比较合适。
何碧宏： 这个涉及数据的刷新问题。我们的图关系构建是基于实时调用链的，所以可以说是近实时的。只要有一次最新的调用链过来，就能够根据这个调用链更新对应的关系。当然，对于一些历史依赖关系，比如某些关系很久没被调用，现在突然调用了，它会马上更新，确保链路是最新的。而对于那些可能一个月没有调用的关系，我们会设置过期时间，将这些长时间未调用的关系去掉。通过这种刷新机制，我们基本上能够实现接近于实时的数据更新。
张瀚元： 在面临标准化的问题时，我们发现公司内部有许多异构的平台，比如蓝鲸、007、鹰眼等，它们各自执行不同的任务，如监控、日志等，而每个平台的数据模型实现也各不相同。这给业务团队带来了选择的困难，尤其是对于新业务来说，不知道该接入哪个平台，也不了解各个平台的能力，只能依赖现有经验或前人的建议盲目接入，这样对业务缺乏深入思考。基于这种背景，我们决定在标准和协议层面实现统一。
第一，我们与 OpenTelemetry 社区进行了深度合作，在过去几年里为 OpenTelemetry 标准贡献了上百个 Commit 和数十万行代码。我们希望通过与业界最先进的团队合作，在数据标准化和协议标准化方面达成一致。随后，我们参与了中国信通院的一些行业标准的制定，如系统稳定性和根因分析等。在此过程中，我们基于 OpenTelemetry 社区标准和国家标准，制定了公司内部的企业标准。通过这些标准，我们在公司内几乎所有业务团队、中台团队和运维团队中达成了统一的数据模型。这样，业务团队在使用不同平台时，如果因为组织架构调整或其他原因需要切换平台，可以在不进行任何改造的情况下，以非侵入方式零成本地切换到兼容标准的另一个平台，从而在数据层面实现一致性。之后，我们联合打通公司内其他平台和团队，成立了一个 OTeam 组织，共同在可观测性和根因分析等领域开展工作。
第二，我们基于现有的数据模型，通过工程化方式以低成本实现多个数据源之间的关联查询和分析。这为 AIOps 的应用奠定了基础。大模型的运行成本较高，而我们的目标是通过低成本实现智能告警、编译和分析等 AIOps 手段。基于标准化的数据模型和 OTeam 的努力，我们达成了这一目标，并在智能告警、跨数据源联合查询上申请了多项国家发明专利。
第三，在私有化领域，我们需要对接客户的环境，这些环境通常脱离公司内部基础设施，无法使用公网的 AI 能力，如 ChatGPT 或其他云厂商甚至客户自身的 AI 能力。因此，我们需要提供一套统一的接入标准和准入标准，有了这套标准，我们能够解耦 AI 能力提供方和系统本身，基于我们的数据实现上层 AI 应用。
张瀚元：22年的 10 月份 ChatGPT 刚问世，对于国内来说，大部分公众可能是 23 年初才逐步接触到这个技术，到现在也有一年多的时间了。在这一年多的时间里，大模型在各种场景中得到了广泛应用。比如在我们自己的业务中，腾讯文档内部提供了 AI 智能助手功能，能够辅助文档编写、函数生成以及 PPT 生成等。
在接入过程中，我们发现 AI 最大的挑战是训练成本非常高，每次处理 Token 的消耗都很大。如果把无关的上下文数据一股脑丢给模型，Token 的消耗会非常剧烈。因为我们每天在标准化平台上可能有几万亿新增数据，存储量达到 PB 级别。如果全部数据都交给 AI 进行学习，成本会非常高。因此，我们首先提取有效信息，基于标准化的数据模型和框架层面的能力，我们提取出一些错误信息所属类型，如中间件错误、网络错误和操作系统错误。针对这些细分领域的问题，我们再补充相应的数据给模型结合相适应的 Prompt 进行训练，以有效减少学习和训练成本。
接下来，我们通过工程化手段对可观测性指标和数据进行初步提取、分析、提炼，最终生成服务质量汇总报告。传统团队评估系统稳定性通常使用 SLO（Service Level Objective，服务等级目标）和 SLI（Service Level Indicator，服务水平指标）指标，这需要数据分析系统和人工总结报告，发邮件等。通过 AI，我们可以将日常监控数据交给大模型，让它帮助提炼、总结报告，甚至总结典型错误案例和编码错误案例。这减少了人工重复劳动的成本，并能帮助输出服务质量报告和代码错误原因，甚至提供修改意见。
张瀚元： 我们实际上会采用两种方式结合的方式进行推进。对于一些经典场景，比如私有化环境中经常遇到的磁盘满了或者网络错误等典型应用场景，我们可能更多地使用第一种方式。而对于一些具有业务特性的特定场景问题，我们则会采用第二种方式。
何碧宏： 我们有使用通过 Prompt 与大模型交互的方式，利用大模型对自然语言的理解能力来帮助提效工单和故障的解决。现在也在探索大模型结合专家经验库，提效故障的根因定位。另外，现在查询监控数据、指标或日志，通常需要按照固定格式填写应用名称或包含的关键字。大模型可以通过自然语言输入，解析生成对应的指标系统或日志系统的 API 调用，这改变了人与数据的交互方式。
在「ArchSummit 全球架构师峰会. 深圳站」大会上，阿里云的陈昆仪博士也将分享《阿里云可观测智能化探索与实践》主题，讨论查询指标数据的方法，这非常有用且通用，我也非常期待。
董善东博士： 刚刚两位老师已经提到了大模型的应用场景，无论是通过 RAG 的方式，还是通过翻译的方式，对完善性的数据或报告进行总结和提炼。这里面其实带来了第一个我认为很重要的场景，就是对于报告的总结和提炼。传统上，我们无论是做异常检测还是数据分析，构建一个编译分析的报告表，报告通常比较冗长。通过大模型的提炼，可以使报告更加简洁。
另外一方面，对于一些基础性的可观测性数据，从中提炼出一些故障模式也是可行的。我个人的感受是，最大的问题还是成本和效率的考量。因为很多场景中，传统的小模型也能完成任务。大模型的价值在哪里？如果只是替代了之前的解决方案，而大模型的调用成本和效率又较高，那么性价比看起来就不是很高。
刚刚何老师也提到利用大模型进行数据查询的新范式，通过自然语言驱动数据查询。我们团队也确实在做这方面的工作。一方面可能是通过自然语言转化为 PromQL 和 Sql 语句的方式，这是一种方式。另一方面，传统的监控平台有很多相对标准化的查询 API，通过与 Agent 结合，驱动调用特定的 API，将自然语言的查询任务拆解为具体的 API 调用，并填写所需的参数。总结来说，我看到的数据查询有两种可能性：一种是直接生成 SQL 语句；另一种是驱动 API 调用。将 API 选出来后，通过上下文和语义提取出所需的参数，执行查询 API。
我个人从去年大模型开始流行起，就一直参与一线的大模型研发工作。可以分享一个有趣的观点和场景：大模型在确定性上下文场景下表现更优。因此一个有趣的场景就是在确定性的告警上下文中， 引入大模型进行告警上下文的问答管理。举个例子，某个运维同学小 A 收到了一条告警，通过钉钉群通知。这条告警可能是一张卡片，内容包括某对象在某时间发生了某类型的告警，告警等级等信息。做得好的卡片可能还会有一些跳转链接，可以查看告警图表，结合根因诊断信息，并传递给小 A。此外，还可能结合 ChatOps，将一些修复和决策动作放在钉钉卡片中，如修复告警、转交告警、接收告警或屏蔽告警等。这条告警背后有大量信息，小 A 在钉钉卡片中并不会直接看到。例如，告警对应的阈值、产生的条件等。这条告警所关心的对象的其它信息，如 RT 指标、QPS 指标、错误率指标以及关联的上下游信息（谁调用了它、它部署在哪台机器上）等，这些信息都是隐藏在背后的。大模型在封闭式、确定性的三层场景下，可以进行很好的问答。告警卡片发出后，将所有相关信号汇总，作为一个整体知识传给大模型。如果小 A 有卡片中未展示的问题，可以与大模型交互（类似于钉钉中的智能机器人）。例如，问当前的 RT 指标、QPS 指标、根因诊断的理由等。通过这种方式，利用大模型结合封闭领域的三方信息，提供相对较好的回答。这是我之前在做的一个场景和思考，分享给大家。
张瀚元： 我觉得这两种方式对于底层的大模型来说其实是一致的，只不过是在上层的交互模式和系统的输入输出，以及系统与系统、用户与系统进行交互时，表现有所不同。
对于业务方的选择，我们目前更推荐前者，即使用 Prompt 这种方式。通过这种方式，我们在设计系统时可以通过更完善的交互形态提供给开发者和用户，并且能够提前通过工程化的方法在各个场景、各个领域预埋对应的 Prompt。例如在分析监控问题或日志时，可以在这些特殊场景下提前设置好对应的 Prompt，从而以较低成本提供给用户一个较好的交互方式，而不需要用户手动编写 Prompt 或产生相关疑惑。这是我们基于业务进行的深入思考结果，包括在腾讯文档业务中的 AI 应用也是采用这种模式。通过这种交互方式，可以给用户提供更好的系统理解、AI 助手理解以及产品使用体验。
董善东博士： 在线观众有一个评论，问到时序大模型和 AIOps 有没有发展前景。我可以简单回应一下这位粉丝。首先，我认为时序大模型是有前景的。目前有很多类似的工作，如 TimeSeiresLLM 和 UniTS 等时序基础模型，所以从学术创新和技术应用领先性我认为是有发展空间的。
对于学术合作或高校研究所来说，这无疑是一个可以发表高质量前沿文章的领域。而对于一些平台型的产品，例如云厂商或头部的监控可观测和 Ops 平台来说，时序大模型也有很大的应用潜力。时序大模型解决了时序如何更好的表征和不同任务更好的模型能力覆盖的问题。在 AIOps 领域，传统算法模型的最大问题是每个任务模型都需要特定设计和调优。如果有了时序大模型，围绕时序相关的大部分任务意味着可以取得一个 80 分甚至 90 分的水平。时序任务包括时间序列预测、时间序列异常检测、时间序列总结、时间序列填充等。
目前我们实践过的如 ChatGPT 和国内的大模型，对日志和 trace 这种结构化文本数据的理解能力还不错，可以达到 70～80 分。但是对于时序数据，往往是一组时序点和指标的描述，信息相对离散，目前大模型并没有展示出很好的理解能力。有了时序大模型之后，可以帮助在时序与现有语言大模型更好地对齐。但需要注意的是，时序大模型的训练成本相对较高，不建议各个业务团队自行开展这方面的工作。更好的选择是与一些开源项目或头部公司、平台型产品合作，一起构建数据集和模型，这样性价比会更好一些。此外，产学研也在推动 OpenAIOps 社区的发展，由社区一起来构建可观测大模型的基座能力，例如时序、日志、trace 等。参与社区合作，也是一个非常不错的选择。
张瀚元： 前几年，我们在 ClickHouse 开始大规模应用的时候，讨论将可观测性数据和运维数据从 Elasticsearch 迁移到 ClickHouse，结果取得了 60% 到 70% 的降本增效效果。这项工作完成后，前段时间又有人咨询是否考虑自研时序数据库，或者自研基于可观测性的时序数据的数据库或缓存。
在这个问题上，我们始终认为成本和投入产出比是最核心的问题。如果我们投入大量人力去开发，但没有得到业界认可，或者没有成为普遍解决方案，那么其性价比是不够高的，无法驱动我们完成这件事。对于大模型，尤其是时序大模型方面，我们也持相同看法。如果能坚持长期有效投入，并带来足够的产出和前景，我们非常愿意探索和尝试时序大模型的应用。但如果前期成本较高而后期收益有限，在选择上可能会更加保守。
何碧宏： 我们目前的工作更多地依赖于专家经验，尤其是在业务监控方面，我们处理的是类似小数据的情况。因此，我们正在探索如何将大模型与专家经验相结合。目前，我们已经构建了一个专门用于根因分析的语言，它实际上是将专家经验转化为语言表达。我们正在探讨的方向是让大模型学习这种语言的语法，以及我们编写的专家经验的语言代码。例如，当发生故障时，我们希望大模型能够解读信息，并根据这些信息生成根因分析，然后执行相关操作。
董善东博士： 目前，专家经验和小模型仍然是性价比较高的解决方案。尽管时序大模型是当前的一个热门话题，但在 Ops 领域，大小模型的组合也在最近一年变得非常流行。许多公司和业务团队已经构建了专属的小模型能力，用于异常检测和诊断等任务。大模型的引入相当于引入了一个新的“大脑”，如何将小模型与大模型结合起来，成为最近一年讨论较多的话题。
我个人的看法是，无论是小模型与大模型的协同还是组合，在 AIOps 领域，我们还处于一个相对初级的阶段。目前，对于可观测数据的判定和问题的排查，更多还是依赖小模型给出确定性的结论。大模型在其中的作用可能更多体现在意图识别、问题拆解，以及汇总小模型的结论并做出总结梳理。一些公司提到，大模型通过思考和总结，会提炼和提升得到的结论的效果，例如结合大模型的反思能力进行提升。但目前来说，我认为小模型可能仍然是主导。在各个业务团队中，小模型可以快速落地并强化价值，而大模型可能会随着自身基座的提升，以及时序大模型、认知大模型等能力的提升，甚至与多模态大模型的组合，更好地应用于 AIOps 领域。
董善东博士： 我认为这位观众提出问题可能是想探讨这些术语之间的概念区别。我个人认为，AIOps 可以视为 DevOps 发展的下一个阶段。AIOps 离不开 Ops 和开发 Dev 的基础能力。首先，你需要拥有自动化平台或自动化转换的能力，在这个基础上，才能利用 AI 手段来提升效果。AIOps 已经有了一个相对明确的定义，即将 AI 手段用于运维，提升运维领域的能力，所以它的范围可能相对较小。至于 AI 内部，看起来好像与 AIOps、DevOps 是另外的话题，希望我们的讨论对观众有所帮助。
关于大模型，我相信许多人对此非常感兴趣，因为大模型的能力确实给大家带来了许多惊喜。正如我们之前分享的，无论是大小模型还是时序大模型，都是很有潜力的方向。但相应地，研究和应用它们的成本也比较高。我的观点是，在 AIOps 领域，如果之前没有相关的算法模型储备，大模型可以帮助你从零基础快速建设到及格水平，填补场景的空白。大模型有这样的能力，可以达到及格标准。但在某些场景中，如果你已经在异常检测等领域深耕多年，你的小模型已经达到了较高水平，那么期望大模型立刻替代小模型，从 80 分提升到 90 分，我认为在当前阶段可能难度还是比较大的。因此，大模型可以帮助快速补充短板，解决泛化问题，但要从 80 分提升到 90 分，在某些场景下可能还有一定难度。
何碧宏： 大模型并不是用来替代小模型的。在某些情况下，大模型可能会替换小模型的一部分功能，但它也有自己的应用场景。使用大模型时，应该针对它真正能够发挥作用的场景进行应用，而不是强行应用在不适宜的场景中。大模型并非万能，不是所有产品都适合使用。例如，我们如果需要获取精确的结果，单凭大模型可能难以实现。大模型可以作为一个整合不同数据和工具的中介，但它并不是一个在所有场景下都可以直接应用的解决方案。使用大模型时，必须根据它的特点和能力来决定如何应用。
张瀚元： 大模型目前越来越受到关注，特别是在 4 月和 5 月，国家相关部门也开始提出大模型安全相关的议题，并组织会议进行讨论。这表明大模型安全问题是一个明显的区别于小模型的重要差异。对于小模型，由于其输入输出的范式相对固定，安全性问题相对可控，小模型本身也会对输出进行质量控制和考察。大模型的情况则不同，它的范式具有非常强不确定性，可以自定义 Prompt 甚至可以通过对话改变其回答方式。这使得大模型容易带来安全问题，可能会给接入的产品和业务带来风险。我认为在未来相当长的一段时间内，大模型无法完全替代所有小模型。小模型具有自己的优势，它们在安全性和质量控制方面更为可靠。
张瀚元： 这位观众提出的问题可能过于理想化，因为在实际应用场景中，我们不太可能遇到完全未知的错误。如果真的发生了完全未知的错误，这对系统而言是非常恐慌的，因为通常错误是可以被分类和理解的。通常业务都有一套错误归类的方法，可以区分错误是由业务自身引起的，还是框架问题，或者是网络错误等。通过对错误进行归类，我们可以确定其所属的范围，并进行大致的分析。虽然分析可能不完全准确，没有任何系统能达到 100% 的准确率，但通常不会出现完全离谱的错误答案。
何碧宏： 直接向大模型询问可能无法获得准确的答案，尤其是在监控领域，我们需要非常精确的结果。要得到精确的问题答案，我们通常会对输入进行更精细的处理。例如，我们会对日志进行解析和归类，然后再将这些信息输入到大模型中进行查询。通过这种方式，我们才可能获得更准确的结果。
董善东博士： 从一个算法人员的角度来看，我想再补充一些更直白的观点。传统的小模型依赖专家经验的总结和有限的数据集进行调优，对于未知问题，这些模型确实没有很好的泛化能力。但根据我之前的实验和体会，大模型展现出一定的“涌现”能力，使得模型对于很多通用的知识都有了一定的掌握，掌握能力大小取决于大模型基座本身。如果遇到业务系统中未曾见过的日志异常，大模型有一定的可能性能够识别出来，尽管这个概率并不是 100%。因此在面对系统新的未知问题时， 相比传统小模型，大模型是可能表现的更优的。
