DeepRec：black-box bridge 开始长成多轮 reasoning-retrieval loop

背景

补完 Rec-R1、Rank-GRPO 和 RecLM 之后，我原本已经把推荐里的几个关键系统位置先粗分成三类：

  1. LLM 直接围着固定推荐器做 closed-loop optimization
  2. LLM 先生成或排序候选，再由推荐系统消费
  3. LLM 负责生成 profile，把它接回传统推荐器或下游 LLM 推荐器

但这轮继续往 black-box bridge / retrieval loop / tool-use recommendation 下钻后，我发现还有一个此前没有被明确写出来的中间层。

真正值得补进 Story Lab 的，不是又多了一篇“LLM 做推荐”的论文，而是 LLM 和传统推荐模型之间的接口，已经从一次性交互推进成了可被 RL 直接训练的多轮工具回路。

这轮我重点核了两个一手入口：

  1. DeepRec: Towards a Deep Dive Into the Item Space with Large Language Model Based Recommendation
  2. RUCAIBox/DeepRec

它给出的信息，正好把当前 Story Lab 里 black-box bridge 和 profile interface 之间那段还没讲清的系统缝补上了。

核心判断

DeepRec 不是普通的 retrieve-then-rank，而是 LLM <-> TRM 的多轮 reasoning-retrieval loop

DeepRec 最值得单独记住的一点，不是它也用了 RL，而是它把 TRM 真正放进了 LLM 的推理轨迹里。

更准确地说，它不是：

  1. 先让推荐器一次性召回候选
  2. 再让 LLM 做一次重排

它的核心结构是：

  1. LLM 先根据用户历史和当前已拿到的 item，生成一段新的偏好描述
  2. TRM 再根据这段偏好描述继续检索 item
  3. 这个过程可以多轮重复
  4. 最后 LLM 再对聚合后的候选做最终排序

论文自己的对比图也把这点写得很清楚：

  1. 传统 LLM-enhanced TRM 更像 feature/data enhancer
  2. TRM-enhanced LLM 更像一次性 candidate provider
  3. LLM as RS 则直接让 LLM 端到端生成
  4. DeepRec 则显式新增了 autonomous 的多轮交互层

所以这条线最重要的增量不是“性能又涨了多少”，而是：

black-box bridge 现在已经不只是一跳闭环，它开始长成真正的 tool-use loop 了。

这里的自然语言偏好，不是持久 profile，而是调 TRM 的临时 query interface

DeepRec 和我前面补过的 RecLM / LettinGo / LangPTune 有一个特别关键的差别：

它中间生成的自然语言偏好，并不是为了被长期存下来做用户画像。

相反，这段文本更像：

给 TRM 用的一次性检索接口

论文 2.3 里写得很明确：作者专门引入了一个 preference-aware TRM，让传统推荐模型不只吃用户历史，还同时吃 LLM 生成的 textual user preference，再把两者融合成用户表示。

这件事非常重要，因为它说明推荐里的自然语言偏好至少已经分成了两种完全不同的系统角色：

  1. persistent profile carrier
  2. ephemeral tool query interface

前者更接近 RecLM / LettinGo / PURE / TETUP 这些画像路线。

后者则更接近 DeepRec 这种：

偏好文本只是 trajectory 里的中间控制信号

也就是说，profile text 在推荐里不一定是“最终要存下来的状态对象”。

它也可以只是 LLM 用来调推荐工具的一种工作语言。

这对 Story Lab 的价值很大，因为它把此前看似分开的两张表连接了起来：

  1. profile constructor 子表
  2. black-box bridge / tool-use 主表

这条 RL 不是只盯最终推荐结果，而是在训练 bridge 本身

DeepRec 另一点特别值得记，是它的 reward 设计明显不是普通“最终列表好不好”。

论文明确把 reward 拆成两层：

  1. process-level rewards
  2. outcome-level rewards

其中 process 这一层，监督的根本不是推荐准确率，而是这条 LLM <-> TRM 交互回路本身。

作者明写了三类过程奖励：

  1. generation format reward
  2. invocation count reward
  3. preference diversity reward

也就是说，它不仅要求模型给出更好的 item list，还要求模型：

  1. 会按规范调用工具
  2. 不要乱调工具，也不要完全不调
  3. 每一轮生成的偏好描述要真的有增量，而不是机械重复

而 outcome 这一层才回到推荐质量本身，包括：

  1. point-wise reward
  2. list-wise reward

这里最值得记住的变化是：

RL 已经开始直接监督“桥是怎么走的”，而不只是监督“桥那头的结果对不对”。

这比单纯记成 PPO / GRPO / DPO 更有解释力。

两阶段 RL 和 TRM-based data selection 说明，混合系统的可学边界首先受工具能力约束

DeepRec 的训练设计还有两个细节特别值得记。

第一个是两阶段训练：

  1. cold-start RL
  2. recommendation-oriented RL

第一阶段主要学会怎么和 TRM 打交道。

第二阶段才进一步优化推荐效果。

这已经说明一个事实：

LLM 在推荐里学 tool-use，不一定能和最终效果优化在同一锅里一次训完。

更关键的是，论文消融还专门指出：

如果把这些 reward 粗暴混成 single-stage RL，性能反而会掉。

作者的解释也很直接：

invocation count 和 preference diversity 容易诱发 reward hacking，让模型沉迷于“多调用几次”或“把偏好改得更花”，而不是认真提升推荐质量。

第二个细节是 TRM-based data selection。

