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

FinanceBench появляется в момент, когда каждый вендор корпоративного ИИ заявляет, что его система может «отвечать на вопросы по вашим финансовым документам». Эта статья от Patronus AI подвергает такие заявления жесткой проверке, используя реальные отчеты SEC и тщательно отобранные вопросы открытого типа. Результаты окажутся неутешительными для всех, кто создает ИИ для финансов.

О статье

Ислам и др. представляют FinanceBench: новый бенчмарк для ответов на финансовые вопросы (arXiv:2311.11944) — набор тестов из 10 231 вопроса о публичных компаниях, составленный на основе реальной отчетности SEC: годовых отчетов (10-K), квартальных отчетов (10-Q), текущих отчетов (8-K) и стенограмм звонков о доходах. В отличие от ранних наборов данных (FinQA, TAT-QA), где таблицы и фрагменты текста уже извлечены, FinanceBench требует от системы самостоятельно найти доказательства в полных документах перед ответом. Это реалистичный сценарий. Вопросы сформулированы так, чтобы ответы на них были однозначными, и, по словам авторов, они представляют собой «минимальный стандарт производительности».

Команда оценила 16 конфигураций, включая GPT-4-Turbo, Llama2 и Claude2, используя четыре стратегии поиска: закрытая книга (без поиска), общее векторное хранилище, векторное хранилище для каждого документа и промпты с длинным контекстом, содержащие всю релевантную страницу. Живые аннотаторы вручную проверили все 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% случаев, имея на руках нужную страницу, проблема заключается в рассуждениях и арифметике, а не в поиске. Статья упоминает использование калькуляторов и цепочек рассуждений как направление для будущих работ — именно эти эксперименты должны были стать центром исследования, а не сноской.

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

Почему это важно для финансового ИИ

Сценарий использования 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 более сложными вопросами, требующими сопоставления данных из разных разделов одного отчета.
• PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) — передает арифметические вычисления интерпретатору Python, напрямую решая проблему 66% вопросов FinanceBench, в которых модели не справляются с числами.