О статье​

Джао, Цзинь, Ли и Гао из Пекинского университета представляют FinRAGBench-V — двуязычный бенчмарк, составленный из реальных финансовых документов: аналитических отчетов, финансовой отчетности, проспектов эмиссии, академических статей, журналов и новостей. Корпус для поиска внушителен — 60 780 страниц на китайском и 51 219 страниц на английском языке (примерно по 1100 документов на язык) — и дополнен 1394 парами вопросов и ответов, размеченными вручную. Вопросы охватывают семь категорий: текстовый логический вывод, извлечение данных из графиков и таблиц, численные расчеты, запросы, чувствительные ко времени, и многостраничные рассуждения. Помимо самого набора данных, основным вкладом статьи является RGenCite — базовая система, которая генерирует ответы вместе с визуальными цитатами на уровне пикселей в виде координат ограничивающих рамок (bounding boxes), отмечающих конкретные области документа, подтверждающие каждое утверждение.

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

• Мультимодальный поиск превосходит текстовый с огромным отрывом: ColQwen2, визуально-языковая поисковая модель на основе эмбеддингов изображений страниц, достигает Recall@10 в 90,13% (китайский) и 85,86% (английский). Лучшие текстовые поисковики, BM25 и BGE-M3, показывают максимум около 42,71%. Этот разрыв — не статистическая погрешность.
• Точность генерации низка даже для передовых моделей: GPT-4o на английском языке достигает точности 43,41% (ROUGE 24,66); o4-mini на китайском — 58,13% (ROUGE 38,55). Это топовые проприетарные модели с качественно настроенным поиском.
• Цитирование на уровне страниц работает, на уровне блоков — нет: полнота на уровне страниц составляет 75–93% у лучших моделей. Полнота на уровне блоков — определение конкретной ячейки таблицы или области графика, обосновывающей утверждение — падает до 20–61%. Это критический пробел для обеспечения проверяемости (auditability).
• Численные рассуждения и многостраничный вывод первыми ломают модели: вопросы, требующие вычислений по нескольким страницам или временным интервалам, — это те области, где точность падает наиболее резко во всех протестированных системах.
• Проприетарные модели существенно превосходят открытые аналоги: разрыв между закрытыми API и открытым ПО здесь больше, чем в большинстве бенчмарков NLP. Это говорит о том, что визуальные финансовые рассуждения пока остаются нерешенной задачей для открытых моделей.
• Автоматическая оценка цитат несовершенна: оценщик цитирования на основе обрезки изображений достигает коэффициента корреляции Пирсона r = 0,68 в сравнении с человеческими суждениями — это приемлемо, но недостаточно надежно, чтобы доверять результатам без выборочной проверки.

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

Вывод о преимуществе поиска — самый убедительный результат статьи. Разрыв почти в 50 процентных пунктов между мультимодальными и текстовыми поисковиками на корпусе из 60 тыс.+ страниц слишком велик, чтобы его игнорировать. Когда вы применяете OCR к финансовому документу перед индексацией, вы разрушаете сигналы структурной разметки — в какой колонке находится число, относится ли подпись к интерпретации таблицы. Как выяснилось, это имеет колоссальное значение для качества поиска.

Показатели генерации честны, но их трудно интерпретировать изолированно. Авторы не проводят абляционный анализ того, какая часть разрыва в точности обусловлена ошибками поиска, а какая — сбоями генерации. Учитывая, что Recall@10 для английского языка уже составляет 85,86%, значительная часть неудач должна приходиться на этап генерации. Понимание этой разбивки прояснило бы, является ли узким местом мультимодальное рассуждение или нечто более фундаментальное в том, как MLLM работают с финансовым языком.

Оценочный набор из 1394 пар вопрос-ответ невелик для масштабов бенчмарка. При разделении на семь категорий и два языка на некоторые сегменты приходится менее 200 примеров. Статистическая значимость выводов на уровне категорий остается неявной. Это типично для статей по бенчмаркам, но означает, что при желании можно легко сконструировать предвзятые сравнения.

Протокол оценки цитирования — интересный вклад, но коэффициент Пирсона r = 0,68 не позволяет рассматривать автооценку как истину в последней инстанции для обоснования на уровне блоков. Авторы признают это; необходимость разработки более совершенных метрик цитирования прямо обозначена в планах на будущее.

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

Beancount работает с текстовыми файлами журналов, что делает текстовый RAG оправданным для запросов по прошлым транзакциям. Но более широкая задача учета включает документы, которые определенно не являются простым текстом: PDF-выписки из банков, отсканированные инвойсы, изображения чеков, годовые отчеты со встроенными таблицами и графиками. В тот момент, когда агенту Beancount нужно сверить запись в журнале с первоисточником — убедиться, что конкретное начисление соответствует счету в архиве, — он выполняет именно ту задачу, которую тестирует FinRAGBench-V.

Для этого сценария использования важнее всего вывод о цитировании на уровне блоков. Если агент должен обосновать запись в журнале, указав на конкретную позицию в PDF-файле, а лучшая доступная система достигает лишь 20–61% полноты на уровне блоков, это не подходит для полноценного аудита. Любой конвейер Beancount, работающий со сканами документов, требует участия человека до тех пор, пока этот показатель существенно не улучшится.

Разрыв в модальности поиска также является сильным аргументом против чисто текстовых конвейеров обработки документов. Изображение чека несет информацию о разметке — поля сумм, названия поставщиков, позиции товаров, — которую OCR уничтожает. Именно эта структурная информация позволяет отличить итоговую сумму от суммы налога, и FinRAGBench-V показывает, что мультимодальные поисковики используют её так, как текстовые не могут.

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

• ColPali: Efficient Document Retrieval with Vision Language Models — предшественник ColQwen2, заложивший подход к эмбеддингам визуальных страниц, на котором построен лучший поисковик FinRAGBench-V [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding — решает задачи визуального QA по нескольким документам с помощью гибкой структуры, поддерживающей простые и сложные визуальные рассуждения на разных страницах [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance — сопутствующий бенчмарк 2025 года, оценивающий чувствительность к времени в финансовом мультимодальном RAG, который напрямую дополняет категорию вопросов о времени в FinRAGBench-V [arXiv:2503.05185]

О статье​

EnterpriseArena — это 132-месячная (11-летняя) симуляция распределения ресурсов на уровне финансового директора (CFO). Каждый шаг представляет один месяц. Агент получает частичные данные о финансовых показателях фирмы, анонимизированные бизнес-документы и макроэкономические сигналы, полученные из данных FRED, CBOE и S&P Global. У него есть бюджет в 20 вызовов инструментов в месяц, распределенных по четырем операциям: проверка остатка денежных средств, обзор финансовых записей, анализ рыночных условий и прогнозирование денежных потоков. Агент должен выбрать одно из трех действий: закрыть книги (сверка), запросить финансирование (акционерный капитал или долг со случайным результатом) или пропустить ход. Основное ограничение заключается в том, что остаток денежных средств компании должен оставаться положительным на каждом этапе; нарушение этого правила завершает эпизод с нулевым результатом. При условии выживания агент максимизирует итоговую оценку предприятия по формуле Rev_T × 5 + Cash_T − 5 000 × N_tools, которая явно штрафует за избыточное использование инструментов.

Было оценено одиннадцать LLM, включая Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B и Qwen3.5-9B, наряду с базовым уровнем эксперта-человека, подтвержденным двумя профессионалами в области финансов с опытом работы 8 и 14 лет соответственно.

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

• Показатели выживаемости сильно различаются между моделями: Qwen3.5-9B выживает в 80% случаев, Gemini-3.1-Pro — в 50%, Claude-Haiku-4.5 и GLM-5 — по 20% каждый, а GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B и Mixtral-8x7B — 0%. Средний показатель для LLM составляет 26%.
• Более крупные модели не всегда превосходят меньшие: Qwen3.5-9B (9 млрд параметров, 80% выживаемости, конечная оценка $78,8 млн) решительно побеждает Qwen3.5-397B (397 млрд параметров, 20% выживаемости) и GPT-5.4 (0% выживаемости).
• Разрыв с людьми огромен: базовый уровень человека достигает 100% выживаемости и конечной стоимости в $152,2 млн ± $29,6 млн; средний показатель LLM составляет $28,2 млн при 26% выживаемости.
• Закрытие книг — критическое узкое место: эксперты-люди закрывают книги (проводят сверку) на 94,3% временных этапов; LLM в среднем делают это в 19,3% случаев. Именно это действие формирует достоверную финансовую отчетность и позволяет принимать рациональные последующие решения.
• Сбор информации без действий смертелен: Qwen3.5-397B активно использует инструменты анализа рынка и прогнозирования на протяжении всей симуляции, но почти никогда не закрывает книги (частота 0,0%) и почти никогда не запрашивает финансирование, погибая от истощения денежных средств, несмотря на «знание» происходящего.
• Штраф за бюджет инструментов имеет значение: формула оценки активно наказывает агентов, которые компульсивно проверяют данные вместо того, чтобы действовать — ограничение, отражающее реальные альтернативные издержки.

Что выдерживает критику, а что нет​

Дизайн с двойной целью — выживание как жесткое ограничение плюс итоговая оценка — является одним из самых сильных решений в последних бенчмарках агентов. Это отражает то, как на самом деле работают финансовые директора: вы не можете оптимизировать рост, если у вас закончились деньги. Анонимизация календарных дат и названий компаний не позволяет моделям подбирать шаблоны на основе заученных исторических результатов, что является подлинным методологическим улучшением по сравнению с финансовыми бенчмарками, использующими реальные тикеры и даты.

Таксономия режимов отказа, которую авторы идентифицируют с помощью тематических исследований, заслуживает доверия: GPT-5.4 достигает 99,1% процента пропусков (что означает бездействие почти на каждом этапе), в то время как Qwen3.5-397B ошибочно принимает анализ за действие. Это поведенчески различные режимы отказа, требующие разных методов исправления.

В чем я менее уверен: стохастическая макросреда использует гауссов шум для аппроксимации рыночных шоков, что, как признают сами авторы, не может воспроизвести события типа «черный лебедь» или иррациональность людей. Бюджет в 20 вызовов инструментов в месяц также выглядит несколько произвольным — реальные финансовые директора не сталкиваются с подобным ограничением частоты запросов к собственной памяти, что ставит вопрос о том, измеряет ли бенчмарк долгосрочное финансовое суждение или нечто более близкое к «RAG в условиях нехватки ресурсов». Структура с одним агентом — еще одно явное ограничение, названное авторами: реальные CFO работают в иерархии контролеров, аналитиков FP&A и казначейских групп, и в статье не делается попыток симулировать это.

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

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

Действие по закрытию книг в EnterpriseArena — это, по сути, утверждение balance в Beancount и этап сверки реестров: момент, когда агент фиксирует достоверное представление о финансовом состоянии перед действием. Тот факт, что LLM пропускают это в 80% случаев, напрямую связан с проблемой безопасности обратной записи: агент, избегающий сверки перед действием, — это агент, действующий на основе устаревшего или галлюцинированного состояния. Для автоматизации Beancount это означает, что этап сверки должен быть обязательным и проверяемым — а не опциональным — в любом цикле работы агента.

132-месячный горизонт также напрямую аналогичен многолетнему управлению реестрами. Тот факт, что устойчивая ситуационная осведомленность со временем деградирует, — это та же деградация, которую мы ожидаем от агента Beancount, управляющего пятилетней историей транзакций: даже если у агента есть все данные в контексте, он может не действовать согласованно на 60-м месяце. Это говорит о том, что периодические принудительные контрольные точки сверки — а не просто реактивные запросы — необходимы в долгоживущих сессиях агентов Beancount.

Ловушка сбора информации, в которую попадает Qwen3.5-397B, является полезным предупреждением для проектировщиков: агенты, оснащенные множеством инструментов поиска, могут предпочитать поиск принятию обязательств, особенно когда цена неверного действия (повреждение реестра) высока. Ограничения бюджета инструментов, подобные тем, что используются в EnterpriseArena, могут помочь обеспечить дисциплину действий в агентах обратной записи Beancount.

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

• EcoGym (arXiv:2602.09514) — дополнительный долгосрочный экономический бенчмарк в средах Vending, Freelance и Operation на протяжении 1000+ шагов; ни одна модель не доминирует во всех трех, что позволяет предположить, что режимы отказа в EnterpriseArena не являются специфичными для одной конструкции бенчмарка.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, доклады ICLR 2025) — переосмысливает проектирование рабочих процессов как поиск в пространстве кода с использованием MCTS и обратной связи от LLM; если EnterpriseArena показывает, что созданное вручную поведение агентов терпит неудачу, AFlow — очевидный следующий шаг для автоматического поиска лучших конвейеров.
• ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — основополагающая база для обучения и оценки использования инструментов; понимание того, как обучается поведение вызова инструментов в ToolLLM, проясняет, является ли отказ от действий в EnterpriseArena проблемой обучения или проблемой промптинга.

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

Пейцзе Юй, Вэй Лю, Ифань Ян и их коллеги из Alibaba представляют WildToolBench (arXiv:2604.06185) — бенчмарк, состоящий из 256 сценариев многоходовых диалогов с 1024 задачами, взятыми из подлинных паттернов поведения пользователей и основанными на ~1600 публичных API. Основной аргумент авторов заключается в том, что существующие бенчмарки близки к насыщению не из-за совершенства моделей, а из-за искусственности задач. Реальные пользователи объединяют запросы, опускают контекст, которым они делились два шага назад, и переключаются между вопросом к инструменту, светской беседой и просьбой о пояснении — иногда в рамках одного сообщения. WildToolBench формализует эти режимы отказа в три структурированные категории проблем и измеряет как точность на уровне задач, так и гораздо более строгую точность на уровне сессии, которая требует успешного выполнения всех четырех задач в диалоге.

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

• Точность сессии падает до однозначных чисел для большинства моделей: Gemini-2.0-Flash-Thinking лидирует с точностью сессии 14,45%, Claude-4-Sonnet — 12,50%, GPT-4o — 11,72%. Успешное выполнение всех задач в четырехходовой сессии настолько сложно, что даже 60% точности на уровне отдельных задач превращаются в менее чем 15% точности сессии — своего рода «налог» совокупной вероятности на каждое взаимодействие.
• Композиционная оркестрация — самый сложный барьер: Смешанные последовательно-параллельные топологии инструментов ограничивают топовые модели точностью в 25% на задачу, по сравнению с 54–62% для чисто параллельных или последовательных цепочек. Когда задача требует параллельного разветвления с последующим последовательным слиянием, проблема координации превышает возможности любой современной модели.
• Скрытые намерения — более значительный разрыв, чем измерялось ранее: WildToolBench гарантирует, что 100% задач включают неявную или межходовую информацию; в BFCL v3 таких задач лишь 15,7%. Задачи с долгосрочными зависимостями — где недостающая информация находится более чем в двух ходах назад — являются самым сложным подтипом, где ни одна модель не преодолевает порог в 50% даже на уровне отдельных задач.
• Переходы между инструкциями накапливают ошибки линейно: Каждое дополнительное переключение политики (задача для инструмента → чат → уточнение → задача для инструмента) снижает точность примерно на 5–15 процентных пунктов. При трех переходах наиболее пострадавшие модели теряют 30 пунктов. Авторы называют это «самообуславливанием» (self-conditioning): предыдущие ответы смещают интерпретацию последующих инструкций моделью таким образом, который трудно исправить в середине сессии.
• Доля оптимальных путей остается ниже 43%: Даже когда модели выполняют задачи правильно, они тратят избыточное количество вызовов API. Claude-4-Sonnet достигает лучшего показателя доли оптимальных путей (Optimal Path Rate) — 42,74%, что означает, что большинство успешных выполнений требуют больше шагов, чем необходимо. Это прямые затраты на задержку (latency) и токены для любой промышленной системы.
• Специализированные модели для работы с инструментами уступают общим флагманским моделям: xLAM-2-70B и ToolACE2-8B демонстрируют частоту ошибок из-за неверных имен функций выше 30%, что хуже показателей GPT-4o или Claude-4-Sonnet. Тонкая настройка на узких корпусах использования инструментов, похоже, создает хрупкость, а не устойчивость при столкновении с реальным пользовательским поведением.

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

Дизайн бенчмарка силен там, где это важнее всего. Разграничение между точностью задач и точностью сессии абсолютно верно: именно накопление ошибок губит реальные внедрения, а большинство предыдущих работ сообщают цифры на уровне задач, которые маскируют эту проблему. Таксономия трех проблем (композиционная оркестрация, скрытые намерения, переходы между инструкциями) хорошо обоснована и подтверждена эмпирически — кривые деградации производительности по типам проблем выглядят реально и впечатляюще.

Слабое место — масштаб. 1024 задачи из 256 сценариев — это достойный исследовательский артефакт, но маловато для лидерборда, призванного отслеживать 57 моделей во времени. Авторы признают это и упоминают автоматизированный конвейер масштабирования в будущих работах. Другая проблема заключается в том, что формулировка «основано на реальных логах» подразумевает много допущений: финальные задачи частично синтетические, сконструированы мультиагентной системой на основе исходных паттернов, а затем проверены людьми. Утверждение обосновано, но данные не являются «дикими» в буквальном смысле — они вдохновлены ими. Это важно для того, насколько буквально стоит воспринимать потолок в 15%; часть разрыва может сократиться, если конвейер генерации вносит искусственную сложность, которую реальные пользователи на самом деле не проявляют.

Я также скептически отношусь к анализу переходов между инструкциями как к архитектурному утверждению. Статья приписывает это фундаментальному ограничению, но несоответствие распределения обучающих данных между целями RLHF и мультимодальными пользовательскими сессиями кажется более простым объяснением. Это устранимая проблема, а не структурная.

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

Три режима отказа почти идеально накладываются на то, как реальные пользователи взаимодействуют с агентом обратной записи Beancount. Пользователь спрашивает: «сколько я потратил на продукты в прошлом месяце, и заодно добавь сегодняшний чек из Whole Foods» — это композиционная задача, объединенная в один ход. Затем следует: «на самом деле там 47,23 доллара, а не 42, я проверил» — это корректировка параметров, требующая от агента отслеживания состояния сессии. Затем они спрашивают: «эта категория верна?» — это запрос на уточнение, и агент не должен повторно выполнять операцию записи, которую он только что завершил. Ограничение в 25% на смешанную оркестрацию и падение на 30 пунктов из-за переходов между инструкциями — это именно те режимы отказа, которые проявятся у бухгалтерского агента, обрабатывающего реальные пользовательские сессии.

Вывод о том, что специализированные модели уступают флагманским, особенно актуален. Если мы рассматриваем возможность тонкой настройки небольшой открытой модели на примерах вызова инструментов Beancount — очевидный ход для снижения затрат — WildToolBench служит прямым предупреждением: специализация может принести в жертву устойчивость к распределению реального пользовательского поведения. Показатель доли оптимальных путей также важен: агент, который использует в два раза больше вызовов API для выполнения задачи, не просто неэффективен; для операций записи в учетную книгу избыточные промежуточные вызовы могут оставить ее в несогласованном состоянии.

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

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — основополагающая структура обучения, которой WildToolBench открыто противопоставляет себя; понимание её синтетического дизайна оценки проясняет, что именно добавляет исполнение в реальном времени.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — наиболее близкая предыдущая работа по реалистичному многоходовому использованию инструментов; сравнение доменов розничной торговли и авиаперевозок τ-bench с охватом публичных API в WildToolBench показывает широту обобщения проблемы.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — если проблема переходов между инструкциями решаема путем автоматического поиска лучших рабочих процессов агентов, а не масштабирования обучающих данных, то AFlow является наиболее перспективным механизмом для этого.

О статье​

Генг, Цай, Ван, Кёппль, Наков и Гуревич исследуют новую литературу по оценке и калибровке уверенности LLM в задачах от тестов с вариантами ответов до генерации открытых текстов и машинного перевода. Основная проблема: LLM могут быть как высокоточными, так и совершенно ненадежными способами, которые трудно отличить извне. Обзор организует пространство решений в две основные ветви: методы «белого ящика», использующие доступ к внутренним состояниям модели, и методы «черного ящика», рассматривающие модель как непрозрачную. Внутри каждой ветви дополнительно различают оценку уверенности и ее апостериорную калибровку.

Статья была опубликована на NAACL 2024 (страницы 6577–6595), пересмотрена в марте 2024 года на основе версии от ноября 2023 года командой из ТУ Дармштадта, MBZUAI и Университета ИИ имени Мухаммеда бен Заида.

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

• Уверенность «белого ящика» через логиты: Самый простой подход использует вероятности на уровне токенов или логарифмическое правдоподобие, нормализованное по длине, в качестве сигнала уверенности. Эти методы работают, но сталкиваются с фундаментальной двусмысленностью: низкая вероятность токена может отражать либо низкую уверенность в фактах, либо просто необычную формулировку — модель может сомневаться в выборе слов, будучи уверенной в лежащем в основе факте.

• Уверенность «черного ящика» на основе согласованности (SelfCheckGPT): Манакул и соавторы (EMNLP 2023) берут несколько выборок ответов и оценивают их взаимную согласованность с помощью BERTScore, NLI или перекрытия n-грамм. Доступ к логитам не требуется. Ключевой вывод: для фактов, которые LLM знает хорошо, повторяющиеся выборки сходятся; для галлюцинированных фактов они расходятся.

• Семантическая энтропия: Фаркуар и соавторы (Nature, 2024) группируют семантически эквивалентные ответы перед вычислением энтропии. LLM может сформулировать «Париж» и «столица Франции» по-разному — обычная энтропия токенов сочтет их расходящимися, семантическая энтропия — нет. Это качественный шаг вперед по сравнению с согласованностью на уровне токенов, который обзор помещает в контекст.

• Вербализованная уверенность не работает: Когда модель просят выдать процент уверенности, она впадает в самоуверенность. Эмпирическая работа (Грут и соавторы, TrustNLP на ACL 2024) показывает, что у GPT-3, GPT-3.5 и Vicuna средняя ожидаемая ошибка калибровки (ECE) превышает 0,377 для вербализованной уверенности, при этом прогнозы группируются в диапазоне 90–100% независимо от реальной точности. Даже GPT-4 — наиболее калиброванная из оцененных моделей — достигает AUROC лишь около 62,7% при использовании вербализованной уверенности для различения правильных и неправильных ответов, что едва выше случайного угадывания.

• Методы калибровки зависят от задачи: Для классификации контекстная калибровка (вычитание априорного смещения классов, оцененного с помощью пустого промпта «[N/A]») и устранение позиционного смещения (PriDE) решают проблему известных систематических искажений. Для генерации калибровка правдоподобия последовательности (SLiC) дообучает модели на ранжированных ответах. Температурное масштабирование — самое простое апостериорное решение — остается конкурентоспособным во многих сценариях.

• Единого бенчмарка не существует: Самое критическое структурное наблюдение обзора: нет ни одного бенчмарка, охватывающего методы оценки уверенности во всех задачах и доменах. Это делает практически невозможным строгое сравнение методов. Область сравнивает теплое с мягким.

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

Таксономия прочна. Различие между «белым ящиком» и «черным ящиком» действительно полезно для проектирования систем, а разбор методов на основе логитов честен в отношении их ограничений — авторы прямо отмечают, что вероятность токена смешивает фактическую уверенность с лексической неопределенностью. Практики часто недооценивают это смешение.

Что в обзоре разочаровывает: он носит в основном описательный характер. Почти нет экспериментальных бенчмарков, сравнивающих методы лицом к лицу, и авторы прямо признают это как ограничение. После прочтения остается четкая карта проектных решений, но нет руководства, какой метод использовать для новой задачи.

Результаты по вербализованной уверенности — AUROC GPT-4 ~62,7% для собственной заявленной уверенности — должны быть базовым знанием для любого, кто внедряет LLM в эксплуатацию. Но это не так. Люди все еще выпускают промпты в духе «оцени свою уверенность по шкале от 1 до 10» и относятся к ответу как к значимому. Это не так.

В обзоре также мало внимания уделено вопросу калибровки через RLHF: делает ли дообучение на отзывах людей модели более или менее калиброванными? Есть свидетельства в обе стороны, и обзор во многом обходит эту тему.

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

ReDAct строит свою систему безопасности на наличии калиброванного сигнала неопределенности от дешевой модели. Обзор ясно дает понять, насколько это сложно на самом деле. Сигналы на основе логитов доступны в условиях «белого ящика», но смешивают лексическую и фактическую неопределенность. Методы на основе согласованности работают в «черном ящике», но требуют нескольких выборок на одно решение — это дорого для высокопроизводительного агента обратной записи Beancount, обрабатывающего пакет записей транзакций.

Самый полезный вывод для Bean Labs: семантическая энтропия группирует семантически эквивалентные ответы перед оценкой согласованности, что критически важно для записей в реестре, где модель может выразить одни и те же дебетово-кредитные отношения в нескольких синтаксически различных формах. Агент Beancount должен использовать семантическую кластеризацию по выборкам завершенных записей — а не простое отклонение токенов — чтобы обнаружить галлюцинацию в названии счета или сумме.

Провал калибровки вербализованной уверенности — это прямое предупреждение для любого интерфейса, показывающего пользователю «насколько уверен ИИ?»: не доверяйте числу, которое выдает модель. Используйте внешний калибратор или методы на основе согласованности, либо не показывайте это число вовсе.

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

• Farquhar et al., «Detecting hallucinations in large language models using semantic entropy», Nature, 2024 — самый строгий метод, вытекающий из структуры этого обзора; стоит прочитать полностью, а не в кратком изложении.
• Manakul et al., «SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models», EMNLP 2023 (arXiv:2303.08896) — канонический метод на основе согласованности; обязателен к изучению перед внедрением любого сигнала уверенности для «черного ящика».
• Groot et al., «Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models», TrustNLP at ACL 2024 (arXiv:2405.02917) — самый тщательный эмпирический аудит того, как вербализованная уверенность дает сбои в различных моделях и задачах.

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

Сайбо Генг, Хадсон Купер, Михал Москаль и их коллеги из Microsoft Research представляют JSONSchemaBench — бенчмарк из 9 558 схем, взятых из реальных производственных источников: сигнатур вызовов функций GlaiveAI, репозиториев GitHub (разбитых по сложности от тривиальных до сверхсложных), конфигураций Kubernetes API, схем аналитики событий Snowplow и коллекции JSONSchemaStore. Они оценивают шесть фреймворков ограниченного декодирования — Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs и Gemini — по трем осям: покрытие (какую долю схем фреймворк вообще может обработать), эффективность (накладные расходы на токены в секунду по сравнению с неограниченной генерацией) и качество (точность выполнения последующих задач). Сетка оценки также включает официальный набор тестов JSON Schema Test Suite, который документирует 45 категорий функций, которые должен поддерживать любой совместимый движок.

Основное утверждение заключается в том, что сложность схемы является решающей переменной, отделяющей способные фреймворки от хрупких, и что ни один фреймворк не доминирует по всем трем осям.

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

• Покрытие обрушивается при усложнении схем. На простых схемах GlaiveAI все фреймворки набирают более 86%. Но на схемах GitHub-Hard — многоуровневая вложенность, рекурсивные определения, сложные паттерны ограничений — покрытие Guidance падает до 41%, Llamacpp до 39%, XGrammar до 28%, а Outlines до катастрофических 3%. OpenAI достигает лишь 9% на GitHub-Hard, а Gemini не выдает валидных результатов на схемах средней и высокой сложности.
• Kubernetes выявляет специфическую слабость XGrammar. Несмотря на заявления XGrammar о скорости, он достигает лишь 7% покрытия на схемах Kubernetes, вероятно, потому что эти схемы полагаются на контекстно-зависимые паттерны, которые контекстно-независимые предварительные вычисления XGrammar не могут обработать. Покрытие в бенчмарке, включающем конфиги Kubernetes, обязательно для производственных агентов.
• Недостаточные ограничения опаснее, чем ошибка компиляции. XGrammar демонстрирует 38 отказов типа «under-constrained» (недостаточное ограничение) в JSON Schema Test Suite — это означает, что он выдает JSON, нарушающий заявленную схему, при этом молча сообщая об успехе. У Guidance только 1 такой отказ. Для агента обратной записи ошибка компиляции обнаруживается на этапе разработки; отказ из-за недостаточных ограничений повреждает данные во время выполнения без какого-либо сигнала.
• Функция fast-forwarding в Guidance обеспечивает реальный прирост скорости на 50%. При наличии длинных детерминированных последовательностей (например, имен полей в фиксированной структуре объекта), Guidance может продвигаться на несколько токенов за один шаг декодирования. На Llama-3.1-8B на A100 Guidance работает со скоростью 6–9 мс на выходной токен, в то время как неограниченная генерация — 15–16 мс. Outlines работает медленнее неограниченной генерации (30–46 мс), в основном из-за предварительной компиляции автомата, занимающей 3–8 секунд на схему.
• Ограниченное декодирование незначительно повышает точность рассуждений. На GSM8K (математика) Guidance повышает точность с 80,1% (без ограничений) до 83,8%. В задачах Last Letter и Shuffle Objects прирост составляет 1–3 пункта. Это противоречит широко распространенному мнению о том, что принудительный формат JSON ухудшает качество ответов, но эффект настолько мал, что выбор формата не должен определять выбор фреймворка.
• Ни один фреймворк не охватывает все 45 категорий функций JSON Schema. Guidance охватывает 13, Llamacpp и XGrammar — по 1, а Outlines — 0. Практическое следствие: любая схема, использующая if/then/else, unevaluatedProperties или рекурсивные определения $ref, будет вести себя непредсказуемо в зависимости от того, какой движок используется под капотом.

Что подтвердилось, а что нет​

Самый сильный вклад бенчмарка — это источники схем. Предыдущие оценки использовали игрушечные схемы или коллекции из одного источника. Включение конфигов Kubernetes наряду с сигнатурами вызовов функций — это правильный вид состязательного разнообразия. Стратификация сложности (от тривиальной до ультра) также дает практикам кривую калибровки: если ваши схемы похожи на вызовы функций GlaiveAI, XGrammar или Guidance одинаково хороши; если они похожи на манифесты Kubernetes, выбор быстро сужается.

Главная слабость — оценка по одному жадному сэмплу (single-sample greedy evaluation). Измерение покрытия по одной генерации на схему занижает реальные возможности — фреймворк может давать сбой в 20% случаев, но срабатывать при повторной попытке. Авторы признают это, но не сообщают показатели pass@k с температурным сэмплированием, что было бы важно для производственных систем, выполняющих повторные попытки при сбое.

Сравнение также смешивает несопоставимые модели. Open-source фреймворки (Guidance, Outlines, Llamacpp, XGrammar) тестировались на Llama-3.2-1B, в то время как OpenAI и Gemini запускают свои собственные закрытые модели. Покрытие OpenAI в 9% на GitHub-Hard может отражать возможности модели так же сильно, как и архитектуру ограниченного декодирования. Для справедливого сравнения потребовался бы контролируемый доступ к моделям, который авторы, очевидно, не могут навязать проприетарным провайдерам.

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

Каждый агент обратной записи Beancount генерирует структурированный вывод. Если агент выдает директивы Beancount в формате JSON перед преобразованием в синтаксис .beancount, или если он вызывает инструменты через JSON-схемы, надежность этой генерации — не деталь, а основа процесса. Исследование FinTrace показало, что передовые модели плохо рассуждают над выводами инструментов; JSONSchemaBench выявляет ортогональную проблему: еще до этапа рассуждений уровень форматирования может незаметно выдать некорректный результат.

Результат с Kubernetes особенно показателен для Beancount. Схемы главной книги — это не плоские наборы «ключ-значение». Иерархии счетов, метаданные транзакций и структуры тегов создают вложенные рекурсивные паттерны, похожие на объекты Kubernetes API. Фреймворк, набирающий 7% на Kubernetes, не готов к сложным схемам бухгалтерского учета, независимо от того, насколько малы его накладные расходы на токен.

Режим отказа из-за недостаточных ограничений — это то, из-за чего я бы лишился сна. Агент Beancount, использующий XGrammar, может выдать транзакцию, которая пройдет внутреннюю проверку валидации фреймворка, но нарушит фактическую схему — и у агента не будет причин для повторной попытки. Незаметное повреждение данных хуже, чем явная ошибка.

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

• XGrammar (arXiv:2411.15100, Dong et al.) — техническая статья об одном из самых быстрых протестированных фреймворков, объясняющая разделение токенов на контекстно-зависимые и независимые, а также причины, по которым схемы Kubernetes создают для него нагрузку.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — показывает, что маскирование токенов при ограниченном декодировании может искажать распределение вероятностей модели, и предлагает скорректированный алгоритм сэмплирования; теоретическая база для проблем качества, которые бенчмарк измеряет лишь косвенно.
• XGrammar-2 (arXiv:2601.04426) — продолжение, расширяющее XGrammar на динамические схемы в агентных сценариях, где сама схема меняется в ходе многоэтапной сессии, что напрямую применимо к агентам Beancount, адаптирующим формат вывода в зависимости от активных типов счетов.

О статье​

Цзе Чжу, Иминь Тянь и коллеги из команды Alibaba Cloud Qwen DianJin, YINGMI Wealth Management и Университета Сучжоу представляют FinMCP-Bench — оценочный набор из 613 образцов, охватывающий 10 категорий финансовых сценариев и 33 подсценария. Инструменты здесь не являются симуляциями — бенчмарк поддерживают 65 реальных MCP-совместимых серверов финансовых инструментов, взятых из реальных логов работы финансового помощника Qieman APP. Авторы разделяют образцы на три типа: 145 задач с одним инструментом, 249 с несколькими инструментами и 219 многоходовых диалогов. Они тестируют шесть моделей: семейство Qwen3 (4B, 30B и 235B параметров, все с режимом расширенного мышления), а также DeepSeek-R1, GPT-OSS-20B и Seed-OSS-36B. Основными метриками оценки являются точность (Tool Precision), полнота (Tool Recall), F1-мера (Tool F1) и показатель точного совпадения (EMR), который требует, чтобы каждый вызов инструмента в последовательности был абсолютно верным.

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

• MCP как основа оценки: использование определений реальных серверов MCP вместо синтетических схем API сокращает разрыв между бенчмарком и тем, с чем агенты сталкиваются в реальных финансовых системах.
• Трехуровневое разделение сложности: задачи с одним инструментом, несколькими инструментами и многоходовые сценарии различаются не только количеством действий — они выявляют качественно разные типы сбоев.
• Крах на многоходовых задачах: лучшая модель (Qwen3-235B) достигает 60% EMR на одном инструменте, 10,62% EMR на нескольких инструментах и всего 3,08% EMR в многоходовых диалогах. Падение от простых задач к сложным — 20-кратное.
• Tool F1 более снисходителен: та же модель набирает 66,85%, 69,42% и 41,56% по метрике TF1 в трех настройках соответственно. Это показывает, что модели часто выбирают правильные инструменты, но ошибаются в порядке вызовов, параметрах или отслеживании контекста беседы.
• Полнота выше точности в простых задачах: при неуверенности модели склонны вызывать лишние инструменты, а не пропускать нужные. Для финансовых задач это более безопасный тип сбоя, хотя он и ведет к лишним вызовам API и шуму в цепочке рассуждений.
• Нелинейная масштабируемость: Qwen3-30B не всегда превосходит Qwen3-4B во всех подсценариях, что опровергает предположение о том, что большая модель всегда лучше справляется с многошаговым использованием инструментов.

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

Использование реальных производственных логов для примеров с одним инструментом — самое сильное методологическое решение. Это привязывает бенчмарк к реальному поведению пользователей, а не к сценариям, выдуманным исследователями, что редко встречается в литературе по финансовому ИИ. Многоинструментальные и многоходовые образцы синтетически расширены с помощью графов зависимостей и ролевых промптов. Это разумно, учитывая стоимость разметки, но создает риск: синтез обычно выдает более чистые и понятные запросы, чем те, что пишут реальные пользователи. Показатель EMR 3,08% в многоходовых задачах пугает, но его следует интерпретировать осторожно: EMR требует идеальной точности всей последовательности, поэтому одна ошибка в промежуточном вызове приводит к провалу всей задачи. Это строгий и, возможно, нереалистичный стандарт для эксплуатации; метрики с частичным зачетом, такие как TF1, дают более нюансированную картину.

Чего в статье нет: отсутствует анализ того, является ли разрыв в производительности проблемой понимания ввода (модель неверно интерпретирует желание пользователя), проблемой форматирования вывода (верное намерение, но неверный формат вызова) или проблемой рассуждения (неверные промежуточные выводы). Без этого разделения трудно понять, куда инвестировать инженерные усилия. Также модели оцениваются изолированно; нет тестов того, изменит ли ситуацию добавление этапа верификации или рефлексии.

Бенчмарк также глубоко привязан к специфическим 65 инструментам Qieman, что ограничивает переносимость результатов на другие финансовые платформы с иным набором инструментов.

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

FinMCP-Bench максимально приближен к тому, что на самом деле делал бы агент для записи в Beancount: получение запроса пользователя, определение подходящего инструмента (или цепочки инструментов), их последовательный вызов и обработка последующих уточнений. Показатель EMR 3,08% для многоходовых задач — это жесткое столкновение с реальностью. Агент Beancount, управляющий многошаговой корректировкой реестра (например, переклассификация группы транзакций по счетам за определенный период с последующей сверкой и генерацией отчета), — это именно та многоходовая задача, с которой текущие модели почти повсеместно не справляются по стандартам точного совпадения.

Контекст MCP имеет прямое отношение: Python API Beancount, интерфейс beanquery и REST-слой fava — все это можно обернуть в MCP-серверы. FinMCP-Bench говорит нам, что узким местом является не протокол, а логика рассуждений над последовательностью вызовов инструментов.

Вывод о том, что полнота вызовов превышает точность (модели вызывают лишнее), также важен для безопасности записи данных: агент, вызывающий инструмент изменения реестра там, где требовалось только чтение, может незаметно повредить данные. Для агентов, работающих на запись, основным сигналом безопасности должны быть метрики, ориентированные на точность (precision), а не на полноту (recall).

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

• JSONSchemaBench (arXiv:2501.10868) — оценивает надежность структурированного вывода по 10 000 схем JSON; напрямую исследует, являются ли сбои форматирования вызовов инструментов в FinMCP-Bench проблемой ограниченного декодирования.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — фундаментальный фреймворк для обучения использованию инструментов, с которым сопоставляется FinMCP-Bench; понимание его поиска по дереву помогает осознать вклад методологии FinMCP-Bench на основе реальных логов.
• WildToolBench (arXiv:2604.06185) — оценивает использование инструментов на реальных пользовательских запросах «в дикой природе»; вывод о том, что ни одна модель не превышает 15% точности на реальном поведении пользователей, дополняет подход FinMCP-Bench.

Статья​

Цао и соавторы представляют FinTrace — бенчмарк из 800 аннотированных экспертами траекторий, охватывающих 34 категории реальных финансовых задач трех уровней сложности: легкий, средний и сложный. Авторы строят свою оценку вокруг рубрики из девяти метрик, организованных по четырем осям: правильность действий (F1 вызова инструментов, релевантность задаче), эффективность исполнения (эффективность шагов, показатель избыточности), качество процесса (логическая последовательность, использование информации, показатель прогресса) и качество результата (коэффициент прохождения задач, качество итогового ответа). Они оценивают 13 LLM, а также выпускают FinTrace-Training — набор данных из 8 196 отобранных траекторий предпочтений для дообучения.

Основное утверждение заключается в том, что передовые модели освоили выбор инструментов, но систематически терпят неудачу на более сложном этапе: использовании того, что возвращают инструменты. Бенчмарк проверяет это с помощью 5-балльной шкалы для использования информации, логической последовательности и показателя прогресса, а также алгоритмических метрик для F1 инструментов и эффективности шагов.

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

• Лучшая модель, Claude-Opus-4.6, достигает F1 вызова инструментов 0.896 — отличный выбор — но набирает всего 3.23/5 по Использованию информации, самой слабой из четырех метрик, ориентированных на результат.
• Коэффициент прохождения задач у Claude-Opus-4.6 составляет 2.65/5, а качество финального ответа — 3.34/5; даже топовая модель не всегда выдает правильные и полные ответы.
• Qwen-3.5-9B демонстрирует дегенеративный паттерн: почти идеальная эффективность шагов (1.000) и избыточность (1.000), потому что она почти не вызывает инструменты, что отражается в F1 вызова инструментов 0.109. Эффективно, но бесполезно.
• Обучение на FinTrace-Training улучшает метрики промежуточных процессов (логическая последовательность растет с 2.29 до 2.56 с DPO; показатель прогресса — с 2.00 до 2.30), но качество финального ответа остается заблокированным — ни один вариант не превышает в среднем 1.21 по шкале 1–5 для малых моделей.
• DPO превосходит SFT в подавлении катастрофических режимов отказа: доля оценок «Логическая последовательность» равных 1 падает с 11.9% (SFT) до 9.5% (DPO).
• Самая худшая подкатегория для всех 13 моделей — Reasoning QA, где Claude-Opus-4.6 набирает всего 0.62 в целом — жесткий потолок даже для сильнейшей модели.

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

Основной вывод о том, что выбор инструмента и рассуждение над ним разделимы, хорошо мотивирован, а рубрика из четырех осей является реальным вкладом. Предыдущие бенчмарки, такие как FinToolBench, останавливаются на трассировках выполнения; FinTrace добавляет метрики качества процесса, оцениваемые LLM, которые показывают, что происходит в промежутках. Коэффициент κ Коэна между экспертами 0.89 на валидации из 100 примеров обнадеживает для бенчмарка, частично построенного на судьях-LLM.

Тем не менее, несколько методологических решений ограничивают доверие к цифрам. 34 категории задач не перечислены в основной статье — они вынесены в Приложение B — поэтому я не могу сказать, насколько они репрезентативны для реальной финансовой практики. Уровни сложности определяются процентильным рангом внутри собственного пула запросов бенчмарка, что является круговым показателем: «сложный» означает просто необычный по сравнению с другими 800 траекториями, а не сложный в каком-либо абсолютном смысле.

Анализ дообучения расстраивает. Обучение модели 9B на FinTrace-Training улучшает промежуточные рассуждения, но качество финального ответа остается неудовлетворительным. В статье это объясняется «разрывом» между процессом и результатом, но не объясняется причина. Самое правдоподобное объяснение — что модели 9B не хватает памяти фактов и арифметических способностей, необходимых для финансовых задач, независимо от качества траектории — осталось без внимания. Демонстрация результатов DPO только для Qwen-3.5-9B также делает невозможным понимание того, получают ли больше пользы крупные модели.

Я также скептически отношусь к агрегации общих баллов. Объединение алгоритмических метрик (F1 ∈ [0,1]) с оценками судей-LLM по 5-балльной шкале Ликерта путем нормализации к [0,1] и усреднения смешивает совершенно разные типы сбоев. Модель, которая вызывает неправильные инструменты, — это не тот же тип поломки, что и модель, которая вызывает правильные инструменты, а затем игнорирует результат.

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

Основной вывод напрямую переносится на проблему записи (write-back) в Beancount. Агент, который надежно вызывает нужные инструменты Beancount CLI, но затем неверно интерпретирует результат — скажем, разбирает ответ по балансовому отчету и делает запись не на тот счет — хуже, чем отсутствие автоматизации: он создает уверенно ошибочные записи в реестре, которые выглядят правильными для случайного проверяющего.

Метрика «Использование информации» — это то, за чем я бы следил внимательнее всего для любого агента Beancount. Тот факт, что лучшая доступная модель набирает 3.23/5 по этому показателю в контролируемом финансовом бенчмарке, должен стать сдерживающим фактором для любого промышленного внедрения. Это аргумент в пользу обязательной проверки человеком любой операции записи, по крайней мере до тех пор, пока мы не увидим, что этот балл стабильно превышает 4.0.

FinTrace также подтверждает то, что ReDAct предполагал на прошлой неделе: правильная архитектура — это не сквозное рассуждение LLM, а конвейер, который выносит проверку вовне. Агент, который хорошо выбирает инструменты (Tool F1 ~0.9), а затем передает результаты на отдельный этап валидации перед действием, более надежен, чем тот, который пытается рассуждать над необработанным выводом инструмента за один проход.

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

• FinMCP-Bench (arXiv:2603.24943): сопутствующая статья, использующая MCP как стандарт интерфейса инструментов, следующая в списке чтения — напрямую сопоставима с FinTrace, но построена на другом протокольном уровне.
• "Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): появилась одновременно и оценивает вызов инструментов вне финансов; прояснит, является ли разрыв в использовании информации специфичным для домена или общим.
• "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): нацелена на те же режимы отказов при вызове функций с точки зрения обучающих данных и может объяснить, чего не хватает в DPO FinTrace-Training.

Статья​

Цзясюань Лу и коллеги представляют FinToolBench (arXiv:2603.08262, март 2026 года) как то, что они называют первым в мире реально исполняемым бенчмарком для оценки финансовых агентов, обучающихся работе с инструментами. Формулировка прямая: существующие оценки финансового ИИ фокусируются на статических ответах на вопросы по документам, в то время как общие бенчмарки использования инструментов, такие как ToolLLM, рассматривают финансы просто как еще одну категорию API без специфических для предметной области регуляторных ограничений. FinToolBench пытается заполнить пространство между этими двумя тупиковыми путями.

Бенчмарк объединяет 760 исполняемых финансовых инструментов — 261 активную конечную точку (endpoint) из RapidAPI и 499 интерфейсов из AkShare — с 295 тщательно отобранными оценочными запросами, разделенными на 166 одноэтапных и 129 многоэтапных кейсов. Инструменты охватывают сферы акций, облигаций, фондов, форекса, деривативов, макроэкономики и криптовалют. Важно, что это реальные, вызываемые API, а не имитации (stubs). Авторы также представляют FATR (Finance-Aware Tool Routing) — базового агента, использующего поиск BGE-M3 (топ-20 кандидатов), карточки инструментов с финансовыми атрибутами и планировщик ReAct, учитывающий ограничения и лимитированный пятью шагами.

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

• Проблемой является не само выполнение, а рассуждение над результатами. У GPT-4o самый высокий показатель Conditional Soft Score (CSS = 0,670), что означает получение правильных ответов при успешном вызове инструмента, но модель вызывает инструменты лишь в 22,7% случаев (TIR = 0,227). Qwen3-8B обращается к инструментам в 87,1% случаев, но дает правильный ответ только в 40,4% успешных вызовов.
• Несоответствие намерений — основная причина нарушений комплаенса. Показатель IMR (Intent Mismatch Rate) превышает 50% у большинства моделей, что означает, что агенты регулярно инициируют транзакционные вызовы, когда запрос требует лишь информационного поиска. Это серьезная проблема в контексте регулируемых финансов.
• Внедрение финансовых атрибутов помогает соблюдению правил без ущерба для возможностей. Карточки инструментов базовой модели FATR — аннотирование каждого инструмента данными об актуальности, типе намерения и регуляторной области — снижают количество вызовов устаревших данных (TMR) и нарушений домена (DMR) без значительного ухудшения частоты вызовов.
• Многоэтапные запросы выявляют разрыв в надежности. 129 многоэтапных запросов требуют цепочки вызовов и передачи данных между шагами; производительность существенно падает по сравнению с одноэтапными случаями, что согласуется с выводами FinTrace и TheAgentCompany.
• Малые модели могут превосходить большие по частоте вызовов, но не по качеству рассуждений. TIR модели Qwen3-8B (0,871) против 0,227 у GPT-4o показывает, что малые модели более «склонны к действию», но CER (Conditional Execution Rate, т.е. TESR/TIR), составляющий 0,339 для Qwen3-8B против 0,618 для GPT-4o, показывает, что GPT-4o гораздо точнее в те моменты, когда она все же решает использовать инструмент.

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

Использование подлинно живых, исполняемых API — главный вклад этого бенчмарка, и он весьма значителен. Имитированные API были «грязным секретом» бенчмарков использования инструментов: 16 000 API в ToolLLM звучат впечатляюще, пока не понимаешь, что в оценке используется LLM в качестве судьи того, «сработал бы» вызов или нет. FinToolBench этого избегает.

Метрики комплаенса (TMR, IMR, DMR) концептуально верны — финансовые агенты должны понимать разницу между получением вчерашней цены закрытия и инициацией сделки, — но описание того, как эти классификации обеспечиваются в статье, довольно скудное. Неясно, проверялись ли эталонные метки для типов намерений (информационные против транзакционных) экспертами по праву или комплаенсу, или же они были просто назначены авторами датасета. На практике это имеет большое значение.

Список моделей также странно узок: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash и GPT-4o. Нет ни Claude Sonnet, ни Gemini 2.5, которые были бы естественными кандидатами для сравнения. Таблица результатов показывает, что GPT-4o является исключением с высокой точностью, но низким охватом; мне было бы интересно узнать, ближе ли поведение Claude к консервативному паттерну GPT-4o или к агрессивному Qwen3-8B.

Набор из 295 запросов невелик по современным стандартам бенчмарков. При наличии 760 инструментов охват в 295 запросов означает, что большинство инструментов никогда не тестируется. В статье не приводятся статистические данные по охвату каждой области, а значит, основные показатели могут определяться подмножеством хорошо охваченных областей, таких как акции и макроэкономика.

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

Агенты обратной записи Beancount — любые агенты, которые вызывают bean-add, вносят правки в файл гроссбуха или запрашивают данные через beanquery, — сталкиваются именно с теми типами сбоев, которые выявляет FinToolBench. Проблема несоответствия намерений переносится напрямую: агент Beancount, который инициирует вызов записи, когда пользователь задал вопрос на чтение, имеет тот же признак отказа, что и нарушение IMR. Измерение актуальности (timeliness) соотносится с проблемой вызова устаревшего кэшированного состояния гроссбуха, когда пользователь ожидает текущий баланс.

Противоречие между точностью и охватом (GPT-4o против Qwen3-8B) также имеет прямое отношение к делу. Для записи в Beancount я бы предпочел консервативное поведение GPT-4o — низкий TIR, но высокие CER и CSS, — чем модель с высокой частотой вызовов, которая часто использует не тот инструмент. Ошибочные записи обходятся гораздо дороже, чем отсутствие действий (no-ops).

Подход FATR по аннотированию инструментов атрибутами комплаенса вместо того, чтобы полагаться на выводы модели, — это паттерн проектирования, который стоит перенять. Обертка инструментов командной строки Beancount явными метаданными о том, является ли вызов только чтением или модификацией, и затрагивает ли он текущее или архивное состояние гроссбуха, — это та же идея, примененная в меньшем масштабе.

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

• FinTrace (arXiv:2604.10015) — оценка на уровне траекторий в 34 категориях финансовых задач с использованием 9 метрик; напрямую расширяет оценку одиночных вызовов FinToolBench до многошаговых последовательностей и выполняет тонкую настройку Qwen-3.5-9B с помощью DPO для улучшения промежуточных рассуждений.
• FinMCP-Bench (arXiv:2603.24943) — 613 примеров на базе 65 финансовых инструментов MCP, тестирующих одиночные, множественные и многоходовые вызовы; структура MCP имеет прямое отношение к интерфейсам инструментов Beancount.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — статья о ToolBench, противопоставление которой эксплицитно выстраивает FinToolBench; понимание того, что может и чего не может измерить база с имитацией API, проясняет, что на самом деле дает исполняемость в FinToolBench.

Статья​

OmniEval выстраивает двумерную сетку оценки: пять классов задач (экстрактивные ответы на вопросы, многошаговые рассуждения, сравнительные ответы, развернутые ответы и диалоговые ответы), пересекающиеся с 16 финансовыми темами (фондовые рынки, инвестиционный банкинг, фонды, страхование имущества и другие). Результатом является структурированный бенчмарк с 11,4 тыс. автоматически сгенерированных тестовых примеров, 1,7 тыс. примеров, размеченных людьми, и поисковым корпусом из 362 тыс. документов, собранным из шести китайских источников финансовых данных (BSCF-DB — 193 тыс. документов, FinGLM — 55 тыс., BAAI-Fin — 48 тыс., официальные веб-страницы, PDF-файлы и финансовый контент Википедии). Бенчмарк также включает тонко настроенный LLM-оценщик — Qwen2.5-7B-Instruct, обученный на 910 размеченных вручную экземплярах, который оценивает качество генерации по параметрам точности, галлюцинаций, полноты, полезности и числовой точности. Статья была опубликована на EMNLP 2025.

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

• Автоматически сгенерированные тестовые случаи прошли проверку на принятие человеком на 87,47%, что означает, что примерно 1 из 8 сгенерированных экземпляров был отброшен — нетривиальный уровень шума для бенчмарка.
• Лучший ретривер (GTE-Qwen2-1.5B) достиг MAP 0,4370 и MRR 0,4491 на автоматически сгенерированном наборе, что означает, что наиболее высоко ранжированный фрагмент оказывается верным менее чем в половине случаев даже при использовании самого сильного из протестированных ретриверов.
• Точность генерации (ACC) для всех комбинаций ретривер-LLM варьировалась от 0,3238 до 0,4476 — лучшая конфигурация дает правильные ответы менее чем на половину вопросов.
• Числовая точность (NAC) — самый яркий вывод: от 0,0659 до 0,3595. Лучшая система правильно называет финансовые показатели примерно в 36% случаев; худшая — почти никогда.
• Тонко настроенный оценщик достиг 74,4% совпадения с человеческой разметкой (κ = 0,6486), существенно превзойдя базовые модели, работающие только на промптах (55–71%), но всё же оставив каждую четвертую оценку не соответствующей суждению человека.
• Многошаговые рассуждения и диалоговые ответы стабильно оказывались самыми сложными классами задач.

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

Матричный дизайн оценки действительно полезен. Предыдущие финансовые бенчмарки (FinanceBench, FinQA, DocFinQA) рассматривают оценку по одной оси — обычно точности ответов — и упускают структурные различия в том, как именно RAG терпит неудачу. Знание того, что система хорошо справляется с экстрактивными ответами, но плохо с многошаговыми рассуждениями, дает возможность для действий; знание того, что она набирает какой-то средний общий балл, — нет. Сетка OmniEval делает эти различия видимыми, а вывод о том, что производительность непостоянна в разных темах, — это именно тот результат, который практики должны видеть перед внедрением.

Тем не менее, есть реальные ограничения, о которых я хочу сказать прямо. Корпус данных преимущественно китайский: пять из шести источников — это китайские финансовые данные (BSCF, FinGLM, BAAI-Fin), а шестой — китайская Википедия. В статье нет результатов с разбивкой по языкам — только агрегированные цифры. Это делает каждый балл в статье сомнительным в качестве утверждения о финансовых RAG в целом, в отличие от финансовых RAG на китайских текстах со специализированными для Китая ретриверами и LLM (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Англоязычные или русскоязычные пользователи финансовых инструментов не могут напрямую использовать эти цифры.

LLM-оценщик обучен на 910 размеченных экземплярах. Этого мало. 74,4% совпадения с человеком при κ = 0,6486 допустимы как отправная точка, но это означает, что сама структура оценки вносит существенный шум. Если бенчмарк используется для сравнения систем, которые различаются на несколько процентных пунктов, дисперсия оценщика поглотит полезный сигнал.

Конвейер автоматической генерации — GPT-4 создает вопросы, люди фильтруют их с уровнем принятия 87,47% — также поднимает вопрос о загрязнении данных (contamination), который в статье не рассматривается: вопросы, сгенерированные GPT-4, могут подыгрывать сильным сторонам моделей класса GPT-4 так, что это систематически ставит в невыгодное положение старые или меньшие модели.

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

Показатели числовой точности — это те цифры, к которым я постоянно возвращаюсь: 0,0659–0,3595. Если лучшая протестированная RAG-система правильно называет финансовые числа только в 36% случаев в рамках бенчмарка, любой агент обратной записи Beancount, построенный на базе наивного RAG-конвейера, будет портить данные гроссбуха. Формат Beancount строг: неправильная сумма, дата или название счета приводят либо к ошибке парсинга, либо к скрытой бухгалтерской ошибке, которая может распространиться на несколько финансовых лет. Этот бенчмарк дает нам конкретные доказательства того, что выборка RAG и генерация LLM еще недостаточно надежны для прямой обратной записи в гроссбух без слоя валидации.

Структура классов задач также четко проецируется на варианты использования Beancount. Экстрактивные ответы соответствуют простым проверкам баланса. Многошаговые рассуждения соответствуют вопросам вроде «какова моя чистая прибыль после уплаты налогов за 1–3 кварталы?». Диалоговые ответы соответствуют пользователю, который итеративно уточняет запрос на сверку в течение сессии. Вывод OmniEval о том, что многошаговые и диалоговые задачи являются самыми сложными, — это как раз плохие новости для проектирования агентов Beancount: простые случаи почти в порядке, но именно на реалистичных сценариях система разваливается.

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

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — ближайший аналог OmniEval в общей области по подходу к тонкой настройке оценщика; сравнение методологии ARES с OmniEval прояснило бы, являются ли решения по дизайну LLM-оценщика обоснованными или ситуативными.
• RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) — автоматизированная генерация сценариев для оценки RAG; расширяет методологию автогенерации, которую использует OmniEval, и может решить проблему загрязнения данных.
• FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) — расширяет оценку RAG на мультимодальные финансовые документы (таблицы, графики); актуально, так как пользователи Beancount всё чаще хранят изображения чеков и PDF-выписки вместе с текстовыми гроссбухами.

Статья​

В обзоре Сюя и Дина (arXiv:2409.01980) предлагается разделить обнаружение аномалий и данных вне распределения (OOD) на базе LLM на два высокоуровневых класса: LLM для обнаружения (LLMs for Detection), где модель напрямую идентифицирует аномалии, и LLM для генерации (LLMs for Generation), где модель дополняет обучающие данные или создает объяснения на естественном языке, которые передаются нижестоящему детектору. Каждый класс подразделяется далее. Обнаружение делится на методы на основе промптов (замороженные или дообученные LLM, опрашиваемые с помощью текстовых промптов) и контрастивные методы (модели семейства CLIP, которые оценивают степень аномальности путем сравнения фрагментов изображений с текстовыми описаниями). Генерация делится на методы, ориентированные на аугментацию (создание псевдо-OOD меток или синтетических выборок меньшинства), и методы, ориентированные на объяснение (создание логических обоснований на естественном языке для помеченных событий).

Сопутствующий список литературы на GitHub охватывает примерно 39 работ: 24 по обнаружению, 10 по аугментации и 5 по объяснению.

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

• Контрастивные методы доминируют в обнаружении аномалий на изображениях. WinCLIP достигает 91,8% и 85,1% AUROC в классификации и сегментации аномалий в режиме zero-shot на датасете MVTec-AD без какой-либо специфической настройки под датасет, что сопоставимо с методами обучения с учителем.
• Замороженные LLM сталкиваются с модальным разрывом в нетекстовых данных. В обзоре прямо отмечается, что «прямое использование замороженных LLM для обнаружения аномалий или OOD в различных типах данных часто приводит к субоптимальной производительности из-за врожденного разрыва между текстом и другими модальностями данных».
• LoRA и адаптерная настройка позволяют преодолеть этот разрыв. Методы вроде AnomalyGPT и AnomalyCLIP используют эффективные по параметрам техники дообучения и существенно превосходят свои «замороженные» аналоги.
• Генерация как аугментация используется недостаточно. Псевдо-OOD метки на уровне подписей, созданные BLIP-2, превосходят альтернативы на уровне слов и описаний при обнаружении OOD, что указывает на важность богатого текстового надзора даже для визуальных задач.
• Генерация с упором на объяснения — самая новая подкатегория. Системы вроде Holmes-VAD и VAD-LLaMA выходят за рамки бинарных флагов и генерируют обоснования аномальных событий на естественном языке, в основном для видео с камер наблюдения.
• Табличные данные почти не представлены. В обзоре цитируется один метод — «Tabular» Ли и др. (2024), который преобразует строки таблиц в текстовые промпты и дообучает модель с помощью LoRA, но сравнительные показатели не приводятся.

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

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

Что я не могу принять, так это позиционирование статьи как широкого обзора обнаружения аномалий. Содержание подавляюще сконцентрировано на изображениях промышленных дефектов (MVTec-AD, VisA) и видео наблюдения (UCF-Crime, XD-Violence). Из примерно 39 каталогизированных работ почти ни одна не касается табличных или финансовых данных. Временные ряды удостоились нескольких упоминаний. Табличные данные — одного предложения. Это не карта ландшафта для Bean Labs — это карта ландшафта для исследователей компьютерного зрения, которые хотят использовать CLIP для поиска дефектов.

Авторы признают, что «ограничения по объему не позволяют привести подробные сводки метрик», что является вежливым способом сказать, что сравнительных таблиц нет. Для обзорной статьи отсутствие количественного синтеза — существенный пробел. Читатели не могут использовать эту работу, чтобы решить, какая парадигма лучше для их сценария использования, не изучая каждую цитируемую статью в отдельности.

Проблема галлюцинаций указана как открытый вопрос, но её рассмотрение поверхностно — упоминается риск без анализа того, какие парадигмы обнаружения более или менее подвержены ему, или как генерация объяснений может сделать галлюцинации более заметными при проверке человеком.

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

Две подкатегории актуальны, несмотря на перекос в сторону изображений. Во-первых, подкатегория генерации с упором на объяснения — это именно то, что нужно агентам аудита Beancount: не просто флаг о том, что бухгалтерская проводка аномальна, а предложение на естественном языке, объясняющее почему. Финансовые аудиторы не могут работать с бинарным выводом. Во-вторых, почти полное молчание обзора по поводу обнаружения аномалий в таблицах само по себе информативно — оно подтверждает, что направление AnoLLM, CausalTAD и AD-LLM, за которым я слежу, является передовым, а не проторенным, и что разработка инструментов аудита на базе LLM для регистров Beancount требует синтеза идей из области компьютерного зрения, которые еще не были перенесены в табличную среду.

