若不同 LLM 对同一证据结论相反，你如何选择，避免挑最好结果？

第135题：若不同 LLM 对同一证据结论相反，你如何选择，避免挑最好结果？

1. 核心回答

如果不同 LLM 在完全相同的证据条件下给出相反结论，我不会在看到测试标签以后逐样本挑“答对的那个模型”。

需要把三个问题严格分开：

1. Model Selection：正式使用哪个模型，要在 Development Set 上按照预先定义的指标选择，并在测试前冻结；
2. Evidence-Based Adjudication：运行时多个模型发生分歧，应依据可验证证据、固定 Rubric 和预定义裁决规则处理；
3. Evaluation Reporting：测试集上必须报告所有预先注册模型及裁决系统的结果，包括分歧率和失败样本，不能只报告事后表现最好的模型。

对于单个冲突样本，我会把两个模型的回答拆成：

Final Label

↓

Source

↓

Sink

↓

Data Flow

↓

Sanitizer / Guard

↓

Evidence Span

↓

Confidence

然后检查哪个结论得到真实代码、执行测试、程序分析结果或人工 Gold Label 的支持。

如果双方都无法被现有证据可靠区分，系统应输出：

UNCERTAIN / NEEDS_REVIEW

而不应强行选择某一个 LLM。

---

2. 为什么逐样本挑“正确模型”会产生选择偏差

假设有两个模型：

$$M_A,M_B$$

测试集为：

$$D_{test}$$

如果运行以后发现：

样本1：A对
样本2：B对
样本3：A对
...

然后定义一个系统：

每个样本选择实际答对的模型

得到的实际上是一个使用测试标签的 Oracle。

它的结果：

$$Scor{e}_{oracle}$$

不能作为真实部署性能。

同样，如果先测试 10 个 LLM：

$$M_1,\dots ,M_{10}$$

看到测试成绩以后才挑：

$$
M^*

\arg\max_i Score(M_i,D_{test})
$$

再只报告 $M^{\ast }$，测试集实际上已经承担了 Model Selection 的角色。

这种结果通常会高估泛化性能。

---

3. 正确的模型选择应在测试前冻结

我会先划分：

Train
Development
Test

模型选择、Prompt 选择、Temperature、阈值和 Ensemble Weight 都只能根据 Development Set 确定。

例如预先定义：

$$
Score(M)

F1
+
\lambda_1 EvidenceAccuracy

\lambda_2 HighConfidenceError

\lambda_3 Cost
$$

其中具体指标和权重都需要在测试前写清楚。

选择：

$$
M^*

\arg\max_M Score_{dev}(M)
$$

之后冻结：

• Model Version；
• System Prompt；
• Temperature；
• Retrieval Settings；
• Confidence Threshold；
• Adjudication Rule。

最终 Test Set 只负责一次独立评估。

---

4. 测试时模型发生分歧，不能重新进行 Model Selection

例如已经确定：

Primary Model = A

另外保留：

Model B = robustness probe

某个测试样本出现：

A：Vulnerable
B：Safe

此时不应该问：

哪一个模型总体更强？

真正的问题是：

当前样本的证据能够支持哪个 Claim？

所以运行时处理的是：

Sample-Level Adjudication

而不是重新做：

Model Selection。

---

5. 第一步：把答案拆成 Atomic Claims

例如 Model A 输出：

存在 SQL Injection。
Source 是 request.args["id"]。
Sink 是 cursor.execute()。
中间没有参数化处理。

可以拆为：

CA={c1,c2,c3,c4} C_A= \{ c_1,c_2,c_3,c_4 \} CA​={c1​,c2​,c3​,c4​}

其中：

• $c_1$：存在 SQL Injection；
• $c_2$：Source 是 request.args["id"]；
• $c_3$：Sink 是 cursor.execute()；
• $c_4$：Source 到 Sink 之间没有有效 Sanitizer。

Model B 也进行相同拆解。

之后逐条检查证据。

这样可以避免比较：

A 的解释看起来更专业。

真正比较的是：

$$EvidenceSupport(c_i)$$

---

6. 最终标签和推理证据要单独评分

可能出现：

Model A:
Label = Vulnerable
Path = Wrong

Model B:
Label = Safe
Path = Partially Correct

这时不能只比较 Label。

至少记录：

