Skip to content
Iniciar sesiónEmpezar

Guías

Casos agrupados

La mayor parte de la aritmética de intervalos supone que cada caso es independiente de todos los demás. Tres turnos de una misma conversación no lo son: cuando la conversación sale mal, los tres suelen salir mal. Una suite que los trata como independientes informa un intervalo más estrecho de lo que la evidencia respalda, y un gate puede pasar con él.

Declarar un grupo

Un caso indica su grupo con group_id, en el nivel superior de la fila, junto a 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"}}

En cuanto un caso declara uno, toda la suite se analiza por grupos. No hay forma de volver atrás métrica por métrica: tratar casos agrupados como independientes es la dirección insegura, así que no se ofrece.

Qué cambia

Los mismos 108 turnos de 36 conversaciones, con una de cada seis conversaciones corrompida desde su primer turno hasta el último. Sin group_id:

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

Con él:

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

La estimación es idéntica. El intervalo es aproximadamente el doble de ancho, porque la suite contiene 36 observaciones independientes y no 108. Con un mínimo de 0.70, y con la aceptación explícita que se describe más abajo, la primera ejecución pasa y la segunda no:

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

La segunda respuesta es la correcta para estos datos.

La aceptación explícita

El intervalo por grupos es un bootstrap de grupos studentizado. Es un método aproximado, y una política tiene que declarar que lo acepta antes de que una regla pueda decidir con él. Sin eso, la misma ejecución agrupada dice:

label-floor: MANUAL_REVIEW (approximate_method_not_permitted)

y termina con 4. Para dejar que la regla decida, añada esto a release.yaml:

allow_approximate_methods: true

Otros dos ajustes limitan aquello para lo que se confía en el método.

AjusteValor por defectoQué hace
min_clusters20Con menos grupos que este valor, una regla da INSUFFICIENT_EVIDENCE con insufficient_clusters. Puede bajarse hasta 10 y no más.
max_missing_fractionningunoSe fija en una regla. Un intervalo por grupos no puede acotar los casos faltantes como lo hace uno independiente, así que una regla agrupada sobre una métrica con algún caso faltante da missingness_unbounded hasta que la regla indique cuánta ausencia de datos acepta.

Una política que fija min_clusters: 5 se rechaza antes de decidir nada:

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

Las mismas conversaciones, con una de ellas dando error en cada turno:

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

Una regla que indica la ausencia de datos que acepta:

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

Indicar una fracción registra un supuesto: que los casos faltantes faltan al azar. La decisión es tan buena como ese supuesto, y por eso el motor no lo hará por usted.

Lo que una suite agrupada aún no puede hacer

Solo las tasas de aprobado/fallo tienen un intervalo por grupos. En una suite que declara group_id:

  • una media, un cuantil o una métrica de ranking no tiene intervalo, y una regla sobre ellos da

MANUAL_REVIEW con unsupported_dependence_structure;

  • con replicates: por encima de 1, ninguna métrica tiene intervalo, incluidas las tasas de

aprobado/fallo, porque las dos estructuras de dependencia se combinan y nada modela ambas;

  • una comparación de dos ejecuciones no tiene intervalo para ninguna métrica.

Un cuantil de latencia en la suite agrupada:

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

La última limitación es la que más importa. Al comparar dos ejecuciones de la suite de conversaciones, en la que el candidato corrige todas las conversaciones corrompidas:

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)

Ningún procedimiento pareado para suites agrupadas ha superado su malla de validación, así que la comparación informa la diferencia y consulta a una persona en lugar de decidir de forma aproximada. MANUAL_REVIEW y no INSUFFICIENT_EVIDENCE, porque más casos del mismo tipo no lo resolverían.

Siguientes pasos

comparación.