企业官网建设流程全解析

1. 项目概述：在树莓派5上用Hailo AI加速帽跑自定义YOLO数据集，全程容器化

你有没有试过在树莓派上部署一个自己标注的YOLO模型，结果发现CPU吃满、帧率卡在3fps、推理延迟动辄800ms，热得外壳发烫还报温控降频？我去年就卡在这个死循环里——标了2700张工地安全帽图像，训练好YOLOv8n，一上树莓派4B就崩。直到把整套流程搬到树莓派5 + Hailo-8L AI加速帽 + Docker环境后，事情才真正转机：端到端推理耗时从760ms压到42ms，功耗稳定在3.8W，连续跑48小时无掉帧，且整个部署过程可版本化、可复现、可迁移到其他边缘设备。这个标题里的四个关键词——Custom dataset（自定义数据集）、Hailo AI Hat（Hailo-8L边缘AI加速模块）、YOLO（目标检测框架）、Raspberry Pi 5（新一代ARM边缘主控）——不是简单堆砌，而是构成了一条完整的“轻量化AI视觉落地闭环”：你手头有真实场景图片（比如仓库货架、农田虫害、产线缺陷），你用LabelImg或CVAT标好，你训练出轻量模型，你把它烧进一块插在树莓派5 GPIO口上的Hailo加速帽里，再用Docker封装成服务，对外提供HTTP或MQTT接口。它不追求云端大模型的精度，但要稳、要快、要省电、要能塞进配电箱、能扛住-10℃冷库、能连4G模组离线运行。这不是玩具项目，是我在三个工业客户现场落地的真实方案：某冷链仓储公司用它实时统计托盘堆叠层数；某光伏板厂用它识别组件隐裂；某畜牧场用它监测牛只体况评分。下面所有内容，都来自这三套系统上线后的日志、温感记录、Docker镜像构建失败截图、Hailo编译报错堆栈，以及反复拆焊Hailo Hat排线留下的烙铁印。

2. 整体架构设计与技术选型逻辑

2.1 为什么必须是树莓派5而不是树莓派4或Jetson Nano？

很多人第一反应是“直接上Jetson”，但实际踩坑后你会发现：Jetson Nano的128核Maxwell GPU在YOLOv5s上实测FPS仅11.3（INT8），且TDP高达10W，散热必须配风扇+铝壳，体积直接翻倍；而树莓派5的Broadcom BCM2712（Cortex-A76 @ 2.4GHz + VideoCore VII GPU）单核性能比Pi4提升2倍，内存带宽翻倍至40GB/s，最关键的是——它原生支持PCIe 2.0 x1通道。Hailo-8L AI Hat正是通过这条PCIe通道与主控通信，理论带宽2GB/s，远超USB3.0（5Gbps）或MIPI（1.5Gbps）。我们做过对比测试：同一YOLOv8n模型，在Pi5+Hailo下端到端延迟42ms；在Pi4+Hailo（走USB转接桥）下延迟跳到118ms，且USB控制器频繁触发DMA timeout错误。更现实的是成本：Pi5（4GB版）官方售价35美元，Hailo-8L Hat 129美元，总成本164美元；Jetson Orin Nano（8GB）起步价199美元，还不含散热和电源。另外，Pi5的GPIO引脚定义完全兼容Pi4，意味着你现有的继电器模块、温湿度传感器、4G模组可以直接复用，不用重写驱动。我们给冷链客户部署时，直接把旧Pi4的整个外壳、电源、SIM卡座、RS485转接板全搬过去，只换主板和Hailo Hat，30分钟完成升级。

2.2 为什么Hailo-8L是当前树莓派生态最务实的AI加速选择？

市面上能插在树莓派上的AI加速模块还有Google Coral USB Accelerator、Intel Neural Compute Stick 2，但它们存在硬伤：Coral依赖Edge TPU，只支持TensorFlow Lite模型，YOLO需先转TFLite再做Post-processing，我们实测其NMS（非极大值抑制）部分在Pi5 CPU上跑，反而成了瓶颈；NCS2基于Myriad X VPU，驱动已停止更新，Ubuntu 22.04内核下常出现USB enumeration failure。Hailo-8L不同——它提供完整的HailoRT SDK，原生支持ONNX模型，YOLO系列只需导出为ONNX（无需修改网络结构），Hailo Compiler会自动完成图优化、算子融合、内存布局重排。更重要的是功耗控制：Hailo-8L典型功耗1.8W，峰值2.3W，而Pi5整机待机功耗仅2.1W，两者叠加总功耗<4.5W，一块10000mAh移动电源就能撑36小时。我们用Fluke Ti400热像仪实测：Pi5+Hailo满载运行时，SoC表面温度48.3℃，Hailo芯片本体51.7℃，远低于70℃温控阈值。反观Coral，USB接口处温度常达62℃，导致Pi5 USB控制器过热降速。还有一个隐形优势：Hailo提供Hailo Model Zoo，里面预置了YOLOv5/v8/v10的量化参考模型，连anchor配置、输入尺寸、输出解析逻辑都给你写好了，我们直接拿YOLOv8n_coco.onnx改两行参数就跑通，省了至少两天调试时间。

2.3 为什么坚持用Docker而不用systemd service裸跑？

有人觉得“边缘设备资源紧张，Docker是累赘”，但我们的生产实践彻底推翻这个认知。首先，Docker镜像分层机制让模型更新变得原子化：客户现场只需docker pull registry.example.com/yolo-safety-hat:20240615，再docker-compose up -d，旧容器自动停、新容器启动，整个过程<8秒，且零配置漂移。如果裸跑，每次更新都要ssh进去，git pull、pip install -r requirements.txt、python app.py --model /models/v20240615.onnx，稍有不慎就因依赖冲突导致服务起不来。其次，Docker的cgroups限制让资源失控成为历史：我们在docker-compose.yml里明确写死mem_limit: 1.2g、cpus: '0.8'、device_cgroup_rules: ["c 10:57 rwm"]（允许访问Hailo设备节点），这样即使YOLO后处理代码有内存泄漏，也不会拖垮整个系统。最关键是安全隔离——Hailo驱动需要/dev/hailo*设备权限，裸跑意味着app进程拥有root级硬件访问权，一旦被注入恶意payload，可直接读取PCIe配置空间。而Docker通过--device=/dev/hailo0:/dev/hailo0 --cap-add=SYS_ADMIN最小权限授予，攻击面大幅收窄。我们给光伏客户做的渗透测试中，用CVE-2023-28843漏洞尝试提权，裸跑环境100%成功，Docker环境因seccomp默认策略拦截了ioctl调用而失败。

2.4 自定义数据集的边界在哪里？什么该做、什么绝不能做？

“Custom dataset”不是指随便拍100张图就开训。我们定了一条铁律：你的数据集必须能通过“产线验证三问”。第一问：图像是否来自真实部署环境？比如做安全帽检测，就不能只用网上下载的公开数据集，必须包含你客户工地的实际光照（正午强光、阴天漫射、黄昏背光）、遮挡（钢架阴影、吊车臂遮挡）、分辨率（用客户现有监控摄像头拍，而非单反相机）。我们曾因用单反拍的高清图训练，上线后发现工地400万像素IPC拍的图模糊，mAP直接掉18个点。第二问：标注是否符合硬件推理约束？Hailo-8L对输入尺寸敏感，我们强制要求所有图像resize到640×640（YOLOv8默认），但标注框坐标必须按原始分辨率保存，训练前再做等比缩放+padding，否则小目标（如远处安全带卡扣）在缩放后变成1×1像素，模型根本学不会。第三问：类别是否可被Hailo硬件原生支持？Hailo Compiler对某些算子有限制，比如YOLOv8的torch.nn.functional.grid_sample在Hailo上不支持，必须替换成torch.nn.functional.interpolate；又比如sigmoid激活函数在Hailo INT8量化后精度损失大，我们改用hardsigmoid。这些细节不写进数据准备规范，后期编译必然失败。所以我们的custom dataset工作流是：采集→筛选（剔除过曝/欠曝/运动模糊图）→标注（用CVAT，导出YOLO格式txt）→生成Hailo专用label.json（含id映射、颜色编码、置信度阈值）→数据增强（仅用Albumentations的RandomBrightnessContrast和MotionBlur，禁用Cutout，因Hailo不支持动态shape）。

3. 核心细节解析与实操要点

3.1 硬件连接与底层驱动安装：避开PCIe枚举失败的深坑

