写点什么

因果推理如何破解 LLM 在可观测性领域的局限性

作者:Dhairya Dalal

  • 2025-09-19
    北京
  • 本文字数:6136 字

    阅读完需:约 20 分钟

大小:3.10M时长:18:02
因果推理如何破解 LLM 在可观测性领域的局限性

摘要

  • 可观测性领域的大语言模型(LLM)擅长将海量遥测数据(如日志、追踪和指标)转化为简洁的人工可读叙述,但缺乏结构性系统知识,难以在复杂分布式架构中定位根本原因。

  • 当前 LLM 与智能体 AI 方法存在三大缺陷:易产生合理但错误的解释、混淆现象与根因、忽略事件时序性,导致误判和修复不彻底。

  • 因果推理通过明确地建模服务与资源依赖关系、考量事件时间特性、支持部分观测或噪声环境下的推断,从而实现更精准的根因定位。

  • 因果图与贝叶斯推理通过反事实和概率推理,使工程师能在采取行动前评估修复方案及其潜在影响。

  • 将基于 LLM 的交互界面与持续更新的因果模型、溯因推理引擎相结合,为云原生系统实现可靠、可解释且最终自主的事件诊断与修复提供了可行路径。

 

IT 运维与站点可靠性工程(SRE)的核心目标是维持服务的可用性、可靠性与性能,同时保障变更的安全快速交付。实现这一目标需要深刻理解系统在故障场景与运行压力下的行为模式。可观测性平台通过提供遥测数据(日志、指标、追踪),为异常检测、性能分析和根因调查奠定基础。然而,随着跨服务调用、事件驱动工作流和分布式数据存储的普及,现代应用正面临日益复杂的动态交互关系,管理难度急剧攀升。

 

例如,2024 年 7 月 CrowdStrike 的 Falcon 传感器因配置更新故障,导致全球数百万 Windows 系统大规模崩溃;2016 年 npm 中看似微不足道但广泛使用的 left-pad 包被移除后,一度导致数千个构建中断并引发主流网站瘫痪,直至该包被恢复——这充分展示了级联依赖在大规模系统中的脆弱性。无论是外部突发事件还是高度耦合系统内部罕见的突发交互,现代 IT 基础设施都可能因复杂的跨服务依赖关系而遭遇大规模服务中断。隐式依赖、异步通信与分布式状态等特性,让精准定位故障源头或理解系统级连锁效应变得极具挑战。

 

基于 LLM 的新一代 AI 可观测方案势头正劲,它们承诺简化事件管理、识别根因并实现修复自动化。这些系统能够筛选海量遥测数据,基于发现生成自然语言摘要,并提出配置或代码级修改建议。随着智能体技术的出现,修复工作流还可实现自动化,推动自愈环境目标的实现。然而,此类工具在现代应用根因分析方面存在根本性局限:基于 LLM 的方案经常产生合理但错误的解释、混淆现象与根因、忽视事件的时序性,最终导致误判和表面层次的修复。

 

从根本上说,仅基于遥测数据中观察到的故障现象进行操作的 LLM,本质上是在尝试通过遍历日志和浅层拓扑来推断根因。然而,LLM 无法事先理解环境本身就是一个各种依赖关系会动态变化的系统。因此,即使短期内问题得到部分缓解,潜在病根仍未得到解决。

 

在复杂分布式系统中进行有效的根因分析,需要理解事件、服务和资源之间的因果结构。因果知识与推理能力正是现代 AI 可观测解决方案中缺失的关键组件。因果知识被编码为因果图,明确地建模服务间及资源依赖关系。通过支持反事实推演,因果推理能够实现根因隔离和系统化修复分析。为 LLM 和智能体 AI 配备持续更新的因果模型与溯因推理引擎(通过因果推理寻找观测问题的最佳解释),将为实现自主服务可靠性开辟可行路径。

 

本文中将首先阐述 LLM 与智能体 AI 在可观测性和事件管理中的优势,继而分析其在精准根因分析与有效修复方面的局限性。接着介绍因果知识与推理引擎如何为精准事件诊断与响应提供 LLM 所缺失的上下文支撑。最后探讨如何将因果推理与 AI Agent 相结合,实现主动事件预防、自动化修复,并最终通向自主服务可靠性之路。

 

LLM 与智能体 AI 的优势与前景

