FinanceBench: Чому RAG на основі векторних сховищ зазнає невдачі на реальних фінансових документах

FinanceBench з’являється в той момент, коли кожен постачальник корпоративного ШІ стверджує, що його система може «відповідати на запитання на основі ваших фінансових документів». Ця стаття від Patronus AI піддає ці заяви жорсткому випробуванню, використовуючи реальні звіти SEC та ретельно підібрані запитання відкритого типу. Результати будуть невтішними для всіх, хто розробляє ШІ для фінансів.

Про дослідження

Іслам та ін. представляють FinanceBench: A New Benchmark for Financial Question Answering (arXiv:2311.11944), набір тестів із 10 231 запитання про публічні компанії, складених на основі реальних звітів SEC — річних звітів 10-K, квартальних звітів 10-Q, поточних звітів 8-K та стенограм виступів керівництва. На відміну від попередніх наборів даних для фінансових QA (FinQA, TAT-QA), які пропонують попередньо витягнуті таблиці та фрагменти, FinanceBench вимагає від системи пошуку доказів у повних документах перед наданням відповіді. Це реалістичний сценарій. Запитання розроблені так, щоб бути фактично однозначними і, за словами авторів, є «мінімальним стандартом продуктивності».

Команда оцінила 16 конфігурацій, що включали GPT-4-Turbo, Llama2 та Claude2, за чотирма стратегіями пошуку: closed-book (без пошуку), спільне векторне сховище, векторне сховище для кожного документа та промпти з довгим контекстом, що подають повну відповідну сторінку. Людські анотатори вручну перевірили всі 2400 відповідей у 150 випадках із відкритим кодом.

Ключові ідеї

• Пошук не є «вузьким місцем». GPT-4-Turbo, отримуючи фрагмент-оракул — точну сторінку, що містить відповідь — все одно досягає лише 85% точності. Промпти з довгим контекстом (автоматична подача потрібної сторінки) дають 79%. Ідеальний пошук додає лише шість пунктів.
• RAG на основі векторних сховищ — це справжня проблема. GPT-4-Turbo з векторним сховищем для кожного документа: 50% правильних відповідей, 39% відмов. Зі спільним векторним сховищем для різних компаній: 19% правильно, 68% відмов. Заголовок про «81% невдач» походить саме від налаштування зі спільним сховищем — конфігурації, яку насправді використовує більшість корпоративних демо-версій.
• Моделі помиляються по-різному. Llama2 агресивно галюцинує (54–70% неправильно); GPT-4-Turbo відмовляється відповідати (39–68% відмов замість помилок). Обидва режими відмови неприйнятні у виробництві, але вони не є еквівалентними ризиками.
• 66% запитань потребують чисельних міркувань. Темпи зростання, маржа, річні зміни. Саме тут моделі помиляються найчастіше — помилки в розрахунках, плутанина в одиницях виміру, помилки в знаках.
• Довгий контекст майже рятує ситуацію. Claude2 з довгим контекстом: 76% правильно. GPT-4-Turbo з довгим контекстом: 79%. Це найкращі практичні показники, досягнуті шляхом пропуску етапу пошуку та прямої подачі всієї відповідної сторінки.
• Навіть «оракул» дає збої. З ідеальними доказами стеля становить 85%, а не 100%. П'ятнадцять відсотків невдач — це чисті помилки в міркуваннях без участі компонента пошуку.

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

Дизайн бенчмарку є ґрунтовним. Вимога використовувати реальні документи замість попередньо витягнутих фрагментів — це правильний методологічний вибір; він тестує те, що насправді має значення при впровадженні. Ручна оцінка 2400 відповідей є дорогою та викликає довіру.

Що мені здається менш переконливим, так це побудова рейтингів на основі n=150. Різниця між Claude2 з довгим контекстом (76%) та GPT-4-Turbo з довгим контекстом (79%) статистично незначуща при такому обсязі вибірки, проте стаття подає це як рейтинг. Повний бенчмарк на 10 231 запитання існує, але не має публічних оцінок, що обмежує незалежне відтворення.

Результат з «оракулом» є найважливішим і водночас найменш проаналізованим висновком. Якщо моделі помиляються у 15% випадків, маючи на руках правильну сторінку, то проблема полягає в міркуваннях та арифметиці, а не в пошуку. Автори зазначають використання інструментів-калькуляторів та ланцюжків думок (chain-of-thought) як напрямок для майбутньої роботи — ці експерименти мали б стати центром статті, а не приміткою.

Бенчмарк також визнає, що він націлений на «мінімальну продуктивність»: запитання по одному документу з однозначними відповідями. Міждокументні міркування, багаторічні тренди та порівняння компаній виключені. Статті, що цитують показник 79% для довгого контексту, рідко згадують про це застереження.

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

Сценарій використання Beancount зі зворотним записом (write-back) майже напряму відображає режими відмов FinanceBench. Агент, який знаходить запис транзакції та перевіряє, чи збігається сума з банківською випискою, виконує те саме завдання «пошук, а потім арифметика», яке вимірює цей бенчмарк. Стеля оракула — 85% навіть за ідеального контексту — є вирішальним обмеженням дизайну: навіть якщо агент знайде правильний запис у гроссбуху, існує реальна ймовірність того, що він неправильно проведе порівняння, переплутає знак або неправильно прочитає одиниці виміру.

Розподіл помилок Llama2/GPT-4 має значення для архітектури агентів. Відмову можна виправити (перенаправити на перевірку людині); галюцинований збіг, занесений до книги обліку, — ні. Це свідчить на користь консервативної поведінки з відмовами, а не впевнених галюцинацій, навіть ціною нижчого видимого показника успіху.

Перевага довгого контексту (79% проти 50%) є практично розчаровуючою для застосунків із книгами обліку. Багаторічні файли Beancount занадто великі, щоб подавати їх повністю. Вирішення задачі пошуку в щільних числових документах — а не просто пошуку тексту — залишається відкритою проблемою.

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

• FinQA: A Dataset of Numerical Reasoning over Financial Data (Chen et al., EMNLP 2021, arXiv:2109.00122) — попередник бенчмарку, який FinanceBench явно вдосконалює; корисно для розуміння того, що в цій галузі вважалося правильним до того, як з’явилася вимога пошуку в реальних документах.
• DocFinQA: A Long-Context Financial Reasoning Dataset (Reddy et al., ACL 2024) — розширює FinanceBench складнішими багатокроковими запитаннями, що потребують аналізу різних розділів одного звіту.
• PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) — перекладає арифметику на інтерпретатор Python, безпосередньо вирішуючи проблему 66% запитань FinanceBench, які не проходять через чисельні міркування.