Článok​

Zhao, Jin, Li a Gao z Pekinskej univerzity predstavujú FinRAGBench-V, bilingválny benchmark vytvorený zo skutočných finančných dokumentov: výskumných správ, účtovných závierok, prospektov, akademických prác, časopisov a novinových článkov. Korpus na vyhľadávanie je značný – 60 780 čínskych strán a 51 219 anglických strán v približne 1 100 dokumentoch na jazyk – spárovaný s 1 394 manuálne anotovanými pármi QA (otázka-odpoveď) pokrývajúcimi sedem kategórií otázok: textová inferencia, extrakcia z grafov a tabuliek, numerické výpočty, časovo citlivé dopyty a viacstranové uvažovanie. Okrem datasetu je hlavným prínosom článku RGenCite, základný (baseline) systém, ktorý generuje odpovede spolu s vizuálnymi citáciami na úrovni pixelov vo forme súradníc ohraničujúcich boxov (bounding boxes) označujúcich konkrétne oblasti dokumentu, ktoré podporujú každé tvrdenie.

Kľúčové myšlienky​

• Multimodálne vyhľadávanie dominuje nad čisto textovým s drvivým náskokom: ColQwen2, vizuálno-jazykový vyhľadávač postavený na embeddingoch obrázkov stránok, dosahuje Recall@10 90,13 % (čínština) a 85,86 % (angličtina). Najlepšie textové vyhľadávače, BM25 a BGE-M3, dosahujú maximálne okolo 42,71 %. Tento rozdiel nie je len štatistickou chybou.
• Presnosť generovania je nízka aj pri špičkových modeloch: GPT-4o v angličtine dosahuje presnosť 43,41 % (ROUGE 24,66); o4-mini v čínštine dosahuje 58,13 % (ROUGE 38,55). Ide o špičkové proprietárne modely so silným nastavením vyhľadávania.
• Citácie na úrovni stránky fungujú; na úrovni blokov nie: Úspešnosť vyhľadávania (recall) na úrovni stránky sa pri najlepších modeloch pohybuje v rozmedzí 75 – 93 %. Recall na úrovni blokov – teda vedieť, ktorá konkrétna bunka tabuľky alebo oblasť grafu podkladá tvrdenie – klesá na 20 – 61 %. To je kľúčová medzera pre auditovateľnosť.
• Numerické uvažovanie a viacstranová inferencia lámu modely ako prvé: Otázky vyžadujúce výpočty naprieč stránkami alebo časovými obdobiami sú tie, kde presnosť klesá najprudšie vo všetkých testovaných systémoch.
• Proprietárne modely výrazne prekonávajú open-source alternatívy: Rozdiel medzi uzavretými API a open-source riešeniami je tu väčší ako vo väčšine NLP benchmarkov, čo naznačuje, že vizuálne finančné uvažovanie zostáva pre otvorené modely nevyriešené.
• Automatické vyhodnocovanie citácií je nedokonalé: Evaluátor citácií založený na orezávaní obrázkov dosahuje Pearsonovo r = 0,68 v porovnaní s ľudským hodnotením – je to primerané, ale nie dostatočne spoľahlivé na to, aby sa mu dalo plne dôverovať bez dodatočnej kontroly.

Čo obstojí — a čo nie​

Zistenie o vyhľadávaní je najdôveryhodnejším výsledkom článku. Rozdiel takmer 50 percentuálnych bodov medzi multimodálnymi a čisto textovými vyhľadávačmi pri viac ako 60 tisícoch strán je príliš veľký na to, aby sa dal ignorovať. Keď pred indexovaním finančného dokumentu použijete OCR, zničíte signály o štrukturálnom rozložení – v ktorom stĺpci sa číslo nachádza, či popis obrázka upravuje interpretáciu tabuľky – čo sa ukazuje ako nesmierne dôležité pre vyhľadávanie.

Čísla týkajúce sa generovania sú úprimné, ale v izolácii sa ťažko interpretujú. Autori nerozoberajú, aká časť medzery v presnosti je pripísateľná chybám vyhľadávania oproti zlyhaniam generovania. Vzhľadom na to, že Recall@10 je pre angličtinu už 85,86 %, významná časť zlyhaní musí byť na strane generovania, nie vyhľadávania. Poznanie tohto rozdelenia by objasnilo, či je úzkym hrdlom multimodálne uvažovanie alebo niečo zásadnejšie v tom, ako MLLM pracujú s finančným jazykom.

Evaluačný súbor 1 394 párov QA je na rozsah benchmarku malý. Rozdelené do siedmich kategórií a dvoch jazykov majú niektoré časti menej ako 200 príkladov. Štatistická významnosť zistení na úrovni kategórií zostáva implicitná. Pre článok o benchmarku to nie je nezvyčajné, ale znamená to, že by bolo ľahké vytvoriť účelovo vybrané (cherry-picked) porovnania.

Protokol na vyhodnocovanie citácií je zaujímavým prínosom, ale Pearsonovo r = 0,68 v porovnaní s ľudským hodnotením nie je dostatočne silné na to, aby sa automatické vyhodnocovanie považovalo za absolútnu pravdu pre ukotvenie na úrovni blokov. Autori to priznávajú; budúca práca na lepších metrikách citácií je výslovne označená za potrebnú.

Prečo je to dôležité pre finančnú AI​

Beancount funguje nad čisto textovými súbormi účtovných denníkov (ledgers), vďaka čomu je čisto textový RAG obhájiteľný pri dopytovaní sa na minulé transakcie. Širšia účtovná úloha však zahŕňa dokumenty, ktoré rozhodne nie sú čisto textové: bankové výpisy v PDF, skenované faktúry, obrázky účteniek, výročné správy s vloženými tabuľkami a grafmi. Vo chvíli, keď agent Beancount potrebuje odsúhlasiť (reconcile) záznam v denníku so zdrojovým dokumentom – overiť, či konkrétna platba súhlasí s faktúrou v evidencii – vykonáva presne tú istú úlohu, ktorú testuje FinRAGBench-V.

Zistenie o citáciách na úrovni blokov je pre tento prípad použitia najdôležitejšie. Ak musí agent odôvodniť záznam v účtovnej knihe ukázaním na konkrétnu riadkovú položku v PDF a najlepší dostupný systém dosahuje len 20 – 61 % recallu na úrovni blokov, nie je to pripravené na audit. Akýkoľvek proces v Beancount, ktorý pracuje s naskenovanými zdrojovými dokumentmi, potrebuje kontrolu človekom, kým sa toto číslo výrazne nezlepší.

Rozdiel v modalite vyhľadávania tiež silne hovorí proti čisto textovým procesom pri spracovaní dokumentov. Obrázok účtenky nesie informácie o rozložení – polia s čiastkami, názvy dodávateľov, pozície riadkových položiek – ktoré OCR zničí. Práve tieto informácie o rozložení odlišujú celkovú sumu od sumy dane a FinRAGBench-V ukazuje, že multimodálne vyhľadávače ich využívajú spôsobom, ktorý textové vyhľadávače nedokážu.

Čo si prečítať ďalej​

• ColPali: Efficient Document Retrieval with Vision Language Models — predchodca modelu ColQwen2, na ktorom je postavený vizuálny prístup embeddingov stránok najlepšieho vyhľadávača v FinRAGBench-V [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding — rieši vizuálne QA nad viacerými dokumentmi pomocou flexibilného rámca, ktorý zvláda jedno- aj viacúrovňové vizuálne uvažovanie naprieč stránkami [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance — sprievodný benchmark z roku 2025 hodnotiaci časovú citlivosť vo finančnom multimodálnom RAG, ktorý priamo dopĺňa kategóriu časovo citlivých otázok vo FinRAGBench-V [arXiv:2503.05185]

Štúdia​

EnterpriseArena je 132-mesačná (11-ročná) simulácia alokácie zdrojov na úrovni finančného riaditeľa (CFO). Každý časový krok predstavuje jeden mesiac. Agent dostáva čiastočné pozorovania o financiách na úrovni firmy, anonymizované obchodné dokumenty a makroekonomické signály čerpané z údajov FRED, CBOE a S&P Global. Má rozpočet 20 volaní nástrojov (tool calls) mesačne rozdelených medzi štyri operácie — overenie hotovostnej pozície, kontrola finančných záznamov, analýza trhových podmienok a prognózovanie hotovostných tokov — a musí si vybrať jednu z troch akcií: uzavrieť účtovné knihy (odsúhlasenie), požiadať o financovanie (vlastné imanie alebo dlh, so stochastickými výsledkami) alebo nič neurobiť (pass). Primárnym obmedzením je, že zostatok hotovosti spoločnosti musí zostať nezáporný v každom časovom kroku; porušenie ukončí epizódu so skóre nula. Pri zachovaní prežitia agent maximalizuje konečnú hodnotu podniku podľa vzorca Rev_T × 5 + Cash_T − 5 000 × N_tools, ktorý explicitne penalizuje nadmerné používanie nástrojov.

Bolo vyhodnotených jedenásť modelov LLM, vrátane Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B a Qwen3.5-9B, spolu s benchmarkom ľudského experta validovaným dvoma finančnými profesionálmi s 8 a 14-ročnými skúsenosťami.

Kľúčové myšlienky​

• Miera prežitia sa u jednotlivých modelov výrazne líši: Qwen3.5-9B prežije 80 % behov, Gemini-3.1-Pro 50 %, Claude-Haiku-4.5 a GLM-5 každý 20 %, a GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B a Mixtral-8x7B zhodne 0 %. Celkový priemer LLM je 26 %.
• Väčšie modely spoľahlivo neprekonávajú tie menšie: Qwen3.5-9B (9 mld. parametrov, 80 % prežitie, konečná hodnota 78,8 mil. USD) rozhodne poráža Qwen3.5-397B (397 mld. parametrov, 20 % prežitie) a GPT-5.4 (0 % prežitie).
• Odstup od ľudí je veľký: ľudský benchmark dosahuje 100 % prežitie a konečnú hodnotu 152,2 mil. USD ± 29,6 mil. USD; priemer LLM je 28,2 mil. USD s 26 % prežitím.
• Uzávierka účtovných kníh je kritickým úzkym hrdlom: ľudskí experti uzatvárajú knihy (reconcile) v 94,3 % časových krokov; priemer LLM je 19,3 %. Toto je akcia, ktorá vytvára pravdivé finančné výkazy a umožňuje racionálne následné rozhodnutia.
• Zhromažďovanie informácií bez akcie je fatálne: Qwen3.5-397B počas simulácie vo vysokej miere využíva nástroje na analýzu trhu a prognózovanie, ale takmer nikdy neuzatvára knihy (0,0 % miera uzávierky) a takmer nikdy nežiada o financovanie, pričom zaniká v dôsledku vyčerpania hotovosti napriek tomu, že „vie“, čo sa deje.
• Penalizácia rozpočtu na nástroje je dôležitá: vzorec bodovania aktívne trestá agentov, ktorí nutkavo kontrolujú namiesto toho, aby konali, čo je obmedzenie, ktoré odráža skutočné náklady príležitosti.

Čo obstojí — a čo nie​

Dvojitý cieľ dizajnu — prežitie ako pevné obmedzenie plus konečná hodnota — je jednou z najsilnejších volieb v nedávnom benchmarkingu agentov. Odráža to, ako skutoční finanční riaditelia v praxi fungujú: nemôžete optimalizovať rast, ak ste bez peňazí. Anonymizácia kalendárnych dátumov a identít spoločností bráni modelom v rozpoznávaní vzorov na základe zapamätaných historických výsledkov, čo je skutočné metodologické zlepšenie oproti finančným benchmarkom, ktoré používajú reálne tickery a dátumy.

Taxonómia zlyhaní, ktorú autori identifikujú prostredníctvom prípadových štúdií, je dôveryhodná: GPT-5.4 dosahuje 99,1 % mieru „pass“ (čo znamená, že v takmer každom časovom kroku vykoná akciu nerobenia ničoho), zatiaľ čo Qwen3.5-397B si mýli analýzu s akciou. Ide o behaviorálne odlišné spôsoby zlyhania s rôznymi riešeniami.

O čom som menej presvedčený: stochastické makroprostredie využíva Gaussov šum na aproximáciu trhových šokov, čo podľa priznania samotných autorov nedokáže replikovať udalosti typu „čierna labuť“ alebo ľudskú iracionalitu. Rozpočet nástrojov vo výške 20 volaní mesačne je tiež mierne ľubovoľný — skutoční finanční riaditelia nečelia takémuto obmedzeniu miery dopytov voči vlastnej pamäti, čo vyvoláva otázku, či benchmark meria dlhodobý finančný úsudok alebo skôr niečo ako RAG pod tlakom zdrojov. Štruktúra s jedným agentom je ďalším explicitným obmedzením, ktoré autori uvádzajú: skutoční finanční riaditelia pracujú v hierarchiách kontrolórov, analytikov FP&A a tímov pokladnice, čo sa táto práca nepokúša simulovať.

Zistenie, že veľkosť modelu nepredpovedá prežitie, je zarážajúce a pravdepodobne pravdivé, ale mechanizmus nie je dobre vysvetlený. Autori to konštatujú bez toho, aby plne rozobrali, či ide o zlyhanie pri dodržiavaní inštrukcií, koherenciu dlhého kontextu alebo kalibráciu rizika.

Prečo je to dôležité pre finančnú AI​

Akcia uzatvárania kníh v EnterpriseArena je v podstate príkaz balance a krok odsúhlasenia účtovnej knihy v Beancounte — moment, kedy sa agent pred konaním zaviaže k pravdivému pohľadu na finančný stav. Zistenie, že LLM to v 80 % prípadov vynechávajú, priamo súvisí s problémom bezpečnosti spätného zápisu (write-back): agent, ktorý sa pred akciou vyhýba odsúhlaseniu, je agent, ktorý koná na základe zastaraného alebo halucinovaného stavu. Pre automatizáciu Beancountu to naznačuje, že krok odsúhlasenia by mal byť povinný a overiteľný — nie voliteľný — v akomkoľvek cykle agenta.

132-mesačný horizont je tiež priamo analogický s viacročnou správou účtovných kníh. Zistenie, že trvalé situačné povedomie sa časom zhoršuje, je rovnaká degradácia, akú by sme očakávali u agenta Beancount spravujúceho päťročnú históriu transakcií: aj keď má agent všetky dáta v kontexte, nemusí na ne v 60. mesiaci reagovať koherentne. To naznačuje, že v dlhodobých reláciách agentov Beancount sú potrebné periodické vynútené kontrolné body odsúhlasenia, nielen reaktívne dopytovanie.

Pasca zhromažďovania informácií, do ktorej padol Qwen3.5-397B, je užitočným varovaním pre dizajn: agenti vybavení mnohými nástrojmi na vyhľadávanie môžu uprednostňovať vyhľadávanie pred záväzkom, najmä ak sú náklady na nesprávnu akciu (poškodenie účtovnej knihy) vysoké. Obmedzenia rozpočtu nástrojov typu, aký používa EnterpriseArena, by mohli pomôcť vynútiť disciplínu v konaní u agentov pre spätný zápis do Beancountu.

Čo si prečítať ďalej​

• EcoGym (arXiv:2602.09514) — doplnkový benchmark pre dlhodobú ekonomiku v prostrediach Vending, Freelance a Operation počas viac ako 1 000 krokov; žiadny model nedominuje vo všetkých troch, čo naznačuje, že spôsoby zlyhania v EnterpriseArena nie sú špecifické len pre jeden dizajn benchmarku.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — preformulováva dizajn pracovných postupov ako vyhľadávanie v priestore kódu pomocou MCTS a spätnej väzby od LLM; ak EnterpriseArena ukazuje, že manuálne navrhnuté správanie agentov zlyháva, AFlow je zrejmým ďalším krokom k automatickému objavovaniu lepších procesov.
• ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — základný rámec pre tréning a vyhodnocovanie používania nástrojov; pochopenie toho, ako sa správanie pri volaní nástrojov učí v ToolLLM, objasňuje, či je zlyhanie vo vyhýbaní sa akcii v EnterpriseArena problémom tréningu alebo promptingu.

Odborná publikácia​

Peijie Yu, Wei Liu, Yifan Yang a kolegovia z Alibaby predstavujú WildToolBench (arXiv:2604.06185), benchmark s 256 scenármi viackolových dialógov s 1 024 úlohami čerpanými z autentických vzorcov správania používateľov a založenými na približne 1 600 verejných API. Hlavným argumentom je, že existujúce benchmarky sa nasýtia nie preto, že by modely boli dobré, ale preto, že úlohy sú umelé. Reálni používatelia spájajú požiadavky dokopy, vynechávajú kontext, ktorý zdieľali pred dvoma kolami, a prepínajú medzi kladením otázok o nástroji, bežnou konverzáciou a žiadosťou o vysvetlenie – niekedy v rámci jednej správy. WildToolBench operacionalizuje tieto režimy zlyhania do troch štruktúrovaných kategórií výziev a meria presnosť na úrovni úloh aj oveľa prísnejšiu presnosť na úrovni relácie, ktorá si vyžaduje úspech vo všetkých štyroch úlohách v dialógu.

Kľúčové myšlienky​

• Presnosť relácie klesá u väčšiny modelov na jednociferné čísla: Gemini-2.0-Flash-Thinking vedie so 14,45 % presnosťou relácie, Claude-4-Sonnet má 12,50 %, GPT-4o 11,72 %. Úspešné zvládnutie všetkých úloh v štvorstupňovej relácii je také náročné, že aj 60 % presnosť na úrovni úloh sa prejaví v menej ako 15 % presnosti relácie – čo je daň za kombinovanú pravdepodobnosť pri každej interakcii.
• Kompozičná orchestrácia je najstrmším útesom: Zmiešané sekvenčné a paralelné topológie nástrojov obmedzujú najlepšie modely na 25 % presnosť úloh v porovnaní s 54 – 62 % pri čisto paralelných alebo sekvenčných reťazcoch. Keď úloha vyžaduje paralelné rozvetvenie (fan-out) nasledované sekvenčným zlúčením (merge), problém koordinácie prevyšuje to, čo súčasné modely dokážu spoľahlivo zvládnuť.
• Skrytý zámer je väčšou medzerou, než sa doteraz meralo: WildToolBench zabezpečuje, že 100 % úloh zahŕňa implicitné informácie alebo informácie z viacerých kôl; BFCL v3 to zvláda len na 15,7 %. Úlohy s dlhodobou závislosťou – kde chýbajúca informácia pochádza spred viac ako dvoch kôl – sú najťažším podtypom, pričom žiadny model neprekoná 50 % ani na úrovni úloh.
• Prechody v inštrukciách znásobujú chyby lineárnym tempom: Každé ďalšie prepnutie politiky (úloha s nástrojom → čet → vysvetlenie → úloha s nástrojom) znižuje presnosť približne o 5 – 15 percentuálnych bodov. Pri troch prechodoch strácajú najviac zasiahnuté modely 30 bodov. Autori to nazývajú „vlastné podmieňovanie“ (self-conditioning): predchádzajúce odpovede ovplyvňujú interpretáciu následných inštrukcií modelom spôsobom, ktorý je ťažké opraviť uprostred relácie.
• Miera optimálnej cesty (Optimal Path Rate) zostáva pod 43 %: Aj keď modely dokončia úlohy správne, spotrebujú nadbytočné volania API. Claude-4-Sonnet dosahuje najlepšiu mieru optimálnej cesty 42,74 %, čo znamená, že väčšina správnych dokončení vyžaduje viac krokov, než je potrebné – čo predstavuje priame náklady na latenciu a tokeny pre akýkoľvek produkčný systém.
• Špecializované modely na používanie nástrojov zaostávajú za všeobecnými špičkovými modelmi: xLAM-2-70B aj ToolACE2-8B vykazujú mieru chýb v názvoch funkcií vyššiu ako 30 %, čo je horšie ako GPT-4o alebo Claude-4-Sonnet. Zdá sa, že jemné doladenie na úzkych korpusoch používania nástrojov vytvára skôr krehkosť než robustnosť pri prechode na distribúciu reálneho správania používateľov.

Čo obstojí – a čo nie​

Dizajn benchmarku je silný tam, kde na tom najviac záleží. Rozlíšenie medzi presnosťou úloh a presnosťou relácie je presne správne: hromadenie režimov zlyhania je to, čo zabíja reálne nasadenia, a väčšina predchádzajúcich prác uvádza čísla na úrovni úloh, ktoré to maskujú. Taxonómia troch výziev (kompozičná orchestrácia, skrytý zámer, prechody v inštrukciách) je dobre zdôvodnená a empiricky doložená – krivky degradácie výkonu naprieč typmi výziev sú reálne a markantné.

Slabým miestom je rozsah. 1 024 úloh z 256 scenárov je dôveryhodný výskumný artefakt, ale málo pre rebríček, ktorý má v priebehu času sledovať 57 modelov. Autori to priamo priznávajú a spomínajú automatizovanú škálovaciu líniu v budúcej práci. Ďalším problémom je, že tvrdenie „založené na reálnych logoch používateľov“ nesie veľkú váhu: výsledné úlohy sú čiastočne syntetické, zostavené multi-agentovým systémom z počiatočných vzorov a následne overené ľudskými anotátormi. Tvrdenie je podložené, ale dáta nie sú doslovne „divoké“ (wild) – sú divokým správaním inšpirované. To je dôležité pre to, ako doslovne interpretovať 15 % strop; časť medzery by sa mohla uzavrieť, ak proces generovania vnáša umelú náročnosť, ktorú reálni používatelia v skutočnosti nevykazujú.

Som tiež skeptický voči analýze prechodov v inštrukciách ako architektonickému tvrdeniu. Práca to pripisuje fundamentálnemu obmedzeniu, ale nesúlad v distribúcii tréningových dát medzi cieľmi jemného doladenia RLHF a multimodálnymi reláciami používateľov je úspornejším vysvetlením. To je riešiteľné, nie štrukturálne.

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

Tieto tri režimy zlyhania takmer dokonale zodpovedajú tomu, ako reálni používatelia interagujú s agentom na zápis do Beancountu. Používateľ sa spýta: „Koľko som minul na potraviny minulý mesiac a rovno tam pridaj dnešný blok z Whole Foods“ – to je kompozičná úloha spojená do jedného kola. Nasleduje: „Vlastne to zmeň na 47,23 USD, nie 42, pozrel som si to“ – to je oprava parametra vyžadujúca, aby agent sledoval stav relácie. Potom sa opýtajú: „Je tá kategória správna?“ – to je žiadosť o vysvetlenie a agent nesmie znova vykonať operáciu zápisu, ktorú práve dokončil. 25 % strop na zmiešanú sekvenčnú a paralelnú orchestráciu a 30-bodový pokles pri prechodoch v inštrukciách sú presne tie režimy zlyhania, ktoré by sa prejavili u agenta spravujúceho účtovnú knihu pri vybavovaní reálnych relácií používateľov.

Zistenie, že špecializované modely na používanie nástrojov zaostávajú za všeobecnými špičkovými modelmi, je obzvlášť relevantné. Ak by sme uvažovali o jemnom doladení menšieho otvoreného modelu na príkladoch volania nástrojov špecifických pre Beancount – čo je logický krok na zníženie nákladov – WildToolBench je priamym varovaním, že špecializácia môže obetovať robustnosť voči distribúcii skutočného správania používateľov. Dôležité je aj zistenie o miere optimálnej cesty: agent, ktorý na dokončenie úlohy spotrebuje dvakrát viac volaní API, je nielen neefektívny; pri operáciách spätného zápisu môžu nadbytočné medzikroky zanechať účtovnú knihu v nekonzistentných medzistavoch.

Čo si prečítať ďalej​

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) – základný tréningový rámec, voči ktorému sa WildToolBench explicitne vymedzuje; pochopenie jeho dizajnu syntetického vyhodnocovania objasňuje, čo presne prináša živé vykonávanie úloh.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) – najbližšia predchádzajúca práca o realistickom viackolovom používaní nástrojov; porovnanie domén maloobchodu/leteckej dopravy v τ-bench s pokrytím verejných API vo WildToolBench ukazuje, nakoľko je táto výzva všeobecná.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) – ak je problém prechodov v inštrukciách riešiteľný automatickým objavovaním lepších pracovných postupov agentov namiesto škálovania tréningových dát, AFlow je najdôveryhodnejším mechanizmom, ako to dosiahnuť.

O článku​

Geng, Cai, Wang, Koeppl, Nakov a Gurevych skúmajú vznikajúcu literatúru o odhade istoty a kalibrácii LLM v úlohách siahajúcich od QA s výberom odpovedí až po generovanie s otvoreným koncom a strojový preklad. Jadro problému: LLM môžu byť vysoko presné a zároveň úplne nespoľahlivé spôsobmi, ktoré je zvonku ťažké rozlíšiť. Prehľad organizuje priestor riešení do dvoch hlavných vetiev – metódy bielej skrinky (white-box), ktoré využívajú prístup k vnútorným stavom modelu, a metódy čiernej skrinky (black-box), ktoré pristupujú k modelu ako k nepriehľadnému – a v rámci každej ďalej rozlišuje medzi odhadom istoty a jej následnou (post hoc) kalibráciou.

Článok bol publikovaný na NAACL 2024 (strany 6577–6595), revidovaný v marci 2024 z novembrového podania z roku 2023 tímom z TU Darmstadt, MBZUAI a Mohamed bin Zayed University of AI.

Kľúčové myšlienky​

• Istota typu biela skrinka cez logity: Najjednoduchší prístup využíva pravdepodobnosti na úrovni tokenov alebo dĺžkovo normalizovanú log-pravdepodobnosť (log-likelihood) ako signál istoty. Tieto metódy fungujú, ale čelia základnej nejednoznačnosti: nízka pravdepodobnosť tokenu môže odrážať nízku faktickú istotu alebo jednoducho nezvyčajné formulácie – model môže byť neistý vo výbere slov, pričom si je istý podkladovým faktom.

• Istota typu čierna skrinka založená na konzistencii (SelfCheckGPT): Manakul a kol. (EMNLP 2023) vzorkujú viacero dokončení a vyhodnocujú ich vzájomnú konzistenciu pomocou BERTScore, NLI alebo n-gramového prekrytia. Nie je potrebný prístup k logitom. Kľúčový poznatok: pri faktoch, ktoré LLM dobre pozná, sa opakované vzorky zhodujú; pri halucinovanných faktoch sa rozchádzajú.

• Sémantická entropia: Farquhar a kol. (Nature, 2024) zoskupujú sémanticky ekvivalentné odpovede pred výpočtom entropie. LLM môže formulovať „Paríž“ a „hlavné mesto Francúzska“ odlišne – surová entropia tokenov ich považuje za divergentné, sémantická entropia nie. Toto je kvalitatívny krok vpred oproti konzistencii na úrovni tokenov, ktorý tento prehľad uvádza do kontextu.

• Verbalizovaná istota je nepoužiteľná: Keď sú modely požiadané, aby uviedli percento istoty, skĺzavajú k nadmernej sebaistote. Empirická práca (Groot a kol., TrustNLP na ACL 2024) zisťuje, že GPT-3, GPT-3.5 a Vicuna vykazujú priemernú očakávanú chybu kalibrácie (ECE) presahujúcu 0,377 pre verbalizovanú istotu, pričom predpovede sa zhlukujú v rozsahu 90 – 100 % bez ohľadu na skutočnú presnosť. Dokonca aj GPT-4 – najlepšie kalibrovaný hodnotený model – dosahuje AUROC len ~62,7 % pri použití verbalizovanej istoty na rozlíšenie správnych od nesprávnych odpovedí, čo je len tesne nad úrovňou náhody.

• Techniky kalibrácie sa líšia podľa úlohy: Pri klasifikácii riešia známe systematické skreslenia kontextová kalibrácia (odčítanie predpätia prioritnej triedy odhadnutého pomocou prázdnej výzvy „[N/A]“) a odstránenie pozičného skreslenia (PriDE). Pri generovaní dolaďuje modely na zoradených dokončeniach metóda Sequence Likelihood Calibration (SLiC). Škálovanie teploty (temperature scaling) – najjednoduchšia post-hoc oprava – zostáva konkurencieschopné v mnohých nastaveniach.

• Neexistuje žiadny zjednotený benchmark: Najviac usvedčujúce štrukturálne pozorovanie prieskumu: neexistuje jediný benchmark zahŕňajúci metódy odhadu istoty naprieč úlohami a doménami. To znemožňuje prísne porovnanie metód. Odbor v súčasnosti porovnáva jablká s hruškami.

Čo obstojí – a čo nie​

Taxonómia je solídna. Rozlíšenie medzi bielou a čiernou skrinkou je skutočne užitočné pre návrh systému a spracovanie metód založených na logitoch je úprimné v ich limitoch – autori priamo poznamenávajú, že pravdepodobnosť tokenu spája faktickú istotu s lexikálnou neistotou. Praktici toto spojenie často podceňujú.

V čom ma prieskum frustruje: je prevažne opisný. Neobsahuje takmer žiadne experimentálne benchmarky porovnávajúce metódy priamo medzi sebou a autori to výslovne priznávajú ako obmedzenie. Môžem odísť s jasnou mapou možností návrhu, ale bez návodu, ktorú metódu použiť pre novú úlohu.

Výsledky verbalizovanej istoty – AUROC GPT-4 ~62,7 % pri vlastnej deklarovanej istote – by mali byť kánonom pre každého, kto nasadzuje LLM do produkcie. Nie sú. Ľudia stále používajú prompty, ktoré sa pýtajú „na stupnici od 1 do 10, ako si si istý?“ a považujú odpoveď za zmysluplnú. Nie je.

Prieskum je tiež stručný v otázke kalibrácie RLHF: robí dotrénovanie pomocou ľudskej spätnej väzby modely lepšie alebo horšie kalibrovanými? Existujú dôkazy pre obe tvrdenia a prieskum sa im z veľkej časti vyhýba.

Prečo je to dôležité pre finančnú AI​

ReDAct stavia svoj príbeh bezpečnosti na kalibrovanom signále neistoty z lacného modelu. Tento prieskum jasne ukazuje, aké ťažké to v skutočnosti je. Signály založené na logitoch sú dostupné v nastaveniach bielej skrinky, ale spájajú lexikálnu a faktickú neistotu. Metódy založené na konzistencii fungujú v nastaveniach čiernej skrinky, ale vyžadujú viacero vzoriek na jedno rozhodnutie – čo je drahé pre agenta pre spätný zápis do Beancountu s vysokou priepustnosťou, ktorý spracováva dávku transakčných položiek.

Najviac využiteľné zistenie pre Bean Labs: sémantická entropia zoskupuje sémanticky ekvivalentné odpovede pred hodnotením konzistencie, čo je presne to, na čom záleží pri zápisoch do účtovnej knihy, kde model môže vyjadriť rovnaký vzťah Má dať/Dal vo viacerých syntakticky odlišných formách. Agent Beancount by mal na detekciu halucinácií názvu účtu alebo sumy používať sémantické zhlukovanie nad vzorkovanými dokončeniami zápisov, nie surový rozptyl na úrovni tokenov.

Zlyhanie kalibrácie verbalizovanej istoty je priamym varovaním pre akékoľvek používateľské rozhranie, ktoré používateľovi zobrazuje „ako si je AI istá?“: nedôverujte číslu, ktoré model vyprodukuje. Namiesto toho použite externý kalibrátor alebo metódu založenú na konzistencii, alebo ho nezobrazujte vôbec.

Čo si prečítať ďalej​

• Farquhar a kol., „Detecting hallucinations in large language models using semantic entropy“, Nature, 2024 – najprísnejšia metóda, ktorá vyplýva z tohto rámca; oplatí sa prečítať celú, nielen cez zhrnutie v prieskume.
• Manakul a kol., „SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models“, EMNLP 2023 (arXiv:2303.08896) – kánonická metóda založená na konzistencii; nevyhnutná pre pochopenie pred nasadením akéhokoľvek signálu istoty čiernej skrinky.
• Groot a kol., „Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models“, TrustNLP na ACL 2024 (arXiv:2405.02917) – najdôkladnejší empirický audit toho, ako verbalizovaná istota zlyháva naprieč modelmi a úlohami.

Práca​

Saibo Geng, Hudson Cooper, Michał Moskal a kolegovia z Microsoft Research predstavujú JSONSchemaBench, benchmark 9 558 schém čerpaných z reálnych produkčných zdrojov: signatúr volaní funkcií GlaiveAI, repozitárov GitHub rozvrstvených podľa zložitosti od triviálnych po ultra, konfigurácií Kubernetes API, schém analýzy udalostí Snowplow a kolekcie JSONSchemaStore. Hodnotia šesť frameworkov pre obmedzené dekódovanie – Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs a Gemini – v troch osiach: pokrytie (akú časť schém framework vôbec zvládne), efektívnosť (réžia v počte tokenov za sekundu oproti neobmedzenému generovaniu) a kvalita (presnosť následných úloh). Hodnotiaca mriežka zahŕňa aj oficiálnu testovaciu sadu JSON Schema Test Suite, ktorá dokumentuje 45 kategórií funkcií, ktoré by mal podporovať každý vyhovujúci engine.

Hlavným tvrdením je, že komplexita schémy je rozhodujúcou premennou, ktorá oddeľuje schopné frameworky od tých krehkých, a že žiadny framework nedominuje vo všetkých troch osiach.

Kľúčové myšlienky​

• Pokrytie kolabuje pod komplexitou schém. Pri jednoduchých schémach GlaiveAI dosahujú všetky frameworky skóre nad 86 %. Ale pri schémach GitHub-Hard – viacúrovňové vnorenie, rekurzívne definície, komplexné obmedzenia vzorov – Guidance klesá na 41 %, Llamacpp na 39 %, XGrammar na 28 % a Outlines na katastrofálne 3 %. OpenAI dosahuje len 9 % na GitHub-Hard a Gemini neprodukuje žiadne platné výstupy pri schémach strednej alebo vyššej zložitosti.
• Kubernetes odhaľuje špecifickú slabinu v XGrammar. Napriek tvrdeniam o rýchlosti XGrammar dosahuje len 7 % pokrytie pri schémach Kubernetes, pravdepodobne preto, že tieto schémy sa spoliehajú na vzory závislé od kontextu, ktoré nezávislá predbežná kalkulácia kontextu v XGrammar nedokáže spracovať. Pokrytie voči benchmarku, ktorý zahŕňa konfigurácie Kubernetes, nie je pre produkčných agentov voliteľné.
• Nedostatočné obmedzenie (under-constrained) je nebezpečnejšie ako zlyhanie kompilácie. XGrammar vykazuje 38 zlyhaní z dôvodu nedostatočného obmedzenia voči JSON Schema Test Suite – čo znamená, že vygeneruje JSON, ktorý porušuje deklarovanú schému, pričom ticho hlási úspech. Guidance má len 1 takéto zlyhanie. Pre agenta so spätným zápisom je chyba kompilácie zachytená v čase návrhu; zlyhanie z dôvodu nedostatočného obmedzenia poškodí dáta za behu bez akéhokoľvek signálu.
• Rýchly posun vpred (fast-forwarding) v Guidance prináša skutočné 50 % zrýchlenie. Ak sú prítomné dlhé deterministické sekvencie (napr. názvy polí v pevnej štruktúre objektu), Guidance môže postúpiť o viacero tokenov v jednom kroku dekódovania. Na Llama-3.1-8B na A100 beží Guidance rýchlosťou 6–9 ms na výstupný token, zatiaľ čo neobmedzené generovanie trvá 15–16 ms. Outlines je pomalší ako neobmedzené generovanie s 30–46 ms, hlavne kvôli počiatočnej kompilácii automatu, ktorá trvá 3–8 sekúnd na schému.
• Obmedzené dekódovanie mierne zlepšuje presnosť uvažovania. Na GSM8K (matematika) Guidance zvyšuje presnosť z 80,1 % (neobmedzené) na 83,8 %. Pri úlohách Last Letter a Shuffle Objects sú zisky v rozmedzí 1–3 bodov. To odporuje často uvádzanej obave, že vynútenie formátu JSON znižuje kvalitu odpovede – efekt je však dostatočne malý na to, aby výber formátu nebol hlavným kritériom pri voľbe frameworku.
• Žiadny framework nepokrýva všetkých 45 kategórií funkcií JSON Schema. Guidance pokrýva 13, Llamacpp a XGrammar každý po 1 a Outlines pokrýva 0. Praktickým dôsledkom je, že akákoľvek schéma používajúca if/then/else, unevaluatedProperties alebo rekurzívne definície $ref, sa bude správať nepredvídateľne v závislosti od toho, aký engine sa nachádza "pod kapotou".

Čo obstojí — a čo nie​

Najsilnejším prínosom benchmarku je výber zdrojov schém. Predchádzajúce hodnotenia používali triviálne schémy alebo kolekcie z jedného zdroja. Zahrnutie konfigurácií Kubernetes popri signatúrach volaní funkcií je správnym druhom kontradiktórnej diverzity. Stratifikácia zložitosti (od triviálnej po ultra) tiež poskytuje odborníkom kalibračnú krivku: ak vaše schémy vyzerajú ako volania funkcií GlaiveAI, XGrammar aj Guidance sú v poriadku; ak vyzerajú ako manifesty Kubernetes, vaše možnosti sa rýchlo zužujú.

