Fin-RATE: Как LLM терпят неудачу в кросс-периодном и кросс-субъектном финансовом анализе

Траектория развития бенчмарков финансовых LLM продолжает расширяться, и Fin-RATE — самый наглядный пример того, что происходит, когда мы просим модели делать то, что делают реальные аналитики: отслеживать компанию не только в рамках одного отчета, но и за несколько периодов, а также в сравнении с конкурентами по отрасли.

Исследование

Fin-RATE, опубликованный в феврале 2026 года Идуном Цзяном, Цзюньжуном Чэнем и их коллегами из Йеля и партнерских институтов, представляет собой бенчмарк, созданный на основе 2 472 отчетов SEC 43 компаний из 36 отраслей за период 2020–2025 гг. Бенчмарк включает 7 500 отобранных экспертами пар вопросов и ответов, разделенных на три типа задач, отражающих рабочие процессы профессиональных аналитиков: DR-QA (детализация и рассуждение в рамках одного отчета), EC-QA (кросс-субъектное сравнение двух компаний по общей теме) и LT-QA (лонгитюдное отслеживание одной и той же фирмы за разные отчетные периоды). Каждый тип задачи содержит 2 500 вопросов. Оценка охватывает 17 LLM — проприетарные модели, включая GPT-4.1 и GPT-5, открытые модели общего назначения, такие как DeepSeek-V3 и Llama-3.3-70B, и специализированные финансовые модели, такие как Fin-R1, Fino1-14B, FinanceConnect-13B и TouchstoneGPT-7B. Для оценки используется унифицированный фреймворк «LLM в качестве судьи» с тремя независимыми судьями (GPT-5, DeepSeek-V3.2, Qwen3-235B), которые оценивают каждый ответ на правильность и по пяти аналитическим измерениям.

Ключевые идеи

• Производительность падает по мере роста сложности задач: точность снижается в среднем на 18,60% при переходе от DR-QA по одному документу к лонгитюдному LT-QA, и на 14,35% от DR-QA к кросс-субъектному EC-QA для всех 17 моделей.
• GPT-5 с веб-поиском показывает лучшие результаты, однако его пиковая точность составляет всего 43–44% во всех трех типах задач — удручающий показатель для бенчмарка, призванного имитировать реальную работу аналитиков.
• Fin-R1, специализированная финансовая модель с функциями рассуждения, достигает 57,48% в DR-QA, но обваливается до 3,32% в EC-QA — падение на 54 пункта, что значительно превышает деградацию любой модели общего назначения.
• В условиях RAG (генерация с дополненным поиском) производительность всех моделей падает ниже 27% по сравнению с результатами на «золотом контексте» (до 57,48%); конвейер поиска, а не сама LLM, является критическим узким местом.
• Работа вводит таксономию ошибок из 13 типов, разделенных на четыре категории: галлюцинации и противоречия, финансово-специфические числовые и семантические ошибки, ошибки понимания запроса/контекста и сбои на уровне поиска. В задаче EC-QA с использованием RAG на «отсутствие доказательств» (Missing Evidence) приходится 75,44% ошибок.
• Специализированные финансовые модели демонстрируют систематически более высокий уровень галлюцинаций в сложных задачах по сравнению с моделями общего назначения, несмотря на лучшее владение финансовой терминологией.

Что подтверждается, а что — нет

Трехкомпонентная структура задач спроектирована действительно грамотно. Большинство финансовых бенчмарков (FinQA, TAT-QA, FinanceBench) рассматривают QA как задачу по одному документу. Fin-RATE одним из первых явно моделирует кросс-субъектное сравнение и лонгитюдное отслеживание как первостепенные задачи, и результаты обнажают фундаментальный пробел: современные LLM сносно справляются с изолированными ответами по отчетности, но разваливаются, как только им нужно синтезировать данные из разных документов, компаний или временных периодов.

Провал Fin-R1 — самый поразительный результат работы, и я считаю, что ему уделяется недостаточно внимания. Финансово-ориентированная модель, преуспевающая в извлечении данных из одного документа, судя по всему, «загнала себя в угол» при обучении: она выучила шаблоны ответов внутри одного документа, но не стратегии рассуждения для сопоставления субъектов и периодов. Это конкретное предостережение против узкоспециализированной тонкой настройки (fine-tuning) без явного контроля над рассуждениями по нескольким документам. Модель, вероятно, переобучилась на поверхностном паттерне «найти число в отчете» и не имеет путей обобщения для задачи «сравнить это число с эквивалентным числом в другом отчете другой компании».

