FinDER: реальні запити аналітиків виявили 74% розриву в повноті фінансових RAG-систем

FinDER (arXiv:2504.15800) — це бенчмарк пошуку, побудований навколо простого, але недооціненого спостереження: запити, які насправді вводять фінансові професіонали, зовсім не схожі на вилизані питання в академічних тестах. Я читаю його, тому що він знаходиться на перетині двох тем, за якими я стежу — розриву в повноті пошуку у фінансовому ШІ та проблеми практичного реалізму, яку почали висвітлювати DocFinQA та FinanceBench.

Стаття

Чаньоль Чхве, Чжіхун Квон та їхні колеги з фірми з розробки фінансового ШІ представляють набір даних із 5 703 анотованих експертами трійок «запит–доказ–відповідь», отриманих з реального сервісу питань та відповідей для аналітиків хедж-фондів. Документами є звіти за формою 10-K від 490 компаній S&P 500, зібрані з бази SEC EDGAR. Що відрізняє FinDER від попередніх бенчмарків, так це сторона запитів: 89,86% запитів містять три або більше галузевих абревіатур або акронімів. Замість «Який загальний дохід компанії X за 2023 фінансовий рік?», реальний аналітик може ввести «GOOGL 10-K FY23 revs breakdown by segment». Набір даних був опублікований на воркшопі ICLR 2025 з досягнень у галузі фінансового ШІ, а пізніше з'явився на ICAIF 2025.

Основні ідеї

• Повнота пошуку (retrieval recall) шокуюче низька скрізь: E5-Mistral (найкраща модель щільного пошуку) досягає лише 25,95% загальної повноти контексту; BM25 справляється лише на 11,68%. Категорія «Фінанси» — найбільш релевантна для бухгалтерського обліку — виявилася найскладнішою: 15,84% та 6,42% відповідно.
• Сама лише неоднозначність запитів коштує 8,2 пункта точності: Тестуючи E5-Mistral на 500 запитах, автори порівнюють правильно сформульовані парафрази (33,9 точності) з реальними скороченими запитами (25,7 точності). Розрив повністю зумовлений обробкою абревіатур та акронімів, а не складністю документів.
• Якість пошуку є домінуючим вузьким місцем для генерації: LLM без контексту показують результат близький до нуля (9–10% правильних відповідей); з топ-10 знайдених фрагментів вони досягають 29–34%; з ідеальним контекстом (oracle context) результат стрибає до 60–68%. Цей розрив у 35 пунктів між реалістичними та ідеальними умовами більший за різницю між моделями з відкритим кодом та передовими (frontier) моделями.
• Композиційна арифметика не дається навіть за умови хорошого пошуку: Багатокрокові обчислювальні завдання (композиційні запити) досягають лише ~20% правильності у всіх чотирьох моделях — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill та Qwen-QWQ — навіть за умови наявності топ-10 фрагментів. GPT-o1 лідирує в задачах на множення з результатом 42,90%, але падає до 27,78% на діленні.
• Переранжування (reranking) за допомогою LLM дає невелике, але стабільне покращення: Якщо дозволити моделям переранжувати топ-10 результатів E5-Mistral перед відповіддю, Claude-3.7-Sonnet досягає F1 63,05, а GPT-o1 — 62,90. Deepseek-R1-Distill відстає з 60,01, попри сильні результати у структурованих міркуваннях в інших тестах.
• Складність категорій нерівномірна: Запити щодо ризиків найлегше піддаються пошуку (E5-Mistral: 33,07 повноти); Фінанси залишаються найскладнішими (15,84). Це корелює зі структурою запиту — розкриття ризиків використовує прозу природною мовою, тоді як фінансові таблиці використовують щільну числову нотацію.

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

Основний внесок є солідним: це реальний розподіл запитів від працюючих аналітиків, і проблема скорочень є справжньою. Будь-який бенчмарк, побудований на Вікіпедії або краудсорсингу в стилі FinQA, пропускає цей момент. Трьохрівнева структура оцінки — без контексту, реалістичний пошук, ідеальний контекст — це правильний підхід; він чітко відділяє якість пошуку від якості міркувань і показує залишковий розрив у генерації (все ще ~32–34% невдач навіть з ідеальним контекстом у якісних питаннях).

Найслабшим місцем статті є відтворюваність. На момент публікації набір даних не був публічно доступним — автори заявляють, що «планують випустити його публічно пізніше». Це суттєва проблема для статті з воркшопу, яка позиціонує себе як стандарт оцінки. Бенчмарки, які не випущені, — це не бенчмарки, а кейс-стаді. Згодом він з'явився на ICAIF 2025, тож реліз міг відбутися, але версія на arXiv цього не підтверджує.

Оцінка пошуку також використовує лише чотири одностадійні моделі (BM25, GTE, mE5, E5-Mistral). Немає гібридного пошуку, немає розширення запитів, немає HyDE, немає етапу переписування, спрямованого саме на проблему скорочень. Враховуючи, що автори точно охарактеризували розрив через абревіатури, дивно, що вони не тестують очевидне рішення: розширити запит («GOOGL» → «Alphabet Inc.») перед пошуком. Цей експеримент відсутній.

Результати генерації заслуговують на уважніше вивчення. Результативність у 9–10% без контексту не є корисною нижньою межею — це фактично нуль — але «стеля» ідеального контексту в 60–68% є більш інформативною, ніж здається. Навіть маючи на руках правильний фрагмент, найкращі моделі зазнають невдачі приблизно в одній третині якісних питань і в чотирьох п'ятих композиційної арифметики. Ця стеля важлива: вона означає, що сам по собі пошук не може вирішити проблему.

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

Розподіл запитів у FinDER добре відображає те, як користувачі Beancount насправді взаємодіють з агентом облікової книги. Користувач, який роками веде свої рахунки, буде вводити скорочені контекстні запити — «AMZN card Q3 reimb?» замість «Які відшкодування за кредитною карткою Amazon у третьому кварталі?». Стандартні моделі ембедінгів не зможуть знайти потрібні записи, оскільки вони були навчені на чистих текстах природною мовою. Падіння точності на 8,2 пункта від чистих до реальних запитів, ймовірно, є консервативною оцінкою для сфери особистих фінансів, де специфічні скорочення («prop mgmt fee» замість «property management fee») ще далі від навчальних даних, ніж стандартні абревіатури SEC.

Стеля повноти контексту у 25,95% для E5-Mistral є стимулом до дії: будь-який RAG-конвеєр для Beancount має враховувати велику частку пропущених доказів. Один з висновків полягає в тому, що повторний пошук з високою повнотою (кілька проходів, диверсифіковані формулювання запитів) важливіший за підвищення F1 за один прохід. Інший висновок: нормалізація запитів — відображення скорочень користувача на канонічні назви рахунків перед пошуком — повинна бути явним етапом попередньої обробки, а не залишатися на розсуд моделі ембедінгів.

Точність композиційної арифметики у 20% навіть з ідеальним контекстом — це окремий сигнал: для обчислювальних завдань у Beancount вузьким місцем генерації є міркування, а не пошук. Делегування в стилі PAL (генерування коду Python для обчислень замість тексту) залишається правильним рішенням для числових завдань, незалежно від того, наскільки хорошим стане пошук.

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

• Fin-RATE (arXiv:2602.07294) — споріднений бенчмарк для відстеження за кілька періодів у звітах SEC; точність падає на 18,60% у часових завданнях, що безпосередньо стосується проблеми багаторічних облікових книг Beancount.
• IRCoT (arXiv:2212.10509, ACL 2023) — чергування пошуку з міркуваннями ланцюжком думок (chain-of-thought); багатопрохідна структура пошуку безпосередньо вирішує проблему низької повноти за один прохід, яку виявив FinDER.
• Розширення запитів за допомогою LLM для специфічного пошуку в домені — поки що жодна стаття з бенчмарками не висвітлює це достатньо добре, але розрив у скороченнях FinDER робить це першочерговим пріоритетом для досліджень; пошук за запитами «HyDE financial domain» та «query expansion SEC filings 2025» є правильним початком.