PALR、RLMRec、KAR：RecLM 之前，画像在推荐里已经有三种系统用法

背景

上一轮，我刚把 RecLM 和 LettinGo 连起来，初步把 profile constructor 支线拆成了两类：

  1. 接传统 CF 推荐器的 adapter
  2. 接下游 LLM recommender 的 profile summarizer

但这轮我顺着 LettinGo 的实验表继续往回追它的 baseline，发现一个更值得写进 Story Lab 的事实：

PALR / RLMRec / KAR 这三个名字经常一起出现，可它们并不是同一种“用户画像方法”。

如果只把它们粗写成一列 profile baseline，就会把 RecLM 和 LettinGo 真正推进的东西看扁。

核心判断

这三条线的共同点，只是都借过 LLM 来理解用户

把三篇原文和官方仓库放在一起看，最清楚的不是“它们都在做 profile”，而是：

它们让 LLM 产出的东西进入推荐系统的接口，根本不是同一种。

| 路线 | LLM 主要产物 | 直接 consumer | 更合适的系统位置 | 当前公开边界 | | --- | --- | --- | --- | --- | | PALR | 自然语言用户画像 + 重排输出 | LLM 自己的 reranker | prompt-time profile + reranking | 论文；截至 2026-03-21 未见稳定官方仓 | | RLMRec | user/item profile 文本，再编码成语义向量 | 传统 recommender 表征层 | representer / profile-as-semantic-view | 论文 + 官方仓 | | KAR | 用户偏好 reasoning knowledge + 物品 factual knowledge，再压成 augmented vectors | 任意 recommendation backbone | open-world knowledge adaptor | 论文 + 官方仓，但 knowledge generation 代码未放出 |

这张表背后的直接含义是：

Story Lab 给 profile constructor 单独开子表是对的，但只记录 downstream consumer 还不够。

至少还要再补一列：

carrier / interface

否则，profile text、semantic embedding view 和 knowledge vector 这三种完全不同的系统接口会被混成一种。

PALR 代表的是 prompt-time profile，不是 profile adapter

PALR 最早把“自然语言用户画像”明确放进了推荐 prompt 里，但它的系统位置和 RecLM 并不一样。

论文摘要和 PDF 都写得很直接：

  1. 先做 candidate retrieval
  2. 再让 LLM-based ranking model 从候选里选结果
  3. 整个任务被拆成 user profile generation / candidates retrieval / items ranking 三步

更关键的是，论文图示和实验说明里，PALR 的自然语言 prompt 由三部分组成：

  1. Interaction History Sequence
  2. Natural Language User Profile
  3. Candidates for Recommendation

并且作者专门设计了 Recommend 与 Recommend_Retrieval 两种 instruction task，其中后者显式把候选集合交给模型去做重排。

所以 PALR 真正做的，不是把 profile 单独拿出来交给下游推荐器，而是：

把 profile 当作 prompt 里的一个 context carrier，服务于 LLM reranker 自己的决策。

这和 RecLM 的差别很大。

RecLM 的 profile 最终要交给 BiasMF / NCF / LightGCN / SGL / SimGCL 这类传统 backbone；PALR 的 profile 则主要是给 LLM 自己看，用来帮它在候选集合里做更准的排序。

因此它更适合被记成：

prompt-time natural-language profile

而不是今天这轮已经更关心的 profile text as optimization target。

RLMRec 代表的是 profile-as-semantic-view，不是 prompt 生成器

RLMRec 往前推进了一步，但方向不是 PALR -> RecLM 这种 prompt-to-policy 线，而是另一条：

profile -> semantic representation -> cross-view alignment

原文摘要、HTML 和官方 README 都指向同一个结构：

  1. 用 LLM 生成 user/item profile
  2. 把这些 profile 编码成语义表示
  3. 再把这套语义空间和 collaborative relational signals 通过 cross-view alignment 对齐

论文还专门强调它的核心不是直接让 LLM 做推荐，而是一个 model-agnostic framework，能增强已有 recommenders 的表征学习；理论部分则把理由写成了 mutual information maximization。

这让 RLMRec 在 Story Lab 里的位置非常明确：

它不是 PALR 那种把 profile 直接塞进推荐 prompt 的路线，也不是 RecLM / LettinGo 那种把 profile generator 本身当成训练对象的路线。

它更像把 profile 变成一个额外语义视图，再回流到推荐器的 representation layer。

官方仓也强化了这个判断。HKUDS/RLMRec 的 README 直接公开了：

  1. usr_prf.pkl / itm_prf.pkl
  2. usr_emb_np.pkl / itm_emb_np.pkl
  3. data/read_profile.py

也就是说，RLMRec 对外公开的核心接口不是“让你直接复现一个会生成推荐列表的 LLM”，而是“让你看到 profile 文本怎样被编码成表示，并与已有推荐器拼接对齐”。

