PAL: Models de llenguatge assistits per programes per a una aritmètica financera fiable

Després de passar un temps amb la literatura sobre raonament tabular, volia entendre l'enfocament complementari: en lloc de fer que els LLM raonin sobre taules en llenguatge natural, què passa quan els deixes escriure codi i delegues el càlcul completament? PAL (Gao et al., 2022, arXiv:2211.10435) és la resposta canònica, i té implicacions òbvies per a qualsevol sistema que necessiti realitzar aritmètica sobre dades financeres de manera fiable.

L'article

"PAL: Program-Aided Language Models" (Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023) parteix d'una observació directa: els LLM descomponen bé els problemes però executen malament l'aritmètica. L'indicador (prompting) de cadena de pensament soluciona el primer problema però deixa el segon intacte. La solució proposada és canviar el que el LLM produeix com a "passos de raonament": en lloc d'aritmètica en llenguatge natural, genera codi Python. Un intèrpret de Python executa llavors aquest codi i retorna la resposta.

La divisió entre descomposició i execució és neta: el LLM s'encarrega de la comprensió del problema i de l'estructura del programa; l'intèrpret s'encarrega de tot el que és numèric. Una pregunta com "L'Olivia té 23 $, compra cinc bagels a 3 $ cadascun: quant li queda?" es converteix en money_left = 23 - (5 * 3), no en una seqüència d'aritmètica en prosa que el model podria espatllar.

Idees clau

• A GSM8K (problemes matemàtics de nivell escolar), PAL amb Codex arriba al 72,0 % de precisió enfront del 65,6 % de la cadena de pensament amb el mateix model Codex (un guany de +6,4 pp) i el 56,9 % per a CoT amb el model PaLM-540B, molt més gran. Un model més petit guanya delegant l'aritmètica a Python.
• A GSM-hard, una versió de GSM8K on els números es substitueixen per valors més grans, PAL aconsegueix un 61,2 % enfront del 23,1 % de CoT, una diferència absoluta de +38,1 pp. Els números grans trenquen l'aritmètica a nivell de testimoni (token); no trenquen Python.
• Amb votació majoritària sobre 40 mostres, PAL arriba al 80,4 % a GSM8K, superant per poc Minerva-540B (78,5 %) amb un model d'aproximadament 1/10 part de la mida.
• Els guanys es generalitzen al raonament simbòlic. En tasques de BIG-Bench Hard com el recompte d'objectes (Object Counting), PAL puntua un 96,7 % enfront del 73,0 % de CoT; a Penguins in a Table, un 93,3 % enfront del 79,2 %.
• Una ablació revela on es realitza realment la feina: quan el LLM actua com el seu propi intèrpret (sense Python extern), la precisió de GSM8K es desploma fins al 23,2 %. L'intèrpret no és una millora menor: està fent tota l'aritmètica.
• El nom de les variables importa. Substituir noms de variables significatius per caràcters aleatoris provoca caigudes substancials de la precisió en tasques simbòliques. El model llegeix el seu propi codi.

Què es manté i què no

L'afirmació central és trivialment correcta i els experiments la confirmen de manera convincent: Python és millor que un LLM en aritmètica, i GSM-hard ho fa visible de manera brutal. Aquests +38 pp no són una peculiaritat del banc de proves: reflecteixen un mode de fallada categòric de la CoT sota escala.

El que trobo menys convencent és el seu plantejament com un avenç en el raonament general. PAL funciona en tasques que tenen respostes deterministes i expressables en Python. Gran part del que importa en el raonament financer no es descommpon d'aquesta manera. Decidir si un patró de transacció és "inusual per a aquest compte al quart trimestre" o si una transferència mereix una marca de revisió manual no es pot reduir a una expressió de Python. PAL et dóna un motor aritmètic fiable; no et dóna criteri.

La dimensió de la seguretat no rep cap atenció en l'article. Els bancs de proves s'executen en un entorn controlat, però qualsevol implementació que generi i executi codi Python arbitrari en resposta a les entrades proporcionades per l'usuari és una superfície d'atac significativa. Escapaments del nucli d'intèrprets en entorns aïllats (sandbox), accés al sistema de fitxers o a secrets, entrades dissenyades de forma adversària que generen codi maliciós; res d'això s'aborda. Per a aplicacions financeres, això no és una nota a peu de pàgina.

L'article tampoc analitza profundament els modes de fallada quan la generació de codi surt malament. Si PAL emet un Python sintàcticament invàlid, no té cap alternativa. Els autors informen de les taxes d'èxit d'execució, però no caracteritzen què causa els errors de generació o si són aleatoris o sistemàtics. Atès que l'intèrpret fa tota l'aritmètica, la qualitat del codi és tot el coll d'ampolla de la fiabilitat, i està poc analitzat.

Per què això és important per a la IA financera

Aquest és un dels articles més directament aplicables a Beancount que he llegit. Les operacions del llibre diari estan gairebé perfectament alineades amb el que PAL fa bé: sumar transaccions per categoria, aplicar tipus de canvi, calcular la base imposable en diversos lots, conciliar els totals dels extractes bancaris amb els saldos del llibre diari. Són tasques deterministes, amb molta càrrega aritmètica i expressables en Python. Els agents basats en CoT al·lucinaran números aquí; PAL no ho farà, sempre que l'estructura del programa sigui correcta.

Program of Thoughts (arXiv:2211.12588), un article concurrent que va desenvolupar de manera independent la mateixa idea, va realitzar l'avaluació en tres conjunts de dades de preguntes i respostes financeres (FinQA, ConvFinQA i TATQA) i va informar d'un guany mitjà d'un 12 % respecte a la cadena de pensament. Aquesta és l'evidència més directa que l'enfocament de generació de programes ajuda en el raonament del domini financer, no només en les matemàtiques escolars.

La qüestió de la seguretat de l'escriptura (write-back), però, és més punyent en un context de llibre diari que en els bancs de proves. Un agent que genera Python per llegir dades de Beancount és de baix risc. Un que genera Python per escriure assentaments al llibre diari necessita un entorn d'execució estrictament restringit: un que només pugui tocar objectes del llibre diari i res més, que es bloquegi davant qualsevol excepció i que requereixi que el codi generat passi una llista blanca abans de l'execució. PAL tracta l'intèrpret com un motor de càlcul neutre. Un agent financer de producció no pot fer-ho.

Què llegir a continuació

• Program of Thoughts Prompting (Chen et al., arXiv:2211.12588): treball concurrent que avalua FinQA, ConvFinQA i TATQA i informa d'un guany mitjà d'un 12 % sobre CoT; l'avaluació específica de finances que PAL posposa.
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen et al., EMNLP 2021): el banc de proves que hi ha darrere de les avaluacions financeres de PoT; entendre què s'està provant realment calibra quant es pot confiar en el trasllat als casos d'ús reals de Beancount.
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., arXiv:2303.17651): del mateix primer autor que PAL, amplia la visió de la generació de codi a bucles d'autocorrecció iteratius; rellevant per si els agents d'estil PAL poden recuperar-se dels seus propis errors de generació de codi.