Salta al contenuto principale

Rilevamento di Anomalie Zero-Shot con LLM: Come GPT-4 si Comporta sui Dati Tabulari

7 minuti di letturaMike ThriftMike Thrift
Rilevamento di Anomalie Zero-Shot con LLM: Come GPT-4 si Comporta sui Dati Tabulari

L'articolo AuditCopilot che ho letto il mese scorso ha confrontato i LLM sul rilevamento di frodi nelle scritture contabili, utilizzando il fine-tuning su dati di anomalie etichettate. Da allora sono curioso di sapere se il prompt zero-shot possa portare la maggior parte del percorso — senza anomalie etichettate, senza fine-tuning specifico del dominio. Questa è esattamente la promessa di "Anomaly Detection of Tabular Data Using LLMs" di Li, Zhao, Qiu, Kloft, Smyth, Rudolph e Mandt (arXiv:2406.16308), un articolo di workshop della metà del 2024. Il risultato principale — GPT-4 che eguaglia metodi trasduttivi classici come ECOD — sembrava quasi troppo bello per essere vero, così l'ho letto attentamente.

L'articolo

L'idea centrale è ciò che gli autori chiamano rilevamento di anomalie "a livello di lotto". Invece di adattare un modello sui dati di addestramento e poi valutare i punti test singolarmente, si presenta al LLM un lotto di N righe al momento dell'inferenza e gli si chiede di identificare quali righe sono anomale rispetto alle altre nello stesso lotto. Le anomalie sono sparse all'interno di qualsiasi lotto, quindi un modello sufficientemente capace dovrebbe riconoscere implicitamente lo schema maggioritario e contrassegnare i valori anomali. Nessun riaddestramento, nessun esempio etichettato — solo la conoscenza del mondo pre-addestrata del LLM e il ragionamento nel contesto.

Valutano sul benchmark ODDS di 32 dataset, una raccolta standard di problemi reali di rilevamento di anomalie su dati tabulari. A causa dei limiti della finestra di contesto, limitano ogni lotto di valutazione a 150 righe e 10 colonne. Le caratteristiche vengono serializzate una dimensione alla volta con il modello "Data i è x_i." e al LLM viene chiesto di nominare gli indici anomali per ogni dimensione separatamente; il punteggio di anomalia finale di una riga aggrega quante dimensioni l'hanno contrassegnata.

Per i modelli proprietari, testano in modalità zero-shot. Per i modelli open-source (Llama2-7B, Llama2-70B, Mistral-7B), le prestazioni zero-shot sono scarse, quindi propongono anche il fine-tuning su un dataset sintetico di 5.000 lotti generati da miscele gaussiane e distribuzioni categoriche — nessuna etichetta di anomalia reale richiesta. Le varianti con fine-tuning sono chiamate Llama2-AD e Mistral-AD.

Idee chiave

  • GPT-4 zero-shot raggiunge un AUROC medio di 74.1 su 32 dataset ODDS, rispetto al 75.5 di ECOD (la migliore linea di base classica) e al 70.7 di KNN. GPT-3.5 è in ritardo a 68.3.
  • Llama2-7B zero-shot ottiene solo 51.1 — essenzialmente casuale — ma il fine-tuning su dati sintetici lo porta a 60.0, un guadagno di +8.9 punti. Mistral-7B migliora da 62.4 a 69.1 (+6.7 punti).
  • La cornice "a livello di lotto" è la mossa concettuale interessante: il LLM agisce come uno stimatore di densità implicito sul lotto, piuttosto che come un discriminatore addestrato a separare le classi.
  • Il fine-tuning utilizza LoRA su dati sintetici gaussiani e categorici — nessuna annotazione di anomalia reale necessaria. Questo è un vantaggio pratico significativo se generalizza.
  • L'analisi dell'output è fragile per i modelli open-source; gli autori impongono vincoli grammaticali e usano espressioni regolari per estrarre gli indici delle anomalie.

Cosa regge — e cosa no

La copertura del benchmark è il problema più grande. L'articolo confronta solo due linee di base classiche: KNN ed ECOD. Isolation Forest, LOF, One-Class SVM e qualsiasi metodo di rilevamento anomalie basato su deep learning sono completamente assenti. ECOD risulta essere una linea di base forte su ODDS — ma GPT-4 non la batte chiaramente (74.1 contro 75.5), e nemmeno Mistral-AD (69.1). Contro un insieme più ampio di linee di base, non è ovvio che GPT-4 manterrebbe la sua posizione.

