文本的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
