CRITIC: Por qué la autocorrección de los LLM requiere retroalimentación de herramientas externas

Leer CRITIC (Gou et al., ICLR 2024) mientras pienso en qué sucede después de que un agente financiero comete un error. Reflexion nos dijo que los agentes pueden aprender del fracaso a lo largo de los episodios. CRITIC plantea una pregunta más incisiva: ¿puede un LLM detectar y corregir sus propios errores en una sola fase de generación — y si es así, qué necesita realmente para hacerlo?

El artículo

CRITIC presenta un marco en el que un modelo de lenguaje genera una salida inicial y luego itera a través de un bucle de verificar-luego-corregir utilizando herramientas externas: una API de búsqueda para afirmaciones fácticas, un intérprete de Python para código y aritmética, y un clasificador de toxicidad para la moderación de contenido. El bucle se ejecuta durante un número fijo de iteraciones (el artículo informa de resultados efectivos en unas tres correcciones), produciendo una salida refinada que los autores evalúan en respuestas a preguntas de formato libre (TriviaQA, AmbigNQ, HotpotQA), síntesis de programas matemáticos y reducción de toxicidad.

La afirmación central no es que los LLM puedan autocorregirse por sí mismos. Es casi lo opuesto: el valor de CRITIC proviene precisamente de fundamentar la crítica en una señal externa que el modelo no puede falsificar. Sin la API de búsqueda, las mejoras en QA se reducen a casi cero o se invierten. El marco funciona porque la herramienta le dice al modelo algo que genuinamente no sabía, no porque el modelo se convierta en un auditor interno confiable.

Ideas clave

• Aplicado a ChatGPT, CRITIC logra mejoras de 7.7 en la puntuación F1 promediadas en tres tareas de QA de dominio abierto y ganancias absolutas de 7.0 puntos porcentuales en tres pruebas comparativas de razonamiento matemático.
• La reducción de la toxicidad es el resultado individual más sorprendente: una reducción del 79.2% en la probabilidad de toxicidad en el conjunto de datos evaluado.
• Eliminar la API de búsqueda hace que el rendimiento de QA se estanque o se degrade; la capacidad de autocrítica intrínseca del modelo es casi inútil para tareas fácticas.
• El bucle converge rápidamente: tres rondas de corrección capturan la mayor parte de la ganancia, con rendimientos decrecientes a partir de ahí.
• El marco es agnóstico al modelo y no requiere ajuste fino; funciona en API de caja negra, incluyendo tanto Text-Davinci-003 como ChatGPT.
• CRITIC supera a la autoconsistencia (votación mayoritaria sobre múltiples muestras) en la mayoría de las tareas, lo cual es significativo porque la autoconsistencia no tiene costo de herramienta por paso.

Qué se sostiene — y qué no

El resultado empírico central es sólido: la retroalimentación de herramientas externas mejora significativamente los resultados, y la ablación que elimina la API de búsqueda es demoledora para los defensores de la autocorrección ingenua. El artículo también es honesto sobre el mecanismo: las ganancias provienen de la herramienta, no de alguna capacidad metacognitiva emergente.

Lo que me parece poco explorado es la taxonomía de los modos de fallo. ¿Cuándo genera el modelo una crítica deficiente que lo aleja aún más de la respuesta correcta? El artículo informa sobre el rendimiento promedio, pero la varianza entre tareas y tipos de preguntas importaría enormemente para el despliegue. En un contexto financiero, el peor resultado no es "ninguna mejora", sino una corrección que suene plausible pero introduzca un nuevo error.

La elección de limitar a tres iteraciones también se presenta como una conveniencia práctica más que como un criterio de parada basado en principios. Tres rondas pueden funcionar para TriviaQA, donde hay una respuesta de verdad fundamental hacia la cual converger. En un dominio como la conciliación de libros contables, donde la respuesta "correcta" requiere razonamiento multidocumento y conocimiento del dominio, no es obvio que tres llamadas a herramientas sean suficientes, o que una API de búsqueda de propósito general proporcione la señal de verificación adecuada en absoluto.

El artículo complementario de ICLR 2024 "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., arXiv:2310.01798) confirma el hallazgo de CRITIC desde la otra dirección: sin retroalimentación externa, la autocorrección degrada de manera confiable la precisión del razonamiento. Estos dos artículos juntos forman una imagen coherente: la capacidad que la gente llamaba "autocorrección" es principalmente refinamiento impulsado por retroalimentación externa, y la distinción es importante.

Por qué esto importa para la IA financiera

El bucle de CRITIC se traslada de forma natural al problema de seguridad de escritura en los agentes de Beancount. En este momento, cuando un agente de LLM propone un asiento de diario —por ejemplo, categorizando una transacción o dividiendo un gasto— no existe una forma sistemática de que verifique su propia salida antes de guardarla en el disco. La arquitectura de CRITIC sugiere un patrón concreto: generar una entrada candidata, luego ejecutar la verificación contra una herramienta (una función de verificación de saldo, un motor de reglas, un detector de duplicados) y usar la salida de la herramienta para solicitar una revisión antes de que la escritura se concrete.

El resultado de la toxicidad es una analogía que me resulta útil reformular: una reducción del 79.2% en las violaciones de políticas no proviene de que el modelo interiorice las reglas, sino de un clasificador que informa de las violaciones al modelo. Para un libro contable de Beancount, el equivalente sería un verificador de reglas que señale transacciones contabilizadas dos veces o violaciones de categorías, y envíe esa señal a la fase de revisión del agente. El agente no necesita saber de forma independiente que las reglas se han infringido; necesita la señal de la herramienta.

La limitación crítica para las finanzas es la dependencia de la API de búsqueda. Los agentes financieros necesitan herramientas de verificación que sean específicas del dominio: verificaciones de integridad del saldo de la cuenta, validadores del plan de cuentas, búsquedas de reglas fiscales. Es poco probable que una búsqueda web genérica detecte un gasto mal clasificado. Construir la capa de herramientas adecuada para la corrección al estilo CRITIC en contabilidad es donde reside el verdadero trabajo de ingeniería, y el artículo no aborda en absoluto el diseño de herramientas específicas del dominio.

Qué leer a continuación

• "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., 2023, arXiv:2310.01798) — el argumento empírico directo de que la autocorrección intrínseca falla; debe leerse junto a CRITIC ya que ambos triangulan el mismo mecanismo desde direcciones opuestas.
• "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (Yao et al., NeurIPS 2023, arXiv:2305.10601) — extiende la idea de crítica y corrección de un solo camino a un árbol de búsqueda sobre pasos intermedios; relevante para la conciliación de múltiples pasos donde el agente necesita explorar y retroceder.
• "ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs" (Qin et al., 2023, arXiv:2307.16789) — examina cómo los agentes aprenden a seleccionar y encadenar llamadas a herramientas, que es el problema previo que CRITIC da por sentado.