长期做视频理解这块的人应该都遇到过同一个场面一段两小时的会议录像或者一集四十多分钟的纪录片丢过来用户只问一句“中间那个穿灰外套的人最后把方案交给谁了”你就得让模型在几十万帧里找出答案。直接把视频帧塞进多模态模型的暴力做法在短视频上还能勉强跑通一旦时长拉到半小时以上token 预算瞬间崩盘检索精度也跟着塌方。这两年我反复在做的就是一件事——把长视频压缩成一张语义事件图让模型不再“看视频”而是“读一张带时间戳的事件关系网”。这套思路是目前提升长视频问答效率最稳的路径之一它解决的不是模型能力问题而是信息组织问题。下面我把整套设计思路、建图流水线、参数取舍和踩坑记录一次性摊开讲适合已经做过基础视频检索、想往长时序推理走的中高级开发者也适合刚接触多模态问答、想找一个能落地的工程切入口的朋友。1. 长视频问答的老大难和语义事件图这味解药1.1 三个真实卡点塞不下、找不到、串不起先说清楚问题不然谈方案都是空的。长视频问答在实际工程里卡在三个地方而且这三个卡点是递进关系不是并列关系。第一是塞不下。一段 60 分钟的视频按 1fps 抽帧就是 3600 张图。就算用最省的编码方式每帧折算 500 多个视觉 token总输入也在 180 万 token 这个量级。目前的上下文窗口撑不住就算撑住了推理成本和延迟也没法接受。有人会说降采样到 0.1fps那又会出现新问题——动作类的关键瞬间恰好落在两帧之间直接丢失。第二是找不到。退一步用“分段摘要 向量召回”的做法把视频切成若干段每段生成一句描述然后按问题检索最相关的几段。这个方案在“视频里有没有出现过狗”这类问题上表现还行但一碰到需要跨段拼接的问题就露馅。比如“他第二次提到预算的时候桌上摆的是什么”答案需要同时定位“第二次提到预算”这个事件和它对应时间段里的视觉信息纯摘要召回很难保证两段落在同一个时间窗里。第三是串不起。真正难的问题是带推理链的像“A 先反对了 B 的提议后来为什么又同意了”。这类问题的答案不在任何单一片段里而在事件之间的因果和时序关系里。分段摘要天然是扁平的、无序的它丢掉了事件之间的连接模型拿到的是一堆散落的碎片只能靠猜。语义事件图针对的正是第三点同时顺带把前两点也缓解了——因为图本身就是一个高压缩比、可检索、带结构的表示。1.2 语义事件图是什么一张带时间戳的“事件通讯录”用生活化的说法语义事件图就是把长视频整理成一份事件通讯录。每一页记录一件事什么时候发生、谁参与了、做了什么、涉及什么物体、在什么场景、有没有留下可回溯的帧证据。页面之间用线连着标明“这件事紧接着那件事”“这件事导致了那件事”“这两件事说的是同一个人”。落到数据结构上它是一个属性图节点是事件带时间区间、参与者、动作、对象、场景、文本摘要、证据帧指针边是事件间关系主干三类时序相邻、因果关系、实体共指。再往上还可以叠一层层级边把若干原子事件归到一个“章节”节点下。比起纯文本摘要它多了两样东西。一是可回溯性每个节点都挂着原始帧的时间戳答案需要视觉细节时可以随时回捞不用重新跑一遍全视频。二是可多跳检索不必一次命中可以先找到起点事件再顺着边游走两三跳把整条链条捞出来。我做过一个粗略的对比测量同一段 58 分钟的素材表示方式送入模型的 token 量级跨段推理问题准确率证据可回溯全帧直塞1fps约 170 万不可行是均匀分段摘要60 段约 3500偏低否语义事件图约 70 节点约 4200明显更高是表里的准确率我不写具体数字因为跟素材类型强相关但趋势很稳定语义事件图用略高于分段摘要的 token 成本换来了结构化的关系信息这个买卖很划算。2. 建图之前先想清楚事件切分的粒度与字段设计2.1 切分粒度为什么是“镜头到事件”两层而不是一层粒度定错了后面全白干。粒度太细比如每 2 秒一个节点一小时视频能产出 1800 个节点图变成了另一个版本的“帧序列”检索照样爆炸粒度太粗比如每 5 分钟一个节点一个节点里塞了七八件事问答时模型根本分不清问的是哪一件。我的经验是两层结构底层是镜头级原子片段上层是事件节点事件由一到若干个原子片段合并而成。底层切分用镜头边界检测得到的是视觉上的连续性片段通常 1 到 8 秒一段。这一层只做一件事——提供一个稳定的、不会把单个动作劈成两半的最小单位。上层合并的规则不能只看时间长度得看语义连续性相邻原子片段如果满足下面任一条件就倾向于合并成同一个事件参与者集合重叠度高于阈值我一般用 0.6场景标签一致且动作描述的主语一致时间间隔小于 1.5 秒且中间没有明显的场景切换。合并的终止条件设一个硬上限单个事件不超过 90 秒。为什么是 90 秒因为事件摘要生成出来通常 40 到 60 个 token一个节点控制在 50 token 上下70 个节点总文本量约 3500 token刚好在可检索、可整体塞进上下文的舒适区。超过 90 秒的事件摘要会开始丢掉细节节点内部的时序也没法表达。注意不同视频类型的最佳粒度差别很大。教学讲解类可以放宽到 120 秒一个事件因为讲一段话就是一件事体育和动作类必须收紧到 30 秒以内否则一个节点里会同时包含“传球”和“射门”两件完全不同的事。2.2 节点字段少一个就答不对的那几个必填项节点字段设计上我踩过最典型的坑是“字段看起来很全但缺了关键那一个”。下面这几个字段是必须的每个都对应一类会答错的问题字段类型缺了它会怎样event_id字符串无法建边、无法回溯start_ts / end_ts浮点秒时间类问题全部失准participants列表“谁做的”类问题无法定位action短语检索召回精度断崖下跌object列表物体相关追问无法回答scene标签场景过滤失效summary一句话无法向量化evidence_frames时间戳列表答案无法给出出处confidence0 到 1无法做质量过滤与重排加权其中evidence_frames最容易被忽略。很多实现只存摘要文本不存证据帧指针结果就是模型答得出来但说不清用户一质疑就没法自证。我在第一版里也省了这个字段后来在复盘时发现超过三成的错答都是“关键词碰巧对上但时间段错位”加上证据帧之后人工核对效率提升非常明显。confidence也是必要的。事件抽取不可能百分之百准确尤其是遮挡严重、音频缺失的片段。给每个节点打一个置信度检索时可以按置信度加权或者干脆把低置信度节点标出来让生成阶段知道“这段信息不太可靠回答时最好留有余地”。2.3 边的设计时序、因果、共指三条主干边决定图的价值。只有节点没有边那就是一个带时间戳的列表跟分段摘要没本质区别。我建议先做三条主干边其余的按需扩展。时序边NEXT最简单按 start_ts 排序相邻事件连一条有向边。这条边支撑“之前之后”“紧接着”这类问题。注意要处理重叠事件两个事件时间区间有交叠时不能简单按开始时间连得按结束时间排序连边否则链条会断。因果边CAUSE触发条件需要一点设计。我的做法是让生成模型在产出事件摘要时额外输出一个可选字段“本事件是否由前序某个事件引起若是请给出序号”。这个提示词方式虽然朴素但比事后用规则推断靠谱得多。阈值上只保留模型给出明确置信的情况宁可少连不要错连——错误的因果边比没有因果边更有害它会把推理引向完全错误的方向。共指边SAME_ENTITY把共享参与者的节点连起来。这条边是解决“跨段追踪”问题的关键。实现上需要一个实体归一化步骤把人脸、声纹、物体特征分别聚类给每个实体分配一个全局 ID事件节点里存的是全局 ID 而不是“那个男人”。除了这三条还有一条层级边PART_OF把若干事件归到章节节点下。这条边对“整体流程”“分几个阶段”这类概括性问题特别有用可以先用章节节点粗筛再展开到具体事件。提示边不要贪多。我试过加“对比边”“空间共现边”收益很小反而让图变得稠密图游走的候选集膨胀重排压力骤增。三条主干加一条层级在大多数场景够用了。3. 从原始视频到可用图逐步拆解建图流水线3.1 抽帧与镜头检测的参数取舍抽帧这块参数不是拍脑袋定的得算。先明确目标镜头检测需要较高的时间分辨率事件摘要只需要少量关键帧。如果统一用一个采样率要么浪费算力要么检测不准。所以我用双路采样检测路以 5fps 的基准采样仅做镜头边界计算不做视觉编码开销主要在解码表示路每个镜头取首帧、中间帧、尾帧三张关键帧送入视觉编码器。算一下开销。一小时视频5fps 是 18000 帧只做缩放和直方图/特征差分单机 CPU 也能跑主要耗时在解码表示路的关键帧数量取决于镜头数一般长视频的镜头数在 400 到 900 之间按 600 算三帧关键帧就是 1800 张比 1fps 全采样3600 张少一半而且覆盖更均匀——固定采样率会在长镜头里浪费大量重复帧在快切镜头里又容易漏。镜头边界的判定阈值我通常设在 0.35 到 0.45 之间归一化的帧间差异分。阈值太低会把运镜误判成切换阈值太高会漏掉渐变转场。实测下来0.4 在会议、教学、访谈这些场景里比较稳如果是剪辑节奏快的纪录片可以降到 0.3再配合一个最短镜头时长约束不短于 0.8 秒抑制误切。3.2 事件描述的生成与压缩token 预算怎么算事件描述是整张图的语义锚点写得不好检索就废。我的做法是分两步先生成再压缩。第一步把事件内的关键帧通常 3 到 6 张连同时间信息一起交给视觉-语言模型要求它输出结构化字段而不是一段自由文本。提示词里明确要求“只描述可见事实不要推测动机”。这一步的输出会比较啰嗦没关系。第二步做压缩。压缩的目标是把单个事件的文本控制在 50 token 左右。压缩不是简单截断而是按优先级保留参与者 动作 对象 场景。抽象成模板就是“某人在某场景对某对象做了某事”。压缩后用一个小型文本编码器向量化存进向量索引。这里有个成本账可以算一下。假设一小时视频切出 70 个事件每个事件送 5 张关键帧做描述生成。如果直接上大模型成本和延迟都很可观。我的做法是分层先用较小规模的多模态模型批量生成初稿再对置信度低于阈值的节点比如 0.6 以下的用更强的模型重跑。实测下来重跑比例通常在 15% 到 25% 之间整体成本能压到全量强模型的三成左右。3.3 实体归一化同一张脸、同一件物品怎么对齐这是最脏最累但最不能省的一步。不做归一化共指边就是假的——同一个人的不同称呼会被当成两个人“穿灰外套的男人”和“讲话者 A”永远连不起来。我的流程是人脸聚类对每个镜头的人脸检测结果提取特征用层次聚类距离阈值设得稍宽松一点宁可合并不要过度分裂然后人工或规则给每个簇分配一个稳定的全局 ID。声纹聚类有音轨的场景下补一路声纹和人脸聚类结果做交叉验证。两者一致时置信度高不一致时保留两条候选不做强行合并。物体追踪对反复出现的物体比如文件、设备、道具用跟踪算法给短时 ID再做跨镜头的相似度匹配能匹配上的升格为全局 ID匹配不上的就只在局部事件内引用。这里有个很实用的技巧不要追求全自动。长视频的实体数量通常在几十个量级让一个自动流程输出候选簇人工花二十分钟核对一遍比调一周阈值划算得多。我在一个 90 分钟的素材上试过纯自动实体合并的错误率大概在 12% 左右人工核对后降到 2% 以下而这 2% 的错误基本集中在远景和侧脸对问答影响很小。3.4 落库与索引向量加图结构双索引存储上我是双份一份图数据库或普通的关系表存节点和边一份向量索引用存事件摘要的嵌入。两者通过 event_id 关联。查询的时候先走向量再做图扩展路径是向量召回 → 图游走 → 重排。这个顺序不能反反过来就变成全图扫描性能直接崩。索引层面有个细节值得说摘要向量和原始描述向量分开存。摘要短、信息密度高适合做粗召回原始描述长、细节多适合在重排阶段做精细匹配。两套索引的嵌入模型可以不同粗召回用轻量模型追求速度重排用更强模型追求精度。4. 在线问答链路从问题到答案的四次收敛4.1 问题解析把自然语言拆成检索意图用户的问题不能直接丢给向量检索。像“他为什么后来又同意了”里面包含指代他、事件指代又、关系类型因果直接向量化去搜召回质量很差。我在检索前加了一个轻量的解析步骤产出结构化查询实体槽位从问题里抽人名、物体、场景词时间槽位显式时间“在第 20 分钟左右”或相对时间“最后”“一开始”关系槽位从问句模式判断是找事件、找顺序、找原因还是找结果类型槽位是问“做了什么”动作类还是问“是什么”属性类还是问“为什么”因果类。解析用规则加小模型组合就够了不必上大模型。规则处理显式时间、数字这类确定性强的内容小模型处理指代消解和意图分类。这一步的收益非常明显——加了时间槽位过滤之后检索召回的前 20 条里混入的时间错位节点明显减少。4.2 粗召回与图扩展粗召回用摘要向量做稠密检索取前 30 到 50 个节点。k 值不能太小因为摘要短、语义模糊正确答案未必排在最前面也不能太大不然重排压力大。拿到种子节点后做图扩展规则是沿时序边向前后各扩一跳因为问题的答案经常在目标事件的“前一件事”或“后一件事”里沿共指边扩展同实体的节点最多扩两跳避免图爆炸如果问题被判定为因果类额外沿因果边向前扩一跳找原因或向后扩一跳找结果。扩展后的候选集一般在 80 到 150 个节点之间需要做去重和剪枝。剪枝规则包括去掉时间与时间槽位明显冲突的节点去掉置信度低于 0.4 的节点同一实体在 3 秒内的重复事件只留一个。4.3 重排与上下文打包重排用交叉编码器把问题与每个候选节点的完整描述做相关性打分取前 15 到 25 个节点。这个数量也是算出来的20 个节点 × 50 token 摘要约 1000 token加上节点的时间戳、参与者字段实际约 1400 token再留出问题、指令和证据帧描述的余量总上下文控制在 3000 token 以内绝大多数模型都能轻松吃下。打包的顺序很重要。我最初按相关度排序拼进去发现模型经常把时间顺序搞混回答“先发生了什么”时出错。后来改成先按相关度筛选再按时间重排同时在每个节点前显式写入时间戳和序号顺序类问题的准确率提升明显。4.4 生成与证据回填生成阶段的关键约束是“只依据给定事件回答如果证据不足就说不知道”。这句话一定要写进指令否则模型会拿预训练知识硬编尤其在人物身份、地点这类问题上。证据回填是在答案里标注引用了哪几个 event_id前端可以点击跳转到对应时间点。这一步对体验的提升比想象中大用户一旦能自己验证对系统的信任度完全不一样。回填的实现很简单让生成模型在输出答案时同步输出引用的节点序号列表再做一次格式校验即可。5. 实操参数与效果验证一套可直接抄的配置5.1 完整参数配置表下面这套参数是我在多个中长视频素材上收敛出来的起点配置直接拿来跑通常不会太差再按具体场景微调。环节参数取值说明抽帧检测路采样率5 fps只做边界判定抽帧表示路关键帧每镜头 3 张首、中、尾镜头检测差异阈值0.40快节奏素材降到 0.30镜头检测最短镜头0.8 s抑制误切事件合并实体重叠阈值0.6低于则不合并事件合并单事件时长上限90 s教学类可放宽到 120 s描述生成单事件关键帧数3 到 6 张超过 6 张收益递减描述压缩单节点 token约 50保留参与者、动作、对象检索粗召回 k30 到 50按库规模调整检索图扩展跳数1 到 2因果类额外扩重排保留节点数15 到 25上下文预算决定生成上下文上限3000 token留足余量5.2 一个具体例子走完全流程拿一段 47 分钟的圆桌讨论素材举例走一遍看看每个环节产出什么。建图阶段。镜头检测输出 512 个镜头。事件合并后得到 63 个事件节点其中 8 个是单人长段发言11 个是多人交替讨论其余是过渡和场景切换。实体归一化识别出 6 个主要参与者其中 1 个因为只有侧脸和背影置信度只有 0.55在节点里标记为未知参与者。问题示例一“B 在反驳 A 之后自己提出的替代方案是什么”解析结果关系槽位是“之后”因果槽位是“反驳”实体槽位是 A 和 B。粗召回拿到 41 个候选图扩展沿共指边捞出所有涉及 A 和 B 的节点共 96 个剪枝后剩 71 个。重排保留 22 个其中包含了“A 提出方案”“B 反驳”“B 提出替代方案”这三个关键节点它们在时间上是连续的三跳。如果只用分段摘要这三段很可能被分到不同的段里而且“反驳”这个语义在摘要里往往被弱化成“B 发表了意见”检索时根本对不上。语义事件图的价值就体现在这里——动作动词被显式保留在节点字段里。问题示例二“整场讨论一共形成了几个结论”这属于概括类问题走的是层级边。章节节点下有 3 个汇总节点分别对应三个讨论阶段每个汇总节点连着一组事件。生成阶段先读汇总节点再按需展开细节答案的完整性明显好于直接对 63 个节点做总结。5.3 怎么评估建图质量建图没有标准评测集得自己搭。我的做法是抽检加端到端评测双轨走。建图抽检随机抽 100 个事件节点人工判定三件事——事件边界是否正确是否把两件事合成了一个或把一件事劈成了两个、参与者标注是否正确、摘要是否遗漏关键动作。三项分别算准确率低于 85% 就说明某个环节的参数需要调。实践里最容易出问题的是边界尤其是多人群聊场景里的说话人切换。端到端评测按问题类型分层构造测试集至少覆盖四类——单事件事实类、跨段追踪类、时序类、因果类每类 30 题以上。分层的好处是能看出瓶颈在哪一层如果单事件类准确率高而因果类低说明边没建好如果四类都低问题多半在事件描述质量或检索召回。还有一个容易被忽略的指标证据命中率。就是答案正确的前提下引用的 event_id 是否真的包含答案依据。这个指标能暴露“答案蒙对但过程错误”的情况对后续迭代的指导意义比单纯的准确率更大。6. 常见问题与排查实录6.1 事件漏抽与边界错位症状问答时模型说“视频中没有提到”但人工一看某个关键动作确实存在。排查路径先看该时间段有没有生成事件节点。没有节点说明抽帧或镜头检测漏了有节点但摘要里没有该动作说明描述生成漏了摘要里有但检索没召回说明是索引或检索的问题。这三层要一层层往下查不要一上来就改提示词。典型原因和解决快速动作被固定采样率跳过。解决办法是在镜头内部做一次基于帧差的高变化点检测把变化剧烈的时刻补进关键帧列表。镜头检测阈值过高把渐变转场当成同一镜头导致两个事件被合并成一个其中一件被摘要挤压掉了。降低阈值或缩短事件合并的时长上限。描述生成的提示词要求“简洁”模型过度概括。改成要求“必须包含动作动词和动作对象”简洁性留给压缩步骤处理。心得漏抽问题八成出在切分阶段不在模型阶段。先怀疑切分再怀疑模型这个顺序能省下大量调试时间。6.2 检索命中但答案错症状检索回来的节点里明明有正确答案模型却答错了或者答成了别的事件。排查路径把打包进上下文的节点按顺序打印出来人工看一遍。常见情况是时间戳冲突——两个节点在描述上相似但时间不同模型选错了。或者打包顺序把时间关系搞乱了。解决显式写入绝对时间戳和相对序号并在指令里强调“注意每个事件的时间”对同实体节点的重复描述做去重避免模型被高度相似的两段文字干扰重排阶段加入时间一致性约束如果问题里有时间槽位与之冲突的节点直接降权。6.3 时间与顺序类问题答不准症状问“先发生了什么”答案顺序颠倒问“过了多久”时间差算错。原因这类问题的答案不在单个节点里而在节点之间的间隔上。如果只把事件内容喂给模型不给时间数值模型只能靠文本顺序猜。解决把 start_ts 和 end_ts 作为结构化字段显式写入上下文格式固定成“序号 | 起止时间 | 摘要”的表格形式对于“过了多久”这类计算题在生成前加一步确定性的计算直接从时间戳算出差值再把结果作为提示交给模型避免模型自己做算术。6.4 常见问题速查表现象最可能的原因优先动作答“视频中未提及”事件漏抽查该时段的节点存在性答案张冠李戴时间戳缺失或打包顺序乱检查上下文格式跨段问题只能答一半共指边缺失查实体归一化结果因果问题答成时序因果边未建或建错抽检因果边准确率概括类问题答得零散缺层级节点补章节汇总节点答案笼统不敢下结论低置信节点未标记加置信度字段与提示检索慢图游走跳数过多收紧扩展规则建图成本高全量走强模型分层生成加权重重跑7. 我踩过的坑和几个可以继续琢磨的方向真正让我改了三次架构的不是模型选型而是两个很朴素的问题。第一个是事件边界的“主观性”。同一段素材我标注和我同事标注的事件切分能差出 20%。后来想明白了事件边界本来就是有层级的——五分钟可以是一件事三十秒也可以是同一件事的一个子动作。所以别指望有一个绝对正确的切分目标是让切分和你的问题类型匹配。如果你的问题多是“做了什么”粒度细一点如果多是“整体讲了什么”粒度粗一点。我现在会为同一段视频建两套粒度不同的图粗图做概览细图做定位成本增加不多但覆盖面宽了很多。第二个是别过度相信自动实体归一化。前面提过纯自动的错误率能到 12%而这 12% 会直接污染共指边进而污染所有跨段推理。后来我改成一个半自动流程自动出候选、人工花二十分钟确认整体效果提升幅度远超预期投入产出比非常高。如果你的场景里实体数量不多这个人工环节千万别省。再分享一个调度上的小技巧建图是个离线任务但不必等全量完成。我现在的流程是流式建图——视频边解码边切分边生成事件图在后台逐步长出来。用户上传后大概几十秒就能对前面几分钟的内容提问后面的事件陆续补进来。这个体验提升比优化检索精度更直观用户感知到的是“能用”和“不能用”的差别。往后还能琢磨的方向我个人比较感兴趣的有三个。一是事件描述的多视图化同一个事件同时生成“动作视角”“情绪视角”“物体视角”三份短描述分别建索引对不同类型的问题用不同视图召回。二是图结构的动态修正让用户对错误答案的反馈能反向修图比如标记“这两个事件不是同一个人”系统据此拆掉那条共指边。三是跨视频的事件图对齐把同一系列的多期内容建成一张大图支撑“上一次提到这个方案是什么时候”这类跨集检索。第三个方向工程量大但价值也最大尤其是内容型场景我个人认为值得投入。这套东西做下来最大的感受是长视频问答的瓶颈早就不在模型能不能看懂单帧画面上了而在怎么把几十万帧组织成模型能高效消费的结构。语义事件图不是唯一解但它是目前性价比最高的那一档。
长期做视频理解这块的人应该都遇到过同一个场面一段两小时的会议录像或者一集四十多分钟的纪录片丢过来用户只问一句“中间那个穿灰外套的人最后把方案交给谁了”你就得让模型在几十万帧里找出答案。直接把视频帧塞进多模态模型的暴力做法在短视频上还能勉强跑通一旦时长拉到半小时以上token 预算瞬间崩盘检索精度也跟着塌方。这两年我反复在做的就是一件事——把长视频压缩成一张语义事件图让模型不再“看视频”而是“读一张带时间戳的事件关系网”。这套思路是目前提升长视频问答效率最稳的路径之一它解决的不是模型能力问题而是信息组织问题。下面我把整套设计思路、建图流水线、参数取舍和踩坑记录一次性摊开讲适合已经做过基础视频检索、想往长时序推理走的中高级开发者也适合刚接触多模态问答、想找一个能落地的工程切入口的朋友。1. 长视频问答的老大难和语义事件图这味解药1.1 三个真实卡点塞不下、找不到、串不起先说清楚问题不然谈方案都是空的。长视频问答在实际工程里卡在三个地方而且这三个卡点是递进关系不是并列关系。第一是塞不下。一段 60 分钟的视频按 1fps 抽帧就是 3600 张图。就算用最省的编码方式每帧折算 500 多个视觉 token总输入也在 180 万 token 这个量级。目前的上下文窗口撑不住就算撑住了推理成本和延迟也没法接受。有人会说降采样到 0.1fps那又会出现新问题——动作类的关键瞬间恰好落在两帧之间直接丢失。第二是找不到。退一步用“分段摘要 向量召回”的做法把视频切成若干段每段生成一句描述然后按问题检索最相关的几段。这个方案在“视频里有没有出现过狗”这类问题上表现还行但一碰到需要跨段拼接的问题就露馅。比如“他第二次提到预算的时候桌上摆的是什么”答案需要同时定位“第二次提到预算”这个事件和它对应时间段里的视觉信息纯摘要召回很难保证两段落在同一个时间窗里。第三是串不起。真正难的问题是带推理链的像“A 先反对了 B 的提议后来为什么又同意了”。这类问题的答案不在任何单一片段里而在事件之间的因果和时序关系里。分段摘要天然是扁平的、无序的它丢掉了事件之间的连接模型拿到的是一堆散落的碎片只能靠猜。语义事件图针对的正是第三点同时顺带把前两点也缓解了——因为图本身就是一个高压缩比、可检索、带结构的表示。1.2 语义事件图是什么一张带时间戳的“事件通讯录”用生活化的说法语义事件图就是把长视频整理成一份事件通讯录。每一页记录一件事什么时候发生、谁参与了、做了什么、涉及什么物体、在什么场景、有没有留下可回溯的帧证据。页面之间用线连着标明“这件事紧接着那件事”“这件事导致了那件事”“这两件事说的是同一个人”。落到数据结构上它是一个属性图节点是事件带时间区间、参与者、动作、对象、场景、文本摘要、证据帧指针边是事件间关系主干三类时序相邻、因果关系、实体共指。再往上还可以叠一层层级边把若干原子事件归到一个“章节”节点下。比起纯文本摘要它多了两样东西。一是可回溯性每个节点都挂着原始帧的时间戳答案需要视觉细节时可以随时回捞不用重新跑一遍全视频。二是可多跳检索不必一次命中可以先找到起点事件再顺着边游走两三跳把整条链条捞出来。我做过一个粗略的对比测量同一段 58 分钟的素材表示方式送入模型的 token 量级跨段推理问题准确率证据可回溯全帧直塞1fps约 170 万不可行是均匀分段摘要60 段约 3500偏低否语义事件图约 70 节点约 4200明显更高是表里的准确率我不写具体数字因为跟素材类型强相关但趋势很稳定语义事件图用略高于分段摘要的 token 成本换来了结构化的关系信息这个买卖很划算。2. 建图之前先想清楚事件切分的粒度与字段设计2.1 切分粒度为什么是“镜头到事件”两层而不是一层粒度定错了后面全白干。粒度太细比如每 2 秒一个节点一小时视频能产出 1800 个节点图变成了另一个版本的“帧序列”检索照样爆炸粒度太粗比如每 5 分钟一个节点一个节点里塞了七八件事问答时模型根本分不清问的是哪一件。我的经验是两层结构底层是镜头级原子片段上层是事件节点事件由一到若干个原子片段合并而成。底层切分用镜头边界检测得到的是视觉上的连续性片段通常 1 到 8 秒一段。这一层只做一件事——提供一个稳定的、不会把单个动作劈成两半的最小单位。上层合并的规则不能只看时间长度得看语义连续性相邻原子片段如果满足下面任一条件就倾向于合并成同一个事件参与者集合重叠度高于阈值我一般用 0.6场景标签一致且动作描述的主语一致时间间隔小于 1.5 秒且中间没有明显的场景切换。合并的终止条件设一个硬上限单个事件不超过 90 秒。为什么是 90 秒因为事件摘要生成出来通常 40 到 60 个 token一个节点控制在 50 token 上下70 个节点总文本量约 3500 token刚好在可检索、可整体塞进上下文的舒适区。超过 90 秒的事件摘要会开始丢掉细节节点内部的时序也没法表达。注意不同视频类型的最佳粒度差别很大。教学讲解类可以放宽到 120 秒一个事件因为讲一段话就是一件事体育和动作类必须收紧到 30 秒以内否则一个节点里会同时包含“传球”和“射门”两件完全不同的事。2.2 节点字段少一个就答不对的那几个必填项节点字段设计上我踩过最典型的坑是“字段看起来很全但缺了关键那一个”。下面这几个字段是必须的每个都对应一类会答错的问题字段类型缺了它会怎样event_id字符串无法建边、无法回溯start_ts / end_ts浮点秒时间类问题全部失准participants列表“谁做的”类问题无法定位action短语检索召回精度断崖下跌object列表物体相关追问无法回答scene标签场景过滤失效summary一句话无法向量化evidence_frames时间戳列表答案无法给出出处confidence0 到 1无法做质量过滤与重排加权其中evidence_frames最容易被忽略。很多实现只存摘要文本不存证据帧指针结果就是模型答得出来但说不清用户一质疑就没法自证。我在第一版里也省了这个字段后来在复盘时发现超过三成的错答都是“关键词碰巧对上但时间段错位”加上证据帧之后人工核对效率提升非常明显。confidence也是必要的。事件抽取不可能百分之百准确尤其是遮挡严重、音频缺失的片段。给每个节点打一个置信度检索时可以按置信度加权或者干脆把低置信度节点标出来让生成阶段知道“这段信息不太可靠回答时最好留有余地”。2.3 边的设计时序、因果、共指三条主干边决定图的价值。只有节点没有边那就是一个带时间戳的列表跟分段摘要没本质区别。我建议先做三条主干边其余的按需扩展。时序边NEXT最简单按 start_ts 排序相邻事件连一条有向边。这条边支撑“之前之后”“紧接着”这类问题。注意要处理重叠事件两个事件时间区间有交叠时不能简单按开始时间连得按结束时间排序连边否则链条会断。因果边CAUSE触发条件需要一点设计。我的做法是让生成模型在产出事件摘要时额外输出一个可选字段“本事件是否由前序某个事件引起若是请给出序号”。这个提示词方式虽然朴素但比事后用规则推断靠谱得多。阈值上只保留模型给出明确置信的情况宁可少连不要错连——错误的因果边比没有因果边更有害它会把推理引向完全错误的方向。共指边SAME_ENTITY把共享参与者的节点连起来。这条边是解决“跨段追踪”问题的关键。实现上需要一个实体归一化步骤把人脸、声纹、物体特征分别聚类给每个实体分配一个全局 ID事件节点里存的是全局 ID 而不是“那个男人”。除了这三条还有一条层级边PART_OF把若干事件归到章节节点下。这条边对“整体流程”“分几个阶段”这类概括性问题特别有用可以先用章节节点粗筛再展开到具体事件。提示边不要贪多。我试过加“对比边”“空间共现边”收益很小反而让图变得稠密图游走的候选集膨胀重排压力骤增。三条主干加一条层级在大多数场景够用了。3. 从原始视频到可用图逐步拆解建图流水线3.1 抽帧与镜头检测的参数取舍抽帧这块参数不是拍脑袋定的得算。先明确目标镜头检测需要较高的时间分辨率事件摘要只需要少量关键帧。如果统一用一个采样率要么浪费算力要么检测不准。所以我用双路采样检测路以 5fps 的基准采样仅做镜头边界计算不做视觉编码开销主要在解码表示路每个镜头取首帧、中间帧、尾帧三张关键帧送入视觉编码器。算一下开销。一小时视频5fps 是 18000 帧只做缩放和直方图/特征差分单机 CPU 也能跑主要耗时在解码表示路的关键帧数量取决于镜头数一般长视频的镜头数在 400 到 900 之间按 600 算三帧关键帧就是 1800 张比 1fps 全采样3600 张少一半而且覆盖更均匀——固定采样率会在长镜头里浪费大量重复帧在快切镜头里又容易漏。镜头边界的判定阈值我通常设在 0.35 到 0.45 之间归一化的帧间差异分。阈值太低会把运镜误判成切换阈值太高会漏掉渐变转场。实测下来0.4 在会议、教学、访谈这些场景里比较稳如果是剪辑节奏快的纪录片可以降到 0.3再配合一个最短镜头时长约束不短于 0.8 秒抑制误切。3.2 事件描述的生成与压缩token 预算怎么算事件描述是整张图的语义锚点写得不好检索就废。我的做法是分两步先生成再压缩。第一步把事件内的关键帧通常 3 到 6 张连同时间信息一起交给视觉-语言模型要求它输出结构化字段而不是一段自由文本。提示词里明确要求“只描述可见事实不要推测动机”。这一步的输出会比较啰嗦没关系。第二步做压缩。压缩的目标是把单个事件的文本控制在 50 token 左右。压缩不是简单截断而是按优先级保留参与者 动作 对象 场景。抽象成模板就是“某人在某场景对某对象做了某事”。压缩后用一个小型文本编码器向量化存进向量索引。这里有个成本账可以算一下。假设一小时视频切出 70 个事件每个事件送 5 张关键帧做描述生成。如果直接上大模型成本和延迟都很可观。我的做法是分层先用较小规模的多模态模型批量生成初稿再对置信度低于阈值的节点比如 0.6 以下的用更强的模型重跑。实测下来重跑比例通常在 15% 到 25% 之间整体成本能压到全量强模型的三成左右。3.3 实体归一化同一张脸、同一件物品怎么对齐这是最脏最累但最不能省的一步。不做归一化共指边就是假的——同一个人的不同称呼会被当成两个人“穿灰外套的男人”和“讲话者 A”永远连不起来。我的流程是人脸聚类对每个镜头的人脸检测结果提取特征用层次聚类距离阈值设得稍宽松一点宁可合并不要过度分裂然后人工或规则给每个簇分配一个稳定的全局 ID。声纹聚类有音轨的场景下补一路声纹和人脸聚类结果做交叉验证。两者一致时置信度高不一致时保留两条候选不做强行合并。物体追踪对反复出现的物体比如文件、设备、道具用跟踪算法给短时 ID再做跨镜头的相似度匹配能匹配上的升格为全局 ID匹配不上的就只在局部事件内引用。这里有个很实用的技巧不要追求全自动。长视频的实体数量通常在几十个量级让一个自动流程输出候选簇人工花二十分钟核对一遍比调一周阈值划算得多。我在一个 90 分钟的素材上试过纯自动实体合并的错误率大概在 12% 左右人工核对后降到 2% 以下而这 2% 的错误基本集中在远景和侧脸对问答影响很小。3.4 落库与索引向量加图结构双索引存储上我是双份一份图数据库或普通的关系表存节点和边一份向量索引用存事件摘要的嵌入。两者通过 event_id 关联。查询的时候先走向量再做图扩展路径是向量召回 → 图游走 → 重排。这个顺序不能反反过来就变成全图扫描性能直接崩。索引层面有个细节值得说摘要向量和原始描述向量分开存。摘要短、信息密度高适合做粗召回原始描述长、细节多适合在重排阶段做精细匹配。两套索引的嵌入模型可以不同粗召回用轻量模型追求速度重排用更强模型追求精度。4. 在线问答链路从问题到答案的四次收敛4.1 问题解析把自然语言拆成检索意图用户的问题不能直接丢给向量检索。像“他为什么后来又同意了”里面包含指代他、事件指代又、关系类型因果直接向量化去搜召回质量很差。我在检索前加了一个轻量的解析步骤产出结构化查询实体槽位从问题里抽人名、物体、场景词时间槽位显式时间“在第 20 分钟左右”或相对时间“最后”“一开始”关系槽位从问句模式判断是找事件、找顺序、找原因还是找结果类型槽位是问“做了什么”动作类还是问“是什么”属性类还是问“为什么”因果类。解析用规则加小模型组合就够了不必上大模型。规则处理显式时间、数字这类确定性强的内容小模型处理指代消解和意图分类。这一步的收益非常明显——加了时间槽位过滤之后检索召回的前 20 条里混入的时间错位节点明显减少。4.2 粗召回与图扩展粗召回用摘要向量做稠密检索取前 30 到 50 个节点。k 值不能太小因为摘要短、语义模糊正确答案未必排在最前面也不能太大不然重排压力大。拿到种子节点后做图扩展规则是沿时序边向前后各扩一跳因为问题的答案经常在目标事件的“前一件事”或“后一件事”里沿共指边扩展同实体的节点最多扩两跳避免图爆炸如果问题被判定为因果类额外沿因果边向前扩一跳找原因或向后扩一跳找结果。扩展后的候选集一般在 80 到 150 个节点之间需要做去重和剪枝。剪枝规则包括去掉时间与时间槽位明显冲突的节点去掉置信度低于 0.4 的节点同一实体在 3 秒内的重复事件只留一个。4.3 重排与上下文打包重排用交叉编码器把问题与每个候选节点的完整描述做相关性打分取前 15 到 25 个节点。这个数量也是算出来的20 个节点 × 50 token 摘要约 1000 token加上节点的时间戳、参与者字段实际约 1400 token再留出问题、指令和证据帧描述的余量总上下文控制在 3000 token 以内绝大多数模型都能轻松吃下。打包的顺序很重要。我最初按相关度排序拼进去发现模型经常把时间顺序搞混回答“先发生了什么”时出错。后来改成先按相关度筛选再按时间重排同时在每个节点前显式写入时间戳和序号顺序类问题的准确率提升明显。4.4 生成与证据回填生成阶段的关键约束是“只依据给定事件回答如果证据不足就说不知道”。这句话一定要写进指令否则模型会拿预训练知识硬编尤其在人物身份、地点这类问题上。证据回填是在答案里标注引用了哪几个 event_id前端可以点击跳转到对应时间点。这一步对体验的提升比想象中大用户一旦能自己验证对系统的信任度完全不一样。回填的实现很简单让生成模型在输出答案时同步输出引用的节点序号列表再做一次格式校验即可。5. 实操参数与效果验证一套可直接抄的配置5.1 完整参数配置表下面这套参数是我在多个中长视频素材上收敛出来的起点配置直接拿来跑通常不会太差再按具体场景微调。环节参数取值说明抽帧检测路采样率5 fps只做边界判定抽帧表示路关键帧每镜头 3 张首、中、尾镜头检测差异阈值0.40快节奏素材降到 0.30镜头检测最短镜头0.8 s抑制误切事件合并实体重叠阈值0.6低于则不合并事件合并单事件时长上限90 s教学类可放宽到 120 s描述生成单事件关键帧数3 到 6 张超过 6 张收益递减描述压缩单节点 token约 50保留参与者、动作、对象检索粗召回 k30 到 50按库规模调整检索图扩展跳数1 到 2因果类额外扩重排保留节点数15 到 25上下文预算决定生成上下文上限3000 token留足余量5.2 一个具体例子走完全流程拿一段 47 分钟的圆桌讨论素材举例走一遍看看每个环节产出什么。建图阶段。镜头检测输出 512 个镜头。事件合并后得到 63 个事件节点其中 8 个是单人长段发言11 个是多人交替讨论其余是过渡和场景切换。实体归一化识别出 6 个主要参与者其中 1 个因为只有侧脸和背影置信度只有 0.55在节点里标记为未知参与者。问题示例一“B 在反驳 A 之后自己提出的替代方案是什么”解析结果关系槽位是“之后”因果槽位是“反驳”实体槽位是 A 和 B。粗召回拿到 41 个候选图扩展沿共指边捞出所有涉及 A 和 B 的节点共 96 个剪枝后剩 71 个。重排保留 22 个其中包含了“A 提出方案”“B 反驳”“B 提出替代方案”这三个关键节点它们在时间上是连续的三跳。如果只用分段摘要这三段很可能被分到不同的段里而且“反驳”这个语义在摘要里往往被弱化成“B 发表了意见”检索时根本对不上。语义事件图的价值就体现在这里——动作动词被显式保留在节点字段里。问题示例二“整场讨论一共形成了几个结论”这属于概括类问题走的是层级边。章节节点下有 3 个汇总节点分别对应三个讨论阶段每个汇总节点连着一组事件。生成阶段先读汇总节点再按需展开细节答案的完整性明显好于直接对 63 个节点做总结。5.3 怎么评估建图质量建图没有标准评测集得自己搭。我的做法是抽检加端到端评测双轨走。建图抽检随机抽 100 个事件节点人工判定三件事——事件边界是否正确是否把两件事合成了一个或把一件事劈成了两个、参与者标注是否正确、摘要是否遗漏关键动作。三项分别算准确率低于 85% 就说明某个环节的参数需要调。实践里最容易出问题的是边界尤其是多人群聊场景里的说话人切换。端到端评测按问题类型分层构造测试集至少覆盖四类——单事件事实类、跨段追踪类、时序类、因果类每类 30 题以上。分层的好处是能看出瓶颈在哪一层如果单事件类准确率高而因果类低说明边没建好如果四类都低问题多半在事件描述质量或检索召回。还有一个容易被忽略的指标证据命中率。就是答案正确的前提下引用的 event_id 是否真的包含答案依据。这个指标能暴露“答案蒙对但过程错误”的情况对后续迭代的指导意义比单纯的准确率更大。6. 常见问题与排查实录6.1 事件漏抽与边界错位症状问答时模型说“视频中没有提到”但人工一看某个关键动作确实存在。排查路径先看该时间段有没有生成事件节点。没有节点说明抽帧或镜头检测漏了有节点但摘要里没有该动作说明描述生成漏了摘要里有但检索没召回说明是索引或检索的问题。这三层要一层层往下查不要一上来就改提示词。典型原因和解决快速动作被固定采样率跳过。解决办法是在镜头内部做一次基于帧差的高变化点检测把变化剧烈的时刻补进关键帧列表。镜头检测阈值过高把渐变转场当成同一镜头导致两个事件被合并成一个其中一件被摘要挤压掉了。降低阈值或缩短事件合并的时长上限。描述生成的提示词要求“简洁”模型过度概括。改成要求“必须包含动作动词和动作对象”简洁性留给压缩步骤处理。心得漏抽问题八成出在切分阶段不在模型阶段。先怀疑切分再怀疑模型这个顺序能省下大量调试时间。6.2 检索命中但答案错症状检索回来的节点里明明有正确答案模型却答错了或者答成了别的事件。排查路径把打包进上下文的节点按顺序打印出来人工看一遍。常见情况是时间戳冲突——两个节点在描述上相似但时间不同模型选错了。或者打包顺序把时间关系搞乱了。解决显式写入绝对时间戳和相对序号并在指令里强调“注意每个事件的时间”对同实体节点的重复描述做去重避免模型被高度相似的两段文字干扰重排阶段加入时间一致性约束如果问题里有时间槽位与之冲突的节点直接降权。6.3 时间与顺序类问题答不准症状问“先发生了什么”答案顺序颠倒问“过了多久”时间差算错。原因这类问题的答案不在单个节点里而在节点之间的间隔上。如果只把事件内容喂给模型不给时间数值模型只能靠文本顺序猜。解决把 start_ts 和 end_ts 作为结构化字段显式写入上下文格式固定成“序号 | 起止时间 | 摘要”的表格形式对于“过了多久”这类计算题在生成前加一步确定性的计算直接从时间戳算出差值再把结果作为提示交给模型避免模型自己做算术。6.4 常见问题速查表现象最可能的原因优先动作答“视频中未提及”事件漏抽查该时段的节点存在性答案张冠李戴时间戳缺失或打包顺序乱检查上下文格式跨段问题只能答一半共指边缺失查实体归一化结果因果问题答成时序因果边未建或建错抽检因果边准确率概括类问题答得零散缺层级节点补章节汇总节点答案笼统不敢下结论低置信节点未标记加置信度字段与提示检索慢图游走跳数过多收紧扩展规则建图成本高全量走强模型分层生成加权重重跑7. 我踩过的坑和几个可以继续琢磨的方向真正让我改了三次架构的不是模型选型而是两个很朴素的问题。第一个是事件边界的“主观性”。同一段素材我标注和我同事标注的事件切分能差出 20%。后来想明白了事件边界本来就是有层级的——五分钟可以是一件事三十秒也可以是同一件事的一个子动作。所以别指望有一个绝对正确的切分目标是让切分和你的问题类型匹配。如果你的问题多是“做了什么”粒度细一点如果多是“整体讲了什么”粒度粗一点。我现在会为同一段视频建两套粒度不同的图粗图做概览细图做定位成本增加不多但覆盖面宽了很多。第二个是别过度相信自动实体归一化。前面提过纯自动的错误率能到 12%而这 12% 会直接污染共指边进而污染所有跨段推理。后来我改成一个半自动流程自动出候选、人工花二十分钟确认整体效果提升幅度远超预期投入产出比非常高。如果你的场景里实体数量不多这个人工环节千万别省。再分享一个调度上的小技巧建图是个离线任务但不必等全量完成。我现在的流程是流式建图——视频边解码边切分边生成事件图在后台逐步长出来。用户上传后大概几十秒就能对前面几分钟的内容提问后面的事件陆续补进来。这个体验提升比优化检索精度更直观用户感知到的是“能用”和“不能用”的差别。往后还能琢磨的方向我个人比较感兴趣的有三个。一是事件描述的多视图化同一个事件同时生成“动作视角”“情绪视角”“物体视角”三份短描述分别建索引对不同类型的问题用不同视图召回。二是图结构的动态修正让用户对错误答案的反馈能反向修图比如标记“这两个事件不是同一个人”系统据此拆掉那条共指边。三是跨视频的事件图对齐把同一系列的多期内容建成一张大图支撑“上一次提到这个方案是什么时候”这类跨集检索。第三个方向工程量大但价值也最大尤其是内容型场景我个人认为值得投入。这套东西做下来最大的感受是长视频问答的瓶颈早就不在模型能不能看懂单帧画面上了而在怎么把几十万帧组织成模型能高效消费的结构。语义事件图不是唯一解但它是目前性价比最高的那一档。
 与 data-* 自定义属性)
