MLE现在还是一个值得投资的方向吗?

woaiyangchaoyue 发表于 2021-09-24 20:58:33
字节（加州山景城）前段时间在招一个MLE intern， 不要Phd学历， 写的是本科就行......

我投了，把我秒拒了， 但我是商科phd........

商科phd << cs master吧

十八线小厂ds同感啊，现在刷题中，真的也纠结是转码还是mle. Ds真的就是da, 小厂苦不堪言。而且ds貌似转都是去mle多，现在ds卷起，mle卷感觉就是ds们的下一站啊

modifiedname 发表于 2021-9-24 11:30
建议深挖 mobile
经验积累会越来越值钱
业界需求大，灵活（大公司小公司都有很大需求）

说的太好了 MLE is over rated.

沉溺于技术而忽视了商业需求也可以说的是一种玩物丧志吧。

MLE 太卷了，个人觉得不太可

匿名者 发表于 2021-9-24 18:07
顺便也跟大神求个front end的建议，值得深挖吗？
感觉一直处在鄙视链底层，其实前端做起来并不容易，繁 ...

我觉得这些问题很简单。就看 Top 5 school 的人 (大S, MIT, UCB..)，他们毕业主要是去哪些领域，就知道哪些领域工资高了。不能搞行行出状元那套糊弄人。

MutouMan 发表于 2021-9-24 21:24
十八线小厂ds同感啊，现在刷题中，真的也纠结是转码还是mle. Ds真的就是da, 小厂苦不堪言。而且ds貌似转都 ...

DS 做的 ML 跟 MLE 做的 ML 到底啥区别呀？

LittleFishBall 发表于 2021-9-25 21:40
我觉得这些问题很简单。就看 Top 5 school 的人 (大S, MIT, UCB..)，他们毕业主要是去哪些领域，就知道哪 ...

扎堆导致内卷

front end挺好找工作的

大公司小公司，创业公司，都需要

现在跨平台开发 front end差点把mobile的活儿都干了

LittleFishBall 发表于 2021-9-25 20:43
DS 做的 ML 跟 MLE 做的 ML 到底啥区别呀？

个人看法，在 product engineering 组可能是 DS/MLE 都做 ML，但是负责范畴不同，一般有如下几个步骤

1. 如果是新产品，可能数据不全，要先 在产品里 定义和 instrument event log，返回需要的数据。如果是大厂 infra 成熟好用，这个步骤可以比较简单。如果是小厂，这些全靠手工，那还蛮麻烦的。这个步骤一般不会是 DS 去做，一般是 eng 去做，因为起码需要能看懂 production code，和能使用自家 infra。有 tech 经验的 DS 也可以定义这个 log，但是如果公司没有清晰定义，直接让 DS 去定义，那就等着一两年后全公司数据爆雷吧。最好是公司内部有规范，培训 DS and SWE，代码有 guardrail.
2. log 能产生了以后，有个 ETL 步骤 把原先的格式转化为训练的时候需要的格式。大厂一般有自己的平台和工具，这个步骤也基本就是 clone 一个别人的 Pipeline。但是如果尚未很好规范化的中小厂，这个步骤要自己搞，开始的 MVP 可以很容易，但是需要考虑将来产品上线后，让整个流程能自动运作起来。很小公司，前几个 ETL 随便搞都可以；中型公司很可能这个步骤乱七八糟，数据缺失，定义跟想象的不一样，有人改了但是没告知下游的使用者，缺省值定义因为产品调整不再合适，计算被 delay一时之间取不到数据，恢复后需要 backfill等，一堆犄角旮旯的情况需要考虑到。DE 一般负责这种步骤，没 DE 的地方也是 eng 去写。
3. 假设收集和转化，并假以时日，然后数据已经工工整整的在某个地方（比如数据库）内等待使用了，一般就进入试错环节，尝试不同的 feature engineering technique, 调参等，经过训练，评测，得到了一个在测试集上表现让人满意的模型。这个反复调整，训练和评测的过程，是很多 DS 最熟悉的活动。如果大公司，内部环境让这个 loop 比较容易实现，无非是搭起试验框架，设置几种条件，花公司一些 GPU 的钱去训练，回来看看 report，想想点子，几天到 1-2 周就好。如果缺乏很好的内部环境，就可能好几周好几个月才能拿出一个改进方案。这一步 MLE DS 应该是都可以做。假定都有一定的 ML 基础，不会犯基础的错误，也能提出一批合理方案，那 谁对试验的 iteration loop 搭建的更好，一般就谁出活快。如果是系统已经比较成熟的地方，就看对 business 的理解（domain knowledge) 和对不同模型技巧的熟悉程度。

KPI 一般是 Business 定义的，具体在公司里是 PM 定义的，DS 也会参与。一般也不会发明什么前所未有的模型，绝大部分时候，product engineering 组就是用已知的模型种类（XGBoost 大法好）应用在自己公司的数据上，或者直接用现成的 DL 模型，或者现成基础上对自己公司数据做一点 fine tune。这部分如果要称 research 也顶多是 applied research. 最终目的还是 move business kpi.
4. 然后是 模型优化（或者简化）和 deploy。需要考虑如何上线，上线后，用户行为如何通过上述 pipeline and model 转化为产品对用户给出不同的反馈，也不完全是一个数字问题，其实主要还是产品问题。一般 Eng 去做。这一步前几年被称为 throw over the wall 的步骤（DS 把一个离线测试时候看起来还可以的模型扔过墙，交给 eng 去上线），特别容易出问题。这几年辅助的工具越来越多，如果用的合适，从 prototype 到上线可以几乎 frictionless。有合适工具的时候，DS 也许可以交付一个 inference API，但是一般不会管这个 API 被使用的时候速度行不行，可靠不可靠，如何 scale up 之类，也不会太多的管这个 API 返回的内容如何被产品使用。这些是 交付给 eng 负责。
5. 试验，后期。大公司现在做 AB test 已经非常成熟了，也犯不着一定要 DS 去定义，当然实际上仍然是 DS 在定义，和分析结果。后期产品上线，monitoring / alert / oncall 这些 DS 肯定不会去做的，一般 Eng 负责。

以上每个步骤，都很难像普通产品代码那样做测试，即使对已知情况做了 unit / integration test，也不可能完备的 cover 全部的情况，而且现实情况也会转移，所以也是为什么 ML 的产品特别容易出问题，出了问题也很难快速找到和解决。


算法更复杂的场景 RS 做尝试(step3)的比例更大，产出的衡量也完全不同。

L123 发表于 2021-9-24 18:06
我以前在小公司做MLE

相比SWE, 有一大堆新奇问题,

非常赞同，做模型在一定程度上是艺术而不是物理。。。

majiamajia1212 发表于 2021-09-26 10:56:32
非常赞同，做模型在一定程度上是艺术而不是物理。。。

不
是玄学...