При этом есть методологические вопросы, заслуживающие внимания. GPT-5 одновременно является одной из оцениваемых моделей и одним из трех судей. Авторы используют трех судей для уменьшения индивидуальной предвзятости, что помогает, но совпадение судьи и самой сильной оцениваемой модели вызывает дискомфорт. В работе сообщается о высоком согласии между судьями, но отдельно не количественно не оценивается, какую долю своих собственных ответов оценил GPT-5 и отличаются ли его оценки систематически от оценок двух других судей. Любая предвзятость при самооценке может завышать итоговый результат лучшей модели в исследовании.

Выборка из 43 компаний также невелика. Охват типов отчетности похвально широк (10-K, 10-Q, 8-K, 6-K, DEF 14A, а также серии S и SC), но одни и те же 43 компании фигурируют во всех задачах. Модели, видевшие отчетность этих компаний на этапе предварительного обучения, имеют неучтенное преимущество, а в статье отсутствует анализ на предмет загрязнения данных (contamination analysis).

Вывод о роли поиска (retrieval) важен, но неполон. Авторы фиксируют, что производительность RAG падает примерно на 30 пунктов по сравнению с идеальным контекстом из-за ошибок поиска. Но они тестируют только одну конфигурацию RAG — ошибка поиска рассматривается как диагноз, а не как переменная для систематического изучения. Последующая работа, тестирующая различные архитектуры поиска на базе Fin-RATE, была бы гораздо более полезной для практического применения.

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

Аудит журналов Beancount требует именно тех двух возможностей, которые, как показывает Fin-RATE, работают плохо: лонгитюдное отслеживание (как менялся этот счет в течение финансовых лет?) и кросс-субъектное сравнение (согласуется ли баланс этой дочерней компании с консолидированным отчетом?). Падение точности на 18,60% при временном отслеживании — это конкретная цифра, которая должна скорректировать ожидания от любого агента Beancount, рассуждающего о нескольких отчетных периодах. Если передовые модели терпят неудачу на уровне 43% при лонгитюдном анализе SEC на идеальном контексте, то агент Beancount, работающий с многолетней историей проводок, должен проектироваться с явным акцентом на поиск, временную привязку и эскалацию на человека, а не на сквозной (end-to-end) вывод LLM.

Вывод о доминирующей роли поиска важнее всего для определения приоритетов при проектировании систем. Если производительность на идеальном контексте почти вдвое выше производительности RAG, то правильные инвестиции должны быть направлены в лучшее разбиение на фрагменты (chunking), выбор пассажей и поиск, а не в более мощную базовую LLM. Это перекликается с тем, что DocFinQA обнаружил для длинных отчетов SEC: узким местом является конвейер вокруг модели.

Предупреждение по поводу Fin-R1 также напрямую относится к использованию Beancount. Тонкая настройка на синтаксисе Beancount DSL и паттернах транзакций может создать модель, которая хорошо справляется с генерацией простых записей, но ломается на сверке нескольких счетов за несколько периодов, что и делает аудит полезным. Специализация без обучения рассуждению по нескольким документам хрупка именно в тех аспектах, которые измеряет Fin-RATE.

Что почитать дальше

• Fin-R1 (arXiv:2503.16252) — чтобы понять, какая настройка обучения привела к столь хрупкой производительности при работе с несколькими документами и входило ли вообще в задачи обучение рассуждению по нескольким документам.
• FinTrace (arXiv:2604.10015) — оценка вызова инструментов LLM на уровне траектории в 34 категориях финансовых задач; дополняет статичный взгляд Fin-RATE диагностикой на уровне процесса: где модели вызывают нужные инструменты, но не могут сделать выводы на основе результатов.
• OpenHands (arXiv:2407.16741) — открытая платформа агентов, лежащая в основе оценок TheAgentCompany; понимание ее архитектуры проясняет, какие базовые возможности агентов были доступны, а какие пробелы связаны со сложностью задач, а не с ограничениями платформы.