Hailo-8L Hat插在Pi5的GPIO上，但物理连接只是开始。最大的坑在于：Pi5默认关闭PCIe控制器，且Bootloader未启用ACS（Access Control Services），导致Hailo设备无法被正确枚举。我们花了37小时才定位到这个问题——lspci命令完全看不到Hailo设备，dmesg | grep -i hailo空输出。解决方案分三步：第一步，编辑/boot/firmware/config.txt，在末尾添加：

# 启用PCIe控制器 dtparam=pciex1 # 强制PCIe链路宽度为x1（Hailo仅需x1） pciex1_width=1 # 关闭PCIe ASPM节能（避免链路休眠） pcie_aspm=off

第二步，更新Bootloader：sudo rpi-eeprom-update -a -d，确保版本≥pieeprom-2023-07-18.bin（此版本首次支持PCIe ACS）。第三步，最关键的一步——在/boot/firmware/cmdline.txt中添加内核参数：

pci=assign-busses pcie_bus_safe=on video=HDMI-A-1:1920x1080@60

其中pcie_bus_safe=on强制内核使用保守的PCIe总线分配策略，避免Hailo设备被分配到无效bus号。做完这三步重启，lspci -vv | grep -A 10 "Hailo"终于能看到设备信息。驱动安装则必须用Hailo官方提供的.deb包，绝不能用pip install hailort——因为pip安装的是用户态SDK，缺少内核模块hailo_pci.ko。我们实测过：pip装完后hailortcli device info报Device not found，而sudo dpkg -i hailo-rt_4.18.0-64_arm64.deb后，lsmod | grep hailo显示hailo_pci 123456 0，且/dev/hailo0节点自动生成。这里有个血泪教训：某次客户现场用错.deb包版本（x86_64误装arm64），dpkg安装成功但modprobe hailo_pci报Invalid module format，最后发现是内核头文件版本不匹配，必须先sudo apt install raspberrypi-kernel-headers再重装。

3.2 YOLO模型转换与Hailo编译：ONNX不是终点，而是起点

YOLO训练完得到.pt权重，第一步是导出ONNX。但直接model.export(format='onnx')会出问题：PyTorch导出的ONNX默认用opset_version=17，而Hailo Compiler 4.18仅支持opset 11-15。我们必须显式指定：

model.model[-1].export = True # 强制导出Detect层 torch.onnx.export( model, torch.randn(1, 3, 640, 640), "yolov8n_custom.onnx", opset_version=13, input_names=["input"], output_names=["output0", "output1", "output2"], # YOLOv8的三个输出分支 dynamic_axes={"input": {0: "batch"}, "output0": {0: "batch"}} )

导出后别急着编译，先用Netron打开ONNX文件，检查三点：1）输入节点名是否为input（Hailo要求严格匹配）；2）输出节点是否为三个[1, 84, 80, 80]等张量（对应P3/P4/P5特征图）；3）是否存在ConstantOfShape等Hailo不支持的算子（如有，需在导出前用torch.fx图重写）。确认无误后，进入Hailo编译环节。关键命令是：

hailocpp --input_network yolov8n_custom.onnx \ --output_path yolov8n_custom.hef \ --target hailo8l \ --quantization_calibration_set /data/calib_images \ --quantization_method symmetric_affine \ --input_shape [1,3,640,640]

这里calib_images目录必须放500张真实场景图（非训练集！），且已按cv2.resize(img, (640,640))预处理。我们曾用训练集做校准，量化后mAP掉12.3%，因为训练集过拟合。另一个致命细节：--quantization_method必须选symmetric_affine而非asymmetric_affine，因为Hailo-8L的INT8引擎对称量化更稳定。编译成功后生成.hef文件，但别以为完事了——.hef只是模型二进制，还需配套的.json后处理描述文件。Hailo Model Zoo里有yolov8_postprocess.json，但必须修改三处："input_shape"改为[1,3,640,640]；"num_classes"改为你的实际类别数（如安全帽检测是2：head、helmet）；"confidence_threshold"设为0.45（太低易误检，太高漏检）。我们用jq工具批量修改：

jq '.input_shape = [1,3,640,640] | .num_classes = 2 | .confidence_threshold = 0.45' \ yolov8_postprocess.json > yolov8n_custom_post.json

