PersonaMem-v2: Towards Personalized Intelligence via Learning Implicit User Personas and Agentic Memory

Paper: arXiv:2512.06688 Code: bowen-upenn/PersonaMem-v2 Code reference: main @ dd52429 (2026-05-17) Dataset: bowen-upenn/PersonaMem-v2

0. 一句话总结

这篇论文的核心不是再做一个“长上下文里找事实”的记忆 benchmark，而是把个性化建模改造成一个更真实的隐式推理问题：用户很少直接说“我喜欢什么、我是谁”，但他们在写邮件、翻译、咨询、上传图片、反复询问某类知识时会泄露偏好、身份线索、兴趣、禁忌、动态变化和第三方信息，模型必须从长而噪的多会话历史中判断哪些信号属于当前用户、哪些只是例子或他人信息、哪些偏好已经被更新或遗忘。

PersonaMem-v2 因此同时贡献了三件事：第一，一个覆盖 1,000 个用户 persona、300+ 场景、20,000+ 偏好、最高 128k token 历史的隐式个性化数据集；第二，一套把个性化任务转成 MCQ 与 open-ended 评测、并用 GPT-5 级 judge 严格过滤的数据生成与评测流水线；第三，展示了 RFT/GRPO 不只适合数学或代码推理，也能训练 4B 模型做隐式用户理解，尤其是 agentic memory 版本只保留约 2k token 的可读记忆，却达到论文中最强的 55.2% MCQ 与 60.7% open-ended accuracy。

我的理解是：论文真正有价值的点在于把“记住用户”拆成了三个更难的能力——证据归属、偏好推断、长期压缩更新。长上下文本身只是输入条件，决定性能的是模型是否能在噪声中形成因果、可更新、可审计的用户状态。

1. Motivation：为什么隐式个性化比普通长记忆更难

现有长上下文和记忆评测经常把任务写成显式事实检索：给定历史，问“用户住在哪里”“用户上次说了什么”。这种设置更接近 needle-in-a-haystack 或 long-context QA，核心压力在检索和定位。

PersonaMem-v2 关心的是另一类更接近真实助手的场景：用户在完成主任务时顺手暴露信息。例如用户让模型润色 TGIF 邀请邮件，邮件里出现 computer science department、Hawaiian cuisine、pet bunny、Capricorn 等信息；用户没有说“请记住我是 CS PhD、喜欢夏威夷菜、有兔子、相信星座”，但个性化助手如果要长期服务，就需要从这些上下文中抽取隐式偏好。

图 1 的设计很好地说明了论文动机：左侧是时间线上不断累积的多场景 user-chatbot history；中间是任务型对话片段；右侧是模型应当归纳出的 persona/preferences。关键在于偏好并不以标签形式出现，而是混在 email writing、translation、therapy、knowledge query、multimodal photo query 等主任务中。

这带来四个困难。

证据分散：一个偏好可能只在很早的几句话里出现，而且后续查询未必和原场景相同。模型不能只看最近对话。
归属模糊：用户可能在帮别人写消息、举反例、假设某个角色、询问第三方情况；模型需要判断偏好是否属于用户本人。
动态变化：用户偏好可能更新，旧偏好不应永久生效。论文把 static/dynamic/update/unlearning 纳入构造。
隐私与安全：医疗、心理、身份、敏感背景等信息既可能影响个性化，也可能不该被过度暴露或刻板化使用。

因此，PersonaMem-v2 的问题定义可以理解为：给定一个长、多会话、跨任务、含噪的交互历史 C 与当前用户查询 q，模型要生成一个既完成当前任务又符合用户真实偏好的回答 ŷ。如果使用 agentic memory，则模型不能一直读取完整 C，而是要维护一个随时间增长和更新的 compact memory M，并仅用 M 与 q 完成个性化。

论文的论点非常明确：前沿模型已经有长上下文窗口，但它们仍然无法稳定推断隐式用户偏好；瓶颈不是“能否放下 128k tokens”，而是“能否正确解释、整合、更新隐式信号”。这也是为什么作者把 RFT 和 agentic memory 作为后半部分重点。

2. Idea：把个性化建成可训练、可验证、可压缩的推理任务

论文的中心思路有三层。

第一层是 benchmark construction。作者不是简单收集闲聊对话，而是从 1,000 个 richly detailed personas 出发，生成各种显式与隐式偏好，再把每个偏好嵌入 2–6 turn 的自然任务型对话。每个 persona 不是固定字段表，而是包含职业、教育、年龄、文化、性别、race/ethnicity、价值观、健康背景、技术熟悉度、说话风格等多维信息。这样做的目的不是为了让模型按人口属性刻板化，而是为了制造足够多的真实背景变量，让模型必须依赖对话证据而不是 population prior。

第二层是 evaluation as personalization decision。论文把同一底层偏好转换为两类测试：MCQ 和 open-ended。MCQ 的正确选项是符合用户真实偏好的回答，错误选项可能是相反偏好、随机偏好、泛化回答或隐私泄露回答。Open-ended 则让模型自由生成，再由多个 judge 判断回答是否真正反映用户偏好。MCQ 提供稳定可验证 reward；open-ended 保留真实助手的生成自由度。

第三层是 learning and memory。如果模型每次都读取 32k/128k 历史，成本高且不可扩展；如果只做静态 profile，又难以处理更新和上下文证据。因此作者探索两种训练策略：

long-context RFT：把完整历史 C 与当前查询 q 输入 Qwen3-4B，通过 GRPO 训练模型直接推理出个性化回答。
agentic memory RFT：把历史拆成 chunks，模型按时间顺序把 C_i 融入上一轮记忆 M_{i-1} 得到 M_i，最后只用 M_T 回答 q。

图 4 的上半部分对应 long-context reasoning：长历史 + 当前 query 直接进入模型，然后 reward 根据 MCQ 匹配或 LLM judge 给出。下半部分对应 agentic memory：历史被切成多个 chunk，模型反复更新 memory，最终 query 只读取 compact memory。这个设计把个性化从一次性长上下文推理，变成“持续写入、持续压缩、最终使用”的 agent 状态管理问题。

该想法的关键直觉是：真实个性化系统不可能每次都回放用户全部历史，长期可用的表示必须是压缩的、可读的、可更新的。与 RAG 式检索不同，agentic memory 的 memory 不是检索若干原文片段，而是一个 human-readable state：里面应当包含用户偏好、背景、禁忌、变化和证据强度。这样既减少 token 成本，也更接近真实助手的长期记忆接口。

3. Method：数据、评测、RFT 与 agentic memory 的细节

3.1 PersonaMem-v2 数据集构建

PersonaMem-v2 的数据生成大致可以拆成 persona expansion、preference generation、conversation generation、QA generation、history building、benchmark preparation 六步。

3.1.1 Persona expansion

起点是 PersonaHub 风格的随机 persona 描述。源码 prompts.py 中的 expand_persona 会要求模型补全姓名、年龄、性别、race、personality、degree、school/work、其他人口统计信息，以及与 chatbot 交互时的 speaking style。这个步骤的意义是让每个用户不只是一个 preference label，而是一个具有现实复杂度的长期用户。

论文强调：数据中包含 1,000 个 personas，覆盖全球地区、文化、种族、性别、性取向、教育和职业背景。它还显式包含 mental/physical health 背景，因为这些场景中个性化既有价值也有高风险。

3.1.2 Preference types

每个 persona 会生成多种偏好类型。

stereotypical preference：与某些 demographic prior 一致，测试模型是否能在有证据时使用相关线索。
anti-stereotypical preference：与群体先验相反，测试模型是否会被刻板印象误导。
neutral preference：与人口属性无明显关系，测试普通兴趣或习惯。
health/therapy preference：涉及高风险个性化。
self/others ownership：测试偏好是否属于用户本人，还是用户谈到的他人。
static/dynamic/update/unlearning：测试偏好随时间变化时，模型能否覆盖旧状态。
multimodal and multilingual cases：测试图片、语言、翻译等非纯文本主任务中的隐式线索。

图 2 展示了数据分布。User preference scenarios 中 Health & Wellness 约 15.8%、Food 约 11.3%、Travel 约 9.0%、Social & Relationships 约 6.6%；chatbot task scenarios 中 Knowledge Query 约 17.8%、Professional Email 约 11.1%、Creative Writing 约 10.9%、Social Media Post 约 10.1%。这说明偏好类型和主任务场景不是一一对应的，同一个偏好可能通过完全不同的任务被间接暴露。

图 2 还说明了几个重要设计：数据中包含 static 与 preference update；绝大多数 preference ownership 是 self，但也有 other’s preference；敏感信息占约 10.2%；preference types 中 anti-stereotypical、neutral、stereotypical 都被覆盖。这样的分布能让评测区分“读到了用户证据”与“按人群先验猜测”。

3.1.3 Conversation generation

每个 preference 会被转成 2–6 turn conversation，而不是直接写成“用户喜欢 X”。源码 data_generation/conv_generator.py 里的 convert_preferences_to_conversations、generate_knowledge_queries 等函数把偏好嵌入不同场景。对于图片相关数据，流程还会把 image path 加进 user query，并区分 self 与 others preference。

