[P] HDFSでF1=0.9975を達成したMamba-3ログ異常検知器を訓練しました——どこまで伸ばせるのか気になります

Reddit r/MachineLearning / 2026/4/3

💬 オピニオンIdeas & Deep AnalysisModels & Research

要点

  • Mamba-3/SSMをベースにした新しいログ異常検知システムが、定番ベンチマークであるHDFSにおいてF1スコア0.9975を達成したと報告されており、従来のLogRobustをわずかに上回っています。
  • 著者は、ベンチマークの異常セッション群と正常セッション群に対して、非常に高い再現率(約0.9973)と適合率(約0.9976)を記録したと述べています。誤検知(false alarm)と見逃し(miss)はごくわずかです。
  • 効率性が重要な主張です。検知器は小型で(約4.9Mパラメータ)、訓練が速く(RTX 4090で約36分)、GPUメモリ使用量は約1GBに収まり、推論は2ms未満(<500ログイベント/秒)で動作します。
  • 改善は、一般的なハイパラ調整よりも前処理の変更に起因するとされています。つまり、BPE/NLPスタイルのトークン化をやめ、ログテンプレートベースのトークン化に置き換えて、各ログテンプレートを1つのイベントタイプ・トークンとして扱います。
  • この研究は、ログを自然言語の並びとして扱うのではなく、構造化されたイベントテンプレートとして扱うことで、大きな改善が得られる可能性を強調しています。その改善は、Mamba-3のような新しいSSMベースのシーケンスモデルと組み合わせた場合に特に生きる、という点が示されています。
[P] HDFSでF1=0.9975を達成したMamba-3ログ異常検知器を訓練しました — どこまで行けるのか気になります

実験#324はうまくいきました。;)

今回は、ログ異常検知を中心に小さなプロジェクトを作りました。だいたい2日で、最初の実行時の有効性が約60%から、HDFSベンチマークで最終F1スコア0.9975まで到達しました。

現在の前処理と評価設定のもとでは、LogAIはF1=0.9975を達成しており、最近の比較研究で報告されているLogRobustの0.996(HDFS)よりわずかに上回っています。

それが実際に何を意味するかというと:

  • テストセットの3,368件の異常セッションで、約9件を見逃し(再現率 = 0.9973)
  • 約112k件の正常セッションで、誤警報はわずか約3件だけに抑えられました(精度 = 0.9976)

特に面白いのは、これがたぶん、ほんの数週間前に公開されたばかりのMamba-3 / SSMの上に構築された、最初のログ異常検知モデルのひとつである可能性が高いことです。

モデルは小さいです:

  • 4.9Mパラメータ
  • RTX 4090で約36分学習
  • 必要なGPUメモリは約1 GB
  • 推論はコンシューマ向けGPU1枚で2 ms未満(つまり1秒あたり500件以上のログイベント)

比較のために言うと、以前の自分のアプローチは学習に約20時間かかっていました。

ここで使ったデータセットは、LogHub / Zenodoにある定番のHDFSベンチマークで、Amazon EC2のログに基づいています:

  • 11M+の生ログ行
  • 575,061セッション
  • 16,838件の異常セッション(2.9%)

このベンチマークは2017年以降、多くの論文で使われているので、アイデアを試すのに役立つ場所です。

いちばん驚いたのはスコアだけでなく、実際に差を生んだ要因が何だったのかです。

自分は最初、かなり標準的なNLPスタイルのアプローチから始めました:

  • BPEトークナイザー
  • 比較的大きいモデルで、だいたい40Mパラメータ

それで、実行によって0.61〜0.74くらいのF1は得られました。最初はそれなりに見えましたが、ずっと壁にぶつかり続けました。ハイパーパラメータの調整は少しは効きましたが、十分ではありません。

ブレイクスルーは、ログを「自然言語」として扱うのをやめたときに起きました。

行をサブワードトークンに分割する代わりに、テンプレートベースのトークナイズに切り替えました。つまり、1つのログテンプレート=イベントタイプを表す1つのトークンです。

