一步一步地，从想法到生产
通往完整的数据管道的道路是漫长而曲折的。照片：Rodion KutsaevonUnsplash
人工智能市场正处于增长阶段。技术堆栈正在成熟，建模 和工程方面的流程正在形成。作为一名数据科学家/工程师，这确实是一个美妙的时刻：乘着早期的浪潮，协助创建其他人将在未来几十年内遵循的模式。每个人都在想出他们自己的解决方案来部署他们的ML功能。
这篇文章的目的是对我们的项目流程进行演练，重点是数据科学/工程流程，并有一个直接来自烤箱的真实例子。我们希望你能挑选一些我们使用的技术，并将它们整合到你自己的团队中去
蓝图
在进入之前，我们需要讨论这个过程本身。在实施人工智能项目的过程中，有三个主要的能力层。数据科学、数据工程和前端。
我们的人工智能特征过程的蓝图。图片由作者提供。
一切都从一个想法开始。公司里有人有了灵感，这个火花被写进了一份文件，用通俗的语言简历了它。数据科学团队将该文件汇编成一个摘要，说明我们如何处理该问题并执行它。我们的前端团队可以开始创建模拟模型 ，让我们的利益相关者尝尝这个抽象的功能会是什么样子。这条捷径使证明该功能的影响变得更加容易。
然后，摘要被用作临时分析的基础，自由式建模，以测试和证明抽象的想法有价值。Jupyter和Excel表格比比皆是。在这个阶段，没有什么是一成不变的，也没有什么是正确的设计，因为自由是处理ML时创新的关键。
如果临时分析是成功的，我们就进入概念证明阶段。这是对前一阶段发现的解决方案进行工程化的第一步：一个尽可能接近于具有适当封装和质量的生产代码的代码。它可以被认为是我们管道内模型的试驾，调整后视镜和座椅的角度。在这一过程中，我们的数据工程团队开始绘制它在我们当前架构中的样子，计划PoC如何进入我们的管道。
随着概念验证的正确测试和评估，我们让数据科学团队在其他项目上工作。现在，数据工程部将开始将PoC整合到管道中，而前端团队可以使用PoC的输出来创建一个真实数据原型。
两个团队都准备好了，是时候把所有东西整合到最终产品中了。我们用一个生产原型进行测试，然后通过逐步淘汰旧版本来确认。瞧。
现在，让我们看看这个过程是如何在一个新的命名实体识别功能上发挥作用的吧
这个想法
我们Dashboard的基本模块之一是方面分析。我们从非结构化的用户生成的文本内容中提取代表产品或服务属性的实体，从句子中提取它们的相对情感，并使用我们的自定义分类法将它们汇总。
方面术语 "崩溃 "和 "视频 "被提取为方面，然后被分类为负面。与问题相关的术语通常是负面的。图片由作者提供。
这种类型的分析是非常细化的：方面通常由1-3个标示物组成。我们没有得到一个问题的完整背景：我们提取了问题的核心**（崩溃**）和原因的根源**（视频**）。
所以，解决方案是一次性识别和提取整个事情。
提取整个子句。图片由作者提供。
有了这个想法，我们创建一个摘要，列出我们可以采取的可能路径。我们目前的摘要写作策略使用RFC结构作为指导我们开发过程的方式。如果你熟悉史诗/故事/任务的抽象，你可以把它比作一部史诗，增加对详细描述和冗长解释的重视。
我们的一个RFC的标题。摘要由多个队友审核，人们在文本中发表评论，内容随着异步输入不断发展。图片由作者提供。
我们的RFC有一个特定的结构。
- 要解决的问题的背景 。
- 问题定义。
- 建议的解决方案 与架构/模型建议**。**
- 已解决的问题的成本和效益 。
- 对成功的定义，以及对RFC实施结束后产生的工件的描述。
这个具体想法的（非常）简短的RFC看起来像这样。
背景：方面太细，无法识别关于具体问题的背景短语。
目标：从句子中提取问题（代表用户在使用产品时遇到的问题的多标记字符串）。
可能的解决方案：使用spacy | Tensorflow | PyTorch、gensim Phraser和分类器进行自定义NER，通过语法分析找到问题的根源。
成本和收益： 一个月的模型开发，另一个月用于管道整合和原型开发。两名数据科学家，一名工程师和一名前端开发人员。
成功的定义：问题提取器集成到管道中，分析结果显示在最终产品中。
验证标准
有了目标，我们就开始计划如何达到目标。我们如何知道我们在项目进行到一半的时候已经 "足够好 "了？或者说 "到达那里 "是否真的可行？像这样的探索性任务可能需要几个月的来回互动，测试新的想法，提出新的问题和新的解决方案......突然间，你陷入了一个循环，你甚至忘记了项目的意义是什么。
设定一个停止探索问题并继续前进的最后期限是非常必要的。在这个想法探索阶段之后，我们应该对我们需要考虑的变量有一个很好的把握。我们需要标记的数据吗？有多少？是否有我们可以使用的实施模型？类似项目的性能是怎样的？
验证阶段是RFC创建过程的一部分：在进入ML模型的细枝末节之前，作者必须考虑项目的最后期限和对 "完成 "的定义 。一个简单的时间框架将帮助团队相应地安排任务，而对交付的定义将指导你的工作。
我们在这里做的是以产品为中心的交付：我们对成功的定义是_将问题提取器集成到我们目前的管道中，并在最终产品中显示分析结果_。没有准确性，没有指标，没有花哨的东西。这意味着我们对架构本身的创建感兴趣，而不是加强一个模型。
下面是关于数据项目管理的一个有趣的阅读链接。最佳Scrum实践 部分有一些关于项目边界的信息。
2021年的数据科学项目管理[ML团队的新指南] - neptune.ai
临时建模
自由式建模：只需一块（键）板和一个梦想。图片：Jacob BentzingeronUnsplash
RFC被批准了，我们要去开发地了。第一站是_临时建模_：在我们通常的架构之外的建模工作，可以用任何可用的工具来快速提供可触摸的结果。对一些公司来说，这就是通常的数据科学工作的范围，由软件和数据工程师来实施。
我们正在采用OSEMN框架来管理这一步的流程。获取、擦洗、探索、建模、iNterpret。这个特别分析的产出将是一个问题提取模型，并附有一份关于提高其准确性和召回率的可能方法的报告。
让我们在我们项目的背景下讨论这些阶段。
- 获得： 我们的输入是用户生成的数据。由于我们已经有了一个来自电子商业的用户评论数据库，我们不需要从原始信息中获取......但我们确实需要对句子进行人工标注，以找到问题子串。要做到这一点，我们采用 神童 作为我们的标签工具，并定义一组将被注释的评论来生成我们的训练数据集。
Prodigy命名的实体注释器。注意实体之间的重叠：一个问题可能涉及一个产品特征。图片由作者提供。
- 刷洗：由于我们的数据在注释之前已经被适当地刷洗过了，所以我们在这里不需要做太多。我们可以将我们的数据集一分为二，按类型将实体分开，或者使用某种相似性测量方法将过于相似的句子丢弃。
- 探索：我们正在深入研究数据，将注释的句子与自动EDA一起手动分析。在我们的数据集中，最简单的（也是最重要的）衡量标准是按实体类型划分的平均令牌数：这个指标显示了实体的语义复杂性。它将是我们任务难度的一个代理指标。
我们选择的探索性指标。请注意，Issues的令牌数很高，而Retailer和Person实体的出现率很低。图片由作者提供。
- 模型：我们需要用命名实体识别器来提取具有5个以上标记的问题实体 。为了做到这一点，我们采用了spaCy EntityRecognizer模型，该模型是用我们之前注释的数据训练出来的。这个分类器的骨干是en_core_web_trf预训练的模型，一个基于RoBERTa的转化器。
只需将你的数据输入训练脚本，并改变配置以训练一个自定义的spoCy管道。来源。
模型分析
呜呜。经过所有这些步骤，我们终于有了一个工作的NER模型。现在，让我们看看这些指标
哦......有点低，不是吗？0.15的F1分数真是令人沮丧。图片由作者提供。
指标低得可怕。分数与每类实体的平均令牌数呈负相关。问题和积极体验（POS_EXP）是具有最高令牌数和最低分数的实体。
但我们从Issue的提取结果中看到了有趣的词云。很明显，_有些东西_被提取出来了，但是我们的指标并没有感知到这个价值。
笔记本电脑评论的问题词云。这里有很多有用的信息：重启、无反应、关闭。
问题提取器的问题不在于模型，而在于评估：正常的评分方法依赖于严格的匹配，其中提取的实体必须与注释的实体相同。这意味着下面的提取会被认为是完全失败的。
句子。笔记本开始不断重启。
注释：开始不断重启
提取：不断重启
"不断重启"这个粒子是问题的核心。即使我们没有这个实体的完整上下文，我们仍然可以挽回它!我们会知道，许多评论都引用了 "重启"这个关键词，帮助生产该特定笔记本电脑的品牌识别这个问题。
因此，我们需要将我们的衡量标准从严格转向部分，使部分匹配计入总分，与它们与注释实体的相似度成正比。
现在情况好多了，从0.15到0.40。虽然不是最好的，但也是可行的
这里的寓意是，度量标准是讲故事的。有时候，一个指标向你描述的故事并不是数据想要讲述的故事。对模型输出的临床分析总是很重要的，而且不应该被忽视。
有时，即使是一个被认为是_破损的_ 模型也能为你的客户提供巨大的价值。
建筑规划
图片由作者提供。
专案分析阶段得出的结论是，这个功能是有前途的。这将会以某种方式出现在最终产品中，由工程团队来组织新铸就的NER模型将以何种方式整合到我们目前的架构中。我们不是在等待数据科学团队的另一次迭代来提高分数：讨论从建立基线的那一刻开始。在具体化之前，任何概念的证明都不会有影响!
一个新功能的架构应该遵守这三个原则。
- 首先，它必须有足够的模块化 ，以便可以轻松地进行升级。如果你以类似于微服务的方式整合数据充实管道，并在数据实体之间保持合理的分离，就可以做到这一点。
- 其次，它应该符合 之前的架构决策。只有在绝对需要的情况下，新功能才应该引入新的架构格式，我们在这里的目的是减少复杂性和不确定性。
- 第三，它应该说明一些基本的可观察性 指标。在一个新的部署所产生的不断扩大的TODO列表中，很容易失去对可观察性的跟踪。在项目的早期阶段，适当的日志和度量标准更容易准备。
本质上，这就是MLOps：引导模型从概念到生产的一套良好实践。
所以，回到退出计划。在birdie.ai，我们有一些预先存在的架构来运行我们的数据充实过程，大量使用AWS基础设施。我们需要选择其中的一个脚手架来执行新的模型。
AWS Lambda + Step Function数据处理管道。图片由作者提供。
第一种模式涉及AWS Lambdas和Step Function，用不需要重型机器的丰富功能来处理大量的数据。一个Ignition函数从Athena数据库中检索数据并将其发送到一个队列中。这个队列被一个单独的步骤函数或Kubernetes服务消耗，通过带有Parquet压缩和适当Hive分区的Firehose流将结果发送到S3。结果可以使用Athena表进行探索。Lambdas通过Cloudwatch日志得到严格的控制，字典里有关于每个Lambda/Step Function执行的格式化信息。
问题是，我们使用的是转化器模型。我们将需要GPU驱动的机器，而Lambda并不适合。Kubernetes服务将与云无关，并允许我们使用GPU机器，但我们需要更多的努力来为这种方法带来可观察性：也许将一个Kubernetes专家带到公司，或者花一些时间来开发一些基本的集群性能分析。
来自S3触发管道的AWS Batch Job。图片由作者提供。
我们的第二个模式依赖于AWS Batch作业被S3文件插入所触发。每当一个Parquet文件进入S3桶，一个Batch作业就会被触发，以读取该文件并运行某种类型的处理行，并将结果反复存入Firehose流中。这个管道的简单性被脚本的复杂性所抵消：Batch作业必须适当地进行多处理，以使用机器的所有处理能力。
它整齐地符合我们的需求!AWS的Batch作业可以为我们的功能带来GPU的全部力量，而不会给我们目前的管道增加太多的复杂性，我们的一个方面提取管道使用SpaCy命名实体识别模型来从评论中提取产品属性。我们可以重新利用它来使用新的问题提取模型。
我们的游戏计划现在的方向是重新调整我们之前的一个管道来执行问题提取。这意味着，如果数据科学团队提供一个经过测试的、可扩展的推理代码，开发时间将从几天缩短到_几个小时_ 。
前端原型
现在，我们有了一个模型和架构，以可扩展、可观察的方式提供这些推理......但如何向客户展示这一功能？
在birdie.ai，我们对用户生成的内容的洞察力是由网络仪表盘提供的。这些仪表盘由一组不同的开发人员管理，他们由数据分析师和前端工程师组成，不在数据科学家和工程师的手中。
这并不是说数据和产品之间存在着不可逾越的鸿沟，因为我们参与了产品发现、影响和价值的讨论：我们被从后端和前端应用开发中分离出来，专注于数据结构。
数据科学小队的重点随着公司的目标而转移。图片由作者提供。
有些产品和公司不需要前端，直接从数据分析师收集的报告中提供洞察力。在这些情况下，数据小组可能需要做仪表板，并测量与用户有关的指标。你可以说这些公司是_前端的_。相比之下，那些更专注于数据采集、充实和架构的公司是_后负荷_的。
我们能够使用Tableau建立一个与我们的产品分析仪表盘相连的工作原型。将Tableau仪表盘连接到HTML页面上真的很容易。
使用Tableau的原型问题浏览器。我们建立了一个问题类型的层次结构，可以进行多层次的分析：图像质量组 包括艺术模式、亮度差和颜色组；亮度差包括所有引用亮度或太暗的问题。图片由作者提供。
这些是从特定品牌的电视评论中提取的问题，我们已经可以看到关于音频、亮度和内置应用商店的投诉。这是我们评论库中的一小部分，范围是数以亿计的。我们期望这将是营销分析师的一个方便的温度计，给他们提供用户最强烈的问题。
该功能在我们有能力的前端工程师和他们的HTML魔法手中。数据科学团队正在努力升级我们的NER模型，工程团队正在处理管道指标。我们正处于管道的最后一步：交付完全集成的功能。很高兴看到一个想法从头到尾被执行，并得到客户的反馈和关注。
我们希望这次通过我们的方法论的旅行可以帮助你在你的数据旅程中!
