Amazon Bedrockが企業内検索の構築と運用を管理サービス化

AWSは、エージェント向けの企業内検索を構築するAmazon Bedrock Managed Knowledge Baseを一般提供しました。接続、文書処理、索引、検索、アクセス制御の運用を一つの管理サービスへまとめます。

要点

• データソース接続、解析、分割、埋め込み、ベクトルまたはグラフ保存、再ランキングを管理サービスとして扱います。
• 文書単位のアクセス制御を検索結果へ反映し、利用者が閲覧できない情報をエージェントへ渡さない設計を支援します。
• コンソールではモデル選択なしでも既定構成を開始でき、必要に応じて埋め込み、再ランキング、文書分割を変更できます。
• 観測性と本番運用を含む一方、検索正解率や権限境界の評価は利用側に残ります。

今回のブログ記事で語られていること

企業向けエージェントでは、モデルそのものより、どの情報を正しく探し、誰へ見せるかが難しい部分です。従来のRAG基盤は、コネクター、ファイル解析、文書分割、埋め込み、ベクトルストア、検索、再ランキングを個別に選び、更新や障害をそれぞれ運用する必要がありました。Managed Knowledge Baseはこれらを抽象化し、コンソールの既定構成から始められるようにします。AWSは、簡単なセットアップ、より賢い検索、本番対応という三つの柱で説明しています。

重要なのは文書ACLです。社内検索では、検索結果に機密文書が混ざるだけで情報漏えいにつながります。利用者やグループの権限を文書メタデータと結び付け、検索時に適用できれば、回答生成前の段階で対象を絞れます。ただし、元システムの権限変更が索引へ反映されるまでの時間、削除済み文書の残存、複数ソースで同一人物をどう識別するかは利用側で検証が必要です。回答画面の認可だけでなく、検索候補、ログ、評価データ、キャッシュにも同じ境界を適用しなければなりません。

管理サービスによって部品選びは減りますが、検索品質の責任が消えるわけではありません。表やPDF、長い手順書など文書種別ごとに解析精度を確認し、代表的な質問と正しい根拠文書を評価セットにします。既定の文書分割や再ランキングで不足する場合だけ調整し、変更前後で再現率、誤った根拠、応答時間、費用を比較します。エージェントが検索結果から操作を行う場合は、検索の誤りが実行へ直結しないよう、人の確認やツール側の権限も必要です。

運用開始後は、索引作成の遅延、接続元の同期失敗、検索結果がゼロになる割合、引用した文書の鮮度を観測します。管理サービスの正常性だけでは、利用者が必要な文書へ到達できているかは分かりません。業務部門から誤検索を報告できる経路と、評価セットへ反映する担当を決めておくことが、継続的な品質改善につながります。

今回のブログ記事が関係する人

社内検索やRAGを運用するAI基盤チーム、文書権限を管理するセキュリティ担当、エージェントへ企業データを接続する開発者に関係します。

結局、今回のブログ記事をどう読むべきか

検索基盤の部品運用を減らすサービスですが、ACLと検索品質の検証は残ります。まず限定したデータソースで、権限変更、削除、引用、検索不能時の挙動を含む受け入れ試験を作るのがよいでしょう。