🤖 machine learning

Risk Under Pressure: Compute-Aware Evaluation of Adversarial Robustness in Language Models

Este artículo propone un marco de evaluación consciente del cómputo que mide el riesgo adversarial utilizando FLOPs acumulados en lugar de presupuestos de consultas fijos, revelando que el entrenamiento de alineación y el escalado de modelos tienen efectos no monotónicos y dependientes de la categoría sobre el esfuerzo computacional requerido para realizar un jailbreak en modelos de lenguaje de gran tamaño.

Autores originales: Malikeh Ehghaghi, Boglárka Ecsedi, Marsha Chechik, Colin Raffel

Publicado 2026-06-11

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Malikeh Ehghaghi, Boglárka Ecsedi, Marsha Chechik, Colin Raffel

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

La gran idea: No se trata solo de si puedes entrar, sino de cuánto cuesta

Imagina que eres dueño de una caja fuerte de alta seguridad. Una empresa de seguridad viene a probarla. Informan: "Logramos entrar en la caja fuerte el 100% de las veces".

En el mundo de los Modelos de Lenguaje Extensos (LLM), eso suele ser el fin de la historia. Los investigadores dicen: "El modelo es inseguro porque un atacante tuvo éxito".

Pero este artículo argumenta que eso es como decir que un banco es inseguro solo porque un ladrón eventualmente entró, sin preguntar qué tanto esfuerzo tuvo que hacer.

Escenario A: El ladrón abre la cerradura en 5 segundos con un clip.
Escenario B: El ladrón pasa 10 días, usa un cortador láser y contrata a un equipo de ingenieros para perforar el concreto.

Ambos escenarios resultan en una caja fuerte "vulnerada". Pero el Escenario B es mucho menos probable que ocurra en el mundo real porque es demasiado costoso y difícil.

Este artículo introduce una nueva forma de medir la seguridad llamada "Riesgo bajo presión" (Risk Under Pressure). En lugar de solo contar cuántas veces falló una IA, mide cuánta potencia de cómputo (esfuerzo) tuvo que emplear un atacante para lograr que la IA dijera algo malo.

Las nuevas herramientas: Midiendo el "sudor de la computadora"

Los autores crearon un marco de trabajo que trata la potencia de procesamiento de la computadora como un presupuesto. Miden el "sudor" que un atacante tiene que ejercer usando FLOPs (operaciones de punto flotante), que es básicamente un recuento de cuántos cálculos matemáticos tuvo que realizar la computadora.

Utilizan dos herramientas principales para visualizar esto:

La "Curva de Riesgo-Cómputo" (La colina): Imagina una colina. La base es "fácil de romper" y la cima es "difícil de romper".
- Algunos modelos son como una colina pequeña; puedes subir a la cima (romper la seguridad) con unos pocos pasos.
- Otros modelos son como el Monte Everest; tienes que gastar una cantidad masiva de energía solo para llegar a la mitad.
El "Precio" (C@τ): Esto responde a: "¿Cuánta potencia de cómputo se necesita para romper este modelo el 50% de las veces?".
- Si el precio es bajo, el modelo es vulnerable.
- Si el precio es enorme, el modelo es robusto, incluso si teóricamente puede ser roto.

Lo que descubrieron: Los resultados sorprendentes

Los investigadores probaron muchos modelos de IA diferentes y métodos de ataque. Esto es lo que encontraron, traducido a términos cotidianos:

1. El entrenamiento no siempre hace las cosas más seguras (La trampa del "Sobre-entrenamiento")

Podrías pensar que cuanto más entrenas a una IA para que sea segura, más segura se vuelve. El artículo encontró que esto no siempre es cierto.

La analogía: Imagina enseñarle a un niño a decir "no" a los extraños.
- Etapa 1 (Base): El niño dice "sí" a todo.
- Etapa 2 (SFT): Le enseñas a ser educado. Se vuelve muy bueno diciendo "no".
- Etapa 3 (DPO/RL): Intentas perfeccionarlo aún más con recompensas. Sorprendentemente, a veces se vuelven peores al decir "no" ante preguntas truculentas.
El hallazgo: A veces, la versión "intermedia" del modelo era en realidad la más difícil de romper. Las versiones finales, más "alineadas", a veces se volvieron más fáciles de engañar, o al menos no se volvieron mucho más difíciles de romper.

2. Los modelos más grandes no siempre son más seguros (El problema del "Gran Objetivo")

Hacer un modelo más grande (con más parámetros) es como construir un castillo más grande.

El hallazgo: Si el atacante utiliza un método "inteligente" (como un ataque de gradiente que calcula la ruta perfecta), un castillo más grande es mucho más difícil de romper. Es como intentar escalar una torre de 100 pisos frente a una casa de 1 piso.
El detalle: Si el atacante utiliza un método "torpe" (como probar plantillas aleatorias o copiar y pegar prompts malos), el tamaño del castillo no importa. Aún pueden entrar con la misma facilidad.
Conclusión: Los modelos más grandes detienen a los hackers "inteligentes", pero no detienen a los hackers "perezosos".

