AWS、Bedrockでマルチテナント文書チャット対応

この投稿は、各テナントのデータを厳密に分離した文書チャット機能を構築する際の、よくあるスケーリング上の課題に焦点を当てている。AWSは、取り込み、ベクターインデックス作成、ランカー、プランニング、最終応答生成を担うBedrock Managed Knowledge Baseに重い処理を移行する。アプリケーション側は、アップロードUI、認証、ユーザーごとのロジックのみを処理すればよい。

重要な設計上の選択は、S3コネクタではなくカスタムコネクタによる直接取り込みである。これにより、ユーザーのアップロードを上書きする可能性のあるスケジュール同期を回避し、カスタム文書IDを割り当ててその場で更新できるようになる。このアーキテクチャは、大きなファイルをS3にステージングし、SQSによるデカップリングでアップロードエンドポイントの応答性を維持する。

インデックス作成のライフサイクルは、TEXT_INDEXEDとINDEXEDを区別する。PDFの場合、テキストが先に検索可能になり、マルチモーダル要素（画像、表）は完全なインデックス作成を必要とする。これはUXに関わる。TEXT_INDEXEDで文書を「準備完了」と表示するとフィードバックは速いが、PDFの一部のコンテンツが欠落する可能性がある。性能数値は参考値であり、保証ではない。