
大規模言語モデルは、プログラミングやエンジニアリングから製造やオートメーションに至るまで、ほとんどあらゆることに関する質問に答えることができます。しかし、重要な制約が1つあります。汎用AIモデルは、工場内で何が起こっているかを自動的に知ることはできません。
産業用ロボットの動作は理解できても、そのロボットの最新のメンテナンス履歴は知りません。一般的な機械の故障コードは認識できても、機器のマニュアル、トラブルシューティング手順、サービス記録には自動的にアクセスできません。
ここで、検索拡張生成(Retrieval-Augmented Generation)、略してRAGが役立ちます。
RAGは大規模言語モデルを外部情報と連携させ、回答を生成する前に適切な知識を取得できるようにします。産業データが保存され生成される場所の近くでその取得とAI処理が行われる場合、同じ概念がエッジRAGとして適用されます。
製造業者やその他の産業組織にとって、エッジRAGは既存の運用知識を、より有用で文脈を意識したAIに変える新しい方法を生み出します。
検索拡張生成とは?

従来の汎用大規模言語モデルは、主にトレーニング中に学習した情報とパターンに基づいて回答を生成します。これは一般的な知識には有効ですが、ユーザーが私的、専門的、または最近更新された情報に基づいて回答を必要とする場合には限界があります。
RAGは、この知識ギャップを埋めるのに役立ちます。
RAGシステムは、LLMがすでに知っている情報のみに依存するのではなく、まずユーザーの質問に関連する情報を組織の利用可能な知識ソースから検索します。関連する情報は、LLMが応答を生成する前の追加のコンテキストとして提供されます。
NVIDIAは、エンタープライズRAGを、AI推論をエンタープライズビジネスデータと組み合わせることで、応答が組織自身の情報に基づいたより関連性の高いものになる方法として説明しています。
メンテナンスエンジニアが質問する例を考えてみましょう。
「この機械のE032故障の原因は何ですか?」
一般的なLLMは、類似の産業機器に基づいた一般的な説明を提供するかもしれません。
RAG対応システムは、まず実際の機械マニュアル、トラブルシューティング手順、関連するメンテナンス記録を取得できます。その後、LLMはその情報を使用して、機器と動作環境に特化した、より具体的な回答を生成できます。
RAGが「エッジRAG」になる理由とは?

