Self-EvolveRec：推荐器自演化开始吃方向性反馈，而不只看标量分数

背景

补完 Self-Evolving Recommendation System、RecNet 和 AgenticRec 之后，站里已经能把几类相邻的“自演化”系统位拆开：

  1. LLM 站在推荐器外层，持续改 optimizer / architecture / reward 的 outer-loop MLE agent
  2. 偏好沿 user-item 社区传播，再通过文本梯度反向更新的 router-mediated preference propagation
  3. 让 reasoning + tool use + final ranking 同吃 list-wise reward 的 tool-integrated ranking policy

但这张图仍然留着一个没被单独写开的空档：

如果演化对象就是 recommender model 本体，反馈到底还该不该只压成一个标量分数？

过去不少 open-ended code evolution 框架虽然已经脱离固定 NAS search space，但它们在推荐场景里通常还是靠：

  1. NDCG / HR / Recall 这类单轮 scalar metric
  2. 试错式 mutation
  3. 很少显式解释“为什么这个模型差”

这一轮我先用 arXiv export API 对 recommendation + user simulator、recommendation + LLM + reward、recommendation + model editing / causal / generative 等查询做标题差集，再与来源池和现有 stories 比对；对比 Improving LLM-based Recommendation with Self-Hard Negatives from Intermediate Layers、Beyond Interleaving、ConvApparel 等候选后，最终最值得补成一篇 story 的，是：

  1. Self-EvolveRec: Self-Evolving Recommender Systems with LLM-based Directional Feedback
  2. Self-EvolveRec arXiv HTML
  3. Sein-Kim/self_evolverec

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

推荐器自演化开始吃方向性反馈，而不只看标量分数

核心判断

这条线真正新增的，不是“又一个 AlphaEvolve for Recsys”，而是 directional feedback 开始替代 scalar metric-only evolution

论文摘要把问题写得很直接：

  1. 传统 NAS 仍受固定 search space 约束
  2. 新一代 LLM-driven code evolution 虽然放开到 program space
  3. 但它们在推荐里仍主要依赖 NDCG / HR 这类 scalar metrics
  4. 这类分数无法提供“为什么错”的 qualitative guidance

Self-EvolveRec 要修的不是“怎样让 LLM 再多改几轮代码”，而是：

怎样把 recommender 的失败模式从单个分数，改写成带方向的反馈闭环。

这意味着它补出的新系统位不是普通的 AutoML for recsys，而是：

feedback semantics

否则后续继续写 Self-Evolving Recommendation System / AgenticRec / RecNet / Self-EvolveRec 时，很容易把它们都压回同一种“会自我优化的推荐 agent”。

但实际上它们站在完全不同的层：

  1. Self-Evolving Recommendation System 改的是工业推荐系统的 meta-configuration
  2. RecNet 改的是 preference propagation pipeline
  3. AgenticRec 改的是 ranking trajectory 里的 tool policy
  4. Self-EvolveRec 改的是 recommender code evolution 所吃的反馈语义

user simulator 和 diagnosis tool 在这里不是重复 evaluator，而是两条不同 owner 的反馈通道

这篇 paper 最值得单独记住的一点，是它没有把 feedback 继续压成一种单一 judge。

它明确拆成两条通道：

  1. User Simulator (SIM) 提供 qualitative critique
  2. Model Diagnosis Tool (DIAG) 提供 quantitative internal verification

前者回答的是：

用户从体验上不满意什么？

后者回答的是：

模型内部到底哪一类结构性缺陷在支撑这种不满意？

仓库实现把这层拆分写得很实在。

self_evolverec.py 同时维护：

  1. researcher / coder / debugger
  2. diagnosis_researcher / diagnosis_coder

而 examples/sasrec_cds/info.json 和 info_sim_diag.json 也把两个问题分开定义：

  1. 一个负责 evolve recommender
  2. 一个负责 evolve diagnosis tools

运行时返回值也不是一团混合反馈，而是显式区分：

  1. simulator_comment
  2. diagnosis_comment

这说明这条线真正要补的不是“多一个 judge”，而是：

critique-verifier split

Story Lab 现有方法图如果不补这列，就会继续把：

  1. simulator as evaluator
  2. judge as scorer
  3. diagnosis tool as probe layer