3.3 Docker镜像构建：如何让Hailo驱动在容器里“看见”硬件

Docker默认无法访问宿主机的PCIe设备，必须做三重穿透。第一步，在Dockerfile里安装Hailo驱动：

FROM balenalib/raspberrypi5-64-debian:bookworm-build # 复制宿主机的Hailo内核模块 COPY hailo_pci.ko /lib/modules/$(uname -r)/extra/ RUN depmod -a && modprobe hailo_pci # 安装Hailo用户态SDK COPY hailo-rt_4.18.0-64_arm64.deb . RUN dpkg -i hailo-rt_4.18.0-64_arm64.deb && apt-get clean

但这样还不够，因为容器启动时hailo_pci.ko可能未加载。第二步，在docker-compose.yml中用init: true确保容器以PID 1启动，并挂载设备：

services: yolo-inference: build: . devices: - "/dev/hailo0:/dev/hailo0:rwm" cap_add: - SYS_ADMIN privileged: false # 严禁privileged，用最小权限 volumes: - ./models:/app/models:ro - ./config:/app/config:ro

第三步，也是最容易忽略的一步：必须在容器启动脚本里显式加载模块。我们在entrypoint.sh里写：

#!/bin/sh # 检查Hailo设备是否存在 if [ ! -c "/dev/hailo0" ]; then echo "ERROR: /dev/hailo0 not found. Loading hailo_pci module..." modprobe hailo_pci || exit 1 fi # 等待设备就绪 timeout 30 sh -c 'until [ -c "/dev/hailo0" ]; do sleep 1; done' exec "$@"

然后在docker-compose.yml中指定：

command: ["sh", "-c", "chmod +x /app/entrypoint.sh && /app/entrypoint.sh python3 app.py"]

这样容器启动时会先检查设备，不存在就加载模块，再等待设备节点生成，最后执行主程序。我们曾因漏掉timeout等待，容器启动快于内核模块加载，导致hailortcli报No device found，日志里全是Failed to open device。

3.4 自定义数据集的推理服务封装：不只是HTTP API

我们的app.py不是简单调用hailort.infer()，而是构建了三层流水线：
第一层：输入预处理管道
接收HTTP POST的base64图像，用OpenCV解码后做cv2.cvtColor(cv2.COLOR_BGR2RGB)，再cv2.resize(..., (640,640))，最后np.transpose(..., (2,0,1))转CHW格式。关键点：cv2.resize必须用INTER_AREA插值（下采样专用），比INTER_LINEAR快17%，且对小目标更友好。

第二层：Hailo推理核心
创建hailo.InferenceRunner实例时，设置batch_size=1（Hailo-8L对batch>1支持不稳定），并启用async_mode=False（同步模式更稳）。推理前调用runner.wait_for_device_ready(timeout_ms=5000)，避免设备忙时直接报错。

第三层：后处理与业务逻辑
加载yolov8n_custom_post.json，用Hailo提供的hailo_postprocess库解析输出。但这里我们加了业务规则引擎：比如安全帽检测，要求“head框必须在helmet框内部，且重叠面积>0.6”，否则过滤掉；又比如光伏板隐裂，要求检测框长宽比必须>3.0（裂纹细长特征）。这些规则写在rules.py里，用Python字节码缓存，避免每次推理都解析JSON。最终输出JSON格式：

{ "timestamp": "2024-06-15T08:23:45.123Z", "frame_id": 12487, "detections": [ { "class_id": 1, "class_name": "helmet", "confidence": 0.92, "bbox": [124.3, 87.6, 189.2, 142.1], "business_rule_passed": true } ], "stats": { "preprocess_ms": 12.4, "inference_ms": 42.1, "postprocess_ms": 8.7, "total_ms": 63.2 } }

这个结构让前端能区分算法延迟和网络延迟，也方便客户做SLA监控。

4. 实操过程与核心环节实现

4.1 从零开始的完整部署流程（含所有命令与参数）

以下是我们给客户交付的标准操作手册，每一步都经过三次现场验证：

步骤1：初始化树莓派5系统

# 刷写Raspberry Pi OS Bookworm 64-bit (2024-03-15) # 首次启动后执行： sudo apt update && sudo apt full-upgrade -y sudo apt install -y git curl wget python3-pip python3-opencv libglib2.0-dev # 启用SSH和I2C（备用传感器） sudo raspi-config # Interface Options → SSH/I2C → Enable

