Skip to content

Latest commit

 

History

History
147 lines (79 loc) · 12.7 KB

scientific-debt.md

File metadata and controls

147 lines (79 loc) · 12.7 KB

科学债务——对数据科学意味着什么?

原文:www.kdnuggets.com/2018/05/scientific-debt.html

c 评论

David Robinson,Datacamp 提供

在软件工程中,一个非常有用的概念是**技术债务**。


我们的前三大课程推荐

1. 谷歌网络安全证书 - 快速进入网络安全职业生涯。

2. 谷歌数据分析专业证书 - 提升你的数据分析技能

3. 谷歌 IT 支持专业证书 - 支持你的组织在 IT 方面


技术债务发生在工程师选择了一个快速但不理想的解决方案,或者没有花时间建立可持续的基础设施。也许他们正在使用一种在团队和代码库扩展时不够灵活的方法(例如硬编码“魔法数字”),或出于便利而非适当性使用工具(“我们将用 PHP 编写 DevOps 基础设施,因为这是我们团队已经掌握的”)。无论如何,这是一种看起来最初有效,但在长期中会带来真正挑战的情况,比如推迟功能发布和难以修复的漏洞。

在我担任DataCamp 首席数据科学家的新工作中,我一直在思考数据科学在企业中的角色,并与该领域的其他专业人士讨论。在今年早些时候的一个讨论小组上,我意识到数据科学家有一个大致相当于这一概念的东西:“科学债务。”

科学债务是指团队在数据分析、实验实践和监控中采取的捷径,这些捷径可能会带来长期的负面影响。 当你听到这样的陈述时:

  • “我们没有足够的时间进行随机测试,让我们直接上线吧”

  • “初步估计,这个效应可能是线性的”

  • “这可能是一个混淆因素,但我们稍后会研究这个问题”

  • “至少在方向上是准确的”

你听到的是一些“借用”的科学债务。

示例:WidgetCorp

大多数工程师对公司在面对技术债务时的感觉有所了解。一个面临科学债务的公司会是什么样子?

想象一个小型初创公司 WidgetCorp 正在开发一款 B2B 产品,并决定他们的销售策略。某一年,他们决定开始将销售重点放在较大的企业客户上。他们注意到,随着这种新策略的实施,他们的月收入有所增加。他们因此受到鼓舞,并在接下来几年中聘请了半打有大型客户经验的销售人员,投入营销和设计工作,将其作为品牌的一部分。

几年后,这种策略似乎没有带来预期的效果:他们的收入陷入困境,早期的成功没有重现。他们聘请了一位分析师,查看了他们的销售数据,并发现实际上他们从未在向大公司销售时获得更高的投资回报率。在早期那一年,他们的收入上升是因为季节性效应(秋冬季节对小部件的需求增加),这与一些随机噪声和轶事(例如“SmallCompany.com 是浪费时间,但我们刚刚与 Megabiz 签署了一份大单!”)叠加在一起。

WidgetCorp 承担了过多的科学债务。

这可能发生的几种方式:

他们基于有缺陷的分析做出了不可逆转的决定。 对于指标,快速查看并欣慰地发现它们朝着正确的方向发展是合理的。但一旦公司在产品、销售和市场营销上做出了改变,就很难再进行调整。在做出重大业务变动之前,值得确保数据能够支持这些决策:即确保他们已经考虑了季节性影响,并应用了适当的统计测试。

缺乏监控。在早期,可能没有足够的数据来判断大型客户是否是更好的投资。但是随着更多数据的收集,值得不断测试这个假设,形式可以是仪表板或季度报告。如果没有进行跟踪,即使他们获得了数据,也没有人会注意到这个假设被证伪了。

数据基础设施的缺乏:也许在公司早期,潜在客户被锁定在销售 CRM 系统中,而会计数据则存储在通过电子邮件传送的 Excel 电子表格中。即便公司内有专门的分析师,他们也可能无法轻易获取相关数据(例如,将销售成功与公司规模联系起来)。即使理论上可以通过一些努力将数据集结合起来,懒惰盲点 也可能让每个人都完全避免进行分析。这是一个技术债务和科学债务常常一起出现的领域,因为解决科学问题需要工程方面的努力。

传播不准确的传说。假设 WidgetCorp 的 CEO 进行了一系列公司范围的演讲和公开博客文章,传达的信息是“WidgetCorp 的未来是服务大公司!”产品团队开始习惯性地优先考虑这个方向的功能,每次失败都归咎于“我想我们没有足够专注于大客户”。这种“文化惯性”可能非常难以扭转,即使高管团队愿意公开承认他们的错误(这并不是保证的!)。

几乎每个经验丰富的数据科学家都有至少一些这样的故事,即使是来自其他成功的公司。这些故事对科学债务的意义就像Daily WTF对技术债务的意义一样。

