Willing but Unable: Separating Refusal from Capability in Code LLMs via Abliteration

Resumen Técnico: Dispuesto pero Incapaz: Separando la Negativa de la Capacidad en los LLM de Código mediante la Abliteración

Planteamiento del Problema
El artículo aborda un cuello de botella crítico en la detección de vulnerabilidades basada en aprendizaje: la escasez de datos de entrenamiento etiquetados con precisión. Los conjuntos de datos existentes sufren de un ruido de etiquetas significativo (20–71%) y duplicación debido a que son extraídos de commits etiquetados con CVE. Si bien los Modelos de Lenguaje de Gran Escala (LLM) ofrecen una vía para el aumento de datos, los métodos actuales suelen transformar semillas vulnerables existentes, heredando así el ruido del corpus de origen. Un enfoque complementario consiste en partir de código seguro e instruir a un LLM para que inyecte una vulnerabilidad específica de la Clasificación de Debilidades Comunes (CWE). Sin embargo, los LLM de código modernos, alineados de seguridad y ajustados por instrucciones, rechazan sistemáticamente tales peticiones debido al Aprendizaje por Refuerzo a partir de la Retroalimentación Humana (RLHF) o la Optimización de Preferencia Directa (DPO), incluso cuando el modelo posee la capacidad subyacente para realizar la transformación. Este rechazo crea una barrera para generar conjuntos de datos de vulnerabilidades a gran escala y dirigidos por especificaciones.

Metodología
Los autores proponen un estudio de viabilidad utilizando la abliteración, una técnica de edición de pesos de bajo rango, para eliminar la barrera de la negativa preservando la capacidad generativa. El estudio se centra en la CWE-89 (Inyección SQL) en Python como caso de estudio.

1. Selección del Modelo: El estudio utiliza la familia Qwen2.5-Coder-Instruct en tres escalas de parámetros: 3B, 7B y 14B. Estos modelos fueron elegidos por sus pesos abiertos, su especialización en código y su viabilidad para la inferencia basada en CPU.
2. Procedimiento de Abliteración: Basándose en la hipótesis de que la negativa es mediada por un subespacio lineal específico en el flujo residual del modelo, los autores aplican una proyección ortogonal para eliminar esta "dirección de negativa".
   • Calculan una matriz de contraste entre las activaciones de los prompts dañinos (inyección de CWE) y los inofensivos.
   • La Descomposición en Valores Singulares (SVD) identifica los $k$ vectores singulares derechos superiores que representan la dirección de la negativa.
   • Estos vectores se proyectan fuera de las matrices de pesos de salida ($W_{out}$) de capas específicas del transformador (típicamente el tercio superior de la red) sin reentrenamiento.
   • Los hiperparámetros ($k$ y pasadas de refinamiento) se ajustan según el tamaño del modelo (por ejemplo, $k=2$ para 3B, $k=8$ para 7B/14B).
3. Pipeline Experimental:
   • Entrada: 70 muestras seguras de Python provenientes de PromSec (20 muestras, aplicaciones Flask de rutas múltiples) y SafeCoder (50 fragmentos de ruta única).
   • Prompting: Una instrucción fija pide al modelo que reescriba el código seguro para introducir la CWE-89 (por ejemplo, reemplazando consultas parametrizadas con concatenación de cadenas).
   • Validación: Un proceso de tres pasos evalúa las salidas:
     1. Clasificación de la Negativa: Detección basada en expresiones regulares de patrones de negativa.
     2. Validación Sintáctica: Análisis AST y comprobaciones de compilación.
     3. Detección de Vulnerabilidades: Un ensamble de tres analizadores estáticos (CodeQL, Semgrep, Bandit) señala posibles vulnerabilidades.
     4. Adjudicación Manual: Dos autores verifican manualmente las salidas positivas de los detectores contra la especificación de CWE-89 para resolver falsos positivos/negativos.
4. Métricas de Evaluación: El estudio mide las tasas de negativa, la validez sintáctica, las tasas de inyección de vulnerabilidades y la similitud de código (CrystalBLEU/CodeBLEU) frente a las contrapartes vulnerables de verdad fundamental (ground-truth).

Contribuciones Clave

