本文改编自Opus Clip投稿，这是全球 AI 视频剪辑工具的头号产品，2024年，获用户量1000万+，产生视频总量1.7亿+。今年二月，获得由软银愿景基金二期领投的新一轮融资。

****01****

****需求分析****

****1.1 需求背景与问题提出****

2025年1月，Opus Clip推出基于Milvus的RAG系统构建的OpusSearch语义搜索产品，该产品可以帮助各种专业视频创作者从素材库中精准找到任何需要的素材内容，并根据热门话题获得AI推荐的视频片段。

该产品在自然语言模糊查询场景（如“找一些关于约会的搞笑时刻”）中表现优异，但随着用户使用深入，核心用户群体（如视频编辑、剪辑师）的反馈暴露出产品功能缺陷：

高效的搜索功能是实现视频内容复用、变现的关键支撑，但只有单纯的语义搜索无法满足精确匹配需求。

典型问题场景如下：

视频编辑需从播客中查找“第281集”片段，搜索后系统返回第280集、第282集甚至第218集等近似结果；搜索“她说了什么”时，系统会返回“他说了什么”等语义相近但关键词不符的结果，严重影响用户工作效率，违背视频编辑对特定内容精准定位的核心诉求。

****1.2 核心需求拆解****

****1.2.1 功能需求****

• ****精确匹配功能：支持用户通过特定关键词（如“第281集”）、短语（如“她说了什么”）搜索，精准返回包含目标内容的结果，避免近似值干扰。

• ****双模式搜索兼容：在保留原有语义搜索优势的基础上，新增关键词精确匹配模式，支持用户根据场景灵活切换不同检索模式。

• ****结果智能排序：精确匹配结果结合相关性进行排序，确保最符合需求的内容优先展示。

****1.2.2 非功能需求****

• ****运维成本可控：作为初创企业，需避免因功能升级引入多套搜索系统，控制运营负担与系统复杂性。

• ****性能稳定：新增功能后，系统查询响应速度、匹配准确率需满足生产环境要求，大规模文本数据集场景下仍保持高效运行。

• ****扩展性良好：支持后续语义搜索与精确匹配的融合查询开发，预留技术扩展空间。

****1.3 需求优先级****

精确匹配功能实现（高优先级，解决当前核心痛点）>双模式搜索兼容（高优先级，保障用户使用连续性）>结果智能排序（中优先级，提升用户体验）>扩展性设计（中优先级，支撑长期业务发展）

****02****

****解决方案设计****

****2.1 方案选型依据****

针对精确匹配需求，初步备选方案为引入Elasticsearch或MongoDB等传统数据库实现精确匹配，与现有Milvus语义搜索系统形成互补。

**但该方案存在核心缺陷：******维护多套搜索系统将大幅增加初创企业的运维成本与系统复杂性。********

但是如果仅采用一套方案，先过滤（关键词）后排序，又常常会因为过滤导致索引的图结构产生断联，最终出现图搜索提前终止或 miss 掉结果。此外，图索引期望候选节点越多越好（recall高），如果 bitset 中符合条件的点很少，那就会导致图结构基本失联，直接退化成 brute-force。

详情可参考Milvus Week | 向量搜索遇上过滤筛选，如何选择最优索引组合？

基于以上背景，最终选型为基于现有Milvus向量数据库进行功能升级，核心依据如下：

****（1）社区支持强大：Milvus拥有38k+ GitHub星标，社区活跃度高，技术迭代有保障；

****（2）功能适配性强：Milvus最新发布的全文搜索功能支持精确匹配场景，经私有数据集测试，未调优状态下表现已超预期；

****（3）单一系统优势：可在同一数据库内实现语义搜索与精确匹配，无需新增系统，降低运维成本；

****（4）性能优势显著：在部分匹配准确性上表现出色，如“喝酒场景”查询可避免检索到“用餐场景”等无关结果，且查询时能返回更全面的结果。

（5）Milvus采用Alpha 策略、ACORN （Approximate Clustering with Over-connected Randomized Neighbors）方法、动态选择邻居、元数据感知索引（Metadata-Aware Indexing）等方式，避免了其他常见向量数据库引入关键词检索后导致的索引锻炼、搜索成本变高等问题。****

详情可参考Milvus Week | 向量搜索遇上过滤筛选，如何选择最优索引组合？

****2.2 整体架构设计****

以Milvus作为企业RAG架构的基础向量数据库，构建“BM25算法+TEXT_MATCH过滤器”的双核心精确匹配架构，与原有语义搜索模块融合形成双模式搜索系统。整体流程如下：

****(1)过滤阶段：通过Milvus的TEXT_MATCH过滤器，精准筛选出包含用户查询关键词/短语的文档，实现精确匹配基础筛选。

****(2)排序阶段：基于BM25算法计算筛选后文档与查询的相关性，对精确匹配结果进行智能排序。

****(3)模式融合：用户可自主选择“语义搜索模式”或“关键词检索模式”，系统根据选择调用对应模块，实现双模式兼容。

架构核心优势：单一数据库系统同时支持语义搜索与精确匹配，简化运维架构，降低扩展成本；先过滤后排序逻辑兼顾精准性与相关性，提升用户体验。

05-03-1.webp

****2.3 核心技术实现****

****2.3.1 数据模式设计****

