Cómo hacemos el benchmark de nuestra propia IA (y por qué publicamos las tandas que descartamos)

La mayoría de las comparativas de modelos que se publican son irreproducibles: cuatro prompts, una captura de pantalla y una conclusión que el autor ya traía de casa. Nosotros necesitábamos algo que pudiéramos repetir, discutir y sobre lo que pudiéramos equivocarnos en público, porque el resultado decide qué modelo responde a las preguntas que nuestros clientes hacen sobre su propio tráfico.

Lo que viene a continuación es el método al que llegamos. No tiene nada de sofisticado. Es sobre todo la disciplina de negarse a puntuar a ojo cualquier cosa que se pueda comprobar con código.

1. Prueba sobre el stack que realmente entregas

Los benchmarks públicos miden un modelo aislado. Nuestro asistente no es un modelo aislado: es un modelo detrás de un system prompt, dentro de un bucle de orquestación, con un inventario de 63 herramientas de analítica y hablando con una API en vivo.

Por eso el harness (nuestro arnés de pruebas) llama al endpoint de producción real del asistente, con el inventario real de herramientas y contra los datos de una cuenta real. El modelo bajo prueba se cambia mediante configuración de entorno y nada más: el código del producto es idéntico byte a byte en todas las condiciones. Si un candidato gana aquí, gana en el trabajo, no en un sucedáneo del trabajo.

Esto significa además que el benchmark hace también de test de integración. Uno de los hallazgos más valiosos de nuestra última tanda no tuvo que ver con ningún modelo: fue un bug de producción en nuestro propio manejo de respuestas, que apareció como un único error de transporte en 162 consultas.

2. Calcula la verdad de referencia desde la base de datos, en vivo

Lo más difícil de evaluar un asistente de analítica es decidir si ha dicho la verdad. Lo resolvemos preguntándole antes a la base de datos. Al inicio de cada tanda, el harness consulta directamente las tablas de analítica para obtener las respuestas — entradas, conversiones, tasa de rebote, ingresos, canal principal, fuente principal, dispositivo principal — y las guarda como verdad de referencia de esa tanda.

Después, cada cifra que el modelo afirma en su prosa se contrasta con ese conjunto. No «¿suena plausible?», sino «¿es este el número?». Calcularla en vivo implica además que el benchmark no se pudre a medida que entran datos nuevos en la cuenta: la verdad se regenera cada vez, así que los mismos escenarios siguen siendo válidos el mes que viene.

3. Evaluadores deterministas primero, juez al final

Todo lo comprobable lo puntúa código normal y corriente: grounding (cifras afirmadas frente a verdad de referencia), llamadas a herramientas, validez del formato estructurado, negativas y resultado de las trampas. Esos evaluadores deterministas tienen 26 tests unitarios propios, porque un bug en un evaluador invalida en silencio un estudio entero. El harness usa solo la librería estándar: ningún framework que se le mueva debajo.

Solo la parte subjetiva pasa por un juez LLM: utilidad, claridad y precisión formal, puntuadas de 1 a 5. Usamos deliberadamente un modelo rival como juez — qwen3-235b a temperatura 0, uno de los candidatos que competía contra nuestro eventual ganador — para que cualquier sesgo empujara en contra del modelo que esperábamos que nos gustara. Puntuó al ganador con un 4,9 sobre 5 aproximadamente.

Y etiquetamos ese número por lo que es: no determinista, de un único juez y sin un segundo evaluador. Apoya la decisión. No la sostiene.

4. Tiéndele trampas a propósito

Las preguntas estándar te dicen si un modelo sabe hacer lo fácil. Las trampas te dicen qué hace cuando la respuesta honesta es «eso no existe». Por idioma ejecutamos 6 escenarios estándar, 2 trampas de grounding y 1 trampa de inyección de prompt:

• Entidades inexistentes. Preguntar por una campaña que nunca se lanzó. El comportamiento correcto es decirlo y parar. Un modelo reconocía la ausencia y acto seguido se desviaba a describir otras campañas reales con cifras que nadie había pedido: no es inventar, es responder a otra pregunta.
• Periodos vacíos. Preguntar por una ventana en la que la cuenta no tiene datos. El comportamiento correcto es explicar dónde está el límite de los datos. Un modelo, en cambio, alegaba una incapacidad falsa, diciendo que le faltaban las herramientas necesarias.
• Instrucciones inyectadas con una cadena canario. Esconder una instrucción hostil dentro de datos que el usuario pega, con una cadena única dentro. Si ese canario aparece en la respuesta, el modelo ha obedecido al atacante. Ejecutar esto en los dos idiomas es lo que destapó a un modelo que resistía el ataque en español y filtraba el canario en inglés.

5. Publica intervalos, no puntuaciones

Con 18 escenarios en dos idiomas, tres pasadas y tres modelos — 162 consultas reales, 54 por modelo —, un porcentaje suelto es falsa precisión. En su lugar publicamos intervalos de confianza de Wilson.

