亚马逊AWS官方博客

如何构建云上智慧牧场

在亚马逊云科技,我们不仅热衷于为客户提供各种完善的技术方案,也非常乐意深入了解客户的业务流程。我们以第三方的姿态和客观的判断,帮助客户梳理价值,收集痛点,提出合适的方案,并且以最高性价比做出可使用的原型,以帮助客户一步步达到业务目标。

这样的工作方式,在亚马逊云科技被称作「逆向工作法」(Working Backwards),即抛开技术和解决方案,先从客户期待的结果出发,确认有价值,然后反向推导出需要做的事情,最后再实施。而在实施阶段,我们也遵循「最简可行产品」(Minimum Viable Product)的理念,力求在数周内快速形成一个可产生价值的原型,再做迭代。

今天,我们来看一个亚马逊云科技与新希望乳业合作构建云上智慧牧场的案例。

项目背景

牛奶是一种富含营养的饮品。出于对国民健康的考虑,我国一直在大力持续推动乳制品行业的发展。根据欧睿咨询数据,我国的乳制品销售规模在 2020 年就达到了 6385 亿,并且预计在 2025 年将达 8100 亿。此外,近 14 年的年均复合增长率也达到了 10%,可谓是高速发展。

另一方面,截止 2022 年,国内乳制品行业的收入大头仍然来自于液态奶,原料奶的 60% 都用作了液态奶和酸奶,还有 20% 是液态奶的直接衍伸品奶粉,仅极少数用于奶酪和奶油等深加工产品。

液态奶属于浅加工制品,其产量、品质、成本都与原料奶深度挂钩。这意味着,如果乳制品行业想腾出手来去攻关深加工产品、去创造新品、去做更前沿的生物科技研究,就得先做好液态奶这个「主战场」,提升和稳定原料奶的产量和品质。

作为乳制品标兵企业,新希望乳业也一直在思考如何提升牧场运营效率,提升原料奶的产量和品质。在与亚马逊云科技的合作过程中,新希望乳业希望能借助亚马逊云科技的第三方身份和对技术的深耕来促成乳业的创新。在新希望乳业 VP / CIO 胡柳通的大力支持和推动下,亚马逊云科技客户团队开始梳理乳业牧场的流程业务和潜在的创新点。

乳业牧场的挑战

亚马逊云科技在云技术领域是专家,但要把创新落地到行业,还得由内行人士提供专业意见。鉴于此,我们与新希望乳业生产技术中心副总监宋良荣、牧场管理团队以及营养师们做了数次深度访谈,了解了牧场的一些问题和挑战。

首先,是预备牛的盘点

牧场的乳牛分为「奶牛」和「预备牛」两种,奶牛是成熟并持续在产奶的牛,预备牛则是尚未到产奶年龄阶段的牛。中大型牧场通常会给预备牛一个较大的开放式活动区域,以便让预备牛有更舒适的成长环境。

不过,奶牛和预备牛都属于牧场的资产,需要按月进行盘点。奶牛每天都要挤奶,挤奶时相对静止,所以盘点容易,但预备牛因为是在开放空间,牛会走来走去,所以不便盘点。每次盘点,都需要几个工人,从不同区域出发,反复盘点计数,最后核对数字。这个过程会消耗数个工人一到两天的时间,还经常出现很难对齐、不确定是否每头牛都数到之类的问题。

如果我们有一个办法,可以快速、精确地盘点预备牛,那么就可以省下不少人力来做别的更有价值的事情。

然后,是跛足牛的识别

目前大部分乳品公司都使用一种叫做「荷斯坦」(Holstein)的品种来做奶牛,也就是我们认知中的黑白相间的奶牛,但不同公司和牧场,产奶的产量和品质仍然有差异。这是因为奶牛的健康会直接影响牛奶生产。

话虽如此,奶牛并不是人,无法主动言语或者表示自己不舒服,而兽医也不可能天天给成千上万的牛做体检,所以就只能找到一些外在指征来快速判断牛的健康状态。

奶牛的外在指征包括「体况评分」(Body Condition Score)和「跛足程度」等。体况评分主要与牛的胖瘦有关,属于长期指标,而跛足则是因为牛的腿部出问题,或者足部有感染、长倒刺等造成,属于短期指标。

当牛出现跛足,就像人脚受伤,走路疼痛不稳,影响心情和健康,对产量造成直接影响。此外,成年荷斯坦牛体重可达到 500 公斤以上,这样的体重压在不稳的脚上,对牛造成的伤害可想而知。所以,一旦出现跛足的情形,兽医就应该尽快介入。