3. El truco del "Sustituto" (Robando las llaves)

Los atacantes a menudo no tienen acceso al modelo de código cerrado y secreto que quieren hackear.

La analogía: Imagina que quieres entrar en un banco específico, pero no puedes acercarte a él. Así que vas a un banco similar en la calle de al lado, abres su cerradura y encuentras una llave maestra que funciona en ambos bancos.
El hallazgo: Los investigadores demostraron que los atacantes pueden entrenar sus herramientas de "abrir cerraduras" en un modelo de IA pequeño y gratuito (de código abierto). Una vez que descubren el truco, pueden usar ese mismo truco en un modelo de IA gigante, caro y cerrado. Esto le ahorra al atacante una cantidad masosa de dinero y esfuerzo.

4. La seguridad es desigual (El efecto "Queso Suizo")

Incluso un modelo que parece generalmente seguro tiene agujeros.

El hallazgo: Puede que tome mucho esfuerzo hacer que una IA hable sobre "bullying", pero podría tomar muy poco esfuerzo hacer que hable sobre "cibercrimen" o "drogas ilegales".
La analogía: Imagina una fortaleza con un muro de piedra grueso en el lado norte (difícil de romper) pero una puerta de madera endeble en el lado sur (fácil de romper). Si solo mides el grosor promedio de las paredes, crees que la fortaleza es segura. Pero un atacante inteligente simplemente pasará por la puerta de madera.

Por qué esto es importante

El artículo argumenta que debemos dejar de preguntar simplemente "¿Se rompió la IA?" y empezar a preguntar "¿Cuánto costó romperla?".

Si una IA requiere una supercomputadora funcionando durante una semana para ser engañada, es efectivamente segura para la mayoría de las personas. Si toma 5 segundos, es un desastre. Al medir el "costo" del ataque, obtenemos una imagen mucho más clara de la seguridad en el mundo real.

En resumen: El artículo dice que debemos dejar de mirar el marcador de la "Tasa de Éxito" y empezar a mirar el marcador del "Esfuerzo Requerido" para entender verdaderamente qué tan seguros son nuestros modelos de IA.

Resumen Técnico: Riesgo bajo Presión: Evaluación de la Robustez Adversaria de Conciencia Computacional en Modelos de Lenguaje

Planteamiento del Problema

Las evaluaciones actuales de la robustez adversaria para los Modelos de Lenguaje de Gran Escala (LLMs) dependen predominantemente de la Tasa de Éxito del Ataque (ASR, por sus siglas en inglés) medida bajo presupuestos de consultas fijos. Este enfoque trata implícitamente todos los pasos de un ataque como si tuvieran un costo igual, ignorando el hecho de que diferentes estrategias de ataque (por ejemplo, optimización basada en gradientes frente a prompting basado en plantillas) incurren en gastos computacionales que pueden variar en órdenes de magnitud. En consecuencia, un modelo que requiere 100 consultas de un ataque de plantilla barato para fallar se califica de forma idéntica a un modelo que falla inmediatamente, ocultando el verdadero "factor de trabajo" o el esfuerzo adversario requerido para vulnerar el sistema. Esta limitación dificulta determinar si el costo computacional de un ataque justifica su beneficio para un adversario y hace que sea difícil comparar modelos bajo un gasto de atacante igual.

Metodología

Los autores proponen un marco de evaluación de conciencia computacional que reemplaza el recuento de consultas por la presión computacional, medida en operaciones de punto flotante acumuladas (FLOPs), como un proxy del esfuerzo adversario.

Marco Central

Refinamiento Iterativo Presupuestado: Los ataques se modelan como procesos iterativos donde una política de ataque $\pi$ propone prompts, un modelo objetivo $M$ genera respuestas y un juez de seguridad $E$ evalúa los resultados. Este bucle continúa hasta que se encuentra un éxito o se agota un presupuesto de consultas $\lambda$ .
Contabilidad de FLOPs: El marco calcula los FLOPs acumulados para cada paso, incluyendo:
- Pasadas hacia adelante (forward passes) a través del modelo objetivo (generación y evaluación).
- Pasadas hacia atrás (backward passes) para ataques basados en gradientes (caja blanca).
- Pasadas hacia adelante a través de modelos atacantes auxiliares (refinamiento de caja negra).
- Pasadas hacia adelante a través del juez de seguridad.
- Los costos se derivan de aproximaciones estándar de FLOPs para transformers ( $C_{fwd} \approx 2NL$ ), asegurando la comparabilidad agnóstica al hardware.
Curvas de Riesgo-Computación: En lugar de un único punto de ASR, el marco genera curvas que mapean los FLOPs acumulados (eje x) frente al riesgo empírico (eje y).
Métricas de Resumen:
- C@ $\tau$ (Computación para el riesgo $\tau$ ): Los FLOPs acumulados promedio requeridos para que un ataque alcance por primera vez un umbral de riesgo específico (por ejemplo, 50%). Valores más altos indican mayor robustez.
- Eficiencia Promedio (AE): El riesgo esperado normalizado por FLOP ( $CAURC / \bar{C}_{max}$ ). Valores más bajos indican que un modelo es más difícil de explotar por unidad de cómputo.

