Unified Ranking：从级联漏斗到单一模型，推荐与搜索排序的范式迁移

“统一排序”这个词在 2025–2026 年被用得极滥。它至少指三件不同的事：统一打分、统一阶段、统一目标。搞混这三个层次，会让技术选型从一开始就错。

导语

推荐与搜索的排序系统，过去十年几乎都长成同一个形状：漏斗。

1	百万级候选 ──召回──> 万级 ──粗排──> 千级 ──精排──> 百级 ──重排──> 十级

这个架构不是设计出来的，是算力约束逼出来的。精排模型（几百维特征、上亿参数、序列建模）算一次要几毫秒，百万候选就是几小时——不可能。所以必须用越来越轻的模型做越来越粗的筛选。

但漏斗有个内在矛盾：每一级都只看得到上一级喂给它的东西。召回用双塔（用户向量·物品向量），它理解不了”用户此刻在比价”；粗排用几十个特征，它判断不了”这个商品和上一个点击是替代关系”；精排终于有全量特征，但它只处理剩下的千分之一。

前链路的天花板，就是整个系统的天花板。 而这正是 Unified Ranking 想解决的问题。

不过，这个领域目前有两个常见的叙事偏差：

“一个模型取代级联”被讲成了纯算法突破，实际上它首先是成本结构的重新计算（下面会给出具体的测算）；
“统一”被当成单一目标，实际上有五个不同层次的统一，混为一谈会导致”以为自己在做 A，其实在做 B”。

本文先把”统一”这个词拆开，再讲三条主流路线的技术细节与代表工作，然后辨析它和多任务、双塔的关系，最后给落地难点。面向做过推荐/搜索排序、理解双塔与 DIN 类模型的读者。

1. 级联架构的五个原罪

在讲方案之前，必须先把痛点量化——否则”统一”听起来只是一个时髦词。

1.1 原罪一：样本选择偏差（SSB）会逐级放大

粗排的训练样本，来自召回的曝光；精排的训练样本，来自粗排的曝光。每一级都在”上一级认为好的东西”上学，从未见过被上一级过滤掉的负样本。

Alibaba 的 ESSM（Entire Space Multi-Task Model, 2019）就是为这个问题提出的：在 CTR 预估里，点击样本是”曝光→点击”链路的子集，直接在上面训练会高估 CTR。它的解法是加辅助任务（CTCVR = CTR × CVR）来利用全空间样本。

但这只是缓解。 级联的每一级都有自己的选择偏差，而且偏差会复利：召回漏掉的，粗排永远学不到；粗排误判的，精排永远纠正不了。

1.2 原罪二：目标不一致，且无法端到端对齐

阶段	典型优化目标	与最终目标的关系
召回	内积相似度 / 对比学习	间接
粗排	CTR（或简化多目标）	间接
精排	多目标加权（CTR × CVR × 时长…）	接近但不等价
重排	列表级效用（多样性、去重）	直接但局部

四级各自优化自己的代理目标，**没有任何一级在优化”最终的列表效用”**。所以会出现：每一级离线指标都涨，线上大盘不涨，甚至跌——因为级间的”最优”是错位的。

1.3 原罪三：算力利用率的极大浪费

这一点在业界的公开分享里有一个很具体的数字。快手在 AICon 的分享（InfoQ，2025-11）提到：

传统级联式推荐系统由于算力高度碎片化，MFU 往往极低，可能仅为 1% 甚至更低。

MFU（Model FLOPs Utilization）低的原因很直接：每一级都是独立的服务，有自己的 batch、自己的扩缩容、自己的峰值冗余。召回阶段为了 QPS 牺牲模型复杂度，精排阶段为了延迟牺牲 batch size——硬件在两处都没跑满。

他们提出了一个”广义 MFU”的定义：以系统一天的推理 OPEX 为基准，算出这笔钱在市场上能买到多少 GPU 算力（分母 T FLOPs），除以当天实际发生的计算量（分子）。这个指标的含义是：你的钱有多少真的变成了计算。

传统级联的答案是：很少。

1.4 原罪四：反馈不闭环

线上真实的用户行为（曝光→点击→转化→留存），只回到最后一级的日志里。召回和粗排的模型更新，依赖的是”重训时的全局数据”，反馈延迟以天计。

而漏斗架构下，任何一级的改动都要重新对齐其他三级。一次联合优化在工程上几乎不可行。

1.5 原罪五：创新被锁在单点

想加一个新目标（”减少营销感内容”），传统做法是：

1
2
3

定义一个可 A/B 的指标 → 在某一级加一个辅助 loss 或加权项
→ 调权重 → 发现压了另一个目标 → 再加一个约束
→ 系统越来越臃肿

快手分享里对这个循环有个很准确的描述：**”长期导致系统冗余”**。每次业务介入都在某一级”加点东西”，最终没有人能说清整个系统在优化什么。

1.6 小结：痛点的本质是”信息在传递中衰减”

把这五条收拢，其实是一个问题：漏斗的每一级都在做有损压缩，而压缩的目标（代理指标）与最终目标（用户价值）不一致。

Unified Ranking 的出发点就是：能不能不做这个有损压缩，或者至少让压缩的目标和最终目标对齐？

2. “统一”到底统一了什么：五个层次

这是本文最想先说清的部分。**”Unified Ranking” 在不同团队嘴里是不同的事**，而它们的难度、收益、风险差一个数量级。

层次	统一的是什么	典型做法	难度	收益
L1 统一打分	一个模型给所有候选打分（不改漏斗）	大模型 + ANN 近似 / 向量检索	中	中（消除同分不同源）
L2 统一阶段	召回+粗排+精排合成一个模型	生成式（SID 自回归） / 全库打分	高	高
L3 统一目标	多目标融合成一个统一效用	统一 reward / 单塔多目标 / RL	中高	高
L4 统一场景	多业务场景共用一个模型	场景 token / 多任务专家	中	中高（迁移效率）
L5 统一模态	行为 ID + 文本 + 图像一起建模	统一 token 空间 + 多任务预训练	高	待验证

大多数被叫做 “Unified Ranking” 的工作，实际落在 L2 或 L3。 而 L1 其实很常见（很多”统一排序”只是把粗排和精排合并成一个模型，召回还是双塔）。

选型的第一步，是确认你要解决哪一个层次的问题：

如果痛点是”粗排和精排目标不一致” → L3（统一目标），不需要动架构；
如果痛点是”召回的天花板限制了精排” → L2（统一阶段），需要重构；
如果痛点是”多场景重复建设” → L4，和 L2 无关；
如果痛点是”新物品冷启动” → 部分在 L2（生成式能编码新物品），部分在特征工程。

2.1 一个关键洞察：L2 的可行性来自”激活参数”，不是”参数量”

这是理解 2025–2026 这波统一排序浪潮的钥匙。

传统认知：推荐模型已经很大了（如果把稀疏 ID embedding 算进去，是 T 级参数），不可能再大。

快手的反驳（同上分享）非常关键：

对”模型已足够大”的判断应聚焦激活参数。在线推理时，推荐模型的激活参数远小于典型语言模型：以快手为例约 250M；亦有同行 baseline 仅 16M。

这个区分极其重要：

	稀疏 embedding（总参数）	激活参数（单次计算量）
规模	T 级（万亿）	M–B 级（百万到十亿）
成本来源	内存/显存（要放下整个表）	计算/延迟
能否 scale	受显存限制	有很大空间

所以”推荐模型已经很大”这个论断混淆了两件事：参数量大 ≠ 计算量大。稀疏表是”查表”，不是”计算”。真正的计算量（激活参数）只有几百 M——比同期的 LLM 小两三个数量级。

这意味着：推荐的 scale-up 空间是真实的，而且不需要等硬件突破。

2.2 成本测算：为什么”更大模型反而更便宜”

这是 Unified Ranking 最反直觉、也最有说服力的部分。我把这个测算完整复述一遍（来源同上），因为它决定了这条路线的可行性边界：

假设（信息流广告场景）：
  CPM = 20 元，广告占比 10%
  → 10,000 次曝光收入 = 20 元
  → 单次曝光收入 = 0.002 元

要保持 80% 的"计算毛利"：
  → 单次曝光可投入计算成本 = 0.002 × 20% = 0.0004 元

硬件：H20，OPEX ≈ 5.6 元/小时
  → 0.0004 元可购买约 15.2T FLOPs（已计入 MFU 40%）

若单次曝光消耗 1,000 token：
  → 可用模型规模 ≈ 15.2T / 1000 / (2 × 激活比例) ≈ 7.6B 参数

结论：在 CPM 20 元量级的业务上，用 7.6B 的模型做在线推荐，在成本上是可行的。

而传统级联因为 MFU 只有 1%，同样的钱只能买到 1/40 的算力。所以：

统一架构的收益，主要不是”模型变强了”，而是”同样的钱买到了 40 倍的算力”。

这也解释了快手公开的结论：服务成本降至原系统的 1/10，同时模型更大、效果更好。不是矛盾，是 MFU 的红利。

但这个测算有三个前提，缺一不可：

业务 CPM 要够高（20 元量级）——低价值场景（如纯信息流的低价广告）算不过来；
单次请求的 token 预算要小（几百 token）——推荐不需要长 CoT，这是它相对 Chatbot 的优势；
MFU 能真的提上去——这依赖工程（下文第 6 节）。

所以”Unified Ranking 一定更便宜”是错的。 正确表述是：”在高 ARPU、低 token 需求的场景下，统一架构能把碎片化的算力集中起来，从而在同等成本下获得更大的模型。”

3. 三条主流技术路线

3.1 路线 A：生成式（Generative Retrieval + Ranking）

这是 2025–2026 最受关注的一条，也是 L2（统一阶段）最彻底的实现。

核心思路

把推荐/搜索重新表述为序列生成问题：

1 2	传统：给定用户，从候选集里挑选 top-k（判别式）生成：给定用户历史，自回归生成下一个 item 的 token 序列（生成式）

关键是物品怎么变成 token。这一步叫 Semantic ID（SID），通常做法是：

1 2	item → 多模态/协同 embedding → 量化（RQ-VAE / K-means）→ 离散 token 序列例：video_12345 → [a3, f7, 2b, 9c] （4 层码本，每层 256 个码）

生成时，模型自回归输出这 4 个 token，再反查回 item ID。

代表工作

工作	时间	机构	核心贡献
TIGER	2023	Google	提出用语义 ID + 生成式检索替代稠密检索，语义 ID 比随机 ID 泛化好
HSTU	2024	Meta	分层序列转导器（Hierarchical Sequential Transducer），把推荐当序列转导；提出推荐领域的 scaling law，报告相对 baseline 有数量级的速度提升（论文自报 5.3×–15.2×，视序列长度）
OneRec	2025	快手	单一模型覆盖召回+粗排+精排+重排；用 RL（Reward System）做偏好对齐；线上服务成本降至 1/10
OneRec-V2	2025	快手	Lazy Decoder-Only：砍掉 Encoder 侧计算，训练资源省 94%，同等算力下模型从 0.5B 扩到 8B
OneRec-Think	2025–2026	快手	文本 + 图像 + 行为 token 统一基座，做”生成—理解”一体
UniSearch	2025	业界（多家）	生成式统一搜索，思路与 OneRec 类似（该名称在多个团队的工作中出现，具体以各自论文为准）

OneRec 的工程细节（值得单独看）

上面那个 InfoQ 分享提供了几个非常具体、且在其他论文里很少见的细节：

① 样本组织：为什么不能直接”用户 Doc + next token”

这是最容易被忽略的一点。LLM 的训练以文档为单位，对全局时间不敏感。但推荐必须严格服从时间因果：

用户 U1 的行为：A → B → C
用户 U2 的行为：... → D（发生在 T4 之后）

如果按 Doc 训练：
  训练完 U1 的 Doc 后，模型已"见过" T4 之后的信息
  再去学 U2 的 B→C 预测，就发生了时间泄漏

解法是拆成曝光级样本：A→B、AB→C、ABC→D……确保每次预测只用到该时刻之前的历史。

代价也明确：语言模型可以用单向 Transformer 复用前缀计算，而曝光级样本会重复计算用户历史，效率下降。这个代价直接引出了 V2 的架构改动。

② V2 的核心发现：Encoder-Decoder 的”计算与监督错配”

第一版用 Encoder-Decoder。分析发现：

1 2	训练计算分布：Encoder（编码用户历史）≈ 90%，Decoder ≈ 10% 监督信号分布：Encoder 无直接 loss，loss 全在 Decoder

算力花在没有监督的地方。 这就是为什么 Encoder 侧的 scaling law 不明显——投更多算力，没有对应的梯度信号去用它。

V2 的改法：几乎移除 Encoder，只保留一个轻量投影，把算力集中到 Decoder。结果：训练资源省 94%，等量资源下模型从 0.5B 扩到 8B，且 loss 随规模平滑下降（符合 scaling law）。

这个洞察的价值超出 OneRec：任何”编码器 + 任务头”的架构，都应该问一句”计算发生在哪、监督发生在哪，它们对齐吗？“

③ RL 的三类 reward

OneRec 用 RL 而不是纯监督，设计了三种奖励：

类型	内容	意义
兴趣偏好	把点赞/关注/观看等信号统一成一个逻辑输出	替代传统的”多目标手工加权”
业务偏好	生态约束（创作者成长、营销感占比等）	只需定义”什么是营销感”+ 设定 reward，天级响应
格式约束	生成的 SID 必须能解码到真实 item	防止”说错话”，提升合法率

第二条值得特别注意：业务方只需定义 reward，不需要在某一级”加点东西”**。这直接解决了 1.5 节的”系统臃肿”问题。而且分享提到业务 reward 收敛所需样本量约为传统方式的 1/1000**——因为梯度直接作用在最终输出上，不需要逐级穿透。

路线的根本限制

生成式统一排序有一个结构性风险，很少被正面讨论：

自回归生成的”候选空间”是全部 item，但它的”打分能力”是序列似然的副产品。

具体三个问题：

