AIPテスト、検証、トラブルシューティング
テクノロジー企業が Amazon Bedrock Knowledge Bases（バックエンドは OpenSearch Serverless）を使った社内ナレッジベース検索システムを構築しました。本番稼働後、ユーザーから「質問に関連するドキュメントが明らかに存在するのに検索結果として返ってこない」という報告が相次いでいます。チームはこの取得品質の問題を定量的に診断し、チャンキング戦略や埋め込みモデルの改善効果を数値で比較できる仕組みを整えたいと考えています。最も適切なアプローチはどれですか？
A本番ユーザーのネガティブフィードバックを DynamoDB に収集し、週次バッチで問題クエリをレポート化してレビューチームが改善方針を検討するサイクルを回す。取得品質の定量評価は行えない
週次フィードバック収集は問題の存在を確認できるが取得品質を定量化できず、どのクエリがなぜ失敗しているか（埋め込みモデル・チャンキング・インデックス設定）の根本原因特定手段にならない。改善効果の数値比較も不可能。
BBedrock Knowledge Bases の Retrieve API でクエリごとの取得チャンクとスコアを抽出し、既知の正解チャンクを含むゴールデンデータセットで Recall@K・MRR などの品質メトリクスを計測して定量評価する
✓ 正解
Retrieve API でゴールデンデータセットに対する Recall@K・MRR を計測することで、取得ステップを生成ステップから切り離して独立評価できる。チャンキングや埋め込みモデルの変更効果を数値で比較でき、定量的な診断と改善サイクルの基盤となる正しいアプローチ。
CAmazon CloudWatch の KnowledgeBase メトリクスを分析し、RetrieverLatency が基準値を超えたタイミングで OpenSearch Serverless のキャパシティを増強して取得速度と品質を改善する
RetrieverLatency はスループットや応答速度の指標であり、関連チャンクが取得されないという取得精度の問題とは異なる評価軸。キャパシティを増強しても取得される文書の関連性スコアや順位は改善しない。
DS3 バケットのソースドキュメントをすべて削除して再インジェストし、同期完了後に本番トラフィックを使って取得結果の改善を経験的に確認することで問題の解消を試みる。原因診断は行わない
原因を特定せずに全件再インジェストする方法はインデックス破損などの物理的問題には有効だが、埋め込みモデルやチャンキング設定に起因する品質問題は再インジェストでは解消されない。診断なしの試行錯誤は非効率で定量的評価にもならない。
解説
Bedrock Knowledge Bases の Retrieve API は、生成ステップを省略して取得ステップのみを独立して実行できる API です。このAPIを使ってゴールデンデータセット（クエリと期待される正解チャンクのペア）を評価することで、Recall@K（上位K件に正解チャンクが含まれる割合）や MRR（Mean Reciprocal Rank）を算出できます。これにより、チャンキング戦略・埋め込みモデル・インデックス設定のどこに問題があるかを定量的に特定し、設定変更の効果を数値で比較しながら改善サイクルを回せます。
選択肢AのDynamoDB 週次フィードバックは問題の存在を確認できるが、取得品質を定量化できず根本原因（埋め込みモデル？チャンキング？）の特定にも役立たない。
選択肢CのRetrieverLatency 監視とスケーリングは、レイテンシ問題への対策としては有効だが、今回の問題は速度ではなく取得精度（関連チャンクが返ってこない）であるため対処法が合致していない。
選択肢Dの全件削除・再インジェストはインデックス破損の修復には有効だが、原因を診断せずに試行錯誤するアプローチであり、埋め込みモデルやチャンキング設定に起因する品質問題は再インジェストでは解消されない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →