Los LLM aún no pueden autocorregir su razonamiento — Hallazgos de ICLR 2024 e implicaciones para la IA en finanzas

Este artículo es el contrapunto directo a las líneas de trabajo CRITIC y Reflexion que he estado leyendo. Huang et al. (ICLR 2024) plantean un argumento sencillo e incómodo: cuando los LLM intentan autocorregir su razonamiento sin ninguna señal externa, no mejoran, sino que empeoran. Siguiendo al LOG-013 sobre CRITIC, donde la crítica basada en herramientas ayudó genuinamente, este artículo aclara exactamente qué tipo de "autocorrección" es real y qué es un artefacto del diseño experimental.

El artículo

"Large Language Models Cannot Self-Correct Reasoning Yet" (Los modelos de lenguaje grandes aún no pueden autocorregir su razonamiento) de Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song y Denny Zhou (Google DeepMind / UIUC) fue publicado en ICLR 2024. La afirmación central es limitada pero devastadora para cierta clase de diseños de agentes: la autocorrección intrínseca —pedirle a un LLM que revise y corrija su propia respuesta usando solo su propio juicio, sin ninguna señal de verdad fundamental— degrada sistemáticamente el rendimiento en las evaluaciones de razonamiento. Las mejoras reportadas en varios artículos previos sobre autocorrección, argumentan los autores, resultan de un sutil fallo metodológico: esos artículos utilizaron etiquetas de oráculo para decidir cuándo dejar de corregir, lo que significa que el modelo solo corrige las respuestas que ya son incorrectas. Eso no es autocorrección; es un filtrado guiado por un oráculo.

Ideas clave

• En GSM8K, GPT-4 comienza con una precisión del 95,5 %. Después de una ronda de autocorrección intrínseca, cae al 91,5 %, y tras una segunda ronda, al 89,0 %. GPT-3.5 cae del 75,9 % al 74,7 % en dos rondas.
• La caída es más drástica en CommonSenseQA: GPT-3.5 cae del 75,8 % al 38,1 % tras una sola ronda de autocorrección, recuperándose ligeramente al 41,8 % en la segunda ronda, pero permaneciendo catastróficamente por debajo del punto de partida.
• El análisis de los cambios en las respuestas en GSM8K muestra que el modelo cambia respuestas correctas por incorrectas con más frecuencia de lo que corrige las incorrectas. La dirección neta del cambio es perjudicial.
• La autocorrección guiada por oráculo sí mejora las cosas: GPT-4 en GSM8K con etiquetas de oráculo pasa del 95,5 % al 97,5 %, y GPT-3.5 en CommonSenseQA del 75,8 % al 89,7 %. Pero esto requiere saber qué respuestas son incorrectas, algo que no se puede saber en un entorno real.
• El debate multiagente, otra idea popular, rinde menos que la simple autoconsistencia cuando se iguala el presupuesto de inferencia. Con 9 respuestas totales, la autoconsistencia alcanza el 88,2 % en GSM8K; el debate multiagente solo llega al 83,0 %.
• La generación restringida (CommonGen-Hard) parece ser una victoria para la autocorrección al principio (44 % → 67 %), pero esa ganancia se evapora si simplemente se mejora el prompt inicial (81,8 %). Cuando el prompt de inicio ya es bueno, la autocorrección perjudica, bajando la precisión al 75,1 %.

Qué se mantiene y qué no

El hallazgo principal es sólido: las cifras son las que son. Si se le pide a GPT-4 que reexamine sus respuestas matemáticas sin decirle cuáles están mal, las respuestas empeoran en promedio. La intuición que ofrece el artículo también es acertada: los LLM no pueden juzgar de manera confiable la corrección de su propio razonamiento, por lo que cuando deciden cambiar una respuesta, están adivinando, y adivinan mal al menos con la misma frecuencia con la que aciertan.

El artículo es menos convincente en sus afirmaciones de generalización. Evalúa exclusivamente tareas de razonamiento y conocimiento. Hay dominios —estilo de escritura, cumplimiento de restricciones de formato, reducción de toxicidad— donde la revisión iterativa posiblemente sí ayuda, y el artículo evita estos temas en gran medida. Los autores lo reconocen de pasada, señalando que "la autocorrección puede ser más efectiva para tareas donde la evaluación es más sencilla", pero no lo prueban cuidadosamente. El experimento de generación restringida de CommonGen es sugerente, pero usar un prompt inicial inadecuado como base y llamar a la mejora resultante "autocorrección" es el mismo fallo metodológico que el artículo critica en otros trabajos.

El artículo tampoco aborda la cuestión de la autocorrección entrenada. Un seguimiento de 2025 (SCoRe, ICLR 2025, arXiv:2409.12917) muestra que la autocorrección entrenada por aprendizaje por refuerzo (RL) sobre los propios resultados del modelo logra un +15,6 % en MATH y un +9,1 % en HumanEval, una mejora intrínseca genuina. Por lo tanto, el título "aún no pueden autocorregir" ha envejecido mejor que lo que permitiría una interpretación más estricta; la interpretación correcta es "no se puede forzar la autocorrección mediante prompts", no "no pueden aprender a autocorregirse".

Por qué esto es importante para la IA en finanzas

La implicación para los agentes de escritura en el libro mayor es concreta. Un agente que genera un asiento contable de Beancount, luego se pregunta a sí mismo "¿esto parece correcto?" y lo corrige, no está obteniendo una segunda opinión: está introduciendo ruido. Los datos aquí indican que si la primera respuesta fue incorrecta, la autorevisión tiene las mismas probabilidades de corromper una respuesta correcta que de corregir una incorrecta.

Lo que este artículo confirma es la restricción de diseño que extraje de CRITIC: la autovalidación sin un oráculo externo no es confiable. Para Beancount específicamente, el oráculo externo está disponible y es económico: las aserciones de saldo se ejecutan en milisegundos, los nombres de las cuentas se validan contra un plan de cuentas conocido y los montos deben conciliarse hasta el centavo. Una arquitectura de agente que envía un asiento tentativo, ejecuta bean-check y devuelve cualquier error como retroalimentación estructurada concreta es fundamentalmente diferente de una que pide al modelo "revisar su asiento contable". El primero utiliza el motor del libro mayor como oráculo. El segundo depende del mismo mecanismo de razonamiento que produjo el error en primer lugar.

También hay una lección más sutil sobre el diseño de prompts. El experimento CommonGen muestra que cuando el prompt ya es preciso y explícito, la autocorrección degrada el rendimiento. Esto significa que si invertimos esfuerzo en escribir prompts de procesamiento de transacciones muy claros —aquellos que establecen todas las reglas de sintaxis de Beancount explícitamente—, añadir un bucle de autorevisión por encima de ellos puede perjudicar activamente la precisión. La arquitectura correcta probablemente activa la autorevisión ante una verificación externa fallida, no en cada generación.

Qué leer a continuación

• SCoRe: Training Language Models to Self-Correct via Reinforcement Learning (arXiv:2409.12917, ICLR 2025) — Enfoque basado en RL que logra las primeras ganancias genuinas de autocorrección intrínseca; contexto necesario para entender lo que el artículo actual descarta o no.
• When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs (TACL 2024) — Taxonomía sistemática de cuándo funciona la autocorrección, distinguiendo variantes intrínsecas, basadas en entrenamiento y asistidas por herramientas.
• Self-Refine: Iterative Refinement with Self-Feedback (NeurIPS 2023) — El artículo principal que Huang et al. critican; leerlo en conjunto aclara exactamente dónde se inserta el supuesto de la etiqueta de oráculo.