感知程序:解耦视觉感知与认知,提升多模态大模型推理效率与精度
1. 项目概述视觉工具推理的瓶颈与感知程序的破局在过去的几年里多模态大模型MLLMs的发展可谓一日千里。从最初只能简单描述图片内容到如今能够进行复杂的视觉问答、图像编辑甚至视频理解模型的“视觉智商”在飞速提升。然而作为一名长期关注模型落地应用的研究者我发现在处理需要精确视觉感知的任务时比如判断两张图片中哪个点是对应的、分析摄像头运动方向或者估算物体的相对深度这些“聪明”的大模型往往会突然变得“笨拙”起来。问题的核心在于“信息过载”与“信息缺失”的矛盾。当我们直接把高分辨率的原始像素图喂给模型时看似提供了最丰富的信息实则让模型陷入了“大海捞针”的困境。模型需要从数百万个像素点中自行识别出哪些是无关的背景噪声哪些是关键的运动向量、边缘特征或深度线索。这个过程不仅计算开销巨大而且极易出错模型可能会被纹理、光照变化等无关因素干扰做出错误的判断。这正是“感知程序”这一新范式试图解决的痛点。它不再简单粗暴地展示像素而是展示经过预处理的、结构化的“线索”。简单来说就是把原始图像交给一个专业的“视觉前处理模块”让它先提取出任务相关的、精简的感知特征例如将整个图像的运动场抽象为“10x10网格中每个小块的运动方向左或右”再将这个高度结构化的“程序输出”交给大语言模型进行推理。这种方法的核心思想是“让专业的工具做专业的事”将感知与认知解耦。从我们实际的评测数据来看这种方法的优势是压倒性的。在HardBLINK这个极具挑战性的视觉推理基准测试中直接使用原始图像的GPT-5 Mini模型在5点定位任务上的准确率仅为41.49%。而当我们为其配备了对应的感知程序后准确率飙升至74.19%提升超过32个百分点。更令人惊喜的是效率的提升使用感知程序后平均每个样本消耗的token数量大幅下降这意味着更快的推理速度和更低的API调用成本。这篇文章我就来详细拆解一下“感知程序”这套方法论它为何有效具体如何实现以及在实际部署中会遇到哪些“坑”。2. 感知程序的核心设计思路与原理拆解2.1 从“所见即所得”到“所想即所需”的范式转变传统的多模态模型处理流程可以比喻为一个刚入职的实习生。你给他一堆原始数据报表像素希望他写一份市场分析报告答案。他需要自己从头学习如何看报表、识别关键数据、计算趋势最后才能组织语言。这个过程漫长且容易因经验不足而出错。感知程序则像为你配备了一位专业的财务分析师视觉工具。这位分析师会先快速浏览报表直接提炼出你关心的核心指标增长率、市场份额、现金流变化结构化的感知特征并以一份清晰的摘要表格感知程序输出呈现。你大语言模型要做的只是基于这份摘要进行战略层面的分析和决策。这个转变的核心在于将模型中原本需要“隐式”学习的低级感知能力外包给了“显式”的、可解释的、专精的工具。这种设计有三大优势降低认知负荷大模型无需再费力理解像素级的低级特征可以直接在高级语义和空间关系层面进行推理。例如在判断相机运动方向的任务中模型接收的不再是两张RGB图像而是一个由100个“左/右”标签组成的网格。它的任务从“分析两张图的光流”简化为“统计100个标签中的多数派”。提升泛化与鲁棒性视觉工具如光流估计器、特征匹配器通常是基于大量数据训练的专业模型对于光照变化、轻微形变等干扰具有更强的鲁棒性。由它们提供的感知线索比模型从原始像素中“猜”出来的要稳定得多。实现可解释与可控制感知程序的输出是结构化的文本或JSON每一步的中间结果都是清晰可见的。如果推理出错我们可以很容易地定位问题是出在感知工具提取的线索不准还是大模型自身的逻辑推理有误便于调试和迭代。2.2 感知程序的结构化输出信息压缩的智慧感知程序的关键在于其输出的设计。它不是一个黑箱而是一种精心设计的、机器可读的“语言”用于描述视觉场景的特定方面。以我们论文中涉及的几个任务为例多视角运动推理输出不是一个稠密的光流图而是一个文本描述如[p1: left, p2: left, ..., p100: right]。这实际上是对全局运动模式的极大压缩将数百万维的像素信息压缩为100维的类别标签。视觉对应匹配输出可能是一组候选点的坐标及其与参考点的匹配分数例如{point_A: (x1, y1, score:0.95), point_B: (x2, y2, score:0.87)}。模型的任务简化为“找到分数最高的点”。相对深度判断输出可能是物体间深度关系的序数描述如object_A is closer than object_B而不是具体的深度图。这种结构化的设计本质上是在大模型擅长符号推理和视觉世界连续的模拟信号之间架起了一座高效的“桥梁”。它过滤了噪声突出了信号使得大模型的推理能力能够被更精准地应用于视觉问题。2.3 与现有工具调用范式的对比在感知程序出现之前社区主要有两种让大模型使用工具的方式程序合成如VisProg、ViperGPT。让大模型生成一段可执行的Python代码代码中调用各种视觉API。这种方式灵活性强但依赖模型生成复杂、正确的代码调试困难且执行环境复杂。思维链工具调用如Visual Sketchpad、ReVPT。将工具调用作为模型推理链中的一步模型在“思考”过程中决定何时、调用何种工具。这种方式更自然但需要针对工具使用进行专门的训练或微调。感知程序可以看作是第二种范式的极致简化和前置化。它不要求模型在推理过程中“决定”调用工具而是在输入阶段就由系统设计者预先、强制性地调用最合适的工具并将结果格式化后交给模型。这样做牺牲了一定的灵活性但换来了极致的可靠性、低开销和易用性特别适合那些感知需求明确、固定的任务。3. 感知程序的具体实现与部署细节3.1 为不同任务定制感知程序感知程序并非一成不变它的具体形态完全取决于下游任务。下面我以两个典型任务为例拆解其构建过程任务一相机全局运动方向判断原始输入视频的起始帧和结束帧两张RGB图像。传统方法将两张图像拼接直接输入MLLM并提问“相机在向左还是向右移动”感知程序方法调用专业工具使用一个预训练的光流估计模型如RAFT、FlowNet2处理两张输入图像得到稠密的光流场每个像素都有一个表示运动方向和大小的二维向量。结构化抽象将图像划分为10x10的网格共100个块。对每个网格块计算其内部所有光流向量的平均水平方向u分量。如果平均值大于0标记为“right”小于0标记为“left”。生成程序输出最终生成一个简单的文本序列p1: left, p2: left, p3: right, ..., p100: left。交付MLLM将上述文本连同问题“基于以下网格运动标签判断相机整体移动方向左A还是右B”一起输入给大模型。大模型只需执行一个简单的计数和多数表决逻辑。任务二视觉对应点匹配原始输入一张参考图像带有一个标记点REF和一张目标图像带有多个候选点A, B, C, D, E。传统方法将两张图及所有点坐标输入MLLM让其找出对应点。感知程序方法调用专业工具使用局部特征匹配模型如LoFTR、SuperGlue处理两张图像得到一系列两图之间的高置信度特征匹配对。结构化抽象以REF点坐标为中心在参考图像中搜索其邻近区域的匹配特征。将这些匹配特征在目标图像中对应的位置坐标提取出来。生成程序输出输出一个结构化的列表描述每个找到的匹配点及其在目标图像中的位置例如Near REF, found correspondence at (0.45, 0.50) in target image.或者直接计算每个候选点与匹配点集的平均距离。交付MLLM将结构化描述和候选点坐标交给MLLM让其选择距离最近或最合理的候选点。注意感知程序的设计需要深度理解任务本质。抽象程度太高会丢失关键信息例如只输出“向左”的结论模型无法验证抽象程度太低则压缩效果不佳例如输出完整的光流图仍然token开销大。最佳实践是提供“刚好足够”的信息让模型执行它最擅长的逻辑推理。3.2 针对开源与闭源模型的差异化提示工程我们的实验发现前沿的闭源大模型如GPT-5 Mini, Gemini 2.5 Pro和开源模型如Qwen3VL, InternVL3.5在使用感知程序时需要不同的“引导”策略。对于闭源模型它们通常具备极强的指令遵循和上下文学习能力。我们只需在系统提示中清晰地说明感知程序输出的格式和含义然后将“问题感知程序输出”直接输入即可。例如“你将收到一个描述图像块运动方向的列表。‘left’表示该块向左运动‘right’表示向右。请根据列表中‘left’和‘right’的数量判断整体运动方向。”对于开源模型它们可能需要更具体的示例才能理解如何利用这些结构化信息。这里就需要用到上下文学习。我们的做法是使用一个更强的模型如GPT-5 Thinking针对某个示例问题生成一段“标准推理过程”。这段推理会详细展示如何解读感知程序并一步步得到答案。将这段生成的推理过程作为一个“单样本示例”与当前的问题和感知程序输出一起构成给开源模型的提示。对于某些理解能力稍弱的模型如InternVL3.5我们还需要在提示中加入额外的“澄清说明”。例如在相对深度任务中明确告知“深度比较基于深度范围而非二维坐标”在视觉对应任务中强调“使用相似度分数进行比较而非直接计算坐标间的欧氏距离”。这种差异化的处理至关重要。闭源模型像经验丰富的专家点到即止开源模型则像需要详细操作手册的实习生提供范例和注意事项能极大提升其表现。在我们的测试中为InternVL3.5-4B添加合适的ICL示例后其在HardBLINK上的性能从40.59%提升至69.89%。3.3 效率优势的量化分析Token消耗大幅降低除了精度提升感知程序带来的效率优势是另一个杀手锏。我们对比了Visual Sketchpad一种先进的思维链工具调用方法和使用感知程序的GPT-5 Mini。Visual Sketchpad模型需要在推理过程中自己决定何时调用工具、如何描述调用结果。这个过程会产生大量的中间推理文本Chain-of-Thought导致单个样本消耗的token数非常高经常接近模型上下文长度的上限如8192。感知程序工具调用和特征提取在输入前已完成并以最精简的结构化格式呈现。大模型接收到的已经是“精加工”的信息它只需要进行最后的逻辑跳转。根据我们的统计在多项任务的综合评估中P2方法平均每个样本消耗的token数远低于Visual Sketchpad。这意味着在相同的预算下你可以处理更多的问题或者对于长上下文模型你可以将宝贵的上下文窗口留给更复杂的推理而不是被冗长的工具调用描述所占据。4. 在HardBLINK等基准测试上的实战表现与分析4.1 HardBLINK任务深度解读HardBLINK是一个旨在评估模型在“多候选点”视觉推理任务上能力的基准。它包含3点、4点、5点三种子任务难度递增。任务形式是给定一个参考点模型需要从3/4/5个候选点中找出在另一视角下与参考点对应的那一个。这非常考验模型对视觉对应关系的理解以及对干扰项的排除能力。这个任务的难点在于随着候选点增多单纯依靠图像级别的语义理解或粗糙的位置先验如“目标点大概在图像中央”会迅速失效。模型必须能够进行精细的、基于几何或外观的匹配。4.2 感知程序带来的性能飞跃我们的实验结果如表4所示清晰地展示了感知程序的威力对顶尖闭源模型的提升GPT-5 Mini在3点、4点、5点任务上原始准确率分别为62.10%, 53.23%, 41.49%平均52.42%。使用感知程序后准确率飙升至82.26%, 87.90%, 74.19%平均81.45%。在最具挑战性的5点任务上性能提升了近33个百分点。Gemini 2.5 Pro平均准确率从55.65%提升至77.68%。对开源模型的“拯救”与增强InternVL3.5-4B这个4B参数的开源模型原始性能仅为40.59%在5点任务上甚至低于30%。这意味着它几乎无法处理此类任务。但在接入感知程序后其平均性能跃升至69.89%5点任务达到66.13%实现了从“不可用”到“可用甚至不错”的质变。Qwen3VL-4B同样获得了从47.04%到61.02%的显著提升。性能下降的例外与分析值得注意的是InternVL3.5-2B这个最小的模型在使用感知程序后性能反而略有下降29.57% - 32.25%。这揭示了一个重要问题感知程序的有效性依赖于大模型具备基本的逻辑推理和理解结构化指令的能力。如果模型规模太小连如何解析和利用你提供的结构化线索都学不好那么再好的输入也是徒劳。这提示我们感知程序与模型能力之间存在一个“匹配度”阈值。4.3 超越其他先进方法的对比我们将P2与当时其他几种先进的工具使用方法进行了对比Aurora, ReVPT这些是专门为工具使用训练或设计的模型在HardBLINK上平均成绩在60%-62%左右。Visual Sketchpad (GPT-5 Mini)作为结合了思维链和工具调用的强基线取得了63.71%的平均成绩。感知程序 (GPT-5 Mini)以81.45%的平均成绩大幅领先。这强有力地证明了在感知任务上将感知与认知明确分离并通过精心设计的结构化接口进行连接比让模型在推理过程中自行学习调用工具更加高效和强大。5. 实操心得、避坑指南与未来展望5.1 从零搭建感知程序管道的实战步骤如果你想在自己的项目中尝试感知程序可以遵循以下步骤任务分析与工具选型明确你的核心视觉任务是什么分类、检测、匹配、运动分析等。调研并选择一个在该任务上表现SOTA的专用视觉模型作为你的“感知工具”。例如目标检测用YOLO系列光流估计用RAFT特征匹配用LoFTR。关键点工具的精度和速度需要权衡。离线分析可用更重更准的模型实时系统则需选择轻量级版本。设计结构化输出格式这是最具创造性的环节。你需要思考为了完成最终推理大模型最少需要知道哪些信息输出格式应尽量简单、一致、易于解析。推荐使用JSON或键值对列表。例如{motion_summary: {left_patches: 93, right_patches: 7}}或matches: [{src_point: [x1,y1], tgt_point: [x2,y2], confidence: 0.98}, ...]。避坑指南避免输出原始浮点数数组或复杂嵌套结构。尽量将其转化为类别标签、比较关系大于/小于、序数第一/第二或经过归一化的简单数值。构建预处理流水线编写脚本将原始输入图像/视频送入你选定的视觉工具。接收工具的输出通常是张量或复杂数据结构并按照你设计的格式进行解析和转换。将最终的结构化文本与原始问题拼接形成给大模型的完整提示。提示工程与迭代对于闭源API设计清晰的系统提示说明结构化数据的含义。对于开源模型准备高质量的ICL示例。一个技巧可以用GPT-4/5等更强模型为你的训练集生成“推理过程”作为开源模型的演示样本。在小规模验证集上测试根据模型反馈调整输出格式或提示词。例如如果模型总是忽略某个关键字段可能需要修改字段名称使其更醒目或在提示中特别强调。5.2 常见问题与排查技巧实录在实际部署中你可能会遇到以下问题问题现象可能原因排查与解决思路模型性能提升不明显甚至下降1. 感知程序输出信息不足或存在歧义。2. 模型太小无法理解结构化输出。3. 提示词未能有效引导模型使用感知信息。1.检查输出人工审视几个样本的感知程序输出看是否包含了回答问题所需的所有关键线索。如果没有增强感知工具或修改抽象逻辑。2.升级模型尝试换用更大参数规模或推理能力更强的基座模型。3.优化提示在提示中更明确地指出“请根据下方提供的XX数据进行分析”并加入ICL示例。处理速度慢成为系统瓶颈感知工具本身推理耗时过长。1.工具轻量化换用更快的模型变体如MobileNet版本的检测器。2.异步处理将感知程序作为独立的预处理服务与LLM推理并行化。3.缓存优化对于相似或重复的输入缓存感知程序的结果。结构化输出token数依然很多抽象程度不够输出了过多细节。进行二次抽象。例如不是输出100个patch的运动方向而是直接输出“left: 93, right: 7”。核心原则是只提供推理结论所需的统计摘要或决策依据而非全部原始中间数据。在复杂场景下感知工具失效感知工具在极端情况如运动模糊、低光照、剧烈形变下性能下降。1.引入冗余结合多个感知工具的输出让大模型进行综合判断。2.设计降级策略当感知工具置信度低于阈值时回退到让大模型直接分析原始图像尽管性能会下降保证系统可用性。5.3 个人经验与未来展望从我个人的实践来看感知程序的成功应用一半靠“术”一半靠“道”。“术”是选择合适的工具和设计精妙的接口“道”则是深刻理解任务本质明确划分感知与认知的边界。一个让我印象深刻的教训是初期我们曾尝试为视觉对应任务输出所有匹配点的坐标和描述符。本以为信息越全越好结果发现token开销剧增且模型容易被大量冗余匹配点干扰。后来我们改为只输出与参考点最相关的几个高置信度匹配并附带其相对位置描述效果和效率才得到质的提升。这让我明白“少即是多”在AI系统设计中同样适用提供精准的“线索”远比提供原始的“数据”更重要。展望未来我认为感知程序范式有几个值得探索的方向自动化感知程序生成能否让大模型根据任务描述自动检索、组合并生成合适的感知程序这将极大提升该范式的通用性和易用性。多模态感知程序融合对于需要结合视觉、听觉、传感器数据的复杂任务设计统一的、跨模态的结构化输出接口让大模型成为真正的“多感官信息整合中枢”。与模型微调结合在特定领域可以基于感知程序的输出对开源大模型进行轻量微调让其更擅长解读此类结构化信息从而在性能和成本间取得更好平衡。感知程序不是万能的但它为破解复杂视觉推理问题提供了一把锋利而高效的“手术刀”。它让我们意识到与其一味追求构建一个能处理一切信息的“全能巨人”不如精心设计一个“专业团队”让每个成员各司其职通过清晰的协议高效协作。在AI系统日益复杂的今天这种“分解与协作”的思想或许比单纯的规模扩张更具深远意义。