RAGの「PoC止まり」を突破する機能拡張
AIテックメディア編集部です。生成AIの導入において、RAG（検索拡張生成）はもはや標準的なアーキテクチャとなりました。しかし、多くの現場で耳にするのは「デモでは動いたが、実務データを入れると回答精度が下がる」「社内ドキュメントのアクセス権限管理（ACL）が複雑すぎて実装できない」という嘆きです。
今回、AWSのフルマネージドRAGサービスである「Knowledge Bases for Amazon Bedrock」に追加された機能は、まさにこの「ラストワンマイル」の課題を解決するものです。特に注目すべきは以下の2点です。
- 高度なチャンク分割（Advanced Chunking）：コンテキストを維持したままデータを細分化する設定。
- メタデータフィルタリング：検索時にドキュメントの属性（部署、役職など）で絞り込む機能。
本記事では、これらを活用して「実用レベルのRAG」を構築するための実装ポイントと、開発者が陥りやすい罠について解説します。
1. 脱・機械的分割。「高度なチャンク分割」の戦略
従来のRAGにおける最大の課題は、ドキュメントの分割（チャンキング）が機械的すぎることでした。単に「500文字で切る」といった処理では、文脈が分断され、LLMが正しい回答を生成できません。
今回のアップデートにより、Bedrock Knowledge Basesではチャンキング戦略を細かく制御できるようになりました。開発者は以下のオプションから選択・設定が可能です。
チャンキング戦略の比較
実務においては、ドキュメントの性質に合わせて以下のように使い分けるのが「定石」となります。
| 戦略 | 概要 | 推奨ユースケース |
|---|---|---|
| Default Chunking | AWS推奨の標準設定。 | 一般的なWeb記事やブログなどの非構造化データ。 |
| Fixed Size Chunking | トークン数や文字数を固定し、オーバーラップ（重複）率を指定。 | 契約書や規約など、文言の一言一句が重要な法的文書。 |
| No Chunking | 1ファイル＝1チャンクとして扱う。 | FAQリストや、Q&Aペアがあらかじめ整備されたCSV/JSON。 |
| Hierarchical Chunking | 親子関係を持たせて分割（要約と詳細の階層化）。 | マニュアルや技術仕様書など、章立てが明確な長文ドキュメント。 |
開発者のハマりどころ：オーバーラップ設定
Fixed Sizeを選択する場合、オーバーラップ（重複部分）の設定を忘れないでください。ここを0にすると、分割点にある重要なキーワードが文脈から切り離され、検索漏れの原因になります。通常はチャンクサイズの10%〜20%をオーバーラップさせるのがベストプラクティスです。
2. 企業利用の必須要件「メタデータフィルタリング」の実装
「人事部の資料が全社員から検索できてしまった」──これはRAG導入における最大のリスクです。これを防ぐために、Bedrock Knowledge Basesではメタデータフィルタリングがサポートされました。
データソース側の準備
S3上のデータソースに対して、.metadata.json ファイルを付与することで属性を定義します。
// employee_handbook.pdf.metadata.json
{
"metadataAttributes": {
"department": "HR",
"accessLevel": "confidential",
"version": "2024-v1"
}
}
検索クエリの実装（Python / boto3）
検索時（Retrieve）に retrievalConfiguration を渡すことで、LLMにコンテキストを渡す前に、Vector DBレベルで情報をフィルタリングします。これにより、LLMが権限のない情報を「ハルシネーション（幻覚）」として漏らすリスクも物理的に遮断できます。
import boto3
client = boto3.client('bedrock-agent-runtime', region_name='us-east-1')
# ユーザーの属性（例：営業部の一般社員）
user_department = "Sales"
user_access = "internal"
response = client.retrieve(
knowledgeBaseId='YOUR_KB_ID',
retrievalQuery={
'text': '今期の経費精算のルールを教えて'
},
retrievalConfiguration={
'vectorSearchConfiguration': {
'numberOfResults': 5,
# ここでフィルタリングを適用
'filter': {
'andAll': [
{
'equals': {
'key': 'department',
'value': user_department
}
},
{
'equals': {
'key': 'accessLevel',
'value': user_access
}
}
]
}
}
}
)
print(response['retrievalResults'])
3. フルマネージド vs 自前構築（LangChain等）
今回のアップデートにより、Bedrock Knowledge Basesは「とりあえず試す」ツールから「本番運用に耐えうる」ツールへと進化しました。自前でPineconeやOpensearchを立て、LangChainでパイプラインを書く場合との比較は以下の通りです。
- 自前構築のメリット： 分割ロジックを1行単位でカスタマイズ可能、最新の論文手法（HyDEなど）を即座に取り入れられる。
- Bedrock KBのメリット： インフラ管理ゼロ、AWS IAMとの統合による堅牢なセキュリティ、データ同期（Sync）の自動化。
結論として、特別な検索ロジックを研究開発する企業でない限り、まずはBedrock Knowledge Basesで構築し、どうしても精度が出ない場合のみ自前構築を検討するアプローチが、TCO（総保有コスト）の観点から最も合理的です。
よくある質問（FAQ）
- Q. 日本語のドキュメントでも精度は出ますか？
- A. はい、問題ありません。埋め込みモデルとして「Titan Text Embeddings v2」や「Cohere Embed Multilingual」を選択することで、日本語特有の文脈を理解したベクトル化が可能です。
- Q. メタデータファイルの作成が面倒です。自動化できますか？
- A. はい。S3へのアップロード時にLambda関数をトリガーさせ、ファイル名やパスから自動的にメタデータJSONを生成・配置するパイプラインを組むのが一般的な実装パターンです。
- Q. 既存のPDFを更新した場合、いつ反映されますか？
- A. S3上のファイルを上書きしただけでは反映されません。APIまたはコンソールから「StartIngestionJob（同期）」を実行する必要があります。これをイベント駆動で自動化する設定をお忘れなく。
コメント