Про статтю​

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

Ключові ідеї​

• Мультимодальний пошук домінує над текстовим з величезним відривом: 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). Це топові пропрієтарні моделі з потужними системами пошуку.
• Цитування на рівні сторінок працює, на рівні блоків — ні: Повнота (recall) на рівні сторінок становить 75–93% для найкращих моделей. Повнота на рівні блоків — знання того, яка саме клітинка таблиці або область діаграми обґрунтовує твердження — падає до 20–61%. Це ключовий розрив для можливості аудиту.
• Числові міркування та багатосторінкові висновки ламають моделі першими: Питання, що потребують розрахунків на основі кількох сторінок або часових інтервалів, — це те, де точність падає найстрімкіше у всіх протестованих системах.
• Пропрієтарні моделі суттєво перевершують аналоги з відкритим кодом: Розрив між закритими API та відкритим кодом тут більший, ніж у більшості бенчмарків NLP, що свідчить про те, що візуальні фінансові міркування залишаються невирішеною проблемою для відкритих моделей.
• Автоматичне оцінювання цитування недосконале: Оцінювач цитат на основі обрізання зображень досягає коефіцієнта Пірсона r = 0,68 з людськими оцінками — це прийнятно, але недостатньо надійно, щоб довіряти йому повністю без вибіркової перевірки.

Що витримує критику, а що — ні​

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

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

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

Протокол оцінювання цитування є цікавим внеском, але r = 0,68 з оцінками людей недостатньо сильний показник, щоб вважати автоматичне оцінювання істиною в останній інстанції для заземлення (grounding) на рівні блоків. Автори визнають це; подальша робота над кращими метриками цитування прямо позначена як необхідна.

Чому це важливо для фінансового ШІ​

Beancount працює з текстовими файлами реєстрів (ledger files), що робить текстовий 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% випадків, безпосередньо корелює з проблемою безпеки зворотного запису (write-back safety): агент, який уникає звірки перед дією, — це агент, який діє на основі застарілого або галюцинованого стану. Для автоматизації 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 oral) — переформульовує дизайн робочого процесу як пошук у просторі коду з використанням 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%, що означає, що більшість правильних завершень вимагають більше кроків, ніж необхідно — прямі витрати на затримку та токени для будь-якої виробничої системи.
• Спеціалізовані моделі для використання інструментів поступаються загальним фронтирним моделям: xLAM-2-70B та ToolACE2-8B демонструють частоту помилок із неправильною назвою функції понад 30%, що гірше, ніж у GPT-4o або Claude-4-Sonnet. Тонке налаштування на вузьких корпусах використання інструментів, схоже, створює крихкість, а не стійкість до зсуву розподілу в бік дикої поведінки користувачів.

Що підтверджується, а що — ні​

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

Слабким місцем є масштаб. 1024 завдання з 256 сценаріїв — це гідний дослідницький артефакт, але замало для лідерборду, призначеного для відстеження 57 моделей протягом тривалого часу. Автори прямо визнають це і згадують про автоматизований конвеєр масштабування в майбутніх роботах. Інша проблема полягає в тому, що фраза «засновано на логах реальних користувачів» приховує велику роботу: кінцеві завдання є частково синтетичними, побудованими багатоагентною системою з базових шаблонів, а потім перевіреними людьми-анотаторами. Твердження є обґрунтованим, але дані не є дослівними «дикими» даними — вони натхненні реальністю. Це має значення для того, наскільки буквально варто сприймати стелю у 15%; частина розриву може закритися, якщо конвеєр генерації вносить штучну складність, якої реальні користувачі насправді не проявляють.

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

Чому це важливо для AI у фінансах​

Три режими відмов майже ідеально відображають те, як реальні користувачі взаємодіють з агентом зворотного запису 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 у завданнях, починаючи від QA з вибором варіантів і закінчуючи генерацією відкритого типу та машинним перекладом. Основна проблема: LLM можуть бути як дуже точними, так і абсолютно ненадійними способами, які важко розрізнити ззовні. Огляд організовує простір рішень на дві основні гілки — методи «білої скриньки», які використовують доступ до внутрішніх станів моделі, та методи «чорної скриньки», які розглядають модель як непрозору — і в межах кожної додатково розрізняє оцінку впевненості та її калібрування post hoc.

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

Ключові ідеї​

• Впевненість «білої скриньки» через логіти: Найпростіший підхід використовує ймовірності на рівні токенів або нормалізовану за довжиною логарифмічну правдоподібність як сигнал впевненості. Ці методи працюють, але стикаються з фундаментальною неоднозначністю: низька ймовірність токена може відображати низьку фактичну впевненість або просто незвичне формулювання — модель може бути невпевненою у виборі слів, будучи впевненою в базовому факті.

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

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

• Вербалізована впевненість не працює: Коли моделей просять видати відсоток впевненості, вони впадають у надмірну впевненість. Емпірична робота (Groot et al., TrustNLP на ACL 2024) виявила, що GPT-3, GPT-3.5 і Vicuna демонструють середню очікувану помилку калібрування (ECE), що перевищує 0,377 для вербалізованої впевненості, причому прогнози групуються в діапазоні 90–100% незалежно від фактичної точності. Навіть GPT-4 — найкраще відкалібрована модель серед оцінюваних — досягає AUROC лише ~62,7% при використанні вербалізованої впевненості для розрізнення правильних і неправильних відповідей, що ледь перевищує випадковість.

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

• Єдиного бенчмарку не існує: Найбільш нищівне структурне спостереження огляду: не існує жодного бенчмарку, який охоплював би методи оцінки впевненості в різних завданнях і доменах. Це робить практично неможливим суворе порівняння методів. Галузь порівнює тепле з м'яким.

Що підтверджується, а що ні​

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

Що мене розчаровує в огляді: він переважно описовий. Майже немає експериментальних бенчмарків, які б порівнювали методи безпосередньо, і автори прямо визнають це як обмеження. Я можу піти з чіткою картою простору проектування, але без вказівок щодо того, який метод використовувати для нового завдання.

Результати вербалізованої впевненості — 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, стратифікованих за складністю від тривіальних до ультраскладних, конфігурацій API Kubernetes, схем аналітики подій 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 failures) у тестовому наборі JSON Schema — це означає, що він видає JSON, який порушує заявлену схему, але при цьому мовчки повідомляє про успіх. Guidance має лише 1 таку відмову. Для агента зворотного запису помилка компіляції виявляється під час розробки; відмова через недостатнє обмеження пошкоджує дані під час виконання без будь-якого сигналу.
• Швидке перемотування 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 з температурною вибіркою, що було б важливо для виробничих систем, які використовують повторні спроби при помилках.

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

Чому це важливо для фінансового ШІ​

Кожен агент зворотного запису Beancount генерує структурований вивід. Якщо агент видає директиви Beancount у форматі JSON перед конвертацією в синтаксис .beancount, або якщо він викликає інструменти через схеми JSON, надійність цієї генерації JSON не є просто деталлю — це основа всього процесу. Дослідження FinTrace показало, що передові моделі зазнають невдачі в міркуваннях над результатами інструментів; JSONSchemaBench виявляє паралельну проблему: ще до етапу міркувань шар форматування може непомітно видати невідповідний результат.

Результат із Kubernetes особливо показовий для Beancount. Схеми бухгалтерських книг — це не пласкі набори ключів та значень. Ієрархії рахунків, метадані транзакцій та структури тегів створюють вкладені рекурсивні патерни, схожі на об'єкти API Kubernetes. Фреймворк, який показує 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, які адаптують свій формат виводу залежно від активних типів рахунків.

Дослідження​

