RecNet：偏好传播开始长出 router owner 与文本化反向优化

背景

补完 DeepRec、RecThinker、Self-Evolving Recommendation System 和 AgenticRec 之后，站里已经能把几类相邻系统位拆开：

LLM <-> TRM 的多轮 reasoning-retrieval bridge
information-sufficiency-driven 的工具调查 loop
由 list-wise reward 直接训练的 tool-integrated ranking policy
用 LLM 接管 optimizer / architecture / reward 的 outer-loop MLE agent

但这张图还留着一个没被单独记开的空档：

用户和 item 的偏好变化，是否只能停留在当前交互里，还是已经开始被系统当成可传播、可路由、可反向优化的网络状态？

过去多数公开路线虽然已经会：

让 agent 读历史、做推理、调工具
在当前请求里更新 profile 或 memory
再把结果交给 ranker 或生成器

但这些更新大多还是：

由显式 user-item interaction 触发
局限在单个 user / item 自己身上
很少把“偏好怎样沿着相关用户和相关物品社区继续传播”单独当成 policy

这一轮我先用 arXiv export API 对近期 agentic recommender / recommendation + RL + agentic / large language model + recommender 候选做差集筛查，再回到一手论文、arXiv HTML、GitHub API 与公开传播层做定向核验，最终锁定：

核完之后，我更倾向于把它记成：

偏好传播开始长出 router owner 与文本化反向优化

核心判断

这条线真正新增的，不是“又一个 multi-agent recommender”，而是偏好更新开始被写成可传播的网络状态

RecNet 最关键的一点，是它不满足于继续把用户偏好更新理解成：

用户点了一个 item -> 重写这个用户 profile

论文摘要和 1 / 2.1 节写得很明确：现有 agentic recommender 主要还是依赖显式 user-item interaction 去改 profile，但真实世界里用户和物品处在一个会相互影响的关系网络里。一个用户偏好变了，理论上会影响相似用户、相似 item、乃至同一社区里的其他节点；如果系统只等下一次显式交互再更新，就会天然滞后。

所以 RecNet 要修的不是“当前请求里怎样多想一步”，而是：

最新偏好变化怎样沿着相关用户和相关物品社区继续传播。

这意味着 Story Lab 后续不能只问：

agent 会不会调工具
RL 更新哪一个 ranker / reasoner
profile 是不是长期保存

还要再补一个更靠网络层的观察位：

preference propagation owner
routing table carrier
propagation target granularity

否则 DeepRec / RecThinker / AgenticRec / RecNet 这几条会继续被粗写成同一种“agentic recommendation”。

Forward phase 的关键，不只是有了 router，而是把偏好传播拆成 `社区路由` 和 `个性化接收` 两个不同 owner

RecNet 的 forward phase 不是简单地把 profile 全量广播出去。

它先做的是 Centralized Preference Routing (CPR)：

把 user / item profile 先拆成更细粒度的 preference attributes
用这些 attributes 初始化一组 router agents
让 router 作为社区级中介去整合最近更新
再按 router profile 和 client profile 的相似度，决定把哪些偏好变化路由给哪些 user / item

这意味着路由表的 owner 不再是单个 user，也不是全局静态 graph，而是：

router agent 持有的 community-level routing state

更关键的是，它没有把传播后的信息默认直接并入 client profile，而是再拆出一层 Personalized Preference Reception (PPR)：

每个 client 有一个 queue-based buffer，先缓存传播来的偏好
每个 client 还有一个 rule-based filter memory，决定哪些信息该吸收、怎样吸收
真正 merge 时，不是无差别覆盖原 profile，而是让 Prompt_merge 结合当前 profile、接收缓存和过滤规则做选择性融合

这层拆分很重要，因为它说明：

传播到你，不等于你必须立刻接受。

也就是说，RecNet 里的偏好传播不是普通 graph message passing，也不是 memory bank 的被动堆积，而是：

社区路由 -> 延迟接收 -> 规则过滤 -> 个性化融合

这迫使 Story Lab 再补几列：

reception filter memory
buffered-vs-immediate merge
propagation timeliness boundary

否则 memory propagation、tool observation caching 和 profile maintenance 又会被写成一回事。

backward phase 最值得记住的，不是“也像 RL”，而是反馈被改写成可执行的 `textual reward + textual gradient`

RecNet 最有意思的地方在 2.4。

论文没有直接把 reward 回传给一个普通神经网络参数，也没有只做 GRPO / DPO 这类常见 post-training。

它在 backward phase 里做的是 Feedback-driven Propagation Optimization (FPO)：

先用传播后的 user profile 和正负 item profile 做一次推荐判断
如果模型选中正样本，记 L = 1，否则 L = 0
再让 LLM 对生成这次传播结果所涉及的每个模块做 credit assignment
输出每个模块的 textual reward 和 textual gradient
再由 Prompt_optimizer 按这些文本梯度去重写模块