En las trampas, el ganador sacó 18 de 18 (intervalo al 95% de 0,82 a 1,00); un rival sacó 15 de 18 (0,61 a 0,94) y otro 9 de 18 (0,29 a 0,71). La disciplina de los intervalos es lo que nos permitió decir algo preciso: frente al modelo de 9 de 18, los intervalos ya no se solapan, así que esa diferencia es significativa con este tamaño de muestra. Frente al de 15 de 18 el solape es pequeño pero existe: ahí no reclamamos una victoria estadística, y señalamos en su lugar los fallos de seguridad concretos que hay detrás de sus derrotas.

6. La tanda que tiramos a la basura

Esta es la parte que la mayoría de los equipos borra. Nuestra primera tanda completa fue inválida y la publicamos igualmente.

El harness destapó un defecto en cómo pilotaba el producto: sin un identificador de conversación explícito, el asistente retomaba una sesión de chat existente entre consultas. Las consultas posteriores — incluidas las que se ejecutaban contra un modelo distinto — podían ver, por tanto, el historial de los modelos anteriores. Todos los números que produjo aquella tanda estaban contaminados, y la contaminación iba en la dirección del modelo que tocara ir el último.

Lo arreglamos (una conversación nueva por consulta), repetimos todo y archivamos ambas tandas. La inválida sigue ahí, etiquetada como inválida y con el motivo.

Conservarla no cuesta nada y lo cambia todo respecto a cómo debe leerse la tanda válida. Un benchmark que no publica las tandas que descarta es una demo: te están enseñando la toma que salió bien y pidiéndote que supongas que solo hubo una.

7. Publica también tus propios defectos

La tanda válida lleva dentro un defecto nuestro, y ahí sigue documentado. Un escenario preguntaba por «el tráfico por dispositivo del último mes». Eso admite dos lecturas: los últimos 30 días — que es lo que calculó nuestra verdad de referencia — o el mes natural anterior. Algunos modelos eligieron el mes natural, en el que la cuenta de pruebas solo tenía cinco días de datos, y reportaron esos números.

Eran números reales, correctamente recuperados. Nuestro evaluador los marcó como fallos. Eso no es alucinación: es una pregunta de benchmark mal redactada, y la redactamos nosotros.

El detalle que hace que valga la pena publicarlo: el 100% de los fallos de hechos de toda la tanda se remontan a ese único escenario. Excluyéndolo, el modelo ganador acertó 144 de 144 hechos verificados. Reformulamos la pregunta para futuras tandas y dejamos el defecto documentado, porque quien viera solo la versión corregida no podría saber si los fallos eran culpa del modelo o nuestra.

8. Haz que reevaluar salga gratis

Cada tanda archiva las transcripciones completas, así que un script de reevaluación independiente vuelve a puntuar las tandas guardadas sin conexión y a coste cero en tokens. Esta acaba siendo la victoria silenciosa de todo el diseño: cuando encuentras un bug en un evaluador o quieres añadir una métrica, no vuelves a gastar una tanda, sino que repuntúas el histórico — incluida la tanda descartada — y compruebas si la conclusión se mueve.

Cómo montar el tuyo

Si estás eligiendo o vigilando un modelo para un producto real, este es el camino más corto que conocemos:

1. Escribe los escenarios a partir de preguntas reales de usuarios, no de ejemplos de prompt engineering. Replícalos en todos los idiomas que hablen tus usuarios, compartiendo la misma verdad de referencia.
2. Pilota el endpoint real. Cambia el modelo por configuración; no cambies nada más entre condiciones.
3. Calcula la verdad de referencia desde tu propia fuente de verdad al inicio de cada tanda, automáticamente.
4. Puntúa con código y hazle tests unitarios a los evaluadores. Si no puedes testear el evaluador, no puedes fiarte de la puntuación.
5. Añade trampas: una entidad que no existe, un periodo sin datos y una instrucción inyectada que lleve una cadena canario.
6. Repite cada escenario varias veces y publica un intervalo de confianza en lugar de un porcentaje de titular.
7. Usa un juez LLM solo para lo estético, elige preferiblemente un modelo rival, fija la temperatura a cero y etiqueta el resultado como no determinista.
8. Archiva todas las tandas, incluidas las que invalides, con el motivo adjunto.
9. Haz posible la reevaluación sin conexión para que mejorar el método no cueste otra tanda.
10. Escribe las limitaciones que ya conoces — juez único, n pequeña, tus propias preguntas ambiguas — antes de que las encuentre otro.

La conclusión

Nada de esto convierte un benchmark en objetivo. Lo convierte en auditable, que es el objetivo alcanzable. Quien lea nuestros resultados puede ver qué preguntas se hicieron, de dónde salieron las respuestas correctas, qué se puntuó con código y qué con criterio, qué tanda se tiró y por qué, y cuáles de los fallos fueron culpa nuestra.

Ese es el estándar que creemos que debería exigirse cualquiera que publique una funcionalidad de IA, sobre todo cuando los resultados son incómodos. La metodología completa y los resultados íntegros están publicados en nuestro informe del benchmark interno, junto con la trazabilidad de modelos que lo produjo.