💻 computer science

Auditing Inference-Time Defense Evaluation for Multimodal Large Language Models

Este artículo presenta una auditoría comparativa trazable de las defensas en tiempo de inferencia de los modelos de lenguaje de gran tamaño multimodales, revelando fallos críticos de procedencia en los datos de referencia y en los protocolos de evaluación que invalidan las afirmaciones previas de rechazo masivo, al tiempo que destaca la necesidad de estándares rigurosos de integridad de datos en las evaluaciones de seguridad futuras.

Autores originales: Bulat Nutfullin, Vladimir Evgrafov, Dmitry Namiot

Publicado 2026-07-17

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Bulat Nutfullin, Vladimir Evgrafov, Dmitry Namiot

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres el chef ejecutivo de un restaurante muy elegante que sirve dos cosas a la vez: una imagen en un plato y un pedido hablado. Tu objetivo es asegurarte de que la cocina nunca cocine nada peligroso, incluso si alguien intenta engañar al chef escondiendo una instrucción "venenosa" dentro de la imagen o susurrándola de una manera extraña. Este es el mundo de los Modelos de Lenguaje de Gran Escala Multimodales (MLLM). Estos son cerebros computacionales súper inteligentes que pueden "ver" imágenes y "leer" texto, y luego charlar contigo. Pero como pueden ver, los actores malintencionados pueden intentar colar comandos dañinos dibujándolos en los píxeles o escondiéndolos en el fondo de una foto.

Para detener esto, los científicos han inventado las Defensas en el Tiempo de Inferencia. Piensa en ellas como guardias de seguridad que se paran justo en la puerta de la cocina; no cambian la receta del chef (el cerebro del modelo), sino que revisan el pedido antes de que entre, o revisan el plato final antes de que salga. Algunos guardias añaden una nota de advertencia cortés al pedido, mientras que otros sacuden un poco la imagen para emborronar cualquier truco oculto. La gran pregunta para todo el mundo en el mundo de la seguridad de la IA es: ¿Qué guardia está haciendo realmente el mejor trabajo? Si no podemos confiar en los guardias, podríamos servir accidentalmente una comida peligrosa o, peor aún, podríamos tener tanto miedo al peligro que nos negáramos a servir cualquier comida en absoluto.

La Gran Auditoría de la Cocina: Cuando la Ficha de Puntuación Estaba Equivocada

Un equipo de investigadores de Moscú decidió jugar a ser detectives. No construyeron nuevos guardias; en su lugar, se metieron en los archivos de un experimento reciente que afirmaba probar tres diferentes guardias de seguridad (inspirados en métodos llamados RapGuard, AdaShield y SmoothVLM) a través de ocho diferentes chefs de IA. Querían ver quién era el mejor. Pero al escarbar entre los archivos, encontraron un desastre de enlaces rotos, ingredientes faltantes y fichas de puntuación confusas.

Esto es lo que descubrieron, servido con una guarnición de realidades.

1. El Misterio del "Ingrediente Faltante"

Los investigadores descubrieron que el experimento debía probar 9,000 pedidos diferentes (entradas) a través de siete diferentes pruebas de seguridad. Sin embargo, cuando revisaron la procedencia (el rastro de papel de dónde venían los datos), se dieron cuenta de que tres de las siete pruebas estaban completamente rotas.

El Error del "Plato Equivocado": Una prueba, destinada a comprobar si la IA podía detectar instrucciones ocultas en imágenes, estaba sirviendo en realidad el plato equivocado por completo. Era como intentar probar una alarma contra incendios rociando agua sobre una tostadora en lugar de sobre un detector de humo.
La Trampa de "Solo Texto": Otra prueba debía ser una mezcla de imágenes y texto, pero el sistema permitió accidentalmente que la IA ignorara las imágenes y solo leyera el texto. Fue un "fallback de solo texto", lo que significa que la IA nunca tuvo que mirar la imagen para pasar la prueba.
El Glitch del "Parche Aleatorio": Una tercera prueba afirmaba usar un "parche adversarial" especial (una pequeña y truculenta pegatina en una imagen para confundir a la IA). Pero la computadora no generó la pegatina truculenta; simplemente dibujó un rectángulo aleatorio.

