长期做视频理解这块的人应该都遇到过同一个场面：一段两小时的会议录像或者一集四十多分钟的纪录片丢过来，用户只问一句“中间那个穿灰外套的人最后把方案交给谁了”，你就得让模型在几十万帧里找出答案。直接把视频帧塞进多模态模型的暴力做法，在短视频上还能勉强跑通，一旦时长拉到半小时以上，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 | 时间戳列表 | 答案无法给出出处 |
| confidence | 0 到 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 | 保留参与者、动作、对象 |
| 检索 | 粗召回 k | 30 到 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% 会直接污染共指边，进而污染所有跨段推理。后来我改成一个半自动流程，自动出候选、人工花二十分钟确认，整体效果提升幅度远超预期，投入产出比非常高。如果你的场景里实体数量不多，这个人工环节千万别省。
再分享一个调度上的小技巧：建图是个离线任务，但不必等全量完成。我现在的流程是流式建图——视频边解码边切分边生成事件，图在后台逐步长出来。用户上传后大概几十秒就能对前面几分钟的内容提问，后面的事件陆续补进来。这个体验提升比优化检索精度更直观，用户感知到的是“能用”和“不能用”的差别。
往后还能琢磨的方向，我个人比较感兴趣的有三个。一是事件描述的多视图化，同一个事件同时生成“动作视角”“情绪视角”“物体视角”三份短描述，分别建索引，对不同类型的问题用不同视图召回。二是图结构的动态修正，让用户对错误答案的反馈能反向修图，比如标记“这两个事件不是同一个人”，系统据此拆掉那条共指边。三是跨视频的事件图对齐，把同一系列的多期内容建成一张大图，支撑“上一次提到这个方案是什么时候”这类跨集检索。第三个方向工程量大，但价值也最大，尤其是内容型场景，我个人认为值得投入。
这套东西做下来，最大的感受是：长视频问答的瓶颈，早就不在模型能不能看懂单帧画面上了，而在怎么把几十万帧组织成模型能高效消费的结构。语义事件图不是唯一解，但它是目前性价比最高的那一档。
