Документът​

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

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

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

Кое се потвърждава — и кое не​

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

Данните за генерирането са честни, но трудни за интерпретиране изолирано. Авторите не анализират колко от спада в точността се дължи на грешки при извличането спрямо неуспехи при генерирането. Като се има предвид, че Recall@10 вече е 85,86% за английски, значителна част от неуспехите трябва да са от страна на генерирането, а не на извличането. Познаването на това разпределение би изяснило дали тясното място са мултимодалните разсъждения или нещо по-фундаментално в начина, по който MLLM боравят с финансовия език.

Наборът за оценка от 1394 двойки въпрос-отговор е малък за обхвата на бенчмарка. Разделени на седем категории и два езика, някои части имат под 200 примера. Статистическата значимост на констатациите на ниво категория е оставена подразбираща се. Това не е необичайно за документ за бенчмарк, но означава, че лесно могат да бъдат конструирани подбрани сравнения.

Протоколът за оценка на цитатите е интересен принос, но Pearson r = 0,68 с човешките оценки не е достатъчно силен, за да се третира автоматичната оценка като абсолютна истина за локализиране на ниво блок. Авторите признават това; бъдещата работа върху по-добри метрики за цитиране е изрично посочена.

Защо това е важно за ИИ във финансите​

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

Констатацията за цитиране на ниво блок е най-важна за този случай на употреба. Ако един агент трябва да обоснове запис в главната книга, като посочи конкретен ред в PDF, а най-добрата налична система постига едва 20–61% припомняне на ниво блок, това не е готово за одит. Всеки Beancount процес, който докосва сканирани изходни документи, се нуждае от преглед от човек, докато този показател не се подобри значително.

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

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

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

Документът​

EnterpriseArena е 132-месечна (11-годишна) симулация на разпределение на ресурси на ниво финансов директор. Всяка стъпка представлява един месец. Агентът получава частични наблюдения върху финансите на фирмата, анонимизирани бизнес документи и макроикономически сигнали, извлечени от данни на 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 под натиск от ресурси. Структурата с един агент е друго изрично ограничение, споменато от авторите: реалните финансови директори работят в йерархии от контрольори, FP&A анализатори и екипи за управление на парични средства, а документът не се опитва да симулира това.

Констатацията, че размерът на модела не предсказва оцеляването, е поразителна и вероятно реална, но механизмът не е добре обяснен. Авторите го отбелязват, без напълно да анализират дали става въпрос за неуспех при следване на инструкции, кохерентност в дълъг контекст или калибриране на риска.

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

Действието за приключване на книгите в EnterpriseArena е по същество проверката balance в Beancount и стъпката за равнение на главната книга — моментът, в който агентът се ангажира с реален поглед върху финансовото състояние, преди да действа. Констатацията, че LLM пропускат това в 80% от случаите, се пренася директно върху проблема с безопасността при записване (write-back safety): агент, който избягва равнението преди действие, е агент, който действа въз основа на остаряло или халюцинирано състояние. За автоматизацията с Beancount това предполага, че стъпката на равнение трябва да бъде задължителна и проверима — а не незадължителна — във всеки цикъл на агента.

132-месечният хоризонт също е пряко аналогичен на многогодишното управление на главната книга. Установяването, че устойчивата ситуационна осведоменост се влошава с времето, е същото влошаване, което бихме очаквали от агент на Beancount, управляващ петгодишна история на транзакциите: дори ако агентът разполага с всички данни в контекста, той може да не действа кохерентно в 60-ия месец. Това предполага, че периодичните принудителни контролни точки за равнение — а не само реактивните запитвания — са необходими в дълготрайните сесии на агенти в Beancount.

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

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

• EcoGym (arXiv:2602.09514) — допълващ бенчмарк за икономика с дълъг хоризонт в среди за търговия, свободна практика и операции над 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 е проблем на обучението или на подканите (prompting).

Докладът​

Peijie Yu, Wei Liu, Yifan Yang и техните колеги от 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): предишните отговори влияят на интерпретацията на последващите инструкции от модела по начини, които са трудни за коригиране в средата на сесията.
• Процентът на оптималния път (Optimal Path Rate) остава под 43%: Даже когато моделите изпълняват задачите правилно, те изразходват излишни API повиквания. Claude-4-Sonnet постига най-добрия процент на оптимален път от 42,74%, което означава, че по-голямата част от правилните завършвания отнемат повече стъпки от необходимото — пряк разход на латентност и токени за всяка производствена система.
• Специализираните модели за използване на инструменти се представят по-зле от общите авангардни модели: xLAM-2-70B и ToolACE2-8B отчитат нива на грешки с грешни имена на функции над 30%, което е по-лошо от GPT-4o или Claude-4-Sonnet. Фината настройка върху тесни корпуси за използване на инструменти изглежда създава чупливост, а не стабилност при промяна на разпределението към реално потребителско поведение.

Какво се потвърждава — и какво не​

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

Слабото място е мащабът. 1024 задачи от 256 сценария е надежден изследователски артефакт, но е малко за класация, предназначена да проследява 57 модела във времето. Авторите признават това директно и споменават автоматизиран тръбопровод за мащабиране в бъдеща работа. Другият проблем е, че фразата „базиран на реални потребителски логове“ върши много работа: крайните задачи са частично синтетични, конструирани от мултиагентна система от базови модели, след което са проверени от човешки анотатори. Твърдението е аргументирано, но данните не са дословно „от дивата природа“ — те са вдъхновени от нея. Това е от значение за това колко буквално интерпретирате тавана от 15%; част от разликата може да се затвори, ако процесът на генериране въвежда изкуствена трудност, която реалните потребители всъщност не проявяват.

Също така съм скептичен към анализа на преходите в инструкциите като архитектурно твърдение. Докладът го приписва на фундаментално ограничение, но несъответствието в разпределението на обучението между целите за фина настройка чрез RLHF и мултимодалните потребителски сесии е по-простото обяснение. Това е нещо, което може да се коригира, а не е структурно.

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

Трите типа грешки се припокриват почти перфектно с начина, по който реалните потребители взаимодействат с агент за запис в Beancount. Потребителят пита „колко похарчих за хранителни стоки миналия месец и докато си на тази вълна, добави днешната касова бележка от Whole Foods“ — това е композиционна задача, обединена в една реплика. След това продължават с „всъщност го направи $47,23, а не $42, проверих го“ — това е корекция на параметър, изискваща от агента да следи състоянието на сесията. След това питат „правилна ли е тази категория?“ — това е искане за разяснение и агентът трябва да не изпълнява отново операцията по запис, която току-що е приключил. Ограничението от 25% при смесена последователна и паралелна оркестрация и спадът от 30 пункта при преходите в инструкциите са точно онези типове грешки, които биха се проявили при агент за счетоводна книга, обслужващ реални потребителски сесии.