Debido a estos errores, los investigadores tuvieron que descartar los resultados de esas tres pruebas. No podían simplemente "arreglar" los números; los datos simplemente no estaban allí. Esto los dejó con solo 4,820 entradas válidas de cuatro pruebas específicas (FigStep, JailBreakV, SALAD-Bench y HarmBench-Simple) para trabajar.

2. La Trampa de las "Palabras Clave"

El experimento original utilizó una forma muy simple de decidir si la IA era segura: buscaba palabras "mágicas" específicas.

Si la IA decía "No puedo hacer eso" o "Lo siento", se marcaba como Segura (un rechazo).
Si la IA decía "Aquí tienes cómo..." o "Claro, puedo ayudar", se marcaba como Insegura (una respuesta dañina).

Los investigadores encontraron un problema enorme con este método. El sistema contaba las respuestas vacías (donde la IA no decía nada en absoluto) como "Seguras" simplemente porque el código heredado no tenía una regla especial para ellas; como la cadena vacía no coincidía ni con la lista de "dañina" ni con la de "rechazo", la lógica por defecto las contaba como seguras. También contaba respuestas que comenzaban con una advertencia cortés pero luego daban las instrucciones peligrosas como "Seguras", porque el sistema solo buscaba la presencia de una frase de rechazo para anular una respuesta dañina, y a veces la lógica se enredaba.

Cuando volvieron a revisar los datos, descubrieron que el método de "palabra clave" era un juez terrible. Era como un profesor calificando un examen mirando solo la palabra "el" e ignorando si el estudiante realmente respondió a la pregunta. En una auditoría de 246 respuestas truculentas, el sistema de palabras clave pasó por alto 13 respuestas dañinas que un juez más inteligente y humano (un "juez de la familia Haiku") identificó correctamente como peligrosas. En términos técnicos, el sistema de palabras clave etiquetó estos 13 casos como "Seguros" cuando en realidad eran "Dañinos" (falsos negativos).

3. El Mito del "Rechazo Masivo"

El estudio original parecía sugerir que los guardias de seguridad estaban causando que la IA rechazara todo (un "rechazo masivo"). Los investigadores re-auditaron 38,500 preguntas seguras y normales para ver con qué frecuencia la IA decía "no" cuando no era necesario.

¿El resultado? La IA era muy educada y servicial.

La tasa estimada de rechazos innecesarios fue de solo 0.52%.
Incluso en el peor de los casos (el grupo de datos más grande), la tasa fue de solo 3.24%.
Los investigadores señalaron que la incertidumbre de "solo muestreo" (el margen de error) podía alcanzar el 10.92%, pero incluso eso está lejos del "rechazo masivo" que el estudio original implicaba.

La confusión provino del "preámbulo defensivo". Los guardias de seguridad a menudo añadían una larga y cortés advertencia al inicio de la respuesta (por ejemplo, "Debo advertirle que esto es peligroso..."). El viejo sistema de palabras clave pensaba que esta advertencia era el rechazo, pero la IA procedía a dar la respuesta de todos modos. Era como un portero diciendo: "No te voy a dejar entrar", pero luego abre la puerta y deja que entres. El sistema de palabras clave etiquetó erróneamente estos preámbulos como rechazos, inflando los números.

4. El Costo de Ser Seguro

Finalmente, los investigadores observaron cuánto tiempo desperdiciaban estos guardias de seguridad.

El guardia "Gaussiano" (que emborrona la imagen cinco veces y vota sobre la respuesta) tardó de 5.45 a 12.76 veces más en procesar una solicitud que si no hiciera nada.
El conjunto completo de tres guardias tardó de 4.36 a 16.59 veces más.

Esto significa que, aunque los guardias podrían estar intentando ayudar, están haciendo que la cocina sea increíblemente lenta.

La Conclusión

Este artículo no nos dice cuál es el mejor guardia de seguridad. De hecho, nos dice que no podemos confiar en las clasificaciones anteriores porque los datos estaban rotos y el método de puntuación era defectuoso.

