Skip to content
登入開始使用

指南

叢集案例

大多數區間計算都假設每個案例彼此獨立。同一段對話的三個回合並非如此：當對話出錯時，三個回合往往一起出錯。將它們視為獨立的測試套件，會回報比證據所能支持的更窄的區間，而關卡可能因此放行。

宣告叢集

案例以 group_id 指定其所屬叢集，位於資料列的最上層，與 id 並列：

{"id": "conv00_t0", "group_id": "conv00", "input": {"question": "Conversation 0 turn 0: refund please (garbled)"}, "expected": {"label": "refund"}}
{"id": "conv00_t1", "group_id": "conv00", "input": {"question": "Conversation 0 turn 1: where is my order (garbled)"}, "expected": {"label": "other"}}
{"id": "conv00_t2", "group_id": "conv00", "input": {"question": "Conversation 0 turn 2: refund please (garbled)"}, "expected": {"label": "refund"}}

只要有任何案例宣告了叢集，整個測試套件就會依叢集進行分析。沒有可針對個別指標切換回來的開關：將分組案例視為獨立是不安全的方向，因此不提供此選項。

會有什麼改變

來自 36 段對話的同樣 108 個回合，其中每六段對話就有一段從第一個回合到最後一個回合都是亂碼。沒有 group_id 時：

│ exact_label │ 83.3%    │ [74.9%, 89.9%] │ 90 / 108 observed · 0 missing · 0 excluded │

加上它之後：

│ exact_label │ 83.3%    │ [65.2%, 94.6%] │ 90 / 108 observed · 0 missing · 0 excluded · 36 clusters · approximate │

估計值完全相同。區間寬了大約一倍，因為測試套件包含的是 36 個獨立觀測值，而不是 108 個。以 0.70 為下限，並採用下文所述的明確啟用設定，第一次執行通過，第二次則沒有：

label-floor: PASS (lower_bound_meets_minimum)
label-floor: INSUFFICIENT_EVIDENCE (interval_overlaps_threshold)

對這份資料而言，第二個答案才是正確的。

明確啟用

叢集區間是一種學生化叢集自助法（studentized cluster bootstrap）。它是近似方法，政策必須先表明接受近似方法，規則才能依它做出判定。若未表明，同一次分組執行會顯示：

label-floor: MANUAL_REVIEW (approximate_method_not_permitted)

並以 4 結束。若要讓規則做出判定，請將以下內容加入 release.yaml：

allow_approximate_methods: true

另有兩項設定界定了此方法可被信任的範圍。

設定預設值作用
min_clusters20叢集數少於此值時，規則會顯示 INSUFFICIENT_EVIDENCE 並附 insufficient_clusters。可以調低到 10，但不能更低。
max_missing_fraction無設定在規則上。叢集區間無法像獨立區間那樣為缺失案例設定界限，因此針對含有任何缺失案例之指標的叢集規則會顯示 missingness_unbounded，直到規則聲明它可接受多少缺失為止。

設定 min_clusters: 5 的政策會在任何判定之前被拒絕：

Configuration error: p5.yaml: min_clusters: Input should be greater than or equal to 10

同樣的對話，其中一段在每個回合都發生錯誤：

│ exact_label │ 82.9%    │ [64.3%, 94.5%] │ 87 / 105 observed · 3 missing · 0 excluded · 35 clusters · approximate │
label-floor: INSUFFICIENT_EVIDENCE (missingness_unbounded)

聲明其可接受缺失程度的規則：

rules:
  - id: label-floor
    metric: exact_label
    min: 0.60
    max_missing_fraction: 0.15
label-floor: PASS (lower_bound_meets_minimum)

聲明一個比例即記錄了一項假設：缺失案例是隨機缺失的。判定的可靠程度取決於這項假設，這正是引擎不會替您做這個假設的原因。

叢集測試套件目前還做不到的事

只有通過/失敗比率具有叢集區間。在宣告了 group_id 的測試套件上：

  • 平均值、分位數或排序指標沒有區間，針對它們的規則會顯示

MANUAL_REVIEW 並附 unsupported_dependence_structure；

  • 當 replicates: 大於 1 時，任何指標都沒有區間，通過/失敗比率也包括在內，因為兩種相依結構會相互組合，而目前沒有任何方法能同時為兩者建模；
  • 兩次執行的比較對任何指標都沒有區間。

分組測試套件上的延遲分位數：

│ latency_p50 │ 1.365 ms │ no interval: unsupported_dependence_structure │ p50 of 108 observed · 0 missing · 0 excluded │

最後一項限制最為重要。比較對話測試套件的兩次執行，其中候選版本修正了每一段亂碼對話：

oloproof compare CANDIDATE_RUN_ID BASELINE_RUN_ID --policy compare.yaml
Comparison sha256:ed7820e6471f70ce2b5e16ba618fdd48ea92a5ed39d23cce0b719ab31fcb16af of run_01M3C43MWTH8127R7S5M4N9DQ9 against run_01M3C43J2DVM93EWWWRBMRW22E · 108 paired cases
exact_label: +16.7 points · 108 paired · 0 missing · 0 excluded
  no interval: unsupported_dependence_structure
Decisions
  no-regression  exact_label  non-inferiority, margin 5.0 points  MANUAL_REVIEW  unsupported_dependence_structure
Gate: BLOCK (exit 4)

目前沒有任何適用於叢集測試套件的配對程序通過其驗證網格，因此比較只回報差異並請人判斷，而不是以近似方式做出判定。之所以是 MANUAL_REVIEW 而非 INSUFFICIENT_EVIDENCE，是因為更多同類案例也無法解決這個問題。

下一步