当日の動き
昨年も雨でしたが、今年も雨模様でした...☔️
- 8:45 海浜幕張駅到着☔️
- 9:00 改札前のパン屋さんで朝食☕️
- 9:15 会場到着（基調講演の指定席券はなくなっていたのでサテライト会場で待機）
- 10:00〜11:00 基調講演（途中で離席し、自社のブースへ）
- 11:30 弁当引き換え
- 11:50〜12:30 セッション『実践的な生成 AI 活用の推進: PoC から価値創出へ』
- 12:50〜13:30 セッション『生成 AI のためのデータ活用実践ガイド』
- 13:50〜14:30 セッション『企業内に分散したデータの分析と AI 活用を推進する：AWS で実現するデータ活用の民主化』
- 14:50〜16:50 社内mtgに出たり、各ブース徘徊したり🚶
- 16:50〜17:20 セッション『エンタープライズ AI の未来：プライベート LLM × Amazon Bedrock で実現する AI エージェント開発』
- 17:20〜18:00 ブース徘徊し、QuizKnockをチラッとみて退散
昨年は半日ほどの滞在でしたが、今年は終日参加でき楽しめました👏
総歩数は1万5千歩ほどでした。
自社のブースがあると嬉しいですね！
Tips
先にAWS Summitを楽しむためのTipsをいくつかご紹介します。
- セッションはすぐ埋まるため事前登録とセッションの予約は早めに行う
- セッションが埋まっていても当日キャンセルが出ることがあるので、定期的にサイトを確認する
- 基調講演の座席券やお弁当無料券が欲しい場合は早めに会場に行く（上記時間を参考にしてください。ご飯食べるところは少ないor遠いのでゲットしておくと吉）
- 飲み物は会場内で入手可能なので無理に駅などで買わなくても良い（ブースでもらえることも）
- 面白いブースも多いのでセッションは詰め込みすぎない
- 会場は広く、いっぱい歩いたり立ちっぱなしになるので、歩きやすい靴で行くことをおすすめします
- 充電ブースは数箇所ありますが、混雑していることが多いのでモバイルバッテリーを持参するがおすすめです
- 会場内Wi-Fiには期待せず、テザリングやモバイルルーターを持参するのが良いです
全体的な所感
- 昨年より人が多い印象
- 多くのブースで生成AI関連の内容が目立つ
- Anthropicのブースが大人気すぎていつ見ても人だかり
- 昨年参加した際の経験を踏まえ、今年はうまく立ち回ることができた
『生成AIのためのデータ活用実践ガイド』
いくつかセッションを見ましたが、今回はその中から『生成AIのためのデータ活用実践ガイド』というセッションについてまとめます。
- ゴール：RAGを中心に自社・お客様のデータを生成AIをどう組み込むのか、考え方、設計、実装のヒントを得る
セッションでは自動車保険を検討しているPatさんの例の紹介がありました。
- Patはネバタ州に住んでいて、新しい⾞を購⼊しました。
- その⾞は、Pat が所有する3台⽬の⾞となり、それに伴い、以前の⾞を売却しました。
- Pat は⾃動⾞保険が必要です。
- Pat は、⾃動⾞保険の料⾦と補償範囲を⽐較したいと考えています。
例えばPatさんが「自動車保険に興味があります」と質問しても、基盤モデルでは一般的な回答しかできません。
しかし、Patさんの運転履歴や車両情報、規制といった「所有するデータ」と連携させる（RAG）ことで、基盤モデルは「Patさんに適した地域の自動車保険料率のリスト」を提示できるようになります。
RAGで重要なコンテキスト
RAGにおいて最も重要なのがコンテキストです。
-
状況コンテキスト
- ユーザーの状況に関する事実情報です。場所、運転履歴、車のスペックなどデータストアにある構造化データがこれに当たります
-
セマンティックコンテキスト
- 事実に類似するより広範な情報です。検索で得られる自動車保険の規制情報や、車の写真、アップロードされた請求書などのベクトルデータベースにある非構造化データがこれに当たります
これらのコンテキストを基盤モデルに渡すための器が「拡張プロンプト」です。拡張プロンプトは、以下の4つの要素で構成されます。
- 基盤モデルへの指示（システムプロンプト）: モデルに「あなたは保険会社の会話エージェントです」といった役割を与える
- 状況コンテキスト: ユーザーの基本情報（Patさんはネバダ州に住んでいる、など）を伝える
- セマンティックコンテキスト: ユーザーの質問に関連する情報（自動車保険に関する法規制など）を伝える
- ユーザー入力: ユーザーからの質問（「自動車保険に興味があります」）をそのまま渡す
これらの情報をプロンプトに盛り込むことで、基盤モデルはより具体的で有用な回答を生成できるようになるということです。
基本のシステムアーキテクチャ
- ユーザーが質問を入力
- プロンプトテンプレートリポジトリからプロンプトテンプレートを取得（※アプリに組み込まれてない場合）
- 企業内のデータベースから状況コンテキストを取得
- 埋め込みモデルを使用してユーザー入力のベクトルを作成
- ベクトル検索を実行してセマンティックコンテキストを取得
- 生成AIモデルへ「拡張プロンプト」を送信し回答を取得
（注: データベースサービスは例として記載しています。他のオプションも利⽤可能です。）
RAGにおける応答精度を⾼めるテクニック
RAG手法は「Naive RAG」「Advanced RAG」「Modular RAG」という3つのパラダイムに分かれ、これまで進化してきました。
1. Naive RAG (ナイーブRAG)
- 最も基本的なRAGのやり方。実装が簡単なのでまずはここから
- 開発フレームワークや基盤モデル、データベースといった技術選定に重点を置く
Naive RAGにはトレードオフがあり、データ取得フローがシンプルで始めやすい反面、データの微妙な関係性やニュアンスを捉えきれない場合があります。
例えば、上記の例で言うと「Patさんが既に車を売却したにもかかわらず、別の所有者となった車の事故データが反映されてしまうことで不正確な情報に基づいて回答してしまう」といったケースです。
2. Advanced RAG (アドバンストRAG)
Advanced RAGは、検索方法を組み合わせ検索の前後にタスクを追加することでより高精度な回答を目指す手法です。
- ユーザー質問
- 検索の前処理: ガードレール、テキストtoSQL、リライティング（LLM経由）など
- コンテキスト検索
- 検索の後処理: ガードレール、リランキング、サマライゼーション（LLM経由）など
Advanced RAGの具体的な手法としては、ベクトル検索と全文（キーワード）検索を組み合わせる「ハイブリッド検索」や、データの関係性をグラフ構造で捉える「GraphRAG」などが挙げられます。
-
ハイブリッド検索
- コンテンツ生成、要約、感情分析など正確な類似コンテキストを必要とする質問（明示的な事実）で活用
-
GraphRAG
- 「この事故記録はPatが車を売却した後に発生したものだ」といった、必ずしも意味的に類似していなくても 関連するコンテキスト（暗黙の事実） を推論するのに役立つ
セッションでは、これらNaive RAGとAdvanced RAGを組み合わせる方法としてAmazon Bedrock Agentsを使った例が紹介されました。
Amazon Bedrock Agentsは、基盤モデルを活用してユーザーの質問に対して適切なアクションを選択し、実行することができます。
Naive RAG と Advanced RAG の使い分け
| Naive RAG | Advanced RAG |
|---|---|
| ・個別判断が不要 ・既存の状況から事実を取り出す ・事実に基づく回答は状況コンテキストとは無関係（誰でも同じ回答になる） |
・コストはかかるがよりパーソナライズした回答が可能 ・追加のコンテキストまたは推論を提供 ・意味のある検索をするために情報や処理を追加する |
3. Modular RAG (モジュラーRAG)
- 「意思決定エンジン」がユーザーの質問に応じて最適なRAG手法を自動で選んでくれるというもの
- 複数のナレッジベースを使い分けることもできる
- Naive RAGではうまく行かない場合や、Advanced RAGの手法を固定で使っても効果が出ない場合に検討すると良い
セッションでは、これを実現する方法としてAmazon Bedrock Agentsを使って「コンテキスト指向」や「タスク指向」のアクションをオーケストレーションする例が紹介されていました。
データの種類とデータ基盤の考え方
RAGで活用するデータは、既存のデータベースの「構造化データ」、JSON/XMLのような「半構造化データ」、そしてドキュメントや画像などの「非構造化データ」といった種類があります。
特に非構造化データを利用する場合は以下のステップが必要になります。
-
① ドキュメントのチャンク化
- PDFなどを意味のある塊（チャンク）に分割
- チャンキング方法には、固定長、構造ベース、階層的、セマンティックなどがある。固定長は実装が容易だが、コンテキストが失われやすいというトレードオフがある
- チャンクのサイズはタスクによって調整が必要。Q&Aタスクのような簡単なタスクには小さく（200トークン以下）、テキスト要約やコード解析のような複雑なタスクには大きく（2000トークン以上）するのが良い
-
② 埋め込みモデルでのベクトル化
- チャンクを「埋め込みモデル」でベクトルに変換
-
③ ベクトルデータベースへの蓄積とインデクシング
- 生成したベクトルを「ベクトルデータベース」に保存
- ベクトルデータベースの選定については、馴染みやすさ、実装の容易さ、スケーラビリティ、パフォーマンスなどを基準に検討
- AWSのサービスでは、Amazon Aurora、Amazon OpenSearch Service、Amazon DocumentDBなどが利用可能
また、ビッグデータ基盤のベストプラクティスとして以下の点が挙げられていました。
- 疎結合なシステムを構築する（データ→保存→処理→保存→分析→回答）
- データ構造やレイテンシーに応じて適切なツールを選ぶ
- マネージドサービスやサーバーレスサービスを活用する
- ログ中心のデザインパターンを使用する
- コストを意識する（ビッグデータだからと言って必ずしもコストが大きくなるわけではない）
データ共有とガバナンス
データの利活用においてはデータガバナンスも非常に重要です。
データの出所や流れを追跡するリネージやデータの鮮度はRAGの回答精度に直結します。
AWS Glueのデータ品質定義言語である DQDL(Data Quality Definition Language) を使うことでデータ品質ルールを定義し、データの品質を担保することができると知りました。
まとめ
RAGにおいてどのようなコンテキストが存在し、それをどのように基盤モデルに渡すかを理解することがまずは重要に感じました。
また、データを活用するだけでなく、データの品質やガバナンスもRAGの精度に大きく影響すると理解できたので、今後のプロジェクトでも意識していきたいと思います！
Discussion