Компромисс между промптингом и дообучением — самый практически применимый вывод: zero-shot промптинг работает как первое приближение, но страдает от модального разрыва; дообучение на базе LoRA на репрезентативных размеченных примерах закрывает этот разрыв. Для развертывания Beancount с размеченными примерами аномалий из прошлых периодов путь дообучения кажется более надежным, чем чистый промптинг.

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

• "Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs" (arXiv:2406.03614) — использует эмбеддинги sentence-transformer от LLM для реальных записей главной книги; прямой мост от структуры этого обзора к табличному использованию в Beancount.
• "Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework" (arXiv:2403.19735) — мультиагентный конвейер для обнаружения аномалий в рыночных данных; паттерн мультиагентной координации может быть перенесен на аудит регистров.
• AnomalyGPT (arXiv:2308.15366) — дообученная LVLM для промышленного обнаружения аномалий с локализацией на уровне пикселей; чтение этой статьи проясняет, что именно означает «настройка LLM для обнаружения» с точки зрения архитектуры, что в обзоре описывается, но не объясняется.

О статье​

Сье и др. начинают с диагностического наблюдения: LLM — даже те, что обучались на длинных контекстах — демонстрируют устойчивый U-образный паттерн внимания. Токены в начале и в конце входных данных получают непропорционально высокое внимание независимо от их релевантности, в то время как токены в середине систематически недооцениваются. Авторы эмпирически связывают это с падением точности «lost-in-the-middle», а не рассматривают как отдельный феномен.

Их решение элегантно по своей сути. Они разлагают внимание на два аддитивных компонента: релевантность (то, что нам нужно) и позиционное смещение (то, что не нужно). Чтобы изолировать смещение, они пропускают «пустой» (фиктивный) документ — неинформативное наполнение — через тот же контекст в каждой позиции и записывают полученное распределение внимания. Это внимание пустого документа аппроксимирует чистое позиционное априорное распределение. Вычитание его из реальных показателей внимания оставляет остаток, который лучше отражает истинную релевантность:

Calibrated attention = Attn(document, k) − Attn(dummy, k)

Затем пересчитанные показатели используются для ранжирования или перевзвешивания извлеченных документов перед финальным этапом генерации ответа. Важно, что обучение не требуется. Калибровка применяется на этапе вывода к последним 16 слоям декодера и всем головкам внимания. Стоимость составляет O(K) дополнительных проходов вперед, где K — количество извлеченных документов — величина нетривиальная, но предсказуемая.

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

• U-образное позиционное смещение внимания присуще архитектуре модели и сохраняется даже в моделях, специально обученных для работы с длинным контекстом.
• Пропуск фиктивного (пустого/шумного) документа через тот же контекст извлечения изолирует позиционное априорное распределение; его вычитание удаляет смещение без какой-либо тонкой настройки (finetuning).
• Recall@3 на NaturalQuestion (K=20, золотой документ помещен в середину) прыгает с 20,52% до 68,32% при калибровке; при K=10 — с 36,38% до 74,27%.
• Сквозная точность ответов на вопросы (QA) улучшается на 6–15 процентных пунктов, когда золотой документ находится в середине контекста; улучшения сохраняются в 22 из 24 экспериментальных конфигураций.
• Метод превосходит шесть базовых моделей для сравнения: стандартное внимание, ранжирование на основе генерации запросов, промптинг с генерацией релевантности, сортировку по вниманию (Peysakhovich & Lerer 2023), переупорядочивание промптов и LongLLMLingua-rk.
• Метод оценивался на NaturalQuestion (2655 реальных запросов по Википедии) и SynthWiki (990 синтетических записей, сгенерированных GPT-4).

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

Основной результат поразителен, и я в него верю. Разрыв в Recall@3 с 20,52% до 68,32% для золотых документов в середине контекста — это не та цифра, которая испаряется при тщательном изучении; она измеряет нечто реальное в распределении внимания. Дизайн без обучения — это подлинное практическое преимущество: вы можете внедрить это поверх любого существующего RAG-конвейера, не касаясь весов модели.

Тем не менее, у меня есть некоторые сомнения. Во-первых, подход с «пустым документом» предполагает, что позиционное смещение примерно позиционно-разделимо и аддитивно — линейное разложение, которое сами авторы помечают как потенциально упрощенное. Реальное смещение внимания может взаимодействовать с контентом нелинейно. Во-вторых, дополнительные O(K) проходов вперед оцениваются как «приемлемые», но никогда не тестировались на предмет задержки или стоимости. В рабочей системе с извлечением K=20 вы запускаете 21 проход вместо одного на запрос. Для агента Beancount, сортирующего сотни транзакций, этот множитель имеет значение.

В-третьих — и это самое интересное ограничение — авторы отмечают, что позиционное смещение может быть полезным для определенных задач. Например, смещение в сторону новизны (recency bias) может заставлять модель правильно отдавать приоритет недавним записям в бухгалтерской книге над старыми. Неизбирательное удаление смещения может повредить задачам, где позиция является валидным сигналом. Это признается, но не изучается.

Наконец, в экспериментах используются NaturalQuestion и синтетический набор данных. Специфические финансовые документы — плотные таблицы, отчеты за несколько лет, записи в журналах с повторяющейся структурой — сильно отличаются от статей Википедии. Калибровку необходимо будет проверить на этих распределениях, прежде чем утверждать, что она будет работать для финансового RAG.

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

Прямая связь очевидна: каждая заметка со времен DocFinQA вращается вокруг одной и той же проблемы. Когда агент Beancount извлекает 20 релевантных записей из журнала, чтобы ответить на вопрос типа «сверь март с банковской выпиской», записям из середины окна извлечения будет уделяться систематически меньше внимания по сравнению с записями в начале и конце контекста. Это не провал извлечения — это ошибка на стороне генерации, которую не исправит никакое улучшение ранжирования.

Калибровка «found-in-the-middle» — это правдоподобный способ смягчения проблемы, который не требует переобучения базовой модели и может быть применен непосредственно на этапе генерации в любом QA-конвейере для бухгалтерских книг. Опасения по поводу стоимости O(K) реальны, но управляемы — окно извлечения в 20 документов с моделью среднего размера все еще находится в практических пределах. Что бы я хотел увидеть перед внедрением, так это проверку именно на структурированных данных Beancount: помогает ли позиционная коррекция равномерно или она непреднамеренно подавляет сигнал новизны, который делает недавние транзакции более заслуживающими доверия, чем старые?

Стоит помнить об общем принципе: механизмы внимания кодируют позиционные априорные значения независимо от релевантности контента, и эти априорные значения можно откалибровать без переобучения. Это открывает дверь к аналогичным калибровкам для других смещений: смещения частоты токенов, нормализации длины ввода, смещения избыточности при генерации.

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

• «Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel» (arXiv:2406.02536, ACL Findings 2025) — предлагает масштабирование одного измерения скрытого состояния вместо вычитания показателей внимания; стоит сравнить с подходом «found-in-the-middle» напрямую.
• «Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey» (arXiv:2409.01980, NAACL 2025) — следующий в списке для чтения; объединяет идеи AnoLLM, CausalTAD и AD-LLM в единую таксономию.
• Liu et al., «Lost in the Middle: How Language Models Use Long Contexts» (arXiv:2307.03172, TACL 2023) — оригинальный «диагноз», на который отвечает данная статья; необходимое базовое чтение.

О статье​

ReDAct (Reason-Defer-Act) базируется на парадигме промптинга ReAct и вводит двухмодельную архитектуру агента. Малая дешевая модель — Qwen3-80B, Llama3.3-70B или Llama4-Maverick — по умолчанию обрабатывает каждый шаг. На каждом этапе она генерирует цепочку рассуждений, а затем — действие. Система измеряет неопределенность на уровне токенов только на этапе генерации действия и сравнивает её с откалиброванным порогом. Если неопределенность превышает этот порог, шаг перезапускается большой дорогой моделью (GPT-5.2, Qwen3-235B или Qwen3-480B); в противном случае выполняется действие малой модели.

Меры неопределенности основаны на теории информации и требуют только логарифмических вероятностей (log-probs) на уровне токенов: вероятность последовательности (суммарная отрицательная логарифмическая вероятность), перплексия (нормализованная по длине) и средняя энтропия токенов (средняя энтропия по позициям токенов). Порог калибруется на отложенной выборке прогонов малой модели путем выбора значения, которое обеспечивает целевое количество вызовов большой модели на эпизод K.

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

• Измеряйте неопределенность на этапе действия, а не рассуждения. Дополнительный эксперимент на 2411 шагах ALFWorld показал, что неопределенность на уровне рассуждений плохо разграничивает правильные и неправильные шаги; перплексия на уровне действий имеет заметно более высокие показатели ROC-AUC и PRR как предиктор правильности.
• Делегирование по PPL с Qwen3-80B + GPT-5.2 достигает 80.8% ± 1.1% на ALFWorld, превосходя результат одной GPT-5.2 (78.3% ± 1.9%), при стоимости $16.25 против $45.21 — экономия составляет примерно 64%.
• На практике делегируется около 15% шагов, чтобы соответствовать калибровочной цели примерно в 10%; разрыв возникает из-за того, что неудачные (более короткие) траектории вносят непропорционально большой вклад в бюджет делегирования.
• Случайное делегирование с той же частотой дает 77.0% — это все равно лучше, чем использование только малой модели (68.3%), но хуже, чем делегирование под руководством UQ (оценки неопределенности). Сигнал неопределенности действительно важен, а не просто сам факт более частого обращения к большой модели.
• MiniGrid показывает меньший потенциал роста. Qwen3-80B + GPT-5.2 с делегированием по PPL достигает 95.0% против 99.0% у одной GPT-5.2. Узкий словарный запас задач создает жесткий потолок для подхода с делегированием, когда малая модель структурно не подходит для задачи.
• Распределение делегирования зависит от задачи. В ALFWorld больше задач делегируется на поздних этапах (длинная история промптов), тогда как MiniGrid демонстрирует бимодальный паттерн, связанный с начальной позицией агента. Это означает, что фиксированная калибровка порога лучше обобщается внутри семейства задач, чем между ними.

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

Основной эмпирический вывод заслуживает доверия: перплексия строки действия является разумным прокси-показателем того, пойдет ли конкретный шаг не так. Декомпозиция рассуждение/действие в ReAct естественным образом предоставляет удобную точку для прикрепления сигнала неопределенности, а вспомогательный эксперимент по прогнозированию правильности дает подлинное механистическое обоснование выбора дизайна.

В чем я менее уверен: в результате «превосходит одну большую модель» на ALFWorld. Значения 80.8% ± 1.1% и 78.3% ± 1.9% пересекаются в пределах одного стандартного отклонения. Авторы объясняют это взаимодополняющими сильными сторонами — малая модель справляется с рутинными шагами без периодического неоправданного риска, свойственного большой модели, — но нет пошагового абляционного исследования для проверки этой гипотезы. Это вполне может быть статистическим шумом.

Выбор бенчмарков также ограничен. ALFWorld и MiniGrid — это текстовые симуляции домашнего хозяйства и навигация в сеточном мире; узкие среды, в которых не используются вызовы инструментов, выполнение кода или поиск по нескольким документам. Остается открытым вопрос, сохранится ли эффективность делегирования с калибровкой по неопределенности в таких более богатых условиях (актуальных для Beancount). А выбор GPT-5.2 в качестве большой модели затрудняет воспроизведение данных о стоимости.

Процедура калибровки содержит неучтенную цикличность: порог выбирается на том же распределении, на котором он калибровался, без отложенной валидации. Авторы признают сдвиг распределения между калибровкой (прогоны малой модели) и оценкой (гибридные прогоны), но оставляют изучение устойчивости порога для будущих работ.

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

Агенты записи в Beancount сталкиваются ровно с тем же вопросом делегирования при каждой транзакции. Обычная покупка продуктов требует категоризации; необычный многоэтапный валютный своп с частично совпадающим примечанием (memo) требует участия человека. Текущая практика — это либо полная автоматизация (рискованно), либо полный ручной обзор (дорого). Фреймворк ReDAct предлагает практически применимый компромисс: запускать дешевую модель и эскалировать задачу, когда перплексия предлагаемой записи в журнале превышает откалиброванный порог.

Финансовый контекст добавляет два соображения, которые не рассматриваются в статье. Во-первых, делегирование здесь часто должно означать остановку и запрос пользователя, а не вызов более крупной LLM — стандартом корректности реестра является намерение пользователя, а не оценка в бенчмарке. Во-вторых, необратимость зафиксированной записи в Beancount выше, чем у неправильно положенного предмета в ALFWorld. Целевой показатель калибровки K, вероятно, должен быть настроен консервативно в сторону более низкой точности на малой модели перед делегированием, а не наоборот.

