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

在受监管行业的质量管理中，解决问题所需的机构记忆几乎总是埋藏在客户的历史记录里。可能是去年调查过的类似缺陷、一个修复了根本原因的纠正与预防措施（CAPA），或是一次标记出相同缺口的审计发现。这些知识存在于数十亿份文档中，没有人能跨越语言和格式按语义相似度进行搜索，因此每次调查都要从零开始。Octave Reliance 一直在帮助每个组织收集多个系统中的文档，让他们更容易搜索并追踪自己拥有的所有资料。Octave Reliance 团队认为，解锁这些历史记录是其帮助客户更快工作并保持合规的最大机遇。障碍同样清晰：投诉记录、审计发现和纠正措施承载着平台最严格的隔离要求，而这些恰恰是 AI 需要读取的记录。在一个服务医疗器械、制药和食品制造领域超过 14,000 家客户的平台上，任何一次客户之间无意的披露所带来的监管后果都远超 AI 带来的任何收益。

Octave 的业务遍及 180 个国家，服务超过 60% 的全球财富 500 强。其云原生质量管理系统 Reliance 通过 40 多个应用程序支持 650 多家企业客户，涵盖投诉管理、CAPA 跟踪、审计管理和供应商质量等。每家客户都生成了 AI 可以进行推理的受监管数据。每个客户都是独立的租户，任何数据都不能跨越租户边界。

面对这种情况，Reliance 团队做出了一个不同寻常的决定：与其先发布某一个 AI 功能，不如把第一个周期用于构建一个所有未来功能都将依托的基础。这一基础此后已将每个用例的部署时间缩短了 50%。如果你正在为一个软件即服务（SaaS）平台引入 AI，其中数据非常有价值，而隔离又不容妥协，那么这些经验的意义就超出了质量管理的范畴。在本文中，我们将深入探讨塑造设计的四大矛盾，以及 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 的数据块可以多个打包进一个请求，新客户接入的吞吐量正是由此而来。

在运行时保持租户隔离

更棘手的问题是在哪里实施租户隔离。应用程序代码可以实现，但这意味着未来每个功能团队都要在每条代码路径上做对，而任何一处遗漏的检查都可能导致无意的跨租户数据泄露。团队转而将隔离推入运行时。作为 Amazon Bedrock AgentCore 一项功能的 AgentCore runtime，在应用层之下实施隔离，并且由于它保持框架和模型无关，因此为投诉分类助手选择的智能体框架和模型并不受这一隔离决策的约束。

每个用户会话都在一个专用的 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），将嵌入的图像作为一等内容处理。分块携带元数据：租户、文档类型、来源应用、语言和内容哈希。这些元数据既驱动检索过滤，也驱动按租户的命名空间强制隔离。

吞吐量的提升来自打包。利用 Embed v4 的 128K 上下文窗口，将多个 4K 数据块交错打包进单个请求，使处理大规模语料库时的 API 调用量减少了大约一个数量级。在 Octave 于 Amazon Bedrock 上的内部测试中，Embed v4 达到了每分钟 2800 万 token 的处理速度。在 Cohere 解决方案架构师的帮助下调整批处理大小直至消除内存瓶颈后，该流水线在每租户工作负载下实现了每 24 小时处理 140 万份文档。正是这一点让“一个工作日内完成”的承诺成为现实。

投诉分类助手

一家医院向医疗器械制造商报告注射器存在缺陷，相关记录以邮件形式送达，附有受损产品的照片和佐证文档。质量处理人员必须将这些不同格式的信息拼凑起来，判断此前是否有类似报告，并找出当时的解决方案。只有在这之后才能确定优先级，而这一切往往要在以天计的报告窗口内完成。

该助手基于 AWS 开源的 Strands Agents SDK 构建，它将智能体工作流组织成图的形式：节点是工具调用或模型调用，边则是它们之间的数据依赖关系。AgentCore 运行时负责执行该图并按会话进行隔离，五个阶段将一份投诉从原始附件处理成一份完成的简报。

第一步是文档提取。PDF、图片、邮件附件和视频全部进入 AgentCore Code Interpreter，由它将每个工件解析为结构化的中间表示。随后，Amazon Bedrock 上的一个 Claude 模型对记录进行摘要，而这份摘要——而非原始的数千 token 源文件——将作为检索查询。检索在租户的 OpenSearch 索引上运行，该索引存储着 Embed v4 生成的嵌入向量，从而找出相似的过往投诉及其 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 位置检索精度以及输出完整性。一段读起来更好但检索效果更差的提示，会在用户看到之前就被发现。

结果

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

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

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

回顾

先构建基础这一决定是团队最初最拿不准的。当利益相关方想要一个看得见的 AI 功能时，数月的基础设施工作很难辩护。而下一批用例证明了这个选择。两个决策支撑了它：将隔离推进到 microVM 会话并采用身份传播而非应用代码，以及针对 Octave 自己的语料库评估嵌入模型，这揭示了 512 维的权衡——任何基准测试都不会显示这一点。

团队还划了一条自己选择不逾越的界线。助手负责呈现上下文和先例，但质量处理员仍然做出判断。在一个该判断具有监管分量的行业里，这条界线决定了哪些环节被自动化，哪些没有。

下一步

Octave 现在正在将这一基础扩展到整个 Reliance 套件。审计就绪监控、事件叙述生成和预测性质量风险评分是接下来的工作，每一项都构建在相同的基础设施之上。

如果你的平台面临类似的张力：有价值的数据处于严格的隔离要求之后。Octave 的经验表明这些权衡是可以解决的。要了解这个故事背后的服务，请参阅 Amazon Bedrock、Amazon Bedrock AgentCore 文档以及 Cohere on Amazon Bedrock。相关的架构指南，请参阅 AWS 向量解决方案：在你的数据所在之处构建智能体 AI 和扩展智能体 AI：无需供应商锁定的企业级模式。