Resumen Técnico: Fair ASR: Reevaluación de los Jailbreaks de Caja Negra bajo Presupuestos Compartidos de Llamadas al Objetivo

1. Planteamiento del Problema

Las evaluaciones actuales de los ataques de jailbreak contra modelos de lenguaje de gran tamaño (LLM) dependen principalmente de la Tasa de Éxito del Ataque (ASR), pero frecuentemente no tienen en cuenta el presupuesto de ataque requerido para lograr dicho éxito. Los estudios existentes suelen reportar valores de ASR terminales obtenidos bajo restricciones de recursos desiguales, lo que conduce a comparaciones injustas donde la efectividad de un método se confunde con la cantidad de acceso al modelo objetivo que utiliza.

Si bien evaluaciones recientes "conscientes del cómputo" intentan normalizar los presupuestos agregando recursos en un escalar unificado (por ejemplo, FLOPs), este enfoque tiene limitaciones significativas para escenarios de caja negra:

1. Invisibilidad: Los FLOPs de inferencia para modelos de código cerrado son generalmente desconocidos y deben estimarse.
2. No intercambiabilidad: Los FLOPs colapsan distintas restricciones de recursos (por ejemplo, límites de tasa de API frente a costos computacionales) en una única métrica, oscureciendo las realidades operativas donde el acceso al modelo objetivo es el cuello de botella principal debido a los límites de tasa y la detección de abusos.

Consecuentemente, existe una falta de base comparable y observable para evaluar ataques de caja negra heterogéneos.

2. Metodología: Protocolo Fair-ASR

Para abordar estos problemas, los autores introducen Fair-ASR, un protocolo de evaluación que estandariza las comparaciones bajo presupuestos compartidos de llamadas al objetivo ($B$).

Principios Fundamentales

• Presupuesto Primario ($B$): El protocolo utiliza el número de llamadas al objetivo (consultas al modelo víctima) como el presupuesto primario. Esto se elige porque:
  • Es universal para todos los ataques de caja negra (todo ataque debe consultar al objetivo).
  • Refleja las restricciones operativas (límites de tasa, suspensiones de cuenta).
  • Es directamente observable, a diferencia de los FLOPs para APIs cerradas.
• Métrica Secundaria: Las llamadas del atacante (consultas a un LLM atacante o a un juez auxiliar) se rastrean por separado para analizar las compensaciones de eficiencia, en lugar de colapsarse en el presupuesto primario.
• Métricas de Evaluación:
  • ASR@B: La fracción de solicitudes dañinas atacadas con éxito dentro de un máximo de $B$ llamadas al objetivo.
  • Curva de ASR-Presupuesto: La trayectoria del ASR a medida que $B$ aumenta, revelando tasas de crecimiento y puntos de saturación.
  • Llamadas al Objetivo Promedio (ATC): El promedio de llamadas al objetivo consumidas por cada ataque exitoso.
  • Puntuación de Dañosidad (HS): Una métrica de calidad (utilizando la rúbrica StrongREJECT) que evalúa la severidad y la capacidad de convicción de la respuesta dañina.

Alcance Experimental

Los autores reevaluaron 11 ataques representativos a través de tres categorías:

1. Plantillas hechas a mano: CodeAttack, DeepInception, CipherChat.
2. Muestreo repetido estocástico: Best-of-N (BoN).
3. Ataques automatizados impulsados por LLM: PAIR, TAP, ReNeLLM, AutoDAN, GPTFuzzer, AutoDAN-Turbo, Rainbow Teaming.

Los experimentos se realizaron en diversos modelos objetivo (Llama-3.1, gpt-oss, GPT-4o, GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6) utilizando conjuntos de datos estándar (HarmBench, JailbreakBench).

3. Hallazgos Clave de la Reevaluación

La aplicación de Fair-ASR reveló tres ideas críticas:

1. Rankings Dependientes del Presupuesto: Los rankings de los ataques son altamente sensibles al presupuesto de llamadas al objetivo. Los métodos que parecen superiores bajo presupuestos grandes pueden ser superados por métodos más simples bajo presupuestos ajustados. Por ejemplo, en Llama-3.1-8B, TAP lidera a BoN en $B=5$, pero BoN supera a TAP en $B=100$.
2. Competitividad de las Primitivas Simples: Las primitivas de ataque simples siguen siendo altamente competitivas bajo un acceso igualitario al objetivo.
   • Perturbación Estocástica: BoN continúa mejorando con llamadas adicionales al objetivo, logrando un alto ASR sin ninguna llamada al modelo atacante.
   • Plantillas Hechas a Mano: Las plantillas estructuradas (ej. CodeAttack) logran altas tasas de éxito con muy pocas llamadas al objetivo (ej. 62% ASR en $B=1$), superando a menudo a los métodos complejos impulsados por LLM en regímenes de bajo presupuesto.
