关于MLOps中的数据工程，你一定要知道的.......
Posted 狐狸的帽子
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了关于MLOps中的数据工程，你一定要知道的.......相关的知识，希望对你有一定的参考价值。
关于MLOps中的数据工程，你一定要知道的.......
背景：
21世纪以来，以Hadoop、Spark、Hive为代表的大数据工具，和以Google Cloud、AWS、阿里云、华为云等为代表的公共云奠定了当今数据生态系统的基础。随着海量数据处理工具集的发展以及数据源和数据格式在种类和规模上的不断增长，数据工程越来越成为一门多技术综合应用的学科，用以实现最终业务目标。
数据工程是什么：
数据工程是关注数据的流向和访问的机制，原始数据从源系统引入、存储和处理，生成高质量、符合标准的数据，转为下游人员可用的数据形式，如数据科学家、数据分析师等。数据工程师致力于构建自动化和规模化的数据处理管道，保障下游业务分析和决策的流畅进行。
MLOps中的数据工程有哪些看点？
比起普通的数据工程，MLOps（机器学习开发运营一体化）中的数据工程更加聚焦于为机器学习模型的开发做准备，它是MLOps开发管理流程的重要一环，其目标是为后续模型开发及最终决策提供高质量的数据。MLOps数据工程架构图如下图所示，从外部或内部系统生成的数据作为数据工程的输入，需经过数据收集、数据探索、数据处理和特征工程一系列的步骤。数据管理和Pipeline编排作为暗线贯穿了数据工程始终。数据工程的输出可以直接提供给下游的传统机器学习任务（如SVM、决策树、逻辑回归等）和深度学习任务（如人脸识别、图像分割、智能对话、机器翻译等）使用。
1.数据收集
数据收集是指从分散的来源中提取、集成和组织数据。数据收集主要分为两种类型：流式处理数据与批处理数据。实际上，我们处理的所有数据本质上都是流式的，数据几乎总是在其源头不断生成和更新。流式处理使我们能够以连续、实时的方式向下游系统（无论是其他应用程序、数据库还是数据分析系统）提供数据。批处理数据要么按预定的时间间隔引入，要么在数据达到预设大小阈值时引入。批处理数据是一种以块状形式处理数据流的专用且便利的方法，例如在单个批处理中处理全天的数据。
2.数据探索
数据探索是在不改动数据本身的前提下，挖掘数据的统计信息，通过可视化的方式展现数据中隐含的规律和特质。数据探索主要包括三个方面：整体分析、统计描述和相关分析。
（1）整体分析：需要检查数据集的数量、完整度，确认数据质量是否存在问题（缺失值、重复值、错误值、异常值），判断样本是否平衡。
（2）统计描述：采用描述性统计的方式刻画数据分布的集中趋势（均值、中位数、众数等）、离散趋势（方差、标准差、极差等）和分布形状（偏度、峰度）。描述性统计中常用的可视化图表有直方图、箱线图、柱形图、茎叶图、折线图、条形图等。
（3）相关分析：考察不同变量之间的关系，分为连续变量与连续变量、离散变量与离散变量、连续变量与离散变量三种，有各自使用的量化指标和图表可视化方式。
3.数据处理
数据处理是指对数据进行清洗、转化和准备，使之可用。数据处理可以解决数据可能存在的质量问题（如异常、缺失、冗余等），将数据加工为模型开发能够直接使用的形式。数据处理主要包含三个部分：数据预处理、数据标注和数据版本管理。
（1）数据预处理：包含数据清洗、数据转换、数据增强、数据纠偏等操作。
·数据清洗包括检查数据一致性、数据去重、异常值检测、处理无效值和缺失值等。
·数据转换是指将数据进行转换,从而构成一个适合数据处理的描述形式，包含格式转换、数据重组（排序、合并、过滤）等。
·数据增强是指基于有限数据生成更多等价数据，丰富训练数据集的分布，提高模型泛化能力，如基于GAN的对抗样本生成、神经风格转换等。
·数据纠偏是针对数据不平衡的问题进行如上采样、下采样等数据纠偏操作。
（2）数据标注：对需要机器识别和分辨的数据贴上标签，是机器学习模型能够学习和准确预测的关键。数据标注通常包括图像标注、语音标注、文本标注、视频标注等类型，标记的基本形式有标注画框、3D画框、文本转录、图像打点、目标物体轮廓线等。
（3）数据版本管理：数据版本管理是对处理过程中的数据各版本进行管理，以实现数据的可追溯性。
4.特征工程
特征工程，目的是最大限度地从原始数据中提取特征以供算法和模型使用，从而获取更好的训练数据。
特征工程由特征预处理、特征提取、特征选择和特征压缩四个步骤组成。
（1）特征预处理包括特征过滤（反常值的平滑化）、特征无量纲化（标准化、归一化）、特征分箱、特征二值化等数据格式和范围的处理操作。
（2）特征提取是将原始特征转换为一组具有明显物理意义（如Gabor、几何特征[角点、不变量]、纹理
[LBP HOG]）或者统计意义的特征。
（3）特征选择是从步骤（2）的特征中挑选一组最具有统计意义的特征，主要的方法包括过滤法、封装法和嵌入法。
过滤法Filter：，按照发散性或者相关性对各个特征进行评分，设定阈值或者待选择阈值的个数，选择特征。
–方差选择法：计算各个特征方差，选择方差高于阈值的特征；
–相关系数法：计算各个特征对目标值的相关系数（如Pearson相关系数）和对应的P值，选择相关系数高于阈值的特征；
–互信息法：计算各个特征的信息增益，选择信息增益高于阈值的特征。
封装法Wrapper：通过递归的方式来消除特征。根据目标函数（通常是预测效果评分），每次选择若干特征，或者排除若干特征。
嵌入法Embedded：使用带惩罚项的某些机器学习算法（如随机森林、决策树）进行特征选择和模型训练，得到特征全集中各个特征的权值系数，根据系数从大到小选择特征。
(4)特征降维是在信息损失最少的情况下，用更少的特征代表原有数量庞大的特征，缓解维度灾难，减小运行时间，便于可视化。特征降维主要有主成分分析（PCA）和线性判别分析等方法。
PCA 是一种无监督的线性降维算法，利用正交变换对一系列可能相关的变量的观测值进行线性变换，从而投影为一系列线性不相关变量的值，这些不相关变量称为主成分。它的目标是通过某种线性投影，将数据映射到低维空间中，并期望映射后的数据方差尽可能大（数据分散开），从而保留更多的有用信息。
线性判别分析是一种有监督算法，它的目标是寻找一个投影矩阵，将数据投影到低维空间后，同一类数据尽可能紧凑，不同类数据尽可能分散。
5.暗线
数据工程的构建和实施是由数据管理、Pipeline编排构成的暗线贯穿的，它们跨越了数据工程生命周期的各个阶段。缺少这些暗线，数据工程生命周期的任何部分都无法正常运行。
（1）数据管理。这里的数据管理是广义范围的所有与数据相关的计划、统筹、实施和复盘的操作，它管理的是数据工程生命周期中的数据安全、数据存储、数据质量、数据流转、数据治理的方方面面，参见下方的数据管理金字塔图。而数据治理更侧重于组织全局范围内的制度体系、职责分配、责任边界划分、统筹规划、风险审计等，形成对于数据安全、数据存储、数据质量、数据流转的流程，发挥更大数据价值。
（2）Pipeline编排。Pipeline编排是指对流程中各步骤进行串联和标准化的管理机制，以加快执行速度，提高生产效率。Pipeline流水线的自动化执行程度充分反映了组织的人工智能研发技术和管理水平。
你一定要知道的关于Scrum的30个问题
1.敏捷Scrum如何开始？
为了成功实施Scrum，团队必须坚持Scrum的基本要素。
团队必须理解Scrum的规则
团队成员必须学习Scrum的基本机制
给予足够的时间
不要在项目中途实施Scrum
保证为持续学习分配时间
要知道Scrum是一个框架，提供的是一整套规则，而不是一个指南。
小婧以前觉得我可以把Scrum中的一部分拿来实施，其他的比如结对编程、重构等不纳入也就不纳入了。
近些年发现自己错了。
因为Scrum框架的各个部分是相互支撑的，如果你进行裁剪，不是倒塌就是变成了另外一个东西，不是Scrum了。
所以在实施Scrum的时候一定要先明确和学习Scrum的规则和机制。
2.如何自下而上实施？
取得大家的支持
耐心：让其他人领悟你已经理解的东西，找到其他人的动机
提供信息
大部分的Scrum都是自下而上实施的，也就是领导没有特别强硬的推行，而是团队内部觉得这种框架很合适，于是在自己团队内做尝试。
这个时候你就要特别注意，一定要及时的向外部，特别是领导层汇报项目的进展情况，使得信息透明。
3.资源冲突如何解决？
有的公司项目多，人力不足，特别是资深的经验丰富的人比较缺乏。
当一个项目出现问题时，大家都想要协调多的资源，特别是那种能够以一敌三的。
但是资源毕竟是有限的。
搞到最后就像是救火一般，哪里紧急就把资源派到哪里。
这样不仅打乱了项目团队的节奏（团队不稳定），而且也让这些资源疲于应对。
针对这样的情况，Scrum提议使用团队顾问。
也就是让员工自愿是否愿意作为顾问，服务所有团队。
这样的解决方案在实施时要特别注意：
依赖于管理层的支持
长时间在小范围内做尝试
选择核心团队，并决定需要哪些专家
小心团队顾问过度承诺
计划可能的空闲时间
顾问团队不应该替代专职团队，应该是一个核心的团队，辅以顾问团队。
4.如何确定团队的速率？
确定团队的速率一般有三种方法：历史数据、走着瞧、猜测。
对于组建的团队，熟悉的技术：优先选择历史数据，其次选择走着瞧，最后选择猜测
对于已组建的团队，不熟悉的技术：优先选择走着瞧，其次选择历史数据，最后选择猜测
对于新成立的团队，熟悉的技术；以及新成立的团队，不熟悉的技术：优先选择猜测，其次选择历史数据，最后选择走着瞧。其中历史数据可以，依赖于其他团队的历史数据。
5.Scrum的三大角色如何平衡？
Scrum的三大角色，包括关于Scrum Master，Product Owner以及团队成员。
很多公司会让一人身兼两职，甚至三职。
相较于让一个团队成员身兼数职，有一个专职的Scrum Master要好很多。
这样可以更好的保持三个角色所固有的检查与平衡。
虽然有人不赞成Scrum轮值，认为不够专注，但是我尝试过。
我个人觉得轮值可以提升团队成员的责任心。
6.如何确定Spring长度？
一般建议是1~4周。而长还是短是与项目、团队等多种因素决定的，各有利弊。
短周期的Sprint能使你更快地发现潜在的风险。
但其代价是团队得花更多的时间与客户互动，受到的干扰也更多一些。
可以尝试一周的sprint强制用户故事更小，让团队有更多机会来反映和纠正问题。
长周期的Spring，意味着需要更长的时间才能发现风险，但好处是互动干扰会少一些。
7.Sprint完成的标准？
制定并发布一个DoD。
这里面包括团队一致同意的内容清单。
比如：所有的Story都已经接受；对应的帮助文档已经更新……
这样一份DoD：
有助于团队成员建立密切联系
为项目干系人提供清楚的交流方式，间接降低了把技术债务推迟到项目后期的风险
使团队保持正确的方向，保持专注
8.Scrum Master到底做什么？
Scrum Master主要职责有：
消除障碍，解决问题
结束争论当团队的保姆
报告团队的行为表现
引导并在必要时提供帮助
教育组织并驱动组织变革
也许这也是为什么大部分人都建议Scrum Master要专职的原因吧。
别以为Scrum Master看着很轻松，其实一点儿也不。
要不你试试看？
9.真正的Scrum应该包含的实践有哪些？
我觉得如果下面这几点缺少了一个，就不能称之为Scrum了。
测试驱动开发TDD
首先写一个新的单元测试用例，但不写通过这个测试所需的代码；
然后写新的代码，使之刚好能够通过这个用例；
最后重构：重构在不改变，而是在已有意图和行为的情况下加强或改善其设计。外部行为保持不变，内部行为更流畅持续集成：团队成员频繁地集成他们的工作，通常每个人每天至少集成一次，这样每天就有多次机场。每次集成都通过一个自动化构建，包括测试来尽快检测错误。团队可在任何时间构建发布。
结对编程：一人驾驶一人导航，一起工作，共同完成一个任务。
自动化集成与验收测试：集成测试是用来测试系统中各种集成点，验收测试用来模拟用户行为的测试
10.团队成员工作时间不一致，如何处理？
现在很多公司为了提倡人性化，对于员工上班时间不做强制规定，也就是所谓的弹性制。
只要你每天工作满8个小时即可。
而这样对于Scrum却是个挑战。
如果团队没有办法保证一定的时间在一起办公，如何进行结对编程？如何开站会？如何进行有效沟通？
所以我们需要确保团队核心时间。
核心时间就是大家对各自喜欢的工作时间和工作习惯所取得的共识。
比如有的人喜欢一大早7点到公司，下午4点左右就下班回家。而有的人喜欢快到中午11点才来上班，然后工作到晚上7、8点回家。这个时候的核心时间就是除去午休时间的共同时间。
在每个项目开始的时候，以及整个项目过程中需要的时候确定核心时间。
鼓励团队保持一定的灵活性。
11.什么是发布计划？
一般来说Scrum都是有节奏的进行发布。
那么为什么还需要发布计划？
因为Scrum是为了“敏捷”的应对，所以每次Demo或者Plan Meeting需求可能会有增加、修改、取消，那么你的发布计划也需要随之更新。
发布计划的目的是：为特定功能和整个项目何时能够完成提供答案。
沟通和交流，并且要频繁
每个Sprint后都更新发布计划
努力做优先级最高的条目
更新对大条目的估计
每个Sprint都交付可工作的软件
12.何时进行故事分解？
我有时候会被问及，这个故事足够小了吧，是否还需要拆得更小？要拆到多小才合适？
要知道任何事情都有一个度，不能过度拆分，这样会造成不必要的浪费。
搞清楚一个故事或任务太大还是太小，可以下面的问题帮助确定分解的级别：
团队能够用故事点来评估产品列表吗？
产品列表中的故事是否清楚定义了？
故事是否精确？
我是否对这个故事有足够的了解？
13.Scrum的缺陷管理方式是怎样的？
首先和其他框架一样，我们需要为缺陷区别等级：
P0灾难：主功能无法使用且没有可行的变通方案
P1高：主功能不可用，但有变通方案
P2中：系统的使用性受损
P3低：影响较小，无关紧要或不便利，可以等到下次产品发布时解决
如果是P0或者P1级别，那发现者及其搭档有一个小时来完成以下任务：
停止手上当前任务
确定该缺陷的根本原因
修复
更新所有测试
生成或重新构建验证测试
保证所有测试都能通过
提交代码
向前逼近一步，至少到集成环境中验验证
如果能一个小时完成则无需记录，如果不能完成：
在一个小时结束时停止
在缺陷管理系统中记录
继续修复
完成并关闭缺陷
更新Sprint列表及小时数
14.如何处理遗留系统的维护工作？
很多时候，我们在进行新功能开发的同时，还需要兼顾遗留系统的维护工作。
这一部分如果不妥善安排，不仅会打乱团队的Sprint节奏，还会影响整体计划。
有两种方案可以解决这个问题：
专用时间
从现在进行的Sprint中划出专用时间来处理遗留或现有系统维护。
比如每个Sprint20个小时。专职团队
划分出专职人员进行维护工作，而且这个团队的Sprint要相对的使用更短的周期。
15.为何要组织demo会？
在每个Sprint的最后一天，Scrum Master需要组织Demo会议。
其目的是：让团队给客户和项目干系人演示他们在这个Sprint中完成的任务。
在这个过程中，最重要的不是演示是否顺利，而是客户和干系人的意见反馈，这样才能敏捷的调整。
16.为何要组织回顾会？
我不止一次的听人抱怨，回顾会就是浪费时间的检讨大会。
但是我们需要正视回顾会的重要性。
回顾会是团队检视调整周期中的关键部分。
团队趁此机会学习如何提高，如何更有效工作，如何以更高的速率与优良的品质交付价值。
这个环节必不可少，如果你的Sprint是一周，那么可以抽15~30分钟回顾一下，但是不可自行取消。
并且在结束会议前可以尝试用1-5分来评估“你觉得这个Sprint如何？”
17.为何要组织每日站会？
同样的一个问题，很多人说每日站会太浪费时间，而且站着开很累。
每日站会的目的就是要同步团队状态，并暴露任何可能影响工作的障碍。
站着不要坐着，这样能使团队更专心，更专注，更有效率。
毕竟可以有效的缩短会议时间，时间一长大家都站不住了。
18.每日站会上的第四个问题是什么？
我们都知道每日站会上需要问三个问题：
我昨天做了什么？
我今天要做什么？
我有什么障碍？
其实还有第四个问题是：
对于团队完成Sprint目标，如果以1~10来度量，你的信心有多少？
第四个问题可以避免团队成员在不愿意面对冲突的情况下表达自己的意见。
19.结对编程有哪些玩法？
结对编程能够在相对较短的时间内产生高质量的软件。
一般的情况是一个人“驾驶”，一个人“导航”。
这样其实可以做及时的Code Review。
但是一般来说“驾驶”的人会更专注，“导航”不自觉得就会走神了。
所以我们可以尝试以下两种玩法：
无序结对编程
大家交换结对
图片发自简书App
微结对
图片发自简书App
图片发自简书App
20.如何让新人快速融入团队？
第一步，选对人。
这点非常重要。
这也是为什么一般来说我面试的时候会问：你平时有什么业余活动？
如果团队本身的成员都比较open，而比较闷的人可能会比较难融入。
更复杂的情况是，对Scrum的排斥，会让新人更难融入。
第二步，帮助新成员学习而制定测试。
比如定期让新成员回答以下问题：
描述系统架构
为何结对和TDD很重要？
谁拥有代码所有权？
21.如何应对与团队格格不入的新成员？
有的时候我们把一个人招进来后却发现这个人与团队格格不入，并不是说这个人的能力有什么问题，而是他会给团队带来负面的影响。
比如无法接受敏捷，并且试图让大家放弃敏捷。
有一个概念叫做社会异常，就是违背以确立文化规范的行为做事方式。
敏捷和瀑布没有谁对谁错的问题，只有合适和不合适的问题。
而当一个团队都觉得自己按照一定的节奏前进时，却出现一个不合群的声音，甚至影响到前进的速度和大家的心情，那么就属于社会异常。
对这个概念如果感兴趣的话可以去搜一下。
那怎么办呢？
首先，避免增加与团队不协调的新成员。有一些预判可以帮助你。
如果已经加入团队，那么尝试和行政主管、HR反馈这个问题。
如果实在不行，就只能尝试和他沟通，让他主动退出团队或者做一些边缘性的工作了。
22.Sprint可以取消吗？
当有异味影响到团队实现Sprint目标能力时，可以：
消除障碍
获得帮助
缩小范围
取消Sprint
一般我们不会建议你取消Sprint的，而是尽力去消除障碍或者获得帮助。
如果一切都行不通，才会取消Sprint。
可能的情况是，需求突然变化，有个异常紧急的需求需要处理。
而我们知道Sprint是不能被打断，临时添加任务的。
所以可以采取取消的方式。
但是一定要注意的是，取消的同时要将代码回滚到上一Sprint。
23.Scrum如何看待加班？
Scrum一致强调“可持续”。
而我们知道，一旦加班抢时间，团队在超负荷状态下工作时间越长，就需要更多时间来恢复。
这种“殉道”行为完全无法实现“可持续”。
所以，如果正在经历精疲力尽，首要任务是缩短周期时间。
这样可以提升每次Sprint的专注力。
另外，大家都必须承认，团队的完成量是有极限的。
24.如何保证每次交付可工作的软件？
记得多年前，小婧所在的团队做一个模块，计划半年后交付。
这个模块比较大，于是我们将所有的需求拆分成Story进行开发。
前几个Sprint，我们的主要精力集中在了“业务配置”功能的开发上。
因为我们当时的想法是，不进行业务配置，后面的功能是无法实现的。
后来我们发现，业务配置的部分开发完成都已经过去了三分之一的时间了，而我们的核心功能、业务场景尚未开始。
后来和公司的敏捷教练交流这件事情的时候。
她告诉我，应该先进行的不是业务配置，而是主业务场景和流程涉及的Story。
因为Scrum强调每个版本都可工作，可交付。
但是业务配置功能的发布并不可交付，用户拿着脱离了模块主业务场景的业务配置功能，其实价值为0。
那应该怎么处理呢？
这里有个概念，叫做“核心故事”：最基本的需求。
我们应该鉴别出一个核心故事，固定其他变量，让这个核心故事贯穿于整个系统。
也就是说，之前我们应该一上来就规划开发核心故事，而不支持可配置的功能。
然后逐步的在随后的Sprint中不断的锦上添花。
还有一种方式，可能会适合于互联网软件，就是控制用户数。
限制使用者或访问系统用户数。
无论如何都应该从风险最大的功能开始，避免后续发生风险后失控。
25.如何优化Scrum的效率？
我们都知道在时间管理的话题中有一项非常重要的工作是：时间记录。
也就是你要想省钱，那就必须先知道你钱都花哪里去了。
对于Scrum提升效率也是如此，你需要知道自己每类工作的花费，才能更好的提升效率。
有这样几类工作，大家可以尝试来进行观察和记录。
功能工作：向用户交付商业价值的功能
额外工作：企业服务或强制要求，比如审核或会议
Spike穿刺：研究类工作
必要性工作：要达到完成标准需要做的工作
26.利用Scrum如何进行项目成本估算？
一般来说我们估算一个项目的成本有几种方式：人天、功能数。
而Scrum会提供给你一个更准确的评估方式。
生成用户故事：列出带评估项目的所有用户故事。
确定用户故事的优先级：按照优先级由高到低，逐一排列。
估算用户故事的大小：主要是为了是确定速率。计算所有用户故事的总点数。以以往的速率计算需要多少人在规定时间内能完成。
确定团队的成本：上一步得到的人数，乘以团队平均工资等成本。
计算项目的成本
承诺是否能做
27.Scrum后就不用写文档了吗？
有好多人说，我们是Scrum，我们不需要写文档，只有你们瀑布才会要写那么多文档。
对不起，我没听清。
谁告诉你Scrum可以不写文档的？
Scrum只是说，不写没用的文档。
也就是说，首先我们需要决定，项目需要什么什么文档以及什么时候做文档最有意义。
然后，按计划交付承诺的文档及及时汇报项目状态和白板照片。
并且，最好是投入自动化，部分文档可以通过自动化工具来生成。
比如我们以前写Online Help文档，后来就自动化转成操作手册进行交付。
28.外包与离岸开发要注意什么？
不管相距多远都要营造出一种氛围，让大家觉得是在同一个地方，工作的同一个团队。
以下几点要特别注意：
选择合适的离岸团队：雇佣敏捷团队，并且时差小于三个小时
以痛苦最小的方式分配工作：
让团队按工作包交付
让多个团队在同一代码机上工作
把特定的开发功能外包，如，测试、UI坚持Scrum框架
建立团队文化
持续集成
准备差旅
配合一个项目或团队协调人
以下情况建议绝不考虑离岸：
高度复杂技术高风险的第一个发布
本地团队还在挣扎于开发实践如TDD等，或缺乏纪律
公司没有成功必备的差旅预算和远程沟通技术的预算
29.大型列表如何进行优先级评定和估算？
像一般开发周期在3个月以上，涉及三类以上干系人的项目，其Story的数量和复杂度是非常可观的。
我们不可能逐一评判优先级，这个工作量太大了，需要协调的干洗人也会非常多。
这里有一个办法，可以快速的（一天内）完成Story列表的优先级评定和估算。
首先，你需要将所有的Story都准备好。
然后，让团队先大致将所有的Story按照大小排序：小的、中等的、大的、超大的。
这种排序是模糊的，不精确的。
接着组织所有干系人对同一区域内的Story进行优先级高低调整。
最后，Scrum Master一定要记录干系人讨论的内容及有争议的地方，以便后续进行进一步的跟踪。
30.你见过这样的合同吗？
一般来说，软件合同分成：固定总价合同和人天合同。
固定总价合同很好理解，就一笔钱，做多做少都这么多钱。
一般对需求比较明确的项目建议使用固定总价合同。
人天合同更多见于软件咨询类的合同。
顾问来多少天就给多少钱。
当然还有一些合同的变形，我这里就不展开讲了。
而Scrum给了我们另外一种合同的可能。
主要是两部分组成：调研合同和项目合同。
首先，签订的是调研合同。
由团队业务人员进行业务调研，并进行分析后给出Story清单和评估。
如果甲方觉得满意可以继续签项目合同，如果觉得不满意可以找别人来进行开发。
这个合同基本上会以“人天”合同为主。
接下来如果签“项目合同”，则是分Sprint签订、给钱。
如果甲方对这个Sprint的交付不满意，可以拒付。
也可以在几个Sprint后随时喊停。只需要提前通知即可。
但是我觉得要做到这点，真的是需要使用Scrum框架的每个实践，保证每次交付都是可用的软件。
出处：https://www.jianshu.com/p/f9f8a19a30a7
以上是关于关于MLOps中的数据工程，你一定要知道的.......的主要内容，如果未能解决你的问题，请参考以下文章
AI数据也要紧跟MLOps，那个把标注精度提高到99.99%的公司又出手了