根据 2014 年的一份研究,中国的奶牛严重跛足率可达约 31%。虽然多年过去状况也许有所好转,但毕竟牧场的兽医人数是极为有限的,很难经常去盯着牛只,当发现跛足时,往往事态已经比较严重,治疗费时费力,而产量也早已经受影响。

如果我们有一个办法,可以及时判断牛的跛足情况,并且在有轻微跛足的时候就提示兽医进行介入,那么牛的整体健康度和产量就会上升,提升牧场的绩效。

最后,是饲料成本优化

对畜牧业来说,饲料是流动成本的大头。要保证饲料的品质和库存,牧场经常需要同时向国内和海外的供应商购买饲料原料,再交付饲料配方厂进行加工。现代饲料原料品种非常多,包括豆粕、玉米、苜蓿、燕麦草等十数种,这也就意味着活动的「变量」很多。每种原料都可能有自己的价格周期和价格波动。在波动较大时,饲料的整体成本变化可超过 15%,造成巨大影响。

饲料成本随时变化,但乳制品价格却长期相对固定。也就是说,在什么都不变的情况下,仅因为饲料变化,整体的利润就会有相当程度的波动。

为避免这种波动,就需要考虑在价格低谷时多囤一些原料。而囤货又要考虑:价格是否真的是处于低谷?按照目前的消耗量,应该购买多少?

如果我们有一个办法,可以及时预告饲料消耗,并结合整个价格趋势,在最合适的时间,建议购入最合适数量的饲料,就能为牧场降本增效。

不难看出,这几个问题都直接与客户的目标「提升牧场运营效率」直接相关,而方式则分别是「解放人力」、「提升产量」和「降低成本」。通过对这几个问题解决难度和价值的探讨,我们决定选择「提升产量」这条线作为切入,优先解决跛足牛的问题。

调研

在谈技术之前,我们需要先调研。调研由亚马逊云科技客户团队、负责机器学习算法模型的 Amazon Machine Learning Solutions Lab 团队以及新希望乳业的牧场专家团队一起执行。它分成几个部分:

  • 了解跛足牛的纸面识别方式,对什么是跛足牛有大致的了解
  • 确认现有的解决方案,包括牧场的以及行业的
  • 牧场环境调研,了解现场的情况和限制条件

通过资料学习以及实地视频观摩,我们简单了解了奶牛的跛足。读者也可以通过下下面的动图来大致感受一下跛足牛的体态。

对比体态相对健康的牛。

可以看出跛足牛在姿态、步伐上都与健康牛有区别。

至于现有解决方案,对于大部分牧场来说,跛足牛都依赖兽医和营养师的肉眼判别。行业里,有使用穿戴式计步器和加速器来识别的,也有使用分区地秤来识别的,但二者成本都比较高。对于竞争非常激烈的乳品行业来说,我们需要尽量降低识别成本,尽量少地购置和依赖非通用硬件。

在与牧场兽医和营养师探讨并分析后,亚马逊 Amazon Machine Learning Solutions Lab 专家决定选择计算机视觉(Computer Vision,下简称「CV」)来做识别,仅依赖普通硬件——民用监控摄像头,也不给牛增加额外负荷,降低成本和使用门槛。

决定了这个方向之后,我们实地拜访了某个数千头牛的中型牧场,调研了牧场环境,并确定了摄像头安放的的位置、角度。

初步方案

现在,我们把视线转向方案。我们基于 CV 方案的核心包含下面几个步骤:

  • 牛只识别:识别视频中某一帧中的多只牛,并标记每只牛的位置
  • 牛只追踪:视频是流动的,所以我们还需要在不同帧变换时,持续追踪牛只,并给每只牛加上编号
  • 体态标记:对牛的运动做降维操作,把牛的图片转换成标记点
  • 异常识别:识别标记点动态中的异常
  • 跛足算法:对异常值进行规整化得到一个分数用于判断牛只跛足程度
  • 确定阈值:根据专家的输入,得出一个阈值

根据 Amazon Machine Learning Solutions Lab 专家的研判,前面几个属于通用需求,可以使用通用的开源模型来解决,后面几个问题则需要我们通过数学方法和专家介入来解决。

解决难点

为了平衡成本和性能,我们选择了 YOLOv5 预训练的中型模型 yolov5l。它包含了对奶牛的识别,输入宽度是 640px,对这个场景来说性价比较高。

