Scaling Law 仍然成立，企业搜广推怎么做才能少踩“坑”？

当大模型从通用技术探索深入产业场景，搜索、广告与推荐系统作为连接用户需求与业务价值的核心链路，正迎来全链路智能重构。那么，生成式推荐真正落地后的关键挑战是什么？又应该如何解决？

近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了 京东内容推荐架构负责人颜林 担任主持人，和 荣耀 AI 算法专家冯晓东、京东算法总监张泽华、中科大计算机学院副教授王皓 一起，在 AICon 全球人工智能开发与应用大会 2025·北京站即将召开之际，共同探讨生成式推荐的落地洞察。

部分精彩观点如下：

• 行业真正做到端到端的统一 pipeline 仍有较大差距，更多工作还是在 pipeline 的单点与大模型结合。

• 搜广推场景中的 scaling law 依然成立，并且仍在快速上升阶段。

• 低价值场景用小模型覆盖，高价值场景用大模型争取额外收益。

• 不应拘泥于某项技术是否是主流，也不必期待每次都带来爆发式收益，所有革命性进展都是逐步积累而成的。

完整直播回放可查看：https://www.infoq.cn/video/0ViWrdqyQwNvO7TdQpyD

以下内容基于直播速记整理，经 InfoQ 删减。

大模型改变了搜广推了什么？

颜林：在各位负责的业务里，如果只用一句话概括：大模型真正改变的是搜广推系统的哪一块？能否结合一个典型场景简单对比一下以前和现在的做法？

冯晓东： 目前变化最大的环节在于特征工程，因为我们现阶段的线上模型尚未完全接入生成式模型，而是主要利用大语言模型，为特征构建提供更丰富的补充。

以广告业务为例，我们拥有大量广告素材，需要从中提取合适的特征。过去一年我们尝试了多种多模态大模型，用于生成标签化特征，甚至获取向量化的语义特征。特征挖掘一直是搜广推领域的痛点，同时也是提升效果的关键。大模型在大量开源语料上完成预训练，具备推理能力，不仅能基于用户历史行为挖掘特征，也能补充具有推理性质的增量知识。

因此，我们在用户侧尝试了多项探索，将传统依赖历史统计、序列、交叉等方式构建的特征统一规划为长序列特征，再结合大语言模型或生成式推荐的序列建模能力，离线提取用户偏好或向量化表示。通过这种方式，我们预计能在很大程度上解决特征工程中的瓶颈，同时减少线上模型对统计类、交叉类特征的依赖，从而提升推理效率。

王皓： 从学术界的角度来说，过去一年，我们持续关注如何让模型规模扩大并具备可扩展性（scaling）。我们发现，模型能否真正实现 scaling，很大程度取决于数据的质量、配比以及整体准备情况。在不同任务下，只要数据质量与结构设置得当，模型做大做深后往往都能呈现出良好的 scaling 能力。

但从高校环境来看，算力受限，使得许多工程化方案较难落地。因此，学界近年来更加关注如何在有限算力下让模型训练得更长、序列更长、行为信息更丰富，或者探索更轻量化的 attention 机制，以提升长序列计算效率。同时，推荐系统是否能够在推理层面具备更强的 reasoning 能力，也是正在探索的方向。当前大部分研究仍基于传统的 HSTU 路线，但未来是否继续沿用或需要回到既有路径，学界也在不断讨论。

张泽华： 大模型刚出现时大家非常兴奋，但过去一年这种热情有所回落，核心原因在于：大模型看似“fancy”，但要让这件“fancy”的事情持续发挥价值，需要大量基础性的“dirty work”。例如，如何清洗数据、如何构建高质量的思维链样本、如何在多模态场景中实现语义对齐等。这些工作占去了我们大量时间和精力，一旦处理不够扎实，大模型在搜广推场景中的实际收益就会受到明显限制，算力堆得再多也难以发挥其真正潜力。

因此，我们过去一年最大的体会之一，是从传统特征工程转向更系统化的数据与样本构建方式。这不仅需要新的方法，也需要投入大量人力物力，建立有效的数据组织体系，才能真正让样本构建落地。