$$Score=(LabelCorrect,SourceCorrect,SinkCorrect,PathCorrect,EvidenceCorrect)$$

例如：

$$A=(1,0,0,0,0)$$

说明 A 可能猜中了最终答案，但没有给出正确的漏洞机制。

如果论文声称：

漏洞分类

A 的 Label 可以计为正确。

如果论文声称：

漏洞根因推理

A 不能被视为完整正确。

---

7. 第二步：优先检查可验证证据

在代码安全场景中，我会优先寻找能够独立验证的证据，例如：

• 真实代码位置；
• Source-Sink Data Flow；
• Call Graph；
• CFG / DFG；
• Patch；
• Unit Test；
• Exploit / PoC；
• 静态分析结果；
• 动态执行结果；
• 人工复核标签。

LLM 自己输出：

Confidence = 95%

只能作为辅助信号。

不能因为：

$$Confidenc{e}_A>Confidenc{e}_B$$

就直接选择 A。

---

8. 一个简单裁决例子

假设：

Model A：
存在 SQL Injection。

Model B：
不存在，因为使用了参数化查询。

检查真实代码发现：

cursor.execute(
    "SELECT * FROM user WHERE id = ?",
    [user_input]
)

那么 B 的核心 Claim 得到实例级代码证据支持。

此时裁决依据是：

Parameterized Query Evidence

而不是：

Model B 比 Model A 参数更多。

---

9. 如果两个模型引用的是同一证据怎么办

这是本题更困难的情况。

例如双方都看到：

Source = request.args["cmd"]
Sink = subprocess.run()

A 判断：

Vulnerable

B 判断：

Safe

此时继续检查关键条件：

• shell=True 是否存在；
• 参数是否经过 allowlist；
• 是否使用参数数组；
• 输入是否真正 attacker-controlled；
• 是否存在 Sanitizer；
• 是否存在可达路径。

也就是进一步把争议缩小成一个可验证 Predicate：

Pi∈{True,False,Unknown} P_i\in\{True,False,Unknown\} Pi​∈{True,False,Unknown}

谁的结论满足这些 Predicate，谁得到更强支持。

---

10. 如果当前证据真的无法区分

例如只看到：

x = sanitize(user_input)
run(x)

但：

sanitize()

实现不可见。

此时没有足够证据确定：

$$Safe$$

或：

$$Vulnerable$$

更合理的状态是：

UNKNOWN

或：

NEEDS_MORE_EVIDENCE

不能因为：

A 说 Vulnerable
B 说 Safe

就强行多数投票。

---

11. 模型分歧本身应该成为不确定性信号

设有 $m$ 个模型：

$$M_1,\dots ,M_m$$

其语义结论为：

$$y_1,\dots ,y_m$$

可以定义简单的 Disagreement Rate：

$$
Disagreement

1-
\frac{
\max_y
\sum_i\mathbb{1}[y_i=y]
}{
m
}
$$

如果所有模型一致：

$$Disagreement=0$$

如果结论高度分散：

$$Disagreement\uparrow$$

说明系统应该提高：

• Evidence Requirement；
• Abstention Probability；
• Human Review Priority。

模型分歧不证明某个答案一定错误，但可以作为很有价值的 Uncertainty Signal。

---

12. 不要默认使用多数投票

例如：

A：Vulnerable
B：Vulnerable
C：Safe

2 : 1

不能自动证明：

Vulnerable

因为 A 和 B 可能：

• 使用相同基础模型；
• 来自相同模型家族；
• 共享训练数据；
• 共享 Prompt Bias；
• 共享错误漏洞先验。

三个模型输出并不意味着三个独立观察者。

所以：

$$MajorityVote$$

只能作为一种预先验证过的 Aggregation Baseline。

---

13. Ensemble 可以用，但规则必须预先冻结

如果开发集表明多模型 Ensemble 确实有效，可以提前定义：

$$
S(y)

\sum_{m=1}^{M}
w_m p_m(y)
$$

其中：

$$w_m$$

只能根据 Development Set 的：

• Accuracy；
• Calibration；
• Evidence Accuracy；
• Slice Performance；

确定。

然后：

$$
\hat y

\arg\max_y S(y)
$$

测试时不能重新修改 $w_m$。

如果 LLM 的自报概率没有经过校准，也不应直接把：

