基盤モデルの統合、データ管理、コンプライアンス
Foundation Model Integration, Data Management, and Compliance
学習目標
- 業務の要件と制約から、FM・統合のパターン・デプロイの方法を選び、Bedrock で PoC を作り、Well-Architected の生成 AI レンズで設計をそろえられる
- FM をベンチマークと評価で選び、コードを変えずにモデルや提供元を切り替える構成（AppConfig・Lambda・API Gateway）と、クロスリージョン推論・サーキットブレーカーによる回復力を設計できる
- FM に渡すデータの検証と処理（Glue Data Quality・マルチモーダル・会話の形式）を作り、ベクトルストア（OpenSearch・Aurora pgvector・S3 Vectors・Bedrock ナレッジベース）とメタデータ・更新の仕組みを設計できる
- チャンク分割・埋め込み・ハイブリッド検索・リランク・クエリの拡張で検索を設計し、プロンプト管理・テンプレート・ガードレール・プロンプトフローでプロンプトを統制できる
要点
- 設計の進め方：要件（品質・遅延・費用・データの所在・規制）を先に決め、小さな PoC で Bedrock の複数のモデルを評価してから本番の設計に進む。共通の部品（プロンプトのテンプレート・ガードレール・ログ）を標準化する。
- モデルの切り替え：モデルの ID やパラメータをコードに埋め込まず、AWS AppConfig などの設定で管理する。Converse API はモデルの間で共通の形式で呼べる。
- 回復力：クロスリージョン推論でリージョンの容量の不足やスロットリングに備え、Step Functions のリトライとサーキットブレーカー、小さなモデルへの切り替えなどの段階的な縮退を設計する。
- カスタマイズ：まずプロンプトと RAG。足りなければファインチューニング（LoRA などのパラメータ効率の良い方法）や蒸留。カスタムモデルはバージョンを管理し、失敗したら戻せるようにする。
- データの処理：FM に渡す前に品質を検証（Glue Data Quality・Lambda）し、画像・音声・表を処理（Transcribe・Bedrock Data Automation・マルチモーダルのモデル）する。会話は役割（user・assistant）の形式で渡す。
- ベクトルストア：ハイブリッド検索や大規模なら OpenSearch、既存の PostgreSQL なら Aurora・RDS の pgvector、安く大量に保存するなら S3 Vectors。メタデータ（日付・作成者・分類）で検索を絞り込む。文書の変更は差分の同期で反映する。
- 検索の設計：チャンク分割（固定・階層・セマンティック・独自の Lambda）、埋め込みのモデルと次元、ハイブリッド検索、リランク、クエリの書き換えと分解。
- プロンプト：システムプロンプトで役割と制約を決め、Bedrock のプロンプト管理でテンプレートとバージョンを管理し、承認と監査を行う。複雑なタスクは手順に分け、Prompt Flows で順番や分岐を組む。
業務での使いどころ
- 営業提案書のアシスタントで、モデルを月ごとに比べて切り替えたい。モデルの ID を AppConfig で管理し、Converse API で呼ぶので、コードを変えずに新しいモデルに切り替えられる。
- 総務社内規程の RAG で、改定前の古い規程が回答に混ざる。文書に施行日のメタデータを付けて検索で絞り込み、S3 の変更をきっかけにナレッジベースの同期を自動で実行する。
- 経理請求書の画像と表を FM で読み取る前に、Lambda で金額や日付の形式を検証し、欠けている項目がある請求書は担当者の確認に回す。
公式のタスクステートメント（英語）
- 1.1 要件を分析し、GenAI ソリューションを設計する。
- 1.2 FM を選定して設定する。
- 1.3 FM 消費のためのデータ検証と処理パイプラインを実装する。
- 1.4 ベクトルストアソリューションを設計して実装する。
- 1.5 FM 拡張のための検索メカニズムを設計する。
- 1.6 FM インタラクションのためのプロンプトエンジニアリング戦略とガバナンスを実施する。