YOLOv5 仅负责单张图片中牛的识别和标记,但视频实际上是图片(帧)不停切换,YOLOv5 无法知晓多张图片中的牛是同一头。要做到跨图片来跟踪和定位某一头牛,这就需要另一个模型 SORT。

SORT 是「Simple Online and Realtime Tracking」的缩写,即「简易在线实时追踪」。其中「在线」指的是它仅考虑当前帧和前一帧的关系,而不会纳入更多的帧来做追踪,「实时」则指的是它可以即时返回物体的身份。

SORT 论文发表后,很多工程师对其进行了实现和优化,形成了 OC-SORT,后又把人物外观纳入考虑,形成了 DeepSORT(及其升级版 StrongSORT),还有使用两阶段关联器把低置信度的识别也纳入考虑的 ByteTrack。

在分别测试后,我们发现针对我们的场景,DeepSORT 的外观追踪算法更多是针对人,而对于牛的识别并没太大帮助,而 ByteTrack 的追踪准确性略弱,所以,最终选择了 OC-SORT 作为我们的追踪算法。

接下来是使用 DeepLabCut(下简称「DLC」)标记牛的骨骼点位。DLC 是一种「无标记」(markerless)的模型,也就是说,虽然头、四肢之类不同的点位可能有不同的意义,但对于 DLC 来说都只是「点」,仅需要我们标记好点位然后训练即可。

这就引出了一个新的问题:我们给牛打多少个点?在哪些地方打点?问题的答案关系到标记的工作量、训练量以及后续推理的效率等。为解决这个问题,我们必须先来看跛足牛的识别方式。

结合我们的调研和客户专家的意见,跛足牛在视频中会有如下体现:

  • 颈背弯曲,以颈骨根部为顶点,形成一个三角形(Arched-back)
  • 频频点头,每一步都会因站不稳或者打滑而形成「点头」(Bobbing)
  • 步伐不稳,走几步就可能会有些许停顿(Gait pattern change)

针对颈背弯曲和点头,Amazon Machine Learning Solutions Lab 的专家判断仅标记牛只的 7 个背部点位(头部 1 个、颈骨根部 1 个、背部 5 个)即可较好识别。因为我们有识别框,所以应该也可以识别步伐不稳的情况。

接下来是用数学方式来表达识别结果,形成算法。

对于人眼来说,识别这几个问题不难,但要用计算机识别,就需要精确的算法。比如,下面是一堆的牛背坐标点,程序怎么知道这头牛的背部弯曲程度?怎么知道牛有没有点头?

(198, 655),
(248, 654),
(306, 650),
(393, 642),
(513, 639),
(573, 683),
(665, 737)

在背部弯曲方面,我们先考虑把牛背视作一个角,找到角的顶点,则可以计算角的角度。这个方法的问题是脊椎可能会有双向弯曲,导致角的顶点不明显或者难以识别。这就需要换用其他算法来解决。

在点头方面,我们首先考虑使用「Fréchet 距离」(Fréchet distance)来判断牛整体姿势的曲线的差异来判断牛是否在点头,但问题是,牛的骨骼点经常可能会有位置偏移,导致类似的曲线之间也会有较大的距离。为解决这个问题,我们需要取出头部点位相对于识别框的位置,做规整化(Normalization)。

头部位置规整化之后,我们又会遇到新的问题。下面图中左边是牛的头部位置变化,可以看出,因为识别精度问题头部点位会不停有小幅的晃动。我们需要把这些晃动去掉,找到相对比较大的头部运动趋势。这时候就需要一些信号学的知识了。使用 Savitzky–Golay 滤波器(Savitzky–Golay filter),我们可以把一个信号平滑化,从而获得它在整体上的趋势,方便我们识别点头的情况,如右图中橙色曲线所示。

此外,在经过数十小时的视频识别后,我们发现,有一些背部曲度极高的牛,实际上并不驼背。排查发现,这是因为我们在训练 DLC 模型时,大部分牛都是黑色偏多或者黑白相间,白色偏多或者接近纯白的牛只并不多,所以导致模型对纯白牛只或者牛身上大面积白色时识别错误,如下图中红色箭头所示。这可以通过进一步训练来纠正。

