Els LLM obtenen un 2,3% en la generació de DSL de Beancount: El benchmark LLMFinLiteracy

Aquest és l'article que estava esperant des de LOG-001: una prova empírica directa de si els LLM poden generar transaccions vàlides en el DSL de Beancount a partir d'escenaris financers en llenguatge natural. Figueroa et al., de la Universitat de Ciències Aplicades de Berlín, presenten el que afirmen —rectament, pel que puc veure— que és la primera avaluació publicada dels LLM en la generació de transaccions financeres en comptabilitat en text pla. La resposta curta és: no poden, almenys no de manera fiable, fins i tot amb prompting de cadena de pensament (chain-of-thought) i tenint el balanç de situació real de Beancount com a context.

L'article

Figueroa, Grundmann, Freidank, Löser i Nejdl avaluen cinc models de pesos oberts d'uns 7B en un benchmark de dues tasques que anomenen LLMFinLiteracy. La Tasca 1 demana als models generar escenaris textuals que afectarien una ràtio de liquiditat determinada (corrent, prova del dret o de tresoreria) a partir d'un balanç trimestral real d'una de les cinc empreses de l'índex DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). La Tasca 2 demana als models traduir aquests escenaris en transaccions de Beancount compilables. El compilador de Beancount serveix com a verificador de sintaxi de referència; experts humans avaluen la correcció semàntica. L'article introdueix una taxonomia d'errors de 12 classes en les dues tasques i utilitza un prompt de cadena de pensament de 9 passos que inclou regles de comptabilitat per partida doble, un exemple d'entrada/sortida i el balanç real de l'empresa en format Beancount. Els models avaluats —Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B i CodeQwen-1.5-7B— es van executar de forma local a causa de la sensibilitat de les dades financeres. El corpus totalitza 1.500 mostres generades, amb 300 entrades estratificades avaluades per experts humans.

Idees clau

• Només 7 dels 300 parells d'escenari-transacció avaluats (2,3%) van ser totalment correctes de principi a fi; fins i tot restringint-ho als tres models de propòsit general, la taxa només puja al 3,8%.
• Els dos millors models, Qwen-2-7B i Mistral-7B, produeixen escenaris correctes només el 21,67% i el 20,00% de les vegades, i transaccions que compilen correctament només el 16,67% i el 10,00% de les vegades.
• Els models especialitzats en codi (CodeLlama, CodeQwen) van obtenir un 0% en ambdues tasques; van respondre a la plantilla del prompt amb la cadena literal "Processat — Esperant la següent entrada", ignorant completament la tasca.
• La sintaxi no és el coll d'ampolla: cap model va produir ni un sol error de sintaxi. Els errors es troben totalment en el raonament comptable —els errors de balanç dominen en Qwen-2 (61,67%) i Llama-3 (38,33%), mentre que Mistral fa referència sobretot a comptes que no existeixen en el balanç proporcionat (45% d'errors de compte desconegut).
• Una fracció significativa de les transaccions que compilen correctament són semànticament errònies —el truc preferit del model és anomenar la reducció d'un passiu "vendre el teu deute", cosa que augmenta l'efectiu però per un motiu equivocat.
• El GPT-4o, utilitzat com a jutge automatitzat, no va detectar inconsistències en cap dels 10 escenaris sense sentit que se li van mostrar, confirmant que l'autoavaluació dels LLM no és un filtre de qualitat fiable per a resultats comptables.
• Els models copien en gran mesura l'exemple d'entrada/sortida del prompt en lloc de generalitzar: els 7 parells correctes s'assemblen molt a l'estructura de la transacció d'exemple proporcionada.

Què se sosté i què no

La contribució empírica central de l'article és sòlida. El compilador de Beancount és un criteri de correcció objectiu i reproduïble, i l'ús de balanços reals d'empreses en lloc de dades de prova simplificades aporta validesa ecològica. La taxonomia jeràrquica d'errors està dissenyada amb criteri: aturar l'avaluació al primer error evita inflar el "crèdit parcial" per resultats sense sentit.

