@
NoOneNoBody 是的,溯因推理局限很大。司法领域的证据链、逻辑链不太了解,不过看着很有意思。
最好的办法还是在有限的代码里清楚无误地发现原因。但是系统一大,耦合高了,就越来越难,因为排列组合有无穷多...大语言模型应该要给出很详细的背景介绍才在这方面有用吧
如果把系统视作一个半透明的黑盒子的话,那么换种方式表述就是
( 1 )证明猜想:条件 => 问题;或者
( 2 )证明等价的逆否命题: !问题 => !条件
用归纳法,也就是要证明以下相关性。溯因推理得出的猜想,用这两个问题来检测一下,应该可以避免一些问题:
( 1 )所有存在某条件的地方,都能观察到某问题; 或者
( 2 )所有不存在此问题的地方,都不存在此条件
如果是作为 tech lead 或者管理者,可以用最大似然估计法:P( 问题 | 条件_i ), 也就是集思广益,避免个人过于集中,狭隘的思维,而忽略有价值的猜想。
一个难点就是相关性不代表因果,而修复 bug 是要在因果关系上做文章的。
首先,因果关系可能有时间上的延迟,这样某个时间点两个不相关的东西,过一段时间就相关了。这样造成观测上的困难。
还有第三变量的问题,会让人找不到问题的根本原因。 比如:
- A 导致 B ,同时 A 也导致 C
- B,C 导致 P (问题)
这种设定下,B 、C 和 P 是条件独立的,也就是说固定 A 的值,B ,C 怎样变化和 P 根本无关。但是实际上因为 B ,C 会和 A 联动,所以你又观察到 B ,C 和 P 是相关的,最后得出结论应该修复 B ,C
基于以上的难点,所以说因果关系是很强的关系。我感觉建立一些确定的因果关系集合可能会比较有用。因果关系可以从可以从小范围的代码阅读中得出,也可以从过去反复被验证的命题中得出。