系统与模型怎么成长？

颜林：在架构演进上，大家所在团队更偏向于在现有 pipeline 上逐步叠加大模型，还是会针对某些环节重新设计新链路？这中间有没有经历过比较激烈的取舍或争论？

冯晓东： 在实际落地中，全面重构 pipeline 的成本极高，带来的收益也难以量化，特别是在低价值场景中更是如此。因此，尽管我们会持续讨论生成式架构的未来形态，但在真实实验中，仍是围绕 pipeline 的某些环节逐步探索。例如在特征工程中，我们优先思考如何与大模型结合、如何叠加其能力。第一阶段是让大模型先进行补充；第二阶段再尝试用大模型替代某些环节；再往后，我们考虑在现有的召回、粗排、精排、重排链路中，先替代召回，再进一步替代召回与重排等模块。这会是一个逐步迭代的过程，但我们依然相信从长期看，颠覆式 pipeline 有机会最终落地。

张泽华： 最初我们对大模型非常乐观，期望能“一步到位”，由模型直接端到端输出推荐或搜索结果。以电商搜索为例，我们希望大模型能同时理解用户 query、上下文信息以及隐性偏好，从而一次性完成检索。但实际结果发现，这种端到端方式在多数场景中不仅无收益，甚至出现负向效果，因此我们开始系统性拆解问题。过去一年中，我和团队几乎把召回、粗排、精排、创意机制、计费、出价等所有环节逐一拆开，并在每个环节单独验证收益。

最终验证发现，大模型能力主要体现在两个方面：第一是强语义理解，第二是一定程度的推理能力。它们适合的场景，一是传统算法语义理解较弱的部分；二是具有较长逻辑链路的任务。比如曝光后立即点击，这类毫秒级反馈链路较短，大模型难以发挥优势；但在电商中，从兴趣形成到决策、下单甚至收货后的行为，这是一条极长链路，在这类任务中，大模型往往能取得明显收益。

因此，我们内部很多争论都围绕取舍展开。第一，大模型规模变大，会大幅增加实时推理成本和算力开销，而效果提升却未必成比例。传统模型几分钟或数小时即可上线验证，但大模型训练和验证可能需要周级甚至月级周期，这就引发了效率与收益之间的矛盾。

第二，大模型需要大量标准化、高质量的新样本，而传统场景中这类数据往往缺失，需要投入巨大的人力物力重新构造。一旦标注不足或质量不稳，大模型不仅无收益，还可能产生负向效果；但标注足够多时，成本又极高。工业界必须考虑投入产出比（ROI），而我们也观察到大模型不仅在参数规模上存在 scaling law，在精炼样本的数量和质量上也呈现 scaling 曲线。

王皓： 近期大家虽然都在构建完整的大模型 pipeline，但深入分析后可以看到，真正被大规模使用的大模型能力通常集中在个别环节。例如做特征交互、生成更丰富的特征；或将大模型融入召回模块，以增强召回效果。行业真正做到端到端的统一 pipeline 仍有较大差距，更多工作还是在 pipeline 的单点与大模型结合。学界也是类似的趋势，主要在各个模块上做针对性创新，而不是已经完全实现一体化的推荐链路。目前学界与业界都更接近于“多点突破”，而非“全链路重构”。

颜林：在推荐 / 广告场景下，如何看待 scaling law？

冯晓东： 推荐领域的模型同样具备 scaling law，而且我认为其边际效益远未触及上限，尚未像大语言模型那样出现明显的边际递减。

原因主要涉及两个方面：数据与线上推理能力。首先，搜广推依赖的是用户行为数据，与语言模型相比，我们的样本量更大、序列 token 更长。当前模型普遍覆盖亿级用户，单个用户的行为序列长度动辄上千甚至上万。在如此规模下，若想完全挖掘行为模式，模型需要具备极高复杂度，甚至可能比语言模型更复杂。因此，我们必须在模型复杂度与线上推理能力之间寻找平衡。由于线上资源受限，我们实际上并未释放模型的全部潜能。其次，尽管 scaling law 的趋势明确，但要让模型能力真正最大化，目前主要仍依赖在线下进一步扩大规模。如何把线下能力有效迁移到线上，是后续需要重点解决的问题。