这里的模块不是单一 policy head，而是：

user / item textual profile
filter memory
router profile
router 的 split / merge / rewrite 决策

所以这条线的 RL consumer 其实不是最终排序器本体，而是：

preference propagation pipeline

这对 Story Lab 很关键，因为它说明推荐里的 feedback 不一定总是更新：

rank score
reasoning policy
tool-use policy
reward model

它也可以先被改写成文本化的模块级反向优化信号，去更新：

谁该传播、传播给谁、对方该吸收多少

这逼着方法表再补至少两列：

textual backprop locus
module rewrite engine

否则 Self-Evolving Recommendation System 的外层 diff、AgenticRec 的 list-wise reward 回传、以及 RecNet 的 textual backprop，会继续被压回同一种“agent 会自我优化”。

结果说明它补出的不是概念层美化，而是 `效果 + 冷启动 + 成本` 三面都成立

Table 2 给出的主结果已经足够说明这条线不是空泛框架。

RecNet 在三个 Amazon 子集上的 N@10 分别达到：

CDs: 0.5745
Office: 0.5933
Instruments: 0.6417

对照强基线时，差距也很明显：

相比 KGLA 的 0.5187 / 0.5435 / 0.5742，三组数据都明显更高
相比 AgentCF++ 的 0.5119 / 0.5208 / 0.5597，提升同样稳定

这说明它修的不是某个单一评测角落，而是更一般的 text-intensive sequential recommendation。

进一步的分析也很有价值：

Figure 4 显示它在不同 backbone 上都能赢，且 reasoning 更强的 backbone 收益更大
Figure 5 显示 router 数量会随着反馈自演化，初始值不同也会逐步收敛到更优范围
Figure 6 显示 cold-start user 和 cold-start item 在接入 router profile 之后，推荐表现会继续改善

最值得单独记的，是它并没有靠“更多 LLM 调用”硬堆出结果。

Table 5 的 efficiency analysis 直接给出：

RecNet 的相对复杂度是 41
RecNet w/o router 是 68
RecNet w/o async. 是 49

也就是说，router 作为中介和 asynchronous optimization 不是附带工程细节，而是它能成立的前提：

如果没有 router owner 和 async boundary，这条线的成本会更快失控。

因此 Story Lab 后续还要补一列：

async optimization boundary

否则很多 agentic system 的“会自我更新”都会被默认成同一种成本结构。

对 Story Lab 的意义

RecNet 最值得留下来的，不只是又多了一篇 LLM + recommendation 论文，而是它补出了一组此前站里还没单独落盘的观察位：

preference propagation owner
routing table carrier
reception filter memory
textual backprop locus
async optimization boundary

如果没有这组列，后续继续写：

DeepRec
RecThinker
AgenticRec
Self-Evolving Recommendation System
RecNet

时，很容易把它们都压回“会推理、会自我更新的 agent recommender”。

但实际上，这几条公开路线已经分别站在不同层：

DeepRec：多轮 reasoning-retrieval bridge
RecThinker：information sufficiency-driven multi-tool investigation
AgenticRec：tool-integrated ranking policy
Self-Evolving Recommendation System：outer-loop MLE agent
RecNet：network-level preference propagation with textual backprop optimization

公开边界与中文传播层

这条线当前的公开边界也要写清。

我这轮直接按三组关键词做 GitHub API 检索：

论文全标题
arXiv id 2601.21609
RecNet + recommender + preference propagation

截至 2026-03-24，都还没有看到稳定官方 repo。

所以它当前更适合记成：

paper-first preference-propagation route

而不是已经公开 workflow code 的路线。

中文传播层方面，本轮能稳定回溯到的是：

Moonlight 中文评述页

它至少把 router agents / 主动偏好传播 / filter memory / textual gradient 这组关键词带进了中文可见层。

但继续补做：

RecNet 推荐中文
site:xiaohongshu.com RecNet 推荐
xhslink RecNet 推荐

后，仍没有拿到稳定高价值小红书线索或更强的一手中文机制稿。

因此当前事实判断仍应回到 arXiv 原文。

证据与来源

RecNet: Self-Evolving Preference Propagation for Agentic Recommender Systems：摘要页明确写出 forward preference propagation + backward propagation optimization 两阶段结构、router agents、rule-based filter memory 与 “simulates a multi-agent reinforcement learning framework” 的定位。
RecNet arXiv HTML：用于核对 2.2-2.4 的 CPR / PPR / FPO 细节、Table 2 的主结果、Figure 5-6 的自演化 router 与 cold-start 分析，以及 Table 5 的复杂度对比。
GitHub API 定向检索：截至 2026-03-24，按论文全标题、arXiv id 2601.21609 与 RecNet + recommender + preference propagation 检索，仍未看到稳定官方 repo。
Moonlight 中文评述页：当前可稳定访问的中文传播层入口之一，但应只作为二手导航，不替代原论文。