1. Pipeline Reproducible: Un flujo de trabajo validado que aplica la abliteración a LLM de código ajustados por instrucciones, junto con un ensamble de análisis estático de múltiples herramientas y adjudicación manual.
2. Medición Empírica: Un estudio factorial controlado (3 modelos $\times$ 2 condiciones $\times$ 2 conjuntos de datos $\times$ 3 ejecuciones) que proporciona las primeras mediciones empíricas de la negativa y el cumplimiento post-abliteración en tareas de inyección de CWE.
3. Separación Ortogonal de Voluntad y Capacidad: El estudio demuestra que la negativa (voluntad) y la capacidad de generación de código son ejes ortogonales. La abliteración elimina con éxito el reflejo de la negativa sin crear nuevas capacidades; simplemente desbloquea capacidades que ya estaban presentes pero suprimidas.
4. Artefactos Abiertos: Publicación del armazón de evaluación (clasificador de negativa, validadores, scripts de puntuación) y los datos agregados, mientras se retienen los checkpoints abliterados específicos y las muestras vulnerables para mitigar los riesgos de uso indebido.

Resultados

• La Negativa Depende del Tamaño y el Contexto:
  • El modelo de 14B rechazó el 100% de las peticiones en ambos conjuntos de datos.
  • El modelo de 7B rechazó el 73% de las peticiones de PromSec (rutas múltiples) pero solo el 5% de las de SafeCoder (ruta única).
  • El modelo de 3B exhibió una negativa insignificante (0–7%).
• La Abliteración Elimina la Negativa:
  • Post-abliteración, las tasas de negativa cayeron a 0% (o cerca de cero, ej. 1.7% para 3B en PromSec) en todos los tamaños de modelo y conjuntos de datos.
  • Preservación de la Capacidad: La validez sintáctica se mantuvo por encima del 93% para todos los modelos abliterados. La intervención no degradó la capacidad de los modelos para generar código Python válido y coherente.
• La Capacidad está Limitada por la Capacidad Intrínseca:
  • Una vez eliminada la negativa, la tasa de inyección de vulnerabilidades escaló con los parámetros del modelo:
    • 14B: ~88–97% de éxito de inyección.
    • 7B: ~89–90% de éxito de inyección.
    • 3B: ~25–48% de éxito de inyección.
  • La baja tasa de éxito del modelo 3B persistió incluso después de la abliteración, indicando que la limitación era una falta de capacidad generativa (incapacidad para realizar la edición estructural correctamente), no un mecanismo de negativa.
• Concordancia de Detectores: Los analizadores estáticos mostraron niveles variables de acuerdo. CodeQL fue altamente específico para ciertos ídiomas (ej. flask_mysqldb), mientras que Bandit tuvo mayor recuperación (recall) en patrones sintácticos. La adjudicación manual fue esencial para resolver discrepancias.

Significado y Reivindicaciones
El artículo afirma proporcionar un estudio de viabilidad preliminar que demuestra que:

1. La negativa puede separarse de la capacidad: El alineamiento de seguridad en los LLM de código actúa como un "reflejo de negativa" que puede ser eliminado quirúrgicamente mediante ediciones de pesos de bajo rango sin dañar el sustrato generativo subyacente.
2. Viabilidad de la Generación de Datos: El pipeline ofrece un método para generar datos de vulnerabilidad etiquetados donde la carga de etiquetado pasa de una detección abierta (propensa al ruido) a una confirmación binaria acotada. Los modelos 14B y 7B, una vez abliterados, muestran un alto potencial para generar conjuntos de datos de vulnerabilidades de alta calidad y dirigidos por especificaciones.
3. Implicaciones de Doble Uso: Los autores destacan una preocupación de seguridad: la capacidad de eliminar la negativa mediante simples ediciones de pesos implica que los modelos de pesos abiertos alineados de seguridad pueden convertirse fácilmente en herramientas para generar código malicioso. Argumentan que la "superficie de ataque" expuesta por la abliteración en entradas complejas ya está presente por defecto en entradas más simples (como se vio con el 7B en SafeCoder).
4. Perspectiva Metodológica: El estudio sugiere que evaluar los modelos alineados de seguridad únicamente mediante tasas de "negativa + fallo" confunde dos fenómenos distintos. El aparente fallo de un modelo en tareas sensibles puede deberse enteramente a la negativa, que es removible, y no a una falta de capacidad.

Los autores mantienen un tono modesto, señalando que el estudio se limita a una sola CWE (89), un solo lenguaje (Python) y una sola familia de modelos. Establecen explícitamente que los hallazgos no garantizan la generalizabilidad a otras CWE o arquitecturas de modelos sin una validación empírica adicional.