Shieldstral: por qué un guard model de 3B empata con uno de 20B

Hay equipos pagando inferencia de un modelo de 20B que razona en voz alta durante varios cientos de tokens para decidir si un comentario rompe su política de contenido. El 4 de agosto Mistral publicó Shieldstral, un clasificador de 3B que contesta lo mismo con un solo token ^[1]. Lo que merece la pena mirar es de dónde sale esa diferencia, porque no está en la arquitectura.

La taxonomía viene cocida en los pesos

El problema de los guard models clásicos es que la lista de categorías de daño se fija durante el entrenamiento. Un guard model es un modelo pequeño dedicado a una sola cosa: mirar un texto o una imagen y decir si viola una política. Es la implementación concreta de lo que en otros posts llamo guardarraíl, aplicado a contenido. LlamaGuard y ShieldGemma funcionan así, y ambos llevan su taxonomía dentro de los pesos.

Eso rompe en cuanto tu producto no es el producto medio. Un texto que describe cómo explotar una vulnerabilidad conocida es contenido normal en una herramienta para pentesters y material a bloquear en una app de acompañamiento a adolescentes: el mismo documento, dos veredictos legítimos. Con la taxonomía dentro de los pesos, ajustar ese matiz significa reetiquetar un dataset y volver a entrenar.

Y reentrenar por un cambio de política es una barbaridad de coste para algo que, mirándolo bien, es texto.

¿Cómo convierte Shieldstral la moderación en una pregunta de sí o no?

Shieldstral plantea la moderación como una tarea de respuesta binaria: recibe una política escrita y una pregunta, y contesta “yes” o “no”. El prompt tiene tres campos ^[1].

<Instruct>
Eres un moderador de una comunidad de ciberseguridad. Sé estricto con
las instrucciones operativas contra objetivos concretos y permisivo con
la teoría y la divulgación.
</Instruct>

<Query>
¿Este mensaje da instrucciones accionables para atacar un sistema ajeno?
</Query>

<Document>
[el mensaje del usuario, la respuesta del modelo, o una imagen]
</Document>

<Instruct> fija el contexto y el nivel de exigencia, <Query> es la pregunta que se responde, y <Document> es lo que se juzga: texto, imagen, o los dos a la vez. Con ese formato, cuatro problemas que normalmente resuelves con cuatro modelos distintos colapsan en uno: clasificar el prompt del usuario, moderar la respuesta del modelo, detectar si el modelo se ha negado a contestar, y detectar toxicidad ^[1]. Cambia la <Query> y cambia el problema.

Lo importante de este diseño es dónde acaba viviendo tu política: en el prompt. Ajustar la línea entre lo aceptable y lo que no lo es se convierte en editar un párrafo y volver a evaluar, no en abrir un notebook de entrenamiento.

La puntuación sale de dos logits, no de un texto generado

En inferencia Shieldstral no genera texto. Se hace un forward pass, se leen los logits de los tokens “yes” y “no”, y se normaliza con softmax sobre esos dos únicamente ^[3]. Un logit es la puntuación bruta que el modelo asigna a cada token candidato antes de convertirla en probabilidad; en la respuesta más probable no es la correcta explico qué significa esa distribución.

Comparación de dos pipelines de inferencia: GPT-OSS-Safeguard-20B genera una traza de razonamiento de varios cientos de tokens antes del veredicto, mientras Shieldstral-3B hace un único forward pass y lee dos logits para calcular una puntuación continua con softmax — Dos formas de llegar al mismo veredicto: generar una explicación completa, o leer dos logits.

# Puntuación de seguridad sin generar ni un token de salida
# pseudocódigo; el snippet real con transformers está en la ficha de HF
logits = model(prompt).logits[-1]          # distribución del siguiente token
z_yes, z_no = logits[tok_yes], logits[tok_no]
score = exp(z_yes) / (exp(z_yes) + exp(z_no))   # softmax sobre dos tokens
unsafe = score > 0.5                       # umbral por defecto

El resultado es un número continuo entre 0 y 1, con umbral por defecto en 0,5 ^[3], en lugar de una etiqueta cerrada. Al salir de un softmax se comporta como una probabilidad: la puntuación está calibrada, y el umbral pasa a ser una decisión tuya. Puedes subirlo donde un falso positivo molesta al usuario, bajarlo donde un falso negativo te cuesta un incidente, y enviar a revisión humana solo la franja intermedia. Con una etiqueta binaria pura no tienes esa palanca.

La comparación obvia es GPT-OSS-Safeguard-20B, que también acepta tu política en el prompt, pero produce una cadena de razonamiento completa antes del veredicto. Misma F1 media en texto (84,9%), coste por llamada de otro orden ^[2].

	Shieldstral-1.0-3B	GPT-OSS-Safeguard-20B	OmniGuard-7B