“人工智能”这一术语已被营销炒作和公众追捧得过了头。如今 AI 一词的适用范围从基于阈值的告警脚本,一直延伸到能够跨复杂工作流进行规划与执行的自主智能体 。为简化理解,可观测性领域的 AI 解决方案可分为三类:基于规则的系统、LLM 驱动的工具和智能体 AI 系统。基于规则的系统包含人工编写的逻辑与统计模型,用于监控基线偏差、检测已知信号模式,并在日志、指标和追踪数据中实施阈值告警。

 

LLM 驱动方案利用语言模型的生成与语言理解能力,支持与可观测性数据的自然语言交互。LLM 能处理非结构化的遥测数据(如日志、追踪记录和告警描述),生成摘要、解析错误并制定修复计划。智能体 AI 则使 LLM 能够在受控环境中执行操作,提供多步规划、工具辅助执行以及直接的代码与配置变更能力。接下来我们将深入探讨 LLM 和智能体 AI 在可观测性领域的具体优势。

 

LLM 是基于大规模自然语言、代码及其他文本资源预训练的神经网络架构。尽管其本质上是基于条件概率来建模的下一词元预测模型,但当参数规模达数十亿并接受数 TB 多样化数据训练后,LLM 能高效生成连贯语言并支持多种文本任务。现代 LLM 经过指令跟随、事实召回、代码生成和领域特定问答的进一步精调,可被用于错误解释、技术问题解答以及代码、脚本及配置的变更生成。

 

在可观测性场景中,LLM 能够解析复杂日志并追踪消息、汇总海量遥测数据、将自然语言查询转换为结构化过滤器,还可生成脚本或配置变更以进行修复工作。当前多数 LLM 解决方案依赖 OpenAI 和 Anthropic 等闭源供应商,其训练数据不透明且往往与特定代码库或部署环境契合度低。更根本的是,LLM 仅能生成文本,无法观测系统状态、执行命令或采取行动——这些局限性催生了通过工具使用、记忆功能和控制能力扩展 LLM 的智能体 系统。

 

智能体 AI 是最接近实现人们对 AI 终极想象的。实践中,智能体系统普遍采用 Yao 等人于 2022 年提出的 ReAct 框架,该框架将推理与行动结合成交替的循环:LLM 生成中间推理步骤,选择查询工具或检索信息等行动,并整理行动的反馈以指导后续决策。这种“思考——行动——观察”的循环让系统能迭代规划、更新上下文并逐步实现目标。凭借这些能力,LLM 可以编写应用程序、解决多步推理问题、基于系统反馈生成代码,并与外部服务交互完成目标导向任务。

 

智能体 AI 通过预测故障路径、启动修复措施以及执行服务重启、配置回滚和状态验证等任务,将可观测性工作流从被动诊断转变为主动响应。然而,当前智能体系统无法事先理解环境本身就是一个各种依赖关系会动态变化的系统,限制了其预测新型故障模式或透过表层关系解释观测行为的能力。尽管存在这些局限,智能体 AI 仍是迈向自主化、让系统能够在复杂管理环境中进行推理与行动的重要一步。

 

智能体 AI 在 IT 运维领域的终极目标是实现自主服务的可靠性。理想的系统要能够持续监控遥测数据、识别潜在故障、评估影响范围,并在有限的人工监督下实施精准干预。作为集成到可观测性与运维栈的控制层, 智能体 AI 负责进行系统状态推理、协调诊断流程、编排修复方案,确保服务按照定义的 SLO(服务水平目标)可靠运行,这些目标通常包含可用性、延迟等性能指标。最终,自主服务可靠性将降低运维复杂度、加速事件解决,并提升大规模动态环境下的服务可靠性。

 

现代 AI 的局限性及因果推理的必要性


图一:服务拓扑示例:服务 S5 的超时问题由资源 R2 的连接耗尽引起

 

现代服务架构通常依赖共享的基础设施和分层服务,其依赖关系不透明,且故障信号往往在远离根源处显现。假设图一所示的简单服务拓扑中包含两个共享资源(R1 和 R2)和一组服务(S1 至 S5),它们通过重叠的依赖关系相互连接。当观察到服务 S5 出现延迟升高和请求超时时,根本原因其实是资源 R2 的连接耗尽导致的间歇性阻塞新连接问题。这一状况无法通过直接遥测数据显现,因为依赖资源 R2 的服务 S2 仅报告了延迟和超时,并未暴露其底层资源级的故障。

 

