Octave在Amazon Bedrock上构建多租户AI基础，将2.7亿份受监管文档的部署周期缩短一半
Octave Reliance将Cohere Embed v4和Amazon Bedrock AgentCore结合，在保持租户隔离的前提下完成21亿份文档的嵌入，并部署其投诉分诊助手；该公司称，该助手已在生产中运行三个月，每个用例的部署时间减少了50%。
AI解读：Octave原有的难题是：受监管行业客户的投诉记录、CAPA和审计发现都带有最严格的隔离要求，而这些资料恰好是AI需要读取的。因此，该公司选择先搭建一个所有功能共用的横向基础，而不是先交付一个单独的AI功能。
按Octave的说法，这个基础的核心技术路线是用Embed v4把文本和图片放进同一个向量空间，省去单独的图片处理流程，并把向量写入Amazon OpenSearch Service中按租户隔离的存储。据其测试，512 维可以保持目标准确率，存储占用比默认的1536维大约减少66%。
租户隔离不依赖应用层代码，而由AgentCore runtime在应用层之下执行：每个用户会话运行在一个独立microVM中，会话结束后停止并清理内存。AgentCore Gateway还会按工具、操作和参数三个层级审批，因此Tenant A的会话不会连到Tenant B的工具或沙箱。
附件被当作不可信输入处理。Guardrails在附件文本嵌入之前、检索内容进入上下文之前和简报生成之后这三个位置进行过滤；附件内容用input tagging标记为数据，而不是指令。PII在输入时会被遮盖，文档解析在无网络出口的Code Interpreter沙箱内进行。
Octave称，其接入管道通过把多个约4K token的块打包进Embed v4的 128K上下文窗口，把大语料库的API调用次数减少了大约一个数量级；调优后的内部测试达到每分钟2800万token，每个租户工作负载可持续处理每天140万份文档。
Octave称，每次调查原来的4到6小时用于提取、查找先例和阅读记录，现在这部分已由管道完成；新AI能力的开发周期从数月缩短到数周，每个用例的部署时间减少50%。这些均为Octave自身的统计，来源未提供独立的对比基准。
Octave Reliance在AWS机器学习博客中介绍了其多租户AI基础的设计。Octave的云原生质量管理系统Reliance服务超过650家企业客户，覆盖医疗器械、制药和食品制造，业务遍及180个国家。
该平台承载超过21亿份文档，每个租户之间不能有数据流通。负责该项目的团队没有先交付单项AI功能，而是先建设共用基础。该基础完成后，Octave称每个用例的部署时间减少了50%。
最先投入生产的是Complaint Triage Assistant，已在生产环境运行三个月。
先建共用基础，而不是单项功能
Octave与AWS的设想工作坊确定了四个高优先级用例：投诉摘要与分诊、审计准备监控、事件叙述生成和预测性质量风险评分。
这些应用有不同的文档类型和工作流。Octave的判断是，如果单独地为每一个应用单独构建AI功能，下一个功能仍要重建基础设施，因此先建横向平台，再把各项功能接入，投诉摘要与分诊被选为第一个验证对象。
- Reliance支持超过40个应用，包括投诉管理、CAPA跟踪、审计管理和供应商质量。
- 平台文档包含Word文件、PDF、扫描表格、电子表格、图片和邮件，语言不止一种。
- Octave设定目标：最大的租户也要在一个工作日内完成接入。
数据表示与向量存储
Octave没有用公开排行榜选型，而是用自有语料库评估嵌入模型，重点看能否把开裂外壳的照片与描述该缺陷的段落一并检索出来，以及德文投诉能否与英文CAPA关联。
据该文，Cohere Embed v4把文本和图像放在同一个向量空间，并原生支持多语言，因此省去了按模态分别建管道和翻译预处理的需求。
向量存储在Amazon OpenSearch Service的每租户索引中。由于该服务的费用随向量维度线性增长，团队用代表性生产查询做了测试：512 维保持了目标准确率，存储占用比默认的1536维减少约66%。该文章把这些数字列为内部测试结果。
- 在区域内推理是硬性条件：客户数据不能离开所在的AWS区域，Embed v4在美国东部（弗吉尼亚北部）、欧洲（爱尔兰）和亚太地区（东京）支持区域内推理。
- AWS提示模型和功能的区域可用性会变化，读者应查阅Amazon Bedrock用户指南的当前覆盖范围。
租户隔离和不可信内容
Octave把租户隔离放在应用代码之下，交由AgentCore runtime处理。每个用户会话运行在独立microVM中，拥有自己的CPU、内存和文件系统，会话结束即停止并清理。
身份贯穿整个执行链：每用户OAuth令牌库验证代理代表特定用户行事，凭证按代理限定且只在会话期间有效；AgentCore Gateway在工具、操作和参数层级做授权。
附件被视为不可信输入，但又是代理必须读取的内容，因此Octave采用纵深防御。Guardrails在三个位置过滤：附件文本嵌入之前、检索文档和工具输出进入上下文之前、合成简报呈现给处理人之前。
- 附件中提取的文本以input tagging传入，标记为数据而不是指令，使埋藏在文档中部的注入内容可以被检出。
- PII在输入端被遮盖。
- 文档提取在AgentCore Code Interpreter沙箱内执行，无网络出口，超出会话不持久化。
- Octave按租户跟踪检测率和遮盖率，使拦截结果可以被举证，而不只是口头声明。
吞吐来自打包和调度
文档事件经Amazon SNS和Amazon SQS进入AWS Step Functions状态机，状态机在专用Amazon VPC内编排解析、切块和嵌入，并通过并发Lambda执行横向扩展。
解析环节保留Word和电子表格的语义层级，对没有文本层的扫描PDF做OCR，并把嵌入图片当作正式内容处理。每个块带有租户、文档类型、来源应用、语言和内容哈希等元数据，用于检索过滤和租户命名空间约束。
吞吐提升主要来自打包：多个约4K token的块放进Embed v4的 128K上下文窗口，在Octave的测试中把大语料库的API调用次数减少大约一个数量级。与Cohere解决方案架构师调优批次大小后，管道达到每分钟2800万token，每个租户工作负载每天处理140万份文档。
投诉分诊助手的生产表现
助手使用AWS开源的Strands Agents SDK构建，工作流以图的形式组合工具调用和模型调用。流程分五步：Code Interpreter解析PDF、图片、附件和视频；Amazon Bedrock上的Claude模型生成记录摘要；摘要作为检索查询，在租户的OpenSearch索引中查找相似投诉和对应CAPA；另一次模型调用按置信度给结果打分，剔除用词相近但根因不同的匹配；最后由Anthropic Claude Sonnet合成关键事实、情绪、紧急程度、相近历史记录及建议分诊优先级。
完成的简报缓存在Amazon DynamoDB中，按环境设置TTL。入口经私有Amazon API Gateway和Lambda到达AgentCore runtime，检索通过预签名URL和基于角色的访问读取。
Octave称，助手已生产运行三个月。每次调查原来需要4到6小时用于提取、查找先例和判断是否为同一缺陷，现在这段时间由管道承担。该公司还称，新AI能力的开发周期从数月缩短到数周。
- 可观测性用于审计，不只是调试：AgentCore记录每个模型调用、检索和Code Interpreter运行的OpenTelemetry兼容轨迹。
- Amazon Bedrock的模型调用日志按租户记录每次请求和响应，成本在Amazon CloudWatch中归到发起租户。
- AgentCore Evals在提示、模型或检索参数变更后，用专家标注的基准数据重跑工作流，报告摘要忠实度、检索精度和输出完整度。