Hlavnou slabinou je hodnotenie na základe jednej vzorky s využitím greedy dekódovania. Meranie pokrytia jednou generáciou na schému podhodnocuje skutočné schopnosti – framework môže zlyhať v 20 % prípadov, ale uspieť pri opakovanom pokuse. Práca to priznáva, ale neuvádza čísla pass@k pri vzorkovaní s teplotou (temperature sampling), čo by bolo dôležité pre produkčné systémy, ktoré pri zlyhaní vykonávajú opakované pokusy.

Porovnanie tiež mieša neporovnateľné modely. Open-source frameworky (Guidance, Outlines, Llamacpp, XGrammar) sú testované na Llama-3.2-1B, zatiaľ čo OpenAI a Gemini bežia na vlastných nezverejnených modeloch. 9 % pokrytie OpenAI na GitHub-Hard môže odrážať schopnosti modelu rovnako ako architektúru obmedzeného dekódovania. Spravodlivé porovnanie by si vyžadovalo kontrolovaný prístup k modelu – čo autori od proprietárnych poskytovateľov samozrejme nemôžu vynútiť.

Prečo je to dôležité pre finančnú AI​

Každý agent so spätným zápisom v Beancounte generuje štruktúrovaný výstup. Ak agent generuje direktívy Beancount ako JSON pred ich konverziou na syntax .beancount, alebo ak volá nástroje cez JSON schémy, spoľahlivosť tejto generácie JSON nie je detail – je to základ celého procesu. Práca FinTrace ukázala, že špičkové modely zlyhávajú pri uvažovaní nad výstupmi nástrojov; JSONSchemaBench odhaľuje iný problém: ešte pred samotným uvažovaním môže formátovacia vrstva ticho vyprodukovať nevyhovujúci výstup.

Výsledok s Kubernetes je obzvlášť príznačný pre Beancount. Schémy účtovných kníh nie sú len ploché sady kľúčov a hodnôt. Hierarchie účtov, metadáta transakcií a štruktúry tagov vytvárajú vnorené rekurzívne vzory podobné objektom Kubernetes API. Framework, ktorý dosahuje 7 % v Kubernetes, nie je pripravený na komplexné schémy účtovných kníh bez ohľadu na to, aká nízka je jeho réžia na token.

Režim zlyhania z dôvodu nedostatočného obmedzenia (under-constrained) je to, čo by mi nedalo spať. Beancount agent používajúci XGrammar by mohol vygenerovať transakciu, ktorá prejde internou kontrolou validácie frameworku, ale poruší skutočnú schému – a agent by nemal dôvod na opakovaný pokus. Tiché poškodenie dát je horšie ako viditeľné zlyhanie.

Čo si prečítať ďalej​

• XGrammar (arXiv:2411.15100, Dong et al.) – technická práca v pozadí jedného z najrýchlejších testovaných frameworkov, vysvetľujúca rozdelenie tokenov na nezávislé a závislé od kontextu a prečo ho schémy Kubernetes zaťažujú.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) – ukazuje, že maskovanie tokenov v obmedzenom dekódovaní môže skresliť pravdepodobnostné rozdelenie modelu a navrhuje opravený algoritmus vzorkovania; teoretický základ pre obavy o kvalitu, ktoré benchmark meria len nepriamo.
• XGrammar-2 (arXiv:2601.04426) – nadväzujúca práca, ktorá rozširuje XGrammar na dynamické schémy v agentických prostrediach, kde sa samotná schéma mení počas relácie s viacerými kolami, čo je priamo relevantné pre agentov Beancount, ktorí prispôsobujú formát výstupu podľa toho, ktoré typy účtov sú aktívne.

O článku​

Jie Zhu, Yimin Tian a kolegovia z tímu Alibaba Cloud Qwen DianJin, YINGMI Wealth Management a univerzity Soochow University predstavujú FinMCP-Bench, vyhodnocovaciu sadu so 613 vzorkami, ktorá pokrýva 10 kategórií finančných scenárov a 33 subscenárov. Nástroje nie sú simulované – benchmark podporuje 65 skutočných finančných serverov kompatibilných s MCP, čerpaných zo skutočných produkčných logov finančného asistenta aplikácie Qieman APP. Autori kategorizujú vzorky do troch typov: 145 s jedným nástrojom, 249 s viacerými nástrojmi a 219 viacotáčkových. Testujú šesť modelov: rodinu Qwen3 s počtom parametrov 4B, 30B a 235B (všetky s rozšíreným premýšľaním), plus DeepSeek-R1, GPT-OSS-20B a Seed-OSS-36B. Hlavnými metrikami vyhodnotenia sú presnosť nástroja (Tool Precision), úplnosť nástroja (Tool Recall), Tool F1 a miera presnej zhody (Exact Match Rate – EMR), ktorá vyžaduje, aby každé volanie nástroja v sekvencii bolo úplne správne.

Kľúčové myšlienky​

• MCP ako základ pre vyhodnocovanie: používanie skutočných definícií serverov MCP namiesto syntetických schém API odstraňuje veľkú priepasť medzi vyhodnocovaním benchmarkov a tým, čomu agenti skutočne čelia v nasadených finančných systémoch.
• Trojité rozdelenie náročnosti: vzorky s jedným nástrojom, viacerými nástrojmi a viacotáčkové vzorky nie sú len kvantitatívne rozdiely – odhaľujú kvalitatívne odlišné chybové režimy.
• Kolaps pri viacerých otáčkach: najlepší model (Qwen3-235B) dosahuje 60 % EMR pri jednom nástroji, 10,62 % EMR pri viacerých nástrojoch a 3,08 % EMR pri viacerých otáčkach. Pokles z jednej otáčky na viacotáčkový scenár je 20-násobný.
• Tool F1 je zhovievavejší: ten istý model dosahuje 66,85 %, 69,42 % a 41,56 % TF1 v týchto troch nastaveniach – čo ukazuje, že modely často vyberú správne nástroje, ale zlyhávajú v poradí, parametrizácii alebo sledovaní konverzácie.
• Úplnosť (Recall) víťazí nad presnosťou pri jednom nástroji: modely majú tendenciu volať nástroje nadmerne, keď si nie sú isté, namiesto nedostatočného volania, čo je bezpečnejší chybový režim pre finančné úlohy, ale stále to znamená zbytočné volania API a šum v stope uvažovania.
• Nemonotónne škálovanie podľa veľkosti: Qwen3-30B neprekonáva Qwen3-4B konzistentne vo všetkých subscenároch, čím vyvracia predpoklad, že väčší model pri viacstupňovom používaní nástrojov vždy vyhráva.

Čo obstojí — a čo nie​

Použitie skutočných produkčných logov ako zdroja pre príklady s jedným nástrojom je tu najsilnejším metodologickým rozhodnutím. Uzemňuje to benchmark v skutočnom správaní používateľov namiesto scenárov vymyslených výskumníkmi, čo je v literatúre o finančnej AI zriedkavé. Viacnástrojové a viacotáčkové vzorky sú synteticky rozšírené pomocou grafov závislostí a promptov na hranie rolí, čo je vzhľadom na náklady na označovanie rozumné, ale prináša to riziko: proces syntézy má tendenciu vytvárať čistejšie a priamočiarejšie dopyty, než aké píšu skutoční používatelia. Hodnota 3,08 % EMR pri viacotáčkových úlohách je znepokojujúca, ale mala by sa interpretovať opatrne – EMR vyžaduje, aby celá sekvencia bola úplne správna, takže jedno nesprávne medzipriľahlé volanie nástroja znamená zlyhanie celej úlohy. To je prísny a pravdepodobne nereálny produkčný štandard; metriky s čiastočným kreditom ako TF1 rozprávajú nuansovanejší príbeh.

Čo článok nerieši: chýba analýza toho, či je výkonnostná medzera primárne problémom v pochopení vstupu (model si zle vysvetlí, čo používateľ chce), problémom s formátovaním výstupu (správny zámer, ale zle sformátované volanie nástroja) alebo problémom v uvažovaní (nesprávne priebežné závery). Bez tohto rozkladu je ťažké vedieť, kam investovať inžinierske úsilie. Článok tiež vyhodnocuje modely izolovane; chýba test, či pridanie kroku overenia alebo reflexie mení obraz pri viacotáčkových úlohách.

Benchmark je tiež hlboko spätý so špecifickými 65 nástrojmi spoločnosti Qieman, čo obmedzuje prenos výsledkov na iné finančné platformy s inými sadami nástrojov.

Prečo je to dôležité pre finančnú AI​

FinMCP-Bench je najbližšie publikované vyhodnotenie toho, čo by skutočne robil agent pre zápis do Beancountu: prijal by požiadavku používateľa, identifikoval, ktorý nástroj (alebo reťazec nástrojov) sa má použiť, vyvolal by ich v poradí a spracoval by následné otázky. Viacotáčkové EMR na úrovni 3,08 % je tvrdým vytriezvením. Beancount agent, ktorý spravuje viacstupňovú opravu účtovnej knihy – povedzme reklasifikáciu sady transakcií medzi účtami v časovom rozsahu, následné odsúhlasenie a vygenerovanie reportu – je presne ten druh viacotáčkovej a viacnástrojovej úlohy, pri ktorej súčasné modely podľa štandardov presnej zhody takmer univerzálne zlyhávajú.

Rámec MCP je priamo relevantný: Python API Beancountu, rozhranie beanquery a REST vrstva favy by sa dali zabaliť ako MCP servery. FinMCP-Bench nám hovorí, že protokol nie je úzkym hrdlom – ním je uvažovanie nad sekvenciami volaní nástrojov.

Zistenie, že úplnosť (recall) nástrojov prevyšuje presnosť (modely volajú nástroje nadmerne), je dôležité aj pre bezpečnosť zápisu: agent, ktorý zavolá nástroj na zmenu účtovnej knihy, keď bolo potrebné iba čítanie, by mohol ticho poškodiť účtovnú knihu. Primárnym bezpečnostným signálom pre agentov so schopnosťou zápisu by mali byť metriky zamerané na presnosť, nie na úplnosť.

Čo si prečítať ďalej​

• JSONSchemaBench (arXiv:2501.10868) – vyhodnocuje spoľahlivosť štruktúrovaného výstupu na 10 000 schémach JSON; priamo rieši, či sú zlyhania formátovania volaní nástrojov vo FinMCP-Bench problémom s obmedzeným dekódovaním.
• ToolLLM (arXiv:2307.16789, ICLR 2024) – základný rámec pre trénovanie používania nástrojov, voči ktorému sa FinMCP-Bench vymedzuje; pochopenie jeho prieskumu stromu vyhľadávania do hĺbky objasňuje, čo pridáva metodológia FinMCP-Bench založená na produkčných logoch.
• WildToolBench (arXiv:2604.06185) – vyhodnocuje používanie nástrojov na reálnych dopytoch používateľov v praxi; jeho zistenie, že žiadny model nepresahuje 15 % presnosť pri reálnom správaní používateľov, dopĺňa prístup FinMCP-Bench založený na produkčných logoch.

O článku​

Cao a kol. predstavujú FinTrace, benchmark s 800 expertmi anotovanými trajektóriami, ktoré pokrývajú 34 kategórií finančných úloh z reálneho sveta v troch úrovniach náročnosti: ľahkej, strednej a ťažkej. Autori postavili svoje hodnotenie na systéme deviatich metrík usporiadaných do štyroch osí: správnosť akcií (F1 skóre volania nástrojov, relevancia úlohy), efektivita vykonávania (efektivita krokov, skóre redundancie), kvalita procesu (logický postup, využitie informácií, skóre progresu) a kvalita výstupu (miera úspešnosti úlohy, kvalita finálnej odpovede). Vyhodnotili 13 modelov LLM a zverejnili aj FinTrace-Training, súbor údajov s 8 196 vybranými preferenčnými trajektóriami na doladenie.

Hlavným tvrdením je, že najvýkonnejšie (frontier) modely zvládli výber nástrojov, ale systematicky zlyhávajú v ťažšom kroku: v používaní toho, čo nástroje vrátia. Benchmark to skúma pomocou 5-bodovej stupnice pre využitie informácií, logický postup a skóre progresu, plus algoritmické metriky pre F1 nástrojov a efektivitu krokov.

Kľúčové myšlienky​

• Najlepšie fungujúci model, Claude-Opus-4.6, dosahuje F1 skóre volania nástrojov 0,896 — čo je silný výber — ale získava len 3,23/5 vo využití informácií, čo je najslabšia zo štyroch metrík zameraných na výstup.
• Claude-Opus-4.6 má mieru úspešnosti úloh 2,65/5 a kvalitu konečnej odpovede 3,34/5; ani tie najlepšie modely nekonzistentne produkujú správne a úplné odpovede.
• Qwen-3.5-9B vykazuje degeneratívny vzorec: takmer dokonalú efektivitu krokov (1,000) a redundanciu (1,000), pretože takmer nevolá žiadne nástroje, čo sa odráža v F1 skóre volania nástrojov 0,109. Efektívne, ale nepoužiteľné.
• Tréning na FinTrace-Training zlepšuje metriky medziprocesov (Logický postup stúpa z 2,29 na 2,56 pomocou DPO; skóre progresu z 2,00 na 2,30), ale kvalita konečnej odpovede zostáva obmedzená úzkym hrdlom — žiadny variant pri malých modeloch výrazne neprekročil priemernú hodnotu 1,21 na stupnici 1–5.
• DPO prekonáva SFT v potláčaní režimov katastrofálneho zlyhania: podiel skóre logického postupu na úrovni 1 klesá z 11,9 % (SFT) na 9,5 % (DPO).
• Univerzálne najhoršou podkategóriou vo všetkých 13 modeloch je Reasoning QA (Uvažovanie pri otázkach a odpovediach), kde Claude-Opus-4.6 dosahuje celkovo iba 0,62 — tvrdý strop, ktorý zdieľajú aj tie najsilnejšie modely.

Čo obstojí — a čo nie​

Hlavné zistenie — že výber nástrojov a uvažovanie nad nástrojmi sú oddeliteľné procesy — je dobre odôvodnené a systém štyroch osí metrík je skutočným prínosom. Predchádzajúce benchmarky ako FinToolBench končia pri stopách vykonávania; FinTrace pridáva metriky kvality procesu posudzované modelmi LLM, ktoré odhaľujú, čo sa deje medzitým. Cohenova kapa (κ) medzi hodnotiteľmi 0,89 na vzorke 100 overení je pre benchmark čiastočne postavený na hodnoteniach LLM povzbudivá.

To znamená, že niekoľko metodologických rozhodnutí obmedzuje to, čo môžem z týchto čísel brať ako bernú mincu. 34 kategórií úloh nie je v hlavnom článku vymenovaných — sú odsunuté do prílohy B — takže neviem posúdiť, nakoľko sú reprezentatívne pre reálnu finančnú prax. Úrovne obtiažnosti sú definované percentilovými poradiami v rámci vlastného fondu dopytov benchmarku, čo je argumentácia v kruhu: „ťažké“ znamená len nezvyčajné v porovnaní s ostatnými 800 trajektóriami, nie ťažké v absolútnom zmysle.

Analýza doladenia (fine-tuning) je frustrujúca. Tréning 9B modelu na FinTrace-Training zlepšuje priebežné uvažovanie, ale kvalita finálnej odpovede zostáva nefunkčná. Článok to pripisuje „odpojeniu“ medzi procesom a výstupom, ale nevysvetľuje prečo. Najpravdepodobnejšie vysvetlenie — že 9B modelu chýba schopnosť vybavovania si faktov a aritmetická kapacita potrebná pre finančné úlohy bez ohľadu na kvalitu trajektórie — zostáva neriešené. Uvádzanie výsledkov DPO len pre Qwen-3.5-9B tiež znemožňuje zistiť, či väčšie modely profitujú viac.

Som skeptický aj voči celkovej agregácii skóre. Spájanie algoritmických metrík (F1 ∈ [0,1]) s hodnoteniami LLM na 1–5 Likertových škálach pomocou normalizácie na [0,1] a spriemerovania spája veľmi odlišné typy zlyhaní. Model, ktorý volá úplne nesprávne nástroje, nie je pokazený rovnakým spôsobom ako model, ktorý volá správne nástroje a potom ignoruje ich výstup.

Prečo je to dôležité pre finančnú AI​

Hlavné zistenie sa priamo mapuje na problém spätného zápisu do Beancountu. Agent, ktorý spoľahlivo volá správne CLI nástroje Beancountu, ale potom nesprávne interpretuje výstup — povedzme, že analyzuje odpoveď zo súvahy a zaúčtuje ju na nesprávny účet — je horší ako žiadna automatizácia: produkuje sebavedomo nesprávne účtovné zápisy, ktoré sa bežnému kontrolórovi javia ako správne.

Metrika využitia informácií je tá, ktorú by som pri akomkoľvek agentovi pre Beancount sledoval najpozornejšie. Skutočnosť, že najlepší dostupný model dosahuje v kontrolovanom finančnom benchmarku skóre 3,23/5, by mala byť určujúcim obmedzením pre akékoľvek produkčné nasadenie. Hovorí to v prospech povinnej ľudskej kontroly každej operácie spätného zápisu, aspoň kým neuvidíme toto skóre konzistentne nad 4,0.

FinTrace tiež potvrdzuje to, čo naznačil ReDAct minulý týždeň: správna architektúra nie je end-to-end uvažovanie LLM, ale pipeline, ktorá externalizuje overovanie. Agent, ktorý dobre vyberá nástroje (Tool F1 ~ 0,9) a potom odovzdá výsledky samostatnému overovaciemu kroku pred vykonaním akcie, je obhájiteľnejší ako ten, ktorý sa pokúša uvažovať nad nespracovaným výstupom nástroja v jednom priechode.

Čo si prečítať ďalej​

• FinMCP-Bench (arXiv:2603.24943): sprievodný článok využívajúci MCP ako štandard rozhrania nástrojov, ďalší na zozname čítania — priamo porovnateľný s FinTrace, ale postavený na inej protokolovej vrstve.
• „Benchmarking LLM Tool-Use in the Wild“ (arXiv:2604.06185): objavil sa súčasne a vyhodnocuje volanie nástrojov mimo financií; objasnil by, či je medzera vo využívaní informácií špecifická pre doménu alebo všeobecná.
• „Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA“ (arXiv:2604.05387): zameriava sa na rovnaké režimy zlyhania volania nástrojov z pohľadu tréningových dát a môže vysvetliť, čo chýba DPO v rámci FinTrace-Training.

Odborná práca​

Jiaxuan Lu a kolegovia predstavujú FinToolBench (arXiv:2603.08262, marec 2026) ako podľa ich tvrdenia prvý reálny, vykonateľný benchmark na evaluáciu finančných agentov učiacich sa používať nástroje. Rámcovanie je priame: existujúce finančné AI evaluácie sa zameriavajú na statické QA nad dokumentmi, zatiaľ čo všeobecné benchmarky na používanie nástrojov ako ToolLLM považujú financie len za ďalšiu kategóriu API bez doménovo špecifických obmedzení zhody (compliance). FinToolBench sa snaží vyplniť priestor medzi týmito dvoma režimami zlyhania.

Benchmark spája 760 vykonateľných finančných nástrojov — 261 živých endpointov z RapidAPI a 499 rozhraní z AkShare — s 295 prísne kurátorovanými evaluačnými dopytmi, rozdelenými na 166 prípadov s jedným nástrojom a 129 s viacerými nástrojmi. Nástroje pokrývajú oblasti akcií, dlhopisov, fondov, forexu, derivátov, makroekonómie a kryptomien. Zásadné je, že ide o reálne, volateľné API, nie o simulované makety (stubs). Autori tiež zavádzajú FATR (Finance-Aware Tool Routing), referenčného agenta využívajúceho vyhľadávanie BGE-M3 (top-20 kandidátov), karty nástrojov anotované finančnými atribútmi a plánovač ReAct s vedomím obmedzení, limitovaný na päť krokov.

Kľúčové myšlienky​

• Vykonávanie nie je úzkym hrdlom — tým je uvažovanie nad výstupmi. GPT-4o má najvyššie podmienené soft skóre (CSS = 0,670), čo znamená, že poskytuje správne odpovede, keď úspešne zavolá nástroj, ale nástroje vyvoláva len v 22,7 % prípadov (TIR = 0,227). Qwen3-8B volá nástroje v 87,1 % prípadov, ale správnu odpoveď dosiahne len v 40,4 % prípadov, keď uspeje.
• Nesúlad zámeru (intent mismatch) je dominantným zlyhaním v oblasti zhody. IMR (Intent Mismatch Rate) presahuje 50 % u väčšiny modelov, čo znamená, že agenti bežne vykonávajú transakčné volania, keď dopyt vyžaduje len vyhľadanie informácií. To je v regulovanom finančnom kontexte vážny problém.
• Injekcia finančných atribútov pomáha zhode bez poškodenia schopností. Karty nástrojov referenčného FATR — anotovanie každého nástroja časovou citlivosťou, typom zámeru a regulačnou doménou — znižujú počet volaní zastaraných dát (TMR) a porušení domény (DMR) bez výrazného zhoršenia miery vyvolania.
• Dopyty s viacerými nástrojmi odhaľujú medzeru v spoľahlivosti. 129 dopytov vyžadujúcich viacero nástrojov potrebuje reťazenie volaní a odovzdávanie výstupov medzi krokmi; výkon podstatne klesá v porovnaní s prípadmi s jedným nástrojom, čo je v súlade so zisteniami z FinTrace a TheAgentCompany.
• Malé modely môžu v počte volaní prekonať tie veľké, ale nie v logickom uvažovaní. TIR 0,871 u Qwen3-8B oproti 0,227 u GPT-4o ukazuje, že menšie modely sú „agresívnejšie“, ale CER (podmienená miera vykonania, t. j. TESR/TIR) 0,339 pre Qwen3-8B oproti 0,618 pre GPT-4o odhaľuje, že GPT-4o je oveľa presnejší, keď sa už rozhodne nástroj zavolať.

Čo obstojí — a čo nie​

Voľba benchmarku používať skutočne živé, vykonateľné API je jeho primárnym prínosom, a to veľmi podstatným. Simulované API boli špinavým tajomstvom benchmarkov na používanie nástrojov: 16 000 API v ToolLLM znie pôsobivo, až kým si neuvedomíte, že evaluácia používa LLM ako sudcu toho, či by volanie „bolo“ fungovalo. FinToolBench sa tomu vyhýba.

Metriky zhody (TMR, IMR, DMR) sú konceptuálne správne — finanční agenti potrebujú poznať rozdiel medzi získaním včerajšej uzatváracej ceny a iniciovaním obchodu — ale popis v práci o tom, ako sa tieto klasifikácie vynucujú, je strohý. Nie je jasné, či označenia pre typ zámeru (informačný vs. transakčný) overovali experti na právo alebo compliance, alebo ich jednoducho priradili autori datasetu. V praxi na tom veľmi záleží.

Zoznam modelov je tiež nezvyčajne úzky: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash a GPT-4o. Chýba Claude Sonnet alebo Gemini 2.5, ktoré by boli prirodzeným porovnaním. Tabuľka výsledkov ukazuje, že GPT-4o je odľahlou hodnotou s vysokou presnosťou, ale nízkym pokrytím; chcel by som vedieť, či sa správanie Clauda pri používaní nástrojov blíži skôr ku konzervatívnemu vzorcu GPT-4o alebo agresívnemu Qwen3-8B.

Evaluačná sada s 295 dopytmi je na pomery moderných benchmarkov malá. Pri 760 nástrojoch znamená miera pokrytia 295 dopytmi, že väčšina nástrojov sa nikdy netestuje. Práca neuvádza štatistiky pokrytia podľa domén, čo znamená, že hlavné čísla môžu byť ovplyvnené podmnožinou dobre pokrytých domén, ako sú akcie a makroekonómia.

Prečo na tom záleží pre finančnú AI​

Agenti so spätným zápisom do Beancount — akýkoľvek agent, ktorý volá bean-add, opravuje súbor hlavnej knihy alebo dopytuje beanquery — čelia presne tým režimom zlyhania, ktoré FinToolBench odhaľuje. Problém nesúladu zámeru sa prekladá priamo: agent pre Beancount, ktorý vykoná príkaz na zápis, keď sa používateľ pýtal na čítanie, má rovnaký charakter zlyhania ako porušenie IMR. Dimenzia aktuálnosti (timeliness) mapuje problém volania zastaraného nacacheovaného stavu hlavnej knihy, keď používateľ očakáva aktuálny zostatok.

Napätie medzi presnosťou a pokrytím (GPT-4o vs. Qwen3-8B) je tiež priamo relevantné. Pre spätný zápis do Beancount by som oveľa radšej prijal konzervatívne správanie GPT-4o — nízke TIR, ale vysoké CER a CSS — než model s vysokou mierou vyvolania, ktorý často spustí nesprávny nástroj. Chybné zápisy sú oveľa nákladnejšie ako nevykonanie žiadnej operácie.

Prístup FATR spojený s anotovaním nástrojov atribútmi zhody namiesto spoliehania sa na to, že ich model odvodí, je dizajnový vzor, ktorý stojí za prijatie. Obalenie nástrojov CLI Beancount explicitnými metadátami o tom, či je volanie len na čítanie alebo meniace stav, a či sa dotýka aktuálneho alebo archivovaného stavu knihy, je rovnaká myšlienka aplikovaná na menší rozsah.

Čo si prečítať ďalej​

• FinTrace (arXiv:2604.10015) — evaluácia na úrovni trajektórií v 34 finančných kategóriách úloh s 9 metrikami; priamo rozširuje evaluáciu FinToolBench z jedného volania na viacstupňové sekvencie a dolaďuje Qwen-3.5-9B pomocou DPO na zlepšenie priebežného uvažovania.
• FinMCP-Bench (arXiv:2603.24943) — 613 vzoriek nad 65 finančnými nástrojmi založenými na MCP, testujúcich vyvolanie jedného nástroja, viacerých nástrojov a viacúrovňovú konverzáciu; rámcovanie MCP je priamo relevantné pre rozhrania nástrojov Beancount.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — práca ToolBench, voči ktorej sa FinToolBench explicitne vymedzuje; pochopenie toho, čo benchmark so simulovanými API dokáže a nedokáže merať, objasňuje, koľko v skutočnosti prináša vykonateľnosť vo FinToolBench.

Odborná práca​

OmniEval konštruuje dvojrozmernú hodnotiacu mriežku: päť tried úloh (extrakčné QA, viackrokové uvažovanie, kontrastné QA, dlhé QA a konverzačné QA) skrížených so 16 finančnými témami (akciové trhy, investičné bankovníctvo, fondy, poistenie majetku a iné). Výsledkom je štruktúrovaný benchmark s 11,4 tisíc automaticky generovanými testovacími príkladmi, 1,7 tisíc manuálne anotovanými príkladmi a korpusom na vyhľadávanie s 362 tisíc dokumentmi zostaveným zo šiestich čínskych finančných zdrojov údajov (BSCF-DB s 193 tisíc dokumentmi, FinGLM s 55 tisíc, BAAI-Fin s 48 tisíc, oficiálne webové extrakcie, PDF a finančný obsah z Wikipédie). Benchmark zahŕňa aj doladený LLM evaluátor – Qwen2.5-7B-Instruct trénovaný na 910 manuálne označených inštanciách – ktorý hodnotí kvalitu generovania v oblastiach presnosti, halucinácií, úplnosti, využitia a numerickej presnosti. Práca bola publikovaná na EMNLP 2025.

Kľúčové myšlienky​

• Automaticky generované testovacie prípady prešli kontrolou ľudskej akceptácie na 87,47 %, čo znamená, že približne 1 z 8 generovaných inštancií bola zahodená – čo nie je zanedbateľná miera šumu pre benchmark.
• Najlepší vyhľadávač (GTE-Qwen2-1.5B) dosiahol MAP 0,4370 a MRR 0,4491 na automaticky generovanej sade, čo znamená, že najvyššie umiestnená pasáž je správna v menej ako polovici prípadov, a to aj s najsilnejším testovaným vyhľadávačom.
• Presnosť generovania (ACC) naprieč všetkými kombináciami vyhľadávač-LLM sa pohybovala od 0,3238 do 0,4476 – najlepšia konfigurácia odpovedá správne na menej ako polovicu otázok.
• Numerická presnosť (NAC) je najvýraznejším zistením: 0,0659 až 0,3595. Najlepší systém trafí finančné čísla správne v približne 36 % prípadov; najhorší je blízko nuly.
• Doladený evaluátor dosiahol 74,4 % zhodu s ľudskou anotáciou (κ = 0,6486), čím výrazne prekonal základné modely založené len na promptovaní (55 – 71 %) – no stále ponecháva jedno zo štyroch hodnotení v nesúlade s ľudským úsudkom.
• Viackrokové uvažovanie a konverzačné QA boli konzistentne najťažšími triedami úloh.

Čo obstojí — a čo nie​

Návrh maticového hodnotenia je skutočne užitočný. Predchádzajúce finančné benchmarky (FinanceBench, FinQA, DocFinQA) pristupujú k hodnoteniu ako k jednej osi – zvyčajne presnosti odpovedí – a prehliadajú štrukturálne variácie v tom, ako RAG zlyháva. Vedieť, že systém dosahuje dobré výsledky v extrakčnom QA, ale slabé vo viackrokovom uvažovaní, je využiteľná informácia; vedieť, že má nejaké priemerné celkové skóre, nie je. Mriežka OmniEval zviditeľňuje tieto variácie a zistenie, že výkon je nekonzistentný naprieč témami, je presne ten druh výsledku, ktorý odborníci potrebujú vidieť pred nasadením.

