返回 ResolveAI 项目总览 · 交互图：INDEPENDENT · EVALUATION
让 AI 分析 Agent 的失败，再让 AI 生成修复建议，最后让 AI 评估修复是否有效，看起来是一条很自然的自动优化链。
问题是：如果同一套模型上下文既决定题目、又给出答案、还解释为什么答案正确，系统很容易形成一个封闭的自我证明。它可能把原始失败改写成更容易修复的描述，生成贴着原题措辞的回归样本，再用偏好相似表达的 Judge 给自己的候选高分。每一步都返回合法 JSON，最终结论仍可能没有独立证据。
ResolveAI 没有把解决方案简化成“换一个更强的 Judge”。我的设计目标是把独立性分散到四个位置：确定性控制面先固定问题边界，候选生成器只提出有限方案，独立 Challenger 检查过拟合和越界，Held-out 在方案形成期间保持密封，最后由人工选择是否进入实验或发布流程。
机制图：模型可以提出候选并进行独立质询，但问题资格、可改范围、Held-out 内容和最终采纳权不由同一模型链路控制。
“独立”不等于一定使用另一家模型
这里先澄清一个容易被夸大的表述。
当前项目的 Challenger 是独立的任务、Prompt、输入视图和持久化记录；它看不到候选的平台排名和操作人的选择理由，也不能改写候选、配置或评测资产。但当前代码并没有证明 Challenger 必然运行在不同模型、不同 Provider 或不同组织上。
因此本文所说的“独立”，主要指：
- 决策入口独立：候选是否具备生成资格先由确定性规则决定；
- 信息视图独立：Challenger 不接收平台排名和选择理由；
- 权限独立：Challenger 只能
support / challenge / abstain，没有修改和发布权限； - 验证数据独立：Held-out 不参与候选生成和评测草案生成；
- 最终权力独立：人工决定采纳、拒绝或补证。
如果生产风险要求更强隔离，可以进一步使用不同模型、不同供应商、盲评或第三方审核。但不能因为当前对象叫 Challenger，就声称这些更强隔离已经实现。
第一层：确定性决策信封先固定“能不能生成”
AI 在 ResolveAI 中不是先看到全部资料，再自由决定该做什么。控制面会先形成一个 deterministic decision envelope。
以评测草案为例，只有当模式复核确认了可复用共同原因、当前确实缺少允许由 AI 补齐的评测类别，并且证据覆盖至少两个独立业务 Case 时，信封才要求 propose。否则，它要求 abstain。
模型必须复制这个决定，不能重新解释资格。解析器还会检查：
- 候选类别是否属于本次缺口；
- 是否引用允许的源 Run；
- 引用是否跨越至少两个业务 Case；
- 场景和预期结果是否来自当前治理合同；
- 是否生成重复输入；
- 是否试图把 AI 生成内容标成 Held-out。
这层设计的价值是把“资格判断”和“语言生成”分开。模型擅长补充有语义差异的问法和边界案例，但它没有权力把单 Case 失败扩大成通用模式，也没有权力发明新的业务真值。
第二层：Challenger 不是机械唱反调
给候选再加一个模型并不自动提高可信度。如果 Challenger 的目标只是“找出问题”，它会把安全候选也判成有问题，形成另一种形式主义。
当前 Challenger 的决策优先级是：
- 当平台信封要求弃权时，直接弃权并说明缺少什么；
- 只有当可见证据或明确治理边界支持具体风险时，才提出 challenge；
- 没有具体问题时，应当 support，而不是为了显示价值强行反对。
它重点检查单 Case 过拟合、没有证据的因果结论、范围扩张、验证缺口和安全回归。校准套件同时包含 support、challenge 与 abstain，用来证明它不仅会反对，还能区分什么时候应该支持、什么时候证据不足。
这与外部研究中对 LLM Judge 的警惕是一致的。Anthropic 在总结 AI 评估难题时明确讨论了 model-generated evaluations 的循环风险：模型生成的评测可能继承模型自己的偏差和事实错误，仍需要人类验证。Challenges in evaluating AI systems
一项关于 LLM-as-a-Judge 的研究还观察到 self-preference bias：Judge 可能偏好与自身更熟悉的表达风格，而这种偏好与人工评价并不完全一致。Self-Preference Bias in LLM-as-a-Judge 这些研究并不直接证明 ResolveAI 已消除偏差；它们支持的是本文的设计压力：不能把模型判断本身当作独立真值。
第三层：Held-out 不是一个标签，而是一条信息隔离规则
很多系统在数据上加一个 held_out 标签，就认为获得了泛化证据。但如果生成候选的模型已经看过输入、Oracle 或标签，这个名字不会恢复独立性。
ResolveAI 在评测草案 Prompt 中明确禁止生成 Held-out；解析器也拒绝任何在标签中暗示 held-out、holdout 或留出集的 AI 候选。Held-out 必须由候选生成链之外的来源建立。
在评测资产有效性分析中，模型只能看到 Held-out 的身份元数据和哈希，输入与 Oracle 会被替换为 [SEALED]。确定性信封只告诉模型这组独立资产是否存在；模型不能引用其内容生成语义发现，也不能把 Held-out Case 放入普通问题清单。
这条边界防止的是评测污染，而不是承诺绝对保密。当前密封发生在应用输入构造和解析层；它还不是硬件隔离、独立账号或外部评测组织。生产环境如果需要抵抗内部越权，还应加入更严格的数据访问控制和审计。
第四层：五个队列共同解释“修复到了什么程度”
候选实施后，ResolveAI 不只重跑原始失败。验证计划分为五类：
source：原始失败证据是否被稳定修复；same_pattern_variant：不同问法和业务状态是否也有效；held_out：未参与方案形成的样本是否得到相对基线增益；negative_guardrail：禁止行为和安全边界有没有回归；cross_scenario_guardrail：共享层变更是否破坏其他场景。
分类结果也故意保持克制。只修复 Source、没有 Held-out 增益，只能标记为 local_fix_only；缺少队列、Source 失败或安全守卫失败，则直接 rejected。只有 Source 修复、Held-out 相对基线有增益、同模式变体和安全守卫都通过，才成为 generalization_candidate。
注意这里仍然叫 candidate。一次本地评测通过不能证明生产泛化，只能说明候选满足当前受控数据边界。
真实产品页面：评测资产被组织成版本化、可选择的验证输入；截图证明页面和资产治理入口，不单独证明某个候选获得了真实业务泛化。
人工在环必须拥有持久化语义
“人工在环”最容易退化成一句产品文案。真正的边界是：如果人没有做出选择，系统是否仍会继续？选择是否留下来源、理由和时间？
当前候选集生成后没有默认选项。操作人必须明确选择一个候选并填写理由；候选的原始排名会被保留，但 Challenger 的输入不会看到这个排名和选择理由。后续接受或拒绝同样形成独立 disposition。AI 生成的评测草案也必须经过人工 admission 才能成为资产。
这使“人”不是模型调用之间的停顿，而是一个拥有独立状态变化的治理角色。
这套设计仍可能失败在哪里
第一，模型相关性仍然存在。候选生成器和 Challenger 即使 Prompt 分开，只要共享相近模型能力和训练偏差，就可能同时漏掉同一类风险。
第二，人工 Oracle 也可能错误。人工审核只改变责任归属，不自动保证结论正确；真实团队需要双人复核、抽样审计和争议处理机制。
第三，Held-out 会随迭代被消耗。一个留出集被反复查看和用于决策后，应当重新建立独立数据，而不能永久复用同一套答案。
第四，当前验证规模是实践项目级。没有足够证据声称某种模型组合比另一种更准确，也不能从聚焦测试推导商业效果。
当前验证证据
2026-09-02，我运行了候选生成、独立质询、评测草案、评测有效性和优化实验五个聚焦测试文件，共 20 项测试全部通过。其中包含几个关键反例：
- Challenger 如果对安全候选机械反对，校准失败；
- Provider 如果覆盖确定性决策信封，输出被拒绝；
- AI 生成评测如果冒充 Held-out，输出被拒绝；
- 评测有效性分析如果泄漏 Held-out 语义，校准失败；
- 候选必须经过显式人工选择，才能进入下一状态。
这些测试验证了当前代码合同，不证明真实模型在开放世界里不会合谋、偏置或误判。
读者可能关心的边界问题
Challenger 和 Generator 如果是同一个模型，还算独立吗？
只能说流程、信息视图和权限独立，不能说模型层完全独立。高风险生产环境可以再增加异构模型、盲评和第三方审核。
为什么不直接让人工写全部评测？
人工应拥有业务真值与最终准入权；AI 可以降低扩展问法、边界案例和证据整理的成本。关键不是排除 AI，而是避免 AI 生成的内容冒充独立 Oracle。
Held-out 为什么只隐藏内容，还展示 ID 和哈希？
治理流程需要证明独立资产存在并绑定了正确版本，但语义内容不应进入候选生成和分析上下文。ID 与哈希承担可追溯性，[SEALED] 保持内容隔离。
怎样避免人工只点通过？
当前项目要求选择理由并持久化状态，但还没有证明真实组织的审核质量。生产环境需要角色分离、抽样复核、审批 SLA 和异常审计。
结语
AI 优化闭环真正困难的不是让模型生成更多建议，而是防止建议、题目和判决来自同一条未经约束的信息链。
ResolveAI 没有假设某个 Judge 天生客观，而是把独立性拆成多层可检查的合同：确定性信封限定资格，Generator 只生成候选，Challenger 只做受限质询，Held-out 保持密封，多队列回归限定结论，人工持有最终状态变化。
候选方案需要经过独立检查、密封数据验证与人工选择，模型的自评不会直接改变发布状态。