Констатацията, че специализираните модели за използване на инструменти се представят по-лошо от общите авангардни модели, е особено релевантна. Ако обмисляхме фино настройване на по-малък отворен модел върху специфични за Beancount примери за извикване на инструменти — очевидният ход за намаляване на разходите — WildToolBench е директно предупреждение, че специализацията може да пожертва устойчивостта спрямо разпределението на действителното потребителско поведение. Находката за процента на оптималния път също е важна: агент, който използва два пъти повече API повиквания за изпълнение на задача, не е просто неефективен; при операции за запис, излишните междинни повиквания могат да оставят счетоводната книга в несъвместими междинни състояния.

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

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

Статията​

Генг, Кай, Уанг, Кьопл, Наков и Гуревич правят обзор на зараждащата се литература за оценка на доверието и калибрирането на LLM в широк спектър от задачи — от въпроси с избор на отговор до генериране със свободен край и машинен превод. Основният проблем: LLM могат да бъдат както много точни, така и напълно ненадеждни по начини, които са трудни за разграничаване отвън. Обзорът организира пространството на решения в два основни клона — методи "бяла кутия", които използват достъп до вътрешните състояния на модела, и методи "черна кутия", които третират модела като непрозрачен — и във всеки от тях допълнително разграничава оценката на доверието от неговото калибриране post hoc.

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

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

• Доверие чрез "бяла кутия" чрез логити: Най-простият подход използва вероятности на ниво токен или нормализирана по дължина логаритмична вероятност като сигнал за доверие. Тези методи работят, но се сблъскват с фундаментална неяснота: ниската вероятност на токен може да отразява ниско фактологично доверие или просто необичайна формулировка — моделът може да е несигурен в избора на думи, докато е сигурен в основния факт.

• Доверие чрез "черна кутия" на базата на последователност (SelfCheckGPT): Manakul и др. (EMNLP 2023) вземат множество проби от допълванията и оценяват тяхната взаимна последователност чрез BERTScore, NLI или n-gram припокриване. Не е необходим достъп до логити. Ключово прозрение: за факти, които LLM познава добре, многократните проби се сближават; за халюцинирани факти те се разминават.

• Семантична ентропия: Farquhar et al. (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 на 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) спрямо JSON Schema Test Suite — което означава, че тя излъчва JSON, който нарушава декларираната схема, докато мълчаливо докладва успех. Guidance има само 1 такъв провал. За агент, който пише обратно в базата, грешката при компилация се улавя по време на разработка; провалът на ограничаването корумпира данни в реално време без никакъв сигнал.
• Функцията за „бързо превъртане“ (fast-forwarding) на Guidance осигурява реално 50% ускорение. Когато са налични дълги детерминистични последователности (напр. имена на полета във фиксирана структура на обект), Guidance може да прескочи няколко токена на една стъпка от декодирането. На Llama-3.1-8B на A100, Guidance работи с 6–9 ms на изходен токен, докато неограниченото генериране работи с 15–16 ms. Outlines е по-бавна от неограниченото генериране с 30–46 ms, до голяма степен поради предварителната компилация на автомати, която отнема 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 агенти, които адаптират своя изходен формат въз основа на това кои типове сметки са активни.

Документът​

Jie Zhu, Yimin Tian и колеги от екипа на Alibaba Cloud Qwen DianJin, YINGMI Wealth Management и Университета Soochow представят FinMCP-Bench — набор за оценка от 613 проби, покриващ 10 категории финансови сценарии и 33 под-сценария. Инструментите не са симулирани — 65 реални MCP-съвместими сървъра за финансови инструменти стоят зад бенчмарка, извлечени от реални производствени логове на финансовия асистент Qieman APP. Авторите класифицират пробите в три типа: 145 с един инструмент, 249 с множество инструменти и 219 с многократни ходове (multi-turn). Тестват се шест модела: фамилията Qwen3 с 4B, 30B и 235B параметри (всички с разширено мислене), плюс DeepSeek-R1, GPT-OSS-20B и Seed-OSS-36B. Основните метрики за оценка са точност на инструментите (Tool Precision), пълнота на инструментите (Tool Recall), 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, което ограничава преносимостта на резултатите към други финансови платформи с различен инвентар от инструменти.

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

FinMCP-Bench е най-близката публикувана оценка до това, което един Beancount агент за запис (write-back agent) всъщност би правил: получаване на потребителска заявка, идентифициране на подходящия инструмент (или верига от инструменти), извикването им в съответния ред и управление на последващи ходове. Резултатът от 3,08% EMR при многократни ходове е отрезвяваща проверка на реалността. Beancount агент, който управлява многостъпкова корекция на главната книга — например прекласифициране на набор от транзакции между сметки за определен период, след това равняване и генериране на отчет — е точно типа задача с многократни ходове и инструменти, при която текущите модели се провалят почти универсално според стандартите за точно съвпадение.

Рамката на MCP е директно релевантна: Python API на Beancount, интерфейсът beanquery и REST слоят на fava могат да бъдат обвити като MCP сървъри. FinMCP-Bench ни казва, че протоколът не е тясното място — проблемът е логическото мислене върху последователностите от извиквания на инструменти.

Констатацията, че пълнотата на инструментите надвишава точността (моделите прекаляват с извикванията), също е важна за безопасността при запис: агент, който извиква инструмента за промяна на главната книга, когато е било необходимо само четене, може да повреди данните безшумно. Метриките, фокусирани върху точността (precision), а не върху пълнотата (recall), трябва да бъдат основният сигнал за безопасност за агентите с право на запис.

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

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

Статията​

Cao и др. представят FinTrace, бенчмарк от 800 експертно анотирани траектории, обхващащи 34 категории финансови задачи от реалния свят в нива на трудност: лесно, средно и трудно. Авторите изграждат своята оценка около рубрика от девет метрики, организирани по четири оси: коректност на действието (tool-calling F1, релевантност към задачата), ефективност на изпълнението (ефективност на стъпките, резултат за излишък), качество на процеса (логическа прогресия, използване на информация, резултат за напредък) и качество на резултата (степен на преминаване на задачата, качество на крайния отговор). Те оценяват 13 LLM модела и също така пускат FinTrace-Training, набор от данни от 8196 подбрани траектории на предпочитания за фина настройка.

Основното твърдение е, че водещите модели са усвоили подбора на инструменти, но системно се провалят на по-трудната стъпка: използването на това, което инструментите връщат. Бенчмаркът изследва това с 5-степенна скала за използване на информация, логическа прогресия и резултат за напредък, плюс алгоритмични метрики за tool F1 и ефективност на стъпките.

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

