原文链接https://zhuanlan.zhihu.com/p/2084072802139820141博客地址https://blog.recsys-frontier.com/第一次听到“技术深度”这个词是我工作的第二年。那时候我觉得工作已经比较得心应手绩效反馈也很好拿到了第一次晋升机会。但在 review 的过程中我第一次被挑战了一个问题技术深度不足。我其实没有理解什么叫“技术深度”第一反应是“技术难度”。当时我的工作都很业务导向但也不乏有难度的项目比如在几乎没有 Infra 的前提下搭建了一版双塔召回。部门的 Leader也是当时的评委给我举了一个例子。他说他在 review 达摩院的晋升时会看到有人把失败的实验也放在 PPT 上不只是知道什么方法成功了还要知道哪些因素导致成功、哪些因素导致失败要知其所以然。晋升被否定当然是极度失望的但从失望里走出来之后我开始恶补那些经典的 Paper养成了扫会、读 Paper 的习惯也会找一些工作去复现结果好的再尝试用到工作里。回头看这其实是一个好的变化它让我从“把事情做出来”开始更多地思考“为什么这个事情能做出来”。但也是从那一两年开始我觉得整个业界有一点不对劲了。如果技术深度的本质是知其所以然那么它其实很难被准确衡量。尤其 ML 本身是一门偏经验的科学我们经常可以通过实验知道一个方法有效却很难真正把原理解释清楚。于是技术深度逐渐被锚定到了一个更容易执行和评价的动作上——实验和消融。再加上 TensorFlow 和深度学习的普及大幅降低了修改网络的门槛学术界和工业界的 Paper 又开始爆发相当多的工作都集中在模型结构上。于是技术深度在执行层面慢慢模糊了原来的面目。一个很常见的工作 Pipeline 变成了看到一个新的模型结构就把它的子图加进自己的网络看到一个新的 Attention再加进去再加一个 Cross Module、一个 Expert、一个新的 Loss。最后模型越来越像一个由很多不同工作里的子模块拼出来的缝合怪。这些工作当然不是没有价值。问题在于技术深度本来想表达的是对问题本质的理解但复杂度慢慢变成了深度的代理指标。我们本来应该追问“为什么”最后却很容易变成了“还能加什么”。所以最近两年我开始尽量避免说“技术深度”这个词。一个直接的原因是我发现团队里一些最优秀的同学也会很自然地走向卷模型结构。相比之下我后来讲得更多的是另一个词技术品味。对于一个研究者来说可以提出大量方案依次实验最后由结果驱动找到新的版本答案。但在公司里这往往不是最优的因为人、机器、流量和时间都是有限资源。技术直觉的重要性就在于在你能够枚举出来的很多方案里提前砍掉大多数只保留有限几条真正值得探索的路径并且让最终的方案尽量接近长期最优而不仅仅是当前这个点上的最优。这种技术直觉一部分来自过去积累的技术深度另一部分则来自技术品味。我理解的技术品味本质上是判断什么值得做而不是“只要有收益就做”。比如同样面对推荐模型效果提升你可以加一个 auxiliary loss、加一个 expert、加一个 cross module、加一个特殊 attention、加一套新的 sample strategy。但一个有技术品味的人会问这个东西值得让整个系统永久复杂一点吗它是 scalable 的方向还是只能拿一次收益它与长期 architecture 是一致的还是在制造技术债能不能通过数据、算力、统一建模把这个特殊模块删掉我们到底在解决什么问题这个问题真的存在吗更基础的问题是什么所以我现在会把技术深度和技术品味做一个区分。技术深度让你理解得更深、看到更多可能的解法技术品味则决定哪些解法值得留下。前者让你的搜索空间变大后者负责做取舍。技术深度很容易表现为做加法而技术品味的核心是长期价值判断和取舍能力很多时候表现为做减法。做技术和做产品的逻辑其实很像。乔布斯有一句很有名的话“Innovation is saying no to 1,000 things.” 真正的产品判断力是知道什么不要做。技术也是如此。OneTrans 对我来说就是一个很典型的例子。它并不是在努力发明一个新的模型架构。正相反它里面那些和标准 Transformer 不同的部分比如 per-token、金字塔结构虽然都可以带来更好的效果或者 ROI按照一般的论文叙事也完全可以被包装成“创新”但我一直觉得它们也许只是当前认知和局部工程约束下的次优解。真正值得追问的问题反而是为什么不能使用一个尽可能标准的 Transformer最早一个版本的 OneTrans其实也带着这种模型架构拼接的思想。有一个 SeqFormer 负责处理序列再有一个 MixFormer 负责特征和序列融合。虽然从代码实现上看和后来的版本差异未必很大但表述背后的思想却完全不同。前一种思维是序列有序列的问题特征交互有特征交互的问题所以分别设计不同的模块后一种思维则是先假设一个尽可能标准的 Transformer 就应该能够解决推荐问题然后研究怎样把推荐的数据重新组织进去。所以 OneTrans 真正研究的重点并不是还能发明什么新的结构而是怎样重新组织样本和特征把它们塞进 Transformer并且让这个架构能够持续 Scaling 算力和数据包括更多样本、更长序列和更多特征。其实第一版 OneTrans 的特征侧底部还拖着一堆上一个时代遗留下来的结构比如 DCN、FM、SIM、各种显式交叉。后来的工作反而是在不断做减法Transformer 加 Scaling 到底够不够强如果够强我们为什么还需要预先设计这么多显式交叉于是这些子结构慢慢被一个个砍掉。我恰好经历过大规模稀疏 LR 的时代。那个时候算法工程师很大一部分工作都在思考怎么处理数据——怎么组织样本、怎么构建特征。即便到了 TensorFlow 和深度网络的时代我也一直很清楚大头的业务收益来自数据一部分来自数据和网络架构的 Co-design真正只来自纯粹模型结构变化的收益其实很小。所以我一直觉得 LR 时代的算法工作有一种特殊的优雅无论是怎么往模型里填数据还是模型本身的结构都非常简单和克制。今天把 LR 换成 Transformer我觉得某种程度上正是这种优雅的延续用一个足够标准、足够通用的模型把算法工程师的工作重心重新拉回到数据上。这自然会引出一个问题为什么是 TransformerTransformer 已经统一了 NLP又进入了 CV语音也可以很自然地纳入。当同一种架构已经能够跨越文本、图像、语音这些差异如此巨大的模态时我们反而应该追问推荐系统到底有什么特殊性特殊到必须拒绝 Transformer如果没有一个足够强的理由那么默认假设应该反过来——Transformer 同样应该能够统一推荐系统。很多时候追求差异性的长期性价比远低于追求通用性。BERT 出现之后一个重要变化并不只是某个任务上效果更好了而是大家开始意识到当一个通用模型能够覆盖越来越多任务时再为每一个任务单独设计一套模型意义会越来越小。局部最优追求的是单任务收益通用性追求的是整个技术体系的长期 ROI。而 ROI 的分母也远不只是机器成本。很多团队讨论 ROI 时默认看 FLOPs、QPS 和机器数但真正的成本还包括研发人力、迭代时间、系统复杂度、维护成本、知识迁移成本以及不同任务之间无法复用带来的重复建设。一个特殊模块今天拿到一次收益可能意味着未来很多年都要继续为这个差异性付费。Transformer 还有另一个重要优势它抽中了 GPU 的彩票。Transformer 的主体计算是大矩阵乘法可以非常高效地跑在 GPU 上反过来今天的 GPU 和整个 AI Infra 生态也越来越围绕 Transformer 和 LLM 优化。从 FlashAttention、Megatron、FSDP 到 Compiler 和各种 Kernel都在围绕这套计算范式持续积累。一个算法如果天然顺着整个计算生态的发展方向就会不断获得硬件、框架和社区共同提供的复利。从这个角度看技术品味和 Transformer 的关系也变得更清楚了。当模型架构确定以后我们可以对非常多研究岔路说“不”。没有新的架构有时候反而是最大的创新。它迫使我们停止不断增加局部结构把注意力放回真正可以持续积累的方向数据、算力、训练方法和 Infra。技术品味还有另外一个我越来越重视的来源就是有没有能力提出更 Fundamental 的问题。表层的问题通常是这个模块怎么加这个 Loss 怎么改这个 Feature 怎么利用这个模型还能怎么涨这些问题都默认接受了当前的问题定义只是在已有框架里面继续优化。Fundamental 问题会再往下一层追问我们为什么需要这个模块这个问题本身是不是旧系统结构制造出来的如果今天从头设计这个模块还会存在吗真正限制效果的是模型结构还是数据、算力和训练方式有没有一个更简单、更通用的问题定义可以把几个表面问题一起消掉这也是为什么技术品味经常表现为减法。当你不断追问更 Fundamental 的问题很多表面上的“问题”会直接消失。原来需要五个模块分别解决的五个问题也许本质上只是同一个底层问题一个看起来非常精巧的结构也许只是因为过去模型容量不够、数据组织不对或者 Infra 不成熟才不得不被发明出来。所以如果现在再让我区分这两个词我会觉得技术深度更像是你能把一个问题向下理解多少层技术品味则是你选择解决哪一层的问题以及什么值得长期留下来。技术深度让你看到更多可能技术品味决定你放弃其中的大多数。而 Fundamental Question 之所以重要是因为一个好的问题并不是帮助你在大量解法里做更精细的搜索而是直接消灭大量根本不需要存在的解法。