Más allá de la clasificación: Evaluando LLMs en una tarea de seguridad real

Para los problemas más difíciles –razonamiento visual abstracto como ARC-AGI-2, matemáticas a nivel de investigación como FrontierMath, o preguntas multidominio a nivel experto como Humanity's Last Exam– la clasificación pública es una guía razonable: elige el modelo mejor clasificado y probablemente obtendrás el mejor resultado.

Para problemas sencillos, como clasificación de texto o extracción de entidades, ajustar un modelo pequeño con unos pocos miles de ejemplos etiquetados suele funcionar a una fracción del costo.

La brecha interesante está en el medio: tareas que son genuinamente complejas, que requieren conocimiento de dominio real y criterio, pero que no son tan difíciles como para que solo los modelos de vanguardia puedan manejarlas. En la práctica, ejecutar un modelo de vanguardia en cada solicitud a escala no es sostenible. Pero no está claro si los modelos más pequeños y económicos pueden mantenerse a la altura en tareas como estas.

Este artículo explora cómo abordamos esa pregunta en Red Sift: qué medimos, cómo lo medimos y qué nos dicen los resultados sobre la selección de modelos para tareas como esta.

Radar Lite ejecuta verificaciones de seguridad automatizadas en dominios en tres áreas: seguridad del correo electrónico, integridad de DNS y configuración web/TLS. La salida bruta es un registro estructurado de resultados de pruebas –aprobado, fallido, advertencia, neutral– con evidencia y observaciones para cada hallazgo.

El trabajo del resumidor es traducir eso en un informe legible en markdown: destacando los fallos más importantes, explicando el impacto real y proporcionando recomendaciones accionables.

Esta es una tarea de evaluación ideal por varias razones:

• Requiere conocimiento de dominio real. DMARC, SPF, DKIM, MTA-STS, DNSSEC, cadenas de certificados TLS: estos no son temas que aparezcan de forma destacada en datos de entrenamiento genéricos. Un modelo que trate DMARC p=none como un resultado aprobado, o confunda una cadena DNSSEC rota con una advertencia menor en lugar de un riesgo de interrupción, producirá resúmenes que engañan activamente a los equipos de seguridad.
• Es difícil, pero no extremadamente difícil. La evidencia se proporciona: el modelo no necesita descubrir nada, solo interpretarla correctamente y escribir con claridad. El techo es la escritura estructurada y fundamentada en el dominio, no el razonamiento abierto o la demostración matemática.
• La calidad es medible. Precisión, integridad, estructura, claridad: hay dimensiones concretas y evaluables, lo que hace posible una puntuación consistente.
• Los riesgos de costo y latencia son reales. Radar Lite es una herramienta gratuita. Ejecutar modelos de vanguardia en cada solicitud no es viable a escala, por lo que el equilibrio entre costo y calidad tiene consecuencias directas en producción.

Antes de ejecutar cualquier verificación de seguridad, Radar Lite analiza la consulta en lenguaje natural del usuario para detectar dos cosas:

• Intención – sobre qué dominio de seguridad pregunta el usuario: EMAIL (DMARC, SPF, DKIM, MTA-STS), DNS (DNSSEC, registros CAA), WEB (configuración TLS, HTTPS, HSTS), o ANY para una evaluación completa en los tres
• Alcance – cuántos dominios están involucrados y cómo: SINGLE para un dominio, MULTI para varios evaluados de forma independiente, o COMPARE para una comparación lado a lado

Ambos determinan qué verificaciones se ejecutan y, crucialmente, qué se espera que produzca el resumidor: un resumen COMPARE necesita establecer contrastes y declarar un ganador; un resumen MULTI necesita una sección separada por dominio. Esto es lo que hace que la evaluación no sea trivial de muestrear: la tarea cambia de forma según lo que preguntó el usuario.

Extrajimos aproximadamente 3.000 consultas de producción reales del almacenamiento y las redujimos a un conjunto de datos de evaluación de 100 entradas. El muestreo aleatorio se inclinaría hacia el tipo de consulta más común –dominio único, intención cualquiera– por lo que utilizamos un muestreo estratificado para garantizar que se cubriera toda la gama de comportamientos del resumidor:

El conjunto de datos tiene cuatro propiedades clave:

• Representativo – la división de alcance refleja las proporciones de producción mientras sobremuestrea deliberadamente MULTI y COMPARE, que son estructuralmente más difíciles y tienen más probabilidades de exponer debilidades del modelo
• Diverso – la división de intención garantiza que se cubran los tres dominios de seguridad, en lugar de recurrir por defecto al tipo de consulta más común
• Imparcial – la restricción de unicidad de dominio significa que cada entrada es una observación genuinamente independiente; ninguna infraestructura de una sola organización influye de manera desproporcionada en los resultados
• Estadísticamente significativo – con 100 entradas, las diferencias de puntuación de ~3-5 puntos son detectables de manera confiable en la escala normalizada de 0 a 1, lo que hace posible distinguir diferencias reales entre modelos del ruido

Las métricas automáticas estándar como BLEU o ROUGE no funcionan aquí. Un buen resumen no es uno que coincida con una cadena de referencia, sino uno que sea preciso, esté bien estructurado y sea accionable. Utilizamos un enfoque de LLM como juez, pero hay algunas variaciones a considerar.

• La comparación por pares –pedirle a un modelo juez que elija el mejor entre dos resultados– es popular, pero con una gran cantidad de configuraciones de modelos y 100 entradas cada una, necesitarías miles de comparaciones solo para clasificarlas. E incluso entonces, sabrías qué modelo ganó sin saber por qué.
• La puntuación directa evita el problema de escala, pero el juez efectivamente inventa su propia rúbrica cada vez, lo que produce resultados inconsistentes entre ejecuciones.
• Una rúbrica estructurada aborda ambos problemas: los criterios se fijan de antemano, por lo que el juez no tiene margen para desviarse, y las puntuaciones por criterio muestran exactamente dónde falla cada modelo. Usamos una escala de 0 a 2 en lugar de puntuación binaria porque algunos criterios tienen un estado intermedio genuino: parcialmente correcto es significativamente diferente de correcto o incorrecto.

Terminamos con una rúbrica de 13 criterios fundamentada en los requisitos de salida de Radar Lite:

• Precisión factual – sin problemas alucinados, todos los fallos reportados
• Lenguaje y tono – sin jerga interna filtrada, formato correcto, registro profesional
• Severidad y estructura – uso correcto de emojis, niveles de encabezado, agrupación de problemas
• Profundidad – especificidad de la causa raíz, recomendaciones accionables
• Corrección de dominio – reglas de supresión de MX nulo (por ejemplo, no marcar la falta de MTA-STS en un dominio sin correo), formato específico de alcance para consultas de múltiples dominios

Cada criterio se puntúa de 0 a 2 con un máximo de 26 puntos en bruto, normalizados a una escala de 0 a 1.

Antes de usar el juez a escala, lo validamos. Tres modelos candidatos a juez se ejecutaron 5 veces de forma independiente en las mismas entradas, y medimos la consistencia por criterio: con qué frecuencia el mismo modelo daba la misma puntuación para la misma entrada en ejecuciones independientes. GPT-5.4 con un nivel bajo de esfuerzo de razonamiento resultó ser el mejor: 11 de 13 criterios produjeron puntuaciones idénticas en las 5 ejecuciones, y los promedios por criterio en todas las ejecuciones oscilaron entre 0,81 y 0,88, un rango estrecho que indica una calibración estable. Fue seleccionado como el juez para la ejecución completa de la evaluación.

Evaluamos modelos tanto de proveedores comerciales como de lanzamientos de código abierto:

• OpenAI: GPT-5, GPT-5 mini, GPT-5 nano
• Anthropic: Claude Sonnet 4.6, Claude Haiku 4.5
• Google: Gemini 3.1 Pro, Gemini 3 Flash, Gemini 3.1 Flash Lite, Gemma 4 26B (a través de Vertex AI)
• Código abierto autoalojado: Qwen3.5 122B, Qwen3.6 35B, Gemma 4 26B

Gemma 4 aparece en ambas listas: se ejecutó en nuestra propia infraestructura y a través de Vertex AI, para verificar que nuestra configuración produce resultados comparables a los del proveedor gestionado. Varios modelos se probaron tanto con como sin razonamiento extendido, para entender si la latencia adicional y el costo de tokens producen resúmenes significativamente mejores.

Ejecutamos cada configuración contra el conjunto completo de 100 entradas, con GPT-5 como juez. Esto es lo que obtuvimos.

Gemini 3.1 Pro y Claude Sonnet 4.6 se sitúan en la cima con 0,93 y 0,92. Pero no están en una liga diferente a los modelos por debajo de ellos. Varios modelos de gama media –la mayoría con alguna forma de razonamiento activado– se agrupan entre 0,88 y 0,90, todos dentro de 0,05 del mejor resultado: GPT-5 con razonamiento bajo, Gemma 4 26B con razonamiento extendido y Gemini 3 Flash con razonamiento bajo.

