re:Invent 2025: AWS OutpostsでAgentic AIによる製造業エッジ自動化の実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Implement Agentic AI at the edge for industrial automation (HMC317)
この動画では、AWSのKarim AkhnoukhとMohammad Salahが、製造業における計画外ダウンタイムによる年間1.4兆ドルの損失という課題に対し、AWS Outposts上でAgentic AIと小規模言語モデルを活用したソリューションを実演しています。データサイロ、スキルギャップ、生産遅延、運用中断という4つの課題を特定し、EKSローカルクラスタ上に統合データレイクを構築。Llama 3.2 3B Instructモデルのファインチューニング、LLM as a Judge評価による14%の性能向上の実証、RAGツールとtelemetryツールを組み合わせたエージェント実装まで、コードレベルで詳細に解説。Strands SDKを用いたツール開発、Ollamaによるモデルホスティング、クッキー工場での実践的なデバッグシナリオを通じて、エッジでの常時稼働可能なスマートマニュファクチャリングの実現方法を示しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
製造業における計画外ダウンタイムの課題：1.4兆ドルの損失と4つの根本的問題
私の名前はKarim Akhnoukhです。私はAWSのシニアソリューションズアーキテクトをしています。この会社には約3年間いますが、ドイツの多くの大手メーカーと一緒に仕事をしてきて、生成AIアプリケーションのデプロイメントの複雑さをナビゲートするのをお手伝いしてきました。私の名前はMohammad Salahで、AWSのソリューションアーキテクトとして中東の公共部門を担当しています。AWSでの私の仕事はKarimと同じような問題を解決することですが、実際のメーカーを対象としています。
こんなシーンを想像してみてください。工場の中で、機械が止まっています。生産ラインが一時停止しています。みんなが走り回り始めます。製品が作られていない1分1分ごとに、注文が遅れ、コストが積み重なっていきます。これが私たちが計画外ダウンタイムと呼ぶものです。世界中の上位500のメーカーがこれに対して代償を払っています。計画外ダウンタイムのために、彼らは1.4兆米ドルを失っています。毎年彼らの収益の約11%を失っているのです。これを視点に入れるために、これはスペインのような国のGDPに相当します。
これをもっと詳しく見てみると、4つの異なる課題を見つけました。1つ目はデータサイロです。生産ラインには複数の機械があります。各機械には独自のアラームとテレメトリデータがありますが、各機械には独自の別々のデータベースがあります。結果として、同じ生産ラインの機械間の関係を理解するためのエンドツーエンドのビューがありません。データはありますが、データが断片化しています。
2番目の問題はスキルギャップです。これはすべて人についてのことです。各メーカーには、ミキサーの音からそこに問題があることを教えてくれるシニアエキスパートがいます。生地が過度に混ぜられていることを。彼らはオーブンから、右側が左側よりもはるかに加熱されていることを教えてくれます。この種の専門知識は重要です。これらのシニアエキスパートがいなくて、ジュニアがこの種の警告を受け取った場合、彼らは対応することができません。知識はありますが、知識が共有されていません。
3番目の課題は生産遅延です。これはジュニアスタッフがいてシニアがいない場合、データはありますがそれが散らばっている場合、そして彼らが専門知識がない、知識がない、データが断片化しているために対応できない場合に起こります。
最後の1つは運用の中断です。これはすべての工場にとって非常に重要です。なぜなら、ほとんどの工場は遠隔地にあるからです。工場について話すとき、多くの場合、安定したインターネット接続がなく、クラウドアクセスもありません。スマートマニュファクチャリングを導入していて、何らかの理由で接続が切れてしまうと、あなたの製造工場は盲目になってしまいます。データに基づいた意思決定と洞察が得られなくなるのです。
AWS Outpostsを活用した統合ソリューション：異なるOEMの統合とエッジでのインテリジェンス
そこで、私たちはシンプルなソリューションを考えました。すべてのデータを1つのデータリンクにまとめて、AWS Outposts の中に置こうということです。しかし、これを実行してみると、別の課題が見つかりました。各機械には独自の統合タイプがあります。OEM X、OEM Y、OEM Z から機械を購入しているかもしれません。しかし、各 OEM には独自の統合とテクノロジーがあります。最新の IoT 統合について話すなら、MQTT や LoRaWAN があります。あるいは REST API と POST HTTP、GET HTTP について話すこともあります。そして、製造業者にとって最も重要な部分はドキュメント、つまり標準操作手順書とマニュアルドキュメントです。これらは従来の SFTP を使って取得できます。
私たちは、なぜ Outposts の基盤となるインフラストラクチャを EKS ローカルクラスタの上に置いて、統一された API デプロイメントを行い、これらの異なる統合を吸収し、それに応じて1つの統合データレイクと統合しないのかと考えました。
その後、このデータレイクのコンシューマーは、私たちの場合 Bedrock である AI になります。また、Amazon QuickSight を使用したダッシュボードでより多くの洞察を得ることができます。 これが結果になります。左側には生産ラインがあり、すべてを理解できます。生産ラインについて完全な詳細と完全な理解が得られます。検査官があなたにひび割れたクッキーがあることを伝えているのが見えます。機械は5分間停止しています。
2番目の問題は、私たちが「常時稼働」と呼んでいるものの回復力です。常時稼働を維持する方法です。 Outposts がどんな理由でクラウドから切断されてしまうと、もはやスマートマニュファクチャリングとして機能することができなくなります。このようなデータドリブンな意思決定ができなくなります。自動化された AI の推奨事項が得られなくなります。そこで、私たちは、複数の小規模言語モデルをエッジにデプロイすることで、エッジにこのようなインテリジェンスを追加してはどうかと考えました。 これについては後のセッションで詳しく説明し、2つの異なる機能があります。1つ目は、テキストと音声を使用してデータとチャットするオペレーターにインテリジェンスを提供することです。 2つ目は、このような自動化を適用することです。 あなたはデータとテレメトリデータを5分ごとに消化し、洞察を理解し、推奨事項を取得します。そして、これらの推奨事項が通知を必要とすると感じた場合、必要なアクションをオペレーターに通知します。
クッキー工場のユースケース：Agentic AIによる品質問題の検出と解決
コーディングセッションに入る前に、皆さんが楽しみにしていることだと思いますが、もう2分だけ時間をください。エンドツーエンドのワークフローがどのように見えるかを理解していただくために、全体像を説明させていただきたいと思います。 ここ Vegas で最高級のクッキーを製造するクッキー工場があると想像してください。シンプルにするために、このクッキー工場には3つの大きな機械があります。クッキーを成形する機械、その後に冷凍トンネル、そして最後にクッキー検査機があります。ここで、視覚的な品質検査を行うクッキー検査機が、割れたクッキーや、形が悪いクッキー、あるいは気泡が入ったクッキーを検出する状況を想像してください。
そして、常時接続性を確保するために AWS Outposts の内部で実行されている Agentic AI アプリケーションがあります。 この Agentic AI アプリケーションは、機械マニュアル、標準操作手順書、リアルタイムテレメトリデータとアラームを含む、異なるデータソースにアクセスできます。 生産現場のオペレーターは、エージェントとチャットまたは音声チャットで会話できます。 彼らは根本的な問題が何かを理解し、その後エージェント自身に指示を出して、生産現場内の問題を修正するためのアクションを取らせることができます。最終的に、割れたクッキーの状態から、おいしいクッキーを製造している状態に移行し、皆さんが再び幸せになります。
でも、ここで私が示しているものに何か問題があるのか、ご存知ですか？AWS Outposts のアイコンをプラグインするだけで、ソリューションがそんなにシンプルだったらいいのにと思います。その裏側には、もう少し複雑なアーキテクチャがあります。 右側には、データ準備とモデルファインチューニングのパイプラインがあり、これについてはこのセッションの残りの時間で非常に詳細に説明していきます。左側には AWS Outposts にデプロイされた Agentic AI アプリケーションがあり、その後、異なる専門化された小規模言語モデルがあります。ユーザーからの異なるタスクを異なるツールにナビゲートするためのルーティングモデルとなる GPT OSS モデルがあります。RAG アプリケーションに特化したファインチューニングされた Llama 3.2 billion parameter モデルがあり、最後に視覚的品質検査用の小規模 VLM があります。時間の都合上、小規模 VLM の実装は行いませんが、その他のすべての実装の詳細について説明していきます。
エッジでの小規模言語モデルデプロイメント：インフラストラクチャ構築と量子化戦略
では、始めましょう。 これが皆さんが望んでいることですね。 私の画面が見えていますね。そうですね。では、インフラストラクチャのデプロイメント設定から始めます。
AWS Outposts 環境を、いくつかの EC2 マシンでシミュレートします。ここで最初のメソッドに移動します。これは EC2 インスタンスの作成です。 ご覧の通り、G4dn.xlarge インスタンスを使用しています。 これは比較的小さいですが、小規模言語モデルを実行できる能力のあるインスタンスです。特定の AMI を選択しています。これは NVIDIA のものです。その後、セキュリティグループ、VPC、IAM ロールなどを作成しています。しかし、ここで私が強調したい最も重要な部分は、EC2 インスタンスにアップロードされるユーザーデータスクリプトです。このスクリプトは、Agentic AI アプリケーションを実行するために必要な実際の依存関係をインストールします。この EC2 マシンを見てみると、ユーザーデータスクリプトは 148 行の長さなので、これを1行ずつ説明するのは非常に現実的ではありません。 その代わりに、この EC2 マシンにどのような依存関係を追加すべきかについて、皆さんの頭を使ってブレインストーミングしたいと思います。 ちょっと時間をください。QR コードをスキャンして、AI エージェントと小規模言語モデル、つまりルーター小規模言語モデルをホストするために EC2 マシンに必要なものについて考えてください。 よく考えてみてください。そして、すぐに結果をお見せします。
投票をまだ集計中です。 ほぼ正解ですね。もちろん、エージェントコードが必要です。これは言うまでもありません。Docker ランタイムが必要です。なぜなら、Docker を使って Ollama のコンテナをプルするからです。Ollama は小規模言語モデルをホストするためのソフトウェアになります。このEC2マシンには微調整されたモデルは必要ありません。なぜなら、別の EC2 マシンに微調整されたモデルをデプロイするからです。CUDA ソフトウェア用に NVIDIA ツールキットが必要です。カスタム Python バージョンが必要です。なぜなら、AI エージェントをインストールするために使用する SDK は Strands で、Strands は最小 Python バージョン 3.10 で動作するからです。G4dn インスタンスのデフォルト Python バージョンは Python 3.9 なので、カスタム Python バージョンをインストールする必要があります。Ollama と言った人、それは実は正解です。なぜなら、Ollama を Docker コンテナとして実行するからです。
これは最初の EC2 マシンでエージェントを実行するためのものでした。では、もう一度 QR コードをスキャンして、微調整された小規模言語モデルを保持する EC2 マシン に必要な依存関係について考えてください。 結果を見てみましょう。Docker が必要です。微調整されたモデルが必要です。 その場合、G4dn.xlarge のデフォルトバージョンで動作するため、カスタム Python バージョンはもう必要ありません。これはトリッキーな質問でした。最初の EC2 マシンにデプロイされたエージェントコードは必要ありません。Ollama が必要で、もちろん小規模言語モデルが必要です。 依存関係についてブレインストーミングできて嬉しいです。その後 ユーザーデータスクリプトを書いたら、私が言ったように、VPC を作成し、セキュリティグループを作成し、S3 へのアクセス権を持つ IAM ロールを作成します。そして、それに満足したら、アプリケーションをデプロイする必要があります。 完璧です。これでインフラストラクチャのデプロイが始まります。この間に、AWS Outposts 上で小規模言語モデルをデプロイする方法に関するいくつかのヒントとコツをお伝えします。
ここをもっと詳しく見てみましょう。AWS Outposts 上にある GPU インスタンスは G4dn です。任意のモデルをデプロイするには、2 つのことを考慮する必要があります。1 つ目はハードウェア制約です。g4dn.12xlarge について話しており、これは 4 つの NVIDIA T4 GPU を備えており、それぞれ 16 ギガバイトのメモリを搭載しています。同時に、2 番目の考慮事項はモデル自体です。オープンソースモデルの例として、GPT OSS 20B、約 200 億パラメータを取り上げています。しかし、ここで言及した異なるパラメータは、AWS Outposts 上でのデプロイを行う際に考慮することが非常に重要です。その 1 つは、これが mixture of experts であるかどうかです。レイヤーの数はいくつか。そしてトークンあたりのアクティブなパラメータです。では、デプロイを行うための最初の戦略に焦点を当てましょう。それは量子化です。 量子化は、簡潔に言うと、メモリフットプリントを削減するために、重みを表現するビット数を削減することです。このモデルは FP16 の精度を使用してトレーニングされました。これはベースモデルです。しかし、別の量子化である MXFP4 を使用することもできます。各重みをどのように表現するか、各パラメータをどのように表現するかについて話しています。各重みを 16 ビットで表現する代わりに、同じ重みを 4 ビットで表現できます。これにより、メモリフットプリントが大幅に削減されます。
完全な精度ではなく、ベースモデルで 40 ギガバイトの代わりに、わずか 13 ギガバイトにすることができます。しかし、すべてにはコストがあります。ここでのコストは精度です。ベースラインの場合、精度への影響はありません。しかし、MXFP4 の場合、重みを表現するビット数を削減するため、1～2 パーセントの精度低下が生じます。 これは、1～2 パーセントの精度低下と引き換えに、メモリの 65 パーセントを節約できることを意味します。これにより、メモリ内に 13 ギガバイトで完全なモデルをデプロイできます。ハードウェア制約を覚えていますか？16 ギガバイトあります。これで、1 つの GPU 内に完全なモデルをデプロイできます。
デプロイ戦略の 1 つは、完全なモデルを 1 つの GPU にデプロイすることです。ご覧のように、同じモデルを GPU 全体にレプリケートしようとしており、これを行うことの重要性は、同時に複数のクライアントに対して並列処理を実装することで、レイテンシに敏感なワークロードを実現することです。アプリケーションはレイテンシに対して何の許容度もありません。各クライアントに対して別の GPU で処理を行おうとしています。 これにより、キューイングなしで 4 つの異なるクライアントにサービスを提供することで、スループットが向上します。
2番目の戦略は tensor parallelism です。 1つのモデルがあって、その重みが複数の GPU に共有されています。各 GPU では、モデルの重みに 3.2 ギガバイトを割り当てることになります。そして残りの部分は KV cache に使われます。KV cache というのは、セッションの一部としてトークンをキャッシュして、新しいコンテンツを生成するたびにモデルがトークンを再計算しなくて済むようにするものです。KV cache が大きければ、同時に多くのユーザーに対応できますし、より大きなコンテキストウィンドウを確保することもできます。これはセッションにとって重要なことです。
データ準備とモデルファインチューニング：Llama 3.2のインストラクテッドファインチューニング
では、この基礎的な部分をお見せしましょう。まずアーキテクチャから始めます。高レベルのアーキテクチャから、データ準備で始めることができます。ここでデータについて何かお見せしましょう。 ご覧の通り、これらはデータソースです。異なるタイプのデータソースがあります。CSV ファイル、テキストファイル、PDF ファイルがあります。
これが通常のデータソースがどのような形をしているかです。異なるフォーマットを持つ異なるファイルがあります。なぜなら、本番ラインでは異なる OEM があり、それぞれが独自の構造を持っているからです。私たちがやる必要があることはモデルをファインチューニングすることですが、モデルをファインチューニングする目的は何でしょうか。ここでの目的は、オペレーターのためのアシスタントを提供することです。このアシスタントは、各問題の重大度を考慮しながら、詳細で指示的なステップをオペレーターに提供するのに役立ちます。コンプライアンスを考慮し、安全性を考慮し、などなどです。
しかし最も重要な部分は、モデルに必要なスキルを理解させ、モデルに必要なトーンで話させることです。だからこそ、私たちは instructed fine-tuning を使ってモデルをファインチューニングすることにしました。では、正確に何が起こっているのかを見てみましょう。右側にお見せします。 これはデータパイプラインで、PDF ファイル、テキストファイル、ドキュメントファイルなど、異なるドキュメントを読み込むことができます。そして、より大きなモデルを呼び出して、モデルをファインチューニングするための構造化されたデータを生成することができます。
ここで最も重要な質問は、なぜデータを直接モデルに投げてモデルをファインチューニングしないのかということです。答えは簡単です。データをすぐにモデルに投げてしまうと、幻覚を生成するマシンを訓練することになるからです。重要な部分は、ドキュメントを読み込み、モデルを呼び出してそれに応じて構造化されたデータを返させ、そのデータを検証し、そしてモデルをファインチューニングするための完全に構造化されたドキュメントを手に入れることができて満足するということです。
では、これを実行してみましょう。 ご覧の通り、パイプラインはこれを読み始めると同時に、Bedrock を呼び出して質問と回答を生成し始めます。なぜ質問と回答を生成するのか？それはモデルをファインチューニングするための指示付きデータセットを持つためです。ここで何かお見せしましょう。 これは、モデルを呼び出すために使用しているデータ準備クラスです。ご覧の通り、ここでモデルを使用して構造化データを生成しています。そして、これの最も重要な部分は、非常に重要なことをお見せします。 これは Converse API です。ご覧の通り、ここで Converse API を使用しています。
Converse API は、異なるモデルに対して同じ API シグネチャを使用するため、いつでも任意の時点でモデルを変更する柔軟性を提供しています。同時に、最も重要な部分はインファレンス設定です。最大トークン数を正しく設定すれば、データの分割などなく、正しく回答を得ることができます。
ここで最も重要な部分はシステムプロンプトです。これは 1 つだけ、たった 1 つのショットを含む指示付きプロンプトです。モデルに対して、現実的な情報を生成し、重大度を含め、安全性に関する質問に正しく答え、必要な情報を含めるという明確で詳細な指示を与えています。このようにすることで、構造化データを持つ完全なデータセットを持つことができます。
次に、これは非常に重要なことですが、なぜ LLM を信頼する必要があるのか？もしかして LLM 自体が幻覚を起こすかもしれません。この場合、LLM が幻覚を起こしている場合は、決定論的検証と呼ばれるものを適用する必要があります。はい、LLM がコンテンツを生成しましたが、このコンテンツが正しいかどうか、これが正しい質問と回答であるかどうか、これが標準的な運用手順が指示していることに従っているかどうか、これが隣接した方法でリクエストの必要な構造に従っているかどうかです。なぜこれが重要なのか？
それは、ファインチューニング用の再構成されたデータに単一のレコードが重複していないことを確認する必要があるからです。2 番目の考慮事項はシャーディングです。データをシャーディングし始める場合は、スマートな方法で行う必要があります。非常に長い段落がある場合、段落の途中で切ることはできません。大きなセクションがある場合は、このセクションが正しい方法で分割されていることを確認する必要があります。文を途中で分割することはできません。
これがなぜ重要なのかというと、同じ目的が適用されます。つまり、構造化されたデータが正しく実装されているということです。右側に見えるように、仕事は完了しています。Q&Aを生成して、検証を行いました。そして、ご覧の通り ここに統計情報があります。50組の質問と回答がリクエストされ、45個が生成され、5個が却下されました。ここで出力ファイルを確認できます。出力ファイルから、これが却下されたのが分かります 。理由は frozen belt misalignment セクションです。これがコンテンツで、これが間違っている重要な情報です。 なぜでしょうか？モデル自体またはパイプライン自体が、必要な構造全体と SOP 内のデータ全体にわたってこの検証を実行しているからです。
それに応じて、モデルのファインチューニングを開始するために、データを S3 にアップロードしました。これは AWS SageMaker AI Studio です。ここでモデルをファインチューニングできます。左側を見ると、これが JumpStart です。JumpStart 内で、モデルを選択できます。ここで、モデルファミリーは Meta です。これがモデルファミリーです。完璧です。Llama 3.2 3B Instruct が私たちのモデルです。 ここには3つの異なるオプションがあります。評価するか、デプロイするか、またはトレーニングするかです。私たちの場合、モデルをトレーニングします。モデルのトレーニングを選択します。
モデルを選択した後、データセットを選択する必要があります。これはデータセットのデータ準備の一部として行いました。 ここが詳細なセットです。これが私たちがアップロードしたばかりのデータです。データを選択して、このファインチューニングが出力を生成します。つまり このファインチューニングまたはあなたのデータセットに基づいたモデルの更新されたウェイトです。S3 バケットを設定します 。更新されたモデルを取得するためです。 それに応じて、これを進めることができます。5つのエポックを持つのは正常だと思います。そしてこれは非常に重要です。これは AWS が推奨するレシピで、この G5 インスタンスを使用してファインチューニングを行うものです。別のインスタンスを選択したい場合は、問題ありません。これは完全に柔軟ですが、これがファインチューニングの一部として私たちが推奨しているものです。
LLM as a Judge評価による検証：ファインチューニングモデルの14%の性能向上
それに応じて、同じ Identity Access Management、同じ VPC、同じ暗号化キーを使用します。 そしてモデルを送信します。これらのことに同意する必要があります。 そしてジョブがモデルのファインチューニングを開始しました。さて、皆さんの多くが自分たちに問いかけているであろう1つの質問があると思います。それは、私の意見では、もしあなたがそれを質問しているなら非常に妥当な質問です。その質問は、なぜあなたたちはエッジで RAG タスクを使用するのに、モデルのファインチューニングとデータ準備をしているのかということです。もしかして、私たちはアーキテクチャをもう少し派手に見せるためだけにこのアーキテクチャの一部を追加したのではないかと思っているのかもしれません。
まあ、そうするのが好きかもしれませんが、実は私たちはこのアプローチが確かに有効であることを証明するために広範な実験を行いました。それを証明するために、LLM as a Judge evaluation と呼ばれるテクニックを使用しました。このテクニックがどのように機能するかをお見せします。
かなり多いですね。試してみるので、ちょっと時間をください。 ほぼ完了です。 なぜか、アスペクト比がうまく機能していないので。LLM as a judge 評価がどのように機能するかを説明させてください。凝ったアニメーションがあったんですが、とにかく、私たちのファインチューニングされたモデルと Meta が製造した Llama ベースのベースモデルがあり、RAG タスクでの両モデルのパフォーマンスを比較したいのです。
最初のステップで、両モデルに提供するのは、テストデータセットからの質問とコンテキストです。 これらの質問とコンテキストに基づいて、両モデルに回答を生成するよう求めます。これは RAG アプリケーションで通常行う方法だからです。 次のステップでは、3 つの LLM as a judge 評価者があります。Claude 4.5 Sonnet、Claude 4.5 Haiku、Amazon Nova Pro が審査員です。 これら 3 つの審査員それぞれに 5 つの異なる入力を渡します。Salah が生成したテストデータセットからの質問とコンテキスト、先ほど示したファインチューニングされたモデルからの回答、質問とコンテキストに基づくベースモデルからの回答です。
テストデータセットからの正解も渡します。 これら 3 つのモデルに、3 つの評価基準に基づいてファインチューニングされたモデルとベースモデルから生成された結果を評価するよう求めます。1 番目は精度で、ファインチューニングされたモデルとベースモデルからの結果がテストデータセットの正解とどの程度一致しているかを測定します。2 番目は完全性で、回答が質問のすべての異なる側面にどの程度対応しているかを測定します。3 番目は関連性で、これは私の意見では RAG アプリケーションで最も重要なメトリクスです。なぜなら、回答が与えられたコンテキストにどの程度従っているかを測定するからです。これが RAG の仕組みだからです。
3 つの審査員にベースモデルとファインチューニングされたモデルのパフォーマンスを評価するよう求めました。 ここに LLM as a judge 評価の結果があります。 私の意見では、これらは本当に素晴らしい結果です。なぜなら、異なる評価者モデルが、ファインチューニングされたモデルが RAG タスクでベースモデルを上回っていることを示しており、すべてのデータセットで 3 つの異なる評価者基準全体で集計されているからです。例えば、Claude 4.5 Haiku は、ファインチューニングされたモデルがベースモデルを 17 パーセント上回っていると言っています。 Claude 4.5 Sonnet は、ファインチューニングされたモデルが 15 パーセント上回っていると言っており、Nova Pro は ベースモデルを 10 パーセント上回っていると言っています。平均すると、Agentic AI アプリケーションの RAG にファインチューニングされたモデルを追加することで、14 ポイントの改善があります。
次のステップに進む前に、簡単に要約させてください。まず、EC2 マシンにインフラストラクチャをデプロイして、AWS Outposts の環境を複製またはシミュレートし、Agentic AI アプリケーションを実行しました。その後、Salah は親切にも、RAG タスク用の小規模言語モデルのデータを準備してファインチューニングする方法を示してくれました。そして、これがアーキテクチャでいかに重要であるかを示しました。
では、これを AWS Outposts のエッジで実行される Agentic AI アプリケーションに組み込む必要があります。この Agentic AI アプリケーションは、rack ツールとテレメトリデータツールにアクセスできるようになります。では、始めましょう。ご覧の通り、2つの EC2 マシンが現在稼働しています。factory agent が instance にあり、fine-tuned small language model instance もあります。factory agent instance にログインしたいので、Kiro を使用します。remote SSH 用のプラグインをインストールしました。ホストに接続すると、最初にインスタンス化した EC2 マシン内で SSH セッションが開きます。
では、EC2 マシンの中にいます。user data スクリプトでコピーした factory agent ディレクトリに移動する必要があります。少しズームインしてみます。 ズームインが機能していません。その間に、非常に重要なことを説明させてください。ここでは2つの異なるアプローチを使用しました。fine-tuned model を使用すると同時に RAG も使用しています。 なぜ両方を行ったのか、何か印象を持っている人はいますか？ほとんどの場合、どちらか一方についてのみ読んでいるからです。何か答えはありますか？正しいデータベースを確保する情報かもしれません。 Fine-tuned model、そうですね。これについて深く掘り下げてみましょう。最も重要な部分は、ドキュメントについての知識を持つことです。モデルを fine-tune するために必要なスキルは、必要なスキルを習得することです。エージェントが正しく応答するためのトーンを設定しています。RAG を使用することで、ナレッジベースから最新の 情報を取得しています。だからこそ、両方を組み合わせて、この LLM as a judge 評価結果を達成しています。ベースモデルから15%の増加について話しています。
Agentic AIアプリケーションの実装：RAGツールとテレメトリツールによるリアルタイム診断
では、Salah が RAG ツールについて話している間に、エージェントアプリケーションで使用する RAG ツールの開発方法を示したいと思います。Rag Retriever という名前のクラスを事前に作成しました。以前、環境内にドキュメントを Chroma DB にベクトルストアとして事前に取り込み、非常にシンプルなメソッドを作成しました。これは search メソッドで、クエリと結果の数を提供できます。その後、このクエリを使用して ベクトルストア内の情報を検索し、ベクトルストア内から最も関連性の高い情報を取得します。 Strands SDK の tool デコレータを使用して、search documents メソッドを持つようにしました。ここでは、エージェントがこのツールが何をしているのか、そして実際にどのように使用できるのかを理解するために使用されるドキュメント文字列を提供しています。その後、 ベクトルストアからの取得結果を反復処理し、それらをいい形式で出力しています。これは RAG、Retrieval Augmented Generation のツールです。
この実装にはなにか不足していると思いますか？ もう一度、retrieval augmented generation があります。このツール実装で不足している大きなものが何か見えますか？時間を節約するために、G が不足しています。generation が不足しています。Salah が時間をかけて fine-tune したモデルを覚えていますか？ここではそのモデルを使用していませんよね？私が示したいのは、LLM as a judge 評価で示したように、結果を強化するためにそのモデルを使用する方法です。では、fine-tuned model を持つマシンの IP アドレスとポートを使用して Ollama クライアントをインスタンス化します。
その後、コードの一部をコピーして貼り付ける必要があります。 これを response に変更しました。これで RAG ツールが完成しました。retrieval 部分と generation 部分があり、Ollama に fine-tuned model のエンドポイントを呼び出すよう要求し、クエリと結果を渡しています。これが最初のツールで、このツールは生産ラインの異なるマシンから標準操作手順とマニュアルを取得するためのものでした。
では、2番目のツールは telemetry tool で、このツールは本番ラインの機械からリアルタイムのテレメトリデータと アラームを取得するためのものです。このリアルタイムデータを非常にシンプルな CSV ファイルで表現しました。ご覧の通りです。 ちょっとズームインしてみます。ご覧の通り、CSV ファイルにはデバイス名、その特定のデバイスのセンサータイプ、読み取り値、そしてその読み取り値のタイムスタンプが含まれています。最初のスライドから覚えていると思いますが、2つのデバイスがあります。freezer tunnel machine と cookie former machine です。これら2つのデバイスのそれぞれに対して、2つの異なるセンサーがあります。温度とスピードです。その後、これらの異なるセンサーの読み取り値があり、最後にその特定の読み取り値のタイムスタンプがあります。
telemetry tool に関しては、私は事前に TelemetryReader というクラスを作成しました。これは CSV ファイルを読み込みます。 また、別のヘルパーメソッドも作成しました。これは CSV を時間フレームに変換します。 このメソッドに3つのものを渡します。探したいデバイス名、現在いる時刻、そして過去のどのくらい前の時間を見たいかという分数です。例えば、過去5分間のテレメトリデータを見たい場合、ここの minutes_back を5に設定します。
ここで入力として freezer tunnel に対応するデバイス名を提供すると、出力はこのようになります。freezer tunnel には temperature と speed センサーがあり、これらは異なるタイムスタンプの読み取り値です。では、これから Strands tool を作成したいと思います。 では、進めながら作成してみましょう。覚えていると思いますが、tool decorator を使用します。get_telemetry_data というメソッドを作成します。このメソッドには device name が必要で、これは string 型です。minutes_back が必要で、これは integer 型です。戻り値はここで formatted string にします。
繰り返しになりますが、すべてのツールには構造化されたドキュメント文字列が必要なので、ここでメモからドキュメント文字列をコピーします。 その後、ツールをコーディングする必要があります。このメソッドは TelemetryReader クラスをインスタンス化します。これが必要です。 TelemetryReader です。先ほど示したメソッドを呼び出すために、 デバイス名が必要です。これは入力として渡されます。minutes_back も必要で、これも入力として渡されます。そして current time string が必要です。幸いなことに、Strands には current time の独自の実装があります。 ですので、それを使用します。current_time_str は Strands の current_time クラスと等しいです。最後に、先ほど示したメソッドを呼び出す必要があります。data frame は tel_reader です。 get_device_sensors_in_timeframe です。入力として持っているデバイス名を渡し、current time string を渡し、minutes_back を渡します。
これで結果を素敵な f-string で定式化するだけです。 Readings for device、デバイス名、for the last minutes_back です。 その後、メソッドから得られた結果を連結するだけです。result に加算して、JSON dumps があり、その後 data frame があり、インデンテーションを2に設定します。最後に、結果を返します。
では、優秀なソフトウェアエンジニアとして、私はツールを書いたので、それをテストする必要があります。それでは非常に素早くテストしてみましょう。アプリケーションが最終的に機能するために。テレメトリデータを取得します。 CSV ファイルから 1 つのデバイスを持つ必要があります。例えば、フリーザートンネルです。 過去 5 分間のデータです。 私はいつもこの問題をやってしまいます。結果だけを返すべきです。 これでうまくいきました。ご覧の通り、フリーザートンネルの過去 5 分間の読み取り値が、素敵な JSON 形式で構造化されています。
ここに追加したい最後のものは、非常にシンプルなツール です。このテレメトリツールの中にあるツールで、エージェントがどのデバイスにアクセスできるかを理解するためのルックアップとして使用できるツールです。ここで状況を考えてみてください。例えば、私が freezer_tunnel と入力します。これは CSV ファイルからコピーペーストしたばかりの名前です。実際のシナリオでは、ユーザーはデータベース内に正確にどのように名前が書かれているかを知りません。ですから、例えばユーザーがタイプミスをしたり、アンダースコアなしで入力したり、大文字や小文字を間違えたりなど、そのようなことがあっても機能するようなルックアップが必要です。では、最後のツール list_available_devices をコピーペーストしましょう。 これで完了です。
最後の楽しい部分は、これらすべてをまとめるエージェントです。FactoryAgent という名前のクラスを事前に作成しました。 これは GPT OSS モデル、セッションの最初にデプロイしたエッジモデルを使用しています。 この大きなシステムプロンプトを使用しています。このプロンプトをどのように構造化したかについて説明したいと思います。これはあなたにとって関連があるかもしれません。最初に渡すことは、ツールがどのように見えるか、そしてどのツールにアクセスできるかについての方向付けです。次のことは、いくつかのシナリオ、いくつかの可能なシナリオとユーザーインタラクションの例です。そしてそれらのユーザーインタラクションに基づいて、エージェントが次々と使用すべきツールです。つまり、ここでは一種の few-shot prompting です。
次に、システムプロンプト、モデル、そしてクラスからインポートしたツールがあります。 trans agent をインスタンス化して、準備完了です。最後に、エージェントをテストして、結果がどのように見えるかを確認する必要があります。セッションの前に、私の親友 Karim に、エージェントをテストするために使用する素敵な UI を作成するよう依頼しました。ですから、このエージェント、この UI を呼び出すだけです。 はい、ここに UI があります。
では、エージェントができたので、クッキーファクトリーの中のオペレーターの立場に自分を置いてください。覚えていますか、私の最初のスライドで、ビジュアルインスペクターがクッキーの中に問題を検出しました。今、あなたはこのクッキーファクトリーの中のジュニアオペレーターで、問題が何であるかを理解したいと思っています。ビジュアル品質検査の前に 2 つのデバイスがあることを知っています。それはフリーザートンネルとクッキーフォーマーマシンです。
ジュニアオペレーターとしての私でしたら、非常にシンプルな質問をします。「debug freezer」です。これは非常にシンプルですが、十分に強力な プロンプトで、エージェントがこのフリーザートンネルで何が問題なのかを理解したり、共鳴させたりするのに役立ちます。ご覧の通り、 CSV ファイル内のデバイスの正確な名前を使用しなかったため、list devices ツールを使用しました。そして、先ほどコーディングした get telemetry data ツールを使用し、レジストリ用に作成した search documents ツールも使用しました。
その理由を見てみましょう。 ご覧の通り、結果を少し大きくしますね。何をしたかというと、 テレメトリデータを取得し、そのテレメトリデータをドキュメンテーションからの正しい結果と比較して、それらの測定値が妥当かどうかを確認しました。私たちの場合、温度が正しい範囲内にないことを検出し、ここではこのマシンをデバッグして動作状態に復元するための フォローアップアクションもいくつか提案しました。
これは、ファクトリースタートがリスニングしている場合に起こることです。ファクトリー内のすべてのものが同じ言語で話すようになります。 つまり、マシン、IoT センサー、システムが完全に統合され、AI システムがファクトリーに関するさまざまなタイプの推奨事項、説明、インサイトを提供できるようになります。ここで重要な部分、これが重要なポイントですが、AWS Outposts EKS ローカルクラスター上での完全なデプロイメントにより、オペレーションを接続しました。接続が切断された場合でも、コントロールプレーンにアクセスでき、データプレーンにアクセスでき、中断が発生した場合でもインフラストラクチャを完全に管理できます。
2 番目は、エッジに小規模言語モデルをデプロイすることで、この種のインテリジェンス、リアルタイムインテリジェンスを可能にします。正確に何をデプロイしているのかを理解し、エージェントがインサイトを取得して、その場で推奨事項を提供します。3 番目、これは非常に重要な部分ですが、毎日さらに多くのデータを生成しており、継続的に学習し、継続的に理解する必要があります。なぜなら、データはあなたの金鉱だからです。このデータを取得したら、モデルを更新し、パイプラインを再度トリガーし、モデルを微調整します。
これら 3 つの QR コードをスキャンして、 agentic AI と小規模言語モデルのエッジでの完全なエンドツーエンドデプロイメントを実行することをお勧めします。今度はあなたの番です。 1 つのプロセスから始めてください。データを取得し、製造生産ラインをより詳細な方法で理解し始めてください。小さく始めて、素早く失敗し、データを理解し、データを正しく適切な方法で構造化し、モデルを微調整してあなたの言語を話すようにしてください。正しい情報を生成してから、AWS Outposts 上のエッジでのデプロイメントを実行してください。
ありがとうございました。このセッションの一部として皆さんにご参加いただけて、本当に嬉しかったです。ぜひアンケートにご回答いただき、フィードバックをお聞かせください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion