AnoLLM: 財務データにおけるテーブルデータの異常検知に向けたLLMのファインチューニング

2日前に読んだゼロショットLLM異常検知の論文（arXiv:2406.16308）では、GPT-4がトレーニングなしでテーブルデータの外れ値を特定でき、ODDSベンチマークにおいてECODのような従来のベースラインに匹敵することを示していました。しかし、モデルに異常な行のインデックスのリストを出力させるという点に明らかな弱点がありました。オープンソースのモデルは日常的にインデックスを捏造（ハルシネーション）したり、範囲外を指定したり、すべての行を疑わしいとしてフラグを立てたりするため、非常に脆弱です。AmazonのChe-Ping Tsai、Ganyu Teng、Phillip Wallis、Wei DingらによってICLR 2025で発表されたAnoLLMは、この脆弱性を修正しつつ、純粋な数値ベースラインが苦戦し始める混合型データセットへと領域を広げています。

論文について

AnoLLMは、テーブルデータの異常検知を、プロンプトによる分類ではなく、言語モデルの密度推定として再構築します。LLMにどの行が疑わしいかを答えさせる代わりに、著者らは事前学習済みの言語モデルをシリアル化されたイン分布（正常）のトレーニング行でファインチューニングし、学習した分布における負の対数尤度（NLL）によって各テスト行をスコアリングします。トレーニング分布と全く似ていない行は高いNLLを得、それが異常スコアとなります。インデックスの形式も、出力のパースも、脆弱な正規表現による抽出も不要です。

シリアル化により、各テーブルの行は特徴量名と値を持つ自然言語の文字列に変換されます。テキスト値の列については、記述が長くなることで機械的に確率コストが累積するのを防ぐため、NLLは列ごとに正規化されます。数値およびカテゴリ列については、生のトークンレベルのNLLがフィールド全体で合計されます。モデルは準教師あり学習の設定でファインチューニングされ、正常ラベルの付いた行のみがトレーニングに使用されます。分散GPUトレーニングを用いて最大2,000ステップまで学習が行われます。

重要なアイデア

• 出力形式の問題: 従来のインデックス予測アプローチでは、LLMがバッチから異常な行のインデックスを確実に提供する必要がありました。Llamaファミリーのモデルは、間違ったインデックスを値と組み合わせたり、バッチサイズを超えるインデックスを生成したり、単にすべてを異常としてリストしたりすることが頻繁にあります。NLLはこれを完全に回避します。
• AnoLLMは、車両保険の不正検知やKaggleのeコマース不正データセットを含む、混合型の特徴量タイプを持つ6つのベンチマークデータセットで最高のパフォーマンスを達成しました。
• 主に数値で構成される30のODDSベンチマークデータセットにおいて、AnoLLMはトップクラスの従来のベースラインと同等の性能を示しました。明らかに優れているわけではなく、競争力があるというレベルです。
• テキスト特徴量に対する「1列あたりのNLL正規化」は、小さいながらも重要なエンジニアリング上の決定です。これがないと、30トークンのトランザクションの説明が、2桁の金額よりもスコアを支配してしまい、誤った帰納バイアスが生じてしまいます。
• トレーニングベースラインの背景: ゼロショットGPT-4アプローチ（arXiv:2406.16308）は、ODDSで平均AUROC 74.1を達成しており、これはECOD（75.5）やKNN（70.7）に匹敵します。AnoLLMの優位性は、特にテキストやカテゴリの特徴量が意味のある異常シグナルを持つデータセットにおいて発揮されます。

評価できる点と課題

NLLを核とするアイデアは堅実です。ファインチューニングされた言語モデルをシリアル化された行に対する密度推定器として使用することは理にかなっており、すべての列の同時分布を自然に扱うことができます。これは、列ごとに適用される従来の教師なし検知器ではクリーンに行えないことです。インデックス予測の修正は非常に有用であり、ゼロショットのベースラインとの比較も公平です。