这一点很重要：如果 benchmark 只在 history 中写“User likes Hawaiian food”，那任务仍然是显式检索。PersonaMem-v2 让 preference 以任务副产物出现，比如邮件内容、翻译文本、咨询背景、照片环境、重复查询主题。模型需要从这些行为中反推偏好。

3.1.4 QA generation and validation

生成 QA 时，源码 prompts.py 的 generate_answer_options 会为一个 user query 生成四类候选：correct、random、generic、opposite；敏感信息场景还会生成 leaked/incorrect 等选项。data_generation/qa_generator.py 再做多重过滤：

不看 conversation history 时，模型不应能直接答对，避免 query 泄露 ground-truth preference。
correct answer 必须忠实反映真实偏好。
incorrect answers 不能也符合真实偏好。
answer format 要自然干净，不能带明显生成痕迹。

论文报告只有约 30% 生成的 Q&A 能通过所有过滤。这个数字很关键：它说明作者宁愿大规模生成再强过滤，也不接受大量带捷径或泄露的样本进入 benchmark。

3.1.5 32k / 128k chat histories

源码 data_generation/contexts_builder.py 与 prepare_benchmark.py 负责构建 chat history 和 benchmark CSV。prepare_benchmark.py 中的字段包括 chat_history_32k_link、chat_history_128k_link、user_query、correct_answer、incorrect_answers、preference、pref_type、related_conversation_snippet、who、updated、prev_pref、sensitive_info、相关/无关 token 统计等。

这意味着每条评测样本不只是一个问题，而是带有可追踪的来源：它来自某个 persona、某段相关 conversation snippet、某类 preference、某种 ownership/update 状态，以及 32k/128k 两种上下文版本。这个设计使后续分析可以按 preference type、scenario、context length、ownership、dynamic state 分组，而不是只有一个总分。

3.2 Benchmark format and evaluation

官方 Hugging Face 数据页显示 benchmark subset 约 51.7k rows，拆分包括 benchmark_text、train_text、val_text、benchmark_multimodal、train_multimodal、val_multimodal。数据格式是 CSV，任务类型被标注为 Question Answering / Text Generation，模态包括 tabular 和 text。

评测脚本 inference.py 的核心类是 PersonaBenchmarkEvaluator。它会：

读取 benchmark CSV。
根据 chat_history_32k_link 或 chat_history_128k_link 加载历史。
解析 user_query。
在 MCQ 模式下调用 create_mcq_options 将 correct/incorrect answers 打乱成 A/B/C/D。
调用 QueryLLM 让模型基于 history + query 生成回答。
从回答中解析 final answer letter，计算 MCQ accuracy。
在 open-ended 模式下生成自由回答，再由 inference_utils.py 中的 judge 函数评估。

源码里的 MCQ instruction 明确要求模型 step-by-step reasoning，并最后输出 Final Answer: [Letter]。这与论文的训练设置一致：MCQ 部分 reward 更可验证，open-ended 部分通过多个 judge 保留真实生成评估。

3.3 Long-context RFT with GRPO

long-context 训练把个性化视为推理任务。输入是用户历史 C 与当前 query q，模型输出回答 ŷ。Reward 分两类：

MCQ：看 final answer 是否匹配正确选项。
Open-ended：使用多个 GPT-5-Chat judge 判断回答是否符合 ground-truth user preference。

论文中训练设置为：先对 Qwen3-4B-Instruct-2507 做 300 steps SFT，SFT batch size 64；再用 GRPO 训练约 1 epoch / 500 steps，batch size 32，每个 prompt 8 rollouts；训练数据混合 80% MCQ 与 20% open-ended。这样做的动机是 MCQ 提供稳定可验证 reward，open-ended 保持生成能力。

源码里的 long-context GRPO launch script 是 verl_custom/scripts/run_qwen3_4b_grpo.sh。它使用 data.train_batch_size=32、data.max_prompt_length=38000、data.max_response_length=2048、data.enable_thinking=True、reward_model.reward_manager=custom_naive、reward_model.eval_method=judge、actor_rollout_ref.rollout.n=8、trainer.total_epochs=1。SFT 脚本 verl_custom/scripts/run_qwen3_4b_sft.sh 使用 data.train_batch_size=64、data.max_length=40960、trainer.total_epochs=4，并从 Qwen3-4B-Instruct-2507 checkpoint 初始化。

这些配置与论文主文基本对应：paper 描述的是训练流程和有效 batch/steps，repo 给出实际开源脚本中的 prompt length、response length、rollout number、learning rate、sequence parallel 等实现细节。注意：paper 写 SFT 300 steps，但脚本以 total_epochs=4 和 save/test freq 描述；因此复现实验时应优先以 repo 当前 commit 的 launch scripts 为准，并把 paper 数字当作论文报告设置。

3.4 Agentic Memory RFT