Сигнал о снижении затрат на 64% стоит воспринимать серьезно даже с этими оговорками. Если агент Beancount обрабатывает транзакции за месяц, и только 15% решений по категоризации требуют дорогой модели, экономика использования способного агента записи выглядит гораздо привлекательнее.

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

• KnowNo (Ren et al., 2023, CoRL): "Robots that ask for help: uncertainty alignment for large language model planners" — использует конформное прогнозирование для калибровки гарантии покрытия того, когда нужно просить о помощи. ReDAct не сравнивается с ним; понимание компромисса между конформными гарантиями и калибровкой порога важно перед выбором подхода для продакшн-системы. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. updated, NAACL 2024) — систематическая таксономия вербализованной уверенности, методов на основе сэмплирования и апостериорной калибровки; теоретическая база для решения вопроса о том, является ли перплексия правильным прокси-показателем неопределенности или калиброванное масштабирование логитов сработает лучше. [arXiv:2311.08298]
• UALA: Uncertainty-Aware Language Agent (Han, Buntine, Shareghi) — применяет структурно схожий порог неопределенности к решению о вызове инструмента (вызвать инструмент или положиться на знания модели), сокращая количество вызовов инструментов более чем на 50%; прямое дополнение к ReDAct в аспекте использования инструментов агентами. [https://uala-agent.github.io/]

Статья​

OpenHands (Wang et al., 2024; ICLR 2025) — это платформа с открытым исходным кодом для создания и оценки LLM-агентов, выступающих в роли универсальных разработчиков ПО. Основное утверждение авторов (команды из 24 человек под руководством Синъяо Ванга и Грэма Ньюбига) заключается в том, что большинство существующих фреймворков для агентов либо слишком узки для исследований (жестко закодированные циклы задач), либо слишком узки для продакшена (закрытый исходный код или узкая специализация), чтобы служить общей основой для сообщества. OpenHands пытается исправить это, предоставляя стандартизированную среду выполнения, чистую абстракцию агента и 15 интегрированных бенчмарков в одном MIT-репозитории.

Среда выполнения представляет собой изолированный Docker-контейнер, содержащий оболочку bash, сервер Jupyter IPython и браузер Chromium под управлением Playwright. Агенты взаимодействуют через три основных типа действий: IPythonRunCellAction для Python, CmdRunAction для команд оболочки и BrowserInteractiveAction для веб-навигации. Примитив координации нескольких агентов, AgentDelegateAction, позволяет основному агенту порождать специализированных субагентов. Дефолтной основой является CodeAct — концепция, изначально опубликованная в виде отдельной статьи, в которой утверждается, что код является идеальным унифицированным пространством действий для LLM-агентов. Платформа поставляется с несколькими реализациями агентов, включая универсальный CodeActAgent и специализированный BrowsingAgent.

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

• Код как универсальное пространство действий: CodeAct объединяет все действия агента (редактирование файлов, вызовы API, преобразование данных) в Python или bash, позволяя LLM рассуждать в той же среде, на которой она обучалась больше всего. Это позволяет избежать хрупкости схем JSON, которая преследует агентов, использующих вызов функций.
• Изолированная среда выполнения в Docker: каждый агент запускается в отдельном контейнере, поэтому он может свободно выполнять произвольный код без угрозы для хост-машины — это обязательное условие для любого финансового агента в продакшене, которому могут быть доверены реальные учетные данные.
• 15 бенчмарков в одной связке: SWE-Bench Lite (исправление кода), HumanEvalFix (исправление багов), WebArena (веб-навигация), GPQA (рассуждения на уровне выпускника вуза), GAIA (решение общих задач) и еще десять. Совместное размещение предотвращает предвзятость при выборе результатов для оценки.
• CodeActAgent + claude-3.5-sonnet достигает 26% на SWE-Bench Lite и 79,3% на HumanEvalFix; BrowsingAgent достигает 15,5% на WebArena — конкурентоспособные результаты zero-shot без специального обучения под конкретные задачи.
• Производительность на GAIA: 32,1% с использованием GPTSwarm, что значительно ниже человеческого уровня в 92% — это согласуется с результатами других бенчмарков для универсальных агентов, показывающих разрыв в 60–70 пунктов между человеком и агентом.
• Масштаб сообщества: 71,4 тыс. звезд на GitHub и более 188 участников на момент подачи статьи на ICLR; TheAgentCompany приняла OpenHands в качестве своей среды оценки, что придало ей статус де-факто стандартной инфраструктуры для бенчмарков.

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

Архитектура изолированной среды выполнения — это солидное инженерное решение. Изоляция выполнения агента в Docker является правильным выбором по умолчанию для любой системы, которой позже может быть предоставлен доступ на запись в реальные финансовые журналы. Также искренне полезно, что бенчмарки собраны вместе, а не разбросаны по несовместимым репозиториям.

Однако охват бенчмарков скорее амбициозен, чем систематичен. 15 бенчмарков охватывают совершенно разные типы задач и уровни сложности без четкой структуры того, как результаты должны агрегироваться или сравниваться. Отчет о 26% на SWE-Bench Lite наряду с 79,3% на HumanEvalFix в одной и той же статье рискует создать впечатление, что один и тот же агент одновременно и посредственный, и превосходный — задачи просто несопоставимы. Авторы не предлагают принципиальной методологии агрегации результатов по нескольким бенчмаркам.

Предположение CodeAct о том, что код является правильным универсальным форматом действий, оспаривается. Это хорошо работает для задач разработки, но накладывает посреднический слой Python/bash на каждое действие, что увеличивает задержку и дает сбои, когда семантика действия не ложится чисто на код (двусмысленные инструкции пользователя, API только на естественном языке). В статье не приводится сравнение с пространствами действий, не основанными на коде, чтобы доказать, что преимущество реально, а не обусловлено мощью самой LLM.

Возможно, самым важным пробелом является разрыв между оценкой и реальным развертыванием. Показатель 26% в SWE-Bench получен на относительно чистом, четко специфицированном бенчмарке. Отчеты сообщества и ветки обсуждений на GitHub постоянно описывают гораздо более низкую надежность в реальных задачах с двусмысленными условиями или длинным горизонтом планирования — тот же режим отказа, который задокументировала TheAgentCompany. В статье не рассматривается вопрос о том, как измерять или повышать устойчивость в условиях зашумленной спецификации задач.

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

OpenHands — это самое близкое к общему фундаменту для агентов, что есть у сообщества. Если Bean Labs будет строить инфраструктуру оценки для Beancount-агентов, архитектуру среды выполнения отсюда — песочница Docker, действия на Python/bash, подключаемые бэкенды LLM — стоит перенять, а не изобретать заново. Примитив AgentDelegateAction естественным образом ложится на конвейер финансового агента, где оркестратор верхнего уровня делегирует задачи специализированным субагентам: одному для чтения гроссбуха, другому для выявления аномалий, третьему для подготовки записей, которые затем проверяет человек.

Цифры SWE-Bench и TheAgentCompany, если читать их вместе, устанавливают отрезвляющую базу: даже лучшие доступные агенты выполняют примерно 26–30% реалистичных, недвусмысленных задач по разработке ПО. Автоматизация финансовых журналов сложнее — транзакции часто двусмысленны, цена ошибки реальна, а намерения пользователя часто не до конца специфицированы. Правильный вывод заключается не в том, что агенты не готовы, а в том, что первыми продуктивными внедрениями будут строго ограниченные рабочие процессы «записи в один проход» (предложения по категоризации, сверка), а не автономное многоэтапное редактирование гроссбуха.

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

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — объединяет дешевую модель с дорогой и передает задачу дорогой модели только при высокой неопределенности; напрямую отвечает на вопрос, как агент в стиле OpenHands должен решать, когда передать запись в Beancount на проверку человеку.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 экспертно размеченных последовательностей задач в 34 финансовых сценариях; методология оценки использования инструментов на длинном горизонте, которой не хватает OpenHands для специфики финансов.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 примеров использования 65 реальных финансовых инструментов MCP; напрямую относится к тому, как Beancount-агент, построенный на базе OpenHands, будет оцениваться в реальном развертывании через MCP.

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

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; понимание ее архитектуры проясняет, какие базовые возможности агентов были доступны, а какие пробелы связаны со сложностью задач, а не с ограничениями платформы.

О статье​

Чанёль Чхве, Джихун Квон и их коллеги из фирмы по финансовому ИИ представляют набор данных из 5 703 аннотированных экспертами триплетов «запрос–доказательство–ответ», полученных из реального сервиса вопросов и ответов для аналитиков хедж-фондов. Документы представляют собой отчеты по форме 10-K 490 компаний из индекса S&P 500, собранные из базы SEC EDGAR. Что отличает FinDER от предыдущих бенчмарков, так это характер запросов: 89,86% из них содержат три или более специфических для отрасли аббревиатуры или акронима. Вместо «Какова общая выручка компании X за 2023 финансовый год?» реальный аналитик может написать «GOOGL 10-K FY23 выручка разбив по сегм.». Набор данных был опубликован на семинаре ICLR 2025 «Достижения в финансовом ИИ» и позже появился на 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-пунктовый разрыв между реалистичными условиями и «оракулом» больше, чем разрыв между открытыми и передовыми моделями.
• Составная арифметика не справляется даже при хорошем поиске: Задачи на многошаговые вычисления (составные запросы) достигают лишь ~20% точности на всех четырех моделях — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill и Qwen-QWQ — даже при наличии 10 лучших найденных фрагментов. GPT-o1 лидирует в задачах на умножение с результатом 42,90%, но падает до 27,78% при делении.
• Переранжирование с помощью 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). Это коррелирует со структурой запроса: раскрытие рисков использует естественный язык, финансовые таблицы — плотную числовую нотацию.

Что выдерживает критику, а что нет​

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

Самое слабое место статьи — воспроизводимость. На момент публикации набор данных не был общедоступным — авторы заявляют, что «планируют выпустить его публично позже». Это серьезная проблема для статьи с семинара, претендующей на статус стандарта оценки. Бенчмарки, которые не опубликованы, — это не бенчмарки, а тематические исследования (case studies). С тех пор работа появилась на ICAIF 2025, так что релиз мог состояться, но версия на arXiv этого не подтверждает.

Оценка поиска также использует только четыре одноэтапные модели (BM25, GTE, mE5, E5-Mistral). Нет гибридного поиска, нет расширения запросов, нет HyDE, нет этапа перезаписи, направленного именно на проблему аббревиатур. Учитывая, что авторы точно охарактеризовали разрыв из-за сокращений, удивительно, что они не протестировали очевидное решение: развертывание запроса («GOOGL» → «Alphabet Inc.») перед поиском. Этот эксперимент отсутствует.

Результаты генерации заслуживают более внимательного прочтения. Показатель в ~9–10% без контекста не является полезной нижней границей — это практически ноль — но потолок «оракула» в 60–68% более информативен, чем кажется. Даже имея на руках правильный фрагмент, лучшие модели терпят неудачу примерно в одной трети качественных вопросов и в четырех пятых задач на составную арифметику. Этот потолок важен: он означает, что поиск сам по себе не решит проблему.

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

Распределение запросов в FinDER хорошо проецируется на то, как пользователи Beancount на самом деле взаимодействуют с агентом главной книги. Пользователь, который годами ведет свои счета, будет вводить сокращенные, контекстные запросы — «AMZN карта Q3 возм?» вместо «Каковы возмещения по кредитной карте Amazon в третьем квартале?». Стандартные модели эмбеддингов не смогут найти нужные записи, потому что они обучались на чистом тексте на естественном языке. Падение точности на 8,2 пункта при переходе от чистых запросов к реальным, вероятно, является консервативной оценкой для домена личных финансов, где специфические сокращения («упр недв сб» для «сбора за управление недвижимостью») еще дальше от обучающих данных, чем стандартные аббревиатуры SEC.

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

Точность составной арифметики в 20% даже с оракульным контекстом — это отдельный сигнал: для вычислительных задач в Beancount «узким местом» генерации являются рассуждения, а не поиск. Вынос вычислений в стиле PAL (генерация кода на Python вместо текстового расчета) остается правильным ответом для числовых задач, независимо от того, насколько хорошим станет поиск.

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

• Fin-RATE (arXiv:2602.07294) — сопутствующий бенчмарк для многопериодного отслеживания по отчетам SEC; точность падает на 18,60% в задачах, связанных со временем, что напрямую отражает проблему многолетних журналов Beancount.
• IRCoT (arXiv:2212.10509, ACL 2023) — чередование поиска с рассуждениями в стиле цепочки мыслей; структура многопроходного поиска напрямую решает проблему низкой полноты за один проход, выявленную в FinDER.
• Расширение запросов с помощью LLM для специализированного поиска — пока нет единого бенчмарка, который бы хорошо это освещал, но разрыв в аббревиатурах FinDER делает это первоочередным приоритетом исследований; поиск по запросам «HyDE financial domain» и «query expansion SEC filings 2025» будет правильной отправной точкой.

Статья​

«Затерянные посередине: как языковые модели используют длинные контексты» Нельсона Ф. Лю, Кевина Лина, Джона Хьюитта, Ашвина Паранджапе, Микеле Бевилакуа, Фабио Петрони и Перси Ляна описывает два целевых эксперимента: ответы на вопросы по нескольким документам на базе NaturalQuestions-Open (с 10, 20 и 30 извлеченными документами) и синтетический поиск пар «ключ-значение» (с 75, 140 и 300 парами). В каждом эксперименте они систематически меняли положение релевантного документа или пары «ключ-значение» внутри входного контекста — начало, середина или конец — при сохранении всех остальных параметров. Вывод однозначен: производительность описывает U-образную кривую с провалом в середине контекста, и эта кривая проявляется у всех протестированных моделей.

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

• U-образная форма реальна и стабильна. В сценарии QA с 20 документами точность в первой позиции составила около 75%, снизилась до примерно 55% на 10-й позиции и восстановилась до 72% на 20-й позиции — разрыв между краями и центром составил около 20 пунктов.
• Все модели следуют одной и той же схеме. Протестированные модели включают как закрытые, так и открытые, малые и большие: GPT-3.5-Turbo (4K и 16K), GPT-4, Claude-1.3 (8K и 100K), MPT-30B-Instruct и LongChat-13B. U-образная кривая проявилась в каждой из них, включая модели, явно позиционируемые как имеющие расширенные окна контекста.
• Даже Claude-1.3-100K не застрахован. Вариант со 100K-контекстом вел себя так же, как и остальные. Длинное окно контекста не означает, что модель действительно распределяет внимание равномерно по нему.
• Базовый уровень «закрытой книги» отрезвляет. GPT-3.5-Turbo без каких-либо документов правильно ответила на 56,1% вопросов NaturalQuestions; при наличии прямого доступа только к одному релевантному документу результат достиг 88,3%. Но в худших средних позициях в сценарии с 20 документами производительность упала ниже уровня «закрытой книги» — это означает, что добавление контекста было активно вредным.
• Модели энкодер-декодер (Flan-T5-XXL, Flan-UL2) более надежны в пределах своей тренировочной длины, но возвращаются к той же схеме, когда контекст ее превышает. Архитектурное различие имеет значение, но оба типа все равно деградируют при масштабировании.
• Коренная причина — причинная маскировка внимания. Каждый токен может обращаться только к предшествующим токенам, поэтому позиции в самом начале накапливают больший суммарный вес внимания во всей модели, чем позиции в середине. Эффекты недавности также подтягивают вверх показатели в конце контекста.

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

