LLM 治理准入规则二次校验：跨批次比较误差、例外压力与容量保护

发表于 分类于 阅读次数： Changyan： 本文字数： 6.7k 阅读时长 ≈ 6 分钟
接着首批 intake 的准入规则校验，这篇用第二批样本比较 false admit、false reject、例外压力与 owner capacity 变化，判断修订规则是真正收敛，还是只适配了上一批样本。

上一篇用下一季度首批 intake 检查更新后的 admission rule，并按单条规则给出 promote、revise、hold 或 rollback 决定。

其中一部分规则还不能进入稳定基线。比如关键 owner 容量证明的方向有效，但首批样本暴露出一个问题：团队总容量仍可能被当成关键角色容量。修订字段后，如果只回放同一批样本，很容易得到一个过于乐观的结果。

修订版能解释上一批错误，只算完成了回放。第二批更关心它面对另一组需求时，能否继续减少高影响误收，同时不制造新的误拒、例外绕行和容量挤兑。

这一篇继续往下走：冻结首批到第二批的规则差异，建立可比较的 cohort，再用错误率变化、例外压力漂移和 owner capacity 保护结果判断规则是否已经具备稳定性。

1. 第二批不是重新统计一次

首批校验发现问题，团队通常会立刻补字段、改阈值或缩小适用范围。第二批开始前，要先写清楚到底改了什么。

1
2
3
4
5
6
7
8
9
10
11
rule_revision:
  rule: critical_owner_capacity_proof
  from_version: admission_rules_2026_q4_rc1
  to_version: admission_rules_2026_q4_rc2
  changes:
    - replace_team_capacity_with_role_level_capacity
    - require_named_owner_acceptance
    - include_evidence_and_operation_hours
  unchanged:
    - protected_capacity_window
    - concurrency_limit

这里特意保留 unchanged。如果规则定义、样本范围、风险分级和观察窗口同时变化，即使误收下降，也无法判断是哪项变化产生了效果。

第二批校验至少冻结四件事：

  • 修订规则的版本与生效时间
  • intake 和 observation window
  • false_admit、false_reject 的判定口径
  • 影响等级与错误成本的计算方式

发现新问题可以先记入候选清单，但不要在批次中途悄悄修改规则。否则第二批内部也会出现不同版本，比较价值会再次丢失。

2. 先建立 cohort bridge，再比较两个批次

两批 intake 很少天然一致。第二批可能高风险项目更多，也可能只是小型内部工具。直接比较 3 个 false_admit 和 1 个 false_admit，结论很可能被样本结构误导。

可以先建立一份 cohort bridge：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
cohort_bridge:
  batch_01:
    total: 24
    high_risk: 6
    medium_risk: 10
    low_risk: 8
    cross_team_dependency: 9
    scarce_owner_required: 7

  batch_02:
    total: 28
    high_risk: 9
    medium_risk: 11
    low_risk: 8
    cross_team_dependency: 12
    scarce_owner_required: 10

  comparability:
    raw_count_comparable: false
    rate_comparable: partial
    risk_adjustment_required: true

这份桥接记录不追求复杂统计模型，只需要说明两个批次在哪些维度相似、哪些维度不同。

至少要看风险等级、依赖数量、稀缺 owner 使用情况、交付周期和证据要求。若第二批明显更难，错误绝对数小幅上升不一定说明规则退化；若第二批更简单，错误数持平反而可能是负面信号。

样本太少时，不要用百分比制造精确感。可以同时保留原始数量、分层结果和典型案例，让决策者看到数据背后的样本结构。

3. false admit 要比较数量，也要比较影响

修订容量证明不必追求所有误收归零，应该优先挡住那些在准入时已经可见、进入后又会消耗大量关键容量的项目。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
false_admit_delta:
  batch_01:
    count: 3
    high_impact: 2
    medium_impact: 1
    weighted_cost: 8
  batch_02:
    count: 2
    high_impact: 0
    medium_impact: 2
    weighted_cost: 4
  interpretation:
    count_delta: -1
    weighted_cost_delta: -4
    high_impact_gap_closed: true

第二批仍有两个误收，看起来规则没有完全解决问题。但高影响误收已经消失，剩余问题来自低估观察期运维成本，而不是再次用团队总容量替代关键角色容量。这说明修订命中了首批缺口，只是规则还没有覆盖全部成本。