その結果、モデルにテキストのようなものを与えるのではなく、次のような系列を与えます:

[5, 3, 7, 5, 5, 3, 12, 12, 5, ...]

例えば:

  • "Receiving block blk_123 from 10.0.0.1" - テンプレート #5
  • "PacketResponder 1 terminating" - テンプレート #3
  • "Unexpected error deleting block blk_456" - テンプレート #12

この1つの変更だけで、かなりのことが同時に起きました:

  • 語彙数が約8000から約50にまで減少
  • モデルサイズがだいたい10倍小さくなった
  • 学習が数時間から数分へ
  • そして、何より重要なのは、過学習の問題がほとんど消えたこと

2つ目の重要な変更は、分類ヘッドをアーキテクチャに合わせたことです。Mambaは因果的なので、最後のトークンには系列コンテキストの圧縮要約が入っています。プーリング/分類の設定でそれを尊重するようにしたところ、モデルは自分が期待していた挙動をし始めました。

学習パイプラインはシンプルでした:

  • 事前学習(次トークン予測):モデルには正常ログだけが見え、「正常」がどのようなものかを学習する
  • 微調整(分類):ラベル付きの正常/異常セッションをモデルに見せる
  • テスト:モデルに未見のセッションを与え、正常か異常かを予測させる

データ分割は70%訓練/10%検証/20%テストだったので、報告されているF1は、学習中にモデルが見ていないセッションでのものです。

もう1つ便利なのは、出力が単なる2値ではないことです。モデルは0〜1の範囲で連続的な異常スコアを出します。

なので、本番では例えば複数のしきい値で利用できます:

  • > 0.7 = 警告
  • > 0.95 = 重大

あるいは、特定のシステムにおけるベースラインのノイズレベルを追跡する適応的なしきい値でも運用できます。

自分にとってのより広い教訓は、AIモデル(チェス)で遊んでいるときに身につけたスキルやワークフローが、驚くほど他の領域にもうまく移植できるということです。これは別に新しい話ではなく、多くのAIラボがゲームから始めているし、今もそうしている場合が多いのですが、それが実際に機能するのを見るのは気持ちいいです。

それに、正直に言うと自分ひとりでここまで来たわけではありません。これは次の組み合わせです:

  • たくさんの論文を読むこと
  • 自動化された実験ループを回すこと
  • AIアシスタントを盲信せず、あえて挑戦すること
  • そして、その後自分で解釈してチューニングすること

かなり大雑把な内訳:

  • 50%:論文を読み、アイデアを抽出
  • 30%:自動化されたハイパーパラメータ/実験ループ
  • 20%:学んだことに基づく手動チューニングと変更

今度はたぶんダッシュボードを作って、自分のAstrography / Astropolisの本番ログで試してみます。あるいは、まずBGL、Thunderbird、Spiritでさらに先に進めるかもしれません。

正直なところ、まともなハードウェア、公開された研究、新しいアーキテクチャをうまく組み合わせて十分早く試せるなら、ゲーミングPCでも今これだけできるのは、まだけっこうワイルドだと感じています。

ここでの皆さんの考えが気になります:

  • この方向性は本当に有望に見えますか?
  • 他に誰か、ログモデリングにSSM / Mambaを試した人はいますか?
  • そして次にどのベンチマークに挑みますか:BGL、Thunderbird、Spiritのどれ?

興味があれば、前処理、学習ループ、そして最終的にうまく噛み合う前に自分を60〜70%で足止めしたミスについても、もう少し共有できます。

P.S. さまざまなシードにまたがって、有効性と再現性もテストしました。ほとんどの場合、実際に以前よりわずかに良い結果でした。

https://preview.redd.it/3hrr4prgbzsg1.png?width=1794&format=png&auto=webp&s=d50ff21226e9aa97c2c0bbefed77be5dd8389cb8

submitted by /u/Adam_Jesion
[link] [comments]