AI项目规划中值得考虑的非技术因素

2020-12-04

最近组队参加了一个创新比赛，期间有专家的一对一辅导。感受比较深的就是，因为我们做的是一个人工智能相关、偏技术的产品，对技术架构和实现关注得较多，而忽略了一些必须要考虑的非技术因素。

明确痛点

从头开始说，首先一个项目，在进入对实现方式的讨论前，需要明确它的定位场景，和痛点，也就是为什么市场会需要这个产品。如果这里不能成立，那么实现的效果再好，也没有多大的意义。

这个道理说起来似乎是显而易见的，但是对于技术圈子，尤其是学术圈子内的，却常常不容易想到。因为一个学术成果想要获得认可，只需要它的效果比起之前的研究有突破或创新之处，又或者提出了某种新的想法，也可能只是提出了新的问题，都可以发表。所以常常首先想到的是，能不能实现、方法是否有创新、效果能不能更好。却忽略了作为一个产品的根本，首先要有足够的理由让别人来用。

所以说，项目的创新要针对痛点，而不是单纯的优化。

充分验证基线

除了产品定位、痛点、目标用户，还有很重要的一点也应该纳入考虑：是否有代价更小的解决方法。在我的理解里，很多人工智能项目就存在这样的误区：盲目追求“高大上”的模型和技术，比如复杂的神经网络，没有对基线的效果做认真的验证。实际上我在我实践过的shared task和各种课题当中，就发现过几个数据集，实际上用几条简单的规则就能逼近各种神经网络的模型效果。

我们容易忽视对基线的验证，原因不难解释，当遇到一个可以和人工智能、机器学习等等概念扯上关系的问题，不论是我们开发或研究人员自己，还是项目中的产品、经理、领导等等参与者，或者是学术界的导师，肯定都希望用上新的、牛逼的技术。说白了，保证技术高大上，这样才有出去吹牛的资本。

至于数据，虽然不同的数据集中内容是完全不同的，但形式却是大同小异的：无非就是一系列的数据点，以及可选的标签。模型的输入，大部分情况下都是矩阵。因此直接从机器学习或深度学习开始，是一个非常有诱惑力的方案。将数据简单处理后，先丢进一个模型，看看效果，可能是很多人最初的想法。而实现起来也会很快——网上有很多开源的模型代码，只要把数据处理成对应的格式塞进模型，就能看到最初步的效果。甚至这个过程中我们只需要关心数据的维度，做一些reshape、sample、padding、PCA、standardize……而不用去查看数据本身。

当然，这样出来的模型效果肯定是不好的，所以很多人会称这个为“基线模型”。又或者说，草率地用随机猜测这种dummy model作为基线。使用这种缺乏充分考虑的基线模型，轻则会导致对模型效果的错误估计，严重则会误导整个团队的方向，浪费大量的时间和人力。

我对基线的理解，它可以是，但也不一定是一种模型，也不一定是一系列规则。对于基线，重点不在于其方法，而是投入和效果，以及对数据的理解。在对数据有了充分了解的情况下，投入尽可能小而效果最好的方案，就是基线。并且基线本身也可能是需要实验和优化的，而不是得到一个结果就弃之不顾。

把基线想象成另一个团队的竞争，他们可能有完全不同的思路和视角，甚至来自不同的圈子。他们有没有可能从另一个方向找到一个解决方案，比我们的更加简单高效？在确定整个项目的方向之前，需要好好论证这一点。

如何落地

一个市场需要、具有可行性的项目，也可能会有无法落地的困扰。尤其是人工智能项目，因为所有的人工智能都是建立于海量数据之上，数据的获取，以及数据的更新，都可能成为落地的阻碍。如何处理这样的问题，是我们需要在项目的规划阶段就想明白的，而不是研发完成之后。

我们如何获取到用于研发的第一批数据，如何、以什么频率获得更新的数据？如果这是一个涉及到模型向外部部署的项目，在上线之后的新数据，以及模型的表现，是否可以准确持续地获得，以形成一个闭环，支持后续的开发。

说到第一批数据的获取，如果数据并不是此前已经统计完成的，那么就有必要首先完成数据采集的模块，并且最好能够先让采集模块落地。这时候因为我们输出的并不是一个完整的产品，可能需要借助其它产品为依托，在后台帮助我们积累一些数据。需要提前做好协调的准备。

在这里又可以谈到一个落地方案上的区别，有的人工智能项目是可以允许一个效果一般的模型先上线，之后对模型不断演进，例如推荐算法。而另一些场景，必须要保证模型的精度非常高，才能允许上线。区分落地要求，能帮助我们明确项目的预期目标。

最后是在做落地计划时，有必要的话可以合理地分步进行。例如只对全量数据中的一部分样本进行实现，或者在所有的预期功能中，先实现部分简单的功能。分步的重点在于，每步应该有其独立的价值，而不仅仅是为最终的结果铺路。这样项目才能不断获得正反馈，避免因为长期无法产出价值而中途夭折。

最小可行产品

制作最小可行产品是一个常用的策略，但要定清楚研发最小可行产品的目的是什么，以及不是什么。可能是为了实验技术路线是否可行，可能是为了试探市场反应，可能是为了进一步明确产品的设计，或者也可能是为了展示给领导或投资人的时候有更加惊艳的效果，等等。

一个最小产品不可能面面兼顾：如果想要做到所有这些，那它也就不是“最小”了。问题是团队里的人对这个最小产品的定位同样可能有各自的理解，而且，如果他们负责任的话，每个人都会希望自己的产出是高质量、无破绽的。那么就会导致大家都在努力，结果却都不满意的局面。

所以说，不能因为它是“最小”可行产品就不进行明确的目标定位，还是要事先明确努力的方向和重点。