To znamená, že existujú skutočné obmedzenia, o ktorých chcem hovoriť priamo. Korpus je prevažne čínsky: päť zo šiestich zdrojov údajov sú čínske finančné dáta (BSCF, FinGLM, BAAI-Fin) a šiestym je čínska Wikipédia. Práca neuvádza výsledky rozdelené podľa jazyka – uvádza len súhrnné čísla. To robí každé skóre v práci podozrivým ako tvrdenie o finančnom RAG všeobecne, na rozdiel od finančného RAG nad čínskym textom s čínsky špecializovanými vyhľadávačmi a LLM (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Anglickí finanční používatelia nemôžu tieto čísla priamo použiť.

LLM evaluátor je trénovaný na 910 označených inštanciách. To je málo. Zhoda s ľuďmi 74,4 % pri κ = 0,6486 je obhájiteľná ako východiskový bod, ale znamená to, že samotný hodnotiaci rámec vnáša značný šum. Ak sa benchmark používa na porovnanie systémov, ktoré sa líšia o niekoľko percentuálnych bodov, rozptyl evaluátora prekryje signál.

Automatický proces generovania – kde GPT-4 vytvára testovacie otázky a ľudia ich filtrujú s 87,47 % úspešnosťou – tiež vyvoláva otázku kontaminácie, ktorou sa práca nezaoberá: otázky generované GPT-4 môžu nahrávať modelom triedy GPT-4 spôsobom, ktorý systematicky znevýhodňuje staršie alebo menšie modely.

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

Čísla numerickej presnosti sú údajom, ku ktorému sa stále vraciam: 0,0659 – 0,3595. Ak najlepší testovaný systém RAG trafí finančné čísla správne len v 36 % prípadov v benchmarkovom hodnotení, akýkoľvek agent na zápis do Beancountu postavený na naivnom RAG procese poškodí údaje v účtovnej knihe. Formát Beancount je neúprosný – nesprávna suma, dátum alebo názov účtu spôsobí buď chybu spracovania, alebo tichú účtovnú chybu, ktorá sa môže šíriť naprieč fiškálnymi rokmi. Tento benchmark nám dáva konkrétny dôkaz, že vyhľadávanie RAG a generovanie LLM ešte nie sú dostatočne spoľahlivé na priamy zápis do účtovnej knihy bez validačnej vrstvy.

Štruktúra tried úloh sa tiež čisto mapuje na prípady použitia Beancountu. Extrakčné QA zodpovedá jednoduchému zisťovaniu zostatkov. Viackrokové uvažovanie zodpovedá otázkam typu „aký je môj čistý príjem po zdanení za Q1 – Q3?“. Konverzačné QA zodpovedá používateľovi, ktorý iteratívne upresňuje požiadavku na párovanie platieb počas relácie. Zistenie OmniEval, že viackrokové a konverzačné úlohy sú najťažšie, je presne tá zlá správa pre návrh agenta Beancount: jednoduché prípady sú takmer v poriadku; realistické prípady sú tie, kde sa systém rozpadá.

Čo si prečítať ďalej​

• ARES: Automatizovaný hodnotiaci rámec pre generovanie rozšírené o vyhľadávanie (arXiv:2311.09476, NAACL 2025) – najbližšia všeobecná obdoba k prístupu doladenia evaluátora v OmniEval; porovnanie metodiky ARES s OmniEval by objasnilo, či sú rozhodnutia o návrhu LLM evaluátora principiálne alebo ad hoc.
• RAGEval: Rámec na generovanie dátových sád pre hodnotenie RAG špecifické pre daný scenár (ACL 2025, aclanthology.org/2025.acl-long.418) – automatizované generovanie scenárov pre hodnotenie RAG; rozširuje metodiku automatického generovania, ktorú používa OmniEval, a môže riešiť obavy z kontaminácie.
• FinRAGBench-V: Benchmark pre multimodálny RAG s vizuálnymi citáciami vo finančnej oblasti (arXiv:2505.17471) – rozširuje hodnotenie RAG na multimodálne finančné dokumenty (tabuľky, grafy); relevantné, pretože používatelia Beancountu majú čoraz častejšie obrázky účteniek a PDF výpisy popri textových účtovných knihách.

Príspevok​

Prehľad od Xu a Dinga (arXiv:2409.01980) navrhuje usporiadať detekciu anomálií a out-of-distribution (OOD) založenú na LLM do dvoch tried vysokej úrovne: LLM pre detekciu, kde model priamo identifikuje anomálie, a LLM pre generovanie, kde model dopĺňa trénovacie dáta alebo vytvára vysvetlenia v prirodzenom jazyku, ktoré slúžia ako vstup pre následný detektor. Každá trieda sa ďalej delí. Detekcia sa delí na metódy založené na promptovaní (zmrazené alebo vyladené LLM dopytované pomocou promptov v prirodzenom jazyku) a metódy založené na kontraste (modely rodiny CLIP, ktoré hodnotia anomálnosť porovnaním výrezov obrázkov s textovými popismi). Generovanie sa delí na metódy zamerané na augmentáciu (generovanie pseudo-OOD štítkov alebo syntetických minoritných vzoriek) a metódy zamerané na vysvetlenie (vytváranie zdôvodnení v prirodzenom jazyku pre označené udalosti).

Sprievodný zoznam literatúry na GitHube obsahuje približne 39 prác: 24 v oblasti detekcie, 10 v oblasti augmentácie a 5 v oblasti vysvetľovania.

Kľúčové myšlienky​

• Metódy založené na kontraste dominujú v detekcii anomálií obrázkov. WinCLIP dosahuje 91,8 % a 85,1 % AUROC pri zero-shot klasifikácii anomálií a segmentácii na MVTec-AD bez akéhokoľvek ladenia špecifického pre daný súbor dát, čo je konkurencieschopné s dohliadanými (supervised) metódami trénovanými na tomto súbore dát.
• Zmrazené LLM narážajú na modalitnú medzeru pri netextových dátach. Prehľad výslovne uvádza, že „priame promptovanie zmrazených LLM pre výsledky detekcie anomálií alebo OOD v rôznych typoch dát často prináša suboptimálny výkon kvôli vrodenej modalitnej medzere medzi textom a inými dátovými modalitami.“
• Ladenie pomocou LoRA a adaptérov túto medzeru výrazne vypĺňa. Metódy ako AnomalyGPT a AnomalyCLIP využívajú techniky efektívne z hľadiska parametrov a podstatne prekonávajú svoje zmrazené náprotivky.
• Generovanie ako augmentácia je nevyužívané. Pseudo-OOD štítky na úrovni popiskov generované modelom BLIP-2 prekonávajú alternatívy na úrovni slov a popisov v detekcii OOD, čo naznačuje, že bohatší textový dohľad je dôležitý aj pre vizuálne úlohy.
• Generovanie zamerané na vysvetlenie je najnovšou podkategóriou. Systémy ako Holmes-VAD a VAD-LLaMA idú nad rámec binárnych príznakov a generujú zdôvodnenia anomálnych udalostí v prirodzenom jazyku, väčšinou v sledovacích videách.
• Tabuľkové dáta takmer chýbajú. Prehľad cituje jednu metódu – „Tabular“ od Li et al. (2024) – ktorá konvertuje tabuľkové riadky na textové prompty a dolaďuje ich pomocou LoRA, ale neposkytuje žiadne porovnávacie čísla.

Čo obstojí – a čo nie​

Táto dvojtriedna taxonómia je skutočne prehľadná a pravdepodobne ju budem používať na usporiadanie vlastných úvah. Rozlíšenie detekcia verzus generovanie zachytáva skutočné architektonické rozvetvenie: buď požiadate LLM, aby klasifikovalo priamo, alebo ho použijete na vytvorenie lepšieho trénovacieho signálu pre tradičný detektor.

Čo nemôžem akceptovať, je rámcovanie príspevku ako prehľadu detekcie anomálií v širokom zmysle. Pokrytie je drvivo sústredené na obrázky priemyselných chýb (MVTec-AD, VisA) a videá z bezpečnostných kamier (UCF-Crime, XD-Violence). Z približne 39 katalogizovaných prác sa takmer žiadna nezaoberá tabuľkovými alebo finančnými dátami. Časové rady dostávajú niekoľko citácií. Tabuľkové dáta jednu vetu. Toto nie je mapa prostredia pre Bean Labs – je to mapa prostredia pre výskumníkov v oblasti počítačového videnia, ktorí chcú používať CLIP na detekciu chýb.

Autori priznavajú, že „priestorové obmedzenia bránia podrobným súhrnom metrík,“ čo je zdvorilý spôsob, ako povedať, že v práci chýbajú porovnávacie tabuľky. V prehľadovej práci je absencia kvantitatívnej syntézy významnou medzerou. Čitatelia nemôžu tento príspevok použiť na rozhodnutie, ktorá paradigma je lepšia pre ich prípad použitia, bez toho, aby si museli každú citovanú prácu vyhľadať jednotlivo.

Problém halucinácií je uvedený ako otvorená výzva, ale jeho spracovanie je povrchné – pomenuje riziko bez toho, aby analyzovalo, ktoré paradigmy detekcie sú naň viac či menej náchylné, alebo ako by generovanie zamerané na vysvetlenie mohlo urobiť halucinácie lepšie detegovateľnými prostredníctvom ľudskej kontroly.

Prečo je to dôležité pre finančnú AI​

Dve podkategórie sú relevantné napriek zameraniu na obrázky. Po prvé, podkategória generovania zameraného na vysvetlenie je presne to, čo auditné agenty pre Beancount potrebujú: nielen príznak, že účtovný zápis je anomálny, ale aj veta v prirodzenom jazyku vysvetľujúca prečo. Finanční audítori nemôžu konať na základe binárneho výstupu. Po druhé, takmer úplné mlčanie prehľadu o detekcii tabuľkových anomálií je samo o sebe informatívne – potvrdzuje, že línia modelov AnoLLM, CausalTAD a AD-LLM, ktorú sledujem, je skôr pionierska oblasť než vychodený chodník, a že navrhovanie auditných nástrojov založených na LLM pre účtovné knihy Beancount vyžaduje syntézu poznatkov z detekcie anomálií vo videní, ktoré ešte neboli prenesené do tabuľkového prostredia.

Kompromis medzi promptovaním a ladením je najpraktickejším zistením: zero-shot promptovanie funguje ako prvotná aproximácia, ale trpí modalitnou medzerou; jemné doladenie pomocou LoRA na reprezentatívnych označených príkladoch túto medzeru uzatvára. Pre nasadenie v prostredí Beancount s označenými príkladmi anomálií z historických denníkov sa cesta jemného doladenia javí ako spoľahlivejšia než čisté promptovanie.

Čo si prečítať ďalej​

• „Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs“ (arXiv:2406.03614) – používa LLM sentence-transformer embeddingy na reálnych účtovných zápisoch v hlavnej knihe; priamy most od rámca tohto prehľadu k tabuľkovému využitiu v Beancounte.
• „Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework“ (arXiv:2403.19735) – multi-agentová pipeline pre detekciu anomálií v trhových dátach; vzor multi-agentovej koordinácie sa môže preniesť aj do auditu účtovných kníh.
• AnomalyGPT (arXiv:2308.15366) – vyladený model LVLM pre priemyselnú detekciu anomálií s lokalizáciou na úrovni pixelov; prečítanie tohto príspevku objasňuje, čo v skutočnosti architektonicky znamená „ladenie LLM pre detekciu“, čo prehľad popisuje, ale nevysvetľuje.

O dokumente​

Hsieh et al. začínajú diagnostickým pozorovaním: LLM – dokonca aj tie trénované na dlhých kontextoch – vykazujú pretrvávajúci vzorec pozornosti v tvare písmena U. Tokeny na začiatku a na konci vstupu dostávajú neúmerne vysokú pozornosť bez ohľadu na to, či sú relevantné, zatiaľ čo tokeny v strede sú systematicky podhodnotené. Autori to empiricky spájajú s poklesom presnosti „stratené v strede“, namiesto toho, aby to považovali za samostatný jav.

Ich riešenie je koncepčne elegantné. Rozkladajú pozornosť na dve aditívne zložky: relevanciu (to, čo chceme) a pozičnú predpojatosť (to, čo nechceme). Aby izolovali zložku predpojatosti, preženú cez rovnaký kontext na každej pozícii „dummy“ dokument – neinformatívny výplňový obsah – a zaznamenajú výslednú distribúciu pozornosti. Pozornosť tohto dummy dokumentu aproximuje čisto pozičnú apriórnu pravdepodobnosť. Jej odčítanie od skutočných skóre pozornosti zanecháva zvyšok, ktorý lepšie odráža skutočnú relevanciu:

Kalibrovaná pozornosť = Attn(dokument, k) − Attn(dummy, k)

Preškálované skóre sa potom použijú na zmenu poradia alebo prehodnotenie váhy vyhľadaných dokumentov pred finálnym krokom generovania odpovede. Zásadné je, že nie je potrebné žiadne trénovanie. Kalibrácia sa aplikuje počas inferencie na posledných 16 vrstiev dekodéra a všetky hlavy pozornosti. Náklady predstavujú O(K) dodatočných dopredných prechodov, kde K je počet vyhľadaných dokumentov – čo nie je zanedbateľné, ale je to predvídateľné.

Kľúčové myšlienky​

• Pozičná predpojatosť v tvare U je vlastná architektúre modelu a pretrváva aj v modeloch explicitne trénovaných s cieľmi pre dlhý kontext.
• Prechod dummy (prázdneho/šumového) dokumentu cez rovnaký vyhľadávací kontext izoluje pozičnú apriórnu pravdepodobnosť; jej odčítanie odstráni predpojatosť bez akéhokoľvek dolaďovania.
• Recall@3 na NaturalQuestion (K=20, zlatý dokument umiestnený v strede) stúpa z 20,52 % na 68,32 % s kalibráciou; pri K=10 z 36,38 % na 74,27 %.
• Presnosť end-to-end QA sa zlepšuje o 6 – 15 percentuálnych bodov, keď je zlatý dokument v strede kontextu; zlepšenia platia v 22 z 24 experimentálnych konfigurácií.
• Metóda prekonáva šesť porovnávacích základných línií: štandardnú pozornosť (vanilla attention), poradie podľa generovania dotazov, promptovanie podľa generovania relevancie, triedenie podľa pozornosti (Peysakhovich & Lerer 2023), zmenu poradia promptov a LongLLMLingua-rk.
• Metóda bola vyhodnotená na NaturalQuestion (2 655 reálnych dotazov nad Wikipédiou) a SynthWiki (990 syntetických záznamov generovaných GPT-4).

Čo obstojí — a čo nie​

Hlavný výsledok je pozoruhodný a verím mu. Rozdiel v Recall@3 pre zlaté dokumenty v strede kontextu z 20,52 % na 68,32 % nie je údaj, ktorý by sa pri bližšom skúmaní rozplynul – meria niečo skutočné o tom, ako je distribuovaná pozornosť. Dizajn bez nutnosti trénovania je skutočnou praktickou výhodou: môžete to nasadiť na akýkoľvek existujúci RAG proces bez zásahu do váh modelu.

Napriek tomu mám určité výhrady. Po prvé, prístup s „dummy dokumentom“ predpokladá, že pozičná predpojatosť je zhruba pozične oddeliteľná a aditívna – ide o lineárny rozklad, ktorý samotní autori označujú za potenciálne príliš zjednodušujúci. Skutočná predpojatosť pozornosti môže s obsahom interagovať nelineárnym spôsobom. Po druhé, O(K) extra dopredných prechodov je označených za „prijateľné“, ale nikdy neboli testované z hľadiska latencie alebo nákladov. V produkčnom systéme s K=20 vyhľadávaniami spúšťate 21 dopredných prechodov namiesto jedného na dotaz. Pre Beancount agenta triediaceho stovky transakcií je tento multiplikátor dôležitý.

Po tretie – a to je najzaujímavejšie obmedzenie – autori uvádzajú, že pozičná predpojatosť môže byť pre určité úlohy v skutočnosti užitočná. Napríklad predpojatosť k aktuálnosti (recency bias) môže byť tým, čo núti model správne pripisovať väčšiu váhu nedávnym záznamom v účtovnej knihe oproti starším. Nerozlišujúce odstránenie predpojatosti by mohlo poškodiť úlohy, kde je pozícia platným signálom. Toto je síce brané na vedomie, ale nebolo to študované.

Nakoniec, experimenty využívajú NaturalQuestion a syntetický dataset. Finančne špecifické dokumenty – husté tabuľky, viacročné výkazy, záznamy v účtovnej knihe s opakujúcou sa štruktúrou – sa veľmi líšia od pasáží z Wikipédie. Kalibráciu by bolo potrebné overiť na týchto distribúciách predtým, než sa vyhlási, že bude fungovať pre finančný RAG.

Prečo je to dôležité pre finančnú AI​

Priame prepojenie je jasné: každý záznam od DocFinQA krúži okolo rovnakého problému. Keď agent Beancount vyhľadá 20 relevantných záznamov v účtovnej knihe, aby odpovedal na otázku typu „odsúhlasiť marec s bankovým výpisom“, záznamom v strede vyhľadaného okna sa bude venovať systematicky menšia pozornosť v porovnaní so záznamami na začiatku a na konci kontextu. To nie je zlyhanie vyhľadávania – je to zlyhanie na strane generovania, ktoré nespraví žiadne zlepšenie poradia vyhľadávania.

Kalibrácia „nájdené v strede“ je pravdepodobným zmiernením, ktoré nevyžaduje žiadne pretrénovanie základného modelu a mohlo by sa aplikovať priamo v kroku generovania akéhokoľvek QA procesu nad účtovnou knihou. Obava z nákladov O(K) je reálna, ale zvládnuteľná – 20-dokumentové vyhľadávacie okno s modelom strednej veľkosti je stále v praktických medziach. Čo by som chcel vidieť pred nasadením, je overenie konkrétne na údajoch so štruktúrou Beancount: pomáha pozičná korekcia jednotne, alebo neúmyselne potláča signál aktuálnosti, vďaka ktorému sú nedávne transakcie dôveryhodnejšie ako tie staré?

Širší princíp – že mechanizmy pozornosti kódujú pozičné apriórne pravdepodobnosti nezávisle od relevancie obsahu a že tieto pravdepodobnosti možno skalibrovať bez pretrénovania – stojí za zapamätanie. Otvára to dvere podobným kalibráciám pre iné predpojatosti: predpojatosť k frekvencii tokenov, normalizáciu dĺžky vstupu, predpojatosť k rozvláčnosti pri generovaní.

Čo si prečítať ďalej​

• „Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel“ (arXiv:2406.02536, ACL Findings 2025) – navrhuje škálovanie jednej dimenzie skrytého stavu namiesto odčítania skóre pozornosti; stojí za priame porovnanie s prístupom „nájdené v strede“.
• „Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey“ (arXiv:2409.01980, NAACL 2025) – ďalšie na zozname čítania; spája vlákna AnoLLM, CausalTAD a AD-LLM do jednotnej taxonómie.
• Liu et al., „Lost in the Middle: How Language Models Use Long Contexts“ (arXiv:2307.03172, TACL 2023) – pôvodná diagnóza, na ktorú „nájdené v strede“ reaguje; nevyhnutné základné čítanie.

O článku​

ReDAct (Reason-Defer-Act) stavia na paradigme promptovania ReAct a zavádza dvojmodelovú architektúru agentov. Malý lacný model — Qwen3-80B, Llama3.3-70B alebo Llama4-Maverick — predvolene spracováva každý krok. V každom kroku vygeneruje stopu uvažovania a následne vygeneruje akciu. Systém meria neistotu na úrovni tokenov iba pri kroku generovania akcie a porovnáva ju s kalibrovaným prahom. Ak neistota tento prah prekročí, krok znovu vykoná veľký drahý model (GPT-5.2, Qwen3-235B alebo Qwen3-480B); v opačnom prípade sa vykoná akcia malého modelu.

Miery neistoty sú informačno-teoretické a vyžadujú len log-pravdepodobnosti na úrovni tokenov: pravdepodobnosť sekvencie (sumárny negatívny log-prob), perplexita (normalizovaná dĺžkou) a priemerná entropia tokenov (priemerná entropia naprieč pozíciami tokenov). Prah sa kalibruje z vyčlenenej sady rolloutov malého modelu výberom hodnoty, ktorá vyprodukuje cieľový počet volaní veľkého modelu na epizódu K.

Kľúčové myšlienky​

• Merať neistotu v kroku akcie, nie v kroku uvažovania. Pomocný experiment na 2 411 krokoch ALFWorld zistil, že neistota na úrovni uvažovania má slabú rozlišovaciu schopnosť medzi správnymi a nesprávnymi krokmi; perplexita na úrovni akcie má merateľne vyššie ROC-AUC a PRR ako prediktor správnosti.
• Odkladanie na základe PPL s Qwen3-80B + GPT-5.2 dosahuje na ALFWorld 80,8 % ± 1,1 %, čím prekonáva samotný GPT-5.2 s 78,3 % ± 1,9 %, pričom stojí 16,25 USD oproti 45,21 USD — o približne 64 % menej.
• V praxi sa odkladá ~15 % krokov, aby sa dosiahol kalibračný cieľ zhruba 10 %; rozdiel vzniká preto, lebo neúspešné (kratšie) trajektórie neúmerne prispievajú k rozpočtu na odkladanie.
• Náhodné odkladanie pri rovnakej miere dosahuje skóre 77,0 % — stále lepšie ako len malý model (68,3 %), ale horšie ako odkladanie riadené kvantifikáciou neistoty (UQ). Signál neistoty skutočne záleží, nie len samotný fakt častejšieho volania veľkého modelu.
• MiniGrid ukazuje menej priestoru na zlepšenie. Qwen3-80B + GPT-5.2 s odkladaním PPL dosahuje 95,0 % oproti 99,0 % pre samotný GPT-5.2. Menšia slovná zásoba úloh vytvára tvrdší strop pre prístup s odkladaním, keď je malý model štrukturálne neadekvátny.
• Distribúcia odkladania závisí od úlohy. ALFWorld odkladá viac v neskorších krokoch (dlhšia história promptu), zatiaľ čo MiniGrid vykazuje bimodálny vzorec spojený s počiatočnou pozíciou agenta. To znamená, že fixná kalibrácia prahu sa lepšie zovšeobecňuje v rámci rodiny úloh než naprieč rôznymi rodinami.

Čo sedí — a čo nie​

Základné empirické zistenie je vierohodné: perplexita nad reťazcom akcie je rozumným ukazovateľom toho, či sa daný krok pokazí. Dekompozícia uvažovanie/konanie v ReAct prirodzene poskytuje čistý bod na pripojenie signálu neistoty a pomocný experiment predikcie správnosti poskytuje skutočné mechanistické odôvodnenie pre túto voľbu dizajnu.

Čím som si menej istý: výsledkom na ALFWorld, kde „prekonáva samotný veľký model“. 80,8 % ± 1,1 % oproti 78,3 % ± 1,9 % sa prekrýva v rámci jednej smerodajnej odchýlky. Autori to pripisujú komplementárnym silným stránkam — malý model zvláda rutinné kroky bez občasného riskovania veľkého modelu — ale neexistuje žiadna ablácia po jednotlivých krokoch, ktorá by tento príbeh overila. Môže to byť pokojne len šum.

Výber benchmarkov je tiež obmedzujúci. ALFWorld a MiniGrid sú textové simulácie domácnosti a navigácia v mriežkovom svete — úzke prostredia, ktoré nevyužívajú volanie nástrojov, vykonávanie kódu ani vyhľadávanie vo viacerých dokumentoch. Či odkladanie kalibrované podľa neistoty funguje aj v týchto bohatších nastaveniach (nastaveniach relevantných pre Beancount), zostáva nezodpovedané. A voľba GPT-5.2 ako veľkého modelu sťažuje reprodukciu nákladov.

Kalibračný postup má neriešenú cyklickosť: prah sa vyberá na rovnakej distribúcii, na ktorej bol kalibrovaný, bez vyčlenenej validácie. Autori priznávajú posun distribúcie medzi kalibráciou (rollouty malého modelu) a vyhodnotením (hybridné rollouty), ale robustnosť prahu nechávajú na budúcu prácu.

Prečo je to dôležité pre finančnú AI​

Agenti Beancount pre spätný zápis čelia presne tej istej otázke odkladania pri každej transakcii. Bežný nákup potravín potrebuje kategorizáciu; neobvyklý viacstranný swap v cudzej mene s čiastočne zhodujúcim sa popisom potrebuje človeka. Súčasná prax je buď plná automatizácia (riziková), alebo plná ľudská kontrola (drahá). Rámec ReDAct naznačuje realizovateľnú strednú cestu: spustiť lacný model a eskalovať, keď perplexita nad kandidátom na zápis do denníka prekročí kalibrovaný prah.

Finančný kontext pridáva dve úvahy, ktorými sa článok nezaoberá. Po prvé, odkladanie by tu malo často znamenať zastavenie a opýtanie sa používateľa, nie volanie väčšieho LLM — štandardom správnosti účtovnej knihy je zámer používateľa, nie skóre v benchmarku. Po druhé, nezvratnosť potvrdeného zápisu v Beancounte je vyššia ako pri nesprávne umiestnenom objekte v ALFWorld. Kalibračný cieľ K by mal byť pravdepodobne ladený konzervatívne smerom k nižšej precíznosti malého modelu pred odložením, nie naopak.

Signál o 64 % znížení nákladov stojí za vážne zváženie aj s týmito výhradami. Ak agent Beancount spracuje mesačné transakcie a len 15 % rozhodnutí o kategorizácii potrebuje drahý model, ekonomika prevádzky schopného agenta pre spätný zápis vyzerá oveľa lepšie.

Čo si prečítať ďalej​

• KnowNo (Ren et al., 2023, CoRL): „Robots that ask for help: uncertainty alignment for large language model planners“ — využíva konformnú predikciu na kalibráciu garancie pokrytia toho, kedy požiadať o pomoc. ReDAct sa s ním neporovnáva; pochopenie kompromisu medzi konformnými garanciami a kalibráciou prahu je dôležité pred výberom produkčného prístupu. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. aktualizované, NAACL 2024) — systematická taxonómia verbalizovanej dôvery, metód založených na samplovaní a post-hoc kalibrácii; teoretické pozadie pre rozhodnutie, či je perplexita správnym zástupcom neistoty alebo či by lepšie fungovalo kalibrované škálovanie logitov. [arXiv:2311.08298]
• UALA: Uncertainty-Aware Language Agent (Han, Buntine, Shareghi) — aplikuje štrukturálne podobný prah neistoty na rozhodnutie o vyvolaní nástroja (volať nástroj vs. spoliehať sa na znalosti modelu), čím znižuje volania nástrojov o viac ako 50 %; priamy doplnok k ReDAct pre os neistoty agenta pri používaní nástrojov. [https://uala-agent.github.io/]

Odborný článok​

OpenHands (Wang et al., 2024; ICLR 2025) je open-source platforma na budovanie a vyhodnocovanie LLM agentov, ktorí fungujú ako generalistickí softvéroví vývojári. Hlavným tvrdením článku, ktorý viedli Xingyao Wang a Graham Neubig s 24-členným tímom, je, že väčšina existujúcich rámcov pre agentov je buď príliš výskumne zameraná (pevne zakódované cykly úloh), alebo príliš produkčne obmedzená (uzavretý kód alebo jednoúčelovosť), aby mohli slúžiť ako spoločný základ pre výskumnú komunitu. OpenHands sa to snaží napraviť poskytnutím štandardizovaného runtime prostredia, čistej abstrakcie agenta a 15 integrovaných benchmarkov v jednom repozitári s licenciou MIT.

Runtime je prostredie so sandboxom v Dockeri, ktoré obsahuje bash shell, Jupyter IPython server a prehliadač Chromium ovládaný cez Playwright. Agenti interagujú prostredníctvom troch primárnych typov akcií: IPythonRunCellAction pre Python, CmdRunAction pre príkazy shellu a BrowserInteractiveAction pre navigáciu na webe. Primitív pre koordináciu viacerých agentov, AgentDelegateAction, umožňuje hlavnému agentovi vytvárať špecializovaných podagentov. Predvoleným jadrom je CodeAct — pôvodne publikovaný ako samostatný článok tvrdiaci, že kód je ideálnym jednotným akčným priestorom pre LLM agentov — a platforma obsahuje niekoľko implementácií agentov vrátane všeobecného CodeActAgenta a špecializovaného BrowsingAgenta.

Kľúčové myšlienky​

• Kód ako univerzálny akčný priestor: CodeAct konsoliduje všetky akcie agenta (úpravy súborov, volania API, transformácie dát) do Pythonu alebo bashu, čo umožňuje LLM uvažovať v rovnakom médiu, na ktorom bolo najviac trénované. Tým sa obchádza krehkosť JSON schém, ktorá trápi agentov využívajúcich volanie funkcií (function-calling).
• Sandboxed Docker runtime: Každý agent beží v izolovanom kontajneri, takže agenti môžu voľne vykonávať ľubovoľný kód bez ohrozenia hostiteľského stroja — čo je nevyhnutný predpoklad pre akéhokoľvek produkčného finančného agenta, ktorému môžu byť zverené reálne prihlasovacie údaje.
• 15 benchmarkov v jednom systéme: SWE-Bench Lite (oprava kódu), HumanEvalFix (oprava chýb), WebArena (navigácia na webe), GPQA (uvažovanie na úrovni absolventov), GAIA (všeobecné riešenie úloh) a desať ďalších. Ich spoločné umiestnenie zabraňuje selektívnemu vyhodnocovaniu (cherry-picking).
• CodeActAgent + claude-3.5-sonnet dosahuje 26 % na SWE-Bench Lite a 79,3 % na HumanEvalFix; BrowsingAgent dosahuje 15,5 % na WebArena — čo sú konkurencieschopné zero-shot výsledky bez akéhokoľvek tréningu špecifického pre danú úlohu.
• Výkon v GAIA: 32,1 % s GPTSwarm, čo je hlboko pod 92 % ľudským základom — v súlade s každým iným benchmarkom všeobecných agentov, ktorý ukazuje 60–70 bodovú medzeru medzi človekom a agentom.
• Rozsah komunity: 71,4 tisíc hviezdičiek na GitHub a viac ako 188 prispievateľov v čase podania na ICLR; TheAgentCompany prijala OpenHands ako svoj evaluačný systém, čím mu udelila de facto status benchmarkovej infraštruktúry.

Čo obstojí — a čo nie​

Dizajn runtime prostredia v sandboxe je solidne inžinierske dielo. Izolácia vykonávania agenta v Dockeri je správnym predvoleným nastavením pre akýkoľvek systém, ktorému môže byť neskôr udelený prístup na zápis do reálnych finančných kníh, a je skutočne užitočné, že benchmarky sú umiestnené spolu, a nie roztrúsené v nekompatibilných repozitároch.

Pokrytie benchmarkmi je však skôr ambiciózne než systematické. Týchto 15 benchmarkov pokrýva divoko odlišné typy úloh a úrovne obtiažnosti bez jasného rámca pre to, ako by sa výsledky mali agregovať alebo porovnávať. Uvádzanie 26 % na SWE-Bench Lite popri 79,3 % na HumanEvalFix v tom istom článku riskuje vytvorenie dojmu, že ten istý agent je súčasne priemerný aj vynikajúci — tie úlohy sú jednoducho neporovnateľné. Autori neposkytujú koncepčnú metodológiu pre agregáciu viacerých benchmarkov.

Predpoklad CodeAct — že kód je správny univerzálny formát akcií — je sporný. Dobre funguje pri vývojových úlohách, ale na každú akciu uvaľuje sprostredkovateľskú vrstvu Pythonu/bashu, čo pridáva latenciu a zlyháva, keď sa sémantika akcie nedá čisto mapovať na kód (nejasné inštrukcie používateľa, API čisto v prirodzenom jazyku). Článok neporovnáva CodeAct s nekódovými akčnými priestormi, aby dokázal, že výhoda je skutočná a nie len dôsledkom kvality samotného LLM modelu.

Možno najdôležitejšou medzerou je rozdiel medzi evaluáciou a nasadením. Číslo 26 % v SWE-Bench pochádza z relatívne čistého, dobre špecifikovaného benchmarku. Komunitné správy a diskusie na GitHub konzistentne popisujú oveľa nižšiu spoľahlivosť pri nejednoznačných úlohách v reálnom svete alebo úlohách s dlhým časovým horizontom — rovnaký režim zlyhania, aký zdokumentovala TheAgentCompany. Článok nerieši, ako merať alebo zlepšovať robustnosť pri realistickom šume v špecifikácii úloh.

Prečo je to dôležité pre finančnú AI​

OpenHands je to najbližšie k spoločnému substrátu pre agentov, čo komunita má. Ak Bean Labs buduje evaluačnú infraštruktúru pre agentov Beancount, architektúra runtime, ktorá je tu použitá — Docker sandbox, Python/bash akcie, vymeniteľné LLM backendy — stojí za prijatie namiesto opätovného budovania. Primitív AgentDelegateAction sa prirodzene mapuje na proces finančného agenta, kde orchestrátor najvyššej úrovne deleguje prácu špecializovaným podagentom: jeden na čítanie z účtovnej knihy, jeden na označovanie anomálií, jeden na navrhovaný spätný zápis, ktorý skontroluje človek.

Čísla zo SWE-Bench a TheAgentCompany spoločne stanovujú triezvy predpoklad: aj tí najlepší dostupní agenti dokončia približne 26–30 % realistických, jednoznačných softvérových úloh. Automatizácia finančných kníh je náročnejšia — transakcie sú často nejednoznačné, rozsah možných škôd pri chybách je reálny a zámery používateľa sú často nedostatočne špecifikované. Správnym záverom nie je to, že agenti nie sú pripravení, ale to, že prvé produktívne nasadenia budú úzko zamerané pracovné postupy typu "zapíš raz" (návrhy kategorizácie, označovanie pri odsúhlasovaní) namiesto autonómnych viacstupňových úprav účtovnej knihy.

Čo si prečítať ďalej​

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — páruje lacný model s drahým a deleguje úlohu na drahý model len vtedy, keď je neistota vysoká; priamo rieši, ako by sa mal agent v štýle OpenHands rozhodovať, kedy postúpiť zápis do Beancount na ľudskú kontrolu.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 expertmi anotovaných sekvencií úloh v 34 finančných scenároch; metodológia evaluácie, ktorá OpenHands chýba pre finančne špecifické používanie nástrojov s dlhým horizontom.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 vzoriek naprieč 65 reálnymi MCP finančnými nástrojmi, priamo relevantné pre to, ako by sa vyhodnocoval Beancount agent postavený na runtime OpenHands v reálnom nasadení MCP.

O dokumente​

Fin-RATE, publikovaný vo februári 2026 Yidongom Jiangom, Junrongom Chenom a kolegami z Yale a spolupracujúcich inštitúcií, predstavuje benchmark vytvorený z 2 472 výkazov SEC od 43 spoločností v 36 odvetviach z rokov 2020 – 2025. Benchmark organizuje 7 500 odborne zostavených dvojíc otázok a odpovedí do troch typov úloh, ktoré odzrkadľujú pracovné postupy profesionálnych analytikov: DR-QA (detail a uvažovanie v rámci jedného výkazu), EC-QA (porovnanie dvoch spoločností v rámci spoločnej témy) a LT-QA (longitudinálne sledovanie tej istej firmy naprieč výkaznými obdobiami). Každý typ úlohy obsahuje 2 500 otázok. Hodnotenie zahŕňa 17 modelov LLM – uzavreté modely vrátane GPT-4.1 a GPT-5, open-source všeobecné modely ako DeepSeek-V3 a Llama-3.3-70B a finančne špecializované modely ako Fin-R1, Fino1-14B, FinanceConnect-13B a TouchstoneGPT-7B. Bodovanie využíva zjednotený rámec LLM-as-Judge s tromi nezávislými sudcami (GPT-5, DeepSeek-V3.2, Qwen3-235B), ktorí hodnotia každú odpoveď z hľadiska správnosti a piatich analytických dimenzií.

Kľúčové myšlienky​

• Výkon klesá so zvyšujúcou sa komplexnosťou úloh: presnosť klesá o 18,60 % pri prechode z DR-QA (jeden dokument) na LT-QA (longitudinálne sledovanie) a o 14,35 % z DR-QA na EC-QA (medzi entitami), v priemere u všetkých 17 modelov.
• GPT-5 s vyhľadávaním na webe je najlepším modelom, avšak jeho maximálna presnosť sa pohybuje len na úrovni 43 – 44 % vo všetkých troch typoch úloh – čo je žalostné pre benchmark, ktorý má odrážať prácu skutočných analytikov.
• Fin-R1, finančne špecializovaný model uvažovania, dosahuje 57,48 % v DR-QA, ale prepadá sa na 3,32 % v EC-QA – pokles o 54 bodov, ktorý ďaleko prevyšuje zhoršenie akéhokoľvek všeobecného modelu.
• V prostredí RAG klesá výkon všetkých modelov hlboko pod 27 % v porovnaní s výkonom pri ideálnom kontexte (gold-context), ktorý dosahuje až 57,48 %; úzkym hrdlom je proces vyhľadávania (retrieval), nie samotný model LLM.
• Dokument zavádza taxonómiu 13 typov chýb v štyroch kategóriách: halucinácie a rozpory, finančne špecifické numerické a sémantické chyby, chyby v pochopení dopytu/kontextu a zlyhania na úrovni vyhľadávania. Chýbajúce dôkazy (Missing Evidence) predstavujú 75,44 % chýb v úlohe EC-QA v režime RAG.
• Finančne špecializované modely vykazujú pri zložitých úlohách systematicky vyššiu mieru halucinácií než všeobecné modely, napriek lepšej finančnej terminológii.

Čo obstojí — a čo nie​

Štruktúra troch ciest je skutočne dobre navrhnutá. Väčšina finančných benchmarkov (FinQA, TAT-QA, FinanceBench) považuje QA za úlohu založenú na jednom dokumente. Fin-RATE je jeden z prvých, ktorý explicitne modeluje porovnávanie medzi entitami a longitudinálne sledovanie ako prvoradé úlohy, pričom výsledky odhaľujú zásadnú medzeru: súčasné LLM zvládajú QA pri izolovaných zverejneniach prijateľne, ale rozpadajú sa v momente, keď potrebujú syntetizovať informácie naprieč dokumentmi, entitami alebo časovými obdobiami.

Kolaps Fin-R1 je najvýraznejším zistením dokumentu a myslím si, že sa mu nevenuje dostatočná pozornosť. Finančne vyladený model, ktorý vyniká v extrakcii z jedného dokumentu, sa zjavne naučil pracovať len v úzkom rámci: osvojil si šablóny pre odpovede v rámci jedného dokumentu, nie stratégie uvažovania pre prepájanie entít a časových období. Toto je konkrétne varovanie pred úzkym ladením (fine-tuning) na konkrétnu doménu bez explicitného dohľadu nad uvažovaním s viacerými dokumentmi. Model sa pravdepodobne „preučil“ na plytký vzorec „nájdi číslo vo výkaze“ a nemá žiadnu cestu zovšeobecnenia k úlohe „porovnaj toto číslo s ekvivalentným číslom v inom výkaze od inej spoločnosti“.

Napriek tomu existujú metodologické obavy, ktoré stoja za zmienku. GPT-5 je súčasne jedným z hodnotených modelov aj jedným z troch sudcov bodujúcich odpovede. Autori používajú troch sudcov na zníženie individuálnej predpojatosti, čo pomáha, ale prekrytie sudcu a modelu u najsilnejšieho hodnoteného modelu je znepokojujúce. Dokument uvádza vysokú mieru zhody medzi sudcami, ale samostatne nekvantifikuje, akú časť odpovedí GPT-5 hodnotil samotný model GPT-5, ani či sa jeho sebahodnotenie systematicky líši od ostatných dvoch sudcov. Akákoľvek predpojatosť pri sebahodnotení by umelo nadhodnotila celkový výsledok najlepšieho modelu v štúdii.

Vzorka 43 spoločností je tiež malá. Pokrytie typov výkazov je chvályhodne široké (10-K, 10-Q, 8-K, 6-K, DEF 14A a niekoľko sérií S a SC), ale rovnakých 43 spoločností sa objavuje vo všetkých úlohách. Modely, ktoré videli zverejnenia týchto spoločností počas predtrénovania, majú nekvantifikovanú výhodu a dokument neobsahuje žiadnu analýzu kontaminácie dát.

Zistenie o vyhľadávaní (retrieval) je dôležité, ale neúplné. Dokument identifikuje, že výkon RAG klesá približne o 30 bodov oproti ideálnemu kontextu (gold-context), pretože vyhľadávanie zlyháva. Benchmarkuje však iba jedno nastavenie vyhľadávania – zlyhanie vyhľadávania považuje skôr za diagnózu než za niečo, čo by sa malo systematicky meniť. Nadväzujúci dokument, ktorý by preskúmal rôzne architektúry vyhľadávania na Fin-RATE, by bol oveľa prínosnejší.

Prečo je to dôležité pre finančnú AI​

Audit účtovnej knihy Beancount potrebuje presne tie dve schopnosti, o ktorých Fin-RATE odhalil, že nefungujú: longitudinálne sledovanie (ako sa tento účet vyvíjal počas fiškálnych rokov?) a porovnávanie medzi entitami (zhoduje sa súvaha tejto dcérskej spoločnosti s konsolidovanou uzávierkou?). Prepad presnosti o 18,60 % pri časovom sledovaní je konkrétne číslo, ktoré by malo korigovať očakávania od akéhokoľvek agenta Beancount uvažujúceho naprieč viacerými výkaznými obdobiami. Ak špičkové modely zlyhávajú na úrovni 43 % pri longitudinálnom QA výkazov SEC aj pri ideálnom kontexte, agent Beancount prechádzajúci viacročnou históriou účtovných kníh by mal byť navrhnutý s explicitným vyhľadávaním, časovým ukotvením a eskaláciou na človeka – nie ako end-to-end LLM inferencia.

Zistenie o dominancii vyhľadávania je kľúčové pre prioritu návrhu systému. Ak je výkon pri ideálnom kontexte takmer dvojnásobný oproti RAG, správnou investíciou je lepšie rozdelenie textu (chunking), výber pasáží a vyhľadávanie – nie schopnejší základný model LLM. Toto zrkadlí zistenia DocFinQA pre dlhé výkazy SEC: úzkym hrdlom je proces okolo modelu.

Varovanie ohľadom Fin-R1 sa priamo vzťahuje aj na prípady použitia Beancount. Jemné ladenie na syntaxi Beancount DSL a vzorcoch transakcií môže vytvoriť model, ktorý dobre zvláda generovanie jednoduchých zápisov, ale zlyháva pri zosúlaďovaní viacerých účtov a období, vďaka čomu je audit užitočný. Špecializácia bez tréningu uvažovania nad viacerými dokumentmi je krehká presne tými spôsobmi, ktoré Fin-RATE meria.

Čo si prečítať ďalej​

• Fin-R1 (arXiv:2503.16252) — pre pochopenie toho, aké tréningové nastavenie viedlo k tak krehkému výkonu naprieč dokumentmi a či uvažovanie nad viacerými dokumentmi bolo vôbec cieľom.
• FinTrace (arXiv:2604.10015) — hodnotenie trajektórie volania nástrojov LLM v 34 kategóriách finančných úloh; dopĺňa statický QA pohľad Fin-RATE o diagnostiku na úrovni procesov, kde modely vyvolávajú správne nástroje, ale zlyhávajú pri uvažovaní nad výsledkami.
• OpenHands (arXiv:2407.16741) — otvorená platforma agentov, na ktorej stoja hodnotenia TheAgentCompany; pochopenie jej architektúry objasňuje, ktoré základné schopnosti agentov boli k dispozícii a ktoré nedostatky možno pripísať náročnosti úlohy, a nie obmedzeniam platformy.

Práca​

Chanyeol Choi, Jihoon Kwon a kolegovia z firmy zaoberajúcej sa finančnou AI predstavujú dataset 5 703 expertmi anotovaných trojíc dopyt–dôkaz–odpoveď pochádzajúcich z reálnej služby otázok a odpovedí pre analytikov hedžových fondov. Dokumenty sú podania Form 10-K od 490 spoločností z indexu S&P 500, zhromaždené z databázy SEC EDGAR. To, čo odlišuje FinDER od predchádzajúcich benchmarkov, je strana dopytu: 89,86 % dopytov obsahuje tri alebo viac doménovo špecifických skratiek alebo akronymov. Namiesto „Aký je celkový výnos spoločnosti X za fiškálny rok 2023?“ by skutočný analytik mohol napísať „GOOGL 10-K FY23 výnosy rozpis podľa segmentov“. Dataset bol publikovaný na ICLR 2025 Workshop on Advances in Financial AI a neskôr sa objavil na ICAIF 2025.

Kľúčové myšlienky​

• Návratnosť vyhľadávania je šokujúco nízka plošne: E5-Mistral (najlepší hustý retriever) dosahuje celkovú návratnosť kontextu len 25,95 %; BM25 dosahuje 11,68 %. Kategória „Financie“ — tá, ktorá je najviac relevantná pre účtovníctvo — je najťažšia: 15,84 % a 6,42 %.
• Samotná nejednoznačnosť dopytov stojí 8,2 bodu presnosti: Pri testovaní E5-Mistral na 500 dopytoch autori porovnávajú dobre formulované parafrázy (presnosť 33,9) voči skutočným skráteným dopytom (presnosť 25,7). Rozdiel je plne pripísateľný spracovaniu skratiek/akronymov, nie zložitosti dokumentu.
• Kvalita vyhľadávania je dominantným úzkym hrdlom pre generovanie: LLM bez kontextu skórujú blízko nuly (9 – 10 % správne); s 10 najlepšími vyhľadanými pasážami dosahujú 29 – 34 %; s dokonalým „oracle“ kontextom vyskočia na 60 – 68 %. Tento 35-bodový rozdiel medzi realistickými a ideálnymi podmienkami je väčší ako rozdiel medzi open-source a špičkovými modelmi.
• Kompozičná aritmetika zlyháva aj pri dobrom vyhľadávaní: Viackrokové výpočtové úlohy (kompozičné dopyty) dosahujú len ~20 % správnosti vo všetkých štyroch modeloch — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill a Qwen-QWQ — dokonca aj s 10 najlepšími vyhľadanými pasážami. GPT-o1 vedie v úlohách na násobenie s 42,90 %, ale pri delení klesá na 27,78 %.
• Prehodnocovanie (reranking) pomocou LLM prináša mierne, ale konzistentné zlepšenie: Ak necháme modely prehodnotiť 10 najlepších výsledkov z E5-Mistral pred odpovedaním, Claude-3.7-Sonnet dosahuje F1 63,05 a GPT-o1 dosahuje 62,90. Deepseek-R1-Distill zaostáva s 60,01, napriek silnému výkonu v štruktúrovanom uvažovaní inde.
• Náročnosť kategórií je nerovnomerná: Dopyty týkajúce sa rizík sa vyhľadávajú najľahšie (E5-Mistral: 33,07 návratnosť); Financie zostávajú najťažšie (15,84). To koreluje so štruktúrou dopytov — zverejnenia rizík používajú prirodzený jazyk (prózu), finančné tabuľky používajú hustú číselnú notáciu.

Čo obstojí — a čo nie​

Základný prínos je solídny: toto je reálna distribúcia dopytov od pracujúcich analytikov a problém so skratkami je skutočný. Akýkoľvek benchmark postavený na Wikipédii alebo crowdsourcingu v štýle FinQA toto prehliada. Trojúrovňová štruktúra hodnotenia — bez kontextu, realistické vyhľadávanie, oracle kontext — je správny dizajn; jasne oddeľuje kvalitu vyhľadávania od kvality uvažovania a ukazuje zvyškovú medzeru v generovaní (stále ~32 – 34 % zlyhanie aj pri perfektnom kontexte pri kvalitatívnych otázkach).

Najslabším miestom práce je reprodukovateľnosť. V čase publikácie nebol dataset verejne dostupný — autori uvádzajú, že ho „plánujú zverejniť neskôr“. To je významný problém pre článok z workshopu, ktorý sa prezentuje ako hodnotiaci štandard. Benchmarky, ktoré nie sú zverejnené, nie sú benchmarkmi; sú to prípadové štúdie. Odvtedy sa objavil na ICAIF 2025, takže zverejnenie mohlo nasledovať, ale verzia na arXiv to nepotvrdzuje.

Hodnotenie vyhľadávania tiež využíva iba štyri jednostupňové modely (BM25, GTE, mE5, E5-Mistral). Chýba hybridné vyhľadávanie, rozširovanie dopytov (query expansion), HyDE alebo krok prepisovania zameraný špecificky na problém skratiek. Vzhľadom na to, že autori presne charakterizovali medzeru spôsobenú skratkami, je prekvapujúce, že netestujú zrejmé riešenie: rozšírenie dopytu („GOOGL“ → „Alphabet Inc.“) pred vyhľadávaním. Tento experiment chýba.

Výsledky generovania si zaslúžia podrobnejšie prečítanie. Výkon ~9 – 10 % bez kontextu nie je užitočná dolná hranica — je to v podstate nula — ale strop 60 – 68 % pri oracle kontexte je informatívnejší, než sa zdá. Aj so správnou pasážou v ruke najlepšie modely zlyhávajú približne v jednej tretine kvalitatívnych otázok a v štyroch pätinách kompozičnej aritmetiky. Na tomto strope záleží: znamená to, že samotné vyhľadávanie problém nevyrieši.

Prečo na tom záleží pre finančnú AI​

Distribúcia dopytov vo FinDER dobre mapuje to, ako používatelia Beancountu skutočne komunikujú s agentom nad účtovnou knihou. Používateľ, ktorý si vedie účty roky, bude písať skrátené, kontextuálne dopyty — „AMZN karta Q3 refund?“ namiesto „Aké sú refundácie na kreditnej karte Amazon v treťom štvrťroku?“. Štandardné embedding modely zlyhajú pri vyhľadávaní správnych záznamov, pretože boli trénované na čistom texte v prirodzenom jazyku. 8,2-bodový pokles presnosti od čistých k reálnym dopytom je pravdepodobne konzervatívny pre doménu osobného účtovníctva, kde sú idiosynkratické skratky („prop mgmt popl“ pre „poplatok za správu nehnuteľnosti“) ešte ďalej od trénovacích dát než štandardné skratky SEC.

Strop návratnosti kontextu 25,95 % pri E5-Mistral je hnacou silou: akákoľvek RAG pipeline pre Beancount musí počítať s veľkou časťou chýbajúcich dôkazov. Jedným z dôsledkov je, že opakované vyhľadávanie s vysokou návratnosťou (viacero prechodov, diverzifikované formulácie dopytov) je dôležitejšie ako zvyšovanie F1 pri jednom prechode. Ďalším je, že normalizácia dopytov — mapovanie používateľských skratiek na kánonické názvy účtov pred vyhľadávaním — by mala byť explicitným krokom predbežného spracovania, nie ponechaná na embedding model.

20 % presnosť kompozičnej aritmetiky aj pri oracle kontexte je samostatným signálom: pre výpočtové úlohy v Beancounte je úzkym hrdlom generovania uvažovanie, nie vyhľadávanie. Delegovanie v štýle PAL (generovanie aritmetiky v Pythone namiesto výpočtu v čistom texte) zostáva správnou odpoveďou pre numerické úlohy bez ohľadu na to, aké dobré bude vyhľadávanie.

Čo si prečítať ďalej​

• Fin-RATE (arXiv:2602.07294) — sprievodný benchmark pre viacročné sledovanie v podaniach SEC; presnosť klesá o 18,60 % pri časových úlohách, čo je priamo vyjadrený problém viacročnej účtovnej knihy v Beancounte.
• IRCoT (arXiv:2212.10509, ACL 2023) — prekladanie vyhľadávania s uvažovaním pomocou reťazca myšlienok (chain-of-thought); viacprechodová štruktúra vyhľadávania priamo rieši nízku návratnosť pri jednom prechode, ktorú odhaľuje FinDER.
• Rozširovanie dopytov pomocou LLM pre doménovo špecifické vyhľadávanie — žiadna samostatná práca s benchmarkom to zatiaľ nepokrýva dobre, ale medzera v skratkách vo FinDER z toho robí výskumnú prioritu prvého rádu; hľadanie „HyDE financial domain“ a „query expansion SEC filings 2025“ je správnym bodom na začiatok.

Článok​

"Lost in the Middle: How Language Models Use Long Contexts" od Nelsona F. Liu, Kevina Lina, Johna Hewitta, Ashwina Paranjapeho, Michela Bevilacqua, Fabia Petroniho a Percyho Lianga realizuje dva cielené experimenty: odpovedanie na otázky na základe viacerých dokumentov nad NaturalQuestions-Open (s 10, 20 a 30 vyhľadanými dokumentmi) a syntetické vyhľadávanie kľúč-hodnota (so 75, 140 a 300 pármi). V každom experimente systematicky menia polohu, kde sa nachádza relevantný dokument alebo pár kľúč-hodnota v rámci vstupného kontextu — začiatok, stred alebo koniec — pričom všetko ostatné zostáva nezmenené. Zistenie je jasné: výkon kopíruje krivku v tvare písmena U s prepadom v strede kontextu a táto krivka sa objavuje pri každom testovanom modeli.

Kľúčové myšlienky​

• Tvar písmena U je reálny a konzistentný. V nastavení QA s 20 dokumentmi bol výkon na prvej pozícii približne 75 % a degradoval na približne 55 % na 10. pozícii, kým sa zotavil na približne 72 % na 20. pozícii — čo predstavuje rozdiel ~20 bodov medzi okrajmi a stredom.
• Všetky modely sledujú rovnaký vzorec. Testované modely zahŕňajú uzavreté aj otvorené, malé aj veľké: GPT-3.5-Turbo (4K a 16K), GPT-4, Claude-1.3 (8K and 100K), MPT-30B-Instruct a LongChat-13B. U-krivka sa prejavila u každého z nich, vrátane modelov explicitne propagovaných pre rozšírené kontextové okná.
• Ani Claude-1.3-100K nie je imúnny. Variant so 100K kontextom sa správal rovnako ako ostatné. Dlhé kontextové okno neznamená, že model mu skutočne venuje pozornosť rovnomerne.
• Baseline bez prístupu k dokumentom (closed-book) nastavuje vytriezvejúce dno. GPT-3.5-Turbo bez akýchkoľvek dokumentov odpovedal správne na 56,1 % otázok NaturalQuestions; s prístupom k práve tomu jednému relevantnému dokumentu dosiahol 88,3 %. Ale pri najhorších stredných pozíciách v nastavení s 20 dokumentmi klesol výkon pod closed-book baseline — čo znamená, že pridanie ďalšieho kontextu bolo aktívne škodlivé.
• Modely typu Encoder-decoder (Flan-T5-XXL, Flan-UL2) sú robustnejšie v rámci svojej trénovacej dĺžky, ale pri prekročení kontextu degradujú. Architektonický rozdiel je dôležitý, ale oba typy pri škálovaní stále degradujú.
• Hlavnou príčinou je kauzálne maskovanie pozornosti (causal attention masking). Každý token môže venovať pozornosť iba predchádzajúcim tokenom, takže pozície na úplnom začiatku akumulujú väčšiu celkovú váhu pozornosti v rámci modelu ako pozície v strede. Efekt nedávnosti (recency effect) zasa vyťahuje koniec kontextu nahor.

Čo obstojí — a čo nie​

Dizajn experimentu je tu obdivuhodne čistý: pozícia je jediná premenná, s ktorou sa manipuluje, úlohy sú štandardné benchmarky a zistenie sa replikuje naprieč širokou škálou rodín modelov. S kľúčovým výsledkom nemám žiadny spor.

Čo považujem za menej presvedčivé, je rámcovanie úlohy vyhľadávania kľúč-hodnota ako zmysluplného zástupcu pre reálne použitie. Vyhľadávanie UUID-to-UUID testuje, či model dokáže zopakovať zapamätaný reťazec, nie či dokáže urobiť niečo, čo vyžaduje logické uvažovanie. U-krivka sa tam objavuje tiež, čo posilňuje tvrdenie o pozičnej zaujatosti, ale zároveň to znamená, že článok spája dva rôzne javy: presnosť vyhľadávania pri úlohách s presnou zhodou a kvalitu uvažovania nad relevantnými pasážami. Chcel by som vedieť, či sa tvar U zhoršuje alebo zlepšuje, keď relevantný dokument vyžaduje viacstupňovú inferenciu pred finálnou odpoveďou, nielen doslovné zopakovanie.

Existuje tu tiež medzera, ktorú autori väčšinou uznávajú, ale neuzatvárajú: nikdy netestujú, či ladenie pomocou inštrukcií (instruction fine-tuning) alebo RLHF mení citlivosť na pozíciu, iba to, či ju mení väčšie kontextové okno. Vzhľadom na to, že hlavná príčina je architektonická (kauzálne maskovanie), mám podozrenie, že ladenie inštrukcií to nevyrieši, ale článok to nepotvrdzuje.

Prečo je to dôležité pre finančnú AI​

Tento článok poskytuje mechanistické vysvetlenie empirického vzorca, na ktorý neustále narážam. DocFinQA zlyhal na dlhých podaniach na SEC. IRCoT aj FLARE vyhľadávajú viaceré pasáže a pred uvažovaním ich spájajú. Každý RAG kanál, ktorý som vo finančnom kontexte videl, sekvenčne nasype vyhľadané pasáže do promptu a dúfa, že model bude venovať pozornosť tej správnej.

Dôsledok pre agentov Beancount je konkrétny. Ak agent vyhľadá desať záznamov v účtovnej knihe ako kontext, záznamy na pozíciách 3 – 7 sú vystavené najvyššiemu riziku, že budú ignorované alebo že okolo nich dôjde k halucináciám. Toto nie je problém vyhľadávania — je to problém prezentácie. Z tohto článku vyplývajú dve reakcie: buď umiestnite diagnosticky najrelevantnejšie záznamy ako prvé (a posledné), alebo ich nespájajte vôbec a uvažujte nad každou pasážou samostatne.

Zistenie tiež komplikuje naratív o LLM s dlhým kontextom. Každý štvrťrok nový model oznámi väčšie kontextové okno. Tento článok hovorí, že dĺžka okna neznamená to, čo si myslíte, ak v ňom dôkazy distribuujete rovnomerne. Model so 128K kontextom, ktorý pochová relevantnú transakciu na pozícii 60K, je horší ako model so 4K kontextom, ktorý vyhľadá presne tú správnu pasáž.

Pre bezpečnosť spätného zápisu sú dôsledky nepríjemné: ak je model požiadaný o zhrnutie účtovnej relácie a relevantné pravidlo politiky „túto transakciu neúčtovať“ sa objaví v strede dlhého systémového promptu, model sa môže správať, akoby toto pravidlo nikdy nečítal.

Čo si prečítať ďalej​

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) — navrhuje Multi-scale Positional Encoding (Ms-PoE) ako opravu bez nutnosti trénovania cez škálovanie RoPE; uvádza zlepšenie až o 3,8 bodu na Zero-SCROLLS, čím priamo rieši U-krivku.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198) — volí opačný prístup a trénuje model tak, aby bol explicitne agnostický voči pozícii; porovnanie s Ms-PoE objasňuje, či sú lepším nástrojom jemné doladenie alebo triky pri inferencii.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536) — identifikuje konkrétnu dimenziu pozičných skrytých stavov zodpovednú za zaujatosť a škáluje ju bez opätovného trénovania; doteraz najchirurgickejšia navrhovaná oprava, relevantná pre nasadenie existujúcich modelov bez preškoľovania.