• Най-добре представящият се модел, Claude-Opus-4.6, постига Tool-Calling F1 от 0.896 — силен подбор — но получава само 3.23/5 за използване на информация (Information Utilization), най-слабата от четирите метрики, ориентирани към изхода.
• Степента на преминаване на задачите (Task Pass Rate) на Claude-Opus-4.6 е 2.65/5, а качеството на крайния отговор (Final Answer Quality) е 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, които разкриват какво се случва между стъпките. Коефициентът на съгласие между оценителите (Cohen's κ) от 0.89 върху 100-пробна валидация е окуражаващ за бенчмарк, изграден частично върху LLM съдии.

Въпреки това, няколко методологични избора ограничават доверието в числата. 34-те категории задачи не са изброени в основната статия — те са оставени за Приложение Б — така че не мога да кажа колко представителни са те за реалната финансова практика. Нивата на трудност са дефинирани чрез процентилни рангове в рамките на собствения пул от заявки на бенчмарка, което е кръгов измерител: „трудно“ просто означава необичайно спрямо останалите 800 траектории, а не трудно в някакъв абсолютен смисъл.

Анализът на фината настройка е фрустриращ. Обучението на 9B модел върху FinTrace-Training подобрява междинните разсъждения, но качеството на крайния отговор остава ниско. Статията приписва това на „прекъсване на връзката“ между процеса и резултата, но не обяснява защо. Най-вероятното обяснение — че на 9B модел му липсва способността за извикване на факти и аритметичните умения, необходими за финансови задачи, независимо от качеството на траекторията — остава неразгледано. Показването на DPO резултати само за Qwen-3.5-9B също прави невъзможно да се разбере дали по-големите модели се възползват повече.

Скептичен съм и към общото агрегиране на резултатите. Комбинирането на алгоритмични метрики (F1 ∈ [0,1]) с оценки от LLM съдии по 5-степенни скали на Ликерт чрез нормализиране към [0,1] и усредняване смесва много различни типове откази. Модел, който извиква напълно погрешни инструменти, не е същият тип „повреден“ като модел, който извиква правилните инструменти и след това игнорира изхода.

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

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

Метриката за използване на информация (Information Utilization) е тази, която бих следил най-внимателно за всеки Beancount агент. Фактът, че най-добрият наличен модел постига 3.23/5 по този показател в контролиран финансов бенчмарк, трябва да бъде ограничаващ фактор за всяко внедряване в реална среда. Това е аргумент за задължителен човешки преглед на всяка операция по записване, поне докато не видим този резултат стабилно над 4.0.

FinTrace също така потвърждава това, което ReDAct подсказа миналата седмица: правилната архитектура не е разсъждение на LLM от край до край (end-to-end), а конвейер (pipeline), който екстернализира проверката. Агент, който подбира инструментите добре (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 г.) като това, което те твърдят, че е първият изпълним бенчмарк в реалния свят за оценка на финансови агенти, обучаващи се на инструменти. Поставянето на темата е директно: съществуващите финансови AI оценки се фокусират върху статични въпроси и отговори върху документи, докато общите бенчмаркове за използване на инструменти като ToolLLM третират финансите просто като поредната категория API без специфични за домейна ограничения за съответствие. FinToolBench се опитва да запълни пространството между тези два режима на неуспех.

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

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

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

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

Изборът на бенчмарка да използва истински работещи, изпълними API е неговият основен принос. Имитираните API са били публичната тайна на бенчмарковете за използване на инструменти: 16 000 API на ToolLLM звучат впечатляващо, докато не осъзнаете, че оценката използва LLM като съдия за това дали едно повикване „би работило“. FinToolBench избягва това.

Метриките за съответствие (TMR, IMR, DMR) са концептуално правилни — финансовите агенти трябва да знаят разликата между извличане на вчерашната цена на затваряне и иницииране на сделка — но описанието в доклада за това как се налагат тези класификации е оскъдно. Не е ясно дали етикетите за тип намерение (информационно срещу трансакционно) са били проверени от правни експерти или експерти по съответствието, или просто са присвоени от авторите на набора от данни. Това е от голямо значение на практика.

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

Оценъчният набор от 295 заявки е малък според съвременните стандарти за бенчмарк. Със 760 инструмента, процент на покритие от 295 заявки означава, че повечето инструменти никога не се тестват. Докладът не съобщава статистики за покритие по домейни, което означава, че водещите числа могат да се движат от подмножество добре покрити домейни като акции и макроикономика.

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

Beancount агентите за обратно записване — всеки агент, който извиква bean-add, коригира файл на главната книга (ledger file) или прави заявка към beanquery — са изправени пред точно тези режими на отказ, които FinToolBench разкрива. Проблемът с несъответствието на намерението се превежда директно: Beancount агент, който извършва повикване за запис, когато потребителят е задал въпрос за четене, има същия признак за отказ като нарушение на IMR. Измерението на актуалността се отнася до проблема с извикване на остаряло кеширано състояние на главната книга, когато потребителят очаква текущия баланс.

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

Подходът на FATR за анотиране на инструменти с атрибути за съответствие, вместо да се разчита на модела да ги изведе, е модел на проектиране, който си струва да бъде възприет. Обвиването на CLI инструментите на 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 файлове и финансово съдържание от Wikipedia). Бенчмаркът включва също и фино настроен LLM оценител — Qwen2.5-7B-Instruct, обучен върху 910 случая с човешки етикети — който оценява качеството на генериране чрез показатели за точност, халюцинации, пълнота, използване и числова точност. Документът е публикуван в EMNLP 2025.

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

• Автоматично генерираните тестови случаи преминаха проверка за приемане от хора с резултат 87,47%, което означава, че приблизително 1 на всеки 8 генерирани случая е бил отхвърлен — това не е тривиален процент шум за бенчмарк.
• Най-добрият модул за извличане (retriever) (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), а шестият е китайската Wikipedia. Документът не отчита резултати, разбити по езици — той докладва само обобщени числа. Това прави всеки резултат в документа подозрителен като твърдение за финансовия 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 е безпощаден — неправилна сума, дата или име на сметка води или до грешка при разбора (parse error), или до скрита счетоводна грешка, която може да се разпространи през фискалните години. Този бенчмарк ни дава конкретни доказателства, че извличането чрез RAG и генерирането чрез LLM все още не са достатъчно надеждни за директен обратен запис в книгата без слой за валидация.

