LLMを用いたゼロショット異常検知：GPT-4はテーブルデータでどのようなパフォーマンスを示すか
先月読んだAuditCopilotの論文では、ラベル付きの異常データでファインチューニングを行うことで、仕訳不正検知におけるLLMのベンチマークを行っていました。それ以来、私はゼロショットプロンプティングでどこまで到達できるのか、つまりラベル付きの異常データもドメイン固有のファインチューニングも不要な手法に興味を持っていました。まさにそれを約束しているのが、Li、Zhao、Qiu、Kloft、Smyth、Rudolph、Mandtらによる「Anomaly Detection of Tabular Data Using LLMs」（arXiv:2406.16308）という2024年半ばのワークショップ論文です。GPT-4がECODのような古典的なトランスダクティブ手法に匹敵するという主要な結果は、あまりにも話が良すぎるように聞こえたので、注意深く読んでみました。
論文について
核心となるアイデアは、著者らが「バッチレベル」の異常検知と呼ぶものです。学習データにモデルを適合させてから個々のテストポイントをスコアリングする代わりに、推論時にLLMにN行のバッチを提示し、同じバッチ内の他の行と比較してどの行が異常であるかを特定させます。異常はバッチ内にまばらに存在するため、十分に有能なモデルであれば、暗黙のうちに大多数のパターンを認識し、外れ値にフラグを立てることができるはずだという考えです。再学習もラベル付きの例も不要で、LLMが事前に学習した世界の知識とインコンテキスト推論のみを利用します。
彼らは、現実世界のテーブルデータ異常検知問題の標準的なコレクションである32のデータセットからなるODDSベンチマークで評価を行いました。コンテキストウィンドウの制限により、各評価バッチを150行10列に制限しています。特徴量は「Data i is x_i.」というテンプレートを用いて1次元ずつシリアル化され、LLMは各次元で異常なインデックスを個別に挙げるよう促されます。行の最終的な異常スコアは、フラグが立てられた次元の数を集計したものになります。
商用モデルについてはゼロショットでテストしています。オープンソースモデル（Llama2-7B, Llama2-70B, Mistral-7B）については、ゼロショットの性能が低かったため、ガウス混合分布やカテゴリ分布から生成された5,000バッチの合成データセットでファインチューニングを行うことも提案しています。これには実際の異常ラベルは不要です。これらの ファインチューニング版はLlama2-ADおよびMistral-ADと呼ばれます。
主なアイデア
- GPT-4のゼロショットは、32のODDSデータセット全体で平均AUROC 74.1を達成しました。これは、最高の古典的ベースラインであるECODの75.5に匹敵し、KNNの70.7を上回ります。GPT-3.5は68.3と遅れをとっています。
- Llama2-7Bのゼロショットスコアはわずか51.1（実質的にランダム）でしたが、合成データでのファインチューニングにより60.0まで向上し、+8.9ポイントの改善が見られました。Mistral-7Bは62.4から69.1（+6.7ポイント）に向上しました。
- 「バッチレベル」の枠組みは興味深い概念的転換です。LLMは、クラスを分離するために訓練された識別器としてではなく、バッチ上の暗黙的な密度推定器として機能します。
- ファインチューニングにはLoRAを使用し、合成ガウスデータとカテゴリデータのみを使用しています。実際の異常アノテーションが不要であることは、汎用化が可能であれば実用上で大きな利点となります。
- オープンソースモデルの場合、出力のパースが不安定です。著者らは文法制約を強制し、正規表現パターンを使用して異常インデックスを抽出しています。
有効な点とそうでない点
ベンチマークの範囲が最大の問題です。この論文では、KNNとECODという2つの古典的なベースラインとしか比較していません。Isolation Forest、LOF、One-Class SVM、およびディープラーニングによる異常検知手法は完全に欠落しています。ECODはたまたまODDSで強力なベースラインですが、GPT-4はそれを明確に上回っておらず（74.1対75.5）、Mistral-AD（69.1）も同様です。より広範なベースラインと比較した場合、GPT-4がその地位を維持できるかどうかは定かではありません。
150行/10列という制限も、論文で十分に扱われていない深刻な制約です。実際の会計帳簿には数千の取引と、より多くの特徴量があります。バッチレベルのアプローチがスケールするのか、あるいはバッチが大きくなりパターンが多様化することで異常の識別が困難になり劣化するのかはテストされていません。
分散の数値も懸念材料です。breastwデータセットにおけるGPT-3.5のAUROCは63.1 ± 34.4です。1回の実行で30から98までのスコアが出る可能性がある手法を、実務に導入することはできません。GPT-4はより安定していますが（breastwで98.7 ± 0.5）、他のデータセットでは同様の分散を示しています。
特徴量独立性の仮定も弱点です。LLMは各特徴次元を個別に照会し、スコアを集計します。そのため、結合された特徴パターンについて推論することができません。金額、取引相手、勘定科目の組み合わせが異常な取引であっても、個々の次元では正常に見える場合があります。会計において最も一般的で経済的に重要な多次元的な異常は、設計を大幅に見直さない限り、この手法では捕捉できません。
その後の文献もこれらの懸念を裏付けています。Amazon ScienceのAnoLLM（ICLR 2025）は異なるアプローチをとっています。異常インデックスをプロンプトで求める代わりに、データの分布をモデル化するようにLLMをファインチューニングし、負の対数尤度を異常スコアとして使用することで、不安定な出力パースを完全に回避しています。CausalTAD（arXiv:2602.07798, 2026年2月）は、本論文とAnoLLMに共通する別の欠陥を指摘しています。シリアル化時の列の順序がランダムであり、特徴量間の因果関係が無視されている点です。因果構造を尊重するように列を並べ替えることで、6つのベンチマークにおいて平均AUC-ROCが約0.80から0.83に向上しました。
なぜ金融AIにとって重要なのか
限界はあるものの、Beancount帳簿の異常検知においてゼロショットの方向性は非常に興味深いものです。AuditCopilotの論文ではラベル付きの異常例でのファインチューニングが必要でしたが、実際の不正事例は稀で機密性が高く、ラベル付けには専門の会計士が必要なため、実務で入手するのは困難です。本論文の合成ファインチューニングアプローチ（Llama2-AD, Mistral-AD）はこれを回避します。本物の帳簿に触れることなく、人工的な異常を含む現実的な取引バッチを生成し、ファインチューニングを行うことができます。
バッチレベルのメカニズムは、会計士が実際に考える方法に自然に 適合します。「今月の取引の中で、他の取引と比較して異常なものはどれか？」これは監査における仕訳テストの背後にある直感です。課題は、実際の帳簿の異常は多次元的であることです。金額は普通だが、タイミング、取引相手、勘定科目の組み合わせが異常な支払いです。この論文のように各特徴を独立して照会する方法では、それらを見つけることはできません。
私が期待するのは、行全体を埋め込み、ホリスティックにスコアリングするアプローチのバージョンです（AnoLLMの分布モデリングに近いもの）。これをBeancountの取引データの現実的なサンプルに適用することです。合成ファインチューニングのアイデアは真剣に検討に値します。注入された異常（誤った勘定科目、重複した仕訳、不自然な金額）を持つ合成Beancount帳簿バッチを生成することは容易であり、それらで7Bモデルをファインチューニングすれば、ラベル付きデータを必要とせずに有用なゼロショット監査モデルを作成できる可能性があります。
次に読むべきもの
- AnoLLM: Large Language Models for Tabular Anomaly Detection — ICLR 2025, OpenReview ID 7VkHffT5X2; 本研究の最も直接的な拡張であり、プロンプトによるインデックス予測ではなく尤度ベースのスコアリングを使用しています。
- CausalTAD: Injecting Causal Knowledge into Large Language Models for Tabular Anomaly Detection — arXiv:2602.07798; シリアル化を因果構造に合わせることで、列 順序の欠落を解消しています。
- AD-LLM: Benchmarking Large Language Models for Anomaly Detection — arXiv:2412.11142, ACL Findings 2025; NLPの異常検知タスクをカバーするより広範なベンチマークで、LLMが異常検知器としてどこで信頼でき、どこで信頼できないかを理解するのに役立ちます。
