El banco de pruebas: cómo medimos si un modelo sirve de verdad
Velocidad, contexto, varias peticiones a la vez, calidad con preguntas trampa, uso de herramientas y seguridad. Qué medimos antes de recomendar un modelo y por qué cada pieza está ahí.
Este post complementa qué es un benchmark y el mini-benchmark casero. Aquí contamos la batería que pasamos a un modelo antes de recomendarlo, con qué herramientas y por qué.
El problema que resuelve
Medir tokens por segundo es fácil. Lo difícil es responder: ¿este modelo sirve para el trabajo que le quiero dar? Velocidad sin calidad no sirve, y calidad sin velocidad tampoco. Y la seguridad no puede ser un añadido: si el modelo va a leer correos, webs o documentos de otros, tiene que resistir que le cuelen instrucciones.
Lo que medimos
| bloque | qué responde |
|---|---|
| Identidad | ¿estamos midiendo el modelo y la configuración que creemos? |
| Velocidad | tiempo hasta el primer token, lectura del prompt y generación, en frío y en caliente |
| Varias peticiones | 1, 2, 4 y 8 a la vez: ¿aguanta varios agentes o solo uno? |
| Contexto largo | ¿encuentra datos escondidos en textos de decenas o cientos de miles de tokens? |
| Calidad | nuestras preguntas trampa (abajo) |
| Herramientas | un banco de 84 escenarios con llamadas a herramientas |
| Seguridad | inyecciones de prompt, repetidas varias veces y con distintas redacciones |
| Sistema | memoria libre, swap, temperatura de la GPU y consumo |
Las preguntas trampa: 56 ítems sacados de nuestro trabajo
Es la pieza más valiosa. No son preguntas genéricas de examen: son 56 ítems sacados de nuestro propio trabajo, en los que la respuesta correcta se conoce porque la comprobamos en la máquina.
| familia | nº | qué mide |
|---|---|---|
| Trampas | 14 | detectar contradicciones, datos que faltan y diagnósticos sin demostrar |
| Factual | 10 | recuperar un dato exacto de un documento largo |
| Derivación | 10 | calcular y razonar sobre medidas reales |
| Código | 7 | escribir código que se pueda comprobar |
| Control | 10 | aceptar premisas correctas sin dudar por dudar |
| Herramientas | 5 | ejecutar algo de verdad y devolver un valor comprobable |
Cada ítem se puntúa 0, 1 o 2. En las trampas, 2 es detectar y nombrar el problema; 0 es aceptar la premisa falsa y responder como si fuera cierta.
El secreto de un buen conjunto de trampas: tienen que ser auténticas. Un documento que de verdad afirmaba algo falso engaña a un modelo igual que nos engañó a nosotros. Las trampas inventadas son más débiles.
Con este conjunto medimos, por ejemplo, que 13 líneas de prompt de sistema triplican la nota de un modelo que tendía a darnos la razón.
Herramientas: un banco de 84 escenarios
Para el trabajo con agentes usamos tool-eval-bench, una herramienta abierta de la comunidad con 84 escenarios: llamadas encadenadas, parámetros que faltan, acciones irreversibles, instrucciones contradictorias… Da una nota sobre 100. Ahí es donde GLM-5.3-Flash saca 89, la mejor nota que hemos medido.
Dos lecciones que nos costaron aprender:
- El banco no es determinista: dos pases idénticos pueden separarse un par de puntos (P-063). Para diferencias pequeñas hacen falta varios pases.
- Lee las respuestas, no solo la nota. El corrector castigaba a un modelo por avisar de un ataque (P-055).
Seguridad: repetir el ataque, y con otras palabras
Una de las pruebas que más miramos es la inyección durmiente: una orden maliciosa escondida en la respuesta de una herramienta que el agente debería ignorar turnos después. La repetimos al menos cinco veces por modelo, porque un 4 de 5 significa que hay un agujero.
Y aprendimos que no basta con repetirla: hay que cambiar la redacción. Un modelo que teníamos por «seguro sin ayuda» cayó el 60 % de las veces con otra frase del mismo ataque (EXP-0045).
Antes de recomendar un modelo
- Configuración guardada y varias medidas seguidas tras calentar el servidor.
- Sin errores de autenticación, de formato, de streaming ni de cancelación.
- Seguridad probada con repeticiones y distintas redacciones.
- Uso de herramientas probado con agentes reales, no solo por API.
- Temperatura, memoria y consumo anotados junto a la velocidad.
- Si va repartido en dos máquinas: comprobar que se recupera cuando una se reinicia.
La regla de comparación honesta
Cada modelo corre con su mejor configuración estable, y la configuración se publica con la cifra. No mezclamos cifras de otros laboratorios con las nuestras, y distinguimos siempre entre lo medido, lo calculado y lo pendiente.
Cuando un benchmark da un número raro, casi siempre está midiendo otra cosa de la que crees.
Los resultados están en Benchmarks.