Štúdia​

Tiankai Yang, Yi Nian a kolegovia z USC a Texas A&M predstavujú AD-LLM (arXiv:2412.11142, ACL Findings 2025), prvý benchmark na systematické vyhodnotenie LLM v troch paradigmách detekcie anomálií na NLP datasetoch. Nastavenie predstavuje jednotriednu klasifikáciu (one-class classification): trénovacie dáta obsahujú iba normálne vzorky a model musí pri testovaní označiť anomálie. Päť datasetov – AG News, BBC News, IMDB Reviews, N24 News a SMS Spam – je odvodených z úloh klasifikácie textu, kde jedna kategória je určená ako anomálna. Práca stavia dva modely LLM, GPT-4o a Llama 3.1 8B Instruct, proti 18 tradičným neudržiavaným (unsupervised) základným líniám (baselines), ktoré zahŕňajú end-to-end metódy (CVDD, DATE) a dvojkrokové kombinácie embedding+detektor (OpenAI embeddingy + LUNAR, LOF, Isolation Forest atď.).

Kľúčové myšlienky​

• Zero-shot detekcia pri texte funguje dobre. GPT-4o dosahuje AUROC 0,9293 – 0,9919 v rámci piatich datasetov v nastavení Normálna+Anomália; Llama 3.1 dosahuje 0,8612 – 0,9487. Najlepšia tradičná základná línia, OpenAI + LUNAR, dosahuje na AG News skóre okolo 0,92 – GPT-4o sa jej vyrovnáva alebo ju prekonáva bez akéhokoľvek trénovania.
• Syntetická augmentácia pomáha, konzistentne, ale mierne. Syntetické vzorky generované pomocou LLM zlepšujú pipeline OpenAI + LUNAR na všetkých piatich datasetoch. Augmentácia popisu kategórií tiež zlepšuje väčšinu základných línií, hoci prírastky sú nerovnomerné – Llama 3.1 zlepšuje AUROC o +0,07 pri IMDB Reviews, ale inde sú výsledky menšie.
• Výber modelu je slabým článkom. GPT-o1-preview odporúča modely, ktoré prekonávajú priemerný výkon základných línií na väčšine datasetov a občas sa približujú k najlepšej metóde (napr. pri IMDB Reviews a SMS Spam). Nikdy však spoľahlivo neidentifikuje najlepšie fungujúci model a autori priznávajú, že odporúčania sú založené na zjednodušených vstupoch, ktorým chýbajú štatistiky špecifické pre daný dataset.
• Priepasť medzi open-source a proprietárnymi modelmi je reálna. Náskok GPT-4o v AUROC oproti Llama 3.1 8B je 4 až 13 bodov v závislosti od datasetu, čo je rozdiel konzistentný so vzorcom pozorovaným v prácach o zero-shot detekcii tabuľkových anomálií.
• NLP detekcii anomálií stále chýba definitívny benchmark. Päť datasetov, všetky odvodené z klasifikačných korpusov, je málo. Sprievodná práca NLP-ADBench (EMNLP Findings 2025) rozširuje záber na osem datasetov a 19 algoritmov, ale stále používa rovnakú konštrukciu „sémantická kategória ako anomália“, čo robí tieto úlohy do istej miery umelými.

Čo obstojí — a čo nie​

Zistenia týkajúce sa zero-shot detekcie sú dôveryhodné. Používanie LLM ako hodnotiacich nástrojov (scorers) bez jemného doladenia na označených dátach anomálií je skutočne užitočné, ak je trieda anomálií sémanticky koherentná – spamová správa sa od legitímnej SMS líši spôsobmi, ktorým dobre natrénovaný jazykový model rozumie. Hodnoty AUROC sú vysoké a porovnanie so silnými základnými líniami založenými na OpenAI embeddingoch je spravodlivé.

Rozsah je však úzky spôsobmi, ktoré práca podceňuje. Všetkých päť datasetov kóduje anomálie ako inú tematickú kategóriu – spam verzus legitímne SMS, správy od vyčleneného vydavateľa verzus správy z distribúcie. To znamená, že LLM v podstate vykonáva tematickú klasifikáciu, čo je úloha, na ktorú je explicitne predtrénovaný. Benchmark nezahŕňa sémantické anomálie v rámci jednej kategórie (napr. neobvyklé transakcie v rámci rovnakého typu účtu), čo je presne ten druh anomálie, na ktorom záleží pri finančnom audite.

Úlohy augmentácie dát a výberu modelu sú vyhodnocované na tých istých piatich datasetoch, takže práca nakoniec testuje, či LLM dokážu mierne zlepšiť rôzne aspekty toho istého úzkeho problému. Autori otvorene uvádzajú šesť obmedzení – vrátane toho, že testujú iba podmnožinu LLM, vylučujú režimy few-shot a jemného doladenia a spoliehajú sa na zjednodušené vstupy pre výber modelu – čo je intelektuálne poctivé, ale zároveň to signalizuje, aký predbežný tento benchmark je.

