专家点评 | 【Google 年度顶级论文】机器学习系统，隐藏多少技术债？

作者在看完新智元12月8日文章《【Google 年度顶级论文】机器学习系统，隐藏多少技术债？》后有感而发，特作此文。

我: 真的好文。象牙塔里出不来的经验总结。

杨静 ༅ 新智元: @wei 你可以写一篇点评！

我: @杨静 ༅ 新智元 这里这么多 ML 大牛，哪里轮得到我这个语言学家点评啊。我算是雾里看花，因为做的都是工程系统，也有强烈共鸣罢了。

很多债务是所有大型软件工程共有的，这里试图强调ML的额外特有债务。债务的结果就是系统报废。历史上见过不少开发了很多年的系统，最后死掉了，封存了，无人问津了。当然，死系统的原先的开发者往往带着教训和经验，在下一轮重开炉灶的系统中，轻装上阵，做得更好。

我们此前讨论中遇到的两难，与这个技术债务也有关。两难是，软件工程需要分层和模块化，而系统需要保留和传递 non-deterministic 结果，如何合理处置，是一个很大的挑战。大家的共识是不要提前给出条件不成熟的确定性结论。但是拖泥带水从一个模块进入另一个模块，对于NLP这样的系统，负载会越来越重，不堪容忍。对于追求纯粹和完美的人，这个两难无解。

而且即便你找到办法保留了 non-deterministic results，系统越大，层次越多，最后是越加不 tractable。如果一切都保留到语用层面最后定夺，很怀疑任何系统设计者会受得了那样的千头万绪。反正我们在实践中是不行的。结果就是不追求纯粹和完美，选择性地、经验性地决定哪些结果可以中途扔掉（枝枝蔓蔓），哪些 non-deterministic 结果必须保留。这种选择肯定会出现问题。会出现以前的deterministic system 同类的问题。就是所谓铁路警察各管一段的踢皮球的问题。但是，出问题不可怕，只要系统是掌握在同一个设计师手中，只要一开始考虑架构的时候就给 non-deterministic 的东西留下了空间，这种问题的出现恰好可以 data-driven 地帮助设计者决定如何调配带还是不带的决策。

谁把李航请来就好了，也想听听他的高见。

白: 应用不同，平衡点可以有所差异。

我: 平衡点总是可以在实践中调控的。关键是，设计者的思维方式的转变。我们以前吃过很多苦头。刚开始做系统的时候，受到 community 的影响，认为 POS 是一个 solved problem, 于是做出了一个错误的决定，把 Brill 拿来就用。表面上这是加速了系统的进度，后去是擦不完的屁股。这不怪 Brill tagger 的精度不够，再高的精度（只要不是百分百）也会出现同类的问题。主要怪的是当时没有意识到模块间的包容，重于模块的纯粹。于是踢皮球就开始了，凡是后面做不好的，往往归到前面没做好支持。很多 parsing 的问题，最后被归结为 POS 的问题。于是回到 POS 层去打补丁。最后做出了一个畸形的系统出来，给 POS 打补丁的模块是整个系统最大的模块，比所有其他模块（包括前处理、Brill POS、NE、chunking、SVO、Events）加起来还大。原因是 parsing 的东西，在 POS 阶段几乎被重复了一遍，而且是拙劣的重复。在螺丝壳里做道场。这个教训很深刻。所以，现在学聪明一些了。

个人的教训是，NLP 没有免费的午餐，在决定拿来就用的时候要慎重再慎重。写过一篇，自给自足是NLP王道。

其实后来我们又做出了一个错误的决定，虽然这个决定在当时是无可奈何的，但显然是错误的。我们在做多语言的时候，因为迫于 deadline，不得不 license 了 Basis 的 多语 morphology，结果不但是擦不完的屁股，交不完的 license fee，更要命的是，他那里一更新，我这里就两难，升级还是不升级？

还有一个体会，同样是擦屁股，擦别人的屁股比擦自己的屁股别扭多了。因此，即便自给自足在时间压力下开始是做不好底层支持的，也比用他人的“成熟”的模块是更好的选择。反正，NLP 终归是长线项目，时间压力只是要求系统先转起来，iteratively 和 incrementally 地擦屁股和维护协调是系统转起来以后的必由之路。

底层的东西最好不用他人的，再大诱惑也不用。顶层的没有 dependency 的可以用，譬如系统要做 visualization 展示结果，这个 tool 用 off-shelf 没有副作用。