Skip to content
Se connecterCommencer

Guides

Cas groupés

La plupart des calculs d’intervalles supposent que chaque cas est indépendant de tous les autres. Trois tours d’une même conversation ne le sont pas : quand la conversation déraille, les trois ont tendance à dérailler ensemble. Une suite qui les traite comme indépendants rapporte un intervalle plus étroit que ce que les preuves justifient, et une porte peut réussir sur cette base.

Déclarer un groupe

Un cas nomme son groupe avec group_id, au niveau supérieur de la ligne, à côté de 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"}}

Dès qu’un cas en déclare un, toute la suite est analysée par groupe. Il n’existe pas d’option par métrique pour revenir en arrière : traiter des cas groupés comme indépendants est la direction dangereuse, elle n’est donc pas proposée.

Ce qui change

Les mêmes 108 tours issus de 36 conversations, une conversation sur six brouillée de son premier tour à son dernier. Sans group_id :

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

Avec :

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

L’estimation est identique. L’intervalle est environ deux fois plus large, parce que la suite contient 36 observations indépendantes et non 108. Face à un plancher de 0.70, avec l’activation explicite décrite ci-dessous, la première exécution réussit et la seconde non :

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

La seconde réponse est la bonne pour ces données.

L’activation explicite

L’intervalle groupé est un bootstrap par groupes studentisé. C’est une méthode approchée, et une politique doit déclarer qu’elle en accepte une avant qu’une règle puisse décider sur cette base. Sans cela, la même exécution groupée donne :

label-floor: MANUAL_REVIEW (approximate_method_not_permitted)

et se termine avec 4. Pour laisser la règle décider, ajoutez ceci à release.yaml :

allow_approximate_methods: true

Deux autres réglages bornent ce qui est confié à la méthode.

RéglageValeur par défautCe qu’il fait
min_clusters20En dessous de ce nombre de groupes, une règle donne INSUFFICIENT_EVIDENCE avec insufficient_clusters. Il peut être abaissé jusqu’à 10, pas au-delà.
max_missing_fractionaucuneDéfini sur une règle. Un intervalle groupé ne peut pas borner les cas manquants comme le fait un intervalle indépendant ; une règle groupée sur une métrique comportant le moindre cas manquant donne donc missingness_unbounded tant que la règle n’indique pas quelle part de données manquantes elle accepte.

Une politique qui fixe min_clusters: 5 est refusée avant toute décision :

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

Les mêmes conversations, dont l’une est en erreur à chaque tour :

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

Une règle qui indique la part de données manquantes qu’elle accepte :

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

Indiquer une fraction enregistre une hypothèse : que les cas manquants le sont au hasard. La décision ne vaut que ce que vaut cette hypothèse, et c’est pourquoi le moteur ne la fera pas à votre place.

Ce qu’une suite groupée ne sait pas encore faire

Seuls les taux de réussite/échec ont un intervalle groupé. Sur une suite qui déclare group_id :

  • une moyenne, un quantile ou une métrique de classement n’a pas d’intervalle, et une règle qui

porte dessus donne MANUAL_REVIEW avec unsupported_dependence_structure ;

  • avec replicates: supérieur à 1, aucune métrique n’a d’intervalle, taux de réussite/échec

compris, parce que les deux structures de dépendance se combinent et que rien ne modélise les deux ;

  • une comparaison de deux exécutions n’a d’intervalle pour aucune métrique.

Un quantile de latence sur la suite groupée :

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

La dernière limite est la plus importante. En comparant deux exécutions de la suite de conversations, le candidat corrigeant toutes les conversations brouillées :

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)

Aucune procédure appariée pour les suites groupées n’a passé sa grille de validation ; la comparaison rapporte donc l’écart et sollicite une personne plutôt que de décider de façon approchée. MANUAL_REVIEW plutôt que INSUFFICIENT_EVIDENCE, parce que davantage de cas du même type ne résoudraient rien.

Pour aller plus loin

comparaison est décidée.