1. 先拆需求：计数、行为监控、人员安全到底要解决什么问题
这个项目来自我参与的一个规模化猪场智慧养殖改造，内部代号就叫模拟项目X。标题里的几个词看着抽象，拆开其实就三件事：数清楚猪、看懂猪在干什么、管好进场的人。这三件事直接对应猪场管理的三个老大难：盘点不清、发病发现太晚、人员违规作业引发事故。猪只行为识别数据集第10542期，则是整个系统能跑起来的根基——没有这套按周期迭代的数据集，后面所有算法都是空中楼阁。
先说说为什么规模化养殖场景下计数这么难。传统散户养猪，一个栏几头猪，人工数一下就行。规模化场里一栋舍几百头甚至上千头，出猪、转群、盘点，靠人去栏里数不光效率低，还会惊动猪群，反而容易漏数、多数。更要命的是，猪一旦扎堆，前后遮挡严重，摄像头里看到的往往是一团模糊的粉色，这个场景下人眼都费劲，更别提算法。我们最早拿通用目标检测模型直接跑，漏检率高得没法用，后来才意识到必须专门做一个猪只行为识别数据集来喂模型。
再说行为监测。猪不会说话，生病早期往往只表现为活动减少、趴卧不动、进食量下降、跛行或者频繁爬跨。以前靠饲养员巡栏，一天看两三次，等到肉眼能看出异常，往往已经发病一到两天。在规模化场里，这个延迟就意味着可能波及整栋猪舍。所以需要用视觉算法持续分析猪只行为，做到异常早发现。人员安全管理相对直接，但同样高频：员工在栏内操作时被猪拱伤、误闯消毒区、夜间单人滞留、不穿防护装备就进生产区，这些都是实际发生过的安全问题。
第10542期这个编号，很多人以为是第10542周，其实不是。它更像数据集的版本号，代表这个数据集已经持续迭代了很久，内部每积累一轮数据、清洗一轮标注、跑完一轮训练和评估，就生成一个新版本。第10542期指的是当前这个迭代版本，里面包含了不同季节、不同光照、不同栏舍结构和不同猪只日龄的视频帧与标注，专门为规模化场景设计。
1.1 为什么通用算法在猪场里“水土不服”
我们一开始踩了个大坑：直接拿公开目标检测模型迁移到猪舍，效果惨不忍睹。原因可以列出一串：猪舍光线复杂，白天强逆光、夜间红外补光、廊灯反射；栏位栅栏会把猪切成一截一截的，猪身颜色又和水泥地面、栏杆、饲料槽高度接近；小猪密集拥挤时，前后腿、耳朵、尾巴互相遮挡，标注稍不准就学出一堆误检。通用模型在公开数据集上没见过这种“密集、遮挡、低对比”的组合，自然扛不住。
这就是为什么必须有专门的猪只行为识别数据集。数据集不仅仅是“图片+框”，它要做的是把猪场真实的环境分布采样下来，让模型见过足够多的反例，才知道什么不是猪，什么不是进食，什么不是躺卧。第10542期的价值就在这：它不是一次性采集的玩具数据集，而是按真实生产节律持续回流的长期资产，每一期都会加入上一期模型做错的难例。
1.2 模拟项目X的总体架构和技术选型
整个系统分四层。最下面是采集层，在猪舍关键点位部署摄像头和边缘计算盒子；中间是数据层，包括猪只行为识别数据集的采集、清洗、标注、版本管理；再往上是算法层，做检测、追踪、计数、行为识别、人员识别；最上面是应用层，接告警、报表、远程App。我们最终没有把全部计算都扔到云端，因为猪场网络环境不稳定，断网不能影响现场预警，所以核心推理放在边缘端，云端只做汇总和模型更新。
选型上我们走的是“开源框架为主、所有细节为场景定制”的路线。检测模型用了当下成熟的YOLO系列作为基座，行为分类在检测框基础上做时序分析，人员安全单独训练了一个人员检测和属性识别模型。数据管理和标注用了一套内部搭建的流程，不是买昂贵平台，而是把开源标注工具和我们自己的质检脚本拼起来，够用就好。这个架构最大的好处是每层都能独立迭代，数据集一期期更新，模型跟着升级，采集端不用频繁动。
2. 数据是地基：猪只行为识别数据集的采集与标注
很多团队把精力都扑在模型调参上，忽略了数据集工程。我在这个项目里最大的体会是：算法模型只是露在水面上的冰山，数据采集、清洗、标注、质检这些工作才是冰山的主体。第10542期能成为一个相对可靠的数据集，靠的不是某一次集中采集，而是一套细到令人烦躁的流程。
2.1 摄像头点位怎么布，直接影响数据质量
摄像头的安装位置决定了数据难度的天花板。我们踩过的坑包括：角度太平导致猪只相互遮挡严重；距离太远导致小目标模糊；有柱子或料槽挡住关键区域；还有廊灯直射造成逆光，猪脸一片黑。最后总结出来一套布点原则：尽量高角度俯视，但不要完全正上方，最好与水平面呈30到45度角；每个栏位至少一个机位，大栏加辅助机位；夜间必须开启红外或低照度模式，保证24小时数据风格一致。
对于计数场景，机位要能覆盖栏位出入口和主要活动区；对于行为识别，机位要能看清猪的四肢和躯干，否则爬跨、跛行这种对姿态敏感的行为根本标不了。数据采集不是装完摄像头就完事，还要按不同时段采集：早晨喂料前、喂料中、喂料后、午后休息、夜间红外、清粪时，每个时段的猪只行为差异巨大，缺少任何一类都可能导致模型在某个时段突然失效。
2.2 数据清洗的隐藏工作量
原始视频录回来，不能直接切帧送标。猪舍环境太脏乱，画面里经常出现粪污飞溅、水雾、蚊虫飞过、饲养员走动、清粪车经过。这些干扰帧会污染模型训练，尤其是指定给行为识别的帧，如果里面混着人员或者设备，模型可能学到错误关联。我们的清洗流程分几步：先做抽帧，按每秒或每两秒取关键帧；再用一个简单的规则加人工抽检去掉明显模糊帧；然后用预标注模型跑一遍，把置信度极低的难例单独挑出来人工确认。
这里有个容易被忽略的点：重复帧问题。猪在栏里大部分时间不动，连续抽帧会产生大量几乎一样的图片。如果全量送标，训练集里同一头猪的静止画面会过采样，模型容易对“静止”过拟合。我们去重的方式是算帧间像素差异，差异小于阈值的丢弃，同时保留少量连续帧给时序行为模型使用。第10542期里专门有一批连续序列数据，是给行为时序模块用的，这和我们说的“数据集”不太一样，它不只是图片，还有序列。
2.3 标注规范怎么定，才能让模型不乱学
标注规范是整个数据集工程中最容易出现分歧的地方。猪只密集场景下，一个框里可能同时压着好几头猪，标注人员稍微犹豫，标准就成了“每人心里的标准”。我们最终把标注规范细化到了这几条：
- 可见面积超过30%的猪必须标，少于30%且完全被遮挡的不标，但要在备注里记录“被遮挡”。
- 猪与猪重叠时，框以可见躯干中心为准，不强行包住被遮挡部分。
- 行为类标签采用多标签，同一头猪可以同时是“站立”和“进食”，避免非黑即白。
- 框的类型分为目标框和关键点框，爬跨、跛行等行为必须额外标关键点，比如头部、前蹄、后蹄。
行为类别我们初期设计了七八种，后来压缩到优先保证的几种：站立、躺卧、进食、饮水、爬跨、跛行、争斗。趴卧和躺卧在视觉上很难区分，干脆合并成躺卧类，等数据量上来再拆。很多人想一次性把动作分得特别细，结果标注一致性崩了，模型也学不明白。先保证高频行为的准确率，再逐步细分，是更务实的路线。
标注质检是另一道坎。初期标注员之间的一致率只有七成多，问题主要出在小猪重叠框和遮挡判断上。我们用了双人标注加仲裁的机制：每批数据抽10%到20%做交叉复核，不一致的由资深标注员仲裁，仲裁结果回填到规范文档里。这个流程看着慢，但能防止错误标注在数据集里滚雪球，后面算法团队再拼命调参都补不回来。
2.4 第10542期的构成与样本分布
第10542期数据集的构成可以简单理解为三个维度：场景、个体、行为。场景维度包括不同猪舍、不同栏位结构、不同季节光照、白昼与夜晚；个体维度覆盖保育猪、育成猪、育肥猪和部分母猪，体型的差异迫使模型学习尺度鲁棒性；行为维度则重点覆盖正常行为与异常行为，异常行为样本刻意做了过采样，因为这类样本在自然视频里太少，不补充的话模型会严重偏向“正常”。
整个数据集的训练集、验证集、测试集划分是严格按“栏位”划分的，不是按“帧”随机划分。这一点非常重要。如果同一个栏位的画面既出现在训练集又出现在测试集，模型可能记住栏位背景特征，而不是学会识别猪本身，导致测试分数虚高。我们测试集选的是模型从未见过的几个栏位，尽量贴近真实上线环境。这套划分逻辑，也是第10542期相对可信的关键原因之一。
3. 算法工程化：计数、追踪、行为识别怎么从模型变成可用功能
有了数据集的底子，算法层面的工作就顺理成章了。但“模型在测试集上分数高”和“系统在场里稳定用”之间还隔着一条很宽的河，下面这块我重点说说建模和工程化阶段的几个关键选择。
3.1 计数方案别直接数框，要做检测加追踪
一开始我们尝试了最直白的思路：检测出猪框，然后数框的数量。这个方案在静态图片上勉强能用，但在视频里会出大问题——猪在走动，摄像头在抽帧，同一个栏里的猪时而出现时而遮挡，直接数框会导致计数结果剧烈抖动，今天下午数出来100头，晚上就变成87头，根本交不了差。
后来改成“检测加追踪”的经典方案：先用检测器识别每一帧里的猪，再用追踪算法给每头猪分配一个临时ID，维护一个轨迹列表。栏舍的活猪数不是当前帧的检测框数，而是轨迹去重后的活跃ID数。哪怕某头猪被挡了两三秒，追踪算法也能根据运动预测把它暂存下来，等它重新出现时继续接上轨迹。这个方案大大降低了遮挡带来的计数波动。我们还额外加了越线计数逻辑，在栏舍出入口画一条虚拟线，猪穿过时自动加或减，用来做转群、出栏时的自动盘点。
不过追踪在密集场景也有短板，猪挤在一起相互遮挡时ID容易切换，Id switch一多，计数又开始飘。针对这个问题我们做了两层补救：一是把追踪框和外观特征结合，不只看运动位置，也看猪背部的花纹和轮廓；二是给轨迹加“冷却期”，短时间消失的猪不立刻判定为离栏，而是保留三到五秒的缓冲，等它重新出现。这些细节看着不起眼，却直接决定了计数功能的可用性。
3.2 行为识别不能只看单帧，要加时序上下文
猪的行为在很多情况下是“一组动作”，而不是“一张定格照”。爬跨是一个持续数秒的动作，先靠近、抬腿、趴上去，最后下来；跛行更是明显的步态异常，要看连续几步的节奏。单帧分类模型即使准确率再高，也容易把爬跨前一刻的“站立靠近”和普通站立搞混，或者把跛行的一条腿落地瞬间当成正常行走。
所以我们的行为识别拆成了两条线。第一条线是高置信度的单帧行为，比如进食、饮水、躺卧，这类行为姿态特征明显，检测框内加一个轻量分类头就能做；第二条线是时序行为，对爬跨、跛行、争斗这类依赖前后帧的动作，我们会抓取该ID目标在时间窗口内的连续帧，丢给一个时序模型，输出行为类别。时间窗口的长度我们试过3秒、5秒、10秒，最终选定5秒，太短看不全动作，太长延迟变大，现场告警等不起。
实际操作上，我们会在边缘端先做实时检测和追踪，再把每个目标的短时轨迹片段缓存下来，每隔一定间隔批量做一次时序推理。这套做法有个好处，就是可以让模型在现场先快速跑检测，行为识别的结果异步更新，不至于拖慢整个系统的响应速度。第10542期数据集里的连续帧序列，就是专门用来训练这部分时序模型的，序列长度统一截成5秒，每秒两帧到三帧。
3.3 模型训练和调参，哪些技巧在猪场里真正有用
训练细节上有几个经验值得写下来。第一是数据增强里Mosaic和随机遮挡很关键，因为猪场里互相遮挡是常态，模型必须学会从露出的局部推断整体。第二是类别不平衡问题，异常行为样本天然稀少，正面样本太多，我们会给异常行为类别调高损失权重，也会复制少量异常样本做重复采样。第三是输入分辨率不要一上来就调大，先跑640分辨率验证流程，再切到更大分辨率提升小目标召回，否则训练周期被拉长好几倍，试错成本太高。
评估指标上，千万不要只看mAP。mAP对猪只计数这类任务并不完全贴合实际，因为场里更关心的是漏检率和误检率的平衡。我们额外统计了每帧的漏检率、重复检测率、计数误差绝对值和置信度分布。置信度分布是一个很容易被忽略但极有价值的指标——如果模型对大多数正确目标输出0.9以上的高分，同时对误检目标也输出0.9高分，说明模型“很自信地犯错”，这种情况通常意味着训练数据出了问题，比如标注不一致，而不是阈值没调好。
推理优化方面，我们用ONNX导出加INT8量化，硬件选择边缘盒子而不是纯CPU服务器。量化之后模型体积缩小约四分之三，推理帧率从十几帧提升到三十帧以上，精度损失控制在可接受范围。夜间红外模式下图像噪声很大，我们专门在训练集里加入红外图像增强样本，并调整了预处理阶段的对比度归一化参数，否则夜间漏检会很严重。
3.4 人员安全模块怎么和生猪功能共用算力
人员安全管理不是完全独立的一套系统，它可以和生猪功能跑在同一个摄像头画面里，共用边缘端算力。人员检测模型比猪只检测简单，类别少、尺度相对固定，但难点在于几点：一是人员可能穿着和猪舍环境相近的防护服；二是人员在走动时存在大角度姿态变化；三是安全帽、反光背心这些细粒度属性识别，需要单独训练分类头。
我们的实现方式是让检测模型多输出一个通道，同时检测猪和人员，然后对人员框额外做属性识别。属性模型判断是否佩戴安全帽、是否穿反光背心、是否处于静止或作业状态。电子围栏则是给栏位、喂料通道、消毒区画多边形区域，人员的中心点落入不同区域，再结合时段和动作，就能触发不同规则。比如夜间非作业时段，有人出现在猪舍内，系统会直接报警；有人在栏内操作时，检测到猪只爬上操作人员身体的姿态，也会触发人猪冲突告警。
算力分配上，我们把视频流分级处理：猪只检测和人员检测是每一帧必跑的高优先级任务；行为时序分析降到后台异步跑；安全帽和反光背心属性识别由于动作变化慢，每两秒抽一帧做一次。这样做的原因是边缘端算力有限，什么都实时跑，最后的结果往往是所有任务都时不时卡顿，倒不如给不同任务分配不同帧率，保证关键任务的稳定性。
4. 人员安全管理：从纯监控到主动告警闭环
人员安全这块如果只做到“录像回放”，那它依然是个摆设。真正有用的系统必须形成闭环：感知到事件、判定风险等级、触发告警、通知到人、记录处置结果。我们在模拟项目X里围绕这个闭环做了不少细节设计。
4.1 区域规则引擎，而不是简单画框报警
最开始我们只在屏幕里画禁用区域，一有人进入就报警，结果一天能报几百条，值班人员直接麻木。后来才意识到，安全规则必须结合“时间”和“任务”两个维度。例如，喂料时段饲养员进入栏内是正常工作，不应该报；但凌晨两点非作业时段出现在栏内，就需要高优先级告警。消毒区在人员完成清洗流程前进入是违规，但清洗流程中的短暂出现在画面中央是正常动作，算法需要配合门禁状态来判断。
所以我们在算法层之上加了一个简单的规则引擎，规则由猪场管理员配置，而不是由算法团队硬编码。规则引擎读入人员轨迹、区域位置、当前时间、门禁状态、作业工单，再输出告警等级。这就是工程上常见的事件驱动架构，具体到养猪场就是“区域+时间+任务”三维判断。这个设计比单独调模型阈值有效得多，也更容易让现场人员理解系统为什么报警。
4.2 人猪冲突和违规作业怎么识别
人猪冲突是我们后来单独加的模块。因为规模化场里饲养员要进栏赶猪、打针、去势、采样，站在猪群里操作时，猪只可能冲撞人腿，也可能突然转身把人绊倒。我们训练了一个姿态匹配模型，同时检测人员关键点和猪只关键点，判断它们之间是否发生快速接近和接触。模型不能做到百分之百精确，但作为辅助告警，只要能在多数冲突前一两秒发出提醒，就能起到实质性的保护作用。
违规作业识别主要靠场景理解。比如在猪舍内发现人员没有穿防护服，或者未戴安全帽，系统会截取这个人员的目标框，保存一张清晰的抓拍图，推送到现场管理端。还有一类是单人滞留：当员工在某个偏僻区域停留过久且没有移动，系统判断可能存在晕倒、被卡住等意外，触发高优先级检查。这一条现场工人反馈特别好，因为以前确实出现过员工在密闭猪舍内因通风不足晕倒的案例。
4.3 告警响应的分层分级，避免狼来了
告警最怕的就是“狼来了”。如果昨天的每一条误报都被当成紧急事件推送到所有人手机上，两三天后就不会有人看通知。我们把告警分成三级：低优先级事件只记录到后台，不弹窗；中优先级推送到当班班组长终端；高优先级才触发现场声光报警并打电话给值班室。误报抑制方面，同一个目标触发同一条规则后，进入一分钟冷却期，避免猪跑动导致连续重复报警。
定期复盘告警日志也很重要。我们发现很多误报来自摄像头抖动、暗角、墙面上的污渍被识别成人脸。这类误报不能在算法层面完全消除，于是我们在摄像头端加了虚拟遮挡区域，把料槽、墙面、排风口这些高频误报区域直接屏蔽掉，大幅降低了有效报警的噪声。这也是“算法+工程”协同的一个典型例子。
5. 落地过程中的真实踩坑与排查速查
这个项目做到后来，大部分时间不是在训练模型，而是在处理各种莫名其妙的问题。下面按问题类型整理一下我们踩过的坑和对应解法，给打算做类似方向的团队一点参考。
5.1 环境干扰类问题
猪舍环境比大多数工业场景恶劣得多。最大的问题是水汽和粉尘附着在镜头罩上，画面模糊但人眼不容易察觉，因为只是边缘泛白。我们为此加了镜头洁净度监测：周期性计算图像清晰度指标，指标低于阈值就提示现场保洁。第二大类是光照剧烈切换，晴天上午阳光从窗户直射进来，画面过曝，猪只糊成一片；我们加强了宽动态摄像头的选型，并在训练数据里专门加了过曝样本，让模型别对高光区域太敏感。还有一个容易被忽视的是风扇、排风管道等设备的周期性遮挡，它们会把猪分割成碎片，需要在数据标注时把它们标记为可忽略区域，而不是硬让模型去识别。
5.2 计数不准的排查思路
计数不准通常不是算法单点问题，而是整个链条中多个环节共同作用的结果。我们从这几步开始排查：先看视频流是否有丢帧，丢帧会导致追踪ID断裂；再看检测阈值是否过高，导致小目标被过滤；再看栏位出入口虚拟线的位置是否和实际路径匹配，猪在虚拟线附近来回徘徊会重复计数；最后看追踪算法的最大丢失帧数是否设置得太短，因为猪从画面边缘走出去再走进来，中间间隔可能超过默认值。按这个顺序排查，大部分计数偏差都能定位到参数配置上，而不是要重新训练模型。
5.3 行为识别误判的典型场景
趴卧和死亡的误判是我们在项目中最头疼的一件事。猪躺着不动，如果长时间没有微动，模型很容易把它判成异常个体，但猪的正常深度睡眠也能维持很久。我们的解法是引入“微动检测”，在检测框内计算亚像素级别的变化量，只要猪还有呼吸起伏，微动指标就不会归零。呼吸极其微弱的晚期病猪确实测不到，但那种情况人工介入已经不算误报。另一个高频误判是争抢饲料，多只猪挤在料槽前，进食行为的置信度很低，模型有时会误判成争斗。我们后来给争斗行为加了“持续快速位移”的约束，猪群抢料时虽然位置密集，但单头猪的位移幅度不大，与真正的追逐打斗有明显差异。
5.4 部署运维阶段的高频故障
运维阶段的问题集中在网络、电源和模型更新。猪场电网电压波动大，偶然断电导致边缘盒子文件系统损坏，系统起不来，我们后来全换了带断电保护的存储方案，并加了看门狗脚本，死机自动重启。网络方面，多路视频同时上传会挤占带宽，我们在边缘端做了流媒体代理，把多路RTSP拉流统一汇聚，再由云端定时拉取关键图片和告警数据，而不是实时传所有视频。模型更新也踩过坑，直接在运行中替换模型文件会导致显存泄漏，必须设计成冷切换：先把新版模型加载到申请好的新内存区，再在推理服务里做原子切换。这些看起来和算法无关，但任何一个环节掉链子，系统整体照样不可用。
6. 后续演进：第10542期之后的迭代方向
第10542期不是终点，它只是整个数据集迭代体系里的一个节点。我们的经验是，智慧养殖项目不能按照“一次性交付”的思路去做，必须设计成持续迭代的体系。
6.1 难例回流和主动学习
每一版模型上线后，我们都会把系统的预测结果与人工复核结果做比对，把预测错误的帧自动打上“难例”标记，回收到待标注池。下次数据采集时，优先让标注人员处理这批难例，而不是随机抽帧。这个机制看起来简单，却是数据集质量持续提升的核心。主动学习还可以更激进，直接用模型的不确定性采样选取最难的那批样本，优先标注，让每一次标注投入都花在刀刃上。
6.2 个体档案、生长曲线与联动控制
数据集持续积累后，可以做的就不只是检测和行为分类了。同一个追踪ID在多日内反复出现，可以逐步累积出个体行为档案，比如某头猪的进食时长、活动量、趴卧比例。把这些指标做成趋势曲线，就能在猪只表现出异常行为之前，先发现它的日常规律出现偏移。再进一步，还可以和喂料器、环控设备联动：当某栏猪只活动量整体降低，系统自动降低该栏的通风强度或通知兽医检查，形成数据到控制的闭环。这些都是第10542期数据长期积累后必然延伸出的价值。
6.3 给同类项目团队的三条建议
第一，先做数据集工程，再养算法团队。没有规范的数据集和标注流程，算法工程师只能做无米之炊，出了效果问题都不知道该怪模型还是怪数据。第二，不要追求算法全覆盖，先选三到五个最高频场景做到高可用。第三，部署前一定要做一次现场网络和硬件的巡检，算法团队很多时间浪费在环境适配，而这些完全可以在前期用一份检查清单规避掉。
结语
回头再看这个项目，最深的感受是：在一线做智慧养殖，真正难的不是某个模型的精度，而是把数据、算法和现场管理拧成一根绳。猪只行为识别数据集第10542期，听起来只是一个版本号，但它背后是一套完整的采集、清洗、标注、迭代机制，而计数、行为监测和人员安全管理这些功能，只是这套机制浮出水面的结果。如果你也在做类似的方向，我建议你先花一半精力把数据流程跑扎实，再开始碰模型，后面你会发现所有算法问题都变得可解释、可追踪、可持续改进。这是我在这类落地项目里最想分享的经验，也是我下一次做类似系统时，会从第一天就开始坚持的做法。
