Knowledge Graph as context for LLMs: demonstrating decisive RCA and faster production performance

在Grafana Labs的产品团队中，我们将AI代理也视为我们的用户。正因如此，我们着手测试代理在全栈范围内调试事件的能力，以及与仅使用原始遥测数据相比，使用Grafana Cloud知识图谱时性能提升的幅度。

我们的初步结果令人鼓舞。在一次我们重复测试16次的真实事件中，使用知识图谱上下文的代理15次正确找到了根本原因，而仅使用原始遥测数据时仅1次成功。在此过程中，我们也发现了一些阻碍可靠AI辅助调试的挑战，包括错误信号追踪、过度自信地编造信息以及答案不一致等问题。

我们仍处于早期阶段，但研究结果指向了一个重要观点。目前行业普遍认为更大的上下文窗口会带来更好的输出效果。我们的发现表明，问题的关键不在于_更多_的上下文，而在于如何结构化数据以提供_正确_的上下文。

以下是我们到目前为止的发现，我们将继续公开实验并以Grafana Labs的方式与您分享。

为代理提供遥测访问权限只是开始

让像Opus 4.8这样的新一代模型在实时事件中访问原始遥测数据时，它确实能开始理解问题：查询指标和日志、形成假设并验证假设。我们已经目睹它在我们自己的事件中有效运行，而且成本可控。

但如果您在大规模运行软件，其中正常运行时间是业务关键因素且大型团队共同负责，仅靠更先进的模型还不足以实现完整的调试能力。通过分析LLM在我们基础设施上的根本原因分析过程，并与客户交流，我们发现了三个阻碍因素：

1. 事件的根本原因距离警报越远，模型出错的可能性越大。
2. 当代理缺乏必要证据时，可能会自信地编造信息。
3. 相同的调查在不同运行中可能产生截然不同的答案。

我们通过自己的事件深入研究了这些问题，包括知识图谱上下文在哪些情况下有所帮助、在哪些情况下没有帮助。

问题一：根本原因距离警报越远，LLM出错概率越高

我们深入研究了我们自己的一个事件，我们将它称为“失控索引事件”，以便在本文后续部分可以回溯参考。

搜索日志依赖于索引，而我们的一位租户改变了他们放入索引的内容：大量完整的JSON数据被写入我们索引的字段。该字段中每个不同的值都会生成独立的索引条目，而两个JSON负载几乎从不完全相同，因此他们每写入一行几乎都会生成一个新的索引条目。该字段的唯一值数量从每天约2,700个激增至每天86,000多个。

索引不再能完全装入内存。存储索引的服务器达到8GB内存上限后被终止、重启、再次填满并重复此过程，大约每48分钟发生一次。查询速度变慢，执行搜索的工作者进程在它们之后排队，用户开始遇到搜索延迟。警报在此处触发，距离问题根源大约有三个步骤的延迟。

大多数LLM的陷阱在于：同样的臃肿索引也让租户自身的搜索变得缓慢且成本高昂。当警报触发时，查询风暴在我们的遥测数据中是最显著的信号。这是问题的第二个影响，看起来完全像一个合法的原因：大量查询、繁忙的工作者进程、缓慢的搜索。

当我们后来将这一事件作为受控实验重演时，在16次尝试中有10次运行没有知识图谱的系统错误地将查询风暴归因于问题根源，得出系统自行恢复无需修复的结论。实际上，正确的解决方案是停止对该字段的索引。

多服务故障导致错误排查路径会迅速变得漫长且代价高昂：每浪费一分钟追踪错误的服务，都会损失金钱和用户信任。在全栈事件中，错误的服务通常意味着错误的团队也被卷入其中。

