Batería ciega para evaluar modelos de reasoning

¿Podemos comprobar cómo resuelve un modelo problemas que no conoce de antemano y contrastar sus respuestas con una referencia independiente?

STATUS       PAUSED
AREA         IA / REASONING
CASES        5
MODEL        GPT-OSS 20B
REASONING    Low
RESULT       3 PASS · 1 PARTIAL · 1 FAIL

La pregunta

La prueba nació de un problema bastante concreto. Estaba utilizando ejercicios de planificación para observar cómo razonaban distintos modelos, pero los problemas se habían preparado manualmente. Aunque un modelo resolviera correctamente uno de ellos, siempre quedaba una duda difícil de eliminar: no podía saber si estaba enfrentándose realmente a una combinación nueva o si aquella estructura se parecía demasiado a ejemplos que pudiera haber encontrado previamente.

Quería evitar además otra dificultad habitual al evaluar modelos: utilizar un segundo modelo para decidir si la respuesta del primero era correcta. En algunos problemas eso puede ser inevitable, pero en este caso podía construir una referencia mucho más sólida.

La idea fue generar pequeños problemas nuevos de planificación, calcular por separado su solución óptima mediante código convencional y entregar al modelo únicamente el problema.

La estructura general era esta:

PROBLEMA GENERADO
        ↓
   ┌───────────┐
   │           │
   ↓           ↓
SOLVER       MODELO
EXACTO
   ↓           ↓
ÓPTIMO      RESPUESTA
PRIVADO        ↓
   └────→ COMPARACIÓN

El modelo nunca recibe la solución calculada por el solver.

Eso permite comprobar después no solo si llegó al mismo resultado, sino también si la solución que construyó realmente cumple las reglas del problema.

Qué problemas tenía que resolver

Los casos eran ejercicios de planificación de tareas para dos trabajadores.

Cada problema contiene varias tareas. Cada tarea necesita un tiempo determinado y algunas dependen de otras, de modo que no pueden comenzar hasta que sus predecesoras hayan terminado.

Por ejemplo, imaginemos algo así:

A ─────→ C ─────→ E
          ↑
B ────────┘

D ─────────────→ F

Si C depende de A y B, no puede empezar hasta que ambas hayan terminado. Si solo tenemos dos trabajadores, además tendremos que decidir qué tareas ejecuta cada uno y en qué momento.

Las reglas básicas eran:

• cada trabajador solo puede realizar una tarea simultáneamente;
• una tarea no puede interrumpirse una vez iniciada;
• las dependencias deben respetarse;
• todas las tareas deben completarse;
• el objetivo es terminar el conjunto completo lo antes posible.

Ese tiempo final recibe habitualmente el nombre de makespan.

Un calendario podría representarse, por ejemplo, así:

TRABAJADOR 1
A    0–4
C    4–7
E    7–11

TRABAJADOR 2
B    0–3
D    3–8
F    8–10

La pregunta para el modelo no era simplemente qué tarea debía ejecutarse primero. Tenía que encontrar una asignación completa que respetara todas las restricciones e intentar demostrar que no existía otra que terminara antes.

Por qué necesitaba un solver

En problemas pequeños podemos mirar una solución y pensar que parece buena, pero eso no demuestra que sea la mejor posible.

Supongamos que un modelo propone terminar todas las tareas en 19 horas.

Podemos comprobar que su calendario es válido, pero todavía queda una pregunta:

¿podría existir otro calendario que terminara en 18, 17 o 16?

Para responder a eso utilicé un solver exacto escrito para la prueba. Su trabajo consiste en explorar las distintas asignaciones posibles respetando las restricciones hasta encontrar el tiempo mínimo alcanzable.

El resultado del solver actúa como referencia.

modelo dice      19 h
solver calcula   16 h

→ la solución del modelo no es óptima

o:

modelo dice      19 h
solver calcula   19 h

→ el resultado final coincide con el óptimo

Pero incluso en el segundo caso todavía hay más cosas que comprobar.

Tres preguntas distintas

