AnoLLM: Фина настройка на LLM за откриване на таблични аномалии във финансови данни

Статията за zero-shot откриване на аномалии чрез LLM, която прочетох преди два дни (arXiv:2406.16308), показа, че GPT-4 може да идентифицира таблични отклонения без никакво обучение, съвпадайки с класически базови линии като ECOD в бенчмарка ODDS. Но тя имаше очевидна слабост: изискването моделът да изведе списък с индекси на аномални редове е крехко — моделите с отворен код рутинно халюцинират индекси, излизат извън границите или маркират всеки ред като подозрителен. AnoLLM, публикуван на ICLR 2025 от Che-Ping Tsai, Ganyu Teng, Phillip Wallis и Wei Ding от Amazon, коригира тази крехкост, като същевременно навлиза в набори от данни от смесен тип, където чисто числовите базови линии започват да изпитват затруднения.

Статията

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 извън предсказването на индекси.