AMD新方法HPP：34K帧视频也能程序化调试

长视频最怕的不是“看不懂”，而是“看得懂一点点，却被海量冗余帧淹没”。HPP把感知和推理解耦，让编码型大模型像程序员一样分层探测视频，思路很硬核，成本也更像工程方案而不是玄学。

龙哥读论文发布于 2026-08-20 00:20:05 阅读 3 查看原文

#大视觉语言模型 #大语言模型 #Agent #多模态

🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
长视频最怕的不是“看不懂”，而是“看得懂一点点，却被海量冗余帧淹没”。HPP把感知和推理解耦，让编码型大模型像程序员一样分层探测视频，思路很硬核，成本也更像工程方案而不是玄学。

原论文信息如下：

论文标题:
HPP: Hierarchical Programmatic Probing for Long Video Understanding by Decoupling Perception and Reasoning

发表日期:
2026年06月发表单位:
AMD; Queen’s University Belfast; Queen Mary University of London 原文链接:
https://arxiv.org/pdf/2606.21734v1.pdf 项目链接:
https://awaisrauf.com/hpp

长视频理解新范式：LLM编程探针替代VLM逻辑推理

长视频理解最烦人的地方，不是“看不见”，而是“看见了也没法一次想明白”。一小时视频里动辄上万帧，真正有用的信息可能只藏在几个瞬间；但传统视觉语言模型偏偏喜欢把感知和推理塞进一次前向里，像让一个人边翻书边做奥数，最后大概率只会头大。

这篇论文的切入点很直接：把“看视频”和“想答案”拆开。具体来说，编码能力强的语言模型负责规划、检索、分步试探，视觉模型只在需要时被叫出来看局部证据。于是，视频不再是一次性吞下去的长句子，而更像一份可以被程序逐层“调试”的数据集。

图1：HPP总体框架图。编码型大模型先在 REPL 环境里写代码、调用探针函数，再按需唤起视觉语言模型完成局部感知，最后再综合证据给出答案。

这套思路最像什么？像把“看视频答题”从一锤子买卖，改成了“先定位、再取证、再复核”的工程流程。对长视频来说，这比硬塞进一个巨型上下文里靠谱得多。

秒懂34K帧视频：HPP如何让LLM像程序员一样“调试”视频

HPP，全称是 Hierarchical Programmatic Probing，中文可以理解为“分层程序化探测”。这里的“programmatic”不是装腔作势，而是真的让大模型像写脚本一样去查视频：先找范围，再缩小，再验证，必要时再换个问法重新搜。

论文里有个很关键的前提判断：长视频的难点其实分成两类。第一类是感知，也就是在海量冗余帧里找出真正发生了什么；第二类是推理，也就是把分散在不同时间段的证据串起来。传统 VLM 往往把这两件事绑在一起做，结果就是两头都不讨好。

图2：利用编码信息进行分层切分。左边展示了如何直接借助视频编码信息把原始帧变成 shot 级片段；右边展示了信息密度感知的分段示意，关键帧会被保留下来作为后续检索和定位的锚点。

先看第一层：分层结构化。论文没有傻乎乎地对所有帧一视同仁，而是直接利用视频编码里的 I 帧、运动向量和残差来判断哪里变化大、哪里变化小。这个思路很工程化：既然压缩算法本来就在记录“哪里值得花比特”，那拿来做视频结构切分，当然比纯算光流省得多。

公式1：shot 信息密度定义。这里的 γi 用来衡量第 i 个 shot 的“变化量”，由运动向量和残差共同决定。直白点说，动得越多、残差越大，就越值得优先看。λ 是平衡两项权重的系数。

有了 shot 之后，还不够。因为长视频里相似场景太多，单靠全局向量很容易“认错人”。所以第二层是细粒度语义检索：先按 motion energy 决定每个 shot 该采多少帧，再用 late interaction 去做 token–frame 级别的匹配。翻译成人话就是，不再粗暴地把整段视频压成一个球，而是让查询词和视频帧先逐个对上眼。

公式2：加权 MaxSim 相似度。MaxSim 可以理解为“每个文本 token 去视频帧里找最像自己的那一帧”，再把这些匹配结果汇总起来。wj,k 会对关键帧更偏重，αs 则控制局部细节和全局语义的占比。这个设计的好处很明显：既能抓动作细节，也不至于丢掉场景整体含义。

第三层是结构化采样接口。HPP 给大模型提供的不是“请自己看着办”，而是一组很明确的操作：按时间戳取帧、按时间区间取片段、在局部区域继续放大、按层级跳转、裁剪片段。对程序员来说，这就像有了一套专门为视频准备的调试 API；对大模型来说，意味着探索空间被约束住了，乱翻车的概率会小很多。

图4：HPP 的实际运行示例。模型会把一个复杂问题拆成多个子目标，在 REPL 中并行搜索、逐步缩小候选范围，再用视觉模型核验证据。即使面对 34k 帧，也只需要检查其中很小一部分。

这部分最妙的地方在于，HPP 并不要求大模型一次想出完美策略。它允许模型先粗搜，再细查，再修正，甚至在证据不够时换一种说法重新检索。这个循环一旦跑起来，视频理解就从“单次回答”变成了“迭代调试”。

效果与效率双赢：HPP在多项基准测试中超越大模型

论文最有说服力的地方，不是“理论上很美”，而是它真的在多个长视频基准上打出了结果。尤其是在 LongVideoBench 上，HPP 的优势集中体现在两类题：一类是局部感知题，另一类是需要跨时间段串联证据的关系推理题。后者才是长视频的真正难点，因为它考的不是“看见没”，而是“把前后几分钟的线索拼起来没”。

表1：在 LongVideoBench 上沿两条轴做感知与推理解耦实验。结果显示，在相同的 LLM 下，HPP 相比单体式 VLM 有稳定提升；而且当视觉编码器从小到大扩展时，HPP 依然能继续吃到增益，说明这个框架不是“小模型专属补丁”，而是能把更强感知模型继续榨出价值。

更有意思的是，论文还专门验证了“LLM 的编程能力能不能迁移到视频推理”。答案是能，而且很明显。相同的视觉模型下，编码能力更强的语言模型，视频理解成绩也更高。这说明 HPP 真不是把大模型当会说话的字幕机，而是把它当成会规划、会搜索、会修正的“控制器”。

表2：LLM 编码能力向视频推理迁移。固定视觉模型后，随着语言模型的编码能力增强，LongVideoBench 成绩单调上升，说明程序化推理本身就是 HPP 的核心增益来源之一。

再看跨基准表现，HPP 在 EgoSchema、VideoMME、MLVU 等数据集上都给出了不错的结果。这里要特别注意一点：论文并没有靠一个超大视觉编码器硬堆算力，而是用 较轻的感知模型 + 程序化推理 走出了另一条路。对工程落地来说，这一点非常重要，因为很多场景真正缺的不是“更大模型”，而是“更少无效计算”。

表3：多基准长视频理解结果。HPP 在多个数据集上都能和更大的模型打得有来有回，部分任务甚至直接超过依赖大视觉模型的方法。尤其是在 LongVideoBench 上，66.4 的平均准确率已经说明，“会规划”这件事本身就很值钱。

表4：MLVU 基准结果。HPP 在整体、单细节、多细节等子任务上都有明显改善，说明它不只是擅长“找一个答案”，而是对多层次视频信息的组织能力也更强。

图5：平均 token 使用量对比。短视频上，HPP 因为要做分层和检索，未必比直接帧采样更省；但视频一长，优势就开始明显放大。说白了就是：短视频未必赢，长视频更值钱。

公式3：API 成本估计。这里把输入 token、缓存 token 和输出 token 分开计算，核心意思是：HPP 把很多计算从“无脑全喂给大模型”变成了“按需调用”，因此在长视频上更容易省钱。

无需训练的“黑科技”：HPP的组件设计与自适应计算

HPP 的另一个优点是，它不是靠重新训练一个大一统模型来解决问题。相反，它更像是把现成组件重新编排：结构切分、语义检索、局部采样、按需调用 VLM，再加上 LLM 的代码规划能力。这个路线的现实意义很强，因为它更容易接到现有系统里，不必为一个新任务重做整套训练管线。

图6：从 shot 到 scene 再到 cluster 的层级构建。论文用轻量图像编码器把局部片段继续聚成更高层语义单元，方便大模型在更粗粒度上快速定位，再在必要时向下钻取。

从系统角度看，HPP 的计算是自适应的。视频越长、问题越复杂，越适合用“先粗后细”的方式；视频越短，系统也不会强行装深沉。论文后面的 token 统计和 API 成本分析也说明了这一点：它不是在所有场景都无脑最省，而是在长视频这种高冗余场景里，优势才会真正释放出来。

图11：不同问题类型下探针函数使用情况。可以看到，框架主要依赖语义搜索和 VLM 查询，而其他函数会根据问题需要被动态调用。这个结果很重要，因为它说明 HPP 不是固定流程，而是一个会根据题目复杂度自动变通的系统。

论文里还有一个很有意思的现象：模型会自己“长出”一些程序化策略，比如多查询并行搜索、去重、再验证，甚至类似事件计数里的时间非极大抑制思路。这说明只要接口设计得对，语言模型并不只是会聊天，它真的能在代码环境里形成相当实用的搜索习惯。

图12：程序化探针中的涌现模式。模型会把全局问题拆成多个局部定位任务，并通过多轮检索和合并候选来完成事件统计或时间排序。这种“自己会写搜索策略”的能力，正是 HPP 最像工程系统的地方。

潜力与挑战：HPP的局限性与未来展望

HPP 的方向是对的，但它也不是“无敌外挂”。首先，系统依赖较强的编码型大模型和多轮交互，推理链会比单次前向更长，实际部署时要考虑延迟和 API 稳定性。其次，语义检索和结构切分虽能大幅缩小搜索空间，但如果视频内容本身非常抽象、或者查询和画面对应关系很弱，程序化探针也会碰到“搜得很努力，证据还是不够”的情况。

另外，HPP 的收益和视频冗余度高度相关。也就是说，越长、越重复、越需要跨段证据的视频，它越占便宜；而对于短视频或本来就很简单的问题，增益未必特别夸张。这个边界说清楚很重要，不然很容易把它吹成“所有视频任务都能一招通吃”。

未来如果继续往前走，比较值得期待的方向有两个：一是把探针函数做得更标准化，让不同视频任务都能共享一套接口；二是进一步压缩交互成本，让系统在边缘设备或低成本云端上也能跑得更顺。换句话说，HPP 现在已经证明了“程序化探测”这条路能走通，下一步比拼的就是谁能把它做得更稳、更快、更便宜。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决什么问题？它解决的是长视频里“信息太多、证据太散、单次推理不够用”的问题。HPP 的核心做法是把视频理解拆成分层探测和程序化推理，让大模型先定位再分析，而不是一口气把所有帧塞进上下文里硬猜。

文中的 REPL、late interaction、MaxSim 分别是什么意思？REPL 是“Read-Eval-Print Loop”，中文可理解为交互式代码执行环境；late interaction 是“后交互”，意思是文本 token 和视频帧 embedding 不先粗暴合并，而是保留细粒度匹配；MaxSim 则是对每个 token 找最相似帧，再把这些匹配汇总，适合做细粒度检索。

HPP 为什么对长视频更有效，对短视频未必那么夸张？因为长视频的主要矛盾是冗余和跨段推理，HPP 正好用分层切分、语义检索和按需调用来减少无效计算；短视频本来信息就少，直接看完也不费劲，所以 HPP 的优势不会像长视频那样被放大。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

把长视频理解拆成“感知 + 程序化推理”这件事不算凭空造新词，但 HPP 把它做成了可执行的交互系统，思路扎实，不是只会写概念图。

实验合理度：★★★★☆

对 LongVideoBench、EgoSchema、VideoMME、MLVU 都做了验证，还分析了不同长度、不同任务类型和资源开销，整体比较完整。

学术研究价值：★★★★☆

它给长视频理解提供了一条很清晰的替代路线：别再死磕单次前向里完成所有推理，程序化探测也许更适合复杂时序任务。

稳定性：★★★☆☆

框架思路合理，但多轮交互依赖 LLM 规划质量，遇到证据稀疏或查询歧义大时，稳定性还得继续打磨。

适应性以及泛化能力：★★★★☆

从多个长视频基准都能工作，说明泛化不差；但它更适合长、冗余、需要检索式推理的视频任务。

硬件需求及成本：★★★★☆

相比直接堆超大视觉模型，HPP 更像“算力花在刀刃上”；但多轮 REPL 和 API 调用仍有成本，不能算零开销。

复现难度：★★★☆☆

思路清楚，但要把编码模型、视觉模型、检索、分层切分和交互环境全跑顺，工程集成门槛不低。

产品化成熟度：★★★☆☆

在长视频检索、内容审核、纪录片分析等场景有潜力，但要进入稳定产品，还需要更低延迟、更强鲁棒性和更标准化的工具接口。

可能的问题：方法很聪明，但交互链路偏长，依赖模型会写代码、会搜证据、会复核结果；一旦其中某一步掉链子，整体效果就会打折。

主要参考文献

HPP: Hierarchical Programmatic Probing for Long Video Understanding by Decoupling Perception and Reasoning, arXiv 2026.

项目主页：https://awaisrauf.com/hpp

原文链接：https://arxiv.org/pdf/2606.21734v1.pdf

长视频太长，别硬塞进模型脑袋里。HPP这类“先找线索、再看细节”的思路，才是更像人也更像工程的做法。想继续追前沿论文、代码和落地套路，欢迎加入龙哥读论文星球，一起把复杂问题拆开看。

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
wechat_helper