误写成一种“评测反馈”。

更关键的是，诊断标准本身也开始共演化，不再默认固定

这篇 paper 还有一个更强的地方：

它没有把 diagnosis tool 当成永远正确、永远固定的 benchmark。

作者明确提出：

Diagnosis Tool - Model Co-Evolution

原因很直接：

  1. recommender architecture 在不断变
  2. 如果诊断指标不跟着变
  3. probe 很快就会 stale
  4. 最后又会退回“拿过时分数指挥新结构”的假闭环

5.3.4 的 case study 把这件事写得很具体。

作者故意把演化后的 SASRec 做成 order-insensitive：

  1. 去掉 positional embeddings
  2. 绕过 exponential decay 模块

随后 co-evolved DIAG 自动长出了初始诊断器里没有的新指标：

  1. Swap Sensitivity
  2. Logit Swap

它不只是说“性能掉了”，而是能把根因定位成：

order-insensitive

这意味着 Story Lab 后续在 self-evolving 路线里还要补一列：

diagnosis co-evolution

否则 固定 probe 看新模型 和 probe itself co-evolves with model 会继续被写成同一种验证范式。

planning & retrieval 的主价值，不一定是直接提分，而是防止演化退化成局部 patching

这篇 paper 还有一个很值得记的细节：

feedback-aware planning & retrieval

Table 5 给出一个相当反直觉的结果：

  1. 去掉 planning 之后，CDs 上的 NDCG@5 甚至从 0.3865 变成 0.3988
  2. 但 HR@5 从 0.5274 掉到 0.5134
  3. Electronics 上整体也只是和完整方法接近

如果只看离线指标，很容易误判成：

planning 没那么重要。

但同一张表又明确给出 code quality 的大幅下滑：

  1. Creativity：8.0 -> 6.5
  2. Explicitness：7.5 -> 6.0
  3. Insight：8.0 -> 8.0
  4. Personalization：6.5 -> 4.5

作者的解释也很合理：

  1. 没有 planning 时，系统依然能靠 directional feedback 看出“哪里不对”
  2. 但更容易产出 local heuristic patches
  3. 不容易长成模块化、可解释、可迁移的 algorithmic design

这条线补出的不是普通的 RAG helps coding，而是一个更细的观察位：

planning-retrieval necessity

后续如果不记这列，就会继续把“对指标有没有帮助”和“对代码结构有没有帮助”混成一件事。

evolving simulator 的收益也不是简单单调，它更像 feedback source calibration

Table 6 也给出一个很有价值的边界。

作者进一步让 SIM 也一起 evolve，结果是：

  1. 推荐性能只有小幅、且并不单调的变化
  2. 但 simulator 自己识别 target item 的准确率明显提升

具体来说：

  1. CDs 上 Initial SIM 的 accuracy 从 0.3473 提到 0.3610
  2. Electronics 上从 0.2238 提到 0.2341

与此同时，evolved NCF 的 NDCG@5 / HR@5 只是在相近范围内轻微波动。

这说明 co-evolving simulator 的首要作用，不是立刻把推荐分数再抬高一点，而是：

让方向性反馈本身更可信。

因此这条线不能只写成“simulator 也可以 evolve”，而应更准确地记成：

feedback source calibration

这对 Story Lab 很关键，因为它说明：

  1. 有些 evolution 模块直接抬主任务指标
  2. 有些模块主要抬反馈可靠性
  3. 这两种 consumer 不是同一类

结果说明它补出的不只是离线涨点，而是 performance + satisfaction + code quality 三重改写

这篇 paper 最终站得住，不只因为主任务分数更高，还因为它把三层结果一起给出来了。

主任务上，Table 4 显示它在随机 seed 和 ensemble seed 上都能稳定赢过 AlphaEvolve / DeepEvolve。

例如：

  1. 随机初始化时，CDs 上 NDCG@5 / HR@5 达到 0.3883 / 0.5165，高于 AlphaEvolve 的 0.3430 / 0.4549
  2. ensemble seed 时，CDs 上达到 0.4105 / 0.5409，高于 seed 的 0.3946 / 0.5179
  3. Electronics 上也达到 0.2524 / 0.3426，高于 seed 的 0.2385 / 0.3246

