多模态 Agent 的记忆系统，过去很容易被理解成一个升级版 RAG：图片、图表、PDF 进来之后，先抽取内容、做 embedding、写进向量库；用户提问时，再用 query 做检索，把命中的top-k图片、文档页或图表一并塞进上下文，再交给多模态模型回答。整个过程中，所有原始模态信息都会不加选择的塞给大模型。这个思路在系统复杂度低的时候，问题不大。但记忆累积到几十个会话、上千个文件之后，失败概率就会直线上升。有时候，是因为系统“召回了太多证据”，导致需要的原图已经在上下文里，但却被一堆语义相近但无关的图片淹没；有时候，则单纯是一些只需要读文字摘要就能回答的问题，系统仍然把原始图片或 PDF 页面渲染进 prompt，白白消耗 token。如果你也有类似困扰，这篇多模态记忆 benchmark 的论文（M3 Exam，arXiv 2606.07402），或许可以给你带来一些启发。01
多模态 Agent记忆，不需要反复看图
与传统的单次视觉理解不同，M3 Exam 论文会更加关注长期多模态记忆。举个例子来帮助我们理解其中区别：单次视觉理解：“这张图片里有什么？”“这张图表最高值是多少？”“这页 PDF 讲了什么？”长期多模态记忆：我之前上传的那份报告里，哪一页能解释这张图？这张照片和我上次提到的训练材料有什么关系？单次视觉理解中，读取原始模态信息的存在是必要的，但在长期的多模态 Agent 记忆中随着多模态信息总量增加还是这么做，就会导致决定性证据被无关视觉内容淹没，以及单次查询 token 预算被抬高。比如一张图表，如果坐标轴、数据系列、关键数值已经被转写成文字，模型可能读文本就能回答。一份 PDF，如果文本层和页面摘要已经可用，很多问题根本不需要重新渲染页面。一张图片，如果问题只问明显对象、场景或描述性信息，caption 也可能够用。当然，也有一类问题必须回到原始视觉源。比如图片里的细微视觉差异、图表布局、截图中的空间关系、文档页面中的视觉结构。这些信息很难被简单 caption 完整替代。02
M3 Proctor：把图变成可检索的文本
M3 Proctor 把是否需要看原图变成了一个显式决策。第一步是在索引阶段为原始多模态内容生成文本代理（textual surrogate）。图片配 caption；图表、表格这类信息密集的视觉内容，额外生成包含坐标轴、数据系列和具体数值的转写；文档页则保留文本层，并加上一句摘要。这样，原本只能靠视觉模型读取的内容，就可以变成普通文本检索器可以命中的代理表示。光有文本代理还不够，每个 chunk 还需要挂一个模态标签（modality tag），标记它对应图片、文档还是图表。M3 Proctor 还为每个 session 增加 session-summary chunk，相当于一份压缩的小时间线，保留跨会话信号，避免跨会话的线索被按轮（round）切碎。第二步是“成本感知级联（cost-aware cascade）”，分为三个阶段：第一阶段是模态偏置检测：用一次指令调优的 LLM 调用，判断这道题到底依赖哪种模态，输出一个二值向量，结果缓存起来。第二阶段是模态感知重排：密集检索只按语义相似度排序，可能把“持有决定性图片、但跟 query 只是中等相似”的那条压下去，于是用模态偏置去校正候选池内的排序，让对的模态浮上来——注意这一步只动 top-k 的模态构成，不会把无关 chunk 提上来，也完全在索引时的标签和代理上操作，不碰原始源。第三阶段才是级联本身。系统先只用文本代理回答。如果置信度足够，流程就结束；如果文本答案不可靠，或者模态偏置明确显示这题需要原始视觉源，系统才进入第二阶段，把对应的原图、图表或文档页补进上下文。论文把这个机制称为 cost-aware modality cascading：先使用足够便宜的表示，只有不够时才为更贵的表示付费。论文报告称，级联只在该升级的场景才触发：在文件管理（fm）上触发率 68.0%、多模态推理（mr）上 51.1%，而纯文本类问题都在 15% 以下。整体只有 26.4% 的 query 会升级到读原图。成本上，M3 Proctor 建索引 需要72 秒、每 query 需要4591 token；而多模态基线如 MIRIX 要 43271 秒建索引、NGM 每 query 要 26988 token，差出一到三个数量级。综合下来，M3 Proctor 相比现有系统准确率提升约 13%、token 少约 70%、索引构建时间少约 80%。需要说明的是，这些数字来自论文在自己 benchmark 上的评测，条件限定在 M3 Exam 内，不能直接外推到所有生产环境模态感知。03
M3 Proctor+Milvus 3.0 ，如何搭建更好的多模态 Agent 记忆
很多人会把这件事放在 Agent 编排层处理：加一个 router，加一个判断模型，加一个 reranker。这样当然可以起步，但如果底层存储不支持对应的数据组织方式，系统很快会变复杂。第一，同一条记忆要能挂多种表示。文本代理、视觉 embedding、图表转写、文档页面摘要，最好围绕同一个 memory entity 管理，而不是拆散后再在业务层拼接。Milvus 3.0 引入的EmbList正好可以承接这个需求：它支持把一个实体（如一篇文档、一张图片）的多个向量片段（文本代理 embedding、原始视觉 embedding、图表转写 embedding ）打包存在一条记录里，并在搜索时直接对整个列表做 late interaction。这样，Stage 1 可以走文本代理路径，Stage 2 再按需走原始模态路径。第二，检索时要能利用 metadata。让模态过滤应该尽可能发生在候选进入上下文之前，也就是让modality tag、session_id、user_id、file_type、created_at 这些字段决定候选范围。这里推荐使用Milvus 的标签过滤能力，我们可以把模态标签作为标量字段存进 Milvus，检索时用过滤表达式可以直接约束候选范围。配合 partition key 或 metadata filter，还能把不同 persona、不同 session 的记忆隔离，避免跨用户记忆互相污染，这正好对应 M3 Exam 里 15 种 persona 各自独立管理的隔离需求。第三，系统要能接受异步补齐。多模态 pipeline 往往不是同步完成的：图的文字描述（caption）可以在图传入时立刻生成，OCR 和图表解析稍后完成，视觉 embedding 更晚才就绪。存储层需要允许一条记忆先以部分表示参与检索，再逐步补齐其他表示。Milvus 3.0 的可空向量字段（nullable vector）支持记忆条目在视觉 embedding 还不存在时先写入，文本代理字段照常参与检索；等视觉 embedding 就绪，补填进来即可。不需要等待两路同时完成才能写入，也不会因为视觉字段为空而影响文本路径的召回。第四，读取应该是列级或字段级的。Stage 1 只需要文本代理，就不该把原始视觉内容也读出来；Stage 2 触发升级时，再读取 raw source。否则上层虽然做了 cascade，底层成本仍然没省下来。Milvus 3.0 的存储引擎Storage V3重构了数据的组织方式：数据可以以列存格式落在 S3 兼容的对象存储上，每个版本状态由一份不可变的 Manifest 快照（Avro 编码）捕获，读取时只拉需要的列，不读整行。尾声
按需取图不是所有系统都需要。只有用户出现图片、图表、PDF 会跨多个 session 长期积累；问题经常需要在旧文件和新对话之间建立联系时才需要，典型场景包括：法律、医疗、教育等等。
粤ICP备14082021号
免费POC，
零成本试错
