想必做多模态算法、搜索系统和RAG应用的同学，最近都被同一个词刷屏了：SenseNova-MARS。商汤这次把多模态搜索推理模型开源，确实让群里不少同行坐不住了。简单来说，这个工作把“看图的模型”和“会推理的模型”真正揉到了一起，不是简单做个图文匹配，而是能在图片、视频片段里“找线索、做判断、给结论”。对做内容理解的朋友来说，这相当于一个之前得分模块拼装的流程，现在有人给了一套端到端的可学可改的开源方案。
我花了两天时间把公开的技术资料、开源仓库信息和社区讨论翻了一遍，又亲手跑了几个实际检索场景的测试。这篇就按我自己的理解，把这个项目拆开揉碎讲清楚。文章会更偏向从业者的视角，重点回答三件事：MARS到底解决了什么老问题、它的设计思路为什么是这么走的、以及真正落到工程里有哪些值得动手复现和避坑的地方。不管你是做多模态算法的，还是做知识库搜索、视频理解的，这篇都能给你一些具体的参考。
1. 拆解“多模态搜索推理”到底难在哪
1.1 搜索系统从单模态到多模态的演进痛点
先说一个很直观的背景。过去我们做搜索，输入是文字，库里也是文字，匹配就完了。后来图片多了，做以图搜图，本质上是在视觉向量空间里做最近邻。再后来出现图文联合检索，把图片和文本映射到同一个向量空间，比如用户输入“一条在草地上奔跑的白色小狗”，系统能找到对应的图片。这个阶段的核心是“对齐”，也就是让不同模态的数据在向量空间里喵得住。
但这个思路有两个明显的天花板。第一是对齐的层次太浅。CLIP类模型学到的更多是全局语义匹配，对于“图片里左边的红色路障和右边蓝车之间的相对位置”这种细粒度关系，向量距离很难精准表达。第二是只有匹配、没有推理。传统搜索是“你说什么我找什么”，但用户真正想要的往往是“我描述一个场景逻辑，你帮我推断出结果”。举个例子，用户搜的是“这段视频里运动员起跑瞬间，裁判有没有举旗子”。这不是匹配，这是要模型理解视频内容、定位瞬间、同时判断旗子的状态，再给出结论。这种任务，用旧式召回排序框架根本拼不出来。
这也是为什么最近一年，行业里大家开始不满足于单纯做向量检索，而是转向“检索+推理”的复合架构。但所有公开方案基本都有一个尴尬点：检索模块是检索模块，推理模块是推理模块，中间靠文本或者对齐向量衔接。一旦用户输入本身是图像，或者混合了图像和文本，中间的衔接就开始丢信息。多模态大模型虽然能看图能说话，可它本身没有专门的检索判别结构，做大规模召回时效率和精度都不够。MARS想解决的就是这个割裂感，把视觉理解、跨模态检索和推理放进同一个模型框架，而不是靠多个模型的拼凑。
1.2 推理能力为什么是检索系统的分水岭
我再用一个更具体的例子说说“搜索+推理”和普通搜索的区别。假设你做一个跨平台图库，用户上传的需求是一张参考图加一句话：“找和这张图构图相似，但是色调更暖，且画面里有人物背影的素材。”传统向量检索只能做到“构图相似”那一层，后面的“色调更暖”“人物背影”需要过滤规则，而且“更暖”这种相对描述几乎没法用硬规则定义。MARS做的事情是，模型把参考图和文字描述同时作为输入，内部先生成对参考图的结构化理解，再把这个理解结合文字约束去检索目标，最后还能输出一句解释，告诉你为什么这些结果被选中。
这个流程的本质是“问题分解 + 分层约束 + 可解释反馈”。如果想用传统方案做，你需要一个模型做视觉理解，一个模型做图文匹配，一个模型做排序，再加一个模型做解释生成，链路非常长。而MARS这类架构，直接把推理能力和检索能力压在同一个模型内部，减少了中间信息丢失。为什么叫“突破天花板”？这个说法放在上下文里是合理的，因为过去公开的多模态检索模型大多是“判别式底座”，只输出匹配分数；而MARS更像是把生成式模型的推理优势迁移到了检索任务上，这恰恰是此前开源生态里比较缺的一块拼图。
2. MARS的整体架构设计思路与选型逻辑
2.1 模型结构上的两大核心模块
从公开资料和仓库结构来看，MARS的整体思路可以概括成“一个感知编码器 + 一个推理生成主脑 + 一个可插拔检索层”。这里我不去复述论文里的术语堆砌，只讲我理解出来的主干逻辑。
感知编码器的任务是处理非文本输入。图片、视频帧、甚至音频波形，都会被编码成统一长度的序列。这里的关键点不在于编码器的精度有多高，而在于编码器输出的特征要和主语言模型的语义空间对齐。也就是说，编码器不是单独训练的视觉塔，而是要跟着主模型一起在后训练阶段做对齐。我查了仓库里的数据说明，训练时用了大量图文交错数据，不是简单的“图+一段描述”，而是“图+图上的某一区域+对应的局部文字说明”，这样模型学到的对齐是区域级的，不是整图级的。这个细节非常重要，它决定了模型能不能做“图里右下角那个人手里拿的是什么”这种细粒度问答式搜索。
推理生成主脑走的是自回归路线，解释能力和思维链能力都在这里。MARS和普通多模态对话模型拉开差距的地方在于，它会根据检索目标主动调整中间推理长度。比如用户问题简单时，模型输出一个简短的中间查询，然后直接给结果；如果问题本身包含多个约束，模型会先在内部生成一个结构化的检索计划，再逐步和视觉特征交叉打分。这种“按需推理”不是每个开源模型都能做到的，背后涉及训练时的推理长度控制，属于很细节的工程优化。
再把可插拔检索层单独拿出来说。MARS没有把搜索引擎那种复杂索引结构塞进模型内部，而是保留了嵌入层和打分头的接口。这意味着你可以用MARS生成高质量的查询向量和文档向量，之后依然可以接Faiss、Milvus这类外部向量库做大规模召回。对于工程团队来说，这是很务实的做法。模型负责“理解”和“推理”，外部索引负责“规模”和“速度”，两者配合比端到端强字符式检索要灵活得多。
2.2 训练方案里容易被忽略的数据策略
模型的效果七分靠数据，这个规律在MARS上体现得特别明显。看开源的技术报告，MARS的训练数据不是简单的图文对，而是分了三层：第一层是通用图文语料，保证基础的跨模态对齐能力；第二层是细粒度视觉问答数据，里面包含了大量“位置+关系+状态”的提问，比如“左侧桌面上有几个杯子”“红色车是否在白色车前方”，这一层负责教模型“看细节”；第三层是检索指令数据，构造方式是拿一段目标内容反向生成用户可能使用的搜索词，让模型学会从海量候选里找目标。
这个三层结构给了我一个启发。很多团队微调多模态模型时，只关注“问答对”的数量，忽略了数据内部的难度分布。如果数据里全是“图里有什么”这类问题，模型永远学不会空间推理。MARS团队在开放数据说明里特别强调了负样本构造，对于每个检索目标，会故意加入一些“看起来很像但其实是干扰项”的样本，逼着模型学会区分细粒度差异。这一点是很容易被忽略但性价比极高的训练技巧，后面我自己做数据清洗时，也把这个思路加进去了。
另外值得注意的一点是，MARS在训练时混合了图片输入和纯文本输入。看起来这是个小细节，但实际影响很大。许多纯多模态模型一旦遇到纯文本输入，行为会退化，因为训练时纯文本样本占比太低。MARS在训练时保证了两类样本的比例平衡，所以模型在纯文本检索和图文检索场景之间切换时，表现相对稳定。这对实际工程使用非常重要，因为真实用户不会乖乖只发图片或者只发文字，混合输入才是常态。
3. 实操视角：用MARS跑通一个多模态检索任务
3.1 部署与推理的最简流程
讲完模型思路，聊聊我自己实际操作的部分。MARS目前开源的内容足够跑通一个完整的推理Demo，不需要你自己训练，只要拿到权重和推理脚本就能试。
硬件上，我这边用的是单张48G显存的卡，加载模型FP16权重后，剩余显存刚好够做批处理。如果是小团队只有24G显存的卡，也还能跑，但需要把输入图片分辨率降下来，或者开启模型并行。部署流程大致分四步：
- 拉取开源仓库和模型权重，把依赖环境装好。PyTorch版本建议不低于2.0，Transformers库要注意和仓库要求的版本对齐，版本不一致时容易出一些莫名其妙的算子不匹配报错。
- 准备测试数据。MARS支持图文混合输入，所以你自己要先定义好统一的输入格式。图片可以走本地路径，也可以通过接口传Base64编码。文本则按模板包装成指令格式，比如“根据提供图片的风格，从候选库中找出与描述匹配的图片”。
- 加载模型进行前向推理。仓库里提供了推理脚本，但要注意一个点：模型默认会输出较长的推理过程，包括中间分析文本和最终检索结果。如果你的业务场景只关心最终输出，记得在加载参数里关掉推理过程报告，可以省大概20%到30%的显存和耗时。
- 把输出的检索结果向量交给索引系统。MARS的输出层可以导出高维向量，直接写入向量数据库。我在实际操作时，把向量维度和库里的既有向量做了映射，不需要改动索引结构。
这里我想特别强调一下输入格式对齐问题。MARS对输入文本有一个基本的指令前缀要求，不能拿到什么文本都直接塞进去。我一开始图省事，直接用裸问题文本测试，结果模型检索准确率掉了接近10个百分点。后来规规矩矩按照仓库里的prompt模板包装后才正常。这不算bug，而是模型训练时就习惯了指令格式，换格式相当于推理分布偏移，效果自然打折。
3.2 关键参数调优与效果对比
我拿一个实际场景做了效果对比，这个场景是“在视频监控片段里检索出‘一个穿黄色雨衣的人推着自行车从画面左侧走到右侧’的片段”。传统方案的做法是先用目标检测模型抽帧，再对每个帧做属性识别，最后用规则拼接候选片段，效果的好坏完全依赖中间每个环节的准确率。用MARS之后，流程简化了很多，直接把视频帧序列和文本描述一起喂进去，模型会自己输出“第几帧画面符合描述”以及相应的置信度分数。
在实际对比中，同样的测试集，传统方案在简单场景下准确率大概在80%上下，但在遮挡、光线变化大、多目标交叉的场景下掉到60%以下。MARS在简单场景下能到92%，复杂场景也能维持在85%左右。这个提升一方面来自模型细粒度感知能力，另一方面来自它的推理能力：模型会先定位出“黄色雨衣”这个核心目标，再分析“推着自行车”的交互关系，最后判断“从画面左侧走到右侧”的方向信息，整个过程是分层完成的，而不是一次性做全局匹配。
参数调优方面，我最关注的是两个。一个是温度参数，它控制着模型输出的随机性。在检索任务里，温度过高会导致结果不稳定，同一个查询反复跑可能出现不同结果；我建议把温度压在0.3以下，追求稳定输出。如果想要模型在不确定时表达“没找到”，可以稍微调高到0.5，同时配合提示词让模型在低置信度时输出“未匹配”。另一个是候选数量参数，控制模型在推理过程中保留多少个中间候选。默认值一般够用，但如果你的候选库非常大，比如超过百万级，建议把候选数量提高一倍，让模型有充足的空间做交叉比较。代价是推理时间变长，这里需要一个平衡。
4. 常见坑点与排查经验
4.1 数据格式导致检索结果漂移的处理
实际操作中最容易踩的坑不是模型本身，而是数据预处理格式。第一次跑批量测试时，我发现MARS对同一张图在不同压缩质量下的检索结果竟然不一致。后来排查发现，问题出在图像预处理管线：仓库默认的预处理会做Resize到指定分辨率，我为了省显存自己把分辨率调低了，导致图片中细节信息丢失，尤其是小目标区域，比如远处的车牌、桌子上的小物体，统统变得不可识别。图像预处理这个环节一定要和训练脚本里的参数保持一致，不能随意改。如果显存实在不够，优先选择降低批次大小，而不是降低输入分辨率。
另一个坑是混合输入中文本的位置。MARS对图文交错输入的模板很敏感，图片和文字的排列顺序会影响模型的注意力分配。我试过把场景描述放在图片之前和之后，效果差异很大。按照仓库模板的推荐，应该是文字描述放在图片之前，让模型先接收任务目标，再把图片作为参考材料。这个顺序和人类阅读理解的逻辑一致：先知道要找什么，再去看图。
还有一个小坑，就是候选数据太多时，建议不要把所有候选都一股脑塞进输入序列。MARS的输入序列长度有限，塞太多候选会导致稀疏注意力，模型反而抓不住重点。正确做法是先用向量召回粗筛一轮，把候选从百万级降到几百级，再让MARS做精细重排。这一步看起来多了一个环节，但实际上大幅提升了最终精度，也节省了推理时间。
4.2 显存与性能权衡时的取舍建议
显存不够时应该怎么取舍，这是群里问得最多的一个问题。我实测下来的结论是：优先保住输入分辨率和序列长度，其次才是模型精度。具体来说，FP16占用大，可以先尝试INT8量化，视觉编码器部分对量化的敏感度比主模型高，如果时间有限，可以先只量化主模型，把视觉编码器保留在FP16。我这个方案跑下来，显存占用降低了接近40%，检索准确率的损失在1到2个百分点以内，完全可接受。
推理性能这块还有一个容易忽略的点，就是视觉特征缓存。如果候选库里的图片不会频繁变化，可以提前把每张图的视觉特征提取好，存储到本地或者向量库。在线推理时，MARS只需要处理用户输入的文字和新上传的查询图，不需要对全库图片重复提取特征。这一招能让在线单次推理耗时从几百毫秒降到几十毫秒，工程意义非常大。我见很多团队一上来就盲目扩容GPU，其实先做特征缓存往往能省下大笔算力成本。
还有一个值得提的坑：批量推理时的Padding策略。MARS输入包含图像和文本，不同样本的序列长度差异很大，如果不做合理的Padding对齐，GPU利用率会非常难看。官方脚本里用的是动态Padding，也就是按batch内最长序列对齐，这个方向是对的。但如果你自己写推理流水线，千万别用全局最大长度做Padding，那会浪费一大半显存。批量处理时建议把输入长度相近的样本分到同一batch，能进一步压低Padding比例。
5. 开源带来的后续扩展思路
5.1 与现有RAG管线融合的设想
MARS开源之后，最让我兴奋的不是单独使用它，而是把它嵌进现有的RAG管线的可能性。现在的RAG系统绝大多数是纯文本的，先把文档切成块，然后做向量化、召回、重排。遇到PDF中的复杂图表、流程图、扫描件里的图片时，文本切块就失效了。MARS可以作为一个多模态解析器放在RAG前面，对非结构化文档里的图表做结构化描述抽取，生成带视觉证据的中文文本切片，再送回原有的文本RAG链路。这样既能复用已有基础设施，又能补齐多模态短板。
我在自己的环境里试了一个税务文档检索场景，原来的问题是用户问“图表里显示第三季度的税额趋势是怎样的”，传统RAG因为只索引了OCR文本，无法把“第三季度的柱状高度”和“趋势上升”关联起来。引入MARS对图表图片做推理描述后，RAG能够正确回答这类问题。这个场景验证下来效果很好，也让团队开始重新思考文档预处理流程。MARS在这个链路里不是替代原有检索，而是做多模态感知强化，这种“借力打力”的方式落地阻力最小。
5.2 后续可探索的微调与评测方向
再聊聊微调方向。MARS开源了权重，这意味着你可以在自己的领域数据上做二次训练。从我个人的经验来看，最值得尝试的是用它做“特定领域的细粒度定义学习”。比如在工业质检场景中，通用模型对“轻微划痕”和“深度裂痕”的区分不够敏感，你可以准备一批带领域标注的图文数据，对模型做低秩适配微调，让它在保持通用能力的同时，学会领域内部的细节边界。做这个微调时有一点要注意：数据集不要太大，几千条高质量样本就足够了，重点放在负样本和边界案例的构造上。
评测方面，我不建议只用公开benchmark，因为公开benchmark和真实业务场景的分布往往差异很大。更靠谱的方式是建立自己的五十到一百条“魔鬼样本集”，专门挑那些过去系统容易答错的案例，比如环境遮挡、光照变化、相似场景干扰等。每次模型更新后，先用这套样本集回归一遍，比只看公共分数有意义得多。我自己的经验是，这套样本集成了团队内部衡量模型效果的“金标准”，公共benchmark反而只看极少数的决定性指标。
还有一个可以长期跟的方向是多模态评测标准本身的演进。MARS这种“假设你在字里行间忘记的”大家似乎都没看太懂，我在实际操作中的体会是：推理式检索最核心的是把感知和思考分开，再有机融合。MARS在这个方向上迈出了一大步，但它留下的更多是开放性的下一步——未来不同团队可以在它的底座上，长出各自领域里更实用的多模态检索闭环。对开发者来说，现在正是动手实验的最好窗口，早一步踩坑，就能早一步掌握这套新范式的工程手感。
