我经常遇到着迷于深度学习、压缩分类和自动驾驶汽车的数据科学团队，它们渴望运用当下流行的算法。比如说，我最近在与一家大型金融机构合作，共同加强其网络安全;我们甚至还没有开始基本的监控，我团队中的一名数据科学家就在谈论K-均值聚类和神经网络。
我们要始终记得先要了解问题和机会，然后运用正确的系统或算法。有时候，自学习神经网络可能是最佳的选择;而有时候，你得采用经典的技术：专家系统。
专家系统是一种基于规则的引擎，它基于专家们的集体智慧。它是人工智能(AI)领域历史最悠久的创新之一，实际应用可以追溯到上世纪70年代。
数据科学界经常开玩笑说，专家系统好比是过时的恐龙，它们很有意思，但是就现代应用而言不切实际。我完全不同意，人工智能领域没有哪一项进步完全取代得了专家系统的功能和效用。此外，由于专家系统已存在相当一段长的时间，你可以运用久经考验的最佳实践。下面是使用专家系统、让你开始入手的六个最佳实践。
1. 征集需求
构建一套专家系统最困难的部分就是，与实际的专家们见面讨论。与任何最终用户见面讨论已够困难了，而你项目需要的那些专家是非常特殊的最终用户，每个人都想要与之讨论。在征集需求之前，要征得管理层的同意，批准你与专家们见面讨论。
比如说，我在接触一家跨国交易处理公司时，整个公司只有五六个人知道交易网络的内部结构。如果你没有让管理层承诺专家到时抽出时间，那么你休想与他们谈论15分钟以上。
2. 进行分析
尽量少花时间在分析上。忍住对专家访谈进行定性分析的冲动，这没有必要。
专家系统旨在进行自己的分析。艰苦的工作在分析中并不多，难就难在框架的搭建和微调上。在这方面，它类似神经网络。你的任务就是告诉系统如何思考，然后让系统为自己处理思考任务。
3. 设计框架
将冗余性(verbosity)设计到你的专家系统框架中。专家系统由两个基本部分组成：知识库和推理引擎。知识库负责存储关于设计领域的事实，而推理引擎负责将归纳(正向链)推理和演绎(反向链)推理运用到知识库中的事实。
这两个系统都必须精心设计，让你可以了解专家系统在想什么。你需要非常详细地了解专家系统知道的情况，以及它如何得出结论。先进系统更侧重于采用自然语言界面――这是我支持的一个最佳实践。
4. 开发系统
开发速度要快。与分析一样，如果你在开发方面花了大量的时间，那么做法不当。你唯一要开发的东西就是框架(知识库和推理引擎)。暂时尽量避免编写程序代码。
然而，要从长计议。在程序代码可以取代框架推理的地方构建接口。虽然将程序代码换成基于框架的推理有悖于大众的看法，但是一旦规则得到了全面审查，它就是你专家系统的一种实际延伸。程序代码让你有机会大大加快执行，这对许多应用程序(比如嵌入式系统)来说更切实际。
5. 训练系统
不要低估了合理训练专家系统所需要投入的时间、精力和专家数量。我使用“训练”这个词很宽泛――专家系统严格上来说并不是一种学习系统。但是，决定专家系统成败的却是领域知识以及它如何进行推理。专家必须是这个过程的一部分，因为一旦馈送了需求征集阶段收集的信息，专家就需要微调引擎。
这时候，情况变得有意思起来。让一个专家解释过程原本够难的，更不用说让一组专家就合适的过程达成共识了。到头来这是值得的，但是勤奋和耐心在这个阶段会给你带来好处。
6. 改进系统
请专家委员会做以后的审查。一旦你的专家系统部署到位，很难长时间留住你的专家;他们需要定期审查实际的结论，确保你的系统仍尽到作为专家的责任。事先获得他们的这种承诺。就像你在需求征集阶段那样征得管理层的同意――可以这么说，专家系统稳定下来后，至少每年每季度你需要一次得到他们的关注。在你开始动手之前，确保每个人对这个想法意见一致。
结束语
尽管种种新奇的系统和算法涌入数据科学界，但使用一种有几十年历史，并久经考验的解决方案：专家系统根本不会错。别因为设计的简洁性而误以为它过时或无效，事实恰恰相反。
只要你能找到合适的专家，就可以立即搭建起一套专家系统;与此同时，其他数据科学家仍在为压缩分类绞尽脑汁。掌握了这里给出的几个要点，以及你自己汲取的经验教训，你可能自己都没意识到，就成了专家系统的专业人士。