列表级约束难做。多样性、去重、配额（”前 3 条不能都是同一作者”）在自回归生成里没有自然的位置。传统重排可以在列表层面优化，生成式只能靠”生成后过滤 + 重新生成”，成本高且不确定。
精确打分难做。判别的精排模型可以输出校准良好的 pCTR（用于计费、排序、混排）。生成模型的 likelihood 与 CTR 不是单调关系，需要额外校准。
冷启动的方向变了。传统模型靠 ID embedding 记忆，新 item 冷启困难；生成式靠内容语义（这是优势），但如果 SID 的量化把细粒度差异抹平了，相似的新 item 会生成同一个 token 序列，无法区分。

第 3 点在实践中很关键：**码本大小（每层多少 token）和层数，直接决定了生成模型的”分辨率”**。太小 → 大量 item 共享 SID；太大 → 生成空间爆炸、合法率下降。

3.2 路线 B：大模型 + 近似检索（”重排序器打全库”）

这条路线的思路是：不做生成，但让精排级的模型能对全库候选打分。

机制

用户请求
  ↓
用轻量的向量表示做 ANN 检索（top-N，N 可以很大，比如 10 万）
  ↓
用重模型对这 N 个候选精确打分（批量化、GPU 推理）
  ↓
取 top-k

关键在中间这一步的吞吐：如果重模型能在 50ms 内打 10 万个候选，漏斗就压成了两级。

这条路线的三个支撑技术

技术	作用
用户表示与物品表示的解耦	用户侧用重模型算一次（一次请求只算一次），物品侧离线预计算或缓存
批量化 + GPU 推理优化	把 10 万个候选当成一个大 batch，用 TensorRT / Triton 优化
级联的”软”化	不用硬 top-k 截断，而是用近似打分 + 精确打分的两段式，但两段共享表示

与生成式的对比

	生成式（路线 A）	大模型+近似检索（路线 B）
候选空间	隐式（生成什么就是什么）	显式（全库）
打分语义	序列似然（需校准）	判别式（天然校准）
列表约束	难	容易（拿到分数后可任意重排）
新 item	靠语义（好）	靠特征（取决于特征工程）
工程改动	极大（重构链路）	中（优化现有精排）
成熟度	早期，少数团队落地	更成熟，多数团队的渐进路径

我的判断：路线 B 是大多数团队的现实选择，路线 A 是头部团队在验证的方向。 因为 B 的改动是渐进的（先把粗排做大、再把召回做大），而 A 需要重建整个数据与训练 pipeline。

3.3 路线 C：级联内的一致性修正（”不统一的统一”）

这条路不追求”一个模型”，而是让多个模型之间的目标对齐。

典型做法

做法	机制	解决的问题
蒸馏对齐	用精排模型给粗排的样本打 soft label，让粗排拟合精排	级间目标不一致
全空间建模（ESSM 类）	加辅助任务，利用全漏斗样本	样本选择偏差
共享底层表示	各级共享 embedding / 特征，只换上层	特征重复建设、表示不一致
联合训练（交替优化）	固定精排训粗排，再反过来	目标对齐
一致性正则	惩罚”粗排高分但精排低分”的样本	排序不一致

为什么这条路值得认真考虑

它有三个现实优势：

工程风险低：不改变线上架构，可以逐步替换；
可解释：每一级的作用清晰，出问题好定位；
收益可测：能单独度量”一致性提升带来了多少线上收益”。

代价：它无法突破”前链路天花板”这个根本限制——粗排的容量还是那么小，召回还是双塔。它只是让漏斗”漏得更少”，不是”不漏”。

3.4 三条路线的定位

      收益上限
         ↑
高  │   路线A（生成式统一）
    │        ●
    │
    │        路线B（大模型+近似检索）
    │            ●
中  │
    │   路线C（一致性修正）
    │        ●
低  │
    └──────────────────────────→ 工程改动 / 风险
        低              高

注意横轴：路线 A 的收益最高但改动最大；路线 C 收益最有限但风险最低。这个图没有”最优解”，只有”当前阶段适合哪个”。

4. 与多任务 / 多目标排序的关系

这是最容易混淆的一对概念，必须辨析清楚。

4.1 它们不是同一件事

	多任务排序（MTL）	统一排序（Unified Ranking）
解决什么	一个模型预测多个目标（CTR、CVR、时长…）	一个模型处理多个阶段/场景/候选空间
统一的维度	目标维（output）	阶段/场景维（pipeline）
典型结构	Shared-Bottom、MMOE、PLE、ESMM	生成式、全库打分、统一 token
不涉及	候选集怎么来	目标怎么融合（通常还是手工加权）
正交性	可以自由组合	同左

关键结论：多任务和统一排序是正交的。 一个统一排序模型内部仍然是多任务的（要预测点击、转化、时长），一个多任务模型也可以只用在精排一级。

4.2 但它们有一个共同的深层问题：目标怎么融合

传统做法是手工加权：

1	final_score = w1 · pCTR + w2 · pCVR · price + w3 · 时长 + ...

这套做法的三个问题：

