How Octave built a secure multi-tenant AI foundation on Amazon Bedrock

如何在Amazon Bedrock上构建安全的多租户AI基础架构 | 人工智能

如何在Amazon Bedrock上构建安全的多租户AI基础架构

在受监管行业的质量管理中，解决问题的机构记忆几乎总是埋藏在客户的历史记录的某个地方。去年调查过的类似缺陷、解决根本原因的纠正与预防措施（Corrective and Preventive Action, CAPA）、标记相同漏洞的审计发现。这些知识存在于数十亿份文档中，而这些文档无法通过语义相似性在不同语言和格式间被人类检索，因此每次调查都必须从零开始。Octave Reliance帮助各组织跨多个系统收集文档，以帮助他们更轻松地搜索并跟踪所有数据。Octave Reliance团队认为，解锁这些历史记录是帮助客户提高效率并保持合规的最大机会。但障碍同样明显：投诉记录、审计发现和纠正措施需要平台最严格的隔离要求，而这些正是AI需要读取的记录。在一个为14,000多家客户提供服务的平台中（涵盖医疗器械、制药和食品制造领域），如果一个客户的数据意外泄露给另一个客户，产生的监管后果将远超AI带来的任何好处。

Octave业务覆盖180个国家，为全球财富500强企业中的60%提供服务。其云原生质量管理平台Reliance支持超过650家企业的40多个应用，从投诉管理、CAPA追踪到审计管理、供应商质量。每个人都会生成AI可以推理的受监管数据。每个客户都是独立租户，数据不能跨越租户边界。

面对这一挑战，Reliance团队做出了一个不寻常的决定：与其推出一个AI功能，不如在第一阶段投入资源构建所有未来功能都将依赖的基础架构。自那时起，该基础架构使每个用例的部署时间减少了50%。如果你正在将AI引入一个数据具有价值但隔离要求不可妥协的软件即服务（SaaS）平台，这种推理方式的影响将超越质量管理领域。在本文中，我们将探讨塑造设计的四个矛盾点，以及Octave如何借助Cohere Embed v4在Amazon Bedrock上构建的三层基础架构。随后，我们将介绍嵌入了20亿份文档的流程，以及在生产环境中验证其效果的投诉分类助手。

为何选择构建基础架构而非单一功能

与AWS的构思研讨会揭示了四个高影响力用例：投诉摘要与分类、审计准备监控、事件叙述生成、预测性质量风险评分。同时，经过数十个应用的验证，团队发现了一个关键洞察：每个应用都有不同的文档类型和工作流程。如果为其中一个应用单独构建AI，就需要为下一个应用重新构建基础设施。

因此，团队调整了计划：首先构建横向平台，再从中切割出纵向功能模块。投诉摘要与分类功能率先推出，以验证架构的可行性，随后其他功能逐步跟进。

四大矛盾点

在选择单一模型之前，团队需要解决四个相互拉扯的问题，这些问题无法通过取舍来解决。

在不冒意外泄露风险的情况下提供数据。投诉记录、纠正和预防措施（CAPAs）、标准操作程序（SOPs）和审计发现属于单一租户，必须无法被其他租户访问。即使是偶然的AI查询也无法跨越租户边界。向量存储、检索逻辑和生成上下文都必须限定在单一租户范围内。

在隔离环境中执行代理。代理的工具、数据存储和模型端点的权限必须限定在请求用户而非共享服务角色，且仅在执行期间临时可用，同时尊重用户的访问权限。使用静态凭证的共享代理池在三个维度上均无法满足要求。

处理不可信内容。此处的代理需要处理来自组织外部的投诉、电子邮件附件、扫描PDF和图像。OWASP 2025年大语言模型（LLM）应用十大威胁明确指出直接相关的风险：通过摄入内容注入提示（LLM01）、敏感信息泄露（LLM02）、输出处理不当（LLM05）和代理权限过度（LLM06）。在如此庞大的数据量下，附件PDF中的隐藏指令并非假设情景。

在无需季度等待时间的情况下嵌入20亿文档。Reliance平台托管着超过20亿文档，单个租户可能存储数百万个Word文件、PDF、扫描表单、电子表格、图像和电子邮件。团队承诺即使为最大租户办理入驻也只需单个工作日。由于这些文档直接影响监管决策，质量不能为吞吐量让路。任何投诉的遗漏都会破坏整个系统的信任基础。

架构最终形态

同时平衡四项矛盾极大限制了选择空间。Amazon Bedrock通过统一平台解决了所有问题：通过单一API实现多模态访问，利用AWS账户已实施的AWS区域驻留和AWS身份与访问管理（IAM）治理，以及将Guardrails作为生产内容控制而非自行构建的防护机制。