步骤2：配置PCIe与安装Hailo驱动

# 编辑config.txt echo -e "\n# Hailo PCIe config\ndtparam=pciex1\npciex1_width=1\npcie_aspm=off" | sudo tee -a /boot/firmware/config.txt # 更新Bootloader sudo rpi-eeprom-update -a -d # 重启后检查PCIe sudo reboot # 重启后验证 lspci | grep -i hailo # 应输出类似 "01:00.0 Processing accelerators: Hailo Technologies Ltd. Device a001" # 下载并安装Hailo驱动（注意版本匹配） wget https://github.com/hailo-ai/hailo-sdk/releases/download/v4.18.0/hailo-rt_4.18.0-64_arm64.deb sudo dpkg -i hailo-rt_4.18.0-64_arm64.deb sudo apt-get install -f -y # 修复依赖 # 验证驱动 sudo modprobe hailo_pci hailortcli device info # 应显示设备序列号和温度

步骤3：准备自定义数据集与模型

# 创建数据目录 mkdir -p /home/pi/dataset/{images,labels} /home/pi/models # 假设你已有YOLO格式标注（images/xxx.jpg + labels/xxx.txt） # 用脚本生成Hailo校准集（随机抽500张） cd /home/pi/dataset find images -name "*.jpg" | shuf -n 500 | xargs -I {} cp {} /home/pi/calib_images/ # 导出ONNX模型（在训练机上完成，传到Pi5） scp yolov8n_custom.onnx pi@raspberrypi.local:/home/pi/models/ # 在Pi5上编译HEF hailocpp --input_network /home/pi/models/yolov8n_custom.onnx \ --output_path /home/pi/models/yolov8n_custom.hef \ --target hailo8l \ --quantization_calibration_set /home/pi/calib_images \ --quantization_method symmetric_affine \ --input_shape [1,3,640,640]

步骤4：构建Docker镜像

# 创建项目目录 mkdir -p /home/pi/yolo-docker/{app,models,config} # 复制模型和配置 cp /home/pi/models/yolov8n_custom.hef /home/pi/yolo-docker/models/ cp /home/pi/models/yolov8n_custom_post.json /home/pi/yolo-docker/config/ # 编写Dockerfile cat > /home/pi/yolo-docker/Dockerfile << 'EOF' FROM balenalib/raspberrypi5-64-debian:bookworm-build RUN apt-get update && apt-get install -y python3-pip python3-opencv libglib2.0-dev && rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip3 install -r requirements.txt COPY app.py /app/app.py COPY entrypoint.sh /app/entrypoint.sh COPY models/ /app/models/ COPY config/ /app/config/ WORKDIR /app CMD ["python3", "app.py"] EOF # 编写requirements.txt cat > /home/pi/yolo-docker/requirements.txt << 'EOF' hailo-python-sdk==4.18.0 numpy==1.24.4 opencv-python-headless==4.8.1.78 Flask==2.3.3 Werkzeug==2.3.7 EOF # 构建镜像 cd /home/pi/yolo-docker docker build -t yolo-hailo-pi5 .

步骤5：运行服务并验证

# 编写docker-compose.yml cat > /home/pi/yolo-docker/docker-compose.yml << 'EOF' version: '3.8' services: yolo-inference: image: yolo-hailo-pi5 restart: unless-stopped ports: - "5000:5000" devices: - "/dev/hailo0:/dev/hailo0:rwm" cap_add: - SYS_ADMIN volumes: - ./models:/app/models:ro - ./config:/app/config:ro environment: - FLASK_RUN_PORT=5000 - FLASK_RUN_HOST=0.0.0.0 EOF # 启动服务 docker-compose up -d # 验证服务 curl -X POST http://localhost:5000/infer \ -H "Content-Type: application/json" \ -d '{"image_base64": "/9j/4AAQSkZJRgABAQAAAQABAAD/..."}' # 查看日志 docker-compose logs -f

4.2 性能压测与稳定性验证方法

部署完不能只测单帧，必须做72小时压力测试。我们用locust模拟并发请求：

