Amazon Bedrockは、Knowledge Basesの完全管理型構成とAgentic Retrievalを提供した。完全管理型では基盤のセットアップ負担を下げ、Agentic Retrievalでは複数ステップの検索・推論を通じて必要な証拠を集める。
RAGの導入は容易になるが、検索品質の責任がなくなるわけではない。特にAgentic Retrievalでは、検索クエリ、検索回数、取得文書、費用、最終回答の関係が単純なTop-K検索より複雑になる。
何が変わったか
従来のRAGでは、ベクトルストア、埋め込み、チャンク、同期、検索パラメータを利用者が選び、単一または限定的な検索結果をモデルへ渡す構成が中心だった。
完全管理型Knowledge Basesは、基盤管理の一部をAWSへ委ねられる。Agentic Retrievalは、質問を分解し、追加検索や推論を行いながら結果をストリーミングする機能を提供する。
変更前後の差
| 項目 | 従来の単純RAG | 完全管理型＋Agentic Retrieval |
|---|---|---|
| 基盤構築 | Vector Store等を選定 | 管理負担を削減可能 |
| 検索 | 主に1回のTop-K | 複数ステップになり得る |
| クエリ | アプリが生成 | Agentが分解・追加可能 |
| コスト予測 | 比較的単純 | 検索回数・推論で変動 |
| 再現性 | 同条件で比較しやすい | 計画差を記録する必要 |
| 運用責任 | 利用者 | 利用者と管理サービスで分担 |
管理型であっても、取り込むデータ、アクセス制御、削除、評価、回答の利用判断は利用者の責任である。
誰に影響するか
- Vector DB運用を簡素化したいチーム
- 複数文書を横断する調査・比較質問を扱う
- 規程、契約、製品仕様、FAQを回答へ使う
- 取得根拠と引用が必要
- 文書の更新・削除を迅速に反映したい
- 部門・顧客ごとにアクセス制御が異なる
- 予測可能な応答時間と費用が必要
単純なFAQや単一文書検索では、Agentic Retrievalが過剰な場合もある。
必要な対応
RAGを三層に分けて設計する。
- 取得品質: 正しい文書・範囲を取れたか
- 証拠品質: 回答を支える十分な根拠か
- 生成品質: 根拠に忠実に回答したか
回答正解率だけを見ると、検索失敗をモデルの一般知識で覆い隠す。
実装・移行手順
1. データ台帳を作る
Data Source、所有者、機密区分、更新頻度、削除要件、保持期限、地域、アクセス条件を記録する。公開情報と機密情報を同じKnowledge Baseへ無条件に混在させない。
2. チャンク戦略を決める
見出し、表、条項、コード、FAQなど文書構造に合わせる。固定文字数だけで分割すると、定義と例外、表の列、契約条項が分断される。
3. Metadata Filterを設計する
テナント、部門、文書種別、有効日、地域、製品バージョンをMetadataとして保持し、検索前に権限と範囲を絞る。取得後のモデル指示だけで秘密を隠さない。
4. 単純検索とAgenticを分ける
明確なFAQや既知文書の参照は通常Retrieval、比較・調査・複数条件はAgentic Retrievalへ振り分ける。すべてを高機能経路へ流さない。
5. Retrieval Traceを保存する
質問、分解クエリ、取得文書ID、Chunk ID、スコア、Filter、検索回数、引用、最終回答、モデル、設定を保存する。本文全体のログはデータ方針へ従う。
6. 削除・更新を試験する
元文書を削除または更新した後、Knowledge Baseから検索されなくなるまでの時間を測る。削除要求をData Sourceだけで完了扱いにしない。
失敗しやすい点
- 管理型だからデータ品質や権限設計が不要と考える
- Agentic Retrievalを全質問へ常時適用する
- 引用があるだけで回答が正しいと判断する
- 旧版と新版を有効日Filterなしで混在させる
- アクセス制御を生成後の表示制御だけで行う
引用文書が質問と無関係、古い、権限外、回答主張を支持していない場合がある。Citation Entailmentを評価する。
評価方法
- Recall@K、Precision@K
- 正答根拠がTop-Kへ含まれる率
- 引用が回答主張を支持する率
- 権限外Chunk取得件数
- 旧版文書の混入率
- 削除反映時間
- Agentic検索回数分布
- P50・P95応答時間
- 質問当たり費用
- 「根拠不足」と正しく回答できる率
- 単純検索とAgenticの改善差
- 文書更新前後の回帰試験結果
評価セットは、答えがある質問だけでなく、情報不足、矛盾、権限外、期限切れを含める。
ロールバック
Agentic Retrievalで不安定化した場合、質問分類Feature Flagを使い、通常Retrievalへ戻す。完全管理型基盤自体から戻す場合は、データExport、Embedding再生成、Index構築、Cutoverが必要になる。
- Agentic経路への新規流入を停止する
- 読み取り専用の通常Retrievalへ切り替える
- 直近の誤回答と取得Traceを確認する
- 更新・削除同期を継続する
- 問題クエリを評価セットへ追加する
- 限定用途から再開する
異なるVector Storeへ戻す可能性があるなら、原文、Metadata、Chunk生成コードを自社管理下に保持する。
編集部分析
完全管理型Knowledge Basesは、インフラの差別化価値が低い組織にとって有力である。Vector DBの選定・保守より、文書ガバナンスと評価へ人員を集中できる。
一方、Agentic Retrievalは検索を賢くする代わりに、検索プロセスを動的にする。結果だけを保存する運用では、なぜその文書を選び、何回検索し、どの費用が発生したか説明できない。
高品質なRAGは、モデル性能よりも、正しいデータ境界、更新・削除、検索前認可、根拠評価で決まる。管理型サービスの採用後ほど、これらの統制を明示すべきである。
実務チェックリスト
- [ ] Data Sourceの所有者と機密区分を記録した
- [ ] 文書構造に合うChunk戦略を試験した
- [ ] テナント・部門・版・有効日をMetadataへ入れた
- [ ] 検索前に権限Filterを適用した
- [ ] 単純検索とAgentic Retrievalを用途分けした
- [ ] 分解クエリと取得ChunkをTraceへ保存した
- [ ] 引用が主張を支持するか評価した
- [ ] 更新・削除の反映時間を測定した
- [ ] 情報不足時に回答を控える試験を行った
- [ ] 他基盤へ戻せる原文・Metadata・Chunk処理を保持した