UserIP-Tuning：prompt tuning 这档，并没有继续走可读画像

背景

上一轮把 LFM -> LangPTune -> RecLM -> LettinGo 连起来之后，我已经确认 profile constructor 子表至少要补 constructor optimization regime 这一列。

但当时 prompt tuning 还只是一个理论占位：还没找到足够像“推荐里的 profile constructor”而不是普通 prompt 技巧的锚点。

这一轮顺着这个缺口继续检索，我补到了 Prompt Tuning as User Inherent Profile Inference Machine。论文 arXiv 页面已注明“accepted by CIKM 2025”，DBLP 也能回溯到正式 DOI 10.1145/3746252.3761574；摘要同时直接给出了官方代码仓 Applied-Machine-Learning-Lab/UserIP-Tuning。

这条线值得写进 Story Lab，不是因为它又多了一种训练技巧，而是因为它把 prompt tuning 这档的系统落点说得很不一样。

核心判断

它补上的确是 prompt tuning，但对象不是可读 profile text

UserIP-Tuning 最关键的一点，是它没有沿着 LFM 那条线继续把画像做成自然语言接口。

论文摘要和 HTML 里写得很明确：

  1. 它把用户潜在画像当作 soft prompt
  2. 用 causal masks 处理画像和行为序列之间的因果关系
  3. 再用 Expectation Maximization (EM) 去推断嵌入式 latent profile

这和 LFM / LangPTune / RecLM / LettinGo 的直觉都不一样。

那些路线里，profile 至少在某个阶段还是可读文本；UserIP-Tuning 则直接把 profile constructor 放回了 LLM 语义空间里的 latent object。

所以如果后续 Story Lab 只按 optimization regime 记它是 prompt tuning，仍然不够。

更准确的描述应该是：

prompt-tuned latent profile inference

这条线最后落到的是 collaborative ID，不是 prompt 本身

UserIP-Tuning 还有一个更关键的系统判断：

它的终点不是“得到一段更好的用户画像文本”，而是把 latent profile 压成可部署的 recommendation carrier。

论文摘要和框架节都明确写到：

  1. latent profile embedding 会进入 profile quantization codebook
  2. 量化后的结果被映射成离散的 collaborative IDs
  3. 这些 IDs 会预存到 offline feature bank，供在线推荐使用

这说明 prompt tuning 在推荐里不一定通向更强的自然语言接口。

它也可能通向另一条更工业、更接近传统推荐底盘的路线：

soft prompt -> latent profile embedding -> discrete collaborative ID

这个分叉很重要，因为它说明 profile constructor 子表里：

  1. constructor optimization regime
  2. carrier / interface

这两列不能互相代替。

同样都是 prompt tuning，最后得到的可能是：

  1. prompt-time 自然语言 carrier
  2. latent semantic prompt
  3. 离散 collaborative ID

如果不把这些分开记录，就会把 UserIP-Tuning 和 LangPTune 误写成同一类方法。

它更像“部署桥”，不是 LangPTune 的轻量版

表面上看，UserIP-Tuning 和 LangPTune 都在回答“怎样训练 profile constructor”。

但它们回答的其实不是同一个问题。

LangPTune 更关心的是：

怎样让 LLM-generated user profile 直接为 downstream recommendation objective 服务。

UserIP-Tuning 更关心的则是：

怎样用 parameter-efficient 的 prompt tuning，在不把系统完全改写成生成式 profile text pipeline 的前提下，抽出一个可部署的 latent profile carrier。

因此更贴切的对照是：

  1. LFM：先把 profile 做成可读接口
  2. UserIP-Tuning：把 latent profile 做成 prompt-tuned deployment bridge
  3. LangPTune：再把 language profile 做成 end-to-end trained interface
  4. RecLM / LettinGo：把 profile generator 本身推成 reward / preference 对齐对象

这也意味着 Story Lab 里 profile constructor 主线不能只写成单线演进。

至少已经分出两条相邻但不同的路：

  1. language profile 主线
  2. latent prompt / collaborative ID 主线

它给 profile constructor 子表又补出一列

上一轮我刚确认，子表里除了 downstream consumer 和 carrier / interface，还要补 constructor optimization regime。

这一轮补完 UserIP-Tuning 后，新的缺口也变得清楚了：

还要再补一个更偏工程落地的字段：

deployment form 或 online storage form

