AIP基盤モデルの統合、データ管理、コンプライアンス
金融サービス企業が、Amazon Bedrock Knowledge Bases を使用した社内規制文書検索システムを構築しています。対象文書は平均80ページの規制マニュアルで、章・節・条項の階層構造を持ち、各条項は相互参照を多数含む複雑な構成です。現在、固定サイズチャンキング（512トークン、オーバーラップ10%）を採用していますが、条項の途中でチャンクが分割されるため、「特定の条項が定める要件は何か」という質問への検索精度が低い状態です。追加のデータ処理パイプライン構築コストを最小化しながら検索精度を最大化するには、どのアーキテクチャ変更が最も効果的ですか？
ABedrock Knowledge Bases の階層チャンキング（Hierarchical Chunking）を採用し、親チャンクを章・節レベル、子チャンクを条項レベルで設定する。検索時は子チャンクで精密にマッチングし、応答生成時に親チャンクのコンテキストも含めて返す構成にする。
✓ 正解
Bedrock Knowledge Bases ネイティブの階層チャンキングは、子チャンクで精密検索・親チャンクでコンテキスト補完を実現し、追加インフラ不要で条項境界の分断問題を解消する。精度最大化とコスト最小化を同時に満たす最適なアーキテクチャ変更。
BAmazon Comprehend でエンティティ認識を前処理に組み込み、条項番号や相互参照を抽出してメタデータとして付与したうえで、固定サイズチャンキングのトークン数を2048に拡大して条項全体を1チャンクに収める構成にする。
Comprehend によるエンティティ認識はメタデータ付与に有効だが、チャンク境界で条項が切断される根本問題を解決しない。トークン数を2048に拡大しても文書階層に沿った境界設定にはならず、前処理の追加コストも発生するため不適切。
CAWS Glue と Lambda を使ったPDF構造解析パイプラインを構築し、章・節の見出しを境界として論理チャンクを生成するカスタムデータソース変換を実装し、生成チャンクをS3経由でKnowledge Basesに取り込む構成にする。
Glue と Lambda によるカスタムパイプラインは章・節見出しを基準とした論理チャンク生成が可能で精度向上が見込めるが、設計・実装・運用コストが大きい。「追加のデータ処理パイプライン構築コストを最小化する」という要件に反するため不適切。
DBedrock Knowledge Bases のセマンティックチャンキングに切り替え、チャンクサイズ上限を1024トークンに設定する。同時に埋め込みモデルをAmazon Titan Embeddings V2 に変更して規制ドメインの意味的精度を向上させる構成にする。
セマンティックチャンキングは意味境界でチャンクを分割するため固定サイズよりも条項の分断が減るが、親チャンクによるコンテキスト補完機能を持たない。規制文書の階層的な構造への対応力は階層チャンキングに劣り、最善策ではない。
解説
Amazon Bedrock Knowledge Bases の階層チャンキング（Hierarchical Chunking）は、文書を大きな親チャンクと小さな子チャンクの2層構造でインデックス化するネイティブ機能です。
検索（Retrieval）フェーズでは粒度の細かい子チャンクを用いて条項レベルの精密なベクター検索を行い、応答生成（Generation）フェーズでは対応する親チャンク（章・節全体）もコンテキストとして言語モデルに渡します。これにより、条項の境界切断問題を追加インフラなしに解決できます。
Glue・Comprehend などの外部パイプラインを構築するコストが発生しない点が、「精度最大化・コスト最小化」の要件を同時に満たす決め手です。
選択肢BのAmazon Comprehendは自然言語のエンティティ認識に有用ですが、チャンク境界で条項が切断される根本問題を解決せず、前処理コストも別途発生するため要件を満たさない。
選択肢CのAWS Glue + Lambdaによるカスタムパイプラインは構造解析の自由度が高い一方で実装・維持コストが大きく、「コスト最小化」の要件に反する。
選択肢Dのセマンティックチャンキングは意味境界で分割するため固定サイズより改善されるが、親チャンクによるコンテキスト補完機能を持たず、階層的な文書構造への対応力は階層チャンキングに劣る。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →