Octave 如何基于 Amazon Bedrock 构建安全的多租户 AI 基础平台

在受监管行业的质量管理中，能够解决某个问题的机构记忆几乎总是埋藏在客户的历史记录里。去年调查过的类似缺陷、修复了根本原因的一项纠正与预防措施（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 亿份文档的处理流水线，以及在生产中验证了它的投诉分诊助手。

为什么是基础，而不是功能

与 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 区域，即使是用于推理也不行，因此 Amazon Bedrock 上的区域内模型可用性是一项前提条件，而非便利选项。Embed v4 支持在美国东部（弗吉尼亚北部）区域（us-east-1）、欧洲（爱尔兰）区域（eu-west-1）和亚太地区（东京）区域（ap-northeast-1）进行区域内推理，覆盖了 Octave 三项区域合规要求中的三项。模型和功能的可用性因区域而异，并会随时间变化。有关当前覆盖范围，请参阅 Amazon Bedrock 用户指南中的按模型划分的区域可用性。在每个区域内，Amazon OpenSearch Service 的成本随维度数量线性增长。这使得 Embed v4 可配置的 256–1,536 输出维度值得测试，而不是默认接受。针对具有代表性的生产查询进行测试表明，512 维在保持目标准确率的同时，相比 1,536 的默认值将存储量削减了约 66%。128K token 的上下文窗口则在另一个方面带来了收益：约 4K token 的块可以在一次请求中打包多个，这正是入门吞吐量的来源。

在运行时隔离租户

更难的问题是在哪里强制执行租户隔离。应用代码本可以奏效，但这意味着未来每个功能团队都必须在每条代码路径上做对，而漏掉一处检查就有意外跨租户泄露的风险。团队转而将隔离推入运行时。AgentCore runtime 是 Amazon Bedrock AgentCore 的一项能力，它在应用层之下强制执行隔离，并且由于它保持框架和模型无关，为 Complaint Triage Assistant 选择的 agent 框架和模型不受隔离决策的约束。

每个用户会话都在一个专用的 microVM 中运行，拥有自己的 CPU、内存和文件系统，会话结束时停止并清理。这是一种硬件级隔离，旨在无论 agent 如何行为都能保持有效。AgentCore 在整个执行链中传递经过身份验证的用户身份：每用户 OAuth token 保管库验证 agent 是代表该特定用户而非共享服务身份行事，凭证按 agent 限定作用域且仅在会话期间存在。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 构建，它将代理工作流组合为图，节点是工具调用或模型调用，边是它们之间的数据依赖关系。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。