做feature engineering的组太赖了

真搞不懂feature engineering组的KPI怎么算。

像我们直接训练model的组，假如本来是用A结构的模型，无论怎么改模型、feature、训练方法啊，最终都是做AB test，线下线上metrics好了才能launch，算完成一个工作。

人家搞feature engineering组，说要做结构B，就直接一招鲜用同一个结构，什么pCTR模型啊，pCVR模型啊，shopping模型之类的，搞了一大堆。每个模型都是用了比较适合他们核心结构的，比较好找的feature，算是我们线上的feature的子集。训练出来嘛，如果直接上线，肯定是metric很糟，但人家用了更少的feature，就有理由效果不好啊。然后呢，他们毕竟是feature engineering组，他们的说法是他们给下游（我们）用B结构生成多一个feature，我们要把他们的feature加到我们的A结构里边，有提高就好了。

我们这边用了，有一点变好，但实在一般，但肯定保不齐人家那一大堆模型里边，某个场景的模型就有用呢。

但我觉得他们太赖了，拍脑袋说要搞个新结构，就搞了一堆模型，显得自己多有产出，从来也不需要上线验证，找个托词把责任推给接近产品的组，反正他们是交了个东西，他们干完了，至于我们拿他的东西好不好用就不管了。
他都已经把上个项目结束了，launch完了我们能才开始拿来干，我们拿他的东西做实验也要很久，出来效果一般吧，但他们的事都完成好久了，我们也不能直接跟人家组起争端、说人家的东西没用，所以这事就这么过去了，我们再去实验新的方法。

总结起来，就是我们要launch个什么，都得一个个想办法，经过严格A/B test。做feature engineering的组，因为结果只是下一个model的输入，不直接使用，所以就没有对metric结果的要求，还能吹launch了个多高端的东西，很轻松地说得自己很牛。

太赖了。

做好去学一下怎么表达自己，看了半天一脸懵逼

这种事情一次两次可以，多了肯定会要求在下游多定几个metrics多实验几次才能launch的，到最后甚至有可能直接跳过他们，你们自己搞（取决于组织架构和重要性）。除非
1、你们不是唯一的下游，甚至不是最大的下游
2、你们组流动性太大，没人记得哪些人在你们头上拉过屎

匿名用户 发表于 2026-6-20 01:04
做好去学一下怎么表达自己，看了半天一脸懵逼

GPT给你总结：

这段话的核心是在吐槽**feature engineering（特征工程）团队和直接做模型团队的绩效考核、责任划分不对等**。

简要总结：

* 你所在的模型组，任何工作最终都要接受业务结果检验：

  * 改模型结构、改feature、改训练方法都行；
  * 但最后必须上线做A/B Test；
  * 线上指标提升了才能算项目成功。

* Feature engineering组的工作模式不同：

  * 提出一个新的特征生成结构（这里叫B结构）；
  * 用少量feature训练很多模型（pCTR、pCVR、shopping等）；
  * 虽然这些模型单独上线效果通常不够好；
  * 但他们的说法是：这些模型不是给线上直接用的，而是给下游模型提供一个新feature。

* 因为他们只负责产出feature：

  * 不需要证明自己的模型能独立创造业务价值；
  * 只要下游模型加进去后某些场景有一点提升，就可以说自己的工作有效；
  * 即使效果很一般，也很难证明他们完全没价值。

* 项目流程上也存在不对称：

  * 他们交付feature后项目就算完成；
  * 真正花时间验证、做实验、承担上线风险的是下游模型组；
  * 等你们验证完发现收益有限，他们的项目早就结项了。

* 作者认为这种机制有问题：

  * Feature engineering组承担的结果责任很小；
  * 可以不断提出新结构、做很多模型来展示产出；
  * 但不用像模型组一样对最终业务指标负责；
  * 于是形成了“功劳容易拿，责任容易推”的局面。

一句话概括：

> 模型组是按最终业务结果（A/B Test）考核，而feature engineering组是按产出特征考核；前者必须证明价值，后者只要交付东西就算完成，因此作者觉得两边的责任和收益严重不对等，feature engineering组有“把验证成本和失败风险转嫁给下游团队”的嫌疑。

有人给你们弄新的features 你就偷着乐吧。

匿名用户 发表于 2026-6-20 06:25
有人给你们弄新的features 你就偷着乐吧。

这又是另一个问题，至少在我看来，他们那些feature或者方法没什么特别的。
这个公司还在追SOTA，我自己都在模型更好的地方做过。
稍微花一两天把数据收集好，就可以跑起来试了。

我不做只是因为我有别的idea可以探索，而且每个组被限制了探索的范围（这个也很糟糕），也不能拍脑袋就跟别的组抢。
而且即使是试了新方法，主要难点是怎么用它真能涨点。不是做了个新feature放那就完了，launch的时候就说“虽然我们的方法没有让metric变好，但我们相信提取的新信息能帮助下游”就交差了。

不要抱怨同侪 focus在做好自己的产品

听起来是传统ml的feature engineering？现在llm满天飞 不知道传统ml还有多少出路

我们这些纯做feature/signal的MLE组有苦说不出啊
大TL每次都要promise上面一点指标去做 不然上面根本不buy我们的主意
. From 1point 3acres bbs然后搞个feature搞个一个月 实验要跑好久才能有gain 这中间要不parallel做其他项目要么想优化方法
一旦没落地组里就是腥风血雨 但是很多时候quality出了事情最后又说需要我们来hotfix 上下都不讨好 组员流失也快

他们存在着就证明还有存在的价值，或者就是人家的领导牛逼。一个大的公司，总有一些对revenue负直接的结果，有些组是support。既然还在就想想怎么让他们帮助你们做出更好的featur拿到更好的结果呀。你也说了你有更好的idea可以探索那些feature不屑于做不是