智能体记忆能否在模型升级后存活？记忆可移植性对照研究

智能体记忆能否在模型升级后存活？记忆可移植性对照研究

论文来源：arXiv:2609.05339v1

摘要

大语言模型驱动的智能体（Agent）普遍依赖外部记忆模块（RAG向量索引、记忆数据库）保存历史上下文、工具调用记录、任务知识。工程实践中经常发生基座模型版本升级：将同一个Agent后端从旧模型切换到新版基座模型。行业普遍存在一个未被充分验证的假设：已经构建好的向量记忆库可以直接复用于新版本大模型，无需重新嵌入（re‑embedding）。

本文开展严格受控对照实验，系统评估模型升级场景下记忆组件的可移植性。实验覆盖不同嵌入模型、不同基座LLM、多组任务数据集，量化记忆检索准确率、召回率、MRR、下游任务问答精度。实验结果表明：直接复用旧模型生成的向量记忆会带来显著性能衰减；即便嵌入模型保持不变，基座LLM本身的分布偏移也会破坏记忆‑推理匹配关系。本文给出可复现实验流程、评估指标、工程建议，为Agent系统版本迭代提供实测依据。

关键词：大模型智能体；Agent记忆；RAG；向量数据库；模型升级；记忆可移植性

1 引言

Agent系统架构通常做分层解耦：

工程迭代时典型操作：仅升级推理层的基座LLM，记忆层向量索引完全保留不改动。开发者默认：向量检索独立于基座LLM，旧索引可以直接给新模型使用。

本研究核心问题：

Q1：当推理基座模型升级，完全复用旧向量索引，下游任务性能下降幅度有多大？
Q2：性能衰减来源：是嵌入模型分布漂移？还是基座LLM与检索片段之间的匹配偏移？
Q3：哪些工程手段可以缓解记忆不可移植问题？完全重嵌入是否是唯一可靠方案？

现有RAG评测大多固定一套“嵌入模型+生成模型”配对；针对模型版本升级、组件解耦迁移场景的受控对照实验较少。本文构造隔离变量实验，分别控制嵌入模型、基座LLM、数据集，分离不同来源的性能损失。

2 实验前置定义与评估指标

2.1 核心变量定义

2.2 评估指标

MRR：平均倒数排名，衡量正确记忆片段的排序质量

实验输出样例指标表格（论文原始实验样例）

注释：Ideal routing upper bound：理想路由上界，代表完全重构建索引的理论性能上限。

2.3 测试用例

• 任务类型：基于记忆文档的问答、多轮历史对话召回、工具调用上下文恢复；
• 数据集：内部Agent记忆测试集，包含事实问答、长上下文多轮对话；
• 变量隔离策略：
• 固定嵌入模型，更换基座LLM；
• 固定基座LLM，更换嵌入模型；
• 同时升级嵌入+基座，模拟完整版本迭代。
  

3 实验环境与复现步骤

完整可复现操作步骤

3.1 环境依赖

# python依赖
pip install langchain chromadb sentence-transformers openai numpy pandas scipy

3.2 实验流程（分步）

3.3 关键实验脚本框架

"""
记忆可移植性对照实验最小框架
arxiv:2609.05339v1
"""
import numpy as np
import pandas as pd
from langchain.vectorstores import Chroma
from langchain.embeddings import HuggingFaceEmbeddings

def build_index(embedding_model_name, persist_path, docs):
emb = HuggingFaceEmbeddings(model_name=embedding_model_name)
db = Chroma.from_documents(docs, embedding=emb, persist_directory=persist_path)
db.persist()
return db

def evaluate_retrieval(vector_db, query_list, ground_truth_list, top_k=3):
"""计算Recall@k、MRR"""
recall_total = 0.0
mrr_total = 0.0
for q, gt in zip(query_list, ground_truth_list):
res = vector_db.similarity_search(q, k=top_k)
hit_pos = None
for idx, doc in enumerate(res):
if gt in doc.page_content:
hit_pos = idx + 1
break
if hit_pos is not None:
recall_total += 1.0
mrr_total += 1.0 / hit_pos
else:
mrr_total += 0.0
n = len(query_list)
return {
"recall@k": recall_total / n,
"mrr": mrr_total / n
}

# 实验流程入口
if __name__ == "__main__":
# 1.构建旧索引
# db_old = build_index("旧嵌入模型", "./index_old", documents)
# 2.构建重嵌入对照索引
# db_rebuild = build_index("新嵌入模型", "./index_rebuild", documents)
# 3.执行多组评估，保存csv用于统计
pass

提示：原始论文未公开完整开源仓库；上述为对齐论文实验逻辑的最小可运行框架。

4 核心实验发现

4.1 关键结论1：仅升级基座LLM，复用旧向量索引会带来显著性能损失

即使嵌入模型完全不变，仅仅替换推理基座LLM，直接复用旧索引依然会出现下游问答准确率下降。

原因：向量检索只负责拿到候选片段；基座LLM需要理解检索片段并对齐用户查询语义，基座模型的语义分布发生偏移，会造成“检索拿到正确片段，但模型不会使用”的失效模式。

4.2 关键结论2：完全重嵌入可以恢复性能上界

$Inde{x}_{rebuild}$（重嵌入）几乎可以完全消除该部分性能损失，达到理想上界。但代价是全量文档重新向量化，带来算力、存储开销。

4.3 关键结论3：检索指标（Recall@k）与下游任务准确率不完全对齐

部分场景：Recall@k指标下降很小，但是下游Answer accuracy大幅下跌。

该现象说明：仅依靠向量检索指标不足以评估Agent记忆迁移效果；必须端到端评估完整Agent链路（检索+LLM推理）。只看向量库召回指标会产生误导。

4.4 4.4小节：原始历史记忆具备修复机会（如果修复组件可用）

原文：Raw history buys a second chance—if the repairer can use it

如果Agent系统完整保存原始未向量化的原始记忆文本（原始对话、原始文档），即使旧向量索引失效，依然可以在新版本环境下重新执行嵌入重建索引。

⚠️风险点：很多Agent工程实现只保存向量，丢弃原始文本；一旦基座模型升级，记忆数据将不可修复。

5 工程实践建议