文章与视频检索：从整篇匹配到片段定位

搜「报销流程」，结果是一份 60 页制度的首页；搜「怎么导出报表」，找到视频却不知道该从哪里看。内容明明存在，用户还是拿不到答案。原文认为，问题往往出在检索单位：文章和视频需要被拆成能直接回答问题的段落与时间片段。

这套方案值得读的地方，是把元数据、内容切分、AI 标注、混合检索和运营指标串了起来。但它没有提供完整实验或前后对照，更适合作为知识库、帮助中心的建设框架，不能直接当成效果承诺。

搜到一篇文章，为什么还不算搜到答案

原文先区分了商品检索与内容检索。

商品通常是一条较短的结构化记录，包含标题、分类、属性、价格和库存。用户搜「iphone 15 256g」，目标已经相当明确，匹配记录后就可以查看商品。

内容的情况不同。一篇 5000 词的文章、一段 30 分钟的视频，用户可能只需要其中 1 段或 1 分钟。整篇内容命中，只完成了第一步，用户还要继续翻找。

内容搜索应该把用户送到答案所在的位置。

因此，文章应按标题层级切成章节或段落，每段保留所属文档的标题、路径和更新时间。搜索结果才能链接到「第 3 章第 2 节」，同时让用户知道这段话出自哪里、是否还有效。FAQ 和政策问答可以继续细化，以一组问答作为检索单位。

视频则按章节和时间戳切分。例如「02:15 创建报销申请」「05:40 上传发票」，每章形成独立记录，命中后直接跳转。语音转写还要保留逐句时间对齐，才能高亮匹配句，并定位到对应时刻。

对前端来说，结果页的职责也随之变化：除了显示标题，还应呈现命中片段、章节位置，以及可用的锚点或播放时间链接。后端即使找到了正确内容，界面只给一个文档首页，用户仍然得自己找答案。

为什么要先整理内容，再谈模型

原文把元数据和转写文本放在基础位置。标题、摘要、作者、更新时间、分类和标签，决定了文章能从哪些入口被找到；视频还需要字幕、语音转写、章节时间戳，以及画面中的对象、场景和文字标注。

这里有两件容易被低估的工作。

第一是统一词表。原文举的思路是采用 Dublin Core 这样的元数据标准，或者企业自己的标签体系，避免同一个概念散落在不同叫法下面。不过，统一标签不等于把所有近义词强行合并。「报销」和「差旅报销」是否应归为同一概念，还取决于业务分类。

第二是持续审计。产品改名、流程调整之后，旧标签与新表述会并存。元数据即使入库时齐全，也会逐渐过时。作者建议把完整性作为内容入库条件，减少后续补账，但没有给出这项做法的量化对照。

内容量大之后，AI 可以承担部分结构化工作：用语音识别（ASR）生成转写文本，用 OCR 提取画面文字，用计算机视觉识别对象和场景，再用自然语言处理抽关键词、写摘要、划章节。

自动生成的标签也会出错。原文建议保留置信度字段，对低置信度标签降低排序权重，或者进入人工复核队列，并通过抽样检查追踪错误率。否则，错误标注会把无关内容带进结果。

VideoObject 则用于描述视频的章节、时长、缩略图和简介等结构信息。需要分清的是，写上结构化标记并不会自动完成站内索引和播放跳转，这些能力仍需检索系统与播放器配合。

用户换一种问法，系统还能找到吗

内容检索的另一处难点是表达差异。

「报销流程」「怎么报销」「如何申请费用报销」「报销需要哪些材料」，都与报销有关，但最后一个问题明显更关注材料清单。系统既要识别近义表达，也不能把相关问题全部当成同一道题。

原文提出三层处理：

• 用人工维护的同义词词典覆盖高频表达，并从高频无结果词和用户改写中补充词族。
• 用查询扩展与查询改写完成纠错、补全和同义归一，让输入靠近规范表述。
• 用向量检索覆盖措辞不同、语义相近的长尾问题。

具体召回方案是组合 BM25 与稠密向量（dense embeddings）：前者负责精确词项，后者负责语义相近的内容，再融合排序。例如，用户搜「如何申请退款」，也能找到标题为「退货退款操作说明」的内容。

这里有个术语边界：BM25 加向量检索属于混合检索，不能仅凭这两项就称为多模态检索。 原文还讨论了从视频画面、声音中提取信息，因此整体方案涉及多种模态；但没有交代是否直接使用跨模态向量，也没有提供融合权重、排序公式或模型选型。

对于问句式搜索，作者还建议单独标记 FAQ、帮助文档和视频章节，让结果优先返回可回答问题的片段。这个方向合理，但「识别成问句」只是开始，最终仍要判断片段是否真正回答了用户的问题。

我的判断

我认同原文的实施顺序：先检查内容是否存在、是否可定位、描述是否完整，再判断召回与排序哪里需要调整。相比直接把全文送进向量库，这条路线更容易解释一次失败究竟发生在哪里。

不过，原文把「视频只能先转成文本才能检索」说得过于绝对。对它描述的文本索引方案，转写与标注确实是基础；把这个前提扩展到所有检索系统，就超出了文中证据。

指标也需要带着口径看。作者定义的搜索成功率，是首次查询产生有效点击的比例，给出的知识库目标通常为 70% 以上；零结果率一般应低于 5%，较好的实践为 2%–3%，引用资料另有 2.25% 的案例。覆盖缺口率则指 Top N 高频查询中，没有匹配内容的占比。

这些数字可以作为参考起点，但原文没有交代样本、统计周期，也没解释「有效点击」如何判定。点击结果后仍然找不到答案，显然不能算用户问题已经解决。零结果率下降，也可能只是返回了更多不相关内容。

作者建议每周导出无结果词和低成功率词，按业务价值安排补写文章、视频或 FAQ，上线后回填索引，再在下一周期复查。这是全文最有操作性的闭环。

但「多数问题来自缺内容、切分过粗或元数据不全」仍是经验判断，文中没有对照数据证明其适用于一般团队。结尾还带有 Tengence Search 产品推广，因此应把方案建议与产品效果主张分开看。

能拿来做什么

• 做知识库或帮助中心时，先选一组高频问题，逐条确认答案是否存在、能否直达。前端结果卡片展示命中段落和章节路径，文章支持锚点，视频支持按时间定位，再观察用户是否还需要反复翻找。

• 用 Node 搭建入库流程时，把父文档标题、路径、更新时间和分段位置保留下来；视频转写同时保存时间信息。入库前检查必要字段，产品改名或制度更新后安排元数据审计。

• 遇到「换个问法就搜不到」时，先整理高频失败查询及其目标答案，区分同义词缺失、内容缺失和切分问题，再评估 BM25、向量召回及融合排序，避免只凭几条演示查询判断效果。

• 每周把零结果词与低成功率词整理成待办，明确是补 FAQ、更新文档、细化章节，还是修正标签。持续记录搜索成功率、零结果率和 Top N 覆盖缺口率，并先统一「有效点击」的统计规则。