Un LLM puede darte la respuesta correcta por el motivo equivocado

Evaluar un modelo de IA parece sencillo mientras solo nos interesa saber si ha acertado. Le planteamos un problema, conocemos la respuesta correcta y comparamos ambas. Si coinciden, damos el resultado por bueno; si no, lo consideramos un fallo. Es una forma cómoda, objetiva y muchas veces perfectamente válida de medir rendimiento.

El problema aparece cuando creemos que esa comparación también nos está diciendo algo sobre el razonamiento del modelo. No necesariamente.

Durante una batería de pruebas con problemas de planificación encontré dos fallos casi opuestos. En uno, el modelo entendió correctamente partes importantes del problema, calculó bien algunos límites y aun así terminó dando una respuesta incorrecta. En otro ocurrió algo bastante más incómodo: llegó exactamente a la respuesta correcta y construyó una solución válida, pero utilizó un argumento erróneo para justificar que aquella solución era óptima.

Si solo hubiera comprobado el resultado final, el segundo caso habría contado como un acierto perfecto. Y precisamente ahí está el problema.

Acertar no es una sola cosa

Cuando pedimos a un modelo que resuelva un problema solemos comprimir varias preguntas diferentes dentro de una sola: si ha dado el resultado correcto, si la solución que propone es realmente válida y si la explicación demuestra lo que afirma. Pueden parecer distintas formas de medir lo mismo, pero no lo son.

En la batería que utilicé, el modelo produjo calendarios factibles en los cinco problemas, acertó el resultado óptimo en cuatro y justificó correctamente esa optimalidad en tres.

calendario válido       5 / 5
resultado correcto      4 / 5
demostración correcta   3 / 5

Las tres cifras son ciertas. El problema aparece únicamente si elegimos una de ellas y asumimos que representa automáticamente a las demás.

Decir que el modelo obtuvo cuatro respuestas correctas describe correctamente una parte del experimento. Decir que razonó correctamente en cuatro casos sería una afirmación diferente, y los datos no permiten hacerla.

Se puede entender mucho y aun así fallar

Uno de los casos de la prueba mostraba muy bien esa diferencia. El problema consistía en organizar tareas entre dos trabajadores intentando completar todo el trabajo en el menor tiempo posible. El modelo calculó correctamente que el volumen total imponía un mínimo de 16 horas y encontró también un camino crítico de exactamente 16 horas. Había identificado, por tanto, dos elementos importantes de la estructura del problema.

Después concluyó que alcanzar esas 16 horas era imposible y propuso 19, aunque existía un calendario perfectamente válido que terminaba en 16.

El fallo no era el de un sistema completamente perdido que hubiera entendido mal el enunciado. Había realizado correctamente una parte considerable del análisis; lo que no consiguió fue resolver la combinación final de restricciones que permitía alcanzar simultáneamente aquellos límites.

Si únicamente registramos que la respuesta esperada era 16, el modelo respondió 19 y por tanto el resultado es un fallo, la clasificación es correcta. Pero perdemos una información bastante importante: sabemos que falló, pero no sabemos cómo.

Y si lo que estamos intentando evaluar es capacidad de razonamiento, ese “cómo” puede importar mucho más que una simple columna de aciertos y errores.

Más problemático: acertar con una demostración incorrecta

En otro problema ocurrió lo contrario. El modelo respondió 19 horas, que era exactamente el óptimo, y además construyó un calendario válido. Hasta ahí todo parecía correcto.

El problema apareció al revisar la explicación. Para justificar que no podía existir una solución mejor afirmó que la duración total de las tareas era de 38 horas, cuando en realidad sumaban 34. Parte de la demostración se apoyaba, por tanto, en un dato falso.

El resultado seguía siendo correcto y la solución continuaba siendo válida, pero el argumento utilizado para demostrar que 19 era el mínimo no lo era.

resultado correcto
+
solución válida
+
justificación incorrecta

Esta combinación me parece especialmente importante porque pasa sin dificultad cualquier evaluación que solo compruebe la respuesta final. El modelo ha acertado, y eso tiene valor. Lo que no podemos concluir es que haya demostrado correctamente por qué la respuesta era esa.

La diferencia puede parecer académica hasta que trasladamos el mismo patrón a tareas en las que no conocemos previamente la respuesta.

Cuando conocemos la respuesta podemos engañarnos a nosotros mismos

Si preguntamos cuánto es 17 × 23, comprobar la respuesta es trivial y podemos ignorar por completo la explicación si únicamente nos interesa el resultado. Pero muchos de los usos interesantes de un LLM no se parecen demasiado a eso.

Le pedimos que revise una arquitectura, analice un error, interprete datos, encuentre una causa probable, compare alternativas o proponga una decisión. Precisamente recurrimos al modelo porque la respuesta no está delante de nosotros esperando una comparación sencilla.

En ese contexto, una explicación convincente adquiere mucho peso y aparece un riesgo evidente: utilizar la calidad aparente de la explicación como sustituto de su validez. Un texto puede estar perfectamente estructurado, utilizar terminología correcta, presentar una cadena lógica reconocible y terminar en una conclusión acertada mientras contiene un error en una de sus premisas.

