MemSifter：用4B小模型给大模型当"记忆管家"，检索又快又准
一句话总结：MemSifter训练一个4B参数的代理模型，通过"先推理再检索"的方式，替大模型从海量历史对话中筛选相关记忆，速度比全上下文方案快12倍，效果还更好。
论文标题：MemSifter: Offloading LLM Memory Retrieval via Outcome-Driven Proxy Reasoning
论文链接：https://arxiv.org/abs/2603.03379
作者：Jiejun Tan, Zhicheng Dou, Liancheng Zhang, Yuyang Hu, Yiruo Cheng, Ji-Rong Wen（中国人民大学高瓴人工智能学院）
1. 这篇论文要解决什么问题？
假设你有一个AI助手，跟它聊了几个月，积累了上百轮对话。现在你问它："上次我提到的那个慈善活动的时间地点是什么？"这个问题看似简单，实际上难倒了绝大多数现有系统。
核心矛盾在于：LLM的长期记忆管理是一个尚未被很好解决的工程和算法问题。
目前主流方案有三种，每种都有明显的短板：
第一种：全部塞进上下文窗口。随着Gemini、GPT-4o等模型把上下文长度推到128K甚至1M token，一个自然的想法是——把所有历史对话直接拼进prompt。但这带来两个严重问题：（1）推理延迟随上下文长度线性甚至超线性增长，128K上下文的一次推理可能要50秒；（2）"大海捞针"效应——当无关信息太多时，模型反而更容易忽略关键信息，回答质量下降。
第二种：嵌入向量检索（如BGE-M3）。把历史对话编码成向量，用余弦相似度检索。速度快，但语义理解太浅。当用户问"上次那个活动"时，嵌入模型很难理解"那个"指代什么，检索命中率不高。
第三种：记忆管理框架（如Mem0、HippoRAG）。构建知识图谱或结构化记忆存储。这类方法在提取和组织信息时会引入信息损失，而且在记忆量大时维护成本高。
MemSifter的思路很直接：让一个小模型（4B参数）专门负责记忆检索，它先思考当前任务需要什么信息，再从历史会话中排序筛选。关键创新是——用大模型的实际任务表现作为奖励信号来训练这个小模型，而不是依赖人工标注的检索标签。
这个思路带来的好处是三重的：小模型推理成本低（延迟约4秒 vs 全上下文50秒）；"先思考再检索"比纯向量匹配理解更深；用实际任务结果训练比用检索标签训练对齐度更高。
2. 方法：MemSifter是怎么做的？
2.1 问题定义
先明确几个角色。工作LLM（Working LLM, M）负责处理用户的实际任务。记忆库（Memory Bank）存储所有历史交互记录\(H\)。代理模型（Proxy Model, P）负责从记忆库中检索与当前任务\(q\)相关的记忆片段\(M_{rel}\)。
整个流程：用户提出任务\(q\) → 代理模型P从H中检索\(M_{rel}\) → 工作LLM基于\(q\)和\(M_{rel}\)生成回答\(a\)。
目标是最大化工作LLM的回答质量，而代理模型的检索质量直接决定了这一点。
2.2 记忆代理推理流水线
MemSifter的推理流程分三个阶段。下面结合框架图逐一拆解。
阶段一：预处理——会话切分
原始历史记录\(H\)是一长串多轮对话。预处理步骤将其按话题连续性切分为独立会话（session），每个会话分配唯一标识符<session id>。切分策略依据话题的转换点，确保同一话题的对话不会被人为拆开。
这步的意义在于：后续的检索和排序都以session为粒度进行，而非单条消息。这既降低了排序复杂度，又保留了对话的上下文完整性。
阶段二：粗筛——嵌入预过滤
当历史记录太长（超过代理模型的上下文窗口128K）时，不能把所有session都送进代理模型。MemSifter在这一步用轻量级嵌入模型BGE-M3做粗粒度的预过滤——计算每个session与当前任务的嵌入相似度，保留前K个session。
论文声称这一步的信息损失不到1%。这个数字是怎么来的？他们在实验中对比了有无粗筛的检索效果，发现在绝大多数情况下，被过滤掉的session确实与当前任务无关。粗筛的作用是"去掉明显不相关的"，把精细筛选的工作留给代理模型。
注意，只有当历史记录超出代理模型上下文窗口时才启用粗筛。对于128K以内的历史记录，直接跳过这一步。
阶段三：Think-and-Rank——先推理后排序
这是MemSifter的核心环节。代理模型接收所有候选session和当前任务，输出格式为：
<think>
分析当前任务需要什么信息...
Session 27涉及慈善活动讨论，可能相关...
Session 15提到了活动地点...
</think>
<ranking>27, 15, 34, 5, ...</ranking>
<think>标签内是推理过程，代理模型在这里分析当前任务与各session的关联性。<ranking>标签内是排序结果，按相关性从高到低排列session ID。
这种"先思考再检索"的设计，与纯向量检索的本质区别在于——代理模型可以进行多步推理。比如用户问"上次那个活动的地点"，代理模型可以先推理"用户指的可能是最近讨论过的某个具体活动"，再去匹配相关session。向量检索只能做单步语义匹配，处理不了这种需要推理的间接引用。
排序完成后，取top-k个session作为\(M_{rel}\)，拼接到当前任务前面，送给工作LLM。
2.3 结果驱动的强化学习训练
模型架构和推理流程讲清楚了，最关键的问题来了：怎么训练这个代理模型？
传统做法是用人工标注的检索标签（哪些session是相关的）来做监督学习。但这个方法有两个问题：（1）标注成本高，尤其是长历史记录场景；（2）标注标准和实际任务需求不一定对齐——标注员认为"相关"的session，不一定是工作LLM真正需要的。
MemSifter的做法彻底不同：用工作LLM的实际回答质量作为奖励信号。具体来说，代理模型检索出一组session后，把这些session送给工作LLM回答问题，然后用评估器（如DeepSeek V3.2）对回答质量打分。这个分数就是训练代理模型的奖励信号。
这就是论文标题中"Outcome-Driven"（结果驱动）的含义——不看你检索对不对，看你检索的东西有没有真正帮到大模型回答好问题。
训练算法采用GRPO（Group Relative Policy Optimization，组相对策略优化）。GRPO是PPO的一个变体，核心思想是：对同一个任务采样多个输出（论文中n=6），计算它们各自的奖励，然后用组内相对排名来计算优势函数，而不是训练一个单独的价值网络。这降低了训练复杂度。
2.3.1 边际效用奖励
奖励函数的设计是MemSifter最精妙的部分。
直觉很简单：一次好的检索，应该让工作LLM的回答质量显著提升。所以我们需要衡量的是——检索出的记忆相比"没有记忆"时带来了多大的边际提升。
具体实现如下图所示：
假设代理模型输出了一个排序列表，MemSifter按Fibonacci序列\(\{1, 2, 3, 5, 8, ...\}\)选取检查点。对于每个检查点\(k_n\)，取排序列表的前\(k_n\)个session，拼接到任务中让工作LLM回答，得到评分\(s_{k_n}\)。同时，不给任何记忆让工作LLM回答同一个问题，得到基线分\(s_0\)。
为什么用Fibonacci序列而不是每加一个session就评估一次？因为工作LLM的推理成本很高。如果排序列表有50个session，每加一个都要调用一次工作LLM，训练成本会爆炸。Fibonacci序列\(\{1, 2, 3, 5, 8\}\)只需要6次调用（包括基线），就能大致描绘出"随着记忆增加，回答质量如何变化"的曲线。
最终的答案奖励公式为：
其中权重\(w_n\)的计算受到信息检索中DCG（Discounted Cumulative Gain）的启发：
这个权重设计的含义：排名越靠前的session，权重越大。下图直观地展示了权重的衰减趋势：
\(w_1 = 0.3691\)，\(w_2 = 0.1309\)，\(w_3 = 0.1131\)，\(w_5 = 0.0714\)，\(w_8 = 0.0528\)。排名第1的session权重是排名第8的7倍。这个设计鼓励代理模型把最相关的session排到最前面——因为排在前面的session对奖励的贡献远大于排在后面的。
再看公式中的\(-s_0\)项。它的作用是减去基线分。如果一个问题不需要记忆就能回答好（\(s_0\)很高），那即使检索结果也得了高分，最终的奖励也不会很大。只有当记忆真正带来了边际提升时，奖励才会显著为正。这防止了代理模型在"简单问题"上获得虚假的高奖励。
2.3.2 训练稳定性策略
纯RL训练容易不稳定。MemSifter采用了三个策略来保持训练过程的稳定：
热身阶段（Warm-up）：总奖励\(R = \alpha \cdot R_{ans} + \beta \cdot R_{ret}\)，其中\(R_{ret}\)是基于传统检索指标（DCG）的辅助奖励。训练初期\(\beta\)较大，提供方向性引导；随着训练推进，\(\beta\)逐渐衰减到0，让模型完全由结果驱动的奖励主导。这就像先给学生一本参考答案让他入门，等他有了基础判断力后再收走参考答案。
课程学习（Curriculum Learning）：设置锚点分数\(\tau = 0.2\)，动态选择难度接近这个阈值的训练样本。太简单的（基线分就很高）学不到东西，太难的（怎么检索都回答不好）容易产生噪声梯度。只有"努力一下能做好"的样本才是最有效的训练信号。
模型合并（Model Merging）：每个epoch结束后，取验证集上表现最好的top-k个checkpoint，用算术平均的方式合并参数，作为下一个epoch的初始化。这类似于集成学习的思路——单个checkpoint可能在某些样本上过拟合，但多个checkpoint的平均通常更加鲁棒。
训练配置方面：基座模型为Qwen3-4B-Thinking，输入上下文128K，输出窗口16K，4K缓冲区，batch size 32，GRPO采样数n=6，训练3个epoch，在8张H200 GPU上完成。工作LLM使用Qwen3-30B-A3B-Instruct提供奖励反馈。
3. 实验：MemSifter表现如何？
3.1 实验设置
数据集：8个数据集，涵盖不同的记忆检索场景和上下文长度——
- LoCoMo：长对话记忆数据集，在32K、128K和1M三个上下文长度上测试
- LongMemEval（128K）：长期记忆评估
- PersonaMem（128K）：个人画像记忆
- PerM-V2（128K）：个性化记忆V2版
- ZH4O（128K）：中文记忆数据集
- HotpotQA（128K）：多跳问答
- WebWalker（128K）：网页浏览记忆
- WebDancer（128K）：网页交互记忆
基线方法：
- 嵌入检索：BGE-M3、GemmaEmb
- 记忆管理：Nemori、Mem0、HippoRAG、A-MEM
- 生成式重排序：Rearank、ReasonRank
- 全上下文：DeepSeek-V3.2、Qwen3-30B（直接把全部历史塞进上下文窗口）
评估指标：F1分数，由DeepSeek V3.2或Qwen3-30B担任评估器。
3.2 主要结果
下表展示了以DeepSeek V3.2为评估器时各方法的F1分数：
| 方法 | LoCoMo 32K | LoCoMo 128K | LoCoMo 1M | LongMemEval | PersonaMem | PerM-V2 | ZH4O | HotpotQA | WebWalker | WebDancer |
|---|---|---|---|---|---|---|---|---|---|---|
| BGE-M3 | 29.57 | 25.67 | 22.56 | 20.27 | 12.87 | 19.19 | 37.60 | 19.98 | 23.39 | 26.59 |
| GemmaEmb | 30.61 | 26.28 | — | 17.72 | 14.38 | 20.30 | 40.41 | 20.14 | 23.18 | 27.41 |
| Nemori | 32.42 | 26.58 | — | 19.04 | 14.14 | 16.93 | 34.82 | 17.02 | 18.56 | 26.41 |
| Mem0 | 27.34 | 24.72 | — | 18.38 | 12.30 | 15.51 | 31.76 | 15.56 | 18.23 | 25.65 |
| HippoRAG | 31.26 | 25.90 | — | 13.38 | 16.23 | 18.74 | 34.06 | 14.41 | 19.69 | 21.91 |
| A-MEM | 28.97 | 23.53 | — | 15.93 | 12.27 | 16.58 | 31.72 | 15.00 | 18.42 | 24.01 |
| Rearank | 32.00 | 30.25 | 24.05 | 16.89 | 16.63 | 20.39 | 40.75 | 20.60 | 22.78 | 31.79 |
| ReasonRank | 34.49 | 30.17 | 25.55 | 18.36 | 16.08 | 21.30 | 39.38 | 20.41 | 24.15 | 30.78 |
| DS-V3.2全上下文 | 33.50 | 28.79 | — | 18.66 | 15.89 | 23.64 | 44.65 | 17.89 | 20.83 | 29.73 |
| MemSifter | 41.79 | 35.38 | 33.32 | 23.70 | 21.14 | 23.57 | 48.13 | 24.95 | 26.11 | 38.21 |
几个值得关注的数据点：
MemSifter在所有10个配置上都取得了最佳或接近最佳的成绩。这不是在某一两个数据集上好，而是全面碾压。
在LoCoMo 32K上，MemSifter（41.79）比第二名ReasonRank（34.49）高出21%。在128K和1M的长上下文场景下，优势更加明显——LoCoMo 1M上，MemSifter（33.32）比ReasonRank（25.55）高出30%。
在PersonaMem上，MemSifter（21.14）比第二名HippoRAG（16.23）高出30%。PersonaMem测试的是个人画像相关的记忆检索，对推理能力要求较高——需要理解"用户偏好"这类隐含信息。MemSifter的think-and-rank机制在这类任务上优势尤为明显。
在中文数据集ZH4O上，MemSifter（48.13）甚至超过了DeepSeek-V3.2全上下文方案（44.65）。这说明即使大模型能看到所有历史，也不如精准检索后再回答。信息过载确实会伤害模型的表现。
更关键的一点——MemSifter的训练数据主要来自LoCoMo和LongMemEval，但在PersonaMem、PerM-V2、ZH4O、HotpotQA、WebWalker、WebDancer这些未见过的数据集上也取得了最优成绩。这说明结果驱动训练学到的不是数据集特定的模式，而是通用的"记忆推理"能力。
以Qwen3-30B为评估器时，趋势基本一致：MemSifter在LoCoMo 1M上达到49.58，LongMemEval上26.45，PersonaMem上23.75，都是最高分。在个别数据集（如WebDancer=35.10）上不是绝对最优，但差距很小。
3.3 检索质量分析
F1分数衡量的是最终回答质量。那检索本身的质量如何？
| 方法 | LoCoMo NDCG@1 | LoCoMo NDCG@5 | LongMemEval NDCG@1 | LongMemEval NDCG@5 | PersonaMem NDCG@1 | PersonaMem NDCG@5 |
|---|---|---|---|---|---|---|
| BGE-M3 | 43.57 | 69.59 | 43.33 | 73.16 | 45.83 | 64.82 |
| ReasonRank | 47.64 | 71.46 | 60.67 | 80.72 | 40.00 | 66.53 |
| MemSifter | 70.00 | 78.11 | 67.33 | 89.67 | 60.00 | 75.63 |
MemSifter在NDCG@1上的表现差距惊人：LoCoMo上70.00 vs ReasonRank的47.64，提升了47%；PersonaMem上60.00 vs BGE-M3的45.83，提升了31%。
NDCG@1反映的是"排在第1位的session是否真的最相关"。MemSifter在这个指标上的巨大优势，验证了边际效用奖励中高权重\(w_1=0.3691\)的设计效果——训练确实教会了模型把最关键的session排到第一位。
3.4 消融实验
论文对MemSifter的各个组件做了详细的消融分析（以DeepSeek V3.2为评估器）：
| 消融配置 | LoCoMo 128K | LongMemEval | PersonaMem | PerM-V2 | ZH4O |
|---|---|---|---|---|---|
| MemSifter完整版 | 35.38 | 23.70 | 21.14 | 23.57 | 48.13 |
| 去掉结果驱动奖励 | 30.44 (-13.96%) | 17.12 (-27.77%) | 16.09 (-23.89%) | 20.22 (-14.21%) | 42.79 (-11.10%) |
| 去掉边际效用 | 33.83 (-4.38%) | 20.92 (-11.73%) | 18.77 (-11.21%) | 23.11 (-1.95%) | 44.27 (-8.02%) |
| 去掉奖励塑形 | 35.17 (-0.59%) | 23.26 (-1.86%) | 19.89 (-5.91%) | 23.53 (-0.18%) | 47.19 (-1.95%) |
结果驱动奖励是最关键的组件。去掉它（退回到纯检索标签训练）后，所有数据集都出现了显著下降，LongMemEval上降幅达27.77%。这直接证明了"以终为始"的训练范式确实比传统的检索标签训练好得多。
边际效用的贡献也不小，LongMemEval上去掉它损失11.73%。没有边际效用，奖励只考虑"检索了记忆后的绝对分数"，不减去基线分，这会导致模型在不需要记忆的简单问题上也获得高奖励，影响学习效率。
奖励塑形（热身阶段的辅助奖励\(R_{ret}\)）的影响相对最小，最大降幅5.91%。这说明模型在没有辅助引导的情况下，仅靠结果驱动奖励也能学到不错的策略，辅助奖励主要起锦上添花的作用。
3.5 效率分析
小模型做代理到底能省多少时间？
| 方法 | 模型参数量 | 延迟（ms） |
|---|---|---|
| BGE-M3 | 0.2B | 1015.05 |
| Rearank | 7B | 7657.52 |
| ReasonRank | 7B | 8322.83 |
| MemSifter | 4B | 3982.53 |
| DS-V3.2全上下文 | 632B | 49873.60 |
在WebDancer 128K数据集上，MemSifter的延迟为3982ms，约为4秒。对比来看：
- 比7B重排序模型（Rearank/ReasonRank）快约2倍
- 比DeepSeek-V3.2全上下文方案快约12.5倍
- 比BGE-M3嵌入检索慢约4倍，但质量远远超出
这个延迟在实际应用中是可以接受的。用户等4秒获得一个高质量回答，比等50秒获得一个可能被信息淹没的回答要好得多。而且4B模型的部署成本也远低于632B的模型。
3.6 训练动态
上图展示了训练过程中F1分数的变化。几个观察：
每个epoch都带来了显著提升。LoCoMo上，Epoch 1结束时约34分，Epoch 2约38分，Epoch 3约40分。LongMemEval上提升更加显著——从Epoch 1的约20分到Epoch 3的约32分。
epoch之间的跳跃（图中不同颜色的衔接处）对应的就是模型合并操作。合并后的模型作为新epoch的起点，通常比上一个epoch的终点稍高，说明模型合并确实有正向效果。
Rearank基线（灰色虚线）在两个数据集上都被快速超越。LoCoMo上训练不到一半epoch就超过了Rearank，LongMemEval上第一个epoch中期就超过了。
4. 与现有方法的对比分析
MemSifter在方法论上的独特性，可以从它和几类代表性方法的对比中看出：
vs 嵌入检索（BGE-M3、GemmaEmb）：嵌入检索是单步匹配——把query和document各编码一次，计算相似度。MemSifter是多步推理——代理模型可以在<think>阶段进行链式推理，理解间接引用和隐含需求。代价是延迟从1秒增加到4秒，但在所有数据集上都带来了巨大的质量提升。当历史量大且问题复杂时，这个trade-off非常值得。
vs 记忆管理框架（Mem0、HippoRAG、A-MEM）：这类方法在存储阶段就对信息做了加工——提取关键实体、构建知识图谱、生成记忆摘要等。问题在于，加工过程不可逆，如果加工时丢失了某个信息，后续检索时就再也找不回来。MemSifter直接操作原始会话记录，不做任何预加工，信息保真度更高。实验中MemSifter在PersonaMem上比HippoRAG高出30%（21.14 vs 16.23），在PerM-V2上比Mem0高出52%（23.57 vs 15.51）。
vs 生成式重排序（Rearank、ReasonRank）：这是与MemSifter最接近的一类方法。Rearank和ReasonRank也用LLM来做检索/排序，也有一定的推理能力。区别在于：（1）它们用7B模型，MemSifter用4B模型，延迟更低；（2）它们用检索标签训练，MemSifter用实际任务结果训练。消融实验表明，去掉结果驱动奖励后MemSifter的表现接近ReasonRank的水平，这直接证明了训练范式的差异才是核心。
vs 全上下文方案（DeepSeek-V3.2、Qwen3-30B）：把所有历史塞进上下文窗口，理论上信息最完整，但实际效果并不好。在ZH4O上，DS-V3.2全上下文方案得44.65分，MemSifter得48.13分。这说明"更多信息≠更好的回答"。当上下文中无关信息太多时，模型的注意力会被分散，反而不如只给它最相关的几个session。
5. 个人思考
5.1 "以终为始"的训练范式值得更广泛的应用
MemSifter最核心的贡献不是具体的架构设计，而是"用下游任务结果训练上游模块"的范式。传统的pipeline系统（检索→生成）中，每个模块用各自的指标训练——检索模块用NDCG，生成模块用BLEU/F1。但每个模块的局部最优不等于全局最优。
这个思路可以推广到很多场景：用最终SQL执行结果训练Text-to-SQL的schema选择模块；用最终代码通过率训练代码生成的plan选择模块；用最终对话满意度训练多轮对话的记忆选择模块。
当然，代价是训练成本更高（每个样本需要多次调用下游模型），但MemSifter通过Fibonacci采样等技巧把成本控制在了可接受范围内。
5.2 边际效用奖励的设计很有工程智慧
\(R_{ans} = -s_0 + \sum w_n \cdot s_{k_n}\)这个公式，把三个核心idea紧凑地编码在了一起：
- \(-s_0\)：只奖励真正的边际贡献，过滤掉"本来就简单"的虚假信号
- Fibonacci采样：用对数级的调用次数近似连续曲线，平衡精度和成本
- DCG权重：排名靠前的session获得更高权重，引导模型优先把最相关的排到前面
这三个设计单独看都不复杂，但组合在一起形成了一个自洽的奖励函数。尤其是Fibonacci采样的选择——它比等间隔采样更合理（前几个session的边际效用变化更大，需要更密的采样点），又比每个位置都采样节省了大量计算。
5.3 粗筛+精排的二级架构有工程启示
在实际部署中，用户的历史记录可能达到数百万token。MemSifter的BGE-M3粗筛→Qwen3-4B精排的二级架构，本质上是一个经典的recall-rerank pipeline。嵌入检索负责从百万token中快速缩小到128K的候选集，代理模型负责在候选集内精细排序。
这个架构在工程上很友好：BGE-M3是0.2B的轻量级模型，可以离线预计算嵌入；Qwen3-4B可以用vLLM等框架高效部署；两者的总延迟约5秒，远低于直接用大模型处理百万上下文。
但这里有一个隐患：论文声称粗筛的信息损失不到1%，这个结论在LoCoMo 1M上是成立的，但如果记忆库继续增长到10M、100M，嵌入检索的召回率是否还能保持？嵌入模型的语义理解能力是有限的，当记忆量极大且话题高度重叠时，粗筛阶段可能会误删关键session。未来可能需要更智能的粗筛策略，比如用小模型做两阶段粗筛。
5.4 局限性
论文自身也提到了一些局限：
训练成本：结果驱动训练需要反复调用工作LLM来计算奖励，8张H200训练3个epoch的成本不低。对于学术团队来说，这个代价是可以承受的；但如果要在更大规模的数据上训练或持续更新模型，成本可能成为瓶颈。
代理模型的上下文限制：Qwen3-4B-Thinking的上下文窗口为128K。当候选session超过128K时，必须依赖粗筛来截断。这意味着代理模型永远只能看到历史的一个子集，无法进行跨子集的全局推理。
评估器的bias：用DeepSeek V3.2或Qwen3-30B作为评估器来打分，这些模型本身的偏好会影响奖励信号。比如，如果评估器更偏好冗长的回答，训练出的代理模型可能倾向于检索更多session来支持冗长的回答，而非精准简洁的回答。论文中用了两个不同的评估器来交叉验证，一定程度上缓解了这个问题。
泛化性的边界：虽然MemSifter在未见数据集上泛化效果不错，但目前的测试场景都是"对话历史+问答"的形式。在其他记忆检索场景（如工具调用历史、代码编辑历史）中的表现尚不清楚。
6. 总结
MemSifter提出了一个巧妙的方案来解决LLM长期记忆检索问题：用4B参数的小模型做"记忆管家"，先推理再检索，用大模型的实际回答质量来训练小模型。在10个数据集上全面超越了现有方法，同时推理延迟仅为全上下文方案的1/12。
这篇论文的方法论贡献大于工程贡献。"结果驱动的代理训练"这个范式，可以迁移到任何"上游选择影响下游质量"的pipeline系统中。而边际效用奖励、Fibonacci采样、课程学习、模型合并等技术细节的组合，展示了如何在RL训练中平衡效果和成本。
对于需要处理长期交互历史的AI产品——无论是个人助手、客服系统还是代码编辑器——MemSifter的架构提供了一个实用的参考。用轻量级的专用模型替代大模型做记忆管理，既降低了成本，又提高了质量。这个思路有望成为未来LLM记忆系统的标配。