在线模型需要大量的工程设计工作，并通过推荐用于个性化客户体验

基于项目需求了解使用哪种模型至关重要，因为它不仅决定了部署过程，而且还影响了模型的训练方式，在本文中，我将讨论在实时生产应用程序中部署个在线机器学习模型时我们面临的一些挑战，以及我们如何应对这些挑战，当我们开始创建模型时，我们很少考虑将模型实际部署到我们的应用程序中，我们在笔记本中构建了模型，该笔记本从数据仓库中加载了干净的数据模型，转换了各个列，并生成了一个模型。尽管这种方法在快速迭代和实验中非常有效，但在部署过程中却带来了一些困难，尤其是在特征提取，特征转换和可伸缩性方面。相反，我们需要找到一种方法来准确地执行这些操作，同时具有足够的可伸缩性和灵活性，以供将来的部署重复使用。有了更多的远见，我们可以大大减少将模型从笔记本电脑转移到已部署的应用程序所需的工程工作量。

业界普遍认为，数据科学家应该期望花费至少80％的时间来准备数据

这是因为创建良好的训练数据集通常需要我们从多个原始数据源中收集数据，然后使用该数据来创建可能可以预测目标变量的新功能，我们拥有一支非常有才能的CPDA数据分析师团队，他们已经从原始数据中构建了复杂的数据模型，以便跟踪我们的业务目标，我们发现，这些预先转换的功能对于建模至关重要，虽然可能很想直接导出数据模型以用于预测建模（我们一开始就对此感到内!！），但跳过预转换的功能可能会给部署到实时应用程序带来严峻的挑战。

出于报告目的而限制在数据仓库中的数据模型已经过优化，可以按可预测的节奏在大量数据上运行

这从根本上不同于应在生产机器学习应用程序中进行特征提取的方式，我们发现，我们需要以不可预测的节奏从少量数据中提取特征，这意味着我们不能按原样使用数据模型，此外，我们发现我们需要复制特征提取以满足Python（而不是SQL）中的不同需求，这是因为我们的部署模型无法接收数据模型提供的表格格式的数据，Python为我们提供了以易于维护的方式解析半结构化数据所必需的工具。

特征转换是训练数据集特征工程中的另一个重要步骤

除其他过程外，这可能包括缺失值插补，合并和一键编码，特征转换特别棘手，因为生产数据是不可预测的，例如训练数据中可能有一列没有缺失数据，因此训练数据不会为该列估算缺失值。但是，这并不一定意味着该字段永远不会缺少值，忽略这种极端情况可能意味着在情况下会出现错误或延迟，或者在坏的情况下可能导致模型中的无形错误，当我们意识到这一点。

首先我们使用了不同的熊猫方法来执行这些操作

但是我们很快发现，在部署时，这些方法无法满足我们的需求，例如，大熊猫具有一种称为“获取假人”的方法，该方法对于单次热编码非常有用，但只能用于训练数据，因为它需要了解要素的所有可能类别。在一个实时环境中，一次只记录一条记录的这种情况下，该方法将只知道一个可能的类别，这意味着一键编码的列将无法反映我们需要的适当类别。

解决这一问题的解决方案模型，即使他们是稍微用户友好的少

API允许以与训练和应用预测模型相同的方式来训练和应用这些功能转换，这样可以“记住”来自训练数据的知识，使用这样的模型要求我们像对待模型本身一样对待特征转换：每个特征转换都在训练数据上进行训练，腌制，然后与我们的模型一起部署。

尽管我们能够在短期内克服这些挑战

但是很明显，我们需要从根本上重新考虑要素工程基础架构，同时要牢记两个思想，功能工程应专门从运行时可用的数据开始，我们对这一基础架构的愿景是功能存储，在这种情况下，功能存储是一个集中式数据库，用于从应用程序生成的原始数据中整理机器学习就绪的功能，功能存储不仅需要维护数据本身，还需要维护用于创建数据的逻辑，这样它可以通过我们的生产模型实时转换原始数据，通过集中特征创建过程，我们确保了训练模型和生产模型之间的特征一致性，同时减少了部署所需的工程资源。