Parámetros	3B	20B	7B
F1 medio en texto	84,9%	84,9%	no reportado en el paper
F1 multimodal	83,8% (estado del arte)	solo texto	77,6%
Cómo emite el veredicto	logits de “yes”/“no” en un forward pass, puntuación continua	genera traza de razonamiento y luego la etiqueta	etiqueta
Dónde vive la política	en el prompt	en el prompt	taxonomía del entrenamiento
Licencia	Apache 2.0	Apache 2.0	consulta su ficha

Que un modelo de 3B iguale a uno de 20B en la media de los benchmarks de texto no se explica ni por la arquitectura ni por más cómputo en inferencia. Se explica en el dataset.

Los pares contrastivos: el mismo documento con veredictos opuestos

La parte más interesante del artículo técnico es cómo generaron los datos para que el modelo aprenda qué política concreta se viola, y no un burdo seguro/inseguro. Entrenaron con unos 54,1M de ejemplos, de los cuales 4,4M son pares contrastivos sintéticos ^[2].

El mismo documento evaluado con dos preguntas de política hermanas produce dos veredictos opuestos: no viola la política de sustancias ilegales pero sí viola la de consejo médico sin supervisión — Un par contrastivo: el documento no cambia, la pregunta sí. Y el veredicto se invierte.

Un par contrastivo es el mismo documento evaluado dos veces con dos preguntas de categorías hermanas: para una la respuesta correcta es “yes” y para la otra es “no”. Un texto sobre dosis de un fármaco puede violar “consejo médico sin supervisión” y no violar “promoción de sustancias ilegales”. Si el modelo solo ve ejemplos etiquetados como tóxicos o no tóxicos, aprende un olfato general de toxicidad y se le escapa la distinción. Si ve el mismo párrafo con veredictos opuestos según la pregunta, no le queda otra que leer la <Query>.

Lo validaron contra una taxonomía de evaluación deliberadamente distinta a la de entrenamiento, que es la única manera honesta de medir si la política del prompt se está usando de verdad. Sin los datos sintéticos, 61,1% de F1. Con ellos, 84,4% ^[2].

Veintitrés puntos que no salieron de más parámetros.

El checkpoint final es una fusión de tres modelos

Shieldstral no es el resultado directo de un entrenamiento: es una fusión de pesos de tres modelos. Model merging consiste en interpolar los pesos de varios checkpoints para obtener uno nuevo sin entrenar nada más, y aquí usaron SLERP (interpolación esférica entre pesos, no una media lineal) con 0,6 del checkpoint entrenado con datos sintéticos, 0,3 del entrenado con datos públicos y 0,1 del modelo instruct de partida ^[2].

La mezcla rinde mejor que cualquiera de sus ingredientes: en adaptación a taxonomías nuevas pasa de 84,4% a 88,7% de F1. Esos cuatro puntos los pone una operación de álgebra sobre los pesos.

Hay un dato adicional del paper que te ahorra dinero si acabas adaptándolo a tu dominio: LoRA (entrenar unas pocas matrices pequeñas añadidas al modelo en lugar de todos sus pesos) rinde prácticamente igual que el fine-tuning completo en esta tarea, 87,1% frente a 87,8% en Aegis v2, uno de los benchmarks de seguridad usados en la evaluación ^[2]. Siete décimas de diferencia por una fracción del coste.

Cuándo te compensa y cuándo no

Shieldstral tiene sentido cuando tienes política propia y volumen. El coste por llamada es un forward pass de un modelo de 3B que cabe en una GPU de 16 GB ^[1], así que la economía cambia respecto a facturar tokens de razonamiento por cada comentario que entra. Si además moderas imágenes: 83,8% de F1 multimodal frente al 77,6% de OmniGuard-7B ^[2].

Donde se cae es en idiomas con pocos recursos, y el propio paper lo publica. En indonesio, la clasificación de prompts baja a 55,5% de F1 mientras que la clasificación de respuestas en ese mismo idioma da 94,1% ^[2]. Es el mismo modelo, la misma lengua y casi cuarenta puntos de diferencia según qué le pidas.

Ahí está la lectura importante para tu decisión: la media de 84,9% es una media. Antes de poner esto delante de usuarios reales, busca en las tablas del apéndice tu idioma y tu tarea concreta.

Errores comunes

Elegir el guard model por tamaño

Es el reflejo natural y aquí no funciona. La curva de “más parámetros, mejor resultado” aplica a tareas abiertas; en una tarea acotada como decidir si un documento responde “yes” a una pregunta, lo que mueve la aguja son los datos. La ablación de los pares contrastivos vale más que multiplicar por siete el modelo.

