1p3a-logo1p3a-logo
留学申请面试经验绿卡排期全民竞猜
APP
    旧版通行证登录注册APP
首页
热榜快讯
NEW
通知私信收藏阅帖历史积分中心
热门功能
💎每日夺宝🌱每日农场🛍️跳蚤市场🏠租房找室友🛒好物折扣💳信用卡助手📱旧机回收比价
我的版块
我的标签

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

马小圆mxy
2026/10/1 · 发布于技术交流版·723
· 来自APP
最近在帮一个叫 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 的同学,很想听听大家怎么看这个方向。
1
共4条回复

✨ 您正在体验新版论坛UI

👉 【有奖公测】反馈问题或建议

新手指南常见Q&A小黑屋关于我们加入团队联系客服VIP通行证购买鳄梨去广告企业招聘地里专栏商务洽谈服务条款社区守则隐私政策
youtubetwitter
1Point3Acres.com does not represent or guarantee the truthfulness, accuracy, or reliability of any of communications posted by users.
Copyright ©2009-2026 1Point3Acres.com All rights reserved. See Terms of Service.