搜广推，吃到这波大模型红利了吗？

"

生成式搜广推，伪需求

生成式搜广推，耗时跟得上吗？卡跟得上吗？

看你这效果就提升一点点

你这真的是完全端到端吗？你后面咋还接了个精排模型...

或者说完全端到端，在真泛需场景中，能撑得住吗？出了badcase，咋调？

"

甜蜜的技术债：祖传代码的沉重包袱

目前搜广推基本还是召回-排序为主的经典级联结构。

有过在各厂主搜，主推经历的同学应该都接手过祖上留下来的历史包袱很重，策略极多的代码，很多策略甚至不知道还在不在运行，下游有没有用，关键特征获取的词典可能显示的负责人都不对了，很多特征为什么要这样做，没有文档，除了当时代码cr记录，其他啥也没有，甚至不知道当时为啥上，为啥又马上下了。整个部门的人好像有代码注释羞耻。

本身整个系统调整改动的难度极大。算法能在原来基础上调整，就尽可能在原来基础上修改，大多数内容能不动就不动。

大模型这波，主搜，主推都喝到了什么汤？

teacher模型可以更强了，参数量更大的teacher模型蒸馏线上小模型带来提升。召回，排序主干模型均可使用。

大模型带来的训练方法，诸如MOE稳定训练等，让主干模型有更多的选型空间。

打标更方便了。原来靠人工标注，现在大模型打标，大模型辅助标注都能带来效率提升。很多训练集数据增强的活，大模型干得挺好。

对于离线的特征生产等，相对没啥耗时需求，大模型能带来更好的效果。

能更从容得做多语言任务。

其他好像，没了？

是时候想想更合理的搜广推架构了

召回、排序本身，能动吗？不少厂在召回排序本身已经是端到端了。

再激进一点，

那么召回-排序的架构能动吗？搞个完全端到端有可能行吗？

上周六参加快手线下的交流会，介绍分享了One系列的各项工作，在搜广推的落地，现场人超级多，氛围很好，来的基本都是业内同行或者同方向有理解的在读研究生博士生。在提问环节对于很多问题都提问的很好，都是目前的痛点。

本来对于这类文章，完全端到端，感觉非常噱头...

因此在那之前，一篇one系列的文章都没点进去看。  在当听完团队成员介绍One系列的时候，我觉得生成式搜广推本身的级联结构真的该动动了...

工程开销

首先谈谈工程开销，生成式给人的感觉就是慢，搜广推对耗时的要求相对高，不少人从直觉来看，生成式没法用。

下面来算笔账。

目前召回-排序为主的经典级联结构，整体来看，MFU低得离谱。

实际有效计算

硬件理论峰值

MFU 低的本质就是：GPU很强大，但我们交给它的任务太碎、太小，或者它总是在等待，而不是在计算。

级联架构将推荐流程分为多个阶段（召回粗排精排重排），每个阶段都使用不同的小模型（任务太碎、太小），模型规模受限于QPS和延迟要求。还需要花大量资源用于非计算任务（GPU处于等待，而不是在计算）。

诸如通信开销：stages之间的数据传输。

存储开销：中间结果的读写。

复杂的embedding查询等。

这么算下来，整体MFU惊人得低。1%以下，你敢信。

那么推荐场景下，从成本角度考虑，最大能承受多大的模型呢？

在现有的硬件环境和业务收入形态下，假设输入+输出token控制是1000，那么计算下来，能支持7.6B参数的模型。

这个参数量是不是远远超乎在级联结构优化的同学的想象。

收益从哪拿？

再来谈谈从级联结构改到生成式端到端，收益从哪里拿？

@王喆 大佬总结的很好

1）模型规模的扩大，带来的scaling law效果提升

2）超长用户行为系列输入模型带来的效果天花板提升。

3）生成式推荐新范式带来的推荐框架一体化收益，这里又分两部分。

推荐框架简化带来的工程成本下降；

合并级联结构使模型优化目标统一，带来的效果收益。

关于目前的生成式推荐

从业务收益来看，目前的探索中，没出现爆炸式增长。投入产出比尚不明朗，这也是很多人质疑生成式搜广推必要性的核心。

其次是完全端到端，在真泛需场景中，能撑得住吗？出了badcase，咋调？

OneRec是有个奖励模型，通过调奖励模型来调。但肯定还有很多小问题，没必要这么大费周章调整。

从我的角度和工业界实际情况来看，完全端到端是美好追求，但围绕主干的端到端，保留必要的、灵活的辅助策略或小型处理模块，具备快速响应和修正边缘问题的能力，也是很正常的嘛。现在大家也是这么干的。

新技术新范式的初期总是艰难的，顶尖厂有技术积累，敢于那么大范围得调整方向去探索，非常值得赞赏。越是顶尖的技术团队，越应该拥抱这次技术革命。

一些看到的有启发的内容

@周国睿大佬关于code book和解码的理解很有启发

”

Code Book 大小：有没有ngram信息可以学习

过往的推荐模型都是以原始的item id为基础构建的，这样的模型对应的code book大小就是item的总量，在10B附近，做了裁剪也在1B附近。而LLM与之对应的code book的大小在100k这个量级。确实，我们这个世界上的知识，用100k的总unique tokens完全能表达清楚了。推荐用1B的token来表达样本，最大的问题在于这么稀疏的表达下，没有太多的ngram信息可以被压缩学习。考虑原始item在一个用户行为序列里面的2元组 (item1,item2)，三元组(item1,item2,item3)，四元组(item1,item2,item3,item4)共现。即使推荐的样本量巨大，一天10T的token总量样本里，恐怕也没有多少四元组共现可以被压缩学习。即使有共现的四元组，他们也大多是热度系统bias的产物，里面的知识剩多少存疑。而LLM则不同，在语言里面，code book只有100k的时候，10T的token总样本量里存在大量的多元组也就是ngram tokens可以被学习和压缩。因此LLM可以学到很多知识，而推荐的学习样本量其实比LLM还普遍大一个数量级（以我手为例，模型一天都要训练30T的样本，还不考虑一条样本是多个token），却学不出智能。没有太多ngram信息可以学习，也是推荐模型增加id emb维度效果增益不显著的原因，毕竟本来就没有多少共现信息需要记录嘛，只记录这个id在共现矩阵里有限的相邻边信息就行了。

解码长度：能思考能推理。

这就完全是个人观点了，有些观点我团队的小伙伴也不认可呢，不过不影响我们共同进步。

LLM的思考和推理能力，在我看来很大程度上是源于token解码步长增加对应了搜索的深度。如果把LLM的解码过程理解成每一个step都在进行100K token的树检索，得到最终答案之前，生成的token越多，就是这个树检索的搜索深度越深。而每一个过程里面的token，都是未来的输入，能帮助模型从自己的参数里面，通过causal transformer激活更多的信息出来对答案做判断。

在判别模式下推荐也有infer的 scaling，不过是宽度检索的scaling，即在每个模块我们增加打分的候选集合大小，模型效果也会变好，不过估计各家这个quota都快打到效果上界了。

但是候选集合扩大是一种宽度检索，不是深度检索。每个候选item的计算是独立的，并不会因为这些计算的增加而增强模型对某个item的判断能力，所以天花板应该是有限的。理想的状态应该是，我们增加的这些计算，对未来结果的推断精度有帮助：infer计算增加生成更多的前序token，这些token能不断的提供更有效的context信息，让结果更准确。

而要实现这一点，把推荐的行为数据也当作一种模态，和语言/声音/图像这些模态在一个LLM基座里对齐是非常必要的。只可惜，我们到现在也没完全找到好的方案，好消息是有些眉目，不过还不足以拿出来分享

“