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

¿Necesitas un modelo para filtrar contenido o actuar como clasificador? Un modelo de 3B acaba de empatar con uno de 20B en moderación de contenido, y además nos permite conocer con exactitud la confianza del modelo en cada respuesta, lo que nos permite definir nuestras propias reglas para decidir cuándo esa confianza es suficientemente alta para actuar.

El modelo en cuestión es Shieldstral, el clasificador de seguridad que Mistral publicó el 4 de agosto (Apache 2.0, corre en una GPU de 16 GB, texto e imagen) ^[1]. Merece la pena mirar de dónde sale ese empate, porque no está en la arquitectura.

En los guard models clásicos la política se define en 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 en ambos la lista de categorías de daño se define durante el entrenamiento.

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 las categorías definidas en el entrenamiento, ajustar ese matiz significa reetiquetar un dataset y volver a entrenar.

Y reentrenar cada vez que cambia la política es un coste difícil de justificar para algo que al final es editar texto.

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

En Shieldstral, como en cualquier LLM moderno, la política de moderación la defines tú en el prompt. Se plantea como una tarea de respuesta binaria: el modelo 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 tokens, no de un texto generado

En inferencia Shieldstral no genera texto. Como el modelo solo puede contestar dos tokens diferentes (“yes” o “no”), basta con mirar la puntuación que asigna a cada uno y convertirla en un número entre 0 y 1 ^[3]. Esas puntuaciones brutas son los logits, y la conversión es un softmax sobre esos dos únicamente; en la respuesta más probable no es la correcta explico qué significa esa distribución.

# 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

Esto es lo que nos permite conocer la confianza del modelo en cada veredicto, en lugar de recibir una etiqueta cerrada. Al salir de un softmax, la puntuación se comporta como una probabilidad (está calibrada, con umbral por defecto en 0,5 ^[3]), y el umbral pasa a ser una decisión nuestra: subirlo donde un falso positivo molesta al usuario, bajarlo donde un falso negativo nos cuesta un incidente, y enviar a revisión humana solo la franja intermedia. Con una etiqueta binaria pura no tenemos 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. En la media de los benchmarks de texto empatan, con un 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 una tarea así no se explica ni por la arquitectura ni por más cómputo en inferencia: se explica por cómo construyeron 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 simple seguro/inseguro. Entrenaron con unos 54,1M de ejemplos, de los cuales 4,4M son pares contrastivos sintéticos ^[2].

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 una noción 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]. Son más de veinte puntos de mejora que no vienen de añadir parámetros, vienen de los datos.

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, y esos puntos extra los pone una operación de álgebra sobre los pesos, sin más entrenamiento.

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 ^[2]. La diferencia son siete décimas de F1, 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, es el estado del arte en moderación multimodal ^[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 es una media. Antes de poner esto delante de usuarios reales, busca en las tablas del apéndice tu idioma y tu tarea concreta.

Y hay una lectura más general que nos toca a todos: seguimos obsesionados con ver cuál es el modelo más potente, y los terminamos usando para tareas acotadas que un modelo pequeño, con los datos bien hechos, resuelve igual o mejor.

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 un 55% en tu idioma principal y tú has decidido a partir de la media 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

1. 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.
2. 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.
3. 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.