推荐系统智能思考：2024对比测评与精选排行榜
推荐系统在过去十年的演进主线，本质上就是在「用户-物料」的统计共现上不断挖掘深度。从协同过滤到深度模型，再到生成式的 OneRec 系列，每一代突破都伴随着记忆颗粒更细、参数量更大、序列更长，推动 Scaling Law 在工业级推荐中持续兑现算力红利。但进入 LLM 时代后，一个无法回避的现实是：单纯堆砌统计规模，已在多个方向触及天花板——冷启用户推荐不准、长尾物料无人问津、跨域迁移举步维艰，而多目标多业务的策略组合，靠权重调参越来越难突破瓶颈。
与此同时，基础大模型的主旋律已从 Scaling 切换到 Reasoning，再延伸到 Agentic——智能的层次与维度被持续刷新：从「知道多少」到「想得对错」，再到「能否成事」。OpenAI o1、DeepSeek R1 已将「先思后答」塑造成共识范式，在数学、代码、Agent 任务上实现了跨代能力跃迁。但这条主线的意义绝不止于 LLM 本身——推荐系统过去靠 Scaling 积累的红利，下一阶段同样需要 Reasoning 来开辟全新的增长曲线。
然而，Reasoning 在推荐系统中绝不是 LLM 范式的简单平移。要回答这个问题，必须先抓住推荐系统自身的三重本质困境：
(1) 推荐天然是「溯因」推理，而非模式匹配。用户行为是「果」，潜在意图是「因」——模型必须从嘈杂、跨域、跨时段的行为序列中反推出某个物料「为何适合此刻」，这本质上就是一场溯因推理。统计模型能记住「看过 A 的人也看 B」，但无法解释用户行为背后多跳的因果链；尤其在冷启用户、新物料、长尾品类、跨域迁移这些行为信号稀疏的场景里，这个短板暴露无遗。
(2) 当推荐从「黑盒打分」变成「可解释、可干预的认知过程」，业务杠杆会显著放大。一个具备推理能力的基模，能把以往藏在权重里的决策过程显式写在 CoT 中。这意味着什么？推理链可以直接读出「为什么推这条」，业务约束可以直接写在推理层，策略迭代节奏从周级压缩到天级；新业务接入不再需要为每个域从头搭建召回排序栈，一个懂物料语义的基模 + 一段业务说明即可跨域生成方案。
(3) Reasoning 是通往 Agentic RecSys 的前置地基。推荐系统的下一站，是从「千人一面的固定流水线」走向「千人千策、能规划、能用工具、能多轮对话」的 Agentic 形态。而规划、工具调用、长程对话推荐这些能力，都需要一个懂物料语义、有推理能力、能稳定指令遵循的基模在底层支撑。
正是基于以上判断，快手技术团队推出了 OneReason——这是一次将 Reasoning 真正注入推荐基模的系统性尝试。其核心改进有三点：一是用 578B 数据做了三阶段预训练，分层递进地实现了推荐知识与通识知识的语义对齐；二是设计了基于归纳/溯因/演绎的推荐专用 CoT 格式，在 SFT 阶段教会模型推荐任务的思维逻辑；三是通过「先专后合」的强化学习链路平衡多业务推荐能力，让 CoT 真正服务于推荐决策。
在评测与部署上，OneReason 充分验证了 Reasoning 在推荐场景的真实价值：
业务层面——在快手本地生活广告的 10 天 A/B 实验中，带来了 +10.33% 曝光、+8.23% 广告收入增长，ROI 超过 5，对应年化数亿元的商业增量。
推荐 Benchmark 评测——OneReason首次在推荐基础模型上让 thinking 模式稳定超越 non-thinking 模式。在此之前，多个公开尝试（如 OneRec-Think、OpenOneRec）都发现 thinking 反而效果变差的反常识现象；而 OneReason 在 Pass@4 上，thinking 模式平均领先 non-thinking 模式 +13.45%，将「思考」在推荐基模上第一次变成了正资产。
通识能力保全——MMLU-pro、GPQA-Diamond 等评估结果表明，OneReason 基本保留了 Qwen3-8B 的原始水平，没有因推荐训练把基座的通用认知和指令遵循能力训坏。
可以说，在 LLM 已将 Scaling-Reasoning-Agentic 这条主轴走到第三步的同时，OneReason 恰好补上了推荐域「Reasoning」这一关键环节——通过物料语义与通识语义的深度对齐，把推荐过程转化为一种可解释、可干预、可进化的认知过程。这不仅让推荐背后的逻辑不再是黑盒，也为原生 ReAct 范式的 Agentic RecSys 打下了基础。
一、背景
在生成式推荐方向上，OneRec 系列模型已验证了 Scaling Law 在推荐系统中同样成立。通过 OneRec V1 到 V2 的迭代，持续释放算力红利，驱动模型能力提升。但进入后 LLM 时代，模型能力的进一步跃迁不再只依赖规模扩展，Scaling 与 Reasoning 的协同，正在成为新的关键路径。
然而，在工业推荐场景中，OneRec 团队此前曾做过一些初步探索（如 OneRec-Think、OpenOneRec），结果发现简单照搬并不奏效：在推荐任务上，thinking 模式并不稳定优于 non-thinking 模式。这个现象与 LLM/MLLM 领域的直觉完全相反。这说明推荐基模与通用基础大模型之间，在任务目标、信息结构和能力形成机制上存在显著差异，简单的 CoT 叠加并不能自然转化为推荐效果的提升。
所以，「推荐 CoT 应该怎么做」就成了生成式推荐继续往前走必须面对的核心挑战。针对这个问题，OneRec 团队交出了最新答卷——OneReason。他们在工业级推荐场景中分析了推荐推理失效的根因，并提出了一套覆盖感知对齐、认知结构化与 CoT 能力增强的完整实验流程，为生成式推荐领域的技术体系打开了新的探索空间，也为行业理解和构建面向推荐场景的推理能力提供了重要参考。
二、推荐 CoT 应该怎么做？
在回答这个问题之前，OneReason 先借鉴了基础大模型领域的经验，参考了多模态领域「Thinking 弱于 Non-Thinking」这一类似现象，以及社区积累的解决经验。基础模型领域的结论指向两个关键点：
模态或表示空间之间需要建立深度语义对齐。如果对齐不足，模型就容易停留在表层模式匹配，无法真正围绕深层语义信息展开推理。
推理链本身需要清晰、连贯、由粗到细的认知结构。即便模型有一定感知能力，如果推理过程缺少稳定的组织方式，长链推理也容易引入噪声、累积误差。
在推荐场景中，这两个问题变得更加显著和突出：
推荐基模中的 itemic token 与自然语言之间，还未能形成足够深的语义连接。模型更多是把 item 作为离散标识符来做关联预测，而不是将其视为可理解、可组合、可推理的语义单元。
直接混合大量通用 Reasoning 数据，沿用通用 LLM 的 CoT 形式，期待模型单纯靠泛化能力去实现推荐推理，却没有针对推荐任务设计专属的推理结构，这自然很难得到真正有推荐思维的逻辑链。
更进一步看，推荐推理与数学推理在问题形态上存在根本差异。数学推理通常是演绎式的：从明确前提出发，经过一系列逻辑步骤推导出确定的结论。而推荐推理更接近溯因推理：用户兴趣并不直接可见，模型需要从长期、嘈杂且不断变化的行为序列里，反推出潜在的兴趣，理解兴趣随时间的演化，并判断某个候选物品为何适合当前的上下文。因此，一条有效的推荐 CoT，不是简单地「展开更多的思考」，而是要完成高质量的信息压缩——从噪声中提取有效信号，从历史行为中假设用户兴趣，再从兴趣假设中收敛到推荐决策。基于此，推荐基础模型需要至少具备以下几个层次的能力：
R0 感知：看懂每个 itemic pattern，解释每个物料含义，让 item 可以被总结为兴趣点。
R1 推导：学习 Item2Item 关系，通过常识知识理解 item 关联背后的原因。
R2 演进：学习用户序列的长期演化过程，找到影响用户未来决策的原因和潜在兴趣点。
R3 推荐：基于兴趣点进行推理，推荐高质量、高相关性物料，并具备跨域推荐能力。
基于这些思考，OneReason 形成了一套面向推荐推理的系统性解法。下面按预训练、SFT、RL 三个阶段分别展开。
三、预训练设计
OneReason 的预训练，目标是构建一个能让 item 与自然语言实现深度语义对齐的推荐基座。在推荐场景中，itemic token 不只是离散的物品标识，它还承载着子 token 组合、物料内容、物料关系以及用户行为上下文等多层语义。为此，预训练阶段首先设计了 Token、Item、Relational、User 四层递进式数据架构，总规模达到 578B token，并配合三阶段分步训练策略：先稳定新增的 item 表征，再进行全参数语义对齐，最后针对长用户行为序列进行优化。这套方案解决了前代 OpenOneRec 系列因 item-text 语义割裂导致 CoT 推理低效的根本痛点，从预训练层面为推荐推理落地夯实地基。
四级分层预训练数据搭配通用多源语料，实现 Item 与自然语言全维度语义对齐
整套推荐预训练数据从微观到宏观划分为四个粒度，逐级打通物品标识与文本的语义关联：
Token 粒度：围绕子 Token 拆解与组合逻辑，设计了单 Token 释义、前缀语义预测及部分到整体的层级推理等任务，在最细颗粒度完成子单元语义绑定。
Item 粒度：对物料描述进行容量感知的粗粒化处理，过滤掉三个 token 无法承载的冗余细节与无效参数，配套多视角 Item QA 样本，实现单品内容与文本的双向精准映射。
Relational 粒度：依托用户看后搜、协同过滤及跨用户同窗共现等多源信号，构造「物品→兴趣说明文本→后续物品」的链路数据，将隐式协同偏好翻译为可解释的文本迁移逻辑。
User 粒度：采用分域分组、全时序穿插两种数据范式，按真实时间串联跨域行为记录，并随机将部分 Item 替换为文本描述，实现全场景用户兴趣对齐。
在推荐专项数据之外，还混合了大量数理、代码、科普等通用文本，并精选了粗粒度多模态数据，将通用视觉知识迁移复用至短视频、商品、直播等各类推荐物料，有效避免了模型因专攻推荐任务而导致的通用理解能力下滑与任务过拟合。
三阶段分步训练
整个预训练阶段，全量 Token 数合计 578B token，相较 OpenOneRec 的 160B 数据量有大幅提升：
预热（110B）：冻结主干，仅优化新增 item 嵌入及对应输出层权重，让 item 表征平稳融入 LLM 语义空间。
全参训练（449B）：全参数开放，四层数据联合进行深度对齐。
长序列优化（19B）：上下文窗口放开至 32K，适配长用户行为序列。
在预训练数据层面，相比 OpenOneRec 基线，OneReason 在各方面能力实现了全面跃升。在统一数据量的实验条件下，OneReason 预训练方案相对 OpenOneRec 基线模型的结果是：
R0 物品锚定涨幅 160.5%，物品理解提升 35.7%，基础感知能力实现全方位突破。
R3 核心跨域推荐指标提升 65.1%。
整套预训练体系为后续的结构化 CoT 微调和推理式推荐上线提供了坚实的语义底座，这也是思考型推荐能实现业务增收的关键前置支撑。
四、SFT 设计
预训练完成之后，模型已经具备了 itemic token 的语义基础。然而，推荐场景下的 SFT，不能等同于普通的问答式指令微调。它面对的是长序列用户行为、跨场景物料、隐式的兴趣变化，以及最终落到候选物品选择的决策问题。因此，OneReason 的 SFT 阶段向上承接了预训练建立的物料语义，向下则为强化学习提供了一个可探索、可评价的推荐推理起点。这个阶段的核心目标，是让模型基于物料语义来推断物料间关系、抽象用户兴趣并理解其演进过程，最终将这些信息组织成面向推荐决策的 reasoning trace。
围绕这个目标，SFT 阶段的重点是推理表达：让模型在真实推荐场景中学会有效引用上述语义证据，并生成可监督、可校验、可追溯的推理过程。具体来说，基于预训练强大的对齐能力，SFT 数据将能力升级为贴近推荐落地的监督信号，使模型逐步习得可解释的推荐推理。
表 2：Persona Abstraction 的典型画像示例。
Interest Expansion（兴趣发散）: 为了避免模型过早对用户意图做出单一判断，OneReason 在推理链路中设计了 Interest Expansion 环节，将用户近期的行为轨迹转化为一组候选的兴趣假设。针对发散宽度 n 的消融实验，展示了一个有趣的「少即是多」现象：当 n 保持在 1、3、5 的紧凑范围时，模型表现最佳；而一旦扩大到 10 或 20，效果反而大幅衰减。这背后的本质在于「推理信号的聚焦」：过大的候选集会引入低置信度的冗余兴趣，从而模糊了用户真正的核心兴趣，干扰最终决策。较小的假设集并没有削弱推理能力，反而防止了推理路径的碎片化。
图 3：Interest Expansion 宽度消融。
Transition Inference (兴趣推断): 在最后一步 Transition Inference 中，模型会对候选方向进行综合评估。评估维度不仅涵盖证据强度、行为近期性与时间连贯性，还兼顾了画像匹配、目标域兼容性以及潜在的答案泄露风险。这一过程有效串联了前序的推理逻辑：既利用 R1 建立跨域的「一跳」桥接，又结合 R2 判断兴趣的时序演进。最终推断出的兴趣，不能仅仅停留在语义层面的「相关」，更需要通过多跳的兴趣演化推理，清晰地还原出它是如何从用户的历史轨迹中一步步自然延伸而来。
表 3：Interest Expansion 和 Transition Inference 的例子。
CoT 质量评估
为了评估推荐思维链（CoT）的生成质量，并规避常见的推理缺陷，OneReason 设计了一套多维度的评估体系。在落地实践中发现，推荐 CoT 极易陷入两个极端：一是「结果剧透」，即推理文本提前暴露了目标商品，让解释变成了同义反复；二是「伪解释」，即生成的文本看似逻辑通顺，但完全脱离了用户的真实行为支撑。针对这些痛点，OneReason 从以下五个维度对 R3 阶段的推理链路进行量化评测：
Safety：排查推理文本中是否混入了目标 Item ID、商品标题等特征，防止模型「偷懒」，直接剧透最终的推荐结果。
Consistency：校验推理链路最终导出的结论，是否与系统预设的推荐目标严格对齐，避免推理过程与最终结果南辕北辙。
Logic：甄别模型是在真正归纳、提炼用户的行为规律，还是仅仅用自然语言把用户的历史行为流水账式地「复读」一遍。
Factuality：确保推理内容严格基于真实的用户行为序列，杜绝大模型常见的「事实幻觉」（如虚构交互行为、打乱时间线，或强行脑补、夸大用户兴趣偏移）。
Informativeness：评估推理过程是否提供了具体、有洞察的解释视角，摒弃那些放之四海而皆准、毫无信息增量的「废话」描述。
图 4：R3 推理轨迹质量评估，覆盖 Safety、Consistency、Logic、Factuality、Informativeness 五个维度）。
五、RL 设计
在 SFT 阶段之后，模型已经学会了理解用户需求、生成推荐推理过程，并输出相应的推荐结果。但 SFT 本质上还是在模仿已有数据，它的能力很容易受到训练样本和教师模型的限制。因此，推荐基础模型需要进一步引入强化学习阶段，让模型不再只是复现已有轨迹，而是能根据推荐结果反馈进行自我探索，发现更有效的推荐策略。
让强化学习适配推荐任务
与数学推理、代码生成等可验证场景相比，推荐任务涉及到的候选空间极大，正确的推荐信号极其稀疏，同时用户兴去往往具有多个方向。如果直接套用通用 GRPO，很难获得足够有效的奖励反馈。为此，OneReason 对 GRPO 进行了三方面改进。
两阶段轨迹生成：先生成推理轨迹，再基于同一轨迹扩展多个候选推荐。这样做能以较小的额外开销，显著增加有效轨迹的数量，缓解推荐奖励稀疏的问题。
Set-wise 奖励：OneReason 把奖励从 point-wise 提升到 set-wise/list-wise 的层面。在同一条推理轨迹下并行生成多条候选，并基于这组候选整体评估其覆盖度和多样性，鼓励模型探索能够覆盖用户多方向兴趣的推理路径。
优化稳定策略：针对推理文本 token 和推荐 itemic token 采用不同的裁剪范围，并降低大量未命中样本在梯度中的权重，从而缓解稀疏奖励下的训练震荡，使模型更稳定地学习推荐推理能力。
先专后合的强化学习链路
推荐基座模型需要同时服务于视频、商品、广告、直播等多个领域。由于不同领域的用户行为模式、物品语义和奖励分布存在明显差异，直接在混合数据上进行强化学习很容易产生跨领域干扰。为此，OneReason 提出了先专后合（Specialize-then-Unify）的训练链路：首先在每个领域内独立进行强化学习，学习该领域特有的推荐知识；随后再将多个领域专家模型的能力融合到统一模型中。具体来说，他们探索了两条不同的技术路线：RFT（Rejection Sampling Fine-tuning）通过学习专家生成的高质量成功轨迹进行知识整合；MOPD（Multi-Teacher On-Policy Distillation）则从策略层面持续吸收多个领域专家的能力。两者各有优势：RFT 能更好地保留专家发现的高质量推理模式，并且随着 Recall@K 中 K 的增大，收益越发明显；MOPD 则能更充分地继承多领域专家知识，对 thinking 和 non-thinking 模式带来同步提升，使 non-thinking 模式也取得具有竞争力的表现。
六、Benchmark
评估的核心思路，是把推荐模型的能力拆成四个递进层级来衡量，从「能否看懂物料内容」一路深入到「能否做好推荐」。第一层是感知（R0），关注模型能否真正理解 itemic token 背后的语义；第二层是推导（R1），关注模型能否从单个内容出发，进一步理解内容与内容之间的关联；第三层是演进（R2），关注模型能否从用户历史行为中识别出兴趣主题，并理解兴趣随时间变化的过程；第四层是推荐（R3），进一步考察模型能否把前三层能力综合起来，最终完成真实业务场景中的推荐决策。为了考察上述模型能力，OneReason-Bench 设计了大量针对性任务，包括物料理解、物料问答、i2i、兴趣链条抽取等多方面评估任务。
七、实验结果
主实验结果
在评测方面，OneReason 在短视频、电商商品、广告、直播四类跨域推荐任务中完成了对标评测，对比基线覆盖三大模型品类：ID 序列类（SASRec、HSTU）、通用大模型（Qwen3、DeepSeek-V3.2、GPT-5.4 等）、物品 Token 架构模型（TIGER、LC 全系列）。实测结论如下：
1. OneReason-RFT 综合全维度领跑，thinking 范式在推荐领域全面超越 non-thinking 范式
RFT 版本的 thinking 效果在四大业务域全面优于所有对照模型，且超越了 non-thinking 的效果。以短视频推荐为例，相较最优基线 LC-Rec-PT-SFT-8B，指标相对涨幅超过 60%；广告、直播场景增益更为突出，直播域召回指标相较通用 LLM 整体高出一个量级。
2. 推理增益依赖 RL 专项优化，原生 SFT 无法激活思考能力
仅经过 SFT 微调的模型，其 Thinking 模式的表现反而劣于 Non-Thinking 模式，这印证了业界普遍面临的痛点：直接在推荐任务中引入 CoT 容易引发「过度思考」，反而损害基础推荐性能。但后续依托「先专后合」的 RL 方案优化后，thinking 指标实现反超领跑，证实了强化学习是解锁推理收益的必备环节。
3. 四层分级预训练筑牢能力上限，是模型性能跃迁的核心底座
搭载 OneReason 预训练权重的 LC-Rec，对比从零 SFT 训练版本，广告域命中率提升了近 5 倍。这印证了 Token、Item、Relational、User 四层预训练实现了 itemic Token 与自然语言的深度语义对齐，构成了后续 CoT 推理的底层基础。
4. ID-Based 模型、通用 LLM 各有短板，专用推荐基座更适配落地
传统 ID 架构受大量新物品冷启动的制约；通用大模型则缺少用户协同行为特征，依赖 ANN 检索落地，跨域推荐效果显著落后于 OneReason。这佐证了一个观点：通用能力不能等价于推荐能力，定制化的生成式推荐基座是更优的技术路线。
CoT 能力内化现象
此外，在 OneReason 的实验中，还存在一个有意思的「CoT 能力内化」现象：引入 CoT 推理监督，不仅能提升模型的 think 能力，还能间接反哺 non-think 的推荐性能。为了进一步验证这一结论，他们在固定总 Token 规模（0.25B tokens）的约束下开展了对照实验：一组仅使用 100K 纯无推理（unCoT）样本训练；另一组采用 40K CoT 样本与 50K unCoT 样本混合训练。两组模型统一采用 non-thinking 模式进行评测，各域 Pass@64 结果如下：
图 5：CoT/unCoT 配比对 non-thinking 推荐的影响。
CoT 信息熵增益
为了判断 CoT 是否真的提升了推荐效果，OneReason 进一步引入了信息熵分析：如果生成 CoT 后推荐目标 Itemic Token 的 log-likelihood 变高，说明 CoT 在推荐中起到了正向作用；如果变低，则说明 CoT 反而可能分散了模型的注意力。
对比结果显示，SFT 阶段的 CoT 在四个领域上的平均 ΔLL 均为负值（Cross-Video: -5.19, Cross-Product: -5.22, Cross-Ad: -4.94, Cross-Live: -2.69），这表明此时的推理链往往会分散模型的注意力。而经过 RFT 后，四个领域的 ΔLL 全部转正（分别提升至 0.63, 1.27, 0.57, 1.10）。这证明了：只有经过成功轨迹筛选与强化学习后，CoT 才真正具备了辅助推荐决策的能力。
图 6：Delta LL 对比，RFT 后全域转正。
与此同时，OneReason 发现随着推理步骤的逐步展开，目标 Item 的似然值呈现整体上升趋势。而且 RFT 模型往往在推理的极早期就达到了似然峰值。这说明高质量的推荐推理长度不应过长，尽早提取关键证据才是关键。这一特性也为未来探索「推理链压缩」或「自适应早停」机制提供了理论依据。
图 7：CoT prefix likelihood progression。
案例分析
看一个真实的推荐案例。推荐目标是一条《三角洲行动》的装备玩法视频。这个案例的难点在于：用户历史行为中并没有大量《三角洲行动》的直接交互，仅包含一次微弱的三角洲游戏广告点击信号。如果模型单纯依赖历史高频 IP，很容易陷入传统 SFT 的路径依赖，继续推荐《和平精英》或《王者荣耀》相关内容，从而失去外推到新游戏的能力。
对比两者的思考过程，SFT 和 RFT 虽然都能识别出用户是 18-23 岁的年轻男性游戏受众，但在兴趣推断阶段产生了本质差异：
SFT 的局限（路径依赖）：SFT 的思考过程完全被高频的《和平精英》和《王者荣耀》主导。在分析潜在兴趣点时，它直接将后续可能性局限在《和平精英》上，因为缺乏深度推断能力，推荐结果仍然是《和平精英》，进而导致推荐失败。
RFT 的优势（多跳推理）：RFT 展现出了更强的泛化推导能力。其思考过程没有被高频的热门游戏淹没，而是准确提炼出用户最深层的核心关注点是「《绝地求生》/ 战术竞技类游戏的新玩法或装备」。基于「战术竞技新玩法」这一底层逻辑，RFT 成功建立了历史高频游戏与「三角洲行动」新游之间的联系。它在思考中明确指出：用户对射击游戏的热情不局限于《和平精英》，已延伸至类似玩法（如地逃），而《三角洲行动》作为热门新游，恰好承接了这一细分需求。
业务收益
在线上部署结果上，OneReason 在快手本地生活广告场景进行了 10 天线上 A/B 实验，实验组和对照组各使用 5% 流量。系统采用 Fast-Slow Thinking 架构：近线 OneReason 负责慢思考召回，实时 OneReason 赋能 OneRec 负责在线快思考服务，两者结果进入排序模型融合。
图 8：Fast-Slow Thinking 在线部署架构。
图 9：Fast 部署架构。