先聊个现象很多团队做多模态记忆核心思路就是存进去、找出来最多加个相似度排序觉得能搜到就算完成任务。但实际用下来你会发现多模态记忆如果只停在找得到那它本质上就是一个带索引的视频相册或者文档仓库根本没法支撑上层决策。我最近在折腾一个叫 ADAMM 的记忆架构它的核心主张恰好是这句话多模态记忆不只要找得到还要算得出来——也就是说长期记忆要能直接产出可执行分析而不是让业务方自己去翻结果、自己再去推断。这篇文章就来拆一拆 ADAMM 的设计思路、实操细节和落地过程中踩过的坑适合正在做多模态大模型应用、智能体记忆系统或者想给业务接会思考的长期记忆的开发者参考。1. 为什么多模态记忆不能只停在找得到1.1 传统记忆检索的三个致命短板先明确一个概念这里的多模态记忆指的是系统长期保存的来自文本、图像、音频、视频等多类模态的数据及其语义关联。早期做法很直白把各个模态的数据丢进向量库来一个 query算相似度返回 Top-K。这套路在 demo 里没问题一上真实业务就露馅。第一个短板是检索结果不可聚合。比如你在做安全监控场景系统存了过去一个月所有摄像头拍到的异常行为片段。现在业务方问最近两周晚上十点之后东门区域出现异常行为的频率和趋势是什么传统检索会给你吐出一堆相似片段但不会告诉你趋势不会给你算均值更不会主动给出该区域夜间异常行为正在上升这样的结论。你得再写一堆后处理代码去统计。第二个短板是跨模态语义难以对齐。文本里说车辆停在消防通道图像里拍到的是一辆白色 SUV 停在黄色网格线区域音频里是有人鸣笛催促。三个模态都描述了同一件事但没有统一的结构化表示检索系统很可能把它们当成三段无关记忆。多模态融合如果只做在 embedding 层面拼向量特征是拼上了语义该对不齐还是对不齐。第三个短板是记忆缺少时间维度的计算能力。长期记忆的核心价值在于长期两个字——它意味着有变化趋势、有周期性、有异常波动。可传统向量库里的记录基本都是一个点没有对时间序列做建模也没法直接在记忆层面对多个时间点的同类事件做比对分析。说白了传统思路把记忆当成存储-检索的流水线而真实业务需要的其实是存储-检索-计算-决策的闭环。这也是 ADAMM 这类可计算记忆架构出现的直接原因。1.2 可执行分析到底指什么我在跟朋友讨论的时候发现大家对可执行分析的理解差别很大。有人说能查出来就是分析有人说能画个图表就是分析还有人说能调用大模型总结一段话就是分析。这些都不够准确。ADAMM 对可执行分析的定位是记忆系统能基于用户的问题主动从多模态记忆中抽取、聚合、比较、推理最终产出可以直接驱动业务动作的结果。举例来说东门区域夜间异常行为频率最近两周比前两周上升了 37%高发时段集中在 22:30-23:15疑似与附近施工区域灯光关闭时间提前有关——这就是一条可执行分析结果因为它包含了变化幅度、时间规律、原因假设业务方拿着就能决定要不要增加该时段巡逻。要做到这一点记忆系统必须额外具备三类能力跨样本统计能力多个记忆条目之间的频次、均值、分布、跨模态对齐能力把同一事件的不同模态表示映射到统一语义空间、时序感知能力把记忆放在时间轴上比较和推理。这三板斧传统向量检索一个都没有。2. ADAMM 的记忆架构整体拆解2.1 整体分层感知、语义、执行三层ADAMM 的全称我按自己的项目理解可以拆成 Adaptive Multi-modal Memory如果团队当初不是这个含义也不影响架构思路本身。它的核心设计是把记忆系统从检索管道改造成分析引擎从底往上分三层。第一层叫感知记忆层负责接收多模态原始输入完成模态识别、事件切分、基础特征提龋这一层输出的是片段级记忆单元每条记忆都带模态标签、时间戳、空间位置如果是视觉类数据、置信度评分等基础元信息。第二层叫语义记忆层负责把感知层产出的片段映射到统一语义空间并建立模态之间的关联关系。这一层不是简单地把文本、图像、音频的 embedding 拼接而是通过跨模态对齐模型把同一事件的多模态表达拉近到同一个语义簇里同时抽出结构化的事件描述谁、什么时间、在哪、发生了什么、状态如何。第三层叫执行记忆层也是 ADAMM 最核心的区别所在。这一层维护了一组可计算记忆单元每个单元不仅有 embedding 向量还带类型化字段数值、类别、时间、枚举、关联引用。查询进来时执行层会根据任务类型做聚合、统计、比较、时序分析最终输出结构化分析结果而不是原始片段列表。这三层的设计逻辑很简单感知层负责记得住语义层负责看得懂执行层负责算得出。你的记忆系统到底解决了什么业务问题看执行层的能力就够了。2.2 为什么强调结构化记忆单元这是整个架构里最容易被忽略、但实际最要命的设计点。传统记忆库里的条目通常是一整段文本或一个完整的图像 embedding查询时整存整取。但可执行分析要求记忆能被拆分、被比较、被统计这意味着记忆的原子粒度必须小且必须带类型化元数据。ADAMM 的做法是把一次感知事件拆成多个原子记忆条目。比如一段监控视频片段它会拆成主体对象条目白色 SUV、行为事件条目停在消防通道、时间状态条目22:41 出现持续 14 分钟、环境状态条目附近照明灯亮度偏低。每个原子条目都是一个结构化的键值集合外面再挂一个统一的语义向量。这样查询夜间违规停车持续时长超过 10 分钟的事件有多少起就能直接对行为事件持续时长数值两个字段做过滤和统计而不是先召回一大段视频再人工数。结构化还有一个好处是解决对齐难的问题。文本、图像、音频在原子条目层面都变成了对象-属性-值的三元组形式跨模态对齐变成了三元组之间的匹配难度比整段语义对齐低了一个量级。我在实际项目中体会很深不做结构化对齐多模态系统基本上就是一个好看但不好用的玩具。3. 核心环节实操从写入、检索到可执行分析3.1 多模态记忆的写入链路搭建这一节直接给可落地的方案。我以16G 显存单卡部署 开源多模态模型 ADAMM 架构的组合为例这个是目前社区里比较主流、成本也可控的配置。写入链路分五步。第一步是模态接入与预处理。视频流按场景切分是关键操作我一般用场景切换检测结合音频静音检测来做切分粒度控制在 5-15 秒一段太短了语义不完整太长了事件杂糅后续结构化的难度会变大。图像先做压缩和统一尺寸文本做清洗和分句音频做降噪和 VAD语音活动检测切分。第二步是多模态统一编码。我试过直接用 Qwen-VL 这类多模态大模型的输出特征也试过用 CLIP 的图文联合向量最终在 ADAMM 里的做法是先让多模态大模型对每个片段生成一段结构化描述文本再用文本编码模型把描述转成语义向量。为什么绕一道因为纯视觉 embedding 很难直接抽结构字段而自然语言描述可以顺便把对象、属性、值带出来。这一步在 16G 显存上跑 Qwen-VL 系列是可行的实测 8B 量级的模型就能产出可用的结构化描述。第三步是结构化信息抽取。把上一步的描述文本输入到一个轻量的信息抽取模块产出三元组和类型化字段。这一步没有太多黑科技用大模型做 few-shot 抽取就够了关键是 prompt 要固定好 schema不然字段命名不稳定后面统计阶段会吃亏。第四步是原子记忆单元生成。这一步把上一步的抽取结果做去重、对齐、时间标注写入记忆库。写库时我会同时维护两个索引一个向量索引用于语义召回一个倒排或关系索引用于字段过滤和数值统计。两个索引共用一个记忆 ID保证分析阶段能来回切换。第五步是记忆质量回写。这一步容易被忽略但它直接影响长期记忆的可用性。每次查询之后把用户反馈和下游任务结果回写到对应记忆单元的元数据里比如这条记忆触发了一次有效告警或者这条记忆被人工标注为误报。时间久了这套系统就有了自己的经验库能按历史有效性做加权召回。3.2 不同类型的分析任务怎么做ADAMM 的可执行分析能力落到实现上其实就是把查询路由到不同的计算子模块。我在工程里按查询意图分成了四类这里分别讲做法。单条记忆的语义理解这类任务最简单query 进来先去向量索引召回 Top-K 相关记忆单元然后让大模型对召回的单元做摘要或者问答。输出一般是自然语言结论比如这段视频里发生了什么。注意这里的 Top-K 不要取太少我实测 16G 显存场景下取 20-30 个单元效果比较稳。多条记忆的聚合统计这一类是算得出来的核心突破口。query 里如果带时间范围、区域范围、对象类别等显式条件先去关系索引做过滤再对过滤结果做 count、sum、avg、p95 这类聚合运算。比如最近两周夜间东门违规停车事件的平均持续时长直接在执行层写一个聚合算子就能出结果不需要大模型参与快且准确。跨模态关联分析这类任务比较高级。比如车辆停在消防通道之后是否伴随有人鸣笛。要回答这种问题系统需要先通过语义索引召回违规停车相关的事件单元找到其事件 ID再通过事件 ID 反查同一时间窗口内的音频记忆单元看是否存在鸣笛事件。本质上靠的是原子记忆单元上的事件 ID和时间戳两个字段做 join架构上支持得好这类任务就很容易实现。时序趋势与异常检测这类任务考验的是记忆库有没有做时间维度的组织。ADAMM 在语义记忆层维护了一张事件时间线表每个事件在表里占一条记录记录事件类型、时间、核心对象 ID、数值属性。做趋势分析就是从这张表按时间桶聚合计数再做环比、同比。异常检测可以用简单的统计阈值法比如同类事件频次均值 2 倍标准差不需要上太复杂的模型。这四类任务合起来基本覆盖了业务方常问的问题形态。我自己的经验是先实现好第 1、2 类就能解决 80% 的日常需求第 3、4 类属于加分项但架构上必须在写入阶段就预留好字段否则后面补是很痛苦的。3.3 16G 显存环境下的模型选型与性能取舍聊到部署很多人上来就问16G 显存能不能跑多模态记忆系统。能跑但要做取舍。我的建议是拆成两个模型离线写入走大模型在线查询走小模型。离线写入阶段用 Qwen-VL 系列的 8B 或 4B 模型负责把多模态片段转成结构化描述。这个过程是异步批处理对延迟不敏感16G 显存跑 8B 模型做推理batch size 控制在 1-2吞吐量完全够用。实测在单张 16G 显卡上处理一段 10 秒视频片段抽关键帧 音频轨道 描述生成大约需要 2-4 秒如果是夜间批量处理日志场景这个速度是可以接受的。在线查询阶段走轻量模型。语义召回用 bge-m3 或者 multilingual-e5 这类 embedding 模型显存占用不到 2G。结构化分析和大模型总结这类任务如果对生成质量要求不极端可以用 4B 或 7B 量级的小模型配合量化和 vLLM 推理框架16G 显存完全扛得住。还有一个经验是不要在查询链路上串太多大模型调用。我见过一些方案一个 query 进来先让多模态模型理解一下再让大模型规划一下再让大模型总结一下结果延迟飙到十几秒显存也吃紧。ADAMM 的做法是把大模型只保留在两个位置写入阶段的结构化描述生成和分析阶段的最终结论生成。中间过滤、聚合、join 全部用确定性的算子来做又快又省钱。4. 落地时遇到的坑与排查思路4.1 检索相关但不可算的尴尬我最早做这个系统的时候犯过一个特别典型的错。当时为了省事直接把原始片段描述整段存进向量库查询时召回 Top-K 之后发现每条记录都跟问题相关但没有一条记录能直接回答问题。比如我想统计夜间违规停车的平均时长召回的结果是几十段描述文字每段都提到违规停车但时长这个信息以叙述形式混在文字里没法直接求和平均。后来改成原子记忆单元 结构化字段方案才彻底解决这个问题。排查这类问题有个规律如果查询结果看起来都对但算不出来十有八九是记忆写入阶段没有做字段结构化。调整方向就是在写入链路里补一层信息抽取把数值、枚举、时间字段单独拎出来存。4.2 跨模态对齐不准怎么定位跨模态对齐不准确的典型表现是同一事件的三段记录文本、图像、音频被分到不同的语义簇导致聚合统计时漏数。我遇到的 case 是同一个违规停车事件文本记录里写白色 SUV 停在消防通道图像记录里是白色车辆在黄色网格区域音频记录里是持续鸣笛声。三个模态的 embedding 相似度都不高系统误判成三个独立事件。排查思路是把跨模态对齐分成两层来看先看底层 embedding 是否已经做了对齐训练。如果用的是通用 CLIP 系列图文能对齐一部分但加上音频就不行了。我的做法是引入一个小的跨模态投影层用几百条业务标注数据把三个模态的 embedding 映射到同一个空间里。这个投影层用对比学习训练数据量不需要很大重点是把业务中出现过的典型场景覆盖到。实在没有标注数据还有一个土办法利用时间窗口共现来辅助对齐。发生在同一时间窗口内的多模态记录优先尝试归并到同一事件。虽然会有误差但在监控和行为分析场景里时间共现本身就是很强的信号。4.3 多模态指标平衡度与数据质量坑做多模态记忆跟做纯文本检索最大的不同是各模态的数据质量和数量往往严重不均。我见过一个项目文本记录占 80%图像占 15%音频只占 5%。这种情况下无论怎么调模型记忆体里的语义分布都是偏的查询结果天然偏向文本模态。这里说的多模态指标平衡度指的是各模态在召回结果中的占比是否与真实分布一致、各模态的召回贡献是否均衡。排查时我会看三个数各模态记忆条目的写入量占比、线上查询中各模态被召回的占比、各模态召回结果的业务采纳率。三个数一对比就能看出是不是某个模态存了一堆但从来没被用到或者数据很少但每次都靠它命中。数据质量上的坑更隐蔽。图像分辨率差异大、音频底噪高、文本有 OCR 错别字这些都会污染 embedding 质量。我的建议是在感知记忆层就做质量打分低于阈值的记忆单元直接标记为低置信在召回和聚合时降权处理别让脏数据污染统计结果。4.4 长期记忆的时间衰减与冷启动策略长期记忆还有一个传统检索不涉及的问题时间久了旧记忆还有没有价值。我在系统里做了一套时间衰减策略每条记忆单元有一个基础权重随着时间递减但递减速度跟记忆类型有关。比如安全事件类记忆衰减慢保留价值高环境状态类记忆衰减快三天前的环境状态基本没有参考意义。冷启动阶段的问题也值得说。新系统刚上线时记忆库是空的任何查询都召回不到内容更谈不上分析。我的做法是分两步先导一批历史数据做预填充哪怕这批数据的结构化程度不太高也要先把时间线和事件主体搭起来同时对高频查询做埋点等线上跑一两周用真实 query 反过来补充记忆写入的 schema让系统逐步适配业务方的提问习惯。说到底冷启动拼的不是模型有多强而是记忆写入能不能跟上业务提问的节奏。我见过不少团队把记忆系统做成一次性工程上线就不再管写入质量过了一个月整个库就变成了垃圾堆。记忆系统是需要持续运营的组件不是部署完就完事的。5. 经验总结与后续扩展思路踩过这么多坑之后我个人在实际操作中的体会是多模态记忆架构的关键不在于用了多大的模型而在于是否在写入阶段就把记忆做成可计算的结构。ADAMM 这套思路最值得借鉴的地方就是它把检索和计算两件事分开用结构化的原子记忆单元把两者衔接起来。这个决策越早做后面的分析能力就越顺。关于后续扩展我现在在尝试的方向是把执行记忆层从规则算子升级成可学习策略。具体来说让系统根据历史查询的效果反馈自动调整聚合算子的权重和时序异常检测的阈值。另外也在尝试把 ADAMM 的原子记忆单元直接暴露给大模型做工具调用让智能体在回答问题时能自己决定是去检索还是去做统计分析而不是每次都在提示词里塞一堆上下文。还有一个小技巧最后分享出来给每条记忆单元加一个可执行度指标表示这条记忆距离直接产出业务动作还差几步。写入时人工标注一批再用模型预测长期维护下来整个系统的记忆质量会越来越可量化也方便你向业务方解释这个记忆系统到底值多少钱。