PAL: Modelos de Lenguaje Ayudados por Programas para Aritmética Financiera Confiable

Tras dedicar tiempo a la literatura sobre el razonamiento tabular, quería entender el enfoque complementario: en lugar de hacer que los LLM razonen sobre tablas en lenguaje natural, ¿qué sucede cuando se les permite escribir código y delegar el cómputo por completo? PAL (Gao et al., 2022, arXiv:2211.10435) es la respuesta canónica, y tiene implicaciones obvias para cualquier sistema que necesite realizar aritmética sobre datos financieros de manera confiable.

El artículo

"PAL: Program-Aided Language Models" (Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023) parte de una observación directa: los LLM descomponen bien los problemas pero ejecutan mal la aritmética. El prompting de cadena de pensamiento soluciona el primer problema pero deja el segundo intacto. La solución propuesta es cambiar lo que el LLM produce como sus "pasos de razonamiento" — en lugar de aritmética en lenguaje natural, genera código Python. Un intérprete de Python ejecuta ese código y devuelve la respuesta.

La división descomposición-ejecución es limpia: el LLM se encarga de la comprensión del problema y de la estructura del programa; el intérprete se encarga de todo lo numérico. Una pregunta como "Olivia tiene $23, compra cinco bagels a $3 cada uno — ¿cuánto queda?" se convierte en money_left = 23 - (5 * 3), no en una secuencia de aritmética en prosa que el modelo podría arruinar.

Ideas clave

• En GSM8K (problemas matemáticos de nivel escolar), PAL con Codex alcanza un 72.0% de precisión frente al 65.6% de la cadena de pensamiento con el mismo modelo Codex — una ganancia de +6.4pp — y un 56.9% para CoT con el modelo mucho más grande PaLM-540B. Un modelo más pequeño gana al delegar la aritmética a Python.
• En GSM-hard, una versión de GSM8K donde los números se reemplazan por valores más grandes, PAL logra un 61.2% frente al 23.1% de CoT — una brecha absoluta de +38.1pp. Los números grandes rompen la aritmética a nivel de tokens; no rompen a Python.
• Con votación por mayoría sobre 40 muestras, PAL alcanza el 80.4% en GSM8K, superando ligeramente a Minerva-540B (78.5%) con un modelo aproximadamente 1/10 del tamaño.
• Las ganancias se generalizan al razonamiento simbólico. En tareas de BIG-Bench Hard como Object Counting (Conteo de objetos), PAL obtiene un 96.7% frente al 73.0% de CoT; en Penguins in a Table (Pingüinos en una tabla), un 93.3% frente al 79.2%.
• Una ablación revela dónde ocurre realmente el trabajo: cuando el LLM actúa como su propio intérprete (sin Python externo), la precisión en GSM8K colapsa al 23.2%. El intérprete no es una mejora menor — está realizando toda la aritmética.
• Los nombres de las variables importan. Reemplazar nombres de variables significativos con caracteres aleatorios causa caídas sustanciales de precisión en tareas simbólicas. El modelo lee su propio código.

Qué se mantiene y qué no

La afirmación central es trivialmente correcta y los experimentos la confirman de manera convincente: Python es mejor que un LLM en aritmética, y GSM-hard hace que esto sea brutalmente visible. Los +38pp allí no son una peculiaridad del benchmark — reflejan un modo de fallo categórico de CoT bajo escala.

Lo que encuentro menos convincente es el planteamiento como un avance en el razonamiento general. PAL funciona en tareas que resultan tener respuestas deterministas y expresables en Python. Mucho de lo que importa en el razonamiento financiero no se descompone de esta manera. Decidir si un patrón de transacciones es "inusual para esta cuenta en el cuarto trimestre" o si una transferencia justifica una bandera de revisión manual no es reducible a una expresión de Python. PAL te ofrece un motor aritmético confiable; no te ofrece juicio.

La dimensión de seguridad no recibe atención en el artículo. Los benchmarks se ejecutan en un entorno controlado, pero cualquier implementación que genere y ejecute código Python arbitrario en respuesta a entradas proporcionadas por el usuario es una superficie de ataque significativa. Escapes del kernel desde intérpretes en sandboxes, acceso al sistema de archivos o secretos, entradas diseñadas de forma maliciosa que generen código malintencionado — nada de esto se aborda. Para aplicaciones financieras, esto no es una nota al pie.

El artículo tampoco analiza profundamente los modos de fallo cuando la generación de código sale mal. Si PAL emite un Python sintácticamente inválido, se queda sin nada. Los autores informan tasas de éxito de ejecución pero no caracterizan qué causa los fallos de generación o si son aleatorios o sistemáticos. Dado que el intérprete realiza toda la aritmética, la calidad del código es el cuello de botella de la confiabilidad, y está subanalizada.

Por qué esto es importante para la IA financiera

Este es uno de los artículos más directamente aplicables a Beancount que he leído. Las operaciones del libro contable están casi perfectamente alineadas con lo que PAL hace bien: sumar transacciones por categoría, aplicar tipos de cambio de divisas, calcular la base imponible a través de múltiples lotes, conciliar los totales de los extractos bancarios con los saldos del libro contable. Estas son operaciones deterministas, con alta carga aritmética y expresables en Python. Los agentes basados en CoT alucinarán números aquí; PAL no lo hará, siempre que la estructura del programa sea correcta.

Program of Thoughts (arXiv:2211.12588), un artículo concurrente que desarrolló de forma independiente la misma idea, evaluó tres conjuntos de datos de preguntas y respuestas financieras — FinQA, ConvFinQA y TATQA — e informó una ganancia promedio de ~12% sobre la cadena de pensamiento. Esa es la evidencia más directa de que el enfoque de generación de programas ayuda en el razonamiento del dominio financiero, no solo en matemáticas de nivel escolar.

Sin embargo, la cuestión de la seguridad en la escritura de datos es más crítica en el contexto de un libro contable que en los benchmarks. Un agente que genera Python para leer datos de Beancount es de bajo riesgo. Uno que genera Python para escribir asientos contables necesita un entorno de ejecución estrictamente restringido — uno que pueda tocar solo objetos del libro contable y nada más, que falle de forma cerrada ante cualquier excepción y que requiera que el código generado pase una lista blanca antes de la ejecución. PAL trata al intérprete como un motor de computación neutral. Un agente financiero de producción no puede hacerlo.

Qué leer a continuación

• Program of Thoughts Prompting (Chen et al., arXiv:2211.12588) — trabajo concurrente que evalúa en FinQA, ConvFinQA y TATQA e informa una ganancia promedio de ~12% sobre CoT; la evaluación específica de finanzas que PAL posterga.
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen et al., EMNLP 2021) — el benchmark que sustenta las evaluaciones financieras de PoT; entender qué se está probando realmente calibra cuánto confiar en la transferencia a casos de uso reales de Beancount.
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., arXiv:2303.17651) — mismo primer autor que PAL, extiende la idea de la generación de código a bucles iterativos de autocorrección; relevante para determinar si los agentes de estilo PAL pueden recuperarse de sus propios fallos de generación de código.