Batería ciega para evaluar modelos de reasoning

¿Podemos comparar modelos con problemas que ninguno de ellos haya visto previamente?

STATUS       PAUSED
AREA         IA / REASONING
START        25 AUG 2026
HARDWARE     RTX 5080 16 GB
CASES        5
MODEL RUN    GPT-OSS 20B · LOW
RESULT       3 PASS · 1 PARTIAL · 1 FAIL

La pregunta

Después de varias pruebas con modelos locales apareció una duda bastante incómoda.

Estaba utilizando problemas de planificación para comparar su capacidad de razonamiento, pero los problemas los habíamos planteado manualmente. Aunque un modelo resolviese correctamente uno de ellos, era difícil saber hasta qué punto estaba razonando realmente sobre un caso nuevo o reconociendo una estructura parecida a ejemplos que pudieran formar parte de sus datos de entrenamiento.

Necesitaba problemas que pudiera verificar con exactitud pero cuya solución no conociese el modelo.

La idea fue construir una batería ciega.

GENERADOR
    ↓
PROBLEMA NUEVO
    ↓
SOLVER EXACTO
    ↓
ÓPTIMO PRIVADO
    ↓
PROMPT
    ↓
MODELO
    ↓
COMPARACIÓN

El modelo recibe el problema. Nunca recibe la solución.

El experimento

Construí en Python un pequeño generador de problemas de scheduling con dos trabajadores.

Cada problema contiene un conjunto de tareas con una duración determinada y dependencias entre ellas. Una tarea no puede empezar hasta que hayan terminado todas sus predecesoras, cada trabajador solo puede ejecutar una tarea simultáneamente y las tareas no pueden interrumpirse.

El objetivo es encontrar el calendario que complete todo el trabajo en el menor tiempo posible.

Para poder repetir exactamente la batería utilicé una semilla fija:

20260825

El generador produjo cinco casos de dificultad creciente:

Los dos últimos incluyen además una condición deliberada: su óptimo no puede deducirse simplemente dividiendo el trabajo total entre dos o buscando el camino crítico.

Necesitaba una fuente de verdad

No quería utilizar otro LLM para decidir si la respuesta de un LLM era correcta.

Así que la batería incluye un solver exacto.

El solver explora los estados posibles mediante programación dinámica y memoización: qué tareas han terminado, qué está ejecutando cada trabajador y cuánto tiempo le queda. Prueba las asignaciones legales, permite incluso tiempos de espera intencionados cuando pueden formar parte de la solución óptima y calcula el makespan mínimo.

Después existe una segunda validación independiente que comprueba que el calendario reconstruido contiene todas las tareas, respeta sus duraciones y dependencias, no introduce solapamientos y termina exactamente en el óptimo calculado.

Eso cambia bastante el experimento.

Ya no estamos comparando una respuesta de un modelo con nuestra impresión de que «parece correcta». Tenemos una referencia exacta.

Primera ronda: GPT-OSS 20B

La primera ronda se hizo con:

MODEL          gpt-oss-20b
REASONING      Low
CONTEXT        8192
GPU OFFLOAD    24 / 24

La regla era utilizar la primera ejecución comparable. Nada de repetir una pregunta hasta conseguir una respuesta buena.

Además del resultado final registré tokens, velocidad, stop reason, validez del calendario y validez de la demostración de optimalidad.

Utilicé tres veredictos:

• PASS cuando el makespan era óptimo, el calendario era factible y la demostración de optimalidad era válida;
• PARTIAL cuando el resultado y el calendario eran correctos, pero la demostración no justificaba realmente el óptimo;
• FAIL cuando la respuesta no alcanzaba el óptimo o la solución propuesta no era válida.

El resultado agregado fue:

PASS COMPLETOS          3 / 5
PARTIAL                 1 / 5
FAIL                    1 / 5

MAKESPAN CORRECTO       4 / 5
CALENDARIO FACTIBLE     5 / 5
PRUEBA DE OPTIMALIDAD   3 / 5

TOKENS TOTALES          17.963
VELOCIDAD MEDIA         ~209,7 tok/s
CONTEXT LIMIT           0 / 5

El caso que cambió la lectura del resultado

CASE-3 fue el más interesante.

GPT-OSS calculó correctamente que el trabajo total era de 32 horas y, por tanto, que con dos trabajadores existía un límite inferior de 16 horas.

También encontró correctamente un camino crítico de 16 horas.

Hasta ahí, bien.

Pero después concluyó que alcanzar ese límite era imposible y propuso como óptimo un calendario de 19 horas.

El problema es que sí existe un calendario válido de 16 horas:

TRABAJADOR 1
A    0–5
E    5–10
F   10–11
I   11–16

TRABAJADOR 2
D    0–2
B    2–5
C    5–8
G    8–12
J   12–15
H   15–16

El modelo había encontrado correctamente las piezas necesarias para demostrar que 16 horas era el mínimo posible, pero falló al decidir si ese mínimo podía alcanzarse.

No fue un problema de contexto: terminó normalmente y utilizó 2.790 tokens. Fue un fallo de razonamiento combinatorio.

Y después ocurrió algo todavía más incómodo

En CASE-4 ocurrió casi lo contrario.

GPT-OSS respondió 19 horas, que era el resultado correcto, y produjo un calendario válido.

Pero su demostración estaba mal.

Afirmó que la suma de duraciones era 38 horas cuando realmente era 34. A partir de ese error construyó un argumento incorrecto para justificar una respuesta que, casualmente, sí era correcta.

El resultado final era bueno.

El razonamiento que lo justificaba, no.

Resultado de la ronda

Los cinco casos dejaron tres mediciones distintas:

RESPUESTA CORRECTA
        ≠
CALENDARIO VÁLIDO
        ≠
DEMOSTRACIÓN CORRECTA

GPT-OSS produjo calendarios factibles en los cinco casos, acertó el makespan en cuatro y demostró correctamente la optimalidad en tres. Esos resultados explican los tres PASS, el PARTIAL de CASE-4 y el FAIL de CASE-3.

Por qué la paré

La batería estaba diseñada originalmente para repetir los cinco casos con Gemma 4 12B QAT y Qwen3 4B Thinking.

No lo hice.

Después de completar GPT-OSS, el experimento se había convertido en una secuencia bastante mecánica:

copiar prompt
→ ejecutar
→ esperar
→ copiar respuesta
→ copiar métricas
→ validar
→ registrar
→ repetir

Seguir manualmente con otras diez ejecuciones iba a producir más datos, pero cada vez menos aprendizaje nuevo.

Así que decidí pausar la batería.

No porque hubiera fallado ni porque hubiera dejado de ser útil. La pausé porque repetir más rondas manuales empezaba a aportar menos aprendizaje que resolver el siguiente problema: automatizar la ejecución sin perder una fuente de verdad independiente.

Siguiente paso

El generador, el solver y los casos se conservan.

La idea es recuperar la batería cuando tenga sentido automatizarla mediante agentes.

Entonces el proceso puede convertirse en algo parecido a:

AGENTE
  ↓
carga / selecciona modelo
  ↓
ejecuta batería
  ↓
captura respuesta y métricas
  ↓
valida con solver
  ↓
compara con óptimo
  ↓
genera informe

Ahí la parte humana vuelve a estar donde aporta más: diseñar la prueba, decidir qué merece medirse e interpretar el resultado.

Y la máquina se queda con la repetición.