做野生动物监测这行快十年了从最早的“布红外相机、人工翻照片”到后来用Faster R-CNN做半自动识别再到今天用YOLO全家桶配合前后端分离架构做一套能实际落地的检测系统技术栈换了一茬又一茬。最近花了几周时间把基于YOLOv8/v10/v11/v12四代模型 SpringBoot 千问 DeepSeek 的野生动物检测系统完整打通了从数据标注、模型训练、后端接口到Web交互界面都跑通了全套流程。这套系统解决的核心问题其实很简单生态保护区和研究机构积累了大量红外相机、野外摄像头拍回来的素材人工审核效率太低而且专家资源稀缺。让模型先做一轮初筛把包含野生动物的片段挑出来再丢给大模型做物种识别和行为描述最后在Web界面上由人来做二次确认这样整个工作流能压缩到原来几十分之一的时间。适合的人群也很明确做动物生态研究的课题组、保护区信息化建设的技术人员以及想拿YOLO和SpringBoot练手做完整项目的开发者。整个过程踩了不少坑尤其是YOLO多版本部署、前后端跨域联调、大模型API接入这几个环节每一个都有不少细节值得记录。这篇文章把我的完整方案、关键代码和踩坑记录都整理出来想自己搭一套的可以直接照着走。1. 系统整体设计与模型选型思路1.1 四代YOLO模型的定位差异项目标题里写了YOLOv8/v10/v11/v12很多人会问到底该用哪个我的做法不是只选一个而是把这四个版本都训了用同一份测试集做对比评估生产环境根据现场算力动态切换。这样做的原因在于——野生动物监测场景太复杂根本没有哪个模型能通吃所有情况。先说结论。YOLOv8是当之无愧的“稳定王”Ultralytics官方维护文档全、社区大、部署资料多训练参数踩坑成本最低不管什么规模的团队拿它做基线版本几乎不会出错。YOLOv10最核心的改进是去掉了NMS非极大值抑制推理速度提升非常明显在边缘设备比如Jetson Orin上跑的时候延迟能比v8低一截这对需要实时监测的河道、路口场景很有价值。YOLOv11在Backbone主干网络里加入了C3k2模块特征提取能力更强小目标的召回率通常比v8好不少而野生动物监测恰恰是典型的小目标场景——动物在画面里往往只占几十个像素。YOLOv12的最大变化是引入了区域注意力机制在复杂背景比如树林、草丛遮挡下的检测精度有明显优势但代价是对显存的消耗更高。选型逻辑很清晰不追求“用最新”而是看现场硬件和拍摄条件来决定用哪个权重文件做推理。四个模型共用同一套数据接口和输出格式切换到哪个版本只是改一个配置项的事这也是为什么我在系统设计上把模型推理做成了独立的服务层。1.2 系统架构与前后端分离设计系统的主体架构采用 SpringBoot Vue 前后端分离模式后端负责模型推理调用、数据持久化、大模型智能分析对接前端只负责交互展示和结果确认。具体分层是这样的层级技术选型职责前端展示层Vue3 Element Plus ECharts图片/视频上传、检测结果展示、物种分布图表、人工审核后端服务层SpringBoot 3.x MyBatis-Plus Redis业务接口、权限管理、任务队列、数据缓存、大模型调用模型推理层Python FastAPI YOLOv8/v10/v11/v12图片/视频目标检测输出标准JSON结果数据存储层MySQL MinIO对象存储元数据、检测记录、标注数据、图片素材存储模型服务外部接口千问API DeepSeek API物种识别、行为分析、生成检测报告文本前后端分离不是赶时髦而是因为这套系统的用户分两类一类是保护区管理员他们主要用Web界面做日常审核另一类是算法工程师他们需要直接调用模型接口做批量测试。把后端做成REST API前端独立部署两头都能兼顾。后端和模型推理服务之间用HTTP协议通信因为模型推理是Python生态的强项而SpringBoot负责业务编排。如果硬要在Java里调ONNX Runtime也可以但后续换模型、调超参数这些实验阶段的事情会非常痛苦。用FastAPI包一层每次模型更新只需要重新加载权重文件。1.3 为什么需要大模型分析千问 DeepSeek 分工最初的设计里检测结果只是输出“动物类别 置信度 边界框坐标”但实际使用中发现这个信息量不够。保护区的专家看到“鹿科 0.87”这个结果还是会问是白唇鹿还是马鹿是独自活动还是集群有没有受伤迹象所以我在架构里引入了两层大模型分析。第一层用千问做物种细分类和特征描述——毕竟千问在多模态理解上积累了不少中文生态语料对“角型”“毛色”“体型比例”这类特征的识别更细腻。第二层用DeepSeek做行为分析和报告生成——DeepSeek在长文本生成和逻辑推理上表现更好适合把检测结果组织成结构化的监测记录。这套设计跑起来之后效果非常理想。原始检测是“找到动物在哪”大模型分析是“告诉用户这是什么动物、在做什么、是否需要关注”信息量上升了一个维度系统也从“检测工具”变成了“监测助手”。两条模型链路全部通过后端API网关接入后续如果要换成其他大模型服务只需要修改适配层就行了。2. 野外数据集的获取、清洗与标注2.1 数据来源与KITTI标注转换野生动物检测最大的门槛不是模型而是数据。公开的野生动物数据集其实不少比如公开的物种影像数据集如Wildlife数据集、Serengeti数据集但大部分公开数据的采集场景和我们实际部署的保护区环境差异很大直接拿来训练的效果往往不理想。我采用的是“公开数据集预训练 本地数据微调”的策略。先用通用目标检测数据集COCO和公开野生动物数据集做预训练让模型具备基础的目标检测能力再用保护区自己积累的红外相机照片做微调。这个方案的好处是几百张高质量的本地数据就能达到可用的精度不用从零开始攒上万张标注图。这里有个很实际的问题网上能找到的不少公开数据是KITTI格式尤其是之前做自动驾驶动物避障的团队分享的数据而YOLO训练需要的是txt格式的归一化坐标。很多同事第一次处理就在这里卡住了KITTI的标注是“类别 x1 y1 x2 y2”这种绝对坐标YOLO是“类别 cx cy w h”且全部归一化到0-1之间。转换逻辑其实很直接import os def kitti_to_yolo(kitti_line, img_w, img_h): parts kitti_line.strip().split() cls_name parts[0] x1, y1, x2, y2 map(float, parts[4:8]) # 确保边界框在图像范围内 x1 max(0, min(x1, img_w - 1)) y1 max(0, min(y1, img_h - 1)) x2 max(0, min(x2, img_w - 1)) y2 max(0, min(y2, img_h - 1)) # 转为YOLO格式 cx ((x1 x2) / 2) / img_w cy ((y1 y2) / 2) / img_h w (x2 - x1) / img_w h (y2 - y1) / img_h return f{cls_name} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}转换之后的txt文件要和图片同名并放在对应的labels目录下目录结构必须符合YOLO训练的约定否则训练脚本会直接报错找不到标签。我给团队的标准化方案是dataset/ ├── images/ │ ├── train/ # 训练图片 │ └── val/ # 验证图片 └── labels/ ├── train/ # 训练标签txt └── val/ # 验证标签txt2.2 数据清洗剔除“废片”比标注更重要野生动物监测数据有个特点真正包含动物的图片可能只占总量的5%到10%大量素材是空镜头、植物晃动、空地和天气变化。如果用未清洗的数据直接训练模型会花大量学习能力在“背景识别”上而且正负样本极度不平衡会导致训练不稳定。我的清洗策略分两步。第一步写脚本做初筛计算图像间的差分把连续变化极小的静态图片剔除再用一个现成的高召回模型哪怕先用YOLOv8的通用权重跑一遍把置信度高于0.1的图全部挑出来作为候选集。第二步人工确认把候选集按序列抽帧成九宫格拼图交给熟悉当地物种的研究生快速打标确认“有没有动物”。实际经验是清洗出一个1000张可用图片的数据集比直接标注5000张未清洗数据的效果要好得多。因为模型不需要花大量参数拟合那些没有目标的图片收敛速度快了最终精度也更高。2.3 标注要点类别合并与遮挡样本处理野生动物标注和通用物体标注有几点很不一样。第一物种类别要慎重划分。很多物种在外观上非常接近比如几种鹿类、几种雉类在低分辨率红外相机下很难区分。我的做法是先合并成“类群标签”比如“鹿类-大型”“鹿类-小型”“雉类”让模型先学会分辨类群再交给大模型做物种细分。这样既保证了检测精度又把细分类的任务交给了文本能力更强的千问模型。第二遮挡样本不能漏。野生动物经常躲在灌木丛后面只露出半个身体。这类样本必须标而且边界框要尽量贴合可见部分不要把遮挡物也框进去。一开始标注员习惯性地把整个动物“脑补”完整标一个框导致模型学了一堆错误特征。后来我在标注规范里明确规定遮挡超过40%的动物不标框只在图片级标签里记录存在该物种。3. YOLO训练实战与损失函数理解3.1 训练环境配置与显卡兼容性先回答很多人问的问题AMD RX 580这种老显卡能不能跑YOLOv8答案是可以但有个前置条件——需要PyTorch的DirectML版本或者Linux下用ROCm。Windows下直接用官方PyTorch CUDA是跑不起来的AMD显卡不认CUDA。我测试过用RX 580通过DirectML跑YOLOv8s推理一张640x640的图片大约需要200ms左右勉强够用但训练就别指望了速度会慢到无法接受。项目实际训练是在一块RTX 4090上完成的YOLOv8m训练了300个epoch大概耗时18个小时。如果显卡显存不够有几个优化手段开启梯度累积将batch size设为4、累积步数设为8等效于batch size 32的效果开启混合精度训练AMP显存占用能降低约30%用YOLOv8n或YOLOv8s这种小模型先跑通整个流程再换大模型精调3.2 三块核心损失函数详解训练YOLO模型绕不开三个损失目标框回归损失Box Loss、分类损失CLS Loss和分布焦点损失DFL。理解它们是对症下药优化模型的前提。YOLOv8之后的版本目标框回归损失用的是CIoU Loss而不是原始的IoU Loss。CIoU在IoU的基础上考虑了边界框中心点距离、宽高比一致性公式看着复杂核心思想就是两个框即使IoU值相同中心点距离更近、宽高比更接近的那组应该获得更好的损失值。这在实际场景里的意义是对于红外相机中常见的远景小目标CIoU能更准确地引导模型回归到目标中心。分类损失用的是BCE二分类交叉熵的变体每个类别独立做二分类。很多人会问为什么不用多分类的Softmax交叉熵因为一个检测框同时属于多个类别在动物场景里并不少见——比如“幼崽”和“鹿科”可以同时成立。BCE让每个类别互不排斥模型可以输出多个标签的置信度。DFLDistribution Focal Loss是YOLOv8引入的一个重要改进它把边界框坐标的回归从“直接预测一个值”改成了“预测一个概率分布”然后用期望值作为最终坐标。这样做的好处是模型能表达坐标预测的不确定性——对于严重遮挡的动物边界框坐标本身就不确定DFL允许模型输出一个更分散的分布而不是强行给一个可能完全错误的精确值。训练时如果发现验证集上的Box Loss特别高优先检查标注框的准确性如果CLS Loss高多检查类别不平衡问题DFL Loss一直降不下来大概率是数据里有大量标注不一致的边界框。3.3 多版本模型训练与评估对比我在同一份数据集上完整训练了YOLOv8m、YOLOv10m、YOLOv11m和YOLOv12m四个模型输入分辨率统一设为640x640训练300轮其他超参数保持一致。最终测试集800张人工标注图上的对比结果如下模型精度mAP0.5小目标AP0.5推理耗时(ms)显存占用(GB)YOLOv8m0.8720.68118.36.2YOLOv10m0.8610.66715.16.0YOLOv11m0.8840.70219.66.8YOLOv12m0.8910.71523.47.5实际测试下来YOLOv12在整体精度和小目标上的优势确实明显但推理耗时和显存消耗也最大。YOLOv11则是最均衡的选择精度接近v12速度比v8还快一些。YOLOv10的优势主要体现在批量推理场景——去掉NMS之后连续处理视频帧时吞吐量更高。项目里的模型调度策略是默认使用YOLOv11m权重做图片检测因为大多数监测场景是离线分析不需要最低延迟如果后续要用在河道实时告警这种场景切换成YOLOv10m把推理服务部署到边缘盒子就行夜间红外图片大量出现时需要更高精度切换到YOLOv12m配合下面的推理优化策略。4. SpringBoot后端服务与模型推理整合4.1 后端工程结构与核心配置后端整体采用标准的SpringBoot分层架构Controller层只做参数校验和结果返回Service层负责业务逻辑Mapper层用MyBatis-Plus操作数据库。模型推理不在Java进程内做而是通过HTTP调用Python FastAPI服务这个决策在后来的模型迭代中省了巨大的工作量。application.yml里有几个地方要特别注意。第一是文件上传大小限制需要调大红外相机图片动辄10MB以上SpringBoot默认的1MB根本不够spring: servlet: multipart: max-file-size: 100MB max-request-size: 200MB第二是大模型API的Key不要明文写在配置里yaml里的密文处理是安全底线。我用的是jasypt加密组件配置里只存密文启动时通过环境变量传入解密密钥jasypt: encryptor: password: ${JASYPT_SECRET} algorithm: PBEWithMD5AndDES第三是接口层要做超时控制。大模型推理通常需要几秒钟但也不能无限等待我用Spring的Async Future配合设置5秒超时超时就直接返回检测结果给前端大模型分析结果通过WebSocket异步推送不让用户干等。4.2 Java与Python模型服务的HTTP通信设计因为前后端分离Java调用Python模型推理服务时我用的是RestTemplate的轻量封装但针对实际场景做了一些调整。推理接口设计成同步阻塞方式图片以Base64编码传给Python服务Python返回JSON格式的检测结果。下面是Python端的FastAPI接口核心代码from fastapi import FastAPI, UploadFile import cv2 import numpy as np from ultralytics import YOLO app FastAPI() # 模型仓库配置时可切换不同版本的权重 models { yolov8m: YOLO(weights/yolov8m_wildlife.pt), yolov11m: YOLO(weights/yolov11m_wildlife.pt), yolov12m: YOLO(weights/yolov12m_wildlife.pt), } app.post(/detect) async def detect(image: UploadFile, model_name: str yolov11m): contents await image.read() nparr np.frombuffer(contents, np.uint8) img cv2.imdecode(nparr, cv2.IMREAD_COLOR) model models.get(model_name, models[yolov11m]) results model.predict(img, conf0.25, iou0.45, verboseFalse) detections [] for r in results: for box in r.boxes: x1, y1, x2, y2 box.xyxy[0].tolist() conf float(box.conf[0]) cls int(box.cls[0]) detections.append({ bbox: [x1, y1, x2, y2], confidence: round(conf, 4), class_id: cls, class_name: model.names[cls] }) return {detections: detections, model: model_name}通信时有一个容易踩的坑是传输超时。长图或者高清大图的检测耗时可能会超过默认的30秒请求超时所以Java端自定义了RestTemplate的连接池和超时参数Bean public RestTemplate restTemplate() { SimpleClientHttpRequestFactory factory new SimpleClientHttpRequestFactory(); factory.setConnectTimeout(5000); factory.setReadTimeout(60000); // 模型推理允许更长时间 return new RestTemplate(factory); }4.3 检测结果的存储与缓存设计检测结果不是直接存MySQL的而是先存一份JSON到Redis再异步写入MySQL。这是因为前端Web界面在展示检测结果时需要频繁查询和分页MySQL扛不住高频率的写读混合请求。我的方案是图片上传后先写一条“检测中”的任务记录到MySQL检测完成后把完整结果JSON写入Redis缓存key为任务ID过期时间设为24小时同时异步更新MySQL中的状态字段。前端轮询任务状态时优先查Redis只有在Redis不存在时才查MySQL。这个设计在业务高峰期效果很明显。保护区一个批次可能上传上千张图片如果每张图片都实时写MySQL数据库压力非常大。采用缓存优先的策略之后MySQL的写入量降低了80%查询响应时间控制在200ms以内。5. 千问 DeepSeek 智能分析模块5.1 大模型API接入与结构化输出智能分析是本系统区别于普通目标检测项目的核心功能。目标检测模型只能回答“这里有什么”而保护区管理员真正关心的是“这是什么物种、在做什么、是否需要处理”。千问和DeepSeek分别承担不同的分析任务。以千问做物种细分类为例检测模型输出的类别是“鹿类-大型”千问接口根据裁剪出来的目标区域图片和提示词输出具体的物种信息和特征描述。核心是设置JSON格式的输出约束这里我踩过一次很深的坑——不约束输出格式时大模型会返回各种幺蛾子文本有的还带一堆解释跟代码里期望的字段对不上。我用了“system prompt JSON Schema”的组合system_prompt 你是一名野生动物识别专家。请根据输入图片识别其中的野生动物物种并严格按照JSON格式输出 { species: 识别的物种名称, confidence: 把握程度值为high/mid/low, features: [特征1, 特征2, 特征3], behavior: 观察到的行为描述, alert: 是否需要人工关注true/false } 注意只输出JSON不要添加任何解释文字。 DeepSeek那边则负责更复杂的监测报告生成。我会把一批图片的检测结果聚合起来连同保护区的地理位置、拍摄时间范围、物种信息一起发送给DeepSeek让它生成一份结构化的监测报告包括物种数量统计、种群活跃时间段、异常行为告警等内容。5.2 批量检测场景的大模型调用优化野生监测通常是批量任务一个批次可能几百张图片。如果每张图片单独调用一次大模型API费时长不说费用也很可观。我做了一个聚合策略先把所有图片的检测结果汇总成表格再一次性发给大模型做批量分析。具体做法是把同一时间段、同一监测点位、检出同一类群的图片合并成一组每组只调用一次大模型接口。比如“2025年4月点位3号检出鹿类-大型共12张图置信度最高0.92”大模型基于这个结构化摘要结合红外相机图片生成分析结论。实测下来API调用次数减少了约70%整体分析成本大幅下降分析质量并没有明显降低。5.3 双模型交叉验证机制大模型存在“幻觉”问题把不存在的动物说得有模有样。我在系统里加了一个交叉验证机制千问识别出的物种会与DeepSeek根据上下文判断的结果做比对如果两者不一致系统会把这个结果标记为“存疑”推送到前端等待人工审核。这个机制在测试中被验证了价值——有次千问把一只岩羊误识别为“山羊”但DeepSeek检查上下文时发现“监测点位位于海拔3500米以上的高山裸岩区山羊出现概率极低”给出了“存疑”的标记。人工复核时发现确实是岩羊幼崽。这个交叉验证机制让系统的可信度提升了一个档次保护区那边也愿意拿它做辅助决策了。6. Web交互界面与前后端联调6.1 前端核心页面设计前端用Vue3 Element Plus搭建核心页面分三块。第一块是“实时监测大屏”。页面轮询后端接口定时获取最新检测任务的状态和结果用ECharts展示近期各物种出现的频次分布、点位热力图和置信度分布图。保护区管理人员打开这个页面一分钟内就能知道当天哪些点位有动物活动。第二块是“图片检测工作台”。用户上传单张或批量图片上传后前端把图片加入检测队列通过WebSocket监听检测进度实时展示每张图片的检测状态。检测完成后页面左侧显示原图并叠加检测框用Canvas绘制不同物种用不同颜色右侧显示检测结果列表和千问的物种分析、DeepSeek的行为描述。第三块是“人工复核页面”。这是实际工作中最重要的界面检测结果和AI分析按置信度从低到高排序置信度低和有“存疑”标记的结果排在最前面人工只需要重点看这部分。复核通过的结果自动进入正式数据库被否决的结果会回传记录作为后续模型迭代的负样本。6.2 跨域联调与WebSocket推送前后端分离联调时最常见的坑就是跨域。开发环境我用前端代理解决// vite.config.js export default { server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }生产环境则用Nginx配置反向代理把前端静态资源和后端API都代理到同一个域名下彻底规避跨域问题。WebSocket推送是整个交互体验的关键。检测任务和大模型分析都是异步的如果前端靠轮询去拿结果实时性差而且白白消耗服务器资源。我用SpringBoot的WebSocket STOMP协议实现了服务端主动推送任务状态变化时后端主动广播给订阅了该任务的前端页面。实际测试下来从Python推理服务返回结果到前端界面刷新展示延迟能控制在1秒以内体验很流畅。6.3 前后端接口约定与权限管理给团队定了Http接口规范所有接口统一返回{code, message, data}结构分页统一用page, pageSize参数错误码统一用4位数字编码。这个约定让前端处理异常非常省心——只有当code 0时才正常渲染其他情况统一弹提示框。权限管理用的是Sa-Token框架支持基于角色的访问控制。保护区管理员、普通科研人员、模型管理员三个角色看到的功能模块不一样。比如普通科研人员只能查看检测结果和自己的复核记录模型管理员才能触发模型重训练和权重版本切换。这块在生产环境非常重要保护区的数据通常涉及珍稀物种的具体点位不能随便开放给所有账号。7. 部署上线与常见问题排查实录7.1 服务器部署方案与一键启动脚本整个系统最终部署在一台阿里云ECS上配置是8核16GB内存 一块RTX 3060显卡。后端SpringBoot打成jar包、前端build成静态文件、Python推理服务用Gunicorn Uvicorn启动三部分各自独立运行。部署时我写了一个一键启动脚本把三个服务的启动、日志查看、异常重启整合到一起。核心脚本逻辑如下#!/bin/bash # 启动后端 nohup java -jar wildlife-backend.jar --spring.profiles.activeprod logs/backend.log 21 # 启动模型推理服务 nohup uvicorn model_server:app --host 0.0.0.0 --port 9000 logs/model.log 21 # 启动前端Nginx systemctl restart nginx echo 所有服务已启动这个脚本最大的价值是让新手也能独立完成部署。保护区那边负责运维的同事可能不懂Java也不懂Python但照着脚本和README就能把服务拉起来。7.2 五个高频问题与排查记录整个开发过程里我记录了很多问题的排查过程挑最常见的五个连同解决方案一起写出来问题一模型推理时出现 BrokenPipeError。原因是Java端等待超时主动断开了连接但Python端还在处理图片。解决方法把Java端RestTemplate的readTimeout调大同时在Python端用asyncio.wait_for给推理任务设置逻辑超时避免线程被长时间占用。问题二YOLOv12用ONNX导出后推理报错提示不支持的算子。原因是YOLOv12引入了新的注意力机制算子旧版ONNX Runtime不兼容。解决方法升级ONNX Runtime到2.0以上版本截至2025年中旬的较新版本或者干脆不导出ONNX直接用PyTorch模型做推理虽然慢一点但稳定。问题三类别不均衡导致稀有物种检测效果差。数据集中“岩羊”有3000张“雪豹”只有150张训练后雪豹的召回率只有30%。我用了两条腿走路的方案一是数据增强对雪豹样本做随机裁剪、亮度变化、旋转等操作扩展到600张二是引入Focal Loss思想提高模型在稀有类别上的学习权重。问题四上传高清大图时后端处理速度特别慢。排查发现瓶颈不在模型推理而在图片读取。红外相机原图是5000x3000像素用OpenCV读取就花了上百毫秒。解决方案上传后先用thumbnailator生成一张1280px宽度的预览图用于展示和检测原图存到MinIO做归档需要精确定位时再调用原图接口。问题五SpringBoot版本过高导致Nacos注册不上去。项目刚开始用SpringBoot 3.3搭配旧版spring-cloud-alibaba结果服务启动正常但服务列表里看不到。排查后发现是版本兼容矩阵的问题。解决方案很简单去官方版本说明里查对应的版本组合锁定SpringBoot 3.2.x spring-cloud-alibaba 2023.0.x组合问题立刻解决。7.3 从实际项目中总结的系统优化心得整套系统跑通之后我最大的感受是技术选型固然重要但真正决定项目成败的是数据治理和流程设计。数据治理方面我把所有训练数据、标注文件和模型权重都建立了版本管理。每次模型迭代训练前先冻结当前数据集版本训练完成后把评估指标和数据集版本号一起记录到模型管理表里。这样如果新模型效果反而变差能很快回退到之前的版本不会出现“模型越改越烂但找不到原因”的尴尬。流程设计方面系统里内置了一条“自动检测 → AI分析 → 人工复核 → 数据归档 → 定期重训”的完整闭环。模型检测出的低置信度样本和人工复核被否决的样本都会自动进入一个“难例库”积累到一定数量后触发增量训练。这个闭环让系统上线后的效果越来越好第一周可能还需要人工检查所有结果到第三周的时候人工需要处理的量已经降到了总量的一成左右。个人觉得这类系统后续还可以往三个方向发展一是接入视频流处理对红外相机视频做实时检测和行为分析二是把声纹识别加进来有些物种听觉特征更明显三是做跨保护区联网共享不同保护区之间的模型可以互相学习共同提升识别能力。技术层面其实都可行关键还是看实际的业务需求往哪里走。