3. Compensaciones de Eficiencia: Ningún método impulsado por LLM evaluado es uniformemente eficiente tanto en llamadas al objetivo como al atacante.
   • ReNeLLM logra una alta eficiencia de llamadas al objetivo (bajo ATC) pero incurre en altos costos de llamadas al atacante debido a la reescritura iterativa y las compuertas de dañosidad basadas solo en prompts.
   • Otros métodos (ej. PAIR, TAP) pueden usar menos llamadas al atacante pero requieren significativamente más llamadas al objetivo para alcanzar umbrales de éxito similares.

4. Solución Propuesta: ReCode

Motivados por la identificada "brecha de eficiencia bidimensional", los autores proponen ReCode, un ataque composicional diseñado para maximizar el ASR minimizando tanto las llamadas al objetivo como las al atacante.

Arquitectura de Diseño

ReCode combina tres componentes en un flujo de trabajo de una sola pasada:

1. Reescritura de Desensibilización Libre de Compuertas: A diferencia de ReNeLLM, que utiliza una compuerta de dañosidad basada solo en prompts para filtrar reescrituras (lo que provoca reintentos costosos), ReCode realiza una reescritura de una sola pasada utilizando estrategias de desensibilización (ej. reescritura literaria, sustitución objetiva) sin un bucle de juez auxiliar.
2. Perturbación Estocástica Libre de Atacante: El prompt reescrito se somete a perturbaciones a nivel de carácter (ej. inversión de mayúsculas/minúsculas, inserción de ASCII) similares a BoN, requiriendo cero llamadas adicionales al atacante.
3. Anidamiento Estructurado Estilo Código: El prompt perturbado se incrusta en una plantilla estructurada de estilo código (ej. definiciones de clases en Python), ocultando aún más la intención sin requerir el refinamiento de un modelo atacante.

Resultados

Evaluado bajo un presupuesto de $B=20$ llamadas al objetivo:

• Desempeño: ReCode logró un ASR promedio del 81.0% en cinco modelos objetivo (incluyendo variantes de gpt-oss) y del 70.3% en los tres modelos de frontera de código cerrado (GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6).
• Eficiencia: Requirió un promedio de solo 7.00 llamadas al atacante por solicitud (AAC), significativamente menor que ReNeLLM (18.69) y TAP (49.56).
• Ganancias Específicas: En GPT-5, ReCode mejoró el ASR del 31% (ReNeLLM) al 85% mientras reducía las llamadas al atacante de 26.02 a 7.19.
• Dañosidad: ReCode también alcanzó la mayor Puntuación de Dañosidad (HS) promedio de 0.662, indicando que las tasas de éxito más altas se correlacionaban con respuestas dañinas de mayor calidad.

5. Significado y Reivindicaciones

El artículo sostiene que Fair-ASR proporciona una línea base necesaria y observable para comparar los jailbreaks de caja negra, corrigiendo conclusiones erróneas derivadas de comparaciones con presupuestos desiguales. Demuestra que la complejidad algorítmica no garantiza la eficiencia y que las primitivas simples y de bajo costo suelen estar subutilizadas.

La introducción de ReCode sirve como una prueba de concepto de que cerrar la brecha de eficiencia es posible combinando la reescritura de desensibilización con técnicas de ofuscación libres de atacante. Los autores concluyen que las evaluaciones futuras deben ir más allá del ASR terminal para considerar la eficiencia de recursos conjunta (llamadas al objetivo y al atacante) para evaluar con precisión el panorama de seguridad de los LLM.

Limitaciones Notadas:

• El protocolo se centra actualmente en ataques de un solo turno y aún no cubre entornos de múltiples turnos.
• Las llamadas al objetivo no capturan el uso de tokens, los precios de la API o el costo manual del desarrollo de plantillas.
• El estudio reconoce que, aunque ReCode es eficiente, los comportamientos específicos de ciertos modelos (ej. la sensibilidad de Claude al anidamiento de código) pueden variar, lo que requiere mayor investigación.