基础架构分解为三层，如图1所示。数据准备阶段使用Amazon Bedrock上的Cohere Embed v4将高质量文档嵌入，并写入Amazon OpenSearch Service上的租户专属向量存储。安全执行阶段将用户请求通过AgentCore Gateway（Amazon Bedrock AgentCore的功能模块）传递，该模块在转发至隔离的微虚拟机会话前执行身份验证和策略检查，该会话调用Amazon Bedrock上的Anthropic Claude模型。双重防护机制贯穿始终：内容保护在输入阶段实施过滤，在输出到达处理程序前再次进行过滤。检索、执行和筛查保持在独立阶段，使每个阶段均可单独实施和验证。

图1：Reliance AI基础架构的高层视图

选择数据表示方式

直到文档可被检索之前，其他方案均无法奏效。这意味着必须实现跨语言和格式的准确检索，且不能跨越租户边界。团队基于自有语料库而非公开排行榜评估嵌入模型。关键问题直接指向数据特性：一张裂纹住房的照片与描述它的段落之间存在何种关联，德语投诉与英文CAPA之间又存在何种联系。

Cohere Embed v4 在 Amazon Bedrock 上凭借五个优势胜出，这些优势之间并非相互独立。首先明确的是，该方案消除了多少冗余流程。质量记录需要同时保存缺陷产品照片、扫描的检验表单、标注的图纸和文本信息。Embed v4 将图像和文本两种模态统一映射到同一向量空间。通过单一查询即可检索到裂纹外壳的照片和描述该缺陷的段落，无需为每种模态单独构建处理流程。原生多语言支持在另一维度实现相同效果：文档可能以多种语言存在，且常出现在同一租户的语料库中，无需进行翻译预处理。团队因此无需构建两个流程，文档在检索过程中的丢失风险也减少了两个可能点。

其余三个优势聚焦于向量存储位置和成本控制。客户数据即使在推理过程中也不能离开其 AWS 区域，因此 Amazon Bedrock 的区域模型可用性成为前提条件而非便利功能。Embed v4 支持美国东部（弗吉尼亚北部）区域（us-east-1）、欧洲（爱尔兰）区域（eu-west-1）和亚太（东京）区域（ap-northeast-1）的本地推理，覆盖了 Octave 的三个区域合规要求。模型和功能的可用性会随区域变化并随时间调整。当前覆盖情况请参见《Amazon Bedrock 用户指南》中的“按区域划分的模型可用性”。在每个区域内，Amazon OpenSearch Service 的成本与维度数量呈线性关系。这使得 Embed v4 的可配置输出维度（256-1536）值得专门测试而非默认接受。针对代表性生产查询的测试显示，512 维度在保持目标精度的同时，相比默认的 1536 维度可减少约 66% 的存储空间。128K 令牌上下文窗口在其他方面带来显著收益：约 4K 令牌的文档块可打包到单个请求中，这正是客户导入吞吐量的来源。

运行时实现租户隔离

更复杂的挑战在于如何在运行时实施租户隔离。虽然应用代码可以实现，但意味着每个未来功能团队都必须在所有代码路径上正确实现，任何遗漏的检查都可能导致无意的跨租户数据泄露。团队选择将隔离机制下推到运行时层面。AgentCore 运行时作为 Amazon Bedrock AgentCore 的一项能力，在应用层之下强制实施隔离，且由于其保持框架和模型无关性，投诉分类助手所选用的代理框架和模型并未受到隔离决策的限制。

每个用户会话都在专用的微虚拟机中运行，拥有独立的 CPU、内存和文件系统，会话结束后系统会停止并清除内存数据。这种硬件级隔离机制确保无论代理如何运行，隔离效果始终有效。AgentCore 在整个执行链中传递认证用户身份：按用户划分的 OAuth 令牌保险库验证代理代表特定用户而非共享服务身份执行操作，凭证按代理实例限定且仅在会话期间有效。AgentCore 网关在工具、操作和参数层级实施授权。自动化推理提供对定义规则的正式验证。这种机制与 IAM 和 Amazon Simple Storage Service（Amazon S3）策略验证采用相同严谨标准。图 2 展示了该隔离机制在两个租户间的实施效果。

图 2：AgentCore 在租户间的会话隔离。每个微虚拟机在使用后都会停止并清除内存数据。

因此，Tenant A的质量处理人员提交的投诉仅能到达AgentCore Code Interpreter中的Tenant A的token vault、工具和沙箱，这是Amazon Bedrock AgentCore的一项功能。Tenant 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万tokens的处理能力。在与Cohere解决方案架构师共同调整批处理大小直至消除内存瓶颈后，该流水线每个租户工作负载每天可处理140万份文档。这正是实现单日完成承诺的关键所在。

投诉分类助手

医院向医疗器械制造商报告缺陷注射器时，相关记录会通过电子邮件、损坏部件的照片以及支持文件一并提交。质量处理人员需要在这些不同格式中拼接上下文，判断是否曾有类似投诉，并查找已解决的案例。只有在完成这些步骤后，才能确定优先级，而这一过程通常需要在数天的报告窗口期内完成。

该助手基于AWS开源的Strands Agents SDK构建，该SDK通过将智能代理工作流表示为图结构来实现，其中节点表示工具调用或模型调用，边表示节点间的数据依赖关系。AgentCore运行时会执行该图结构，并在每个会话中进行隔离，整个流程包含五个阶段，将原始附件逐步转化为完整的摘要报告。