关键设计要点：完全禁用停用词，因业务场景中“THE Office”与“Office”为不同实体，需保留所有词汇；启用TEXT_MATCH功能开关，支持精确匹配过滤；配置词干提取器，实现“running”与“run”等词形还原匹配。具体代码实现如下：

    export function getExactMatchFields(): FieldType[] {  return [    {      name: "id",      data_type: DataType.VarChar,      is_primary_key: true,      max_length: 100,    },    {      name: "text",      data_type: DataType.VarChar,      max_length: 1000,      enable_analyzer: true,      enable_match: true,  // This is the magic flag      analyzer_params: {        tokenizer: 'standard',        filter: [          'lowercase',          {            type: 'stemmer',            language: 'english',  // "running" matches "run"          },          {            type: 'stop',            stop_words: [],  // Keep ALL words (even "the", "a")          },        ],      },    },    {      name: "sparse_vector",      data_type: DataType.SparseFloatVector,    },  ]}

****2.3.2 BM25算法配置****

配置BM25函数作为相关性排序核心，将文本字段转换为稀疏向量用于计算。代码实现如下：

    export const FUNCTIONS: FunctionObject[] = [  {    name: 'text_bm25_embedding',    type: FunctionType.BM25,    input_field_names: ['text'],    output_field_names: ['sparse_vector'],    params: {},  },]

****2.3.3 索引优化配置****

针对生产数据集调优BM25关键参数，平衡术语频率与文档长度对结果的影响，选用SPARSE_INVERTED_INDEX索引类型提升查询效率。

参数说明：

1. bm25_k1=1.2：适度重视术语频率，避免过度加权；

2. bm25_b=0.75：对较长文档施加适度惩罚，兼顾结果准确性与全面性。具体配置如下：

    index_params: [  {    field_name: 'sparse_vector',    index_type: 'SPARSE_INVERTED_INDEX',    metric_type: 'BM25',    params: {      inverted_index_algo: 'DAAT_MAXSCORE',      bm25_k1: 1.2,  // How much does term frequency matter?      bm25_b: 0.75,  // How much does document length matter?    },  },],

****2.3.4 搜索查询逻辑实现****

通过“TEXT_MATCH过滤+BM25排序”组合实现精确匹配查询，支持单关键词与多关键词组合场景。单关键词查询（如“第281集”）与多关键词查询（如“foo”和“bar”）代码示例如下：

    // 单关键词精确匹配查询await this.milvusClient.search({  collection_name: 'my_collection',  limit: 30,  output_fields: ['id', 'text'],  filter: `TEXT_MATCH(text, "episode 281")`,  // Exact match filter  anns_field: 'sparse_vector',  data: 'episode 281',  // BM25 ranking query})// 多关键词精确匹配查询（同时包含多个关键词）await this.milvusClient.search({  collection_name: 'my_collection',  limit: 30,  output_fields: ['id', 'text'],  filter: `TEXT_MATCH(text, "foo") and TEXT_MATCH(text, "bar")`,  // 多条件精确匹配  anns_field: 'sparse_vector',  data: 'foo bar',  // BM25 ranking query})

****03****

****实施效果与验证****

****3.1 实施时间线****

2025年1月-5月：完成Milvus全文搜索功能调研、技术验证与方案设计；2025年6月：完成精确匹配功能开发、测试并部署上线。

****3.2 核心成效****

• ****用户体验显著提升：精确匹配功能解决了视频编辑找特定集数、特定短语的核心痛点，搜索相关支持请求量明显减少。

• ****双模式兼容达标：系统保留原有语义搜索优势，用户可根据需求灵活切换模式，探索性查询与精准查询场景均得到满足。

• ****运维成本可控：基于单一Milvus数据库实现功能升级，未引入多系统维护负担，符合初创企业资源约束要求。

• ****业务价值支撑强化：高效的搜索功能进一步助力企业视频库内容重用与变现，为《All The Smoke》《KFC广播》《TFTC》等客户的成功案例提供更坚实的技术支撑。

****04****

****经验教训与注意事项****

****4.1 关键技术坑点规避****

• ****启用动态字段：****

  初期未启用动态字段导致生产环境中模式修改需删除并重建集合，影响系统稳定性。

  解决方案：创建集合时配置enable_dynamic_field: true，保障模式修改灵活性。

  代码示例：

await this.milvusClient.createCollection({  collection_name: collectionName,  fields: fields,  enable_dynamic_field: true,  // 关键配置：启用动态字段  // ... 其他配置})

• ****集合设计模块化：采用每个功能域独立集合的设计思路，减少模式变化对系统整体的影响，提升可维护性。

• ****内存优化：稀疏索引占用内存较高，大规模文本数据集场景下需启用MMAP（内存映射文件）利用磁盘存储，同时保障足够I/O带宽维持性能。配置方式：在Milvus配置中设置use_mmap: true。

****05****

****未来规划****

****5.1 短期目标（1-3个月）****

实现语义搜索与精确匹配的融合查询功能，支持用户在单一查询中同时包含精确匹配关键词与语义描述，如“找到第281集的搞笑片段”（“第281集”用精确匹配，“搞笑片段”用语义搜索），进一步提升搜索效率。

****5.2 长期规划****

构建“智能融合搜索”体系，无需用户手动切换模式，系统可根据查询内容自动判断场景，智能选择精确匹配、语义搜索或融合模式，实现“用户无需思考模式，只关注需求本身”的极致体验，持续强化企业视频库货币化支撑能力。

****06****

****附****

****Milvus全文检索相关功能解读：官宣|Milvus 2.6正式开源：内存减少 72%，速度比ES快4倍

****如何从ES迁移到Milvus：手把手教你如何把代码库从 ES 迁到 Milvus

****类似方案教程：如何用向量数据库构建网站AI查询助手