·
关注 发表在 Towards Data Science ·14 min read·2023 年 8 月 23 日
--
行业内的高级数据科学工作有时也被称为“应用科学”，反映了它不仅仅是关于数据的现实，以及许多前学者在该领域工作的事实。我发现“应用科学”有着不同于研究科学的期望。因此，我写下了在我看来有助于产生出色应用科学工作的内容。我将其作为数据科学工作的“完成定义”，但许多要点也将对分析师、工程师和其他技术角色有所帮助。
伟大的应用科学家通过巧妙地利用数据和模型，解决有价值的实际问题，从头到尾。有时，第一步是发现最具影响力的商业问题，这些问题可能提供可行的科学解决方案；有时，商业问题已经被很好地理解，科学工作则从制定明确的技术问题陈述开始。
无论哪种情况，成功的科学工作都始于理解实际问题。科学家需要充分理解复杂的商业挑战，以便将其转化为可以在有限时间内解决的技术公式。他们穿透模糊性，创建适当的结构假设以实现解决方案。
成功的科学工作能够找到技术上合适且务实的解决方案：这可能意味着最先进的深度学习，但非常高级的科学工作也可能由一些巧妙的 SQL 查询组成。优秀的科学家知道如何为任务选择合适的工具。
伟大的科学家理解，陷入糟糕的技术方法很容易。为了避免这种情况，他们将工作分阶段进行：他们能够将大型问题拆解为较小的子问题；通过生成中间结果验证单个方法，并积极从同行那里获取反馈。
优秀的科学工作会纳入反馈，因为良好的归纳偏见能显著加快学习过程。但优秀的科学家也知道如何识别经验性问题，并坚持使用数据来回答这些问题。
伟大的科学工作意味着记录再现解决方案所需的步骤，并以适合观众的方式呈现结果。同时，还要确保结果被使用——无论是软件的变化、战略决策，还是发表的论文。因为只有这样，宝贵的实际问题才能从头到尾得到解决。
以下四个原则支撑了这些关于行业应用科学工作的建议：
-
所有权：我们的工作是解决模糊的问题，从头到尾。
-
高效的好奇心：我们喜欢学习。理想情况下，比通过盲目实验更高效。
-
三思而后行：在探索性工作中，明确的规划可以防止迷失方向。
-
迭代结果：频繁的反馈减少了模糊性。
以下章节提供了根据我的经验能够改善科学工作的具体建议，这些建议是按照科学过程结构化的。
应用科学的工作本质上是社会性的。要产出出色的成果，应用科学家需要在团队中表现出色。
很多科学工作需要与他人协作；理解之前的工作，寻找相关的数据集，要求解释，将进展传达给你的利益相关者，说服你的团队成员支持你的项目。最终你负责交付结果——管理协作是工作的一部分。这可能意味着你需要说服团队成员审查你的 Pull Request，也可能意味着你需要找到将数据工程需求纳入另一个团队待办事项中的方法。当这个过程陷入困境时，你可以升级问题，领导可以帮助明确优先级——但你有责任完成这一工作。
作为科学工作的一部分，团队经常在小组讨论或一对一的情况下头脑风暴。这些会议可以非常有价值，帮助产生比任何一个人单独完成的更高质量的工作。但如果头脑风暴会议没有直接与后续工作相关联，它们通常是一种浪费时间。你需要避免后者——这意味着要主动跟进讨论的想法和任务：如果团队达成了一致，认为某事应该完成，就去做（并沟通结果）。如果立即做完太多，可以为这些想法写一个工单（并沟通工单）。在头脑风暴会议中，主动询问具体的收获和谁负责下一步是非常有帮助的——任何人都可以这样做，并与团队分享他们的笔记。
并非一切都按照计划进行，科学工作的性质决定了大多数实验会失败。计划没有如预期那样顺利进行是可以预期的。这使得科学工作成为一种高变异性的活动：即使你可以准确预测你工作的“期望值”，意外也是很可能发生的。
当事情没有按计划进行时，要完全透明。最重要的是，当发现问题时立即通知你的团队。这可以更高效地协调路线图和交付物。作为回报，期待信任：失败的实验是我们日常工作的组成部分。
最令人烦恼的实验结果是“结论不明确”：实验并没有完全失败，但也没有成功。这些也是科学工作的一部分，它们也值得展示和分享：我们可以假设为什么科学问题无法解决吗？如果我们从头再来，我们会做得不同吗？
在团队合作时，自然不会理解演示、对话或任务中的所有内容。然而，“随声附和”是有问题的——当其他人假设你理解了你其实没理解的内容时，这很可能导致误解和工作结果的不一致。作为科学家，“为什么”应该是我们最喜欢的问题：当某些事情不清楚时，继续提问直到感到有了共同理解。如果有疑问，用自己的话重新表述某些内容是检查你是否真正理解的有效工具。
正确理解商业问题往往比纯粹的研究科学更“复杂”：概念定义不明确，量度不可测量，利益相关者的目标不一致。然而，误解待解决的问题会导致失望，减少应用科学工作的价值——没有科学的复杂性可以挽救这种情况。
继续提问直到你完全理解商业问题。在某些情况下，你的问题可能会导致商业问题表述的细化甚至转变。
在将商业问题用技术术语表述时，我们通常需要做出一些基本假设：我们需要选择某一概念的具体定义，我们忽略边缘情况，我们需要决定哪些潜在副作用超出范围。记录这些假设，以便后续回顾。
由于做出假设，你可能会解决错误的问题，因为一个合理的假设证明是不准确的。预防这种情况的最有效方法是渐进工作，并频繁验证增量是否朝着正确方向发展。极端情况下，构建一个模拟解决方案（例如一个快速的电子表格）通常可以帮助生成有价值的商业反馈。
在开始深入建模工作之前，仔细检查你的方法是否能解决正确的商业问题。但不要忘记在过程中反复验证这一点。如果有疑问，选择频繁且较小的迭代。
一旦开始深入数据和模型，就容易迷失方向。写下清晰的研究路线图可以帮助避免这种情况。经验丰富的科学家通常会有意识或无意识地遵循明确的假设结构，将模糊问题分解为顺序可解的子问题。我建议在编写第一行代码之前，先写一个完整的假设结构草稿，并获取反馈。
重要的是你要写下一些形式的计划，并在进展过程中在其中定位自己。我发现的一个有用格式是思维导图或以假设树结构明确规定的项目符号。这是创建一个的粗略“算法”：
-
对你的问题进行一些不同的思考；不要忘记查找来自其他团队的现有解决方案、开源项目和已发表的材料。将它们记录为“候选方案”。这里的想法是广度优先：收集许多粗略的想法。
-
粗略估计“验证”某种方法所需的工作量：这不是解决问题所需的工作量，而是判断某种方法是否很可能有效的工作量。
-
按照估计的验证工作量对你的方法进行排序。
-
从最低验证工作量的方法开始，头脑风暴如何验证这种方法，并最终使用它来解决你的（子）问题。递归地继续你的树（即对于每个子问题，从 1 重新开始）。根据需要对树的各个层次重复这一过程。
使用这种方法，你最终理想的结果是一个结构良好、优先级排序的计划，明确首先尝试什么，成功后怎么做（沿着那一分支），以及失败后怎么做（继续在当前分支下的下一个分支上工作）。你树的“叶子”理想情况下应该是相对容易测试、可以通过数据回答的问题。你的计划结构还应该使描述进展和获取中期结果反馈变得更加容易。
最难捉摸的建议：伟大的科学家对哪些方法可能有效、哪些方法不值得进一步考虑具有非凡的直觉。这有时会给人一种特定的人“总是能让一切奏效”的印象——更准确的说法是，这些人知道什么不要尝试，他们大多数时间都花在了富有成效的想法上。当然，建立这种水平的直觉是困难的，是一个终身的事业。好的直觉意味着你将大多数时间花在富有成效的假设上——这很重要，因为潜在的假设和想法的宇宙是巨大的，直觉减少了你假设树中的搜索空间。
当你找到一个你信任其直觉的人时，请向他们询问该跟随哪些方法。请他们为该建议提供理由。尽量理解他们如何思考问题-解决方案的映射，超越直接的技术问题。
构建直觉特别受益于互动学习：考虑与同事进行配对编程的日子，并互相解释概念。尽量面对面交流，而不仅仅是远程交流：至少我尚未找到能完全替代白板或几张白板以及同处一室的替代品。
投资于理解基础知识：你应该建立事物运作的心理模型。这些模型需要“足够正确”，但又足够简单，以便应用于现实世界情况。你应该能够在架构层面进行“黑箱思维”，并在处理细节时理解黑箱的内部工作。为了更具体地说明：在处理图像或文本数据时，使用“嵌入”的想法是一个很好的直觉，可以帮助你快速建立潜在模型的心理架构。但要准确判断这些方法的可行性，你需要完全理解嵌入是如何训练的，以及结果信息的编码方式。
对类似但不同的问题保持好奇。考虑它们相似的地方和不同的地方。思考你问题的解决方案如何适用于这些类似的问题。一些例子：可替代产品的实验与社交网络的实验（“溢出效应”）相关。时尚定价与航空公司定价（“易腐烂商品”）相关。产品/实体匹配与音乐版权执法（“粗略+精确匹配步骤”）相关。
反思你之前的工作：当你不得不尝试某些东西时，因为你没有强烈的直觉，你可以从实验中学到什么？是否有从实验中学到的普遍真理可以帮助你提高直觉？
积极寻求对你方法的批评：无论是作为“研究路线图审查”的一部分，还是作为你对完成项目的反思，异议意见可以帮助你磨练直觉和发现盲点。
在应用于探索/实验性工作时，干净的代码是一项特殊的挑战，这在应用科学中非常典型。但它同样重要：干净的代码可以避免错误，部分是因为它强制进行清理，部分是因为阅读你代码的人更容易发现错误，部分是因为它使你在第一次实验不可避免地失败时更容易迭代思想。变量名称比大多数大学课程所建议的要重要得多。函数、类和模块的封装可以帮助处理不同层次的细节和抽象。
过早的“生产化”可能会拖慢进度：在解决方案明确之前，应该容易替换你方法中的部分。
当你编写分析笔记本时，要为读者编写，而不仅仅是为了自己。解释你在做什么。使用好的变量名称。清理图表。标记单元格是发明有原因的。
思考DRY 代码。当你发现自己从以前的调查中复制/粘贴代码时，这通常是一个重新构造的好时机。
当进行探索性工作时，考虑到读者的需求，可以像处理其他代码一样将其作为 Pull Request 进行审查。实际上，最终分析答案所需的所有步骤都应该经过第二双眼的审查。请为你的审阅者提供方便，在提交审查之前，移除（或明确标记）纯粹的探索性代码。
组织和更新中央知识库是我所知技术组织中最普遍的问题之一。我不知道简单的解决方案。但我知道，投资于良好的文档从长远来看是值得的。对于中央知识，应该有一个（而且只有一个！）中央来源。这个文档应该是真相的来源：如果代码与文档不符，代码是错的（而不是文档）。这需要频繁且便捷地更新文档：写得差，但正确且完整的文档远胜于写得好但过时的文档。投资文档是值得推广的工作，我相信它的影响。
演讲是一个大步后退，反思你工作在宏观层面上意义的机会。这对于最终结果的展示是正确的，但对于中期结果的展示可能更为适用。
每次你展示结果时，都要考虑观众的期望。对于你提出的每一点（每一张幻灯片；每一节文本），你应该回答观众心中的隐含“那又怎样？”不同的观众在这里会有不同的期望：高级业务领导可能对一个直接叙述最感兴趣，这个叙述捕捉了你的发现的精髓，并且可以轻松地与其他高级领导共享。你的经理可能最关心的是了解如何解决一个特定问题以及何时解决。一个同事可能最感兴趣的是他们可以从你的方法中学到什么，以便用于自己的工作。一个利益相关者或客户将想知道你的工作使他们能够做出哪些新的决策或采取哪些行动。
我发现许多科学家倾向于在展示中遵循他们的发现过程，从第一个实验开始。我强烈建议不要这样做，因为这通常会导致在你甚至还没到达有趣的部分时就失去观众的注意力：相反，从你试图回答的原始业务问题开始，以及你对原始问题的最佳答案开始。然后描述你的高层次方法，并解释为什么你认为你的答案是你能给出的最佳答案。预见你的展示会提出哪些问题，并准备好答案。最重要的是，回答你提出的每一点“那又如何？”的问题。
有趣的实验，如果最终未对你的答案产生贡献，应放在附录中——它们可能对深入讨论有帮助，但不需要在主要展示中出现。
推论：为展示准备材料常常感觉像是在忙碌工作。相反，我发现频繁制作可展示的中期结果有助于保持专注和思维清晰，因为你迫使自己退后几步。制作清晰的图表和展示用叙述对保持专注于最终目标以及得出明确结论极为有用；但优化幻灯片布局并非如此。因此，对于中期结果，形式服从功能。重要的是清楚传达关键信息。设计是否完美并不重要。例如，手绘图形并展示其照片是完全可以接受的。
所有图表应自解释，并传达明确的信息。我强烈建议即使是在你仅为自己创建的图表中，也要遵循一些基本原则。
-
用自解释的描述标记你的轴：使用单词，而不仅仅是字母。
-
使用清晰的图表标题，解释所展示的内容和 主要信息（再一次，“那又如何？”）。
-
将展示的数据减少到必要的部分：例如，数据中可能包含一个明显不打算有用的“虚拟”类别。不要让这些在图表中占据视觉空间。
-
当展示多组仅通过颜色区分的数据时，请确保颜色图例清晰区分（如果考虑到色盲友好会更好）。
-
可视化有助于理解数据中的模式。如果一个图表仅展示了一个混乱的点云，它可能是多余的（除非你想证明某个特定点）。
-
对数尺度通常有助于清理（正）计数数据的图表。
每当展示数值结果时（例如，在表格中）：
-
针对并展示一个合适的成功指标进行优化。许多应用科学家在这方面花的时间太少：了解何时使用 RMSE/MAPE/MAE、对数尺度、F1 与 ROC 与精准度-召回曲线下面积的区别。
-
几乎所有现实世界的问题都涉及加权成功度量，然而大多数机器学习课程几乎不涉及这个话题：例如，销售预测的成功度量可能需要根据使用情况加权价格、库存价值或包装尺寸。
-
如果成功意味着估计反事实（“假如”分析），请明确表达，并找到一个明确的推理，说明你的成功度量如何捕捉这样的反事实。（自然）实验是一个流行的选择。
-
对于你呈现的任何数字，请提供合理的基准。通常，确定“正确”的基准需要深思熟虑，但这总是值得的。你拟合了一个复杂的机器学习模型？它比线性回归好多少？你建立了下周的预测？它比假设下周等于这周好多少？你正在呈现 A/B 测试结果？相对于我们的月收入，或者相对于上次改进，增长了多少？
把想法表达出来可能比听起来更难，而且做得好对技术人员来说是一种真正的超能力。沟通风格也是主观和文化的，因此你需要找到适合自己的风格。无论如何，我建议你有意识地改进沟通技巧：注意他人的表达方式；定义你喜欢的方式；批评并让他人批评你现有的沟通；编辑你自己的写作；写出如何解释一个复杂想法以准备在演示中实际解释；录制自己解释一个想法并听听它；寻求风格反馈。我们一直在沟通：如果你愿意，就有大量练习的机会。
谢谢你阅读到这里！我很想听听你的反馈：什么让你产生共鸣？你的经验在哪里不同？还有什么其他帮助解决有价值的现实世界问题的方法？
下面是我发现启发性的进一步阅读资源。大多数资源是“永恒”的，但有些技术资源可能在你阅读时已经过时。请在评论中分享你自己的推荐！
-
丹·纳：“用乐观和善良克服摩擦，因为这是工作。”（30 分钟视频）
-
Netflix 宣言：“我们是一支职业运动队，而不是一个家庭”，以及许多关于高绩效团队的想法
-
一个受咨询启发的关于“那么”和假设树的解释
-
更具问题解决能力的工程师的愿景（而不是“只做票中事项”）
-
对 ML、统计学、经济学相关观点的精彩总结 — 强烈推荐！ Matt Taddy 的商业数据科学
-
独特的现代统计学复习：Statistical Rethinking 2022
-
为迭代工作辩护的一个想法，最初来自软件工程：“追踪子弹”（来自下面链接的《实用程序员》一书）
-
Lisa Muth 的易懂的 数据可视化教程
-
现代 pandas（和/或直接阅读 Wes McKinney 的书）
-
超现代 Python：数据科学与良好的工程实践结合
-
宇宙 Python：软件架构与开发流程
-
成为一名 实用程序员
-
Dan Luu 的写作 — 从工程角度看有效的写作。
-
Ciechanowski 的博客 — 极其美丽的技术写作和插图
