把一段 1 小时的停车场监控录像交给当前主流的视频大模型然后问它“这 1 小时里有几辆车从 B 区出口驶出”你会得到一个非常反直觉的结果模型回答得很自信但数字经常是错的。更离谱的是如果这件事一共只发生了 2 次模型的错误率往往比发生了 50 次时还高——它可能说“0 次”也可能说“5 次”。这就是近期视频大模型研究里被反复讨论的“低频陷阱”Low Frequency Trap。粗看这个结论只是在说“模型数数不行”但细想就会发现它戳中的其实是视频大模型最基础的一项能力短板事件记账Event Bookkeeping。视频模型在“看懂一个片段”上进步很快在“给整段视频记流水账”上却远没有及格。本文不打算复述某篇论文的实验细节而是从问题本身出发拆解三件事事件记账到底难在哪、低频陷阱是怎么形成的、以及我们在实际项目里有哪些能落地的绕开方案。文章后面会给出可复用的评测脚本和工程建议适合正在做视频理解、视频检索、监控分析或多模态应用的工程师和技术负责人阅读。1. 这篇文章真正要解决的问题先给“事件记账”一个直觉定义它指的是模型在看完一段完整视频后能像会计记账一样准确回答“某个事件发生了多少次、发生在什么时候、先后顺序是什么、当时的状态是什么”。典型问题包括红色车一共经过路口几次仓库里的人从几点到几点处于滞留状态人员是先戴了安全帽还是先进入施工区域这条生产线上一共出现了几次异常抖动这些问题在人类看来非常简单甚至不需要高级推理只需要“认真看完整段视频然后一条一条记下来”。但视频大模型恰恰在这类问题上系统性翻车。为什么这件事值得专门写一篇文章因为事件记账是所有视频理解业务的地基。监控安防要数人、数车体育分析要统计传球次数和犯规顺序工业质检要记录异常发生频次自动驾驶要判断某个低频交通事件是否出现。如果模型记不住账后面再强的语义分析、推理、问答都是空中楼阁。更值得警惕的是“低频陷阱”造成的认知偏差。日常评测里我们通常拿那些事件密集出现的视频去测模型模型看起来表现不错可一旦进入真实场景关键事件往往是稀疏的——一次闯入、一次违规变道、一次设备异响一小时内可能只出现一次。模型在低频事件上的失败率会比评测指标显示的高得多。这才是“陷阱”二字的真正含义不是模型完全不会而是它在最需要被信任的时刻掉链子。2. 基础概念视频大模型、事件记账与低频陷阱2.1 视频大模型是什么视频大模型通常指以视觉编码器Video Encoder将视频帧转换为视觉令牌Visual Tokens再送入大语言模型LLM进行统一推理的多模态模型。它的核心流程大致是对视频做均匀或随机采样抽出一批帧。用视觉编码器把每帧编码成若干视觉令牌。将视觉令牌序列与文本指令拼接交给 LLM 生成回复。这里面有两个关键点。第一模型看到的不是“连续视频”而是“采样后的帧集合”时序关系是隐式编码在令牌顺序里的。第二视觉令牌数量通常很大一小时的视频经过压缩后仍然可能有数千甚至上万令牌而模型最终只能通过有限的计算资源完成推理。2.2 事件记账的定义与类型事件记账可以拆成五类基础能力按难度从低到高排列记账类型说明典型问题存在性判断某事件是否发生过视频里有没有人摔倒计数统计事件发生的总次数一共有几个人进场顺序判断多个事件的先后关系是报警先响还是门先开状态跟踪某个状态持续多久、何时切换红灯亮了多久时序定位事件发生在什么时间点第几分钟出现异常这些能力单独看都不难难的是“一次性全部做对”。模型既要理解每一帧的内容又要在整个时间轴上维护一个持续更新的状态表。这就好比让人一边看球赛一边做技术统计看漏一拍账就对不上。2.3 低频陷阱的核心定义低频陷阱可以理解为当一个目标事件在长视频中的出现频率很低时视频大模型对该事件的检测、计数和状态跟踪能力会出现显著下降且这种下降不会体现在常规高密度事件评测中。它包含两层含义操作层模型确实漏掉了稀疏事件导致业务上不可用。评测层现有评测数据分布偏向高频事件掩盖了模型在低频事件上的系统性缺陷让开发者对模型能力产生错误信心。很多团队把视频大模型接到生产环境后才发现效果远不如 demo低频陷阱是常见原因之一。它不是某一个模型的个别缺陷而是当前“采样 编码 语言推理”这套架构共同导致的系统性问题。3. 低频陷阱的三种典型失败模式为了把问题讲清楚我把它拆成三种在项目里最容易遇到的失败模式。3.1 漏记事件发生了模型说没发生漏记是低频陷阱最直接的表现。当事件在一小时里只出现一两次时模型往往回答“没有发生”。原因并不难理解帧采样可能根本没采到事件出现的关键帧或者事件只在画面里占据很小的区域编码后被当作背景噪声丢弃了。在安防场景里漏记是致命的。一次未佩戴安全帽、一次跌倒、一次夜间闯入只要漏掉一次整个系统的价值就归零。3.2 误报事件没发生模型编造了事件与漏记相反模型有时会“过度记账”。比如视频里根本没有红色车模型却斩钉截铁地说看到了三次。这是多模态大模型常见的幻觉问题在视频领域的延伸。文本模型会基于语言先验编造内容视频模型则会基于“这类场景通常会发生什么”的知识去补全缺失的视觉证据。低频场景尤其容易触发误报。因为事件稀疏模型获得的视觉证据不足它只能靠猜。猜的次数越多编造的概率越大。3.3 次序与状态错乱数量对了账目不对第三种失败更隐蔽模型总数可能答对了但追问“第几次发生在什么时候”“A 和 B 谁先发生”它就露馅了。这说明模型大概率是通过整体印象猜了一个数字而不是真正逐帧记账。这一类失败最值得警惕。因为它会让评测指标看起来不错——计数准确率挺高——但实际业务中一旦需要按照时间点核验、追溯或回放模型完全无法提供可靠依据。失败模式直观表现业务影响在评测中是否容易被发现漏记说“没发生”安全事件被忽略不一定取决于数据集分布误报编造事件次数无效告警、信任崩塌不容易被合并进总体准确率次序错乱答对总数、答错顺序无法追溯核验很可能被忽视4. 视频大模型为什么会掉进低频陷阱搞清楚失败模式之后我们需要回答一个更深的问题为什么这类模型会统一地、系统性地在低频事件上失败以下四个原因来自对现有架构的分析按影响程度从大到小排列。4.1 帧采样天然会漏掉稀疏事件几乎所有视频大模型在输入阶段都要做帧采样。常见策略是均匀采样例如每秒 1 帧或者固定抽 32 帧、64 帧。这种做法对“频繁发生的事件”比较友好但对“低频出现的短事件”非常不友好。举个直观例子一段 10 分钟的视频模型只采样 64 帧平均每 9.4 秒才有一帧。如果一个关键动作只持续 1 秒那么它被采样到的概率约等于十分之一。如果目标事件还恰好发生在两帧之间的间隔里模型根本不可能从输入中看到它。均匀采样不是唯一方案还有随机采样、关键帧提取、光流加权采样等。但在绝大多数公开模型中默认策略依然是均匀采样。这就注定了低频事件在输入端就已经丢失后续无论模型多强都无法挽回。4.2 视觉令牌压缩会抹掉小目标与细节即使事件所在帧被采样到了视觉编码器还会对画面做第二次“抽血”。一帧 1080p 图像经过 ViT 编码后通常产生数百个视觉令牌但在送入 LLM 前很多模型会做空间池化Spatial Pooling或令牌降采样把分辨率压得很低。低频事件往往是小目标事件画面远处的一辆车、角落里的一次挥手、屏幕上闪过的一条提示。这些细节在令牌压缩过程中很容易被当成噪声抹掉。模型保留的是画面主体、大色块、显著运动而事件记账偏偏要求模型关注那些“不显眼但关键”的部分。这带来一个反直觉结论要让模型记好账有时候不能只追求高分辨率帧还要保证视觉编码器有足够能力保留小目标的语义。4.3 长上下文注意力被高频信息稀释当视频很长时视觉令牌数量会非常大。LLM 的注意力机制需要对所有令牌分配注意力权重而高频出现的场景元素——固定的背景、重复的走动、持续的噪声——会占据大量注意力资源。低频事件对应的少数令牌被淹没在海量令牌中注意力权重被稀释到几乎为零。这和人在嘈杂环境里听声音类似环境噪声太响一声轻微的呼救很容易被盖过去。模型并没有“刻意忽略”低频事件只是它的注意力预算被高频信息占满了。这个现象也解释了为什么很多团队发现把视频剪短之后模型表现明显变好。视频越短令牌越少注意力越集中低频事件越容易被注意到。但真实业务里视频往往就是很长的我们没有剪短的自由。4.4 模型内部没有持久的“记账本”最后是架构层面最本质的问题当前视频大模型本质上是“无状态”的。它把整段视频一次性编码进上下文然后让 LLM 在一次前向传播里给出答案。模型没有维护一个累积更新的计数器、状态表或时间轴结构所有信息都依赖注意力机制在现场重建。人类做事件记账时是边看边记的看到一个事件在纸上画一笔状态变了更新表格。这个“外部记账本”是准确率的保障。而大模型只能依赖隐式的注意力权重相当于要求一个人不看笔记凭印象汇报整场比赛的统计。当事件数量少、但分布在很长的视频里时这种“凭印象”的做法必然出错。更有意思的是低频事件对记忆反而是更难的——因为中间隔了太多无关信息模型容易把少数几次事件的痕迹彻底覆盖掉。4.5 语言先验的干扰最后一个因素来自 LLM 自身的先验知识。即使视觉证据不足模型也会用语言先验来补全答案。比如它知道“停车场”场景里大概率会有车进出就会倾向于给出一个“合理”的数量而不是诚实地回答“我看不清楚”。这种先验在短答案、低置信度场景下特别危险。模型不是为了正确而回答而是为了流畅而回答。低频事件恰恰给了语言先验最大的发挥空间——因为视觉证据弱模型只能依赖猜。5. 如何构造一套可复现的事件记账评测理解了问题下一步就是把它变成可测量的指标。很多团队不做低频评测不是不想做而是不知道怎么做或者以为只能靠人工标注。实际上用合成视频就能构造一套低成本、可复现、能自动打分的评测方案。5.1 用合成数据生成带标准答案的视频合成数据的核心优势是我们拥有 100% 准确的地面真值Ground Truth。事件发生次数、发生时间、顺序全部由脚本控制不需要人工标注。下面是一个最小示例用 OpenCV 生成一段有人物进出的模拟场景并把事件记录保存为 JSON。# 文件路径scripts/generate_synthetic_video.py import cv2 import numpy as np import json import random # 配置参数 W, H 640, 480 FPS 30 DURATION_SEC 120 # 2 分钟视频 TOTAL_FRAMES FPS * DURATION_SEC TARGET_EVENTS 3 # 低频事件出现次数可按需调整 random.seed(42) events [] frame_idx 0 # 生成事件时间点保证事件之间间隔足够大 event_frames sorted(random.sample(range(FPS * 10, TOTAL_FRAMES - FPS * 5), TARGET_EVENTS)) def draw_scene(img, t, has_target): # 背景 img[:] (60, 60, 80) # 一个行人从左向右移动位置随时间变化 x int((t % 4) / 4 * W * 0.6) 50 cv2.circle(img, (x, 300), 15, (0, 200, 0), -1) # 目标事件画一个红色方块从右侧出现、短暂存在 if has_target: cv2.rectangle(img, (500, 200), (600, 260), (0, 0, 255), -1) for i in range(TOTAL_FRAMES): t i / FPS has_target (i in event_frames) frame np.zeros((H, W, 3), dtypenp.uint8) draw_scene(frame, t, has_target) # 记录事件标签 if has_target: events.append({ frame_index: i, time_sec: round(t, 2), event_type: target_appear }) if i % 10 0: cv2.imwrite(fframes/frame_{i:06d}.png, frame) with open(events_ground_truth.json, w, encodingutf-8) as f: json.dump({total_events: TARGET_EVENTS, events: events}, f, indent2) print(f生成完成共 {TOTAL_FRAMES} 帧目标事件 {TARGET_EVENTS} 次)这段代码生成了 120 秒、包含 3 次目标事件的合成视频帧。事件次数可以自由调整用来对比模型在高频例如 30 次和低频例如 1 到 3 次场景下的表现差异。5.2 用多种采样策略跑模型推理有了带标准答案的视频下一步就是模拟视频大模型的推理输入。不同的视频模型对输入格式要求不同但我们可以统一用“抽帧 图片序列”的方式构造一个评测脚本测试不同帧采样策略对低频事件的影响。# 文件路径scripts/evaluate_sampling.py import cv2 import os import json video_dir frames total_frames 3600 # 与生成脚本对齐120秒 * 30fps def uniform_sample(n_frames64): 均匀采样 n_frames 帧 indices [int(i * total_frames / n_frames) for i in range(n_frames)] return indices def dense_short_window(sample_rate5): 高频采样前 10 秒其余部分稀疏采样 indices list(range(0, 150, sample_rate)) # 前 5 秒全采 indices list(range(150, total_frames, 60)) # 后续每 2 秒 1 帧 return indices def motion_weighted_sample(n_frames64): 简化的运动加权采样帧差大于阈值时保留该帧 indices [] prev None for i in range(total_frames): path os.path.join(video_dir, fframe_{i:06d}.png) frame cv2.imread(path, cv2.IMREAD_GRAYSCALE) if prev is not None: diff cv2.absdiff(frame, prev).mean() if diff 15 and len(indices) n_frames: indices.append(i) prev frame return indices # 输出采样结果 strategies { uniform_64: uniform_sample(64), dense_prefix: dense_short_window(), motion_weighted: motion_weighted_sample() } for name, ids in strategies.items(): print(f{name}: 采样 {len(ids)} 帧 f命中目标事件的帧数 f{sum(1 for i in ids if i in target_frames)}) # 读取 ground truth with open(events_ground_truth.json, r) as f: gt json.load(f) target_frames set(e[frame_index] for e in gt[events])这里的关键不是推荐某一种采样方式而是让大家直观看到采样策略直接决定模型“能不能看见”低频事件。均匀采样 64 帧时如果事件帧没有被选中那模型再强也答不对。5.3 自动校验模型的记账答案最后一步是打分。为了减少人工阅卷成本我们可以让模型按固定 JSON 格式输出记账结果然后用脚本自动比对。# 文件路径scripts/verify_bookkeeping.py import json # 假设模型输出实际使用时替换为模型 API 的返回结果 model_output { target_appear_count: 2, occurrences: [ {time_sec: 18.5}, {time_sec: 41.2} ] } with open(events_ground_truth.json, r) as f: gt json.load(f) gt_events gt[events] gt_count gt[total_events] gt_times [e[time_sec] for e in gt_events] pred_count model_output[target_appear_count] pred_times [e[time_sec] for e in model_output[occurrences]] # 计数精确匹配 count_correct (pred_count gt_count) # 时间点匹配允许 2 秒误差 def match_times(pred, gt, tolerance2.0): matched 0 for p in pred: if any(abs(p - g) tolerance for g in gt): matched 1 return matched time_match_ratio match_times(pred_times, gt_times) / max(len(gt_times), 1) print(f真实次数: {gt_count}预测次数: {pred_count}计数是否正确: {count_correct}) print(f时间点匹配比例: {time_match_ratio:.2f}) # 输出统一分数计数对 时间点匹配各占 50 分 score (50 if count_correct else 0) (50 * time_match_ratio) print(f本样本事件记账得分: {score:.1f} / 100)这个脚本的价值在于把“感觉模型不行”变成“模型低频事件记账得分 31 分”有了可量化的分数你才能做版本对比、策略调优和回归测试。6. 缓解低频陷阱的实用策略评测只是第一步真正的问题是项目里该怎么缓解低频陷阱以下四种策略已经在工程实践中被反复验证按落地成本从低到高排列。6.1 让模型先“记账”再回答最简单、见效最快的方法是要求模型在正式回答前先输出一个显式的记过账过程。这相当于把模型从“凭印象汇报”逼成“先列流水账再汇总”。一个实用的 Prompt 模板如下请扮演视频事件记账员。你会收到一段按时间顺序排列的视频帧。 请逐步完成以下任务 1. 先逐帧检查找到所有符合目标事件“红色车出现”的帧。 2. 把每次出现记录为一条账目格式为{time_sec: 事件时间, note: 简短的视觉证据描述}。 3. 全部检查完后汇总输出 JSON {total: 总次数, occurrences: [账目列表]} 要求 - 只记录你能看到明确视觉证据的事件。 - 如果某次出现证据不足宁可不计也不要编造。 - 不要先给出结论再补理由必须先记账再汇总。这个 Prompt 的设计思路是用结构化输出约束模型的推理路径让它在回答前先做一遍“显式跟踪”。很多情况下这种约束能显著减少漏记和误报。它不是从架构上解决问题而是把问题变得更容易被模型处理。6.2 改用事件驱动的两阶段架构如果业务允许更可靠的做法是放弃“一个模型看全片直接答”改成“检测器 记账器”的两阶段架构。第一阶段用一个专门的目标检测或动作检测模型对全部帧做扫描输出候选事件及其时间戳。这一阶段的目标是“召回”宁可多报不可漏报。第二阶段把第一阶段筛出的候选事件帧而不是完整视频交给大模型让模型判断每个候选是否成立并按时间线完成汇总记账。这种架构的本质是先用专用模型解决“在哪一帧看什么”再用大模型解决“这些证据意味着什么”。因为第一阶段采用了密集或滑动窗口扫描低频事件漏检率会大幅下降第二阶段输入变短注意力也不再被稀释。两阶段架构在监控、体育和工业场景里已经有不少落地案例代价是需要额外维护一个检测模型工程复杂度比单模型方案高一些。6.3 引入外部“记账本”作为推理缓存在长视频场景下可以考虑把“记账”从模型推理中剥离交给一个外部结构。例如对视频做逐段处理每 30 秒提取字幕级描述或事件标签。将事件标签写入一个时序数据库或 KV 存储附带时间戳。需要回答事件记账问题时先从数据库查询再把查询结果交给 LLM 做语言组织。这样做的好处是模型不需要靠注意力记住所有事件外部存储代替了人类手里的“纸和笔”。它的上限取决于事件标签的质量如果第一步提取错了后面再准也没用。因此实际项目中通常会把策略 6.2 和 6.3 结合使用检测器负责写账本LLM 负责查账和解释。6.4 对关键业务保留规则兜底最后一条建议不是技术升级而是工程觉悟不要把低频事件的正确性全部押在模型身上。在安防、医疗、工业等高危场景只要事件计数错误会导致严重后果就必须设置规则兜底。例如当模型报告“本次视频未发现目标事件”时系统自动触发一次低速率的全量规则扫描用传统计算机视觉方法背景差分、运动检测、模板匹配对完整视频再做一遍复查。复查结果与模型结果不一致时交人工复核。这套“模型先判、规则复查、人工兜底”的流程虽然牺牲了一部分自动化率但能有效避免低频漏报带来的业务事故。对于低频事件可靠性远比自动化率重要。7. 常见问题与排查思路在实际接入视频大模型时低频陷阱带来的问题往往以各种形态出现。下面这张表汇总了最常见的五类现象以及对应的排查路径。问题现象可能原因排查方式解决方案模型对低频事件回答“没发生”帧采样未命中事件帧打印输入模型的实际帧序号比对事件时间戳改事件驱动采样或两阶段检测器补召回模型回答事件次数偏多视觉证据不足模型靠语言先验编造查看模型是否输出不确定措辞追问事件细节强制结构化记账要求“证据不足则不记账”短视频准确、长视频准确率骤降长上下文注意力稀释分段时间窗口测试对比长视频和短视频得分分段处理 外部记账本缓存计数对但时间点对不上模型没有真正逐帧记账只是整体猜测解析输出时间戳与 Ground Truth 计算匹配率使用 5.3 节的校验脚本做时间点级评测更换模型后效果波动大不同模型采样率、令牌压缩策略不同固定输入帧对比同名模型的差异在评测集中固定输入协议避免变量不可控排查低频问题时最忌讳的是只看最终准确率一定要把错误细化到“漏记、误报、时间错位”三个维度。这决定了你该去调采样策略、调 Prompt还是换架构。8. 最佳实践与工程建议8.1 评测集必须包含低频正样本从今天的讨论可以得出结论一个没有低频事件样本的评测集无法反映视频大模型的真实记账能力。建议在评测集中明确配置三类样本高频样本事件出现 20 次以上用于评估模型基础能力。低频样本事件出现 1 到 3 次用于暴露低频陷阱。零次样本事件完全不出现用于检测误报倾向。三类样本分别计分不要合并成一个总分。只有单独看低频样本的分数你才能判断一个模型是不是“只会处理密集事件”。8.2 事件记账评测要测到时间戳级很多团队只测“模型答对事件次数”这远远不够。一个真正可靠的记账系统必须能回答“第几次发生在什么时间”。因此建议把第 5.3 节的“时间点匹配比例”纳入核心指标。一个答对总数但时间点全错的模型在生产环境里仍然是不可用的。8.3 记录输入帧清单做可复现实验视频模型的采样策略各不相同同一段视频喂给不同模型实际输入帧可能完全不同。做评测时分不清是模型能力差异还是采样差异。最佳实践是每次推理都记录实际输入的视频帧序号连同输出一起存档。这样出了问题可以精确回放判断瓶颈到底在采样层还是推理层。8.4 结合置信度做分层处理模型在低频事件上的答案往往伴随着低置信度但很多系统设计时没有读取置信度。建议让模型在输出记账结果时同时输出一个“视觉证据充分度”评分。当评分低于阈值时自动走规则复查或人工复核流程而不是直接采信模型结论。8.5 版本升级后必须回归低频场景大模型迭代很快但新版本可能改善推理能力同时降低对稀疏视觉细节的关注。每次升级视频模型都应在固定低频评测集上做回归。比较常见的情况是新版模型在通用视频问答上分数涨了低频事件记账分数却跌了。如果不做专门回归这个问题会在上线后突然爆发。9. 总结与后续学习方向回到标题那句话Video Language Models Fail at Simple Event Bookkeeping。这篇文章想传达的核心判断是这不是一个“模型不够聪明”的问题而是当前视频大模型架构在处理稀疏时序事件时的系统性短板。低频陷阱提醒我们模型在密集事件上的良好表现很容易让我们误判它在真实稀疏场景中的可用性。如果你正在做视频理解相关项目下一步至少有四个可以深挖的方向第一把本文第 5 节的合成视频评测方案跑通先量化你的模型在低频事件上的真实得分。这是成本最低、收益最直接的一步。第二尝试事件驱动的两阶段架构用专用检测器解决召回用大模型解决判断和汇总看低频事件得分能提升多少。第三研究长视频的分段处理方案把“一段一小时视频”切成“若干 30 秒片段 外部事件缓存”从机制上缓解注意力稀释问题。第四持续关注视频大模型在时序建模上的新架构。当前模型普遍用均匀采样 令牌序列建模时序未来如果有事件级采样、记忆增强或显式状态跟踪机制的模型出现低频陷阱有望在架构层面得到缓解。最后提醒一句在关键业务上不要把低频事件的判断完全交给单次模型推理。模型先判、规则复查、人工兜底这个流程虽然不酷但它是目前最稳妥的工程方案。低频事件往往意味着高风险事件宁可多一次复查也不要一次漏报。