OxygenREC：生成式推荐开始把慢思考放到近线，把快执行留给统一在线模型

背景

补完 OneMall、OneSearch、From Logs to Language 和 GFlowGR 之后，我原本已经比较习惯把 LLM × 推荐 × RL 的公开主线拆成几种常见样子：

  1. 用一个统一生成器去压多场景或多阶段 cascade。
  2. 用 RL 去修 ranking reward、token trajectory 或 action space。
  3. 用 LLM 把 logs、profile、query 或 deep interest 改写成上游语言接口。

但这一轮继续做增量检索时，我发现还有一个此前站里没有单独写开的工业结构：

LLM 不一定要坐在在线推荐环里，它也可以只做近线 slow-thinking supplier

这一轮我没有继续依赖旧版 search-layer 做事实判断，而是直接回到一手来源做定向核验，最后锁定：

  1. OxygenREC: An Instruction-Following Generative Framework for E-commerce Recommendation
  2. OxygenREC arXiv HTML
  3. 京东云官方中文技术稿：OxygenREC 快慢思考框架
  4. 京东云官方训练框架稿：Oxygen 9N-LLM 生成式推荐训练框架
  5. jd-opensource/xllm

核完之后，我更倾向于把这条线记成：

生成式推荐开始把慢思考外移到近线，把快执行留给统一在线模型

核心判断

OxygenREC 的关键不是“京东也做生成式推荐”，而是把 LLM 改写成了 reasoning supplier

这篇 paper 最值得记住的点，不是它来自电商场景，也不是它再次证明生成式推荐能涨点。

真正新的地方在于，它公开把系统拆成了两层：

  1. slow thinking：近线 LLM pipeline 负责生成 Contextual Reasoning Instructions
  2. fast thinking：高效 encoder-decoder backbone 负责在线实时生成

这意味着 LLM 在这里的角色，已经不是“在线 loop 里的大而慢 policy”。

它更像：

reasoning supplier

而真正常驻在线、吃多场景 reward、承担 serving latency 和业务对齐压力的，是那个统一的快模型。

这和站里已经补过的几条线都不一样。

  1. OneMall 更像把多场景 item distribution 压到同一个 family。
  2. OneSearch 更像把电商搜索的 MCA 三段压成统一 stack。
  3. From Logs to Language 更像先修 logs 怎样变成 LLM 能消费的文本观察。
  4. OxygenREC 则更像把深推理和在线执行在系统层彻底拆开。

所以对 Story Lab 来说，这篇 paper 逼出了一个此前没单独立起来的观察列：

reasoning supplier / executor split

否则后面会继续把“近线大模型给在线模型供 reasoning carrier”和“在线大模型自己做推荐”写成一种系统。

这条线真正把 RL consumer 锚到了统一快模型，而不是近线 LLM

OxygenREC 第二个很重要的信号，是它没有把 RL 压在近线 LLM 上。

摘要和正文都写得很清楚：

  1. 场景信息先被改写成 controllable instructions。
  2. 多场景业务目标再通过 unified reward mapping 进入统一 policy。
  3. 最终用 SA-GCPO 去做 policy alignment，目标是 train-once-deploy-everywhere。

这意味着这里的 RL consumer 不是“谁负责思考，谁就负责学策略”。

更准确地说，是：

  1. 近线 LLM 负责供应更深的意图解释和推理线索。
  2. 在线生成 backbone 负责真正学可部署的策略。
  3. SA-GCPO 处理的是多场景 reward 对齐和稳定更新，而不是把近线 LLM 自己变成在线 actor。

这和很多直觉上的 LLM-RL 写法不一样。

大家很容易把“有大模型 reasoning”直接等同于“有大模型在线决策”，但 OxygenREC 证明了工业系统可以走另一条路：

slow model supplies reasoning, fast model owns policy

这层分工非常关键，因为它同时回答了两个工业约束：

  1. latency 不能让位给深推理
  2. 多场景 deployment 不能为每个场景单独养一套大模型

IGR + Q2I 的真正作用，是把近线 reasoning 变成在线模型真能消费的 carrier

如果只看“近线 LLM 生成指令”，这条线很容易被误写成普通的 prompt augmentation。

但 OxygenREC 不是把 instruction 当装饰层。

论文专门补了两道对齐机制：

  1. IGR：过滤出和当前意图真正相关的历史行为
  2. Q2I：保证 instruction 和 item space 在语义上对齐

这件事非常重要，因为它说明近线 reasoning 不是在写一段“更好看的解释文本”，而是在构造一个在线生成 backbone 真能消费的中间语义载体。

把它和 From Logs to Language 放在一起看，会出现一个更清楚的分叉：

  1. Netflix/LinkedIn 那条线更像 observation verbalizer / textual feature constructor
  2. OxygenREC 更像 policy-side reasoning carrier supplier

两者都在做“上游语言接口”，但 consumer 不同。

前者最终喂的是 reasoner、retriever 或 ranking stack； 后者最终喂的是统一在线生成 policy。

因此站里后面如果要继续补表，除了 context constructor 之外，还要把：

reasoning carrier supplier

单独拉出来。

train-once-deploy-everywhere 说明它不是单一电商入口技巧，而是多场景统一部署方法

