FinanceBench: Защо RAG с векторно хранилище се проваля при реални финансови документи

FinanceBench се появява в момент, в който всеки доставчик на корпоративен ИИ твърди, че системата му може да „отговаря на въпроси от вашите финансови документи“. Тази научна публикация от Patronus AI подлага тези твърдения на сериозно изпитание, използвайки реални отчети към SEC и внимателно подбрани въпроси от типа „отворена книга“. Резултатите са неприятно четиво за всеки, който изгражда финансов ИИ.

Документът

Islam и др. представят FinanceBench: Нов бенчмарк за финансови въпроси и отговори (arXiv:2311.11944) – тестов пакет от 10 231 въпроса за публично търгувани компании, извлечени от реални SEC документи: годишни отчети (10-K), тримесечни отчети (10-Q), текущи отчети (8-K) и транскрипти от срещи за приходите. За разлика от по-ранните масиви от данни за финансови въпроси и отговори (FinQA, TAT-QA), които предоставят предварително извлечени таблици и пасажи, FinanceBench изисква от системата сама да намери доказателствата в пълните документи, преди да отговори. Това е реалистичната обстановка. Въпросите са проектирани да бъдат фактологично недвусмислени и, по думите на авторите, представляват „минимален стандарт за производителност“.

Екипът оцени 16 конфигурации, включващи GPT-4-Turbo, Llama2 и Claude2, чрез четири стратегии за извличане: затворена книга (без извличане), споделено векторно хранилище, векторно хранилище за отделен документ и промпти с дълъг контекст, подаващи пълната релевантна страница. Човешки анотатори ръчно прегледаха всички 2 400 отговора в 150 случая с отворен код.

Основни идеи

• Извличането не е тясното място. GPT-4-Turbo, на който е предоставен „oracle“ пасажът — точната страница, съдържаща отговора — все още достига само 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%. Петнадесет процента от неуспехите са чисти провали в логическото разсъждение без компонент на извличане.

Какво издържа проверката — и какво не

Дизайнът на бенчмарка е солиден. Настояването за използване на реални документи вместо предварително извлечени фрагменти е правилният методологичен избор — той тества това, което всъщност има значение при внедряване. Ръчната оценка на 2 400 отговора е скъпа и вдъхва доверие.

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

Резултатът от „оракула“ е едновременно най-важната и най-малко анализирана констатация. Ако моделите се провалят в 15% от случаите с правилната страница в ръка, проблемът е в разсъждението и аритметиката, а не в извличането. Документът посочва инструментите за калкулатор и „веригата от мисли“ (chain-of-thought) като бъдеща работа — тези експерименти трябваше да бъдат центърът на това изследване, а не просто бележка под линия.

Бенчмаркът също така признава, че е насочен към „минимална производителност“: въпроси към един документ с недвусмислени отговори. Разсъжденията върху няколко документа, многогодишните тенденции и сравненията между компании са изключени. Публикациите, цитиращи числото 79% за дълъг контекст, рядко ще споменават тази уговорка.

Защо това е важно за финансовия ИИ

Случаят на употреба с обратно вписване (write-back) в Beancount съответства почти директно на режимите на отказ на 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 с по-трудни „multi-hop“ въпроси, изискващи разсъждения в различни раздели на един и същ отчет.
• PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) — прехвърля аритметиката на Python интерпретатор, директно адресирайки тези 66% от въпросите във FinanceBench, които се провалят при численото разсъждение.