LLM異常検知サーベイ (NAACL 2025)：強力な分類体系、欠如した表形式データへの対応

このスレッドの過去3つのエントリーでは、AnoLLM、CausalTAD、AD-LLMについて取り上げました。これらはいずれも表形式データの異常検知を具体的にターゲットとしたものです。Ruiyao Xu氏とKaize Ding氏による、NAACL 2025 Findingsに採択されたこのサーベイ論文は、それらのスレッドを統合し、統一されたランドスケープ・マップとして提示することを目的としています。私は設計空間を明確にするような分類体系を期待していましたが、得られたものは、汎用性を装いつつも、その大半が画像およびビデオの異常検知に関する調査でした。

論文の内容

Xu氏とDing氏のサーベイ（arXiv:2409.01980）は、LLMベースの異常検知および分布外（OOD）検知を、2つのハイレベルなクラスに整理することを提案しています。一つはモデルが直接異常を特定する「検知用LLM（LLMs for Detection）」、もう一つはモデルが訓練データを拡張したり、後続の検知器に供給する自然言語による説明を生成したりする「生成用LLM（LLMs for Generation）」です。各クラスはさらに細分化されます。検知は、プロンプトベースの手法（自然言語のプロンプトで照会される凍結または調整済みLLM）と、コントラスティブ学習ベースの手法（画像パッチとテキスト記述を比較して異常性をスコアリングするCLIPファミリーのモデル）に分かれます。生成は、拡張中心の手法（擬似OODラベルや合成マイノリティサンプルの生成）と、説明中心の手法（フラグが立てられたイベントに対して自然言語による根拠を生成する）に分かれます。

付属のGitHubリーディングリストには、約39本の論文が掲載されています。検知に関するものが24本、拡張に関するものが10本、説明に関するものが5本です。

主なアイデア

• コントラスティブ学習ベースの手法が画像異常検知を支配している。 WinCLIPは、データセット固有の調整なしで、MVTec-ADのゼロショット異常分類およびセグメンテーションにおいて、それぞれ91.8%と85.1%のAUROCを達成しました。これは、そのデータセットで学習された教師あり手法に匹敵する性能です。
• 凍結されたLLMはテキスト以外のデータに対してモダリティ・ギャップに直面する。 サーベイでは、「凍結されたLLMを様々なデータタイプの異常またはOOD検知結果のために直接プロンプティングすると、テキストと他のデータモダリティとの間の固有のモダリティ・ギャップにより、最適ではないパフォーマンスになることが多い」と明記されています。
• LoRAとアダプターチューニングがそのギャップの多くを解消する。 AnomalyGPTやAnomalyCLIPのような手法は、パラメータ効率の良い技術でファインチューニングを行っており、凍結されたモデルを大幅に上回る性能を発揮します。
• 拡張としての生成は十分に活用されていない。 BLIP-2で生成されたキャプションレベルの擬似OODラベルは、OOD検知において単語レベルや記述レベルの代替案を上回っており、視覚的なタスクであっても、より豊かなテキストによる教師あり学習が重要であることを示唆しています。
• 説明中心の生成は最も新しいサブカテゴリーである。 Holmes-VADやVAD-LLaMAのようなシステムは、単なるバイナリフラグを超えて、主に監視ビデオにおける異常なイベントに対して自然言語による根拠を生成します。
• 表形式データがほぼ欠如している。 サーベイでは、Liら（2024）による「Tabular」という、表の行をテキストプロンプトに変換してLoRAでファインチューニングする手法が1つ引用されていますが、比較数値は提供されていません。

有効な点、そうでない点

2クラスの分類体系は非常に洗練されており、私自身の思考を整理するためにも活用するつもりです。「検知 vs 生成」の区別は、実際のアーキテクチャ上の分岐点を捉えています。LLMに直接分類させるか、あるいはLLMを使用して従来の検知器のためにより良い学習信号を構築するかのどちらかです。

承服しがたいのは、この論文を広く「異常検知のサーベイ」として位置づけている点です。対象範囲は、産業用欠陥画像（MVTec-AD、VisA）や監視ビデオ（UCF-Crime、XD-Violence）に圧倒的に偏っています。リストアップされた約39本の論文のうち、表形式データや財務データを扱っているものはほとんどありません。時系列データについては数件の引用がありますが、表形式データについては1文触れられているだけです。これはBean Labsのためのランドスケープ・マップではなく、欠陥検知にCLIPを使用したいコンピュータビジョン研究者のためのマップです。

著者らは「紙幅の都合上、詳細な指標の要約は行わない」と述べていますが、これは比較表が存在しないことを丁寧に言い換えたに過ぎません。サーベイ論文において、定量的な統合が欠如していることは重大な欠陥です。読者は引用された各論文を個別に調べない限り、自分のユースケースにどのパラダイムが適しているかをこの論文から判断することはできません。

ハルシネーションの課題は未解決の問題として挙げられていますが、その扱いは浅いものです。リスクを挙げるだけで、どの検知パラダイムがより影響を受けやすいのか、あるいは説明中心の生成が人間によるレビューを通じてハルシネーションをどのように検知しやすくするかといった分析はありません。

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

画像中心の内容ではありますが、2つのサブカテゴリーが関連しています。第一に、説明中心の生成というサブカテゴリーは、まさにBeancount監査エージェントが必要としているものです。仕訳が異常であるというフラグを立てるだけでなく、なぜ異常なのかを説明する自然言語の文章が必要です。財務監査人は、バイナリの出力だけでは行動できません。第二に、表形式の異常検知に関するこのサーベイのほぼ完全な沈黙自体が、示唆に富んでいます。これは、私が追ってきたAnoLLM、CausalTAD、AD-LLMという流れが、開拓され尽くした分野ではなくフロンティア領域であることを裏付けています。また、Beancount元帳用のLLMベースの監査ツールを設計するには、まだ表形式の設定に移植されていないビジョン異常検知の知見を統合する必要があることを示しています。

プロンプティング vs チューニングのトレードオフは、最も実用的な知見です。ゼロショットプロンプティングは第一近似としては機能しますが、モダリティ・ギャップに悩まされます。代表的なラベル付きサンプルを用いたLoRAベースのファインチューニングが、そのギャップを埋めます。過去の元帳から異常のラベル付きサンプルが得られるBeancountの導入においては、純粋なプロンプティングよりもファインチューニングの道の方が信頼性が高いと考えられます。

次に読むべきもの

• "Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs" (arXiv:2406.03614) — 実際の総勘定元帳の仕訳にLLMのsentence-transformer埋め込みを使用しており、このサーベイのフレームワークからBeancountの表形式ユースケースへの直接的な橋渡しとなります。
• "Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework" (arXiv:2403.19735) — 市場データの異常検知のためのマルチエージェント・パイプライン。このマルチエージェント調整パターンは、元帳監査にも応用できる可能性があります。
• AnomalyGPT (arXiv:2308.15366) — ピクセルレベルの局所化が可能な、産業用異常検知のためにファインチューニングされたLVLM。これを読むことで、サーベイでは記述されているものの説明されていない「検知のためのLLMチューニング」がアーキテクチャ的に何を意味するのかが明確になります。