权重是全局的，但最优权重随上下文变化（新用户更看重探索，老用户更看重精准）；
权重与业务目标的关系不透明（调 w2 会不会伤留存？不知道）；
目标之间会冲突（提时长可能降转化）。

统一排序模型的一个隐含承诺是：用统一效用替代手工加权。 具体有三种实现：

方式	机制	代表
单一 reward	把多目标压成一个标量（如”用户价值”），用 RL 优化	OneRec 的 Reward System
列表级效用	直接优化整个列表的效用（而非逐条打分）	生成式天然是列表级
帕累托 / 约束优化	主目标最大化 + 其他目标做约束	业务约束型 reward

第一条最激进也最吸引人：业务方只需定义”什么是好的推荐”，不需要调权重。但它引入了新问题——reward 设计错了，模型会朝错误方向优化，而且因为是端到端，错误会被放大。

这是我在第 6 节要展开的核心风险。

4.3 一个实用的组合建议

如果你的团队现在做的是 MTL 精排，想往统一排序走，不要一步跳到 L2。建议的路径：

Step 1：把精排的 MTL 做扎实（PLE 类），确定主目标是哪些
Step 2：用蒸馏/全空间建模做级间对齐（路线 C），验证"一致性"值多少收益
Step 3：把粗排和精排合并成一个模型（L1 的部分统一），看延迟和效果
Step 4：如果 Step 3 收益明显，再考虑 L2（生成式或全库打分）

每一步都要有独立的 A/B 和归因。跳过 Step 2 直接做 L2 的团队，往往在上线后无法回答”收益来自哪里”，也无法在出问题时回滚。

5. 与传统双塔、深度排序模型的对比

5.1 三代排序技术的定位

代际	代表	用户-物品交互	候选空间	主要瓶颈
双塔（Two-Tower）	DSSM、YouTubeDNN	只在最后内积	全库（ANN）	表达力（用户和物品不能细粒度交互）
深度排序（DLRM）	DIN、DIEN、SIM、DeepFM	特征交叉 + 序列 attention	千级（只做精排）	候选空间小（受延迟限制）
统一排序	OneRec、HSTU	全序列建模 + 生成/全库打分	全库或准全库	工程复杂度、目标设计

这张表说明了统一排序的历史位置：它想同时拿到”双塔的全库覆盖”和”DLRM 的交互表达力”——而这两者此前是互斥的。

5.2 为什么双塔的表达力是天花板

双塔的结构决定了：

1	score(u, i) = f(u) · g(i)

用户和物品在编码时完全看不见对方。这带来一个数学后果：它只能表达”用户-物品”的可分解（decomposable）交互。

DIN 的贡献正是指出这一点：用户的历史兴趣应该根据候选物品做 attention（”这个用户买过鞋，但现在看的是手机，鞋的历史应该降权”）。而这个 attention 需要 (u, i) 同时参与——双塔做不到。

所以双塔的召回率上限，本质上是”可分解交互”的表达上限。

5.3 统一排序怎么绕开这个限制

两条不同的绕法：

绕法一（生成式）：把候选”内化”进模型

1	score = P(next_item = i \| history)

模型在生成时，已经把 history（用户侧）和候选空间（全部 item 的 token 表示）都编码进了参数。用户和物品在”生成过程”中交互——每次生成一个 token，都是用 history 去约束 item 空间。

这与双塔的根本差别：双塔的 item 表示是独立预计算的、与用户无关的；生成式的 item 表示是在用户上下文中”逐 token 生成”的。

绕法二（全库打分）：把重模型批量化

保持判别式结构，但让重模型能对 10 万候选打分。这样 (u, i) 在每个候选上都有完整交互（DIN 类的 attention 可以做）。

代价是算力：10 万候选 × 每候选 N 次特征交叉。这就是为什么它依赖”用户侧算一次 + 物品侧预计算”的解耦。

5.4 一张更完整的对比表

维度	双塔召回	深度精排	生成式统一	大模型+近似检索
候选规模	全库（亿级）	千级	全库（生成）	万–十万级
用户-物品交互	内积（弱）	全特征交叉（强）	生成过程中隐式交互	全特征交叉（强）
序列建模	用户侧	用户侧（SIM 类）	双向/长程	用户侧
训练方式	对比学习 + 负采样	监督（CTR/CVR）	生成（next token） + RL	监督
打分校准	中	好	需额外校准	好
列表级优化	❌	❌（逐条）	⚠️（隐式）	✅（拿到分数后可重排）
新物品冷启动	差（ID 记忆）	差	好（语义）	中
工程改动	—	中	极大	中
延迟	低（<10ms）	中（几 ms/千条）	需优化（吞吐取决于解码）	高（万条 × 重模型）

6. 落地难点：四个不能绕过的工程问题

6.1 难点一：延迟与吞吐的重新计算

传统级联的延迟预算是”每级几十毫秒”。统一架构变成”一个模型吃掉全部预算”，这就要求单次推理必须极快。

生成式的延迟特性与传统模型完全不同：

	传统精排	生成式
计算模式	一次 forward 出全部候选分	自回归：每生成一个 token 一次 forward
延迟与什么成正比	候选数（可批量）	生成序列长度（串行）
优化手段	batch、量化、蒸馏	beam search 宽度、KV cache、投机解码

一个关键数字：如果 SID 是 4 层码本，生成 10 个 item 就是 40 次自回归 forward。假设每个 forward 5ms，就是 200ms——超预算。

所以生成式统一排序必须做并行解码：一次 forward 用 beam search 出 K 条候选，再用一个轻量的判别头精排。快手的分享提到生成后还会反解回 item ID 并做合法性校验，这一步也是延迟的一部分。

路线 B（全库打分）的延迟瓶颈在特征：10 万候选 × 每个候选 200 个特征的搬运，是 memory-bound 的。必须做：

物品侧特征离线预计算 + 缓存（只取增量）；
用户侧特征算一次，broadcast 到所有候选；
特征交叉在 GPU 上做（而不是 CPU 拼装）。

6.2 难点二：样本分布与时间因果

这一节是统一排序最容易被低估的坑。

坑一：时间泄漏（前面提过，但值得再说一遍）

LLM 的训练是”文档为单位”，推荐是”事件流为单位”。两者的根本差异：

1 2	LLM：同一个 doc 内的 token 是"同时"可见的（训练时）推荐：用户 t 时刻的行为，只能由 t 之前的事件解释

如果你把”用户全部历史”拼成一个 doc 做 next-token 预测，训练时模型会看到未来。快手的解法是拆曝光级样本（A→B、AB→C），代价是重复计算。

判断你的 pipeline 有没有这个问题，看一个指标：离线 AUC 是否显著高于线上（差 2 个点以上）。如果有，先查时间泄漏，而不是加特征。

坑二：曝光偏差在统一模型里依然存在

统一排序消除了”级间”的样本选择偏差，但**没有消除”曝光偏差”**：

1
2
3

用户只对"被展示的 item"产生行为
→ 训练数据只有被展示的
→ 模型学不到"没被展示但用户会喜欢"的

这个问题在生成式里更微妙：**如果训练目标是 next-item prediction，那模型学到的是”用户会点什么”，而不是”用户会喜欢什么”**。这两个不等价（点击诱饵）。

三条缓解路径：

探索流量（ε-greedy / Thompson sampling）：主动展示一些低分候选，收集反事实样本；
IPS / 逆倾向加权：用曝光概率做加权，纠正分布偏差（需要准确的 propensity 估计）；
RL + 长期价值：用留存/长期指标做 reward，而不是单次点击（OneRec 走的是这条）。

6.3 难点三：目标冲突与 reward 设计（最大的风险）

这是我认为统一排序最大的、且最少被公开讨论的风险。

传统级联下，目标冲突是在模块边界上处理的：

1	精排优化 CTR → 重排加多样性约束 → 冲突在重排层被"修正"

统一之后，冲突必须在模型内部解决，靠一个 reward 函数。这带来三个问题：

问题一：reward 错了，全链路一起错

因为端到端，一个设计不当的 reward 会直接扭曲整个生成分布。而且错误会被放大——没有下游模块来”兜底”。

问题二：reward hacking 更隐蔽

单个模型优化一个标量，容易找到”看起来优化了但实际有害”的路径：

表面优化	实际伤害
提高点击率	用标题党（短期涨、长期伤留存）
提高时长	推长视频/自动连播（用户疲劳）
提高转化	推低价引流品（GMV 涨、毛利跌）

这些在传统架构下会被重排或业务规则拦截，在统一模型里需要显式写进 reward 或作为约束。

问题三：多目标的量纲不可比

pCTR 是概率，时长 是秒，GMV 是元。压成一个标量需要归一化，而归一化的方式直接影响优化方向。

我的建议（三条）：

reward 必须可分解、可审计：每个子 reward 单独记录，出问题能定位到是哪一项被过度优化；
必须有护栏指标（guardrail metrics）：留存、多样性、内容质量等不进 reward，但作为硬约束监控，一旦越界就回滚；
先离线小规模验证 reward 的单调性：用历史数据回放，看”reward 高的轨迹”是否真的对应”业务指标好”，再上线。

一条经验：如果你不能把”什么是好的推荐”写成 3–5 条可度量的规则，就不要上端到端 RL。 先用多任务 + 手工加权，至少每一步都是可控的。

6.4 难点四：SID 的设计（生成式独有）

这条路线的很多效果，最终落在 tokenizer 上。

核心权衡：

维度	小码本 / 少层	大码本 / 多层
分辨率	低（大量 item 共享 SID）	高（能区分细粒度）
生成空间	小（容易生成）	大（合法率下降）
泛化	好（相似 item 共享 token，冷启动友好）	差（等价于 ID）
序列长度	短（解码快）	长（解码慢）

快手分享里有个很关键的观察：SID 的 embedding 必须”既懂内容、又懂推荐”。

只用多模态相似度 → 看了”葡萄视频”，会推其他水果（形似神不似）；
只用协同过滤 embedding → 会推”挑选蔬菜”（共现相关但语义浅）；
理想的是能识别”这个视频核心是农药污染/食品安全”，从而推其他食品安全内容。

他们的做法是双 loss：item-to-item 对比学习（对齐协同信号）+ 语义保持 loss（用 LM 从表征重建描述）。这是目前公开资料里最具体的一个 SID 设计。

6.5 一张落地检查清单

在决定做统一排序之前，逐条自查：

检查项	不满足的后果
业务 ARPU 是否足够高（CPM 20 元量级）？	成本算不过来
单次请求的 token 预算是否 < 500？	延迟超标
有没有可靠的离线评测（能预测线上）？	无法归因
有没有护栏指标与回滚机制？	reward 出错时无法止损
数据 pipeline 是否严格时间因果？	时间泄漏，离线虚高
是否有探索流量收集反事实？	曝光偏差无法纠正
团队能否维护”数据—训练—推理”一体化系统？	上线后无法迭代

七项里少于五项满足，建议先走路线 C（一致性修正）。

7. 选型建议

7.1 按团队阶段选

你的现状	建议路线	理由
级联已经很成熟，指标卡住	路线 C（一致性修正 + 蒸馏对齐）	低成本验证”前链路天花板”是不是真瓶颈
精排已很强，召回明显拖后腿	路线 B（放大召回 + 重模型打全库）	直接补短板，改动可控
多场景重复建设，边际成本高	L4 统一场景（不是 L2）	问题和阶段无关，别上生成式
有强工程团队 + 高 ARPU 场景	路线 A（生成式）	唯一能拿到 40× 算力红利的路线
新物品占比高、冷启动痛	路线 A（生成式的语义 SID 有天然优势）	但要注意码本分辨率的权衡
团队 < 10 人	路线 C 或 B，不要碰 A	A 需要数据/训练/推理一体化团队

7.2 按场景选（推荐 vs 搜索）

场景	特点	推荐
信息流推荐	候选多、无明确 query、序列长	生成式（OneRec 类）最契合
电商搜索	有 query、强约束（库存/价格）、需要精确匹配	路线 B（大模型+检索）为主，生成式做 query 理解
电商推荐	有明确购买意图、列表约束多（不能重复店铺）	混合：生成式做召回，判别式做精排+重排
本地生活	地理约束强、候选相对少	路线 B（约束可以先过滤，再做重排序）
短视频	无限下滑、强序列、时长敏感	生成式（当前落地案例最多）
广告	需要校准（计费）+ 出价机制	判别式为主，生成式只做召回

最后一行值得强调：广告场景对”校准”的要求是刚性的（计费必须准），而生成式的 likelihood 需要额外校准层。这是为什么广告排序的统一化比自然推荐更慢。

7.3 一条务实的演进路线（12 个月）

M1–M2：量化现状
  - 算清楚各级的 MFU（用"广义 MFU"口径）
  - 建离线→线上的归因链路
  - 这一步的产出是"值不值得改"的判断依据

M3–M5：路线 C
  - 精排蒸馏到粗排
  - 全空间建模（ESSM 类）
  - 目标：nDCG/GAUC 涨 1–2 个点，验证一致性价值

M6–M8：粗排与精排合并（L1）
  - 共享底层，统一打分
  - 观察延迟与效果
  - 这一步是"统一"的第一次真实检验

M9–M12：评估 L2
  - 若 L1 收益明显且延迟可控 → 试点生成式（选一个子场景）
  - 若 L1 收益不明显 → 说明瓶颈不在这里，回到特征/数据

关键在 M1–M2：如果不先量化 MFU 和归因，后面的每一步都无法判断”是不是真的变好了”。

8. 小结

