你有没有想过，一个一直盯着监控画面的AI，到底该什么时候开口说话？
这个问题听起来简单，实际上藏着一个很棘手的矛盾。假设你让AI盯着一场足球比赛，告诉你什么时候有人进球。它要是看一帧画面就报告一次，那你的手机会被刷屏刷到爆炸。它要是攒够了一整场比赛才汇报，那“实时”这两个字就没有任何意义了。
现在主流的解决办法,是训练一个专门的小模型去做“要不要说话”的判断,或者按固定的时间表去检查。这篇来自NAAMII、伦敦大学学院等机构研究者的论文Foresight,提出了一个相当反直觉的观点:不需要专门训练任何东西,一个现成的、冻结权重的视觉语言模型,其实已经具备预判未来的能力,只是没有人把这个能力用起来。
视觉语言模型*：一种能同时理解图像/视频和文字的AI模型，可以看懂画面内容，并用自然语言描述或回答关于画面的问题。
核心问题：现有系统都在"看过去"而不是"看未来"
先说说现在的系统是怎么工作的。
早期的流式视频理解系统,靠的是边看视频边决定什么时候该开口。后来的系统把这个判断过程做得更精细了,比如MMDuet2用强化学习训练响应时机的判断,StreamChat在每一步解码时都刷新视觉上下文,MiniCPM-o 4.5更是把视觉、音频、语音全打通,做到了全双工交互。LiveStar的做法挺有意思,它靠检测新画面是否还和自己之前的描述“对得上”来判断要不要重新思考。Dispider训练了一个轻量级分类器专门做“响应不响应”的二元判断。
但这些系统有一个共同的毛病,它们全都是被动响应式的。
什么意思？就是说它们都在根据“已经发生的事”做决定,而不是根据“即将发生的事”做准备。论文里举的例子特别形象：在一个不断变化的场景里，最好的下一步往往是等待正确的证据出现,而现有系统把这个“等待多久”的问题,交给了固定的时间表,或者一个单独训练出来的触发器。
这就好比你雇了个保安盯着监控,保安的工作方式是每隔30秒看一眼屏幕,或者看到画面变化超过某个阈值就按一下警报器。这个保安压根不懂足球规则,他不知道球员带球突入禁区意味着接下来几秒钟很可能有射门,所以他没办法提前把注意力集中到门前。如果不让保安具备这种“预判”能力,他就只能靠加快检查频率来弥补,这意味着大部分时间都在做无用功,盯着一场什么都没发生的比赛反复确认。
论文的核心洞察是：既然这个视觉语言模型已经理解了场景,它其实也有能力推断“什么时候信息会出现”“到时候该检查什么”。换句话说,预判不该只是一个被评分的预测任务,而应该变成控制计算资源的一种手段。
这个转变带来了三个必须解决的硬骨头。第一,预判必须足够靠谱,乱猜会把整个推理带偏。第二,做计划这件事必须和持续的感知同时进行,不能让“想”打断“看”。第三,在线调整系统配置的开销必须小到可以忽略,否则省下来的计算又被规划本身吃掉了。
Foresight的解法：一个模型，分裂成两个“自己”
Foresight给出的方案,说出来其实挺朴素：用同一个冻结权重的视觉语言模型,跑出两个副本,一个叫Ingest（摄入），一个叫Think（思考）。
Siamese架构*：指两个结构完全相同、权重完全共享的网络副本并行工作,就像一对双胞胎,长得一模一样,但各自做着不同的事。
Ingest LLM*：持续处理视频流,把每一帧编码后写入共享的KV缓存,它从不停歇,也是唯一能往缓存里写数据的角色。
KV缓存*：Transformer模型里用来存储已经处理过的上下文信息的一种缓存机制，这样模型不需要每次都从头重新计算整段历史。
Ingest永远在干一件事：把新进来的画面编码,塞进共享的因果状态里,从不停下。而Think则是另一回事,它只在被唤醒的时候,偷偷读一份当前缓存的“快照”,根据这份快照生成一份计划,然后再把计划写回去,指导接下来该怎么处理视频流。
这个设计最巧妙的地方在于,Think读的是快照,从不往缓存里写东西。这就保证了Think的“胡思乱想”不会污染视觉历史的真实记录。
这里的类比可能更容易懂。想象你在值夜班,一个人既要盯着仪表盘读数,又要时不时停下来琢磨接下来会发生什么。如果你把这两件事混在一起做,你一琢磨事情,仪表盘的数据就漏看了。Foresight的做法相当于克隆了一个你,一个专心盯着仪表盘记录数据从不走神,另一个定期拿着记录的副本去琢磨接下来该怎么办,琢磨完了把结论反馈给值班系统,但绝不会去碰原始记录本身。如果不这样分开,结果就是感知和规划互相抢资源,规划越想得深入,感知就越容易漏帧,这在实时监控场景里是不可接受的。
计划里到底写了什么
Think每次运行,输出的东西论文里叫“计划”，分成两部分：一个是“证据状态”，记录当下看到了什么、是否已经足够回答问题；另一个是“控制更新”，决定接下来怎么调整系统的行为。
控制更新里有几个关键字段。FPS字段用来调整视觉门控的采样频率，事情平静的时候采样稀疏点省计算，预判要出事了就提高采样密度。Keep Classes和Ignore Classes这两个字段，是告诉视觉编码器该关注画面里哪些物体类别，忽略哪些，这样可以把不相关的视觉token直接剔除掉。Compact Now是发给KV缓存的信号，告诉它该“瘦身”了，把陈旧或不重要的历史信息压缩掉。Next Check和Next Question则决定了Think下一次该在什么时候醒来，到时候该重点关注什么问题。
这套机制听起来有点像一个总机调度员的工作方式。你不需要调度员一直守在电话旁边，你只需要他告诉你“下次大概什么时候会有重要来电，到时候重点听什么内容”，然后下一次来电之前，前台该怎么接待、该不该先核实身份，全靠这份提前写好的交接单。如果没有这份交接单，调度员每次接班都要从头问一遍发生了什么，效率必然低下。
Live Executor*：论文里的“执行器”，负责把Think生成的计划真正落实到系统里，比如调整采样率、压缩缓存、更新视觉编码器该关注的物体类别。
值得一提的是，论证的严谨性还体现在证据状态和控制状态是分开管理的。证据状态是“临时”的，每一步都从当前观测重新计算，绝不持久保留；而控制更新则是“持久”的，一旦某个设定（比如采样频率）被写入，就一直有效，直到下一份计划显式修改它。这种设计是为了避免瞬时的证据波动干扰到长期的调度策略，论文管这个叫“保持瞬时证据和持久控制分离”。
计划怎么被“省着写”
这里有个工程上很聪明的细节。第一次做计划的时候，模型要把完整的计划内容都生成出来，但从第二次开始，模型只需要生成和上一份计划相比变化的部分，论文叫这个“diff-based”更新，也就是“差异化解码”。
这就好比你每天给同事发工作交接单，第一天你得写清楚所有流程细节，但从第二天开始，大部分流程没变，你只需要写“今天和昨天不一样的地方是……”，剩下的默认沿用昨天的版本。如果每次都重新写一份完整交接单,时间全耗在重复劳动上了,交接效率反而更慢。
布尔值的判断也做了优化。像“证据是否足够”这种是非判断，模型不是靠生成“是”或“否”这两个词来表达，而是直接读取这两个候选词在模型内部的概率分布，用比值来当作一个连续的置信度信号。这样做的好处是省去了解码一整段文字的开销，一步logits读取就能拿到结果。
实验结果：23分的差距意味着什么
说了这么多设计理念，数据才是检验的硬标准。
论文选用的骨干模型是Qwen3-VL-8B，整个过程中权重完全冻结，没有任何额外训练。实验在三个基准上展开：专门测试主动响应能力的OmniPro Online，综合测试流式视频理解的StreamingBench，以及测试证据出现时机差异的OVO-Bench。
在OmniPro Online这个最硬核的测试里，Foresight拿到了23.0的平均联合F1分数，而排名第二的训练过的基线方法MiniCPM-o 4.5只有13.5。这个差距是9.5个百分点，换算成相对提升接近70%。这意味着在九种不同任务类型里，一个完全没有经过专门训练、只是巧妙调用现成模型的系统，整体表现把专门为这个任务训练过的系统甩开了一大截。
在StreamingBench上，Foresight把骨干模型本身的表现提升了6.7分，达到66.0的总分，超过了此前最强的MiniCPM-o 4.5（62.7分）。
OVO-Bench上提升了15.4分，其中最引人注意的是在“Forward Active Responding”任务上提升了18.7分。这个任务测试的是答案要等视频后面才会出现的情况，也就是说，模型得先“憋着”，等到合适的证据出现再回答。这恰好是论文整篇论证想要证明的场景：当正确答案要晚点才揭晓时，提前规划什么时候该再检查一次，比起每次都临场反应，优势会特别明显。
| 方法 | OmniPro联合F1 | StreamingBench总分 | OVO-Bench总分 |
|---|---|---|---|
| MiniCPM-o 4.5 | 13.5 | 62.70 | 59.70 |
| StreamAgent | 5.0 | 57.02 | 49.40 |
| QueryStream | 6.7 | — | 47.51 |
| **Foresight** | **23.0** | **66.00** | **62.16** |
速度也没落下
有一个常见的疑虑是：这套“先想后做”的系统会不会反而更慢？
论文专门做了成本分析来回答这个问题。核心逻辑是这样的：如果没有共享KV缓存，每次Think要做计划，都得把整段历史重新读一遍、重新计算一遍，这个成本是随着视频长度的平方增长的，视频长一倍，计算量涨四倍。而Foresight因为所有视觉token只在Ingest阶段被编码一次，Think只是读一份现成的快照，所以总计算量基本只取决于“做了多少次检查”和“触发了多少次响应”，跟视频总长度几乎没关系。
论文还测了几个真实跑起来的竞品的实际速度。StreamAgent无论用哪种骨干模型，处理一秒钟的视频都要花两到三秒的计算时间，这意味着它压根跟不上实时视频流的速度。相比之下，QueryStream跑得很快，只需要原视频时长的5%到8%的计算时间，但它的准确率明显不如Foresight。Foresight在准确率上大幅领先的同时，速度也接近实时，这个“又快又准”的组合在论文的图里表现得很直观。
局限性：预判这件事，也不是万能的
论文的态度挺诚实的，专门用了一组实验去探究“模型到底能提前预判多久”。
他们做了一个很直接的测试：让模型在事件发生前T秒就停止观看，只用已经看到的内容去预判接下来会发生什么。结果发现，提前2秒时模型的预判已经相当准，几乎接近了“看到事件本身”的理想水平的四分之三；但到了30秒，预判准确率已经跌到几乎和“完全不看视频瞎猜”差不多的水平。
这说明模型对未来的洞察力，是短命的。一个球员带球突入禁区，确实预示着接下来几秒钟很可能有射门，但这个信号对半分钟后的比分毫无帮助。
这也解释了为什么Foresight的架构里，Think必须频繁地重新检查，而不能一次计划管很久。这就跟天气预报类似，气象台能比较准地告诉你明天会不会下雨，但没人敢打包票说一个月后的某一天天气如何。预判的有效期有多长，取决于能支撑预判的线索还能看多远，而不是模型想预判多远就能预判多远。如果强行让系统按照一个很长的时间间隔去检查，那些中途突然冒出来的事件，系统将完全来不及反应。
论文也坦率承认了另一个问题：如果模型一次误判触发了响应，接下来有时候会持续性地重复报告同一个已经不存在的事件，哪怕证据已经不支持了。给Think提供“历史上已经报告过什么”这份记录，能大幅缓解这个问题，但没能完全根除。
这些局限不是什么丢人的事，恰恰说明了研究者没有回避问题，而是把测出来的边界老老实实写进了论文里。
Q&A
Q1：Foresight是什么？
A：Foresight是一个训练免费的架构，它用两个共享权重的视觉语言模型副本，一个持续感知视频流，一个在后台提前规划未来该怎么处理，让流式AI从被动响应变成主动预判，而且不需要重新训练任何模型。
Q2：Foresight比现有的流式视频理解方法好在哪里？
A：在OmniPro Online主动响应测试中，Foresight的联合F1得分达到23.0，比最强的训练过的基线MiniCPM-o 4.5高出9.5分，同时在StreamingBench和OVO-Bench上也分别提升了6.7分和15.4分，尤其在答案延迟出现的场景提升高达18.7分。
Q3：Foresight的预判能力有多远的有效期？
A：论文的实验显示，模型提前2秒预判事件时准确率接近理想水平，但到30秒时几乎和瞎猜无异，说明预判只在短时间内可靠，这也是为什么系统需要频繁重新检查而不是制定长期计划。