王皓： 第一个问题是：推荐领域的 scaling law 应该如何定义？它是否等同于语言模型中的 scaling law？我们最近做了一个推荐 Scaling Law 方向的工作，过程中发现不同数据集、不同任务拟合得到的 scaling 曲线差异很大，并不存在像语言模型那样一个统一的公式，尤其是在推荐领域中，performance 更依赖 loss，而我们观察到的 scaling 规律也主要体现在 loss 层面。

基于此，我们提出了 P-law（performance law）的定义形式：在不同推荐数据集上，将 item ID 词表归一为相同规模，将数据质量约束统一为一致指标后，我们发现不论是在传统模型还是 LLama、SOTA 模型上，都能拟合出较为统一的 scaling 规律。说明推荐领域是可以研究通用 scaling law 的，而非完全碎片化。

第二个问题是：既然 scaling law 可以拟合，我们是否已经接近它的上限？推荐模型到底需要多大规模？当前的模型与数据是否足以支撑继续扩大？我的看法是：推荐模型规模普遍还不够大，还远未到达 scaling law 的极限。而且推荐未来到底走哪条技术路线，是继续沿着 sequence-to-sequence（S2S），还是朝 unified LLM 发展，目前也没有共识。

张泽华： 在推荐与广告场景中，我们距离 scaling law 的天花板还非常遥远。首先，以典型搜广推场景为例，如果假设使用一个真正端到端的模型，在 300 毫秒的推理预算内完成所有计算，要同时理解用户特征、兴趣序列和候选 item，经过反算后，我们推测模型参数量至少需要十几个 billion 才能支撑。然而，即使如此，工程、算力和网络通信必须全部压到极限，300 毫秒已经接近行业上限。

第二个例子来自我们对模型推理的可视化研究。以 7B 规模模型为例，我们逐步分析其每一层的中间状态后发现，不少区域的参数几乎不影响最终结果。这意味着小模型能力不足的原因并非单纯参数量少，而是有效参数比例低。

第三，当我们采用 MoE 结构处理如 query–SKU 这种典型任务时，随着模型参数规模扩大，尤其是有效参数占比提升时，性能呈现明确的 scaling 趋势。这证明在推荐领域，有效参数规模比总参数规模更关键。

此外，我们目前的许多模型，无论传统模型还是 MoE，都做了大量裁剪和折中，有效计算量和可分辨度受到限制。因此，仅仅从 8B 换到 10B 不能保证提升，关键是有效参与推理的部分是否真正扩大。一旦扩大，效果提升趋势非常明显。

接下来分享几个我们在放宽约束后的实验发现。第一，如果暂时不考虑 300 毫秒的实时限制，而允许 3 秒甚至 30 秒推理，我们即可使用更大规模的模型。在不做结构裁剪的前提下，模型参与推理的有效参数大幅增加。在线下评测中，当规模扩大到 200B–300B 时，其效果明显优于 8B–10B。

第二，当我们放宽 input 的限制，把用户 query、历史行为以及商品丰富的描述全部作为输入时，模型效果进一步提升。此时的 prompt 已非常复杂，但 scaling 趋势依然明显，只是斜率不如前几项那么陡。

综合以上，我认为搜广推场景中的 scaling law 依然成立，并且仍在快速上升阶段。关键问题是如何让 scaling 趋势不仅体现在论文和离线评测中，而是真正转化为线上收益。如何在推理耗时、工程成本与规模扩展之间找到平衡，将是未来最重要的研究方向。

颜林：通常是如何平衡模型规模、收益和算力 / 时延成本的？在哪些场景里会更倾向于“小而精”的模型？

冯晓东： 大模型上线时势必面临性能瓶颈，而要突破这些瓶颈往往需要投入大量人力物力进行优化，并配备更多或更高规格的 GPU。因此在实际过程中，我们首先的目标自然是尽可能降低成本。在这一点上，我们主要做了两类探索。第一类是模型蒸馏，无论是大语言模型还是生成式序列模型，我们都尝试用大模型去蒸馏小模型，或以对比学习等方式让教师网络帮助线上小模型学习，从而在保持线下效果的前提下降低线上推理成本。