agentic memory 的目标是避免每次都读取完整历史。设完整 conversation history 被切成 T 个 chunks：C_1, ..., C_T。模型维护一个单一 memory M：

第 i 步输入当前 chunk C_i 和上一轮 memory M_{i-1}。
模型生成新 memory M_i。
最终输入当前 query q 与 M_T，生成个性化回答。

论文给出三个原则。

Causality：memory 只能基于当前及过去 chunk，不能偷看未来 chunk 或未来 query。
Markovian assumption：M_i 必须概括过去所有重要信息，使下一步只依赖 M_i 和 C_{i+1}。
Compactness / human-readability：memory 要足够短、可读、可检查，不能退化成复制原文历史。

源码中 MemAgent/recurrent/impls/memory.py 实现了这个 recurrent memory agent。MemoryConfig 定义 context_key、max_prompt_length、chunk_size、max_memorization_length、max_chunks、max_final_response_length。MemoryDataset 从数据里读取 context；MemoryAgent.action() 根据 original_ctx_length > step * chunk_size 与 step < max_chunks 判断哪些样本还需要继续处理 chunk；当所有 chunk 处理完后，进入 final turn，用 token_final_message_template 基于 prompt 和 memory 生成最终回答。update() 则把模型生成的 memory/answer 写回 agent 状态。

论文的 agentic memory 训练设置为：仍使用 80% MCQ + 20% open-ended 混合数据，初始化自 Qwen3-4B-Instruct-2507 的 SFT checkpoint；GRPO 约 500 steps，batch size 32，8 rollouts；在 32k context window 下把 memory cap 到 2,048 tokens，每个 chunk 限制 5,000 tokens，因此最多 T = 8 memory-update iterations。

开源脚本 MemAgent/run_qwen3_4b_grpo.sh 中能看到核心实现参数：recurrent.enable=memory、recurrent.memory.config.chunk_size=5000、recurrent.memory.config.max_chunks=8、algorithm.adv_estimator=grpo、actor_rollout_ref.rollout.n=8、MODEL_PATH=../verl_custom/ckpt_sft/global_step_400、MAXLEN=8192、MAX_NEW_TOKEN=1024、actor_rollout_ref.actor.optim.lr=1e-6、actor_rollout_ref.actor.kl_loss_coef=0.001、trainer.total_epochs=1。当前脚本中 data.train_batch_size=16，与论文文字里的 batch size 32 不完全一致；这可能来自开源脚本的资源/版本调整，复现时应明确记录 commit 与实际 launch 参数。

3.5 源码对应的伪代码

下面伪代码不是 paper 文字的重述，而是按当前官方 repo 的文件组织整理的执行流。

3.5.1 数据生成与 benchmark 准备

# data_generation/main.py + conv_generator.py + qa_generator.py + contexts_builder.py + prepare_benchmark.py
for persona_seed in range(num_persona):
    persona = prompts.expand_persona(seed_persona)
    preferences = generate_stereotypical_neutral_anti_sensitive_dynamic_preferences(persona)
 
    conversations = {}
    for pref in preferences:
        # 不直接写“用户喜欢 X”，而是把 pref 放入任务型对话
        conv = conv_generator.convert_preferences_to_conversations(
            persona_str=persona,
            preference=pref,
            scenario=random_task_scenario,
        )
        conv = maybe_extend_to_multiturns(conv)
        conv = maybe_attach_image_or_sensitive_context(conv)
        conversations[pref.id].append(conv)
 
    for conv_item in conversations:
        query = generate_in_situ_user_query(conv_item)
        answers = prompts.generate_answer_options(conv_item.preference, query, owner, persona)
        if qa_generator.validate_qa_pair(query, answers, history_required=True):
            save_qa_item(conv_item, query, answers)
 
build_context(target_lengths=["32k", "128k"], mix_relevant_and_irrelevant=True)
prepare_benchmark_csv(fields=[history_links, query, correct_answer, incorrect_answers,
                              pref_type, who, updated, prev_pref, token_stats])

3.5.2 推理评测

# inference.py
rows = read_csv(benchmark_file)
for row in rows:
    history = load_chat_history(row[f"chat_history_{size}_link"])
    user_query = parse(row["user_query"])
 
    if eval_mode == "mcq":
        options, option_mapping = create_mcq_options(row["correct_answer"], row["incorrect_answers"])
        prompt = history + [user_query + options]
        response = QueryLLM.query_llm(prompt)
        pred_letter = extract_final_answer_letter(response)
        is_correct = option_mapping[pred_letter] == row["correct_answer"]
 
    if eval_mode == "generative":
        response = QueryLLM.query_llm(history + [user_query])
        is_correct = evaluate_narrow_judge(row, response, judge_llm)