90%
80%
60%

当作可比较概率。

---

14. 更适合安全任务的是 Selective Prediction

对于高风险安全任务，我更倾向于允许拒答。

定义置信门槛：

$$\tau$$

只有当：

$$Confidence\ge \tau$$

并且：

$$EvidenceSupport\ge {\tau }_e$$

时自动输出结论。

否则：

NEEDS_REVIEW

需要联合报告：

Coverage

$$
Coverage

\frac{
N_{\text{automatic decisions}}
}{
N
}
$$

Selective Risk

$$
Risk

ErrorRate(
Confidence\ge\tau
)
$$

目标是在合理 Coverage 下保持较低错误率。

---

15. 如果使用第三个 LLM 当 Judge，需要额外防偏差

一种直觉方案是：

A 和 B 不一致
↓
让 Model C 判断谁对

这仍然存在风险。

LLM-as-a-Judge 已知可能受到：

• Position Bias；
• Verbosity Bias；
• Self-Enhancement Bias；
• Prompt Bias；
• Model-Family Bias。

因此 Judge 不能直接看到：

这是 GPT-X 的答案
这是 Model-Y 的答案

应该隐藏模型身份。

---

16. Pairwise Judge 至少要交换顺序

例如第一次：

Answer A
Answer B

第二次：

Answer B
Answer A

如果 Judge 第一次选择 A，

交换以后却仍然选择第一个位置，

说明存在 Position Bias。

可以采用：

A/B → A wins
B/A → A wins

才认为 A 稳定胜出。

如果结果翻转：

TIE / UNCERTAIN

然后进入其他验证路径。

---

17. Judge 应只看 Claim 与 Evidence

更合理的 Judge Prompt 输入：

Claim A
Evidence A

Claim B
Evidence B

Source Code / Ground Truth Evidence

Rubric

Rubric 可以固定：

1. Claim 是否被证据蕴含；
2. Source 是否正确；
3. Sink 是否正确；
4. Data Flow 是否存在；
5. Sanitizer 判断是否正确；
6. 是否存在 Unsupported Claim。

Judge 评价：

$$EvidenceEntailment$$

而不是评价：

哪个答案写得更漂亮。

---

18. Judge 也必须用人工数据校准

应准备一批双人或专家标注的：

$$D_{gold}$$

然后比较：

$$Agreement(Judge,Human)$$

必要时报告：

• Accuracy；
• Cohen’s $\kappa$；
• Pairwise Agreement；
• Position-Swap Consistency；
• 不同 Query Slice 的稳定性。

如果自动 Judge 在关键漏洞类型上与人工频繁不一致，就不能把 Judge 分数直接当 Ground Truth。

---

19. 最可靠的裁决器可能不是另一个 LLM

如果任务存在独立 Oracle，应优先使用它。

例如：

19.1 编译问题

直接：

compile

19.2 单元测试问题

直接运行：

test suite

19.3 Source-Sink 问题

使用：

• Data Flow Analysis；
• 静态分析；
• 人工检查。

19.4 漏洞可利用性

条件允许时使用：

• Patch Differential；
• Test Case；
• PoC；
• Execution Validation。

这样裁决链更接近：

$$Claim\to IndependentEvidence$$

---

20. 还要专门做 Evidence Intervention

源文件要求通过证据干预检查模型是否真正使用证据。

假设 A、B 对同一证据分歧，可以构造：

20.1 Evidence Removal

删除关键证据。

20.2 Evidence Replacement

替换成结论相反但语义相近的证据。

20.3 Conflict Context

同时提供支持和反对证据。

20.4 Order Perturbation

改变证据顺序。

20.5 No-Retrieval

删除外部检索证据。

观察：

$$Predictio{n}_A$$

和：

$$Predictio{n}_B$$

分别怎样变化。

真正证据敏感的模型应该随着关键事实改变而有规律地调整结论。

---

21. 可以定义 Evidence Sensitivity

假设有 $n$ 个反事实干预：

$$I_1,\dots ,I_n$$

每个都有逻辑上的预期答案：

$$y_i^{\ast }$$

可以定义：

$$
InterventionConsistency(M)

\frac1n
\sum_{i=1}^{n}
\mathbb{1}
[
M(I_i)=y_i^*
]
$$

如果：

$$M_A$$

