过去一年以来，我的工作内容从简单编写 Jupyter Notebook，转向为机器学习开发流水线，用于全天候向建筑工程师提供实时建议。虽然工作成果仍有改进的余地（我承认，我在编码和数据科学方面犯了不少错误），但在过程中我还是学到了不少关于数据科学的知识。在本文中，我将结合自己的实践经验，与各位分享心得，希望帮助大家避免我曾在日常数据科学前沿工作中遇到过的错误。
生产层面的数据科学，总体属于计算机科学范畴
在被问及工作当中最困难的部分时，我总会首先强调一点——生产层面的数据科学，不属于机器学习。毕竟我们平时接触的“机器学习”基本都是这个样子：
相反，数据科学当中最困难的部分，在于建模之前与之后的开发工作。建模之前，我们需要解决的问题有：从数据库加载数据、特征工程、数据验证以及数据处理流水线（假设我们的荼在数据摄取之后才正式开始）。在结果验证之后，任务即可按计划自动运行，将结果写入回我们的数据库内，并发送 webhooks 以触发其他服务。
这些具体操作构成了机器学习中的大部分内容，同时也对工作人员的计算机科学知识提出严格要求。与代码开发相关的实践方面，则包括编写负责实现单一功能的短函数、开发类以实现多个相关函数、合理的命名约定、以代码与数据为基础编写单元测试、编写读取代码，同时确保不存在重复代码。此外，我们还需要将其他计算机科学实践应用于代码之内，例如版本控制、代码审查、持续集成、代码覆盖与部署等等。这些实践方法，共同构建起一个完全独立的新领域——机器学习运营（MLOps）。
尽管我努力完成了从机械工程到数据科学的过渡，但现在回想起来，如果当初能够选择从工程到计算机科学、再到数据科学的成长道路，也许效果会更好一些。后一种方法意味着，我用不着在数据科学实践当中积累编码知识。换句话说，虽然先学数据科学、再学计算机科学也不是不可行，但最好的方法应该是把二者的顺序颠倒过来。
计算机科学涉及一种完全不同的系统性思维方式，即在编码之前进行合理规划、逐步编写代码，并在编写完成之后进行代码测试。清晰明确的代码，与我之前随意写下的各种 notebook（我们都会编写名为 Untitled12.ipynb 的 notebook）形成了鲜明的对比。此外，计算机科学更强调快速获取结果的重要性，而非可重复利用的无错误代码。
任何数据科学家，都能够从计算机科学最佳编码实践课程当中受益。结构化脚本与软件包、简洁的代码编写风格、测试与记录代码的能力，将帮助我们更高效地管理从探索性数据科学到生产性机器学习的过渡。此外，计算机科学还带来一种重要的思维模式，帮助我们编写出更易于理解且可复用的代码。即使是那些单纯为了分析论文数据而编写数据科学脚本的学术型数据科学家，也将从这些实践当中获得助益。如果科学家们能够编写出更简洁的代码，并佐以用于输入、输出以及函数行为验证的单元测试，那么对科学中可重复性问题的处理能力将得到极大增强。
数据科学当中包含大量值得学习的主题，有时候会令刚刚上手的朋友感到不知所措。但是，计算机科学并非补充性知识；相反，对于希望保证代码可操作性的数据科学家而言，计算机科学更是一种基础性前提。幸运的是，目前市面上存在大量优秀资源，可供感兴趣的朋友学习并应用这些重要的编码实践。
数据科学仍是一种高度主观的学科
数据科学承诺利用数据——而非人类判断——做出最佳决策。虽然这个目标听起来有理有据，但目前的现实还远远无法支撑起这样的效果，这是因为我们使用的数据内容与分析方法在很大程度上仍受到人类的影响。事实上，就连数据科学中的所谓客观因素，同样与人类行为密不可分。正如 Vicki Boykis 在文章中提到，神经网络从始至终都是人的体现。
典型机器学习系统中的每一个步骤，都会受到个人选择的影响。下面来看几种具体决策方向：
数据收集: 我们需要收集什么数据？使用什么传感器？要调查谁？如何表达我们的问题？
特征工程: 我们建立哪些特征？应当使用特定领域知识还是自动化特征工程？如何填充缺失值？哪些意见需要被剔除？
建模: 我们应该使用哪些超参数？模型的复杂度应该控制在怎样的水平？
验证: 我们使用哪些评估指标？验证流程该如何设计？理想的结果应该拥有怎样的性能表现？
部署: 我们能否信任结果并将其展示给客户？是否需要引入人工评估预测，以进行完整性检查？
很明显，不同的人对于上述问题将给出不同的结论。《同一套数据集，不同的分析师（Many Analysts, One Data Set）》一文列举了一个实例，描述多位数据科学家如何凭借不同方法，利用相同的数据集得出相互矛盾的决策结果。毫不夸张地说，我们完全可以通过变更分析方法的方式，利用同一数据集同时证明某个论点及其对立观点。由此来看，我们不该对任何一项研究得同的结论坚持不放，而应该以怀疑的态度审视元分析过程。
此外，人为偏见（无论有意还是无意）都会出现在数据当中，进而影响到机器学习模型。正如《数学毁灭性武器（Weapons of Math Destruction》一书所提到，将决策工作交由机器处理并不能消除歧视，而只是对现实数据中存在的现有偏见进行了一番“整理”。我们的最终目标当然是利用数据科学消除决策偏见，但只要仍有人类参与，我们就不能盲目信赖机器学习的预测结果。
数据科学的主观性，是否意味着我们将陷入关于真理的“不可知论”当中？我认为我们有必要重新思考这个问题：我们不可能找到完全正确的答案，而只能利用数据科学——哪怕仍存在缺陷——不断朝着更好的方向迈进。毕竟，数据科学只是科学的一个子领域，因为其目标同样是随着时间的推进而减少错误机率。同样的，研究问题的人员越多，工作结果就越容易直接比较，也能帮助我们不断提升结果质量。假设有 20 名科学家进行 20 项不同的分析，只要他们能够后续比较分析方法并协同努力，那么最终成果将优于任何单一项目。
在数据科学实践当中，我们必须牢记：与任何其他领域一样，数据科学并非没有缺陷，我们也不应该毫无保留地对其给予信任。因此，负责任的数据科学研究态度，应该是每隔一段时间展示分析结果、尝试找出结果中的谬误、将自己的结果与其他类似工作进行比较，并在展示结果时充分与现实情况进行对比。
正是由于数据科学的一大前提在于人类的判断力，因此我们必须意识到：
人员与沟通技巧至关重要
尽管看起来像是废话（毕竟，有哪个领域能够接受负面的沟通效果呢？），但我每天都在提醒自己，必须要切实有效地向来自各个技术领域的人们传递机器学习知识。单纯了解机器学习术语还远远不够，我们需要能够与拥有不同理解的人们沟通，并告知他们需要知晓的种种细节。
（举个例子，有些朋友非常了解我的工作内容，能跟我进行长时间的机器学习细节讨论；但也有些人认为我是「管电脑的」……）
以我自己为例，机器学习决策并不能替代人工选择（即使有时准确率更高），毕竟最终要由建筑工程师来决定哪些建议值得采纳。事实上，自主建筑运营的全面实现，也许要比无人驾驶汽车更为困难。单纯建立模型、证明模型准确性并将结果提交给客户，当然还远远不够。数据科学家还需要玩转一片混乱的社交互动场景。如果无法说服他人，那么即使开发出了最强大的机器学习模型，它也不可能发挥任何实际作用。
我日常工作中最常规的组成部分，就是面向内部与外部小组通过文章与案例演示来解释分析方法，了解我们的客户如何制定当前决策，并与行业内专家交谈以将知识转化为数据科学系统。大学里肯定不教这些内容，课堂上我们总是认为科学家可以始终高举完美客观的大旗——但现实工作是位好老师，狠狠地击碎了我的幼稚梦想。
即使在解释了计算机如何做出决策之后，客户有时候仍然不愿意采纳，这是因为人类绝不是纯理性的动物。在呈现出客观层面更好的选择时，人们可能出于习惯、不信任、熟悉或者某些误导性信息等理由，而下意识到选择其他选项。
我们不妨以外出兜风例具体聊聊这个问题：人们似乎会出于逻辑角度选择两点之间距离更长的路径。为什么？因为沿途风景更漂亮。天真的数据科学家们当然会推荐模型给出的最短路线，但真正了解客户的数据科学家们会意识到，他们想要旅途中充分享受与大自然的亲密接触。
同样的，有时候客户不愿使用最佳机器学习预测方案，是因为准确性并不是唯一的考量因素。例如，我们预测了建筑工程师开始为建筑物供暖的理想时间点，但不少工程师仍然会更早打开设备，因为他们不希望租户感到温度不适。这当然不合理（我们会按时提出建议，确保在租户抵达室内时将温度提升至正确的水平），但除非能够把人彻底从决策流程中剔除出去，否则需要做出调整的永远只能是计算机系统这一方。
也许除了计算机科学课程之外，我们还可以参加一些社会学课程来了解人类同胞的想法。
使用标准工具，同时放慢新技术的采用速度
我们怎样才能保证算法当中不存在任何错误？首先，从 sklearn 上导入模型，这比自己编写靠谱得多。除非大家是在搞前沿研究，否则真的没什么理由自己动手编写机器学习模型。相反，最好是使用经过广泛测试及使用的公开库提供的函数（我称其为标准工具）来完成任务。
在最近的一条推文中，我提到差劲的数据科学家总爱自主编写算法，而优秀的科学家们则选择从标准库处导入算法。这里面当然有戏谑的成分，但我仍然坚持这样一条原则：相较于自主开发的代码，使用经过广泛测试的开源库中的代码，几乎永远是更加高效可靠的作法。
这种标准工具优先的逻辑不仅适用于机器学习模型。事实上，我们希望对数据集执行的几乎一切操作，都能在 pandas 中找到对应的实现方案（假设您使用 Python），所以不妨优先从这里入手。同样的，与统计、绘图、测试、调度、任务部署以及机器学习流水线内大部分其他操作相关的标准库也所在多有，请善加利用。
我现在这份工作，原本是由两位拥有博士学位的数据科学家负责的。作为学术精英，他们一直渴望发明自己的数据结构、指标、算法、文件加载机制等等（可能是为了证明自己的学位货真价实吧……），但这也带来了一大堆无法理解的混乱代码。我入职后的前六个月，主要工作就是用三个 import 语句替换这些上百行的脚本。现在，我可能非常骄傲地向大家宣布，我已经成为这套机器库出色的负贡献者。
此外，不要盲目采用新近发布的库/技术/框架/数据库。像 SQL 数据库、sklearn 机器学习以及 pand 数据操作这样的标准工具虽然古老而且无聊，但却能够正常运作——而且经过了大范围的测试与可靠性评估。别搞新官上任三把火那种没用的事情，虽然起初在热情的支持下吐故纳新似乎很有乐趣，但在经历一系列错误与文档匮乏问题的折磨之后，大家很快就会筋疲力尽。
新兴技术往往只是媒体头条的跟踪对象，但对于实际从业的人员及企业几乎没有任何即时影响。不少年轻一代的技术人员对我这种观点持反对意见，但相较于那些新鲜出炉但还没有证明过自己的技术，我确实更偏爱那些无聊却已经非常成熟的方案。在内部，我们的工程团队对库版本的升级问题进行过长时间的争论；最终，我们认为如果没有明显的优势或者需求，我们不会单纯因新版本的发布而升级。要向机器学习项目中添加库之前必须经过严格证明，因为新库的加入意味着我们需要管理的依赖项也将同步增加。
生命力最顽强的企业，恰恰就是那些安于平凡且步伐稳健的企业（例如 Caterpillar）；而那些行动迅速，而且总是显得“酷酷”的初创公司则往往在几年之内就会烟消云散。最强大的机器学习系统绝不是塞满了尖端技术的工具展柜，而是久经考验、以数据科学标准工具为基础的可靠小背包。
利用外部简单性，隐藏数据科学的内部复杂性
计算机非常擅长处理人类几乎无法应对的大规模数字。为了有效将计算机与人类的长处结合起来，我们应当利用计算机分析大型数据集，且只向决策者展示其中最关键的几项数值。数百万数字进，几个数字出。复杂模型在内，可行性建议在外。
过去一年以来，我开发出一种理论，即图表中的数据点越多（黄金数据点大概是……7？），结论就越是缺乏实际意义。人类确实没有能力准确地分析复杂定量图。热图虽然很酷，但有人能利用包含 1000 个数据点的热图（相较于只有 5 个数字的柱状图）做出关键性决策吗？不存在的。
我是那种喜欢细读数字并了解机器学习模型细节的人，但我也很清楚，大多数朋友其实并不想一下子被数据所吞没。客户和制定决策的领导者们想听重点、听干货，一定是这样。换句话说，内容越简练，图表的展示效果就越好。
外部简单性这一论点，并不代表单纯使用线性模型。数据科学往往只涉及复杂的算法与高技术培训性操作，因此对于非技术人员而言，必须确保数据科学拥有一套平易近人的“外壳”。不过需要注意的是，有些数据科学模型太过复杂，以至于我们自己可能都不太理解。那么，有必要以无法解释为代价，通过混合模型提高那么一丁点精度吗？答案恐怕是否定的。
为了用外部简单性掩盖内部复杂性，我们应当使用有助于描述模型决策的工具。SHAP 值就是一种非常实用的技术，当然大家也可以选择其他方法。为了解释建筑物的最佳运作启动时间，我们对所有特征（包括工程化特征）采用 SHAP 值，并将其组合为人类能够理解的特征组——例如天气与建筑物内部条件。我们采用复杂的机器学习算法，SHAP 值的介入能够简化算法帮助我们理解，并有必要在向客户展示产品之前借助自己的专业知识做出进一步简化。
简化定量信息的一种可行方法，是准备一份单纯以数字为起点的报告，而后根据需要慢慢添加其他数字（或者图形）。这种累加的方法相当于由少而多，确保演示与报告内容当中不存在无关紧要的统计数据——与之对应的，就是由多而少，准备大量图表而后逐一删除。请记住，人不是计算机，所以千万不要把只适合计算机的展示方式摆到人类面前。
“名不副实”综合症
再加一点：每个人都或多或少会有“名不副实”综合症；自省是对的，但不要被这种情绪所支配。
最后，作为数据科学（也包括其他专业）中的一个重要问题，我想跟大家聊聊：不要让“名不副实”焦虑或者偶尔犯下的错误，占据你的全部情绪。
每个人都会产生一种感觉，认为自己没有资格负担起目前的工作，或者终究会因无法胜任而被“曝光”。在这里我要劝劝大家，不要为此过度烦恼，毕竟并不是只有我们存在这样的想法，而且学习新事物与产出的结果同样重要。另外，如果您才刚刚迈入数据科学圈，那么也可以安心享受一波新手红利（例如寻找新的方法来解决问题）。另外，虽然身边的人们可能非常成功、甚至拥有辉煌的成功，但请相信，他们的成长道路上同样布满荆棘（这是种幸存者偏差）。
InfoQ高级技术编辑
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论