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

在受监管行业的质量管理中，能够解决问题的组织记忆几乎总是埋藏在客户历史记录的某个角落：去年调查过的类似缺陷、修复了根本原因的纠正与预防措施（CAPA），或指出同一漏洞的审计发现。这些知识分散在数十亿份文档中，没有任何人能够跨语言和格式按语义相似性进行搜索，因此每次调查都不得不从头开始。Octave Reliance 一直在帮助各组织跨多个系统收集文档，以便更轻松地搜索并跟踪其全部内容。Octave Reliance 团队认为，解锁这些历史记录是帮助客户加快工作并保持合规的最大机遇。障碍同样明确：投诉记录、审计发现和纠正措施包含平台最严格的隔离要求，而这些正是 AI 需要读取的记录。在一个服务于医疗器械、制药和食品制造行业超过 14,000 家客户的平台上，一家客户向另一家客户意外披露信息，其监管后果将远远超过任何 AI 所能带来的收益。

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

面对这一情况，Reliance 团队做出了一个不同寻常的决定：它没有直接推出一项 AI 功能，而是用第一个周期构建了一套基础架构，让未来的每项功能都建立在其之上。这套基础架构随后将每个用例的部署时间缩短了 50%。如果你正在为一个数据具有高价值、但隔离要求不可妥协的软件即服务（SaaS）平台引入 AI，那么其中的思路并不局限于质量管理。在本文中，我们将介绍影响设计的四项矛盾，以及 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 区域，即使是用于推理也不行，因此 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 的一项功能，可在应用程序层以下强制实施隔离；由于它不依赖特定框架或模型，投诉分流助手所选用的智能体框架和模型不会受到隔离方案的限制。

每个用户会话都在专用微型虚拟机中运行，拥有独立的 CPU、内存和文件系统；会话结束后，虚拟机会停止运行并清除数据。这种硬件级隔离旨在确保无论智能体如何运行，隔离都能得到维持。AgentCore 会在整个执行链中传递经过身份验证的用户身份：每用户 OAuth 令牌保险库会验证智能体是代表该特定用户行事，而非使用共享服务身份；凭证按智能体限定范围，且仅在会话期间有效。AgentCore Gateway 在工具、操作和参数级别进行授权。自动化推理可针对已定义的规则进行形式化验证。这与 IAM 和 Amazon Simple Storage Service (Amazon S3) 策略验证所遵循的是同一套严谨做法。图 2 展示了两个租户之间的隔离机制。

图 2：AgentCore 中各租户之间的会话隔离。每个 microVM 使用后都会停止运行，并清除内存。

因此，租户 A 的质量专员提交的投诉只会访问 AgentCore Code Interpreter（Amazon Bedrock AgentCore 的一项功能）中租户 A 的令牌库、工具和沙箱。租户 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 runtime 运行该图并按会话隔离；五个阶段将投诉从原始附件处理成完整简报。

首先进行文档提取。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 runtime；检索通过基于角色的访问和预签名 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 percent，因为每项新功能都能继承这些能力，而无需从头重建。由此，语义搜索在 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 的合作伙伴关系，并帮助客户集成复杂的生成式 AI 解决方案。

Nate Stecz

Nate 是高级合作伙伴开发经理，通过 AWS 合作伙伴关系帮助领先的生成式 AI 模型提供商提升收入。Nate 在 Amazon Web Services 任职近 10 年。他常驻华盛顿州西雅图，喜欢户外活动，也热衷于了解新兴技术。你可以在 LinkedIn 上联系或关注 Nate。