在原始样本上分数高，

但：

$$InterventionConsistency(M_A)$$

很差，

其优势可能依赖表面模式，而缺少稳定机制证据。

---

22. 需要报告“模型分歧发生在哪里”

不能只给整体：

A F1 = ...
B F1 = ...

还应专门建立 Disagreement Set：

$$
D_{dis}

{
x:
M_A(x)\neq M_B(x)
}
$$

然后报告：

$$Accuracy(M_A|D_{dis})$$

$$Accuracy(M_B|D_{dis})$$

以及分歧集中在哪些：

• CWE；
• Repository；
• Language；
• Cross-file Case；
• Hard Negative；
• Missing Context；
• Conflicting Retrieval；
• Long Function。

这往往比总体平均分更有解释力。

---

23. 可以建立分歧矩阵

例如：

类型	A正确/B错	B正确/A错	双方错	无法判定
CWE-A	…	…	…	…
CWE-B	…	…	…	…
Cross-file	…	…	…	…
Hard Negative	…	…	…	…
Conflict Evidence	…	…	…	…

如果 A 只在某类数据占优，

B 在另一个 Slice 占优，

结论应该写成：

不同模型具有不同错误分布。

没有必要强行制造一个“全局赢家”。

---

24. 如果确实要做路由，也要在开发集学习

可能最终发现：

Model A：
代码结构推理更强

Model B：
自然语言漏洞知识更强

可以建立 Router：

$$g(x)\to M_i$$

但 Router 也必须在 Development Data 上训练和验证。

测试时：

$$g$$

已经冻结。

否则如果根据测试标签决定：

这个样本给 A
那个样本给 B

仍然属于 Oracle Selection。

---

25. 推荐建立 Evidence Card

对于两个模型的冲突，记录：

Sample ID

Claim:
当前代码是否存在漏洞？

Model A:
Label:
Source:
Sink:
Evidence:
Confidence:

Model B:
Label:
Source:
Sink:
Evidence:
Confidence:

Strongest Evidence:
...

Alternative Explanations:
...

Distinguishing Test:
...

Expected Result:
...

Observed Result:
...

Final Status:
SUPPORTED_A /
SUPPORTED_B /
UNCERTAIN /
NEEDS_REVIEW

这样冲突解决过程可以被审计。

---

26. 统计报告不能只展示赢家

最终论文或面试中应报告：

$$Metri{c}_A$$

$$Metri{c}_B$$

$$Metri{c}_{Adjudication}$$

以及：

$$
\Delta

Metric_A-Metric_B
$$

对于同一批测试样本，可以用 Paired Bootstrap 对：

$$\Delta$$

建立置信区间。

如果：

$$0\in C{I}_{95\%}(\Delta )$$

更稳妥的结论是：

当前证据不足以证明一个模型稳定优于另一个。

此时不能只选平均值略高的模型并宣称确定优势。

---

27. 什么情况下可以说一个模型更适合正式系统

需要在预定义指标上具有稳定优势。

例如：

1. Development Set 主指标更高；
2. Evidence Accuracy 更高；
3. 跨项目表现稳定；
4. High-Confidence Error 更低；
5. Calibration 更好；
6. 延迟和成本满足约束；
7. 多 Seed / Prompt 稳定；
8. 置信区间支持优势；
9. 关键安全 Slice 没有严重退化。

然后在测试前写死：

Primary Model = A

这样测试结果才有清晰统计意义。

---

28. 什么结果会推翻我的选择规则

我会预先定义 Falsification Criteria。

28.1 只有看完 Test 后才能确定赢家

说明 Model Selection Protocol 有泄漏。

28.2 Judge 交换 A/B 顺序后结论翻转

说明 Judge 存在明显 Position Bias。

28.3 Judge 更偏好同模型家族回答

需要怀疑 Self-Enhancement / Shared Bias。

28.4 Evidence Intervention 后裁决没有变化

说明系统可能没有真正使用证据。

28.5 Ensemble 只提高平均分，却增加高风险 Slice 错误

不能据此声称系统整体更可靠。

28.6 Disagreement 样本上错误率极高

说明模型分歧应触发 Abstention 或人工升级。

---

29. 推荐的完整实验

我会比较：