误收 delta 复核时，建议逐项回答：

  • 首批暴露的同类错误是否再次出现
  • 新误收是否由修订规则引入
  • 错误在准入时是否真的可见
  • 错误成本是否从高影响迁移到低影响
  • 剩余缺口应该改规则，还是改执行期保护

只有同类高影响错误在可比样本中没有复发，才有理由认为修订方向已得到第二次验证。

4. false reject 不能成为降低误收的隐性代价

门禁加严后，误收下降并不意外。更难的是确认团队没有靠大面积拒绝来换取一个漂亮数字。

1
2
3
4
5
6
7
8
9
10
11
12
false_reject_delta:
  batch_01:
    rejected: 10
    false_reject: 2
    repeated_reason:
      workflow_entry_required: 2
  batch_02:
    rejected: 12
    false_reject: 1
    repeated_reason:
      workflow_entry_required: 0
      owner_acceptance_timeout: 1

首批中，workflow_entry_required 错误地挡住了有稳定 API 消费者的项目。修订适用范围后，第二批没有再出现同类误拒，说明范围调整有效。

新出现的 owner_acceptance_timeout 要单独判断。若 owner 明明有足够容量，只因审批窗口过短而被自动拒绝，这是规则副作用；若 owner 一直无法确认真实投入，它更接近正确拒绝，而不是流程效率问题。

因此，第二批不能只看 false reject rate，还要跟踪拒绝原因是否发生迁移。旧错误消失、新错误集中出现，说明规则不是稳定了，只是把压力从一个入口移到了另一个入口。

5. 例外压力要看“去了哪里”

首批例外请求主要集中在 capacity_override。修订容量证明后，请求数量下降，只能说明显式绕过减少了，不能证明压力消失。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
exception_pressure_drift:
  batch_01:
    total: 9
    capacity_override: 5
    business_deadline: 2
    premise_extension: 2
  batch_02:
    total: 7
    capacity_override: 1
    business_deadline: 5
    premise_extension: 1
  review:
    total_pressure_down: true
    pressure_migrated: true
    suspected_relabeling: business_deadline

capacity_override 从 5 次降到 1 次，但 business_deadline 增加到 5 次。如果这 5 个请求仍要求在没有关键 owner 保护容量的情况下进入 roadmap，只是换了理由，规则并没有真正收敛。

例外复核要回到请求内容，而不是依赖申请人选择的类型。可以检查：

  • 是否仍绕过同一条证据要求
  • 是否由同一业务线或审批人反复发起
  • 例外获批后是否补齐了承诺
  • 临时路径是否逐渐变成默认路径
  • 被拒绝的例外是否又以新项目名重新提交

稳定规则应该让合理例外更容易识别，让重复绕行更难伪装，而不是单纯把例外总量压低。

6. owner capacity 要验证“保护”，不只验证“声明”

修订版要求关键 owner 按角色确认容量，可以减少虚高声明。但项目进入 roadmap 后，这些容量是否真的被保护，仍然需要第二批观察。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
owner_capacity_comparison:
  role: policy_runtime_owner
  batch_01:
    declared_hours: 120
    verified_hours: 84
    protected_hours: 68
    borrowed_hours: 28
  batch_02:
    declared_hours: 96
    verified_hours: 94
    protected_hours: 90
    borrowed_hours: 6
  result:
    declaration_gap_reduced: true
    protection_gap_reduced: true
    concurrency_limit_respected: true

这里有两个独立改善：声明容量更接近可验证容量，进入执行窗口后被借走的时间也明显减少。

如果只有前一个改善，说明 admission rule 已经更准确，但 roadmap 仍没有兑现容量合同。此时继续收紧准入规则意义有限，应该补的是执行期变更审批、容量借用上限和默认降级动作。

容量保护可以用几个简单信号观察：

  • 声明容量与准入时可验证容量的差值
  • 可验证容量与观察期实际保护容量的差值
  • 单个稀缺 owner 的并发 commitment 数
  • 容量被借用后，是否同步缩减 scope 或延后 milestone
  • 因 owner 变化产生的例外和重新准入次数

规则负责阻止不真实的承诺进入，执行机制负责防止真实承诺进入后被掏空。两者不能混在一个指标里。