Экспериментальный дизайн здесь восхитительно чист: позиция — единственная переменная, задачи являются стандартными бенчмарками, а результат воспроизводится в широком диапазоне семейств моделей. У меня нет возражений против основного результата.

Что мне кажется менее убедительным, так это представление задачи поиска «ключ-значение» как значимого прокси для реального использования. Поиск UUID-в-UUID проверяет, может ли модель повторить заученную строку, а не способна ли она на логические рассуждения. U-кривая проявляется и там, что подкрепляет тезис о позиционном смещении, но это также означает, что в статье смешиваются два разных явления: точность извлечения в задачах на точное совпадение и качество рассуждений над релевантными фрагментами. Мне было бы интересно узнать, ухудшается или улучшается U-образная форма, когда релевантный документ требует многошагового логического вывода перед окончательным ответом, а не просто дословного воспроизведения.

Также есть пробел, который авторы в основном признают, но не устраняют: они так и не проверили, меняет ли тонкая настройка инструкций или RLHF чувствительность к позиции, проверив только влияние размера окна контекста. Учитывая, что коренная причина архитектурная (причинная маскировка), я подозреваю, что настройка инструкций это не исправит, но статья этого не подтверждает.

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

Эта статья дает механистическое объяснение эмпирической закономерности, с которой я постоянно сталкиваюсь. DocFinQA провалилась на длинных документах SEC. IRCoT и FLARE извлекают несколько фрагментов и объединяют их перед рассуждением. Каждый пайплайн RAG, который я видел в финансовом контексте, последовательно сбрасывает извлеченные фрагменты в промпт и надеется, что модель обратит внимание на нужный.

Вывод для агентов Beancount вполне конкретен. Если агент извлекает десять записей реестра в качестве контекста, записи в позициях 3–7 подвергаются наибольшему риску быть проигнорированными или вызвать галлюцинации. Это проблема не извлечения, а представления. Из этой статьи следуют два решения: либо ставить наиболее диагностически важные записи первыми (и последними), либо вообще не объединять их и проводить рассуждения по одному фрагменту за раз.

Результаты также усложняют риторику вокруг LLM с длинным контекстом. Каждый квартал новая модель объявляет об увеличении окна контекста. Эта статья говорит о том, что длинное окно не означает то, что вы думаете, если вы равномерно распределяете доказательства в нем. Модель с контекстом 128K, которая прячет релевантную транзакцию на 60-й тысяче токенов, хуже, чем модель с контекстом 4K, которая извлекает именно тот фрагмент, который нужен.

Для безопасности обратной записи последствия неутешительны: если модель просят обобщить сессию работы с реестром, а соответствующее правило политики «не проводить эту транзакцию» оказывается в середине длинного системного промпта, модель может повести себя так, будто она никогда не читала это правило.

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

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" («Найдено посередине: как языковые модели лучше используют длинные контексты с помощью подключаемого позиционного кодирования», Zhang и др., arXiv:2403.04797) — предлагает многомасштабное позиционное кодирование (Ms-PoE) как исправление без переобучения через масштабирование RoPE; заявляет об улучшении до 3,8 пункта на Zero-SCROLLS, напрямую решая проблему U-кривой.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" («Никогда не теряться посередине: мастерство ответов на вопросы в длинном контексте с помощью декомпозиционного обучения, не зависящего от позиции», arXiv:2311.09198) — использует противоположный подход и обучает модель быть явно независимой от позиции; сравнение с Ms-PoE проясняет, является ли тонкая настройка или ухищрения на этапе вывода лучшим инструментом.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" («Смягчение позиционного смещения в больших языковых моделях путем масштабирования одного измерения», arXiv:2406.02536) — выявляет конкретное измерение скрытых состояний позиций, ответственное за смещение, и масштабирует его без переобучения; самое хирургическое исправление, предложенное на данный момент, актуальное для развертывания существующих моделей без переобучения.

Научная работа​

Тянькай Ян, И Нянь и их коллеги из USC и Texas A&M представили AD-LLM (arXiv:2412.11142, ACL Findings 2025) — первый бенчмарк для систематической оценки LLM в трех парадигмах обнаружения аномалий на наборах данных NLP. Условия задачи — одноклассовая классификация: обучающие данные содержат только нормальные образцы, а модель должна выявлять аномалии во время тестирования. Пять наборов данных — AG News, BBC News, IMDB Reviews, N24 News и SMS Spam — получены из задач классификации текста, где одна из категорий обозначена как аномальная. В работе сравниваются две LLM, GPT-4o и Llama 3.1 8B Instruct, с 18 традиционными неконтролируемыми (unsupervised) базовыми моделями, которые включают как сквозные методы (CVDD, DATE), так и двухэтапные комбинации «эмбеддинги + детектор» (эмбеддинги OpenAI + LUNAR, LOF, Isolation Forest и др.).

Основные идеи​

• Обнаружение в режиме Zero-shot хорошо работает для текста. GPT-4o показывает AUROC от 0,9293 до 0,9919 на пяти наборах данных в режиме «Норма+Аномалия»; Llama 3.1 достигает 0,8612–0,9487. Лучшая традиционная базовая модель, OpenAI + LUNAR, набирает около 0,92 на AG News — GPT-4o сравнивается с ней или превосходит её без всякого обучения.
• Синтетическая аугментация помогает стабильно, но умеренно. Синтетические образцы, сгенерированные LLM, улучшают конвейер OpenAI + LUNAR на всех пяти наборах данных. Аугментация описаний категорий также улучшает большинство базовых моделей, хотя результаты неоднородны — Llama 3.1 увеличивает AUROC на +0,07 на IMDB Reviews, но в других местах прирост меньше.
• Выбор модели — слабое звено. GPT-o1-preview рекомендует модели, которые превосходят среднюю базовую производительность на большинстве наборов данных, а иногда приближаются к лучшему методу (например, на IMDB Reviews и SMS Spam). Однако она ни разу не смогла надежно определить лучшую модель, и авторы признают, что рекомендации основаны на упрощенных входных данных, в которых отсутствуют специфические статистические показатели датасета.
• Разрыв между открытым ПО и проприетарными моделями реален. Преимущество GPT-4o по AUROC над Llama 3.1 8B составляет 4–13 пунктов в зависимости от набора данных. Этот разрыв соответствует паттерну, наблюдаемому в работах по обнаружению аномалий в табличных данных в режиме zero-shot.
• В области обнаружения аномалий NLP все еще не хватает окончательного бенчмарка. Пять наборов данных, производных от корпусов для классификации, — это мало. Сопутствующая работа NLP-ADBench (EMNLP Findings 2025) расширяет список до восьми наборов данных и 19 алгоритмов, но по-прежнему использует ту же конструкцию «семантическая категория как аномалия», что делает эти задачи несколько искусственными.

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

Результаты zero-shot выглядят убедительно. Использование LLM в качестве оценщиков без дообучения на размеченных данных аномалий действительно полезно, когда класс аномалий семантически связен — спам-сообщение отличается от обычного SMS так, как это понимает хорошо обученная языковая модель. Показатели AUROC высоки, а сравнение с сильными базовыми моделями на основе эмбеддингов OpenAI является честным.

Однако сфера применения ограничена, что в статье несколько приуменьшается. Во всех пяти наборах данных аномалии закодированы как иная тематическая категория — спам против легитимных SMS, новости от стороннего издателя против новостей из основной выборки. Это означает, что LLM, по сути, выполняет тематическую классификацию — задачу, на которой она была специально предварительно обучена. Бенчмарк не включает семантические аномалии внутри одной категории (например, необычные транзакции внутри одного типа счета), а ведь именно такие аномалии важны для финансового аудита.

Задачи аугментации данных и выбора моделей оцениваются на тех же пяти датасетах, поэтому статья в итоге проверяет, могут ли LLM немного улучшить решение одной и той же узкой проблемы. Авторы честно перечисляют шесть ограничений — включая то, что они тестируют лишь подмножество LLM, исключают режимы few-shot и дообучения, и полагаются на упрощенные входные данные для выбора моделей. Это подчеркивает предварительный характер данного бенчмарка.

Один результат стоит отметить для скептиков: показатели AUPRC существенно ниже AUROC для обеих моделей. Llama 3.1 на BBC News достигает AUROC 0,8612, но лишь 0,3960 AUPRC, что отражает дисбаланс классов в одноклассовой постановке задачи. В контексте высокоточного аудита AUPRC является более значимой метрикой, и здесь картина выглядит менее радужной.

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

Повестка Bean Labs включает два сценария обнаружения аномалий: выявление необычных записей в бухгалтерской книге в реальном времени (табличные, структурированные данные) и маркировка подозрительного повествовательного текста в инвойсах, меморандумах или тикетах поддержки (неструктурированный NLP). AD-LLM напрямую относится ко второму случаю и дает нам реалистичный «потолок»: GPT-4o может в режиме zero-shot обнаруживать тематические аномалии в тексте с AUROC выше 0,93 на чистых, сбалансированных данных. Это полезный ориентир, но аномалии в описаниях проводок более тонкие: меморандум к счету, который описывает рутинную услугу, но относится к поставщику, замеченному в подозрительных схемах, не является проблемой тематической классификации. Бенчмарк дает отправную точку, но не готовый ответ.

Вывод о выборе моделей интересен отдельно для проектирования систем. Мечта о том, чтобы спросить у LLM «какой детектор аномалий мне использовать для этого набора данных?» и получить надежный ответ, пока не сбывается. Это означает, что выбор между дообучением в стиле AnoLLM, причинно-следственными промптами в стиле CausalTAD или классическим методом эмбеддингов по-прежнему требует человеческого суждения или систематической эмпирической оценки — это нельзя делегировать советнику на базе LLM.

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

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025) — сопутствующий бенчмарк от той же группы, охватывающий восемь наборов данных и 19 алгоритмов; предоставляет более широкий контекст классических базовых моделей, который не может обеспечить AD-LLM.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025) — обзор всего ландшафта подходов к обнаружению аномалий на базе LLM для текста, изображений и таблиц; помогает понять место AD-LLM относительно предыдущих работ.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — табличный аналог; сравнение его подхода на основе логарифмического правдоподобия (likelihood) со стратегией zero-shot на основе промптов в AD-LLM проясняет, какая парадигма больше подходит для записей в реестре Beancount.

О статье​

Ванг и др. предлагают CausalTAD — метод, который надстраивается над детекторами аномалий типа AnoLLM и вносит одно целевое изменение: вместо сериализации строк таблицы в случайном или произвольном порядке столбцов, он обнаруживает каузальные (причинно-следственные) зависимости между ними и переупорядочивает их с учетом этих зависимостей перед тем, как LLM прочтет строку.

Работа состоит из двух функциональных частей. Первая — модуль каузального упорядочивания столбцов. Авторы адаптируют фреймворк извлечения факторов COAT: LLM считывает метаданные столбцов и образцы данных для извлечения семантических факторов высокого уровня (например, для транзакций по кредитным картам фактор «Компенсация» может объединять столбцы суммы и продавца). На основе этих факторов три алгоритма каузального обнаружения — PC, LiNGAM и FCI — строят ориентированные графы причинности. Проблема переупорядочивания столбцов превращается в задачу линейного упорядочивания: найти перестановку π, максимизирующую сумму весов ориентированных ребер так, чтобы столбцы-причины шли перед столбцами-следствиями в сериализованном тексте. Поскольку задача линейного программирования имеет много близких к оптимальным решений, они выбирают K ≈ 10 вариантов упорядочивания в пределах 90% от оптимума и усредняют результат.

Вторая часть — модуль перевзвешивания с учетом каузальности. Не все столбцы одинаково важны. Столбец, влияющий на множество факторов, получает более высокий вес αj = |M⁻¹(cj)|, соответствующий количеству факторов, в которые он вносит вклад. Итоговая оценка аномальности — это средневзвешенное значение отрицательных логарифмических правдоподобий по столбцам для K вариантов упорядочивания.

Основные идеи​

• Порядок столбцов — это нетривиальное индуктивное смещение для авторегрессионных LLM: размещение столбца-причины перед столбцом-следствием позволяет модели опираться на правильный контекст при присвоении правдоподобия следствию.
• Каузальное обнаружение на уровне факторов (а не на уровне исходных столбцов) позволяет методу обрабатывать таблицы смешанного типа, где прямое каузальное обнаружение между разнородными столбцами затруднено из-за шума.
• На 6 бенчмарках со смешанными типами данных CausalTAD с использованием SmolLM-135M достигает среднего AUC-ROC 0,834 против 0,803 у AnoLLM — абсолютное улучшение на 3,1 пункта при использовании той же базовой модели.
• В частности, на датасете Fake Job Posts CausalTAD показывает результат 0,873 против 0,800 у AnoLLM — относительный прирост 9,1%, что достаточно существенно для реальных систем сортировки данных.
• В 30 числовых бенчмарках ODDS CausalTAD достигает лучшего среднего AUC-ROC, стабильно превосходя классические базовые решения (Isolation Forest, ECOD, KNN) и глубокие методы (DeepSVDD, SLAD).
• Все три алгоритма каузального обнаружения превзошли случайное упорядочивание в абляционном исследовании; LiNGAM незначительно опередил PC и FCI на наборах данных смешанного типа.

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

Основное утверждение — о том, что каузальный порядок столбцов помогает — хорошо обосновано. Абляционное исследование проведено чисто: замена случайного порядка любым из трех методов каузального обнаружения улучшает результаты в бенчмарке Fake Job Posts (с 0,832 до 0,870–0,873), а перевзвешивание по количеству факторов дает дополнительный прирост в каждой конфигурации. Это выглядит убедительно.

Менее убедительным мне кажется предположение о самозагрузке (bootstrapping). Каузальный граф строится с использованием LLM для извлечения семантических факторов из тех самых данных, которые система должна анализировать. Если LLM неверно поймет предметную область — скажем, специфическую систему учета с нестандартными именами столбцов — извлечение факторов будет ошибочным, а плохой каузальный граф, пожалуй, хуже случайного порядка, так как вносит систематическую ошибку. Авторы признают этот риск («зависит от способности LLM извлекать факторы»), но не тестируют точность извлечения факторов отдельно.

Также существует проблема вычислительных затрат, которая серьезнее, чем представлено в статье. Запуск трех алгоритмов каузального обнаружения, решение задачи линейного программирования, выборка K вариантов порядка и последующий инференс на K сериализованных версиях каждой тестовой точки умножает стоимость инференса на K. Для бухгалтерской книги с миллионами записей это критично. В статье отмечается, что «будущая работа может быть сосредоточена на повышении эффективности», но конкретных профилей производительности не приводится.

Наконец, 30 числовых датасетов ODDS хорошо изучены и, возможно, уже исчерпаны для подобных методов. Более значимый сигнал дают 6 датасетов смешанного типа — они более реалистичны для финансов — и улучшения там, хотя и реальные, в абсолютном выражении выглядят умеренными.

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

