从 Netflix 到 LinkedIn：RL 开始前移到推荐里的 logs-to-language 文本构造层

背景

补完 profile constructor / representer adapter、process verifier / search controller、CRS scaffold 和 simulator consumer 之后，我原本已经比较习惯这样理解推荐里的 RL：

  1. 要么修最终推荐输出。
  2. 要么修 reasoning 轨迹。
  3. 要么修 profile、simulator、tool-use 这类中下游模块。

但这一轮沿 verbalization、textual user representation、Netflix recommendation GRPO、LinkedIn recommendation RL text representation 继续做增量检索后，我补到了两条此前没进 Story Lab 的关键入口：

  1. From Logs to Language: Learning Optimal Verbalization for LLM-Based Recommendation at Industry Scale
  2. High Fidelity Textual User Representation over Heterogeneous Sources via Reinforcement Learning

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

RL 开始继续前移到 observation verbalizer / text context constructor

也就是：

不是先优化推荐器本身，而是先优化“原始日志 / 异构用户状态怎样被翻译成 LLM 真正能消费的文本上下文”

核心判断

这两篇 paper 共同说明，推荐里的 RL consumer 还能更靠前

把两篇论文并起来看，会出现一个此前站里还没单独写出来的系统层：

| 路线 | 输入对象 | 经过 RL 优化的对象 | 最终 consumer | 持久化方式 | | --- | --- | --- | --- | --- | | From Logs to Language | 结构化交互日志 | interaction-history verbalizer | 下游 Reasoner LLM | 更偏 ephemeral context | | High Fidelity Textual User Representation | profile、职业信息、搜索行为 | member textual synopsis | retrieval / ranking / query rewriting | 明确写成 persisted text feature |

这两条线都不是传统意义上的“直接优化推荐列表”，也不完全等于此前已经补过的 profile constructor。

更准确地说，它们在做的是：

把 recommendation-native signals 改写成 language-native carrier

而且这层 carrier 已经开始被 RL 单独优化。

所以对 Story Lab 来说，现有统一方法表里除了 端到端生成器 / 黑盒推荐桥接 / profile constructor / representer adapter 这些集成层之外，至少还该再补一层：

observation verbalizer / text context constructor

否则后面会把“为下游模型构造文本观察”的方法，误写成普通 profile、普通 prompt engineering，或者普通 ranker alignment。

Netflix 这条线的关键不是“又一个 reasoner”，而是 verbalizer 本身开始吃 GRPO

From Logs to Language 于 2026-02-24 提交，2026-03-19 更新到 v2；作者表里直接有 Netflix。

它最重要的新意，不是又做了一个推荐 LLM，而是把系统明确拆成两段：

  1. Verbalizer：把原始交互历史改写成优化后的自然语言上下文。
  2. Reasoner：在 verbalized context 和 candidate set 上做预测。

论文 4.3-4.4 节把训练链路写得很清楚：

  1. 第一阶段先训 Verbalizer，把 recommendation accuracy 当 reward。
  2. reward 不来自待训练的 reasoner，而来自一个更强的 closed-source oracle reasoner。
  3. 训练算法直接用 GRPO。
  4. verbalizer 冻结后，再训下游 Reasoner 去适配这套新的语言分布。

这意味着它的主问题已经不是：

下游模型会不会推荐

而是：

结构化日志该怎样被翻译成一个更利于 LLM reasoning 的文本观察

这层前移非常关键，因为结果也说明真正的大头收益并不只来自 reasoner。

论文 6.1-6.2 节给出的相对提升是：

  1. zero-shot verbalizer：+5.3%
  2. action-based verbalizer：+10.7%
  3. rewrite verbalizer：+12.5%
  4. rewrite verbalizer + trained reasoner：+92.9%

更关键的是，对照实验里“只训 reasoner、直接吃 raw interactions”只有：

+42.8%

这组数说明什么？

说明在这条 Netflix 工业路线里，真正被单独暴露出来的新瓶颈是：

logs-to-language verbalization

也就是输入构造层本身。

如果只把这篇 paper 记成“LLM recommender + RL”，会直接丢掉它最有价值的新结构。

这条 verbalization 线也不是单一动作选择，而是已经分出 action-based 和 rewrite-based

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

它没有把 verbalization 限定成固定模板或有限裁剪。

正文 4.1 节明确给出两种设计：

  1. action-based：逐条决定保留/丢弃，以及要不要补 metadata。
  2. rewrite-based：直接整段重写历史，让模型自己学聚合、摘要和重排。

最终结果里，rewrite-based 明显更强。

而 7 节分析又补出三种 emergent behavior：

  1. syntax normalization
  2. noise filtering
  3. preference summarization

这说明推荐里的 RL 在这一层已经不只是做 token pruning，而是在学：

怎样把机器日志改写成 LLM 真正擅长消费的语义句子