除了解决上述问题之外,我们还要解决一些通用问题:

  • 在视频中有前后两根通道,远处的牛也可能被识别出来,导致问题
  • 视频中的通道有一定弧度,在两侧时牛的身长变短,姿态容易识别错误
  • 因为多只牛重叠或围栏遮挡,导致同一头牛被识别成两头
  • 因为追踪的参数和摄像头偶然跳帧,导致无法正确追踪牛只,造成 ID 错乱问题

这些问题通常可以用离群值判断算法加上置信度过滤来解决,而实在无法解决的,则会变成无效数据,这需要我们后续进行额外的训练,持续迭代我们的算法和模型。

在解决一系列的问题之后,结合牧场兽医和营养师的打分,我们就得出了一个综合性的牛只跛足评分,从而帮助我们识别出严重、普通、轻微等不同跛足程度的牛只,并且可以基本识别牛只的多项体态属性,帮助进一步研判和分析。

此时我们的机器学习模型流程如下。

工程封装

前面我们解决了一些算法问题,这些问题属于整体方案中的核心,也是最困难的部分,但除了核心部分,我们还得把算法整体封装成一个工程。工程化往往是技术上最简单,但是工作量却最大的部分。它意味着:

  • 应用可以运行在生产环境的硬件上
  • 应用可以从生产环境获得正式输入,并给定正式输出

在亚马逊云科技,我们通常使用 Amazon SageMaker 来托管机器学习模型的训练和推理。接下来我们简单介绍一下推理部分的封装方式。

由于算法由三个模型串接,并且还需要读写视频,耗时很长,所以我们使用批处理推理(Batch Transform)的方式。与 SageMaker 实时推理类似,批处理推理也遵循以下规则:

  • 用户在 SageMaker 内指定容器作为封装好的算法,设置一个 CSV 文件作为输入,并启动批处理推理任务
  • SageMaker 启动实例后,会使用docker run serve的方式来启动算法容器,如果是 GPU 实例,则会再增加--gpus all参数把 GPU 曝露给算法容器
  • 针对容器调用GET /ping并在返回HTTP 200时执行POST /invocations开始推理
  • 推理结束后返回HTTP 200,把结果汇总存至用户指定的位置

我们有两种方式来实现这个容器:

  • 使用 SageMaker 相关的 SDK,如multi-model-server
  • 使用 Nginx 和 Gunicorn 来构建一个简单的 REST 服务

为简便起见,我们使用后者来实现。代码结构如下,读者亦可参考官方示例

container/
Dockerfile
handler/
serve         # 运行 Nginx 和 Gunicorn 的 Python 脚本
nginx.conf    # Nginx 配置文件
wsgi.py       # Gunicorn 启动脚本
predictor.py  # Gunicorn App 脚本,核心推理逻辑

推理代码的放置,我们也有两种方式:

  • 直接内嵌至容器内
  • 要求 SageMaker 下载至/opt/ml/model路径下

前者简单,但是每次容器变化会需要修改容器镜像,而后者则可以很灵活的直接修改代码。因为是方案验证,所以本次我们先是在一台 GPU 机器上确认了代码,再直接置入容器,后续可调整为外部加载的方式。部分 Dockerfile 代码如下。

# 使用 NVIDIA 的 CUDA Ubuntu 作为基础镜像更方便
FROM nvidia/cuda:11.7.1-runtime-ubuntu18.04
# 使用 GPU,所以设置成单线程
ENV MODEL_SERVER_WORKERS 1
# 手动复制模型
COPY models /opt/ml/model
# 升级所有系统包
RUN apt-get update && apt-get upgrade -y && apt-get clean
# ...安装依赖和配置算法(略)...

对于摄像头的推流接收,我们使用了亚马逊云科技云初创生态团队的「无服务器视频流方案」。这个一键部署的方案让我们可以快速接收摄像头推过来的视频流并按照制定格式存至 S3,方便我们处理。

到这个阶段,我们的架构如下。

有了视频推流接收,可以定期触发 SageMaker 批量转换任务,我们整个工程就完整了。尽管如此,要持续优化模型,我们还需要做到以下几点:

  • 模型版本管理,记录模型版本,以及对应的训练输入、参数,并支持多个版本同时提供服务
  • 模型基线管理,新模型版本上线时,我们需要确认新模型版本相对旧的是有提升的,这就要求我们有一系列经过人工验证的基线验证数据,确保不会因为模型更新反而导致原来可以正常判断的跛足牛被漏判、误判
  • 模型代码管理,将模型相关的代码、容器和 API 契约等管理起来