Gemini 3 Flash produjo el mejor equilibrio general en nuestros resultados: puntuación de 0,88, latencia de 7 segundos, $0,76 por 100 consultas –más de 5 veces más económico y más del doble de rápido que Gemini 3.1 Pro. El único modelo más rápido es GPT-5 nano sin razonamiento, que obtiene una puntuación significativamente más baja de 0,58.

Gemma 4 en Vertex AI es la opción viable más eficiente en costo, con $0,17 en total, una puntuación de 0,86 y una latencia de 13 segundos. Se sitúa justo por debajo de Gemini 3 Flash en calidad, pero a menos de una cuarta parte del costo. Para aplicaciones de alto volumen, esa diferencia se acumula rápidamente.

GPT-5 mini con razonamiento bajo también merece mención: 0,87 a $0,46, igualando la puntuación del modelo GPT-5 completo ejecutándose sin razonamiento ($1,70) –misma calidad, una cuarta parte del costo.

Ejecutamos Gemma 4 en nuestra propia infraestructura y también a través de Vertex AI. Los resultados son esencialmente idénticos en ambos modos de razonamiento –0,85 (autoalojado) frente a 0,86 (Vertex AI) sin razonamiento, y 0,90 frente a 0,89 con razonamiento activado. El total de tokens de salida en 100 consultas sin razonamiento también coincide estrechamente: 51.223 (autoalojado) frente a 52.405 (Vertex AI). Para los equipos que ejecutan modelos abiertos en producción, este tipo de verificación cruzada importa: cuando la salida autoalojada se alinea con la API gestionada tanto en calidad como en verbosidad, puedes tener la confianza de que tu implementación está configurada correctamente y que los resultados de la evaluación se transfieren entre entornos.

En los modelos donde se probaron ambos modos, el razonamiento extendido o bajo típicamente añade entre 0,02 y 0,03 a la puntuación:

• GPT-5: 0,89 (bajo) frente a 0,87 (ninguno)
• Claude Haiku 4.5: 0,86 (extendido) frente a 0,83 (ninguno)
• Qwen3.5 122B: 0,85 (extendido) frente a 0,83 (ninguno)

Si esa mejora justifica la latencia y el costo depende de tu situación. Para un resumen de seguridad –donde la tarea es escritura estructurada a partir de evidencia proporcionada en lugar de razonamiento de varios pasos– las ganancias son reales pero no transformadoras.

La excepción clara es GPT-5 nano: sin razonamiento obtiene una puntuación de 0,58, la más baja de toda la evaluación, y es el único modelo que produjo regularmente resúmenes incompletos o mal estructurados. Con un esfuerzo de razonamiento bajo salta a 0,72. Para modelos más pequeños con menor capacidad inherente, el razonamiento puede hacer una mayor parte del trabajo pesado.

Realizar esta evaluación cambió cómo pensamos sobre la selección de modelos para tareas de producción en el rango "desafiante pero no tan difícil como de vanguardia":

1. Las clasificaciones generales evalúan amplitud, no profundidad. El puesto de un modelo en clasificaciones generales no predice cómo se desempeña en una tarea de dominio específico. La única forma de saberlo es evaluarlo con tu carga de trabajo real y tus datos reales.
2. El razonamiento es un equilibrio, no una mejora gratuita. Para la mayoría de los modelos, añade entre 0,02 y 0,03 a la puntuación a costa de una latencia significativa. Si vale la pena depende de tu tarea: para la escritura estructurada fundamentada en evidencia proporcionada, las ganancias son reales pero modestas.
3. Evalúa con datos de producción, no con muestras sintéticas. El muestreo estratificado a partir de consultas reales expuso toda la gama de tipos de tareas que una evaluación con datos sintéticos habría pasado por alto. El modelo que elijas puede comportarse de manera muy diferente en el extremo de tu distribución.
4. El autoalojamiento es viable si lo validas. Los modelos de código abierto ejecutándose en tu propia infraestructura pueden igualar la calidad de la API gestionada, pero solo si lo verificas. La puntuación, la longitud de la salida y el comportamiento de razonamiento deben alinearse antes de implementarlo en producción.

Si quieres ver el tipo de resúmenes que están generando estos modelos, Radar Lite es gratuito: solo introduce un dominio y haz una pregunta.