Il limite di 150 righe / 10 colonne è anche un vincolo serio che l'articolo non affronta adeguatamente. I registri contabili reali hanno migliaia di transazioni e molte più caratteristiche. Se l'approccio a livello di lotto sia scalabile — o se degradi perché le anomalie diventano più difficili da distinguere in lotti più grandi con motivi più diversificati — non viene testato.

I numeri sulla varianza sono preoccupanti. GPT-3.5 sul dataset breastw ottiene 63.1 ± 34.4 AUROC. Non è un metodo che si possa implementare quando una singola esecuzione può plausibilmente ottenere un punteggio ovunque da 30 a 98. GPT-4 è più stretto (98.7 ± 0.5 su breastw) ma mostra varianza simile su altri dataset.

L'ipotesi di indipendenza delle caratteristiche è un'altra lacuna. Il LLM interroga ogni dimensione della caratteristica separatamente e aggrega i punteggi. Non può ragionare su modelli congiunti di caratteristiche — una transazione con una combinazione insolita di importo, controparte e codice contabile potrebbe sembrare normale su ogni singola dimensione. Le anomalie multidimensionali, che sono probabilmente il tipo più comune e economicamente significativo in contabilità, non verranno rilevate con questo approccio senza una riprogettazione significativa.

La letteratura successiva conferma queste preoccupazioni. AnoLLM (ICLR 2025) di Amazon Science adotta un approccio diverso: invece di richiedere indici di anomalia, mette a punto un LLM per modellare la distribuzione dei dati e utilizza la log-verosimiglianza negativa come punteggio di anomalia, evitando completamente il regime fragile di analisi dell'output. CausalTAD (arXiv:2602.07798, febbraio 2026) identifica un'altra lacuna condivisa da questo articolo e AnoLLM: l'ordinamento delle colonne durante la serializzazione è casuale, ignorando le relazioni causali tra le caratteristiche. Riordinare le colonne per rispettare la struttura causale migliora l'AUC-ROC medio da ~0.80 a 0.83 su sei benchmark.

Perché questo è importante per la finanza basata sull'IA

Nonostante i suoi limiti, la direzione zero-shot è genuinamente interessante per il rilevamento di anomalie nei registri Beancount. L'articolo AuditCopilot richiedeva il fine-tuning su esempi di anomalie etichettate — difficili da ottenere nella pratica perché i casi di frode reali sono rari, sensibili e la loro etichettatura richiede contabili esperti. L'approccio di fine-tuning sintetico dell'articolo (Llama2-AD, Mistral-AD) lo elude: si generano lotti di transazioni dall'aspetto realistico con anomalie artificiali e si mette a punto senza mai toccare un registro reale.

Il meccanismo a livello di lotto si allinea naturalmente a come i contabili pensano effettivamente: "in questo mese di transazioni, quali voci appaiono insolite rispetto al resto?" Questa è l'intuizione alla base del test delle scritture contabili nella revisione. La sfida è che le anomalie dei registri reali sono multidimensionali — un pagamento normale nell'importo ma insolito nella tempistica, nella controparte e nella combinazione di codici contabili. Interrogare ogni caratteristica in modo indipendente, come fa questo articolo, non le individuerà.

Quello che vorrei vedere è una versione di questo approccio in cui l'intera riga sia incorporata e valutata in modo olistico — più vicino a ciò che AnoLLM fa con la modellazione della distribuzione — applicata a un campione realistico di dati di transazioni Beancount. L'idea del fine-tuning sintetico merita una seria esplorazione; generare lotti di registri Beancount sintetici con anomalie iniettate (conti errati, voci duplicate, importi inverosimili) è semplice, e mettere a punto un modello da 7B su di essi potrebbe produrre un revisore zero-shot utile senza richiedere alcun dato etichettato reale.

Cosa leggere dopo

  • AnoLLM: Large Language Models for Tabular Anomaly Detection — ICLR 2025, OpenReview ID 7VkHffT5X2; l'estensione più diretta di questo lavoro, che utilizza il punteggio basato sulla verosimiglianza invece della previsione dell'indice tramite prompt
  • CausalTAD: Injecting Causal Knowledge into Large Language Models for Tabular Anomaly Detection — arXiv:2602.07798; affronta la lacuna dell'ordinamento delle colonne allineando la serializzazione alla struttura causale
  • AD-LLM: Benchmarking Large Language Models for Anomaly Detection — arXiv:2412.11142, ACL Findings 2025; un benchmark più ampio che copre compiti di rilevamento anomalie in NLP, utile per capire dove i LLM sono già affidabili vs. inaffidabili come rilevatori di anomalie

Condividi questo articolo