系统	选择规则
Model A	固定
Model B	固定
Majority Ensemble	测试前冻结
Calibrated Ensemble	权重在 Dev 上确定
LLM Judge	盲评 + 双顺序
Evidence Adjudicator	原子 Claim + 外部证据
Human / Execution Oracle	高风险样本

统一：

• Dataset；
• Evidence；
• Retrieval；
• Prompt；
• Token Budget；
• Tool Permission。

然后同时报告：

• F1；
• Evidence Accuracy；
• Disagreement Rate；
• Accuracy on Disagreement Set；
• High-Confidence Error；
• Abstention Coverage；
• Selective Risk；
• Cost；
• Latency。

---

30. 当前资料能够支持到什么程度

根据原始表格，第 135 题目前能够确定：

1. 不同 LLM 对同一证据产生相反结论需要专门分析；
2. 应通过 Evidence Replacement 检查证据依赖；
3. 应测试顺序扰动；
4. 应测试冲突上下文；
5. 应测试 No-Retrieval；
6. 应加入拒答样本；
7. 输出需要拆成 Atomic Claims；
8. Source/Sink 和引用证据要与最终结论分开评估；
9. 应建立 Evidence Card；
10. 需要明确最强替代解释、区分实验、预期观察和适用边界。

当前源文件没有提供：

• 真实参与比较的 LLM 名单；
• 各模型测试结果；
• Disagreement Rate；
• 人工裁决结果；
• Judge Agreement；
• 模型 Calibration；
• 具体置信区间。

因此当前不能替候选人声称：

模型 A 比模型 B 更可靠

这些结论需要真实实验支持。

---

31. 面试时可以压缩成下面这段

如果不同 LLM 对完全相同的证据给出相反结论，我不会看到测试标签以后逐样本挑答对的模型，因为那相当于把 Test Set 用于 Model Selection。

正式模型应该在 Development Set 上按照预先定义的 F1、Evidence Accuracy、Calibration、成本和关键安全 Slice 表现选定，并在测试前冻结。

运行时发生分歧时，我会把两个答案拆成 Final Label、Source、Sink、Data Flow、Sanitizer 和具体 Evidence Span，然后判断哪些 Atomic Claim 能被真实代码、程序分析、执行测试或人工 Gold Label 支持。如果只有一方得到可靠证据支持，就按照证据裁决；如果双方证据都不足，就输出 UNCERTAIN 并触发人工或执行验证。

如果使用第三个 LLM 做 Judge，我会隐藏模型身份、交换 A/B 顺序、固定 Rubric，并用人工 Gold Sample 校准，因为 LLM Judge 已知存在 Position、Verbosity 和 Self-Enhancement Bias。

实验上我还会单独建立 Disagreement Set，报告每个模型在分歧样本上的正确率，并做 Evidence Replacement、Conflict Context、Order Perturbation 和 No-Retrieval 等干预。如果一个模型只有在原始 Prompt 上占优，但证据改变后不能按逻辑调整判断，我不会把它视为更可靠。

所以最终选择依据应该是测试前冻结的模型选择协议和样本级可验证证据。无法区分时保留不确定性，比事后挑最好结果更可信。

---

32. 来源

1. 原始题目表格，第135题：要求通过 Evidence Replacement、Order Perturbation、Conflict Context、No-Retrieval 和拒答样本验证模型是否真正使用证据，并将 Final Claim 与 Source-Sink / 引用证据分别评估。
2. scikit-learn Documentation, Common Pitfalls and Recommended Practices — Data Leakage：明确指出 Test Data 不应参与模型选择，否则会造成过度乐观的泛化估计。
3. scikit-learn Documentation, Nested versus Non-Nested Cross-Validation：说明同一数据同时用于参数/模型选择和性能评估会产生选择偏差，Nested CV 可用于隔离选择和最终评估。
4. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023：系统分析 LLM Judge 的 Position Bias、Verbosity Bias 和 Self-Enhancement Bias。
5. Wang et al., Large Language Models are not Fair Evaluators, ACL 2024：证明交换候选回答顺序即可显著改变部分 LLM Judge 的判断，并提出顺序平衡和人工校准方案。
6. Farquhar et al., Detecting Hallucinations in Large Language Models Using Semantic Entropy, Nature 2024：通过语义层面的输出分歧估计不确定性，并展示高不确定性条件下拒答可以改善可靠性。