Структурата на класовете задачи също се съпоставя точно с случаите на употреба на Beancount. Екстрактивното QA съответства на прости проверки на баланса. Многостъпковото разсъждение съответства на въпроси като „какъв е нетният ми доход след данъци за периода от Q1 до Q3?“. Разговорното QA съответства на потребител, който итеративно прецизира заявка за равняване по време на сесия. Констатацията на OmniEval, че многостъпковите и разговорните задачи са най-трудни, е точно лошата новина за дизайна на Beancount агентите: лесните случаи са почти наред; реалистичните случаи са тези, при които системата се разпада.

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

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — най-близкият аналог в общата област на подхода на OmniEval за фино настройване на оценител; сравняването на методологията на ARES с тази на OmniEval би изяснило дали дизайнерските избори за LLM оценителя са принципни или ad hoc.
• 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 за генериране, където моделът допълва данните за обучение или създава обяснения на естествен език, които захранват последващ детектор. Всеки клас се подразделя допълнително. Откриването се разделя на методи, базирани на подкани (frozen или tuned LLM, запитвани с подкани на естествен език) и методи, базирани на контрастиране (модели от фамилията CLIP, които оценяват аномалността чрез сравняване на части от изображения с текстови описания). Генерирането се разделя на методи, фокусирани върху допълване (генериране на псевдо-OOD етикети или синтетични малцинствени проби) и методи, фокусирани върху обяснението (създаване на обосновки на естествен език за маркирани събития).

Придружаващият списък за четене в GitHub обхваща приблизително 39 документа: 24 за откриване, 10 за допълване и 5 за обяснение.

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

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

Кое е устойчиво и кое не​

Таксономията от два класа е наистина чиста и вероятно ще я използвам, за да организирам собственото си мислене. Разграничението между откриване и генериране улавя реално архитектурно разклонение: или искате от LLM да класифицира директно, или го използвате, за да изградите по-добър тренировъчен сигнал за традиционен детектор.

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

Авторите признават, че „ограниченията в пространството предотвратяват подробни обобщения на метриките“, което е учтив начин да се каже, че липсват сравнителни таблици. За обзорна статия липсата на количествен синтез е значителен пропуск. Читателите не могат да използват този документ, за да решат коя парадигма е по-добра за техния случай на употреба, без да проследяват всяка цитирана статия поотделно.

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

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

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

Компромисът между подкани (prompting) и настройка (tuning) е най-практичната находка: zero-shot подканите работят като първо приближение, но страдат от модалната пропаст; донастройката на базата на LoRA върху представителни етикетирани примери затваря тази разлика. За внедряване на Beancount с етикетирани примери за аномалии от исторически регистри, пътят на донастройката изглежда по-надежден от чистото използване на подкани.

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

• „Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs“ (arXiv:2406.03614) — използва LLM вграждания (embeddings) от 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 настройка за откриване“, което обзорът описва, но не обяснява.

Документът​

Hsieh et al. започват от диагностично наблюдение: LLM — дори тези, обучени на дълги контексти — показват постоянен U-образен модел на вниманието. Токените в началото и в края на входните данни получават непропорционално голямо внимание, независимо дали са уместни, докато токените в средата систематично се подценяват. Авторите свързват това емпирично със спада в точността „изгубени в средата“, вместо да го разглеждат като отделно явление.

Тяхното решение е елегантно като концепция. Те разлагат вниманието на два адитивни компонента: уместност (това, което искаме) и позиционно отклонение (това, което не искаме). За да изолират члена за отклонението, те прекарват „фиктивен“ документ — неинформативно запълващо съдържание — през същия контекст на всяка позиция и записват полученото разпределение на вниманието. Вниманието към този фиктивен документ апроксимира чистия позиционен приоритет (prior). Изваждането му от реалните резултати за внимание оставя остатък, който по-добре отразява истинската уместност:

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

След това мащабираните резултати се използват за прекласиране или претегляне на извлечените документи преди последната стъпка на генериране на отговор. От решаващо значение е, че не се изисква обучение. Калибрирането се прилага по време на извеждане към последните 16 слоя на декодера и всички глави на вниманието. Цената е O(K) допълнителни преминавания напред (forward passes), където K е броят на извлечените документи — не е незначително, но е предвидимо.

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

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

Какво е валидно и какво не​

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

Въпреки това имам някои резерви. Първо, подходът с „фиктивен документ“ предполага, че позиционното отклонение е грубо позиционно отделимо и адитивно — линейно разлагане, което самите автори отбелязват като потенциално прекалено опростено. Реалното отклонение на вниманието може да взаимодейства със съдържанието по нелинейни начини. Второ, O(K) допълнителните преминавания напред са оценени като „приемливи“, но никога не са тествани за латентност или цена. В производствена система с K=20 извличания, вие изпълнявате 21 преминавания напред вместо 1 за заявка. За Beancount агент, обработващ стотици транзакции, този множител е от значение.

Трето — и това е най-интересното ограничение — авторите отбелязват, че позиционното отклонение всъщност може да бъде полезно за определени задачи. Отклонението в полза на актуалността (recency bias), например, може да е това, което кара модела да претегля правилно последните записи в счетоводната книга спрямо по-старите. Премахването на отклонението безразборно може да навреди на задачи, където позицията е валиден сигнал. Това е признато, но не е проучено.

И накрая, експериментите използват NaturalQuestion и синтетичен набор от данни. Финансово-специфичните документи — плътни таблици, многогодишни отчети, записи в счетоводни книги с повтаряща се структура — са много различни от пасажите в Wikipedia с отворен домейн. Калибрирането ще трябва да бъде валидирано върху тези разпределения, преди да се твърди, че ще работи за финансов RAG.

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

Директната връзка е ясна: всяка бележка след DocFinQA се върти около същия проблем. Когато един Beancount агент извлече 20 подходящи записа в счетоводната книга, за да отговори на въпрос като „равни март спрямо банковото извлечение“, записите от средата на извлечения прозорец ще получат систематично по-малко внимание в сравнение със записите в началото и в края на контекста. Това не е провал на извличането — това е провал на страната на генерирането, който никакво подобрение в ранжирането при извличане няма да коригира.

Калибрирането „открити в средата“ е реалистично смекчаване на проблема, което не изисква преобучение на базовия модел и може да бъде приложено директно в стъпката на генериране на всеки QA конвейер за счетоводни книги. Притеснението за цената O(K) е реално, но управляемо — прозорец за извличане от 20 документа с модел с умерен размер все още е в практическите граници. Това, което бих искал да видя преди внедряването му, е валидация специално върху структурирани данни на Beancount: помага ли позиционната корекция равномерно или неволно потиска сигнала за актуалност, който прави последните транзакции по-достоверни от старите?

