← [ BACK_TO_NOTES ]

证据强度与结论校准

建立证据强度与结论强度匹配框架:区分证据相关性、可靠性、独立性、直接性、代表性与多源收敛,并避免把弱证据写成确定结论。

#synthesis #growing #phil

[!info] related notes

  • 所属 MOC: logic-moc
  • 相关概念:
  • 易混淆概念:
  • 相关资源:

证据强度与结论校准

这篇笔记解决什么问题

很多错误不是“完全没有证据”,而是:

证据只够支持一个弱结论,却被语言写成了强结论。

例如:

一个用户反馈
↓
“可能存在问题”        合理
↓
“很多用户都遇到”      需要更多证据
↓
“产品普遍存在缺陷”    更强
↓
“根因就是 X”          还多了一层因果

所以推理需要同时校准两件事:证据有多强,结论说得有多满。

证据强度不是单一排行榜

一条证据的价值至少取决于多个维度:

1. 相关性 Relevance

它是否真的与当前命题有关?

“公司很有名”对“这个具体 API 是否存在 IDOR”相关性很低。

2. 可靠性 Reliability

来源、测量和记录是否可信?

  • 原始日志通常比转述更直接;
  • 可复现测试比模糊记忆更可靠;
  • 有明确方法的数据比没有采样说明的数字更可靠。

3. 直接性 Directness

证据离待证明命题有几层推断?

直接观测资源越权成功

通常比:

“这个团队过去安全做得一般”

更直接支持“当前接口存在越权”。

4. 独立性 Independence

十篇文章都引用同一个原始消息,并不等于十个独立来源。

真正的多源收敛要求证据链尽量独立。

5. 代表性 Representativeness

样本是否能代表你要推断的总体?

一百个重度用户的意见不一定代表全部用户。

6. 区分力 Discriminating Power

证据是否更支持 H1,而不是同样容易出现在 H2 下?

例如:

“API 500”

同时兼容数据库故障、代码异常、上游超时,区分力较低。

而:

“数据库连接错误 + 同期连接池耗尽 + 扩容后立即恢复”

对数据库假设的区分力更高。

结论也有强度

可以粗略形成一个语言阶梯:

可能
有一定证据支持
更可能
高置信度
几乎确定
必然

越往下,需要越强的论证。

因此好的表达不是追求永远保守,而是:

让措辞忠实反映当前证据。

一个常见错误:把“证据存在”当成“证据充分”

例如:

有研究发现 A 与 B 相关,所以 A 导致 B。

研究是真实证据,但它当前可能只支持:

A 与 B 存在统计关联

而不是完整因果结论。

证据真实与推论过强可以同时发生。

多条弱证据能否变强

可以,但要看它们是否真正独立、是否都更支持同一解释。

E1
E2
E3
↓
如果相互独立且都更可能在 H 为真时出现
→ 对 H 的联合支持可能显著增强

但如果 E1、E2、E3 都来自同一个错误数据源,只是被三个网站转载,就没有真正增加多少证据。

证据层级不是万能的

医学中常用 evidence hierarchy,例如系统综述、随机对照试验、观察研究等。但不能把层级机械套到所有问题。

例如:

“这个版本的代码是否包含函数 X?”

直接检查仓库本身就是最强证据之一,没必要找随机对照试验。

证据质量取决于问题类型。

对软件工程特别实用的证据分类

事实存在性

问题:某 bug 是否存在?

强证据:

  • 可复现步骤;
  • failing test;
  • trace / log;
  • 最小复现。

因果根因

问题:哪个改动导致 bug?

强证据:

  • bisect;
  • 回滚后恢复;
  • 控制变量实验;
  • 明确机制链。

性能改善

问题:优化是否有效?

强证据:

  • 固定 workload;
  • 基线与重复实验;
  • 方差 / 分布;
  • 多指标与资源成本;
  • 真实环境验证。

不同命题需要不同证据。

AI 回答中的证据校准

模型最常见的问题之一是从来源里看到:

“可能”“提示”“相关”

总结时写成:

“证明”“导致”“确定”。

审核时可以专门检查动词:

suggests → 不要自动写成 proves
associated with → 不要自动写成 causes
reported by one source → 不要自动写成 consensus

竞争解释

证据强不强,不只看它是否兼容 H,还要问:

如果 H 是假的,这条证据出现的可能性有多大?

如果 E 在 H 和非 H 情况下都很常见,它区分力就弱。

这个问题会自然进入 条件概率 和 贝叶斯更新。

“没有证据”也需要校准

如果搜索范围很窄:

“我没找到”

只支持非常弱的缺失结论。

如果数据集完整、检索可靠,而且目标若存在几乎一定会出现:

“完整扫描没有发现”

就可以成为更强的反向证据。

一个可复用的 Evidence Card

Claim:要判断的命题
Evidence:证据是什么
Source:来源
Directness:直接 / 间接
Reliability:高 / 中 / 低
Independence:是否独立于其他证据
Alternatives:还兼容哪些解释
Scope:能外推到哪里
Claim strength:最终最多说到什么程度
Falsifier:什么新证据会显著改变判断

这非常适合 AI 研究、技术评审和新闻阅读。

快速自测

观察:

新版本上线后 P95 从 800ms 降到 500ms。

你现在至少可以说:

新版本上线与指标改善在时间上同时出现。

但要说:

“新版本中的缓存改动导致 P95 降低 37.5%。”

还需要区分同期流量、其他 commit、缓存命中、重复实验等。

一句记忆

好的推理不是让结论听起来尽可能确定,而是让结论的音量和证据的音量一致。

创建于 2026/9/11 更新于 2026/9/11
Digital Biome
Access

键盘导航

j / k / ↑ / ↓
选择对象
Enter / o
打开选择
/ 或 Ctrl+K
全站搜索
i / f / 1–4
筛选当前列表
g → h / l / p / t / a
首页 / 笔记 / 项目 / 工具 / About
r → 1–9
打开所选对象的关联
u
返回上一页
Esc
关闭浮层 / 取消命令;输入框内清空文本