这篇 paper 还有一个很值得单独记的地方：

它不是只在一个电商入口上证明“近线 reasoning 有用”。

摘要直接把现有工业问题写成：

existing solutions require independent training and deployment for each scenario

也就是说，作者真正要打的对象不是某一个点击率 baseline，而是：

每个场景各训各上，资源利用率低、维护成本高

它的解法是把 scenario information instruction 化，再用 unified reward mapping 和 SA-GCPO 做跨场景对齐。

这里最重要的不是一句 train-once-deploy-everywhere slogan，而是它把多场景统一写成了：

instructionized scenario control + shared fast executor

这和 OneMall 的差别也要记清。

  1. OneMall 更强调 scenario family 和 ranking reward supplier
  2. OxygenREC 更强调 shared executor 和 reasoning supplier / executor split

两者都在讲多场景，但系统矛盾并不一样。

这条线的工业证据不只在论文里，周边训练与 serving 栈也已经部分公开

OxygenREC 最难得的一点，是它不是只有 paper abstract 在说故事。

先看论文正文本体。

arXiv API 显示它于 2025-12-26 提交，2025-12-31 更新到 v2。HTML 里已经给出几类足够硬的证据：

  1. model scaling 从 0.1B -> 3.0B，HR@10 从 13.17% 升到 16.99%
  2. 在 33% synthetic ratio 下，SA-GCPO 的 HR@1 / HR@10 明显高于 GRPO 和 GSPO
  3. 语义 ID 质量达到 Cluster Purity 92.80%，P999 collisions = 35
  4. 多个线上 bucket 给出 GMV 和 Order Volume 的显著正增益，公开数值至少包括 GMV +4.52%、GMV +8.40%、Order Volume +8.03% 和 GMV +11.80%

再看周边工程公开边界。

京东云 2026-01-28 的官方中文技术稿已经把 Fast-Slow Thinking、IGR、Q2I 和多场景统一部署思路用中文解释出来；2026-01-30 的训练框架稿则进一步公开了：

  1. PyTorch 统一训练框架
  2. 128 张 H800 集群
  3. 约 40% MFU
  4. Ray-based RL 框架
  5. UniAttention 优化
  6. xLLM 推理引擎

再往外看，jd-opensource/xllm 这个官方仓也已经公开，而且 GitHub API 显示截至 2026-03-23 仍在活跃更新，README 还明确写到它已部署在京东核心零售业务里，覆盖广告推荐等场景。

所以 OxygenREC 当前最准确的公开边界，不是纯粹的 paper-only。

更准确地说，它像是：

paper-first core method + official Chinese blogs + adjacent serving stack repo

但这里也要把边界写清：

截至 2026-03-23，按论文全标题、OxygenREC 与 arXiv id 2512.22386 做 GitHub API 检索，我仍没有看到稳定官方 OxygenREC workflow repo。

因此不能把 xLLM 的公开误写成 OxygenREC 已开源。

公开边界与传播层

当前最适合记成 industrial paper-first slow-fast serving split route

综合论文、京东云官方中文稿和 GitHub API 边界后，我觉得这条线当前最适合这样记：

industrial paper-first slow-fast serving split route

原因很直接：

  1. 论文本体已经把方法、训练和线上价值写得足够细
  2. 官方中文稿让传播层和工程语境变得更可回溯
  3. 相邻 serving 栈 xLLM 已公开
  4. 但 OxygenREC 自身还没有稳定官方 repo

这条边界和 OneSearch / GPR / GR4AD 也不完全一样。

它比纯 paper-first 多了一层可回查的周边工程语境，但还没到 OpenOneRec 那种公开 workflow 底盘。

中文传播层目前以京东云官方稿为主，稳定 xhslink 仍缺位

这一轮我也专门补做了 小红书 / xhslink 方向的检索。

截至 2026-03-23，围绕 OxygenREC 能稳定回查的高价值中文入口，仍主要集中在：

  1. 京东云官方中文技术稿
  2. 京东云官方训练框架稿

而稳定、可复用、机制信息足够强的小红书线索暂时还没出现。

所以当前传播层判断应写成：

中文一手传播已出现，但仍以官方技术博客为主，xhslink 仍缺位

对 Story Lab 的更新意义

补完 OxygenREC 之后，我觉得站里至少要新增一个明确观察位：

reasoning supplier / executor split

至少先区分：

  1. LLM stays online as policy
  2. LLM supplies near-line reasoning, fast model executes online
  3. LLM rewrites observation or profile, downstream model consumes

否则下面这些路线还会继续被写扁：

  1. From Logs to Language
  2. OneMall
  3. OneSearch
  4. OxygenREC

它们都碰了 language carrier、multi-scenario 或 RL，但系统位置其实不一样。

接下来更值得做的，不是再补一篇“京东也做推荐”的平铺直叙故事，而是把：

OxygenREC / OneMall / From Logs to Language / OneSearch

压到同一张观察表里，专门比较：

  1. 谁负责供应上游语言载体
  2. 谁真正拥有在线 policy
  3. reward 最终落在哪个执行层
  4. 系统怎样在慢推理和快执行之间切分