因为对推荐系统来说，下面这些并不是一回事：

  1. 训练期的 profile 是文本、soft prompt 还是 embedding
  2. 线上真正被存储和消费的是 profile text、embedding 还是 discrete IDs
  3. 下游 consumer 是 LLM、CF encoder 还是 CTR / ranking 模型

UserIP-Tuning 的价值就在于，它把这三件事显式拆开了。

这条线已经给出真实工业落点，但证据主要还在论文与代码层

论文摘要里还有一条值得单独记的信号：

作者明确写到，这套方案自 2025-05 起已经部署在 Huawei AppGallery 的 Explore 页面，服务约 200 万 DAU。

对 Story Lab 来说，这意味着 profile constructor 这条线并不是只能留在论文和离线实验里。

但这条工业证据当前仍然主要来自论文正文 / 摘要，而不是更完整的公开工程报告；因此它更适合被写成：

paper-claimed industry deployment with public code

而不是已经充分公开的工业底盘。

公开仓已经不是占位页，但也不是开箱即用复现栈

这轮我也核了官方仓 Applied-Machine-Learning-Lab/UserIP-Tuning 的公开边界。

和一些只有占位 README 的仓不同，它已经公开了真实脚本：

  1. main3_movies_llama2.py
  2. CTR_llama2_movies.py
  3. discrete.py
  4. module*.py
  5. utils*.py

GitHub API 显示：

  1. 仓库创建于 2025-08-22
  2. 最近一次代码 push 在 2025-08-27

但它也有明显边界：

  1. README 目前几乎只有标题
  2. 目录更像一组实验脚本，而不是整理好的训练框架
  3. 代码里直接写死了 Amazon/MoviesAndTV 路径和若干 dataset-specific 入口

这意味着它更适合被记成：

repo with experiment scripts / code dump

而不是 LangPTune 那种已经明确到 data prep + training commands 的公开层级。

中文传播层有导航页，但还没有稳定高价值 xhslink

这一轮我也补做了中文传播层检索。

目前能稳定回溯到的入口主要有两个：

  1. 智源社区的中文论文摘要页
  2. 一篇搜广推论文速递型知乎帖子

但继续补做 site:xiaohongshu.com UserIP-Tuning、site:xiaohongshu.com Prompt Tuning as User Inherent Profile Inference Machine 与相关 xhslink 检索后，结果仍以账号页、无关内容和噪声为主。

所以截至 2026-03-21，这条线仍然没有拿到可复用的稳定 xhslink。

证据与来源

  • Prompt Tuning as User Inherent Profile Inference Machine：arXiv 摘要已明确写出 soft prompt、EM、profile quantization codebook、collaborative IDs、Huawei AppGallery 部署与官方代码仓链接；页面评论区同时注明“accepted by CIKM 2025”。
  • arXiv HTML：框架节明确把 latent profile 写成 soft prompts，并解释 causal masks、量化 codebook 与 offline feature bank 的系统位置。
  • DBLP 检索：可回溯到该文已以 CIKM 2025 论文形式出现，对应 DOI 10.1145/3746252.3761574。
  • Applied-Machine-Learning-Lab/UserIP-Tuning：论文摘要直接指向的官方仓。GitHub API 截至 2026-03-21 显示仓库创建于 2025-08-22 02:06:01 UTC，最近一次代码 push 为 2025-08-27 02:14:10 UTC；根目录已公开 main3_movies_llama2.py、discrete.py 与多个 module/utils 脚本。
  • 仓库原始文件检查：当前 README 极简，主脚本默认路径直接指向 CIKM20-NETE-Datasets/Amazon/MoviesAndTV，说明公开仓更像实验脚本堆栈，而不是完整复现底盘。
  • 中文传播层检索补到智源社区摘要页与知乎搜广推论文速递；site:xiaohongshu.com 与 xhslink 检索截至 2026-03-21 仍未找到稳定高价值线索。

下一步

  • 把 UserIP-Tuning 加进 PALR / LFM / LangPTune / RLMRec / KAR / RecLM / LettinGo 那张 profile constructor 子表。
  • 在子表里新增 deployment form 或 online storage form 一列，显式区分 profile text / embedding / collaborative ID。
  • 再补一轮 profile management / profile maintenance 路线，例如 PURE 这类工作，判断它们是 profile constructor 的延伸，还是另一条 memory/update loop 支线。