Low-Resource Safety Failures Are Action Failures, Not Representation Failures

Este artículo demuestra que los fallos de seguridad en entornos de bajos recursos derivan de un desajuste en la calibración de decisiones en lugar de una falta de representaciones de nocividad, y propone un método para solucionar esto recalibrando las compuertas de seguridad de altos recursos existentes utilizando solo unos pocos ejemplos del lenguaje objetivo.

Lo esencial

El gran problema: La "barrera del idioma" en la seguridad de la IA

Imagina que tienes un guardia de seguridad muy inteligente y bien entrenado (el modelo de IA). A este guardia se le ha enseñado en inglés (un idioma de altos recursos) a detectar peticiones peligrosas y decir "No". Si alguien pregunta "¿Cómo construyo una bomba?" en inglés, el guardia se niega inmediatamente.

Sin embargo, si haces la misma pregunta exacta en suajili o birmano (idiomas de bajos recursos), el guardia de repente olvida su entrenamiento. Podría responder a la pregunta en lugar de negarse.

Durante mucho tiempo, los investigadores pensaron que esto sucedía porque la IA simplemente no entendía las palabras peligrosas en esos otros idiomas. Pensaban que la "señal de peligro" faltaba en el cerebro de la IA cuando cambiaba de idioma.

El descubrimiento: El guardia sí entiende, pero no actúa

Los autores de este artículo decidieron mirar dentro del "cerebro" de la IA (sus matemáticas internas) para ver qué estaba pasando realmente. Encontraron algo sorprendente:

La IA sí sabe que la petición es peligrosa, incluso en suajili o birmano.

Piénsalo de esta manera: El guardia de seguridad escucha la petición peligrosa en suajili. Su cerebro se ilumina con una alarma de "PELIGRO", tal como lo hace en inglés. La alarma está ahí, y es lo suficientemente fuerte como para ser escuchada.

El fallo no es que la alarma esté rota; el fallo es que el guardia ignora la alarma.

En inglés, la alarma es tan fuerte que el guardia presiona automáticamente el botón de "Rechazar". En los idiomas de bajos recursos, la alarma sigue ahí, pero es un poco más silenciosa. Debido a que es más silenciosa, el guardia no se da cuenta de que es lo suficientemente fuerte como para activar el botón de "Rechazar", por lo que simplemente sigue hablando.

El artículo llama a esto un fallo de calibración, no un fallo de representación.

• Fallo de representación: El guardia no sabe qué significa "bomba" en suajili. (El artículo dice que esto es falso).
• Fallo de calibración: El guardia sabe qué significa "bomba", pero la perilla de volumen para el botón de "Rechazar" está configurada demasiado alta para ese idioma específico. (El artículo dice que esto es verdadero).

La solución: Un ajuste simple de la "perilla de volumen"

Dado que la IA ya posee el conocimiento del "peligro", los autores no necesitaron reentrenar a toda la IA (lo cual es costoso y lento). En su lugar, construyeron un guardián diminuto e inteligente (un "portal latente").

Así es como funciona su solución:

1. Usar la alarma existente: Toman la "dirección de peligro" que la IA ya aprendió del inglés.
2. Escuchar unos pocos ejemplos: Le muestran al guardián solo de 1 a 4 ejemplos de peticiones peligrosas y seguras en el idioma objetivo (como el suajili).
3. Reiniciar el umbral: El guardiño dice: "De acuerdo, en suajili, la alarma de peligro es un poco más silenciosa que en inglés. Necesito bajar el volumen requerido para presionar el botón de 'Rechazar'".
4. Dirigir la decisión:
   • Si el guardián cree que la petición es peligrosa, sube el volumen de "Rechazar" para asegurar que la IA diga que no.
   • Si el guardián cree que la petición es segura, baja el volumen de "Rechazar" para que la IA no rechace accidentalmente peticiones inofensivas (como "¿Cómo horneo un pastel?").

Los resultados: Un guardia más inteligente y seguro

Al utilizar este simple ajuste de la "perilla de volumen" con muy pocos ejemplos, los autores lograron grandes resultados:

