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 选择的代理框架和模型不受隔离决策的约束。

每个用户会话都在一个专用 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 中，并带有按环境设置的时间 to live（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 处检索精确率和输出完整性。一个读起来更好但检索更差的提示词会在用户看到之前被捕获。

结果

投诉分诊助手已在生产环境中运行三个月，以下数字反映了这一期间的情况。

过去一无所知就开始调查的处理人员，现在打开调查时相关历史已经整理完毕。Octave 测得的每次调查 4–6 小时，是流水线所吸收的工作：跨格式提取、寻找先例，以及区分真正相似的缺陷与措辞巧合所需的阅读。

该基础还改变了 Octave 交付的速度。按其自己的统计，新 AI 能力的开发周期从数月缩短到数周。共享的数据准备、安全执行和检索是图 1 的三个层次。它们将每个用例的部署时间缩短了 50%，因为每个新能力都继承它们，而不是重新构建。这使语义搜索在第二季度落地，比原定第四季度目标提前了两个季度。

回顾

先构建基础的决定是团队事后质疑最多的一个。当利益相关者想要一个看得见的 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。