re:Invent 2025: エッジ環境での生成AIとagentic AI構築 - SLM最適化とBedrock Agentsの実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Build generative and agentic AI applications on-premises & at the edge (HMC308)
この動画では、AWSのエッジ環境における生成AIとエージェンティックAIの実装について、実践的なアーキテクチャとベストプラクティスが解説されています。データレジデンシー、企業ポリシー、低レイテンシーという3つの主要なビジネスドライバーに対応するため、AWS Regions、Local Zones、Outposts、AI Factoriesを含むAI continuumが紹介されます。小規模言語モデル(SLM)の最適化手法として、llama.cppフレームワークを用いて5倍のパフォーマンス向上を実現した事例や、プロンプトエンジニアリング、RAG(Retrieval-Augmented Generation)、re-rankerの活用により、30億から80億パラメータのモデルで90-95%の精度を達成する方法が具体的に示されます。さらに、Bedrock Agentsを使用したagentic AIシステムの構築例として、g4dn.xlargeインスタンス上でLlama 3.2モデルを実行するデモが実演され、エッジでの自律的なAIワークロードの実現可能性が証明されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
エッジにおける生成AIとエージェンティックAI：re:Invent 2025の挑戦
皆さん、こんにちは。re:Invent 2025へようこそ。本日は、エッジにおける生成AIとエージェンティックAIの進化について、エキサイティングなプレゼンテーションをお届けします。多くの方がすでにお聞きになっているかと思いますが、AWSはリージョンでAIワークロードを実行することに関して、多くの進歩を遂げています。しかし、データレジデンシー、コンプライアンス要件、または低レイテンシー要件のために、リージョンにワークロードをデプロイできないお客様も数多くいらっしゃいます。だからこそ、私たちはエッジでエージェンティックAIと生成AIの力を活用し、イノベーションを推進する方法についてお話しするためにここにいます。
私はPranavです。FernandoとChrisと一緒にここに来られて嬉しく思います。過去数年間、私たちはお客様がリージョン外でアプリケーションワークロードを設計し、アーキテクトするお手伝いに多くの時間を費やしてきました。この実践的な経験により、この分野における課題と機会について独自の洞察を得ることができました。このセッションでは、エッジベースのAIワークロードをデプロイする際にどのように考えるべきかについて、実践的なガイダンスを共有します。私たちの意図は、万能なソリューションを提供することではないことを明確にしておきたいと思います。皆さんがアプリケーションとワークロードを最適にアーキテクトするための、適切なフレームワーク、適切な選択肢を提供したいと考えています。
それでは始めましょう。本日は皆さんにエキサイティングなアジェンダをご用意しています。まず、生成AIとエージェンティックAIとは何を意味するのかを紐解いていきます。次に、すでにお客様に具体的なビジネス価値をもたらしているユースケースについてお話しします。その基盤の上に、事前学習済みモデルをエッジで効率的に実行できるように最適化する方法についてお話しします。最適化は戦いの半分に過ぎませんので、これらのモデルの精度を高め、パフォーマンスを向上させる方法についてもお話しします。最後に、エージェンティックAIワークロードをエッジで効率的に実行できるようにデプロイする方法について深く掘り下げていきます。このセッションの終わりには、AIとエージェンティックAIでイノベーションを推進するために、エッジワークロードをどのようにデプロイすべきかについて、包括的な理解を持ってお帰りいただけるでしょう。
生成AIからエージェンティックAIへ：お客様の進化の旅路
ユースケースやさまざまなAWSのオファリングについて説明する前に、AWSで生成AIを使用しているお客様に見られる旅路についてお話ししたいと思います。全体として、特にこれほど短期間でどれだけ進歩してきたかに非常に感銘を受けています。2023年を見てみると、これはPOCの年でした。お客様はまだテストを行っており、生成AIで何ができるかを見極めようとしていました。
そして2024年には、大きな変化が見られました。ここでお客様は、実世界のユースケースを優先し、達成できるビジネス成果に焦点を当て始めました。そして2025年の今、お客様はビジネス価値の推進に本当に注力しながらも、セキュリティ、プライバシー、そして正しい方法で行うことなど、気にかけるべきことにも引き続き配慮しています。この数年間で見られた大きな変化は、お客様がますます多くのAIワークロードをオンプレミスまたはエッジにデプロイすることを考えるようになったことです。この旅はここで終わるわけではありません。
ここで私たちが目にしているのが、agentic AIシステムの次なる進化です。そしてここからが本当に興味深いところです。agentic AIシステムに入る前に、まずgenerative AIエージェントについて何を意味するのかお話しさせてください。Generative AIエージェントは、はるかにゴール指向です。generative AIシステムと比較して、はるかに複雑な範囲のタスクを処理できます。人間の介入をあまり必要とせずに、ワークフロー全体を本当に自動化できます。同時に、変化するエコシステムに進化していくことができます。
一方、agentic AIシステムは完全に自律的です。ここではエージェント同士が相互作用し、非常に複雑な意思決定を行い、人間のような推論能力を本当に模倣することができます。AIワークロードのデプロイについて考えるとき、ビジネスプロセスを改善するためにagentic AIシステムのパワーをどのように活用すべきかについても考えることが本当に重要です。先ほど申し上げたように、このセッションではgenerative AIとagentic AIシステムの両方をカバーします。
AI continuumとAWS AI Factories：リージョンからエッジまでの一貫した体験
ユースケースに深く入る前に、AI continuum と、この領域に存在する様々なAWSのオファリングについてご説明したいと思います。AIワークロードのデプロイについて考えるとき、人々は2つの選択肢について考える傾向があります。それはリージョンかオンプレミスかです。現実には、これははるかに微妙な会話なのです。実際、多くのエンタープライズが、オンプレミス、リージョン、さらにはエッジデプロイメントに関して一貫したエクスペリエンスを求めています。
では、このような様々なデプロイメントニーズを持つお客様の要件をどのように満たしているのでしょうか？基本的には、お客様が必要とする場所にAWSを提供することで実現しています。左側にはAWS Regionsがあり、38の場所で利用可能です。これらは引き続き、最新かつ最高のNVIDIA GPU、そしてTrainiumやInferentiaを含む私たち独自のAmazon accelerated chipsへのアクセスを提供しています。
これらのリージョンは、高性能ストレージと、より優れたペタビットスケールのネットワーキングを提供するEC2 Ultra Clustersも提供しています。これらのリージョンでは、BedrockやSageMakerのようなAIサービスへのアクセスも得られます。右側に移ると、ここにはAWS Local Zonesがあり、Atlanta、Dallas、Phoenixのような特定の場所で利用可能です。これらのLocal Zonesは、NVIDIAのGPUが高密度に集中し、私たち独自のAmazon accelerated chips、そしてEC2 Ultra Clustersと高性能ストレージを備えた、これらのリージョンと同様のエクスペリエンスを提供します。
2日前に、AWS AI Factoriesと呼ばれるものも発表しました。これは、これらのリージョンや一部のLocal Zonesと非常に似た体験を提供しますが、お客様自身のデータセンターやオンプレミス施設内で利用できるものです。AWS AI Factoriesが何を意味するのかについては、次のスライドでも少しお話しします。しかし、私が説明した3つの提供形態、つまりリージョン、これらの一部のLocal Zones、そしてAWS AI Factoriesを見ていただくと、これらは一貫した体験を提供し、推論、ファインチューニング、さらには単一のロケーションで多数のGPUを必要とするトレーニングなど、あらゆる種類のAIワークロードをデプロイすることを可能にします。
右側は、私たちがエッジと呼んでいるものです。ここには、世界中の複数のロケーションに分散している他のLocal Zonesがあります。これらのLocal Zonesは、お客様自身でデータセンターを運用する必要なく、コンピュートとストレージへのアクセスを提供します。また、AWS OutpostsとDedicated Local Zonesもあり、これらはお客様自身のオンプレミス施設内で同様の体験を提供します。そして、ファーエッジ向けのAWS IoTの提供もあります。これらすべてのエッジデプロイメントについて考えると、推論とファインチューニングのワークロードに最適です。
全体として、このAIコンティニュアム全体を通じて、私たちが確実にしたことの1つは、サービス、API、ツール、そしてインフラストラクチャに関する一貫した体験です。それでは、AIコンティニュアムをご理解いただいたところで、ユースケースやビジネスドライバーについて説明する前に、これらのAWS AI Factoriesについて簡単にお話ししましょう。これらのAWS AI Factoriesは、最新のAIチップとEC2 Ultra Clusters、そしてFSXやS3 Express One Zoneのような高性能ストレージを組み合わせた専用デプロイメントです。
全体として、これらのAWS AI Factoriesは、お客様がデジタル主権の要件を満たしながら、AIを活用したアプリケーションを迅速にデプロイすることを可能にします。私たちは、お客様の電力を活用して、お客様のデータセンターにこれらのAWS AI Factoriesをデプロイします。同時に、お客様は自身のGPUや自身のネットワーク接続を使用するオプションも持っており、これにより基本的にお客様がこの分野で行った投資を活用することができ、お客様がAIジャーニーのどこにいても、そこでお客様に対応することを本当に可能にします。
これらのAWS AI Factoriesのもう1つの重要な部分は、BedrockやSageMakerのようなAIサービスへのアクセスです。これらのサービスとAWS AI Factoriesにより、お客様は異なるモデルプロバイダーと契約を交渉する必要なく、基盤モデルへのアクセスを得ることができます。同時に、これらのAWS AI Factoriesはリージョンに接続されているため、お客様はAWS Cloudで使用しているのと同じセキュリティ、同じプライバシー、同じツールを得ることができます。そして先ほど申し上げたように、AWS AIコンティニュアムは、お客様にリージョンからエッジまで一貫した体験を提供します。
エッジデプロイメントを推進する3つのビジネスドライバーと実用ユースケース
エッジに関しては、すべてのお客様に共通する3つの主要なビジネスドライバーがあります。1つ目はデータレジデンシーに関するもので、特定の規制対象ワークロードを持つお客様は、これらのワークロードをリージョンにデプロイすることができません。これは国固有のレジデンシー要件、または国固有のソブリンティ要件があるためです。全体として、特定の地政学的境界や地理的境界の外でデータを移動したり処理したりすることに制限があるのです。
2つ目のビジネスドライバーは企業ポリシーに関するもので、特定の企業やエンタープライズは、自社のデータ、特にモデルウェイトを、自社のサイトや自社のオンプレミス施設の外でデプロイしたり実行したりすることができません。3つ目のドライバーは低レイテンシーに関するものです。これは特定のワークロードを持つ特定のお客様が、これらのワークロードを遠隔地のリージョンにデプロイすることで発生するレイテンシーに耐えられない場合です。全体として、これら3つの主要な要素、つまりデータレジデンシー、企業ポリシー、そして低レイテンシーが、より多くのお客様がAIワークロードをエッジやオンプレミスにデプロイすることを検討している背景にある基本的なビジネスドライバーを形成しているのです。
私が説明したこれらすべての3つのビジネスドライバーにおいて、さまざまな業界のお客様が、これらのエッジデプロイメントをさまざまなAIユースケースに使用しています。
アーキテクチャの観点から見ると、それらは3つの大きなカテゴリーに分類される傾向があることがわかりました。1つ目は顧客体験の向上に関するものです。素晴らしい例としてはチャットボットがあり、お客様は汎用モデルから業界特化型モデルまで、あらゆるジェネレーティブAIを使用しています。また、コールセンターサポートの素晴らしい例も見てきました。コールセンターでは、音声通話をテキストに書き起こし、それらを分析してインサイトを得るためにジェネレーティブAIを使用しようとしています。また、多くのお客様がジェネレーティブAIを使用してセンチメント分析を行い、自社の顧客とのインタラクションを本当に理解しようとしているのも見ています。
2つ目のカテゴリーは生産性と創造性の向上に関するものです。これは私たちがAmazon社内でも行っていることの素晴らしい例です。すべての通話の後、すべてのミーティングの後、私たちは音声をテキストに書き起こし、特定のミーティングで話し合われた主要な決定事項、主要なアクションアイテム、そして次のステップを要約しています。もう1つの素晴らしいユースケースの例はコンテンツ作成で、ここでは強い需要が見られています。お客様はマーケティング資料、営業資料、さらには他の技術資料の初稿にジェネレーティブAIを使用しようとしています。
3つ目のカテゴリーは、ビジネスプロセスの最適化に関するものです。最近、ある銀行が私たちに連絡してきまして、彼らは月次の重要なビジネスレポートを生成するのにかかるコストと時間を大幅に削減するために、generative AIを活用したいと考えていました。これも、お客様から強い関心をいただいている素晴らしいユースケースです。実際、黄色で表示されているユースケースは、お客様がすでにPOCから本番環境に移行しているユースケースで、スライドでハイライトされている他のものは、まだお客様とテストやPOCに取り組んでいるユースケースです。
ユースケースとビジネスドライバーをご理解いただいたところで、Chrisをステージにお招きします。彼は、事前学習済みモデルをエッジで効率的に実行するために最適化する方法についてお話しします。また、これらのモデルでモデルの精度を向上させ、パフォーマンスを引き出す方法についてもお話しします。その後、Fernandoがデモを実演し、これらすべてを実際にお見せします。Chrisが始める前に1つ明確にしておきたいのは、セッション終了後に、デモのコードにアクセスできるようにしますので、皆さん自身で試していただき、ここでの興奮を追体験していただけます。ありがとうございます。
モデル選択の戦略：小規模言語モデルで実現する5倍のパフォーマンス向上
こんにちは。この1年間、お客様と共にgenerative AIのエッジユースケースをデプロイするために取り組んできた私たちの旅を、皆さんと共有したいと思います。その過程で、私たちは多くの教訓を共に学んできました。私たちがお見せしようとしている形式は、テクノロジーを説明し、アーキテクチャを示し、そして実際に動作しているシステムのデモをお見せするというものです。同僚が述べたように、最後には質問があれば、他に話したいことがあればお答えしますので、お声がけください。
では、まずこの分野全体を見ていきましょう。お話ししたように、ビジネスドライバーは、お客様向けのself-managed SLMsです。様々な理由から、お客様はデータレジデンシーや透明性などの理由で、generative AIアプリケーションをオンプレミスで管理する必要があります。私たちが取り組んできたのは、特定のモデルを実行するためだけでなく、実際にはHugging Face上のほぼどんなモデルでも選択して、この方法論とアーキテクチャを適用できるようなcookbookを作成することです。
私たちはllama.cppフレームワークを採用しました。なぜなら、モデルの実行方法について多くの制御が可能だからです。しかしさらに重要なのは、モデルを圧縮して小さな領域に収めることができる点です。エッジで実行する場合、電力、冷却、そしてGPUはすべて希少で入手困難なコモディティだからです。この1年間取り組んできた作業で、このフレームワークを使用してモデルのパフォーマンスを約5倍向上させました。最初は数tokens per secondから始まり、現在では全く同じSLMを全く同じGPU上で実行して、40から50 tokens per secondまで到達しています。
それでは、このエンゲージメントに入る際に最初に考えるべきことは、モデルの選択です。実際にどのようにモデルを選ぶのか?左側のスライドを見ていただくとわかるように、各モデルはそれぞれ異なる分野に強みを持っています。特に小規模言語モデル、つまり100億パラメータ未満のモデルに絞って見ていくと、その傾向が顕著です。
実際に私たちが発見したのは、MistralやPhiのような特定のモデルは数学に非常に強いということです。Qwenはテキスト生成に非常に優れており、また特定の言語や特定のドメインにも非常に強いです。デプロイメント戦略の観点から、最初に決めるべきことは、実際にどのようにモデルをデプロイするかということです。数百台のGPU上で動作するエンタープライズLLMを使うLLM戦略を選ぶのか、それとも特定のタスクや特定のシステムで動作する小規模言語モデルを使うという業界のトレンドに従うのか、ということです。
この数年間で私たちが学んだことは、モデルに何をさせたいのかを理解することが本当に重要だということです。ハイレベルだけでなく、詳細まで理解する必要があります。本当に優れた評価基準を持つ必要がありますし、ユースケースはかなり低いレベルまで定義される必要があります。そして選択をしなければなりません。その選択とは、1秒あたり何トークン必要なのかということです。非常に小さな言語モデルを使えば、1秒あたりのトークン数は膨大になりますが、その精度はそれほど高くありません。あるいは、モデルに入力するコンテキストサイズとのバランスを取りたいと考えるかもしれません。なぜなら、私たちが発見したのは、より大きなコンテキストサイズはモデルを遅くする傾向があるからです。または、モデルをより小さなフットプリントに圧縮するための量子化を考えることもできます。
例えば、CPUで音声からテキストへの変換を実験しているお客様もいます。GPUすら使っていません。私たちが常にベストプラクティスとして推奨しているのは、小さなモデルから始めて、試してみて、うまくいくかどうかを確認し、それから次のサイズに上げ、さらに次のサイズに上げ、というように進めていくことです。私たちが発見したのは、多くのお客様がLLMから始めて、うまく動作すると、実際には同じ精度とパフォーマンスを得るためにより小さなモデルが使えるかどうかを確認しないということです。
最後に考えるべきことは、サステナビリティとTCOです。昨年、あるお客様がいらっしゃいました。基本的に手動プロセスを使っていた金融サービスの銀行です。毎月実行しなければならない財務レポートがあり、人間を使ってまとめていました。なぜなら、データベース上に共有インデックスがないからです。基本的に生成するのが難しいレポートなんです。彼らは実際に始めて、大規模言語モデルを選びました。手動で行うコストはおよそ6万ドルでした。LLMに移行したところ、うまく機能しました。それほど多くの作業をせずに約80%の精度を得ることができ、彼らはそれに非常に満足していました。しかし、その後、実際にLLMを実行してトークンを処理するために支払うコストが12万ドルだということがわかったのです。
私たちが関与して、彼らは小規模言語モデルをデプロイし、これから説明するプロセスを経ました。全体で約7,000ドルから8,000ドルで稼働させることができました。つまり、実際に良好なTCOを実現できたわけです。ここで私たちが言いたいのはそういうことなんです。作業している全体のエコシステムを理解することが本当に重要で、単に仕事をこなせる最大のモデルを選ぶだけではいけないということです。
エッジ推論アーキテクチャの実装とデモ：Llama 3.2による実践例
これがこれからお見せするアーキテクチャです。このアーキテクチャには3つのレベルがあります。これは現時点で始めているものです。図の右側から始めると、ユーザーがいて、彼らがシステムにプロンプトを提示します。複数のアプリケーションサーバーに負荷分散するアプリケーションロードバランサーがあります。アプリケーションサーバー自体は実際にプロンプトエンジニアリングの作業を行っており、プロンプトを受け取り、プロンプトテンプレートでそれを充実させます。チャットボットのようなリアルタイムアプリケーションの場合は、ALBを通ってモデルに入ります。
また、テキスト要約とテキスト生成のユースケースもあり、同じアーキテクチャフレームワークを使用していますが、異なるコンテキストとLLMの異なるトレーニングを使用しており、キューイングメカニズムを通ってシステムに入ります。このアーキテクチャは基本的に、さまざまなユースケースをサポートし、1ユーザーから数十万ユーザーまでスケーラブルなシステムを提供するように設計されています。
もう一つ言っておきたいのは、本当に大規模なGPUを使いたいというお客様と多くの議論をしましたが、その結果、水冷の問題に直面したということです。これはある法律事務所で行ったテスト結果で、彼らはすべての法律テキストを取り込んでいました。私は弁護士ではないので、彼らが正確に何をしていたのかはわかりませんが、すべてのテキストがそこにあり、実際に会社の弁護士にアドバイスして応答を返すためにチャットボットを使用していました。
ここの白い線は必要なパフォーマンスを示しており、彼らは要件として1秒あたり6トークンと定義しました。ご覧のとおり、
1ユーザーから始めて、最大48の同時ユーザーまで実行しています。ここでテストしているすべてのモデルは、私たちがテストするモデルのサンプルセットに過ぎません。私たちは常にさまざまなモデルをテストしています。そして、約48の同時ユーザーあたりで、1秒あたりのトークン数が低下し始めるのがわかります。一方、いくつかのモデルは64まで性能を維持することができました。彼らが評価のために選んだモデルは約50でピークに達しました。そのため、最大10,000人がモデルを使用するスケーリングシステムでは、同時ユーザーが1%以下であることがわかったので、基本的にユーザー数を50倍するだけでGPUのサイジングができました。
それでは、同僚のFernandoにデモをお願いします。ありがとうございます、Chris。それでは、エッジでのローカル推論を実証するために使用されるこのPythonアプリケーションをご覧ください。これはシンプルなPythonアプリケーションです。開発にフレームワークは使用していません。そして、ここではLlama 3.2モデルを使用していることがわかります。これは38億パラメータのモデルです。この種のアプリケーションには非常に小さなモデルです。ここにシステムプロンプトがあり、扱うべき非常に重要なトピックの1つはプロンプトエンジニアリングに関連しているので、ここでいくつかのユースケースに対応しています。また、エッジで実行されていることを実証するために、temperatureとTop Pもあります。
このアプリケーションの背後にあるインスタンスについてお話しすると、g4dn.xlargeがあることがわかります。つまり、小さなGPUです。インスタンスごとに1つのGPU Tesla T4を使用しており、アプリケーションとベクトルデータベースもその場で実行されています。これらのインスタンスはLocal ZoneやOutpostsにデプロイできます。リージョンから特定のものは何も使用していません。ここで質問をすると、例えばService Linkとは何ですか、と聞くと、答えが表示されます。非常に小さなモデルで作業しているため、非常に高速です。そして、ここには入力トークン、出力トークン、レイテンシー、1秒あたりのトークン数に関するいくつかのメトリクスがあります。
もう1つ興味深い部分は、これはLlama serverを実行している場所です。Llama CPPは、この場合にローカル推論を実行するために使用しているLlama serverです。そして、こちら側にチャットボットがあります。上部にはメモリ、使用中のGPUメモリ、および使用率が表示されています。同じ質問、Service Linkとは何ですか、と聞くと、使用率が表示されます。消費が始まり、その後停止します。このユースケースには非常に高速なモデルであり、Chrisが述べたように、この場合は小さなモデルを使い始めて、ユースケースにとって重要な適切なモデルが見つかるまでテストを開始することがベストプラクティスです。
もう1つ重要なトピックは、temperatureに関連しています。ここで観察したことの1つは、大きなモデルで作業していて、より創造性を持たせたい場合、temperatureを上げることができます。0.7、0.8、時には0.9から始めます。小さなモデルで作業する場合は、非常に簡単にハルシネーションを起こし始める可能性があるため、注意が必要です。したがって、適切な値を定義する際に注意が必要なパラメータです。この種のパラメータの適切な値を検出して見つけるために、内部で評価プロセスを実施する必要があります。
それでは、こちらのアーキテクチャですが、ベクトルデータベースとしてMilvus を実行しています。また、RDS Postgresとpgvectorを使用して実行することもできます。ご希望であればこの拡張機能を有効にすることができますし、実行可能な他のベクトルデータベースもあります。
rerankを使用していますが、これは別のインスタンスで、このプレゼンテーションの後半で説明します。実行に使用しているSLMはLlama Serverの54 Instructです。そして ベクトル埋め込みですが、これは私たちが使用している別のモジュールで、RAGの一部となっており、数分後に説明いたします。それでは、お願いします。
モデル精度向上のフレームワーク：プロンプトエンジニアリングとファインチューニング
ありがとうございます、Fernando。さて、ここでご覧いただけるのは、モデルを効率的に実行するためのフレームワーク です。私たちの取り組みの最初の部分として、おそらく2年前に始めたのは、エッジで低い所有コストで本当に効率的にモデルを実行する方法でした。今年わかったことは、お客様が私たちのところに来て、「昨年の70%の精度は素晴らしかったが、今年は95%が欲しい」とおっしゃることです。次のスライドで説明するのは、汎用モデルを実際に取り上げて、実際の運用において本当に高いレベルの精度 を提供できるように準備する方法です。
そこで、すべてのデプロイメント、特にエッジでのデプロイメントにおいて、 プロンプトエンジニアリング、RAGデータベースの使用、そしてオプションでファインチューニングを強く検討すべきだと推奨しています。なぜなら、一部のモデルは特定のタスクに対してファインチューニングが実際には必要ないからです。必要な場合もあります。しかし、私たちが言っているのは、基本的にモデルの再トレーニング、つまりモデルに対して心臓手術を行い、完全に作り直すようなことは、リージョンで行うべきだということです。そして、お客様には合成データの作成をアドバイスしており、情報セキュリティ情報をエクスポートしたり、リージョンでモデルをトレーニングするためのデータを拒否したりしないようにしています。これは規制市場でうまく機能する戦略です。
それでは、プロンプトエンジニアリングから始めますが、先ほど申し上げたように、Fernandoが今ちょうど一部をお見せしましたが、これは本当に重要です。そして、これは暗黒の技術とも言われており、実際にモデルに何をしてほしいかを伝える必要があります。それがプロンプトエンジニアリングの技術です。10語で応答するように、または1語で応答するように指示を与える必要があります。モデルを非常に詳細にコントロールできます。コンテキストを与える必要があります。
そして最近発見した面白いことの一つとして、コンテキストに関することがあります。私たちにはAWS Wavelengthという AWS製品があるのですが、Wavelengthとは何ですか？という質問をしたところ、モデルは光速の物理学的な定義を返してきたんです。モデルは私たちがAWSベースの製品について尋ねていることを全く理解していませんでした。これこそがコンテキストがいかに重要かということなんです。モデルを望む動作に本当に導いてあげる必要があります。ユーザー入力は非常に重要で、ユーザーが誰なのか、どういう人なのか、技術者ではないのか、技術者なのか、などです。また、セキュリティコンポーネントを追加して、実際にアクセスできるものとできないものを指定することもできます。
そして出力はトーンとスタイルです。アーキテクトの回答が欲しいのか、エンジニアリングの回答が欲しいのか、弁護士タイプの回答が必要なのか、あるいは後ほどのデモでご覧いただきますが、シェフの回答が欲しいのか。これらすべてはプロンプトエンジニアリング側でコントロールできます。また、必須項目を設定することもできます。答えがわからない場合は作り上げないでください、といったようなことです。
そして、お客様と一緒に行うもう一つのことがファインチューニングです。私たちはパラメータ効率的ファインチューニングを手法として推奨しています。基本的にはモデルを取得し、モデルのほとんどのレイヤーを凍結して、いくつかのレイヤーで重みを変更します。重みというのは実質的にモデル内のデータのことですが、実際にモデルを、例えばチャットボット環境や要約環境などで応答できるように装備するわけです。
RAGアーキテクチャとre-rankerによる精度改善：90%超の精度を実現する方法
それでは、これらすべてが動作するアーキテクチャをお見せします。コンテキストエンジニアリングについては既に簡単にご覧いただきましたが、ここにRAGアーキテクチャを示す2つのスライドがあります。スライドの右側には、多数のデータソースがあります。PDFやWord文書が入ったファイルリポジトリから、データベースまで、すべてです。金融サービスのお客様の多くは、実際にこれを使用して顧客アカウント情報などのデータにアクセスしています。
また、インターネットにもアクセスできます。後ほどのデモでご覧いただけますが、データレイクなどの外部データソースにもアクセスして、それを取り込むことができます。インジェスチョンプロセスは、新しいファイルや新しいデータセットがあることを検出します。これはEC2インスタンス上で実行されているアプリケーションで、新しいファイルや新しいデータセットがあることを検出し、それを取り込みます。PDFの場合は、PDFのチャンキング戦略も実行します。
なぜなら、巨大なファイルを一つのチャンクとして入れたくないので、おそらく1ページあたり4つのチャンクに分割します。それから適切なフォーマットでembedding modelに入力され、embedding modelは基本的にそれをチャンクと一緒にベクトルに変換し、両方がベクトルデータベースに保存されます。ここではRDS Postgres上のPG vectorを示していますが、他のものを使ったデモもあります。このアーキテクチャは特定のタイプのknowledge baseに固定されているわけではありません。
そして、RAGデータベースを使ってシステムが稼働すると、消費者がやってきて質問やプロンプトを発行します。それが私たちのアプリケーションに到達し、prompt engineeringを行います。そしてプロンプトをembedding SLMに送信し、基本的にベクトルを作成します。そのベクトルを使ってtop K検索を行います。私たちのケースでは、出力として25を設定していると思いますので、クエリに対してデータベース内で最も近い25個のチャンクを返します。
それについて私たちが発見したことの一つは、多くのSLMが混乱していたということです。なぜなら大量のデータを受け取っていたからです。また、上位のチャンクの中には似たようなベクトルを持っているかもしれませんが、間違ったデータである可能性もあります。これら両方のことがモデルを混乱させていました。なぜなら、25個すべてのチャンクを処理し、推論を行う際にどれが有用でどれがそうでないかを判断しなければならなかったからです。これが多くの不正確さを引き起こしていました。
そこで私たちはre-rankerというアイデアを導入しました。top Kの出力を取得して、別のSLMに通すのです。そのSLMは2つの重要なことを行います。一つは、knowledge baseからの応答におけるバイアスを検出します。また、システムに設定したガードレールを適用することもできます。例えば、この種のデータを公開したくないといったようなことです。それらすべてをre-rankerで設定できます。さらに重要なのは、knowledge baseから得たリストを精査して、推論を行うSLMにはこれら2つのフラグメントだけを送りたい、なぜなら残りはそれほど関連性がないからだ、と判断することです。
これはSLMのパフォーマンスに非常に大きな影響を与えます。なぜなら、今や25個のチャンクを処理するのではなく、たった2つを見るだけで済み、チャンクのいくつかが何らかの形で誤解を招いているかどうかを判断する必要がないからです。そしてアプリケーションがプロンプト、プロンプトテンプレート、そしてre-rankerから返されたtop Kチャンクをパッケージ化し、推論のプロセスを経て答えを返します。
このアーキテクチャによって、小規模なモデル、特に80億パラメータのモデルから30億パラメータのモデルにおいて、非常に良い結果が得られていると言えます。実際、これらのモデルは常に90%から95%の精度で動作しており、ハルシネーションもほとんど発生していません。お客様は実際に非常に驚き、喜んでおられまして、このアーキテクチャでどのようにこれを実現しているのかについて、データサイエンスチームと多くの議論を交わしています。
では、re-rankingについて少しお話ししたいと思います。これは私たちが新しく取り組んでいることの一つですので。通常、セマンティック検索では、基本的にアプリケーションがセマンティック検索を呼び出し、ナレッジベースが処理を行って、入力されたプロンプトに可能な限り近いベクトルを選択し、それがアプリケーションに返されます。ここでご覧いただけるように、この例では5つのチャンクを使用している場合、5つのチャンクがプロンプトに追加され、その5つのチャンクとプロンプトがSLMに送られます。
これが意味するのは、SLMは大きなコンテキストサイズを処理しなければならないということです。なぜなら、5つのチャンク全てがそこに含まれているからです。そしてさらに重要なのは、これらのチャンクの中には誤解を招くものもある可能性があるため、SLMは通常よりも多くの処理を行わなければならないということです。re-rankerを使用することで、実際に別のシステムを通してフィードし、リストをフィルタリングして、この場合は本当に関連性の高い1つのレスポンスに絞り込むことができます。つまり、SLMに送られるコンテキストは非常に小さく、プロンプトを補強する点で非常に正確になります。
これは非常に有益な設定であることがわかりました。そして、なぜナレッジベースで全ての検索を一度に行わないのかと疑問に思われるかもしれません。しかし、2つのステップで行うことで、実際にバイアス検出を行い、ガードレールを設けることができることがわかりました。また、ナレッジベースで非常に複雑な検索を一度に行うよりも高速でした。それでは、デモのために戻します。
ありがとうございます、Chris。それでは、こちらに比較モードもご用意しており、エッジで動作するRAGを使用した場合と使用しない場合を示しています。このアプリケーションは、Chrisが前のスライドで紹介したアーキテクチャをそのまま実行しています。
まず思い出していただきたいのは、2つのインスタンスがあるということです。1つはRAGのコンテキストを使って推論を実行するために使用しているもので、もう1つはコンテキストなしで使用しているものです。ここで質問をすると、左側ではRAGなしで実行される推論が見られることを期待しています。右側ではRAGありです。では、Service Linkとは何ですか、という質問をしてみます。このRAG環境では、Local ZonesとOutpostsに関するAWSの公式ドキュメント、そしてBedrockに関する情報を取り込んでいます。Service Linkについて質問すると、システムプロンプトではチャットボットを定義するように作業を行い、この情報を使って質問に答える責任を持たせています。
ここで見ることができますが、Service Linkとは何ですか?こちら側から見ると、Service LinkはAWS Outpostsの機能で、Outpostsとそれに関連するリージョン間の顧客VPCトラフィックのためのものです。反対側を見ると、モデルがハルシネーションを起こしているのが分かります。なぜなら、この小さなモデル内の情報を使用しているからです。正確な答えや正確な情報を使用していないのです。こちら側では、使用されたソースも表示されており、ここで使用しているチャンクを見ることができます。RAGでの距離、この場合はナイーブRAGですが、このチャンク、距離、この場合の類似度は19%です。rerankの後、rerankはこのチャンクを99%に再分類します。これは理にかなっています。これも同じです。つまり、26%だったものが今では92%になっています。27%だったものが90%になっています。rerankはここで実行されて、ハルシネーションを減らし、モデルに送るノイズの量を減らしているのです。
小さなモデルに送る場合、大きなモデルで作業するときは、大きなモデルは複雑さを処理できます。つまり、何がノイズで何がそうでないかを理解でき、正確な答えを提供できます。小さなモデルで作業する場合は、注意が必要です。なぜなら、それは小さなモデルができることではなく、非常に簡単にハルシネーションを起こし始める可能性があるからです。この場合、異なるデータセットでテストを行い、まさにこの動作を観察することができました。
はい、Chrisさん。はい。では、そのセクションを締めくくると、私たちが言っているのは、このプロセスを顧客と何度も経験してきたということです。まず、評価基準に時間をかけ、ファインチューニングに使用できる高品質なデータセットを作成することは本当に価値があります。また、モデルをチェックし、モデルが正しく動作していることを確認するためにも使えます。プロンプトエンジニアリングは、先ほど申し上げたように、本当に重要で、モデルがどのように動作すべきかのコンテキストです。モデルへのガイドであり、また、私たちのデモでも見ることができますが、指示には、でっち上げないでください、答えが分からない場合は答えが分かりませんと答えてください、などと書かれています。
そして、RAGを使用することは、常に再トレーニングする必要なく、新鮮なデータをモデルに取り込むのに非常に優れていますが、特にエッジにデプロイしている小規模言語モデルにおいて、モデルの精度を向上させるのにも役立ちます。そして、最適化プロセスとテストプロセスを経ます。これが、私たちが現在多くの顧客に成功裏に展開しているブループリントです。特定のQ&Aチャットボットから要約、さらにはコンプライアンスチェックなどまで、あらゆることを行っています。これが、いわば、パズルの生成AI部分でした。
エージェンティックAIシステムの設計：自律的な意思決定を可能にするアーキテクチャ
次は、agentic AIについてお話しします。そして繰り返しになりますが、私たちにはagentic AIを実行したいというお客様がいらっしゃいますが、エッジで実行するのは課題となっています。まず、皆さんが同じ認識を持っていることを確認するために、私たちはagentic AIを、人間による常時監視なしに、事前に決められた目標を達成するために独立して行動できる自律的な人工知能システムと定義しています。私はこれを、基本的にはシステムがあなたの望むことを理解して、そしてあなたのためにデータを取得しに行く方法だと考えるのが好きです。
主要な要素とアーキテクチャの観点では、AIエージェントは独立しています。常に実行し続けており、半自律的です。人間をループに含めるチェックポイントを設けることができます。
しかし、それらは単独で実行できます。ゴール指向です。Natural Language Processingを使用して、人間からエージェントに入ってくる文章を実際に処理し、エージェントはそれを分解し、文脈的推論を使用して、顧客の応答にどう対応するかのワークフローを作成します。さらに重要なのは、エージェントがGenerative AIと異なる点として、進行しながら継続的に学習していくということです。
アーキテクトとして考慮すべき点の一つは、エージェントはトークンを大量に消費するということです。ですから、本当に必要な場合にのみエージェントを使用したいのです。あらゆる場所にエージェントを配置したくはありません。なぜなら、tokens per secondの観点で実行コストが非常に高いからです。主なメリットは、本当に適応性、自律性、そして複雑なワークフローを持つ可能性のあるプロセスにおけるより迅速な意思決定です。
エージェントがどのようなユースケースに適しているかについてのガイダンスを示そうとしています。なぜなら、私たちはエージェントがすべてに適しているとは言っていないからです。エージェントは、顧客が以前に見たことのない質問をしてくるタスクに適しています。動的に作成される、あるいはその場で作成されるワークフローの作成に適しており、基本的にはタスクリストに向かって作業し、他のツールや他のエージェントと相互作用します。つまり、異なるツールと連携できるのです。私たちのデモでそれをお見せしますが、そこではエージェントがGenerative AIシステムを呼び出してテキストを作成するだけでなく、画像も作成します。
また、エージェントがあまり関連性のない場合についても考慮する必要があります。変化がほとんどない構造化された環境では、エージェントはオーバースペックです。あるいは、ワークフローが常に同じで、常に同じパターンを経由する場合、それを行うためにエージェントは必要ありません。通常のGenerative AIアプリケーションや標準的なMLモデルで同じことができます。ここでの重要なポイントは、変化が限定的である場合や、コストに敏感な場合、エージェントはデプロイメントの最適な出発点ではない可能性があるということです。
留意すべき点の一つは、Generative AIにおけるハルシネーションです。ハルシネーションは良くありません。エージェントにおいて、それが暴走すると、本当に悪い事態になる可能性があります。ですから、常にシステムの動作方法と振る舞いを制約しようとすることが重要です。エッジにおけるエージェントに対して私たちが推奨していることの一つは、制約されたコンピューティング環境であるため、推論エンジンとしてsmall language modelsを実行することです。
これらは本当に優れています。スペシャリストになれるという点で、エージェント内で動作するスペシャリストSLMになることができます。各ドメインや操作のセットに合わせてカスタマイズでき、非常にカスタマイズ性が高いです。さらに重要なのは、エージェントのすべての側面、つまり振る舞いや見ることができるデータをコントロールできることです。基本的に低いインフラストラクチャコストを実現できます。なぜなら、SLMを実行する際のトークンあたりのコストは、LLMのコストの2、3パーセント程度と、はるかに低いからです。エッジで実行するために同じ数のGPUは必要ありません。また、特に低レイテンシという点で、非常にパフォーマンスが高いです。一部のモデルは実際に非常に迅速に回答を返してくれますが、これはエージェントにとって重要です。
実際に私たちは、ここでお見せしているデモをAWS Bedrock Agentsを使って構築しました。これを選んだのは、かなり使いやすかったからです。実際に非常に堅牢な機能セットです。非常に拡張性が高く、私たちはそれをエッジまで拡張しました。そして、エージェントを迅速に作成してデプロイすることができます。これは、私たちがどのようにエージェントを構築したかについての背景説明です。Bedrock Agentsの詳細には立ち入りません。
アーキテクチャの観点から見ると、同じセットアップを再び使用しており、アプリケーションがあり、そのアプリケーションがプロンプトエンジニアリングを行い、ユーザーをチェックしています。それがエージェントに転送され、エージェントについては、次のスライドでエージェントの内部を詳しく説明します。また、semantic cacheも導入しました。なぜなら、エージェントでは多くの場合、クエリや質問が既に受信したものと類似していることがわかっているからです。そのため、ワークフロー全体を経由する必要はありません。semantic cacheから何かを取り出すだけで済み、コストの面でかなり良い節約になります。
次に、human in the loopのステップを設けることができます。ここでは人間が何かをチェックしたり、クリックしたりする必要があります。そして、一連のツールがあるわけですが、agenticアーキテクチャとの重要な違いは、ツールが再帰的に呼び出されるという点です。エージェントは必要に応じて何度でもツールを呼び出すことができます。一方、Generative AI RAGシステムでは、ここに示しているRAGデータベースはプロンプトを受け取った時に呼び出されますが、再度呼び出されることはありません。
一方、エージェントは実際に何度でもデータベースからデータを取得することができます。RAGデータベースから受け取った答えが気に入らなければ、再度アクセスすることができます。また、他のエージェントを呼び出して、専門的なタスクや自分が対応できないタスク、例えば数学エージェントやグラフィックスエージェントなどを実行させることもできます。そして、データベースへのクエリやデータベースからデータを取得するためのSQLクエリの記述といった単純なタスクを実行するためにツールを呼び出すことができ、これを何度でも繰り返すことができます。
RAGデータベースのコンポーネントの内部を見てみると、最初のステップは入ってくる質問を認識、つまり理解することです。モデルはテキストを分解して、何かを尋ねている場合、それが何を意味するのかを判断する必要があります。次に推論段階を経ます。ここでは基本的に、ワークフローの外で人々がSLMとプランニング機能を使って作業し、問題が何であるかの理解と、問題にどう対処するかの理解を作り出します。そして、実際にツールを繰り返し呼び出すことができるアクション機能があります。また、重要なこととして、メモリを持っています。つまり、実行していることのコンテキストのための短期メモリと、システムから学習するための長期メモリ、そして監視と学習機能があります。
Chef AntoineとChef Amélie：エッジで動作するAIエージェントの実演とまとめ
それでは、デモに移りたいと思います。ありがとうございます。SLMは特定のドメインに対して非常によく機能します。非常に明確に定義されたドメインがある場合、使用を検討できるものです。このデモでは、一般的なAIシェフ、フレンチシェフのChef Antoineをお見せできます。ここでいくつかの材料を定義すると、レシピを準備してくれます。すべてがオンサイトで実行されており、すべてがAIによって生成されています。
では、タンパク質を選択できます。ここに4つのステップがあります。牛肉を選択したいと思います。次に、栄養源ですが、ボタンマッシュルームとトマトだけを使いたいと思います。そして香味料ですが、ここでこれを選択できます。最後に材料があり、ここをクリックするとエージェント用の特定のシステムプロンプトが表示されます。使用しているモデルはLlama 3.2 1B Instructです。モデルに送信すると、モデルがレシピを準備し、また画像の説明も準備します。なぜなら、この説明を別の実行中のモデルに送信して、この料理の画像を生成するからです。
それでは、ここで作成した際に、レシピを準備しましたが、Boeuf Bourguignonを選択したのが見えますね。レシピが作成されているのが分かります。シェフのヒントがあり、最後にここに備考があります。このモデルでは27トークン毎秒でした。そしてここに画像が表示されています。この画像は1つのSLMによって生成されています。このSLMに基づいて、別のモデルに送信し、その料理に関連する画像を生成しています。これは単純なPythonアプリケーションですが、Chef Amélieもあります。Chef Amélieはパーティーや自宅でのイベントの準備や整理をお手伝いします。
ここでは自然言語で、例えば、6人分のカジュアルな日曜日のランチを主催する予定で、誰もベジタリアンではない、といった自然言語で尋ねることができます。しかし、ここのこちら側に表示する代わりに、アプリケーションログが表示されているのが見えます。これでアプリケーションが実行されているのが分かります。これはAgentic AIアプリケーションです。Strands Agents SDKを使用しており、ここでご覧いただけるように、SLMが利用可能なツールを分析し、今度はツールの使用を開始しています。メニュー要件の分析、調理時間の計算です。これらは、このSLMモデルに、このアプリケーションがSLMモデルに送信するために提供しているツールであり、最終的に組織の準備に必要なすべての情報を組み合わせるために、どのツールを使用するかを決定しています。
ここにはワインペアリングの提案もあります。もちろん、すべてのログはここで実行されており、すべての情報を組み合わせて最終的な組織計画を準備する最後の部分を処理します。繰り返しになりますが、小さなモジュールを使用してそれを処理しています。
拡大させてください。ここに、ああ、カジュアルな日曜日のランチですね。メニュー概要として、前菜、メイン、サイドがあり、6人分です。調理のタイムライン、使用するショッピングリスト、予算の内訳、ワインペアリングがあります。最終的な注意事項と、ここにあるいくつかのメトリクスを考慮しています。エージェントはエッジで実行されており、特定のドメインのためにOutpostsで実行されています。もちろん、これは単なる一般的な例ですが、組織内で自分のアプリケーションにとって何が意味があるかを考えることができます。
素晴らしいですね。それでは、Agentic AIのまとめでした。ここでお見せしたのは、比較的小さなGPUでエッジでAgentic AIを実行することが完全に可能で実現可能であるということです。SLMはシステム全体の基盤であり、アーキテクチャについて説明し、また、これらのシステムのTCOを可能な限り低く抑えることについても見てきました。
それでは全体のまとめです。エッジでSLMを実際にどのように実行するかについて、皆さんに楽しんでお聞きいただけたことを願っています。いくつかのベストプラクティスをご提供しました。より詳しく知りたい方のために、ブログやコードサンプルも公開しています。本番環境への道筋と私たちが経てきたいくつかのステップを簡単に共有し、そしてAgentic AIについてお話ししました。それでは、ご清聴ありがとうございました。何かご質問はありますでしょうか?
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion