IoTセンサーのデータをLLMに解釈させて、人間が読める言葉にしたい。そう思って、
「温度が24.1, 24.2, 24.5, 29.8…異常を判定せよ」とプロンプトに突っ込んだことがある人は
多いかもしれない。（前回のブログでも試した。これは条件付きで上手くいったが・・）
結論から言うと、これは悪手だ。
最近のLLM4TSと呼ばれる分野の研究でも、はっきりとコンセンサスが形成されている。
LLMに生の数値列を渡して統計的な判断をさせるのは、原理的にうまくいかない。
なぜLLMは数値が苦手なのか
理由はシンプルで、トークナイザーの問題だ。
LLMにとって「24.1」という数値は 2 , 4 , . , 1 という文字トークンの並びでしかない。人間が「24.1、24.2、次に24.5」と見れば「じわじわ上がってる」と一瞬で分かるが、LLMは言語の確率モデルだから「次にどんな単語が来るか」を予測してしまう。「数値列の移動平均が上昇トレンドにあるか」を判定する機構は持っていない。
だから生の数値を渡すと何が起きるかというと、もっともらしい嘘をつくようだ。ハルシネーションだ。「異常が検知されました」と自信満々に言っても、統計的に検証されたものではなく、言語的にそれっぽい文章を生成しているだけだ。
じゃあどうするか — 「因数分解」して渡す
答えは意外と明快だ。数値の分析はMLにやらせて、その結果だけをLLMに渡す。
つまり、LLMに食わせるのは生の数値列ではなく、こういう構造化されたテキストだ。
「MLモデルの分析結果: 温度が24時間で8°C上昇するドリフトを検知。異常スコア0.85。主要因は温度センサー（寄与度80%）。振動は正常。」
これならLLMは得意な仕事に集中できる。「ドリフト」「異常スコア0.85」「主要因は温度」という言語的に処理可能な情報から、人間に伝わるナラティブを組み立てればいい。
実装に落とすと — 3層アーキテクチャ
この考え方をIoTシステムに実装すると、3つの層に分かれる。
[第1層：Edge AI (マイコン)]
・生のセンサーデータを取得
・統計的特徴量（平均・分散など）を計算
・通信量を99%圧縮して送信
↓
[第2層：クラウドML (機械学習)]
・Isolation Forest、Autoencoder等の教師なしモデルで分析
・異常スコア、種類（スパイク/ ドリフト/ ボラティリティ）、原因センサーを特定
・「異常シグネチャ(JSON)」を生成
↓
[第3層：LLM (言語モデル)]
・シグネチャを受け取り言語化
・事実、推定、推奨を明確に分離したレポートを生成
[状況] Z軸の振動が24時間かけて上昇しています（4.2mm/s）。
[推定] この設備では過去2回、グリス不足が原因でした。
[推奨] 前回はグリスアップで改善しています（振動 4.2→2.1）。
[状況]はデータの事実、[推定]は根拠付きの推測、[推奨]は過去の実績に基づく提案と、確実性のレベルを明示的に分離している。
LLMに「発明」させるのは言い回しだけ。推定と推奨の中身は、初期知識か過去の経験からの引用に限定する。これでハルシネーションを構造的に封じ込める。
まとめ — 適材適所に帰着する
結局のところ、この話の本質は「適材適所」だ。
- 数値の統計処理 → 統計モデル/ML
- 言語化と対話 → LLM
- エッジでのデータ圧縮 → 信号処理
生の時系列データをLLMに食わせている人は、今日からやめたほうがいい。
まずMLで因数分解して、結果だけをLLMに渡せば、精度が上がり、コストが下がり、ハルシネーションが減る。理論も実績もある、確立されたアプローチだ。
コメント