| 実験#324はうまくいきました。;) 今回は、ログ異常検知を中心に小さなプロジェクトを作りました。だいたい2日で、最初の実行時の有効性が約60%から、HDFSベンチマークで最終F1スコア0.9975まで到達しました。 現在の前処理と評価設定のもとでは、LogAIはF1=0.9975を達成しており、最近の比較研究で報告されているLogRobustの0.996(HDFS)よりわずかに上回っています。 それが実際に何を意味するかというと:
特に面白いのは、これがたぶん、ほんの数週間前に公開されたばかりのMamba-3 / SSMの上に構築された、最初のログ異常検知モデルのひとつである可能性が高いことです。 モデルは小さいです:
比較のために言うと、以前の自分のアプローチは学習に約20時間かかっていました。 ここで使ったデータセットは、LogHub / Zenodoにある定番のHDFSベンチマークで、Amazon EC2のログに基づいています:
このベンチマークは2017年以降、多くの論文で使われているので、アイデアを試すのに役立つ場所です。 いちばん驚いたのはスコアだけでなく、実際に差を生んだ要因が何だったのかです。 自分は最初、かなり標準的なNLPスタイルのアプローチから始めました:
それで、実行によって0.61〜0.74くらいのF1は得られました。最初はそれなりに見えましたが、ずっと壁にぶつかり続けました。ハイパーパラメータの調整は少しは効きましたが、十分ではありません。 ブレイクスルーは、ログを「自然言語」として扱うのをやめたときに起きました。 行をサブワードトークンに分割する代わりに、テンプレートベースのトークナイズに切り替えました。つまり、1つのログテンプレート=イベントタイプを表す1つのトークンです。 その結果、モデルにテキストのようなものを与えるのではなく、次のような系列を与えます: [5, 3, 7, 5, 5, 3, 12, 12, 5, ...] 例えば:
この1つの変更だけで、かなりのことが同時に起きました:
2つ目の重要な変更は、分類ヘッドをアーキテクチャに合わせたことです。Mambaは因果的なので、最後のトークンには系列コンテキストの圧縮要約が入っています。プーリング/分類の設定でそれを尊重するようにしたところ、モデルは自分が期待していた挙動をし始めました。 学習パイプラインはシンプルでした:
データ分割は70%訓練/10%検証/20%テストだったので、報告されているF1は、学習中にモデルが見ていないセッションでのものです。 もう1つ便利なのは、出力が単なる2値ではないことです。モデルは0〜1の範囲で連続的な異常スコアを出します。 なので、本番では例えば複数のしきい値で利用できます:
あるいは、特定のシステムにおけるベースラインのノイズレベルを追跡する適応的なしきい値でも運用できます。 自分にとってのより広い教訓は、AIモデル(チェス)で遊んでいるときに身につけたスキルやワークフローが、驚くほど他の領域にもうまく移植できるということです。これは別に新しい話ではなく、多くのAIラボがゲームから始めているし、今もそうしている場合が多いのですが、それが実際に機能するのを見るのは気持ちいいです。 それに、正直に言うと自分ひとりでここまで来たわけではありません。これは次の組み合わせです:
かなり大雑把な内訳:
今度はたぶんダッシュボードを作って、自分のAstrography / Astropolisの本番ログで試してみます。あるいは、まずBGL、Thunderbird、Spiritでさらに先に進めるかもしれません。 正直なところ、まともなハードウェア、公開された研究、新しいアーキテクチャをうまく組み合わせて十分早く試せるなら、ゲーミングPCでも今これだけできるのは、まだけっこうワイルドだと感じています。 ここでの皆さんの考えが気になります:
興味があれば、前処理、学習ループ、そして最終的にうまく噛み合う前に自分を60〜70%で足止めしたミスについても、もう少し共有できます。 P.S. さまざまなシードにまたがって、有効性と再現性もテストしました。ほとんどの場合、実際に以前よりわずかに良い結果でした。 [link] [comments] |
[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ベースのシーケンスモデルと組み合わせた場合に特に生きる、という点が示されています。




