康泰纳仕用亚马逊Bedrock做视频语义搜索，检索时间从 250 分钟降到 2 分钟
康泰纳仕编辑团队此前检索一条视频平均要花 250 分钟，只能在 14 万多条视频的库里靠标题和描述手动翻找。它和AWS生成式AI创新中心合作，用TwelveLabs Marengo嵌入模型和亚马逊OpenSearch搭出一套多模态检索方案，按AWS博客披露的数据，单次任务检索时间降到约 2 分钟。
AI解读：康泰纳仕的问题不是视频不够，而是找不到。14 万多条视频只能靠标题和描述检索，编辑平均一次要花 250 分钟手动翻片，能不能找到还严重依赖某几个老员工记不记得。这次它把检索对象从文字元数据换成了视频本身的画面、音频和字幕，单次任务时间降到约 2 分钟。
真正起作用的是“意图搜索”。编辑想找的是“适合初学者的瑜伽内容”或“时装周幕后花絮”，而不是文件名，所以方案用TwelveLabs Marengo把画面、声音、字幕联合编码成向量，再用亚马逊OpenSearch做近邻搜索，返回具体时间戳而不只是整条视频。
对管着大视频库的团队来说，这项变化的价值在于把档案里原本搜不到的素材重新变成可用资产，同时降低对个别人记忆的依赖。但要注意，99.2% 的降幅、约 80 万美元年节省都来自康泰纳仕 2026 年 5 月的基准测试，是它自己的测量结果，不是通用承诺。
还有一个工程细节值得留意：生成向量贵且慢，查询要求快，所以方案把入库和检索拆成两层，向量生成走异步。这套架构已经跑了六个月，补数据时检索仍可用。前提是你得有 14 万条量级的视频、愿意接一套云上管线，小团队未必划算。
康泰纳仕的编辑团队此前没有快速做多模态视频检索的办法。按AWS机器学习博客作者Mariah Miller的描述，他们平均每个内容检索任务要花 250 分钟，在超过 14 万条视频的素材库里手动翻找，检索依据只有标题和描述。
这套流程给Vogue、GQ、Vanity Fair、Wired等品牌带来可测量的运营拖累。博客称，在媒体行业里上市速度直接决定收入获取。问题的根源是结构性的：既有搜索工具无法看进视频内容内部，团队只能靠个人经验定位素材，特定人员不在时就形成单点故障；同时大量未被充分利用的内容躺在库里无法被发现，因为标题或描述里没有任何关键词能连上编辑实际发起的查询。
为此康泰纳仕与AWS生成式AI创新中心合作，构建了一套AI驱动的多模态视频检索方案。方案基于Amazon Bedrock和Amazon OpenSearch Service，对视频字幕、视觉元素和音频做基于意图的语义搜索。团队选择了TwelveLabs Marengo嵌入模型，原因是它能原生地把视觉、音频和字幕信号联合编码。博客称该方案把每个任务的检索时间从 250 分钟降到 2 分钟以内。
这篇文章介绍了架构、技术选型理由和业务结果。以下事实来自该AWS博客，业务数据均为康泰纳仕自行测量的结果。
为什么必须放弃关键词搜索
团队界定问题时有两个约束决定了方案设计。第一，关键词搜索根本不够用。编辑不会去搜“yoga_tutorial_march_2024.mp4”，而是搜“有舒缓背景的初学者瑜伽内容”或“时装周幕后瞬间”。搜索层需要理解意图而不是匹配字符串，这直接指向能跨模态（视觉、音频、字幕）捕捉语义的向量嵌入，仅靠人工撰写的元数据无法达到这种理解程度。
第二，视频库超过 14 万条，规模大到任何方案都必须把昂贵的、计算密集的嵌入生成工作与低延迟的搜索结果服务工作分开。单体架构会迫使团队在入库吞吐和查询响应之间做取舍。解耦后两个平面可以独立扩展、独立失败、独立演进。博客称这个决定在回填处理时被证明至关重要。
- 编辑的实际查询是“有舒缓背景的初学者瑜伽内容”，不是文件名。
- 14 万条视频的规模要求把嵌入生成和结果服务解耦。
技术栈怎么搭：Bedrock管模型、OpenSearch管检索
方案的核心设计是：向量嵌入由Amazon Bedrock上的TwelveLabs Marengo模型生成，索引进Amazon OpenSearch Service，再通过专门构建的查询层提供服务。该查询层把自然语言转成向量搜索，返回精确的时间戳。
团队通过Amazon Bedrock访问Marengo，因为Bedrock用单一API提供一系列基础模型，并施加AWS治理控制，包括用AWS Identity and Access Management做访问控制、用Amazon Virtual Private Cloud做网络隔离、用AWS CloudTrail做审计。博客称，这一组合让团队无需自建或运维模型服务基础设施就能采用专用嵌入模型。
向量索引方面，Amazon OpenSearch Service提供托管的k近邻搜索，支持多可用区复制和混合查询用的元数据过滤。团队因此可以在超过 14 万条视频上运行低延迟相似度搜索，而不用管理底层搜索集群。
- 嵌入模型：Amazon Bedrock上的TwelveLabs Marengo。
- 向量索引：Amazon OpenSearch Service的k-NN搜索。
- 治理控制：IAM做访问、VPC做隔离、CloudTrail做审计。
五项检索能力与两层架构
博客列出该方案为编辑团队提供的五项能力：基于意图的搜索，用户用自然语言描述需求（例如“初学者瑜伽内容”或“关于可持续性的名人采访”），得到带精确时间戳的相关片段；多模态理解，检索同时覆盖字幕、视觉元素和音频，一条片段可以因为说了什么、显示了什么或听到了什么而被发现；基于图片的查询，用户可以上传参考图，在档案中找视觉上相似的内容；拼写容错与意图解析，搜索层处理不精确的查询，关注含义而非精确关键词匹配；时间戳精度，结果精确到视频内的具体时刻，减少观看整条片段的需要。
架构上方案分成两个解耦的平面：一个是把视频变得可检索的异步入库管线，另一个是处理用户查询的同步服务层。
入库和索引平面：新视频上传到存放源视频的Amazon S3存储桶后，事件被触发，把视频元数据推进入库流程并协调管线；入库服务校验视频并提取格式、时长、分辨率等元数据；同一入库服务在Amazon Elastic Container Service上以AWS Fargate运行，把视频切分成片段，Auto Scaling组跨多个可用区横向扩展以并行处理；每个片段通过Amazon Bedrock上TwelveLabs Marengo模型的异步调用处理，生成跨视觉、音频、字幕维度的多模态向量嵌入；生成的嵌入写入一个Amazon S3存储桶以保证持久性，并索引进Amazon OpenSearch Service集群做向量相似度搜索。
博客称该管线事件驱动、端到端编排，提供按步骤重试、跨片段并行处理和完整可追溯性，这些能力在最初 14 万条视频回填时被大量依赖。
查询和服务平面：请求经互联网网关进入VPC，到达外部应用负载均衡器，再分发到Amazon ECS on AWS Fargate上的前端服务；前端服务通过内部负载均衡器调用搜索服务，两个服务都由Auto Scaling组跨多个可用区扩展；搜索服务把用户查询转成向量嵌入，对OpenSearch索引做k近邻相似度搜索；搜索服务从Amazon DocumentDB读取视频元数据（标题、缩略图、引用）来丰富结果；合并后的结果带相关片段和精确时间戳返回给用户。
- 检索入口是自然语言描述，不是文件名。
- 可上传参考图找视觉相似内容。
- 结果返回视频内精确时间戳，而非整条视频。
- 入库管线异步，查询服务同步，两层各自跨可用区扩展。
高可用与实测结果
方案整体多可用区部署。OpenSearch Service跨三个可用区同步复制（两个活跃、一个待命）；Amazon DocumentDB用主节点加待命副本跨两个可用区；入库服务、前端服务和搜索服务都用跨可用区分布的Auto Scaling组，由负载均衡器绕开故障节点；计算和数据工作负载位于私有子网，只有外部负载均衡器可公开访问，出站流量经NAT网关。
康泰纳仕在 2026 年 5 月做了一次基准测试工作坊来量化影响。博客称以下结果反映康泰纳仕在该工作坊中的测量：内容检索时间减少 99.2%，从每任务 250 分钟降到约 2 分钟；人工视频审看工作量减少超过 90%，团队拿到的是带精确时间戳的目标片段而不是逐条翻片；基于减少重复人工搜索带来的生产力提升，估计每年节省约 80 万美元运营成本；资产可发现性改善，此前利用不足的视频通过纯元数据搜索无法识别的语义连接被浮现出来；收入获取加速，更快发现意味着更快响应广告主请求和销售机会，缩短从询价到变现的路径。
康泰纳仕全球创意优化高级总监Billy Keenly在博客中说：“AWS团队以及GenAI和TwelveLabs的与会者帮我们把商业理由讲得清晰简洁。我对不久后在流程目标上取得更多进展感到乐观。”
- 检索时间：250 分钟降至约 2 分钟，降幅 99.2%（康泰纳仕 2026 年 5 月基准测试）。
- 人工视频审看工作量减少超过 90%。
- 估计年运营节省约 80 万美元。
- 全部业务数据为康泰纳仕自行测量，非AWS或第三方独立验证。
六个月生产运行中的经验
博客总结了在超过 14 万条视频库上构建这套方案得到的实践教训。早期用户研究塑造了整个嵌入和查询设计：团队访谈编辑人员，了解他们如何用自己的话描述内容，这些对话定义了语义搜索的合适抽象层级，没有这个基础，系统可能为没人真正输入的查询做优化。
入库与服务分离在这个规模上被证明是必要的。两个平面可以独立演进、扩展和失败。博客称方案已在生产运行六个月，入库管线重处理回填内容或接收更新时，生产搜索保持可用。
找到合适的视频片段长度需要刻意实验。片段太短会丢失上下文，太长会稀释语义信号，针对真实编辑查询的迭代基准测试把团队推向一个平衡精确率和召回率的时长。
在这个规模上，异步嵌入生成没有商量余地。对嵌入模型做同步调用会在 14 万多条视频上形成瓶颈，通过AWS Step Functions做异步调用让管线在不阻塞的情况下处理积压，这也仍是持续入库的模式。从一开始就内置多可用区可用性避免了昂贵的事后改造：对编辑团队全天依赖的方案，哪怕短暂中断也直接意味着生产力损失，一开始就建比后来补便宜。
- 方案已在生产运行六个月，回填期间搜索未中断。
- 片段长度经过迭代基准测试才确定。
- 同步调用嵌入模型在 14 万条视频规模上会形成瓶颈。
- 多可用区能力从第一天内置，未事后补建。
适用边界与未知信息
博客称这套模式适用于管理大型视频库的组织，包括广播机构、流媒体服务、体育联盟和企业媒体团队；解耦架构可随多模态AI能力演进适配不同的嵌入模型和内容类型。
需要说明的是，来源为AWS博客的单方叙述，除康泰纳仕员工的乐观表态外，未提供第三方验证，也未披露基准测试工作坊的方法细节、样本量或具体测法。99.2% 的降幅和约 80 万美元年节省均为康泰纳仕自行测量和估算，不能当作其他组织的预期收益。博客提到康泰纳仕内部检索依赖曾形成单点故障，但未给出具体人员、岗位或因此损失的收入数字。
关于方案本身，博客未披露用量成本、Marengo模型版本、片段长度最终取值、回填具体耗时，以及图像检索能力是否有准确率数据。
- 适用对象是管理大型视频库的广播、流媒体、体育联盟和企业媒体团队。
- 数据来源为康泰纳仕自测，缺少第三方验证和方法细节。
- 未披露成本、模型版本、最终片段时长和图像检索准确率。