怎么让推荐效果随模型算力投入增大而显著增长？

先思考为什么推荐模型，如精排模型，没有明显的scaling law。我想主要是三个问题：

• 1. 问题定义：判别 or 生成。

  • 推荐模型在非常长的时间内，都被定义为解决一个判别问题，即已知推荐结果item的情况下，预测用户接受的概率 P(xtr|item,user).#card

    • 在这样的问题定义下，最有效的算子或者模型结构就是target attention，即拿着 target item，去检索用户或者其他context中和这个item相关的信息。

    • 这会导致在每一条样本的学习过程中，模型的关注的信息范围急剧减少。

    • 虽然用户兴趣是多种多样的，但是对于每一条被学习的样本，target item确定后，attention都能让模型关注信息快速收敛。

    • 同时，推荐模型的训练过程就有极强的曝光偏差，只能从已经曝光的样本分布中学习，要面临的却是全局候选集。

    • 这两个因素耦合下，判别模型的智力天花板恐怕本身就有限。

  • 如果把推荐定义成一个生成任务，模型面临的问题就变了。#card

    • 生成模式下， 要求模型先把用户和其他context信息做压缩，

    • 这个压缩的信息要能对所有潜在item判断用户是否喜欢，这个问题的解空间和复杂度是比判别模型大得多的。

    • 更复杂的问题，可能才能撑满更大的算力投入。当然上述一段都是我自己的假设和分析，不严谨。

• 2. Code Book 大小：有没有ngram信息可以学习。

  • 推荐模型和 LLM 的 codebook 大小对比 #card

    • 推荐模型都是以原始的item id为基础构建的，这样的模型对应的code book大小就是item的总量，在10B附近，做了裁剪也在1B附近。

    • 而LLM与之对应的code book的大小在100k这个量级。确实，我们这个世界上的知识，用100k的总unique tokens完全能表达清楚了。

  • 推荐用1B的token来表达样本，最大的问题在于这么稀疏的表达下，没有太多的ngram信息可以被压缩学习。#card

    • 考虑原始item在一个用户行为序列里面的2元组 (item1,item2) ，三元组(item1,item2,item3)，四元组(item1,item2,item3,item4)共现。

    • 即使推荐的样本量巨大，一天10T的token总量样本里，恐怕也没有多少四元组共现可以被压缩学习。

    • 即使有共现的四元组，他们也大多是热度系统bias的产物，里面的知识剩多少存疑。

  • 而LLM则不同，在语言里面，code book只有100k的时候，10T的token总样本量里存在大量的多元组也就是ngram tokens可以被学习和压缩。#card

    • 因此LLM可以学到很多知识，而推荐的学习样本量其实比LLM还普遍大一个数量级（以我手为例，模型一天都要训练30T的样本，还不考虑一条样本是多个token），却学不出智能。

    • 没有太多ngram信息可以学习，也是推荐模型增加id emb维度效果增益不显著的原因，毕竟本来就没有多少共现信息需要记录嘛，只记录这个id在共现矩阵里有限的相邻边信息就行了。

• 3. 解码长度：能思考能推理。

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

  • LLM的思考和推理能力，在我看来很大程度上是源于token解码步长增加对应了搜索的深度。#card

    • 如果把LLM的解码过程理解成每一个step都在进行100K token的树检索，得到最终答案之前，生成的token越多，就是这个树检索的搜索深度越深。

    • 而每一个过程里面的token，都是未来的输入，能帮助模型从自己的参数里面，通过causal transformer激活更多的信息出来对答案做判断。

  • 在判别模式下推荐也有infer的 scaling，不过是宽度检索的scaling，即#card

    • 在每个模块我们增加打分的候选集合大小，模型效果也会变好，不过估计各家这个quota都快打到效果上界了。

  • 但是候选集合扩大是一种宽度检索，不是深度检索。#card

    • 每个候选item的计算是独立的，并不会因为这些计算的增加而增强模型对某个item的判断能力，所以天花板应该是有限的。

    • 理想的状态应该是，我们增加的这些计算，对未来结果的推断精度有帮助：infer计算增加生成更多的前序token，这些token能不断的提供更有效的context信息，让结果更准确。

  • 而要实现这一点，把推荐的行为数据也当作一种模态，和语言/声音/图像这些模态在一个LLM基座里对齐是非常必要的。#card

    • 只可惜，我们到现在也没完全找到好的方案，好消息是有些眉目，不过还不足以拿出来分享。