Gemini 3.5 Flash 漏洞分诊决策 65% 被另一模型推翻

Gemini 3.5 Flash 提出的漏洞分诊决策，有 65% 被另一个模型直接挑战。这个比例最初被当成 bug，后来才发现它暴露了单一模型的系统性偏见。作者用五天构建的自主系统，本意是解决安全程序六周修复周期里最难的追责环节，却意外让模型互评成了发现隐藏偏差的工具。

65% 分歧率来自模型对同一 triage 决策的直接对抗

作者花五天时间搭建了一套自主系统，目标是接管漏洞扫描之后的整个 remediation 生命周期。扫描发现漏洞已经不是难题，真正卡住单人安全团队的是后续六周内如何持续追责漏洞所有者并推动修复。

在这个系统中，每一次 triage 决策都由 Gemini 3.5 Flash 的 reasoning agent 先提出具体判断，包括漏洞严重程度、责任人分配和修复优先级。决策生成后，并非直接进入执行状态，而是立即交给另一个模型进行审查。审查模型会对同一输入上下文重新推理，给出独立结论。

结果显示，65% 的决策在两模型之间出现明确分歧。分歧形式不是细微差异，而是直接对抗：一个模型建议立即指派给某开发团队并设定 48 小时 SLA，另一个模型则认为该漏洞属于低优先级，只需记录观察。作者起初以为这是实现中的 bug，比如 prompt 不一致或上下文截断导致的随机性，但反复测试后确认，这是两个模型在相同事实基础上产生的稳定判断差异。

这种对抗发生在系统每一次决策闭环之前，成为强制校验环节。65% 的数字不是一次性实验结果，而是多轮运行后的统计均值。作者特别指出，Gemini 3.5 Flash 在速度和成本上表现突出，但其 triage 逻辑在面对边缘场景时表现出明显倾向性，而审查模型则更保守或更激进，形成了互补。

这一机制让原本隐藏在单一模型内部的推理路径被强行拉到台前。分歧不是噪声，而是信号。它迫使开发者不能再把任何一个模型的输出当作最终事实，而是必须面对模型间认知差距带来的系统性问题。

模型互评把原本不可见的判断偏差变成了可量化的信号

作者最初把 65% 分歧当成实现故障，怀疑是 temperature 设置过高或 agent 状态管理出错。直到他把所有分歧案例逐一列出，才意识到这不是 bug，而是两个模型在相同漏洞描述、相同历史上下文下得出了系统性不同的结论。

这种偏差此前很难被发现。因为单个模型在回答时总是自信满满，输出的语气和格式高度一致，开发者很容易把流畅的回答当作正确。互评机制打破了这种幻觉：当第二个模型明确写出「我不同意前一模型的严重性判断，理由是……」时，偏差就从不可见变成了可量化、可追踪的信号。

作者发现，分歧主要集中在两类场景。一类是涉及业务影响判断的模糊地带，Gemini 3.5 Flash 倾向于把潜在影响放大，另一个模型则要求更明确的证据；另一类是责任归属，第一个模型更愿意把 ticket 推给具体代码所有者，第二个模型则更倾向于先内部消化。

这些差异如果只依赖人工审查，可能永远不会被注意到。人工审核者通常只看最终结论，不会同时运行两个模型并对比推理链。互评把这种对比自动化了，把原本主观的「我觉得这个模型有点激进」变成了 65% 这样一个硬数字。

这一发现让作者把文章重点从技术 pipeline 转向了这个意外数字。它证明模型互评可以作为一种元评估工具，暴露单一模型在训练数据、偏好对齐或架构上留下的隐形痕迹。

漏洞修复场景下，单一模型偏见会放大哪些执行风险

在单人安全程序中，扫描之后的六周是真正的死亡地带。漏洞 owner 经常不打开 ticket，优先级判断错误会导致关键修复被延误，也可能让低风险问题占用过多资源。

如果完全依赖单一模型的 triage 决策，65% 的分歧率意味着近三分之二的判断可能带着系统性偏差。当模型倾向于过度严重化时，安全团队会收到大量高优先级 ticket，开发团队疲于应付，最终对所有警报产生麻木；当模型倾向于保守时，真正的高危漏洞可能被低估，导致修复窗口被错过。

作者构建的系统正是为了解决追责难题。传统流程里，安全工程师要反复跟进同一个 ticket，而自主系统希望通过模型判断自动分配 owner、设定截止时间并在超期时自动升级。但如果底层判断存在稳定偏见，这些自动化动作就会系统性地出错：某些团队持续收到不该由他们负责的 ticket，另一些团队则被系统「遗忘」。

