50 万個のセンサーが LLM を混乱 Semantic Blindness

50 万個のセンサーを LLM が混乱させた理由：「意味的盲目」を解決する新アーキテクチャとは

Fedra の研究者らが、大規模 AI ファクトリーで発生した「意味的盲目（Semantic Blindness）」という深刻な問題を解決した事例を紹介します。従来の RAG や単純なコンテキスト拡張では対応できない 50 万個のセンサー名を扱う際、LLM が混乱し精度が急落する現象に対し、設備の物理的な階層構造を活用して検索計画を LLM に任せ、実際のデータ抽出は決定論的コードで処理するという新アーキテクチャを提案しました。この手法により、システム規模が 64 台から 46 万個に拡大しても 100% の精度と一定のコストを維持することに成功しています。

50 万個のセンサー名が LLM を混乱させる「意味的盲目」

Fedra は、顧客のデータセンター運用を支援する AI エージェントを開発しています。ユーザーは「どのチラーが過熱しているか」「特定の GPU に問題はないか」といった多様な質問を投げかけます。しかし、大規模システムにおいて LLM をそのまま使うには致命的な欠陥がありました。

まず、LLM のコンテキストウィンドウ（記憶容量）には限界があります。1ギガワット規模の工場では 40 万基以上の GPU や冷却装置が存在し、これらすべての機器名をコンテキストに含めるとすぐに飽和します。また、業界には統一された命名規則がなく、「Chiller 6」と「Chiller 7」のように 1 文字の違いしかない名称や、独自ルールで付けられた複雑な名前が混在しています。

「LLM に 50 万個のセンサー名を与えると、文脈制限や類似名称による検索失敗（ハルシネーション）が発生し、大規模システムでは実用不可能となる」

単純なベクトル検索や RAG でも、1 文字の違いを見分けるのは困難です。さらに深刻なのが「周波数ペナルティ」と呼ばれる現象で、LLM が似た名前を繰り返し出力しようとする際に内部ガードレールが作動し、処理を停止してしまうケースです。「i7 の GPU をすべてリストして」という質問に対し、100 個の名前を列挙するだけでシステムがフリーズしてしまいます。つまり、従来のアプローチではスケーラビリティの壁に直面していたのです。

階層構造（ツリー）を活用した解決策

この問題を解決するため、研究者らは物理インフラの構造そのものに着目しました。データセンターは「データセンター→ホール→通路→列→ラック→GPU」のように明確な階層的構造を持っており、まるで木（ツリー）のようになっています。

「システムの規模が広がっても、ツリーの深さはゆっくりとしか増えません。新しい機器を追加しても、ルートからリーフへ到達するためのパスは常に 4 レイヤー程度です」

この洞察に基づき、システム全体を要約した「ツリー構造」を LLM のコンテキストに含めるアプローチを採用しました。64 台の GPU を持つ小規模システムも、46 万個の GPU を持つ大規模システムも、階層パス（例：データセンター A → ホール 11 → ラック C）は同じ長さです。これにより、LLM が参照するコンテキストサイズをシステム規模に依存しない一定値に抑えることに成功しました。

「計画は LLM、実行はコード」の分離アーキテクチャ

鍵となるのは、LLM と決定論的コード（ソフトウェア 1.0）の役割を明確に分けたことです。研究者らは「LLM は計画には優れているが、検索や集計には不得意である」と結論付けました。

新しいシステムでは、以下の 2 段階で処理を行います。

1. LLM の役割（計画）：曖昧なユーザーのクエリを解析し、「どのサブツリー（例：データホール 11）を対象に」「どのようなフィルター（例：高温稼働中）」を適用すべきかを決定します。LLM は具体的な機器名を列挙するのではなく、検索パターンやルールを生成するだけです。
2. コードの役割（実行）：生成された計画に基づき、事前インデックス化されたツリー構造から該当するノードを抽出し、集合演算（交差など）でデータを照合・集約します。この部分は 100% 再現性のある決定論的コードが処理します。

「LLM に検索を行わせるのではなく、LLM に『探し方』を指示させます。実際のデータ抽出と集約は、構造やルールを記述できる決定論的なコードに任せるのです」

これにより、ユーザーのクエリから最終結果までのプロセスは、無限ループする複雑なエージェント・ループではなく、2〜3 ステップのシンプルなフローで完結します。

検証結果：規模拡大でも精度 100% とコスト平坦化

この新アーキテクチャの実証実験では、劇的な成果が得られました。旧アプローチ（単純な LLM や RAG）では、64 GPU の段階で正答率 80% を示していましたが、システムが 46 万個の GPU にスケールすると正答率は約 30% まで急落しました。

一方、新アーキテクチャでは以下の結果を達成しています。

• 精度 100% の維持：64 台から 46 万台への規模拡大に関わらず、すべてのテストケースで正答率 100% を維持しました。これは合成データだけでなく、実際の生産環境での 66 ケースでも再現されています。
• コストの平坦化：システムが巨大化しても、クエリあたりのトークン使用量は約 9,000 トークンで一定です。旧アプローチでは 1GW スケールで 1,160 万トークンを消費したのに対し、新方式では 39 万トークン（約 300 万トークンの削減）に抑えられました。

AI ネイティブ開発における「逆転パラダイム」

この事例は、ソフトウェア開発のパラダイムシフトを示唆しています。Carpathia が指摘するトレンドでは、レガシーシステムが「決定論的コード（Software 1.0）」から「LLM プロンプト（Software 3.0）」へ移行してきました。

しかし、大規模 AI ネイティブシステムの構築においては、逆の動きが必要です。最初は LLM 中心でプロトタイプを作成し、価値のあるユースケースを見極めた後、構造化されたデータ処理や正確な検索が必要な部分はあえて「Software 1.0（コード）」へ戻すのです。

「難しい判断は LLM に任せ、推測すべきではないこと（構造の理解、完全なセットロジック、名前の重複削除など）はすべて決定論的コードに移管する。これが信頼性を高めるための鍵です」

LLM は「何を」「どこで」探すかという判断と、人間にわかりやすい回答の合成に集中させます。一方、データモデル内の構造化処理や 100% の再現性が必要な作業は、ソフトウェア 1.0 の領域としてコード化します。

この「逆転」のアプローチにより、LLM の柔軟性とコードの信頼性を両立させた新しい開発パラダイムが確立されました。産業レベルで AI エージェントを運用するエンジニアにとって、これはコスト効率と信頼性を同時に実現するための重要な指針となるでしょう。