企业官网建设流程全解析

原文链接：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，我觉得某种程度上正是这种优雅的延续：用一个足够标准、足够通用的模型，把算法工程师的工作重心重新拉回到数据上。

这自然会引出一个问题：为什么是 Transformer？

Transformer 已经统一了 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 之所以重要，是因为一个好的问题并不是帮助你在大量解法里做更精细的搜索，而是直接消灭大量根本不需要存在的解法。