Safe responses matter: Output-aware safety guardrail mitigate over-refusal in MLLMs

Resumen Técnico: OutGuard – Salvaguarda de Seguridad Consciente de la Salida para MLLMs

1. Declaración del Problema: El Compromiso entre Seguridad y Utilidad (Over-Refusal Trade-off)

Los mecanismos de seguridad existentes para los Modelos de Lenguaje de Gran Escala Multimodales (MLLMs) enfrentan un compromiso crítico entre la seguridad y la utilidad. Si bien el ajuste fino (fine-tuning) del modelo ofrece una seguridad robusta, a menudo compromete la utilidad general. Por el contrario, las salvaguardas de seguridad en el lado de la entrada (input-side) proporcionan una alternativa ligera y no intrusiva, pero sufren de una severa sobre-negativa (over-refusal).

Las salvaguardas actuales operan bajo un paradigma consciente de la entrada (input-aware), tomando decisiones de seguridad basadas únicamente en el análisis de pares de imagen-texto de entrada. Este enfoque no tiene en cuenta las capacidades de seguridad intrínsecas del modelo. Como se demuestra en el artículo, los MLLMs suelen poseer mecanismos de alineación interna que pueden transformar entradas dañinas en salidas seguras (por ejemplo, respuestas de tipo negativa, amonestaciones o advertencias). Sin embargo, las salvaguardas conscientes de la entrada bloquean indiscriminadamente estas interacciones una vez que la entrada es marcada como riesgosa, independientemente de si el modelo habría generado una respuesta inofensiva. Esto conduce al rechazo de consultas benignas que simplemente parecen riesgosas (por ejemplo, "¿Cómo matar un proceso de Python?" o "¿Dónde puedo disparar una buena foto?"), degradando significativamente la experiencia del usuario y limitando su utilidad práctica.

2. Metodología: El Marco de Trabajo OutGuard

Para abordar esto, los autores proponen OutGuard, un cambio de paradigma de una salvaguarda consciente de la entrada a una consciente de la salida (output-aware). OutGuard opera dentro del espacio de estados ocultos del modelo para predecir la seguridad de la generación venidera antes de que se produzca por completo, en lugar de juzgar solo el riesgo de la entrada.

Componentes Principales:

• Utilización de Estados Ocultos: OutGuard extrae representaciones de estados ocultos ($H_l$) del backbone del LLM durante la etapa de inferencia (Etapa S4 en el flujo de datos). Estos estados vinculan la dinámica interna del modelo con la salida final.
• Clasificador de Aprendizaje Contrastivo de Múltiples Instancias (MICL):
  • Formulación del Problema: La tarea de detección se enmarca como un problema de Aprendizaje de Múltiples Instancias (MIL). Una secuencia de estados ocultos para una salida generada se trata como una "bolsa" (bag), donde las representaciones de los tokens individuales son "instancias". La etiqueta a nivel de bolsa (Seguro/Inseguro) es conocida, pero la peligrosidad a nivel de token es latente.
  • Arquitectura: El clasificador MICL emplea un mecanismo de atención con compuerta (gated attention mechanism) para agregar representaciones a nivel de token en una representación a nivel de bolsa ($z_l$). Este mecanismo aprende a enfocarse en instancias de alta atención (probablemente tokens dañinos) mientras suprime el ruido.
  • Objetivo de Entrenamiento: El clasificador se entrena utilizando una función de pérdida compuesta:
    1. Pérdida de Entropía Cruzada Binaria ($L_{cls}$): Para la clasificación a nivel de bolsa.
    2. Regularización de Entropía ($L_{ent}$): Para fomentar la dispersión (sparsity) en los pesos de atención, obligando al modelo a enfocarse en tokens salientes específicos.
    3. Pérdida Contrastiva Intra-bolsa ($L_{con}$): Una pérdida de tipo InfoNCE que maximiza la similitud entre las instancias de alta atención (positivas) y minimiza la similitud con las instancias de baja atención (negativas) dentro de la misma bolsa.
• Selección de Capas y Votación:
  • Se utiliza una métrica de Safety-Score para evaluar el rendimiento de los clasificadores MICL entrenados en diferentes capas.
  • Solo se seleccionan los clasificadores de las capas con un Safety-Score > 0.9.
  • Durante la inferencia, los clasificadores seleccionados votan sobre la seguridad de los estados ocultos. Un voto por mayoría determina la decisión final (Seguro vs. Inseguro).