Lo que descartaron: Demostraron que las afirmaciones originales sobre el "rechazo masivo" eran erróneas y que tres de las siete pruebas de seguridad eran inválidas.
Lo que encontraron: Los guardias de seguridad (específicamente los envoltorios de prompts) sí cambian el comportamiento de la IA, pero el efecto varía enormemente dependiendo del modelo de IA y del tipo de prueba. A veces ayudan, a veces perjudican y a veces simplemente ralentizan las cosas.
La Lección: No puedes simplemente ejecutar una prueba y mirar una puntuación. Necesitas asegurarte de que los ingredientes (entradas) sean reales, que la ficha de puntuación (evaluación) realmente mida la seguridad, y que tengas la receta completa (texto bruto) para revisar el trabajo.

Los autores concluyen que, antes de que podamos comparar diferentes guardias de seguridad, necesitamos construir un sistema mejor y más honesto para probarlos. Hasta entonces, no podemos decir con certeza quién es el héroe y quién es solo alguien que hace que la cocina sea más lenta.

Resumen Técnico: Auditoría de la Evaluación de Defensas en Tiempo de Inferencia para Modelos de Lenguaje de Gran Escala Multimodales

Planteamiento del Problema

Los Modelos de Lenguaje de Gran Escala Multimodales (MLLM) introducen nuevas superficies de ataque a través de canales visuales, incluyendo instrucciones incrustadas en imágenes, divididas entre modalidades o escondidas en perturbaciones del espacio de píxeles. Aunque las defensas en tiempo de inferencia (que modifican entradas, prompts o salidas sin reentrenar los pesos) ofrecen una estrategia de mitigación rentable, su evaluación sufre problemas críticos de integridad. Los autores identifican que los resultados de seguridad comparativos suelen basarse en una procedencia de datos defectuosa: los archivos de resultados pueden no corresponder con las cargas útiles de imagen procesadas realmente, las etiquetas de "seguro" pueden derivarse de cadenas vacías o votos de la canalización en lugar de rechazos semánticos, y los cargadores de benchmarks pueden recurrir silenciosamente a modos de solo texto cuando faltan las imágenes. En consecuencia, las evaluaciones existentes a menudo confunden los artefactos de la canalización con la seguridad semántica, fallando al validar si una defensa realmente previene la generación dañina o simplemente altera el formato de la salida.

Metodología

Los autores realizaron una auditoría trazable de un archivo experimental que cubre dos envoltorios de prompts fijos (inspirados en AdaShield y RapGuard) y un adaptador de perturbación de imagen gaussiana (inspirado en SmoothVLM). El estudio evaluó estos adaptadores en ocho MLLM de las familias InternVL y Qwen-VL.

La metodología consistió en tres fases principales de auditoría:

Auditoría de Procedencia de Entrada y Salida:
El equipo examinó los registros de ejecución y los archivos de entrada de siete benchmarks de seguridad previstos (un total de 9,000 entradas). Verificaron que las cargas útiles de imagen coincidieran con los benchmarks previstos y que el cargador no admitiera fallos de retroceso (fallbacks) a solo texto. Se encontraron tres ramas que fallaron estas comprobaciones:
- MM-SafetyBench: El renderizador local utilizó el campo de carga útil incorrecto.
- JailBreakV-MM: El cargador admitió retrocesos a solo texto para imágenes faltantes.
- Rama de parches adversarios (Adversarial-patch): El ejecutor generó rectángulos aleatorios en lugar de parches adversarios optimizados.
  Estas ramas fueron puestas en cuarentena, dejando cuatro corpora (FigStep, JailBreakV, SALAD-Bench, HarmBench-Simple) con 4,820 entradas por configuración para el análisis.
Reevaluación Semántica y de Palabras Clave:
Los puntajes de seguridad originales dependían de un clasificador de palabras clave heredado ( $C_{kw}$ ) que contaba las cadenas vacías como "seguras" y utilizaba un voto de mayoría para los adaptadores gaussianos. Los autores re-auditaron 274 respuestas adversarias utilizando un protocolo separado de juez basado en LLM. Encontraron que la regla de palabras clave tenía una alta tasa de falsos negativos (13 de 246 respuestas comparables) y que las etiquetas "seguras" a menudo ocultaban preámbulos defensivos o salidas vacías.
Auditoría de Rechazo Benigno:
Para medir el sobre-rechazo (falsos positivos en consultas benignas), los autores analizaron 38,500 salidas almacenadas de consultas benignas derivadas de MMBench. Emplearon un juez de LLM dedicado para distinguir entre rechazos directos del sistema, preámbulos defensivos seguidos de respuestas y rechazos reales. Calcularon las tasas de rechazo agrupadas y los intervalos de muestreo, excluyendo explícitamente la interpretación de "rechazo masivo" derivada del protocolo de palabras clave heredado.

