AuditCopilot: LLM для виявлення шахрайства в подвійній бухгалтерії

Стаття, яку я читаю цього тижня — це AuditCopilot: Leveraging LLMs for Fraud Detection in Double-Entry Bookkeeping (arXiv:2512.02726), представлена в грудні 2025 року Кадіром, Мачарлою Васу, Наїром та Зоннтагом. Вона знаходиться на перетині досліджень LLM-агентів та фінансового комплаєнсу: використання базових моделей для виявлення шахрайських журнальних проведень у реальних корпоративних реєстрах. З усіх статей у списку читання Bean Labs на сьогодні, ця безпосередньо стосується того самого формату сирих даних, який нас цікавить.

Стаття

Аудит кожної публічної компанії — згідно зі стандартом аудиту PCAOB AS 2401 — має включати тестування журнальних проведень (JET): систематичну перевірку реєстру на наявність записів, які відповідають евристичним правилам. Ці правила включають такі речі, як "запис внесено після півночі", "кругла сума", "незвичайна пара рахунків" або "запис внесено користувачем, який рідко буває активним". Ці правила працюють, але вони генерують величезну кількість хибнопозитивних результатів: аудитори витрачають більшу частину свого часу на відсіювання очевидного шуму.

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

Ключові ідеї

• На синтетичному наборі даних (5000 ID проведень, рівень реальних аномалій ~1%), Mistral-8B з повним промптом досягає точності (Precision) 0.90, повноти (Recall) 0.98 та F1-міри 0.94 — порівняно з базовим JET, де Precision 0.53, Recall 0.90, F1 0.50. Важливо, що було зафіксовано лише 12 хибнопозитивних результатів проти 942 у JET.
• "Повний" промпт AuditCopilot включає не лише ознаки сирого запису, але й глобальну статистику набору даних (середнє значення, медіану, суми 95-го та 99-го перцентилів) та попередньо обчислений показник Isolation Forest для кожного рядка. Ця інженерія контексту є вирішальною.
• На реальному наборі даних Gemma-7B з повним промптом досягає Precision 0.89, Recall 0.78, F1 0.83. Коли підказку Isolation Forest видаляють, точність падає до 0.14 — сама лише LLM не справляється з навантаженням.
• Пояснення є найвагомішим внеском системи: на відміну від числової оцінки аномалії, кожен позначений запис супроводжується обґрунтуванням природною мовою ("ця сума перевищує 99-й перцентиль для цього кластера рахунків і внесена в неробочий час"), яке аудитор може швидко прийняти або відхилити.
• Жодного донавчання (fine-tuning). Усе працює за принципом zero-shot або з коротким промптом системної ролі, що вигідно з точки зору вартості розгортання, але також означає, що результати дуже залежать від шаблону промпту.

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

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

Але у мене є серйозні застереження щодо дизайну оцінювання.

По-перше, мітки "істини" (ground-truth) у синтетичному наборі даних самі по собі сконструйовані на основі правил JET. Аномалії, які були впроваджені, — це саме ті патерни, для виявлення яких створювалися JET. Тож твердження, що "LLM перевершує JET" на наборі даних, маркованому за правилами JET, може частково відображати те, що LLM навчилася імітувати ті самі правила на основі контекстної статистики в промпті, а не узагальнювати поза їх межами.

По-друге, абляція Isolation Forest на реальних даних є нищівною в такий спосіб, який у статті обговорюється недостатньо. Показник F1 падає з 0.83 до 0.24 без балів IF. Це говорить мені про те, що LLM функціонує насамперед як гнучкий поріг поверх сигналу IF, а не як незалежний детектор аномалій. Система ближча до ансамблю машинного навчання з оболонкою з природної мови, ніж до "базової моделі, що здійснює аудиторське мислення".

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

По-четверте, стаття порівнює результати з JET та одним базовим алгоритмом ML (Isolation Forest). Виявлення аномалій на основі автоенкодерів, XGBoost з інженерними ознаками та проста логістична регресія на балах IF відсутні. Спектр того, що тут вважається "класичним ML", є вузьким.

Питання галюцинацій не розглядається. Автори називають пояснення ключовим внеском, але немає оцінки того, чи є обґрунтування природною мовою фактично правильними або узгодженими з бінарним передбаченням.

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

Це найближча до розробок Bean Labs стаття з усіх наявних. Реєстри Beancount — це системи подвійної бухгалтерії. Кожна транзакція — це набір рядків проведень. Виявлення аномалій у цих рядках — незвичайні рахунки, суми поза межами діапазону, неправдоподібні часові патерни — є очевидною першою функцією для автономного фінансового помічника.

Результат AuditCopilot свідчить про те, що правильний підхід для аудиту Beancount, ймовірно, полягає не в тому, щоб "передати LLM сиру транзакцію і запитати, чи є вона підозрілою", а в тому, щоб "обчислити легкий статистичний контекст (базові показники на рівні рахунків, часовий розподіл, бали Isolation Forest) і надати LLM цей збагачений контекст". Цінність LLM полягає в синтезі та поясненні, а не в чистому оцінюванні аномалій.

Зменшення кількості хибнопозитивних результатів також є безпосередньо релевантним. Аудиторський інструмент Beancount, який видає 942 потенційні аномалії за один запуск, буде проігнорований. Той, що видає 12 кандидатів з високим рівнем достовірності разом із поясненнями, буде використовуватися. Це не просто метрика продуктивності — це продуктова метрика.

Питання безпеки зворотного запису (write-back safety), яке мене найбільше хвилює, у цій статті не розглядається. 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 свідомо обходить: як тільки аномалії позначені, як переконатися, що агент запису не внесе зміни, які порушують інваріанти бухгалтерського обліку?