Цзе Чжу, Імінь Тянь та колеги з команди Qwen DianJin Alibaba Cloud, 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) та коефіцієнт точного збігу (Exact Match Rate, 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 у всіх субсценаріях, що спростовує припущення, що більша модель завжди краща для багатоступеневого використання інструментів.

Що підтверджується, а що ні​

Використання реальних логів експлуатації як джерела для прикладів з одним інструментом — найсильніший методологічний вибір у цій роботі. Це заземлює бенчмарк у реальну поведінку користувачів, а не в сценарії, вигадані дослідниками, що рідко зустрічається в літературі про ШІ у фінансах. Зразки з кількома інструментами та багатоходові зразки синтетично розширені за допомогою графів залежностей та промптів для рольових ігор, що цілком виправдано, враховуючи вартість маркування, але це створює ризик: процес синтезу зазвичай створює чистіші та більш структуровані запити, ніж ті, що пишуть реальні користувачі. Показник 3,08% EMR у багатоходових завданнях тривожний, але його слід інтерпретувати обережно — EMR вимагає повної правильності всієї послідовності, тому один неправильний проміжний виклик інструменту призводить до невдачі всього завдання. Це суворий і, можливо, нереалістичний стандарт для експлуатації; метрики з частковим зарахуванням, такі як TF1, дають більш нюансовану картину.

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

Бенчмарк також глибоко прив’язаний до конкретних 65 інструментів Qieman, що обмежує можливість перенесення результатів на інші фінансові платформи з іншим набором інструментів.

Чому це важливо для ШІ у фінансах​

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

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

Висновки про те, що повнота викликів перевищує точність (моделі викликають занадто багато інструментів), також важливі для безпеки запису: агент, який викликає інструмент зміни реєстру, коли було потрібно лише читання, може непомітно пошкодити дані. Метрики оцінки, орієнтовані на точність, а не на повноту, повинні бути основним сигналом безпеки для агентів, що мають право запису.

Що почитати далі​

• JSONSchemaBench (arXiv:2501.10868) — оцінює надійність структурованого виводу на 10 тисячах схем 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 — набір даних із 8196 відібраних траєкторій переваг для тонкого налаштування.

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

Ключові ідеї​

• Найкраща модель, Claude-Opus-4.6, досягає показника Tool-Calling F1 0,896 — сильний вибір — але отримує лише 3,23/5 за використання інформації, що є найнижчим результатом серед чотирьох метрик, орієнтованих на результат.
• Коефіцієнт проходження завдань (Task Pass Rate) у Claude-Opus-4.6 становить 2,65/5, а якість фінальної відповіді — 3,34/5; навіть топова модель не завжди видає правильні та повні відповіді.
• Qwen-3.5-9B демонструє дегенеративний патерн: майже ідеальну ефективність кроків (1,000) та показник надмірності (1,000), оскільки вона майже не викликає жодних інструментів, що відображено в Tool-Calling 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. Агент, який надійно викликає правильні інструменти CLI Beancount, але потім неправильно інтерпретує результат — наприклад, парсить відповідь про балансовий звіт і робить запис не на той рахунок — гірший за відсутність автоматизації: він створює впевнено помилкові записи в реєстрі, які виглядають правильними для звичайного перевіряльника.

Метрика використання інформації — це те, за чим я б стежив найуважніше для будь-якого агента 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 жива кінцева точка від RapidAPI та 499 інтерфейсів від AkShare — з 295 ретельно підібраними запитами для оцінки, розділеними на 166 випадків з одним інструментом і 129 — з декількома. Інструменти охоплюють сфери акцій, облігацій, фондів, форекс, деривативів, макроекономіки та криптовалют. Важливо, що це реальні API, які можна викликати, а не макетовані заглушки. Автори також представляють FATR (Finance-Aware Tool Routing) — базового агента, що використовує пошук BGE-M3 (топ-20 кандидатів), картки інструментів з анотаціями фінансових атрибутів та планувальник ReAct з урахуванням обмежень, обмежений п'ятьма кроками.

Ключові ідеї​

• Виконання не є вузьким місцем — ним є міркування над результатами. GPT-4o має найвищий умовний м'який бал (CSS = 0,670), що означає, що вона дає правильні відповіді, коли успішно викликає інструмент, але викликає інструменти лише у 22,7% випадків (TIR = 0,227). Qwen3-8B викликає інструменти у 87,1% випадків, але отримує правильну відповідь лише у 40,4% випадків, коли виклик успішний.
• Невідповідність намірів є домінуючою помилкою відповідності. Коефіцієнт невідповідності намірів (IMR) перевищує 50% у більшості моделей, що означає, що агенти регулярно роблять виклики з транзакційним наміром, коли запит вимагає лише інформаційного пошуку. Це серйозна проблема в регульованих фінансових контекстах.
• Впровадження фінансових атрибутів допомагає дотримуватися правил без шкоди для можливостей. Картки інструментів базового рівня FATR — де кожен інструмент анотований за актуальністю, типом наміру та регуляторною областю — зменшують кількість викликів застарілих даних (TMR) та порушень доменів (DMR) без значного погіршення частоти викликів.
• Запити з кількома інструментами виявляють розрив у надійності. 129 запитів з кількома інструментами вимагають ланцюжка викликів і передачі результатів між кроками; продуктивність суттєво падає порівняно з випадками з одним інструментом, що узгоджується з висновками FinTrace та TheAgentCompany.
• Малі моделі можуть частіше викликати інструменти, але не перевершують великі в міркуваннях. TIR Qwen3-8B 0,871 проти 0,227 у GPT-4o показує, що менші моделі більш схильні до дії, але CER (умовна частота виконання, тобто 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. Вимір актуальності відповідає проблемі використання застарілого кешованого стану леджера, коли користувач очікує на поточний баланс.

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

Підхід 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 будує двовимірну сітку оцінювання: п'ять класів завдань (екстрактивні QA, багатоходові міркування, контрастні QA, розлогі QA та діалогові QA) у поєднанні з 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%) — але все одно залишає кожну четверту оцінку невідповідною людському судженню.
• Багатоходові міркування та діалогові QA стабільно виявлялися найскладнішими класами завдань.

Що підтверджується, а що ні​

Дизайн матричного оцінювання справді корисний. Попередні фінансові бенчмарки (FinanceBench, FinQA, DocFinQA) розглядають оцінювання за однією віссю — зазвичай точністю відповідей — і не враховують структурні варіації помилок RAG. Знання того, що система добре справляється з екстрактивними QA, але погано з багатоходовими міркуваннями, дає можливість для вдосконалення; знання середнього загального бала — ні. Сітка 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% — також ставить питання про забруднення даних, яке в статті не розглядається: питання, згенеровані GPT-4, можуть підігрувати сильнім сторонам моделей класу GPT-4, систематично ставлячи в невигідне становище старіші або менші моделі.

Чому це важливо для ШІ у фінансах​

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

Структура класів завдань також чітко відповідає сценаріям використання Beancount. Екстрактивні QA відповідають простому пошуку залишків. Багатоходові міркування відповідають на запитання на кшталт "який мій чистий дохід після оподаткування за період з 1-го по 3-й квартал?". Діалогові QA відповідають ситуації, коли користувач ітеративно уточнює запит на звірку протягом сесії. Висновок 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 для виявлення, де модель безпосередньо ідентифікує аномалії, та LLM для генерації, де модель доповнює навчальні дані або створює пояснення природною мовою, які передаються подальшому детектору. Кожен клас поділяється далі. Виявлення ділиться на методи на основі промптів (заморожені або донавчені 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» від Li et al. (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) — використовує ембеддінги LLM sentence-transformer для реальних записів головної книги; прямий міст від структури цього огляду до табличного використання 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-подібний патерн уваги. Токени на початку та в кінці вхідних даних отримують непропорційно велику увагу незалежно від того, чи є вони релевантними, тоді як токени посередині систематично недооцінюються. Автори емпірично пов’язують це з падінням точності «загублено посередині», а не розглядають це як окреме явище.

Їхнє рішення елегантне за своєю концепцією. Вони розкладають увагу на два адитивні компоненти: релевантність (те, що нам потрібно) і позиційне зміщення (те, що нам не потрібно). Щоб ізолювати термін зміщення, вони пропускають «фіктивний» документ — неінформативний наповнювач — через той самий контекст у кожній позиції та фіксують розподіл уваги, що виникає. Ця увага до фіктивного документа наближається до чистого позиційного пріоритету. Віднімання її від реальних показників уваги залишає залишок, який краще відображає справжню релевантність:

Відкалібрована увага = Attn(документ, k) − Attn(фіктивний, k)

Потім перераховані бали використовуються для переранжування або перезважування отриманих документів перед фінальним кроком генерації відповіді. Важливо, що навчання не потрібне. Калібрування застосовується під час виведення до останніх 16 шарів декодера та всіх голів уваги. Вартість становить O(K) додаткових прямих проходів, де K — кількість знайдених документів — що не є тривіальним, але є передбачуваним.

Основні ідеї​

• U-подібне позиційне зміщення притаманне архітектурі моделі та зберігається навіть у моделях, спеціально навчених для роботи з довгим контекстом.
• Пропускання фіктивного (порожнього/шумового) документа через той самий контекст пошуку ізолює позиційний пріоритет; його віднімання усуває зміщення без будь-якого донавчання.
• 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 реальних запитів до Wikipedia) та SynthWiki (990 синтетичних записів, згенерованих GPT-4).

Що витримує критику — а що ні​

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

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

По-третє — і це найцікавіше обмеження — автори зазначають, що позиційне зміщення насправді може бути корисним для певних завдань. Наприклад, зміщення в бік недавніх подій може бути саме тим, що змушує модель правильно надавати перевагу недавнім записам у гросбуху над старішими. Невибіркове усунення зміщення може зашкодити завданням, де позиція є важливим сигналом. Це визнається, але не вивчається.

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

Чому це важливо для фінансового ШІ​

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

Калібрування «знайдено посередині» — це правдоподібний засіб пом'якшення проблеми, який не потребує перенавчання базової моделі та може бути застосований безпосередньо всередині кроку генерації будь-якого конвеєра QA для гросбухів. Занепокоєння щодо вартості O(K) реальне, але кероване — вікно пошуку з 20 документів з моделлю середнього розміру все ще знаходиться в межах практичного застосування. Що я хотів би побачити перед впровадженням, так це валідацію саме на структурованих даних Beancount: чи допомагає позиційна корекція рівномірно, чи вона ненавмисно пригнічує сигнал актуальності, який робить нещодавні транзакції надійнішими за старі?

Ширший принцип — що механізми уваги кодують позиційні пріоритети незалежно від релевантності вмісту, і що ці пріоритети можна відкалібрувати без перенавчання — вартий уваги. Це відкриває двері для подібних калібрувань інших упереджень: зміщення частоти токенів, нормалізація довжини вводу, зміщення багатослівності при генерації.

Що читати далі​

• «Пом'якшення позиційного зміщення в LLM шляхом масштабування одного каналу прихованих станів» (arXiv:2406.02536, ACL Findings 2025) — пропонує масштабування одного виміру прихованого стану замість віднімання балів уваги; варто порівняти з підходом «знайдено посередині» безпосередньо.
• «Великі мовні моделі для виявлення аномалій та виходу за межі розподілу: огляд» (arXiv:2409.01980, NAACL 2025) — наступне у списку для читання; об'єднує напрацювання AnoLLM, CausalTAD та AD-LLM у єдину таксономію.
• Liu et al., «Загублено посередині: як мовні моделі використовують довгі контексти» (arXiv:2307.03172, TACL 2023) — оригінальний діагноз, на який відповідає «знайдено посередині»; необхідна література для розуміння контексту.

Про статтю​

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

Показники невизначеності є теоретико-інформаційними і потребують лише логарифмічних ймовірностей на рівні токенів: ймовірність послідовності (сума негативних лог-ймовірностей), перплексія (нормована за довжиною) та середня ентропія токенів (середня ентропія на позиціях токенів). Поріг калібрується на відкладеному наборі прогонів малої моделі шляхом вибору значення, яке дає цільову кількість викликів великої моделі на епізод 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 стикаються з точно таким же питанням передавання завдання при кожній транзакції. Рутинна покупка в продуктовому магазині потребує категоризації; незвичний багатоетапний валютний своп із частково збіжним описом потребує втручання людини. Поточна практика — це або повна автоматизація (ризиковано), або повна перевірка людиною (дорого). Фреймворк 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 експертно відібраних пар QA (питання-відповідь) у три типи завдань, що відображають робочі процеси професійних аналітиків: 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-as-Judge з трьома незалежними суддями (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% порівняно з продуктивністю на ідеальному контексті (gold-context), яка сягає 57,48%; конвеєр пошуку, а не сама LLM, є основним вузьким місцем.
• У статті представлена таксономія помилок із 13 типів у чотирьох категоріях: галюцинації та суперечності, специфічні для фінансів числові та семантичні помилки, помилки розуміння запиту/контексту та збої на рівні пошуку. Відсутність доказів (Missing Evidence) становить 75,44% помилок у завданні EC-QA при використанні RAG.
• Спеціалізовані фінансові моделі демонструють систематично вищий рівень галюцинацій, ніж загальні моделі в складних завданнях, попри краще володіння фінансовою термінологією.

Що витримує критику, а що ні​

Структура з трьома типами завдань дійсно добре продумана. Більшість фінансових бенчмарків (FinQA, TAT-QA, FinanceBench) розглядають QA як роботу з одним документом. Fin-RATE — один із перших, хто явно моделює міжсуб'єктне порівняння та лонгітюдне відстеження як першочергові завдання, і результати виявляють фундаментальну проблему: сучасні LLM цілком пристойно справляються з ізольованими питаннями щодо розкриття інформації, але зазнають невдачі в той момент, коли їм потрібно синтезувати дані з різних документів, суб'єктів або часових періодів.

Крах Fin-R1 є найбільш вражаючим висновком статті, і я вважаю, що йому приділяють недостатньо уваги. Фінансово оптимізована модель, яка чудово справляється з вилученням даних з одного документа, очевидно, загнала себе в кут під час навчання: вона вивчила шаблони для відповідей у межах одного документа, а не стратегії міркування для порівняння суб'єктів і періодів. Це конкретне попередження проти вузького доменного тонкого налаштування (fine-tuning) без явного контролю над багатодокументними міркуваннями. Модель, ймовірно, перенавчилася на поверхневому шаблоні "знайти число у звіті" і не має шляхів генералізації для завдання "порівняти це число з еквівалентним числом в іншому звіті іншої компанії".

З іншого боку, є методологічні питання. GPT-5 одночасно є і однією з оцінюваних моделей, і одним із трьох суддів. Автори використовують трьох суддів, щоб зменшити індивідуальну упередженість, що допомагає, але накладення ролей судді та найсильнішої оцінюваної моделі викликає дискомфорт. Стаття повідомляє про високу згоду між суддями, але не вказує окремо, яку частку відповідей GPT-5 оцінювала сама GPT-5, і чи відрізняються її оцінки систематично від оцінок двох інших суддів. Будь-яка упередженість у самооцінці могла б завищити результати для найкращої моделі дослідження.

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

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

Чому це важливо для фінансового ШІ​

Аудит головної книги Beancount потребує саме тих двох можливостей, які, за даними Fin-RATE, є проблемними: лонгітюдного відстеження (як цей рахунок змінювався протягом фінансових років?) та міжсуб'єктного порівняння (чи узгоджується баланс цієї дочірньої компанії з консолідованим звітом?). Падіння точності на 18,60% при часовому відстеженні — це конкретна цифра, яка має відкоригувати очікування від будь-якого агента Beancount, що аналізує дані за кілька звітних періодів. Якщо передові моделі демонструють точність лише 43% у лонгітюдному QA за звітами SEC навіть з ідеальним контекстом, то агент Beancount, що працює з багаторічною історією реєстрів, повинен бути спроєктований з акцентом на точний пошук, часову прив'язку та можливість залучення людини, а не на наскрізний висновок 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 revs breakdown by segment». Набір даних був опублікований на воркшопі ICLR 2025 з досягнень у галузі фінансового ШІ, а пізніше з'явився на ICAIF 2025.

Основні ідеї​

• Повнота пошуку (retrieval recall) шокуюче низька скрізь: 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%; з ідеальним контекстом (oracle context) результат стрибає до 60–68%. Цей розрив у 35 пунктів між реалістичними та ідеальними умовами більший за різницю між моделями з відкритим кодом та передовими (frontier) моделями.
• Композиційна арифметика не дається навіть за умови хорошого пошуку: Багатокрокові обчислювальні завдання (композиційні запити) досягають лише ~20% правильності у всіх чотирьох моделях — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill та Qwen-QWQ — навіть за умови наявності топ-10 фрагментів. GPT-o1 лідирує в задачах на множення з результатом 42,90%, але падає до 27,78% на діленні.
• Переранжування (reranking) за допомогою LLM дає невелике, але стабільне покращення: Якщо дозволити моделям переранжувати топ-10 результатів E5-Mistral перед відповіддю, Claude-3.7-Sonnet досягає F1 63,05, а GPT-o1 — 62,90. Deepseek-R1-Distill відстає з 60,01, попри сильні результати у структурованих міркуваннях в інших тестах.
• Складність категорій нерівномірна: Запити щодо ризиків найлегше піддаються пошуку (E5-Mistral: 33,07 повноти); Фінанси залишаються найскладнішими (15,84). Це корелює зі структурою запиту — розкриття ризиків використовує прозу природною мовою, тоді як фінансові таблиці використовують щільну числову нотацію.

Що підтверджується, а що ні​

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

Найслабшим місцем статті є відтворюваність. На момент публікації набір даних не був публічно доступним — автори заявляють, що «планують випустити його публічно пізніше». Це суттєва проблема для статті з воркшопу, яка позиціонує себе як стандарт оцінки. Бенчмарки, які не випущені, — це не бенчмарки, а кейс-стаді. Згодом він з'явився на ICAIF 2025, тож реліз міг відбутися, але версія на arXiv цього не підтверджує.

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

Результати генерації заслуговують на уважніше вивчення. Результативність у 9–10% без контексту не є корисною нижньою межею — це фактично нуль — але «стеля» ідеального контексту в 60–68% є більш інформативною, ніж здається. Навіть маючи на руках правильний фрагмент, найкращі моделі зазнають невдачі приблизно в одній третині якісних питань і в чотирьох п'ятих композиційної арифметики. Ця стеля важлива: вона означає, що сам по собі пошук не може вирішити проблему.

Чому це важливо для фінансового ШІ​

Розподіл запитів у FinDER добре відображає те, як користувачі Beancount насправді взаємодіють з агентом облікової книги. Користувач, який роками веде свої рахунки, буде вводити скорочені контекстні запити — «AMZN card Q3 reimb?» замість «Які відшкодування за кредитною карткою Amazon у третьому кварталі?». Стандартні моделі ембедінгів не зможуть знайти потрібні записи, оскільки вони були навчені на чистих текстах природною мовою. Падіння точності на 8,2 пункта від чистих до реальних запитів, ймовірно, є консервативною оцінкою для сфери особистих фінансів, де специфічні скорочення («prop mgmt fee» замість «property management fee») ще далі від навчальних даних, ніж стандартні абревіатури 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) — чергування пошуку з міркуваннями ланцюжком думок (chain-of-thought); багатопрохідна структура пошуку безпосередньо вирішує проблему низької повноти за один прохід, яку виявив FinDER.
• Розширення запитів за допомогою LLM для специфічного пошуку в домені — поки що жодна стаття з бенчмарками не висвітлює це достатньо добре, але розрив у скороченнях FinDER робить це першочерговим пріоритетом для досліджень; пошук за запитами «HyDE financial domain» та «query expansion SEC filings 2025» є правильним початком.

Стаття​

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

Основні ідеї​

• U-подібна форма реальна та стабільна. У сценарії відповідей на запитання з 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 документами продуктивність падала нижче базового рівня «закритої книги» — це означає, що додавання контексту було активно шкідливим.
• Моделі архітектури encoder-decoder (Flan-T5-XXL, Flan-UL2) стабільніші в межах своєї довжини навчання, але деградують, коли контекст її перевищує. Архітектурна різниця має значення, але обидва типи моделей все одно втрачають якість у великих масштабах.
• Першопричиною є каузальне маскування уваги. Кожен токен може звертатися лише до попередніх токенів, тому позиції на самому початку накопичують більшу загальну вагу уваги в моделі, ніж позиції в середині. Ефекти новизни (recency effects) також підтягують продуктивність у кінці контексту.

Що підтверджується — а що ні​

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

Що мені здається менш переконливим, так це подання завдання пошуку ключ-значення як значущого проксі для реального використання. Пошук UUID за UUID перевіряє, чи може модель повторити зазубрений рядок, а не чи може вона робити щось, що потребує міркувань. U-подібна крива з’являється і там, що підкріплює твердження про упередженість щодо позиції, але це також означає, що стаття змішує два різні явища: точність пошуку в завданнях на точну відповідність і якість міркування над релевантними уривками. Я хотів би знати, чи погіршується або покращується U-подібна форма, коли релевантний документ вимагає багатокрокового логічного висновку перед фінальною відповіддю, а не просто дослівного відтворення.

Також існує прогалина, яку автори здебільшого визнають, але не закривають: вони ніколи не перевіряли, чи змінює точне налаштування інструкцій (instruction fine-tuning) або RLHF чутливість до позиції, лише чи робить це більше вікно контексту. Враховуючи, що першопричина є архітектурною (каузальне маскування), я підозрюю, що налаштування інструкцій це не виправить, але стаття цього не підтверджує.

Чому це важливо для ШІ у фінансах​

Ця стаття дає механістичне пояснення емпіричної закономірності, з якою я постійно стикаюся. DocFinQA провалився на довгих звітах SEC. IRCoT та FLARE обидва отримують кілька уривків і об'єднують їх перед міркуванням. Кожен RAG-пайплайн, який я бачив у фінансовому контексті, послідовно скидає знайдені уривки в промпт і сподівається, що модель зверне увагу на потрібний.

Наслідки для агентів Beancount цілком конкретні. Якщо агент отримує десять записів бухгалтерської книги як контекст, записи на позиціях 3–7 перебувають під найбільшим ризиком бути проігнорованими або стати основою для галюцинацій. Це не проблема пошуку — це проблема подання. З цієї статті випливають дві реакції: або ставте найбільш діагностично релевантні записи першими (і останніми), або взагалі не з'єднуйте їх і робіть висновки по одному уривку за раз.

Цей результат також ускладнює наратив про «LLM з довгим контекстом». Кожного кварталу нова модель оголошує про збільшення вікна контексту. Ця стаття каже, що довжина вікна не означає того, що ви думаєте, якщо ви рівномірно розподіляєте докази по ньому. Модель із вікном 128K, яка ховає релевантну транзакцію на позиції 60K, гірша за модель із вікном 4K, яка отримує саме той уривок, що треба.

Для безпеки зворотного запису (write-back safety) наслідки неприємні: якщо модель просять підсумувати сесію роботи з книгою, а релевантне правило політики «не публікувати цю транзакцію» з'являється посередині довгого системного промпту, модель може діяти так, ніби вона ніколи не читала цього правила.

Що читати далі​

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., 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 та Техаського університету 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 традиційними базовими моделями без вчителя, що охоплюють як наскрізні методи (CVDD, DATE), так і комбінації вбудовування та детектора (OpenAI embeddings + LUNAR, LOF, Isolation Forest тощо).

Основні ідеї​

• Zero-shot виявлення добре працює для тексту. GPT-4o демонструє AUROC 0,9293–0,9919 на п’яти наборах даних у режимі «Normal+Anomaly»; 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 як інструментів оцінки без тонкого налаштування на мічених даних про аномалії є дійсно корисним, коли клас аномалій семантично цілісний — спам-повідомлення відрізняється від звичайного повідомлення так, як це розуміє добре навчена мовна модель. Показники AUROC високі, а порівняння з потужними базовими моделями на основі вбудовувань OpenAI є чесним.

Проте сфера застосування вужча, ніж це представлено у статті. У всіх п’яти наборах даних аномалії закодовані як окремі тематичні категорії — спам проти легітимних SMS, новини стороннього видавця проти внутрішньорозподілених джерел. Це означає, що LLM, по суті, виконує тематичну класифікацію — завдання, на якому вона була спеціально попередньо навчена. Бенчмарк не включає семантичні аномалії всередині однієї категорії (наприклад, нетипові транзакції в межах одного типу рахунку), що є саме тим типом аномалій, який критично важливий для фінансового аудиту.

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

Один результат варто відзначити для скептиків: показники 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) — табличний аналог; порівняння його підходу на основі ймовірності з zero-shot стратегією AD-LLM на основі промптів прояснює, яка парадигма більше підходить для записів у книзі Beancount.

Стаття​

Ванг та співавт. пропонують CausalTAD, метод, який працює поверх детекторів аномалій на базі LLM на кшталт 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), а перезважування за кількістю факторів додатково допомагає в кожній конфігурації. Це виглядає переконливо.