第二类方法是分层剪枝，也可以理解为压缩。例如某些模型可能有十几层，我们会先尝试只保留一两层，观察其在序列任务中是否仍有收益，并据此裁剪后上线。另一种类似做法借鉴了 DeepSeek 的 MoE 机制，将大专家拆分成多个小专家并加入路由机制，以减少推理时的激活参数量，提升线上性能。

理想情况当然是所有场景都能用小而精的模型取得良好效果，但当前小模型仍有明显天花板。因此我们会优先在低价值场景中使用小模型甚至通用小模型；在高价值场景中，如果 ROI 能覆盖成本，我们才会尝试规模更大的模型。整体策略仍是：低价值场景用小模型覆盖，高价值场景用大模型争取额外收益。

王皓： 从学术角度看，我们还观察到一个现象：在推荐的长链路中，不同阶段所需的模型规模其实不同。例如从召回到粗排再到精排，每一阶段对模型大小的需求并不一致，这意味着模型规模并非越大越好，而是可以在不同阶段进行区分设计。

第二个观察是，很多人希望用 2B 规模模型达到 8B 或 10B 的表现。除了蒸馏，我们也尝试从另一个方向切入：既然许多场景的高质量数据尚未触顶，我们能否通过生成更多高质量数据，训练出性能更好的小模型？我们并不是直接做蒸馏，而是利用大模型生成更纯净、更高质量的训练数据，让小模型在数据端突破瓶颈。按照我们提出的 P-Law 规律，小模型仍有很大提升空间。如果目标模型处于 2B–3B 区间，我们会用更大模型持续生成数据，让小模型逐步逼近这一能力上限。

张泽华： 模型只要能在特定场景中达到目标效果，它就是合格的模型。剩下的都是 ROI 的问题，包括算力、人力与数据成本。因此关键是资源的最优分配，而非一味追求更大规模。

推荐领域存在三类“类 scaling law”趋势。基于此，如果我们手里只有一个 2B 的模型，如何让它的能力最大化？无非几条路径：第一，提高有效参与推理的参数比例；第二，给予模型更高质量、更纯净的训练样本；第三，即便模型小，也可以在输入、输出的设计上扩大规模，让其“物尽其用”。

此外，在企业环境中还有一个现实因素：老板是否认可 ROI。例如一个 671B 的模型，可能需要 16 卡或 32 卡主流 GPU 才能跑起来，并且要支撑每秒上万次请求，还得在几秒内完成完整推理，这带来的成本是指数级增长的。与此同时，推理延迟无法通过无限堆卡来无限降低，因此必须在算力投入与延迟之间找到最优的平衡区间。

低价值场景自然更适合小模型，即便只达到大模型 40% 的能力也完全足够。而在核心高价值场景，例如开屏、信息流、搜索核心位，即便大模型只能带来小幅提升，大家仍愿意投入资源去扩模型规模以争取额外收益。

颜林：当大模型真正上线到生产系统之后，大家遇到过的主要工程挑战是什么（时延、吞吐、资源成本、稳定性等）？从这些经历中总结下来，有哪些坑是可以提醒下同行的？

冯晓东： 搜广推领域的模型高度依赖用户的近期或实时数据，因此模型必须能够快速迭代。传统推荐模型已经能够实现分钟级或小时级更新，但我们当前采用的大模型，其训练和推理都在线下进行，要同步更新就非常困难。核心问题在于，如何让实时或进线产生的大量用户行为能够及时输入模型，并支撑模型快速迭代更新。

我们尝试的优化方向包括：其一，设计更高效的数据流 pipeline，确保生成式推荐模型在训练时能迅速获取样本及必要的序列特征，并以合适方式输入模型。其二是模型的更新方式。对于增量更新，我们需要判断究竟是进行全量全参更新，还是只更新部分参数。因此我们做了许多实验，例如仅更新最后几层、仅更新关键任务的几个塔、或只更新共享网络等。我们也尝试过全参更新，但会遇到上一批生产数据尚未训练完、下一批数据又已到来的情况。为平衡训练成本和更新效率，我们最终更多采用“冻结部分参数”的方式，以取得更稳定的更新效果。

王皓： 最大的困难之一是在线与离线结果长期无法对齐，离线实验表现良好，但上线后的结果常常差异很大。另一个问题是，当我们尝试上线一个更大规模或新版的模型时，会发现线上已有一个相对老旧但长期训练的模型。虽然该模型结构简单、规模较小，但因长期基于历史数据持续更新，它对一年甚至更长周期的数据都有充分学习。而新模型往往只基于最近几个月的数据训练，尽管离线验证中性能更优，但在真实线上场景中却很难打败长期训练的旧模型。

因此，即便验证通过，新模型依旧难以上线。我们面临的问题是：如何让更新后的新模型既利用近期数据，又能有效继承长期数据，从而真正超过线上模型？随着版本增多，需要重新训练的历史数据越来越多，训练与验证成本也随之大幅上升。

张泽华： 王皓老师提到的“离在线对不齐”，是在模型稳定运行之后仍然存在的问题。而在模型能够稳定运行之前，其实还有更多“坑”。大模型时代算法迭代非常快，新模型的发布节奏往往以周甚至小时计，这带来巨大的适配成本。很多算法工程师希望下载一个开源模型就能直接跑在业务场景上，但业务数据有自身结构，训练平台与资源组织方式也不同，因此实际适配难度远比预期高。

适配完成后，大家又希望尽快做在线 AB 实验。但离线能跑通并不意味着能满足线上 serving 的资源和时延要求，尤其是在工业环境中，这个 gap 通常非常大。国内虽然有组织会做 0-day 的在线适配，但一旦你在模型结构中做了任何微调，线上 serving 图通常需要大规模重写，迭代成本非常高。

此外，不同版本模型常常使用不同的 tokenizer，但许多工程师在上线前并不会特别关注 tokenizer 的变更，而是更关注参数量是否更新。一旦 tokenizer 未对齐，模型效果就会出现不可预测的问题。

另一个难点在于，工业场景下用户行为的分布本身就是算法系统长期影响的结果。例如，在某些 App 中，历史模型已筛选出一批习惯“搜→看→点→买”的高效率用户。如果你的新模型更适合“慢节奏、喜欢比较”的用户，即使模型本身更好，在现有交互环境下也可能表现不佳。因此，模型上线后往往需要通过大量随机流量，经历一个漫长的“探索—利用”期，才能评估其真实表现。

很多情况下，新模型上线表现不佳并非模型本身的问题，而是实验环境不够友好。为解决这一点，我们开发了一套工具，包括多智能体强化学习模拟器，能够基于上下文和系统行为构造沙箱环境，让基线模型和新模型先在模拟环境中对比，从而获得相对客观的评价。现实环境中无法获得某个用户在两种模型下的“反事实”表现，而模拟器可以一定程度上弥补这一缺失。此外，我们会不断将线上样本回放到离线或进线的模拟器中，支持大规模持续强化学习。在大模型场景下，无论全参还是局部参数更新，其校验机制都必须更加严谨。

从推荐到广告：生成式、智能体与知识工程

颜林：目前生成式能力在各位所负责业务中的主要定位是什么？更多是做创意 / 文案 / 特征辅助，还是已经开始承担候选生成、策略规划等更核心的工作？以及，个人最期待、但觉得还需要一段时间才能成熟的应用方向是什么？

冯晓东： 目前生成式技术在我们业务中集中在多模态内容的理解与生成，例如营销与广告素材的自动生成。在算法落地方面，我们也在探索生成式推荐的可能性。由于生成式模型具备一定推理能力，我们会基于用户历史的离线数据，先进行推理特征的生成，相当于在用户已有知识体系上补充增量知识。