论文会根据 TRM 自己给 label item 的 rank 来过滤数据，直接丢掉 rank 高于 100 的过难样本。

这个设计背后的判断也很重要：

混合式 LLM-RL 推荐的训练难度，不能只按 LLM 会不会来定义，还要按工具本身的 recall ceiling 来定义。

这意味着 Story Lab 后续在记 tool-use 或 black-box bridge 路线时，除了记模型、reward 和优化算法，可能还要再补一条：

tool competence assumption

否则像 DeepRec 这种方法的训练边界会被写得过于乐观。

公开边界已经到了底盘层，但复现门槛仍然很高

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

更稳的说法是：

  1. 论文 arXiv v2 更新时间是 2025-05-26
  2. 论文正文已经直接给出官方仓 RUCAIBox/DeepRec
  3. GitHub API 显示仓库创建于 2025-05-26 08:31:17 UTC
  4. 最近一次代码 push 也是 2025-05-26 08:29:56 UTC

说明它更像：

论文与官方仓同日对外发布的一次性开源

而不是一个后续长期高频维护的工程项目。

但它也绝对不只是占位仓。

当前公开内容已经包括：

  1. openrlhf/
  2. script/cold_train.sh
  3. script/rec_train.sh
  4. script/recall.sh
  5. script/reward.sh
  6. server/reward.py
  7. evaluation/metric_calc_rec.py

README 还把这些复现前置条件直接摆出来了：

  1. 数据集从 Google Drive 下到 data/
  2. preference-aware TRM 权重下到 server/
  3. reward server 和 recall server 要单独起
  4. 再分别跑 cold-start 和 recommendation-oriented 两阶段训练

但这不能被写成“开箱即用复现栈”。

原因也非常明确：

训练脚本默认就是：

  1. 2 个 8-GPU 节点
  2. Ray 作业提交
  3. 独立 reward/recall server
  4. Qwen2.5-7B base model
  5. vLLM 和 deepspeed

所以更准确的表述应该是：

DeepRec 已经公开到底盘层，但它是“可复查的高门槛底盘”，不是低门槛 demo。

中文传播层目前很弱，而且被同名 DeepRec 稀疏引擎严重污染

这轮中文检索里还有一个很实际的问题：

DeepRec 这个名字本身就是高噪声关键词。

继续补做：

  1. DeepRec 推荐 大模型 中文
  2. site:xiaohongshu.com DeepRec 推荐 大模型
  3. xhslink DeepRec 推荐

结果大部分都会先回到：

  1. 阿里巴巴那个同名的大规模稀疏训练推理引擎
  2. 和推荐论文无关的中文旧文章
  3. 招聘页
  4. AI 自动摘要页面

截至 2026-03-21，我没拿到稳定高价值的中文机制稿，也没有拿到可复用的稳定 xhslink。

目前相对还算可见的中文页面，只能回溯到 Moonlight 的 AI 评述页。

但这种页面更像自动生成摘要，不适合单独当作事实依据。

所以这条线当前仍应主要依赖：

  1. arXiv 论文
  2. 官方 GitHub
  3. GitHub API
  4. 训练脚本与 README

证据与来源

  • DeepRec: Towards a Deep Dive Into the Item Space with Large Language Model Based Recommendation：摘要与 2.3-2.5 节明确写出 autonomous multi-turn interactions between LLMs and TRMs、preference-aware TRM、hierarchical rewards 与 two-stage RL training strategy。
  • DeepRec 论文 PDF：正文进一步给出 process-level 的 format / invocation count / preference diversity 奖励、outcome-level 的 point-wise / list-wise 奖励，以及 TRM-based data selection 会过滤 label rank 大于 100 的过难样本。
  • RUCAIBox/DeepRec：官方仓 README 明确公开了 retrieval server -> cold-start RL -> recommendation-oriented RL -> evaluation 的完整流程，并给出数据集与 preference-aware TRM 权重下载入口。
  • GitHub API 对 RUCAIBox/DeepRec 的核验：截至 2026-03-21，仓库创建于 2025-05-26 08:31:17 UTC，最近一次代码 push 为 2025-05-26 08:29:56 UTC；仓库树已可见 openrlhf/、script/、server/ 与 evaluation/。
  • 官方训练脚本核验：script/cold_train.sh 与 script/rec_train.sh 默认配置为 2 个 8-GPU 节点、Ray 作业、独立 reward/recall server、Qwen/Qwen2.5-7B base model；这说明它公开到了系统底盘层，但复现门槛仍高。
  • 本地 search-layer 与公开网页检索 DeepRec 推荐 大模型 中文、site:xiaohongshu.com DeepRec 推荐 大模型、xhslink DeepRec 推荐：截至 2026-03-21，结果主要被阿里同名 DeepRec 引擎、招聘页和 AI 自动摘要页污染，没有拿到稳定高价值中文机制稿或可复用 xhslink。

下一步

  • 把 DeepRec 和 Rec-R1 / Rank-GRPO / RecLM 放到一起，补一条新的观察维度：interaction depth / tool query interface，先区分 single-shot bridge 与 multi-turn reasoning-retrieval loop。
  • 在 profile constructor 子表的备注里，新增一类不是持久画像的 ephemeral preference query，避免把 DeepRec 这类中间控制信号误写成普通 profile。
  • 继续补 tool-use recommendation / autonomous retrieval / LLM TRM interaction 相关路线，判断公开世界里是否还存在第三种不是 one-shot bridge、也不是 profile adapter 的混合接口。