Brida
La mayoría de benchmarks de IA piden a un modelo resolver una tarea grande y después reducen el resultado a una sola puntuación. ReflexBench empieza en otro lugar: decisiones pequeñas y repetidas que el software y los agentes necesitan tomar rápido, barato y con un contrato tipado estable.
Hoy publicamos ReflexBench v1.0.0, un benchmark abierto y un arnés de evaluación reproducible para modelos System One y motores de decisión tipada.
El benchmark se organiza alrededor de tres formas de decisión acotadas:
- Binary / Noul — una decisión sí/no calibrada, con abstención cuando el motor la soporta.
- Choice — seleccionar entre un conjunto limitado de opciones.
- Score — devolver una puntuación semántica acotada que el software pueda consumir directamente.
El objetivo no es declarar un “mejor modelo” universal. El objetivo es hacer medibles los compromisos importantes: corrección, calibración, consistencia multilingüe, robustez al orden de opciones, cardinalidad soportada, comportamiento ante fallos y el valor de la política determinista alrededor del modelo.
Por qué la IA System One necesita su propia capa de evaluación
Los grandes modelos de razonamiento son muy potentes, pero muchas decisiones de producción no necesitan una cadena larga de razonamiento. Un agente que decide si debe despertarse, un pipeline que clasifica un evento entrante o un producto que selecciona una acción entre unas pocas opciones necesitan un juicio rápido y acotado.
A ese espacio lo llamamos System One AI: decisiones semánticas inmediatas con contratos de salida explícitos.
Un benchmark útil para este espacio tiene que medir más que accuracy. Un modelo correcto el 90% de las veces pero mal calibrado, frágil al orden de las opciones o incapaz de abstenerse puede ser más difícil de operar que uno ligeramente menos preciso pero estable.
Por eso ReflexBench publica las dimensiones por separado en lugar de esconderlas en un único número de leaderboard.
Qué mide ReflexBench v1
El protocolo v1 incluye:
- evaluación de motores sobre el mismo corpus;
- calibración de probabilidad y comportamiento de confianza;
- contratos Binary/Noul, Choice y Score;
- carriles en inglés y español;
- robustez al orden de opciones;
- cardinalidad y límites de capacidad de Choice;
- receipts legibles por máquina;
- fallos retenidos en lugar de filas eliminadas silenciosamente;
- evaluación same-response, donde se mantiene fija la respuesta del modelo y cambia únicamente la política determinista de Reflex;
- gates ciegos de workflow para medir si el sistema completo mejora de verdad la tarea posterior.
El arnés y la metodología son públicos. El protocolo v1 queda congelado para que futuros resultados de motores y checkpoints sigan siendo comparables.
Los primeros resultados públicos
Hay un resultado especialmente importante para cómo pensamos Brida Reflex.
En los fixtures públicos same-response, la respuesta subyacente de Jev se mantiene fija. Aplicar la política determinista de Reflex Core mueve el resultado medido de 96,4% a 100,0%: 4 rescates, 0 daños y 0 llamadas adicionales al modelo.
No es una afirmación de que un harness pueda mejorar mágicamente cualquier modelo. Es evidencia de una idea más concreta: en sistemas de decisión acotados, una política determinista alrededor de un motor probabilístico puede eliminar modos de fallo conocidos sin pagar otra inferencia.
Después lo probamos en una réplica ciega separada. Gate v2 completó las 150 filas y pasó de 76,7% a 82,0%, una mejora de +5,3 puntos porcentuales, con un intervalo bootstrap pareado del 95% de +1,3 a +10,0 puntos. El gate registró 10 rescates y 2 daños.
También publicamos el primer intento fallido. Gate v1 se conserva como FAIL formal porque un error 503 del proveedor dejó la ejecución en 149/150. En las filas completadas pasó de 45,0% a 64,4%, pero una ejecución incompleta no se presenta como un benchmark aprobado.
Ese fallo forma parte del registro a propósito.
Mismo corpus, receipts reales
ReflexBench incluye además un cohort público difícil para comparar motores. En nuestra ejecución, TypeSafe Jev alcanzó 73,0% sobre las mismas 111 filas. Una configuración upstream de kshetrajna12/reflex con Qwen3.5-2B alcanzó 41,4% sobre ese mismo cohort local.
Esos números son útiles, pero no constituyen un ranking global. Los motores tienen superficies de despliegue, latencia, calibración y límites de capacidad diferentes. ReflexBench mantiene esas dimensiones visibles y publica los receipts necesarios para inspeccionarlas.
Por la misma razón no mezclamos latencia local y hosted para declarar un único “ganador de velocidad”. La inferencia local normalizada por hardware y la latencia de una API alojada son mediciones distintas.
Search y retrieval van antes del modelo
La búsqueda web puede mejorar mucho la calidad cuando una decisión depende de evidencia reciente o ausente. Pero añadir búsqueda silenciosamente a un modelo y no a otro invalida la comparación del modelo.
Nuestro patrón de integración es explícito:
web / search / retrieval
↓
filtros de procedencia + frescura
↓
evidencia acotada
↓
modelo System One
↓
política / revisión ReflexAsí podemos evaluar la calidad de retrieval por separado de la calidad de decisión. Un futuro carril con retrieval puede añadirse como extensión identificada del protocolo sin fingir que “tener internet” es inteligencia intrínseca del modelo.
Metodología abierta, ventaja operativa privada
La publicación incluye el contrato del benchmark, metodología, corpora públicos sintéticos, arnés, receipts y verificaciones de release.
El control plane alojado de Brida, routing, credenciales de proveedores, sistemas de tenant, corpora privados y futuros hidden gates siguen siendo privados. Queremos que el protocolo de evaluación sea inspeccionable y útil fuera de Brida sin convertir la infraestructura operativa en teatro de benchmark.
El ecosistema público de Reflex tiene ahora tres superficies complementarias:
- Brida Reflex — registro abierto y recipes de decisión.
- Brida SDK — superficie pública de integración.
- ReflexBench — benchmark, metodología y receipts reproducibles.
v1 es un protocolo histórico, no un objetivo móvil
ReflexBench v1 queda congelado. Nuevos resultados de modelos o checkpoints pueden añadirse en v1.x si utilizan el protocolo sin cambios. Los cambios materiales del corpus, scoring o metodología pasarán a ReflexBench v2.
Esa distinción importa. Un benchmark gana valor cuando sus resultados históricos siguen siendo interpretables después de que aparezcan modelos nuevos.
El repositorio incluye los resultados completos, la metodología, benchmark card, receipts y verificación del release manifest.