Транзакции Beancount обладают подлинной каузальной структурой: сумма проводки каузально определяет выбор счета, счет определяет ожидания по контрагенту, а текст примечания каузально зависит от всех трех факторов. Случайная сериализация столбцов игнорирует это, а значит, модель типа AnoLLM видит вариант «memo: groceries | account: Expenses:Food | amount: $4200» так же часто, как и правильно упорядоченную версию.

CausalTAD предлагает принципиальный способ кодирования правила «сумма и счет идут первыми» без жесткого прописывания его в коде. Для аудиторских агентов Bean Labs это предполагает практический архитектурный выбор: перед оценкой пакета транзакций на наличие аномалий выполнить один проход для поиска каузального графа по схеме столбцов книги, а затем использовать этот фиксированный порядок для всех последующих выводов. Затраты на вычисления оплачиваются один раз на уровне схемы, а не за каждую транзакцию.

Пример обнаружения мошенничества с кредитными картами в статье по структуре задачи идентичен поиску аномалий в бухгалтерских книгах: разнородные признаки, редкие метки и каузальный порядок, который эксперты в предметной области знают интуитивно, но который LLM без подсказки могут проигнорировать.

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

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — систематический бенчмарк по трем парадигмам обнаружения аномалий с помощью LLM, в который вписывается CausalTAD; дает полную картину вместо сравнения только AnoLLM и CausalTAD.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — фреймворк извлечения факторов, адаптированный в CausalTAD; понимание его работы проясняет, в каких моментах качество каузального графа может пострадать.
• Causal discovery in heterogeneous data: a survey — для понимания относительных преимуществ PC, LiNGAM и FCI при работе с табличными данными смешанного типа, поскольку в статье они рассматриваются как взаимозаменяемые, хотя делают разные предположения о независимости.

Статья​

AnoLLM переосмысляет обнаружение аномалий в таблицах как оценку плотности вероятности языковой моделью, а не как классификацию через промпты. Вместо того чтобы просить LLM назвать подозрительные строки, авторы дообучают (fine-tune) предобученную языковую модель на сериализованных тренировочных строках из основного распределения (нормальных), а затем оценивают каждую тестовую строку по ее отрицательному логарифмическому правдоподобию (NLL) в рамках изученного распределения. Строка, которая совсем не похожа на тренировочное распределение, получает высокий показатель NLL — это и есть оценка аномальности. Никаких форматов индексов, никакого парсинга вывода, никакой хрупкой экстракции через регулярные выражения.

Сериализация преобразует каждую строку таблицы в строку на естественном языке с именами признаков и их значениями. Для текстовых столбцов NLL нормализуется по столбцам, чтобы избежать смещения из-за длины, иначе более длинные описания механически накапливали бы более высокие штрафы вероятности. Для числовых и категориальных столбцов сырой NLL на уровне токенов суммируется по всему полю. Модель дообучается в полуавтоматическом режиме (semi-supervised) — в обучение попадают только строки с меткой «нормально» — до 2000 шагов с использованием распределенного обучения на GPU.

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

• Проблема формата вывода: предыдущие подходы с предсказанием индексов требуют от LLM надежного вывода индексов аномальных строк из пакета данных. Модели семейства Llama часто привязывают неверные индексы к значениям, генерируют индексы за пределами размера пакета или просто перечисляют все подряд как аномалию. NLL полностью обходит эту проблему.
• AnoLLM достигает наилучшей производительности на шести эталонных наборах данных со смешанными типами признаков, включая обнаружение мошенничества в автостраховании и наборы данных о мошенничестве в электронной коммерции с Kaggle.
• На 30 преимущественно числовых наборах данных бенчмарка ODDS AnoLLM работает на уровне лучших классических базовых моделей — не явно лучше, а просто конкурентоспособно.
• Нормализация NLL по столбцам для текстовых признаков — это небольшое, но критически важное инженерное решение: без него описание транзакции из тридцати токенов доминировало бы в оценке над двузначной суммой, что является неверным индуктивным смещением.
• Контекст базового обучения: zero-shot подход GPT-4 (arXiv:2406.16308) достигает среднего AUROC 74.1 на ODDS, что сопоставимо с ECOD (75.5) и KNN (70.7). Преимущество AnoLLM проявляется именно на наборах данных, где текстовые и категориальные признаки несут значимый сигнал об аномалии.

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

Основная идея NLL здравая. Использование дообученной языковой модели в качестве оценщика плотности над сериализованными строками принципиально верно, и оно естественным образом обрабатывает совместное распределение всех столбцов одновременно — то, что классические детекторы без учителя, применяемые столбец за столбцом, не могут сделать чисто. Исправление проблемы с предсказанием индексов действительно полезно, а сравнение с zero-shot базой выглядит честным.

Меня беспокоит разрыв между затратами и выгодой, о котором в статье сообщается недостаточно подробно. AnoLLM требует дообучения и обслуживания LLM для инференса — это существенные инфраструктурные обязательства по сравнению с запуском ECOD или IsolationForest на CPU за считанные секунды. На бенчмарке ODDS (чисто числовом) AnoLLM лишь «на уровне», но не лучше. Таким образом, аргументы в пользу AnoLLM лежат исключительно в плоскости смешанных типов данных, где шесть оцененных наборов данных взяты из задач по обнаружению мошенничества на Kaggle. Шесть датасетов — это тонкий эмпирический фундамент для сильной рекомендации, особенно учитывая, что наборы данных с Kaggle, как правило, имеют чистые схемы, фиксированную семантику столбцов и известную истину (ground truth) — все то, чего часто не хватает реальным данным из журналов учета (ledger data).

Проблема порядка столбцов также остается открытой. CausalTAD (arXiv:2602.07798) немедленно выявила этот пробел: AnoLLM сериализует столбцы в произвольном порядке, игнорируя причинно-следственные связи между полями. Для структурированных данных с известными причинно-следственными цепочками — например, тип счета влияет на допустимые диапазоны транзакций, которые влияют на ожидаемого контрагента — это реальное ограничение. CausalTAD формулирует переупорядочивание как задачу линейного упорядочивания и сообщает о стабильном улучшении по сравнению с AnoLLM на более чем 30 наборах данных. То, что этот пробел существовал и был так быстро обнаружен, наводит на мысль, что дизайн сериализации в AnoLLM не был до конца продуман.

Существует также вопрос масштабируемости, который в статье не рассматривается: при каком объеме нормальных обучающих примеров дообучение LLM становится выгоднее, чем, скажем, табличная модель глубокого обучения, обученная непосредственно на числовых признаках? Для личных журналов Beancount с несколькими тысячами записей стоимость вычислений может легко перекрыть любой выигрыш в точности.

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

Записи в журнале Beancount — это именно тот тип смешанных данных, на который нацелена AnoLLM: суммы (числовые), названия счетов (структурированный текст), получатель/описание (произвольный текст), теги (категориальные), даты (структурированные). Одна строка вида 2024-03-15 * "AWS" "Cloud invoice" Assets:Checking -$2,400 кодирует информацию по всем этим типам одновременно. Классические детекторы аномалий здесь пасуют, потому что им нужна отдельная обработка для каждого типа столбцов, и они теряют корреляции между ними — совместный паттерн того, что счета от "AWS" должны быть в определенном диапазоне и списываться с конкретного счета.

Подход NLL в AnoLLM, в принципе, должен выучить эти совместные паттерны из обычных исторических записей и помечать отклонения в любой комбинации столбцов. Это потенциально полезнее, чем проверки на основе правил (JETs) или статистические тесты одного столбца.

Тем не менее, ограничение двойной записи — это структурное знание, которое AnoLLM не может выучить только из сериализованных строк: дебет должен быть равен кредиту, иерархия счетов должна соблюдаться. Эти доменные инварианты являются жесткими ограничениями, а не статистическими закономерностями, и никакое дообучение LLM на исторических строках не заставит модель соблюдать их надежно, если в обучающих данных есть исключения или артефакты округления. Правильная архитектура, вероятно, должна сочетать оценку NLL от AnoLLM для семантических аномалий с явными проверками правил для структурных отклонений.

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

• CausalTAD (arXiv:2602.07798) — напрямую улучшает AnoLLM, внедряя причинно-следственный порядок столбцов; самое актуальное продолжение темы.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — предоставляет систематическую многопарадигмальную оценку, которой не хватает в статьях по отдельным методам.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) — модель BE-GREAT, которую AnoLLM использует в качестве базы; ее понимание проясняет, что именно AnoLLM улучшает помимо предсказания индексов.

Статья​

Фигероа, Грундманн, Фрейданк, Лёзер и Недль оценивают пять моделей с открытыми весами (~7B) на бенчмарке из двух задач под названием LLMFinLiteracy. Задача 1 просит модели создать текстовые сценарии, которые повлияли бы на заданный коэффициент ликвидности (текущей, быстрой или абсолютной) на основе реального квартального баланса одной из пяти компаний индекса DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). Задача 2 требует перевести эти сценарии в компилируемые транзакции Beancount. Компилятор Beancount служит инструментом проверки синтаксиса; эксперты в предметной области оценивают семантическую корректность. В статье вводится таксономия ошибок из 12 классов для двух задач и используется 9-шаговый промпт «цепочка рассуждений», включающий правила двойной записи, пример ввода/вывода и реальный баланс компании в формате Beancount. Оцениваемые модели — Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B и CodeQwen-1.5-7B — запускались локально из-за конфиденциальности финансовых данных. Корпус включает 1500 сгенерированных образцов, из которых 300 стратифицированных записей были проверены людьми-экспертами.

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

• Только 7 из 300 оцененных пар «сценарий-транзакция» (2,3%) были полностью верными от начала до конца; даже ограничение выборки тремя моделями общего назначения поднимает этот показатель лишь до 3,8%.
• Две лучшие модели, Qwen-2-7B и Mistral-7B, создают правильные сценарии только в 21,67% и 20,00% случаев, а корректно компилируемые транзакции — лишь в 16,67% и 10,00% случаев.
• Специализированные на коде модели (CodeLlama, CodeQwen) набрали 0% в обеих задачах; они ответили на шаблон промпта буквальной строкой «Processed — Waiting for next input», полностью проигнорировав задание.
• Синтаксис не является узким местом: ни одна модель не допустила ни одной синтаксической ошибки. Ошибки лежат исключительно в плоскости бухгалтерской логики — ошибки баланса доминируют у Qwen-2 (61,67%) и Llama-3 (38,33%), в то время как Mistral чаще ссылается на счета, которых нет в предоставленном балансе (45% ошибок неизвестных счетов).
• Значительная часть транзакций, которые успешно компилируются, семантически неверны — излюбленный трюк моделей заключается в том, чтобы назвать уменьшение обязательства «продажей долга», что увеличивает наличность, но по неверной причине.
• GPT-4o, использованная в качестве автоматического судьи, не смогла выявить несоответствия во всех 10 абсурдных сценариях, которые ей показали, подтверждая, что самопроверка LLM не является надежным фильтром качества для бухгалтерских данных.
• Модели в основном копируют пример ввода/вывода из промпта вместо обобщения: 7 верных пар очень похожи на структуру предоставленного примера транзакции.

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

Основной эмпирический вклад статьи солиден. Компилятор Beancount — это объективный, воспроизводимый критерий правильности, а использование реальных балансов компаний вместо игрушечных данных добавляет экологической валидности. Иерархическая таксономия ошибок продумана — прекращение оценки на первой же ошибке позволяет избежать начисления «частичных баллов» за мусорные выходы.

Тем не менее, есть очевидные ограничения, которые авторы в основном признают. Пять моделей с открытыми весами ~7B образца 2023–2024 годов — это лишь узкий срез возможностей современных ИИ; GPT-4o и Claude были исключены из соображений конфиденциальности, что объяснимо, но означает, что общая цифра (2,3% успеха) занижает показатели передовых моделей. Формулы финансовых коэффициентов намеренно не включались в промпты для проверки внутренних знаний предметной области — методологически интересный выбор, но он делает результаты несопоставимыми с любой реальной системой, где документация по формулам была бы доступна. Кроме того, 300 проверенных экспертами образцов на пять моделей, три коэффициента и пять компаний — это скромно; выборки на уровне «модель-коэффициент» слишком малы (12 образцов) для серьезных выводов о дисперсии.

Самый интересный методологический пробел — отсутствие итеративного протокола или протокола на основе обратной связи. Ни вызова инструментов, ни самокоррекции, ни цикла обратной связи с компилятором — только генерация в один проход. Учитывая, что CRITIC (LOG-012) и связанные работы показывают, что итеративное уточнение с инструментами существенно повышает точность в задачах с проверяемым результатом, эксперимент с «компилятором Beancount в цикле» дал бы гораздо больше информации о возможности практического применения.

Почему это важно для Finance AI​

Каждое проектное решение для агента записи Bean Labs опирается на предположения о том, что LLM могут делать с Beancount DSL. Эта статья — первая эмпирическая точка опоры. Основные выводы отрезвляют, но они также поддаются полезной интерпретации.

Во-первых, типы ошибок специфичны, а не случайны. Ошибки баланса и неизвестные счета — две доминирующие проблемы, и обе решаемы с помощью цикла обратной связи с компилятором: компилятор Beancount точно говорит, какой счет неизвестен и сбалансирована ли транзакция. Архитектура агента, которая итерирует на основе вывода компилятора, а не генерирует один раз и останавливается, должна существенно превзойти результаты прогона в один этап. Во-вторых, синтаксис дается «бесплатно». Модели явно усвоили поверхностную грамматику Beancount; они просто не могут надежно перевести финансовое намерение в правильное движение по счетам. Это различие важно для того, во что инвестировать: в промптинг или в дообучение (fine-tuning). В-третьих, вывод о том, что GPT-4o не может автоматически оценивать качество бухгалтерского учета, повышает планку для любых систем автоматической верификации: вам нужен компилятор плюс выборочные проверки экспертами, а не критик-LLM.

Статья также подтверждает то, что я подозревал в работе по обнаружению аномалий (LOG-049): LLM, работающие с финансовыми транзакциями, слишком охотно компилируют и отправляют данные. Категория «Неверно | Компилируется» — транзакции, которые проходят проверку синтаксиса, но семантически ошибочны — это именно тот сценарий отказа, который должен ловить защитный барьер агента записи. Транзакция может идеально сходиться по балансу и при этом записывать выручку как уменьшение обязательств, что не будет обнаружено никакой чисто синтаксической проверкой.

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

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — оценка аномалий на основе правдоподобия как альтернатива пакетному обнаружению; естественно сочетается с сигналом компилятора Beancount для выявления структурно валидных, но статистически аномальных записей.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — перенаправляет решения с низкой уверенностью на более крупную модель или человеку; напрямую касается вопроса о том, когда агент записи Beancount должен передать задачу на проверку человеку вместо продолжения цикла обратной связи с компилятором.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — наиболее релевантная работа для создания агента коррекции с компилятором в цикле поверх архитектуры, оцениваемой в данной статье.