По-широкият принцип — че механизмите на вниманието кодират позиционни приоритети независимо от уместността на съдържанието и че тези приоритети могат да бъдат калибрирани без преобучение — си струва да се запомни. Това отваря вратата за подобни калибрирания за други отклонения: отклонение според честотата на токените, нормализиране на дължината на входа, отклонение към многословност при генериране.

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

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

Докладът​

ReDAct (Reason-Defer-Act) се основава на парадигмата ReAct и въвежда архитектура на агент с два модела. Малък евтин модел — Qwen3-80B, Llama3.3-70B или Llama4-Maverick — обработва всяка стъпка по подразбиране. На всяка стъпка той генерира следа от разсъждения (reasoning trace), след което генерира действие. Системата измерва неопределеността на ниво токен само върху стъпката на генериране на действие и я сравнява с калибриран праг. Ако неопределеността надвиши този праг, стъпката се изпълнява повторно от голям скъп модел (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 са текстови симулации на домакинство и навигация в мрежов свят — тесни среди, които не упражняват извикване на инструменти (tool calling), изпълнение на код или извличане на информация от множество документи. Дали отлагането, калибрирано спрямо неопределеността, важи в тези по-богати среди (средите, подходящи за Beancount), остава без отговор. А изборът на GPT-5.2 като голям модел прави цифрите за разходите трудни за възпроизвеждане.

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

Защо това е важно за финансовия изкуствен интелект​

Агентите за автоматично вписване в 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“ — използва конформно предсказване (conformal prediction) за калибриране на гаранция за покритие кога да се поиска помощ. ReDAct не се сравнява с него; разбирането на компромиса между конформните гаранции и калибрирането на прага е важно преди избора на производствен подход. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. updated, NAACL 2024) — систематична таксономия на вербализирана увереност, методи, базирани на извадки (sampling-based), и post-hoc методи за калибриране; теоретичната база за решаване дали перплексията е правилният прокси за неопределеност или дали калибрираното мащабиране на логитите би се представило по-добре. [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 агенти, които действат като софтуерни разработчици с общо предназначение. Воден от Xingyao Wang и Graham Neubig в екип от 24 автори, основното твърдение на документа е, че повечето съществуващи рамки за агенти са или твърде тесни за изследователски цели (твърдо кодирани цикли на задачи), или твърде тесни за производство (със затворен код или с една цел), за да служат като споделена основа за изследователската общност. OpenHands се опитва да поправи това, като предоставя стандартизирана среда за изпълнение (runtime), чиста абстракция на агента и 15 интегрирани бенчмарка за оценка под едно MIT-лицензирано хранилище.

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

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

• Кодът като универсално пространство за действие: CodeAct обединява всички действия на агента (редактиране на файлове, API повиквания, трансформации на данни) в Python или bash, позволявайки на LLM да разсъждава в същата среда, в която е бил обучен най-интензивно. Това заобикаля крехкостта на JSON схемите, която измъчва агентите, използващи повиквания на функции (function-calling).
• Изолирана Docker среда (Sandboxed runtime): всеки агент се изпълнява в изолиран контейнер, така че агентите могат свободно да изпълняват произволен код, без да компрометират хост машината — предпоставка за всеки производствен финансов агент, на когото могат да бъдат поверени реални идентификационни данни.
• 15 бенчмарка в една система: SWE-Bench Lite (поправка на код), HumanEvalFix (отстраняване на грешки), WebArena (уеб навигация), GPQA (разсъждения на ниво завършил висше образование), GAIA (общо решаване на задачи) и още десет. Наличието им на едно място предотвратява избирателното представяне на резултати (cherry-picking).
• 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 документира. Документът не разглежда как да се измери или подобри устойчивостта при реалистичен шум в дефинирането на задачите.

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

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

Числата от SWE-Bench и TheAgentCompany, четени заедно, установяват отрезвяваща представа: дори най-добрите налични агенти изпълняват приблизително 26–30% от реалистичните, недвусмислени софтуерни задачи. Автоматизацията на финансовите книги е по-трудна — транзакциите често са двусмислени, радиусът на поражение от грешки е реален, а намеренията на потребителите често не са достатъчно дефинирани. Правилният извод не е, че агентите не са готови, а че първите продуктивни внедрявания ще бъдат тясно ограничени работни процеси за еднократен запис (предложения за категоризация, отбелязване за съгласуване), а не автономни многостепенни редакции на счетоводната книга.

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

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

Документът​

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

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

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

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

Структурата с три пътеки е наистина добре проектирана. Повечето финансови бенчмаркове (FinQA, TAT-QA, FinanceBench) разглеждат въпросите и отговорите като задача за един документ. Fin-RATE е един от първите, които изрично моделират сравнението между предприятия и лонгитудиалното проследяване като първокласни задачи, а резултатите разкриват фундаментална празнина: настоящите LLM се справят приемливо с изолирани отчети, но се разпадат в момента, в който трябва да синтезират информация от различни документи, предприятия или периоди от време.

Сривът на Fin-R1 е най-забележителното откритие в документа и мисля, че е подценено. Финно настроен модел за финанси, който превъзхожда при извличането от единични документи, очевидно се е вкарал в капан: той е научил шаблони за отговаряне в рамките на един документ, а не стратегии за разсъждение за свързване на предприятия и периоди от време. Това е конкретно предупреждение срещу тясното специализиране на домейна без изричен надзор на разсъжденията върху множество документи. Моделът вероятно се пренастройва към плиткия модел на „намери числото в отчета“ и няма път за обобщаване към „сравни това число със съответното число в друг отчет от друга компания“.

Въпреки това има методологични опасения, които си струва да бъдат отбелязани. GPT-5 е едновременно един от оценяваните модели и един от тримата съдии, оценяващи отговорите. Авторите използват трима съдии, за да намалят индивидуалното пристрастие, което помага, но припокриването между съдия и модел с най-силния оценяван модел е смущаващо. Документът отчита високо съгласие между съдиите, но не количественo определя отделно каква част от отговорите на GPT-5 са били оценени от самия GPT-5, нито дали самооценките на GPT-5 се различават системно от тези на другите двама съдии. Всяко пристрастие при самооценката би надуло водещия резултат за най-добре представящия се модел в изследването.

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

Откритието за извличането на данни е важно, но непълно. Документът идентифицира, че RAG производителността се срива с приблизително 30 пункта в сравнение с идеалния контекст, защото извличането се проваля. Но той сравнява само една конфигурация за извличане — той третира провала на извличането като диагноза, а не като нещо, което да се променя систематично. Последващ документ, който изследва различни архитектури за извличане върху Fin-RATE, би бил много по-приложим на практика.

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

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

Констатацията за доминиращата роля на извличането е най-важна за приоритетите при проектирането на системата. Ако производителността при идеален контекст е почти двойно по-висока от тази при RAG, правилната инвестиция е в по-добро разделяне на сегменти (chunking), избор на пасажи и извличане — а не в по-мощен базов LLM. Това отразява откритото от DocFinQA за SEC отчети с дълъг контекст: конвейерът около модела е тясното място.

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

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

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

Документът​

Chanyeol Choi, Jihoon Kwon и техните колеги от фирма за финансов AI представят набор от данни от 5 703 анотирани от експерти триплети "запитване–доказателство–отговор", извлечени от реална услуга за въпроси и отговори за анализатори на хедж фондове. Документите са отчети по формуляр 10-K от 490 компании от S&P 500, събрани от SEC EDGAR. Това, което отличава FinDER от предишните бенчмаркове, е страната на запитванията: 89,86% от тях съдържат три или повече специфични за домейна съкращения или акроними. Вместо „Какъв е общият доход на компания X за фискалната 2023 година?“, реалният анализатор може да напише „GOOGL 10-K FY23 revs breakdown by segment“. Наборът от данни беше публикуван на ICLR 2025 Workshop on Advances in Financial AI и по-късно се появи на ICAIF 2025.

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

• Пълнотата на извличането е шокиращо ниска навсякъде: E5-Mistral (най-добрият модел за плътно извличане) постига само 25,95% обща пълнота на контекста; BM25 постига 11,68%. Категорията „Финанси“ — най-пряко свързана със счетоводството — е най-трудна: съответно 15,84% и 6,42%.
• Двусмислието на запитването само по себе си струва 8,2 пункта прецизност: Тествайки E5-Mistral върху 500 запитвания, авторите сравняват добре оформени парафрази (33,9 прецизност) срещу реалните съкратени запитвания (25,7 прецизност). Пропускът се дължи изцяло на обработката на съкращения/акроними, а не на сложността на документа.
• Качеството на извличане е основното тясно място за генерирането: LLM без контекст постигат резултат близо до нулата (9–10% верни отговори); с топ 10 извлечени пасажа те достигат 29–34%; с идеален оракулски контекст те скачат до 60–68%. Тази разлика от 35 пункта между реалистични и оракулски условия е по-голяма от разликата между моделите с отворен код и водещите модели (frontier models).
• Композиционната аритметика се проваля дори при добро извличане: Задачите за многостъпкови изчисления (композиционни запитвания) достигат само ~20% точност и при четирите модела — Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill и Qwen-QWQ — дори с топ 10 извлечени пасажа. GPT-o1 води в задачите за умножение с 42,90%, но пада до 27,78% при деление.
• Прекласирането (reranking) от LLM добавя скромно, но постоянно подобрение: Позволявайки на моделите да прекласират топ 10 попаденията на E5-Mistral преди отговор, Claude-3.7-Sonnet постига F1 от 63,05, а GPT-o1 достига 62,90. Deepseek-R1-Distill изостава с 60,01, въпреки силното представяне в структурираното разсъждение другаде.
• Трудността по категории е неравномерна: Запитванията за риск са най-лесни за извличане (E5-Mistral: 33,07 пълнота); Финансите остават най-трудни (15,84). Това корелира със структурата на запитването — оповестяването на рискове използва естествен език, докато финансовите таблици използват гъста цифрова нотация.

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

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

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

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

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

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

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

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

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

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

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

Статията​

„Lost in the Middle: How Language Models Use Long Contexts“ от Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni и Percy Liang провежда два целеви експеримента: отговаряне на въпроси върху множество документи чрез 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 контекст се държеше като останалите. Дългият контекстен прозорец не означава, че моделът действително отделя равномерно внимание по цялата му дължина.
• Базовата линия „затворена книга“ (closed-book) поставя отрезвяваща граница. GPT-3.5-Turbo без никакви документи отговори правилно на 56,1% от NaturalQuestions; с директен достъп само до единствения подходящ документ той достигна 88,3%. Но при най-лошите средни позиции в настройката с 20 документа, производителността падна под базовата линия „затворена книга“ — което означава, че добавянето на повече контекст е било активно вредно.
• Моделите енкодер-декодер (Flan-T5-XXL, Flan-UL2) са по-стабилни в рамките на дължината си на обучение, но се влошават, когато контекстът я надвиши. Архитектурната разлика има значение, но и двата типа все още деградират при мащабиране.
• Основната причина е каузалното маскиране на вниманието (causal attention masking). Всеки токен може да обръща внимание само на предхождащите го токени, така че позициите в самото начало акумулират по-голямо общо тегло на вниманието в целия модел, отколкото позициите в средата. Ефектите на скорошността (recency effects) също изтеглят производителността в края на контекста нагоре.

Кое е основателно и кое — не​

Експерименталният дизайн тук е възхитително чист: позицията е единствената променлива, която се манипулира, задачите са стандартни бенчмаркове и откритието се възпроизвежда в широк диапазон от семейства модели. Нямам възражения срещу основния резултат.

Това, което намира за по-малко убедително, е рамкирането на задачата за извличане на ключ-стойност като смислено прокси за реална употреба. Търсенето на UUID към UUID тества дали моделът може да папагалства запаметена низа, а не дали може да прави нещо, изискващо разсъждения. U-кривата се появява и там, което засилва твърдението за позиционно отклонение, но също така означава, че статията обединява две различни явления: точност на извличане при задачи с точно съвпадение и качество на разсъжденията върху съответните пасажи. Бих искал да знам дали U-образната форма се влошава или подобрява, когато съответният документ изисква многоетапно логическо извеждане преди крайния отговор, а не просто дословно възпроизвеждане.

Съществува и празнина, която авторите до голяма степен признават, но не запълват: те никога не тестват дали фината настройка на инструкциите (instruction fine-tuning) или RLHF променя чувствителността към позицията, а само дали по-големият контекстен прозорец го прави. Като се има предвид, че основната причина е архитектурна (каузално маскиране), подозирам, че настройката на инструкциите няма да го поправи, но статията не потвърждава това.

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

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

Последиците за Beancount агентите са конкретни. Ако един агент извлече десет записа от главната книга като контекст, записите на позиции 3–7 са под най-голям риск да бъдат игнорирани или около тях да се появят халюцинации. Това не е проблем на извличането — това е проблем на представянето. От тази статия следват два възможни подхода: или поставете най-важните диагностични записи първи (и последни), или изобщо не ги обединявайте и разсъждавайте върху всеки пасаж поотделно.

Констатацията също така усложнява наратива за LLM с дълъг контекст. Всяко тримесечие нов модел обявява по-голям контекстен прозорец. Тази статия казва, че дългият прозорец не означава това, което мислите, ако разпределяте доказателствата равномерно в него. Модел със 128K контекст, който заравя съответната трансакция на позиция 60K, е по-лош от модел с 4K контекст, който извлича точно правилния пасаж.

За безопасността при записване (write-back) последиците са неудобни: ако от модела се поиска да обобщи сесия в главната книга и съответното правило на политиката „не публикувай тази трансакция“ се появи в средата на дълга системна подкана, моделът може да действа така, сякаш никога не е чел това правило.

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

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) — предлага Multi-scale Positional Encoding (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) — идентифицира специфичното измерение на скритите състояния на позицията, отговорно за отклонението, и го мащабира без преобучение; най-хирургичната корекция, предложена досега, подходяща за внедряване на съществуващи модели без преобучение.