Eso no convierte automáticamente el resultado en incorrecto, pero tampoco convierte el razonamiento en correcto.

Convincente y demostrado no significan lo mismo

Los modelos de lenguaje son especialmente buenos produciendo explicaciones que tienen forma de explicación. Esa es una capacidad extraordinariamente útil, pero también puede hacernos bajar la guardia.

Cuando una respuesta está ordenada, desarrolla sus pasos y utiliza conceptos adecuados, nuestra intuición tiende a concederle más credibilidad que a una respuesta dubitativa o desorganizada. Es comprensible: hacemos algo parecido cuando escuchamos a otras personas.

Pero la forma del argumento no valida sus premisas.

suena convincente
≠
está demostrado

En el caso de la prueba bastaba comprobar una suma para descubrir que parte del argumento no podía sostenerse. En otros problemas, verificarlo puede ser muchísimo más difícil y, cuanto más difícil sea esa comprobación, más peligroso resulta confundir coherencia verbal con evidencia.

Por eso necesitaba una fuente de verdad que no fuera otro modelo

Una de las decisiones más importantes de aquella prueba fue utilizar un solver exacto para conocer la solución óptima. No quería evaluar la respuesta de un LLM preguntándole a otro LLM si parecía correcta; necesitaba una referencia independiente que no estuviera basada en otra generación probabilística.

Eso permitía separar varias comprobaciones: si el resultado coincidía con el óptimo, si el calendario cumplía todas las restricciones y si la demostración justificaba realmente la optimalidad.

El solver no hacía que el modelo razonara mejor. Hacía que yo pudiera medir mejor lo que había hecho.

Cuando evaluamos sistemas capaces de producir respuestas plausibles, una fuente de verdad externa puede ser mucho más valiosa que una evaluación igualmente plausible. No siempre tendremos un solver exacto, por supuesto, porque muchas tareas reales no admiten una verificación matemática, pero el principio sigue siendo útil: todo aquello que podamos comprobar de manera determinista deja de necesitar nuestra confianza.

Si una salida puede ejecutarse, la ejecuto. Si hay tests, los utilizo. Si puedo validar restricciones automáticamente, las valido. Si existe una fuente independiente, la comparo. Y dejo el juicio subjetivo para aquello que realmente lo necesita.

Si puede ser determinista, probablemente no debería decidirlo un LLM

Hay además una consecuencia que me parece especialmente importante en el momento actual.

Estoy viendo utilizar IA para resolver partes de procesos que ya sabemos resolver de forma determinista. Se pide a un modelo que decida si dos valores coinciden, que compruebe una condición perfectamente formalizable, que clasifique estados definidos por reglas explícitas o que determine resultados que pueden obtenerse con código convencional.

Me parece un error de diseño bastante serio.

No porque los modelos sean poco capaces, sino precisamente porque estamos sustituyendo una garantía conocida por una probabilidad sin obtener nada a cambio.

Si una condición puede expresarse como código determinista, el mismo input debería producir siempre el mismo resultado y podemos probar exactamente qué reglas se están aplicando. Introducir un LLM en ese punto añade coste, latencia, variabilidad y una nueva posibilidad de error.

regla determinista
→ código

interpretación ambigua
→ quizá LLM

La frontera no siempre será tan limpia, pero la dirección me parece importante.

Un LLM tiene muchísimo valor allí donde necesitamos interpretar lenguaje, trabajar con información incompleta, sintetizar, proponer alternativas, descubrir relaciones o enfrentarnos a problemas donde no existe un procedimiento cerrado sencillo. Utilizarlo para sustituir una comprobación que podemos expresar con una función, un parser, una consulta o un conjunto de reglas no aprovecha su fortaleza. Renuncia innecesariamente a una certeza que ya teníamos.

Y esto resulta todavía más difícil de justificar cuando sabemos que un modelo puede entregar la respuesta correcta utilizando una explicación equivocada.

La IA debería rodearse de determinismo siempre que podamos

Para mí, la consecuencia no es separar el mundo entre “IA” y “software tradicional”, sino combinarlos correctamente.

Un sistema puede utilizar un modelo para interpretar una petición, extraer información, proponer una solución o decidir qué camino merece explorarse, mientras utiliza código convencional para comprobar aquello que tiene una respuesta objetiva.

La IA puede generar un calendario.

El programa puede validar que no existan solapamientos.

La IA puede proponer código.

Los tests pueden comprobar que funciona.

La IA puede interpretar un documento.

Un parser puede verificar que los campos obligatorios existen.

La IA puede decidir que un evento parece relevante.

Una regla determinista puede comprobar primero si el evento siquiera cumple las condiciones mínimas para necesitar esa evaluación.

No estamos limitando al modelo. Estamos construyendo un sistema mejor alrededor de él.

Desde el punto de vista de ingeniería, además, esto resulta bastante natural: dejamos a cada componente resolver el tipo de problema para el que es más adecuado.

Los benchmarks miden aquello que decidimos contar