级联架构的五个痛点，本质是”信息在传递中衰减，而压缩目标与最终目标不一致”。 样本选择偏差会逐级复利；每级优化的是代理指标；算力碎片化；反馈不闭环；创新被锁在单点。
“统一排序”至少指五个层次：统一打分（L1）、统一阶段（L2）、统一目标（L3）、统一场景（L4）、统一模态（L5）。大多数工作落在 L2 或 L3，而 L1 常被误认为 L2。选型第一步是确认你要解决哪一层。
L2 的可行性来自”激活参数”而非”参数量”。 推荐模型的总参数（稀疏表）是 T 级，但单次计算的激活参数只有几百 M——比同期的 LLM 小两三个数量级。**”推荐模型已经很大了”这个论断混淆了显存和计算。**
统一架构的收益主要不是”模型变强”，而是”同样的钱买到更多算力”。 传统级联 MFU 可能只有 1%（算力碎片化），统一后能到 40% 量级。这是 40× 的杠杆，比换模型架构的收益大得多。
但”更便宜”有三个前提：高 ARPU（CPM 20 元量级）、低 token 需求（<500/请求）、工程能把 MFU 提上去。低价值场景算不过来。
三条路线各有位置：生成式（A）收益最高但改动最大；大模型+近似检索（B）是多数团队的现实路径；一致性修正（C）风险最低但突破不了天花板。没有最优解，只有阶段适配。
生成式的结构性风险是”打分能力是序列似然的副产品”。 列表级约束难做、精确校准难做、SID 分辨率有限。这三点决定了它不能无条件替代判别式精排。
OneRec-V2 最有价值的发现是”计算与监督的错配”**：Encoder 吃掉 90% 算力但没有直接 loss，所以 Encoder 侧看不到 scaling law。任何”编码器 + 任务头”的架构都该自查这一点。**
时间泄漏是统一排序最隐蔽的坑。 用户 Doc + next-token 会让模型看到未来；解法是拆曝光级样本，代价是重复计算。判断方法：离线 AUC 显著高于线上（差 2 点以上）就先查这个。
多任务与统一排序是正交的。 MTL 统一的是”目标维”，统一排序统一的是”阶段/场景维”。一个统一排序模型内部仍然是多任务的。
最大的风险在 reward 设计，不在架构。 端到端意味着 reward 错了全链路一起错，且没有下游模块兜底。必须有可分解的子 reward + 护栏指标 + 离线单调性验证。
“如果你不能把’什么是好的推荐’写成 3–5 条可度量规则，就不要上端到端 RL。” 先用多任务 + 手工加权，至少每一步可控。
演进顺序应该是 C → L1 → L2，而不是直接跳到生成式。 跳过中间步骤的团队，上线后往往答不出”收益来自哪里”，出问题也无法回滚。

如果只留一句：统一排序不是”用一个更大的模型替代漏斗”，而是”把碎片化的算力集中起来，用省下来的钱换更大的模型”——它的前提是成本结构，不是算法先进性。

参考来源

生成式推荐与统一排序

Rajput et al., Recommender Systems with Generative Retrieval（TIGER）, NeurIPS 2023；arXiv:2305.05065（语义 ID + 生成式检索）
Zhai et al., Actions Speak Louder than Words: Trillion-Parameter Sequential Transducers for Generative Recommendations（HSTU）, ICML 2024；arXiv:2402.17152（Meta；序列转导 + 推荐 scaling law）
OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment, arXiv:2502.18965（快手；单模型覆盖召回→重排）
Killing Two Birds with One Stone: Unifying Retrieval and Ranking with a Single Generative Recommendation Model, arXiv:2504.16454
周国睿（快手），抛弃”级联”架构！快手 OneRec 用大模型重构推荐系统，服务成本降至 1/10，AICon 演讲实录，InfoQ（本文中 MFU 测算、激活参数 250M、服务成本 1/10、V2 的 94% 资源节省与 0.5B→8B、时间泄漏与曝光级样本、三类 reward、业务 reward 样本量 1/1000、短视频到其他场景 1.5 个月迁移等细节均引自该分享）
Scaling Generative Recommendations with Context Parallelism on Hierarchical Sequential Transducers, arXiv:2508.04711

级联与多任务

Ma et al., Entire Space Multi-Task Model: An Effective Approach for Estimating Post-Click Conversion Rate（ESSM）, SIGIR 2018；arXiv:1904.06813（样本选择偏差）
Ma et al., Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts（MMoE）, KDD 2018
Tang et al., Progressive Layered Extraction（PLE）, RecSys 2020
Zhou et al., Deep Interest Network for Click-Through Rate Prediction（DIN）, KDD 2018（双塔表达力上限的经典论证）
Pi et al., Search-based User Interest Modeling with Lifelong Sequential Behavior Data（SIM）, 2020
Covington et al., Deep Neural Networks for YouTube Recommendations, RecSys 2016（双塔召回的工业范式）

排序评估与偏差

Joachims, Swaminathan, Schnabel, Unbiased Learning-to-Rank with Biased Feedback, WSDM 2017（IPS 与曝光偏差）
Steck et al., Deep Learning for Recommender Systems: A Netflix Case Study, 2021（列表级效用与校准的讨论）

说明：本文的成本测算（CPM 20 元、广告占比 10%、MFU 40%、单次 1000 token → 7.6B 可行）完整引自快手在 AICon 的公开分享，属单一厂商的假设与结论，不同业务量级下结论会变。”MFU 传统级联仅 1%”是分享中的表述，我未独立验证，引用时请保留出处。UniSearch 这一名称在多个团队的工作中出现，本文未展开具体技术细节，以各自论文为准。各论文的效果数字均为作者自报，复现条件不同会有偏差。