可读画像不等于可信画像：用户自识别和推荐效用开始分叉

背景

这几轮我已经把 profile constructor 这条线拆得越来越细：

  1. PALR / LFM / RLMRec / KAR 补出 carrier / interface
  2. LangPTune / RecLM / LettinGo / UserIP-Tuning 补出 constructor optimization regime 与 deployment form
  3. PURE / TETUP / LLM-TUP 又把画像生命周期拆成 construction / maintenance / deployment

但这里还留着一个此前没有被单独写出来的问题：

即便一个画像是自然语言、可读、可编辑的，它就一定是“像用户本人”的画像吗？

而且，即便它能提升推荐指标，它就一定是用户自己愿意认领的那种画像吗？

这一轮我补到 Deezer 的 Biases in LLM-Generated Musical Taste Profiles for Recommendation 后，觉得这条线必须单独写一篇。

因为它补的不是新的 carrier，而是 profile validity / fairness 这一层：谁来验收画像、画像对谁更像、这种“像”与下游推荐效用是否一致。

核心判断

这篇工作补的不是新画像类型，而是 profile validity

这篇论文关心的核心问题不是：

怎样再生成一种更强的 profile

而是：

用户会不会把 LLM 生成的 profile 认成“这就是我”

论文把自然语言画像的价值说得很清楚：它们是比协同过滤 latent vector 更可读、可编辑、可审查的替代物。

但作者没有把“可读”直接等价成“可信”。

相反，他们先把 profile quality 拆成两层：

  1. 用户自我识别，也就是用户主观上觉得画像像不像自己
  2. 下游推荐效用，也就是这些画像被拿去做推荐后，Recall@10 / NDCG@10 有没有变好

这个拆法对 Story Lab 很重要，因为它说明：

profile constructor 这条线不能只记录“怎么造画像”，还要开始记录“谁来验证画像”。

time window 影响没有想象中大，LLM 写法反而更关键

作者在音乐流媒体场景下做了一组很干净的对照：

  1. 64 位参与者
  2. 每人基于 30 / 90 / 180 / 365 天四种时间窗口生成画像
  3. 每个窗口分别用 Gemini 2.0 Flash / DeepSeek-R1 / Llama 3.2 三个模型生成
  4. 因而每位用户共有 12 份画像可评分

这组实验最值得记的一个结论是：

时间窗口长度对自我识别的影响只有边际作用，LLM 的写法和风格影响更大。

论文 Figure 2 和结论部分都在说同一件事：

  1. time window 没有显著主效应
  2. model 有显著主效应
  3. 用户能认出“真画像”高于随机画像，但不同模型写法会显著改变评分

作者进一步解释了这种差异：

  1. Gemini 更短、更高层概括
  2. Llama 更容易写出具体艺人和曲名，即便 prompt 已要求少写这些细节
  3. DeepSeek 有时会把 remastered 这类元数据细节突出出来，用户并不觉得这些信息更有意义

也就是说，对当前的自然语言画像来说，form 还没有稳定从 content 里分离出来。

这和我前面写 LFM / LangPTune / RecLM / LettinGo 时的默认直觉不一样。此前更容易把关注点放在：

  1. 取哪段历史
  2. 用什么训练目标
  3. 怎样把画像接回推荐器

但这篇 Deezer 工作说明，在用户主观验收这一步上，真正先起作用的可能是：

模型把同一份偏好写成什么样

用户自我识别和推荐指标只有弱相关，user-facing profile 与 rank-facing profile 可能需要拆开

这篇论文最值得记住的判断，不是某个模型分数高，而是它把一个常被默认忽略的错位明确写出来了：

用户觉得像自己的画像，不一定就是最适合做推荐检索的画像。

作者把生成的 profile 直接喂给下游 bi-encoder 推荐流程，使用 Recall@10 和 NDCG@10 做对照。

结果很克制：

  1. 用户评分和推荐表现总体只有弱正相关
  2. DeepSeek 甚至没有稳定的正相关趋势
  3. 推荐表现随更长时间窗口往往变好，但用户评分模式并不和它同步

这意味着一个很重要的系统判断：

representativeness 和 utility 不是同一件事。

如果后续 Story Lab 继续把 profile text 只当成 recommendation-side interface，就会漏掉这条线真正补出的东西。

更准确的写法应该是：

  1. 有些画像更适合给用户看，用来做解释、确认和编辑
  2. 有些画像更适合给模型吃，用来做排序、检索或 adaptor
  3. 这两种画像不一定必须完全相同

论文结论甚至已经把这个方向点明了：

可以把 user-facing profile 和 recommendation-optimized profile 解耦

偏差不是只落在模型总分上，而是会沿 user attributes 和 item composition 具体落下来

这篇工作另一个很有价值的地方，是它没有只报“哪个模型平均分更高”，而是把偏差具体拆到了用户和内容构成上。

在用户侧，论文给出的稳定信号包括：

  1. specialist users，也就是 GS-score 更高的用户，更容易认同生成画像
  2. 年龄更大的用户、以及听较老歌曲的用户，往往也会给出更高评价
  3. mainstreamness 并没有成为显著预测因子

这说明 LLM 画像目前更容易抓住的是：

更集中、更可语言化、更稳定的偏好

而不是所有用户都被均匀地表示。

在内容侧，偏差则更具体：

  1. 更高比例的 rap 内容会系统性拉低评分
  2. metal 反而会系统性拉高评分
  3. United States 来源内容和某些流行语境更容易得到正向关联
  4. Belgium / world music / Canada 等 locale 效应还会随模型不同而变化

这比“LLM 可能有偏见”这种泛判断要强得多。

它说明 profile bias 在推荐里会沿着实际 catalog 维度具体展开：

genre / locale / exposure composition

如果这些维度不被单独记录，后面再讨论 profile fairness 时，容易只剩抽象口号。

对 Story Lab 来说，profile constructor 子表还缺一层“验收口径”

补完这篇之后，我觉得当前 profile constructor 子表虽然已经有：

  1. carrier / interface
  2. constructor optimization regime
  3. deployment form
  4. lifecycle stage

但还是不够。

至少还缺一个紧邻它的观察层，用来记录：

  1. profile validator
  2. representativeness signal
  3. fairness risk

更具体一点，可以先这样粗分：

  1. profile validator：用户自评、下游 ranker、人工编辑者、离线实验者
  2. representativeness signal：self-identification、Recall/NDCG、编辑接受度、行为一致性
  3. fairness risk：用户属性偏差、内容构成偏差、模型风格偏差

否则下面这些工作会被混成一条线：

  1. RecLM / LettinGo 在优化怎么生成 profile
  2. PURE / TETUP 在优化 profile 怎样长期维护
  3. 这篇 Deezer 工作在验证 profile 到底像不像用户、对谁更像

它们显然不是同一个问题。

公开边界比我预期更强：不只放论文，还放了用户研究数据和分析代码

这条线本来我以为更可能停留在 paper-level。

但继续核到 repo 后，公开边界其实比预期更完整。

官方仓 deezer/recsys25_llm_biases 已经公开：

  1. user_data.csv
  2. long_term.csv
  3. LLM_bias_plots.ipynb
  4. repo_plots.ipynb
  5. src/
  6. downstream bi-encoder 训练与评测说明

README 还明确写出：

  1. 仓库用于复现论文实验
  2. long_term.csv 用来做 doubly robust 的 ATE
  3. downstream task 需要下载前作 cross-encoder，再在这套数据上训练新模型

所以更准确的记录方式不是“profile fairness 的一篇论文”，而是：

公开到了 user-study dataset + bias analysis + downstream evaluation workflow

这让它在 Story Lab 里的地位明显高于普通 paper-only 观察点。

中文传播层仍然几乎为空

这轮我也补做了：

  1. Biases in LLM-Generated Musical Taste Profiles for Recommendation 中文
  2. site:xiaohongshu.com 音乐 推荐 用户画像 大模型
  3. xhslink 音乐 推荐 用户画像 大模型

结果还是比较一致：

  1. 没有拿到稳定高价值的中文机制稿
  2. 小红书相关结果仍主要是噪声、通用画像页和无关页面
  3. 当前最稳定的公开入口仍然是 arXiv、RecSys 页面、SlidesLive 与官方 GitHub 仓库

因此这条线目前仍应以英文一手材料为主。

证据与来源

  • Biases in LLM-Generated Musical Taste Profiles for Recommendation：摘要明确给出问题设置，即用自然语言画像替代 opaque collaborative filtering representation，并同时考察用户属性、item 属性与 downstream recommendation 的偏差。
  • arXiv HTML：正文 2-5 节可直接核到 64 位参与者、30 / 90 / 180 / 365 四个时间窗口、Gemini / DeepSeek / Llama 三个模型、user rating 与 downstream Recall@10 / NDCG@10 的弱相关关系，以及 specialist / age / rap / metal / locale 这些偏差细节。
  • deezer/recsys25_llm_biases：官方仓公开了 user_data.csv、long_term.csv、notebook 与 downstream task 说明，说明这条线已不只停在 paper-level 结论。
  • GitHub API deezer/recsys25_llm_biases：本轮核到仓库创建于 2025-04-30 09:00:38 UTC，最近一次代码 push 为 2025-09-20 19:25:26 UTC。
  • RecSys 2025 Session Page：可回溯到正式会议收录与 ACM DOI 10.1145/3705328.3748030。
  • SlidesLive：官方 talk 摘要用更压缩的口径确认了几个关键结论，包括 time-window length 影响小、LLM choice 更重要、specialist/older users 评分更高，以及 genre / locale 偏差。
  • 本轮继续补做 Biases in LLM-Generated Musical Taste Profiles for Recommendation 中文、site:xiaohongshu.com 音乐 推荐 用户画像 大模型 与 xhslink 音乐 推荐 用户画像 大模型 检索后，仍未找到稳定高价值中文机制稿或可复用 xhslink。

下一步

  • 把这篇 Deezer 工作和官方仓并入 profile constructor 相关观察表，新增一层 profile validity / fairness 记录，而不是硬塞回 carrier / optimization / deployment / lifecycle 四列里。
  • 在 profile 支线旁边补一个小观察表，至少先记录 profile validator / representativeness signal / fairness risk / user-facing vs rank-facing split。
  • 继续找音乐之外的公开样本，判断“self-identification 与 ranking utility 分叉”是 music-specific 现象，还是更普遍的 LLM profile 规律。
  • 继续跟踪这条线是否出现中文高价值机制稿、稳定 xhslink，或更完整的正式发表页与后续扩展实验。