Auto-alineamiento: cuánta seguridad hay que enseñar a un modelo de lenguaje sin que deje de ser útil

Segunda entrega de Radiografía del clúster. Tras el fuzzing de banda base , la primera de tres líneas sobre seguridad de modelos de lenguaje.

La pregunta #

Ajustar un modelo de lenguaje para que rechace peticiones dañinas tiene un coste: si se le enseña demasiado a decir no, empieza a rechazar también lo inofensivo, y pierde utilidad. La línea estudia ese equilibrio: qué proporción de datos de seguridad hay que mezclar con los datos de utilidad, y si el propio modelo puede generar sus ejemplos de rechazo y regular la dosis solo.

Cómo se aborda #

El modelo es Llama 3.2 3B Instruct, ajustado con SFT y LoRA. La utilidad la aporta Alpaca (o MetaMathQA cuando el dominio es matemático); la seguridad, conjuntos públicos como BeaverTails, HH-RLHF harmless y OR-Bench, mezclados al 15 % o al 5 % con varias semillas. Cada entrenamiento guarda una veintena de checkpoints, y cada uno se evalúa por separado para trazar la curva completa, no solo el final.

Las familias de experimentos siguen la lógica de la pregunta:

Mezclas fijas. Solo Alpaca; Alpaca con un 15 % de cada conjunto de seguridad; MetaMath como dominio distinto.
Respuestas enlatadas. Mismos prompts dañinos, pero la respuesta es una negativa fija o una paráfrasis de un pool de quince. Aísla si lo que importa es el contenido de la respuesta o basta con que sea un rechazo.
Auto-alineamiento. El pool de rechazos lo genera el propio Llama con best-of-4 y un juez por pares: unos 14.000 prompts dan 10.300 ejemplos. Una variante añade un 25 % de respuestas útiles generadas sobre OR-Bench, para combatir el exceso de rechazo desde los datos.
Régimen dinámico. La proporción de seguridad no se fija: se ajusta por rondas según la tasa de éxito de ataques medida en un held-out de 256 prompts. Se comparan tres controladores (PID, bandido y banda muerta) con la mezcla fija equivalente.

La evaluación combina HarmBench (tasa de éxito de ataques), XSTest (exceso de rechazo), perplejidad o GSM8K (utilidad) y, en el checkpoint final, IFEval, ARC y MMLU. Las respuestas de cada evaluación se guardan separadas de los adaptadores, y eso permitió al final re-juzgarlas con un juez LLM y tres prompts distintos sin reentrenar nada.

Qué se aprende #

La línea construye un frente de Pareto utilidad-seguridad por experimento, con el modelo base sin adaptar como ancla. Las preguntas que responde son las que se lee entre líneas en los scripts: si un pool de rechazos generado por el propio modelo vale tanto como uno anotado a mano; si un controlador que reacciona a la tasa de ataques logra la misma seguridad con menos datos; y cuánto pesa el juez, porque el mismo checkpoint cambia de nota según quién lo juzgue. El último día de la campaña quedó escrito el principio que cierra esa deriva: «consistencia juez sensor↔test… una única fuente de verdad».

En el clúster #

Cifras de la línea. Las horas de GPU son de junio; la contabilidad de mayo no registró tarjetas asignadas.

Cada entrenamiento dispara un array de evaluaciones, una por checkpoint, y al terminar estas una agregación. De ahí que la línea sea la segunda en número de trabajos con relativamente pocas horas de GPU: el 3B con LoRA entrena en poco más de una hora en una L40S y cada evaluación dura unos minutos.

Trabajos por tipo: casi todos son evaluaciones de checkpoints.

La tercera entrega es la otra mitad de la misma pregunta: atacar el modelo en vez de defenderlo.

Cifras de la contabilidad de Slurm (capacidad reservada, no uso medido) y de los sbatch archivados. Entrada anonimizada: sin usuarios, rutas, correos ni nombres de proyecto identificables. Las citas son de los comentarios de los scripts.