所以如果后续 Story Lab 还把它和 PALR 一起粗写成 profile method，就仍然太粗。

更准确的命名应该是：

representer / profile-as-semantic-view

KAR 代表的已经不是画像，而是 open-world knowledge adaptor

KAR 则进一步说明：

有些被放进 profile baseline 对照表里的方法，实际上已经不该叫“画像生成”了。

论文摘要最关键的两句是：

  1. 从 LLM 获取两类外部知识：reasoning knowledge on user preferences 和 factual knowledge on items
  2. 用 hybrid-expert adaptor 把这些知识压成 recommendation-space 的 augmented vectors

正文又把整个系统明确拆成三段：

  1. knowledge reasoning and generation
  2. knowledge adaptation
  3. knowledge utilization

并专门写了 factorization prompting，用来把复杂偏好推理拆成可控因素，以缓解 compositional gap。

这意味着 KAR 里的 LLM 输出，已经不是单纯意义上的用户画像。

它更像是一套：

open-world reasoning/factual knowledge carrier

这些文本不会直接当最终推荐结果，也不是像 PALR 那样原样塞进 prompt；它们会先被 encoder 和 adaptor 转成 augmented vectors，再交给推荐 backbone 使用。

这条线和 RecLM / LettinGo 最不同的地方在于：

RecLM / LettinGo 仍把 profile text 本身当成核心对象，而 KAR 更关心的是怎样把开放世界知识可靠地变成推荐空间里的可消费信号。

它的公开仓也把这一点暴露得很清楚。YunjiaXi/Open-World-Knowledge-Augmented-Recommendation 当前已经公开：

  1. preprocess/
  2. knowledge_encoding/
  3. RS/
  4. 预生成的 user.klg / item.klg

但 README 同时明确写出：

knowledge generation 代码没有放出，只给了已经生成好的知识文件。

所以 KAR 的开放边界应写成：

paper + adaptor/code + generated knowledge artifacts

而不是“完整放出了从 prompt 到知识生成的一整条流水线”。

这也让 RecLM / LettinGo 的推进点更清楚

把这三条前史路线补齐之后，RecLM 和 LettinGo 的真正新增量反而更容易看清。

它们的新意不在于“第一次引入用户画像”。

更准确地说，是把画像从不同系统里的辅助 carrier，继续推进成了可被训练、可被对齐、可被显式优化的对象：

| 路线 | 画像 / 知识在系统里的主要形态 | 优化对象 | | --- | --- | --- | | PALR | prompt 里的自然语言用户画像 | 候选重排输出 | | RLMRec | 语义视图 / profile embedding | 表征对齐 | | KAR | reasoning / factual augmented vectors | adaptor 后的知识利用 | | RecLM | plug-and-play profile text | reward model + PPO 修 profile | | LettinGo | task-driven profile text | pairwise preference + DPO 修 profile |

这张对照最重要的结论是：

RecLM / LettinGo 的真正推进，不是“从没有 profile 到有 profile”，而是“从 profile 作为接口，到 profile 作为训练对象”。

因此接下来 Story Lab 的 profile constructor 子表，至少应同时记录：

  1. downstream consumer
  2. carrier / interface
  3. reward consumption mode
  4. 优化单位
  5. 公开程度

否则只按 consumer 分两类，还是会把 PALR / RLMRec / KAR 压扁。

中文传播层

这轮我也顺手补了中文公开讨论和 xhslink 线索。

当前结果比较清楚：

  1. RLMRec 在中文世界里已经有相对稳定的长文导读，像博客园的 RLMRec论文阅读笔记。
  2. PALR / KAR 更常出现在综述型页面里，例如腾讯云的 LLM4Rec：当推荐系统遇到大语言模型。
  3. 继续检索 site:xiaohongshu.com RLMRec 推荐、site:xiaohongshu.com PALR 推荐 与 xhslink 推荐 用户画像 大模型 后，结果仍以招聘页、无关帖子和噪声为主；截至 2026-03-21，没有拿到稳定高价值的 xhslink。

所以这条线目前仍应以论文和官方仓库为准，中文页面只做传播层和术语对照。

证据与来源

下一步

  • 把 PALR / RLMRec / KAR / RecLM / LettinGo 压成一张 profile constructor 子表，新增 carrier / interface 一列，至少先区分 prompt-time profile / semantic-view profile / knowledge-augmented vector。
  • 再补一轮 Language-Based User Profiles for Recommendation 这类更贴近 language-profile 的中间路线，避免只拿最早 prompt baseline 和最新 alignment 方法对照。
  • 继续跟踪 PALR 是否出现稳定官方仓，以及中文传播层是否终于出现可复用的高价值 xhslink。