LLM dosahujú 2,3 % v generovaní Beancount DSL: Benchmark LLMFinLiteracy

Toto je vedecký príspevok, na ktorý som čakal od LOG-001: priamy empirický test toho, či LLM dokážu generovať platné transakcie Beancount DSL z finančných scenárov v prirodzenom jazyku. Figueroa a kol. z Berlínskej univerzity aplikovaných vied predstavujú to, čo – podľa môjho najlepšieho vedomia správne – označujú za prvú publikovanú evalváciu LLM v oblasti generovania finančných transakcií v rámci plain-text účtovníctva. Krátka odpoveď znie: nedokážu to, aspoň nie spoľahlivo, a to ani pri použití promptovania s reťazcom myšlienok (chain-of-thought) a s poskytnutou reálnou súvahou v Beancounte ako kontextom.

O príspevku

Figueroa, Grundmann, Freidank, Löser a Nejdl hodnotia päť modelov s otvorenými váhami o veľkosti cca 7B na benchmarku s dvoma úlohami, ktorý nazvali LLMFinLiteracy. Úloha 1 vyžaduje od modelov vygenerovať textové scenáre, ktoré by ovplyvnili daný ukazovateľ likvidity (bežnú, pohotovú alebo okamžitú likviditu) na základe reálnej štvrťročnej súvahy jednej z piatich spoločností kótovaných v indexe DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). Úloha 2 vyžaduje od modelov preložiť tieto scenáre do skompilovateľných transakcií Beancount. Kompilátor Beancount slúži ako overovateľ syntaktickej správnosti; experti na danú doménu následne hodnotia sémantickú správnosť. Príspevok zavádza taxonómiu chýb s 12 triedami naprieč oboma úlohami a používa 9-krokový prompt s reťazcom myšlienok, ktorý zahŕňa pravidlá podvojného účtovníctva, príklad vstupu/výstupu a reálnu firemnú súvahu vo formáte Beancount. Hodnotené modely — Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B a CodeQwen-1.5-7B — boli všetky spustené lokálne (on-premise) kvôli citlivosti finančných údajov. Korpus celkovo obsahuje 1 500 vygenerovaných vzoriek, pričom 300 stratifikovaných záznamov bolo vyhodnotených ľudskými expertmi.

Kľúčové myšlienky

• Iba 7 z 300 hodnotených párov scenár-transakcia (2,3 %) bolo plne správnych; aj pri obmedzení na tri univerzálne modely sa miera úspešnosti zvýši len na 3,8 %.
• Dva najlepšie modely, Qwen-2-7B a Mistral-7B, produkujú správne scenáre len v 21,67 % a 20,00 % prípadov a správne skompilovateľné transakcie len v 16,67 % a 10,00 % prípadov.
• Modely špecializované na kód (CodeLlama, CodeQwen) dosiahli v oboch úlohách 0 %; na šablónu promptu odpovedali doslovným reťazcom „Processed — Waiting for next input“, pričom úlohu úplne ignorovali.
• Syntax nie je úzkym hrdlom: žiadny model nevyprodukoval ani jednu syntaktickú chybu. Zlyhania spočívajú výhradne v účtovnom uvažovaní — chyby v rovnováhe (balance errors) dominujú u Qwen-2 (61,67 %) a Llama-3 (38,33 %), zatiaľ čo Mistral väčšinou odkazuje na účty, ktoré v poskytnutej súvahe neexistujú (45 % chýb neznámeho účtu).
• Významná časť transakcií, ktoré sa úspešne skompilujú, je sémanticky nesprávna – obľúbeným trikom modelov je nazývať zníženie záväzku „predajom vášho dlhu“, čo zvyšuje hotovosť, ale z nesprávneho dôvodu.
• GPT-4o použitý ako automatizovaný hodnotiteľ nedokázal identifikovať nezrovnalosti vo všetkých 10 nezmyselných scenároch, ktoré mu boli predložené, čo potvrdzuje, že sebahodnotenie LLM nie je spoľahlivou bránou kvality pre účtovné výstupy.
• Modely vo veľkej miere kopírujú príklad vstupu/výstupu v prompte namiesto generalizácie: 7 správnych párov sa úzko podobalo štruktúre poskytnutej ukážkovej transakcie.

Čo obstojí — a čo nie

Hlavný empirický prínos príspevku je solídny. Kompilátor Beancount je objektívne, reprodukovateľné kritérium správnosti a použitie reálnych firemných súvah namiesto umelých dát zvyšuje ekologickú validitu. Hierarchická taxonómia chýb je premyslene navrhnutá — zastavenie hodnotenia pri prvej chybe zabraňuje umelému navyšovaniu „čiastočných bodov“ za nepoužiteľné výstupy.

