AWS推出基于Bedrock托管知识库的多租户文档聊天架构方案
该方案通过共享知识库加元数据过滤实现用户级数据隔离，文档上传后数秒内可检索，并提供完整的参考实现代码。
AI解读：AWS发布了一篇架构方案，教企业如何在Amazon Bedrock托管知识库上构建多租户的文档问答应用。它的核心价值在于把最难的隔离问题简化了：每个用户上传的合同、报告等文档，在检索时都会带上从登录凭证（JWT）推导出的用户ID过滤条件，而不是相信客户端传来的值，所以用户只能查到自己的内容。方案还展示了如何让上传和后台索引解耦——小文件直接上传，大文件先存S3，用队列缓冲，用户上传后几秒内就能开始问答。对想快速上线类似功能的团队来说，这意味着不必自己搭建向量检索和隔离逻辑，能省下不少基础设施工作。但要注意：AWS明确表示索引时间会随文件大小和负载变化，而且这些数字不是服务承诺；另外方案推荐的是共享知识库加过滤，如果你只有少数几个大租户且要求严格隔离，可能还是得用独立知识库。
AWS机器学习博客发布了一份解决方案架构，介绍如何利用Amazon Bedrock托管知识库构建多租户的Agentic文档聊天应用。方案支持用户上传文档后立即提问，并通过共享知识库加元数据过滤实现用户级数据隔离。
架构组件与数据流
方案包含两大流程：文档摄入（ingestion）和对话检索（retrieval）。应用使用Amazon API Gateway和AWS Lambda处理上传、状态和聊天端点；Amazon Cognito负责用户认证，提供用于隔离的已验证身份；Amazon SQS解耦上传与后台摄入，吸收突发流量；Amazon DynamoDB记录文档索引状态；Amazon S3存储大于内联限制的文件并托管前端。
上传流程：用户通过Cognito登录后上传文档，请求携带JWT，API Gateway验证并提取用户身份（而非信任客户端值），身份信息随文档（或S3引用）放入SQS消息，立即返回响应。文件小于6MB直接内联发送，更大文件先存S3，SQS消息携带S3 URI。工作Lambda为文档打上user_id元数据（值为Cognito sub），调用IngestKnowledgeBaseDocuments API进行异步摄入，并在DynamoDB中记录状态。
文档索引生命周期
IngestKnowledgeBaseDocuments API是异步的，文档需经过五个状态才完全可查询：STARTING（未开始）、PENDING（排队）、IN_PROGRESS（解析嵌入中）、TEXT_INDEXED（文本chunk可查询，PDF等模态仍在处理）、INDEXED（完全处理，包括图像表格）。AWS在空闲知识库上用小于5MB文档测试的数据：纯文本2-3秒即可查询文本且完全索引；PDF文本可查询需5-30秒，完全索引约90秒。AWS提醒这些时间因文档大小、复杂度、Region和负载而异，不构成服务承诺，仅作量级参考。应用轮询GetKnowledgeBaseDocuments API并将状态存入DynamoDB，在UI显示received、processing、ready。文档在TEXT_INDEXED时即可标记为ready，无需等待INDEXED。
多租户数据隔离
隔离有两种方式：每租户独立知识库，或共享知识库加查询过滤。对大量终端用户场景，AWS推荐共享知识库加显式过滤，理由是避免每个账户的知识库配额、多小索引的基线成本和注册时创建知识库的延迟。知识库也可以从问题措辞推断过滤条件，但那是相关功能，不是访问控制。隔离必须由应用基于认证身份构建的显式过滤器完成。参考实现在每次请求前确认过滤器范围与调用者一致，并丢弃user_id不匹配的返回块。未认证请求返回HTTP 401，认证但无法解析sub返回HTTP 403。如需服务自身强制访问，知识库也支持文档级ACL，在查询时用userContext评估，这样权限检查就不在应用代码里。
检索与最佳实践
检索流程使用AgenticRetrieveStream API在一次调用中完成一次完整对话轮次：将问题分解为子查询，每个子查询应用每用户过滤，并流式返回带引用的响应（启用generateResponse时）。AWS指出Managed Knowledge Base不支持RetrieveAndGenerate API；若需自定义提示词或特定模型的应用，应使用Retrieve API获取段落再调用Converse API。要显示引用来源，GetDocumentContent API返回原始文件供预览或下载。
最佳实践包括：上传与摄入解耦，用SQS队列缓冲，工作Lambda每次批量摄入最多10个文档，比如500个并发上传可合并为约50次API调用。失败消息进死信队列。摄入吞吐量与检索吞吐量不同：Retrieve API每知识库支持25 QPS突发或10 QPS持续，很少成为瓶颈；摄入上限适合交互式上传，但批量迁移会饱和，此时应使用S3连接器加定时同步。超过并发限制时Bedrock返回ValidationException而非ThrottlingException，重试分类器需相应处理。监控摄入成功率、INDEXED时间P50/P99和检索延迟，INDEXED时间上升是摄入接近上限的最早指标。对话历史需自己存储（如DynamoDB），AgenticRetrieveStream API不持久化消息。
成本说明
成本取决于模型配置：使用托管模型时，Managed Knowledge Base仅按存储和检索计费（每次调用，非每token），摄入无额外费用；选择Amazon Bedrock模型则需支付摄入时的嵌入token和Agentic检索时的编排与生成token。支持服务（Lambda、API Gateway、SQS、DynamoDB、S3）在中等规模下占总成本很小部分。