“在ML的模糊成功标准米奥德尔”实施的ML模型来提高客户的满意。您如何定义“幸福”？相反，应将重点放在可配对且对预期结果敏感的最配对的下降指标上。幸福的中间或代理指标可以是完成重复工作流（例如在会计软件中创建发票）所花费的时间，也可以是共享引荐链接的次数。
“即使我们拥有完美的模型，也不知道如何在现有工作流程中使用它”这很普遍。我们更多地专注于从数据到洞察力，而错过了从洞察力到结果的最后一英里。仅简单地预测客户流失没有多大价值，直到将其应用于客户成功过程以主动接触并管理这些客户。
“建立％准确的模型-无法在可接受的权衡因素（例如精确度和召回率）上弄清楚”ML模型通常被认为是“魔术”。如果您有一个模型来预测可能患有心脏病的患者，那么您正在优化的是：精确度或召回率。在此示例中，使误报率最小化的高召回率比使误报率最小化更为重要。
“用锤子杀死蚂蚁-不检查简单替代方案的性能”随着ML的嗡嗡声，通常忽略了简单替代方案或启发式模型。我看到了一些示例，其中现有的启发式方法满足了99％的成功指标，但是仍然需要构建ML模型。此外，在考虑ML模型时，还应考虑使用HumaninLoop替代方案。
“并非所有的机器学习问题都值得解决-影响可能不值得付出努力”要交付在生产环境中部署的，经过良好调整的健壮的机器学习模型，视复杂性而定，可能需要6到24个月不等。明确项目的战略价值至关重要。
“使业务团队陷入技术巨无霸”的讨论中，对AUC或规范化的熵的讨论对业务用户几乎没有价值。相反，要花时间解释其重要性以及在业务结果或成功标准的背景下这些含义的含义。
“低估项目成本-忽略数据成本”ML取决于数据-获取和标记数据需要庞大的团队。数据集维护成本很高。数据成本通常在项目成本中被忽略，并且还可能导致错误的裁员决策。
“将AI道德作为一种必备品”将道德作为软件设计考虑因素和政策考虑因素，这一点很重要。在ML管道的各个方面，评估与团队价值观相符的道德考量-从数据收集到决策制定，再到绩效和有效性的验证和监视。
“在项目制定过程中不利用过去的指标”在最初的项目制定阶段，我经常看到业务，工程和数据团队在资源分配，里程碑和时间表方面存在失调。通常，过去类似项目的数据科学家和项目经理会在此决策中缺失，从而使决策由猜测来驱动，而不是利用数据指标。
“无法管理利益相关者的期望”通常，基于对数据可用性，数据质量，业务工作流程，团队资源，端到端产品部署的了解很少，机器学习项目往往以不切实际的高期望开始。从用户体验的角度来看，很少使业务涉众了解错误预测的风险和成本。
“没有定义杀死项目的标准”通常，在数据和业务问题中发现了根本的空白。即使有足够的证据，也没有定义明确的标准来终止项目。相反，应该鼓励团队将项目“搁置”，并提供清晰的文档，说明何时审查项目（例如，一段时间内何时收集某些数据属性）。部分项目可以提供有价值的经验教训，这些经验教训可以应用于其他当前或将来的项目中
“没有为适当的ML项目复杂性做准备”就培训，部署，维护而言，并非所有ML项目都具有相同的复杂性。判断复杂度的一种方法是训练和推理是在线还是离线。离线训练和离线推理模型是最简单的ML模型。在线培训的模型刷新时间窗口有所不同，从几周到几分钟不等。在线培训和在线推理的模型需要非常强大的ML管道以及漂移监控和警报功能。
“不分解问题”大多数解决方案不是将业务问题视为一个单一的ML模型，而是涉及使用一系列模型和方法。
“永久优化模型”改进模型可能是无休止的努力。改进模型的资源要付出机会成本，因为它们没有在其他项目上工作。一种有用的策略是限制资源的数量，并在一个有时间限制的窗口结束时评估项目的状态。在评估中，您可以决定分配另一组有时间限制的资源，或者声明结果目前足够好。通常，只有在看到牵引力时才分配其他资源增量。
“假设可用数据的PB==成功的ML项目”在计划过程中，业务利益相关者将大量数据的事实作为可以建立准确的ML模型的代理。数据的大小并不能保证成功的机器学习项目-数据质量，数据事实缺失，我们要建模的事实的不完整表示以及其他几个方面决定了项目的命运。
数据集制作问题“我认为此数据集属性还具有其他含义”数据属性通常从不记录。在大数据时代之前，先对数据进行整理，然后再将其添加到中央数据仓库中。这称为写模式。如今，使用数据湖的方法是首先聚合数据，然后在使用时推断数据的含义。这称为读取架构。
“同一业务度量标准存在5个定义，供您使用。”派生数据或度量标准可以有多个真实和业务定义源。例如，即使诸如“新客户”之类的基本指标也具有多个定义，这些定义对应于将客户限定为新客户的条件。
“我的模型需要哪里的数据集？”考虑到数据的孤立性，多个团队将对不同的数据集进行管理和分类。数据团队中有关数据集和相应联系人的许多部落知识。
“数据仓库已过时”将原始数据复制到DataLake中，然后将其复制到DataWarehouse中。给定ETL管道错误，仓库中的业务指标可能会过时并且无法及时刷新。
“需要的仪器的详细点击流活动的应用程序-这将需要几个月的时间”添加标管理仪表-在更多细节博客。
“假设所有数据集都具有相同的质量”这是一个经典错误。并非所有数据集都是可靠的。其中一些由源团队非常紧密地更新和管理，而其他数据集则被放弃或不定期更新或具有不稳定的ETL管道。
“客户更改了首选项，以不将其数据用于ML。为什么仍保留这些记录？“数据权限现在变得至关重要。它是跟踪和执行的重要过程ML模型培训和再培训。
“数据源处的模式变更不协调”非常普遍，源头处的模式变更与下游处理不协调。更改的范围从架构更改（破坏现有管道）到难以检测到数据属性的语义更改。此外，当业务指标发生变化时，将缺少定义的版本控制。
“不对输入数据进行单元测试”在传统的软件开发项目中，最佳实践是编写单元测试以验证代码依赖性。在ML项目中，应采用类似的最佳做法来连续测试，验证和监视您的输入数据。
“当心有偏见的数据集”从统计的角度来看，数据集并没有捕捉到最终的真理。它们仅捕获应用程序所有者当时针对其用例所需的属性。分析数据集的偏差和掉落数据很重要。了解数据集的上下文是超临界的。
“让数据集变成没有管理者的孤儿”如果无法理解数据集，它们将毫无用处。试图对列的含义进行逆向工程通常是一场“失败的战斗”。关键是积极记录数据集属性详细信息，并确保有一个数据管家负责数据集更新和发展文档详细信息。资料准备
“不要忘记数据过期了吗？”数据有有效期限。十年前的客户行为记录可能不具有代表性。此外，确保数据是用于模型训练的IID（独立且完全相同），并考虑到数据的季节性。
“使整体数据集产生偏差的系统性数据问题”如果数据集中的错误是随机的，则对模型训练的危害较小。但是，如果存在这样的错误，即系统地丢失了特定的行或列，则可能导致数据集中的偏差。例如，由于错误，Andriod用户缺少客户点击的设备详细信息，因此该数据集将因iPhone用户活动而产生偏差。
“数据中分布的突然变化没有引起注意”数据集在不断发展。数据分布分析不是仅在模型创建时就需要的一次性活动。相反，需要连续监视数据集的漂移，尤其是对于在线培训。
“将所有数据用于训练-每个模型迭代可能需要几天的时间”虽然更多的数据有助于建立准确的模型，但有时数据量巨大，拥有数十亿条记录。在更大的数据集上进行训练需要时间和资源。每次培训迭代都需要更长的时间，从而减慢了整个项目的完成速度。需要有效地使用数据采样。31.“我们正在使用最好的多语种数据存储-但是，现在如何有效地对这些数据编写查询？”没有“灵丹妙药”数据存储。通常，多语言持久性与专门的数据存储一起使用，用于键值，文档，图形，时间序列数据等。异构性可提供最佳性能，而数据团队则具有学习曲线，可以有效地构建管道来分析和联接跨数据存储的数据。
“忽略销售或客户行为数据的季节性”在使用数据集之前，请验证iid，平稳（随时间而变化）的属性，并确保在训练和测试过程中分布相同。经常错过季节性，这是对平稳性的经典违反。
“在分割训练和测试数据之前不要随机化”很多时候，如果没有随机化，我们最终可能会在训练中得到所有秋季数据，而在测试中得到夏季数据。这可能会导致需要不必要的调试的损失时期图。低挂的水果经常被错过。
“测试示例在训练集中有重复项”通常，我们为真正的高精度数字感到兴奋。加倍检查通常表明测试集中的许多示例与训练集中的示例重复。在这种情况下，模型概括的度量是不确定的。
“不合格的测试集”确保测试集产生统计上有意义的结果，并代表整个数据集。
“使用标准化而不是标准化来缩放要素值”要使要素达到相同的比例，请在数据均匀分布时使用标准化（MinMaxScaler），在要素近似为高斯时使用标准化（StandardScaler）。
“异常值的处理不当”基于此问题，异常值可能是忽略的噪声，也可能是重要的考虑因素。通常由收集错误引起的异常值可以忽略。机器学习算法对异常值的敏感性有所不同-与XgBoost相比，AdaBoost对异常值的敏感性更高，而XgBoost则比决策树（将简单地将异常值视为错误分类的决策树）更为敏感。正确处理离群值需要了解是否可以忽略它们，并根据敏感度选择适当的算法。
“在大型数据集中选择任意样本”对于非常大的数据集，采样通常是任意的。要特别注意利用重要性抽样之类的技术。ML模型设计
“在过渡到非线性模型之前充分利用特征交叉”线性学习器可很好地扩展以获取海量数据，并且更易于维护。对于本质上不是线性的问题，我已经将特征交叉视为解决多个问题的有效方法，即，当数据在输入空间中不可线性分离时，添加交叉特征对于海量输入数据集尤其有效。
“模型精度太高，难以置信-检查特征泄漏”不正确的特征值可能会导致特征泄漏-有关详细信息的博客。41.“依靠不稳定的流水线来生成时间相关的特征”诸如“到目前为止的产品视图”之类的时间相关的特征需要低延迟的健壮流水线来计算值。通常，很难在整体模型行为的上下文中调试这些管道中的错误。
“偏差（拟合不足）和方差（拟合过度）之间缺乏平衡”提防简化的模型将数据（偏倚）拟合到复杂的高维模型的另一个极端，并且对数据的微小变化敏感（方差）。为了在生产中建立有效的模型，需要取得适当的平衡。
“过早地降低性能的可解释性”ML计划过早地推进应用深度学习。在ML项目的早期迭代中，可解释的模型比执行黑匣子的模型更为重要。可解释的模型有助于生成有关特征和数据属性的下一组假设。关键是要从简单的模型开始而不是过早地进行优化。更简单的模型更易于调试和迭代。
“添加新功能而没有理由说明它们如何提高模型质量”添加编码新信息的功能将提高模型性能，但以增加模型复杂性（以及测试，部署，维护相应ML功能的复杂性为代价）管道）。添加到模型中的新功能应使用相关矩阵来证明，或训练模型并分析具有或不具有功能的结果。用软件工程术语来说，在模型执行合理之后添加新功能应被视为“代码冻结阶段”，并仔细检查每个功能更改。
“跳过特征缩放”如果不进行特征缩放，则模型会过多