个人观点：DS / MLE 如何健康地职业发展

两目如剑的木瓜 发表于 2024-10-21 12:38
求问为什么不折腾ds就可以存在？？是因为给了ds空间和时间吗

失去上层的信任 上层才会折腾你， 才会搞reorg；
不折腾就是‘维持目前形势就好’，领导对现状满意，对你们组满意，对你满意。
所以 DS 就得学孔老夫子，周游列国 寻找明君

dajiangdongqu 发表于 2024-10-21 11:50
楼主过谦了；你的观点很对，但论证不敢苟同。
我用春秋战国比喻，大家看看怎么样，各个公司就是战国七雄 ...

你说的都非常有道理。老实说公司/上层追求最终结果是所有社畜无法避免的问题，他们选择盲信KPI也是社畜没办法挑的外界因素。DS很容易撞枪口上也是事实。

谢谢分享，作为一个6+ yoe的MLE, 收获不小。

就是寻找应用的场景，开发新产品吧。

感谢楼主分享，也很赞同楼主的看法！
不知道能不能和您约个coffee chat？

这帖子说的太好了，加精了吗

说的很好，解释了 MLE/DS/ 在做什么. 或者说 AI/DA 部门在做什么。比如弄清楚自己/部门 的位置 是在做0到1，还是1 到100， 还是100 到1000 的工作。有个big picture。做到从一个发现关键问题 到解决问题的角度走。而不是埋头苦干 螺丝钉式的折腾。（大组会需求螺丝钉，但是个人的长远 interest 和大组的需求是不是一致的 还要自己考量的）

归根到底 AIDA 部门注定是个承上启下的部门，哪怕在一些做 infrasturcure 或者 heavy duty 的research 风格的部门，弄清楚问题 选好正确方向，一切以objective 为前提 也是十分重要的。

The most common

感谢lz分享，想请问lz怎么定义1-100和100-1000的阶段？以及为什么认为在1-100的阶段DS/MLE是鸡肋的呢？

henryylb 发表于 2024-10-24 18:38
感谢lz分享，想请问lz怎么定义1-100和100-1000的阶段？以及为什么认为在1-100的阶段DS/MLE是鸡肋的呢？

好问题啊。我说的有点简化了。

1-100这个阶段大致上是这么种情况：

糙快猛的落地Prototyping已经不适合组/公司的发展了。具体来说，项目的impact/用户到了某种程度，使得让单个的DS去支持feature request, bug fix和dev op的模式不堪重负。但又没到一种需要专精的TPM support来过滤噪音（从FR和bug fix来的），也没有需要devop来offload oncall， monitor服务，也没有足够的ROI来投资开发专门的framework来自动支持这些东西。那么DS组的困境就来了，有几个项目开始产生效益，但是由于开发阶段糙快猛，积累了很多tech debt，比如优化不够，比如edge case 开始累积，但要进一步改进需要很多的资源去refactor，比如把单纯的script 去modularize，把在多个项目里公用的代码和模块抽取出来。另一方面需要进一步开发新的项目，这些项目要求比之前的高，或者low hanging fruit已经不多了，需要大量时间研究。但是DS组只有N个员工，是扩招还是压榨已有员工，怎么能确保这活做完之后有新的“增长点”出现？而不是陷入死局。这种就是1-100的情况。这种情况很难由DS/MLE bottom up去改变.

100-100000的阶段就是之前阶段所提到的问题都已经unblock了，并不一定完全解决，但已经有相对成熟的process和框架来进一步改进，这种技术和流程的积累已经出现了质变，比如上头已经安排了专业的devop, TPM，或者framework已经可以满足迅速的模型迭代和简单的monitor，这时候DS/MLE要做的就是考虑，解决什么问题才是能迅速scale效益的，有什么新的capability能打开新的大门，能一下影响大量客户：因为这时候的DS组已经不是小打小闹就行的了，上头有可能已经不太关注bespoke的解决方案（比如客户A需要模型B，然后你们来解决），上头想要的是推出一个通用方案一下造益很多人，你的模型能在不同的数据上适用吗？另外这种组的成熟的Process可以让DS/MLE少走很多弯路。上头很可能知道什么该做，什么不该做，或是什么由谁来做，DS可以做螺丝钉给senior打下手，就算纯做analytic也可能可以打出一片天下，毕竟一个关键的why可能一下造成很大的impact。也可以有机会做next big thing。这样的大组是不容易由于自身原因fail的，组在饭碗在。（当然被别人吃干抹尽，以及其他toxic的情况不算）

其实这些也不是绝对的标准，但是从我个人经验来看（1-100的情况我不幸经历过两次了），与其死磕，不如跑路。