我们内部也持续讨论一个重要问题：生成式推荐是否能够完全替代线上推荐系统的能力。大家的愿景是一致的，即希望逐步朝这个方向演进。若生成式推荐能承担全流程线上推断，首先能显著简化线上工程体系，从而进一步节省成本；其次，它在大规模在线推断中可能带来显著的业务效果提升。

王皓： 沿着生成式推荐的发展趋势来看，它正逐渐呈现系统工程化的特征，即构建完整的推荐 pipeline，将各环节流程化，并在统一范式下解决多个任务。因此，学界的研究重点也逐步转向如何优化 pipeline 各细节、打通不同模块的衔接，而在此框架内做颠覆式创新的空间似乎相对有限。

张泽华： 从工业界的视角来看，大家的目标都是尽可能发挥大模型的作用。创意文案类任务已经大规模应用，尤其是图像、视频等多模态内容的生成，在扩散模型阶段就已展示出巨大潜力，如今在 AIGC 的演进中仍然保持高速发展。语言类模型出现后，文案生成进一步普及。我最近参加行业交流时发现，无论是营销、电商还是微商领域，很多团队已经非常熟练地使用大模型智能体进行视频制作、文案生成及创意加工。

在零售等企业内部，这类能力也逐渐渗透到更多场景中。例如本次直播过程中，自动翻译、自动文案总结、会议纪要生成、要点抽取等能力，都是基于大模型的自然延伸。在更核心的业务任务中，例如 item 筛选、广告投放策略规划等，许多团队也在尝试使用大模型提升效率。特别是在面向“小 B 端”，即没有专门研发团队的商家群体，自动化工具尤为受欢迎。无论是生成营销文案、整合外部数据还是自动挑选关键评论，这类功能都已非常普遍。

我个人认为接下来值得期待的方向，是出现真正具有高度灵活性的智能体。当前的大部分智能体仍基于人工定义的 workflow，由人预设步骤与业务逻辑，本质上属于流水线式执行。而未来更具价值的智能体，应具备自主规划与自主研究能力，能够在更少人工干预的情况下完成复杂任务。

颜林：从智能体、知识工程、系统架构、行业标准等不同角度出发，你会如何描述：大模型时代，一个“成熟的”搜广推系统应该长成什么样的生态？这对团队分工和角色有什么影响？

冯晓东： 我认为未来特征工程可能会逐渐弱化甚至消失，并被知识工程取代。也就是说，模型学习可能直接基于用户的原始行为语料来构建，不再依赖大量人工设计的特征，而是需要通过增量知识进行补充。这类增量知识，例如基于大模型能力构建的知识库，可以为推荐系统带来新的优势。以冷启动为例，有了更多开源或预训练的知识，知识工程能够弥补冷启动过程中的信息不足。

此外，随着模型直接使用大量用户行为序列和原始特征，我们还需要引入上下文信息、item 画像或用户基础画像等内容，这些都可以通过知识工程进行系统性丰富。

再说系统架构的变化，未来智能体可能在搜广推中扮演更重要的角色。目前各家公司在智能体编排方面已有大量实践，我们也在思考是否可以将特征工程或模型训练流程以智能体编排的方式推进。换句话说，未来搜广推的算法工程师可能会逐渐演变为“跑模工程师”。

王皓： 从学术角度来看，有两个根本性问题需要明确。第一个问题是搜广推的基础模型究竟应该是什么？它应该基于怎样的机制来实现决策？只有想清楚基础的决策模型，我们才有可能进一步讨论智能体、自动编排等能力。如果不解决“如何将 ID 这样的离散表示融入模型”这一核心问题，我们很难真正往下推进。

第二个问题是：如果我们希望让整个系统最终变成 workflow 或 problem-based 的形式，并通过智能体来完成任务，那就必须首先把这个任务形式化定义出来。我们需要明确任务的边界、结构与规则，使模型能够理解并解决它。怎么定义任务、怎么表达问题本身，是比解决模型细节更难的环节。

张泽华： 在不同业务场景下，问题的定义确实差异很大。例如传统推荐的召回与粗排，本质上就是信息检索：粗排是对子集的筛选，召回策略宽松或严格都能接受；而精排与重排阶段，则需要大量 ID 之外的辅助信息。

