AuditCopilot: LLM за откриване на измами при двустранно счетоводство

Статията, която чета тази седмица, е AuditCopilot: Leveraging LLMs for Fraud Detection in Double-Entry Bookkeeping (arXiv:2512.02726), представена през декември 2025 г. от Kadir, Macharla Vasu, Nair и Sonntag. Тя се намира в пресечната точка между изследванията на LLM агентите и финансовото съответствие: използване на базови модели за откриване на измамни счетоводни записи в реални корпоративни регистри. От всички статии в списъка за четене на Bean Labs досега, тази е най-пряко свързана със същия формат на сурови данни, който ни вълнува.

Статията

Одитът на всяко публично дружество — изискван от одиторския стандарт AS 2401 на PCAOB — трябва да включва тестване на счетоводни записи (Journal Entry Testing - JET): систематични проверки на главната книга за записи, които сигнализират по правила, базирани на евристики. Правилата са неща като „запис, публикуван след полунощ“, „сума с кръгло число“, „необичайна двойка сметки“ или „запис, публикуван от рядко активен потребител“. Тези правила работят, но генерират огромен обем фалшиво положителни резултати: одиторите прекарват по-голямата част от времето си в отхвърляне на очевиден шум.

AuditCopilot проучва дали LLM могат да заменят или допълнят тези правила. Системата предава всеки счетоводен запис — структуриран като JSON-подобен текстов фрагмент с полета за дата на осчетоводяване, суми по дебит/кредит, идентификатори на сметки, данъчни ставки и набор от предварително изчислени бинарни флагове за аномалии — към промпт за LLM, който връща бинарен етикет за аномалия и обяснение на естествен език. Авторите тестват Mistral-8B, Gemma-2B, Gemma-7B и Llama-3.1-8B върху синтетична корпоративна главна книга и една реална анонимизирана данъчна книга, сравнявайки ги с традиционните JET и базов модел Isolation Forest.

Основни идеи

• Върху синтетичния набор от данни (5 000 идентификатора на записи, ~1% истински темп на аномалии), Mistral-8B с пълния промпт постига Прецизност 0.90, Обхват 0.98, F1 0.94 — в сравнение с базовия JET с Прецизност 0.53, Обхват 0.90, F1 0.50, и най-важното, само 12 фалшиво положителни резултата срещу 942 при JET.
• „Пълният“ промпт на AuditCopilot включва не само характеристиките на суровия запис, но и глобална статистика на набора от данни (средна стойност, медиана, 95-и и 99-и персентил на сумите) и предварително изчислен резултат от Isolation Forest за всеки ред. Този инженеринг на контекста е от решаващо значение.
• Върху набора от данни от реалния свят, Gemma-7B с пълния промпт достига Прецизност 0.89, Обхват 0.78, F1 0.83. Когато подсказката от Isolation Forest бъде премахната, прецизността се срива до 0.14 — LLM сам по себе си не се справя със задачата.
• Обясненията са най-защитимият принос на системата: за разлика от числовия резултат за аномалия, всеки флагнат запис идва с обосновка в свободен текст („тази сума надвишава 99-ия персентил за този клъстер от сметки и е осчетоводена извън работно време“), която одиторът може бързо да приеме или отхвърли.
• Без фина настройка никъде. Всичко работи чрез zero-shot или с кратък промпт за ролята на системата, което е добре за разходите по внедряване, но също така означава, че резултатите зависят силно от шаблона на промпта.

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

Резултатът за намаляване на фалшиво положителните резултати е поразителен и реален. Преминаването от 942 на 12 фалшиво положителни резултата върху едни и същи данни е вид оперативна полза, която всъщност променя дали един инструмент ще се използва в практиката. Вярвам в тази посока.

Но имам сериозни резерви относно дизайна на оценката.

Първо, етикетите за „истинска истина“ (ground-truth) в синтетичния набор от данни сами по себе си са конструирани от JET правила. Аномалиите, които са инжектирани, са точно тези модели, които JET са проектирани да улавят. Така че „LLM превъзхожда JET“ върху тестов набор, етикетиран от JET, може отчасти да отразява това, че LLM се учи да имитира същите правила от контекстната статистика в промпта, а не да обобщава извън тях.

Второ, аблацията на Isolation Forest върху реални данни е разобличаваща по начин, който в статията не се обсъжда достатъчно. F1 спада от 0.83 на 0.24 без IF резултатите. Това ми подсказва, че LLM функционира основно като гъвкав праг върху сигнала от IF, а не като независим детектор на аномалии. Системата е по-близо до ML ансамбъл с обвивка от естествен език, отколкото до „базов модел, извършващ одиторски разсъждения“.

Трето, само един набор от данни от реалния свят, извлечен от един индустриален партньор. Авторите признават това, но то означава, че не можем да оценим обобщаването между компании с различен размер, счетоводни системи или индустрии.

Четвърто, статията сравнява с JET и един базов модел на ML (Isolation Forest). Липсват откриване на аномалии, базирано на автоенкодери (autoencoder), XGBoost с инженерно разработени функции и обикновена логистична регресия върху IF резултатите. Пространството на това, което се счита за „класически ML“ тук, е тясно.

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

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

Това е най-близката съществуваща статия до това, което Bean Labs изгражда. Регистрите на Beancount са системи за двустранно счетоводство. Всяка трансакция е набор от редове (postings). Откриването на аномалии в тези редове — необичайни сметки, суми извън диапазона, неправдоподобни дати — е очевидна първа функция за автономен финансов асистент.

Резултатът от AuditCopilot предполага, че правилният подход за одит в Beancount вероятно не е „подаване на сурова трансакция към LLM и питане дали е подозрителна“, а по-скоро „изчисляване на олекотен статистически контекст (базови нива на ниво сметка, времево разпределение, резултати от Isolation Forest) и предоставяне на този обогатен контекст на LLM“. Стойността на LLM е в синтеза и обяснението, а не в суровото оценяване на аномалии.

Намаляването на фалшиво положителните резултати също е пряко приложимо. Инструмент за одит на Beancount, който извежда 942 потенциални аномалии на пускане, ще бъде игнориран. Такъв, който извежда 12 кандидати с висока степен на увереност заедно с обяснения, ще бъде използван. Това не е метрика за производителност — това е метрика за продукт.

Въпросът за безопасността при записване обратно (write-back), който ме вълнува най-много, не е разгледан в тази статия. AuditCopilot само чете и сигнализира; той не предлага корекции и не променя регистъра. Това е правилният обхват за първа статия, но трудният проблем за Bean Labs остава: след като имате сигнализирана аномалия, как безопасно да решите какво да правите с нея?

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

• Understanding Structured Financial Data with LLMs: A Case Study on Fraud Detection (arXiv:2512.13040, ACL 2026) — представя FinFRE-RAG, който добавя извлечени чрез RAG примери в контекста към същия проблем за откриване на измами и прави сравнителен анализ на четири публични набора от данни за измами; директно адресира ограничението за един набор от данни на AuditCopilot.
• Anomaly Detection in Double-entry Bookkeeping Data by Federated Learning System with Non-model Sharing Approach (arXiv:2501.12723) — разглежда ограничението за поверителност, което предотвратява обединяването на данни от регистрите на различни фирми; федеративният подход вероятно е необходим за всяка производствена услуга за одит на Beancount, която иска да се обучава върху клиентски данни, без да ги централизира.
• GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning (arXiv:2406.09187) — проблемът с прилагането на безопасността, който AuditCopilot умишлено избягва: след като аномалиите са маркирани, как да се гарантира, че агентът за записване няма да потвърди промени, които нарушават счетоводните инварианти?