# locustfile.py from locust import HttpUser, task, between import base64 import os class YoloUser(HttpUser): wait_time = between(0.1, 0.5) # 每秒2-10次请求 @task def infer_image(self): with open("/home/pi/test_images/test1.jpg", "rb") as f: img_b64 = base64.b64encode(f.read()).decode() self.client.post("/infer", json={"image_base64": img_b64})

启动压测：locust -f locustfile.py --host http://192.168.1.100:5000 --users 5 --spawn-rate 1。关键监控指标有三个：
1）Hailo设备温度：hailortcli device info | grep "Temperature"，持续高于65℃需检查散热；
2）内存泄漏：docker stats yolo-docker-yolo-inference-1 --no-stream | awk '{print $3}'，24小时内增长超过100MB即告警；
3）推理成功率：curl -s http://localhost:5000/metrics | grep "inference_success_total"，应保持100%。

我们给光伏客户的压测报告：5并发持续72小时，平均延迟63.2ms（含网络），P99延迟89ms，设备最高温58.4℃，内存波动±12MB，无一次失败。当把并发提到10时，延迟升至92ms，但成功率仍100%——说明Hailo-8L的吞吐瓶颈不在计算而在PCIe带宽，这是设计预期。

4.3 故障恢复与热更新机制

生产环境不能停机更新。我们设计了双模型热切换：

• /app/models/active/存放当前运行的.hef和.json；
• /app/models/staging/存放新模型；
• app.py监听/tmp/model_update.flag文件，一旦检测到该文件被touch，立即加载staging目录模型，5秒内完成切换。

具体实现：

# 在app.py中 import threading import time import os def model_watcher(): while True: if os.path.exists('/tmp/model_update.flag'): try: # 原子化切换 os.system('mv /app/models/active /app/models/old_active') os.system('mv /app/models/staging /app/models/active') os.system('rm /tmp/model_update.flag') load_new_model() # 重新初始化runner print("Model hot-swapped successfully") except Exception as e: print(f"Hot swap failed: {e}") time.sleep(1) threading.Thread(target=model_watcher, daemon=True).start()

客户只需touch /tmp/model_update.flag，整个过程业务无感知。我们实测切换时间2.3秒，期间新请求会排队，但不会丢失。

5. 常见问题与排查技巧实录

5.1 Hailo设备无法识别的12种原因及解决路径

提示：最隐蔽的问题是config.txt中dtparam=pciex1写成dtparam=pciex1（多了一个空格），导致Bootloader忽略该行。我们用sudo vcgencmd bootloader_config验证生效。

5.2 YOLO自定义数据集训练的5个致命陷阱

1. 标注框坐标超出图像边界：LabelImg导出时若拖拽框到画布外，会生成负坐标或大于宽高的值，YOLO训练时静默跳过该样本，导致数据集缩水。解决方案：用脚本清洗labels/*.txt：

   for label in labels/*.txt; do awk -v w=640 -v h=640 '{ x=$2; y=$3; w2=$4; h2=$5; x=(x<0)?0:(x>1)?1:x; y=(y<0)?0:(y>1)?1:y; w2=(w2<0)?0:(w2>1)?1:w2; h2=(h2<0)?0:(h2>1)?1:h2; print $1, x, y, w2, h2 }' "$label" > "${label}.clean" done

2. 类别ID不连续：CVAT导出时若删除过类别，ID可能为0,2,5，但YOLO要求ID从0开始连续。解决方案：用labelme2yolo工具重映射，或手动编辑data.yaml的names列表。

3. 图像分辨率差异过大：混合使用手机拍摄（4032×3024）和IPC（1920×1080）图像，训练时mosaic增强会导致小图严重失真。解决方案：预处理阶段统一resize到长边1280，短边等比缩放，再中心裁剪640×640。

4. 光照条件未归一化：阴天图像直方图集中在[30,120]，正午图像在[100,220]，模型学到的是光照特征而非物体特征。解决方案：训练前用CLAHE（对比度受限自适应直方图均衡化）处理：

   clahe = cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8,8)) lab = cv2.cvtColor(img, cv2.COLOR_BGR2LAB) lab[...,0] = clahe.apply(lab[...,0]) img = cv2.cvtColor(lab, cv2.COLOR_LAB2BGR)

5. 验证集泄露：用sklearn.model_selection.train_test_split随机划分，但同一场景的多张图被分到训练/验证集，导致