20亿文档检索如何守住租户边界

在受监管行业的质量管理中，解决问题所需的组织历史经验，几乎总是埋藏在客户的历史记录中：去年调查过的类似缺陷、消除根本原因的纠正和预防措施（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 亿份文档生成嵌入向量，以及投诉分诊助手如何在生产环境中验证这套架构。

为什么先建基础架构，而不是开发功能

与 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）治理机制，并通过护栏提供生产级内容控制，无须自行构建。

这套基础架构分为三层，如图 1 所示。数据准备层使用 Amazon Bedrock 上的 Cohere Embed v4，为质量管理文档生成嵌入向量，并写入 Amazon OpenSearch Service 上按租户独立设置的向量存储。安全执行层将用户请求传入 Amazon Bedrock AgentCore 的 AgentCore Gateway，由其完成身份验证和策略检查，再将请求交给隔离的 microVM 会话，由该会话调用 Amazon Bedrock 上的 Anthropic Claude 模型。内容保护层覆盖前两层，在两个环节应用 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，一次请求可以容纳许多这样的文本块，这正是租户接入吞吐量的来源。

在运行时隔离租户

更难的问题是，应该在哪一层强制实施租户隔离。通过应用代码实现也能奏效，但这意味着未来每个功能团队都必须在每条代码路径上正确实现隔离，只要漏掉一次检查，就可能造成意外的跨租户数据泄露。因此，团队将隔离机制下沉到了运行时。Amazon Bedrock AgentCore 的 AgentCore runtime 在应用层之下强制实施隔离；同时，由于它独立于框架和模型，为投诉分诊助手选择智能体框架和模型时，也就不会受到隔离方案的限制。

每个用户会话都在专属的 microVM 中运行，拥有独立的 CPU、内存和文件系统；会话结束后，microVM 会停止运行并完成清理。这种硬件级隔离旨在确保无论智能体如何行动，隔离都能成立。AgentCore 将经过身份验证的用户身份贯穿整个执行链：每用户独立的 OAuth 令牌保管库用于验证智能体代表的是该特定用户，而非共享的服务身份；凭证的作用域限定到单个智能体，且仅在会话期间有效。AgentCore Gateway 在工具、操作和参数层面进行授权。自动推理则依据已定义的规则提供形式化验证。这与 IAM 和 Amazon Simple Storage Service（Amazon S3）策略验证背后采用的是同一套严谨方法。图 2 展示了两个租户之间的隔离机制。

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

因此，租户 A 的质量处理人员提交的投诉，只能访问租户 A 的令牌保管库、工具，以及 Amazon Bedrock AgentCore 的 AgentCore Code Interpreter 功能中属于租户 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），并将嵌入的图像作为一等内容处理。每个分块都携带元数据，包括租户、文档类型、源应用、语言和内容哈希。这些元数据既用于检索过滤，也用于强制执行每租户的命名空间隔离。

吞吐量的提升来自批量打包。利用 Embed v4 的 128K 上下文窗口，将多个 4K 分块交错打包进单次请求，使大型语料库所需的 API 调用次数减少了约一个数量级。在 Octave 基于 Amazon Bedrock 的内部测试中，Embed v4 达到了每分钟处理 2,800 万个 token 的吞吐量。在与 Cohere 的解决方案架构师共同调整批次大小、消除内存瓶颈后，流水线针对每个租户的工作负载，能够持续实现每 24 小时处理 140 万份文档。正是这一点，让一个工作日内完成接入的承诺成为现实。

投诉分诊助手

一家医院向医疗器械制造商报告注射器存在缺陷，提交的记录附带了电子邮件、受损产品的照片以及支持文档。质量处理人员必须从这些不同格式的材料中拼出完整背景，查明此前是否有人报告过类似问题，并找到当时的解决办法。只有完成这些工作，才能确定优先级，而报告时限往往只有几天。

该助手使用 AWS 开源的 Strands Agents SDK 构建。这个 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 将同一流程简化为一条直线，并在两端通过护栏进行过滤。

图 5：投诉分诊助手从摄取到处理人员所见输出的流水线

证明智能体做了什么

这里的可观测性不仅用于工程团队调试，也用于与系统审计能力集成，以满足合规要求。审计人员可能会问，为什么某条投诉被如此分诊，而“这是模型决定的”无法成为站得住脚的回答。

AgentCore 会在图中的每个节点捕获兼容 OpenTelemetry 的跟踪数据，涵盖每次模型调用、检索和 AgentCore Code Interpreter 运行。即使数月之后，Octave 仍能展示某份简报由哪些检索文档和提示词生成。Amazon Bedrock 的模型调用日志进一步按租户记录每一次请求和响应，其作用域由 AgentCore 传递的 IAM 身份限定，相关成本则在 Amazon CloudWatch 中归属于发起请求的租户。

在线下，每当提示词、模型或检索参数发生变化后，AgentCore Evals 都会以专家标注的标准答案为基准重新运行工作流，报告摘要忠实度、前 K 项检索精确率和输出完整性。某个提示词即使让文字读起来更好，只要降低了检索质量，也会在用户看到之前被发现。

投诉分诊助手已在生产环境中运行三个月，以下数据反映的就是这段时间的情况。

过去，处理人员启动调查时手头一无所有；如今，开始调查时，相关历史资料已经整理就绪。Octave 测得每次调查节省的 4–6 小时，正是流水线承担下来的工作：跨格式提取内容、寻找历史先例，以及阅读材料，分辨究竟是真正相似的缺陷，还是仅仅措辞上的巧合。

这套基础架构也加快了 Octave 的交付速度。据 Octave 自身统计，新 AI 功能的开发周期已从数月缩短至数周。图 1 中的三个层次分别是共享数据准备、安全执行和检索。它们将每个用例的部署时间缩短了 50%，因为每项新功能都能直接复用这些层次，无需重新构建。这使得语义搜索在第二季度就已上线，比原定的第四季度目标提前了两个季度。

先构建基础架构，是团队最反复质疑的一项决定。当利益相关方希望看到实实在在的 AI 功能时，很难为耗时数月的基础设施工作辩护。后续一批用例验证了这一决定的价值。其中有两项关键选择：一是将隔离机制下沉到 microVM 会话和身份传递层，而不是在应用代码中实现；二是使用 Octave 自有语料库评估嵌入模型，从而发现了采用 512 维向量所涉及的取舍，而这是任何基准测试都无法揭示的。

团队还划定了一条明确不跨越的边界：助手负责提供上下文和既往案例，最终决定仍由质量管理人员作出。在一个决策具有监管意义的行业中，这条边界决定了哪些工作可以自动化，哪些不能。

Octave 目前正将这套基础架构扩展到整个 Reliance 套件。接下来将推出审计就绪状态监控、事件叙述生成和预测性质量风险评分，所有这些功能都将构建在同一套基础设施之上。

如果你的平台也面临类似的矛盾：数据价值很高，却受到严格隔离要求的限制，那么 Octave 的经验表明，这些取舍是可以妥善处理的。要进一步了解本文涉及的服务，请参阅 Amazon Bedrock、Amazon Bedrock AgentCore 文档，以及 Amazon Bedrock 上的 Cohere。有关相关架构指导，请参阅《AWS 向量解决方案：在数据所在之处构建智能体式 AI》和《扩展智能体式 AI：避免供应商锁定的企业级模式》。