Memorilla用16个记忆词元压缩文档知识

把整套文档塞给模型，成本会随上下文增长；先检索再回答，又可能漏掉不够相似但有用的线索。Stanford 研究团队开源的 Memorilla 尝试另一条路：读取整套文档，按问题生成 16 个记忆 token，再交给冻结的 LLM 回答。

它在部分任务里同时压低了输入量、提高了准确率，但代价并没有消失，而是转移到了记忆模块训练、文档编码和缓存上。对做知识库问答、个性化助手的程序员来说，值得看的是这套取舍，而不只是压缩倍数。

16 个 token，怎么承载一整套文档？

Memorilla 的输出不是 16 个可读的文字 token，而是 16 个向量，也就是软记忆嵌入。可以把它理解成：一个经过训练的模块替模型读资料，再把与当前问题有关的信息整理成模型能接收的内部表示。

流程分三步：

1. 冻结的 Qwen3-Embedding-4B 为每篇文档编码一次。新增文档时，旧文档不需要重新编码。
2. 每次提问，16 个可学习槽位结合问题读取完整文档存储，模块使用 2 层交叉注意力，每层 8 个注意力头。
3. 将这些槽位投影到 Qwen3-8B 的输入嵌入空间，放在问题前面，由冻结的 Qwen3-8B 生成回答。

固定的是交给解码器的记忆长度，读取文档存储的工作仍随规模增长。

这与常见方案的区别在信息如何进入模型：Mem0 提取文字记忆，MemoRAG 用记忆模型辅助检索，xRAG 将检索内容压成 1 个投影嵌入；Memorilla 则针对问题，从整套存储中生成潜在记忆。

编码器和解码器都不更新，训练集中在 194,123,776 个参数的记忆模块上，约 194M。训练分三阶段：先用约 1.98M 条 Wikipedia 改写重建样本，再加入来自 10 个问答和摘要数据集的约 1.34M 条样本，最后在全部 8 个基准上微调。完整配方需要 4 张 H100，耗时约 19 小时。

所以，「冻结 LLM」不等于不需要训练。它把训练对象缩小到了连接文档与模型的中间模块。

压缩后成绩更好，哪些任务成立？

论文主表中的基线统一使用冻结的 Qwen3-8B，成绩由研究团队自行报告。Memorilla 在 8 个基准上平均得分 49.68，其中 5 个拿到最高分。

几个结果能看出它的优势：

• FactKG 准确率为 84.33%，高于完整上下文的 80.43% 和 MemoRAG 的 80.38%，文档 token 用量减少 108 倍。
• PersonaMem-v2 准确率为 44.60%，完整上下文为 27.92%，次优方法 xRAG 为 30.90%。
• TriviaQA 的精确匹配分数为 57.00，略高于 MemoRAG 的 56.60；LaMP-4、LaMP-7 的 ROUGE-L 分别为 18.15、48.37，均为最高分。

一种合理解释是，按问题压缩信息可以减少无关内容干扰。但原文没有给出足以单独验证这个解释的对照，不能把它当成已经证明的原因。

它也输了 3 项。PubMedQA 只有 59.00%，LLMLingua-2 达到 69.00%；这项任务的摘要合计仅 324 个 token，压缩空间很小。PersonalizationV4 上，MemoRAG 以 67.88% 超过它的 66.65%；NarrativeQA 上，MemoRAG 的 ROUGE-L 为 20.51，它为 19.31。

后两项中，MemoRAG 分别使用了约 690 倍、50 倍的文档 token。这提醒我们，质量和输入成本需要一起比较。NarrativeQA 的压缩最突出：67,385 个文档 token 被替换成 16 个记忆 token，减少约 4,212 倍，但分数仍未拿到第一。

另一个实验使用 8 个记忆 token，让 Qwen3-4B 在 TextWorld 中的平均成功率从 18.6% 升到 24.2%。它支持继续探索智能体记忆，尚不足以代表日常编程 Agent 的收益。

回答很快，部署门槛却不低

在单张 H100 上，面对 512 篇文档、约 128K token，Memorilla 回答耗时 0.74 秒。完整上下文方案的耗时随规模从 0.75 秒增至 19.9 秒，后者约慢 27 倍；记忆模块自身约耗时 2 毫秒。

可选缓存会提前计算交叉注意力的键和值。在单张 B200 上，100 万篇文档对应的单次问题处理耗时为 8.1 毫秒，400 万篇为 33 毫秒；使用 torch.compile 后，100 万篇场景降至 5.0 毫秒。400 万篇文档的缓存占用为 80 GiB。

这些毫秒数据不能直接读成端到端回答延迟，原文没有把它们与 H100 的完整回答时间统一口径。

部署要求是 Linux、CUDA GPU 和 Python 3.11。快速开始需要 1 张 80 GB 显存 GPU，首次运行下载约 25 GB 模型，原文未披露量化版本。安装使用 uv，通过 MemoryVLLM.from_pretrained 加载；检查点位于 memorilla/Memorilla-Qwen3-8B，包含 Stage 1、Stage 2、Stage 3、PV4 和 PMv2 文件夹。

每个检查点必须搭配训练时的解码器。自定义数据使用 parquet，需有 collection_id、question、answer、documents 四列。这也说明，它需要模型侧集成，接一个普通文本聊天 API 并不能直接复现。

我的判断

我认可它把「文档如何进入模型」作为可训练环节。对长文档和个性化信息，始终传入全文确实未必划算，单靠相似度检索也可能漏线索。

但 16 个记忆 token 不是整套系统的成本账单。 编码器、解码器、训练和缓存都需要资源；压缩还可能损失细粒度事实，PubMedQA 的结果已经给出了边界。

评测还有一个前提：第三阶段在全部 8 个基准上微调。这不等于测试数据泄漏，但原文没有说清各基线是否获得了相当的任务训练预算，也没有给出普通团队私有数据上的直接迁移结果。不能据此断言，它拿来就比现有 RAG 更好。

此外，8 项平均分混合了准确率、精确匹配和 ROUGE-L，适合概览，不能当作统一业务收益。原文列出的 xRAG、LLMLingua-2、Mem0 平均分分别为 41.92、40.75、38.02，仍应回到目标任务逐项判断。

能拿来做什么

• 做知识库问答时，可以先复现完整上下文、现有检索方案和 Memorilla，使用同一套业务问题，同时记录正确率、延迟和资源占用。
• 做个性化助手时，可以参考团队发布的 PersonalizationV4 数据组织方式。它包含 149 个合成用户，每人 200 段对话，采用 CC BY 4.0；合成数据上的收益仍需用真实业务样本验证。
• 用 Node 搭建服务时，应先确认推理服务能接入对应解码器和软记忆嵌入，再设计业务接口。代码、训练配方和检查点按 Apache 2.0 开放，但现有硬件与集成成本仍需单独核算。