Skip to content

Latest commit

 

History

History
175 lines (88 loc) · 14.2 KB

collection-things-learned-data-science.md

File metadata and controls

175 lines (88 loc) · 14.2 KB

我在数据科学中学到的东西

原文:www.kdnuggets.com/2019/07/collection-things-learned-data-science.html

c 评论

Saeed Hajebi,沃达丰大数据与人工智能主管

Header image

  1. 数据总是很混乱。如果你认为你的数据很干净,也许你还没有深入查看;如果你认为你的数据很混乱,那它可能更混乱。

  2. 没有人关心你是怎么做的;只要正确地做就可以了。

  3. 人们不会关心你知道多少,直到他们知道你关心他们及他们的业务有多少。

  4. 数据 > 大数据。在 2-3 年内,没人会再谈论大数据。

  5. 交付价值 > 算法、工具和技术。

  6. 交付价值 > 精美图表。

  7. 交付价值 > 行话。

  8. SQL > 任何语言(Python、R,甚至英语)。

  9. 精通数字、Excel 和 PowerPoint(是的,还有演示技巧)总是有回报的;Tableau 是一个很大的加分项。

  10. 下载一些代码和数据并运行它们并不会让你成为数据科学家。同样,参加数据科学课程也是如此。

  11. 参加 Kaggle 竞赛并不会让你成为数据科学家,但它可以帮助你从他人那里学习。

  12. 获得 Kaggle 竞赛的胜利并不一定能让你成为一个优秀的数据科学家。

  13. 现实世界的经验>任何东西。

  14. ETL 总是需要的——擅长它并学习一个好的工具(Talend 是一个不错的选择)。此外,还要学习 ETL 的脚本语言。

  15. 深度学习很酷,但如果在不需要的时候不使用它,它仍然很酷,在 99% 的情况下你不需要它。

  16. 算法是商品,你的数据不是。

  17. 创意是商品,执行则不是。

  18. 深度学习的专长很快会成为商品;问题解决技能则不会。

  19. 合适的统计知识>学习一个新的工具或库。

  20. 学习并使用你业务的语言;否则,人们会把你看作一个不懂任何东西的书呆子。

  21. 在许多情况下,一个简单的业务规则(SQL 中的 if else 或 CASE WHEN)就能完成工作。

  22. 线性模型和决策树很好,深入学习并经常使用它们。

  23. 如果你需要良好的表现却没有足够的时间,使用 GBM,但要正确使用它。

  24. 学习并使用模型可解释性技术——shap 是一个不错的选择。

  25. Python 和 R 都很好。停止争论,学习并使用两者。

  26. 在传达你的模型结果时,不要使用 AUC、Kappa、R² 等;业务用户不理解这些,也不在乎。改用 lift 和 gains。

  27. AUC 与准确率不同。不要用 AUC 混淆你的客户。AUC 只是“随机选择的正样本获得比随机选择的负样本更高分数的概率”。例如:如果你的应用场景是流失预测,而你的 AUC 是 0.8,那么随机选择的流失者获得比随机选择的非流失者更高分数的概率是 80%。对客户来说并不太有趣,对吧?客户可能会认为,如果你给他们 1000 个高流失风险的客户,800 个会是真正的流失者;但这与现实相去甚远,尤其是在高度不平衡的问题中。

  28. 在预测建模的应用场景中,如果人类表现不佳(或者贝叶斯误差率较高),例如,预测用户流失或点击预测等,人为的高准确率或 AUC(>0.9)可能是数据泄漏的迹象。

  29. 如果模型性能提升对业务没有重大影响,不要花费过多时间;“足够好”就是足够的。将大部分时间用来更好地理解你的领域、业务问题、数据以及如何通过分析增加价值。不论你的模型有多准确,它们很可能不会按照预期的方式使用。例如:你花一个月时间将模型的 AUC 从 0.8 提高到 0.82,但你的市场团队总是需要更多的潜在客户,因此你最终使用了你不满意的结果部分。你发送了 1000 个高潜力客户的名单,他们需要 5000 个。我见过数据科学家花了超过 3 个月的时间将 AUC 提高 0.0001,但他们的模型根本没有被使用。现实世界不是 Kaggle 竞赛。考虑业务需求。

  30. 当你没有好的表格数据,并且问题对人类而言容易(专家可以在 2 秒内给出正确答案)但对计算机而言困难时,深度学习是合适的;例如,图像分类、自然语言处理、计算机视觉等。如果你有结构化(表格)数据,或者通过特征工程可以从原始数据中创建出有意义的表格数据,并且问题对人类并不容易(例如,人类行为预测如流失预测、下一个点击预测等),并且你需要最佳的预测能力,经过微调的梯度提升树(GBM、XGBoost、CatBoost、LightGBM)可能是最好的选择。在这种情况下,不要在深度学习上浪费时间和金钱。

  31. 如果机器学习确实是你的应用场景所需的(请参见#21),那么在大多数情况下(也许超过 90%),二分类是最佳选择;即,问题已经是二分类问题或者可以简化为二分类问题。在约 5%的情况下,回归是合适的。因此,在约 95%的情况下,你将处理监督学习。对于剩下的 5%,如果可能的话,尝试将问题重新框定为监督学习问题。尽量避免无监督学习,因为结果并不总是有用——存在随机性、需要做出任意选择等。

  32. 对于每个使用案例请求,“从结果开始思考”。换句话说,考虑整个“数据到价值”过程,端到端。在跳到模型训练之前,向你的客户提出这些问题:

    • 要解决的业务问题是什么?定义、假设、指标等是什么?

    • 需要影响/改进的决策是什么?

    • 谁是客户?

    • 用户是谁?

    • 谁是业务赞助者?

    • 从分析中增加价值的一般机会是什么(例如,成本节省、收入提升等)?

    • 使用案例的年度货币价值是多少?

    • 他们今天是如何进行流程或做出决策的?

    • 选择标准是什么(例如,这是一个涉及所有客户还是特定客户群的问题)?

    • 预期的交付物是什么?深入分析和见解、数据驱动的决策、预测模型、数据产品、仪表板等?

    • 成功标准或 KPI 是什么(成功或改进的衡量标准是什么)?

    • 数据将来自哪里?

    • 我们是否有权使用这些数据?

    • 如何确保数据质量?记住,垃圾进,垃圾出。这对目标变量尤为重要。

    • 应该开发哪些 ETL 过程?

    • 结果将如何使用?例如:更好的定位和减少联系次数、节省费用、额外收入、识别新线索等。

    • 结果影响了哪些组织单位?(考虑 RACI 模型:负责、问责、咨询、告知。)

    • 假设模型已经准备好,是否存在潜在的部署/利用限制?

    • 利用模型/结果需要哪些能力?

    • 会影响到哪些流程和系统?

    • 一切准备好以利用模型/结果了吗?如果没有,还缺少什么?

    • 是否存在模型/结果利用的潜在障碍?如果有,解决这些障碍的计划是什么?

    • 谁将确保基础设施支持端到端的客户体验?

    • 解决方案的运行频率是多少(实时、每日、每周、每月等)?

    • 谁将维护、支持和服务解决方案?

  33. 不要用大量的信息、图表、数字、流行词汇和废话轰炸你的客户。保持简洁明了(KISS)。如果所需的结果是深入分析,尽量将自己限制在 3 个可操作的见解。我强烈建议进一步提升,并提供有见地的行动建议。请注意,这两者之间有很大的区别;前者只是一些见解/想法,而后者则涉及行动/执行(请参见第 17 条——想法是商品,执行不是。)。不过,请始终与运营和业务人员咨询,以了解你的行动建议的有效性和影响。

  34. 从简单开始,迅速交付解决方案,然后再添加功能并增强你的解决方案。这就是软件工程中所说的最小可行产品(MVP)。交付一个没有任何机器学习但在第一天/周/月中在很大程度上满足客户需求的有效解决方案并无害——这取决于请求和环境的复杂性。如果需要,你可以在之后添加机器学习来使其更智能——请参见#21。

  35. 预测很简单,但创造业务影响很困难。让我们用一个具体的例子来解释这一点;然而,这个想法是可以普遍适用的。我以客户保留为例。业务问题是我们想要增加客户在公司停留和消费的生命周期。我们可以从这个用例中定义出许多分析问题。为了简单起见,我只关注流失率。我们需要首先预测哪些客户可能会流失,然后定义一些保留活动以使他们留在公司并继续消费。虽然流失预测是一个具有挑战性的分析问题,但它是整个客户保留业务问题中最简单的部分。你建立了一个 AUC 为 0.85 的优秀模型,这非常好。你的模型在前 10%中创造了 60%的提升,因此你可以在前 10%的高风险客户中识别出 60%的真实流失者。你建议你的营销团队用营销活动来针对前 10%。一个月后,你会发现流失率增加了!是的,预测很简单,保留很困难。你可能已经唤醒了“沉睡的狗”。你可能需要使用更先进的技术,如响应建模和提升建模来识别可说服者(更多内容将在未来的帖子中讨论)。此外,你需要与营销团队合作,深入了解业务背景、客户需求等。记住:预测很简单,创造业务影响很困难。

  36. 数据科学(和/或 AI)可能大部分时间都是无聊的——如果你只喜欢机器学习的部分。人们可能认为我们 AI 专家会坐在一个空旷的房间里,享受美丽的视野,思考人类的未来。然而,现实却大相径庭。我们必须应对不切实际的期望、不明确的需求、脏乱和分散的数据,以及不断改变问题和请求的客户,并期望昨天得到答案。我们都听说过数据科学家 80%的时间都花在数据清理上。这可能仅适用于技术部分。在完整的背景中(详见#32),技术方面的时间不会超过项目时间的 50%。根据我的经验,模型训练和调整不会超过项目时间的 2-3%。所以,如果这是你唯一喜欢的部分,你可能需要考虑换工作。更好的选择是尝试享受工作的每一个方面。

  37. 什么时候使用机器学习?第 21 点认为“在很多情况下,一个简单的业务规则(在 SQL 中使用 if else 或 CASE WHEN)就可以完成工作”。所以,问题是什么时候使用机器学习,什么时候使用业务规则?答案在于传统编程和机器学习之间的区别。在传统编程中,我们有“数据”和“逻辑”(作为逻辑编码的领域知识)作为系统的输入,而输出是“标记数据”(或一个动作或一个决策)。你的输出质量是输入数据和编码逻辑的质量及复杂性的函数,这通常由领域专家定义。然而,在机器学习中,我们有“数据”和“标记数据”作为输入,而逻辑(由算法识别的数据中的模式)是系统的输出,称为“模型”。因此,如果你有良好的历史数据和标记输出,你可以从机器学习中获益。否则,业务规则将是更好的起点,可以收集“数据”和“标记数据”。在收集到足够的“标记数据”后,你可以使用机器学习来识别更复杂的模式,实现更好的预测性能。

  38. 为了更好的业务表现,牺牲模型的表现。第 28 和第 29 点已经讨论了数据泄露和模型表现。这里的重点略有不同。在预测建模和机器学习中,当我们进行特征工程和特征选择时,我们必须考虑很多问题。其中最棘手的问题之一是:虽然包含一个特征可能会改善模型表现(即使没有造成数据泄露),但它可能会降低模型的业务影响。例如,假设我们正在建模 XXX 产品的交叉销售用例。拥有像“收到的 XXX 营销活动数量”这样的特征很可能会提高模型表现,但它会优先考虑那些已经收到活动的客户,这并不是业务所希望的。为了更好的业务表现,牺牲模型的表现(AUC,再次强调!)是更明智的选择,而不是反过来。

  39. 每天学习——成为一个学习机器。


我们的前三大课程推荐

1. Google 网络安全证书 - 快速进入网络安全职业的快车道。

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

3. Google IT 支持专业证书 - 支持你所在组织的 IT 工作。


简历:Saeed Hajebi 是沃达丰大数据与人工智能部门的负责人。

原文。经授权转载。

相关:

  • 加速 Python 数据分析的 10 个简单技巧

  • 调试神经网络的检查清单

  • Kaggle 上的优秀特征构建技巧和窍门

更多主题内容