当一群技术博士决定“折腾”出点什么

最近，字节跳动启动了新一年的筋斗云人才计划，共涵盖大模型应用、搜索/推荐/广告、计算机体系结构与系统优化、安全/AI Safety、硬件、AI Coding、视频架构、AIGC 等八大领域中的 42 个技术课题。

其实，在筋斗云计划发起之前，就有一批优秀的字节同学在这些课题中，追逐技术创新的“务实和浪漫”。我们邀请到了三位筋斗云课题里的同学，以下是他们的口述：

2023年7月，从中国科学院博士毕业后，我放弃了几家知名企业的头部人才计划Offer，加入了字节一个在当时相对较小的产品——汽水音乐。

在求职的当口，我最关注自己将来做的事是不是够长期？是不是够创新？敲钉子的事谁都能干，我想做那个造锤子的人。

字节满足了我的期待。我了解到汽水音乐内部也有很多长期课题，这对于一个以应用为主的团队来说非常难得。面试时Leader的一句话也很打动我，“你来了之后，不给你设方向限制。”

入职后我接手的第一个课题就非常长期和有独创性——兴趣时钟。

如何建模时间关联的用户偏好是推荐系统中的一个经典问题。过去行业普遍直接对时间进行小时编码（hour embedding），再让模型自己学习时间与用户偏好的关系。这种方法在传统天级训练的推荐系统中效果不错，但并不适用现在的流式推荐系统：同一时刻所有样本的小时编码相同，会导致模型无法学习其他的小时编码，从而出现过拟合现象。

兴趣时钟的逻辑是直接对某一时间用户的兴趣偏好建模，本质上是让时间成为兴趣的“触发器”，在当前时间使用合适的用户兴趣偏好去预估，将最合适的、用户最喜欢的内容推荐给他们。

听起来，逻辑的转变似乎很简单。但我认为衡量一个技术成功与否的标准从来都不是够不够复杂，一剑封喉，越简单的技术越有效，也更容易被行业广泛使用，从而为更多用户提供更好的体验。

兴趣时钟在汽水音乐上线后，将用户的活跃天数提升了0.509%。后来，我们的论文被顶会SIGIR2024 Industry Track录用，评委们也给出了积极的认可。

互联网是一个0和1构成的世界，技术也是如此，在拿到最终结果之前，无论过程有多长，我们会一直停留在“0”这个阶段。

我印象很深刻，刚开始做兴趣时钟时，大家都很期待。但两三个月后迟迟拿不到效果，也就没人再问了。有那么一段时间，我经常胡思乱想，“这么久都不出来，Leader和其他同学会不会对我有意见？”

之所以这么难，还是因为这是一件从0到1的事，没什么前人的经验可以借鉴，所有事情都要重来，也踩过不少坑。举个很小的例子，模型代码取的是AOE时间，但存储系统取的是UTC8时间。因为时间标准不同，导致最后的收益不及预期。

兴趣时钟的研发过程并没有什么动人心魄的故事，无非就是遇到一个又一个小问题，一次又一次解决它们，直到最后走向成果落地。

2024年，我开始负责汽水音乐的推荐技术。在此期间，我也像曾经的Leader一样，提供一些思路上的指引，让同学们去搞一些长期课题。比如我们去年把兴趣时钟升级成了长期兴趣时钟，提出了不对称扩散模型等。

也是在管理团队后，我突然发现自己当年想多了。有时候不问进展，并不代表不关心，而是不想给同学们太多压力。我相信同学们，也深刻知道，这本来就是一件需要长期投入的事。

在清华读博时，导师经常鼓励我们要重视技术的实践落地。这点对我影响很大，2020年4月到字节实习后，更加深了我的理解。

博士期间我的研究方向就是数据库和AI。写论文时，我们通常会设置一个理想环境，并在理想条件下拿结果。但真实的工业环境更加复杂，工作不只停留在纸面上，而是要落到具体实践中——当你做的东西解决了实际问题、产生了真正价值，论文和专利这些是水到渠成的事。

从2021年到今天，我职业生涯的第一次实习和第一份工作都在字节跳动的 ByteBrain 团队。这四年中，激励我一步步走过来的，正是一个又一个可触碰的问题，以及解决问题后带来的满足感。

我在字节ByteBrain团队的工作和博士期间的研究方向一脉相承，刚开始做AI for Infra，也就是用AI技术优化数据库等基础设施，在节省成本的同时提升性能。随着大模型的发展，我的工作也拓展到了Infra for AI领域，本质上是为AI大模型的开发和落地提供基础设施支持，从而加速开发流程、降低落地门槛。

正式入职后不久， ABase （字节跳动规模最大的首个自研NoSQL数据库产品）团队找到我们，提出要做数据库的扩缩容，在用户用量出现持续上涨和下跌时及时预警。对于算法侧来说，常见的思路是在云引擎上线一个算法预测服务，其他需求部门来调用算法 API 就好。但我们并没有局限于此，而是从0到1 把整套链路搭建了起来，涵盖了数据采集、算法预测、扩缩容建议、消息预警、大盘展示等全流程。

说实话，这一定程度上超出了一个算法工程师的工作范畴。但我一直坚信要有长期视角，只要当下舍得沉下心来投入，就一定会收获更多成果。

最后，功能上线后的结果也很不错，在扩容上帮助ABase 将紧急扩容工单的数量降低了60%左右，并在缩容上节省了3亿左右的成本。后来，我们与 ABase 团队在更多场景下展开了更深入的合作，双方共创的论文也被今年的 SIGMOD 25 （数据库领域顶级会议）收录。

类似的故事几乎每天都在我的工作中发生。还记得最开始做“MySQL 虚拟索引 VIDEX 开源项目”时，我们的想法很简单，只是觉得它对公司业务有用、对行业有用，值得开源，并没想到最后会产生还不错的影响力。

索引推荐是数据库领域的一个经典问题，如果没有索引工具，仅依靠DBA（数据库管理员）的经验来优化索引会非常耗时耗力。随着数据量级越来越大，在数据库中插入一个真实索引的成本非常高，同时会带来客户隐私数据泄露的风险。虚拟索引便应运而生，它可以实现虚拟环境中实现索引查询，让用户可以按需调用。

MySQL 虽然是当前业内最主流的开源数据库，但一直没有成熟的虚拟索引工具。像 Meta 等公司都提到自己用了类似技术，但没有开源，没人知道他们是怎么做的。

当我们自己上手时，却发现就像打地鼠游戏那样，很多未曾预料的问题总会层出不穷的冒出来，导致索引结果的准确率不高。怎么办？只能埋头去啃代码，下了很多“笨功夫”。

比如结果不准时，我们会对比真实索引和虚拟索引的不同，并深入到代码层寻找卡点。可能就是那么一两个环境变量，但解决了它们，也就将很多环节的卡点都解决了。诸如此类的情况发生了几十上百次，每一次我们都要去几百万行的系统代码中定位到具体的某一行。

在那段时间，很多问题都面临着挑战。应该说，痛并快乐着吧，我喜欢这种“长期专注一件事”的感觉。

VIDEX项目做成后，我们在公开测试集上的加速效果达到了理论基准（Ground Truth）下的90%以上，并且已经在公司大规模上线，每天处理上千个 RDS 和 MySQL 的慢 SQL 优化任务。目前，ByteBrain-VIDEX 已经被数据库顶级会议 VLDB 2025 Demo Track 接收。我们将VIDEX开源后，也引发了行业的关注与认可，并吸引了众多海内外研究者的讨论与贡献。