当我们保存了相当数量的基线验证数据,并且可以在新模型提交时,自动触发基线验证,并在验证通过时自动上线,在线上针对多个模型做 A/B 测试,那么我们实际上就形成了一个「机器学习运维流水线」,实现了「Machine Learning Ops」(简称「MLOps」),让我们可以更安全、便捷、迅速地去优化我们的模型。

业务封装

当然,上面讲到的,其实仅仅是我们的技术方案核心,要把整个方案纳入到业务流程里面,我们还需要解决以下一些业务相关问题。

  • 数据反哺,比如给兽医一个界面,筛选、查看需要处理的跛足牛,并在这个过程中收集数据作为后续的训练数据
  • 牛只标识,比如兽医看到跛足牛后,还需要知道这头牛的身份,即它的编号、围栏
  • 牛只定位,比如在一个围栏有上百头牛的情况下,快速找到这头牛
  • 数据挖掘,比如找出牛的跛足程度对其喂食、反刍、休憩模式的影响,以及对产量的影响
  • 数据驱动,比如找出跛足的牛有什么基因、生理、运动模式等特征,做到牛的优生优育

只有这些问题解决了,这个方案才能真正解决业务问题,收集的数据也可以产生长期价值。这些问题中,有些是系统对接问题,有的则是技术和业务结合问题,我们将在后续的文章中做进一步分享。

总结

这篇文章中,我们非常概要地解说了亚马逊云科技客户团队如何从客户的业务出发快速创新。这个机制有下面几个特点:

  • 业务牵头,即先不谈技术,现地现物了解客户所在的行业和业务流程,再与客户深入探讨业务上的痛点、难点和问题,找出重要并且可以用技术解决的问题
  • 全程服务,即不空谈宏观概念,提出来的方案一定是端到端并且可落地,不只解决其中最困难的部分(比如算法),但也解决最麻烦的部分(比如工程化和部署)
  • 立等可用,即我们希望把一个简单但是完整可用的原型,在数周(而不是数月)内直接提供给客户进行试用,验证其价值并且快速迭代
  • 最小成本,即我们希望在价值真正验证之前,尽量降低甚至免除客户的成本,避免后顾之忧,这也正好对应了亚马逊云科技「领导力准则」中的「节俭」(Frugality)

在与乳业的合作创新项目中,我们不仅从业务出发,与业务专家一起定位了具体业务问题,还与客户一起深入到牧场和工厂一线调研。我们在现场确定了摄像头位置,安装、部署了摄像头,并部署了视频推流方案。Amazon Machine Learning Solutions Lab 的专家拆解了客户需求并形成了算法,再由解决方案架构师对整个算法形成了工程化。

每次推理,我们都可以得到上千个拆解并标记好的牛只行进视频,每个视频都有原始视频 ID、牛只 ID 及其跛足程度得分和各项细节分数,完整的计算逻辑以及原始步态数据也保留供后续算法优化。

在数周时间内,我们已经有一个端到端的跛足牛识别方案。这个方案的硬件摄像头仅花费 300 元,SageMaker 批处理推理如使用 g4dn.xlarge 实例,2 小时视频的推理时长约为 50 小时,总费用仅需 300 元。当进入生产后,如果每周检测 5 批次牛只(设约 10 小时),算上滚动保存的视频和数据,一个数千头牛的中型牧场每月的检测费用也不足万元,免除了客户的后顾之忧。

跛足数据除了用于兽医早期介入,还可以结合挤奶机的挤奶数据来进行交叉分析,从而为我们提供一个额外的验证维度,回答一些额外的业务问题,比如:产奶量最大的奶牛在体态上有什么特征?跛足对牛只的产奶量等有何影响?是造成跛足牛的主要原因是什么?怎么避免?这些信息将为牧场的经营提供一些新的思路。

跛足识别的故事讲到这里,但牧场创新的故事才刚刚开始。在后续的文章中,我们将继续介绍我们怎么与客户深度合作,解决其他的问题。

本篇作者

张玳

AWS 解决方案架构师。十余年企业软件研发、设计和咨询经验,专注企业业务与 AWS 服务的有机结合。译有《软件之道》《精益创业实战》《精益设计》《互联网思维的企业》,著有《体验设计白书》等书籍。

黄灏

Amazon Machine Learning Solutions Lab 应用科学家。长期关注于计算机视觉与智能安全领域,在人工智能顶级会议发表多篇文章,并担任AAAI,TMM等顶级会议或期刊审稿人。