做了这么多年 production / incident response，最近开始重新想 RCA 这件事

最近在帮一个叫 TypeRCA 的项目，方向是用 AI 做 production incident 的 root cause analysis。

我自己做 reliability / production engineering 很多年了，处理过不少线上事故。过去一段时间也试了不少 LLM agent 做 RCA。

一个挺有意思的发现是：现在模型已经很强了，读 log、trace、metric，甚至提出可能的 root cause 都没什么问题。

但真的让它自己跑完整个 investigation loop，体验还是不太好。

不是因为模型“不聪明”，而是 RCA 本身有很多小决策：

* 下一步该查哪个 service？
* 这个 error 是 cause 还是只是 symptom？
* 两个 hypothesis 都能解释现象时先验证哪个？
* 什么 evidence 才算真的排除了一个可能性？
* 到什么时候可以停止 investigation？

如果全部交给一个 general-purpose agent，它很容易变成一个很长的 open-ended loop。能找到答案，但可能慢，也很难判断它为什么相信这个答案。

TypeRCA 现在在尝试一个不太一样的方向：

不让一个 LLM agent 控制整个 RCA，而是把 investigation 拆成很多 bounded decisions。

比如给模型当前 evidence，然后只问：

现在最值得检查哪个 hypothesis？

或者：

根据目前 evidence，哪个 service 更可能是 failure origin？

模型负责这些小 decision，普通 code 负责整个 investigation loop、verification 和什么时候停止。

最近跑了一些 synthetic incident，挺有意思的一点是：有时候模型其实已经“看到”了正确 signal，但最后还是选错 cause。
这让我越来越觉得，RCA 的难点可能不只是 reasoning，而是怎么连续做对一串 decision，并且让每一步都能验证。

这个方向现在还非常早，我主要也在帮忙测试它到底在哪些地方有效、哪些地方会翻车。

网站是 TypeRCA.io，如果这里有做 SRE / infra / observability / incident response 的同学，很想听听大家怎么看这个方向。

内部的几个工具准确率都很一般, 最好的在40%左右吧, 这还是他们自己给的数据, 没有认真核实
这种准确率基本上就是让AI investigator空跑, 没人会看
个人觉得LLM不适合incident处理

两周前用fable RCA了一个其他组的问题效果还挺好的。我是更偏向于强大的通用模型这一派，做通用模型的公司财大气粗训练的时候可以用更多的算力，然后训练出来的模型商业价值高形成正向循环。之前关注了一些做数学模型的公司像harmonic/axiom，talent density不见得比OA对应的组低，但目前看还是干不过OA。

而且LLM处理incident风险大 尤其是和钱挂钩

多金的大白鹅 发表于 2026-10-01 21:19:40
两周前用fable RCA了一个其他组的问题效果还挺好的。我是更偏向于强大的通用模型这一派，做通用模型的公司财大气粗训练的时候可以用更多的算力，然后训练出来的模

这个一直是难点 模型强大也不行