视频语义搜索正在为各行各业释放新的价值。以视频为先的体验需求正在重塑组织提供内容的方式，客户也希望能快速、准确地访问视频中的特定时刻。比如，体育转播方需要精准找出球员得分的瞬间，及时向观众推送精彩片段；影视公司需要在数千小时的存档内容中找出某位演员出现的所有场景，以制作个性化预告片和宣传内容；新闻机构则需要按情绪、地点或事件检索素材，以比竞争对手更快发布突发报道。目标是一致的：更快把视频内容交付给终端用户，捕捉关键时刻，并将这种体验变现。
与文本或图像等其他模态相比，视频天然更复杂，因为它融合了多种非结构化信号：屏幕中展开的视觉画面、环境音和音效、口语对话、时间信息，以及描述该资源的结构化元数据。用户搜索“伴有警笛声的紧张追车场面”时，同时在描述一个视觉事件和一个音频事件。用户按姓名搜索某位运动员时，找的也可能是一个在画面中明显出现、但从未被口头提及的人。
当前主流做法是先把所有视频信号转成文本，无论是通过转录、人工打标还是自动字幕，然后再用文本嵌入做搜索。对于对白较多的内容，这种方式可以奏效；但把视频转换成文本，必然会丢失关键信息。时间维度的理解会消失，视觉和音频质量问题也会带来转录错误。如果有一种模型可以处理所有模态，并在不丢失细节的情况下，直接把它们映射到统一的可搜索表示中，会怎样？Amazon Nova Multimodal Embeddings 就是这样一种统一嵌入模型，它可以原生处理文本、文档、图像、视频和音频，并映射到共享的语义向量空间中，同时具备领先的检索准确率和成本效率。
本文将介绍如何在 Amazon Bedrock 上使用 Nova Multimodal Embeddings 构建一套视频语义搜索方案，使其能够智能理解用户意图，并同时跨所有信号类型检索准确的视频结果。文中还提供了一个可部署、可用自有内容进行探索的参考实现。
图 1：最终搜索方案示例截图
解决方案概览
我们的方案构建在 Nova Multimodal Embeddings 之上，并结合了一种智能混合搜索架构，在所有视频模态上融合语义信号与词法信号。词法搜索匹配精确关键词和短语，语义搜索理解含义和上下文。后文将说明我们为何选择这种混合方法，以及它在性能上的优势。
图 2：端到端解决方案架构
该架构由两个阶段组成：一是摄取流水线（步骤 1-6），将视频处理为可搜索的嵌入；二是搜索流水线（步骤 7-10），智能地把用户查询路由到这些表示上，并将结果合并为排序列表。以下是各步骤的细节：
这套灵活的架构解决了多数视频搜索系统容易忽视的四个关键设计决策：保持时间上下文、处理多模态查询、在海量内容库上扩展，以及优化检索准确率。完整参考实现已发布在 GitHub 上，建议结合下文的讲解一起查看，以了解每项设计决策如何帮助系统在所有信号类型上实现准确且可扩展的搜索。
为保持上下文连续性进行分段
在生成任何嵌入之前，首先需要把视频划分为可搜索的单元，而划分边界会直接影响搜索准确率。每个分段都会成为检索的原子单元。分段太短，会丢失赋予某一时刻意义的上下文；分段太长，又会把多个主题或场景混在一起，稀释相关性，使搜索系统更难找出正确时刻。为简化起见，可以先从固定时长切块开始。Nova Multimodal Embeddings 对单个嵌入支持最长 30 秒，这让你有空间去覆盖完整场景。但要注意，固定边界可能会在动作进行到一半时截断场景，或在一句话尚未说完时把它切开，从而破坏使某一时刻可被检索到的语义含义，如下图所示。
目标是语义连续性：每个分段都应代表一个连贯的意义单元，而不是任意切出的一段时间。固定 10 秒一段虽然易于生成，但它忽略了内容的自然结构。如果场景切换发生在分段中间，一个视觉概念就会被拆到两个块中，从而同时降低检索精度和嵌入质量。
为了解决这个问题，我们使用 FFmpeg 的场景检测来识别视觉内容真正发生变化的位置。FFmpeg 是一个开源多媒体框架，被广泛用于视频处理、格式转换和分析。下文的 _detect_scenes 函数会对视频运行 ffprobe（FFmpeg 用于媒体检测的关联工具），并返回一个时间戳列表，其中每个时间戳都标记了一个场景边界：
输出会是一个简单的时间戳列表，例如 12.345、28.901、45.678，每一个都表示场景发生变化的自然边界。
有了这些边界之后，分段算法会在可接受窗口内，把每次切分点对齐到最近的场景变化位置：目标时长约为 10 秒，从当前起点开始最短 5 秒、最长 15 秒。如果这个范围内没有场景变化，就退回到在目标时长处进行硬切分。最终得到的一组分段会更自然，例如 8.3 秒、11.1 秒、9.8 秒、12.4 秒、7.6 秒，它们都与真实场景边界对齐，而不是机械地按固定节拍切分。
这种基于镜头的简单分段方式，可以确保分段边界与自然的视觉转场对齐，而不是任意切开。目标分段时长应根据内容类型和使用场景进行校准：剪辑频繁、动作密集的内容，可能更适合这种视觉分段；而纪录片或访谈类长镜头内容，则可能更适合更长、基于主题的分段方式。若需更高级的分段技术，包括基于音频的主题分段，以及视觉和音频结合的方法，作者建议参考 Media2Cloud on AWS Guidance: Scene and Ad-Break Detection and Contextual Understanding for Advertising Using Generative AI。
分别为视觉、音频和转录信号生成嵌入
在分段确定之后，嵌入模型的选择就会成为不同方案之间拉开质量差距的关键。当前主流方法是在生成嵌入之前，先把所有视频信号转成文本；但正如前文所说，视频所承载的意义远不是任何转录稿或字幕所能完全表达的。视觉动作、环境音、屏幕文字以及实体上下文，要么会完全丢失，要么只能通过不精确的描述来近似表达。
Nova Multimodal Embeddings 从根本上改变了这一点，因为它是一种原生面向视频的模型，能够以两种模式生成嵌入。组合模式会把视觉和音频信号融合为统一表示，捕捉最重要的关键信号。这种方式每个分段只需一个嵌入，因此有利于存储成本和检索延迟。另一种是 AUDIO_VIDEO_SEPARATE 模式，会分别生成视觉嵌入和音频嵌入。这种方式能最大程度保留各模态的独立表示，也让你能更好地控制何时搜索视觉内容、何时搜索音频内容。
在实现中，作者还加入了第三种来自 Amazon Transcribe 的语音嵌入。该嵌入通过将完整句子的转录文本与嵌入分段前后的时间戳进行对齐来生成，从而保持口语语言的语义完整性，确保一个完整表达不会被拆到两个嵌入中。
图 4：每个视频分段的视觉、音频和语音嵌入生成
这三种嵌入合在一起，覆盖了一个视频分段的完整信号空间。视觉嵌入捕捉摄像机看到的内容：物体、场景、动作、颜色和空间构图。音频嵌入捕捉麦克风听到的内容：音乐、音效、环境噪声以及场景的声学质感。转录嵌入捕捉人们说了什么，表示对白和旁白的语义含义。如果把这三类信号压缩成一个统一嵌入，就等于把不同模态压进同一个向量里。这会模糊“看见的、听见的、说出的”边界，丢失使每种信号各自有价值的细粒度信息。将它们分开保留，则可以根据查询意图精确调高或调低各模态权重，让搜索流水线优先匹配最可能包含答案的模态。
将元数据与嵌入结合，进行混合搜索
即使已有三个分别覆盖视觉、音频和口语内容的独立嵌入，系统仍然有一类查询处理得不够好。嵌入的设计目标是捕捉语义相似性。对于“紧张的人群时刻”或“水面上的落日”这类具有丰富视觉和音频含义的概念，它很擅长查找。但如果用户搜索某个具体姓名、产品型号、地理位置或某个特定日期，嵌入往往会失效。因为这些是离散实体，本身缺乏足够的语义信号。这正是混合搜索发挥作用的地方。系统不是只依赖嵌入，而是像下图所示那样并行运行两条检索路径：一条语义路径，在视觉、音频和转录嵌入上匹配概念相似性；一条词法路径，在结构化元数据上执行精确关键词和实体匹配。
图 5：结合语义检索与词法检索的混合搜索流水线
需要多少元数据？答案取决于你的内容类型、组织方式和使用场景，想在一开始就捕捉所有元数据并不现实。为了说明问题，作者选取了几类元数据，代表媒体与娱乐内容中的常见元数据类型。
首先，作者选用了视频标题和日期时间，代表直接从内容目录或文件元数据中提取的技术元数据。随后又加入了分段字幕、类型和名人识别，作为上下文元数据，这些内容由 Amazon Nova 2 Lite 和 Amazon Rekognition 生成。字幕根据每个分段的视频和转录生成，为模型同时提供视觉和口语上下文。类型是根据所有分段的完整视频转录来预测的，这样比重复发送所有视频片段更便宜，也更可靠。名人识别则由 Amazon Rekognition 负责，它可以识别屏幕中出现的已知公众人物，而无需自定义训练。
下文示例展示了用于生成字幕和分类类型的提示词：
这一思路也可以自然扩展到其他元数据类型。技术元数据可以包括分辨率或文件大小，上下文元数据则可能包括地点、情绪或品牌。具体采用怎样的平衡，取决于你的搜索场景。另外，在检索时叠加元数据过滤器，也可以在语义匹配之前先缩小搜索空间，从而进一步提升搜索的可扩展性和准确率。
用意图感知查询路由优化搜索相关性
现在你已经拥有三类嵌入和元数据，一共四个可搜索维度。但针对某个具体查询，怎么知道该用哪一个、用多少？关键在于意图。为此，作者构建了一个智能意图分析路由器，使用 Haiku 模型分析每条传入查询，并为每个模态通道分配权重：视觉、音频、转录和元数据。下图展示了一个示例查询。
“Kevin 在一辆复古汽车旁接电话”
图 6：基于搜索意图智能分配权重的示例查询
系统会提示 Haiku 模型返回一个 JSON 对象，其中各项权重之和为 1.0，并附带简短的推理说明来解释分配结果。提示词如下：
这些权重会直接决定执行哪些子查询。任何权重低于 5% 的模态都会被完全跳过，从而减少不必要的嵌入 API 调用，在不牺牲准确率的前提下降低搜索延迟。其余通道会并行执行，各自独立搜索自己的索引。所有活跃通道返回的结果，再通过加权算术平均进行评分。BM25 分数（基于词频和文档长度的词法相关性度量）与余弦相似度分数（度量两个向量方向接近程度的几何指标）所处量级差异很大。为此，系统会先把每个子查询的分数归一化到 0-1 区间，再结合路由器给出的意图权重进行融合：
作者选择加权算术平均作为重排序技术，是因为这种方法可以直接把查询意图纳入计算。与不区分意图、对所有活跃通道一视同仁的 Reciprocal Rank Fusion（RRF）不同，加权平均会放大路由器判定为更相关的通道。根据作者的测试结果，这种方法在其搜索任务中给出了更准确的结果。
为向量和元数据选择合适的存储策略
最后一个设计决策是数据存储的位置与方式。每个视频分段最多会产生三类嵌入和一组元数据字段，而存储方式会同时决定搜索性能和规模化成本。作者将其拆分到两个角色互补的服务中：Amazon S3 Vectors 用于向量存储，Amazon OpenSearch Service 用于混合搜索。
S3 Vectors 会为每个项目保存三个向量索引，分别对应三种嵌入类型：
OpenSearch 则为每个项目保存一个索引，其中每个文档代表一个视频分段，同时包含用于 BM25 搜索的文本字段，以及用于 k 最近邻（kNN）搜索的向量字段：
之所以选择 S3 Vectors，是看中了它的成本与性能比。与其他专用替代方案相比，Amazon S3 Vectors 可将向量存储和查询成本最多降低 90%。如果你的场景对搜索延迟要求不高，S3 Vectors 是一个很有竞争力的默认选择。如果需要尽可能低的延迟，作者建议使用 OpenSearch Hierarchical Navigable Small World（HNSW）引擎，将向量放在内存中。
最后还需要指出的是，某些使用场景要求在更长、语义更密集的视频片段中搜索，例如完整采访、持续数分钟的纪录片场景，或较长的产品演示。包括 Nova Multimodal Embeddings 在内的大多数多模态嵌入模型，单次输入时长上限都是 30 秒，这意味着 3 分钟的视频片段无法作为单个单元直接嵌入。强行这样做，不是会失败，就是不得不切块，从而失去更广泛的上下文。
OpenSearch 的嵌套向量支持可通过让单个文档包含多个子分段嵌入来解决这一问题：
在查询时，OpenSearch 会根据最佳匹配的子分段来为文档打分，而不是使用单个平均表示。因此，一段较长场景仍然可以凭借其中某个具体视觉时刻被匹配到，同时又能作为一个连贯结果整体返回。
性能结果：优化方案如何优于基线
为了验证这些设计决策，作者将优化后的混合搜索方案与 Nova Multimodal Embeddings 基线 AUDIO_VIDEO_COMBINED 模式进行了基准测试。测试使用了 10 个内部长视频（每个 5-20 分钟），并围绕视觉、音频、转录和元数据相关搜索共评估了 20 条查询。基线方案对每个 10 秒分段只使用一个统一向量、一个索引和一次 kNN 查询。优化方案则生成独立的视觉、音频和转录嵌入，用结构化元数据增强分段，并应用意图感知路由，对模态通道动态加权。下图展示了四项标准检索指标上的结果：
图 7：基于 Nova MME 的混合搜索与基线方案在检索指标上的性能对比
下表汇总了关键指标：
结果显示，各项指标都有明显提升。优化后的混合搜索在 Recall@5 和 Recall@10 上达到 90% 以上，而基线分别为 51% 和 64%（覆盖准确率提升约 40%）。MRR 从 48% 提升到 90%，NDCG@10 从 54% 升至 88%。这些 30-40 个百分点的提升验证了作者的核心架构决策：语义分段保留了内容连续性，独立嵌入带来了精确的搜索控制，元数据增强覆盖了事实型实体，意图感知路由则确保每次查询都由正确的信号驱动。通过将每种模态独立处理，并基于查询意图进行智能组合，系统能够适应多样化的搜索模式，并在视频档案规模扩大时持续提供高相关性的结果。
清理资源
为避免未来继续产生费用，请通过删除 AWS CloudFormation 堆栈来清理此方案所使用的资源。具体命令请参见 GitHub 仓库。
结论
本文介绍了如何在 AWS 上使用 Nova Multimodal Embeddings 构建视频语义搜索方案，涵盖四个关键设计决策：通过分段保持语义连续性，使用多模态嵌入分别捕捉视觉、音频和语音信号，用元数据补足实体型查询的精度缺口，以及通过合理的数据结构实现高效且可扩展的检索。再结合智能意图分析路由器和加权重排序，这些设计把原本碎片化的信号转化为统一且准确的视频搜索体验。后续还可以进一步优化搜索准确率，包括为意图路由层进行模型定制。想进一步了解这些技术，可阅读第 2 部分。若要查看这一视频搜索与元数据管理技术在大规模生产环境中的实现，可参考 Guidance for a Media Lake on AWS。
Amit Kalawat
Amit Kalawat 是 Amazon Web Services 驻纽约的首席解决方案架构师。他与企业客户合作，帮助其推进业务转型和上云进程。
James Wu
James Wu 是 AWS 的首席生成式 AI/机器学习专业解决方案架构师，帮助企业设计并执行 AI 转型战略。他专注于生成式 AI、代理式系统以及媒体供应链自动化，也是会议演讲嘉宾和技术作者。在加入 AWS 之前，他曾担任架构师、开发者和技术负责人超过 10 年，相关经验横跨工程和营销行业。
Bimal Gajjar
Bimal Gajjar 是 AWS 的高级解决方案架构师，与全球客户合作设计、采用并部署可扩展的云存储和数据解决方案。Bimal 拥有超过 25 年与领先 OEM 合作的经验，其中包括 HPE、Dell EMC 和 Pure Storage。他把深厚的技术专长与战略业务洞察结合在一起，这些能力也来自其在售前架构和全球服务交付中的端到端实践。
