Cambiar la definición de «unsafe» mueve la puntuación de un guardrail de 0 a 100 con solo el 0,03% de los pesos

Lo habitual es describir un clasificador guardrail como si la «inseguridad» fuera una propiedad del texto. Un nuevo trabajo de Hugging Face Daily Papers muestra que es una propiedad de la política de etiquetado. Los autores tomaron unos 53 mil prompts que, en un despliegue industrial, se habían etiquetado dos veces. Con ellos entrenaron diez variantes de guardrail en dos escalas y obtuvieron puntuaciones que iban de 0 a 100 en un mismo benchmark. La arquitectura, la base de código y la familia de optimizadores eran las mismas en todas las variantes.

Un corpus, dos políticas

El proceso industrial dejó un «efecto secundario» afortunado para los investigadores: los mismos prompts se etiquetaron con dos definiciones operativas. La primera: «¿es una petición de contenido dañino?». La segunda: «¿lo habría bloqueado un moderador?». Sobre el papel, ambas formulaciones describen la misma tarea; en la práctica, sus fronteras no coinciden. El resultado es un experimento limpio: lo único que cambia es la política que llega al modelo a través de las etiquetas.

En total se entrenaron diez variantes (arms) en dos escalas de modelo, es decir, veinte checkpoints. Las cifras clave del trabajo:

• el 88% de JailbreakBench-benign y el 82% de OR-Bench-hard ya estaban presentes en los conjuntos de entrenamiento de los guardrails;
• la dispersión entre las diez variantes fue de 0,99 en HarmBench-copyright y de 0,043 en WildGuard-benign, una diferencia de 23 veces en la sensibilidad a la definición;
• HarmBench-copyright recorre todo el rango 0–100, y el over-refusal en OR-Bench-hard va de 3,4 a 56,4%;
• el desplazamiento afecta al 0,03% de los parámetros;
• correlación de la precisión en un split de validación común con la coincidencia con la política del anotador: rho=+0,74; con la capacidad real de detección: rho=+0,34.

Contaminación y sensibilidad de los benchmarks

El primer hallazgo es incómodo de por sí. Dos benchmarks de rechazos excesivos, JailbreakBench-benign y OR-Bench-hard, son precisamente los que se citan para demostrar que un guardrail no bloquea de más. Una parte considerable de ellos estaba dentro del propio corpus de entrenamiento del guardrail. Los autores calculan todos los demás resultados ya con datos descontaminados.

El segundo hallazgo atañe al diseño de los benchmarks. Con arquitectura y optimizador fijos, algunos tests casi no dependen de la política elegida y otros dependen de ella casi por completo. WildGuard-benign oscila dentro de 0,043; HarmBench-copyright, dentro de 0,99. El primero se acerca más a una medición del modelo; el segundo mide sobre todo qué definición de «dañino» ha asimilado.

Tercer hallazgo: para llevar la puntuación a lo largo de todo el rango basta con modificar el 0,03% de los parámetros. Cuatro variantes cuya última señal de entrenamiento llevaba una política determinada quedaron en el mismo extremo de ambas escalas (prueba exacta de rangos, p=0,005; en el peor de los casos, 0,04–0,14). La capacidad de detección, mientras tanto, no cambió.

Destilación y validación

Hay también una consecuencia desagradable para los checkpoints abiertos. En un modelo estudiante destilado, las etiquetas blandas del profesor transmiten la política, incluso si todas las etiquetas duras llevan otra distinta. El origen del profesor se convierte así en un factor de confusión no documentado para cualquier checkpoint publicado. Dos modelos con el mismo nombre de familia pueden diferir más en su «política» que en su arquitectura.

Con la validación ocurre lo mismo. La precisión en el único split que evalúa las veinte variantes refleja mejor la coincidencia con la política del anotador (rho=+0,74) que la capacidad de detectar lo dañino (rho=+0,34). Una puntuación alta suele significar que se ha acertado con el gusto del etiquetador.

Cómo leer los informes sobre guardrails

Los autores proponen tres variables obligatorias en cualquier informe: el nivel de contaminación, el límite inferior de ruido por seeds (seed floor) y la definición con la que se evaluó. En la práctica, esto significa lo siguiente. Antes de comparar dos guardrails, compruebe qué política había detrás del etiquetado de los datos de entrenamiento y del benchmark.

No confíe en los resultados de over-refusal mientras no vea la proporción de solapamiento con el entrenamiento. Si la diferencia entre modelos es menor que la dispersión entre seeds, no es una diferencia. Los equipos que adopten el checkpoint de otro deben averiguar quién fue el profesor y ejecutar el modelo sobre sus propios casos de política antes de integrarlo en un producto.

El trabajo es un preprint y su reproducibilidad en otros corpus aún está por comprobar, pero sus conclusiones se pueden verificar de inmediato en los pipelines propios.