7. 区分规则收敛和环境偶然变好

第二批结果改善，还有一种可能：需求变简单了，关键 owner 恰好更空闲，或者外部依赖比首批稳定。

可以给每个主要改善补一个最小反事实检查：

1
2
3
4
5
6
7
8
9
10
11
12
13
stability_counterfactual:
  observed_improvement: high_impact_false_admit_removed
  possible_explanations:
    rule_revision:
      supported: true
      evidence: role_level_capacity_blocked_2_items
    easier_cohort:
      supported: false
      evidence: scarce_owner_items_increased_from_7_to_10
    temporary_capacity_relief:
      supported: partial
      evidence: incident_load_below_quarter_average
  conclusion: improvement_likely_but_monitor_next_window

反事实检查不负责证明唯一因果，它只用于避免把所有好结果都归功于规则。

如果修订字段确实在第二批拦住了两个过去会被接受的高风险项目，同时第二批稀缺 owner 需求并没有减少，就有较强证据支持规则有效。若改善主要来自临时容量宽松，则可以保留规则，但不应急着宣布稳定。

8. 稳定基线应该按单条规则晋升

一整套 admission rules 不需要同时进入 baseline。按单条规则做决定，能够保留已验证部分，也避免一个未解决的缺口拖住全部更新。

决策 第二批证据 后续动作
promote 首批同类高影响错误未复发，未产生不可接受的新误拒 写入稳定 baseline
revise 主要缺口改善，但出现可重复的新边界问题 形成 rc3 再验证
hold 样本不足或 cohort 差异过大 保持候选状态
rollback 错误成本或绕行压力高于治理收益 恢复上一稳定版本 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
second_batch_promotion_decision:
  baseline_target: admission_rules_2026_q4
  decisions:
    critical_owner_capacity_proof:
      decision: promote
      evidence:
        repeated_high_impact_false_admit: 0
        new_false_reject: 0
        capacity_protection_gap_reduced: true

    owner_acceptance_timeout:
      decision: revise
      evidence:
        new_false_reject: 1
      next_change:
        risk_based_response_window: true

    execution_escalation_contract:
      decision: hold
      reason: insufficient_triggered_samples

promote 也不是永久锁死。它只是说明规则已经通过当前两批验证，可以从候选配置进入受控基线。后续仍要有版本、漂移阈值和回退条件。

9. 一个可直接复用的第二批校验模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
second_intake_admission_validation:
  rule_versions:
    batch_01: admission_rules_2026_q4_rc1
    batch_02: admission_rules_2026_q4_rc2

  cohort:
    batch_01_size: 24
    batch_02_size: 28
    material_differences:
      - more_high_risk_items_in_batch_02
      - more_scarce_owner_dependencies_in_batch_02

  error_delta:
    false_admit:
      count: -1
      high_impact: -2
    false_reject:
      count: -1
      new_reason_count: 1

  exception_pressure:
    total_delta: -2
    migrated_to: business_deadline
    relabeling_confirmed: partial

  owner_capacity:
    declaration_gap_reduced: true
    protection_gap_reduced: true
    concurrency_limit_respected: true

  decisions:
    promote:
      - critical_owner_capacity_proof
    revise:
      - owner_acceptance_timeout
    hold:
      - execution_escalation_contract
    rollback: []

  next_control:
    baseline_owner: governance_program_owner
    drift_review_window: monthly
    rollback_contract_required: true

每个汇总值仍要能回到具体样本、准入快照和观察结果。无法完成反事实复核的拒绝项保持 pending，不要为了让第二批按时结束而强行归类。

小结

第二批 intake 不负责给首批结论再盖一次章，它要检查修订规则能否跨样本工作。

先冻结规则 delta 和判定口径，再用 cohort bridge 说明两批样本是否可比。误收需要同时比较数量与影响，误拒要检查压力是否迁移到新的拒绝原因；例外要识别换标签后的同类绕行，owner capacity 则要拆开声明准确性与执行期保护。

只有首批高影响错误没有复发、新副作用可接受、例外没有形成稳定旁路、容量保护在第二批仍能兑现，规则才适合进入稳定 baseline。晋升后还需要版本控制、漂移阈值和回退合同，避免“稳定”变成无人复查的永久配置。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-revised-admission-rule-second-intake-batch-stability-validation/