IA · reasoning · LLM · evaluación
Un LLM puede darte la respuesta correcta por el motivo equivocado
Qué cambia cuando un modelo acierta el resultado pero falla en el razonamiento que utiliza para justificarlo.
Evaluar un modelo de IA parece sencillo hasta que intentas comprobar algo más que su respuesta final.
Le planteas un problema, comparas la solución con la respuesta correcta y marcas una casilla:
ACIERTO
o
FALLOEl problema es que esa clasificación puede ocultar bastante información.
Durante una batería de pruebas con un modelo de reasoning me encontré con dos casos casi opuestos.
En uno, el modelo identificó correctamente los límites del problema, pero terminó proponiendo una solución peor que la óptima.
En otro llegó exactamente a la respuesta correcta, pero la demostración que utilizó para justificarla contenía un error.
El segundo caso es probablemente el más incómodo.
Porque si solo hubiera mirado el resultado final, habría contado como un acierto.
El resultado no cuenta toda la historia
La prueba utilizaba problemas de planificación de tareas.
Hay dos trabajadores, un conjunto de tareas con distintas duraciones y dependencias entre ellas, y el objetivo consiste en encontrar el calendario que termina todo el trabajo en el menor tiempo posible.
Para poder evaluar las respuestas construí una batería de problemas inéditos y un solver exacto que calculaba el óptimo real.
Eso permitía comprobar tres cosas por separado:
RESPUESTA FINAL
CALENDARIO PROPUESTO
DEMOSTRACIÓN DE OPTIMALIDADAl principio parecen tres formas de mirar prácticamente lo mismo.
No lo son.
La primera ronda con GPT-OSS 20B dejó bastante clara la diferencia.
El modelo produjo calendarios factibles en los cinco casos.
Acertó el makespan óptimo en cuatro.
Pero solo justificó correctamente la optimalidad en tres.
Dependiendo de qué métrica utilizara, la lectura del mismo experimento podía cambiar bastante.
Cuando sabes cuál debería ser la respuesta y aun así fallas
En uno de los casos, el trabajo total sumaba 32 horas.
Con dos trabajadores eso establece inmediatamente un límite inferior de 16 horas.
El modelo encontró además un camino crítico de exactamente 16 horas.
Es decir, había identificado correctamente dos piezas importantes de la solución:
carga mínima posible 16 h
camino crítico 16 hDespués concluyó que alcanzar ese límite era imposible.
Su respuesta final fue:
19 hPero existía un calendario perfectamente válido de 16 horas.
El fallo resulta interesante porque no parece el de un modelo completamente perdido.
Había entendido buena parte de la estructura del problema.
Había calculado correctamente los límites.
Lo que falló fue la parte combinatoria: decidir si esos límites podían alcanzarse simultáneamente mediante una asignación válida de tareas.
Una evaluación basada únicamente en la respuesta final lo clasificaría como un fallo.
Eso es correcto, pero incompleto.
También interesa saber dónde falló.
Más incómodo: acertar por una justificación incorrecta
El siguiente caso produjo la situación contraria.
El modelo respondió:
19 hY 19 horas era, efectivamente, el óptimo.
El calendario que construyó también era válido.
Aparentemente, un acierto perfecto.
Hasta revisar la demostración.
GPT-OSS afirmó que la suma de las duraciones de las tareas era de 38 horas.
En realidad eran 34.
A partir de ese dato incorrecto construyó parte del argumento con el que justificaba que 19 horas era el mínimo.
La respuesta era correcta.
El calendario era correcto.
La demostración no.
RESULTADO CORRECTO
+
CALENDARIO CORRECTO
+
ARGUMENTO INCORRECTOSi nuestro benchmark solo pregunta «¿cuál es la respuesta?», ese caso recibe exactamente la misma puntuación que una solución correctamente razonada.
Y esa equivalencia empieza a ser problemática cuando precisamente queremos evaluar capacidad de razonamiento.
Una respuesta correcta no demuestra un razonamiento correcto
Es tentador utilizar el resultado final como sustituto de todo lo demás.
Tiene una ventaja evidente: es fácil de medir.
Si el óptimo es 19 y el modelo responde 19:
PASSPero una coincidencia entre la respuesta esperada y la respuesta generada no demuestra por sí sola que el proceso utilizado para llegar hasta ella sea válido.
Puede haber ocurrido algo mejor:
razonamiento válido
→ respuesta correctapero también algo mucho menos tranquilizador:
razonamiento incorrecto
→ respuesta correctaEn un problema pequeño, donde podemos verificar cada paso, podemos detectar la diferencia.
En problemas complejos esa comprobación puede ser mucho más difícil.
Y precisamente ahí es donde más peligroso resulta utilizar la respuesta final como única señal de calidad.
Separar lo que estamos evaluando
La prueba me obligó a dejar de tratar «resolver el problema» como una sola métrica.
En este tipo de tarea hay, como mínimo, tres niveles.
1. ¿La respuesta final es correcta?
Es la comprobación más sencilla.
En el experimento:
makespan correcto
4 / 52. ¿La solución construida es válida?
Un modelo puede dar un tiempo correcto y después describir un calendario que viola dependencias o asigna dos tareas simultáneas al mismo trabajador.
Aquí GPT-OSS lo hizo especialmente bien:
calendarios factibles
5 / 53. ¿La justificación demuestra realmente lo que afirma?
Esta era la parte más exigente.
pruebas de optimalidad correctas
3 / 5La diferencia entre 4/5 y 3/5 puede parecer pequeña en una batería de cinco problemas.
Conceptualmente no lo es.
Está midiendo una capacidad diferente.
Evaluar mejor requiere poder verificar
La parte más útil del experimento terminó siendo algo que inicialmente parecía infraestructura auxiliar: el solver exacto.
No quería utilizar otro LLM para decidir si la respuesta del primer LLM era correcta.
Necesitaba una fuente de verdad independiente.
El generador producía problemas nuevos.
El solver calculaba el óptimo.
Una validación adicional comprobaba las duraciones, las dependencias, los solapamientos y el makespan del calendario.
Solo entonces tenía sentido comparar al modelo.
Ese diseño cambia el papel del evaluador.
En lugar de preguntar:
¿Esta respuesta parece razonable?
podemos preguntar cosas mucho más concretas:
¿Coincide con el óptimo?
¿El calendario es ejecutable?
¿Respeta todas las restricciones?
¿La demostración justifica realmente la optimalidad?Cuanto más objetiva pueda ser la verificación, menos tenemos que confiar en la apariencia de una buena respuesta.
El lenguaje convincente también puede engañar
Hay otra consecuencia interesante.
Una explicación larga, ordenada y técnicamente escrita puede transmitir mucha seguridad.
Pero su forma no garantiza su validez.
En el caso de las 19 horas, el argumento podía resultar plausible si no se comprobaba la aritmética que había debajo.
Esto obliga a separar dos impresiones que es muy fácil mezclar al utilizar modelos generativos:
SUENA CONVINCENTE
≠
ESTÁ DEMOSTRADONo es un problema exclusivo de los LLM.
Las personas también podemos construir argumentos convincentes sobre premisas equivocadas.
La diferencia es que un modelo puede producirlos con mucha velocidad, consistencia formal y aparente seguridad.
Por eso, cuando la tarea lo permite, prefiero una verificación externa a confiar únicamente en la explicación generada.
Los benchmarks también condicionan lo que creemos que estamos midiendo
El experimento empezó como una forma de comparar modelos.
Terminó interesándome más como una lección sobre cómo evaluarlos.
Si hubiera utilizado únicamente la respuesta final, el resultado de GPT-OSS habría sido:
4 / 5Si exijo además una demostración válida:
3 / 5Ninguna de las dos cifras es falsa.
Simplemente responden a preguntas distintas.
Eso significa que antes de interpretar cualquier benchmark conviene entender qué considera exactamente un acierto.
¿Coincidencia con una respuesta esperada?
¿Código que pasa unos tests?
¿Una solución ejecutable?
¿Una demostración verificable?
¿La valoración de otro modelo?
El número final siempre depende de esa definición.
Cinco casos no permiten extraer una conclusión general sobre GPT-OSS ni sobre los modelos de reasoning. Sí fueron suficientes para mostrar un problema de evaluación: dos métricas válidas pueden producir lecturas distintas porque no están midiendo lo mismo.
Esto cambia cómo quiero utilizar las evaluaciones
No creo que la conclusión sea que necesitamos construir un solver exacto para cualquier pregunta que hagamos a un LLM.
Eso sería imposible en muchos casos.
La conclusión que saco es más práctica:
cuando una parte de la respuesta puede verificarse objetivamente, merece la pena separarla y comprobarla.
Si puedo validar una restricción, la valido.
Si puedo ejecutar el resultado, lo ejecuto.
Si existe una fuente de verdad independiente, la utilizo.
Y si no puedo verificar el razonamiento, intento al menos no confundir una respuesta convincente con una demostración.
Una métrica menos cómoda, pero más útil
Es mucho más sencillo guardar una tabla con una columna:
correcto / incorrectoPero después de esta prueba me cuesta considerar suficientes esos dos estados cuando hablamos de reasoning.
Prefiero saber algo más:
¿acertó?
¿la solución era válida?
¿podemos justificar que era correcta?
¿falló en el resultado o en el argumento?
¿acertó a pesar de haber razonado mal?La evaluación se vuelve menos cómoda.
También se vuelve bastante más interesante.
Porque un modelo que produce la respuesta correcta por el motivo equivocado sigue habiendo acertado la respuesta.
Pero quizá no ha demostrado exactamente lo que creíamos estar midiendo.