Преминете към основното съдържание

FinDER: Реални запитвания от анализатори разкриват 74% пропуск в пълнотата при финансовия RAG

· 7 минути четене
Mike Thrift
Mike Thrift
Marketing Manager

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

Документът

2026-06-28-finder-financial-dataset-rag-evaluation

Chanyeol Choi, Jihoon Kwon и техните колеги от фирма за финансов AI представят набор от данни от 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 Workshop on Advances in Financial AI и по-късно се появи на ICAIF 2025.

Ключови идеи

  • Пълнотата на извличането е шокиращо ниска навсякъде: 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%; с идеален оракулски контекст те скачат до 60–68%. Тази разлика от 35 пункта между реалистични и оракулски условия е по-голяма от разликата между моделите с отворен код и водещите модели (frontier models).
  • Композиционната аритметика се проваля дори при добро извличане: Задачите за многостъпкови изчисления (композиционни запитвания) достигат само ~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). Това корелира със структурата на запитването — оповестяването на рискове използва естествен език, докато финансовите таблици използват гъста цифрова нотация.

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

Основният принос е солиден: това е реално разпределение на запитвания от работещи анализатори и проблемът със съкращенията е автентичен. Всеки бенчмарк, изграден от Wikipedia или краудсорсинг в стил FinQA, пропуска това. Тристепенната структура на оценяване — без контекст, реалистично извличане, оракулски контекст — е правилният дизайн; тя ясно отделя качеството на извличане от качеството на разсъждение и показва остатъчния пропуск в генерирането (все още ~32–34% неуспех дори при перфектен контекст за качествени въпроси).

Най-слабата страна на документа е възпроизводимостта. Към момента на публикуване наборът от данни не беше публично достъпен — авторите заявяват, че „планират да го пуснат публично по-късно“. Това е сериозен проблем за документ от уъркшоп, представящ се за стандарт за оценка. Бенчмаркове, които не са публикувани, не са бенчмаркове; те са казуси. Оттогава той се появи на ICAIF 2025, така че пускането може да е последвало, но версията в arXiv не потвърждава това.

Оценката на извличането също използва само четири едноетапни модела (BM25, GTE, mE5, E5-Mistral). Липсва хибридно извличане, разширяване на запитванията, HyDE или стъпка за пренаписване, насочена конкретно към проблема със съкращенията. Като се има предвид, че авторите са дефинирали точно пропуска при съкращенията, изненадващо е, че не тестват очевидното решение: разширяване на запитването („GOOGL“ → „Alphabet Inc.“) преди извличане. Този експеримент отсъства.

Резултатите от генерирането заслужават по-внимателен прочит. Производителността от ~9–10% без контекст не е полезна долна граница — тя е практически нулева — но таванът от 60–68% при оракулски контекст е по-информативен, отколкото изглежда. Дори с правилния пасаж в ръка, най-добрите модели се провалят в около една трета от качествените въпроси и четири пети от композиционната аритметика. Този таван е важен: той означава, че само извличането не може да реши проблема.

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

Разпределението на запитванията във FinDER съответства добре на това как потребителите на Beancount всъщност взаимодействат с агент на счетоводната книга. Потребител, който поддържа сметките си от години, ще въвежда съкратени, контекстуални запитвания — „AMZN card Q3 reimb?“ вместо „Какви са възстановяванията по кредитната карта Amazon през третото тримесечие?“. Стандартните модели за вграждане ще се провалят при извличането на правилните записи, защото са обучени на чист текст на естествен език. Спадът на прецизността от 8,2 пункта от чисти към реални запитвания вероятно е консервативна оценка за домейна на личните счетоводни книги, където специфичните съкращения („prop mgmt fee“ за „property management fee“) са още по-далеч от данните за обучение, отколкото стандартните за SEC съкращения.

Таванът от 25,95% пълнота на контекста при E5-Mistral е принудителен фактор: всеки Beancount RAG конвейер трябва да предвиди голяма част от пропуснатите доказателства. Един от изводите е, че повторното извличане с висока пълнота (множество преминавания, диверсифицирани формулировки на запитванията) е по-важно от повишаването на F1 при еднократно преминаване. Друг извод е, че нормализирането на запитванията — картографиране на потребителските съкращения към канонични имена на сметки преди извличане — трябва да бъде изрична стъпка на предварителна обработка, а не да се оставя на модела за вграждане.

Точността от 20% при композиционната аритметика дори с оракулски контекст е отделен сигнал: за задачите за изчисление в Beancount, тясното място в генерирането е разсъждението, а не извличането. Делегирането в стил PAL (генериране на Python аритметика вместо изчисление в свободен текст) остава правилният отговор за числови задачи, независимо колко добро става извличането.

Какво да прочетете след това

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