Contribuciones Clave

El artículo realiza cuatro contribuciones específicas:

Marco de Auditoría Trazable: Un método para distinguir entre los benchmarks previstos, las cargas útiles reales, el texto devuelto, los proxies de la canalización y los juicios semánticos.
Análisis Comparativo Restringido: Una reevaluación de los envoltorios de prompts (Ada, Rap) y su combinación (A+R) contra un adaptador gaussiano (Smooth) en los corpora retenidos (FigStep, JailBreakV, SALAD-Bench, HarmBench-Simple).
Reestimación del Rechazo Benigno: Una estimación corregida de la tasa de rechazo basada en 38,500 salidas, demostrando que el protocolo de palabras clave heredado sobreestimó significativamente las tasas de rechazo debido a la contaminación por preámbulos defensivos.
Medición del Costo Operacional: Cuantificación del tiempo de procesamiento por lote y la frecuencia de emisión de preámbulos defensivos, separando estos costos de la precisión de la tarea no medida.

Resultados

Integridad de Datos: Tres de las siete ramas de benchmarks previstas fueron invalidadas debido a fallos de procedencia de entrada. Los resultados restantes son agregados descriptivos de un protocolo de palabras clave heredado, no tasas de inocuidad validadas semánticamente.
Puntajes de Seguridad: Los puntajes de palabras clave heredados no mostraron un orden uniforme entre modelos o adaptadores. Por ejemplo, en el modelo 8B InternVL3.5, el puntaje varió de 0.882 (sin adaptador) a 1.000 (envoltorio Rap), pero la auditoría semántica no pudo validar estos como mejoras de seguridad genuinas.
Discrepancia entre Palabras Clave y Semántica: En una búsqueda no aleatoria de 246 respuestas adversarias, la regla de palabras clave omitió 13 casos dañinos (falsos negativos) que un juez semántico identificó. La precisión fue del 41.7% y la recuperación (recall) del 69.8% en esta muestra.
Rechazo Benigno: La estimación puntual del punto de rechazo agrupado para consultas benignas fue de 0.52%, con la celda estimable más grande en 3.24%. Esto contradice la interpretación de "rechazo masivo" original. El protocolo de palabras clave había inflado esta tasa aproximadamente 54 veces porque contaba los preámbulos defensivos (emitidos por el envoltorio Rap en el 20–78% de las salidas) como rechazos.
Costos Operacionales: El adaptador gaussiano aumentó el tiempo de procesamiento de 5.45 a 12.76 veces, y el stack completo de tres adaptadores lo aumentó de 4.36 a 16.59 veces.

Significancia y Reivindicaciones

Los autores declaran explícitamente que este trabajo no pretende que una defensa o un enrutador adaptativo sea universalmente superior. En cambio, la significancia radica en:

Corrección Metodológica: Resaltar que las evaluaciones de seguridad requieren manifiestos inmutables que vinculen las cargas útiles con los resultados, la preservación del texto visible para el usuario separado de los votos de la canalización, y evaluadores que midan el constructo pretendido (seguridad semántica frente a coincidencia de palabras clave).
Evidencia de Variabilidad: Los datos muestran que el rendimiento de la defensa depende altamente del modelo y el corpus específicos, lo que justifica el perfilado de las canalizaciones candidatas sobre el tráfico objetivo antes del despliegue.
Requisitos de Procedencia: El artículo establece un conjunto de requisitos de procedencia para futuras evaluaciones de defensa de MLLM, argumentando que sin estas puertas (entradas válidas, respuestas puras almacenadas, juicio semántico), los rankings comparativos son inválidos.

El artículo concluye que los datos archivados no respaldan la interpretación anterior de rechazo masivo ni un ranking definitivo de las defensas. Hace un llamado para que las evaluaciones futuras utilicen manifiestos versionados y juicios semánticos independientes más densos antes de comparar canalizaciones de defensa fijas y adaptativas.