人工智能
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%。如果你要将 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的一项能力，它在将请求交给调用 Amazon Bedrock 上 Anthropic Claude 模型的隔离 microVM 会话之前应用身份验证和策略。内容保护层包裹两者，两次应用 Amazon Bedrock Guardrails：输入时进行输入过滤，输出时在内容到达处理程序之前进行输出过滤。检索、执行和筛查保持在独立阶段，因此每个阶段都可以单独强制执行和取证。
图 1：Reliance AI 基础的高层架构
如何选择数据的表示方式
在文档变得可检索之前，其他方法都行不通。这意味着要跨语言、跨格式准确检索，且不跨越租户边界。团队针对自己的语料库而非公开排行榜来评估嵌入模型。决定性的问题都针对这份数据：一张外壳开裂的照片与描述它的段落有什么关系，一份德语投诉与一份英语 CAPA 又有什么关系。
Amazon Bedrock 上的 Cohere Embed v4 在五个方面胜出，而这五个方面并非彼此独立。首先决定的是有多少流水线环节变得不再必要。质量记录中除了文本，还带有缺陷产品照片、扫描的检验表单和带注释的图表。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 的一项能力，它在应用层之下强制执行隔离，并且由于它保持框架和模型无关，为投诉分诊助手选择的智能体框架和模型不受隔离决策的约束。
每个用户会话都在专用的 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 中，并设置按环境的生存时间（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 能力的开发周期从数月缩短到数周。共享的数据准备、安全执行和检索是 Figure 1 的三个层次。它们将每个用例的部署时间缩短了 50%，因为每项新能力都继承这些层次，而不是重新构建。这使得语义搜索在第二季度上线，比原定的第四季度目标提前了两个季度。
回顾
先构建基础这一决定是团队事后最常质疑的一个。当利益相关者想要一个看得见的 AI 功能时，数月的基础设施工作很难辩护。下一轮用例已经证明了它的价值。有两个选择支撑了它：将隔离推进到 microVM 会话，以及将身份传播而非应用代码作为载体；还有针对 Octave 自己的语料库评估嵌入模型，这揭示了 512 维的权衡，而任何基准测试都不会显示这一点。
团队还划定了一条选择不跨越的界线。助手呈现上下文和先例。质量处理人员仍然做出最终决定。在一个该决定承载监管分量的行业中，这一边界决定了哪些被自动化、哪些没有。
下一步
Octave 现在正在将基础扩展到 Reliance 套件。审计准备监控、事件叙述生成和预测性质量风险评分是接下来的项目，每一项都构建在相同的基础设施之上。
如果您的平台面临类似的矛盾：有价值的数据处于严格的隔离要求之后。Octave 的经验表明这些权衡是可行的。要了解更多关于本故事背后的服务，请参阅 Amazon Bedrock、 Amazon Bedrock AgentCore 文档和 Amazon Bedrock 上的 Cohere。有关相关架构指导，请参阅 AWS 向量解决方案：在数据所在之处构建智能体 AI 和 扩展智能体 AI：无供应商锁定的企业模式.