Fiarte del F1 medio

Si el desglose por idioma del apéndice muestra 55,5% en tu idioma principal y tú has decidido a partir del 84,9% de la portada, has desplegado un moderador que falla casi la mitad de las veces en tu mercado. Lee el desglose antes que el titular.

Reentrenar un clasificador cuando la política cabe en el prompt

Este es el error caro. Un equipo con un clasificador propio en producción resuelve cada cambio de criterio abriendo el pipeline de entrenamiento, porque es lo que sabe hacer. Con un modelo que lee la política del prompt, ese cambio es editar el bloque <Instruct>, pasar tu conjunto de evaluación y comparar. De semanas a una tarde. La condición es tener ese conjunto de evaluación: sin él, editar el prompt es cambiar el comportamiento a ciegas.

Pagar una traza de razonamiento por cada mensaje

Un juez con razonamiento explícito es una herramienta magnífica para casos ambiguos, revisiones de calidad o auditar decisiones dudosas. Usarlo para el 100% del tráfico de una plataforma con volumen es pagar una explicación que nadie lee. Reserva el razonamiento para la franja de puntuaciones intermedias.

Checklist antes de poner un guard model en producción

Tienes un conjunto de evaluación propio, con contenido de tu producto y etiquetado con tu política
Has leído el desglose por idioma y por tarea del modelo que vas a usar, no solo la media
La política está escrita en el prompt y versionada en el repositorio, no dispersa en la cabeza del equipo
El umbral está fijado por producto y por superficie, no heredado del valor por defecto sin pensarlo
Existe una franja de puntuación intermedia que va a revisión humana o a un modelo con razonamiento
Mides falsos positivos en producción, no solo el F1 del benchmark

Fuentes

Shieldstral — Mistral AI — anuncio oficial del 4 de agosto de 2026: formato de tres campos, los cuatro problemas cubiertos, ejecución en una GPU de 16 GB y el claim de igualar a modelos de hasta siete veces su tamaño.
Shieldstral — arXiv:2607.25857 — artículo técnico del clasificador de seguridad multimodal: F1 de texto y multimodal, volumen y composición del dataset, ablación de los pares contrastivos, pesos de la fusión SLERP, LoRA frente a fine-tuning completo y desglose por idioma.
mistralai/Shieldstral-1.0-3B — Hugging Face — ficha del modelo: base Ministral-3B, encoder de visión de Pixtral, cálculo de la puntuación a partir de los logits de “yes”/“no”, umbral por defecto de 0,5 y lista de idiomas soportados.

Preguntas Frecuentes

¿Qué es un guard model y en qué se diferencia de un LLM normal?

Un guard model es un modelo entrenado para clasificar contenido según una política de seguridad, no para conversar ni escribir: recibe un documento y devuelve un veredicto sobre si viola una regla. En Shieldstral la salida es una probabilidad entre 0 y 1 obtenida de dos logits, sin generar ni una frase, lo que sale mucho más barato que preguntarle lo mismo a un modelo generalista.

¿Shieldstral sustituye a las APIs de moderación como las de OpenAI o Azure?

Depende de si tu política encaja con la suya. Las APIs gestionadas moderan contra categorías definidas por el proveedor y no exigen que mantengas infraestructura; Shieldstral te obliga a servir el modelo tú, pero a cambio escribes la política en el prompt y el contenido no sale de tu red.

Si tus criterios son estándar y tu volumen bajo, la API sale más barata en tiempo de ingeniería.

¿Qué significa que la puntuación esté calibrada?

Que puedes tratar el número como una confianza y cortar donde te convenga: a partir de 0,8 bloqueas automáticamente, entre 0,4 y 0,8 mandas a revisión humana. El umbral por defecto es 0,5 ^[3].

¿Puedo hacer fine-tuning de Shieldstral con mi propia política?

Puedes, pero antes prueba a editar el prompt: el modelo está entrenado precisamente para que la política viva ahí. Si tras eso sigues necesitando adaptarlo, el paper mide LoRA frente a fine-tuning completo en esta tarea y la diferencia es de siete décimas de F1 ^[2], así que empieza por LoRA.

¿Funciona en español?

Sí. El español está entre los idiomas soportados de la ficha del modelo ^[3], junto al inglés, francés, alemán, italiano, portugués, neerlandés, chino, japonés, coreano, árabe y ruso. Aun así, el desglose por idioma del paper muestra diferencias grandes entre lenguas y tareas, así que evalúalo con tu propio contenido en español antes de fiarte de la media global.