3.5.3 Agentic memory training/inference

# MemAgent/recurrent/impls/memory.py + MemAgent/run_qwen3_4b_grpo.sh
memory = NO_MEMORY
step = 0
while original_context_length > step * chunk_size and step < max_chunks:
    chunk = context_tokens[step * chunk_size : (step + 1) * chunk_size]
    message = format_memory_update_prompt(prompt=user_query_or_task,
                                          memory=memory,
                                          chunk=chunk)
    memory = policy.generate(message, max_tokens=max_memorization_length)
    step += 1
 
final_message = format_final_prompt(prompt=user_query, memory=memory)
answer = policy.generate(final_message, max_tokens=max_final_response_length)
reward = mcq_match(answer) or llm_judge(answer, ground_truth_preference)
update_policy_with_grpo(reward, rollout_group=8)

这段伪代码揭示了 agentic memory 的本质：训练 reward 发生在最终回答，但 credit 被分配给前面的 memory-writing steps。论文说 GRPO 中每个 rollout 的 advantage 由 final turn reward 计算，并共享给 preceding conversations；这让模型学习“写什么 memory 会提高未来个性化回答 reward”。

4. Experimental Setup：实验对象、训练设置和评估维度

4.1 数据规模和对比 benchmark

表 1 把 PersonaMem-v2 与 LongMemEval、PrefEval、PersonaMem-v1 对比。PersonaMem-v2 的最大上下文是 128k；persona 数量是 1,000；topic 数量约 335；preference 数量在表中写为 26,000，正文摘要写 20,000+；它覆盖 cross-session reasoning、dynamic preferences、implicit preferences、sensitive user information、anti-stereotypical preferences、多模态和多语言，并且支持 SFT、RFT/GRPO、RFT with agentic memory。

这与 PersonaMem-v1 的区别很明显：v1 更强调 fine-grained personalized responses，但 v2 进一步把隐式偏好、真实 task-driven conversation、动态更新、敏感信息和训练方法都纳入同一框架。

4.2 Frontier LLM evaluation

论文评估了多类 frontier 模型，包括 GPT-5-mini、GPT-5-chat、o4-mini、GPT-4.1、GPT-5-nano、GPT-4.1-mini 等。每个模型在 32k 和 128k 上下文下分别做 MCQ 与 open-ended。

图 3 的关键数字如下。

GPT-5-mini：MCQ 32k 48.7%，MCQ 128k 44.1%，open-ended 32k 56.4%，open-ended 128k 47.6%。
GPT-5-chat：MCQ 32k 45.6%，MCQ 128k 41.4%，open-ended 32k 46.2%，open-ended 128k 40.7%。
o4-mini：MCQ 32k 39.1%，MCQ 128k 38.9%，open-ended 32k 52.0%，open-ended 128k 43.0%。
GPT-4.1：MCQ 32k 38.7%，MCQ 128k 38.2%，open-ended 32k 48.5%，open-ended 128k 45.6%。
GPT-5-nano：MCQ 32k 37.9%，MCQ 128k 33.9%，open-ended 32k 50.1%，open-ended 128k 44.0%。
GPT-4.1-mini：MCQ 32k 37.6%，MCQ 128k 37.5%，open-ended 32k 45.3%，open-ended 128k 39.8%。

这些结果支持两个结论：第一，frontier LLMs 在隐式个性化上仍然只达到约 37–48% 的 MCQ accuracy，远低于人们对“长上下文模型”的直觉预期；第二，128k 不一定优于 32k，甚至多处更低，说明噪声历史会放大推理难度，单纯扩窗口不是解决方案。

4.3 RFT training setup

long-context RFT 的 base model 是 Qwen3-4B-Instruct-2507。训练先冷启动 SFT，再做 GRPO。论文强调混合 80% MCQ 和 20% open-ended，是为了在 reward verifiability 和真实生成能力之间折中。MCQ reward 稳定，open-ended reward 需要三个 GPT-5-Chat judge。

源码的 long-context GRPO 脚本提供了更具体的实现参数：max prompt length 38,000，max response length 2,048，rollout n=8，learning rate 5e-6，Ulysses sequence parallel size 8，训练 1 epoch。SFT 脚本则使用 train batch size 64、max length 40,960、learning rate 1e-5。

4.4 Agentic memory setup

Agentic memory 仍然使用同一训练框架和混合数据。区别在于输入不再是一次性 full history，而是 chunk_size=5000、max_chunks=8 的 sequential memory writing。论文报告 memory cap 是 2,048 tokens；repo 的 MemAgent 脚本中 MAX_NEW_TOKEN=1024 和 recurrent config 共同控制每轮生成长度，当前脚本展示的是开源实现参数。

