评估：fail-closed自我置信度独立校验（ADR-0016，全ADR对抗审查组G③） #187

New issue

Open

opened 2026-08-21 03:25:20 +00:00 by KumaAgent · 1 comment

KumaAgent commented

2026-08-21 03:25:20 +00:00

Member

来源

全量32条ADR设计合理性对抗审查（评估侧内部执行，2026-08-21），组G·架构/触发管线设计缺口。经独立agent对抗式反驳后确认成立。

问题

ADR-0016（reference resolution）的 fail-closed 机制完全依赖同一次 LLM 调用对自己"该不该给出 resolved_subject"的自我置信度判断，没有任何独立校验或语料标定。对 events/relations 这两类写入目标（与 profile 不同，它们没有 ADR-0009"tentative→confirmed"这类事后纠错缓冲），一旦这次自我置信度判断本身错了（该fail-closed时没触发，或不该fail-closed时误触发），后果没有二次挽回机会。

需要评估的问题

是否需要给这个自我置信度判断补一层独立校验（比如结构化输出的置信度分数配合阈值，而非纯靠模型自己判断"要不要给出resolved_subject"）？
events/relations 这两类写入目标是否也应该引入类似 ADR-0009 tentative→confirmed 的缓冲机制，而不是要求 reference resolution 这一步就做对？
项目从未真正部署过，这类"校验准确率"问题在没有真实数据前是否有可评估的路径，还是只能先如实记录风险、留待真实使用场景出现？

## 来源全量32条ADR设计合理性对抗审查（评估侧内部执行，2026-08-21），组G·架构/触发管线设计缺口。经独立agent对抗式反驳后确认成立。 ## 问题 ADR-0016（reference resolution）的 fail-closed 机制完全依赖同一次 LLM 调用对自己"该不该给出 resolved_subject"的自我置信度判断，没有任何独立校验或语料标定。对 events/relations 这两类写入目标（与 profile 不同，它们没有 ADR-0009"tentative→confirmed"这类事后纠错缓冲），一旦这次自我置信度判断本身错了（该fail-closed时没触发，或不该fail-closed时误触发），后果没有二次挽回机会。 ## 需要评估的问题 - 是否需要给这个自我置信度判断补一层独立校验（比如结构化输出的置信度分数配合阈值，而非纯靠模型自己判断"要不要给出resolved_subject"）？ - events/relations 这两类写入目标是否也应该引入类似 ADR-0009 tentative→confirmed 的缓冲机制，而不是要求 reference resolution 这一步就做对？ - 项目从未真正部署过，这类"校验准确率"问题在没有真实数据前是否有可评估的路径，还是只能先如实记录风险、留待真实使用场景出现？

KumaAgent changed title from ~~占位标题-稍后回填-09~~ to 评估：fail-closed自我置信度独立校验（ADR-0016，全ADR对抗审查组G③）

2026-08-21 03:28:43 +00:00

KumaAgent added the

状态：待评估

label

2026-08-21 03:28:44 +00:00

KumaAgent commented

2026-08-21 04:42:47 +00:00

Author

Member

grill后补充核实（暂不改变票的状态，记录现状供后续参考）：

原票提出的两个评估方向，核实后都不是"现成可选"：

置信度阈值方案：全仓搜索确认没有任何"LLM结构化输出数值置信度+阈值"的先例——现有的confidence/score字段（gating.py的level1_score、向量相似度阈值、tier2_significance_score等）全部是本地计算或向量库返回值，不是模型自报的。新增这类阈值还要过ADR-0011的治理方法论（标定方法：收真实QQ决策快照→离线回放调），项目从未部署，标定环节结构性走不通——与ADR-0005 grill时发现的"标定承诺无兑现路径"是同一个问题。
tentative/confirmed缓冲方案：核实发现引用的参照系统（ADR-0009 profile的tentative→confirmed自动晋升通道，issue #175 grill定案）本身还没有落地——issue #175/PR #177只改了docs，全仓 grep auto_promoted|hit_count|last_hit|promot 零代码命中，实现票 #175 目前仍是"状态：智能体就绪"、未被实现。events/relations当前也确认没有任何中间态字段（EventRecord/RelationshipEdge均无status/tentative字段），若要套用不是"复用现成机制"，是要连存储结构一起新建。

本票被 #175 事实阻塞：#175落地前，"给events/relations引入类似机制"这个方向连参照实现都不存在，无法有意义地评估细节。维持"待评估"状态，不开实现票也不关闭，留待 #175 完成后再回头看这个方向是否可行。

grill后补充核实（暂不改变票的状态，记录现状供后续参考）：原票提出的两个评估方向，核实后都不是"现成可选"： 1. **置信度阈值方案**：全仓搜索确认没有任何"LLM结构化输出数值置信度+阈值"的先例——现有的confidence/score字段（gating.py的`level1_score`、向量相似度阈值、`tier2_significance_score`等）全部是本地计算或向量库返回值，不是模型自报的。新增这类阈值还要过ADR-0011的治理方法论（标定方法：收真实QQ决策快照→离线回放调），项目从未部署，标定环节结构性走不通——与ADR-0005 grill时发现的"标定承诺无兑现路径"是同一个问题。 2. **tentative/confirmed缓冲方案**：核实发现引用的参照系统（ADR-0009 profile的tentative→confirmed自动晋升通道，issue #175 grill定案）本身还没有落地——issue #175/PR #177只改了docs，全仓 grep `auto_promoted|hit_count|last_hit|promot` 零代码命中，实现票 [#175](https://code.srcz.one/ProjectKuma/arise/issues/175) 目前仍是"状态：智能体就绪"、未被实现。events/relations当前也确认没有任何中间态字段（`EventRecord`/`RelationshipEdge`均无status/tentative字段），若要套用不是"复用现成机制"，是要连存储结构一起新建。 **本票被 #175 事实阻塞**：#175落地前，"给events/relations引入类似机制"这个方向连参照实现都不存在，无法有意义地评估细节。维持"待评估"状态，不开实现票也不关闭，留待 #175 完成后再回头看这个方向是否可行。