Статията​

Tiankai Yang, Yi Nian и колеги от USC и Texas A&M представят AD-LLM (arXiv:2412.11142, ACL Findings 2025) – първият бенчмарк за систематична оценка на LLM в три парадигми за откриване на аномалии върху NLP набори от данни. Настройката е класификация с един клас: данните за обучение съдържат само нормални примери, а моделът трябва да идентифицира аномалиите по време на тестването. Петте набора от данни – AG News, BBC News, IMDB Reviews, N24 News и SMS Spam – произлизат от задачи за текстова класификация, при които една категория е обозначена като аномална. Статията сравнява два LLM, GPT-4o и Llama 3.1 8B Instruct, срещу 18 традиционни базови модела за обучение без надзор, които обхващат методи от край до край (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 и режимите на фина настройка и разчитат на опростени входни данни за избор на модел – което е интелектуално честно, но също така показва колко предварителен е този бенчмарк.

Един резултат, който си струва да бъде отбелязан за скептиците: AUPRC резултатите са значително по-ниски от AUROC за двата модела. Llama 3.1 в BBC News достига AUROC 0.8612, но само AUPRC 0.3960, което отразява дисбаланса на класовете в конфигурацията с един клас. В контексти на одит с висока точност AUPRC е по-смислената метрика и тук картината е по-малко ласкава.

Защо това е важно за ИИ във финансите​

Програмата на Bean Labs включва два случая на използване за откриване на аномалии: улавяне на необичайни записи в главната книга в реално време (таблични, структурирани) и сигнализиране за подозрителен текст във фактури, бележки или заявки за поддръжка (неструктуриран NLP). AD-LLM говори директно за втория случай и ни дава реалистичен таван: GPT-4o може да открива аномалии на ниво тема в текст чрез zero-shot с AUROC над 0.93 върху чисти, балансирани набори от данни. Това е полезна отправна точка, но аномалиите в описанията на главната книга са по-фини – бележка към фактура, която описва рутинна услуга, но принадлежи на доставчик, отбелязан с подозрителни модели, не е проблем на тематичната класификация. Бенчмаркът предоставя начална точка, а не окончателен отговор.

Констатацията за избора на модел е отделно интересна за дизайна на системи. Мечтата да попитате LLM „кой детектор на аномалии трябва да използвам за този набор от данни?“ и да получите надежден отговор все още не се сбъдва. Това означава, че изборът между фина настройка в стил AnoLLM, причинно-следствени инструкции (causal prompting) в стил 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) – табличният еквивалент; сравняването на неговия подход, базиран на вероятността, със стратегията на AD-LLM за zero-shot чрез инструкции изяснява коя парадигма е по-подходяща за записи в главната книга на Beancount.

