异质任务下的记忆提取：为什么单一Prompt就是搞不定，得"先聚类再演化"
一个被低估的工程现实
如果你正在给一个 LLM 助手做长期记忆模块，大概率会遇到这样一个让人头秃的局面：
刚开始你接的是一个偏个性化的场景，记住"用户是软件工程师、过敏海鲜、喜欢看科幻片"就够用了。然后产品要扩展到 Agent 任务，让它去操作环境、调工具——这下记忆系统得开始记"上次开门要先 pickup 钥匙"这类操作经验。再后来又要支持解题场景，记忆又得变成"这类组合数学问题先枚举上界再剪枝"。
你换了一波又一波 extraction prompt。Mem0 那种偏 personal facts 的写法在闲聊里很顶，但放到 AlfWorld 这种多轮 Agent trajectory 上就拉垮；ReasoningBank 那种侧重 strategies/lessons 的写法在 Agent 任务上跑得不错，但塞给一个聊用户偏好的对话又写一堆"成功是因为你认真对待用户"这种水话。
说到底，"该记什么"这件事不是一个 prompt 能搞定的——但所有 self-evolving 的 prompt optimization 框架（GEPA、ACE、MemEvolve），都默认任务分布是同质的。
USC 这篇刚挂出来的工作，把这个被忽视的问题正面拎出来：先证明了它确实是个问题（建了一个跨 18 个数据集的异构基准 BEHEMOTH），再提出了一个挺直觉但工程意义很大的方法——CluE（Cluster-based Evolution）：把训练样本按"提取场景"聚类，每个 cluster 独立分析，最后跨 cluster 综合出一个新 prompt。
效果：相对 Simple baseline 拿到 +9.04% 的总体 relative gain，而且是同时在三个类别都涨（personalization +12.34%、problem-solving +8.39%、agentic +7.22%）。同期对比的三个 self-evolving 框架，几乎都有"东边涨西边掉"的问题。
更狠的一点：当从一个已经很强的种子 prompt（Survey）出发时，ACE、MemEvolve、GEPA 全部出现负增长——也就是说，盲目演化反而把好东西改坏了。CluE 在这个设置下还能继续涨 +6.54%。
这篇论文我读完最大的感受是：它不是在卷某个 SOTA 数字，而是把一个长期被 sweep under the rug 的问题摆到台面上——当 prompt optimization 框架遇到异质任务时，所有人之前的那种"一个大 batch 喂进去让 LLM 反思"的范式，是有结构性缺陷的。
论文信息
- 标题：Self-Evolving LLM Memory Extraction Across Heterogeneous Tasks
- 作者：Yuqing Yang, Tengxiao Liu, Wang Bill Zhu, Taiwei Shi, Linxin Song, Robin Jia
- 机构：南加州大学（USC）、加州大学圣塔芭芭拉分校（UCSB）
- arXiv：2604.11610
- 代码：github.com/ayyyq/heterogeneous-memory-extraction
这个问题为什么不是个伪命题
先承认一点，我刚看到 abstract 时是有点警觉的——"异构任务"听起来很大，但容易做成一个把一堆 benchmark 揉到一起，然后"我们的方法平均最好"的那种灌水文。
但读到 Figure 1 那张图，我觉得这件事还是站得住脚的。
图1：异质记忆提取的核心场景示意——一个通用助手必须在不同性质的过往对话上提取出形态完全不同的记忆，并在新对话中正确调用它们
注意图里有个细节挺关键：评估方式不是用 LLM-as-Judge 看记忆"质量好不好"，而是把提取出来的记忆当作 context 喂给下游模型 \(\mathrm{LLM}_g\)，看它在 target query 上的回答 reward。这是一个 utility-driven 评估，绕开了 LLM Judge 的偏差和方差问题——这是这篇论文方法论上一个值得抄作业的设计。
形式化地说，给定 source conversation \(c\)、extraction prompt \(P\)、target query \(q\) 和 reward function \(R\)：
整个 pipeline 把"提取"和"管理/检索/合并"做了正交分解，每次只评估单步提取的效果。这个 setup 的好处是评估稳定、controllable，缺点是和真实部署的连续记忆累积场景有一定 gap——这点作者后面也专门做了一组 continual 实验来回应。
那为什么"同一个 prompt 通吃"行不通？作者用 Table 1 给了一组直接的反例：
| 方法 | Personalization MA | Problem-Solving MA | Agentic MA | Overall MA |
|---|---|---|---|---|
| No Memory | 34.15 | 46.52 | 30.36 | 37.84 |
| Simple | 58.76 | 48.76 | 32.46 | 46.00 |
| Mem0（聚焦 personal facts） | 73.31 | 45.97 | 31.62 | 48.48 |
| ReasoningBank（聚焦 strategies/lessons） | 50.67 | 50.72 | 32.12 | 44.51 |
| OpenMemory（5类 taxonomy） | 57.39 | 50.47 | 34.93 | 47.14 |
| Survey（2类 taxonomy） | 62.05 | 49.86 | 33.58 | 47.69 |
看几个特别扎眼的数：
- Mem0 在 personalization 上飙到 73.31（比 Simple 高出近 15 个点），但放到 Problem-Solving 直接掉到 45.97，比 No Memory 还低——也就是说，错误的记忆类型不是"没用"，而是"有害"。
- ReasoningBank 在 personalization 上从 58.76 跌到 50.67，相对 Simple 是 -10.78%。用错记忆类型，跌幅可以接近两位数。
- OpenMemory 五类比 Survey 两类更细，但反而没赢——粒度更细 ≠ 提取质量更好。
这个表把"为什么需要自演化"这件事直接讲清楚了：手工写 prompt 在异质任务下注定是顾此失彼。
BEHEMOTH：18 个数据集，三个类别，不预设标签
要研究这个问题，先得有合适的 benchmark。作者把 18 个现成的数据集重组成统一的 (source conversation, target query, reward function) 三元组形式，覆盖三大类：
图2：BEHEMOTH 的数据集组成——三大类共 18 个 benchmark，从分层覆盖了从聊天偏好到工具调用、从数学推理到代码生成的完整谱系
注意一个细节：每类挑了一个数据集 hold out 不参与训练——LongMemEval（个性化）、GPQA-Diamond（解题）、ToolBench（Agent）。这是为了测 self-evolving prompt 在 OOD 上的迁移性，避免"只在训练分布上看起来很好"的假象。
更重要的是作者强调了一个常被忽略的点：类别不决定该提取什么。
举几个例子： - 同一个 Agent trajectory 类别下，成功的 trajectory 应该提取"可复用 strategy"，失败的应该提取"避坑 lesson"——同类不同处理。 - 跨类别看，从 personalization 对话里提取"用户的领域知识"，和从 problem-solving 里提取"领域知识"，说到底是同一种提取行为——异类同处理。
也就是说，真正决定该提取什么的，不是 dataset 标签，而是"提取场景"本身。这是后面 CluE 设计的核心动机——按"提取场景"聚类，而不是按数据集分组。这一点我觉得是这篇论文最聪明的地方。
CluE：先聚类，再演化
为什么不能直接套现有自演化框架？
来看看竞品的处理方式有什么问题：
GEPA（Agrawal 2025）：一个反思性 Proposer，每次拿当前 prompt + 一小批 (5 个) training log，让 LLM 反思后产出新 prompt。问题：上下文长度有限，每个 batch 偏向最近的样本——所以 GEPA 在 agentic 上能涨 +14.08%，但 personalization 直接掉 -2.16%，明显是被最后几批 trajectory 数据拉偏了。
ACE（Zhang 2025d）：一个 Reflector + 一个 Curator。Reflector 标记规则是 helpful/harmful，Curator 累计计数后做原子操作（add/update/delete）。问题：在线串行学习，跑一轮要 12.4h，最慢；而且加规则远多于删规则，最终 prompt 膨胀到 1403 tokens（CluE 是 936），过度详细反而削弱模型的指令遵循。
MemEvolve（Zhang 2025c）：一个 tool-augmented Analyzer + 一个 Proposer，能处理大批量 (35 个) 样本。问题：分析时把跨任务的 feedback 一锅炖，异质信号互相对消，最后产出的 prompt 没有 memory taxonomy，只剩下一堆"不要做 X"的 penalty 子句。
作者把这个困境总结得很到位：
更新太频繁 → 不稳定，相邻 batch 的异类样本把 prompt 往相反方向拽；更新太稀疏 → 信号被稀释，不同任务的反馈互相抵消。
CluE 的四步流程
CluE 沿用了 MemEvolve 的 Analyzer-Proposer 架构，但在中间加了按"提取场景"聚类这一步。一个演化轮次（round）走四步：
图3：CluE 的四阶段流程——Summarizer → Cluster Manager → Cluster Analyzer → Proposer
具体来说：
1. Summarization（摘要）
对 batch 里每个样本，让 Summarizer 读它的 log（source conversation + extracted memory + target conversation + reward），写一段 2-3 句的摘要，只描述提取场景而不是任务表面。比如"需要从冗长对话里提取过程性知识"，而不是"AlfWorld 里的开门任务"。
这一步是为了把 dataset name、具体内容这些表面特征剥离掉，只留下提取行为本身的特征——什么类型的信息、提取难点在哪。
2. Clustering（聚类）
Cluster Manager 拿到 batch 的所有摘要，加上之前轮次保留下来的 cluster 标签和描述，重新分配 cluster。它可以新建、合并、拆分 cluster，但要求每个 cluster 至少 2 个样本。Cluster 数量上限是 7。
注意一个细节：聚类用的是 LLM 而不是传统的 embedding+kmeans。这样 cluster 边界可以根据自然语言的语义动态调整——"从冗长对话提取过程性知识"这个 cluster 在不同轮次可以吸收来自 AlfWorld（agent）和数学题逐步解答（problem-solving）的样本。
3. Cluster-based Analysis（聚类内分析）
每个 cluster 由一个 Cluster Analyzer 独立分析，只看本 cluster 内的样本。它用 tool calling 拉取这些样本的 log，识别出该 cluster 的成功模式（什么样的记忆对该场景有用）和失败模式（缺了什么、太具体/太抽象）。
这是 CluE 和 MemEvolve 的核心差异：MemEvolve 是把 35 个样本一锅分析，异质信号在 LLM 的 context 里互相干扰；CluE 把它们按场景拆开，每个 cluster 内的信号是同质的，分析的结论自然就更尖锐。
4. Cross-cluster Proposal（跨聚类综合）
最后所有 cluster 的分析报告喂给 Proposer，让它综合而不是串联。具体要求：识别多个 cluster 共有的 general guidelines、把 cluster-specific insight 组织成 memory taxonomy、解决冲突时把规则按 memory category 隔离（而不是强制一条统一规则）。
这一步产出的 prompt 是 targeted modifications，不是全量重写。
一个我特别欣赏的设计
Cluster 数和 taxonomy 的 category 数不是一一对应的。论文给的例子：从 Simple 演化出来的最终 prompt，4 个 cluster 产出了 5 个 taxonomy section——其中"User Preferences and Emotional Context (with Translation)"这个 cluster 被拆成了 taxonomy 里的 "User Preferences & Emotional Context" 和 "Translation & Stylistic Requirements" 两个独立 section。
这个解耦让 cluster 的演化和 taxonomy 的组织各自服务自己的目标——cluster 是为了让分析阶段信号干净，taxonomy 是为了让最终 prompt 表达清晰，两件事不该绑死。
实验结果：从两个 seed 看演化稳定性
Seed = Simple（弱起点）
这是 main result，所有方法从一个最简单的 prompt 开始演化：
| 方法 | Personalization | Problem-Solving | Agentic | Overall |
|---|---|---|---|---|
| Simple | 58.76 / 0% | 48.76 / 0% | 32.46 / 0% | 46.00 / 0% |
| GEPA | 56.59 / -2.16% | 50.05 / +2.86% | 37.23 / +14.08% | 47.52 / +5.06% |
| ACE | 53.73 / -4.38% | 51.04 / +8.04% | 33.49 / +4.93% | 45.91 / +3.56% |
| MemEvolve | 63.67 / +10.76% | 49.49 / +1.17% | 30.92 / -3.25% | 47.08 / +2.11% |
| CluE | 65.72 / +12.34% | 51.85 / +8.39% | 35.24 / +7.22% | 50.01 / +9.04% |
读这个表的时候，请注意几个我觉得有意思的细节：
- GEPA 和 ACE 在 personalization 上是负增长——演化反而比 Simple 还差。这就是前面说的"被最近 batch 拉偏"现象。
- MemEvolve 在 agentic 上 -3.25%——它的"大 batch 一锅炖"机制让 agentic 的细节信号被 personalization 和 problem-solving 的信号洗掉了。
- CluE 是唯一一个三个类别全部正增长的方法——这才是"通用记忆提取系统"该有的样子。
OOD 上也是同样的结论：
| 方法 | LongMemEval | GPQA-D | ToolBench |
|---|---|---|---|
| Simple | 46.02 | 47.14±4.15 | 25.30 |
| GEPA | 35.06 | 50.00±0.82 | 24.09 ↓ |
| ACE | 29.71 | 46.13 ↓ | 26.82 |
| MemEvolve | 56.82 | 47.98±1.09 | 26.67 |
| CluE | 63.07 | 48.48±1.80 | 26.67 |
CluE 在 LongMemEval 上 63.07 vs MemEvolve 56.82——这个差距不小，6.25 个绝对点。而 GEPA 在 ToolBench 退化、ACE 在 GPQA-Diamond 退化，再次印证"演化不当反而有害"。
Seed = Survey（强起点，残酷测试）
这一组实验我觉得是这篇论文最有杀伤力的部分。Survey 是 Table 1 里 overall 第二好的 prompt（47.69 MA），从这里起步意味着已经没多少便宜可占，但很容易把现成的好东西改坏。
| 方法 | Personalization | Problem-Solving | Agentic | Overall |
|---|---|---|---|---|
| Survey | 62.05 / 0% | 49.86 / 0% | 33.58 / 0% | 47.69 / 0% |
| GEPA† | 62.05 / 0% | 49.86 / 0% | 33.58 / 0% | 47.69 / 0% |
| ACE | 54.80 / -10.48% | 50.06 / +0.75% | 34.41 / +3.69% | 46.11 / -1.44% |
| MemEvolve | 62.88 / -0.31% | 51.22 / +2.51% | 31.34 / -4.85% | 47.70 / -0.74% |
| CluE | 70.67 / +13.62% | 51.63 / +2.68% | 34.69 / +5.79% | 51.06 / +6.54% |
†GEPA 跑完后找不到一个比 Survey 更好的 prompt，干脆原样退回——这本身就是个失败信号。
ACE 把 personalization 砍掉 10.48% 才换来 problem-solving 0.75% 的微薄涨幅。MemEvolve 在 agentic 上掉 4.85%。两个方法的 overall 都是负的。
只有 CluE 在三个类别上都涨，overall +6.54%。论文用一个挺到位的句子总结：
一个更强的 seed 意味着更少的提升空间，但更多的破坏空间。
CluE 之所以能做到"既能找到剩余空间，又不破坏现有优点"，说到底是因为它的更新是 per-cluster targeted 的——每个 cluster 内部的反思只针对那个场景，不会影响别的场景。这是 cluster-based 设计的一个很自然的副产品。
一张图看清四个框架的演化结果
CluE 的四个 cluster 最终演化出了 5 个 memory taxonomy section（Factual Data & Temporal Disambiguation / User Preferences & Emotional Context / Procedural & Technical Knowledge / Logical & Combinatorial Reasoning / Translation & Stylistic Requirements）。从 prompt 的结构上能直观看出 CluE、GEPA、MemEvolve 的根本差异：
图4：三个框架的演化结果对比——CluE 长出了结构化的 taxonomy，GEPA 把 AlfWorld 的具体语法烧进 prompt，MemEvolve 退化成一堆 "不要做 X" 的禁令
特别值得注意 GEPA 的 prompt 里出现了 go to <object> <id> 这种 AlfWorld 专属的导航语法——这就是 GEPA 在 agentic 上涨 14% 但 personalization 跌 2% 的根本原因：它的 prompt 已经被特定 domain 锚死了。
而 MemEvolve 的 prompt 主要是 penalty clause（"不要做 X"），缺少正向的 taxonomy 和 guideline。这说明它的"大 batch 一锅分析"主要能识别"哪些做法明显有害"，但难以归纳出"哪些做法明确有用"——因为后者需要按场景区分，而它没有这个机制。
CluE 长成结构化的 taxonomy，是因为聚类阶段已经把同类信号分组好了，Proposer 综合时自然能产出 well-organized 的输出。
单步提取的结论能迁移到连续场景吗？
这是我读这篇论文时最关心的一个问题——主实验都是 single-step 的（每个样本独立评估），但真实部署都是 continual 的（对话流式到来，提取出的记忆要不断累积，新提取要在已有记忆增强的 context 上做）。两者之间会有 gap 吗？
作者在 Game of 24 和 AlfWorld 这两个场景上做了对照：
| 设置 | Game of 24 (Single-Step) | Game of 24 (Continual) | AlfWorld (Single-Step) | AlfWorld (Continual) |
|---|---|---|---|---|
| No Memory | 26.67±3.86 | 35.42±5.03 | 30.41±2.71 | 63.74±0.41 |
| Simple | 27.92±3.86 | 29.58±3.12 | 47.66±2.19 | 64.91±5.01 |
| MemEvolve | 27.50±2.70 | 43.33±3.58 | 40.64±0.41 | 62.57±2.30 |
| CluE | 37.08±2.12 | 50.83±7.52 | 55.85±3.23 | 67.25±2.98 |
读这个表有几个值得停一下的点：
- Game of 24 在 continual 设置下，Simple prompt（29.58）反而比 No Memory（35.42）更差——这是因为低质量的记忆累积起来会"污染"context，越积越糟。这个现象坦率讲挺反直觉，但很有警示意义：记忆系统不是"加上就好"，差的记忆有负面 compound 效应。
- AlfWorld 在 continual 下 No Memory 是 63.74，Simple 是 64.91——几乎没差。这说明 Simple 提取出的记忆在多轮累积下没起到正向效果。
- CluE 在两种设置下都稳定领先，特别是 Game of 24 continual 50.83 vs MemEvolve 43.33（+7.5 个绝对点），说明 single-step 的优化结论能迁移。
不过我觉得这块也有需要诚实承认的局限——作者自己也明确点了：CluE 的 prompt 是在 single-step 下演化的，但 continual 场景下提取模型要处理"已经包含 retrieved memory 的 context"，这种 distribution shift 没有被显式优化进 prompt。直接在 continual + heterogeneous 双重 setting 下做演化，是个 future work。
计算开销：贵了多少？
这个领域的 self-evolving 方法有个老问题——为了优化 prompt，可能要烧大量 LLM call。看下作者的 efficiency 对比：
| 方法 | Wall Time | Optimization LLM Calls | Eval Calls |
|---|---|---|---|
| GEPA | ~7.4h | 46 | 1,645 |
| ACE | ~12.4h | 610 | 1,120 |
| MemEvolve | ~5.0h | 30 | 1,150 |
| CluE | ~5.5h | 221 | 1,150 |
CluE 比 MemEvolve 多出来的 0.5h 主要是因为多了 per-example summarization 和 per-cluster analysis 两个步骤（30 → 221 个 optimization call）。但总时间还是比 GEPA 和 ACE 短。
我自己的判断：221 个 optimization call 这个规模在工业部署里完全可接受，关键是它不需要在 eval call 上做更多——eval 是 1150 次，和 MemEvolve 持平。所以在真实场景里，CluE 的"贵"主要贵在 optimization LLM 上（这块用 cheap model 替换的成本下降空间很大），而不在 eval LLM 上（这是真用户场景里更敏感的部分）。
我的判断：这篇论文真正值钱的几个地方
第一：把"异质任务"问题正面化了
之前 self-evolving prompt optimization 这一支（APE、OPRO、GEPA、ACE、MemEvolve）几乎都默认任务是同质的，benchmark 也都是单 task 内的。这篇是第一次把"跨任务异质性"当作 first-class problem 来设定——这件事的重要性可能被低估了，因为真实部署的 LLM 助手就是天然异质的。一个 ChatGPT 用户今天问菜谱、明天问代码、后天问数学，如果我们的记忆/prompt 优化框架都假设它们是同质的，那线上效果跟 benchmark 上的 SOTA 注定有 gap。
第二：cluster-based 这个想法不限于 prompt 演化
这套"先聚类再分析"的范式可以迁移到很多地方： - Routing 系统：根据 query 类型路由到不同的子模型/sub-prompt——其实 CluE 的 memory taxonomy 就是一种 implicit routing。 - 数据合成：合成训练数据时按场景聚类后再生成，避免一锅炖产生的同质化。 - Eval 设计：评估时按场景聚类报告分数，而不是只看 macro average，能更早发现"东边涨西边掉"的问题。
第三：诚实承认了 single-step → continual 的 gap
这点我特别欣赏——很多论文为了 sell story 会刻意 downplay 自己的局限。这篇明确说了 single-step 演化的 prompt 在 continual 设置下没有显式优化，并把 continual+heterogeneous 列为 future work。这种诚实让人愿意相信他们 reported 的数字。
几个我觉得不那么 strong 的地方
+9.04% 这个数听起来不算特别炸。如果你期待的是 +30% 这种"颠覆式"提升，那 CluE 给不出来——它更像是"把不稳定的方法变稳定"，而不是"把弱方法变强"。但反过来想，这恰恰是 prompt optimization 这一支的天花板特征——能在异质任务上稳定 +9% 而不是某些类别 +14% / 某些类别 -3%，已经是很有工程价值的事。
对比的 baseline 都还很新（GEPA 2025年7月、ACE 2025年10月、MemEvolve 2025年12月）——也就是说 CluE 是和"还在快速迭代中的方法"在比。一年后这些方法可能各自都改进了 cluster-based 的思想，那时候 CluE 的相对优势可能会缩小。但这恰恰是 cluster-based 范式的胜利——好的 idea 会被吸收成 community standard。
Cluster 数和质量依赖 LLM 的 clustering 能力。如果换一个比 Qwen3-32B 弱的 extraction backend，cluster 的质量会不会显著掉？文章的 Gemini-3-Flash 实验显示 CluE 总体相对增益从 +9.04% 缩到 +3.40%（agentic 还掉了 -5.93%）——也就是说，当 backend 更强、Simple baseline 已经很高时，演化空间被压缩，cluster-based 的优势也会被削弱。这个 finding 论文里点了，但我觉得还可以挖得更深。
工程落地我会怎么用
如果你正在做以下任意一件事，CluE 这套思路可能直接有用：
- 多场景通用助手的记忆系统：别再写一个全局 extraction prompt 了。先把你的训练数据按"提取场景"（不是按业务标签）做粗分类，每类独立训一套 sub-prompt，最后用一个 routing 层动态选。如果嫌训练麻烦，至少可以把 CluE 演化出的那个最终 prompt（5 个 taxonomy section）当 starting point。
- Agent skill bank 的设计：很多 agent 框架都把 skill 按 domain 组织（每个工具一个 skill），但其实更合理的是按 extraction scenario 组织——同一个 domain 里成功的 trajectory 该提取 reusable strategy，失败的该提取 lesson，这是两种完全不同的 skill，应该独立编排。
- Prompt 优化迭代流程：如果你正在做 GEPA / ACE / MemEvolve 那种"产 prompt → 评估 → 反思更新"的 loop，强烈建议在 reflect 阶段前加一步"按场景聚类"。哪怕是用 embedding kmeans 这种 cheap 的方法，效果可能就比一锅分析强很多。
最后留一个开放问题——这篇论文做的是"记忆该提取什么"这一步，但记忆系统的完整 lifecycle 还包含 storage、retrieval、management。如果这三个环节都按"场景"做 cluster-aware 设计（比如不同场景的记忆走不同的 retrieval 策略，user preference 走 entity graph、procedural knowledge 走 vector top-k），整个系统可能还有更大的提升空间。这是个值得做的方向。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我