更重要的是，它到达 peak 的速度也更快：

  1. CDs 在第 8 轮达到 peak
  2. Electronics 在第 11 轮达到 peak
  3. 基线通常要 13-19 轮，甚至无法稳定超过初始模型

用户满意度上，Table 2 给出的信号更直接。

在 Agent4Rec evaluator 下：

  1. SASRec + CDs 的 Satisfy 从 seed 的 4.606 提到 5.046
  2. SASRec + Electronics 从 4.173 提到 4.502

在 PUB evaluator 下：

  1. SASRec + CDs 的 Satisfy 从 4.630 提到 4.906
  2. Electronics 从 3.928 提到 4.134

这说明 directional feedback 确实在把模型从“只对离线分数负责”往“对用户感受负责”推。

代码质量上，GPT-5 的 LLM-as-a-Judge 评估又给出第三层证据：

  1. Creativity
  2. Explicitness
  3. Insight
  4. Personalization

完整 Self-EvolveRec 在四项上都领先，并且论文明确写出 Personalization 相比基线约有 +50% 增益。

所以这条线真正补出的，不是“又一个能涨推荐分的进化框架”，而是：

自演化 recommender 开始同时对 performance、user satisfaction 和 code quality 三种结果负责。

公开边界与中文传播层

这条线的公开边界也要写准。

当前它已经明显强于 paper-first：

  1. 官方仓 Sein-Kim/self_evolverec 已公开
  2. 根目录可直接看到 self_evolverec.py
  3. 还公开了 researcher_rec.py / coder_rec.py
  4. 以及对应的 diagnosis 分支实现
  5. simulator/、examples/sasrec_cds/ 和 get_recommendation/evolved_sasrec_cd/ 也都在

README 还给出两个明确入口：

  1. 演化入口：python self_evolverec.py problem="sasrec_cds"
  2. 已演化模型测试入口：get_recommendation/evolved_sasrec_cd/main_code.py

但这条线也还不能被写成“低门槛完整复现栈”。

因为仓库当前仍有几个现实边界：

  1. 只放出 SASRec on Amazon CDs 单一示例
  2. 依赖 OPENAI_API_KEY
  3. 文档很薄
  4. GitHub API 截至 2026-03-24 显示最近一次 push 仍停在 2026-02-13
  5. commit 历史也只回溯到首个提交

所以更准确的写法是：

workflow code with thin docs / single-example release

中文传播层这一轮仍然偏弱。

我继续补做了：

  1. 论文全标题中文检索
  2. Self-EvolveRec 中文
  3. site:xiaohongshu.com Self-EvolveRec
  4. xhslink Self-EvolveRec

稳定结果主要还是论文原文页、GitHub 仓库和少量自动摘要聚合页，没有拿到足够强的中文机制稿或可复用小红书线索。因此这轮不额外把弱传播层来源入池。

对 Story Lab 的意义

Self-EvolveRec 最值得留下来的，不只是又多了一篇 LLM + recommender evolution 论文，而是它补出了一组此前站里还没单独命名的观察位：

  1. feedback semantics
  2. critique-verifier split
  3. diagnosis co-evolution
  4. planning-retrieval necessity
  5. code-quality divergence

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

  1. Self-Evolving Recommendation System
  2. RecNet
  3. AgenticRec
  4. Self-EvolveRec

时，很容易继续把它们粗写成同一种“自演化推荐系统”。

但更准确的分层应该是：

  1. Self-Evolving Recommendation System：outer-loop MLE agent
  2. RecNet：network-level preference propagation
  3. AgenticRec：trajectory-level tool-integrated ranking policy
  4. Self-EvolveRec：directional-feedback-driven model evolution

也正因此，Story Lab 下一步更适合把这几条线压到同一张 self-evolving recommendation 观察表里，至少新增：

  1. feedback semantics
  2. critique-verifier split
  3. diagnosis co-evolution
  4. evolution target granularity
  5. planning-retrieval necessity

否则“谁在 evolve、吃什么反馈、改哪一层系统”这三个最关键的问题，还是会继续混在一起。