小陈所在的团队每周的周一，周三，周五都会在晚上法定下班时间后（此处要打码？）做一个一小时的技术分享。一天，正当小陈津津有味的听同事唾沫横飞的讲解一个模型时，老刘突然神色慌张地闯进会议室，满面通红的对小陈说，“快点儿快点儿，你的模型5XX了，快去看看吧。”

小陈飞奔出去。

在从会议室飞奔到自己工位的路上，思绪纷飞，想到了自己的模型在上线时，代码被Review后，处理各种Comments时的场景。

“用户输入为空时，怎么办？”

“你不能假定用户不会输入什么，要做转码处理。”

“你的函数名能不能改一下，容易理解的那种。”

“代码要简洁，你的代码虽然是从框架中扒出来的，但是要尽可能整洁，不要的代码都删掉。”

……

坐到工位上，想到了之前工程组的大佬给算法组的同学分享如何debug时讲到的三要素：代码，日志和现场。于是向产品小妹妹要到了模型输入的case，测试输入，确实5XX了。看日志，确实某行代码在处理这个case的时候，越界了。

小陈不开心了。

“我是做模型的啊，不是只需要保证测试集和训练集的一致就行了吗？我的测试集中怎么会出现这种case？后端同学调用我的模型的时候，难道不做异常处理吗？为什么需要我来做啊。啥都要我做了，后端同学只需要调用一下？那是不是并发也需要我来做啊…”

于是小陈找到后端对接同学，理论一番。后端同学心里其实也很早就不爽了。因为服务不可用的原因，已经被产品同学挤兑了好多次了。

“我们怎么知道你需要做什么预处理啊？”

“我们在调用你的模型的时候，以为你都做了异常处理了啊。”

……

这个时候，产品Leader拿着一份模型评测报告走向小陈。“我说小陈啊，你目前的模型评测指标不如上一版啊，为啥上线了啊？”

“我的评测指标提升了10个百分点啊。”， 小陈反驳到。心里想，“产品端拿10个case来测，能测出个锤子来。”，实际上，小陈当然也测了产品端的测试标准，要知道，模型指标和业务指标是两种不同的评测指标。

说话间，小小的工位附近汇聚了好多人，大家七嘴八舌的撕起来。

没错，这是小陈的日常，一个NLP算法工程师的日常。当然，讨论的结果自然是：小陈加异常处理，小陈需要考虑到各种用户输入的边界，小陈要重新做测试，小陈要做并发提速。然后小陈要提交代码给Leader做代码review，小陈要写logging，要代码整洁，要命名规范…

小陈心疼求虎摸。

从上述的场景中，可以梳理出一些问题，如下：

（1）算法工程师要不要考虑来自业务端的各种输入情况？

实际上，距离业务端最近的同学可能是对各种输入情况最了解的，算法端同学实际上看到的更多的是标准的训练和测试集，从这个角度来说，业务端近的同学做比较合适，保证调用模型时，模型的输入是合法的。但是，从另一方面来讲，一般团队都会有内部的模型管理平台，也就是说通过该平台，模型可以单独地对用户服务，从这个角度来说，当然是算法同学来做了。

因为这个事情其实谁来做都有理由，所以自然就遇到了算法和工程同学在面对一些问题时的边界模糊问题，这正是撕逼的来源之一。

（2）算法工程师要不要做服务可用性？

实际上，模型是部署在一个模型管理平台上的，该平台后端是资源调度平台，前端是复杂的一些工程模块，同时会有存储模块。完整的模型管理平台会有一个监控模块，该模块不仅监控模型或者服务的一些基本情况，同时可能会对模型的周边资源进行监控管理。

同学，想不想体验一下“连环夺命Call”的体验？不过，无论怎样，当模型要单独对外服务的时候，自然要保证服务的可用性。

（3）算法工程师如何做测试？

一个模型能否上线，要同时兼顾模型指标和业务指标。很多时候算法的同学可能关注更多的模型指标，但是线下模型指标的提升并不一定能够带来业务指标的提升，一般的A/B测试可以用来科学地评估业务提升。但是这里带来的问题是：谁来测？

模型测试有其独特性。产品端同学可能更多地关注一个个具体case，“你看，虽然你说你的模型提升了，但是这个case还是测不出来啊。”，算法同学嘀咕，“模型重在泛化，要关心统计指标啊。”

模型测试也是软件测试，既然是软件测试，将传统测试方法论用于模型测试总是没有错的。不过同时要看到模型测试有其特殊性，具体问题终究需要具体分析。

（4）还有很多问题。

总结：

不要以为一个NLP算法工程师的日常都是读论文，推公式，设计模型等，可能很多时候，你也会做这些：

比如看数据，标注数据，是那种一条条的看，一条条的标。不要小瞧这个阶段的工作，很多时候可以带来显著的增益。

比如看badcase，做case分析。这个case为啥会误报呢？怎么快速fix这个case呢？因为多数时候，你会遇到来做产品同学的灵魂鄙视，“你的模型指标都提升了那么多了，这个case还是误报！！”

比如要花很多时间写单元测试。

比如要想怎么把异常不要直接抛给用户，任务情况下，这种问题都是不可接受的，要做服务可用性。

比如要做代码鲁棒性。无数工程的同学吐槽过算法同学的工程能力太差了。实际上，可能平均水平确实不高，但是这与算法同学的核心诉求不一致，也是能够理解。无论是产品端还是工程端同学都迫切希望算法同学的工程能力有所提升。

比如，首先希望你是一个好的工程师，然后是一个好的算法工程师。

比如，模型在一个NLP算法工程师的日常中，占的比重真的不高。分析各种问题，解决各种可能是来自数据，模型，工程上的各种问题。必要时，给产品同学科普算法能力，销售算法能力。

时隔好久，看到凯飞的一篇文章，颇有感触，以飨读者。