気になるのは、論文で十分に報告されていないコスト対効果のギャップです。AnoLLMは、推論のためにLLMのファインチューニングとサービングを必要としますが、これはCPU上で数秒でECODやIsolationForestを実行するのと比較して、かなりのインフラ投資を意味します。ODDSベンチマーク（純粋な数値データ）において、AnoLLMは「同等」であり、それ以上ではありません。したがって、AnoLLMのケースは完全に混合型データの領域にありますが、評価された6つのデータセットはKaggleの不正検知データです。6つのデータセットというのは、強力な推奨を行うための実証的な基盤としては薄いと言わざるを得ません。特に、Kaggleのベンチマークデータセットは、クリーンなスキーマ、固定された列のセマンティクス、既知の正解ラベルを持つ傾向がありますが、これらは本番環境のレジャー（帳簿）データには欠けていることが多い要素です。

列の順序の問題も未解決のままです。CausalTAD (arXiv:2602.07798) は即座にこのギャップを指摘しました。AnoLLMは列を任意の順序でシリアル化し、フィールド間の因果関係を無視しています。勘定科目のタイプが有効な取引範囲に影響を与え、それが期待される取引先に影響を与えるといった、因果関係の連鎖が分かっている構造化データにとって、これは現実的な制限です。CausalTADは並べ替えを線形順序付け問題として構成し、30以上のデータセットでAnoLLMを上回る一貫した改善を報告しています。このギャップが存在し、これほど早く発見されたことは、AnoLLMのシリアル化設計が十分に検討されていなかったことを示唆しています。

また、論文で言及されていないスケールの問題もあります。数値特徴量で直接トレーニングされたテーブルデータ用ディープラーニングモデルなどと比較して、どの程度のボリュームの正常なトレーニングサンプルがあれば、LLMのファインチューニングに価値が出るのでしょうか？数千件のエントリしかない個人のBeancountレジャーの場合、計算コストが精度の向上を簡単に上回ってしまう可能性があります。

なぜこれが財務AIにとって重要なのか

Beancountのレジャーエントリは、AnoLLMがターゲットとしているまさに混合型のデータです。金額（数値）、勘定科目名（構造化テキスト）、支払先/摘要（フリーテキスト）、タグ（カテゴリ）、日付（構造化データ）が含まれます。2024-03-15 * "AWS" "Cloud invoice" Assets:Checking -$2,400 という1つの行は、これらすべてのタイプにわたる情報を同時にエンコードしています。従来の異常検知器は、列のタイプごとに個別の処理を必要とし、それらの間の相関関係、つまり「AWSの請求書は特定の範囲内にあり、特定の勘定科目に計上されるべきである」という結合パターンを見失ってしまうため、ここで苦戦します。

AnoLLMのNLLアプローチは、原理的には、過去の正常なエントリからこれらの結合パターンを学習し、あらゆる列の組み合わせにわたる逸脱をフラグ立てすることができます。これは、ルールベースのJETsや単一列の統計テストよりも潜在的に有用です。

とはいえ、複式簿記の制約は、シリアル化された行だけではAnoLLMが学習できない構造的な知識です。借方と貸方は一致しなければならず、勘定科目の階層は尊重されなければなりません。これらのドメイン不変条件は統計的な規則性ではなくハードな制約であり、トレーニングデータに例外や端数処理の不備が含まれている場合、過去の行に対するLLMのファインチューニングをいくら行っても、それらを確実に強制することはできません。正しいアーキテクチャは、おそらくセマンティックな異常に対するAnoLLMのNLLスコアリングと、構造的な異常に対する明示的なルールチェックを組み合わせたものでしょう。

次に読むべきもの

• 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) — AnoLLMがベースラインとして使用しているBE-GREATモデル。これを理解することで、AnoLLMがインデックス予測以外に実際に何を改善したかが明確になります。