评估时，agentic memory 最终只用 compact memory 回答，而不是读取完整 32k history。论文称这相当于 16x fewer input tokens：从 32k 对话历史降低到约 2k memory。

5. Experimental Results：结果和解释

5.1 前沿模型的失败模式

论文最重要的负结果是：即便 GPT-5 系列、o4-mini、GPT-4.1 具备强推理或长上下文能力，它们仍然难以稳定处理隐式个性化。图 3 中最强的 open-ended 32k 是 GPT-5-mini 的 56.4%，但 MCQ 只有 48.7%；GPT-5-chat 在 MCQ 32k 是 45.6%，open-ended 32k 是 46.2%。这说明“会写一个看似自然的回答”和“准确匹配用户真实偏好”不是同一件事。

更有意思的是 128k 上下文并没有带来提升。许多模型在 128k 下低于 32k。论文解释为：当相关偏好被埋在更长、更噪的历史里，模型需要更强的证据选择和归纳能力；如果只是把更多历史塞进窗口，噪声也会一起增加。

5.2 按偏好类型与场景拆分

图 5 把所有模型按 preference type、static/dynamic、ownership、conversation scenario 拆分。几个数值很有解释力。

Stereotypical preferences：48.9 ± 5.7%。
Neutral preferences：41.6 ± 3.3%。
Anti-stereotypical preferences：33.0 ± 5.0%。
Static：40.1 ± 2.7%。
Dynamic：35.4 ± 10.5%。
Unlearning：35.4 ± 10.5%。
Self preference：42.1 ± 4.9%。
Others preference：17.5 ± 11.7%。
Therapy scenario：44.7 ± 3.0%。
Health & Medical scenario：32.9 ± 8.9%。

这些拆分说明模型常常依赖 population priors。Stereotypical 明显高于 anti-stereotypical，说明当偏好与常见群体先验一致时模型更容易猜中；当偏好反先验时，模型容易被刻板印象带偏。Others preference 的分数非常低，说明模型很难判断“这是不是用户本人”的信息。Dynamic/unlearning 也低，说明更新旧 memory 是当前模型薄弱点。

5.3 RFT 显著改善 4B 模型

图 6 显示 Qwen3-4B 系列训练结果。

Qwen3-4B Base：MCQ 30.5%，open-ended 38.3%。
Qwen3-4B SFT：MCQ 35.0%，open-ended 42.8%。
Qwen3-4B GRPO：MCQ 53.8%，open-ended 56.0%。
Qwen3-4B GRPO ablation, train on MCQ only：MCQ 55.5%，open-ended 42.9%。
Qwen3-4B GRPO ablation, train on open-ended only：MCQ 35.6%，open-ended 52.3%。
Qwen3-4B Memory：MCQ 55.2%，open-ended 60.7%，输入上下文约 2k memory。

这个结果支持三个判断。

第一，SFT 只带来有限增益。Base 到 SFT 从 30.5/38.3 到 35.0/42.8，说明模仿数据能帮助一点，但不足以学会隐式证据推理。

第二，GRPO 的收益很大。Qwen3-4B GRPO 到达 53.8/56.0，超过 GPT-5-chat 的 45.6/46.2。这说明小模型如果有针对性的可验证 reward，也可以学会个性化推理模式。

第三，MCQ-only 与 open-ended-only ablation 体现 reward 混合必要性。MCQ-only 让 MCQ 很高但 open-ended 低；open-ended-only 让 open-ended 高但 MCQ 低。80/20 混合是为了让模型既能做可验证选择，也能保留自由生成质量。

5.4 Agentic memory 的意义

最强结果来自 Qwen3-4B Memory：55.2% MCQ、60.7% open-ended。它不仅略高于 long-context GRPO，而且输入 token 少 16x。这个结果的意义不是单纯“memory 更快”，而是：经过 RFT 训练的 memory writer 能把 long conversation 压缩成对未来个性化有用的状态，而不是随机摘要。

这也解释了为什么论文称 agentic memory 是 scalable path。长上下文方法每次 query 都要重新消费历史；agentic memory 把历史处理成本摊到每次交互后的 memory update，并在服务时只读 compact memory。对真实长期助手来说，这种设计比“无限上下文窗口”更可部署。

6. Source Code Mapping

Code reference: main @ dd52429 (2026-05-17)