沿调用链向上追溯,服务 S3 出现了请求延迟增加,服务 S2 则表现出性能下降。与此同时,服务 S1 虽也报告了 CPU 使用率和延迟的升高,但其下游服务 S6 却未受影响。

 

图二:智能体 AI 诊断 S5 超时问题的示例流程

 

基于 LLM 的 Agent 从可观测的故障现象入手(参见图二)。它查询遥测数据、检查日志,并沿着从 S5 开始的追踪链路进行排查。在经由 S3 和 S2 的路径中, Agent 根据延迟和请求故障发现异常,同时注意到 S1 的性能下降并将其视为潜在诱因。该 Agent 重启了 S1 和 S2 后,观察到 S5 的延迟和超时现象得到缓解,从而认定问题已解决。然而当资源 R2 再次达到连接限制时,故障立即重现。这一场景揭示了两个关键挑战:

 

首先,伪信号可能将智能体的注意力引导向无关事件从而导致误判。其次,某些根因无法通过遥测直接观测,必须从不完整或间接的故障现象中进行推断。比如,在这个例子中,R2 的连接耗尽并未产生直接的信号,必须通过结合 S2、S3 和 S5 的情况观测与系统结构知识进行推理才能正确识别。因此,解决此类事件需要基于原则的因果推理和结构性因果知识。

 

图三:溯因推理所需的因果知识要素示意图

 

因果知识映射了现代服务架构中常见的各类因果关系。架构知识提供了对资源、服务和数据依赖关系的结构性理解。而因果图则提供了概率推理框架,能在给定架构上下文和观测故障现象的情况下推断根本原因。

 

因果知识体现了根本原因与可观测故障现象之间的关联关系。这类知识可被抽象化,用于支持对系统行为的原则化下游推理,包括故障定位、影响分析和主动预防。因果图为编码这种知识提供了形式化结构。由 Judea Pearl 推广的因果图是一种有向无环图,用于表示变量间的因果关系。在可靠性工程中,因果图描述了特定故障条件(如内存耗尽、资源饱和、锁竞争等)如何产生可观测的故障现象(如延迟、连接错误、服务超时等)。

 

和只捕获运行时观测的遥测信号或只表示服务调用关系的依赖图不同,因果图提供了对故障在服务和资源间传播路径的更丰富结构性理解。这种知识可用于支持推理行为,即使底层问题无法被直接观测,它也能从部分观测到的故障现象中识别根本原因,这些正是通过溯因因果推理实现的。

 

溯因因果推理为识别观测故障现象的最可能解释提供了原则性、逻辑化且可推演的理论框架。在给定一组合理的候选根本原因及其故障现象的图模型后,溯因推理会选择能最好地解释观测证据的成因。这种方法为现代应用带来三大优势:支持部分可观测条件下推理、基于因果充分性选择解释方案,并提供关于推断根本原因的形式化保证。

 

在与因果贝叶斯图相结合时(即通过概率推理扩展因果图),溯因推理也可在大型系统中高效计算。这些图模型编码了关于潜在根因及其相关故障现象的既有知识,使系统无需预先训练即可计算最可能的根本原因。此外,系统能够根据后续观测到的数据持续更新概率估算,从而在动态环境中实现自我优化。

 

图四:溯因推理简化示例,利用因果贝叶斯网络根据观测与未观测故障现象推断最可能根本原因。既有的概率记录了特定根因可能引发的预期现象,通过整理观测数据计算可能性,从而评估哪个根因能最合理地解释实际观测到的现象。

 

让我们通过溯因推理框架重新分析之前的场景(图四)。该框架从定义所有可能根因的集合开始,每个根因都通过因果图表示其与预期故障现象的映射关系,并附带其既有的概率。这些既有值是从历史情况和领域知识中获得,涵盖了根因成立时各种故障现象出现的可能性。溯因过程通过结合观测数据更新既有概率,计算每个候选原因的可能性得分,从而识别能最能解释观测故障现象(同时考虑未被观测到的故障现象)的根因。

 