La batería separaba tres aspectos que es muy fácil mezclar cuando vemos una respuesta bien redactada.

¿Ha encontrado el resultado óptimo?

Es la comparación más sencilla. Si el solver establece que el mínimo es 19 horas y el modelo también responde 19, el resultado numérico es correcto.

¿El calendario que propone es realmente válido?

El modelo puede acertar el número final y, sin embargo, construir una planificación imposible. Podría ejecutar dos tareas simultáneamente con el mismo trabajador, empezar una tarea antes de que termine otra de la que depende o incluso olvidar alguna.

Por eso el calendario se validaba por separado.

¿La explicación demuestra realmente que no existe una solución mejor?

Esta era la condición más exigente.

Encontrar un calendario de 19 horas demuestra que 19 es alcanzable.

No demuestra que 18 sea imposible.

Para afirmar que 19 es el óptimo hace falta además algún argumento válido que establezca un límite inferior de 19 horas.

Esta diferencia terminó siendo una de las partes más interesantes de la prueba.

Cómo se evaluó cada respuesta

La batería contenía cinco problemas de tamaño creciente:

Cada problema se ejecutó una sola vez. No se repetía una consulta porque el resultado hubiera sido malo.

Después se comparaba la respuesta del modelo con la referencia calculada y se utilizaban tres posibles veredictos.

PASS cuando coincidían las tres condiciones:

resultado óptimo
+
calendario válido
+
demostración válida

PARTIAL cuando el resultado y el calendario eran correctos, pero la explicación no demostraba realmente que aquel resultado fuera óptimo.

FAIL cuando el resultado no alcanzaba el óptimo o la solución construida no era válida.

Esta clasificación era más exigente que limitarse a preguntar si el número final coincidía.

Resultados

La primera ronda produjo estos resultados:

Separando las distintas dimensiones:

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

RESULTADO ÓPTIMO        4 / 5
CALENDARIO VÁLIDO       5 / 5
DEMOSTRACIÓN VÁLIDA     3 / 5

Esa diferencia entre 5 / 5, 4 / 5 y 3 / 5 fue precisamente lo que convirtió la prueba en algo más interesante que una simple tabla de aciertos.

Los dos casos que mejor lo muestran son CASE-3 y CASE-4.

CASE-3: detectar correctamente los límites y aun así fallar

En CASE-3, la duración conjunta de todas las tareas era de 32 horas.

Como solo había dos trabajadores, incluso en el mejor escenario imaginable sería imposible terminar en menos de 16 horas:

32 horas de trabajo
÷
2 trabajadores
=
16 horas como mínimo

El modelo calculó correctamente ese límite.

Además encontró un camino de dependencias cuya duración también era de 16 horas. Esto proporciona otra razón independiente por la que el problema no podía resolverse en menos tiempo.

Hasta ese punto, el análisis era correcto.

Sin embargo, el modelo concluyó que no era posible construir un calendario que alcanzara esas 16 horas y propuso 19 como mejor solución.

El solver encontró una planificación válida de 16:

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

Esto permite localizar bastante bien el fallo.

El problema no estuvo en calcular el volumen de trabajo ni en identificar una cadena crítica de tareas. El modelo había obtenido correctamente ambas cosas.

Falló al intentar determinar si todas las restricciones podían encajar simultáneamente en un calendario de 16 horas.

El resultado fue:

RESULTADO       incorrecto
CALENDARIO      válido
DEMOSTRACIÓN    incorrecta

VEREDICTO       FAIL

No es simplemente un “fallo”. Podemos observar en qué parte del problema apareció.

CASE-4: llegar al resultado correcto con una demostración equivocada

CASE-4 produjo una situación casi opuesta.

El modelo propuso terminar el trabajo en 19 horas.

El solver confirmó que 19 era exactamente el mínimo posible y el calendario generado por el modelo era válido.

Si hubiéramos comprobado únicamente el resultado final, este caso habría sido indistinguible de un PASS.

Pero había un problema en la explicación.

Para justificar que no podía existir una solución mejor, el modelo afirmaba que las tareas sumaban 38 horas de trabajo. La suma real era 34.

