算法工程师的核心能力是什么

type

status

date

slug

summary

格子

以推荐算法为例。当你加入一家公司的第一天，系统的架构和流程是定好的。

推荐系统的 pipeline 已经跑着了，召回、粗排、精排、重排，每一级用什么模型、什么特征、什么样本，都有既定的方案。给算法工程师留出来的，是几个格子——在既定流程里的固定节点上，做有限变量的修改。换个模型结构，加几维特征，调调超参，跑个 A/B test，看看指标涨没涨。

大多数算法工程师的日常，就是填格子。

这不是贬义。填格子是基本功，是入门的必经之路。但如果你的全部职业生涯都在填格子，你的天花板就是那个格子的大小。

真正拉开差距的，是能改格子、甚至重新画格子的人。

重新定义 pipeline 本身，改数据流的组织方式，加一个新的 stage，把离线链路改成实时，把不通的模块强行串联——这些事情，需要的不是更好的算法直觉，而是工程能力。

那不是有专门的工程架构师吗？

两个问题。第一，架构师未必懂算法（懂的话他就是最好的算法）。他不知道你为什么要改，不理解算法的意图，给你搭出来的东西可能方向都是错的。第二，跨团队协作本身就是创新最大的阻力。你提需求、排期、评审、联调，一个来回两个月过去了。而且架构团队优化的目标函数和你不一样——他追求稳定性和通用性，你追求灵活性和实验速度，这两个天然矛盾。

顶级的算法工程师，就应该是半个工程架构师。

我讲几个自己的经历。

上一家公司，团队接了一个新业务，目标是两个月内拿到 10% 的提升。按照一般流程，就是交接、看代码、分工找优化点、做实验、上线收益。

我没有把时间浪费在晦涩难懂的交接代码上。我根本不需要知道之前是怎么做的。我只需要知道一件事：顶级的推荐系统应该是什么样的。

我和我的一个师弟花了一个月时间，从头写了一套推荐系统。串联公司最前沿的推荐组件，重新组织样本和特征，重新训练模型。一个月之后上线，不留一行老代码，直接拿到 15% 的收益。

而其他人还在纠结"这个实验涨了 1%，到底要不要上线"。

大多数人把"理解现有系统"当成第一步。但有时候，理解旧代码恰恰是陷阱——它把你的思维锁死在别人的设计空间里。掀桌子重来，反而是最快的路。

做搜索 ranking 的迭代。搜索用的是一套 C++ 核心的交战马系统，核心机器资源和权限都被别的团队占着，我只能在它设计好的框架和流程下迭代。推荐侧的 rtp 套件明显更好用，但 sp 到 rtp 是不通的，而且 sp 和 rtp 都没有组织特征的能力。

一般人到这儿就认命了：基础设施不是你的，权限不在你手上，那就在格子里慢慢磨吧。

我用了一个额外的 dii 服务做中转，硬生生打通了 sp → dii → rtp 的链路，顺便在 dii 里把特征组织也做了。迭代效率直接翻倍。一个 5% 的上线结果，就把整个 infra 给换掉了。

刚到新公司的时候，发现 I2I 召回的链路是个 Python 的 UDF，慢得要死。我直接重构成 Java，做了第一级加速。

然后我发现更离谱的事：它的数据上线，居然是部署在一个在线容器里，一条一条地写存储。那时候体量还小，居然要一整天才能把数据写完。

我用了一个 MapReduce 重构，固定 64 个 reducer 并发写，半小时写完。

当然这不容易——你得在 YARN 的环境里调通在线服务的写入，额外给 YARN 打一个 Docker 搞定写入环境。但搞定之后，我的迭代效率是别人的数倍。整个业务所有的 I2I 召回，几乎都是我上线的。

新公司当时还没有 SIM 超长序列建模。开始做的时候，架构团队评估开发要一个多月。

一个多月？我和另一个算法同事一商量——搞个离线版有什么难的？他搞历史数据组织，我搞在线服务，两个星期 launch 上线，直接拿到了收益。

有工程能力的算法工程师，可以肆意地改造流程，让迭代更高效，让系统更符合算法的预期，做无限变量的修改拿到业务结果。 而格子里的人，只能做有限变量的修改。

当算法收敛，Infra 就是战场

以上还只是推荐系统的例子。如果你把视野放到大模型领域，这个结论会更加清晰。

大模型时代，算法已经高度收敛了。大家用的都是 Transformer，谁用得好、模型大、数据大、infra 好、迭代快，谁就有优势。差异化不在模型结构的创新，而在谁的基础设施更好、迭代效率更高、GPU 压榨得更狠。

前一阵子听（OpenAI）翁家翌的播客，他参与了 GPT-3.5、GPT-4、GPT-5 的训练，是强化学习后训练的 infra 骨干。他在 OpenAI 每次发布大模型都会被挂名——不是因为他提出了新算法，而是因为所有人都在用他搭建的 Post-Training infra。

他说过一句话："每家 infrastructure 都有不同程度的 bug，谁修的 bug 多，谁的模型性能就越好。" "idea is cheap，真正稀缺的是验证的效率和质量。"

他的一位同事总结得更直接："教一个 researcher 如何做好 engineering，比教一个 engineer 如何做好 research 难得多。"

在大模型最前沿的战场上，决定胜负的不是谁发了更好的 paper，而是谁的 infra 迭代更快、bug 更少、GPU 利用率更高。

AI 时代，这件事更稀缺了

有人可能会说：现在有 AI 了，写代码的门槛不是更低了吗？工程能力是不是反而没那么重要了？

恰恰相反。

回头看推荐系统这些年，2018 年之后进入深度学习时代，TensorFlow 给了你自由——任意改造拼接网络结构，DIN、DIEN、DCN、DeepFM，各种花样层出不穷。很多人觉得这才是算法工程师的核心能力。但这恰恰是最容易被 Agent 替代的技能——在一个已经定义好的框架里排列组合网络模块，加个 attention，换个 gate，这件事 Agent 已经做得很好了。

而 18 年以前调大规模稀疏 LR 的时候，核心是理解数据和特征。26 年往后看，核心是训练推理效率、理解数据、用好一个 Transformer。前后两头真正重要的东西，都不是调模型结构。

Agent 擅长自包含的项目——给它一个明确的任务边界，它能写出不错的代码。但它没有完整 infra 级别的 context。一个真实的推荐系统，涉及几十个服务、多个团队的代码库、各种历史决策留下的技术债。Agent 看不到这些。

能串联系统模块之间间隙的能力，能在算法和工程之间自如切换的能力——这是 Agent 暂时还替代不了的。

AI 让执行层面的编码越来越便宜，但系统层面的架构判断力越来越稀缺。算法工程师的工程能力，不是贬值了，是升值了。

算法工程师。算法是定语，工程师是中心语，工程能力才是核心。