Skip to content

Anleitungen

Geclusterte Fälle

Die meiste Intervallrechnung nimmt an, dass jeder Fall von jedem anderen unabhängig ist. Drei Züge eines Gesprächs sind es nicht: Wenn das Gespräch schiefgeht, gehen meist alle drei schief. Eine Suite, die sie als unabhängig behandelt, meldet ein engeres Intervall, als die Evidenz trägt, und ein Gate kann darauf bestehen.

Einen Cluster deklarieren

Ein Fall nennt seinen Cluster mit group_id, auf oberster Ebene der Zeile neben 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"}}

Sobald irgendein Fall einen Cluster deklariert, wird die ganze Suite nach Clustern analysiert. Es gibt keinen Schalter pro Metrik, um das zurückzunehmen: Gruppierte Fälle als unabhängig zu behandeln ist die unsichere Richtung, daher wird es nicht angeboten.

Was sich ändert

Dieselben 108 Züge aus 36 Gesprächen, jedes sechste Gespräch vom ersten bis zum letzten Zug verstümmelt. Ohne group_id:

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

Mit:

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

Die Schätzung ist identisch. Das Intervall ist etwa doppelt so breit, weil die Suite 36 unabhängige Beobachtungen enthält statt 108. Gegen eine Untergrenze von 0.70 und mit der unten beschriebenen Zustimmung besteht der erste Lauf und der zweite nicht:

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

Die zweite Antwort ist die richtige für diese Daten.

Die Zustimmung

Das geclusterte Intervall ist ein studentisierter Cluster-Bootstrap. Es ist eine approximative Methode, und eine Policy muss erklären, dass sie eine solche akzeptiert, bevor eine Regel darauf entscheiden darf. Ohne diese Erklärung lautet derselbe gruppierte Lauf:

label-floor: MANUAL_REVIEW (approximate_method_not_permitted)

und endet mit 4. Damit die Regel entscheiden kann, fügen Sie Folgendes zu release.yaml hinzu:

allow_approximate_methods: true

Zwei weitere Einstellungen begrenzen, womit der Methode vertraut wird.

EinstellungVoreinstellungWas sie bewirkt
min_clusters20Bei weniger Clustern lautet eine Regel INSUFFICIENT_EVIDENCE mit insufficient_clusters. Der Wert kann auf 10 gesenkt werden, nicht weiter.
max_missing_fractionkeineWird an einer Regel gesetzt. Ein geclustertes Intervall kann fehlende Fälle nicht so begrenzen wie ein unabhängiges, daher lautet eine geclusterte Regel über einer Metrik mit auch nur einem fehlenden Fall missingness_unbounded, bis die Regel angibt, wie viel Fehlendes sie akzeptiert.

Eine Policy, die min_clusters: 5 setzt, wird abgelehnt, bevor irgendetwas entschieden wird:

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

Dieselben Gespräche, wobei eines davon bei jedem Zug einen Fehler liefert:

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

Eine Regel, die angibt, wie viel Fehlendes sie akzeptiert:

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

Einen Anteil anzugeben hält eine Annahme fest: dass die fehlenden Fälle zufällig fehlen. Die Entscheidung ist nur so gut wie diese Annahme, und deshalb trifft die Engine sie nicht für Sie.

Was eine geclusterte Suite noch nicht kann

Nur Bestehensquoten haben ein geclustertes Intervall. Bei einer Suite, die group_id deklariert:

  • hat ein Mittelwert, ein Quantil oder eine Ranking-Metrik kein Intervall, und eine Regel darauf

lautet MANUAL_REVIEW mit unsupported_dependence_structure;

  • hat bei replicates: über 1 keine Metrik ein Intervall, Bestehensquoten eingeschlossen, weil

sich die beiden Abhängigkeitsstrukturen überlagern und nichts beide modelliert;

  • hat ein Vergleich zweier Läufe für keine Metrik ein Intervall.

Ein Latenzquantil bei der gruppierten Suite:

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

Die letzte Einschränkung wiegt am schwersten. Ein Vergleich zweier Läufe der Gesprächs-Suite, bei dem der Kandidat jedes verstümmelte Gespräch repariert:

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)

Kein gepaartes Verfahren für geclusterte Suites hat bisher sein Validierungsraster bestanden, daher meldet der Vergleich die Differenz und fragt einen Menschen, statt approximativ zu entscheiden. MANUAL_REVIEW statt INSUFFICIENT_EVIDENCE, weil mehr Fälle derselben Art das nicht beheben würden.

Wie es weitergeht

entschieden wird.