Esta forma de pensar cambia también cómo interpreto cualquier benchmark.

Un porcentaje de aciertos parece una propiedad del modelo, pero antes de llegar a ese número alguien ha tenido que decidir qué significa exactamente “acertar”. Puede significar coincidir con una respuesta esperada, exigir además que el código pase unos tests, requerir una solución ejecutable, incluir la validez de una demostración o incluso depender de la evaluación de otro modelo.

Todas esas decisiones forman parte del benchmark aunque después desaparezcan detrás de una cifra.

En mi prueba, decir que el modelo obtuvo 4 de 5 respuestas correctas y decir que consiguió 3 de 5 soluciones completamente justificadas son dos descripciones válidas del mismo experimento. No compiten entre sí; simplemente responden a preguntas diferentes.

Por eso una métrica no debería interpretarse únicamente por el número que produce. También necesitamos saber qué tuvo que ocurrir para que el benchmark asignase un punto.

El conocimiento de desarrollo vuelve a ser útil aquí

Hay algo en esta forma de evaluar que me resulta muy familiar como programador. Cuando una función produce el resultado esperado una vez, no asumimos automáticamente que su implementación sea correcta. Intentamos probar casos límite, comprobar invariantes, ejecutar tests y separar las distintas responsabilidades del sistema.

Un test que pasa es evidencia, pero no es una explicación mágica de todo lo que ocurre dentro del programa.

Con los modelos creo que resulta útil mantener una mentalidad parecida. La respuesta final puede verse como una salida observable del sistema. Es importante y debemos medirla, pero no siempre es suficiente para afirmar cosas sobre el proceso que la produjo.

Además, si podemos dividir un problema grande en propiedades verificables, obtenemos una evaluación bastante más útil. En lugar de preguntar simplemente si “el modelo lo hizo bien”, podemos comprobar qué partes hizo bien y cuáles no.

Eso no solo mejora una tabla de resultados. También ayuda a decidir para qué podemos confiar en ese modelo, dónde necesitamos controles y, quizá todavía más importante, qué partes del proceso ni siquiera deberían depender de él.

No necesitamos verificar cada pensamiento del modelo

Tampoco creo que la conclusión correcta sea intentar auditar cada paso interno de cualquier respuesta. En muchos casos sería imposible y, en otros, completamente innecesario.

Lo importante es no pedir a una métrica que nos diga más de lo que realmente mide.

Si solo comprobamos la respuesta final, sabemos si la respuesta final es correcta. Eso ya puede ser extremadamente útil. El problema comienza cuando transformamos ese dato en una afirmación más fuerte: ha acertado, por tanto ha razonado correctamente.

Ese “por tanto” es precisamente lo que la prueba puso en duda.

Evaluar mejor cambia cómo podemos construir con IA

Para mí, la consecuencia práctica no está en crear benchmarks cada vez más complicados. Está en diseñar mejor los puntos de verificación cuando utilizamos IA para trabajo real.

Si un agente modifica código, puedo ejecutar tests. Si genera una configuración, puedo validarla. Si transforma datos, puedo comprobar propiedades de la salida. Si calcula algo, puedo contrastarlo con una herramienta determinista. Si toma una decisión basada en varias fuentes, puedo pedir evidencia concreta para las partes importantes.

Cuantas más partes del proceso convierta en verificaciones objetivas, menos necesito confiar en que una respuesta “parezca buena”.

Esto cambia también el papel de la IA. No necesito que sea infalible para que resulte útil; necesito entender qué puede hacer bien, qué puedo verificar, dónde puede equivocarse y qué consecuencias tendría ese error.

Y, sobre todo, necesito evitar pedirle que decida aquello para lo que ya dispongo de una respuesta determinista.

Es una forma bastante más práctica de construir confianza que asumir que un modelo suficientemente capaz dejará simplemente de cometer errores.

Una respuesta correcta sigue siendo una respuesta correcta

Conviene no irse tampoco al extremo contrario. Si un modelo da la respuesta correcta mediante un razonamiento defectuoso, ha dado la respuesta correcta y no tiene sentido fingir que eso no tiene valor.

Pero tampoco deberíamos otorgarle automáticamente una capacidad que la prueba no ha demostrado.

Esa distinción parece pequeña, pero cambia mucho la forma en que interpreto evaluaciones, benchmarks y mis propios sistemas basados en IA. Ya no me interesa únicamente preguntar si el modelo acertó. También quiero saber qué parte puedo comprobar, qué evidencia sostiene la conclusión, cuánto del resultado depende de aceptar como válida la explicación generada y si existe alguna parte del proceso que podría resolver de forma determinista en lugar de delegarla al modelo.

A veces esas preguntas confirman que la IA resolvió el problema perfectamente. Otras descubren algo más interesante: llegó al lugar correcto por un camino que no deberíamos reutilizar.

Y en algunas ocasiones la conclusión es todavía más sencilla: nunca debimos pedirle al modelo que resolviera esa parte del problema.

Una respuesta correcta puede ser un buen resultado. Pero cuando queremos construir sistemas fiables alrededor de la IA, acertar es solo una parte de la arquitectura.