Configuración Experimental

El marco se aplicó a través de:

Modelos: Diez modelos que abarcan tres familias (Tulu3, Qwen2.5, Qwen3) y varios estadios de entrenamiento (Base, SFT, DPO, RLVR, SafeRL).
Ataques: Tres estrategias distintas:
- JailBroken: Basado en plantillas (ofuscación aleatoria).
- PAIR: Refinamiento iterativo de caja negra utilizando un LLM atacante.
- GCG: Optimización de gradiente de coordenadas basada en gradientes de caja blanca.
Benchmarks: HarmBench (200 comportamientos) y JailbreakBench (100 comportamientos).

Resultados Clave

El análisis de conciencia computacional reveló patrones invisibles para las métricas estándar de ASR:

Efectos No Monotónicos del Alineamiento: El entrenamiento de alineación no aumenta la robustez de forma lineal. En la familia Tulu3, el estadio de Ajuste Fino Supervisado (SFT) exhibió a menudo la mayor robustez (por ejemplo, GCG y PAIR no lograron alcanzar el 50% de riesgo dentro del presupuesto). El alineamiento posterior mediante Optimización de Preferencia Directa (DPO) y Aprendizaje por Refuerzo con Recompensas Verificables (RLVR) a menudo redujo la robustez, particularmente contra ataques basados en plantillas, a pesar de presentar un ASR más alto en algunos casos.
Beneficios de Escalamiento Asimétricos: Aumentar el tamaño del modelo (por ejemplo, de Qwen2.5 0.5B a 7B) incrementó significativamente el costo computacional para ataques basados en gradientes (un aumento de 20 $\times$ en C@0.5) pero ofreció una protección mínima contra ataques de plantillas baratos (solo un aumento de 2.8 $\times$ ). Las métricas estándar de ASR enmascararon esta disparidad, mostrando tasas de éxito similares entre escalas.
Transferencia de Ataque Sustituto: Los ataques basados en gradientes (GCG) optimizados en un modelo sustituto pequeño de pesos abiertos (Qwen2.5-0.5B) se transfirieron con éxito a un objetivo más grande de pesos cerrados (Qwen3-8B) a una fracción del costo original. Aunque la transferencia no siempre alcanzó regímenes de alto riesgo, demostró que los atacantes pueden reducir costos optimizando en sustitutos.
Heterogeneidad entre Categorías de Daño: Dentro de un mismo modelo, el costo computacional para vulnerar la seguridad varió hasta $\approx 5\times$ entre diferentes categorías de daño (por ejemplo, acoso frente a cibercrimen). El RL de seguridad alineada aumentó los costos agregados pero dejó ciertas categorías (por ejemplo, cibercrimen, actividades ilegales) desproporcionadamente accesibles o incluso más eficientemente explotables (mayor AE) que el modelo base.
Compromisos de Seguridad-RL: Si bien el Safety-RL generalmente elevó el costo adversario agregado, introdujo vulnerabilidades específicas. Por ejemplo, bajo GCG, el modelo SafeRL fue estrictamente menos robusto que su contraparte base, lo que sugiere un desajuste entre la distribución de los prompts de entrenamiento de RL y las secuencias de tokens descubiertas por la optimización de gradientes.

Significancia y Reivindicaciones

El artículo argumenta que la robustez es una función del costo computacional, no solo de la posibilidad. Al adoptar una perspectiva de "factor de trabajo" centrada en la seguridad, los autores afirman:

Relevancia Operacional: Una vulnerabilidad solo es operativamente relevante si es explotable dentro de un presupuesto realista del adversario. Elevar el piso del costo computacional puede ser tan efectivo como reducir las tasas de éxito.
Limitaciones de las Métricas Estáticas: Los puntajes de ASR estándar bajo presupuestos de consultas fijos sobreestiman sistemáticamente la robustez al ignorar la eficiencia variable de las diferentes clases de ataque y los efectos no lineales del escalamiento y el alineamiento de los modelos.
Comparación Unificada: El marco propuesto permite comparaciones justas entre diversas estrategias de ataque (caja blanca vs. caja negra) y configuraciones de modelos al normalizarlas frente a un eje de cómputo compartido.
Evaluación de Seguridad Matizada: El ajuste de seguridad no es una mejora monolítica; crea paisajes de protección desiguales donde algunas categorías se vuelven significativamente más difíciles de vulnerar mientras otras permanecen vulnerables o se vuelven más eficientes de atacar.

Los autores concluyen que la evaluación adversaria consciente del costo es necesaria para calibrar con precisión el riesgo real del despliegue de LLMs, ya que los modelos que parecen robustos bajo métricas de recuento de consultas pueden fallar catastróficamente cuando se evalúan bajo presión de conciencia computacional.