Dit això, hi ha limitacions òbvies que els autors reconeixen majoritàriament. Cinc models de pesos oberts d'uns 7B del 2023–2024 són una part petita del panorama de capacitats; el GPT-4o i el Claude van ser exclosos per motius de privadesa, cosa que és comprensible però significa que la xifra titular (2,3% de correcció) subestima la frontera tecnològica. Les fórmules de les ràtios financeres es van ometre deliberadament dels prompts per provar el coneixement inherent del domini —una elecció metodològicament interessant, però que fa que els resultats no siguin comparables a cap sistema que inclouria raonablement la documentació de les fórmules. I 300 mostres avaluades per humans entre cinc models, tres ràtios i cinc empreses és una xifra modesta; les cel·les per model i ràtio són massa petites (12 mostres) per treure conclusions sòlides sobre la variància.

La llacuna metodològica més interessant és l'absència de qualsevol protocol iteratiu o basat en el feedback. Res de crides a eines, ni autocorrecció, ni bucle de feedback amb el compilador —només generació d'un sol intent (one-shot). Atès que CRITIC (LOG-012) i treballs relacionats mostren que el refinament interactiu amb eines millora substancialment la precisió en tasques amb resultats verificables, un experiment amb el compilador de Beancount en el bucle hauria estat molt més informatiu sobre la viabilitat de desplegament.

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

Cada decisió de disseny per a l'agent d'escriptura de Bean Labs es basa en suposicions sobre què poden fer els LLM amb el DSL de Beancount. Aquest article és la primera àncora empírica. Les conclusions principals són alliçonadores, però també es poden interpretar de manera útil.

En primer lloc, els modes d'error són específics, no aleatoris. Els errors de balanç i els comptes desconeguts són els dos problemes dominants, i ambdós es poden abordar amb un bucle de feedback del compilador: el compilador de Beancount t'indica exactament quin compte és desconegut i si la transacció està quadrada. Una arquitectura d'agent que iteri sobre la sortida del compilador —en lloc de generar una vegada i aturar-se— hauria de superar substancialment els resultats d'un sol intent d'aquí. En segon lloc, la sintaxi és "gratuïta". Els models han après clarament la gramàtica superficial de Beancount; simplement no poden traduir de manera fiable la intenció financera en moviments de compte correctes. Aquesta distinció és clau per decidir on invertir en prompting i ajust fi (fine-tuning). En tercer lloc, la troballa que el GPT-4o no pot avaluar la qualitat comptable automàticament puja el llistó per a qualsevol sistema de verificació automatitzat: necessites el compilador, a més de comprovacions puntuals d'experts en el domini, no un LLM com a crític.

L'article també confirma una cosa que sospitava del treball de detecció d'anomalies (LOG-049): els LLM que operen sobre transaccions financeres compilen i envien amb massa facilitat. La categoria "Incorrecte | Compila" —transaccions que passen la verificació sintàctica però són semànticament errònies— és exactament el mode d'error que un sistema de seguretat d'escriptura ha de detectar. Una transacció pot quadrar perfectament i tot i així comptabilitzar ingressos com una disminució del passiu, cosa que passaria desapercebuda per a qualsevol verificació purament sintàctica.

Què llegir a continuació

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — puntuació d'anomalies basada en la probabilitat com a alternativa a l'enfocament de detecció per lots; es combina naturalment amb un senyal del compilador de Beancount per marcar entrades estructuralment vàlides però estadísticament anòmales.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — desvia decisions de baixa confiança cap a un model més gran o cap a un humà; aborda directament la qüestió de quan un agent d'escriptura de Beancount hauria de recórrer a la revisió humana en lloc de continuar després d'un bucle de feedback del compilador.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — el treball existent més rellevant per construir un agent de correcció amb compilador en el bucle sobre l'arquitectura que avalua aquest article.