在资源有限的单人安全团队里，这种放大效应特别危险。65% 的分歧不是学术讨论，而是直接影响修复完成率和团队士气。作者强调，发现漏洞已经解决，但「追着从不打开 ticket 的 owner」仍然是瓶颈，而模型偏见会让这个瓶颈更难突破。

互评机制为 AI 安全性和可解释性提供了新的验证路径

作者把 65% 这个数字视为比 pipeline 本身更值得写的内容，正是因为它展示了模型互评在实际工程中的价值。它把隐藏的判断偏差变成了可量化的、可审计的信号，为 AI 系统的安全性和可解释性打开了一条新路。

传统可解释性方法多依赖单个模型的 attention 可视化或 chain-of-thought 记录，但这些记录仍然来自同一认知框架。互评则引入了外部视角：第二个模型像审计员一样指出第一个模型哪里过于乐观、哪里证据不足。这种对抗式审查让偏差不再是抽象概念，而是具体案例。

在安全场景中，这一点尤其重要。漏洞 triage 直接影响真实世界的风险暴露水平。互评机制可以作为持续验证层，在决策进入执行前强制通过第二道审查，从而降低单一模型幻觉或偏见导致的错误执行风险。

作者的实验虽然规模有限，却证明了这种机制的可行性。它不需要极大规模的计算资源，五天就能搭出一个原型。这为更多团队提供了低成本尝试的可能。把互评嵌入关键决策流程，或许能显著提升整个 AI 驱动安全系统的可信度。

国内模型开发团队引入互评的现实门槛与适配方向

对国内开发者而言，这一思路有直接参考价值。目前不少团队已在安全、代码审查和合规场景中使用大模型，但多数仍以单一模型输出为准。引入互评机制能帮助发现模型在中文上下文、安全规范理解上的特有偏见。

现实门槛主要有两个。一是成本。Gemini 3.5 Flash 本身追求低延迟低价，国内模型如通义、豆包、深求等也在成本上持续优化，但同时跑两个模型做互评会使推理费用翻倍。对中小团队来说，需要先在高风险子场景（如高危漏洞 triage）做有限部署，而不是全量覆盖。

二是中文适配。英文漏洞描述和修复流程已有较多公开数据集，中文场景下的合规要求、内部术语和责任体系差异较大。国内团队需要构建针对性的 review prompt 和中文偏见评估案例，才能让互评真正发挥作用。

适配方向可以从两个角度切入。一是把互评做成可插拔模块，支持不同模型组合，比如让一个擅长速度的模型生成初判，让一个更擅长逻辑严谨的模型做审查。二是将分歧案例收集起来做成持续训练数据，反馈给模型迭代，逐步降低系统性偏见。

在监管日益重视 AI 安全可解释性的背景下，这种机制也能帮助团队提供更可审计的决策记录，符合合规要求。

当前互评结果的可靠性仍缺乏独立验证基准

尽管 65% 这个数字令人印象深刻，但作者也坦承，目前还缺乏独立第三方基准来判断哪个模型的判断更接近人类专家或真实风险水平。分歧被发现了，但「谁对谁错」仍然没有绝对答案。

审查模型自身是否也带有偏见？它挑战第一个模型时的理由是否充分？这些问题在作者的实验中没有得到充分讨论。65% 的分歧率可能反映了两个模型各自的训练偏差叠加，而不是单纯揭露了其中一个的缺陷。

这意味着互评机制目前更适合作为发现工具，而非最终仲裁工具。要让它真正可靠，还需要引入人类专家抽样验证、构建专门的 triage 评测集，或者设计三模型甚至多模型交叉验证流程。

作者把重点放在这个意外数字上，而不是完整的 pipeline 细节，也暗示了当前技术的阶段性：我们已经能用模型发现模型的偏见，但距离用模型可靠地纠正偏见还有距离。

在实际落地时，团队需要谨慎对待互评结果，把它当作辅助信号而非唯一依据。特别是在漏洞修复这样直接影响业务连续性和安全态势的领域，过度依赖未经充分验证的互评结论可能引入新的风险。

整体来看，这一实验为 AI 安全实践提供了一个值得追踪的方向。模型互评把原本不可见的偏差变成了可操作的信号，但要把它变成生产级能力，仍需更多基准、更多案例和更多跨模型的系统性研究。

参考来源