Self-Evolving Recommendation System：LLM 开始接管推荐器的外层演化循环

背景

补完站里现有的 policy / reasoner / representer / explainer / simulator / judge / profile constructor / risk diagnostics 这些层之后，我发现一个更外层、但此前还没有被单独写开的系统位置：

谁在持续改推荐器本身？

过去 Story Lab 里大多数 LLM-RL 协同路线，都还停留在：

LLM 直接参与 item generation / reranking / reasoning。
RL 直接更新推荐 policy 或 reward 对齐目标。
judge、simulator、tool-use 和 memory 再作为周边模块协同。

但这套图仍然默认一个前提：

推荐系统的 optimizer、architecture、reward definition，主要还是由人类工程师手工迭代。

这一轮我先用 arXiv export API 做差集发现，再回到一手来源做定向核验，最终锁定：

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

LLM 开始接管推荐器的外层演化循环

核心判断

这条线真正新增的，不是“又一个推荐 agent”，而是 `LLM` 开始优化推荐器的 `meta-configuration`

这篇 paper 最重要的一点，是它没有把 LLM 放到 request-time recommender 里，也没有把 LLM 当成 train-time judge 或 user simulator。

它做的是更靠外的一层：

让 LLM 像 MLE 一样，持续改推荐系统的 optimizer、architecture 和 reward。

论文把问题直接写成一个双层优化：

下层是 ranking model 自己的训练，也就是传统意义上推荐 RL 或 value-based ranking 在做的事。
上层是 Phi 这类 system meta-configuration 的选择，包括 optimizer / architecture / reward definition。

这意味着它补出的新层不是“推荐模型又多了个模块”，而是：

谁拥有推荐系统的改模权。

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

LLM-RL 协同推荐不一定只发生在 policy 学习层，也可以发生在“谁来持续改 policy 的训练系统”这一层。

它把推荐工程正式拆成 `Offline Agent` 和 `Online Agent` 两个不同时间尺度的回路

这篇 paper 的架构核心不是 generic multi-agent，而是很明确的双回路分工：

Offline Agent (Inner Loop) 负责高频假设生成和廉价筛选。
Online Agent (Outer Loop) 负责低频线上验证和安全放量。

论文 Figure 1 把它画得很清楚：

Inner Loop 先围绕 proxy signals 做高吞吐假设生成。
候选通过 Think-Code-Verify 闭环转成可执行 diff。
再通过 offline tool calls 先做 cheap filtering。
只有幸存者才进入 Outer Loop。
Outer Loop 再通过 live traffic 和 delayed north-star metrics 做最终验证。

这条分工的系统意义非常直接：

推荐里的 delayed business metric 不能被频繁直接消费，所以必须先有一个 proxy-driven fast loop，再有一个 north-star-driven slow loop。

这不是普通的“先离线、再在线”流程复述，而是把二者正式写成：

不同 owner、不同反馈时延、不同工具接口、不同安全职责的两套 agent 回路。

Reward 这件事，在这篇 paper 里第一次被明确写成“不能和 loss 共用同一把尺子”

这篇 paper 最值得单独记的一点，在于它没有把 optimizer / architecture / reward 粗暴当成同一类搜索对象。

论文明确指出：

Optimizer persona 和 Architecture persona 可以共用 compute_loss。
Reward persona 不能直接拿 L_proxy 比较不同 reward 定义。

原因非常硬：

一旦 reward definition 变了，loss 本身的可比性就断掉了。

论文因此让 Reward persona 改用 run_sql_query 去做大规模日志分析和相关性验证，先看候选 reward signal 是否与更理想的用户行为相关，再决定是否往线上推。

这意味着它补出的不是“agent 会写 SQL”，而是一个非常重要的系统拆分：

loss-comparable optimizer search
loss-comparable architecture search
semantic-but-not-loss-comparable reward search

所以 Story Lab 现有方法表后续不能只记“是否用了 reward”。

至少还要再补几列：

change owner
offline validator
online validator
metric comparability

否则 reward engineering 和普通超参搜索还会继续被写成一回事。

它真正让人警觉的，不是线上涨了多少，而是“改模型速度”的 owner 已经开始换人

如果只看 Table 1，这篇 paper 很容易被误读成“Google 又发了一篇小幅线上 uplift”。

但它最该记住的其实不是绝对数值，而是：

LLM agent 已经开始接管推荐工程的实验吞吐。

当然，论文仍给了明确的线上信号：

RMSprop 替换带来 YouTube-level +0.06%、Surface-level +0.12%。
Gated Path (GLU) 带来 +0.06% / +0.14%。
Activation Refinement 虽然 YouTube-level -0.02%，但 Surface-level +0.12%。
Multi-Objective Reward Synthesis 带来 +0.03% / +0.13%。

但更硬的是速度层：

训练延迟先后做到 4x 和 2x 改善。
累计训练效率与 Inner Loop capacity 达到 8x 提升。
Table 2 直接把实验吞吐从 Theta(1)-Theta(10) / week 推到 Theta(100) / week。
单实验的人类工程成本从 Theta(1)-Theta(10) hours / week 压到 0 hours / week。

也就是说，这篇 paper 真正新增的系统位不是：

agent 替人做一个实验

而是：

agent 开始拥有持续改推荐系统的节奏控制权。

它把 prompt、persona 和 experiment journal 也写成了推荐系统的一部分

这篇 paper 另一个非常值得记的地方，是它把 prompt engineering 从外围技巧推进成了系统组成件。

论文 4.1 和 5.4-5.6 里明确写到，Offline Agent 的 prompt 不是随便问问题，而是固定包含：

expert MLE persona
任务目标
可选 steering instructions
safety guardrails
baseline configuration
schema definition
Experiment Journal

而且消融还说明：

更大的 Gemini 2.5 Pro 明显好于 Gemini 2.5 Flash。
没有 expert persona framing，提案质量会明显下滑。
没有完整且排序过的历史实验上下文，效果也会变差。
让 agent 生成 delta，而不是完整配置文件，稳定性会更高。

这说明在这类系统里，prompt、persona、实验历史并不是附属品，而更像：

agentic recommendation engineering 的基础设施。

所以 Story Lab 后续如果继续补 agent 路线，也不能只记 tool-use / planning / memory。

还要补：

experiment-memory owner
delta-vs-full edit regime
human steering slot
safety guardrail locus

对 Story Lab 来说，它补出的不是新的推荐任务，而是新的“系统角色层”

这篇 paper 最终让我确定了一件事：

现有的 LLM 角色 taxonomy 还不够。

因为它不是：

LLM-as-Recommender
LLM-as-Reasoner
LLM-as-Representer
LLM-as-Judge
LLM-as-Simulator

它更接近：

LLM-as-Outer-Loop MLE Agent

而这类角色最关键的观察位也和前五类不一样。对它来说，更重要的是：

change owner
validation horizon
experiment-memory carrier
human override slot
online gatekeeper

否则它会被错误塞回“agent recommender”或“AutoML for recsys”这两类旧桶里。

公开边界与中文传播层

这条线当前的公开边界也要单独记一笔。

我这轮直接做了 GitHub 搜索与 GitHub API 定向检索，按论文全标题、2602.10226 和作者名继续查，当前没有看到稳定官方 repo。能稳定回出的主要是社区整理仓，例如：

awesome-self-evolving-systems
Awesome-LLM-Agent-Recsys

因此这条线截至 2026-03-24 更适合记成：

industrial paper-first outer-loop MLE-agent route

而不是“已开放 workflow”。

中文传播层方面，这一轮我继续补做了：

Self-Evolving Recommendation System 中文
site:xiaohongshu.com 推荐系统自演化大模型
xhslink 自演化推荐系统大模型

结果仍然比较弱，没有拿到稳定高价值小红书线索。

目前能稳定回溯到的中文传播入口，主要是 Moonlight 中文评述页。它至少把 dual-loop / Experiment Journal / Think-Code-Verify / reward engineering 这些关键词带进了中文可见层，但事实判断仍应回到 arXiv 原文。

证据与来源

Self-Evolving Recommendation System: End-To-End Autonomous Model Optimization With LLM Agents：摘要页明确给出 Offline Agent / Online Agent 双回路、optimizer / architecture / reward 三类发现对象，以及 YouTube 生产部署背景。
Self-Evolving Recommendation System arXiv HTML：用于核对 Figure 1 的双回路架构、4.1 的 specialized personas、4.2 的五阶段 DAG、Table 1 的线上指标与 Table 2 的实验吞吐。
Self-Evolving Recommendation System PDF：用于复核 Phi 的双层优化定义、reward persona 的 run_sql_query 路径、8x 训练效率提升、Theta(100)/week 实验吞吐，以及 Lessons Learned 里的 delta-based diff / exploration prompt / cold start / generalization。
GitHub 搜索与 GitHub API 定向检索：截至 2026-03-24，按论文全标题、arXiv id 2602.10226 与作者名检索，仍未看到稳定官方 repo；可见结果主要是社区整理仓，而非论文对应实现。
Moonlight 中文评述页：当前可稳定访问的中文传播层入口之一，但应只作为二手导航，不替代原论文。

下一步

把 Self-Evolving Recommendation System 加进 Story Lab 的统一观察表之外，再单独补一张 outer-loop optimization / change ownership 观察表，至少新增 change owner / offline validator / online validator / experiment-memory carrier / human override slot 五列。
后续继续找这条线的官方代码、公开视频或工程博客；在出现稳定公开资产前，不把它写成已开放 workflow。
再找能与它形成直接对照的公开路线，例如“LLM 只负责 request-time recommendation”或“LLM 只负责 train-time reward/judge”的系统，避免把这些不同 owner 混写成一种 agent 推荐。