Менш переконливим мені здається припущення про бутстрепінг. Каузальний граф будується за допомогою 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 назвати, які рядки виглядають підозрілими, автори проводять тонке налаштування попередньо навченої мовної моделі на серіалізованих тренувальних рядках з нормальним розподілом, а потім оцінюють кожен тестовий рядок за його від’ємною логарифмічною правдоподібністю (NLL) відповідно до цього вивченого розподілу. Рядок, який зовсім не схожий на тренувальний розподіл, отримує високий NLL — це і є оцінка аномальності. Жодних форматів індексів, жодного парсингу виводу, жодного крихкого вилучення за допомогою регулярних виразів.

Серіалізація перетворює кожен рядок таблиці на рядок природною мовою з назвами ознак та їхніми значеннями. Для стовпців із текстовими значеннями NLL нормалізується для кожного стовпця, щоб уникнути зміщення через довжину, де довші описи інакше б мехачно накопичували вищі витрати ймовірності. Для числових і категоріальних стовпців необроблений NLL на рівні токенів підсумовується по всьому полю. Модель налаштовується в напівкерованому режимі — у навчанні беруть участь лише рядки з міткою «нормальні» — до 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 на процесорі за лічені секунди. На тесті ODDS (суто числовому) AnoLLM лише «на рівні», не краще. Отже, аргументи на користь AnoLLM повністю лежать у площині змішаних типів, де шість оцінених наборів даних стосуються виявлення шахрайства на Kaggle. Шість наборів даних — це слабкий емпіричний фундамент для впевненої рекомендації, особливо враховуючи, що набори даних з Kaggle зазвичай мають чисті схеми, фіксовану семантику стовпців і відомі істинні значення — усе те, чого часто бракує реальним даним реєстрів.

