Un paper reclama definir el razonamiento antes de medirlo

Un position paper subido a arXiv el 14 de agosto sostiene algo incómodo para casi todo el que publica evaluaciones: la comunidad de IA generativa no ha convergido en una definición operativa de «razonamiento», y sin ella la validez de constructo de cualquier benchmark que diga medirlo queda sin verificar. El texto, titulado Position: Reasoning is a Learnable Rule-Based Process, va directo al punto: no es que los resultados sean falsos, es que no se puede demostrar qué miden.

El argumento tiene una parte histórica. El razonamiento automático fue durante décadas territorio de la IA simbólica y de la lógica formal, con una tradición de verificación bastante estricta: un razonamiento es válido si la conclusión se sigue de las premisas, y es sólido si además las premisas son verdaderas. Los autores sostienen que el avance reciente, apoyado casi por completo en modelos generativos probabilísticos profundos, ha llegado rechazando de forma implícita ese tratamiento previo, y que la ambigüedad resultante sí es corregible.

Validez de constructo, en cristiano

Un benchmark tiene validez de constructo cuando hay evidencia de que mide el concepto que dice medir y no otro correlacionado. Con accuracy sobre problemas de matemáticas o de lógica, lo que se registra es si la respuesta final coincide con la esperada. Un modelo puede llegar a esa respuesta por una cadena inválida, por memorización del conjunto de entrenamiento o por un atajo estadístico que funciona en ese formato de pregunta concreto. La métrica no distingue los tres casos, y sin definición operativa no hay forma de decidir cuál de ellos cuenta como razonar.

Qué propone el paper

Aporta dos cosas. La primera, un conjunto de definiciones operativas sintetizadas de la literatura, que sitúan el razonamiento válido y sólido como un proceso basado en reglas y aprendible: reglas, porque permite auditar paso a paso; aprendible, porque no obliga a volver a escribir a mano un sistema simbólico completo. La segunda, una checklist de buenas prácticas para comunicar investigación sobre razonamiento en IA. Esa segunda parte es la de recorrido práctico más inmediato, porque obliga a declarar qué definición se está usando antes de enseñar una cifra.

Por qué importa si construyes agentes

Interesa a quien evalúa modelos, pero también a cualquiera con agentes en producción. Cuando delegas una tarea a un subagente y solo compruebas si el output final es correcto, estás haciendo la versión doméstica del mismo error. Una tarea que sale bien con un razonamiento intermedio equivocado volverá a fallar en cuanto cambie un dato de entrada, y para entonces habrás construido encima.

Nos ha pasado con pipelines que pasaban los tests durante semanas y se rompían con el primer caso fuera de la distribución de los ejemplos. La checklist sirve bien como plantilla para escribir evaluaciones internas: definir qué se considera un paso válido, registrar la cadena y no solo el resultado, y separar los aciertos con razonamiento correcto de los aciertos por casualidad. No hace falta lógica formal para eso, basta con dejar de tratar la respuesta final como única señal.

Los límites

Conviene recordar qué es y qué no es esta pieza. Es un position paper: no trae benchmark nuevo ni resultados empíricos, y su tesis central es discutible por diseño. Quien defienda que el razonamiento de los LLM es un fenómeno emergente que no se deja reducir a reglas explícitas tiene margen de sobra para discrepar, y esa discusión lleva abierta desde bastante antes de que existieran estos modelos. Una definición tampoco arregla un conjunto de test filtrado en el entrenamiento.

Nuestra opinión: la parte de definiciones dará para debate largo y probablemente no cierre nada. La checklist, en cambio, se puede aplicar mañana y cuesta poco. Si de este paper solo sobrevive el hábito de decir qué se entiende por razonar antes de publicar el número, ya habrá servido para algo.