假设你手里有一段一小时的公司培训视频，里面讲了年假、报销和考勤制度。
现在有人问：“年假要怎么申请？”
最笨的办法，是把视频从头看一遍。更理想的办法，是让系统直接找到讲年假的那几十秒，整理出答案，同时把原视频和时间位置交给你复查。
这正是很多人希望 RAG 做到的事。
RAG 这个名字听起来有点技术，其实就是先从指定资料里找内容，再让大模型根据找到的内容回答。它和普通聊天的区别在于，大模型回答之前会先“翻资料”。但找到资料也不代表一定答对，答案最好还能回到原文检查。
问题来了：PDF、Word 都可以作为资料，视频也是一个文件，为什么不能直接扔进知识库？
因为知识库真正需要的不是一个文件名，而是可以搜索、可以定位、可以核验的内容片段。
保存一个 MP4，只说明服务器里多了一个文件。系统依然不知道第几分钟讲了什么，也不知道答案藏在声音里、字幕里，还是某一页 PPT 上。
这就像一间图书馆。把书搬进仓库，只解决了“有没有保存”的问题。读者想根据一句话找到具体内容，还需要目录、页码和可以检索的正文。视频文件就像一本只有封面、没有目录的书。它能播放，但搜索系统还看不懂里面的内容。
所以，“支持上传视频”和“支持搜索视频”是两回事。前者关心文件能不能保存，后者关心内容能不能被拆出来、建立索引，并在回答时回到正确位置。
本文讨论的是讲解、培训、教学录播这类以人声和演示画面为主的视频，以及“先把内容转成文本，再进行检索”的常见做法。能直接理解视频的多模态模型是另一条路线，不在这篇文章的范围内。
一、PDF 为什么相对容易？
先从更熟悉的文档说起。
一份 PDF 进入知识库后，通常不会在每次提问时都把整本文件交给模型。系统会先把里面的文字取出来，再整理成许多较短的内容片段。
比如一份员工手册可以拆成：
年假申请条件
年假审批流程
报销所需材料
试用期考核规则
每一段都尽量只讲清一件事。这样用户问“休假怎么走审批”时，系统不必把整本手册翻一遍，只要先找到“年假审批流程”这一段。
PDF、Word 和 Excel 的处理方式不同。PDF 往往按页提取文字，Word 可以参考标题和段落，Excel 则要注意表头、行列和单元格之间的关系。但它们的目标一致：既拿到正文，也保留“这段话来自哪里”。
文字取出来以后，还要变成便于比较意思的一组数字坐标，这一步叫 Embedding。
不熟悉这个词也没关系。你只需要知道，系统可以借助这些数字，比较两段话在意思上是否接近。用户写“休假怎么审批”，原文即使写的是“年假申请流程”，系统也有机会把它找出来。
专门存储这些数字坐标、并支持按相似度搜索的资料库，通常叫向量数据库。
找到相关片段后，系统才会把用户的问题和片段原文一起交给大模型。大模型负责把资料整理成通顺的回答，页面再把文件名、页码或章节展示出来。
整个过程可以压缩成一条线：
读取文件 → 切成内容片段 → 建立索引 → 找到相关片段 → 整理答案 → 展示来源
PDF 之所以能被搜索，不是因为它上传成功，而是因为里面的文字已经被取出、整理并建立了索引。
如果原始 PDF 是扫描图片，根本没有可提取的文字，它同样需要先做图片文字识别。文件后缀本身不决定能不能搜索，内容有没有变成机器可处理的形式才是关键。
二、视频比 PDF 多了什么？
文档里通常已经有文字，视频里的信息却主要藏在声音和画面中。
对讲解类视频来说，第一件事是把人声变成字幕。这个过程常被称为 ASR，也就是语音识别。
只得到一整篇字幕还不够。如果还希望用户能够回到原视频，字幕最好同时保留时间位置，例如：
08:12 - 08:19 申请年假前先确认剩余额度
08:19 - 08:27 然后在系统里提交申请
08:27 - 08:34 审批通过后申请才正式生效
时间位置有两个用处。
一是告诉系统哪些句子原本挨在一起。二是在播放器支持按时间定位时，让用户点击来源后跳到 08:12，而不是从一小时视频的开头慢慢寻找。
时间还关系到声音和画面的对应。讲解者在 08:20 说“看这张表”，系统只有知道这句话出现的时间，才有机会去同一时间附近寻找 PPT 画面。时间丢了，字幕和画面就像被打乱的两摞卡片，很难再准确拼回去。
但逐句字幕往往太碎，直接拿来搜索容易丢掉上下文。
假如知识库里只有“然后在系统里提交申请”这一句，用户并不知道提交的是年假、报销还是请假。系统需要参考标点、停顿、时间间隔和内容是否连贯，把相邻字幕合并成一段能够独立说清楚事情的文字。
声音处理完，问题还没有全部解决。
讲解者可能会说：“具体数字看右边这张表。”这句话本身没有答案，真正的信息在 PPT 或操作画面里。
遇到这类视频，可以进一步从关键画面中读取文字，再把它和同一时间段的字幕放在一起。图片文字识别常被称为 OCR。它能帮助读出画面上的文字和数字，但不能自动保证自己理解了表格关系，更不能替代人工核验。
对本文讨论的讲解类视频，可以把处理过程分成三层：
- 人声先变成带时间的字幕。
- 相邻字幕再合并成语义完整的片段。
- 如果答案依赖画面，再补充同一时间段的画面文字。
完成这些处理后，大部分文档 RAG 的索引、检索和回答链路才能继续复用。
三、为什么字幕不能随便切？
把字幕切成片段，看起来只是一个排版动作，实际上会直接影响后面的搜索。
还是用年假申请举例。原始内容是：
申请年假前，需要先确认剩余额度。
确认后，在系统里选择休假日期并提交审批。
直属负责人和人事审批通过后，申请才正式生效。
如果第一段停在“选择休假日期”，下一段从“并提交审批”开始，用户问“年假怎么申请”时，系统即使找到了其中一段，也可能只拿到半个流程。
片段过短，容易失去上文；片段过长，又可能把年假、报销、考勤几个主题混在一起。搜索年假时，一大段无关内容也会跟着进入答案生成环节。
更合适的目标不是“每段长度一样”，而是“每段尽量独立说清一件事”。
文档可以参考标题、段落、列表和表格边界。视频可以参考标点、停顿、时间间隔、章节变化和 PPT 切换。至于一段究竟应该多长，没有一个适合所有资料的固定数字，需要拿自己的内容和问题去测试。
这一步很容易被忽略。很多“明明资料里有答案却搜不到”的问题，未必出在大模型，也可能是答案在切分时被拆散了。
四、真正进入知识库的是什么？
经过处理后，进入知识库的不再是整条视频，而是一组内容片段。
每个片段至少要保存两类信息。
第一类是“讲了什么”，也就是用于搜索的字幕或画面文字。
第二类是“来自哪里”，包括视频名称、开始时间、结束时间，必要时再加章节名称或对应的 PPT 页面。
两类信息缺一不可。只有来源、没有内容，系统无法按照意思搜索；只有内容、没有来源，即使答案碰巧正确，用户也很难判断它是否忠于原视频。
用白话表示，一段视频知识可以长这样：
内容：申请年假前先确认剩余额度，然后在系统里提交申请
来源：员工制度讲解
位置：08:12 到 08:27
章节：年假申请
这里的内容负责参与搜索，来源信息负责让用户回到原视频。示例只用于解释结构，不是某个真实项目的业务记录。
现在再看用户的问题：“视频里是怎么讲年假申请的？”
系统先在已经建立索引的字幕片段中寻找意思接近的内容。如果找到了上面这段文字，就把它连同问题一起交给大模型。大模型整理出申请步骤，答案旁边同时显示视频名称和 08:12 到 08:27。
在这条以字幕索引为主的链路里，大模型并没有临时看完一小时视频。真正参与回答的是提前处理好的几个内容片段。如果字幕缺失、时间不对，或者片段没有进入索引，只更换回答模型通常不能解决根本问题。
搜索负责“把证据找出来”，大模型负责“把证据说清楚”。如果第一步找错了，第二步写得越流畅，反而越容易让人误信。做 RAG 时，不能只盯着最后那段回答，还要回头看它究竟拿到了哪些原文。
五、资料里没有答案时怎么办？
搜索系统通常会从资料库里挑出“最接近”的内容。但最接近，不等于真正相关。
如果员工手册里根本没有“海外差旅补贴”的规定，系统仍然把一段国内报销流程交给大模型，模型就可能生成一段听起来合理却没有资料依据的答案。
可以先给搜索结果设一道相关程度门槛。达到要求，才根据资料回答；低于门槛，就明确说“现有资料中没有找到答案”。
门槛不能凭感觉设定。太低，容易把无关资料当答案；太高，又可能拒绝本来有答案的问题。
测试时同时准备两类问题：一类在资料里确实有答案，另一类明确没有答案。观察系统该回答时有没有找到，该拒绝时有没有忍住。
这个检查与视频同样有关。视频里没有讲过的内容，不应该因为系统“总能找出几段相近字幕”就被包装成答案。
六、怎么判断视频 RAG 真的有用？
页面能够上传视频，聊天框能够返回一段话，只能说明流程跑起来了，不能说明结果可靠。
验证之前，先准备一批来自真实资料的问题。每个问题都要人工确认三样东西：正确答案是什么，答案来自哪条视频，以及正确内容位于哪个时间段。
例如，人工先确认“年假申请需要哪些审批”这个问题的答案位于 08:12 到 08:34。测试时，不是只看系统有没有写出一段通顺的话，而是顺着结果往回检查：它找回的是不是这段字幕，关键信息有没有缺失，答案有没有添上原视频没说的条件，点击来源能不能回到对应位置。
这样一查，问题出在哪里会更清楚。字幕根本没被找回，应该先检查切分和搜索；字幕找对了但回答漏掉一步，再检查交给模型的内容是否完整；答案没问题但跳转时间错误，则要查来源信息和播放器定位。不同问题需要修不同环节，不能全部归结为“大模型不够强”。
接下来检查四件事。
先看有没有找对。 用户问年假，搜索结果里应该出现讲年假的字幕，而不是只因为“申请”两个字相同，就找回报销流程。
再看证据够不够。 如果完整答案需要连续两段字幕，系统只找回一段，生成的回答就可能漏掉关键步骤。
然后看回答有没有超出资料。 模型写出的事实应当能在字幕或画面文字中找到依据。资料没写的内容，即使听起来合理，也不能当成已确认事实。
最后看来源是否对得上。 回答标注 08:12，点击后就应该回到讲这件事的位置。来源写得很漂亮，却指向错误时间，同样无法让用户复查。
这四项检查分别对应“找对、找全、不乱说、指对位置”。第一次接触 RAG，先把这四句话看懂，比急着记一串英文指标更重要。
测试问题也不能只挑最容易的。题目里要有原话能直接搜到的、换一种说法的、需要相邻两段字幕才能回答的，还要有资料中明确没有答案的。这样才能知道系统是在真正寻找证据，还是只对少数关键词碰巧有效。
面试官追问：答案错了，怎样判断错在视频处理的哪一步？
先把一次问答拆成可以查看的中间结果，而不是只盯着最终回复。至少要拿出用户原问题、实际参与检索的查询、召回的字幕片段、每个片段的时间范围、送给模型的上下文，以及最终返回的来源位置。随后从前往后核对。
如果正确内容根本没有出现在字幕里，先检查语音识别、说话人重叠、专有名词和音频质量。字幕存在但被拆到两个互不完整的片段里，问题在字幕合并与切分。完整片段已经进入索引却没有被找到，再检查查询改写、检索范围和排序。正确证据已经排在前面，模型仍然漏掉条件，才继续检查上下文是否被截断、提示是否要求依据资料回答。
时间跳转错误要单独处理。字幕文字正确但来源跳到了相邻片段，通常说明切分后的开始时间、结束时间或片段 ID 在写入索引时没有保持一致。此时重新调检索分数不会修好引用。面试时能把这些现象对应到具体阶段，比笼统说“看日志”更有工程价值。
排查记录还应保留处理版本。语音识别器、字幕合并规则和切分配置只要有一项变化，同一个片段的文字与边界就可能改变。没有版本信息，今天找到的证据和昨天的引用无法稳定比较，也很难判断一次修复究竟影响了哪一层。
面试官追问：字幕与画面表达不一致，应该相信谁？
讲解视频里，口播、字幕和画面并不总是三份完全相同的内容。讲解者可能口误，自动字幕可能识别错数字，PPT 也可能还是旧版本。系统不能简单规定“画面永远优先”或“字幕永远优先”，而要先保留它们各自的来源与时间关系。
更稳妥的内容单元可以同时保存口播字幕、画面文字、画面位置和二者的重叠时间。两份信息一致时，可以共同支持检索；出现数字、日期或条件冲突时，应把冲突标出来，保留原始片段，不让生成模型自行挑一个看起来合理的版本。是否对外回答，要结合资料管理规则和人工核验结果决定。
这也解释了为什么画面 OCR 不能直接拼到字幕后面。拼接会让两种来源看起来像一段连续原文，冲突和归属都被隐藏。区分字段后，页面可以告诉用户某句话来自口播、某个数值来自画面，并分别回到对应时间和区域。面试官继续追问“怎样防止模型混淆两者”时，就可以回答：先在数据层保存来源类型与冲突状态，再在上下文构建时过滤未核验内容，而不是只靠提示词提醒模型小心。
面试官追问：视频重新处理时，怎样避免旧字幕继续被搜到？
视频处理规则更新后，不能只把新片段追加进索引。若旧字幕没有删除，用户可能同时搜到新旧两份证据；如果所有片段 ID 都随数组顺序变化，又会把一次局部修正变成整条视频的无差别替换。
可以把视频文件版本、时间范围、内容摘要和处理版本作为片段身份的一部分。重新处理前先生成一份待发布结果，与当前索引比较哪些片段未变、哪些需要替换、哪些已经消失。确认新字幕、时间位置和来源引用通过回归后，再切换到新版本；切换失败时仍能回到上一份可用结果。
需要重点回归的不是“新片段总数是否相同”，而是原来能回答的问题是否仍能找到同一段证据，修正过的坏样本是否消失，引用是否跳到正确位置，以及旧版本片段是否已经退出检索。这样才能证明重新处理没有制造重复证据或断开的来源链接。
面试官追问：视频被删除或权限改变后，字幕索引怎么办？
视频内容能够被搜索，不代表所有用户都应该看到它。原文件的可见范围、字幕片段的检索范围和答案里的播放链接必须使用同一套权限依据。只在播放器打开时检查权限不够，因为未授权片段可能已经在检索阶段进入上下文，模型甚至会在没有展示链接时泄露其中的信息。
因此，检索前应先限定用户能够访问的视频或资料集合，再在允许范围内搜索字幕。字幕片段需要保留所属视频和权限版本，缓存键也要带上用户或权限范围，不能把一个人的检索结果直接复用给另一个人。权限收紧后，要验证旧缓存、旧索引和已经生成的分享链接是否仍然暴露内容。
删除也不只是移走 MP4。与视频关联的字幕、画面文字、向量、片段映射和播放器引用都需要退出可检索状态。可以先把视频标成不可搜索，再异步清理派生内容，最后核对各存储中是否还有孤儿片段。清理过程中即使索引尚未物理删除，查询过滤也不能再让它返回。
面试官若继续问“怎样证明删除完成”，可以回答：用视频标识反查原文件、片段、向量和引用映射，确认查询无法命中，并记录清理任务的完成状态和失败项。这里不需要声称已经支持某种规模，只需讲清权限必须贯穿原文件、索引、缓存和引用，而不是只在页面上隐藏一个播放按钮。
视频时间跳转、字幕和画面对齐，都属于需要实现并验证的设计。没有播放器记录、测试问题和原始结果，就只能说“准备这样做”或“已经跑通这一步”，不能直接写成“效果提升了多少”。
还要区分原视频与派生数据的生命周期：字幕纠错、重新转写或画面抽取规则升级时，应生成可追踪的新版本，先用固定问题回归，再原子切换检索版本。否则播放器仍能打开，并不代表搜索到的字幕与当前视频一致。
同样要保存转写、OCR、切分与索引各自的处理版本；只有版本链完整，引用偏移时才能定位究竟是哪一步改变了时间坐标。
视频 RAG 的难点，不只是把文件后缀从 PDF 换成 MP4。
真正要解决的是：怎样把一小时视频变成一组能够搜索、能够回到原位置、也能够让人检查的内容。
知识库接收的不是文件，而是可以被找到和核验的内容。