RPP：固定模板和软提示之间，还有一层 instance-wise prompt policy

背景

沿 PALR -> LFM -> LangPTune -> RecLM -> LettinGo -> UserIP-Tuning 这条线继续往前补的时候，我原本已经把推荐里的 prompt / profile personalization 先粗分成两类：

1. 把用户状态写成可读文本，再塞进固定 prompt 或下游推荐器
2. 把用户状态写成 latent soft prompt，再压成 embedding 或 collaborative ID

这张图已经能解释很多工作，但它还是默认了一件事：

被优化的对象要么是 profile，要么是 prompt embedding

这轮继续用本地 search-layer 做候选发现，再回到 arXiv、官方仓库、USTC Lab publication 页与中文导航页核验后，我补到一个很适合填这个空位的入口：

1. Reinforced Prompt Personalization for Recommendation with Large Language Models
2. maowenyu-11/RPP
3. USTC Lab for Data Science 的官方 publication 页
4. 智源社区的中文导航页 Reinforced Prompt Personalization for Recommendation with Large Language Models - 智源社区论文

它真正补上的，不是又一种 prompt 技巧，而是：

prompt personalization 本身也可以被单独写成 RL policy

核心判断

RPP 优化的不是 profile object，而是 prompt-time policy

这篇工作的关键，不是再发明一种新的 profile carrier。

它最值得记住的地方是：作者明确把推荐里的 prompt personalization 从 task-wise fixed template 推到了 instance-wise prompting。

更具体地说，它不是给所有用户共享一套固定模板，而是把 prompt 拆成四类 pattern：

1. role-playing
2. history records
3. reasoning guidance
4. output format

然后让四个 agent 分别在各自的句子子空间里选动作，再把这些句子拼成当前用户的 prompt。

所以 RPP 真正被 RL 优化的对象，不是：

1. LLM 参数
2. 持久化 profile text
3. soft prompt latent vector

而是：

当前这个用户，这一轮推荐，到底该用哪组离散句子来组织 prompt

这使它更适合被记成 prompt-time controller / prompt policy，而不是普通 profile constructor。

它把 history length 也写成了 prompt policy 的一部分

RPP 最容易被忽略、但最值得单独记住的一点，是它对 history records pattern 的处理。

论文 3.2 节没有把历史简单当作固定的 few-shot 上下文，而是把“要再往前展开多少条交互”也写成 action。

也就是说，这条线不是先维护一份持久 profile，再交给下游模型； 它允许 agent 在 prompt-time 决定：

1. 这个用户更该看近因历史，还是更长的历史窗口
2. 当前应当追加多少条历史交互
3. 历史应该怎样和其他 pattern 一起被组织进 prompt

这件事很关键，因为它说明：

temporal personalization 不一定非要落到 persistent profile 上，也可以先落到 prompt-time 的 history exposure policy 上

从这个角度看，RPP 既不同于 PALR 那种固定模板里的自然语言 profile，也不同于 TETUP / LLM-TUP 那种显式生成 short-term + long-term profile 的双时域 carrier。

它的 RL consumer 是外置 prompt controller，而不是 end-to-end recommender

这篇工作的 RL 结构也很值得单独记。

论文 3.3-3.4 节把 state / action / reward 写得很清楚：

1. 初始状态 s0 来自传统推荐器的用户 embedding，文中以 LightGCN 为例
2. 后续状态 st 会把当前 prompt 的编码和 LLM 当前 ranking output 的编码加在一起
3. 编码器层面，prompt 走 BERT，ranking output 走 GRU
4. 四个 agent 在 CTDE 框架下分别用 A2C 选动作
5. reward 直接使用 LLM ranking output 的 NDCG@10

这意味着它和 RecLM / LettinGo / UserIP-Tuning 的系统位置都不一样。

在这些方法里，被训练和部署的通常是：

1. profile generator
2. profile text / embedding / collaborative ID
3. 或者更下游的 recommendation adapter

而 RPP 的 RL 更像一个外置的 prompt orchestrator。

它不要求把 LLM 或推荐 backbone 改成 end-to-end 可训练主角，而是把 RL 预算花在：

怎样给冻结 LLM 组装一份更适合当前用户的 prompt

它补出的不是 prompt tuning，而是 discrete prompt policy

这条线和 UserIP-Tuning 很容易被误看成一类，因为两者都在讲 prompt personalization。

但它们实际处在完全不同的系统位置。

UserIP-Tuning 做的是：

1. 把 latent profile 写进 soft prompt
2. 用 causal mask + EM 推断嵌入式用户画像
3. 最后把结果压成 collaborative IDs 部署

而 RPP 做的是：

1. 保持 prompt 为离散自然语言句子
2. 不把 prompt 本身压成 latent storage object
3. 不把结果落成持久 user ID
4. 只在 inference / evaluation 时为当前用户组装一份 instance-wise prompt

所以如果后续 Story Lab 还只把 prompt personalization 记成：

1. fixed prompt
2. soft prompt

那就会漏掉 RPP 这种中间层：

discrete sentence-level prompt policy

这也逼着当前 profile constructor 子表再往前补一层更细的区分：

1. task-wise fixed template
2. instance-wise discrete prompt policy
3. prompt-tuned latent profile

否则 PALR、RPP 和 UserIP-Tuning 会再次被粗写成同一种“prompt 方法”。

它也暴露了这类方法的公开边界：代码在，workflow 不算低门槛

这轮我也专门核了它的公开边界。

比较稳的事实是：

1. arXiv API 显示论文最早提交于 2024-07-24，更新到 v2 的时间是 2025-02-03
2. USTC Lab for Data Science 的官方 publication 页已经把它挂到 TOIS 2025
3. GitHub API 显示官方仓 maowenyu-11/RPP 创建于 2024-01-26 10:40:36 UTC，最近一次代码 push 也停在 2024-01-26 14:57:36 UTC
4. 仓库根目录已公开 train.py、evaluate.py、baseline.py、model/、props/、dataset/ 与 saved/

但另一方面，README 也把复现门槛写得很直白：

1. 需要手工准备 gpt-3.5-turbo API
2. 需要下载 LLaMA2-7B-chat
3. 需要准备 Alpaca / LLaMA2-7B
4. 需要下载 bert-base-chinese
5. 还要手工把 RPP checkpoint 和 finetuned Alpaca checkpoint 放到指定目录

所以它更适合被记成：

experiment code + manual checkpoints

而不是开箱即用的低门槛 workflow。

中文传播层刚出现入口，但稳定 xhslink 仍然缺位

中文传播层这轮能稳定回溯到的入口，主要是智源社区导航页。

它至少能把 RPP 压成中文语境下可读的一句话：

多智能体强化学习 + 四类 prompt pattern 的句子级选择

但截至 2026-03-21，我继续用本地 search-layer 检索：

1. site:xiaohongshu.com Reinforced Prompt Personalization 推荐
2. xhslink Reinforced Prompt Personalization 推荐

结果仍然没有拿到稳定高价值的小红书线索，噪声远多于有效结果。

证据与来源

• Reinforced Prompt Personalization for Recommendation with Large Language Models：arXiv 摘要与 HTML 正文明确写出 instance-wise prompting、四类 pattern、A2C + CTDE、state/action/reward 定义，以及 RPP+ 的 action refinement。
• RPP：官方仓库 README 与 GitHub API 共同说明，公开实现已到 train.py / evaluate.py / model / props / dataset / saved 这一层，但仍依赖外部模型、API 与手工 checkpoint。
• Reinforced Prompt Personalization for Recommendation with Large Language Models | USTC Lab for Data Science：官方 publication 页把这条线稳定锚到 TOIS 2025。
• Reinforced Prompt Personalization for Recommendation with Large Language Models - 智源社区论文：可复用的中文导航层入口。

下一步

• 把 RPP 并入 PALR / UserIP-Tuning / RecLM / LettinGo 那张子表，单独补一列 prompt personalization mode，至少先区分 fixed template / discrete prompt policy / latent soft prompt。
• 继续找 RPP 同类路线的公开后继工作，确认“prompt-time policy”究竟是孤例，还是一条尚未被 Story Lab 单独命名的支线。
• 继续追中文传播层里更稳定的机制稿与 xhslink，避免这条线长期只剩论文原文和导航页。