Cuando lees que un modelo alcanza 95.5% en SWE-bench Verified, parece la prueba definitiva de su capacidad. Pero ese porcentaje no se midió sobre el modelo que tú usas en producción: se midió sobre una versión sin clasificadores de safety. Aquí desarmamos los principales benchmarks de modelos de lenguaje y te damos un marco para distinguir evidencia real de marketing, útil si construyes o evalúas sistemas con LLMs.

¿Qué miden los benchmarks de ingeniería de software?

En ingeniería de software hay cuatro evaluaciones que importan, y cada una mide algo distinto.

SWE-bench toma issues reales de GitHub y le pide al modelo un parche que pase los tests [00:31]. Tiene variantes con propósitos específicos:

• Verified usa 500 problemas confirmados como resolubles.
• Pro trabaja con repositorios activos y cambios multi-archivo para reducir contaminación.
• Multilingual extiende la prueba a nueve lenguajes.
• Multimodal agrega screenshots al contexto.

La pregunta de fondo es simple: ¿puede el modelo leer un bug report real y producir un fix funcional?

¿Cómo evalúan calidad FrontierCode, Terminal-Bench y CursorBench?

FrontierCode de Cognition usa 150 tareas basadas en pull requests reales: un websocket roto, hardening de un bundle, extensión de reglas de linting [01:00]. La diferencia clave es que también evalúa calidad de código, no solo si el test pasa. Fable 5 obtuvo 29.3% en el subconjunto Diamond, contra 5.7% de GPT 5.5 [01:17].

Terminal-Bench 2.1 coloca al modelo dentro de un shell real, ejecutando comandos y navegando el sistema [01:26]. Y CursorBench deriva del uso real de desarrolladores dentro de Cursor; ahí Fable 5 alcanzó 72.9% a effort máximo [01:40].

¿Qué es SWE-bench Verified? Es un subconjunto de 500 issues reales de GitHub confirmados como resolubles, donde el modelo debe generar un parche que pase los tests automatizados del repositorio.

¿Qué tan lejos están los modelos del razonamiento real?

En matemáticas y razonamiento, los benchmarks van desde competencias de secundaria hasta problemas de investigación activa.

• USAMO 2026 evalúa demostraciones formales multi-paso, no respuestas numéricas. Mythos 5 sacó 99.8% [01:59].
• ArxivMath usa problemas de papers académicos de marzo y abril de 2026 para evitar contaminación. Mythos 5 llegó a 78.5% [02:10].
• RiemannBench contiene 25 problemas escritos por investigadores sobre su propio trabajo, promediando cuatro intentos por problema [02:15].
• CritPt simula proyectos de investigación en once subcampos de física. Mythos 5 sacó 28.6%, lo que muestra cuán lejos estamos del razonamiento genuino de investigación [02:28].

¿Por qué Mythos 5 y Fable 5 no son el mismo modelo?

Aquí viene el detalle que cambia toda la lectura. En los benchmarks anteriores el nombre que aparece es Mythos 5, no Fable 5. Ese es el asterisco.

Piensa en un fabricante de autos que publica la velocidad máxima lograda en circuito cerrado con la versión stripped-down de competición, pero te vende la versión de calle con todo el equipamiento de seguridad [02:42]. Eso es exactamente lo que pasa con los modelos de lenguaje: el modelo evaluado y el modelo que responde tus requests no son la misma máquina.

Mythos 5 es la versión sin clasificadores de safety. Fable 5, el que llega cuando haces un request, tiene una capa encima que intercepta, bloquea y redirige [00:15]. Mismo nombre en el titular, máquina diferente bajo el capó.

¿Cómo afecta la capa de safety a los resultados reales?

El impacto se ve con números concretos:

• En ExploitBench, Mythos 5 sacó 78%; Fable 5 en producción redirige queries de ciberseguridad a Opus 4.8, que saca 40%. Casi la mitad [02:56].
• En BioMysteryBench no hay score de Fable 5 porque el clasificador intercepta la mayoría de queries de biología antes de que el modelo responda [03:10].
• En ProgramBench, que evalúa reconstrucción de comportamiento de binarios, directamente no se reportó número para Fable 5 [03:20].
• En tareas ofensivas de ciberseguridad, Fable 5 con safeguards activos hizo 0% de progreso [03:31].

¿Cómo saber qué modelo respondió tu request?

Ya conoces response.model del primer request. Súmale dos señales más para tener trazabilidad real.

El fallback content block dentro de response.content te dice dónde ocurrió el switch, con campos from y to [03:52]. Y usage.iterations registra cada intento: un decline aparece con cero output tokens, y el modelo que sirvió aparece como type: fallback_message [04:01].

El truco está en el sticky routing. Después de un fallback, los requests siguientes en la misma conversación pueden ser servidos por el modelo fallback durante aproximadamente una hora, sin fallback content block. Parecen respuestas normales de Fable 5, pero Opus las respondió [04:13]. Sin instrumentación explícita, tus métricas mienten.

¿Qué es el sticky routing? Es un comportamiento donde, tras un fallback, las respuestas posteriores de la conversación siguen siendo servidas por el modelo alterno durante aproximadamente una hora, sin marcarlo explícitamente.

¿Qué preguntas hacerle a cualquier benchmark antes de creerlo?

Antes de confiar en cualquier número de benchmark, hazte cinco preguntas [04:31]:

1. ¿Qué versión exacta del modelo se testeó?
2. ¿Qué configuración de effort y sampling usaron?
3. ¿Estaban los safeguards activos?
4. ¿Cuántos intentos se promediaron?
5. ¿De dónde vienen los números de los competidores?

Si alguna respuesta falta, el número es marketing, no evidencia [04:48]. La gráfica de barras de un lanzamiento es el punto de inicio para preguntas, no una conclusión.

¿Por qué un mismo modelo da resultados distintos en producción y en el paper? Porque el modelo evaluado suele estar sin clasificadores de safety, mientras que el modelo en producción tiene capas que interceptan o redirigen queries a modelos secundarios.

En la siguiente clase vamos a convertir este marco crítico en algo ejecutable: una comparativa reproducible entre Fable 5 y Opus 4.8 con tu propio workload, midiendo tokens, latencia y calidad, segregados por el modelo que realmente sirvió cada turno [04:59]. Cuéntame en los comentarios qué benchmark te ha hecho dudar últimamente.