Статията​

Wang и др. предлагат CausalTAD, метод, който надгражда LLM детектори на аномалии от типа на AnoLLM и прави една целенасочена промяна: вместо да сериализира табличните редове в случаен или произволен ред на колоните, той открива каузалните зависимости между тях и ги пренарежда така, че да се спазват тези зависимости, преди LLM да прочете реда.

Статията има две основни части. Първо, модул за подреждане на колони, воден от каузалност. Авторите адаптират рамката за извличане на фактори COAT: един LLM чете метаданните на колоните и примери от данните, за да извлече семантични фактори от високо ниво (например за транзакции с кредитни карти, фактор като „Възмездие“ може да обхваща колоните за сума и търговец). От тези фактори три алгоритъма за откриване на каузалност — PC, LiNGAM и FCI — изграждат насочен каузален граф върху факторите. Проблемът с пренареждането на колоните след това се превръща в Проблем на линейното подреждане (Linear Ordering Problem): намиране на пермутацията π, която максимизира сумата от теглата на насочените ребра, така че колоните-причини да се появяват преди колоните-следствия в сериализирания текст. Тъй като линейното програмиране (LP) има много близко-оптимални решения, те вземат извадка от K ≈ 10 подредби в рамките на 90% от оптимума и изчисляват средната стойност върху тях.

Второ, модул за претегляне, съобразен с каузалността. Не всички колони са еднакво уместни. Колона, която влияе на много фактори, получава по-високо тегло αj = |M⁻¹(cj)|, броят на факторите, за които тя допринася. Крайният резултат за аномалия е среднопретеглената стойност от отрицателните логаритмични вероятности за всяка колона в рамките на K-те подредби.

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

• Подредбата на колоните е нетривиално индуктивно пристрастие (inductive bias) за авторегресивните LLM: поставянето на колоната-причина преди нейната колона-следствие позволява на модела да се обуслови върху правилния контекст, когато приписва вероятност на следствието.
• Откриването на каузалност на ниво фактори (а не на ниво сурови колони) позволява на метода да се справя с таблици със смесен тип данни, където директното откриване на каузалност между хетерогенни колони е зашумено.
• При 6 бенчмарк набора от данни със смесен тип, CausalTAD със SmolLM-135M достига среден AUC-ROC 0.834 срещу 0.803 за AnoLLM — абсолютно подобрение от 3.1 пункта със същия модел.
• По-конкретно при набора от данни Fake Job Posts, CausalTAD постига 0.873 срещу 0.800 за AnoLLM — относителен ръст от 9.1%, което е достатъчно значимо за реална система за триаж.
• В 30 числови ODDS бенчмарка, CausalTAD постига най-добрия среден AUC-ROC, като последователно превъзхожда класическите базови модели (Isolation Forest, ECOD, KNN) и дълбоките методи (DeepSVDD, SLAD).
• И трите алгоритъма за откриване на каузалност побеждават случайния ред при аблационния анализ; LiNGAM леко превъзхожда PC и FCI при наборите със смесени данни.

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