科学债务总是坏的吗?

完全不是!

我在自己的分析中经常走捷径。对一个功能发布进行随机实验有时成本过高,尤其是当用户数量相对较少或变化相当无争议时(例如,你不会对拼写错误修正进行 A/B 测试)。尽管相关性不意味着因果关系,但在做出商业决策时,它通常比什么都没有要好。

将其与技术债务相比是有用的:一个小型工程团队的首要目标通常是快速构建一个最小可行产品,而不是过度工程一个他们认为在遥远的未来会非常稳健的系统。(科学债务中的等价物通常被称为过度思考,例如:“是的,我认为我们可以在检查销售交易成功与否时控制天气,但我很确定你在过度思考这个问题。”)与财务债务的比较也是有意义的:公司在成长过程中通常会承担债务(或类似地,放弃股份)。就像你不能在不借钱的情况下建立一家公司一样,你不能在确定每个决策都得到充分数据支持的情况下建立公司。

技术债务和科学债务中重要的是要记住长期成本

如果你没有...

  1. 利用它先获得一些有价值的东西

  2. 定期支付利息

  3. 将其视为一种可能最终需要全额偿还的负债

不符合这些标准的代码不是债务,它只是低质量的工作。

— 实践开发者 (@practicingdev) 2018 年 2 月 26 日

错误的决策代价高昂,不关注数据是一种风险。我们可以对这种风险是否值得进行成本效益分析,但不应将其视为“数据科学家总是找借口”的表现。

为什么还要称之为“债务”?

对于数据科学家或分析师来说,这篇文章可能听起来相当明显。当然,忽视统计严谨性是有缺陷的,那么为什么还要给它一个“流行术语”的名字呢?因为它将这个概念放在了高管和经理们易于理解的术语中。

再次回到技术债务。个人工程师可能有很多原因想要编写“干净的代码”:他们欣赏代码的优雅,他们想给同行留下深刻印象,或者他们是完美主义者,拖延其他工作。这些原因对非技术员工通常并不重要,他们关心的是产品特性和可靠性。技术债务的框架帮助强调公司因不投资架构而失去的东西:即使产品看起来在正常工作,缺陷在实际的金钱和时间上也会有长期的成本。


工程师: 我很烦恼不同的内部项目使用不同的命名规范。

首席技术官: 对不起让你烦恼了,但代码就是代码,我不明白你为什么要在这上面浪费时间。


工程师: 我们不一致的命名规范就是技术债务:它使新开发者更难学习系统。

首席技术官: 我一直在寻找减少我们入职时间的方法!好主意,告诉我你需要什么来解决它。


同样,科学家,尤其是来自学术背景的科学家,通常对揭示现实中的真相有特别的兴趣。因此,“我想分析 X 是否是这里的一个混杂因素”的想法可能听起来像是一种奢侈,而不是一个迫切的商业需求。统计学家尤其喜欢发现数学方法中的缺陷。因此,当数据科学家说“我们不能使用那个方法,Jones 等人在 2012 年证明了它在渐近上是不一致的”时,非技术同事可能会认为他们在过度思考,甚至是炫耀。将其框架化为我们实际上冒的风险有助于传达为何花时间去做是值得的。

我们如何有效地管理科学债务?

  • 让数据科学家“支付利息”。正如不是每个工程项目都会带来新特性一样,不是每次分析都会带来令人兴奋的发现或新颖的算法。有些时间需要花费在确认或证伪现有假设上。乔纳森·诺利斯关于数据科学工作的优先级排序有一篇很好的文章,他在文章中将这一象限描述为“提供证明”。

  • 构建数据工程流程: 正如之前所描述的,公司可能会陷入科学债务的一个原因是分析师可能无法轻松访问他们需要的数据。这些数据可能被锁在尚未被摄取的平台中,或存储在需要手动编辑的 Google 表格中。将相关数据摄取到数据仓库或数据湖中,可以使数据科学家更有可能进行相关发现。

  • 重新审视旧的分析:早期阶段公司进入科学债务的一个常见原因是数据不足以得出可靠的结论。即使你还没有足够的数据,也不意味着你应该忘记这个问题。有时,我会在日历上安排时间以便在预期有足够数据时进行分析,即使这可能要几个月。这样也可以帮助确认一个重要的分析是否仍然相关:就像你会随着时间跟踪 KPI 一样,你也要跟踪结论是否仍然正确。

  • 让数据专业知识在公司内部传播。就像一个不能编程的人可能不会认识到技术债务一样,一个没有分析和理解数据经验的人可能不会认识到科学债务。这是另一个在公司内部实现数据科学民主化的理由,正如我们在 DataCamp 所做的

简介:David Robinson,是 DataCamp 的首席数据科学家,使用 R 和 Python 进行工作。

原文。经许可转载。

相关:

更多相关主题