DocFinQA: Dlho-kontextové finančné uvažovanie na úplných podaniach SEC

DocFinQA je článok z konferencie ACL 2024, ktorý preberá existujúci dataset FinQA a opätovne predkladá každú otázku spolu s kompletným podaním SEC, z ktorého pochádza — čím rozširuje priemerný kontext z menej ako 700 slov na 123 000 slov. Čítam ho, pretože priamo testuje scenár, ktorému čelí každý produkčný agent Beancount: nie úhľadne extrahovaná pasáž, ale celý chaotický dokument. Výsledky sú triezvym varovaním pre každého, kto plánuje nasadiť modely s dlhým kontextom na viacročné účtovné knihy.

O článku

DocFinQA: A Long-Context Financial Reasoning Dataset — Varshini Reddy, Rik Koncel-Kedziorski, Viet Dac Lai, Michael Krumdick, Charles Lovering a Chris Tanner (ACL 2024, Short Papers) — preberá 8 281 párov otázok a odpovedí z FinQA a 7 621 z nich dopĺňa o úplnú výročnú správu SEC, z ktorej každá otázka pôvodne pochádzala. Výsledkom je 1 236 unikátnych podaní rozdelených do 5 798 trénovacích, 791 vývojových a 1 032 testovacích príkladov, pričom priemerný kontext sa nafúkol 175-násobne z približne 700 slov na 123 453 slov.

Súbor otázok sa nezmenil — ide o tie isté viacstupňové otázky na numerické uvažovanie, ktoré si na zodpovedanie vyžadujú programy v Pythone. Čo sa mení, je to, že model teraz dostáva celé podanie namiesto odborne vybranej 700-slovnej pasáže. Výskum porovnáva dve rodiny prístupov: klasické vyhľadávacie procesy (segmentácia, zoradenie, odpoveď) a vznikajúce LLM s dlhým kontextom, ktoré sa pokúšajú spracovať celý dokument end-to-end.

Kľúčové myšlienky

• Najlepšia presnosť vyhľadávacieho procesu na testovacej sade: GPT-3.5 s 42,64 %. Open-source modely výrazne zaostávajú: Mistral/7B s 24,97 %, CodeLlama/13B s 21,01 %, MPT/30B s 18,07 %.
• Najlepší vyhľadávací enkóder — doladený ColBERT — dosahuje HR@1 = 0,35 a HR@3 = 0,55, čo znamená, že správny úsek chýba v kontexte modelu takmer v polovici prípadov, aj keď sa vyhľadávajú tri pasáže.
• GPT-4 s dlhým kontextom (hodnotený na subsade 400 otázok): 46,5 % na kratších dokumentoch (≤ 100 000 tokenov) oproti 23,0 % so stratégiou „Zhrnúť a potom odpovedať“ (Summarize-then-Answer) na najdlhších dokumentoch (> 100 000 tokenov). GPT-4 robí na dlhých dokumentoch takmer dvakrát viac chýb ako na krátkych.
• Parsovanie PDF špecifické pre financie (Kensho Extract) podstatne prekonalo všeobecné parsovanie HTML (BeautifulSoup), najmä pri zachovaní tabuliek — praktické zistenie pre akýkoľvek proces postavený na podaniach SEC.
• Značná časť relevantných úsekov sa nachádza za pozíciou 250 v dokumente, čo znamená, že stratégie založené na orezávaní (truncation) ticho zahadzujú správne dôkazy skôr, než ich model vôbec uvidí.

Čo obstojí — a čo nie

Hlavný empirický prínos je solídny: dataset je verným rozšírením FinQA s jasne definovanou metodológiou (skórovanie podobnosti štvorgramov na identifikáciu zlatých úsekov, 2 750-znakové úseky s 20 % prekrytím) a zistenie, že výkon s dĺžkou dokumentu prudko klesá, je konzistentné v rámci vyhľadávacích prístupov aj prístupov s dlhým kontextom. Takmer zdvojnásobenie chýb GPT-4 pri dlhých dokumentoch v porovnaní s krátkymi je pozoruhodné a ťažko spochybniteľné.

To, čomu sa článok plne nevenuje, je hranica modelov s dlhým kontextom z roku 2024. Hodnotenie dlhého kontextu pokrýva kvôli nákladom len 400 vzoriek a netestuje Gemini 1.5 Pro (okno 1M tokenov) alebo Claude 3 (200K). Hyperparametre segmentácie (chunking) sú rozumné, ale nie systematicky testované, a stratégia viacerých volaní „Zhrnúť a potom odpovedať“ pravdepodobne nie je to najlepšie, čo je k dispozícii — prekladané vyhľadávanie IRCoT a štruktúrovaná syntéza StructRAG naznačujú, že pre agregáciu viacerých dôkazov v dlhých dokumentoch existujú lepšie prístupy.

Doladený ColBERT dosahujúci HR@3 = 0,55 odhaľuje hlbší problém: samotné vyhľadávanie v dlhých finančných dokumentoch je nevyriešené. Dokonca aj s dokonalým generatívnym modelom by takmer polovica dopytov dostala odpoveď postavenú na nesprávnych pasážach. Článok to vyzdvihuje ako limitujúce obmedzenie, ale nekvantifikuje, o koľko by sa presnosť zlepšila, ak by bolo vyhľadávanie ideálne (oracle).

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

Viacročné účtovné knihy Beancount nemajú v priemere 123 000 slov, ale desaťročie transakcií s detailnými poznámkami túto hranicu ľahko dosiahne a finančný agent pracujúci s úplnými výročnými správami čelí presne tomuto režimu. Prechod od „vybrali sme správnych 700 slov“ (FinQA) k „tu je celé 10-Q“ (DocFinQA) predstavuje rozdiel medzi ukážkovým benchmarkom a produkčnou realitou. DocFinQA robí tento rozdiel merateľným.

Takmer 50 % pokles presnosti GPT-4 pri prechode od krátkych k dlhým dokumentom hovorí proti jednoduchému riešeniu „stačí použiť väčšie kontextové okno“. Vyhľadávanie zostáva nevyhnutné, ale pri HR@3 je spoľahlivé len na 55 %. Pre Beancount agenta so spätným zápisom, ktorý potrebuje nájsť odpisový plán pochovaný v rok starom dodatku k účtovnej závierke, ani jedna architektúra neposkytuje spoľahlivosť, ktorú by ste chceli pred odoslaním účtovného zápisu. Úprimné čítanie tohto článku: to, čo oblasť skutočne potrebuje, je lepšie vyhľadávanie, lepšia agregácia dôkazov a explicitné vyhodnocovanie tichých zlyhaní — nie väčšie kontextové okno.

Čo si prečítať ďalej

• "Lost in the Middle: How Language Models Use Long Contexts" — Liu et al., 2023, arXiv:2307.03172. Poskytuje mechanistické vysvetlenie kolapsu presnosti podľa pozície, ktorý DocFinQA meria, s dnes už kanonickou krivkou výkonu v tvare písmena U.
• FinDER: Financial Dataset for Question Answering and Evaluating Retrieval-Augmented Generation — arXiv:2504.15800, ICLR 2025 Workshop. Nástupnícky benchmark z roku 2025 s 5 703 trojicami dopyt-dôkaz-odpoveď, navrhnutý podľa realistických profesionálnych finančných vyhľadávacích dopytov, vrátane skratiek a akronymov, ktoré štandardné vyhľadávače prehliadajú.
• Fin-RATE: A Real-world Financial Analytics and Tracking Evaluation Benchmark for LLMs on SEC Filings — arXiv:2602.07294. Novší benchmark podaní SEC, ktorý k úlohám QA v rámci jedného dokumentu pridáva úlohy sledovania v čase, čo je bližšie tomu, čo by skutočne potreboval auditný agent Beancount.