Paper Concept	Source File	Key Class/Function
官方 repo 与数据/训练说明	`README.md`	Installation, Inference and Evaluation, Training, Data Generation sections
Persona expansion 与偏好生成 prompt	`prompts.py`	`expand_persona`, `generate_stereotypical_preferences`, `generate_answer_options`, `validate_qa_multiple_choice`
多场景对话生成	`data_generation/conv_generator.py`	`convert_preferences_to_conversations`, `generate_knowledge_queries`, multimodal preference generation helpers
动态偏好 / others preference 处理	`data_generation/conv_update.py`	`process_existing_files_for_others_preferences` and update-processing flow
QA 生成与过滤	`data_generation/qa_generator.py`	answer option generation, leakage checks, MCQ validation, correctness/contamination filters
32k/128k 历史构建	`data_generation/contexts_builder.py`	`build_context` and token-budgeted context assembly
benchmark CSV 准备	`data_generation/prepare_benchmark.py`	`get_chat_history_links`, `process_persona_file`, output fields including preference metadata and token stats
前沿模型推理评测	`inference.py`	`PersonaBenchmarkEvaluator`, `load_chat_history`, `create_mcq_options`, `evaluate_row`, `run_evaluation`, `run_judge_evaluation`
Open-ended judge	`inference_utils.py`	`evaluate_narrow_judge`, `evaluate_broad_judge`
API/model wrapper	`query_llm.py`	`QueryLLM`, OpenAI/Azure/Gemini/Claude setup, caching/rate limit handling
Long-context GRPO 训练	`verl_custom/scripts/run_qwen3_4b_grpo.sh`	GRPO launch config: train/val parquet, prompt length, response length, rollout n, judge reward
SFT cold start	`verl_custom/scripts/run_qwen3_4b_sft.sh`	Qwen3-4B SFT launch config, batch size 64, max length 40960
Agentic memory recurrent agent	`MemAgent/recurrent/impls/memory.py`	`MemoryConfig`, `MemoryDataset`, `MemoryAgent.action`, `MemoryAgent.update`
Agentic memory GRPO launch	`MemAgent/run_qwen3_4b_grpo.sh`	recurrent memory config: chunk_size 5000, max_chunks 8, rollout n=8, GRPO, KL, vLLM rollout
Agentic memory inference	`MemAgent/run_qwen3_4b_inference.sh`	recurrent memory inference launch path with same chunking interface

代码搜索结论：该论文有公开官方实现，仓库为 bowen-upenn/PersonaMem-v2。当前本地检出的 commit 是 main@dd52429，日期 2026-05-17。仓库包含 benchmark data generation、frontier LLM inference/evaluation、long-context GRPO、SFT、基于 MemAgent 的 agentic memory 训练与推理代码。没有在 ~/ai-skills/skills/ 中找到已存在的同名 paper-to-skill 技能。

7. 与相关工作的区别

与 LongMemEval 这类 long-term memory QA 相比，PersonaMem-v2 不是问显式事实，而是问“历史中隐式暴露的偏好如何影响当前回答”。LongMemEval 可以有 1.5M tokens，但任务重点更多是 factual Q&A；PersonaMem-v2 的上下文上限较小但推理更偏用户建模。

与 PrefEval 相比，PersonaMem-v2 的优势在 dynamic preferences、implicit preferences、sensitive information、anti-stereotypical cases、多场景任务历史，以及训练数据和 RFT 框架。PrefEval 也涉及用户偏好，但 v2 更接近真实助手每天遇到的工具型对话。

与 PersonaMem-v1 相比，v2 从“细粒度个性化回答”进一步扩展到 1,000 personas、335 topics、26,000 table-reported preferences、128k contexts，并把 SFT/RFT/agentic memory 作为实验对象。这使它不仅是 benchmark，也是个性化模型训练平台。

与传统 memory agent 或 RAG memory 相比，本文强调 memory 的三个约束：因果、Markov、紧凑可读。RAG 检索可以找到相似片段，但不一定能处理偏好归属、更新和反刻板印象；agentic memory 则要求模型主动写入一个长期状态。

8. 局限与风险

第一，数据主要由 GPT-5 生成和过滤。虽然作者用多重 judge 和严格过滤提高质量，但 synthetic pipeline 仍可能继承 generator/judge 的偏好、文化假设和表达风格。尤其在敏感身份、健康、心理和文化价值场景中，合成数据是否能代表真实用户仍需实证验证。

第二，benchmark 把“正确个性化”定义为匹配 ground-truth preference，但真实系统中用户偏好可能模糊、矛盾、临时、上下文依赖，甚至用户自己不希望模型长期记住。论文有 privacy-aware design，但离真实部署中的 consent、retention、deletion、scope control 还有距离。

第三，agentic memory 的 human-readable memory 虽然可审计，但也带来隐私集中化风险。把用户长期信息压缩成 2k memory 可能更高效，也可能更容易被泄露、误用或跨场景过度泛化。真实系统需要权限、加密、可删除和用户可控的 memory 管理。