[问题二：LLM宁愿编造答案也不承认自己不知道](https://grafana.com/blog/knowledge-graph-as-context-for-llms-demonstrating-decisive-rca-and-faster-production-performance/#problem-two-an-llm-would-rather-fake-it-than-admit-it-doesnt)

在构建本地工具测试向代理提供上下文的不同方式时，我犯了一个错误。其中一次运行完全没有附加任何查询工具。代理没有任何方式可以查看数据。

但它仍然进行了调查，并生成了一份自信且结构良好的根本原因分析：

"我将对[环境]中[服务]的401错误增加情况进行深入调查。我先通过并行查询指标和日志开始分析。"

随后它编造了工具调用，更关键的是，还编造了这些调用的结果，声称成功获取了从未实际查询的数据：

<tool_call> prometheus_query_handler {"promql": "rate of 401s for [service]"} </tool_call> <tool_response> {"status": "success", "data": {"result": [{"values": [[…, "0.0011"], …]}]}} </tool_response>

它继续这样编造，生成了一整套从未见过的指标数据矩阵。在没有任何依据且不受约束的情况下，它选择编造内容而不是停止。这只是一个旧模型的偶然运行，但即便如此，我还是感到既好笑又惊讶。

代理倾向于自信地给出答案，无论答案是否正确，它们会编造内容来实现这一点。它们被设计为积极回应，而不是接受“不知道”的状态。对模型来说，承认无法找到答案看起来就像失败。对于真实事件，自信的编造可能比沉默更糟糕，因为值班团队会浪费时间根据错误信息采取行动。

[问题三：LLM每次给出的答案都不同](https://grafana.com/blog/knowledge-graph-as-context-for-llms-demonstrating-decisive-rca-and-faster-production-performance/#problem-three-an-llm-gives-a-different-answer-every-time)

另一个显而易见的特性是非确定性。使用相同的提示多次运行相同调查时，结果会出现实质性差异。这种现象让人联想到薛定谔的猫：在打开盒子之前，你永远无法确定得到的是敏锐的代理，还是状态不佳的代理。

当我们的代理重复执行相同调查时，这种现象尤为明显。以“失控指数事件”为例，16次完全相同的运行返回了4个不同等级的答案（从正确到明确错误），执行耗时从13次遥测查询到31次不等，单次运行成本从0.56美元到1.26美元不等。更令人惊讶的是，代理在评估其他代理的调查时，也会出现这种不确定性！

对于依赖自动化答案履行SLA的团队来说，这就像把一个只在心情不错时才出现的天才安排进值班表。你更希望拥有一个始终如一的可靠同事，因为信任不是来自一次成功的运行，而是源于可预测性。你无法信任那些无法预测的事物。

早期发现：知识图谱作为上下文层

我们一直在研究**Grafana Cloud知识图谱**是否能提供帮助。知识图谱是Grafana Cloud实现全栈可观测性的核心层：它能自动发现客户系统中的服务、基础设施和数据库，绘制它们之间的依赖关系，并每分钟更新一次健康洞察。

这种映射本质上是一种语义解析，向模型清晰解释全栈层级关系：这个指标、这个Pod和这个数据库实际上描述的是同一个服务，而非让模型自行猜测它们是否相关。其他企业AI部署研究（包括来自dbt Labs、b-eye和Glean的研究）也独立得出了类似结论。模型并非因记忆缺失而产生幻觉，而是因为输入数据在不同系统中存在定义冲突。

我们尚未完全解决这三个问题，但已经发现了令人振奋的初步成果（包含必要的免责声明）。

在复杂事件中，知识图谱解锁了正确答案

（注：此处原文段落未完整提供，翻译到此结束）

可以实际重放的多跳案例非常罕见，因此我们将“失控索引事件”转化为一项严谨的实验，最终的根本原因由人工进行了事实核查。每次试验都以高推理努力度运行 Claude Opus 4.8：我们向其发送了告警信息，并允许它通过 gcx CLI 查询我们的生产环境 Grafana Cloud 堆栈。部分运行提供了知识图谱访问权限，而其他运行仅提供原始遥测查询。我们在任何运行前就固定了假设，并使用两个独立的判别模型对每项结果进行盲评，每种配置下进行 16 次运行。

我们发现，使用知识图谱时，代理始终能准确找到根本原因（p < 0.0001），所需遥测查询量约为无知识图谱情况的一半（中位数 10 次 vs 19 次，p = 0.001），且在相同 token 和美元成本下完成。

调查 | 找到正确根本原因 | 95% 置信区间 --- | --- | --- 使用知识图谱上下文 | 16 次运行中 15 次 | 72-99% 仅使用原始遥测 | 16 次运行中 1 次 | 1-28%

关于统计数据的说明。p 值是对运气的检验：它估算如果知识图谱完全无影响，你看到如此显著差异的概率。此处 p < 0.0001 表示在一万次中不到一次的概率，因此我们确信差异是真实存在的，而非偶然。两个置信区间不重叠也说明了同样的结论。

遗憾的是，我们还不能宣称胜利：这是个特意挑选的案例，因为该案例应适合知识图谱。但在成本最高的故障类型中，知识图谱是可靠找到根本原因与几乎找不到根本原因之间的关键差异。

当知识图谱无法提供帮助时，它不会让情况变得更糟

我们发现了另一个事件，这次答案超出了知识图谱的范围。一个下游后端变慢，其前面的服务被积压的请求填满并因内存不足被终止，告警在真实故障上方一跳处触发。解决该事件的证据是一条单一日志行，明确指出了缓慢的后端，而知识图谱中并未包含这条信息。

我们发现在此情况下知识图谱没有产生影响：有知识图谱时，代理在 16 次运行中有 8 次找到正确根本原因；无知识图谱时，也有 7 次找到（Fisher p = 1.0，与我们预测的零假设一致）。

调查 | 找到正确根本原因 | 95% 置信区间 --- | --- | --- 使用知识图谱上下文 | 16 次运行中 8 次 | 28-72% 仅使用原始遥测 | 16 次运行中 7 次 | 23-67%

这可能令你感到意外，但我们要庆祝这一结果。我们曾担心知识图谱会让代理陷入错误事实并导致更多错误答案，或降低效率。事实并非如此：无论是否使用知识图谱，失败的运行都遗漏了相同的日志行。在此情况下知识图谱没有帮助，但它也没有误导（万岁！）。

与第一个案例并置时，我们开始看到一些积极的信号：当知识图谱包含根本原因时，它具有决定性作用；当答案超出知识图谱范围时，它保持中立；在两种情况下，它都可以安全启用。

[使用知识图谱上下文的代理更高效](https://grafana.com/blog/knowledge-graph-as-context-for-llms-demonstrating-decisive-rca-and-faster-production-performance/#an-agent-with-knowledge-graph-context-gets-there-for-less)

在生产环境中，我们的自动化调查会同时运行多个代理来验证不同假设，其中部分代理使用了知识图谱。在为期一周的测试中，我们发现了553组数据，这些数据展示了使用知识图谱的代理和未使用知识图谱的代理对相同告警进行调查的情况。

当两个代理得出相同结论时，72%的案例中使用知识图谱的代理消耗的token更少，典型案例中减少了约25%（p < 0.0001）。当得出不同结论时（通常发生在复杂且涉及多服务的事件中），使用知识图谱的代理仍然倾向于消耗更少的token。

当两个代理... | 配对占比 | 中位数令牌减少量 | 使用更少token的配对占比 ---|---|---|--- 得出相同结论 | 553组中的258组（47%） | ~25% | 72% 得出不同结论 | 553组中的166组（30%） | ~15% | 64% 均未得出明确结论 | 553组中的129组（23%） | ~60% | 80%

自这项分析以来，调查代理功能得到了进一步开发，我们对623组新数据重新进行了测试。核心结论依然成立：总体来看，配备知识图谱的代理成本并未增加，尽管随着基准代理的改进，token消耗差距有所缩小，但出现了首次研究未发现的速度优势。现在，知识图谱代理的中位数完成时间提前了36秒（64%的案例中更快，p≈10⁻⁹）。随着系统持续优化，效率提升的百分比将持续变化；我们将继续测量并报告这些进展。

[下一步与仍需探索的领域](https://grafana.com/blog/knowledge-graph-as-context-for-llms-demonstrating-decisive-rca-and-faster-production-performance/#whats-next-and-what-we-still-dont-know)

目前，知识图谱的数据来源于客户遥测信息。它追踪每个实体的健康状况，以及通常导致事件发生的部署和配置变更。但这只是Grafana Cloud所看到数据的一小部分。我们正在构建的全栈可观测性版本中，每层已收集的数据都将成为代理可访问的节点，知识图谱则在底层完成问题解析。我们最近开发了Write API，允许内部产品将自有实体添加到知识图谱中。接下来将进行测试，首先从事后分析开始。

展望未来，我们尚未确定本文描述的早期成果是否能在最复杂的链路中持续有效，这些链路的证据可能分散在多个服务中。我们还不清楚提前提供上下文是否会增加代理错误锁定线索的风险。而推动一致性（如问题三所述）仍需探索：让代理两次给出相同答案的问题，目前上下文尚未能可靠解决。

但方向是明确的。能够调试的模型与值得信赖的调试模型之间的差距在于上下文：现有信息、连接方式、变更内容以及上次发生的情况。我们有许多关于如何在全栈中构建这一层的想法，并将在后续持续展示我们的工作进展，包括取得的成果和遇到的死胡同。

将本文视为系列文章的第一篇。在后续内容中，我们会逐步解答上述未解答的问题。