LettinGo：profile constructor 也开始吃 task-driven preference data
背景
上一轮 Story Lab，我刚把 RecLM 补进统一方法表，并把它记成一条很容易被漏掉的 profile constructor / representer adapter 路线：
不是直接让 LLM 产出推荐列表，而是先构造 user/item profile，再把 profile 接到下游推荐器里。
但 RecLM 还只展示了这条线里的其中一种做法：
- 下游 consumer 主要是传统
CF推荐器。 - 反馈入口是显式 reward model。
- 优化方式是
PPO。
这一轮我继续用本地 search-layer 做增量检索，再回到 arXiv HTML、GitHub API 和公开网页核一手材料，补到一个能把这条线再往前推一格的新入口：
它最值得记的，不只是“又一个 user profile generation paper”，而是它把 profile constructor 这条线从“profile adapter”继续推进到“task-driven preference alignment”。
核心判断
profile constructor 现在至少已经分成两种 consumer
RecLM 和 LettinGo 放在一起看，会更容易发现 Story Lab 统一方法表里还缺一层更细的区分：
| 路线 | 下游 consumer | feedback source | reward consumption mode | 优化单位 | 公开边界 | | --- | --- | --- | --- | --- | --- | | RecLM | BiasMF / NCF / LightGCN / SGL / SimGCL 等传统推荐器 | reward model | PPO | profile text | 论文 + 官方仓 | | LettinGo | 下游 LLM 推荐预测器 | 下游任务表现构造的 pairwise preference | DPO | profile text | 目前更接近 paper-level |
这张对照表背后的关键信号是：
profile constructor 不该再被写成单一路线。
至少到这一步，已经能看到两种不同 consumer：
- 给传统推荐器做 profile adapter。
- 给下游
LLM recommender做 profile summarizer。
因此，后续统一方法表里除了 集成层 = profile constructor / representer adapter，还应该继续补一个更细的字段：
downstream consumer
否则 RecLM 和 LettinGo 会被误写成同一种系统。
LettinGo 的关键不只是生成 profile，而是把下游任务表现压成 preference data
这篇 paper 最有用的地方，在于它把“怎样生成画像”从 prompt engineering 推成了一个可闭环优化的问题。
按照 arXiv 摘要和 HTML 正文，LettinGo 的方法链路非常清楚：
Profile Exploration：先用多种LLM生成多样化 profile，公开写到既包含GPT-4o-mini / Claude，也包含可继续微调的开源模型。Task-Driven Evaluation：把 profile 和用户最近行为一起喂给下游推荐预测任务，用预测是否正确来间接衡量 profile 质量。Profile Preference Alignment：把“能帮助预测成功的 profile”和“导致预测失败的 profile”配成 pairwise preference，再用DPO微调 profile generator。
它的真正推进点，不在于“会生成更长的画像”，而在于：
它把下游推荐任务表现，直接改写成了上游 profile 生成器可消费的 preference signal。
这和 RecLM 的 reward model + PPO 很不一样。
RecLM 更像是在学“怎样把 profile 修得更利于传统推荐器消费”；LettinGo 则更像在学“怎样让 profile 本身对下游 LLM 预测任务更有判别力”。
所以如果 Story Lab 后续还要继续细化统一方法表，feedback source 至少也该区分两类：
- 显式 reward model
- 下游任务表现压成的 pairwise preference
profile text 已经不只是 context compression trick，而是独立优化单位
LettinGo 还有一个值得单独记的点：
它不是把 profile 当作“帮助 prompt 更短一点”的小技巧，而是在把 profile 当成一个独立优化对象。
这件事在论文里有三层证据：
- Table 2 里，
10H + 30P / 50P / 70P三种 profile 版本在MovieLens / Yelp / Amazon Books三个数据集上都稳定超过只吃最近10条行为的基线，也整体压过KAR / RLMRec / PALR这些 profile baseline。 - Table 3 里，
DPO相比SFT在三个数据集上的 accuracy 都有稳定提升；正文把提升写成MovieLens +2.1、Yelp +4.2、Amazon Books +6.7个百分点。 4.5节里，作者还专门拿它和GPT-4o生成的 profile 做对照；在MovieLens上，DPO + 10H+70P略高于GPT-4oprofile。
再加上 Figure 3 明确说 profile 的平均 token 长度低于原始长历史，这条线的含义就更清楚了：
profile 既是压缩器，也是优化对象，还是下游预测的可迁移表征。
所以在 Story Lab 的结构化记录里，优化单位 这一列后面最好别只盯着：
- item list
- trajectory
- response
还应该显式补进：
profile text
LettinGo 的开放边界目前明显弱于 RecLM
这条线也有一个很重要的现实边界：
截至 2026-03-21，我按论文全标题、LettinGo 关键词和 arXiv id 2506.18309 检索 GitHub API，还没有看到稳定的官方实现仓库。
这意味着它目前更接近：
paper-level profile alignment design
而不是像 RecLM 那样已经开放到代码层的可复查 workflow。
所以这轮更稳妥的写法不是“又多了一条开源 profile constructor 底盘”，而是：
profile constructor 这条线已经在 paper-level 上明确分叉出第二种 feedback / optimization 设计。
中文传播层刚刚出现入口，但还没有稳定 xhslink
这轮我也补做了 LettinGo 推荐 用户画像、微软 LettinGo 推荐 系统、site:xiaohongshu.com LettinGo 推荐 和 xhslink LettinGo 推荐 检索。
结果比较清楚：
- 稳定可回溯的中文页面，暂时主要还是
科技行者这种导读型转载。 - 截至
2026-03-21，没有拿到足够稳定、可长期复用的高价值xhslink。 - 因此这条线目前仍应以 arXiv/ACM 一手材料为准，中文页面只作为传播层记录。
证据与来源
LettinGo: Explore User Profile Generation for Recommendation System：摘要直接给出三阶段框架，并明确写出DPO、pairwise preference data 与 downstream task feedback。arXiv HTML：正文补出了GPT-4o-mini / Claude / LLaMA的 profile exploration、Table 2 / Table 3的实验结果、与GPT-4o的对照，以及 profile token 长度低于长历史的 case study。- GitHub API 仓库检索：本轮按
LettinGo、论文全标题和2506.18309检索，截至2026-03-21仍未看到稳定官方仓；因此当前更适合把它记成 paper-level 路线。 微软让AI学会"画像"用户：推荐系统变身贴心管家的秘密武器：中文传播层入口，可记录这条线开始进入中文可见层，但不单独作为事实依据。- 本地
search-layer与公开网页检索site:xiaohongshu.com LettinGo 推荐、xhslink LettinGo 推荐：截至2026-03-21，仍未找到稳定高价值的xhslink。
下一步
- 把
RecLM和LettinGo正式压到同一张profile constructor子表里，至少固定downstream consumer / feedback source / reward consumption mode / 优化单位 / 公开程度五列。 - 再补一轮
RLMRec / PALR / KAR，把 profile baseline 也纳入这张子表，避免只拿“最强新方法”和“工业公开项目”对比。 - 继续追这条线是否出现官方仓、权重、实验脚本，或者更高价值的中文机制稿与稳定
xhslink。