Проблема порядку стовпців також залишається відкритою. 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, в принципі, дозволив би вивчити ці спільні закономірності з нормальних історичних записів і позначати відхилення в будь-якій комбінації стовпців. Це потенційно корисніше за правила або статистичні тести для окремих стовпців.

Проте обмеження подвійного запису — це структурне знання, яке 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" (Борисов та ін., arXiv:2210.06280, ICLR 2023) — модель BE-GREAT, яку AnoLLM використовує як базову; розуміння її допомагає з'ясувати, що саме AnoLLM покращує, окрім прогнозування індексів.

Про статтю​

Фігероа, Грундманн, Фрейданк, Лезер та Неждль оцінюють п'ять моделей з відкритими вагами розміром ~7 млрд параметрів у межах бенчмарку з двома завданнями під назвою 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% в обох завданнях; вони відповідали на шаблон промпту буквальною строкою "Оброблено — Очікування наступного вводу", повністю ігноруючи завдання.
• Синтаксис не є перешкодою: жодна модель не припустилася синтаксичної помилки. Помилки цілком зосереджені в бухгалтерській логіці — помилки балансу переважають у 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 зразків), щоб робити впевнені висновки про варіативність.

Найцікавіша методологічна прогалина — відсутність будь-якого ітеративного протоколу або протоколу на основі зворотного зв'язку. Жодного виклику інструментів, жодної самокорекції, жодного циклу зворотного зв'язку від компілятора — лише генерація за один прохід (one-shot). Враховуючи, що CRITIC (LOG-012) та пов'язані роботи показують, що ітеративне вдосконалення за допомогою інструментів суттєво покращує точність у завданнях із результатами, які можна перевірити, експеримент із компілятором Beancount у циклі зворотного зв'язку був би значно інформативнішим щодо можливості впровадження.

Чому це важливо для фінансового ШІ​

Кожне дизайнерське рішення для агента зворотного запису 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) — найрелевантніша існуюча робота для створення агента корекції з компілятором у циклі зворотного зв'язку на основі архітектури, яку оцінює ця стаття.