あるEC事業者がAmazon Bedrockを用いた製品サポートチャットボットを本番運用している。Amazon Bedrock Knowledge Bases（ベクターストア：OpenSearch Serverless）でS3上の製品マニュアルを取り込み、Claude 3 Sonnetで回答生成するRAGアーキテクチャを採用している。数週間後、Amazon Bedrock Model Evaluationで評価したところ、以下の結果が得られた： ・Context Recall: 0.91 ・Context Precision: 0.88 ・Faithfulness: 0.57 検索精度（Context RecallとContext Precision）は高水準だが、Faithfulnessが著しく低く、回答が取得コンテキストと矛盾する事例が多発していた。このメトリクスパターンが示す根本原因と最も効果的な対策はどれか。
FaithfulnessはRAGASの評価指標の一つで「モデルの回答が取得コンテキストにどれだけ忠実か」を測定する。Context RecallとContext Precisionが共に高水準にもかかわらずFaithfulnessのみ低い場合、検索パイプラインは正常に機能しており問題は生成フェーズにある。基盤モデルが取得コンテキストを無視して事前学習知識から回答を補完・創作するハルシネーションが発生している状態である。 最も効果的な対策は2段階のアプローチである。 ①システムプロンプトで「提供されたコンテキストのみに基づいて回答し、コンテキストにない情報は含めないこと」と明示する。 ②Bedrock GuardrailsのContextual Grounding Checkを有効化する。このポリシーはモデルの回答を取得ソース文書と比較し、根拠スコアが閾値を下回る回答を自動的にブロックするRAG特化のセーフガードである。 選択肢Aのチャンキング戦略の見直しはContext PrecisionやContext Recallが低い場合に有効な対策であり、両指標が高い本ケースには適合しない。 選択肢CのOpenSearch ServerlessからAurora PostgreSQL pgvectorへの移行は検索インフラ変更であり、Context metricsが高水準を示す本シナリオでは根本原因に対応しない。 選択肢Dの埋め込みモデルの変更はContext Recallが低い場合（関連チャンクを取りこぼす場合）に有効であり、Recall 0.91の本ケースには不適切である。