DocFinQA: Фінансове міркування в довгому контексті на повних звітах SEC

DocFinQA — це стаття ACL 2024 року, яка бере існуючий набір даних FinQA та представляє кожне запитання разом із повним звітом SEC, з якого воно походить — розширюючи середній контекст з менш ніж 700 слів до 123 000 слів. Я читаю її, тому що вона безпосередньо тестує сценарій, з яким стикається кожен робочий агент Beancount: не акуратно витягнутий уривок, а цілий заплутаний документ. Результати протверезні для будь-кого, хто планує розгортати моделі з довгим контекстом над багаторічними гросбухами.

Стаття

DocFinQA: A Long-Context Financial Reasoning Dataset — Варшіні Редді, Рік Концел-Кедзіорскі, В’єт Дак Лай, Майкл Крумдік, Чарльз Ловерінг та Кріс Таннер (ACL 2024, Short Papers) — бере 8 281 пару запитань та відповідей з FinQA та доповнює 7 621 з них повним річним звітом SEC, з якого кожне запитання спочатку походило. В результаті ми маємо 1 236 унікальних звітів, розділених на 5 798 навчальних, 791 розробницький та 1 032 тестових приклади, причому середній контекст роздувається в 175 разів — з приблизно 700 слів до 123 453 слів.

Набір запитань залишився без змін — це ті самі багатокрокові запитання на числове міркування, що потребують програм на Python для відповіді. Що змінюється, так це те, що модель тепер отримує повний звіт, а не майстерно відібраний уривок на 700 слів. Дослідження порівнює два сімейства підходів: класичні конвеєри пошуку (фрагментація, ранжування, відповідь) та нові LLM з довгим контекстом, які намагаються обробити весь документ наскрізно.

Ключові ідеї

• Найкраща точність пошукового конвеєра на тестовому наборі: GPT-3.5 — 42,64%. Моделі з відкритим кодом значно відстають: Mistral/7B — 24,97%, CodeLlama/13B — 21,01%, MPT/30B — 18,07%.
• Найкращий кодувальник пошуку — донавчений ColBERT — досягає HR@1 = 0,35 та HR@3 = 0,55, що означає відсутність правильного фрагмента в контексті моделі майже в половині випадків, навіть при отриманні трьох уривків.
• GPT-4 з довгим контекстом (оцінено на підвибірці з 400 питань): 46,5% на коротших документах (≤100 тис. токенів) проти 23,0% зі стратегією «Підсумувати, а потім відповісти» на найдовших документах (>100 тис. токенів). GPT-4 припускається майже вдвічі більше помилок на довгих документах, ніж на коротких.
• Спеціалізований фінансовий парсинг PDF (Kensho Extract) суттєво перевершив загальний HTML-парсинг (BeautifulSoup), особливо щодо збереження таблиць — практичне відкриття для будь-якого конвеєра, побудованого на звітах SEC.
• Значна частина релевантних фрагментів знаходиться за межами 250-ї позиції в документі, що означає, що стратегії, засновані на відсіканні, мовчки відкидають правильні докази ще до того, як модель їх побачить.

Що підтверджується, а що — ні

Основний емпіричний внесок є солідним: набір даних є сумлінним розширенням FinQA з чітко визначеною методологією (чотириграмна оцінка схожості для ідентифікації золотих фрагментів, фрагменти по 2 750 символів з 20% перекриттям), і висновок про те, що продуктивність серйозно погіршується зі збільшенням довжини документа, є послідовним як для пошукових підходів, так і для підходів з довгим контекстом. Майже дворазове збільшення помилок GPT-4 на довгих документах порівняно з короткими є вражаючим, і його важко спростувати.

Чого стаття не розглядає повною мірою, так це передові моделі з довгим контекстом зразка 2024 року. Оцінка довгого контексту охоплює лише 400 зразків через обмеження вартості та не тестує Gemini 1.5 Pro (вікно 1 млн токенів) або Claude 3 (200 тис.). Гіперпараметри фрагментації є розумними, але не були систематично перевірені, а стратегія декількох викликів «Підсумувати, а потім відповісти», ймовірно, не є найкращою — переплетений пошук IRCoT та структурований синтез StructRAG свідчать про наявність кращих підходів для агрегації доказів у довгих документах.

Донавчений ColBERT, що досягає HR@3 = 0,55, виявляє глибшу проблему: пошук у довгих фінансових документах сам по собі залишається невирішеним. Навіть з ідеальною генеративною моделлю майже половина запитів отримала б відповідь, побудовану на неправильних уривках. Стаття висвітлює це як стримуючий фактор, але зупиняється перед кількісною оцінкою того, наскільки відновлюється точність, коли пошук стає безпомилковим (oracle).

Чому це важливо для фінансового ШІ

Багаторічні гросбухи Beancount не мають у середньому 123 тис. слів за замовчуванням, але десятиліття транзакцій з детальними примітками легко досягають цього обсягу, і фінансовий агент, що працює з повними річними звітами, стикається саме з таким режимом. Перехід від «ми вибрали правильні 700 слів» (FinQA) до «ось повний звіт 10-Q» (DocFinQA) відображає розрив між іграшковим бенчмарком та виробничою реальністю. DocFinQA робить цей розрив вимірюваним.

Майже 50-відсоткове падіння точності GPT-4 від коротких документів до довгих свідчить проти простої відповіді «просто використовуйте більше вікно контексту». Пошук залишається необхідним, але він надійний лише на 55% при HR@3. Для агента зворотного запису Beancount, якому потрібно знайти графік амортизації, похований у річній примітці до рахунків, жодна архітектура не забезпечує надійності, якої ви хотіли б перед фіксацією запису в журналі. Чесне прочитання цієї статті: те, що галузі насправді потрібно — це кращий пошук, краща агрегація доказів та явна оцінка прихованих збоїв, а не просто більше вікно контексту.

Що читати далі

• "Lost in the Middle: How Language Models Use Long Contexts" — Liu et al., 2023, arXiv:2307.03172. Надає механістичне пояснення падіння точності залежно від позиції, яке вимірює DocFinQA, з тепер уже канонічною U-подібною кривою продуктивності.
• FinDER: Financial Dataset for Question Answering and Evaluating Retrieval-Augmented Generation — arXiv:2504.15800, ICLR 2025 Workshop. Наступний бенчмарк 2025 року з 5 703 трійками запит-доказ-відповідь, розробленими навколо реалістичних професійних фінансових пошукових запитів, включаючи абревіатури та акроніми, які стандартні пошукові системи пропускають.
• Fin-RATE: A Real-world Financial Analytics and Tracking Evaluation Benchmark for LLMs on SEC Filings — arXiv:2602.07294. Новіший бенчмарк на основі звітів SEC, який додає завдання часового відстеження поза межами відповідей на запитання за одним документом, що ближче до того, що насправді знадобиться аудиторському агенту Beancount.