Jeden výsledok stojí za zmienku pre skeptikov: skóre AUPRC sú u oboch modelov podstatne nižšie ako AUROC. Llama 3.1 na BBC News dosahuje AUROC 0,8612, ale AUPRC iba 0,3960, čo odráža nerovnováhu tried v jednotriednom nastavení. V kontextoch auditu s vysokou presnosťou je AUPRC zmysluplnejšou metrikou a tu je obraz menej lichotivý.

Prečo na tom záleží pre finančnú AI​

Agenda Bean Labs zahŕňa dva prípady použitia detekcie anomálií: zachytávanie neobvyklých položiek účtovnej knihy v reálnom čase (tabuľkové, štruktúrované) a označovanie podozrivého naratívneho textu vo faktúrach, memách alebo tiketoch podpory (neštruktúrované NLP). AD-LLM hovorí priamo k druhému prípadu a poskytuje nám realistický strop: GPT-4o dokáže zero-shot detegovať anomálie na úrovni tém v texte s AUROC nad 0,93 na čistých, vyvážených datasetoch. To je užitočný základ, ale anomálie v opisoch účtovnej knihy sú jemnejšie – poznámka na faktúre, ktorá popisuje rutinnú službu, ale patrí dodávateľovi označenému pre podozrivé vzorce, nie je problémom tematickej klasifikácie. Benchmark poskytuje východiskový bod, nie odpoveď.

Zistenie o výbere modelu je samostatne zaujímavé pre návrh systému. Sen o tom, že sa spýtame LLM „ktorý detektor anomálií mám použiť na tomto datasete?“ a dostaneme spoľahlivú odpoveď, sa zatiaľ nenapĺňa. To znamená, že výber medzi jemným doladením v štýle AnoLLM, kauzálnym promptovaním v štýle CausalTAD alebo klasickou metódou embeddingov stále vyžaduje ľudský úsudok alebo systematické empirické vyhodnotenie – nemožno to delegovať na LLM poradcu.

Čo si prečítať ďalej​

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025) – sprievodný benchmark od rovnakej skupiny, pokrývajúci osem datasetov a 19 algoritmov; poskytuje širší kontext klasických základných línií, ktorý rozsah piatich datasetov AD-LLM nemôže obsiahnuť.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025) – prehľad celého prostredia prístupov k detekcii anomálií založených na LLM v textových, obrazových a tabuľkových modalitách; dopĺňa kontext o tom, kde sa AD-LLM nachádza v porovnaní s predchádzajúcimi prácami.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) – tabuľkový náprotivok; porovnanie jeho prístupu založeného na pravdepodobnosti (likelihood) so zero-shot stratégiou AD-LLM založenou na promptoch objasňuje, ktorá paradigma je vhodnejšia pre položky účtovnej knihy Beancount.

Odborný príspevok​

Wang a kol. navrhujú CausalTAD, metódu, ktorá stojí nad detektormi anomálií typu AnoLLM a robí jednu cielenú zmenu: namiesto serializácie tabuľkových riadkov v náhodnom alebo ľubovoľnom poradí stĺpcov zisťuje kauzálne závislosti medzi stĺpcami a preusporiada ich tak, aby tieto závislosti rešpektovali ešte predtým, než LLM riadok prečíta.

Príspevok má dve pohyblivé časti. Po prvé, modul usporiadania stĺpcov riadený kauzalitou. Autori adaptujú rámec na extrakciu faktorov COAT: LLM číta metadáta stĺpcov a vzorky na extrakciu sémantických faktorov na vysokej úrovni (pri transakciách kreditnou kartou môže faktor ako „Kompenzácia“ zahŕňať stĺpce sumy a obchodníka). Z týchto faktorov tri algoritmy na zisťovanie kauzality — PC, LiNGAM a FCI — každý zostaví orientovaný kauzálny graf nad faktormi. Problém preusporiadania stĺpcov sa potom stáva problémom lineárneho usporiadania (Linear Ordering Problem): nájsť permutáciu π, ktorá maximalizuje súčet váh orientovaných hrán tak, aby sa stĺpce príčiny objavili pred stĺpcami následku v serializovanom texte. Keďže lineárne programovanie (LP) má mnoho takmer optimálnych riešení, odoberajú vzorku K ≈ 10 usporiadaní v rámci 90 % optima a vypočítajú z nich priemer.

Po druhé, modul prehodnotenia váh zohľadňujúci kauzalitu. Nie všetky stĺpce sú rovnako relevantné. Stĺpec, ktorý ovplyvňuje mnoho faktorov, získa vyššiu váhu αj = |M⁻¹(cj)|, čo je počet faktorov, ku ktorým prispieva. Konečné skóre anomálie je vážený priemer negatívnych logaritmických vierohodností na stĺpec naprieč K usporiadaniami.

Kľúčové myšlienky​

• Usporiadanie stĺpcov je netriviálny induktívny bias pre autoregresné modely LLM: umiestnenie stĺpca s príčinou pred stĺpec s následkom umožňuje modelu podmieniť sa správnym kontextom pri priraďovaní vierohodnosti následku.
• Zisťovanie kauzality na úrovni faktorov (namiesto úrovne surových stĺpcov) umožňuje metóde spracovávať tabuľky so zmiešanými typmi dát, kde je priame zisťovanie kauzality medzi heterogénnymi stĺpcami zašumené.
• Na 6 benchmarkových súboroch dát so zmiešanými typmi dosahuje CausalTAD s modelom SmolLM-135M priemerné AUC-ROC 0,834 oproti 0,803 pri AnoLLM — čo je absolútne zlepšenie o 3,1 bodu pri rovnakom základnom modeli.
• Konkrétne na súbore dát Fake Job Posts dosahuje CausalTAD skóre 0,873 oproti 0,800 pri AnoLLM — relatívny zisk 9,1 %, čo je dostatočne významné v reálnom systéme triáže.
• Naprieč 30 numerickými benchmarkovými súbormi dát ODDS dosahuje CausalTAD najlepšie priemerné AUC-ROC, pričom konzistentne prekonáva klasické základné metódy (Isolation Forest, ECOD, KNN) aj hlboké metódy (DeepSVDD, SLAD).
• Všetky tri algoritmy na zisťovanie kauzality porazili náhodné usporiadanie v ablačnej štúdii; LiNGAM mierne predstihol PC a FCI na zmiešaných súboroch dát.

Čo obstojí — a čo nie​

Hlavné tvrdenie — že kauzálne poradie stĺpcov pomáha — je dobre podložené. Ablačná štúdia je jasná: výmena náhodného usporiadania za ktorúkoľvek z troch metód zisťovania kauzality zlepšuje výsledky na benchmarku Fake Job Posts (z 0,832 na 0,870–0,873) a prehodnotenie váh na základe počtu faktorov ďalej pomáha v každej konfigurácii. To je dôveryhodný príbeh.

Čo považujem za menej presvedčivé, je predpoklad bootstrappingu. Kauzálny graf je vytvorený pomocou LLM na extrakciu sémantických faktorov práve z tých dát, ktoré má systém analyzovať. Ak LLM nesprávne pochopí doménu — napríklad v prípade účtovného systému na mieru s neštandardnými názvami stĺpcov — extrakcia faktorov bude nesprávna a zlý kauzálny graf je pravdepodobne horší ako náhodné usporiadanie, pretože zavádza systematické skreslenie. Autori priznávajú toto riziko („spolieha sa na schopnosť LLM extrahovať faktory“), ale netestujú presnosť extrakcie faktorov nezávisle.

Existuje tiež problém s výpočtovou réžiou, ktorý je vážnejší, než naznačuje článok. Spustenie troch algoritmov na zisťovanie kauzality, riešenie LP, vzorkovanie K usporiadaní a následné spustenie inferencie na K serializovaných verziách každého testovacieho bodu znásobuje náklady na inferenciu faktorom K. Pre účtovnú knihu s miliónmi záznamov je to dôležité. Článok uvádza, že „budúca práca sa môže zamerať na zlepšenie efektívnosti“, ale neponúka žiadne konkrétne profilovanie.

Napokon, 30 numerických súborov dát ODDS je dobre preštudovaných a pravdepodobne už saturovaných pre metódy tohto typu. Významnejší signál je v 6 súboroch dát so zmiešanými typmi — ktoré sú realistické pre financie — a tamojšie zlepšenia, hoci reálne, sú v absolútnych číslach skôr mierne.

Prečo je to dôležité pre finančnú AI​

Transakcie v systéme Beancount majú skutočnú kauzálnu štruktúru: suma účtovného zápisu kauzálne ovplyvňuje výber účtu, účet ovplyvňuje očakávanie protistrany a text poznámky je kauzálne závislý od všetkých troch. Náhodná serializácia stĺpcov to ignoruje, čo znamená, že model typu AnoLLM vidí „poznámka: potraviny | účet: Výdavky:Jedlo | suma: 4200 $“ rovnako ľahko ako správne usporiadanú verziu.

CausalTAD poskytuje principiálny spôsob, ako zakódovať, že „suma a účet sú na prvom mieste“, bez toho, aby to bolo natvrdo kódované ako pravidlo. Pre auditných agentov Bean Labs to naznačuje praktickú architektonickú voľbu: pred skórovaním dávky transakcií na anomálie urobte jeden prechod na zistenie kauzálneho grafu nad schémou stĺpcov účtovnej knihy a potom použite toto pevné usporiadanie pre celú následnú inferenciu. Réžia sa zaplatí raz na úrovni schémy, nie pri každej transakcii.

Príklad detekcie podvodov s kreditnými kartami v článku má v podstate rovnakú štruktúru úloh ako detekcia anomálií v účtovnej knihe: heterogénne vlastnosti, vzácne označenia a kauzálne poradie, ktoré doménoví experti poznajú intuitívne, ale ktoré by modely LLM inak ignorovali.

Čo si prečítať ďalej​

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — systematický benchmark naprieč tromi paradigmami detekcie anomálií pomocou LLM, do ktorého CausalTAD zapadá; jeho prečítanie poskytuje celkový prehľad namiesto jediného porovnania AnoLLM vs CausalTAD.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — rámec pre extrakciu faktorov, ktorý CausalTAD adaptuje; pochopenie jeho fungovania objasňuje, kde môže kvalita kauzálneho grafu zlyhať.
• Causal discovery in heterogeneous data: a survey — pre pochopenie relatívnych výhod PC vs LiNGAM vs FCI na tabuľkových dátach zmiešaného typu, keďže článok s nimi zaobchádza ako so zameniteľnými, hoci vychádzajú z rôznych predpokladov o nezávislosti.

O čom je tento článok​

AnoLLM preformulováva detekciu anomálií v tabuľkových údajoch skôr ako odhad hustoty jazykového modelu než ako klasifikáciu pomocou promptov. Namiesto toho, aby autori žiadali LLM o pomenovanie riadkov, ktoré vyzerajú podozrivo, doladia predtrénovaný jazykový model na serializovaných trénovacích riadkoch z normálnej distribúcie a potom ohodnotia každý testovací riadok podľa jeho zápornej logaritmickej vierohodnosti (NLL) v rámci tejto naučenej distribúcie. Riadok, ktorý sa vôbec nepodobá na trénovaciu distribúciu, získa vysoké NLL — to je skóre anomálie. Žiadny formát indexu, žiadne parsovanie výstupu, žiadna krehká extrakcia pomocou regulárnych výrazov.

Serializácia prevádza každý riadok tabuľky na reťazec v prirodzenom jazyku s názvami príznakov a ich hodnotami. Pri stĺpcoch s textovými hodnotami sa NLL normalizuje na stĺpec, aby sa predišlo skresleniu dĺžkou, kde by dlhšie popisy inak mechanicky akumulovali vyššie pravdepodobnostné náklady. Pri numerických a kategorických stĺpcoch sa sčítava surové NLL na úrovni tokenov naprieč polom. Model sa dolaďuje v semi-supervizovanom nastavení — do tréningu vstupujú iba riadky označené ako normálne — až v 2 000 krokoch pomocou distribuovaného tréningu na GPU.

Kľúčové myšlienky​

• Problém s formátom výstupu: predchádzajúce prístupy k predikcii indexov vyžadujú, aby LLM spoľahlivo vypísali indexy anomálnych riadkov z dávky. Modely z rodiny Llama často priraďujú nesprávne indexy k hodnotám, generujú indexy mimo veľkosti dávky alebo jednoducho uvádzajú všetko ako anomálne. NLL sa tomuto úplne vyhýba.
• AnoLLM dosahuje najlepší výkon na šiestich benchmarkových súboroch údajov so zmiešanými typmi príznakov, vrátane detekcie podvodov v poistení vozidiel a e-commerce súborov údajov z Kaggle.
• Na 30 prevažne numerických súboroch údajov benchmarku ODDS dosahuje AnoLLM porovnateľné výsledky s najlepšími klasickými baseline modelmi — nie je jednoznačne lepší, len konkurencieschopný.
• Normalizácia NLL na stĺpec pre textové príznaky je malé, ale kľúčové inžinierske rozhodnutie: bez neho by popis transakcie s tridsiatimi tokenmi dominoval skóre nad dvojcifernou sumou, čo je nesprávna induktívna predpoveď.
• Tréningový kontext: zero-shot prístup GPT-4 (arXiv:2406.16308) dosahuje priemerné AUROC 74,1 na ODDS, čo je porovnateľné s ECOD (75,5) a KNN (70,7). Výhoda AnoLLM sa prejavuje konkrétne na súboroch údajov, kde textové a kategorické príznaky nesú významný signál o anomálii.

Čo obstojí — a čo nie​

Hlavná myšlienka NLL je správna. Použitie doladeného jazykového modelu ako odhadu hustoty nad serializovanými riadkami je principiálne a prirodzene spracováva združenú distribúciu všetkých stĺpcov súčasne — čo klasické detektory bez dozoru aplikované stĺpec po stĺpci nedokážu urobiť čisto. Oprava predikcie indexov je skutočne užitočná a porovnanie so zero-shot baseline modelom je férové.

Čo ma zaráža, je rozdiel v nákladoch a prínosoch, o ktorom článok informuje nedostatočne. AnoLLM vyžaduje doladenie a prevádzku LLM pre inferenciu — čo je podstatný infraštruktúrny záväzok v porovnaní s natrénovaním ECOD alebo IsolationForest na CPU v priebehu sekúnd. V benchmarku ODDS (čisto numerickom) je AnoLLM len „na úrovni“, nie lepší. Prípad pre AnoLLM je teda výhradne v režime zmiešaných typov, kde šesť vyhodnotených súborov údajov pochádza z detekcie podvodov na Kaggle. Šesť súborov údajov je tenký empirický základ pre silné odporúčanie, najmä preto, že benchmarkové súbory údajov z Kaggle majú tendenciu mať čisté schémy, pevnú sémantiku stĺpcov a známu skutočnosť (ground truth) — čo sú všetko veci, ktoré produkčným údajom účtovných kníh často chýbajú.

Problém s poradím stĺpcov zostáva tiež otvorený. CausalTAD (arXiv:2602.07798) okamžite identifikoval túto medzeru: AnoLLM serializuje stĺpce v ľubovoľnom poradí, pričom ignoruje kauzálne vzťahy medzi poliami. Pri štruktúrovaných údajoch so známymi kauzálnymi reťazcami — typ účtu ovplyvňuje platné rozsahy transakcií, ktoré ovplyvňujú očakávanú protistranu — je to reálne obmedzenie. CausalTAD definuje zmenu poradia ako problém lineárneho usporiadania a uvádza konzistentné zlepšenie oproti AnoLLM vo viac ako 30 súboroch údajov. Skutočnosť, že táto medzera existovala a dala sa tak rýchlo nájsť, naznačuje, že návrh serializácie AnoLLM nebol úplne domyslený.

Existuje aj otázka rozsahu, ktorou sa článok nezaoberá: pri akom objeme normálnych tréningových príkladov sa doladenie LLM oplatí viac ako napríklad tabuľkový deep learning model trénovaný priamo na numerických príznakoch? Pre osobné účtovné knihy Beancount s niekoľkými tisíckami záznamov môžu náklady na výpočet ľahko prevýšiť akýkoľvek nárast presnosti.

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

Záznamy v účtovnej knihe Beancount sú presne tým druhom údajov so zmiešanými typmi, na ktoré sa AnoLLM zameriava: sumy (numerické), názvy účtov (štruktúrovaný text), príjemca/popis (voľný text), tagy (kategorické), dátumy (štruktúrované). Jeden riadok ako 2024-03-15 * "AWS" "Cloud invoice" Assets:Checking -$2,400 kóduje informácie naprieč všetkými týmito typmi súčasne. Klasické detektory anomálií tu majú problémy, pretože potrebujú samostatné spracovanie pre každý typ stĺpca a strácajú korelácie medzi nimi — spoločný vzorec, že faktúry „AWS“ by mali byť v určitom rozsahu a mali by smerovať na konkrétny účet.

Prístup NLL v AnoLLM by sa v princípe naučil tieto spoločné vzorce z normálnych historických záznamov a označil by odchýlky v akejkoľvek kombinácii stĺpcov. To je potenciálne užitočnejšie ako JETy založené na pravidlách alebo štatistické testy jedného stĺpca.

Napriek tomu je obmedzenie podvojného účtovníctva štrukturálnou znalosťou, ktorú sa AnoLLM nedokáže naučiť len zo serializovaných riadkov — debet sa musí rovnať kreditu, hierarchie účtov sa musia dodržiavať. Tieto doménové invarianty sú pevné obmedzenia, nie štatistické pravidelnosti, a žiadne množstvo doladenia LLM na historických riadkoch ich nebude spoľahlivo vynucovať, ak tréningové údaje obsahujú akékoľvek výnimky alebo zaokrúhľovacie artefakty. Správna architektúra pravdepodobne kombinuje skórovanie NLL pomocou AnoLLM pre sémantické anomálie s explicitnými kontrolami pravidiel pre tie štrukturálne.

Čo si prečítať ďalej​

• CausalTAD (arXiv:2602.07798) — priamo vylepšuje AnoLLM vložením kauzálneho poradia stĺpcov; najaktuálnejšie nadväzujúce čítanie na vyhodnotenie.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — poskytuje systematické multiparadigmatické vyhodnotenie, ktoré chýba v článkoch o jednotlivých metódach.
• „Language Models are Realistic Tabular Data Generators“ (Borisov a kol., arXiv:2210.06280, ICLR 2023) — model BE-GREAT, ktorý AnoLLM používa ako základ; jeho pochopenie objasňuje, čo AnoLLM skutočne vylepšuje okrem predikcie indexov.

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.