Había utilizado, por tanto, una premisa falsa dentro del argumento con el que justificaba la optimalidad.

RESULTADO       correcto
CALENDARIO      válido
DEMOSTRACIÓN    incorrecta

VEREDICTO       PARTIAL

El caso resulta interesante precisamente porque el error no cambia la respuesta final.

El modelo llegó al número correcto y construyó una solución correcta, pero la explicación no demostraba aquello que afirmaba demostrar.

Si nuestra evaluación hubiera consistido únicamente en comparar:

respuesta esperada = 19
respuesta modelo   = 19

este matiz habría desaparecido completamente.

Qué permite afirmar esta prueba

Los cinco casos mostraron que el modelo era capaz de construir calendarios válidos en toda la batería y encontró el resultado óptimo en cuatro de ellos.

En tres consiguió además justificar correctamente que su solución era óptima.

También apareció un caso en el que varias partes importantes del análisis eran correctas pero la conclusión final no lo era, y otro en el que la conclusión final era correcta mientras que parte de la justificación contenía un error objetivo.

Eso permite demostrar algo concreto sobre esta ejecución: resultado correcto, solución válida y argumentación válida son propiedades diferentes y pueden separarse en la práctica.

No hace falta inferirlo de forma teórica. Ocurrió dentro de la propia batería.

Qué no permite afirmar

La muestra es deliberadamente pequeña.

Cinco problemas ejecutados con un único modelo y una determinada configuración no permiten caracterizar de forma general su capacidad de razonamiento ni establecer porcentajes fiables de error.

Tampoco permiten afirmar que otro modelo, otra configuración o incluso nuevas ejecuciones sobre problemas distintos producirían el mismo patrón.

La prueba no pretendía responder a esas preguntas.

Su objetivo era mucho más limitado: construir un entorno en el que pudiera separar y comprobar distintas partes de una respuesta, utilizando una referencia determinista siempre que el problema lo permitiera.

Bajo ese objetivo, los cinco casos fueron suficientes para detectar comportamientos que una métrica basada únicamente en la respuesta final habría ocultado.

Por qué no continué manualmente con más modelos

La idea inicial era ejecutar la misma batería con otros modelos y comparar los resultados.

Después de terminar esta primera ronda, el proceso empezó a mostrar otro problema distinto. Cada nueva ejecución exigía repetir una secuencia casi idéntica:

preparar problema
→ ejecutar modelo
→ recoger respuesta
→ registrar métricas
→ validar calendario
→ comparar con solver
→ clasificar resultado

La parte intelectualmente interesante ya estaba en diseñar la prueba, definir qué debía medirse e interpretar los resultados.

El resto empezaba a ser trabajo mecánico.

En lugar de continuar realizando manualmente más rondas, decidí conservar el experimento para retomarlo cuando esa parte pudiera automatizarse.

La siguiente versión tendría que separar todavía mejor IA y determinismo

Si continúo la batería, el diseño que más me interesa no consiste en sustituir el proceso completo por un agente.

Consiste en dejar al agente aquello para lo que resulta útil y mantener determinista aquello que podemos comprobar exactamente.

Algo parecido a esto:

AGENTE
  ↓
ejecuta el modelo
  ↓
captura respuesta
  ↓
extrae la solución propuesta
  ↓
VALIDADOR DETERMINISTA
  ↓
comprueba restricciones
  ↓
SOLVER EXACTO
  ↓
compara con el óptimo
  ↓
registra resultados

El modelo puede seguir resolviendo el problema y el agente puede encargarse de la orquestación, pero la decisión de si un calendario es válido o si alcanza el óptimo no necesita delegarse otra vez en una IA.

Esa separación es, probablemente, el resultado más útil que me dejó esta primera iteración.

No porque cinco problemas permitan juzgar de forma general a un modelo, sino porque fueron suficientes para mostrar algo mucho más práctico: cuando una parte de una respuesta puede comprobarse exactamente, merece la pena construir el sistema de forma que esa comprobación no dependa de confiar en otra respuesta probabilística.