AIPテスト、検証、トラブルシューティング
ある製造業企業が、Amazon Bedrock Knowledge Bases と OpenSearch Serverless を使って製品マニュアル（設置・保守手順書）を対象とした QA システムを構築しました。デフォルトの固定サイズチャンキング（500トークン）を使用しています。「製品Xの設置手順の全体的な流れを教えて」という質問に対し、ベクター検索では正しいページのチャンクがヒットしているにもかかわらず、手順の前半または後半しか回答に含まれないケースが頻発しています。調査で取得チャンクに前後の手順コンテキストが含まれていないことが根本原因と特定されました。最小限の再構成でこの問題を解決するには、どのアプローチが最も効果的ですか？
AKnowledge Bases の階層的チャンキング（Hierarchical Chunking）を有効にし、大きな親チャンクで文脈を保持しながら子チャンクで精密な検索を実現する
✓ 正解
Amazon Bedrock Knowledge Bases の Hierarchical Chunking は、細かい子チャンクでベクター検索精度を維持しながら、取得後に対応する親チャンク（大きな文脈ブロック）を応答コンテキストとして返す二層構造です。「ヒットはするが前後の手順が欠ける」という症状を構造的に解消でき、最小限の変更で文脈完全性を実現できます。
Bチャンクサイズを2000トークンに拡大して200トークンのオーバーラップを設定し、手順全体が同一チャンクに収まるよう Knowledge Bases を再インデックス化する
Knowledge Bases の固定サイズチャンキングにおけるサイズ拡大は、文脈を増やす一方で無関係な内容が同一チャンクに混入するリスクが高まります。Hierarchical Chunking のように検索精度を犠牲にせず文脈を拡張する構造とは異なり、精度と文脈の両立が困難であるため根本解決になりません。
C取得チャンク数（numberOfResults）を5から20に増やして、手順の前後チャンクもプロンプトコンテキストに含められるようにする
Knowledge Bases の numberOfResults パラメーター増加は、より多くのチャンクをコンテキストに含められますが、コンテキストウィンドウ消費の増大とノイズ混入という副作用があります。チャンクの構造的な文脈断絶を根本から解消するアプローチではなく、対症療法に留まります。
D埋め込みモデルを Amazon Titan Embeddings V2 から Cohere Embed Multilingual v3 に変更し、文脈依存の意味類似度計算の精度を向上させる
Cohere Embed Multilingual v3 への埋め込みモデル変更は多言語ドキュメントの意味類似度計算を改善しますが、今回の問題はベクター検索のヒット精度ではなく取得チャンクの文脈完全性にあります。モデル変更では手順前後の断絶という構造的な問題に対処できません。
解説
Amazon Bedrock Knowledge Bases の階層的チャンキング（Hierarchical Chunking）は、細粒度の子チャンクで高精度なベクター検索を行い、取得後に対応する大きな親チャンクを応答コンテキストとして返す二層構造です。「ベクター検索は正しいチャンクをヒットするが前後の手順が欠ける」という症状は典型的な文脈断絶の問題であり、Hierarchical Chunking によって検索精度と文脈完全性を両立できます。
選択肢Bの固定サイズチャンキング拡大は、全チャンクを画一的に大きくするため無関係なコンテンツが混入して検索精度が低下するリスクがあり、構造的な文脈断絶の根本解決にはなりません。
選択肢CのnumberOfResults増加は、コンテキストウィンドウ消費の増大とノイズ混入という副作用があり、チャンクの構造的問題を解消するアプローチではありません。
選択肢Dの埋め込みモデル変更は意味類似度の計算改善に寄与しますが、チャンクの文脈断絶という根本原因には対処できません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →