一套向量按预算截断：多模态检索降本的开关在维度上｜洹拓科技
一、降本的开关从选模型挪到了选档位
据公开报道，某大型应用的视觉团队开源了一组多模态检索模型，提供三档参数规模，可以把文字、图片、视频和视觉文档编码到同一个向量空间，用于跨模态检索、以图搜图、视频搜索与多模态知识库；训练分两个阶段，并支持从六十四维到两千零四十八维之间截断使用同一份索引。这些参数与维度口径不作为本篇的判断依据，我们要抽走的是那个开关本身。
过去做检索降本，决策项是模型：换更小的编码器、降批大小、把召回层裁剪掉。代价是每换一次模型，索引要重建、离线评测要重跑、线上一致性要重新对齐，而且精度是一次性整体涨跌，没法按场景分配。可变维度把这件事拆开了：模型只有一个，索引只有一份，成本决策变成给每个场景选几维。同一份向量，粗排用低维，精排用高维；高频查询走高维，长尾流量走低维。这条变化看起来只是多了一个参数，实际是把预算分配从月度重构变成请求级配置。
二、同一份索引多档截断要解决的四件事
截断不是把向量前若干位切掉就完事，四件事要有明确处置。
第一，截断后的相似度排序与全维度的一致性怎么测。判据不是“分数接近”，而是排序是否保得住：同一批查询在全维度和截断维度下各取前若干条结果，看重叠率与名次位移；只看余弦值的变化会把大量顺序颠倒漏掉。这件事要按内容类型分别测，图和文的位移形态不一样。
第二，不同档位各自的召回损失曲线。横轴是维度档位，纵轴是分段召回，曲线要按查询类型分开画。有的场景在很低的档位就触到平台，有的要中高维才开始收敛，一张平均曲线会把两类都骗过去。曲线跑一次不够，索引增删一段后要重跑，档位的选择会漂。
第三，缓存与索引文件是否按档位分建。低维检索的收益很大程度来自能塞进内存，但如果每个档位都存一份完整索引，磁盘和构建时间会成倍上去。可行的结构是一份全维索引，加一层低维派生文件；派生文件必须标出它派生自哪一版，防止两侧不同步。
第四，查询侧与库侧档位不一致时怎么处理。这是线上最容易出隐形故障的地方：新上线的查询用了高维，库里还是低维向量，相似度算得出数但完全不可比。处置办法是把维度做成索引的显式字段，查询里带的维度必须匹配，不匹配直接报错而不是补零或截断。
三、粗排精排分档能省什么，赔在哪
省的部分很直白：粗排阶段要在几千万条候选上做近邻搜索，向量越短，每次距离计算的算术量越小，同一块内存能装的条目越多，能常驻的机会越大。低维粗排之后，精排只对很小的候选集重新用高维打分，编码与索引仍然只有一份。这套组合还顺带降了网络传输与序列化开销，多副本部署时那部分并不小。
赔的部分只有一条，但必须量化：粗排档位漏掉的长尾内容，精排永远救不回来，因为它根本不在候选集里。所以分档的成本模型不能只看平均召回，要单列一个漏检率——真正该出现在结果里的内容在粗排阶段就被丢掉的比重。测法是给同一批标注查询构造两组候选，分别用低维和高维跑，统计高维能召回、低维完全召不回的条目。长尾内容、冷门表述和新入库内容在这一项上最差，而这正是知识库类业务最在意的部分。量出来的漏检率要能按档位查表，业务方要扩量时看的是这张表，不是一句“精度损失很小”。
四、上线前必须补的三张表
在洹拓做多模态检索项目，上线评审前要看三份数据，缺一份就不签。
- 跨模态对的召回表。行是查询类型——文搜图、图搜文、文搜视频、图搜视觉文档；列是维度档位；每格填分段召回和名次重叠率。这张表是用来抓“某一类跨模态对整体偏弱”的，平均指标里看不出来。
- 按内容类型的准确率表。图表页、纯文字截图、短视频、长视频、扫描件、图文混排，每一类单独一档，同时记录该类的入库量占比。小类占比低但错误率高，业务方感知照样很强。
- 按查询频次的成本表。头部查询、腰部、长尾三档，各自记录一次查询触达的候选量、维度档位、平均耗时与算力开销。这张表决定档位怎么分配：头部往高维走值得，长尾走低维省得最多。
三张表的共同前提是有一个自己的离线评测集，题目按真实查询日志抽，标注按内容类型分。用别人给的数据集定档位，最后是按别人的分布下结论。
五、四类最容易出事的边界，以及两阶段训练对使用方的意义
四类边界在验收里要单独出用例，不能并进主表。
视觉文档里的图表与小字：图内表格、坐标轴标签、被压到几个像素的小字，编码后很容易在向量层面失去区分度，结果就是能按整页风格匹配，但按表里某个具体值搜不到。用例要专门包含“按图内文字提问”和“按图表数值区间提问”两类。
视频的时长与信息密度差异：一段几十秒的短片和一段几十分钟的长视频进同一个向量空间，前者信息集中、后者被平均化，长视频里某个片段相关的查询很容易被整体表征吞掉。验收要按视频时长分档给召回，不能只看整体。
同一内容的多版本近重复：封面重制、分辨率不同、剪辑版本、带水印与不带水印，同一事物会有多个近重复表征，检索会返回一堆同义结果。这一类的处置要在入库侧做归并与去重，不能指望向量自己分开。
跨语言查询：用一种语言提问去找另一种语言的内容，是否成立取决于第一阶段对齐做得有多宽。这一类要单测，不能默认它跟着文本检索能力一起有。
两阶段训练这个信息对使用方的意义，不是“效果更好”，而是能力覆盖面的推断线索：第一阶段建立跨模态对齐，第二阶段提升检索判别力。据此可以怀疑两件事——细粒度判别（同类物体之间的微小差异、图上标注的差别）与长视频的片段级检索，可能是表征层面没有被重点训练的方向。这不是断言，是要在自家数据上验一验的两个高风险点。
六、最小成本模型，和“已上线”这句话能推出什么
选型不该只比精度，要能把成本按档位摊开。一份最小成本模型四个量：每千万条内容在不同维度档位下的索引体积；内存常驻与磁盘加载的取舍，低维常驻、高维按需加载是常见组合，代价是多一层命中判断；单次查询的算力量级，按候选量乘以向量长度估；按档位分层的年化成本对比，把不同流量档位分别落到不同维度上再加总。四个量填出来，档位分配就从“感觉省一点”变成一张可查的表，扩容和降档都有数可依。
据公开报道，这一组模型已经在它自家的搜索与推荐里上线。这句话是全套信息里最值钱的，但要读准它的边界。能推出的三条：它在检索链路而非生成链路上跑得稳，因为嵌入模型的线上形态是召回与排序服务；它的延迟能接受业务要求，粗排精排的组合在真实流量下不塌；它的索引更新机制至少支持持续入库。推不出的一条同样重要：它没有在你的数据分布上被验证过——你的内容类型占比、你的查询分布、你的近重复密度都不同。
所以选型时我们只问三件事：召回口径是什么，按什么分段、算不算跨模态对；索引更新频率是多少，全量重建还是增量入库；有没有可复核的离线评测集，能不能换成甲方自己的数据重跑。三个问题都能拿到答案，参数规模和维度区间这些数字就可以往后放；拿不到答案，再高的公开指标也只是别人的分布。