Основното твърдение — че каузалният ред на колоните помага — е добре подкрепено. Аблационният анализ е ясен: замяната на случайния ред с който и да е от трите метода за каузално откриване подобрява резултатите в бенчмарка Fake Job Posts (от 0.832 до 0.870–0.873), а претеглянето според броя фактори допълнително помага във всяка конфигурация. Това е убедителна теза.

Това, което намирам за по-малко убедително, е хипотезата за самоорганизация (bootstrapping assumption). Каузалният граф се конструира чрез използване на LLM за извличане на семантични фактори от самите данни, които системата трябва да анализира. Ако LLM не разбере правилно домейна — например за специфична счетоводна система с нестандартни имена на колони — извличането на фактори ще бъде погрешно, а лошият каузален граф вероятно е по-лош от случайния ред, защото внася системно пристрастие. Авторите признават този риск („разчита на способностите на LLM за извличане на фактори“), но не тестват независимо точността на извличане на фактори.

Съществува и проблем с изчислителните разходи, който е по-сериозен, отколкото статията подсказва. Изпълнението на три алгоритъма за откриване на каузалност, решаването на LP, вземането на извадка от 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 да назове кои редове изглеждат подозрителни, авторите извършват фина настройка на предварително обучен езиков модел върху сериализирани тренировъчни редове от разпределението (нормални), след което оценяват всеки тестов ред чрез неговата отрицателна логаритмична вероятност (negative log-likelihood - NLL) спрямо това научено разпределение. Ред, който не прилича на тренировъчното разпределение, получава висока NLL — това е оценката за аномалия. Без формати на индекси, без парсване на изхода, без крехко извличане чрез регулярни изрази.

Сериализацията преобразува всеки ред от таблицата в низ на естествен език с имена и стойности на характеристиките (features). За колони с текстови стойности NLL се нормализира за всяка колона, за да се избегне пристрастие към дължината, където по-дългите описания иначе механично биха натрупали по-високи вероятностни разходи. За числовите и категориалните колони суровата NLL на ниво токен се сумира в полето. Моделът се настройва фино в полуконтролирана среда (semi-supervised) — само редове с етикет „нормални“ влизат в обучението — за до 2000 стъпки, използвайки разпределено GPU обучение.

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

• Проблемът с изходния формат: предишните подходи за предсказване на индекси изискват от LLM надеждно да извеждат индексите на аномалните редове от пакет (batch). Моделите от фамилията Llama често сдвояват грешни индекси със стойности, генерират индекси извън размера на пакета или просто изброяват всичко като аномално. NLL заобикаля това напълно.
• AnoLLM постига най-добри резултати в шест бенчмарк набора от данни със смесени типове характеристики, включително откриване на измами с автомобилни застраховки и набори от данни за измами в електронната търговия от Kaggle.
• При 30-те предимно числови набора от данни на ODDS бенчмарка, AnoLLM се представя наравно с най-добрите класически базови линии — не по-добре, а просто конкурентно.
• Нормализацията на NLL за всяка колона за текстови характеристики е малко, но важно инженерно решение: без него описание на транзакция с тридесет токена би доминирало в резултата над двуцифрена сума, което е грешен индуктивен уклон.
• Контекст на базовата линия за обучение: подходът zero-shot GPT-4 (arXiv:2406.16308) постига среден AUROC от 74,1 в ODDS, сравним с ECOD (75,5) и KNN (70,7). Предимството на AnoLLM се проявява конкретно при набори от данни, където текстовите и категориалните характеристики носят значим сигнал за аномалия.

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

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

Това, което ме притеснява, е разликата в разходите и ползите, която статията не отразява напълно. AnoLLM изисква фина настройка и поддържане на LLM за инференция — значителен инфраструктурен ангажимент в сравнение с пускането на ECOD или IsolationForest на CPU за секунди. В бенчмарка ODDS (чисто числов), AnoLLM е само „наравно“, не по-добър. Така че аргументите в полза на AnoLLM са изцяло в режима на смесените типове, където шестте оценени набора от данни са от откриване на измами в Kaggle. Шест набора от данни са тънка емпирична основа за силна препоръка, особено след като наборите от данни от Kaggle обикновено имат чисти схеми, фиксирана семантика на колоните и известна основна истина (ground truth) — все неща, които производствените данни в главните книги често нямат.

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

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

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

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

Подходът на AnoLLM с NLL би трябвало, по принцип, да научи тези съвместни модели от нормални исторически записи и да маркира отклонения във всяка комбинация от колони. Това е потенциално по-полезно от базираните на правила JET-ове или статистически тестове върху единични колони.

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

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

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

Докладът​

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

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

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

Какво се потвърждава — и какво не​

Основният емпиричен принос на доклада е солиден. Компилаторът Beancount е обективен, възпроизводим критерий за коректност, а използването на реални фирмени баланси вместо примерни данни добавя екологична валидност. Йерархичната таксономия на грешките е обмислена внимателно — спирането на оценката при първата грешка избягва изкуственото завишаване на „частичното признание“ за безполезни резултати.

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

Най-интересният методологически пропуск е липсата на какъвто и да е итеративен протокол или такъв, базиран на обратна връзка. Без извикване на инструменти (tool-calling), без самокорекция, без цикъл на обратна връзка от компилатора — само генериране от един опит (one-shot). Като се има предвид, че CRITIC (LOG-012) и свързаните с него трудове показват, че интерактивното прецизиране с инструменти значително подобрява точността при задачи с проверими резултати, експеримент с компилатор Beancount в цикъла би бил далеч по-информативен относно възможностите за внедряване.

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

Всяко дизайнерско решение за агента за обратен запис на Bean Labs почива на предположения за това какво могат да правят LLM с Beancount DSL. Този доклад е първата емпирична опора. Водещите констатации са отрезвяващи, но също така интерпретируеми по полезен начин.

Първо, режимите на отказ са специфични, а не случайни. Грешките в балансирането и непознатите сметки са двата доминиращи проблема и двата са решими с цикъл на обратна връзка от компилатора: компилаторът Beancount ви казва точно коя сметка е непозната и дали транзакцията е балансирана. Архитектура на агент, която итерира върху изхода на компилатора — вместо да генерира веднъж и да спре — би трябвало значително да превъзхожда резултатите от един опит тук. Второ, синтаксисът е „безплатен“. Моделите ясно са научили повърхностната граматика на Beancount; те просто не могат надеждно да преведат финансовото намерение в правилни движения по сметките. Тази разлика е важна за това къде да се инвестира в подтикване (prompting) и фина настройка (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) — най-релевантният съществуващ труд за изграждане на агент за корекция с компилатор в цикъла върху архитектурата, която този доклад оценява.