Pruebas de robustez frente a ataques adversariales

Cuando un sistema de identificación sale del laboratorio y empieza a recibir imágenes de personas reales, deja de importar cómo se comporta en el conjunto de validación. Lo que importa es qué pasa cuando alguien decide engañarlo. Ese "alguien" puede ser un atacante con intención, pero también un usuario con mala iluminación, una cámara sucia o una pose poco habitual. Los ataques adversariales, en el fondo, son la versión extrema de esa misma pregunta: ¿cuánto aguanta el modelo antes de equivocarse?

En este artículo describimos cómo construimos un banco de pruebas reproducible, qué perturbaciones aplicamos sobre las imágenes y por qué separamos los resultados por tipo de ataque en lugar de promediarlos. También explicamos qué métricas consideramos útiles y cuáles solo dan una falsa sensación de seguridad.

Por qué un banco de pruebas y no una batería de casos sueltos

La primera tentación es reunir un puñado de ejemplos llamativos, pasarlos por el modelo y publicar una tabla. Eso no es una prueba, es una anécdota. Un banco reproducible exige tres cosas: una versión congelada del modelo, un conjunto de imágenes fijo con su hash y un script que aplique siempre las mismas transformaciones en el mismo orden. Si cualquiera de esas piezas cambia, los números dejan de ser comparables y la auditoría pierde su valor.

Nosotros trabajamos con lotes cerrados. Cada lote se etiqueta con la fecha de generación, la versión del modelo evaluado y la semilla aleatoria usada en las perturbaciones. Cuando repetimos una prueba meses después, esperamos obtener exactamente el mismo resultado. Si no coincide, hay algo que no estamos controlando y eso ya es un hallazgo.

Qué perturbaciones aplicamos

No todas las perturbaciones sirven para lo mismo. Algunas miden la fragilidad del modelo ante ruido, otras miden su sensibilidad a cambios semánticos. Las agrupamos en cuatro familias y las reportamos por separado:

• Ruido numérico controlado. Variaciones de píxel con magnitud acotada, pensadas para detectar cuánto margen tiene la frontera de decisión antes de que una predicción se invierta.
• Transformaciones geométricas. Rotaciones leves, recortes, cambios de escala y pequeñas deformaciones. Son las que más se parecen a lo que ocurre con una cámara mal sujeta.
• Alteraciones fotométricas. Cambios de exposición, temperatura de color y contraste. Aquí aparecen muchos falsos negativos que en validación no se veían.
• Ataques dirigidos. Perturbaciones optimizadas para empujar la salida hacia una clase concreta. Son las más costosas de generar y las que más información aportan sobre los límites reales del sistema.

Por qué no promediamos los resultados

Un promedio único sobre todas las familias de ataque es cómodo de leer y casi siempre engañoso. Un modelo puede resistir muy bien el ruido numérico y desmoronarse ante un cambio de exposición. Si juntamos ambos números en una sola cifra, la debilidad desaparece del informe y el lector se queda con una impresión falsa de solidez.

Por eso reportamos cada familia por separado, con su intervalo y con el tamaño de muestra usado. Cuando una familia tiene pocos casos, lo decimos explícitamente en lugar de rellenar con datos sintéticos. Preferimos un hueco visible a una curva suave que no significa nada.

Métricas que sí miramos

La exactitud agregada no nos dice gran cosa en este contexto. Nos interesan más la tasa de inversión de predicción bajo perturbación creciente, la distancia mínima necesaria para provocar un cambio de clase y la varianza de esas distancias entre subgrupos de imágenes. Esa varianza es la que suele revelar que el modelo no es frágil en general, sino frágil para cierto tipo de rostros, ciertas condiciones de luz o ciertos ángulos de cámara.

También registramos el coste computacional de generar cada ataque. Un ataque que tarda horas en producirse y solo afecta a un caso aislado no es lo mismo que uno que se genera en segundos y afecta a miles. Esa diferencia cambia por completo la lectura del riesgo.

Qué consideramos una falsa sensación de seguridad

Hay dos señales que nos hacen desconfiar de inmediato. La primera es un informe que solo muestra el rendimiento global sin desglose. La segunda es un banco de pruebas que no se puede volver a ejecutar porque falta la semilla, la versión del modelo o el conjunto exacto de imágenes. En ambos casos el número puede ser correcto y, aun así, no servir para tomar decisiones.

Nuestra recomendación es sencilla: antes de aceptar cualquier resultado de robustez, pedir el script, la semilla y la lista de casos. Si no están, el resultado es una opinión con formato de tabla.