做模型的人应该要关注模型到底是如何被使用的

https://www.douban.com/note/488015251/

做数据模型的人最纠结的问题莫过于如何评估你的模型做的好还是不好。尤其是在复杂多变的商业场景下。

有可能出现的问题：

1、建模前对业务不了解或者了解的不透彻，对业务目标认知的缺失或者偏离导致模型的产出并不适配业务，从而导致模型可能离线效果很好，但是因为出发点就是错的，所以没有解决业务问题。模型做了而无用。
这个是属于比较low level的问题，新人易犯。有一定经验或者吃过亏之后，这个问题很快会得到解决。

2、模型做的不错，也解决了业务方认为的业务问题。但是发现解决的这个问题并不是真正的问题。导致模型做了，有时候无用。有时候反而对业务有害。
这个问题往往不在于算法团队。而在于业务方本身对于业务没有梳理清楚，对业务的理解不够深刻导致的。但是作为提供数据服务的人，其实我们是有义务在建模前期，通过分析的方法，挖掘最原始的需求，和业务方一起定位真正的业务问题。

3、模型做的不错，考虑了模型相对的通用性和对业务场景的适配，业务问题也被解决了。但是模型使用一段时间，或者模型开发完成还没怎么用，就发现商业场景已经发生了变化。模型虽然解决了问题，但是模型能够发挥作用的前提条件或者前提假设已经发生了变化，导致你的模型开始无法发挥应有的价值。
在复杂多变的商业场景下，这种情况是比较常见的。做模型的人如果追求的是带来真正的价值和业务的提升，那么在这种情况下，做模型的人甚至可以去深度的参与业务本身中去。

其实说到底，作为业务的支持方，业务好坏是衡量你做的模型的根本指标。我们尝试过在业务明显不行的情况下，使用了很多分析的手段剥离出了一些指标衡量模型的客观效果，说明模型做的很好，没有问题。但是面对业务的下滑，你的模型做的再好其实也没有用。根本没人care。

然而在这种情况下，你去剥离，去分析到底模型效果如何的过程其实是对业务有很大的好处的。因为通过分析，剥离，你会看到模型真正影响到的地方，你会看到很多问题并不是模型带来的。这个时候，你就会看到很多的问题，你对业务的认识会更加深刻全面，你可以看到业务下滑的问题在哪。这样的收获其实才是我们最终的目的。我们是通过分析的手段，来看到业务真正的问题所在，去尝试解决那些问题，目的是让你的模型能够回到一个能够发挥它作用的正轨上来。也许最终，通过这些手段，你可以帮助业务提升，切实证明了你的模型其实发挥了它应该发挥的作用。而这个时候，哪怕你的模型是有瑕疵的，大家也认为你的模型是好的。

再引申一层，做模型的人应该要有服务意识，也要有ownership。这一点很关键。当然，也有一种观点是做模型的人要懂得选题选场景。题目选得好，业务可能本身就在上升期。业务方看到高速增长的业绩时，也已经不关心你的模型到底做的好不好了。普天同庆水涨船高。但是做模型的人不能因此就认为是自己模型做的好。我们还是要剥离，要分析，到底模型影响到了哪些业务，起到了什么样的作用。哪些问题不是模型要解决的，我们能不能通过其他手段，比如运营或者产品的手段，推动模型发挥它应该发挥的作用。

因此，我们应该要认真的去思考模型的效果如何去评估。除了离线的指标，我们要思考模型的这些数据如何能够去最恰当的发挥他的作用。既不夸大，也不妄自菲薄。我相信模型一定是有作用的，关键是要用得恰到好处。一个模型做完交出去之后，没有售后，会产生很大的问题。最严重的问题莫过于你做的模型最后没人用从而导致的个人价值下降。

前一段时间读到KK的技术元素，其实里面一个观点也和我要表述的很像。即任何技术，只要能够被复制，那么注定会变得廉价。而在这些廉价或者终将变得廉价的技术之外，我们要思考更为核心的价值。而这种深度的服务意识和能力，也许是一个人的核心竞争力之一。