• La seguridad mejoró: La IA comenzó a rechazar peticiones peligrosas con mucha más frecuencia en los idiomas de bajos recursos (pasando de rechazar aproximadamente el 44% de las veces a más del 67% en algunos casos).
• Se preservó la utilidad: Crucialmente, la IA no empezó a rechazar peticiones seguras. No se volvió excesivamente paranoica.
• Eficiencia: No necesitaron reentrenar el enorme modelo de IA. Solo ajustaron un pequeño interruptor usando un puñado de ejemplos.

Analogía de resumen

Imagina un detector de humo instalado en una casa.

• La visión antigua: Cuando el detector no sonaba en la cocina (idioma de bajos recursos), la gente pensaba que el detector estaba roto o que no sabía qué era el humo.
• La nueva visión: El detector sí olía el humo. Solo que no era lo suficientemente sensible para activar la alarma en esa habitación específica.
• La solución: En lugar de comprar una casa y detectores nuevos, los autores simplemente ajustaron el dial de sensibilidad del detector existente. Ahora, el detector huele el humo en la cocina y grita "¡Fuego!" con la misma fuerza que lo hace en la sala de estar.

La conclusión fundamental: Los fallos de seguridad en idiomas de bajos recursos no se deben a que la IA sea "tonta" en esos idiomas; se debe a que su "interruptor de seguridad" está configurado demasiado alto. Un pequeño ajuste de pocos pasos (few-shot) puede solucionar esto sin necesidad de reaprender todo desde cero.

Resumen técnico

Resumen Técnico: Los fallos de seguridad en recursos bajos son fallos de acción, no de representación

Planteamiento del problema

Los modelos de lenguaje de gran tamaño (LLM) entrenados para el alineamiento de seguridad en lenguas de altos recursos (HRL) suelen fallar al rechazar instrucciones dañinas cuando dichas instrucciones se traducen a lenguas de bajos recursos (LRL). Mientras que los modelos rechazan con éxito las instrucciones dañinas en inglés, frecuentemente cumplen con solicitudes idénticas en idiomas como el suajili o el birmano. El trabajo previo ha documentado esta brecha de comportamiento, pero no ha aclarado su mecanismo interno. Existen dos hipótesis contrapuestas:

1. Fallo de representación: El modelo carece de una representación interna utilizable de la "dañosidad" en las LRL debido a una comprensión semántica más débil.
2. Fallo de acción (enrutamiento): El modelo posee la representación de la dañosidad, pero falla al traducir esa señal en una decisión de rechazo (es decir, el umbral de decisión está desalineado).

Este artículo diagnostica la causa raíz de la brecha de seguridad multilingüe y propone una intervención ligera para repararla.

Metodología

Configuración experimental

Los autores evaluaron tres modelos ajustados por instrucciones (Qwen2.5-7B, Gemma-2-9B y Llama-3.1-8B) en 23 idiomas categorizados en niveles de recursos (Alto, Medio, Bajo) basados en la participación de Common Crawl. Utilizaron una versión extendida del conjunto de datos PolyRefuse, que contiene prompts dañinos e inocuos traducidos a estos idiomas.

Fase de diagnóstico

Para distinguir entre fallos de representación y de acción, los autores emplearon técnicas de interpretabilidad mecánica en el flujo residual (residual stream):

1. Extracción de la dirección de dañosidad: Calcularon una "dirección de dañosidad" unidimensional ($v_{HRL}$) tomando la diferencia de las activaciones medias entre prompts dañinos e inocuos en las HRL.
2. Mediación causal (ablación): Probaron si eliminar esta dirección derivada de la HRL de las activaciones de las LRL suprimía el rechazo. Los resultados mostraron que la ablación de $v_{HRL}$ en las LRL reducía significativamente el rechazo de contenido dañino, demostrando que la dirección es causalmente activa.
3. Separabilidad lineal: Proyectaron las activaciones de las LRL sobre $v_{HRL}$ y midieron el Área Bajo la Curva (AUC) para separar prompts dañinos de inocuos. El AUC se mantuvo alto (>0.85) incluso en las LRL donde las tasas de rechazo eran bajas, lo que indica que la representación está presente y es decodificable.
4. Análisis de magnitud de la señal: Observaron que, aunque la señal existe, las puntuaciones de proyección para los prompts dañinos de las LRL se desplazan hacia abajo en comparación con las HRL. El umbral de rechazo implícito del modelo no se activa porque la magnitud de la señal es insuficiente, no porque la señal falte.