文档提取是第一步。PDF、图像、电子邮件附件和视频都会进入AgentCore代码解释器，该组件将每个文档解析为结构化中间表示。随后Amazon Bedrock上的Claude模型会对记录进行摘要，该摘要（而非原始数千token的原始内容）成为检索查询。检索过程会将其与租户的OpenSearch索引中的Embed v4嵌入向量进行比对，找出相似的历史投诉及其CAPAs，而AgentCore网关会确保只有授权的命名空间可被访问。

返回的结果不会仅基于相似性进行信任判断。另一个独立的模型调用会根据置信度对结果进行评分，并剔除那些词汇相似但根本原因不同的匹配项。通过验证的结果将进入合成阶段，Amazon Bedrock上的Anthropic Claude Sonnet会生成最终输出：关键事实、情感倾向、紧急程度指标、最相似的历史记录及其处理结果，以及建议的分类优先级。

完成的摘要报告会被缓存在Amazon DynamoDB中，并设置按环境配置的生存时间（TTL），因此重复查看不会产生额外成本。处理人员不再需要从零开始，而是基于机构记忆进行判断。

图4展示了该引擎如何部署在私有API边界后。门户请求通过私有Amazon API Gateway和Lambda函数到达AgentCore运行时，检索过程通过基于角色的访问控制和预签名URL读取文档索引，而附件则保留在Amazon S3中。缓存的摘要和OpenTelemetry追踪数据会传输到摘要表和评估仪表板。

图4：摘要引擎：基于AgentCore的智能工作流在私有API边界内处理文档提取、检索、推理和合成，包含响应缓存和完整可观测性。

图5将相同流程简化为单条路径，两端均设有防护网过滤。

图5：从数据摄入到处理人员输出的投诉分类助手流水线

证明代理的行为

可观测性不仅涉及工程团队如何调试，还涉及他们如何与系统审计功能集成以满足合规要求。审计人员可以询问为何某条投诉被处理的方式如此，而“模型决定”这样的解释将无法经受住这样的质询。

AgentCore 在图中的每个节点都捕获兼容 OpenTelemetry 的追踪记录：每次模型调用、检索操作以及 AgentCore 代码解释器的运行。数月后，Octave 可以展示哪些检索文档和提示生成了特定的摘要。Amazon Bedrock 的模型调用日志为每个请求和响应添加了租户级别的记录，通过 AgentCore 传播的 IAM 身份进行范围限定，成本在 Amazon CloudWatch 中归因于发起租户。

离线时，AgentCore Evals 在任何提示、模型或检索参数更改后，会重新运行工作流以对比专家标注的真实数据，报告摘要忠实度、K 位置检索精度和输出完整性。一个读起来更好但检索效果更差的提示会在用户看到之前被发现。

结果

投诉分类助手已在生产环境中运行了三个月，以下数字反映了这一时期的表现。

过去需要从零开始启动调查的处理人员，现在可以利用已组装的相关历史信息启动调查。Octave 每次调查测量的 4-6 小时是流程吸收的工作量：跨格式的提取、寻找先例以及判断真正相似缺陷与措辞巧合所需的阅读时间。

基础架构也改变了 Octave 的发布速度。根据其自身统计，新 AI 功能的开发周期从数月缩短至数周。共享数据准备、安全执行和检索构成了图 1 的三个层级。它们将每个用例的部署时间减少了 50%，因为每个新功能都继承了这些层级而非重新构建。这使得语义搜索在 Q2 实现，比原定 Q4 目标提前了两个季度。

回顾

团队最初构建基础架构的决定是他们最犹豫的。当利益相关者希望看到 AI 功能时，数月的基础设施工作难以辩护。下一阶段的用例验证了这一决策。两个关键选择支撑了这一成果：将隔离措施推进到微虚拟机会话中，并通过身份传播而非应用代码实现，以及使用 Octave 自己的语料库评估嵌入模型，这揭示了基准测试无法显示的 512 维度权衡。

团队也划定了一个选择不跨越的界限。助手仅呈现上下文和先例，质量处理人员仍保留最终决策权。在该行业，这一决策承载着监管权重，这一边界决定了哪些流程被自动化，哪些没有。

未来计划

Octave 现在正在将基础架构扩展到 Reliance 套件的其他部分。审计准备监控、事件叙述生成和预测性质量风险评分是下一步，它们都建立在相同的基础设施之上。

如果您的平台面临类似困境：有价值的数据受到严格的隔离要求。Octave 的经验表明，这些权衡是可行的。要了解更多关于这些服务的信息，请参阅 Amazon Bedrock、Amazon Bedrock AgentCore 文档 和 Cohere on Amazon Bedrock。有关相关架构指导，请参阅 AWS 向量解决方案：在数据所在位置构建智能体 AI 和 扩展智能体 AI：无供应商锁定的企业模式。

作者简介

'"`