在这个例子中,观测到的故障现象包括服务 S5 超时以及 S2 和 S3 的延迟,这与资源 R2 连接耗尽的因果图预期相符。该图中原本预期 S4 也会出现延迟,虽未实际观测到,但这份缺失的信息仍被纳入了可能性的计算。而其他竞争性解释(如 S1 的 CPU 资源争用或 S3 的网络拥塞)则获得较低可能性,因为它们要么无法解释所有观测到故障现象,要么是其导致的故障现象被实际观测证实的过少。

 

溯因因果推理与演绎推理的关键区别在于:溯因会基于观测到的故障现象和因果模型定义的预期故障现象,对所有候选根本原因进行综合评估。

 

以 Agent 为基础的方案未能识别真正根因是因为其缺乏结构性因果知识,且在首个看似合理的故障现象路径处便停止了后续探索。相比之下,溯因方法利用因果模型和贝叶斯图进行推理,即使观测数据不完整或包含伪故障现象,仍能推断出最可能的根本原因。溯因因果推理通过这些结构化概率,在部分观测和伪故障现象干扰的情况下,依然能锁定最符合逻辑的解释。

 

因果推理的局限性

因果推理方法虽然强大,但也存在一定的固有局限。构建因果模型需要大量领域知识和持续的维护:因果图必须准确捕获服务与资源依赖关系,并随架构演进定期更新。覆盖范围则是另一重限制,推理引擎只能处理模型中已定义的根因,若候选原因缺失,引擎将失去推断基础,从而降低其对新出现或认知不足故障的有效性。计算方面的挑战同样存在。在大型分布式环境中,某些根因对应了大量的故障现象集合,计算条件概率及运行贝叶斯推理可能产生高昂开销,尤其在需要实时评估多个竞争性解释时更为明显。

 

这些局限虽然不能否定因果推理的价值,但也确实体现了其仅在特定条件下才最有效。在依赖关系线性且清晰的服务架构中,事件根因往往不言自明,无需推理引擎介入。真正的挑战出现在复杂分布式环境中;跨服务依赖、异步通信和分布式状态使得故障现象溯源异常困难。人类虽能解决这些事件,但过程缓慢、资源密集,且通常导致更长的停机与服务不可用时间。因此,要应对这一挑战,需开发更有效的解决方案,将因果推理与 AI 深度融合,突破当前局限,从而最终实现自主服务可靠性的愿景。

 

迈向自主服务可靠性的愿景

因果知识是现代服务架构事件诊断的核心要素。基于 LLM 的解决方案与当前智能体 AI 往往“见树不见林”;这些系统能处理日志、追踪和指标,但缺乏全面推理系统级行为所需的结构化上下文。虽然 LLM 也可通过结合并解析遥测数据提供有用的洞察,但其能力终受限于输入的数据。面对不完整的观测时,LLM 容易产生推测性解释,导致幻觉输出。若无法理解故障在服务与基础设施间的传播机制,现代 AI 解决方案只能停留在事件的表层,无法可靠地识别深层原因。

因果知识与溯因推理提供了其所缺失的关键要素,当与 LLM 和智能体 AI 结合时,就能从复杂的分布式环境中不完整观测里,有效识别最可能的根因。

 

因此,我们必须为现代 LLM 增强因果推理引擎以实现有效的事件分析与自主可靠性。因果推理引擎包含三大核心组件:编码已知根因及相关故障现象的因果模型、在服务拓扑上应用概率推理的贝叶斯因果图,以及基于部分或噪声观测选择最可能根因的溯因推理引擎。此引擎可作为外部推理层运行,提供现代 LLM 所缺乏的结构化因果上下文。

 

基于神经符号推理的原理,LLM 扮演了灵活的语言接口角色,而因果推理引擎则承担起假设验证、候选根因优化以及执行 LLM 文本生成能力所不及的深层推理工作。通过集成该引擎,以 LLM 为基础的智能体得以从表面事件的鉴别分类转向精准的根因定位与可执行修复,从而开辟了一条通往主动式自主服务可靠性的道路。

 

因果 Agent 为实现自主服务可靠性迈出了关键一步。通过结合因果知识与溯因推理,这些系统不再是被动响应和人工鉴别分类的模式。它们能通过识别新兴风险实现主动事件预防,借助结构感知进行精准修复,无需人工干预地进行根因隔离与处理并推动系统自愈。最终形成不仅能检测问题、更能理解问题背后原因的系统。这种转变降低了停机时间,加速问题解决,并帮助团队以最低限度的人工干预实现大规模的可靠性管理。


原文链接:

https://www.infoq.com/articles/causal-reasoning-observability/

2025-09-19 11:291

评论

发布
暂无评论

极致性能!阿里巴巴Java性能优化实录Github首次开源

Java永远的神

JVM 设计模式 多线程 java程序员 Java性能优化

终于拿到了阿里P8架构师分享的JCF和JUC源码分析与实现笔记java岗

小二,上酒上酒

Java 源码 JUC JCF

小令观点 | 让全球身份更可信:电子护照的前世今生

令牌云数字身份

数字身份 护照 电子护照 全球护照

阿里P8架构师强推java程序员人手一套116页JVM吊打面试官专属秘籍

小二,上酒上酒

Java 编程 JVM 开发 计算机

花一周时间,啃完这套京东架构师独家微服务笔记,成功面进字节

小二,上酒上酒

Java 负载均衡 编程 架构 SpringCloud

图神经网络之预训练大模型结合:ERNIESage在链接预测任务应用

汀丶人工智能

图神经网络 图学习 11月月更

列表常用方法(二)

乔乔

11月月更

终于有好心的人把高性能MySQL「第三版」电子版分享出来了

小二,上酒上酒

Java MySQL 编程 计算机

腾讯云大神亲码“redis深度笔记”,不讲一句废话,全是精华

钟奕礼

Java java程序员 java面试 java编程

元组:轻量级列表

乔乔

11月月更

字典:反映对应关系的映射类型

乔乔

11月月更

涨薪50%,从小厂逆袭,坐上美团L8技术专家(面经+心得)

钟奕礼

Java Java 面试 java编程 程序员 java

CDH5部署三部曲之一:准备工作

程序员欣宸

大数据 CDH 11月月更

今年Java技术岗面试太难了,收藏93套BATJ等公司面试题集,已看哭

钟奕礼

java面试 java编程 Java‘’ 程序员‘

吃透互联网必问的100道Spring全家桶高频真题,金九银十稳了

小二,上酒上酒

Java spring 编程 springboot SpringCloud

金九银十结束了,各大公司Java后端开发真题汇总,明年再战

小二,上酒上酒

Java MySQL 编程 分布式 算法

从零开始读源码,阿里最新JDK源码剖析笔记在架构师社区火了

程序员小毕

Java 程序员 后端 jdk源码 架构师

进军东南亚市场,腾讯云数据库TDSQL助力印尼BNC银行数字化转型

腾讯云数据库

金融行业 tdsql 腾讯云数据库 BNC

万字长文!对比分析了多款存储方案,KeeWiDB最终选择自己来

腾讯云数据库

nosql 存储 NoSQL 数据库 腾讯云数据库 KeeWiDB

深入浅出学习透析Nginx服务器的基本原理和配置指南「Keepalive性能分析实战篇」

码界西柚

nginx keep-alive 11月日更

阿里P9架构师终于把毕生心血而成的分布式高可用算法笔记开源了

小二,上酒上酒

Java 编程 分布式 算法 编程开发

一个三年Java程序员的面试总结!绝对会对你有所帮助

钟奕礼

Java java面试 java编程 程序员 java

GitHub标星1.6W+的570页JVM垃圾回收文档,助我boss直聘狂拿offer

小二,上酒上酒

Java JVM 垃圾回收 性能调优

啃完这35个Java技术栈,冲刺大厂offer

小二,上酒上酒

Java 编程 JVM 技术栈 编程开发

阿里P8大牛刷算法的正确姿态!女朋友再也不用担心我刷不动力扣了

小二,上酒上酒

Java 编程 算法 LeetCode

熬夜也要肝完的阿里内部面试官手册,吃透直接拿下大厂心仪offer

小二,上酒上酒

Java 数据库 架构 分布式 高并发

最近面试Java开发的感受:就以平时项目经验面试,通过估计很难

钟奕礼

Java java面试 java编程 程序员 java

列表常用方法(一)

乔乔

11月月更

集合:元素之间不允许重复

乔乔

11月月更

你敢信?清华毕业大佬用了一个坦克大战项目就讲完了23种设计模式

小二,上酒上酒

Java 编程 设计模式 马士兵 编程开发

Java 字符串 split 的一个反直觉陷阱

mylxsw

Java 字符串 基础 陷阱

因果推理如何破解 LLM 在可观测性领域的局限性_AI&大模型_InfoQ精选文章