第四，图 5 中 others preference 和 anti-stereotypical preference 很难，说明当前模型仍会把他人信息误归给用户，或者用 population prior 替代个体证据。这是个性化安全中的核心风险：错误个性化可能比不个性化更糟。

第五，repo 与 paper 之间有少量实现数字差异。例如论文描述 agentic memory batch size 32，而当前 MemAgent/run_qwen3_4b_grpo.sh 中 data.train_batch_size=16；论文描述 memory cap 2,048 tokens，而脚本中可见的 MAX_NEW_TOKEN=1024 也参与控制生成长度。复现实验必须固定 commit、脚本、数据版本和 checkpoint。

9. 我会如何复现或扩展

如果要复现，我会先只跑 inference/evaluation，不直接训练。步骤是下载 Hugging Face 数据到 data/，用 scripts/inference_scripts/run_gpt5_chat.sh 或等价脚本在小样本上验证 CSV 字段、history path、query parsing、MCQ extraction 和 judge 流程。这样可以先确认 benchmark pipeline 没有路径和 API 问题。

第二步复现 long-context Qwen3-4B SFT/GRPO。优先检查 verl_custom/data_preprocess_sft.py 与 verl_custom/data_preprocess_rft.py 输出的 parquet schema 是否与 run_qwen3_4b_sft.sh、run_qwen3_4b_grpo.sh 一致。训练日志中需要分别记录 MCQ reward、judge reward、response length、KL、rollout accuracy 和 parse failure rate。

第三步再复现 agentic memory。这里最容易出 bug 的地方不是 GRPO 本身，而是 memory chunking 与 final reward 对齐。需要检查 MemoryAgent.action() 的 active mask、chunk order、max_chunks、final turn 是否只在所有 context 处理完后触发；还要检查 memory 是否被错误地看到 future query 或 future chunks。

如果要扩展，我会增加四类评测：用户明确撤回 consent 的记忆删除；同一偏好在不同任务下的 scope control；多个用户共享设备时的身份隔离；以及用户可编辑 memory 后模型是否尊重修改。这些比单纯提高 accuracy 更接近真实个人助手。

10. Takeaways

PersonaMem-v2 把个性化从“给模型更多上下文”推进到“让模型学习如何解释、压缩和更新用户状态”。这对 agent 方向很重要，因为长期 agent 的核心不是一次性解决任务，而是在多次交互后形成可持续、可控、可审计的用户模型。

论文最有说服力的证据是：frontier LLMs 在 37–48% MCQ accuracy 区间挣扎，说明现有模型并不会自然拥有隐式个性化能力；Qwen3-4B 经过 GRPO 后能到 53.8/56.0，说明这种能力可以被 reward 学出来；agentic memory 进一步到 55.2/60.7 且 token 减少 16x，说明长期个性化不一定要靠无限上下文，而可以靠训练出的 memory writer。

这篇工作的实践启发是：如果要做个人助手，不能只接入聊天历史检索，也不能只让模型“总结用户画像”。更稳妥的系统应当同时具备 evidence-aware preference inference、causal memory update、explicit deletion/update handling、privacy-preserving memory storage，以及能被用户查看和纠正的 memory 表示。PersonaMem-v2 给出了一个可训练、可评估的起点，但真实部署还需要把用户控制权和安全边界补上。

Paper Notes

探索

PersonaMem-v2: Towards Personalized Intelligence via Learning Implicit User Personas and Agentic Memory

PersonaMem-v2: Towards Personalized Intelligence via Learning Implicit User Personas and Agentic Memory

0. 一句话总结

1. Motivation：为什么隐式个性化比普通长记忆更难

2. Idea：把个性化建成可训练、可验证、可压缩的推理任务

3. Method：数据、评测、RFT 与 agentic memory 的细节

3.1 PersonaMem-v2 数据集构建

3.1.1 Persona expansion

3.1.2 Preference types

3.1.3 Conversation generation

3.1.4 QA generation and validation

3.1.5 32k / 128k chat histories

3.2 Benchmark format and evaluation

3.3 Long-context RFT with GRPO

3.4 Agentic Memory RFT

3.5 源码对应的伪代码

3.5.1 数据生成与 benchmark 准备

3.5.2 推理评测

3.5.3 Agentic memory training/inference

4. Experimental Setup：实验对象、训练设置和评估维度

4.1 数据规模和对比 benchmark

4.2 Frontier LLM evaluation

4.3 RFT training setup

4.4 Agentic memory setup

5. Experimental Results：结果和解释

5.1 前沿模型的失败模式

5.2 按偏好类型与场景拆分

5.3 RFT 显著改善 4B 模型

5.4 Agentic memory 的意义

6. Source Code Mapping

7. 与相关工作的区别

8. 局限与风险

9. 我会如何复现或扩展

10. Takeaways

目录