AnoLLM: тонке налаштування LLM для виявлення аномалій у табличних фінансових даних

Стаття про zero-shot виявлення аномалій за допомогою LLM, яку я прочитав два дні тому (arXiv:2406.16308), показала, що GPT-4 може ідентифікувати табличні викиди без будь-якого навчання, відповідаючи класичним базовим показникам, таким як ECOD у тесті ODDS. Але у неї був очевидний недолік: прохання до моделі вивести список індексів аномальних рядків є ненадійним — моделі з відкритим кодом постійно галюцинують індексами, виходять за межі або позначають кожен рядок як підозрілий. AnoLLM, опублікований на ICLR 2025 Че-Пін Цаєм, Ганью Тенгом, Філліпом Уоллісом та Вей Діном з Amazon, усуває цю вразливість, водночас просуваючись у набори даних змішаного типу, де суто числові базові моделі починають відчувати труднощі.

Про статтю

AnoLLM переосмислює виявлення табличних аномалій як оцінку щільності мовної моделі, а не як класифікацію за допомогою промптів. Замість того, щоб просити LLM назвати, які рядки виглядають підозрілими, автори проводять тонке налаштування попередньо навченої мовної моделі на серіалізованих тренувальних рядках з нормальним розподілом, а потім оцінюють кожен тестовий рядок за його від’ємною логарифмічною правдоподібністю (NLL) відповідно до цього вивченого розподілу. Рядок, який зовсім не схожий на тренувальний розподіл, отримує високий NLL — це і є оцінка аномальності. Жодних форматів індексів, жодного парсингу виводу, жодного крихкого вилучення за допомогою регулярних виразів.

Серіалізація перетворює кожен рядок таблиці на рядок природною мовою з назвами ознак та їхніми значеннями. Для стовпців із текстовими значеннями NLL нормалізується для кожного стовпця, щоб уникнути зміщення через довжину, де довші описи інакше б мехачно накопичували вищі витрати ймовірності. Для числових і категоріальних стовпців необроблений NLL на рівні токенів підсумовується по всьому полю. Модель налаштовується в напівкерованому режимі — у навчанні беруть участь лише рядки з міткою «нормальні» — до 2000 кроків з використанням розподіленого навчання на GPU.

Ключові ідеї

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

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

Основна ідея NLL є обґрунтованою. Використання тонко налаштованої мовної моделі як оцінювача щільності над серіалізованими рядками є принциповим підходом, і він природним чином обробляє спільний розподіл усіх стовпців одночасно — те, чого не можуть зробити класичні некеровані детектори, що застосовуються окремо до кожного стовпця. Виправлення прогнозування індексів є дійсно корисним, а порівняння з базовим рівнем zero-shot — чесним.

Що мене турбує, так це розрив між витратами та вигодами, про який у статті повідомляється недостатньо. AnoLLM вимагає тонкого налаштування та обслуговування LLM для виведення — це значне інфраструктурне зобов’язання порівняно з налаштуванням ECOD або IsolationForest на процесорі за лічені секунди. На тесті ODDS (суто числовому) AnoLLM лише «на рівні», не краще. Отже, аргументи на користь AnoLLM повністю лежать у площині змішаних типів, де шість оцінених наборів даних стосуються виявлення шахрайства на Kaggle. Шість наборів даних — це слабкий емпіричний фундамент для впевненої рекомендації, особливо враховуючи, що набори даних з Kaggle зазвичай мають чисті схеми, фіксовану семантику стовпців і відомі істинні значення — усе те, чого часто бракує реальним даним реєстрів.

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

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

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

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

Підхід NLL в AnoLLM, в принципі, дозволив би вивчити ці спільні закономірності з нормальних історичних записів і позначати відхилення в будь-якій комбінації стовпців. Це потенційно корисніше за правила або статистичні тести для окремих стовпців.

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

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

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