所以它和 RPP 那种 prompt-time sentence policy 也不是同一类系统对象。

RPP 优化的是 prompt orchestration； From Logs to Language 优化的是 observation verbalization。

LinkedIn 这条线把同样的问题继续推进到 persistent textual representation

如果 Netflix 这篇更像 ephemeral interaction-history verbalizer，那 High Fidelity Textual User Representation over Heterogeneous Sources via Reinforcement Learning 则把同一层问题继续推进到了更持久的产品形态。

这篇论文于 2026-02-07 提交，作者基本来自 LinkedIn。

它的输入不只是推荐历史，而是明确写成四类异构来源：

  1. profile attributes
  2. professional content
  3. job search actions
  4. search queries

论文 3 节把这层表示直接定义成一个 text-generation problem：

给定 heterogeneous textual sources，学一个 stochastic policy 产出 compact textual synopsis

这里的 reward 也不是人工标注，而是更贴近产品指标的 engagement signals：

  1. clicks
  2. applies

再叠加两类约束：

  1. length penalty
  2. format penalty

它甚至明确写出为什么要这样做：

如果不给长度和格式约束，policy 会 reward hacking，靠冗长输出去抬 evaluator 分数。

也就是说，这条线已经把推荐里的 RL 问题写成了：

如何在 latency constraint 下，保留足够预测力，又不要让文本表示被 verbosity 拖垮

这和传统 profile paper 里那种“画像越完整越好”的直觉已经不一样了。

LinkedIn 这条线更重要的信号，是它已经把文本表征做成真实产品 feature

这篇 paper 最值得记的，不只是 abstract 里的方向，而是它把 deployment 边界写得很实。

论文正文明确给出：

  1. 1.7B actor
  2. 30B reward oracle
  3. 200k training samples
  4. 平均每个 member 原始输入约 5000 tokens
  5. daily offline inference 跑在 16 张 H100 上
  6. 12 小时内刷新 25M members
  7. 结果持久化到 key-value store 供下游消费

这已经不是 paper-only 的 representation learning 想法，而是明确写成了产品级 textual feature pipeline。

效果也不是单点离线指标，而是多层 consumer 一起吃：

  1. 离线 Val ROC-AUC：pointwise reward 最优，相对 baseline +3.50%
  2. retrieval 层：Recall@10 +3%
  3. query rewriting：CTR +1.3%（with preferences）、+1.1%（without preferences）
  4. Job Search 排序 A/B：CTR +1.48%、Job Applications +1.2%、Apply to Viewport Ratio +1.02%

这组结果的含义非常直接：

上游文本构造层不只是喂一个 LLM，它可以成为多个下游 consumer 共享的语言接口

于是 Netflix 和 LinkedIn 两篇放在一起，Story Lab 里又会自然长出另一个要补的字段：

persistence mode

至少先区分：

  1. ephemeral prompt context
  2. persisted textual feature

否则 From Logs to Language 和 LinkedIn 这篇又会被糊成同一种“文本画像”。

但 persisted textual feature 也不只是“写完存起来”，它内部还分 reward formulation 和 refresh regime

这次回头深读 LinkedIn 论文 3.3-6 节后，我觉得前一版 story 其实还少记了两层很关键的系统细节。

第一层是：

文本表征层自己的 reward formulation

这篇论文并不是“随便拿一个 reward 都行”。

正文把三种路线放得很清楚：

  1. pointwise string-based reward
  2. pointwise logprob-based reward
  3. entropy-weighted listwise reward

而最终最强的并不是看起来更“dense”的 logprob reward，而是更朴素的 pointwise string reward。

论文 5.1 节和 Table 6 的解释非常关键：

  1. 下游 pure-text engagement predictor 本身是 pointwise BCE 目标
  2. 因而 pointwise string reward 和最终 consumer 的优化方向更一致
  3. entropy-weighted listwise reward 虽然能加速收敛，也保留更多相对偏好结构，但在这个 consumer 上仍弱于 pointwise
  4. logprob-based reward 反而最容易 reward hacking，把摘要越训越偏向 activity-heavy 的“高置信线索”，忽略 profile 和职业内容里更弱但有用的信号

所以这条线不该只记成：

有一个 persisted textual feature

还要再记成：

这个 feature 是用什么 reward formulation 训出来的，它跟下游 consumer 是否同构

否则后面很容易把“文本表征层的 reward”粗写成普通 RLHF 技巧，而看不见它和 retrieval / ranking / query rewriting consumer 之间的结构对应。

第二层是：

refresh regime

这篇论文的 Deployment 写得很直白，它并不是每天把全站 member 重写一遍。

真实生产流程是：

  1. 这是一个 scheduled daily offline flow
  2. 平台不会重刷全部 1.4B+ members
  3. 只挑那些“表征最可能变化”的 member IDs 重新推理
  4. 具体包括：更新过 professional profile、有新 job application、或者 seeker score 日变化显著的成员
  5. 推理跑在 16 张 H100 上，12 小时内刷新 25M members/day
  6. 结果再写回 key-value store，供多个下游 consumer 复用

这意味着 persisted textual feature 也不是静态 profile。

它更像：

有刷新策略的离线语言接口

所以如果 Story Lab 后面真要把 Netflix 和 LinkedIn 这类方法压进同一张表，除了 construction locus / downstream consumer / persistence mode，还应该再补一列：

refresh regime

至少先区分：

  1. one-shot prompt build
  2. scheduled selective refresh
  3. near-real-time rewrite

否则 persisted textual feature 很容易又被误写成一次性生成、长期不动的普通画像。

因而这条线和 profile constructor 的边界，也该重新写清

这轮最容易混淆的地方，其实正是：

文本上下文构造 和 profile constructor 看起来都在生成文字

但它们的系统角色并不一样。

目前更稳妥的区分方式至少有三层：

  1. profile constructor

更强调“用户状态本身”作为长期对象如何被构造、维护、部署和验收。

  1. observation verbalizer

更强调“原始日志/异构状态怎样被翻成语言输入”。

  1. persistence mode

决定这层文本是一次性 prompt context，还是可被多个系统复用的持久 textual feature。

按这个标准看：

  1. Netflix 更接近 observation verbalizer + ephemeral context
  2. LinkedIn 更接近 text context constructor + persisted feature

两者都和 RecLM / LettinGo / PURE / UserIP-Tuning 那条主打画像生命周期的路线不同。

公开边界

这两条线当前都更适合先记成 industrial paper-first。

我这轮按论文全标题做 GitHub API 检索，截至 2026-03-22：

  1. From Logs to Language 只检到 arXiv 聚合仓与日更索引仓，没有稳定官方实现。
  2. High Fidelity Textual User Representation 只检到无关的 awesome list，也没有稳定官方仓。

也就是说，公开世界已经出现了这层方法论，但还没有把它开放成可复查 workflow。

中文传播层

这一轮我也继续补做了：

  1. From Logs to Language 推荐 中文
  2. High Fidelity Textual User Representation 推荐 中文
  3. site:xiaohongshu.com Netflix 推荐 verbalization
  4. site:xiaohongshu.com LinkedIn 推荐 文本 用户 表征

截至 2026-03-22，结果仍几乎只有原论文页、聚合索引页和噪声，没有拿到稳定高价值中文机制稿或可复用的 xhslink。

所以这条线当前仍应以 arXiv 一手材料为准。

证据与来源

  • From Logs to Language: Learning Optimal Verbalization for LLM-Based Recommendation at Industry Scale：2026-02-24 提交，2026-03-19 更新到 v2；摘要直接把 verbalization 定义成 learnable component，并给出 Netflix discovery task 上相对模板基线最高 +93% 的提升量级。
  • arXiv HTML：正文 4.1-4.4 明确写出 action-based / rewrite-based verbalizer、两阶段 GRPO、closed-source oracle reasoner，以及 +42.8% raw-reasoner 对照和 +92.9% full pipeline 结果。
  • High Fidelity Textual User Representation over Heterogeneous Sources via Reinforcement Learning：2026-02-07 提交；摘要直接给出 LinkedIn 的 heterogeneous sources、implicit engagement reward 与 format / length 约束。
  • High Fidelity Textual User Representation PDF：正文补出 1.7B actor、30B reward oracle、25M members/day、16 张 H100、12 小时刷新窗口，以及 pointwise / logprob / entropy-weighted listwise reward、scheduled selective refresh、query rewriting 和 Job Search A/B 的具体指标。
  • GitHub API 仓库检索：按两篇论文全标题精确检索，截至 2026-03-22，均未看到稳定官方仓；返回结果分别是 arXiv 聚合仓、日更索引仓或无关 awesome list。
  • 公开网页检索 site:xiaohongshu.com 与相关 xhslink 组合：截至 2026-03-22，仍未找到稳定高价值的小红书一手线索。

下一步

  • 把 From Logs to Language、LinkedIn 这篇文本表征论文和 RecLM / LettinGo / PURE / UserIP-Tuning 放到同一张表里，至少先区分 profile constructor 与 observation verbalizer 两层。
  • 在统一方法表里新增 persistence mode / refresh regime，至少先区分 ephemeral prompt context、persisted textual feature 与 scheduled selective refresh。
  • 给文本接口表补一列 reward formulation / verification regime，避免把 pointwise string、logprob 与 entropy-weighted listwise 写成同一种“文本表征 RL”。
  • 继续跟踪这两条工业路线是否出现官方仓、技术博客、Slides、中文高价值机制稿或稳定 xhslink。