辅助信息大致有几类：第一，item 与 item 之间的关系；第二，用户在前一次结果与当前展示之间是否产生兴趣变化；第三，一些人为定义的重排指标，如多样性、新颖性；第四，则是多模态信息。例如推荐一件商品时，不仅是商品本身，还有价格变化、优惠信息、图片质量等因素都会带来影响。比如图片美观度、上下文差异甚至一些“反常图片”带来的好奇心，都会显著提升点击率。

在基础模型的测试上，我们发现对于传统信息检索类任务，目前的大语言模型（尤其是稠密结构）表现相对适用，引入 MoE 也没有太大问题。但对于典型的曝光→点击→转化这样的单链路任务，HSTU 类模型，需要结合用户与当前上下文交互，再叠加大量背景信息，会更适合具体业务场景。

观众：离线和在线不对齐，新模型打不过旧模型，这样的问题该如何处理？

张泽华： 新旧模型对不齐大致有两个层面的原因。第一，在传统模型中，在线模型在 online learning 的过程中会不断累积数据，而离线模型只能在特定时间点获取有限数据，因此离线效果即使优于在线，但由于在线模型长期积累，实际仍可能更强，这就导致新模型难以在短期内打过旧模型。

第二个层面是离线评测与线上环境之间存在失真，这在工业界非常常见。在大模型中，这类失真甚至会被放大，原因主要有两点。第一，传统 CTR 类模型本质上是“小稠密 + 大 embedding table”，大量依赖稀疏 ID 特征，而真正可学习的稠密参数很有限，因此模型具有更多不可变结构，导致线上失真程度较低。第二，大模型的参数量巨大，离线推理与在线推理的路由机制可能存在差异，导致误差被进一步放大。

对于传统 online learning 无法打平的问题，如果离线训练无法提供足够数据，就要判断取舍。若离线模型虽然离线评估更好，但潜力不足，而在线实验表现不如旧模型，那继续维护旧模型是更合理的；但如果离线模型虽然短期略差，但扩大参数或数据后会有更陡峭的 scaling 曲线，那么可以接受短期损失，将新模型推上线上，保证团队整体迭代节奏顺畅。

第二类结构性误差问题没有绝对解法。若误差特别大，要回到训练与评测环节排查；若误差在可接受范围内，则应直接通过 AB 实验检验其是否能随着时间逐步收敛。

王皓： 在推荐领域，HSTU 这套范式是否可能成为未来的推荐基础大模型？我们未来应该走向“RL for reward”的方向，将推荐转化为反语言模型式的决策任务，还是继续沿用 HSTU，让其成为长期的反推选模型结构？

冯晓东： 之所以包括我们在内的许多团队都选择 HSTU，是因为它本质上仍是 Transformer 风格的结构，但对长序列用户行为的处理具有独特优势。因此可以明确的是：序列模型是推荐领域的关键方向。

目前 HSTU 作为一种生成式序列模型，为我们提供了不错的 base model。尽管推荐系统和大语言模型都尚未跳出 Transformer 结构，但过去推荐系统的发展确实大量借鉴了 NLP 与 CV 的网络结构，例如 CNN 在推荐中的应用。因此我始终期待未来推荐系统能够结合自身数据特征与业务特征，发展出新的、更贴合长序列特点的模型结构。

颜林：在过去这一两年大模型和搜广推的实践里，有哪一件事情是让你改变过自己原本的判断的？比如：曾经觉得不重要但现在很重要，或者相反？

冯晓东： 我们一直关注一个问题：大模型是否会在推荐领域产生颠覆性的影响。我最初的判断是，基于语言 Token 的建模方式并不完全适用于推荐场景。因为用户行为序列在转换成 Token 后，其上下文之间往往不具备类似自然语言那种强逻辑性的结构，因此传统语言模型并不能直接替代推荐模型来生成推荐结果。直到 Meta 提出 HSTU，我才意识到序列模型在推荐场景的潜力被进一步释放。HSTU 以 Transformer 为基础，但对用户长行为序列的处理方式更契合推荐系统的需求，也为我们提供了全新的方向启发。序列建模会是推荐领域的核心方向，大语言模型在网络结构设计和整体建模思想上确实为我们提供了重要参考。

