Resumen Técnico: AdversaBench

Planteamiento del Problema

Escalar la evaluación adversarial de los Modelos de Lenguaje Extensos (LLMs) presenta un desafío dual: generar entradas difíciles y confirmar de manera fiable que los fallos resultantes son genuinos. Aunque un único juez automatizado es rápido, carece de la capacidad para detectar su propia lenidad o resolver casos dudosos. Además, las métricas estándar de acuerdo entre anotadores, como la $\kappa$ de Cohen, pueden ser engañosas en entornos adversariales donde las tasas de fallo son altas (distribuciones sesgadas), lo que puede enmascarar desacuerdos sustantivos en casos difíciles. El red-teaming actual suele depender de un prompting ingenuo o de una verificación de juez único, lo cual no logra capturar la sutileza de las violaciones de instrucciones, los errores de razonamiento o el uso indebido de herramientas a escala.

Metodología

AdversaBench es un pipeline de red-teaming automatizado y un estudio de fiabilidad diseñado para abordar estas brechas. El sistema opera en un bucle que involucra a un atacante, un modelo objetivo y un panel de múltiples jueces.

Arquitectura del Sistema

• Pipeline: Construido utilizando LangGraph para la orquestación y LangChain para las llamadas al modelo, el sistema admite la reanudación de puntos de control (checkpoints) y un manejo robusto de los límites de tasa de la API.
• Modelo Objetivo: Llama 3.1 8B Instant (seleccionado intencionalmente como un objetivo débil para estresar las métricas de evaluación y asegurar una alta prevalencia de fallos).
• Atacante: Principalmente Llama 3.3 70B, escalando a GPT-4o-mini a partir de la iteración 2 si un fallo aún no ha sido confirmado.
• Jueces: Un panel de tres modelos (Llama 3.3 70B, Cerebras GPT-OSS 120B y Qwen3 32B) vota sobre si una respuesta viola una especificación de verdad fundamental (ground-truth). El consenso unánime guarda el resultado; los empates se resuelven mediante un meta-juez GPT-4o-mini.

Construcción de Semillas y Mutación

El estudio utilizó 45 prompts semilla a través de tres categorías: Razonamiento (15), Seguimiento de Instrucciones (15) y Uso de Herramientas (15). Estos se expandieron a partir de un piloto inicial para cubrir razonamiento temporal, formato estricto (por ejemplo, claves JSON exactas), restricciones negativas y casos límite de herramientas. Cada semilla incluye un prompt base, una especificación de comportamiento_esperado inequívoca y una respuesta de referencia.

Se aplican cinco operadores de mutación estructurados de forma iterativa (hasta 5 iteraciones por semilla) utilizando una estrategia de selección $\epsilon$-greedy ($\epsilon=0.2$):

1. rephrase (refrasear): Reformulación superficial de la semilla.
2. inject_distractor (inyectar distractor): Añade una restricción plausible pero engañosa.
3. role_flip (cambio de rol): Replantea la tarea bajo un personaje adversarial.
4. constraint_add (añadir restricción): Anexa requisitos conflictivos.
5. jailbreak_wrap (envolver en jailbreak): Embebe la semilla en una plantilla de estilo jailbreak.

Contribuciones Clave

1. Pipeline Reproducible: Un sistema basado en LangGraph que cuenta con selección de operador $\epsilon$-greedy, escalada de atacante y un panel de tres jueces con un meta-juez para desempatar la confirmación de fallos.
2. Métrica de Costo de Iteración: Una propuesta para reportar el número promedio de iteraciones del atacante requeridas para romper una semilla junto con las tasas de fallo binarias. Esta métrica revela niveles de dificultad que las tasas de éxito/fallo agregadas suelen ocultar.
3. Estudio de Fiabilidad: Una adaptación del análisis de fiabilidad inter-juez (la $\kappa$ de Cohen) para veredictos binarios de respuesta única. El estudio demuestra cómo un alto acuerdo bruto puede coexistir con una $\kappa$ cercana a cero o negativa en distribuciones sesgadas, argumentando que las tasas de desacuerdo estratificadas por categoría son una métrica más informativa.
4. Evidencia de Transferibilidad: Un experimento de transferencia zero-shot que muestra que los prompts adversariales generados contra un modelo débil de 8B logran romper con éxito un modelo de 70B sustancialmente más fuerte, sugiriendo que las mutaciones explotan patrones de comportamiento generales en lugar de debilidades específicas del modelo.

Resultados

• Tasa de Éxito: Todas las 45 semillas produjeron fallos confirmados.
• Efectividad de los Operadores: La efectividad varía drásticamente según la categoría. Por ejemplo, inject_distractor logró una recompensa media de 1.00 en semillas de razonamiento y uso de herramientas, pero solo de 0.33 en semillas de seguimiento de instrucciones. Los conteos agregados enmascararon estas dependencias específicas de la categoría.
• Costo de Iteración: Las semillas de seguimiento de instrucciones requirieron significativamente más esfuerzo (promedio de 2.4 iteraciones) en comparación con las de razonamiento y uso de herramientas (promedio de 1.1 iteraciones). Una curva de supervivencia mostró que el 60% de las semillas de instrucciones permanecieron sin romper tras la primera iteración, frente a solo el 10% de las otras categorías.
• Fiabilidad de los Jueces: El acuerdo entre pares de jueces fue alto (80–87%), pero la $\kappa$ de Cohen fue cercana a cero o ligeramente negativa (−0.05 a −0.11) debido a la alta prevalencia de veredictos de "fallo" (90–97%). Las tasas de desacuerdo fueron más altas en el seguimiento de instrucciones (33% de los casos), mientras que los fallos de razonamiento fueron unánimes (0% de desacuerdo).
• Transferibilidad: Una revisión manual preliminar de 15 prompts adversariales verificados indicó que las trampas lógicas y las mutaciones basadas en restricciones se transfirieron con éxito de Llama 3.1 8B a Llama 3.3 70B.

Significado y Reivindicaciones

El artículo afirma que AdversaBench proporciona una visión más matizada de la evaluación adversarial al ir más allá de las simples tasas de fallo binarias. Argumenta que:

• La selección de operadores debe depender de la categoría: Ningún operador domina en todos los tipos de tareas; el reporte agregado oculta ineficiencias críticas.
• El costo de iteración es una métrica crítica: Revela la "dificultad" de romper un modelo, lo cual es invisible cuando solo se reportan las tasas finales de éxito.
• Los paneles de múltiples jueces son esenciales para el seguimiento de instrucciones: Los jueces únicos pasan por alto fallos que otros jueces detectan, y las tasas de desacuerdo en esta categoría resaltan la necesidad de arbitraje en casos ambiguos.
• La $\kappa$ requiere contexto: En entornos adversariales sesgados, una $\kappa$ cercana a cero es una señal de la prevalencia más que una falta de alineación de los jueces; el desacuerdo estratificado por categoría es un mejor indicador de dónde divergen los jueces.
• Generalizabilidad: Las mutaciones exponen patrones de comportamiento generales (por ejemplo, la dificultad para resolver restricciones conflictivas) en lugar de debilidades específicas de los modelos pequeños, como lo evidencia la transferencia exitosa a modelos más grandes.

Los autores concluyen que el código, el conjunto de datos y los scripts de análisis se liberan para facilitar el red-teaming reproducible y el estudio posterior de la fiabilidad del evaluador.