Capítulo 40 — Laboratorio de verificación II
Mapa de la lección
Lección 40 publicada. Mapa, ejemplo, EX118.
flowchart TD
N0["Resultados de aprendizaje"]
N1["40.1 Campañas integradas"]
N2["40.2 Criterios de aceptación"]
N3["40.3 Las tasas base en la aceptación"]
N4["40.4 Paquete de evidencia"]
N5["40.6b Repetir la campaña tras las correcciones"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX118"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["40.1 Campañas integradas"]
N2["40.2 Criterios de aceptación"]
N3["40.3 Las tasas base en la aceptación"]
N4["40.4 Paquete de evidencia"]
N5["40.6b Repetir la campaña tras las correcciones"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX118"]
[Resultados de aprendizaje]
|
v
[40.1 Campañas integradas]
|
v
[40.2 Criterios de aceptación]
|
v
[40.3 Las tasas base en la aceptación]
|
v
[40.4 Paquete de evidencia]
|
v
[40.6b Repetir la campaña tras las correcciones]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX118]
Resultados de aprendizaje
Usted será capaz de (1) ejecutar una campaña de verificación integrada que abarque varios componentes de IA; (2) probar los controles ante ataques y fallos combinados; (3) usar criterios de aceptación estadísticos; y (4) elaborar un paquete de evidencia adecuado para un evaluador independiente.
40.1 Campañas integradas
El laboratorio I probó componentes; el laboratorio II prueba el sistema. Combine ataques con fallos: inyección durante una caída de un conector; envenenamiento detectado durante una actualización del modelo; intentos de extracción mientras la monitorización está degradada. Los sistemas fallan a menudo en estas intersecciones. Las pruebas de componentes suponen que todos los vecinos se comportan con normalidad. En el sistema real, las caídas, las actualizaciones y los ataques se solapan, y la gestión de uno puede abrir una brecha para otro. Un conector que falla puede desviar las alertas a una cola que nadie vigila; una actualización del modelo puede desactivar brevemente la monitorización. Los escenarios integrados se eligen a partir del modelo de amenazas y del análisis de fallos conjuntamente, emparejando cada amenaza de alta prioridad con un fallo simultáneo verosímil.
40.2 Criterios de aceptación
Use criterios estadísticos vinculados a los requisitos: para un requisito de tasa ≤ p con una confianza del 95 %, la cota superior de Wilson (o la cota exacta) debe quedar por debajo de p. Con cero fallos, se necesitan unos 3/p ensayos (regla del tres). Decida los criterios antes de ejecutar las pruebas.
"""Lab S: reporting attack-success rates honestly: Wilson intervals,
seed variation and a paired bootstrap. Synthetic trial outcomes only."""
import math, random
def wilson(k, n, z=1.96):
p = k/n; d = 1 + z*z/n
c = (p + z*z/(2*n))/d; h = z*math.sqrt(p*(1-p)/n + z*z/(4*n*n))/d
return c - h, c + h
for k, n in ((3, 20), (30, 200), (300, 2000)):
lo, hi = wilson(k, n); print(f"successes={k}/{n} rate={k/n:.3f} wilson95=[{lo:.3f}, {hi:.3f}]")
# five seeds of a synthetic defence evaluation: per-seed attack success rate
rates = []
for seed in range(5):
r = random.Random(seed); rates.append(sum(r.random() < 0.12 for _ in range(200))/200)
m = sum(rates)/5; sd = math.sqrt(sum((x-m)**2 for x in rates)/4)
print("per-seed rates:", " ".join(f"{x:.3f}" for x in rates), f"mean={m:.3f} sd={sd:.3f}")
# paired bootstrap: baseline vs defence on the same 300 synthetic prompts
r = random.Random(42)
base = [r.random() < 0.30 for _ in range(300)]
defn = [b and r.random() < 0.6 for b in base] # defence blocks ~40% of successes
diffs = []
for _ in range(2000):
idx = [r.randrange(300) for _ in range(300)]
diffs.append(sum(base[i] for i in idx)/300 - sum(defn[i] for i in idx)/300)
diffs.sort()
print(f"baseline_asr={sum(base)/300:.3f} defended_asr={sum(defn)/300:.3f} "
f"reduction_ci95=[{diffs[50]:.3f}, {diffs[1949]:.3f}]")
Salida esperada:
successes=3/20 rate=0.150 wilson95=[0.052, 0.360]
successes=30/200 rate=0.150 wilson95=[0.107, 0.206]
successes=300/2000 rate=0.150 wilson95=[0.135, 0.166]
per-seed rates: 0.110 0.130 0.135 0.105 0.145 mean=0.125 sd=0.017
baseline_asr=0.350 defended_asr=0.190 reduction_ci95=[0.120, 0.203]
La regla del tres hace visible el coste: demostrar una tasa de fallos inferior al 1 % sin ningún fallo requiere unos 300 ensayos, e inferior al 0,1 %, unos 3.000. Escribir primero el criterio impide que el equipo relaje un umbral una vez conocidos los resultados, o que detenga una prueba antes de tiempo porque las cifras parecen buenas en ese momento. Cada criterio nombra su requisito, de modo que una cota no superada señala directamente qué debe cambiar.
40.3 Las tasas base en la aceptación
Los requisitos de los detectores deben comprobarse con tasas base realistas; un detector que supera los umbrales de TPR/FPR puede producir aun así una precisión inutilizable en la operación.
"""Lab B: base rates and alarm precision (Bayes' rule).
A detector for malicious prompts with given true- and false-positive rates
is applied to traffic with different shares of malicious prompts."""
for tpr, fpr in ((0.95, 0.05), (0.95, 0.01), (0.80, 0.001)):
for prev in (0.10, 0.01, 0.001):
tp = tpr * prev; fp = fpr * (1 - prev)
prec = tp / (tp + fp)
per_10k = round(10000 * (tp + fp))
print(f"tpr={tpr:.2f} fpr={fpr:.3f} prevalence={prev:.3f} precision={prec:.3f} alerts_per_10k={per_10k}")
Salida esperada:
tpr=0.95 fpr=0.050 prevalence=0.100 precision=0.679 alerts_per_10k=1400
tpr=0.95 fpr=0.050 prevalence=0.010 precision=0.161 alerts_per_10k=590
tpr=0.95 fpr=0.050 prevalence=0.001 precision=0.019 alerts_per_10k=509
tpr=0.95 fpr=0.010 prevalence=0.100 precision=0.913 alerts_per_10k=1040
tpr=0.95 fpr=0.010 prevalence=0.010 precision=0.490 alerts_per_10k=194
tpr=0.95 fpr=0.010 prevalence=0.001 precision=0.087 alerts_per_10k=109
tpr=0.80 fpr=0.001 prevalence=0.100 precision=0.989 alerts_per_10k=809
tpr=0.80 fpr=0.001 prevalence=0.010 precision=0.890 alerts_per_10k=90
tpr=0.80 fpr=0.001 prevalence=0.001 precision=0.445 alerts_per_10k=18
Por eso el plan de aceptación indica una prevalencia esperada para cada detector, tomada de los datos de operación o de una estimación justificada, y calcula la precisión y el volumen de alertas con esa tasa. Un detector que enviaría a los operadores cien falsas alertas por cada alerta real no supera la aceptación aunque su TPR y su FPR cumplan sus umbrales, porque en la operación sus alertas pronto se ignorarían.
40.4 Paquete de evidencia
Organice la evidencia por requisito: plan de pruebas, resultados en bruto, análisis, supera/no supera, desviaciones, nuevas pruebas. Incluya descripciones del entorno, las versiones de modelos y datos con sus hashes y las versiones de las herramientas. Un evaluador independiente debe poder seguir cada requisito hasta su evidencia sin preguntar al equipo. Los hashes de los modelos y los datos vinculan cada resultado a artefactos exactos, de modo que nadie pueda alegar más tarde que se probó una versión distinta. Las desviaciones, como un escenario ejecutado con menos ensayos de los previstos, se enumeran en lugar de ocultarse. Un evaluador que lea el paquete debe poder repetir cualquier prueba a partir de las versiones y semillas registradas y llegar a las mismas cifras.
40.5 Ejemplo resuelto (caso sintético de NRS)
La campaña integrada de Sam ejecutó 18 escenarios sobre TrackEye, Pulse y Wrench. El escenario 11 (suplantación de un sensor de Pulse durante una caída del conector del sistema de incidencias) reveló que, cuando fallaba el sistema de incidencias, las alertas de Pulse quedaban en cola en silencio durante 40 minutos. La corrección añadió una comprobación de salud de la vía de alertas con recurso a SMS para las alertas críticas. Todos los requisitos de tasa se evaluaron con cotas superiores de Wilson definidas de antemano; dos que habían superado las estimaciones puntuales no superaron sus cotas y necesitaron conjuntos de prueba mayores, tras lo cual uno se superó y el otro dio lugar a una mejora del modelo.
La cola silenciosa es el tipo de fallo que ninguna prueba de componentes podría encontrar.
40.6 Errores y límites
- Probar solo los componentes por separado.
- Criterios de aceptación decididos después de ver los resultados.
- Evidencia dispersa en carpetas personales.
Las pruebas de componentes aislados pasan por alto las interacciones en las que fallan los sistemas integrados, como mostró el escenario 11. Los criterios elegidos tras ver los resultados pueden forzarse para que encajen con lo que haya ocurrido. La evidencia guardada en carpetas personales desaparece cuando las personas se van y no puede revisarla un evaluador. La plantilla de campaña de Sam fija los criterios, los escenarios y las ubicaciones de la evidencia antes de la primera ejecución, y un revisor la firma. Sus cambios se fechan.
40.6b Repetir la campaña tras las correcciones
Cuando el laboratorio II encuentra un fallo, la corrección va seguida de la misma campaña, no de una más pequeña, para que NRS pueda demostrar que la corrección funcionó sin romper otros criterios de aceptación. Ambas ejecuciones se conservan en el paquete de evidencia con sus fechas y versiones. El escenario 11 muestra por qué. La corrección de la cola silenciosa de 40 minutos de las alertas de Pulse añadió una comprobación de salud y un recurso a SMS, lo que cambió la vía de todas las alertas críticas, no solo las de Pulse. Repetir los 18 escenarios, y no solo el escenario 11, era la única forma de demostrar que las alertas de TrackEye y de Wrench seguían llegando a tiempo por la vía modificada.
Ejercicios — capítulo 40
- EX118 — Escenario combinado. Diseñe un escenario combinado de ataque más fallo para Wrench. Rúbrica: 3 = ataque concreto + fallo + comportamiento seguro esperado + medición; 2 = parcial; 1 = vago; 0 = nada.
- EX119 — Cota. Observa 1 fallo en 200 ensayos para un requisito ≤ 2 %. ¿Se supera la cota superior del 95 %? (Cota superior de Wilson ≈ 2,8 %). Rúbrica: 3 = no, la cota superior supera el 2 %; se necesitan más ensayos o una mejora; 2 = solo la respuesta; 1 = usa la estimación puntual; 0 = nada.
- EX120 — Lectura del laboratorio. Con una prevalencia de 0,01, ¿qué precisión da el detector 0,95/0,01 y es aceptable para el bloqueo automático? Rúbrica: 3 = 0,490; probablemente no para bloquear sin revisión, depende del coste; 2 = solo la cifra; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
La verificación integrada encuentra los fallos en las intersecciones, juzga los resultados con criterios estadísticos definidos de antemano y empaqueta la evidencia para que otros puedan evaluarla de forma independiente.
Siga estudiando — capítulo 40 de 50
← Capítulo 39 (borrador) · Índice de capítulos del curso · Capítulo 41 (borrador) →