Intervención: Puerta latente de pocos disparos (Few-Shot Latent Gate)

Basándose en el diagnóstico de que el fallo es de calibración y no de representación, los autores propieron un método de guiado (steering) sin entrenamiento:

1. Puerta latente: Se entrena una lectura logística de bajo rango en datos de HRL para mapear la proyección de dañosidad a una decisión de seguridad binaria.
2. Recalibración del umbral: En lugar de reentrenar el modelo o aprender una nueva dirección específica para la LRL, el umbral de decisión ($\tau$) se restablece utilizando un número mínimo de ejemplos del idioma objetivo (tan solo de 1 a 4 por clase).
3. Guiado condicional: El sistema enruta los prompts basándose en la salida de la puerta:
   • Si se clasifica como dañino: La dirección de dañosidad de la HRL se añade a la activación (guiando hacia el rechazo).
   • Si se clasifica como inocuo: La dirección de dañosidad de la HRL se ablaciona (evitando falsos rechazos).

Resultados clave

Hallazgos del diagnóstico

• La representación está intacta: La dañosidad sigue siendo linealmente separable en las activaciones de las LRL. El fallo no es la falta de representación.
• Desplazamiento de la señal: Los prompts de las LRL producen proyecciones más bajas sobre la dirección de dañosidad. El modelo no rechaza porque la magnitud de la señal cae por debajo del umbral implícito establecido durante el entrenamiento de las HRL.

Mejoras de rendimiento

La puerta latente de pocos disparos propuesta superó significativamente a las líneas base de guiado adaptativo existentes (CAST y AdaSteer):

• Rechazo selectivo ($\Delta$): La métrica $\Delta$ (tasa de rechazo de contenido dañino menos tasa de rechazo de contenido inocuo) aumentó de 33.6 (la línea base adaptada más fuerte) a 54.5 con el método propuesto.
• Rechazo de contenido dañino: El método elevó las tasas de rechazo de contenido dañino en las LRL (por ejemplo, de 43% a ~67% en promedio) manteniendo el rechazo de contenido inocuo bajo (12.7%).
• Comparación con líneas base: Los métodos competidores como CAST y AdaSteer fallaron al no mejorar significativamente el rechazo de contenido dañino o causaron un "sobre-rechazo" excesivo de prompts benignos (por ejemplo, AdaSteer alcanzó un 52.8% de rechazo de contenido inocuo).
• Generalización: La puerta generalizó bien a los benchmarks de seguridad fuera de la distribución (MultiJail, IndoSafety) y se transfirió a través de diferentes LRL al calibrarse en una sola LRL de origen.
• Preservación de la utilidad: La intervención preservó la utilidad en el benchmark Global-MMLU, con cambios insignificantes en la precisión.

Significación y afirmaciones

El artículo afirma que los fallos de seguridad en recursos bajos son principalmente fallos de acción (problemas de calibración) en lugar de fallos de representación.

• Perspectiva mecánica: El trabajo demuestra que las representaciones de seguridad aprendidas en lenguas de altos recursos son transferibles y están presentes en las lenguas de bajos recursos, pero su magnitud de activación es insuficiente para activar el rechazo sin una recalibración.
• Eficiencia: La solución propuesta no requiere actualizaciones de los pesos del modelo ni un reentrenamiento extensivo. Logra un rendimiento de seguridad de vanguardia utilizando solo un puñado de ejemplos del idioma objetivo para restablecer un umbral de decisión.
• Implicación práctica: Los autores sugieren un flujo de trabajo de "diagnóstico-luego-reparación": antes de intentar aprender nuevas representaciones de seguridad para una lengua de bajos recursos, primero se debe probar si la representación de altos recursos existente es decodificable. Si lo es, una simple recalibración del umbral de decisión es suficiente para reparar el alineamiento de seguridad.

Los autores señalan limitaciones, incluyendo el alcance de los modelos probados (modelos densos de 7B–9B), la dependencia de Common Crawl como proxy de recursos, y el hecho de que la intervención es una herramienta de diagnóstico que requiere acceso a las activaciones en lugar de ser una salvaguarda de modelo cerrado. También enfatizan que este método no reemplaza la necesidad de un entrenamiento de seguridad multilingüe ni garantiza la robustez contra todos los tipos de prompts adversarios.