AWS发布的一篇案例文章介绍了Octave为质量管理系统Reliance构建的共享AI基础架构。按照文章披露，Octave在180个国家开展业务，服务对象覆盖全球财富500强企业的60%以上。Reliance通过40多个应用支持650多家企业客户，功能涉及投诉管理、纠正与预防措施跟踪、审计管理和供应商质量，系统托管的文档超过20亿份。

这些文档属于不同客户。案例将每个客户定义为独立租户，要求数据始终留在相应租户边界内。围绕这一要求，Octave没有从单个功能开始搭建，而是先建立可供多个AI应用使用的共同基础。首个落地场景是投诉摘要与分流，设计同时处理用户权限、非可信内容以及大规模文档接入问题。

先建立共同基础，再开发具体应用

Octave与AWS开展的研讨还确定了审计准备状态监测、事件叙述生成和预测性质量风险评分等方向。文章描述的先后关系是，投诉助手先使用共同基础，后续场景继续沿用这套能力。对于文档接入，企业提出即使是规模最大的租户，也应在一个工作日内完成接入的承诺；这项承诺需要与文章另外披露的吞吐量测试分别理解。

架构把文档准备、智能体执行和内容保护结合起来。文档通过Amazon Bedrock上的Cohere Embed v4生成向量，向量存入各租户独立的Amazon OpenSearch Service存储。智能体通过AgentCore Gateway和隔离会话调用Bedrock上的Anthropic Claude，内容控制则使用Amazon Bedrock Guardrails。文章将多模型统一API、AWS区域内的数据驻留、IAM治理和托管内容控制列为选择Bedrock的原因。

检索质量与文档处理规模

Octave使用自身文档语料评估嵌入模型。文章称，Embed v4可把文本和图像放入同一向量空间，也可在不预先翻译的情况下进行多语言检索。这意味着案例所述的检索准备流程同时涉及文字、图片和不同语言，而不是只对单一语言的纯文本建立索引。

在Octave的内部测试中，512维向量保持了目标准确度，与1536维相比，存储需求约减少66%。模型支持的输出维度范围为256至1536维。这里的准确度和存储结果对应企业自己的语料及测试，文章没有提供独立验证，也没有证明相同比例适用于其他文档集合。

文章还列出了发布时北弗吉尼亚、爱尔兰和东京的区域内推理可用性，并提醒可用性会变化。因此，这部分属于发布时的平台情况，不能据此判断此后各区域的实时支持状态。它与企业选择区域驻留能力的设计考虑有关，但不构成当前可用性的确认。

文档事件先经过Amazon SNS和SQS，再交给Step Functions协调处理。解析、分块和嵌入生成由专用VPC中的多个Lambda执行并行完成。解析过程保留Word文档和电子表格中的语义层级，对没有文本层的扫描PDF执行OCR，并处理文档内嵌图像。不同输入因此进入共同的文档准备流程。

每个文档块附带租户、文档类型、来源应用、语言和内容哈希等元数据。这些字段用于检索过滤和执行租户命名空间限制。对投诉助手而言，搜索不仅要找到内容相关的材料，也要在对应租户的文档范围内完成；案例中的向量存储与元数据过滤共同服务于这一要求。

Octave将约4000个token的文档块打包到请求中，利用Embed v4的128000个token上下文窗口。企业报告，这使大型语料的API调用次数减少约一个数量级，内部Bedrock测试达到每分钟2800万个token。随后，团队与Cohere解决方案架构师调整批次大小以处理内存瓶颈，最终持续达到每个租户工作负载每24小时处理140万份文档。

这些数字分别描述请求打包、内部token吞吐量和文档处理速度。它们没有证明全部20多亿份文档在一天内处理完毕，也不能直接确定每位客户的实际接入时间。一个工作日接入最大租户是文章记载的企业承诺，每24小时140万份则是特定租户工作负载下披露的处理结果。

会话隔离、身份传递与内容检查

根据案例，AgentCore在应用层以下执行隔离，并保持对智能体框架和模型的独立性。每个用户会话获得专用microVM，拥有自己的CPU、内存和文件系统。会话结束后，环境被停止并清理。身份通过每用户OAuth令牌保管库，以及限定于会话和智能体的凭证传递，执行过程因此沿用请求用户的身份。

Gateway分别在工具、操作和参数层面控制授权，并使用自动化推理检查已定义的规则。工具访问限制与会话隔离承担不同的控制环节：前者规定能够调用什么，后者分隔执行环境。文章描述了这些机制，但并未证明它们可以排除所有数据泄露或提示注入的可能。

内容检查贯穿输入、检索和输出。附件文本在生成向量前经过ApplyGuardrail API，检索文档和工具输出在进入智能体上下文前接受检查，合成后的简报在交付前再次检查。附件内容被标记为数据，个人身份信息在接入时进行掩码处理。检测率和掩码率按租户跟踪，使这些控制的运行情况也具有租户维度。

文档提取运行在AgentCore Code Interpreter沙箱内，该环境没有向外的网络访问，也不会在会话结束后保留数据。这个环节负责把附件转换为后续处理所需的内容；Gateway对工具的限制以及Guardrails对内容的检查，则覆盖流程中的其他位置。案例描述的是多处控制的组合，而非单一检查步骤。

投诉如何形成辅助判断

Complaint Triage Assistant使用Strands Agents SDK，将工作流程表示为图，并在隔离的AgentCore会话中执行。Code Interpreter从PDF、图像、电子邮件附件和视频中提取结构化表示。Claude先生成摘要，再用该摘要查询当前租户的OpenSearch向量数据，从已有材料中寻找相关案例。

检索之后还有单独的模型调用，对匹配结果评分，并剔除根本原因不同的案例。因此，向量检索得到的相近内容不会直接全部成为最终依据。随后，Claude Sonnet汇总关键事实、情绪倾向、紧急程度信号和历史处理结果，形成建议的分流优先级。助手提供背景、先例和建议，质量处理人员保留最终决定权。

完成的简报缓存在DynamoDB中，存活时间按环境设置。门户请求通过私有API Gateway和Lambda到达AgentCore。文档访问采用基于角色的权限与预签名URL，附件仍存放在S3。案例分别说明了请求入口、文档授权和附件存储的位置，并未把简报缓存等同于原始附件存储。

运行记录方面，AgentCore采集兼容OpenTelemetry的追踪，覆盖模型调用、检索和Code Interpreter执行。Bedrock调用日志按租户记录请求与响应，CloudWatch将成本归属到发起请求的租户。这些记录对应模型执行、信息获取、文档提取以及成本归属等不同环节。

评估、企业披露的结果与后续方向

提示词、模型或检索参数改变后，AgentCore Evals会依据专家标注的标准答案重新运行工作流程。评估指标包括摘要对原文的忠实程度、前K项检索结果的精确率，以及输出完整性。文章把持续评估与这些具体变更联系起来，而不是仅以模型输出是否流畅衡量效果。

文章报告了三个月的生产运行情况，并称助手承担了Octave估计每次调查需花费四至六小时的工作，包括提取内容、查找先例和评估相似缺陷。这一说法描述被助手接手的任务量，并不表示所有调查都可缩短相同时间，也不改变由质量人员作出最终判断的安排。

Octave还表示，共享基础设施使每个AI用例的部署时间减少50%，开发周期从数月缩短到数周。语义搜索在第二季度交付，比原定第四季度提前两个季度。企业正在把共同基础扩展到审计准备监测、事件叙述生成和预测性质量风险评分；文章未将这些后续方向全部描述为已经部署。

上述架构与结果均来自这一篇AWS案例。所提供的材料没有对性能、准确度、存储节省或开发周期测量给出独立佐证。阅读这些数据时，需要保留其企业内部测试及特定工作负载的范围，同时区分已报告的投诉助手运行情况与仍在扩展中的其他用途。

来源：AWS案例文章。