Octave 如何在 Amazon Bedrock 上构建安全的多租户 AI 基础
How Octave built a secure multi-tenant AI foundation on Amazon Bedrock
Octave 未先交付单一 AI 功能，而在 Amazon Bedrock 上为 Reliance 建成安全多租户 AI 基础，每个用例的部署时间缩短 50%。
在受监管行业的质量管理中，解决问题所需的机构记忆几乎总是埋藏在客户历史的某处。去年调查过的类似缺陷、修复了根本原因的纠正与预防措施（CAPA）、标出同一缺口的审计发现。这些知识存在于数十亿份文档中，没有人能够跨语言和格式按语义相似度进行搜索，因此每次调查都要从零开始。Octave Reliance 已帮助各组织从多个系统收集文档，以便更轻松地搜索并跟踪他们所拥有的一切。Octave Reliance 团队将解锁这段历史视为帮助客户更快工作并保持合规的最大单一机会。障碍同样明确：投诉记录、审计发现和纠正措施承载着该平台最严格的隔离要求，而这些恰恰是 AI 需要读取的记录。在一个服务于医疗器械、制药和食品制造领域超过 14,000 家客户的平台上，一次从一个客户到另一个客户的无意披露所带来的监管后果，将远远超过任何 AI 收益。
Octave 的业务遍及 180 个国家，服务超过 全球《财富》500 强的 60%。其云原生质量管理系统 Reliance 以超过 40 个应用程序支持逾 650 家企业客户，涵盖投诉管理、CAPA 跟踪、审计管理以及供应商质量。每一个都会生成可供 AI 推理的受监管数据。每位客户都是独立的租户，任何数据都不能跨越租户边界。
面对这一局面，Reliance 团队做出了一个不寻常的决定：与其推出单一 AI 功能，不如把第一个周期用来构建一个供所有未来功能依托的基础。此后，该基础已将每个用例的部署时间缩短 50%。如果你正在把 AI 引入一个数据极具价值、但隔离不容妥协的软件即服务（SaaS）平台，这套思路可以延伸到质量管理之外。在本文中，我们梳理塑造该设计的四项张力，以及 Octave 借助 Amazon Bedrock 上的 Cohere Embed v4 构建的三层基础。随后，我们跟随那条嵌入了 20 亿份文档的流水线，以及在生产环境中验证了它的 Complaint Triage Assistant。
为什么是基础，而不是功能
与 AWS 的构想研讨会浮现出四个高影响力用例：投诉摘要与分诊、审计就绪监控、事件叙述生成，以及预测性质量风险评分。它们还揭示了塑造此后一切的洞见：数十个应用程序各自具有不同的文档类型和工作流。以孤岛方式为其中一个构建 AI，就意味着为下一个重建基础设施。
于是，团队把计划颠倒过来：先构建横向平台，再在其中切出纵向功能切片。投诉摘要与分诊先行，以便在其余部分跟进之前验证该架构。
四项张力
在选定任何一个模型之前，团队把时间花在了四个方向彼此拉扯的问题上。没有一个可以舍弃。
在不冒无意披露风险的情况下提供数据。投诉记录、CAPA、标准操作程序（SOP）和审计发现属于一个租户，必须无法被另一租户触及。即便是一次偏离正轨的 AI 查询也无法跨越。向量存储、检索逻辑和生成上下文都必须限定在单一租户范围内。
隔离执行智能体。管控智能体工具、数据存储和模型端点的权限必须限定于请求用户，而非共享服务角色；仅在执行期间可用，并尊重该用户的访问权限。使用静态凭证的共享智能体池在这三项上全部失败。
读取不可信任的内容。这里的智能体会摄取来自组织外部的投诉、电子邮件附件、扫描版 PDF 和图像。OWASP 大型语言模型（LLM）应用十大风险（2025）点明了直接适用的威胁：通过摄取内容实施提示注入（LLM01）、敏感信息泄露（LLM02）、不当输出处理（LLM05）以及过度代理（LLM06）。在这种体量下，附件 PDF 中的隐藏指令并非假想。
嵌入 20 亿份文档，无需等待一个季度。Reliance 托管超过 20 亿份文档，单个租户存储数百万个 Word 文件、PDF、扫描表单、电子表格、图像和电子邮件。团队承诺即使最大的租户也能在一个工作日内完成接入。由于这些文档为监管决策提供依据，不能以质量换取吞吐量。漏掉一则投诉就会削弱对整个系统的信任。
架构最终落点
同时承受这四项张力，使可选方案大幅收窄。Amazon Bedrock 以一个平台应对它们：通过单一 API 访问多种模型、AWS 区域驻留，以及 AWS 账户已经强制执行的 AWS Identity and Access Management (IAM) 治理，并将 Guardrails 作为生产级内容控制，而非需要自行构建的东西。
该基础归结为三层，如图 1 所示。数据准备使用 Amazon Bedrock 上的 Cohere Embed v4 嵌入质量文档，并将其写入 Amazon OpenSearch Service 上按租户划分的向量存储。安全执行将用户请求经由 AgentCore Gateway 传递，这是 Amazon Bedrock AgentCore 的一项能力；它在把请求交给隔离的 microVM 会话之前应用身份验证和策略，该会话会调用 Amazon Bedrock 上的 Anthropic Claude 模型。内容保护将二者包裹起来，对 Amazon Bedrock Guardrails 应用两次：进入时进行输入过滤，在任何内容到达处理程序之前进行输出过滤。检索、执行和筛查保持在不同阶段，因此每一项都可以单独强制执行并单独举证。
图 1：Reliance AI 基础的高层架构
选择如何表示数据
在文档变得可检索之前，其他一切都行不通。这意味着要跨语言和格式准确检索，且不得跨越租户边界。团队针对自己的语料库而非公开排行榜评估嵌入模型。决定性问题都特定于这些数据：一张外壳开裂照片与描述它的段落有何关系，以及一则德语投诉与一份英语 CAPA 有何关系。
Cohere Embed v4 在 Amazon Bedrock 上从五项胜出，而且这些项并非彼此独立。首先确定的是有多少流水线因此变得不再必要。质量记录在文本之外还包含缺陷产品的照片、扫描的检验表单以及带注释的图表。Embed v4 将两种模态置于同一向量空间。一张外壳开裂的照片与描述该缺陷的段落可通过单次查询检索，无需为每种模态单独建立流水线。原生多语言支持在另一条轴上做同样的事：文档以多种语言到达，常常位于同一租户的语料库内，且无需翻译预处理。两条团队从未需要构建的流水线，也少了两处文档可能从检索中掉出的地方。
其余三项确定了向量可以存放在何处以及成本如何。客户数据即使为了推理也不能离开其 AWS Region，因此 Amazon Bedrock 上的区域内模型可用性是前提而非便利。Embed v4 支持在 US East (N. Virginia) Region (us-east-1)、Europe (Ireland) Region (eu-west-1) 和 Asia Pacific (Tokyo) Region (ap-northeast-1) 进行区域内推理，覆盖 Octave 的三项区域合规要求。模型和功能的可用性因 Region 而异，并会随时间变化。有关当前覆盖范围，请参阅 Amazon Bedrock 用户指南中的 按模型划分的区域可用性。在每个 Region 内，Amazon OpenSearch Service 的成本随维度数线性增长。这使得 Embed v4 可配置的 256–1,536 输出维度值得测试，而不是默认接受。针对有代表性的生产查询的测试表明，512 维在保持目标准确率的同时，相较 1,536 的默认值将存储削减约 66%。128K token 的上下文窗口则完全在别处见效：约 4K token 的分块可在一次请求中装入许多块，接入吞吐量正是由此而来。
在运行时隔离租户
更难的问题是在何处强制执行租户隔离。应用代码本可以做到，但这将意味着每个未来的功能团队都必须在每条代码路径上做对，漏掉一次检查就有无意中跨租户披露的风险。团队转而把隔离推进到运行时。AgentCore runtime 是 Amazon Bedrock AgentCore 的一项能力，在应用层之下强制执行隔离；并且由于它保持与框架和模型无关，为 Complaint Triage Assistant 所选的智能体框架和模型不受该隔离决策的约束。
每个用户会话都在专用 microVM 中运行，拥有自己的 CPU、内存和文件系统，会话结束时即停止并清理。这是硬件级隔离，设计为无论智能体如何行为都能成立。AgentCore 在整个执行链中携带已认证用户的身份：按用户划分的 OAuth 令牌保管库验证智能体是代表该特定用户而非共享服务身份行事，凭证按智能体限定范围且仅在会话期间存在。AgentCore Gateway 在工具、操作和参数级别进行授权。自动推理针对已定义规则提供形式化验证。这与 IAM 和 Amazon Simple Storage Service (Amazon S3) 策略验证背后的同一套原则。图 2 追踪了该隔离在两个租户之间的情况。
图 2：租户之间的 AgentCore 会话隔离。每个 microVM 在使用后停止，并清除内存。
因此，租户 A 的质量处理人员提交的投诉只会到达租户 A 在 AgentCore Code Interpreter（Amazon Bedrock AgentCore 的一项功能）中的令牌保管库、工具和沙箱。租户 B 的会话无法访问其中任何一项。
将摄取的内容视为不可信
这种矛盾没有干净利落的答案。投诉附件是不可信输入，但它也正是智能体存在所要读取的内容，因此无法拒绝可疑内容。团队最终采用了纵深防御。
Octave 在智能体逻辑之上而非其内部应用了 Amazon Bedrock Guardrails，覆盖投诉工作流中的三个节点。ApplyGuardrail API 会在嵌入之前评估从附件中提取的文本，在检索到的文档和工具输出进入智能体上下文之前对其进行评估，并在处理人员看到综合简报之前对其进行评估。源自附件的内容在传递时带有输入标记，将其标为数据而非指令。正因如此，埋在文档中部的注入才可被检测。个人身份信息（PII）在进入时会被屏蔽。
仅有检测并不充分，因此其下还有有界自主性。无论要求智能体做什么，AgentCore Gateway 仍会管控它可以调用哪些工具，文档提取则在 AgentCore Code Interpreter 沙箱中运行，没有网络出站，也不会在会话之外持久化。隐藏在 PDF 中的载荷必须突破每一层，而不是仅仅一层。
效果：检测率和屏蔽率按租户跟踪，因此筛查捕获了什么是 Octave 可以举证的，而不是仅仅声称。
让 20 亿份文档通过该管道
在嵌入模型之前还有一个更难的问题：从 Word 文件、电子表格、数字 PDF、扫描页面、照片和电子邮件线程中提取可用内容。会出现多种语言，有时甚至在同一条记录中。而且它必须运行得足够快，使接入只需一天而非一个季度。图 3 端到端地描绘了由此形成的管道。
图 3：摄取管道：事件驱动的文档处理，从应用平台经由 Step Functions 编排，直至按租户划分的 OpenSearch 索引。
文档事件通过 Amazon Simple Notification Service（Amazon SNS）和 Amazon Simple Queue Service（Amazon SQS）扇出，进入 AWS Step Functions 状态机。该状态机在专用的 Amazon Virtual Private Cloud（Amazon VPC）内，跨并发的 AWS Lambda 执行来编排解析、分块和嵌入。由于并行来自将批次分散到多次执行，而不是扩展单一资源，吞吐量可以在无需重新架构的情况下增长。
解析负责处理这种异构性：保留 Word 文件和电子表格中的语义层级，对缺少文本层的扫描 PDF 应用光学字符识别（OCR），并将嵌入图像视为一等内容。分块携带元数据：租户、文档类型、来源应用、语言以及内容哈希。这些元数据既驱动检索过滤，也驱动按租户的命名空间强制执行。
吞吐量来自打包。将许多 4K 分块交错放入针对 Embed v4 的 128K 上下文窗口的单次请求中，使大型语料库的 API 调用减少了大约一个数量级。在 Octave 于 Amazon Bedrock 上的内部测试中，Embed v4 达到每分钟 2800 万个 token。在与 Cohere 的解决方案架构师一起调整批大小、直至内存瓶颈消除之后，该流水线在每个租户工作负载下每 24 小时可持续处理 140 万份文档。正是这一点让一个工作日的承诺成为现实。
投诉分诊助手
一家医院向医疗器械制造商报告有缺陷的注射器，该记录送达时附有电子邮件、损坏产品的照片以及支持文档。质量处理人员必须跨这些格式拼合上下文，判断此前是否报告过类似情况，并找出当时的解决办法。只有在此之后才能分配优先级，而这往往必须在以天为单位的报告时限内完成。
该助手基于 AWS 开源的 Strands Agents SDK 构建，该 SDK 将智能体工作流编排为图，节点为工具调用或模型调用，边为它们之间的数据依赖。AgentCore 运行时运行该图并按会话进行隔离，五个阶段将一则投诉从原始附件处理为完成的简报。
文档提取是第一步。PDF、图像、电子邮件附件和视频全部进入 AgentCore Code Interpreter，由其将每个工件解析为结构化中间表示。随后，Amazon Bedrock 上的 Claude 模型对记录进行摘要，该摘要而非原始的数千 token 来源成为检索查询。检索针对租户存放 Embed v4 嵌入的 OpenSearch 索引运行该查询，找出相似的历史投诉及其 CAPA，同时由 AgentCore Gateway 强制规定只有已授权的命名空间可以访问。
返回结果不会仅因相似度就被采信。另一次单独的模型调用按置信度对结果评分，并丢弃那些共享词汇但根本原因不同的匹配。留存结果进入综合阶段，由 Amazon Bedrock 上的 Anthropic Claude Sonnet 组装输出：关键事实、情感、紧急程度指标、最接近的历史记录及其结果，以及建议的分诊优先级。
已完成的简报缓存在 Amazon DynamoDB 中，并带有按环境设置的生存时间（TTL），因此重复查看不会产生额外成本。处理人员不再从零开始，而是从机构记忆出发。
图 4 将该引擎置于私有 API 边界之后。门户请求通过私有 Amazon API Gateway 和 Lambda 函数到达 AgentCore 运行时；检索借助基于角色的访问和预签名 URL 读取文档索引，而附件则保留在 Amazon S3 中。缓存的摘要和 OpenTelemetry 追踪输出到摘要表和评估仪表板。
图 4：摘要引擎：由 AgentCore 驱动的工作流在私有 API 边界内处理文档提取、检索、推理与综合，并具备响应缓存和完整可观测性。
图 5 将同一路径简化为一条线，并在两端以 Guardrails 进行过滤。
图 5：投诉分诊助手流水线：从摄入到处理人员输出
证明智能体做了什么
这里的可观测性不仅关乎工程团队如何调试，也关乎他们如何与系统审计能力集成，以满足合规要求。审计人员可以询问某项投诉为何以那种方式被分诊，而“是模型决定的”经不起那场对话。
AgentCore 会在图的每一个节点上捕获与 OpenTelemetry 兼容的追踪：每一次模型调用、检索，以及 AgentCore Code Interpreter 运行。数月之后，Octave 可以展示是哪些检索到的文档和提示生成了某一份简报。Amazon Bedrock 的模型调用日志会增加一份按租户记录的每一次请求与响应，其范围通过 AgentCore 所传递的 IAM 身份加以限定，费用在 Amazon CloudWatch 中归属于发起该请求的租户。
在离线状态下，AgentCore Evals 会在提示、模型或检索参数发生任何变更后，对照专家标注的真实基准重新运行该工作流，并报告摘要忠实度、K 处的检索精确率以及输出完整性。一条读起来更好、但检索更差的提示，会在用户看到之前就被发现。
结果
Complaint Triage Assistant 已在生产环境中运行三个月，以下数字反映的就是这一时期。
过去常常在手头空空的情况下开启调查的处理人员，现在开启调查时，相关历史已经汇总完毕。Octave 测得的每次调查 4–6 小时，正是这条流水线所承担的工作：跨格式提取、寻找先例，以及为分辨真正相似的缺陷与措辞上的巧合而进行的阅读。
这一基础也改变了 Octave 的交付速度。按照其自身的统计，新 AI 能力的开发周期从数月缩短至数周。共享的数据准备、安全执行与检索构成图 1 中的三层。它们将每个用例的部署时间缩短了 50%，因为每项新能力都继承这些层，而不是重新构建。这使得语义搜索在 Q2 落地，比原先的 Q4 目标提前了两个季度。
回顾
先打造基础这一决定，是团队最反复自我质疑的一项。当利益相关方想要一个看得见的 AI 功能时，数月的基础设施工作很难辩护。下一轮用例已经证明了它的价值。有两项选择支撑了这一点：把隔离推进到 microVM 会话和身份传递中，而不是放进应用代码；以及对照 Octave 自己的语料库评估嵌入模型，从而揭示出任何基准测试都不会显现的 512 维权衡。
团队还划定了一条自己选择不跨越的界线。助手呈现的是上下文和先例。质量处理人员仍然做出判断。在这一判断具有监管权重的行业中，这条边界决定了哪些被自动化、哪些没有。
下一步
Octave 目前正在 Reliance 套件中扩展这一基础。审计就绪监控、事件叙述生成以及预测性质量风险评分是接下来的方向，每一项都构建在同一基础设施之上。
如果你的平台面临类似的张力：有价值的数据位于严格的隔离要求之后。Octave 的经验表明，这些权衡是可行的。要进一步了解这个故事背后的服务，请参阅 Amazon Bedrock、Amazon Bedrock AgentCore 文档和 Amazon Bedrock 上的 Cohere。有关相关的架构指导，请参阅 AWS 向量解决方案：在数据所在之处构建智能体 AI和 规模化智能体 AI：无供应商锁定的企业模式。
关于作者
Urvish Saraiya
Urvish 是 Octave 的工程负责人，正在 AWS 上构建工业 AI 平台。他在分布式软件系统、数据平台和机器学习领域拥有超过 18 年的经验，在公共安全、支付和数字营销方面具备深厚的技术专长。Urvish 将扎实的技术能力与战略性、以产品为导向的方法相结合，专注于以商业影响力解决业务需求。
Manu Mishra
Manu 是 AWS 的高级解决方案架构师，在软件行业拥有超过 18 年的经验，专长于人工智能、数据与分析以及安全。他的专业能力涵盖战略监督和动手技术领导，负责审阅并指导内部和外部客户的工作。您可以通过 LinkedIn 与 Manu 联系或关注他。
Madhunika Reddy Mikkili
Madhunika 是 AWS 的数据与机器学习工程师。她帮助企业客户利用生成式 AI 和机器学习解决复杂的业务问题。
Payal Singh
Payal 是 Cohere 的解决方案架构师，在 DevOps、云、安全、SDN、数据中心架构和虚拟化方面拥有超过 15 年的跨领域专长。她在 Cohere 推动合作伙伴关系，并帮助客户完成复杂的 GenAI 解决方案集成。
Nate Stecz
Nate 是高级合作伙伴发展经理，帮助领先的生成式 AI 模型提供商通过与 AWS 的合作提升收入。Nate 在 Amazon Web Services 工作了近 10 年。Nate 位于华盛顿州西雅图，喜欢户外活动并学习新兴技术。您可以通过 LinkedIn 与 Nate 联系或关注他。
来源：AWS Machine Learning Blog · aws.amazon.com