溯因推理的危害

什么是溯因推理？

“溯因推理是推理到最佳解释的过程。或者说，溯因推理就是从结果出发，推测出事件发生的原因的过程。”

在编程界，溯因推理发生的常见场景是维护/bug 修理。

举例说明，你的 PM 或者上级观察到了一连串错误 log ，或者用户的投诉，问你是怎么回事，要求你马上回复。此时你就会构思出几个猜想，你从中选出最可信，最有说服力的那一个，作为答案回复了。

那么猜想如何产生？肯定是根据每个人的工作范围，知识经验产生。这里就有一个 Availability Bias 的问题，也就是走思维捷径，思考的素材，思考的方式，都是选择最熟悉的，最偏爱的，这里甚至有随机性，比如某人早上看了一篇关于吸烟的英文文章，结果思考的时候不自觉的把“smoking test”给考虑进来了。这种 availability bias 会让人的思维产生局限。

另外，逻辑上说，“说得通”并不能证明这个解释就是正确的原因，所以你还是得找证据证明你的猜想是不是对的。而人有一种很严重的缺陷，就是会不由自主寻找支持自己偏爱的结论的证据，而忽略其他事实。结果是把人引入死胡同。同理，还有工作上各种成见，摩擦，误会的产生，大半可归因于此。

在一个很复杂的系统中，搜集信息进行推理成本很高的，甚至连部署某个小改动的成本都很高。

可能解决的办法：建立一系列小的因果关系集合，里面每个结论都是清晰，可靠，经过证明的。推理从这里出发，可确保结论的正确性，防止不必要的，错误的调查分析。

各位觉得如何？

p7534a

202 天前

@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

基于以上的难点，所以说因果关系是很强的关系。我感觉建立一些确定的因果关系集合可能会比较有用。因果关系可以从可以从小范围的代码阅读中得出，也可以从过去反复被验证的命题中得出。

kneo

202 天前

脚踏实地一点吧。修 bug 不是靠嘴修的。你有 bug 想不明白可以拿出来讨论，在这讨论有可能有某些 bug 在某些情况和某些特定条件干扰之后产生的某些现象还能不能认为一定是由这个 bug 导致的这个过程的证明是不是可以由特定的人使用特定的方法在特定的条件下让这个特定的人掌握这个事情是不是有意义，我就觉得有点搞笑了。