算法思维与工程思维差异的根源

下面说的工程是专指IT工程。

很多时候，大家习惯直接把工程的经验直接迁移到算法上，用工程去理解算法。这好像没什么问题，但是在实施过程中，却容易产生各种问题，无论是在项目方案阶段，还是在项目验收阶段。这两种思维的本质差异是什么呢？

工程思维是确定性的，而算法思维是概率性的。

我想这就是差异的根源。

你可能会反对，工程也不是完全确定的，墨菲定律随时在发生作用，你永远都不知道什么时候就出bug了。确实，但是在工程上，只要代码这样实现了，得到这样的结果就是确定，可以很明确告诉客户，我们的系统在这些情况下都是没问题的，即使出了bug，也可以定位bug，然后修复，这也是确定性的，你可以拍着胸脯跟客户担保。

另外，确定性还体现在对于一个工程问题，只要你经验丰富，你完全可以通过工作分解，进行比较准确工作量预估。

但是，对于算法问题，你是几乎永远没法保证完全解决了客户的问题，因为你的模型准确率永远没法达到100%，从根源上它就是概率性的。即使你的测试集准确性达到了99.99%，但客户的数据可能就是那万分之一，虽然概率极低（但是也不一定就很低，因为客户的测试数据很可能跟你的测试集的分布特征不一致，但是你的测试集又不可能涵盖所以情况）。

算法的另一大难题是项目方案阶段，如果是工程问题，我们可以列出一个功能列表即可，但是算法本身是概率性的，只是列出功能并没有什么用，准确性等指标怎么定义才是关键。但是你没有你没有测试没有训练模型，你怎么知道你的算法在客户的数据上指标是多少呢，这已经是你做过这个领域已经有相关算法模型的情况了，要是没有的话，还得做选型，那就更难估计了。

这时候你通常只能根据你已有的经验，评估这个算法估计能达到90%的准确率，你可以估计得保守一点，也可以估计得激进一点，但是这其中风险可能很大。可能你算法做到80%的准确率只需要5天，但是从80到90可能你得花费50天，甚至你可能再花费500天也达不到。这有点混沌的意思，一个看似微小的输入，最终可能导致成本的巨大差异。

而且，对于客户来说，你这90%怎么行，十个就有一个是错的，你这个系统根本没有用，起码99%才行，最好100%！就算客户认可了你提的指标，交付的时候，客户拿一个数据测试，出问题了，这么明显的数据都有问题，明显不可用呀。

所以涉及算法的项目，最后交付都变成比较有挑战的事情，客户想要人工智能，但是你却交付了个人工智障！

因此，在交付算法类项目的时候：方案可能定义了95%，但是算法团队做到90%时，可能就很难再进一步了，再进的成本太高，这个时候比较靠谱做法通常是多管齐下，完成交付。具体的多管就是从工程解决一部分，商务解决一部分，争取客户的理解等。

最后，算法工程师也是工程师，但是目前算法工程还很难解决概率问题，还很难达到IT工程的确定性。