视频 RAG 中分块策略：基于停顿、滑动窗口与基于 LLM 的方法

文本的RAG我们都已经很熟悉了，但是如果数据以原始视频转录文本的形式存储，没有合适的时间结构，那么相比标准的 PDF 或文本文档，如何检索视频里面的内容呢？

针对同样的问题还可以换一个更高层次的问法：

"这个视频整体在讲什么？"

系统会出现幻觉，或者返回一段泛泛的答案------检索器看到的只是孤立的短片段看不到整体。这个问题问题不在 LLM而是在分块策略本身。

本文会拆解视频分块的具体机制，从基础的文本解析往前推进一步，构建一个能够理解视频时间结构与组织结构的系统。

分块简介

分块（Chunking）指的是把大段信息切分为更小、有意义的片段，以便大语言模型（LLM）或向量数据库进行检索和处理。

视频分块为什么不同于文本分块

为文本文档构建 RAG 流水线时，可以依赖段落、换行符或固定数量的 Token 这些标准分隔标记。视频则天然是多模态、带时间维度的。

一段视频文件不是一份文档，而是一个由时间驱动的交互流，包含画面切换和语音对话。

基于停顿的分块

第一种真正可用的工程方案是基于停顿的分块（Pause-Based Chunking）。

说话人在不同思路、幻灯片切换或话题切换之间，会自然留出停顿。这些天然边界可以用来切分视频转录文本。

假设转录文本中包含每句话或每段话的起止时间戳。算法比较前一段的结束时间与后一段开始时间之间的间隔：

仅靠停顿分块为什么会失败

停顿检测是一个不错的起点，但根据查询类型的不同，它存在两类结构性缺陷。

说话人在解释一个复杂概念时短暂喘了口气，算法可能会从这里切出一个新块，上下文也随之被割裂：

块 1： "CI/CD 把......的过程自动化"
块 2： "......构建、测试和部署软件。"

如果检索系统只取出块 1，LLM 收到的就是一个不完整的句子，缺少给出完整技术性回答所需的上下文。

要在保留基于停顿分段优势的同时解决上下文割裂，可以引入带重叠的窗口策略。

通过保留一段重叠（例如 5 秒或若干句话），相邻分块之间的上下文得以保留。

如果数据是节奏很快、几乎没有停顿的教程视频，基于停顿的分块就会失效------切出的块要么过大、要么过小，都缺乏意义。

当不存在明显停顿、音频几乎是连续的，就回退到基于长度的递归策略：

检查停顿： 如果有，使用基于时间的边界。
回退条件： 如果某个片段没有停顿，且超过最大长度（例如 200 个词），按句子边界进行切分。

基于 LLM 的主题分块

要解决这类高层次的查询，需要一种更进阶的策略：基于 LLM 的主题分块（LLM-Based Topic Chunking）。

把数据不再视作一条条独立的话语，而是将细粒度分块送入 LLM，让它对片段做聚类和摘要，归纳出有意义的主题。

把细粒度分块和一个用于生成主题与元数据的 Prompt 一起传给模型：

复制代码

 {  
 "topic": "Introduction to CI/CD Fundamentals",  
 "summary": "Covers the basic definition of CI/CD, its role in modern deployment, and the foundational stages of a build pipeline.",  
 "start": 0,  
 "end": 120,  
 "key_terms": ["CI/CD", "deployment", "build stage"]  
 }

把细粒度分块与主题分块结合起来

生产级的 RAG 系统会同时用上两种策略：

细粒度分块： 存入向量数据库，用于具体信息的检索，例如时间戳和精确答案。
主题分块： 用于全局检索和摘要类任务。

整体串起来，端到端的处理 Pipeline 是这样的：

总结

分块不只是数据预处理的一个前置步骤------数据被切分的方式，决定了检索系统对它的理解程度。从简单、均匀的切分，转向利用自然停顿与 LLM 驱动主题分段的多层、多模态架构，Agent 才能拿到回答具体技术问题和宽泛主题问题所需的上下文。

https://avoid.overfit.cn/post/6d24a4a88971454bb68d54c82772a759

by Rishav Aich