王皓： 推荐系统实际上一直在沿着大语言模型的路线演进，只是过程中会遇到如何处理 ID、扩大词表、推理时延等工程与结构问题。从长期趋势看，推荐系统仍需与基础语言模型深度结合。只有在此基础上，我们才能构建面向不同业态和公司场景的通用大模型。

另一个关键挑战在于数据。模型性能的上限取决于高质量数据的数量，而未来的重要研究点仍会集中于如何构建更多高质量数据、如何扩大模型规模以及如何进一步提升性能。

张泽华： 行业共识是“有多少人工，就有多少智能”。过去一年，业界在结构、优化器、attention 等方面不断创新，但真正落到工业场景，数据是决定性因素，没有高质量数据，所有结构创新都无法发挥。通用大模型在垂直领域的效果往往很差，因此我们必须沉淀专业化的知识工程。我们内部将其总结为六大类知识体系，并在推荐、广告、搜索等场景中带来了显著提升，很多改进都达到两位数甚至更高收益。

回到“推荐系统到底在解决什么用户问题”。以电商为例，用户可能带着明确意图进入 App，例如搜索特定型号，这时系统只需快速给出直接结果。但在用户漫无目的浏览时，他们有更高耐心接收不同品类的内容；而当进入“货比三家”的深度对比阶段，用户会进行反复思考，此时推荐系统的任务不再是传统召回与排序，而是利用模型的推理能力来辅助决策。

例如比较手机规格、容量或屏幕优劣，本质是一种反复权衡的 reasoning 过程。传统算法可以部分支持，但新一代大模型的推理能力能够提供新的解决手段。因此我们在探索新的推荐路径，例如在不同意图状态下的搜推策略：用户随意浏览、明确搜索、深度对比、争取优惠等。

颜林：如果让你给现在在一线做推荐 / 广告算法的同学一句建议，结合大模型的浪潮，你会建议什么？

冯晓东： 最初探索大模型与推荐系统结合时，我们也并不确定最终形态。传统推荐模型本身也是从不同方向借鉴、引入并不断改进的。因此在真正落地时，我们首先思考的问题是：未来如果走向生成式推荐，那么我们在现阶段应该如何切入？我们的做法是先把业务链路完整拆解，无论是广告还是传统推荐，逐段分析每个环节的核心目标，并判断哪些环节最适合与大模型结合。

找到切入点后，不必过度关注模型上线后究竟能提升多少效果。我们更看重的是是否真正解决了某个问题，只要能在效果、运营成本或推理成本中带来任何方面的优化，都值得尝试。不应拘泥于某项技术是否是主流，也不必期待每次都带来爆发式收益，所有革命性进展都是逐步积累而成的。在未来回望时，可能某一次迭代便成为真正的突破。

王皓： 一个真正的基础模型应该能解决多类任务，并能在不同公司间迁移、共享和复用，这是生态价值的核心。另一个重要思考是，我们的系统是完整链路，而不仅是单点技术。模型或系统需要形成“产品力”，需要让别人看到其独特性和不可替代性。尽管理论上的链路类似，但我们必须思考自身的壁垒和差异化：我们的场景优势是什么？哪些能力是别人无法轻易获得的？这将决定最终的竞争力。

张泽华： 在过去几年，大模型演进的趋势始终指向更综合的方向。从早期简单的 CV 模型，到 NLP 时代的 BERT，再到如今的 Transformer 大模型，以及行业内大量尝试的多模态融合模型，如 ViT、DiT 等等。无论是搜索、推荐，还是传统算法升级，本质要解决的业务问题并不会消失，它们只会转移。比如先解决某一模态的问题，另一模态仍需要处理；先解决检索问题，排序问题仍然存在。只是方法和路径不同，本质问题依旧。因此我对大家最大建议是，不要给自己设定过强的边界或挑拣式学习，所有核心问题最终都必须被解决，而且需要被解决得足够好。