Napriek tomu existujú zrejmé obmedzenia, ktoré autori väčšinou priznávajú. Päť modelov s otvorenými váhami o veľkosti ~7B z rokov 2023–2024 predstavuje len úzky výsek súčasných schopností; GPT-4o a Claude boli vylúčené z dôvodu ochrany súkromia, čo je pochopiteľné, ale znamená to, že hlavné číslo (2,3 % správne) podhodnocuje možnosti špičkových modelov. Vzorcom finančných ukazovateľov sa v promptoch zámerne vyhli, aby otestovali inherentné znalosti domény — metodologicky zaujímavá voľba, ktorá však robí výsledky neporovnateľnými s akýmkoľvek systémom, ktorý by logicky obsahoval dokumentáciu vzorcov. A 300 ľudsky vyhodnotených vzoriek naprieč piatimi modelmi, tromi ukazovateľmi a piatimi spoločnosťami je skromný počet; skupiny vzoriek pre jednotlivé modely a ukazovatele sú príliš malé (12 vzoriek) na vyvodenie silných záverov o variancii.

Najzaujímavejšou metodologickou medzerou je absencia akéhokoľvek iteratívneho protokolu alebo protokolu založeného na spätnej väzbe. Žiadne volanie nástrojov (tool-calling), žiadna samooprava, žiadna slučka spätnej väzby kompilátora — iba jednorazové generovanie. Vzhľadom na to, že CRITIC (LOG-012) a súvisiace práce ukazujú, že interaktívne vylepšovanie pomocou nástrojov podstatne zvyšuje presnosť pri úlohách s overiteľnými výstupmi, experiment so zapojením kompilátora Beancount do slučky (compiler-in-the-loop) by bol oveľa informatívnejší z hľadiska nasaditeľnosti v praxi.

Prečo je to dôležité pre AI vo financiách

Každé konštrukčné rozhodnutie pre agenta na spätný zápis v Bean Labs sa opiera o predpoklady o tom, čo LLM dokážu s Beancount DSL. Tento príspevok je prvou empirickou kotvou. Hlavné zistenia sú triezve, ale zároveň interpretovateľné užitočným spôsobom.

Po prvé, režimy zlyhania sú špecifické, nie náhodné. Chyby v rovnováhe a neznáme účty sú dva dominantné problémy a oba sú riešiteľné pomocou spätnej väzby kompilátora: kompilátor Beancount vám presne povie, ktorý účet je neznámy a či je transakcia vyrovnaná. Architektúra agenta, ktorá iteruje na výstupe kompilátora — namiesto toho, aby raz vygenerovala výstup a skončila — by mala podstatne prekonať tu uvedené jednorazové výsledky. Po druhé, syntax je „zadarmo“. Modely sa jasne naučili povrchovú gramatiku Beancountu; len nedokážu spoľahlivo preložiť finančný zámer do správnych pohybov na účtoch. Tento rozdiel je dôležitý pre určenie toho, kam investovať pri promptovaní a jemnom ladení (fine-tuning). Po tretie, zistenie, že GPT-4o nedokáže automaticky vyhodnotiť kvalitu účtovníctva, zvyšuje nároky na akýkoľvek automatizovaný overovací systém: potrebujete kompilátor plus námatkové kontroly doménovými expertmi, nie LLM kritika.

Príspevok tiež potvrdzuje niečo, čo som tušil pri práci na detekcii anomálií (LOG-049): LLM operujúce nad finančnými transakciami majú tendenciu až príliš ľahko „skompilovať a odoslať“. Kategória „Nesprávne | Skompilovateľné“ – transakcie, ktoré prejdú syntaktickou kontrolou, ale sú sémanticky chybné – je presne ten typ zlyhania, ktorý musí zachytiť bezpečnostná poistka pre spätný zápis. Transakcia môže byť dokonale vyrovnaná a stále účtovať výnosy ako zníženie záväzku, čo by nebolo odhalené žiadnou čisto syntaktickou kontrolou.

Čo čítať ďalej

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — skórovanie anomálií na základe pravdepodobnosti ako alternatíva k prístupu detekcie v dávkach; prirodzene sa kombinuje so signálom z kompilátora Beancount na označenie štrukturálne platných, ale štatisticky anomálnych záznamov.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — smeruje rozhodnutia s nízkou istotou na väčší model alebo človeka; priamo rieši otázku, kedy by mal agent na zápis do Beancountu delegovať prácu na ľudskú kontrolu namiesto pokračovania po slučke spätnej väzby kompilátora.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — najrelevantnejšia existujúca práca pre budovanie korekčného agenta s kompilátorom v slučke nad architektúrou, ktorú hodnotí tento príspevok.