从另一个角度补充几点观察：
关于「数据合成成本」的真实规模
主文提到五步骤管道生成了大量反思 QA 对，但没说清楚成本。论文表 11 给出的数据：
- BrowseComp-Plus：~60 万对
- NarrativeQA：~160 万对
- MuSiQue：~80 万对
一个实际问题：如果你每天有新文档要纳入，是否每次都要跑完整五步骤管道？论文的模型合并方案可以增量更新，但数据合成管道能否增量？论文没有回答。如果每次更新都要重新生成全部 QA 对，那 MEMO 的「低成本更新」优势就大打折扣。
关于「对检索噪声免疫」的深层含义
主文强调 MEMO 对检索噪声免疫，RAG 在噪声下掉 6 个点，MEMO 几乎不变。这个结论成立的前提是：MEMORY 模型已经成功内化了知识。但如果 MEMORY 本身训练不充分、知识有缺口呢？
想象一下：用户问了一个 MEMORY 没有内化的问题，EXECUTIVE 从 MEMORY 得不到有效信息，又无法回退到原始文档（因为 MEMO 不保留检索路径），这时候系统会生成什么？可能是幻觉，也可能是「我不知道」。
RAG 的优势在于可解释的回退：检索失败时，你可以看到拿到了哪些文档、为什么没拿到目标文档。MEMO 把知识压缩成参数后，这个可见性丧失了。论文没有讨论「知识缺口检测」或「置信度校准」机制——如果 MEMORY 对某个查询不确定，它应该怎么告诉 EXECUTIVE？
关于「跨 LLM 可迁移」的实际情况
论文表 1 把「跨 LLM 可迁移」列为 MEMO 的优势，理由是 MEMORY 和 EXECUTIVE 是解耦的。但实验里 MEMORY 用的是 Qwen2.5-14B-Instruct，EXECUTIVE 用的是 Qwen2.5-32B-Instruct 和 Gemini-3-Flash——同一家族或兼容架构。
如果 EXECUTIVE 换成 Llama 3 或 Claude 呢？MEMORY 的输出生成方式（token 分布、特殊 token 使用）是否还能被正确理解？论文没有做这个消融。真正的「跨 LLM」可迁移需要验证：用一个在 Qwen 上训练的 MEMORY，去服务一个 Llama EXECUTIVE，看性能是否保持。
关于模型合并的精度损失
主文提到 TIES 合并后 NarrativeQA 从 26.85% 掉到 15.81%，跌了 11 个点。论文说这是「可接受的 trade-off」，但这个跌幅实际上是回到 1.5B MEMORY 模型的水平（1.5B 单独训练是 24.00%，合并后 15.81% 反而更低）。
这意味着合并后的 MEMORY 不如直接用小模型重训。如果持续更新是核心需求，用户面临的选择可能是：
- 每次完全重训（精度高，但计算量 Θ(K²)）
- 模型合并（计算量 Θ(K)，但精度可能不如小模型重训）
- 小模型频繁重训（精度中等，计算量 Θ(K)）
一个被低估的设计：实体浮现（步骤 4）
主文提到步骤 4 缓解逆转诅咒，但没有展开。逆转诅咒是 LLM 的深层病理：模型能答「奥巴马是美国总统」，但问「谁是美国总统」时答不出来——因为训练数据中前者出现频率远高于后者，模型的知识是单向的。
MEMO 的步骤 4 专门生成「答案揭示实体身份」的 QA 对。比如问题设计为「第 44 任美国总统是谁？」答案是「巴拉克·奥巴马」。这强制模型把「总统职位」和「奥巴马」做双向关联。这个设计很细，但可能是最接近「根治逆转诅咒」的方法之一。
不过论文没有定量测量逆转诅咒的缓解程度——如果做了这个实验，会更有说服力。
EvoAgentX 的视角
这篇论文的架构设计（双模型分工、持续更新、模块化）跟几天前解读的 EvoAgentX 框架有呼应。EvoAgentX 强调 Agent 系统应该自我进化，MEMO 则展示了一个具体实现：MEMORY 模块可以被持续训练、合并、替换，而不影响 EXECUTIVE 的稳定性。
如果把 MEMO 放进 EvoAgentX 的框架里，MEMORY 模型的训练/合并/更新正好对应「Optimiser」组件——它根据环境反馈（新文档、新任务）更新 Agent 系统的一个子模块。这验证了 EvoAgentX 框架的实用性：MEMO 是其框架在大规模知识管理场景下的一个实例化。
#MEMO #补充视角 #千寻