Flujo de Trabajo Operativo:
OutGuard se ejecuta como un módulo independiente junto al MLLM. Realiza la detección de seguridad en una sola pasada durante la inferencia, analizando los estados ocultos a medida que se generan. Si el sistema predice una salida insegura, interviene; de lo contrario, la generación continúa. Esto evita la necesidad de consultas adicionales o una sobrecarga de latencia significativa.

3. Contribuciones Clave

1. Cambio de Paradigma: El artículo identifica la causa raíz de la sobre-negativa como la dependencia de los paradigmas conscientes de la entrada y propone un cambio hacia la evaluación de seguridad consciente de la salida.
2. Marco de Trabajo OutGuard: Un marco novedoso que utiliza representaciones de estados ocultos y un clasificador de Aprendizaje Contrastivo de Múltiples Instancias (MICL) para evaluar directamente la seguridad de la salida, distinguiendo entre entradas que conducen a salidas dañinas y aquellas que el modelo neutraliza internamente.
3. Validación Empírica: Experimentos extensos demuestran que OutGuard reduce significativamente las tasas de sobre-negativa manteniendo un fuerte rendimiento de detección contra contenido dañino y ataques de jailbreak.

4. Resultados Experimentales

Los autores evaluaron OutGuard en LLaVA 1.6 y Qwen 3.5 utilizando conjuntos de datos que incluyen GQA, AdvBench, SafeBench, MM-Vet, MM-SafetyBench y XSTest. Los modelos de referencia (baselines) incluyeron HiddenDetector, QGuard, LoD y ProGuard.

• Equilibrio entre Seguridad y Utilidad: OutGuard logró un rendimiento superior en todas las métricas. En el conjunto de prueba, mantuvo una baja tasa de Respuesta Insegura ante Prompts Inseguros (URUP < 0.1) mientras reducía drásticamente la tasa de Respuesta de Abstención ante Prompts Seguros (ARSP < 0.1). Por ejemplo, en LLaVA, OutGuard logró un F1-Score de 0.9335 y un ARSP de 0.0749, superando al siguiente mejor método (LoD-PP) que tenía un ARSP de 0.1124.
• Mitigación de la Sobre-negativa: En el conjunto de datos XSTest (consultas benignas que parecen dañinas), OutGuard redujo significativamente las tasas de sobre-negativa en comparación con los baselines (por ejemplo, 0.5840 frente a 0.7400 para LLaVA).
• Robustez: OutGuard demostró una fuerte robustez contra ataques de jailbreak (Visual-Adversarial-Examples, HADES, JOOD), logrando métricas de clasificación casi perfectas (AUPRC/AUROC > 0.97) manteniendo la sobre-negativa baja.
• Eficiencia: El método introduce una latencia mínima. El tiempo de decisión promedio por muestra fue de 0.208 segundos, comparable o más rápido que muchos baselines (por ejemplo, QGuard en 3.154s) y significativamente más rápido que los métodos post-salida.
• Estudios de Ablación: Eliminar componentes clave (módulo de compuerta, aprendizaje contrastivo o regularización de dispersión) provocó una degradación severa en la capacidad de detección, confirmando la necesidad de la arquitectura MICL.

5. Significado y Reivindicaciones

El artículo afirma que OutGuard proporciona una solución práctica al compromiso entre seguridad y utilidad en los MLLMs. Al desplazar el enfoque del riesgo de la entrada hacia el daño real de la salida, el método preserva las capacidades de seguridad integradas y la utilidad general del modelo. Los autores enfatizan que su enfoque permite una intervención precisa solo cuando la respuesta real del modelo sería dañina, evitando así el bloqueo innecesario de interacciones benignas.

El trabajo destaca la importancia de los mecanismos de seguridad conscientes de la salida y demuestra que los clasificadores ligeros entrenados en estados ocultos pueden mitigar eficazmente la sobre-negativa sin comprometer la detección de amenazas reales ni requerir el reentrenamiento del modelo. El código se ha puesto a disposición para facilitar más investigaciones en esta dirección.