エッジRAGは、新しい種類のRAGアルゴリズムではありません。
その違いは主に、データ、検索サービス、AI処理がどこにデプロイされるかという点にあります。
クラウドベースのRAGアプリケーションでは、データが保存されたり、クラウドインフラストラクチャを使用して検索やLLM推論が実行されたりする場合があります。エッジRAGでは、これらの機能の一部またはすべてが、代わりに、データが生成され使用される工場、施設、または運用システムの近くでローカルに実行できます。
シンプルなエッジRAGのワークフローは次のようになります。
- 産業文書と運用情報がローカルに保存または収集されます。
- ユーザーが質問すると、RAGシステムは最も関連性の高い情報を検索します。
- 取得された情報は、コンテキストとしてLLMに提供されます。
- LLMはコンテキストを使用して、より関連性の高い応答を生成します。
ワークフロー全体がローカルに留まる必要は必ずしもありません。一部の組織では、クラウドホスト型LLMを使用しながらローカルで検索を実行する場合がありますが、他の組織では、検索とLLM推論の両方をオンプレミスでデプロイする場合があります。
つまり、重要な質問は単純に「クラウドかエッジか?」ではありません。
それは次のとおりです。
RAGワークフローのどの部分をデータの近くに保持するのが理にかなっていますか?
RAGが利用できる産業データとは?
ここに、RAGが産業AIにとって特に興味深いものとなる点があります。
工場ではすでに大量の貴重な情報が生成され、管理されていますが、その知識は多くの場合、異なる文書、システム、チームに分散しています。
産業用RAG知識ベースには、機器マニュアル、標準操作手順書、作業指示書、技術仕様書、トラブルシューティングガイド、保守記録、サービスレポート、生産文書、品質記録、機械ログなどが含まれる可能性があります。
一部のRAGアプリケーションは、より動的な運用コンテキストを組み込むこともできます。
例えば、Intelは、テレメトリーデータ、サポートログ、機械マニュアル、生産計画を含む展開固有の知識を使用できるRAG対応の製造HMIアーキテクチャを実証しており、機械オペレーターのトラブルシューティング、要約、計画をサポートします。
これにより、産業チームが情報とやり取りする方法に重要な変化が生まれます。
次の質問ではなく、
「この問題を説明している文書はどこにありますか?」
オペレーターは次のように尋ねることもできます。
「このアラームは何を意味し、最初に何をチェックすべきですか?」
何年にもわたるサービス文書を手動で検索する代わりに、技術者は次のように尋ねることができます。
「以前にもこの問題を見たことがありますか?」
したがって、RAGの価値は、単にテキストをより多く生成することではありません。人々やAIアプリケーションが既存の組織知識にアクセスしやすくすることにあります。
なぜRAGを産業データに近づけるのか?
産業環境は、従来のクラウドベースのチャットボットとは異なる優先順位を持つことがよくあります。
製造情報には、独自のプロセス、機器構成、運用記録、知的財産、その他の機密ビジネス情報が含まれる場合があります。RAGワークフローの大部分をオンプレミスに保つことで、外部クラウドインフラストラクチャに継続的に移動する必要がある情報の量を減らすことができます。
接続性も重要です。工場、倉庫、輸送拠点、または遠隔操作では、AIアプリケーションがリモートクラウドサービスへの常時接続に完全に依存することを望まない場合があります。
そして、AIアプリケーションの背後にある知識がより運用に近づくにつれて、近接性が重要になります。
データはすでに施設内に存在している可能性があります。それを使用する人々は施設内にいる可能性があります。新しい情報を生成する機械も施設内にある可能性があります。
エッジRAGは、AIの知識層をその環境に近づけます。
これは、すべてのRAG展開がクラウドから離れるべきだという意味ではありません。クラウドRAGは、組織が高度にスケーラブルなインフラストラクチャや大規模なホスト型AIモデルにアクセスする必要がある場合に依然として有用です。多くの場合、ハイブリッドエッジクラウドアーキテクチャが適切なバランスを提供する可能性があります。
エッジRAGの価値は、データの場所、接続性、プライバシー、または運用管理が重要な場合に、別の展開オプションがあることです。
エッジRAGは産業でどのように活用できるか?
最も実用的なアプリケーションの1つは、メンテナンスとトラブルシューティングです。
機器が故障した場合、RAG対応アシスタントは、関連するマニュアル、サービス手順、および以前のメンテナンス情報を取得し、技術者が問題を調査するのを支援することができます。
エンジニアリングチームの場合、RAGは、仕様、構成文書、製品文書の膨大なコレクションを、自然言語の質問を使用して簡単に検索できるようにすることができます。
工場オペレーターの場合、知識アシスタントは、ユーザーが正しい文書を手動で探す必要なく、関連する作業指示書、操作手順、またはトラブルシューティング情報を表示するのに役立ちます。
そして、現場サービスの場合、技術者は、作業が行われている場所に近い場所で、機器固有のサービス知識にアクセスできる可能性があります。
これらはエンジニアや技術者に取って代わるものではありません。これらのチームがすでに依存している情報をより簡単に取得し、使用できるようにすることです。
エッジAIサーバーはどこに適合するのか?
RAGアプリケーションには、その背後にあるコンピューティングインフラストラクチャが依然として必要です。
システムはデータを保存またはアクセスし、関連情報を検索し、サポートするAIモデルを実行し、最終的にLLM応答を生成する必要があります。
小規模なRAGアプリケーションの場合、これらの要件は比較的控えめである可能性があります。しかし、ユーザー、文書、AIモデル、およびアプリケーションの数が増加するにつれて、組織はより多くのCPUパフォーマンス、システムメモリ、ストレージ容量、GPUアクセラレーション、およびネットワーク接続を必要とする可能性があります。
NVIDIAのエンタープライズRAGアーキテクチャは、取り込み、埋め込み、ベクトルデータベース、リランキング、検索、およびLLM推論などの機能を、アプリケーションに応じてスケーリングできる異なるサービスに分離することで、この広範なワークロードを反映しています。
ここで、エッジAIサーバーが本番RAGのローカルインフラストラクチャ層になることができます。
サーバーをLLMを実行するためのハードウェアとしてのみ見るのではなく、モデルを取り巻く広範なワークフロー、つまりローカルデータアクセス、検索、ストレージ、AIアクセラレーション、およびエンタープライズまたは産業システムへの接続をサポートできます。
PremioのLLMシリーズエッジAIサーバーは、オンプレミスの生成AIおよびLLMワークロード向けに設計されています。Premioは現在、プライベートLLMやRAGなどのアプリケーション向けにポートフォリオを位置づけており、ローカルGPUアクセラレーションとサーバークラスのコンピューティングがオンプレミスデータセンターエッジに展開されています。
Premio LLMシリーズ エッジAIサーバーでエッジRAGを強化する
RAGが小規模なテストから本番環境への展開に移行するにつれて、組織はローカル検索、LLM推論、および増大するAIワークロードをサポートするために、より多くのコンピューティング、メモリ、ストレージ、およびGPUアクセラレーションを必要とする場合があります。
Premio LLMシリーズエッジAIサーバーは、プライベートLLM、RAGパイプライン、マルチモーダルAI、およびエッジでのその他の生成AIワークロード向けに設計された、スケーラブルなオンプレミスインフラストラクチャを提供します。
異なるパフォーマンスと拡張要件に対応するラックマウントフォームファクターで構築されたLLMシリーズは、組織がAI処理をプライベートエンタープライズおよび産業データに近づけるのに役立ちます。
重要な知識にAIを近づける
RAGの価値は、LLMに単に多くの情報を提供するだけではありません。
質問されている内容に対して、適切な情報にAIがアクセスできるようにすることです。
産業組織にとって、その情報はすでに運用全体に存在している可能性があります。機械マニュアル、メンテナンス記録、トラブルシューティング履歴、生産文書、その他の独自のデータソースなどです。
エッジRAGは、すべてのAIインタラクションが集中型クラウドインフラストラクチャに完全に依存する必要があると仮定するのではなく、検索とAI処理をその知識に近づける方法を提供します。
産業AIが汎用チャットボットからより文脈を意識したアシスタントやAIエージェントへと進化するにつれて、モデルを信頼できる運用知識と接続することがますます重要になります。
そして、多くの産業環境では、AIにとって最も価値のある知識は、すでにエッジに存在する可能性があります。
オンプレミスLLM、RAG、生成AIワークロード向けPremio LLMシリーズ エッジAIサーバーを詳しく見る >>

llm-1u-rpl llm-2u-am5 llm-3u-am5 llm-series
