RAGを中心とした生成AIデータ活用実践ガイド
〜コンテキスト強化から基盤設計まで：技術者向け包括的解説〜
講演者
高野氏（AWSジャパン）
ソリューションアーキテクト
セッション情報
時間: 40分
レベル: 300（技術詳細）
講演概要
RAG（Retrieval-Augmented Generation：検索拡張生成）を中心とした生成AIにおけるデータ活用について、 技術的詳細から実装までを体系的に解説した講演です。 自動車保険の具体的ユースケースを通じて、コンテキストの種類から高度な検索手法、 そしてスケーラブルなデータ基盤設計まで、実際のシステム構築に必要な知識が包括的に提供されました。
対象内容
技術メインの詳細内容（レベル300）
対象外
ファインチューニング・モデル学習
RAGにおける2つのコンテキストの重要性
🚗 具体的ユースケース：自動車保険チャットボット
ユーザー設定
- • パット（新車購入者）
- • 旧車は売却済み
- • 新車用保険が必要
ユーザーニーズ
- • 料金比較
- • 補償内容検討
- • パーソナライズ見積
解決課題
- • 汎用的回答の限界
- • 個別最適化の必要性
- • 適切なコンテキスト提供
RAGで必要な2種類のコンテキスト
1状況コンテキスト
定義
ユーザーの人物、現在の状況、事実についての情報
パット例
- • 運転履歴、車両スペック
- • 居住地、家族構成
- • 過去の保険履歴
データソース
既存データベース（RDB）に構造化保存
2セマンティックコンテキスト
定義
質問や事実に関連する類似情報、意味を与える情報
パット例
- • 保険法律・規則
- • 保険請求情報
- • 業界ベストプラクティス
データソース
ベクトル変換後、ベクトルDBに保存
拡張プロンプトの4要素構成
基盤モデル指示
システムプロンプト
状況コンテキスト
ユーザー固有事実情報
セマンティックコンテキスト
関連類似情報
ユーザー質問
実際のクエリ
RAGの3段階進化アプローチ
1Naive RAG：全ての基礎となる手法
特徴
- • 質問→ベクトルDB検索→回答
- • シンプルで実装容易
- • 技術選定の基礎となる
適用場面
- • 個人差によらず同様回答でOK
- • パット・テリー等誰でも同じ
- • 基本的な情報提供システム
制限事項
- • データニュアンス捉えられない
- • パーソナライゼーション不足
- • 例：「保険料200-5,000ドル」
2Advanced RAG：複数検索手法の組み合わせ
3つの処理段階
検索前処理
質問のカスタマイズ・リライティング
コンテキスト検索
高度な検索手法適用
検索後処理
フィルタリング・リランキング・要約
主要テクニック
A. ハイブリッド検索
B. グラフRAG
C. 自然言語→SQL変換
3Modular RAG：自動化されたオーケストレーション
概念
- • 複数ナレッジベース・処理手法のモジュール化
- • 最適なタイミング・順番での自動実行
- • ユーザー体験の最大化
技術基盤
- • Amazon Bedrock Agentsによる自動オーケストレーション
- • 複数データソース・サービスの統合呼び出し
- • ユーザー入力からの自動判断・実行
データ基盤設計の実践指針
データソースの分類と処理方針
構造化データ
特性: 定義されたスキーマで管理
処理: 従来のデータベースクエリ
RAG統合: SQL→自然言語変換での活用
半構造化データ
特性: JSON、XML等のスキーマ可変形式
処理: 時系列変化に対応した柔軟な管理
RAG統合: 必要に応じてベクトル化
非構造化データ
特性: 文書、画像等の意味抽出が必要
処理: 埋め込みモデルによるベクトル化必須
RAG統合: ベクトルデータベースでの類似検索
チャンキング（分割）戦略の選択
1. 固定長チャンキング
PoC推奨2. 階層的チャンキング
Bedrock対応3. セマンティックチャンキング
高精度ベクトルデータベース選択基準
主要選択基準
- 1. 馴染みやすさ・実装しやすさ（最優先）
- 2. 特定ユースケース要件（グラフRAG、ハイブリッド検索等）
- 3. スケーラビリティ・パフォーマンス
AWS推奨サービス
- • Neptune Analytics: グラフRAG特化
- • OpenSearch: ハイブリッド検索特化
- • その他: 馴染みのあるDBサービス
データ基盤設計5つのベストプラクティス
疎結合アーキテクチャ
データ保存層とデータ処理層の分離
💡 部分変更・再利用の容易性確保
適切なツール選択
データ鮮度・レイテンシ要件に応じた技術選定
💡 リアルタイム：ストリーミング、バッチ：データウェアハウス
マネージドサービス活用
クラスター管理・運用をAWSに委任
💡 アプリケーション開発・UX向上に集中
ログ中心データデザイン
全データをイミュータブルログとしてデータレイクに保存
💡 バグ・不具合時の復旧可能性確保
コスト意識の徹底
設計段階での必ずコスト見積もり実施
💡 予想外の高コスト時は技術選択・要件の見直し
データガバナンスの実装
主要課題と対応策
主要課題
- • データの散在・重複
複数部署でのデータ管理による不整合 - • リネージ追跡困難
データの出所・変更履歴が不明 - • 品質管理不足
データクオリティの継続監視不備 - • アクセス制御複雑化
適切な権限管理の困難さ
ソリューション
- • Amazon SageMaker Data Wrangler Catalog
データカタログ化による統合管理 - • AWS Glue Data Quality
宣言的ルール記述による品質チェック - • Amazon SageMaker
データ系譜の可視化・トレーサビリティ - • IAM・リソースベースポリシー
きめ細かいアクセス制御
統合ガバナンスアプローチ
アクセス制御
- • 部署別データ管理維持
- • 許可ベースアクセス
- • カタログ統合管理
品質管理
- • SQLベース複雑ルール
- • 自動チェック実行
- • 継続的品質監視
コンプライアンス
- • 法規制要件自動チェック
- • ビジネスルール適合確認
- • 監査ログ自動生成
組織のAI活用戦略への応用ポイント
RAG実装の段階的アプローチ
段階的実装ロードマップ
Phase 1: Naive RAG
技術選定・基本機能検証
Phase 2: Advanced RAG
高度検索手法・精度向上
Phase 3: Modular RAG
完全自動化・UX最大化
データ活用戦略の実践指針
- 「全データのベクトル化は不要」の原則
- • 既存データベースの直接活用
- • SQL変換による効率的データ取得
- • ベクトル化コスト・管理負荷の最適化
技術選択の優先順位
- 1. 馴染みやすさ: 実装経験・チーム習熟度
- 2. 要件適合性: 特定ユースケース要求仕様
- 3. スケーラビリティ: 将来拡張性・パフォーマンス
組織実装時の考慮事項
技術面
- • 段階的進化によるリスク軽減
- • 既存システム統合性確保
- • コスト予測・管理の徹底
組織面
- • ドメイン知識者の巻き込み
- • データガバナンス体制構築
- • 部門横断データ活用合意
継続改善
- • 自動化による運用負荷軽減
- • ユーザー価値提供への集中
- • 定期的技術・コスト見直し
まとめ：RAG実装成功のための行動指針
高野氏が示す実践的アプローチ
1. 段階的発展の重要性
「RAGはNaive RAGから始めて、段階的に発展させていきましょう」
実装順序: 基礎技術確立（Naive RAG）→ 精度向上（Advanced RAG）→ 完全自動化（Modular RAG）
2. データ活用の効率化
「データは別に全部ベクトル化しなくてもいいです。今あるデータを利用して、生成AIアプリケーションに使うことができます」
実装方針: 既存データベース直接活用・必要最小限のベクトル化・SQL変換による効率的データ取得
3. 自動化への投資
「RAGのパイプラインは出来る限り自動化していきましょう。ユーザーに価値を届けるところとは関係ないところはもう出来る限り自動化する」
自動化対象: データ収集・前処理パイプライン、品質チェック・ガバナンス、オーケストレーション・意思決定
RAG実装で得られるビジネス価値
ユーザー体験向上
- • パーソナライズ高精度応答
- • やり取り回数削減
- • リアルタイム対応
組織運営効率化
- • 既存データ資産有効活用
- • 部門横断データ統合
- • 人的リソース最適配置
技術的優位性確立
- • 段階的進化による技術蓄積
- • スケーラブル将来対応
- • ガバナンス基盤安全性
「コンテキストを提供するために最適なデータアーキテクチャーをちゃんと考えて、
ユーザーに価値を届けることに集中しましょう」