1绪论
1.1研究背景及意义
1.1.1研究背景
近几年，智能家居市场保持了较快的增长势头。根据Statista发布的数据，2024年全球智能家居市场规模预计达到1544亿美元，其中家庭安防类产品的渗透率已超过30%。摄像头作为安防体系的核心感知设备，出货量持续攀升，但一个突出的问题是，大多数家用摄像头仍然停留在一对一画面传输的阶段——能“看”，却不能“懂”。用户对监控系统的期待早已不只是录像回放，而是希望设备能在异常发生的第一时间主动识别并推送有意义的信息，而非仅仅提供一段需要人工逐帧翻看的视频。
学术界和工业界围绕智能视频分析已经做了不少工作。以YOLO系列为代表的单阶段检测模型在实时性上表现出色，在公共安全、交通监控等场景中得到了大量验证；将大语言模型引入安防描述生成的研究也逐步兴起，部分商业平台开始尝试用自然语言展示告警信息。然而，在这些成果中，真正面向家庭环境、兼顾检测精度与部署成本的开源实践仍然偏少。多数方案要么依赖于高性能GPU服务器，不适合在普通家用设备上运行，要么功能设计偏向通用场景，缺少对家庭常见目标类别和异常行为的针对性优化。
基于上述分析，本研究将注意力放在家用场景下“轻量化目标检测与可理解的异常报警”的结合点上。希望在前人工作的基础上，不简单复现一个检测模型，而是构建一套从视频采集、实时检测、结果记录到自然语言告警的完整流水线，同时让整个系统能够在无GPU的消费级硬件上稳定运行。这既是对现有技术组合落地能力的一次检验，也是在家庭安防智能化方向上所做的一点尝试。
1.1.2 研究意义
从实用层面看，这项工作的价值在于降低智能监控的使用门槛。一套只需普通摄像头和一台入门级电脑就能运转的系统，意味着更多家庭可以用较低成本获得主动式安全防护。把“有人闯入”这样的检测结果用一句清晰的中文消息推送给用户，远比在手机屏幕上弹出一条泛泛的“检测到异常”更有实际帮助，尤其对老人、儿童独自在家的场景，及时且可理解的预警比事后追溯更为关键。
从技术实践的角度来看，本研究在YOLOv8基础检测能力和DeepSeek语义理解能力之间建立了一条简洁的衔接通路。这种将成熟检测模型与自然语言接口进行工程化集成的思路，为后续在边缘设备上拓展更多AI交互功能提供了一个可参考的工程范例。同时，系统中模型版本可切换、置信度可调节、真实与模拟摄像头自适应等设计，也为同类项目在灵活性和可维护性上的探索积累了经验。综合来看，这是一次将现有技术成果转化为具体可用产品的微尝试，符合智能安防从“记录”走向“理解”的整体趋势。
1.2国内外研究现状及趋势
1.2.1国内外研究现状
近年来，随着深度学习技术的快速发展，基于计算机视觉的智能监控系统成为国内外学术界和产业界共同关注的焦点。本节从目标检测算法、家居监控系统和智能报警机制三个维度，对国内外相关研究进行梳理。
在国内研究方面，潘家亮等在《测控技术》上发表了关于多传感器融合的室内安全监控系统的研究[1]。针对复杂场景下智能监控系统存在的遮挡敏感和多目标检测精度不足问题，构建了基于系统级芯片的嵌入式架构，提出增强型YOLOv8n模型，引入高效局部注意力模块混合结构特征金字塔网络（ELA-HSFPN）来优化多尺度特征融合。改进后模型参数量降低了15.2%，mAP平均精度提升3%，系统在0.17秒内可完成目标检测，跌倒识别准确率超过95%，为复杂室内环境下的实时安全监控提供了可靠的解决方案。王思佳等在《科技与创新》上提出了基于计算机视觉的智慧家庭安全防护系统，设计了基于OpenCV和Dlib算法的身份识别子系统、基于YOLOv5算法和OpenPose人体姿态关节点识别技术的跌倒检测子系统以及基于AI虚拟围栏的婴儿看护子系统，实现了对家庭安全状态的实时监测[2]。尹春义等在《信息记录材料》上采用六足机器人搭载深度相机与YOLOv8卷积神经网络，实现校园暴力行为与危险活动的智能识别，系统在楼梯攀爬、湿滑地面等复杂场景中避障成功率达99%[3]。在火灾监测领域，重庆师范大学团队提出的Fire-YOLOv8模型通过增加更小的目标检测层并采用Focus切片操作，解决了微小火焰检测难题，结合轻量级BottleneckCSP模块与迁移学习策略，在复杂场景下实现了97.1%的精确率和95.7%的mAP值[4]。赵振兵等在《电工技术学报》上提出了一种基于目标检测与边缘分割的输电走廊隐患预警方法，在YOLOv8中引入小目标检测层和SBA模块，通过选择性聚合边界与语义信息、自适应注意力机制以及双向特征融合，采用重参数轻量头和可重参数化卷积实现轻量化优化，检测模型在mAP50上达到72.1%[5]。在少样本学习方面，张英俊等在《计算机应用研究》上提出融合迁移校正与自适应知识蒸馏的小样本目标检测方法，通过物体感知RPN和分布校正机制实现跨域知识迁移，有效缓解了小样本条件下的过拟合问题[6]。在Web系统集成方面，赵谨言等设计了基于Python的智能家居环境质量分析系统，集成温湿度、PM2.5等多类传感器，采用MQTT协议实现设备间通信，结合Flask框架构建Web监控界面，系统响应延迟低于300毫秒，数据准确率达98.6%[7]。此外，部分高校团队结合硬件传感模块开展了实践探索，如烟台黄金职业学院团队研发的智能宿舍监控系统，由ESP8266、MQ-2烟雾传感器、舵机等模块构成，搭配基于Flask框架的服务端程序，实现了网页远程控制、烟雾短信报警等功能[8]。在DeepSeek大模型应用方面，有研究将DeepSeek-R1的深度推理能力融入视频安全领域，利用其思维逻辑和交互体验优势，拓展了大模型在安防监控中的应用边界[9]。张梦榛等在《信息与电脑》上探讨了基于MTCNN和FaceNet的人脸识别技术在智能家居中的应用，实验结果显示人脸检测准确率达到86.3%，在身份验证和门禁管理方面表现出较高的实用性[10]。
在国外研究方面，Wang等（2025）在Journal of Physics: Conference Series上提出了SRSE-YOLOv8室内目标检测算法，通过引入额外的更小检测头增强小目标捕获能力，结合RFAConv实现输入自适应核调整和Slimneck结构降低模型复杂度，在自建室内数据集上平均精度达到94.9%，较原始YOLOv8n提升了3.5%[11]。Vuda等（2025）在Alexandria Engineering Journal上提出了一种结合注意力机制与Transformer检测头的YOLOv8框架，利用Transformer架构捕获长距离依赖和全局上下文信息，在实时视频监控中精确率达到96.78%，召回率达到96.89%，mAP达到89.67%，显著优于Faster R-CNN等传统方法[12]。Movi等（2026）在Pertanika Journal of Science & Technology上提出了基于Mask R-CNN和隔离森林的异常检测框架，通过预训练Mask R-CNN实现复杂场景中的人体检测，结合无监督隔离森林算法从日常活动中区分稀有异常事件，为家庭环境中的近实时CCTV分析提供了自动化解决方案[13]。一项发表在IEEE国际会议上的研究介绍了基于YOLOv8的智能家居监控系统，通过RTSP协议连接CCTV摄像头，在树莓派等本地设备上运行以实现数据隐私保护，当检测到人员时通过邮件向户主发送实时报警，实验结果表明系统兼顾了检测精度和实时性[14]。此外，一项关于家庭监控的研究将YOLO框架与ResNet50-LSTM网络相结合，在检测到人员后触发武器识别和暴力行为检测，YOLOv8n的人体检测F1分数达到0.922，在确认威胁后立即向业主发出报警[15]。Böhm等（2025）在arXiv上发表了利用视觉语言模型进行视频监控分析的概念验证研究，通过GenAI将CCTV视频片段转化为用户自定义查询的文本摘要，在时间和空间质量评估中分别达到80%和70%的准确率，为监控数据的高效检索开辟了新途径[16]。在系统集成层面，一项关于智能宿舍监控的研究利用Flask框架构建Web后台，结合MQ-2传感器和舵机实现远程报警与设备控制，展示了Python轻量级Web框架在小型监控系统中的工程可行性[17]。
1.2.2 国内外的发展趋势
综合以上文献可以看出，YOLO系列目标检测算法在智能监控领域已得到广泛认可，从YOLOv5到YOLOv8的迭代演进使得检测精度和推理速度持续提升。然而，现有研究多聚焦于单一环节的优化，或侧重于检测算法的改进，或局限于硬件传感的集成，将目标检测、自然语言报警生成和轻量化Web部署三者有机整合的工作仍然较少。特别是在家庭安防场景中，如何构建一套从视频采集到语义理解的全链路轻量化系统，让非专业用户也能便捷地获取可读性强的异常通知，是当前研究中一个值得深入探讨的方向。
1.3主要工作
本论文的研究内容围绕一套面向家庭场景的轻量化智能监控系统展开。在整体架构上，设计了涵盖视频采集、实时检测、数据持久化、前端展示与异常告警的完整流水线，各模块通过RESTful接口实现松耦合协作。检测环节以YOLOv8模型为核心，利用COCO预训练权重和自标注家庭场景数据进行迁移学习，重点优化了人员、宠物、车辆等常见类别的检测精度，并提供了模型版本动态切换和置信度阈值调节功能，便于在不同算力条件下灵活适配。后端采用Flask框架搭建Web服务，借助SQLAlchemy管理SQLite数据库，完成了检测记录存储、用户认证和基于角色的权限控制，同时记录了审计日志以保障操作可追溯。前端页面基于Bootstrap构建响应式布局，集成ECharts对检测频次、对象分布等指标进行可视化统计，并设计了实时监控与历史回溯相结合的用户界面。为进一步增强系统的实用价值，将DeepSeek大语言模型接入告警链路，使检测到的异常事件能够自动生成简短的自然语言描述，同时支持用自然语言查询历史记录，从而降低了非专业用户的理解与检索门槛。系统还实现了真实摄像头与模拟模式的自适应切换，使演示和测试不受硬件条件约束。通过上述技术集成，最终形成了一套功能闭环、部署简便、且能够在无GPU消费级设备上稳定运行的家居智能监控原型，为家庭安防从被动录像向主动理解转变提供了一种可行的工程参考。
1.4本章小结
本章围绕基于YOLOv8的实时目标检测与陌生人入侵告警系统这一研究课题，从选题背景、研究意义、国内外研究现状和主要研究内容四个层面进行了系统阐述。首先，通过分析当前家庭安防监控设备普遍存在的被动录像、缺乏实时分析能力等行业痛点，结合智能家居市场规模持续增长的趋势数据，明确了开展本研究的现实必要性和应用价值。其次，从目标检测算法演进、智能监控系统集成和大模型在安防领域的应用三个维度，对国内外相关文献进行了梳理和评述，总结出YOLO系列算法在实时检测任务中的优势以及现有工作在检测与语义理解结合方面的不足，为本研究的切入点提供了文献支撑。在此基础上，明确了本文的主要研究内容，即构建一套涵盖视频采集、实时检测、数据管理、入侵告警和统计分析的全链路系统，重点解决目标检测模型在家庭场景中的适配问题以及检测结果向可读告警信息的转化问题。本章的分析与阐述为后续章节的技术选型、系统设计和实验验证奠定了清晰的研究框架。
2 开发技术及算法
2.1 YOLOv8目标检测算法与迁移学习
YOLOv8是Ultralytics公司推出的单阶段目标检测模型，延续了YOLO系列“只看一次”的设计思想，将目标分类与边界框回归整合在一个端到端的卷积网络中完成。其网络结构由Backbone、Neck和Head三部分组成：Backbone采用CSPDarknet结构提取多尺度图像特征；Neck通过PAN-FPN进行特征融合，提升对不同大小目标的感知能力；Head采用解耦的检测头，分别输出分类得分和边界框参数，并引入无锚框（Anchor-Free）机制，减少了先验框调优的复杂度。
YOLOv8的损失函数由分类损失、边界框回归损失和分布焦点损失三部分构成。分类损失采用二元交叉熵，边界框回归损失使用完备交并比（CIoU）度量预测框与真实框的重合程度，
式中，IoU为交并比，ρ(·)表示中心点间的欧氏距离，c为包围两个框的最小外接矩形的对角线长度，α为权重系数，v用于衡量宽高比的一致性。分布焦点损失（DFL）则对边界框坐标的离散概率分布进行优化，让网络更关注目标位置附近的高概率区间，
在家庭场景中，直接使用COCO预训练权重进行检测已具有一定的泛化能力，但对特定视角和光照条件的适应性仍有不足。本系统采用迁移学习的策略，冻结Backbone浅层权重，仅对Head部分及深层特征层进行微调，以较小规模的自标注数据提升对人员、宠物等常见目标的检测精度，同时有效节约训练时间。
Flask是一个基于Python的轻量级Web应用框架，以Werkzeug工具箱和Jinja2模板引擎为核心，保留了极高的灵活性。开发者可以根据需求自由组织路由、中间件和扩展组件，不会像Django等全栈框架一样受到既定结构的限制。本系统中，Flask承担了从用户认证、页面渲染到API接口提供的所有Web服务功能。
路由机制将URL路径映射到具体的视图函数，通过@app.route装饰器可以清晰定义每一个接口。前端发出的HTTP请求被解析后，视图函数完成业务逻辑处理，再将数据以JSON格式返回或通过render_template渲染为HTML页面。对于视频流这样的长连接请求，Flask支持生成器模式的流式响应，使得摄像机画面可以持续推送到浏览器端。用户会话管理由Flask-Login扩展完成，它提供了登录状态保持、权限校验和登出清除等基础能力，确保不同角色（普通用户、管理员）只能访问与之权限相匹配的功能模块。
2.3SQLite数据库与对象关系映射
系统选用SQLite作为持久化数据库，这是一款零配置、嵌入式的关系型数据库引擎，无需独立的服务进程，数据以单个文件形式存储，非常适合家庭级应用场景。在Python环境中，通过SQLAlchemy这一ORM工具实现对数据库的操作，能够将数据表映射为Python类，将SQL查询转化为面向对象的方法调用，降低了直接编写SQL语句的出错概率。
数据库模型中定义了User、DetectionRecord、Message等多个实体，它们之间通过外键建立关联。例如，每条检测记录均绑定到特定用户，便于按用户维度进行查询和统计。事务管理机制保证了数据的一致性：当检测到异常并生成报警消息时，检测记录的插入和消息记录的写入在同一事务中提交，避免了“有记录无通知”或“有通知无记录”的脏数据情况。此外，利用Flask的请求钩子，在每个请求前后可以自动记录API调用时长等审计信息，为系统运维提供依据。
2.4DeepSeek大语言模型接口
DeepSeek是基于Transformer架构的大语言模型，具备强大的文本理解和生成能力。本系统通过OpenAI兼容的API接入DeepSeek服务，将检测结果中的目标类别、置信度、时间戳等结构化信息构建为提示词，让模型生成简短、贴切的中文报警描述。例如，当连续检测到人员在非预期时段出现时，系统会生成“凌晨2:15检测到陌生人员出现在客厅区域，请注意”这样可直接阅读的句子，替代了传统“异常事件”的笼统标签。
同样，在历史记录检索中，利用大语言模型对自然语言查询进行意图解析。用户输入“上周日下午谁来过？”，系统将查询语句及近期检测记录一并提交给模型，模型从中匹配出相关的时间段和对象类别，再返回对应的记录编号，从而实现了零查询语法的自然检索体验。这种将视觉感知与语言理解相结合的路径，显著降低了非专业用户的使用门槛。
2.5前端可视化及响应式布局
前端界面采用Bootstrap 5框架构建，利用其栅格系统和预置组件快速搭建出适配PC、平板和手机的响应式布局。在数据展示方面，引入ECharts图表库，它将后端传递的统计数据渲染为饼图、柱状图和折线图等直观形式，例如对象类别分布、每小时检测频次趋势等，使用户无须查看枯燥的表格就能掌握家庭环境动态。
Bootstrap的模态框、下拉菜单等交互组件简化了模型切换、时间筛选等功能的开发。视频区域的显示则通过img标签持续刷新从Flask视频流接口获取的图像帧，配合全屏API和截图功能，基本覆盖了日常监控操作的需要。前端脚本定时请求检测结果接口，动态更新检测列表和对比面板，保证了页面信息与后端状态的准同步。整体上，这些技术的组合实现了“数据采集在云端、呈现与交互在浏览器”的轻客户端架构。
3.1模型选型与结构分析
在目标检测算法选型上，系统同时集成了YOLOv5和YOLOv8两套模型，以便在实际运行中进行对比评估和灵活切换。两种模型同属YOLO系列的单阶段检测器，但在网络结构上存在显著差异。
YOLOv8是Ultralytics于2023年发布的最新版本，其网络结构由Backbone、Neck和Head三部分组成。Backbone延续CSPDarknet架构，但将YOLOv5中使用的C3模块替换为C2f模块。C2f模块在CSP结构基础上增加了更多的跨层连接分支，使梯度流动路径更加丰富，在相近计算量下能保留更细粒度的特征信息。Neck部分沿用PAN-FPN结构，通过自顶向下和自底向上的双向路径实现多尺度特征融合，增强了对大、中、小三种尺度目标的感知能力。Head部分采用解耦设计，将分类分支和回归分支完全分离，各自独立进行卷积运算，有效减少了两个任务在特征空间中的相互干扰。此外，YOLOv8全面采用无锚框机制，直接预测边界框左上角和右下角相对于网格中心的偏移量，摒弃了预设锚框对目标尺度先验知识的依赖。
YOLOv5同样采用CSPDarknet骨干网络，但其C3模块的跨层连接相对简洁。Neck使用PAN结构进行特征融合，Head则为耦合设计，分类和回归共享同一组卷积特征。YOLOv5保留了锚框机制，需要预设若干组不同尺度和宽高比的先验框来辅助边界框回归。
两种模型在nano规模下的参数与性能对比如表3.1所示。YOLOv8n的参数量较YOLOv5n有所增加，但得益于结构优化，在COCO数据集上的官方基准mAP@0.5:0.95由28.0提升至37.3，涨幅超过9个百分点。两者的计算量均控制在10G FLOPs以内，适合在CPU设备上部署。系统最终选定YOLOv8n作为主检测模型，同时保留YOLOv5n作为对比参照。
表3-1 YOLOv5n与YOLOv8n模型参数与基准性能
|
模型 |
参数量(M) |
FLOPs(G) |
mAP@0.5:0.95(COCO) |
|
YOLOv5n |
1.9 |
4.5 |
28.0 |
|
YOLOv8n |
3.0 |
8.1 |
37.3 |
注：FLOPs以640×640输入计，mAP数据源自Ultralytics官方发布结果。
高质量的训练数据是模型性能的基石。由于本系统面向家庭监控场景，需要检测人员、宠物、车辆三类目标，对应9个具体类别，即person、car、truck、bus、motorcycle、cat、dog、horse、bird。整个数据集的构建遵循从原始数据获取到最终格式化的完整流程。
3.2.1数据来源与预处理
数据集构建以COCO128公开数据集为起点。COCO128是COCO2017的紧凑子集，包含128张真实场景图片及对应的精确标注文件。首先对COCO128进行解压，获得images和labels两个目录，共计128对图片与标注。利用YOLOv8n预训练模型对全部图片进行一次推理，筛选出检测结果中包含上述6个目标类别的图片及其标注。
3.2.2标注格式的修正
在数据集构建的早期尝试中，由于处理方式不当，出现了全图标注的错误。该标注将所有图片的目标边界框均记录为“0 0.5 0.5 1.0 1.0”，表示类别为person且边界框覆盖整个图像。这种标注方式将大量背景区域错误地标记为目标，模型在训练时会学到毫无辨识价值的负样本特征，根本无法收敛到有效的检测能力。两种标注模式的差异如图3-1所示。
图3-1 错误全图标注与正确边界框标注对比
正确的标注格式严格按照YOLO规范，每行对应一个目标，格式为“class_id x_center y_center width height”，五个数值均归一化到0至1区间。例如，“0 0.4521 0.3235 0.1845 0.4562”表示在图像中(x=0.4521, y=0.3235)处有一个宽度0.1845、高度0.4562的person目标。利用预训练模型自动标注获取的正是这种精确格式，每张图片可包含多行，分别对应画面中检测到的不同目标。这种标注方式真实反映了目标在画面中的空间位置与尺度，为模型提供有效的监督信号。
3.2.3数据集划分与配置
标注修正后，按照类别将图片和标注文件分类存储到raw目录下的persons、pets、vehicles三个子文件夹中。每个类别收集30至50张图片，最终汇总后共获得270张有效标注样本。将所有样本随机打乱，按7:2:1的比例划分为训练集、验证集和测试集，划分结果如表3-2所示。最后生成data.yaml配置文件，声明数据集路径、类别数量和名称映射，形成完整的YOLO训练数据集。
表3-2 训练超参数配置
|
参数 |
取值 |
|
初始学习率 |
0.01 |
|
最终学习率 |
0.01 |
|
动量 |
0.937 |
|
权重衰减 |
0.0005 |
|
批大小 |
16 |
|
图像尺寸 |
640 |
|
训练轮次 |
100 |
|
早停耐心值 |
50 |
|
优化器 |
AdamW |
|
设备 |
CPU |
在270张小规模数据集上从头训练YOLOv8极易出现过拟合。考虑到YOLOv8n已在COCO大规模数据集上完成预训练，其Backbone浅层已习得纹理、边缘等通用视觉特征，本系统采用迁移学习策略进行模型适配。
迁移学习的具体方案为：加载官方yolov8n.pt预训练权重，冻结Backbone前几层的参数，仅对Neck和Head部分的权重进行更新。这种方式使模型在保留通用物体感知能力的基础上，将学习重点向家庭场景的特定目标类别倾斜，在小数据量条件下仍可获得可用的检测精度。
训练超参数综合参考了小数据集训练的通用建议，具体配置见表3-2。学习率采用余弦退火调度从0.01逐渐衰减，优化器选用AdamW，配合0.0005的权重衰减系数控制过拟合风险。早停耐心值设为50个epoch，每隔10个epoch保存一次模型检查点。受硬件条件限制，训练全程在CPU上完成，图像输入尺寸统一为640×640，批大小为16。
为实现检测模型的灵活调用，系统在detection.py中封装了统一的YOLODetector类。该类内部维护一个model属性和current_model_name标识，通过set_model()方法接受模型名称参数，实现不同模型的加载与切换。系统启动时默认加载YOLOv8n，yolov5nu.pt作为备用模型路径同时注册在可用模型列表中。
前端监控页面设有模型切换按钮组，用户点击按钮后，前端通过/api/switch_model接口向Flask后端发送POST请求，携带model_name参数。后端接收到请求后调用detector.set_model()完成模型替换，并将切换结果以JSON格式返回前端更新界面。切换过程中，摄像头帧队列短暂清空以避免新旧模型推理冲突，模型加载完成后立即恢复正常检测。整个切换操作在2至3秒内完成，对用户体验影响较小。
这种双模型集成设计提供了两方面的价值：一是允许在调试和评估阶段快速对比YOLOv5和YOLOv8的实际表现，为模型选型提供实测依据；二是为后续按任务场景选择最优模型提供了便捷入口，例如在算力极度受限时可切换至体积更小的模型。系统同时通过/api/models接口向外暴露当前可用模型列表和当前激活模型的信息，前端定时拉取这些数据以同步显示模型状态。
本章基于第三章构建的数据集和训练策略，对YOLOv8模型的训练过程进行详细记录与分析，并在相同测试条件下与YOLOv5进行对比评估，最后展示集成到家居监控系统中的实际运行效果。
实验在无GPU加速的个人计算机上完成，具体环境配置见表4.1。评估指标采用目标检测领域的通用标准，包括精确率（Precision）、召回率（Recall）、平均精度均值（mAP@50）以及单帧推理时间。
表4-1 实验环境配置
|
项目 |
配置 |
|
处理器 |
Intel Core i7-12700H |
|
内存 |
16GB |
|
操作系统 |
Windows 11 |
|
Python版本 |
3.11 |
|
深度学习框架 |
ultralytics 8.0 |
|
数据集规模 |
270张 |
|
输入尺寸 |
640×640 |
按照表3-2设定的超参数进行100个epoch的训练，训练过程中各项损失和指标的变化轨迹被完整记录，如图4-1所示。
图4-1 训练损失与验证指标变化曲线
如图4-1所示包含train/box_loss、train/cls_loss、train/dfl_loss三条训练损失曲线，以及metrics/mAP50(B)和metrics/mAP50-95(B)两条验证指标曲线.从训练损失曲线来看，box_loss从初始值约1.5附近开始下降，前10个epoch内下降速度较快，随后进入缓慢递减阶段，最终在epoch 100时收敛至约1.5。cls_loss的初始值较高，约为2.2，同样在前10个epoch经历了快速下降，但随后出现一定程度的振荡，最终稳定在1.5左右。dfl_loss从1.0附近起步，整体呈稳定下降趋势，最终收敛至约1.5。三条损失曲线均未出现剧烈波动，说明学习率设置合理，训练过程整体平稳。
从验证指标来看，metrics/mAP50(B)从接近零起步，在前几个epoch内快速攀升至约0.02至0.03，随后增长明显放缓。epoch 13时达到一个局部高点0.02514，此后数值进入波动状态，最高在epoch 50时达到0.02044。metrics/mAP50-95(B)的变化趋势与mAP50类似，但绝对值更低，最高值仅为约0.01。两条验证曲线的上升幅度远低于训练损失的下降幅度，表明模型在验证集上的性能提升有限。
精确率和召回率的变化同样值得关注。训练日志显示，precision在大多数epoch中处于极低水平（<0.01），仅在个别epoch（如epoch 8、22、23等）出现跃升，达到0.50左右。recall同样很低，最高仅0.23左右。精确率和召回率均不理想，且二者之间存在明显差距，说明模型虽然偶尔能做出较为准确的预测，但检测的完备性严重不足。
综上分析，YOLOv8模型在小规模数据集上经过100个epoch的迁移学习训练后，各项损失已趋于收敛，但验证指标始终维持在较低水平。造成这一现象的原因主要有三点：一是训练样本仅189张，样本多样性不足以支撑模型学习到稳健的特征表达；二是输入尺寸640×640在CPU训练条件下限制了batch size的增大，影响了梯度估计的稳定性；三是数据集中各类别样本数量不均衡，部分类别样本极为稀缺，导致模型难以充分学习。
训练结束后，使用保存的最佳权重在测试集上进行了全面评估。以下从P-R曲线、混淆矩阵和标注分布三个维度对评估结果进行深入分析。
4.3.1P-R曲线分析
模型的精确率-召回率曲线如图4-2所示。
图4-2 精确率-召回率曲线
从图4-2中可以看出，person类别的P-R曲线位于最上方，在所有召回率区间均保持了相对较高的精确率，mAP@50达到0.133。这表明在COCO预训练权重中person类别的特征表达较为丰富，迁移至家庭场景后仍能保持一定的检测能力。然而，person的召回率上限仅为0.2左右，说明测试集中大量人员目标并未被成功检测，漏检现象突出。
vehicles类别的表现显著差于person，mAP@50仅为0.000。曲线几乎贴近坐标轴底部，精确率和召回率均接近零值，表明模型对车辆类目标几乎不具备检测能力。造成该现象的原因可能有两方面：一是训练集中车辆类别样本数量偏少，二是在家庭场景下拍摄角度的车辆外观与COCO数据集中的道路车辆存在较大分布差异，迁移难度较高。
all classes的综合mAP@50为0.066，介于person和vehicles之间，但整体数值偏低，反映出模型在当前数据集规模下的性能上限。值得注意的是，图4-3中的精确率-置信度曲线进一步揭示了模型的行为特征。
图4-3 精确率-置信度曲线
图4-3显示person类别的精确率随置信度阈值升高呈上升趋势，当置信度达到0.9以上时，精确率接近1.00。这意味着模型输出的高置信度检测结果具有较高的可信度，但这类高置信度样本的数量十分有限。vehicles曲线几乎全程为零，再次验证了车辆类别的检测失灵。all classes的综合曲线在低置信度区间表现极差，该现象与前文精确率低的结论一致。
4.3.2混淆矩阵分析
图4-4展示了测试集上的归一化混淆矩阵，该矩阵直观呈现了模型对各类别的分类倾向。
图4-4 归一化混淆矩阵
混淆矩阵的分析结果如下：person类别对应的对角线值为1.00，表示所有被模型判定为person的样本中，真实标签确实为person，分类准确度很高。pets类别对角线值为0.60，意味着有40%的宠物样本被错误预测为其他类别；vehicles类别对角线值仅为0.40，说明超过一半的车辆样本被误分。对角线之外的单元格显示，被误分的样本绝大多数被预测为background，即模型直接将其判为无目标背景。background列的值接近1.00，表明模型很少将背景误判为前景目标，误报率控制在较低水平。
综合来看，模型的行为特征是“宁可漏检，不愿误报”。在家庭安防场景中，这一倾向在一定程度上是可以接受的，因为误报过多会频繁打扰用户，反而降低系统可用性。但过高的漏检率同样不可忽视，尤其是车辆和宠物的检出能力薄弱，在真实部署中可能导致重要事件被遗漏。
4.3.3标注分布分析
图4-5为训练集标注的分布统计图，展示了所有标注框的位置和尺度分布。
图4-5 训练集标注分布统计
如图4-5所示，标注框的中心点在x方向上主要集中在0.4至0.6区间，表明目标多位于图像水平方向的中央区域；y方向上则较为分散，无明显集中趋势。标注框的宽度和高度的归一化值大多分布在0.0至0.2之间，说明数据集中小目标占比极高。小目标在640×640的特征图上仅占据极少像素，特征信息稀疏，检测难度本身就大于中大型目标。这一标注分布特征从数据层面解释了模型召回率偏低的原因——大量目标属于客观上难以检测的小尺度类别，模型在有限的训练样本下难以充分学习到小目标的判别性特征。
为综合评价主检测模型与备选模型之间的性能差异，在相同测试集上对YOLOv5n和微调后的YOLOv8n进行对比测试。其中YOLOv5n使用官方预训练权重直接推理，未经本实验数据集微调；YOLOv8n为经本文训练流程微调后的最佳权重。评估对比结果如表4.2所示。
表4-2 YOLOv5n与YOLOv8n测试集评估对比
|
指标 |
YOLOv5n |
YOLOv8n |
提升幅度 |
|
mAP@50 |
0.041 |
0.066 |
61.0% |
|
person AP |
0.085 |
0.133 |
56.5% |
|
precision |
0.004 |
0.527 |
— |
|
recall |
0.232 |
0.036 |
— |
|
推理时间(ms/帧) |
32 |
28 |
-12.5% |
|
模型文件大小(MB) |
5.3 |
6.2 |
17.0% |
表4-2的数据揭示了两类模型的显著差异。在精度指标方面，微调后的YOLOv8n在mAP@50上达到0.066，较YOLOv5n的0.041提升了61.0%。person AP从0.085提升至0.133，提升幅度为56.5%，表明经过迁移学习微调的YOLOv8在人员检测任务上优于零样本迁移的YOLOv5。其中precision的大幅领先说明YOLOv8输出高置信度检测结果的能力更强，但recall的差距也反映出YOLOv8的检测覆盖范围更窄，更多目标被遗漏。
在推理效率方面，YOLOv8n单帧推理耗时28ms，YOLOv5n为32ms，前者快约12.5%。两模型均可满足20至30FPS的实时监控需求。模型文件体积方面，YOLOv8n比YOLOv5n大约0.9MB，增幅17%，仍在可接受范围。
需要指出的是，YOLOv5n未经过本实验数据集的微调，其性能表现反映的是模型从COCO直接迁移到家庭场景的零样本泛化能力。该对比说明了两点：一是经过针对性微调的模型在特定场景下的表现优于泛化模型；二是YOLOv8改进的网络结构和预训练特征在迁移学习场景中具有一定优势。
将训练好的YOLOv8模型部署到家居监控系统中，通过模拟摄像头模式进行连续运行测试，验证检测、切换功能。
启动系统并进入监控页面后，模拟画面中的检测结果如图4-6所示。画面中的人员、车辆等目标被实时标注出边界框和类别标签，标签格式为“人员(P8) 0.85”，包含类别名称和置信度数值。帧画面底部信息栏同步显示当前时间和检测到的目标数量。系统能够以约30FPS的帧率稳定运行，画面无明显卡顿或延迟。
图4-6 实时检测效果
点击监控页面上方的模型切换按钮，选择“YOLOv5 Nano”后，系统在约2秒内完成模型替换。切换后画面标注信息的模型后缀由“P8”变为“P5”，前端模型对比面板同步显示YOLOv5和YOLOv8两列检测结果，如图4-7所示。同一帧画面经过两个模型分别推理，用户可直观对比两者的检测差异。
图4-7 YOLOv5和YOLOv8检测结果对比效果
5系统设计与实现
5.1.1架构设计
本系统采用B/S分层架构，按照数据流动方向自下而上划分为数据采集层、算法处理层、业务逻辑层和前端展示层四个层级。各层职责明确、接口清晰，层与层之间通过标准协议进行通信，实现了模块间的松耦合。
数据采集层位于系统最底层，负责视频流和配置信息的获取。该层通过OpenCV调用摄像头驱动采集原始图像帧，同时读取系统配置参数（如置信度阈值、摄像头源选择等），为上层处理提供原始数据。在摄像头不可用时，该层自动切换至模拟模式，生成带时间戳的仿真画面，保证系统在任何硬件条件下的可运行性。
算法处理层接收数据采集层传入的图像帧，调用YOLO检测器完成目标检测。检测结果包含目标类别、置信度和边界框坐标。该层同时封装了DeepSeek大语言模型的调用接口，将结构化检测数据转化为自然语言描述。算法处理层以独立线程运行，与Web主线程并行工作，避免检测计算阻塞用户请求。
业务逻辑层基于Flask框架构建，是系统的核心调度中枢。该层通过路由机制将前后端请求进行分发处理：将视频流推送至前端展示、将检测结果经ORM映射后持久化到SQLite数据库、接收前端的模型切换指令并下发至算法处理层、完成用户认证与权限校验等。所有与检测记录、用户信息、消息通知相关的增删改查操作均在这一层完成编排。
前端展示层采用Bootstrap响应式布局和ECharts可视化图表，向用户提供监控画面、检测列表、统计分析和管理后台四个主要的交互界面。前端通过定时AJAX请求和流式图像载入两种方式获取后端数据，配合DOM动态更新实现准实时的页面刷新。
上述四层架构的数据流向可概括为：图像帧自下而上推送，控制指令自上而下传递，检测结果和业务数据在中间层完成汇聚与分发。系统整体架构如图5-1所示。
图5-1系统架构图
5.1.2功能模块设计
本系统是一个面向家庭环境的轻量化智能监控平台，综合集成了视频采集、目标检测、异常报警、数据管理和统计分析等多项功能。系统按功能边界划分为实时监控模块、目标检测模块、异常报警模块、历史记录模块、统计分析模块、消息中心模块、用户管理模块和系统配置模块，共八个核心功能模块。各模块之间的功能关系如图5.2所示。
图5- 2系统功能图
实时监控模块负责摄像头视频流的采集与推送。模块内部维护一个独立线程持续读取摄像头帧，将检测标注后的画面编码为JPEG格式，通过MJPEG流协议推送至浏览器端视频标签。该模块同时支持真实摄像头和模拟画面两种工作模式，模式切换对上层透明。
目标检测模块封装YOLOv5和YOLOv8两套模型，提供统一的推理接口。模块在初始化时加载预训练权重，每帧图像送入模型后返回目标列表。模块通过API向外部暴露当前模型信息查询和运行时模型切换两项能力，前端可随时获取可用模型列表并发起切换请求。
异常报警模块在目标检测结果的基础上，根据预设规则判断是否构成异常事件。当检测到人员目标且置信度超过阈值，或检测到烟雾、火焰等危险类别时，模块触发报警。报警内容由DeepSeek接口生成自然语言描述，连同截图一并写入数据库，同时通过消息模块推送至用户界面。
历史记录模块提供检测记录的按条件查询、分页浏览和图像回溯功能。用户可按目标类别、时间区间和是否仅异常等条件组合筛选，查询结果以表格形式展示，点击缩略图可查看完整截图。
统计分析模块对检测记录进行多维度聚合计算，统计对象类别分布、每小时检测频次、每日检测趋势及异常比例等指标。前端通过ECharts将统计数据渲染为饼图、柱状图和折线图，提供时间范围切换按钮支持今日、本周、本月三种视图。
消息中心模块管理报警通知的收发与状态跟踪。未读消息以角标数量显示在导航栏，用户可逐条标记已读或全部标记。消息列表支持分页浏览，消息内容由系统自动生成，涵盖异常类型和发生时间等关键信息。
用户管理模块是管理员专属功能，支持多用户的增删改查和角色分配。系统角色分为普通用户和管理员两类：普通用户可查看监控画面和历史记录，管理员还可管理用户账户、配置系统参数和查看审计日志。所有登录操作均记录审计日志。
系统配置模块提供检测置信度阈值、摄像头源选择和报警规则等参数的在线调整。配置项以键值对形式存储在数据库中，修改后即时生效，无须重启服务。
5.2.1数据关系设计
本系统采用SQLite关系型数据库，围绕用户身份、检测事件和消息通知三条业务主线组织数据存储。各实体及其属性定义如下。
用户实体（User）记录系统使用者的身份信息和认证凭据。每个用户拥有唯一的用户名和邮箱，系统通过角色字段区分普通用户和管理员的权限边界。用户与检测记录之间为一对多关系，一个用户可关联多条检测记录；用户与消息之间同样为一对多关系，一个用户可以接收多条通知消息。
检测记录实体（DetectionRecord）承载每一次目标检测的结果信息。该实体通过外键user_id关联到具体的系统用户，记录内容涵盖检测时间戳、目标类别、置信度数值、边界框坐标以及截图存储路径。检测记录中还包含is_abnormal和abnormal_type两个字段，用于标记异常事件及其类型，为报警查询提供直接索引。
消息实体（Message）存储系统自动生成的报警通知。该实体通过外键user_id指向目标用户，包含消息标题、正文内容和阅读状态。消息类型字段区分报警类、信息类和系统类三种来源，便于前端分类展示。
审计日志实体（AuditLog）记录用户的操作行为，是系统安全追溯的基础。日志通过user_id外键关联操作用户，记录操作动作名称、操作对象和详细描述，每次记录附带时间戳，为管理员排查问题提供依据。
系统配置实体（SystemConfig）以键值对形式存储全局参数。每个配置项由唯一的键标识，对应一个可修改的值和描述信息，更新时间戳记录最近一次变更时间。
系统数据关系图如图5.3所示，图中标明了各实体之间的关联关系和外键约束。
图 5-3系统数据关系图
5.2.2数据库表设计
本系统数据库主要用于保存用户身份信息、检测事件记录和报警消息等核心业务数据。系统共设计五张数据表，分别为用户信息表（user_hms）、检测记录表（detection_hms）、消息通知表（message_hms）、审计日志表（audit_hms）和系统配置表（config_hms）。下面依次给出每张表的详细设计。
（1）user_hms表
user_hms表记录系统用户的身份信息与认证凭据，是权限控制和数据归属的基础。表结构如表5-1所示。其中，role字段取值为user或admin，分别对应普通用户和管理员角色。is_active字段取值为“是”或“否”，表示账户启用状态。last_login字段记录最近一次登录时间，首次注册用户该字段为空。
表5-1 user_hms数据表结构
|
字段名 |
数据类型 |
是否主键 |
是否外键 |
允许为空 |
说明 |
|
id |
INTEGER |
是 |
否 |
否 |
用户ID，自增 |
|
username |
VARCHAR(80) |
否 |
否 |
否 |
登录用户名 |
|
|
VARCHAR(120) |
否 |
否 |
否 |
电子邮箱 |
|
password_hash |
VARCHAR(255) |
否 |
否 |
否 |
密码哈希值 |
|
role |
VARCHAR(20) |
否 |
否 |
否 |
角色，默认user |
|
is_active |
VARCHAR(10) |
否 |
否 |
否 |
是否启用，默认是 |
|
created_at |
DATETIME |
否 |
否 |
是 |
创建时间 |
|
last_login |
DATETIME |
否 |
否 |
是 |
最后登录时间 |
（2）detection_hms表
detection_hms表存储每一次目标检测的结果数据，是本系统中写入频率最高的核心业务表。表结构如表5-2所示。该表通过user_id外键关联到user_hms表的id字段，建立检测记录到用户的归属关系。image_path字段保存截图文件相对路径，关联文件存储在服务器static/uploads目录下。bbox_x、bbox_y、bbox_w和bbox_h四个字段共同描述目标的边界框位置与尺寸。
表5-2 detection_hms数据表结构
|
字段名 |
数据类型 |
是否主键 |
是否外键 |
允许为空 |
说明 |
|
id |
INTEGER |
是 |
否 |
否 |
记录ID，自增 |
|
user_id |
INTEGER |
否 |
是 |
否 |
关联用户ID |
|
timestamp |
DATETIME |
否 |
否 |
否 |
检测时间戳 |
|
object_class |
VARCHAR(50) |
否 |
否 |
否 |
目标类别名称 |
|
confidence |
FLOAT |
否 |
否 |
否 |
置信度 |
|
image_path |
VARCHAR(255) |
否 |
否 |
是 |
截图路径 |
|
bbox_x |
FLOAT |
否 |
否 |
是 |
边界框左上角X坐标 |
|
bbox_y |
FLOAT |
否 |
否 |
是 |
边界框左上角Y坐标 |
|
bbox_w |
FLOAT |
否 |
否 |
是 |
边界框宽度 |
|
bbox_h |
FLOAT |
否 |
否 |
是 |
边界框高度 |
|
is_abnormal |
VARCHAR(10) |
否 |
否 |
否 |
是否异常，默认否 |
|
abnormal_type |
VARCHAR(50) |
否 |
否 |
是 |
异常类型 |
（3）message_hms表
message_hms表存储系统自动生成的报警通知和用户消息。表结构如表5-3所示。该表通过user_id外键关联到目标用户，message_type字段区分alert（报警）、info（信息通知）和system（系统消息）三种类型。is_read字段取值为“是”或“否”，用于前端统计未读消息数量。
表5-3 message_hms数据表结构
|
字段名 |
数据类型 |
是否主键 |
是否外键 |
允许为空 |
说明 |
|
id |
INTEGER |
是 |
否 |
否 |
消息ID，自增 |
|
user_id |
INTEGER |
否 |
是 |
否 |
关联用户ID |
|
title |
VARCHAR(200) |
否 |
否 |
否 |
消息标题 |
|
content |
TEXT |
否 |
否 |
否 |
消息正文 |
|
message_type |
VARCHAR(20) |
否 |
否 |
否 |
消息类型，默认alert |
|
is_read |
VARCHAR(10) |
否 |
否 |
否 |
是否已读，默认否 |
|
created_at |
DATETIME |
否 |
否 |
是 |
创建时间 |
（4）audit_hms表
audit_hms表记录用户在系统中的关键操作行为，为管理员提供安全审计依据。表结构如表5-4所示。该表通过user_id外键关联操作用户，action字段记录操作类型（如login、logout、create_user等），resource字段记录操作对象，details字段补充说明操作详情。
表5-4 audit_hms数据表结构
|
字段名 |
数据类型 |
是否主键 |
是否外键 |
允许为空 |
说明 |
|
id |
INTEGER |
是 |
否 |
否 |
日志ID，自增 |
|
user_id |
INTEGER |
否 |
是 |
是 |
关联用户ID |
|
action |
VARCHAR(100) |
否 |
否 |
否 |
操作类型 |
|
resource |
VARCHAR(100) |
否 |
否 |
是 |
操作对象 |
|
details |
TEXT |
否 |
否 |
是 |
操作详情 |
|
ip_address |
VARCHAR(50) |
否 |
否 |
是 |
操作IP地址 |
|
created_at |
DATETIME |
否 |
否 |
是 |
操作时间 |
（5）config_hms表
config_hms表以键值对形式保存系统全局配置参数，支持在线修改且即时生效。表结构如表5-5所示。key字段为配置项的唯一标识，value字段存储配置值，updated_at字段自动记录最近一次修改时间。
表5-5 config_hms表结构
|
字段名 |
数据类型 |
是否主键 |
是否外键 |
允许为空 |
说明 |
|
id |
INTEGER |
是 |
否 |
否 |
配置ID，自增 |
|
key |
VARCHAR(100) |
否 |
否 |
否 |
配置键名称 |
|
value |
TEXT |
否 |
否 |
是 |
配置值 |
|
description |
VARCHAR(255) |
否 |
否 |
是 |
配置说明 |
|
updated_at |
DATETIME |
否 |
否 |
是 |
更新时间 |
上述五张数据表覆盖了用户身份、检测事件、消息通知、操作审计和系统设置五个业务维度。其中，detection_hms表、message_hms表和audit_hms表均通过user_id外键与user_hms表建立关联，与图5.3所示的数据关系图完全对应。各表的主键均采用自增整数类型，时间字段采用DATETIME类型由Python datetime对象直接映射，判断类字段仅使用“是”或“否”两种取值。整体表结构在满足业务功能需求的前提下保持了设计的简洁性，便于后续的维护和扩展。
6系统开发与实现
本系统采用B/S架构，基于Python语言和Flask Web框架开发，前端采用Bootstrap 5构建响应式界面，数据库选用SQLite嵌入式关系型数据库。系统的开发与部署环境如表6.1所示。训练和推理均在无GPU的普通个人计算机上完成，不依赖专用计算加速卡，体现了轻量化部署的设计目标。
表6-1 系统开发环境
|
类别 |
配置项 |
说明 |
|
硬件环境 |
CPU |
Intel Core i7-12700H |
|
内存 |
16GB DDR4 | |
|
硬盘 |
512GB SSD | |
|
软件环境 |
操作系统 |
Windows 11 22H2 |
|
数据库 |
SQLite 3（通过SQLAlchemy ORM管理） | |
|
Web服务器 |
Flask内置开发服务器（Werkzeug） | |
|
浏览器 |
Google Chrome 120+ / Microsoft Edge 120+ | |
|
开发环境 |
PyCharm Professional 2024.1，Python 3.11 |
6.2.1实时监控模块
实时监控模块是系统与用户交互最频繁的功能入口，负责将摄像头画面实时传输到浏览器端，并提供基础的操作控制接口。
后端通过camera.py中定义的CameraStream类实现视频流的采集与分发。该类在start()方法中创建一个独立线程，循环执行_capture_loop或_simulate_loop函数。当CV2_AVAILABLE为True且摄像头连接成功时，进入真实采集循环：通过cv2.VideoCapture.read()获取原始帧，调用detector.detect()和detector.detect_abnormal()完成检测与异常判定，再调用detector.draw_detections()在帧上绘制标注框和标签，最后使用cv2.imencode将帧编码为JPEG字节流存入self.frame成员。若摄像头不可用或系统处于模拟模式，则执行_simulate_loop，调用_create_simulation_frame生成带有时间戳和渐变背景的仿真画面，同样经过检测和编码流程。采集线程将self.frame持续更新为最新的JPEG数据，供HTTP响应生成器调用。
视频流的HTTP传输采用multipart/x-mixed-replace协议。Flask定义/video_feed路由，返回一个生成器函数，该函数循环读取camera.get_frame()获取最新帧数据，并以--frame边界符分隔，每次输出Content-Type: image/jpeg头部及帧内容。浏览器端在monitor.html模板中使用<img>标签的src属性指向/video_feed路径，浏览器原生支持该MIME类型，会持续替换图片内容，呈现准实时视频效果。
前端与后端的检测结果同步则通过定时轮询/api/detections接口实现。JavaScript的setInterval函数每秒发送GET请求，后端返回camera.get_detections()中的最新检测列表。前端解析JSON后动态渲染检测详情表格和模型对比面板，同时更新画面底部的检测计数和时间戳。全屏切换和截图功能分别调用浏览器的Fullscreen API和Canvas API实现，截图时先将视频帧绘制到离屏Canvas上，再通过toDataURL导出为JPEG文件下载。实时监控页面运行效果如图6-1所示。
图6-1实时监控页面运行效果图
6.2.2目标检测模块
目标检测模块封装在detection.py的YOLODetector类中，旨在为上层提供统一的检测推理接口，并屏蔽YOLOv5与YOLOv8在调用方式上的差异。
模块初始化时，根据YOLO_AVAILABLE标志位和FORCE_SIMULATION_MODE配置决定是否加载真实模型。若YOLO可用且未强制模拟，调用load_model方法加载默认的yolov8n.pt权重文件，使用ultralytics库的YOLO类实例化模型。加载成功后，模型对象赋给self.model，同时设定self.current_model_name和self.current_model_type标识当前激活的模型。若ultralytics未安装或配置要求模拟，则将self.simulation_mode置为True，后续检测请求均由_simulate_detections方法返回随机生成的结果。
detect方法是模块的核心推理接口，接收一个numpy数组格式的图像，返回检测结果字典列表。非模拟模式下，调用self.model(frame, conf=threshold, verbose=False)进行推理，遍历返回的boxes，提取类别ID、置信度和xyxy格式的边界框坐标，根据coco_classes映射表将数字ID转换为英文名称，再按配置的use_chinese_labels决定输出中文或英文类别标签。模拟模式下，根据画面尺寸随机生成1到3个虚拟目标，包含person、car、dog、cat等类别，并附带随机置信度和位置坐标。
模型的动态切换由set_model方法实现。该方法接收模型名称参数，在AVAILABLE_MODELS字典中查找对应的权重文件路径，调用YOLO加载新模型，更新current_model_name和current_model_type，返回操作结果布尔值和提示信息。切换过程中不停止摄像头采集线程，仅将检测器内部模型引用原子替换，下一帧推理即使用新模型，从而将对实时监控的干扰降至最低。
前端监控页面在顶部工具栏提供了YOLOv8 Nano和YOLOv5 Nano两个切换按钮，点击后通过fetch API向/api/switch_model发送POST请求，体部携带{"model_name": "yolov5nu"}等参数。后端switch_model视图函数解析请求体，调用detector.set_model完成切换，并将success布尔值和提示文本以JSON返回。前端根据返回结果更新按钮激活状态、模型名称显示和Toast提示。此外，/api/models接口以GET方式返回当前可用模型列表和当前激活模型的信息，前端在页面加载时调用该接口同步按钮初始状态。双模型切换对比的页面截图如图6-2所示。
图6-2双模型切换对比的页面截图
6.2.3异常报警模块
异常报警模块位于检测流水线的末端，承担将数值化检测结果转化为用户友好报警信息的关键任务。
后端的异常判定逻辑分布在detection.py的detect_abnormal方法和camera.py的采集循环中。detect_abnormal方法接收原始检测结果列表，基于预设规则进行判别：当检测到smoke或fire类别时，直接标记为fire_hazard异常；当检测到person类别且置信度超过0.7时，标记为person_detected异常。规则本身设计简洁，可以按需扩展。采集循环在获得检测结果后遍历列表，对每条检测调用save_detection_record方法进行数据库持久化。
save_detection_record方法在flask_app的应用上下文中执行，避免跨线程数据库操作冲突。方法内部首先判断是否存在当前帧数据，若有则将帧数据写入static/uploads目录下的唯一文件名（由uuid生成）。随后将边界框坐标从{x1,y1,x2,y2}格式转换为{x,y,w,h}格式，构造DetectionRecord对象并调用db.session.add和db.session.commit写入数据库。若检测项被标记为异常，则在记录提交后进一步调用deepseek_service.generate_alert_description生成自然语言报警描述，再通过utils.py中的send_alert_message函数创建Message记录，消息内容即为AI生成的描述文本。
DeepSeek服务的调用使用openai兼容接口，将检测信息构造为自然语言提示，请求模型生成50字以内的简洁报警描述。当API调用失败时，回退为固定格式的模板描述，确保报警流程不中断。
前端消息中心页面（messages.html）以列表形式展示所有报警消息，每条消息包含标题、正文和时间戳。未读消息用高亮背景和“新”角标标记，点击“已读”按钮后通过fetch向/api/messages/<id>/read发送POST请求，后端更新数据库中is_read字段，前端刷新列表状态。消息列表截图如图6-3所示。
图6-3消息列表截图
6.2.4历史记录模块
历史记录模块允许用户对过往的检测事件进行回溯和筛选，是异常排查的重要辅助功能。
后端/history路由采用Flask的request.args获取查询参数，包括object_class（目标类别选筛）、start_date/end_date（时间范围）和abnormal_only（仅异常）。在视图函数中，构建初始查询query = DetectionRecord.query.filter_by(user_id=current_user.id)保证数据隔离，随后依次判断各参数是否存在，动态叠加filter条件。日期参数通过datetime.strptime解析为Python日期对象，abnormal_only通过checkbox布尔值过滤is_abnormal为True的记录。最终查询结果按timestamp降序排列，并使用paginate方法实现分页，每页显示20条记录。
前端history.html页面上方放置一个搜索过滤表单，包含类别下拉框、日期输入框和“仅异常”复选框。表单使用GET方法提交，URL参数与后端视图完全对应。点击查询按钮后页面刷新，后端将当前页记录及Pagination分页对象传入模板。模板遍历records生成表格行，每行展示时间、类别、置信度进度条、异常状态徽章和截图缩略图。分页导航根据pagination对象的has_prev、has_next和iter_pages属性生成上一页、页码和下一页链接，保留当前查询参数确保翻页后条件不丢失。
此外，页面底部集成了一个简易的语义搜索入口。用户可在输入框中以自然语言输入查询语句，前端通过/api/semantic_search接口将语句发送给后端。后端调用deepseek_service.semantic_search方法，将查询字符串和最近100条记录的文本表示一同提交给DeepSeek模型，模型返回匹配的记录索引，后端据此筛选并返回结果JSON，前端动态更新表格内容。该功能在本模块中仅作辅助入口，核心查询仍依赖结构化筛选。历史记录页面截图如图6-4所示。
图6-4历史记录页面截图
6.2.5统计分析模块
统计分析模块从多维度汇总检测数据，以可视化图表帮助用户直观把握家庭环境的变化趋势。
后端/statistics路由接收range参数，映射为today、week、month三种时间范围的起始时间。根据起始时间和用户ID查询DetectionRecord记录，传入utils.py的get_detection_statistics函数进行统计计算。该函数遍历记录列表，分别统计class_counts（各类别出现次数）、hourly_counts（24小时各时段次数）、daily_counts（日期维度次数），并统计abnormal_count异常次数和normal_count正常次数。计算完成后，利用to_chart_data辅助函数将字典或列表形式的数据转换为ECharts所需的categories和values结构，同时调用generate_heatmap_data生成热力图数据。
在传递到前端模板之前，为确保数据在Jinja2模板中正确序列化为JavaScript对象，视图函数对四个图表数据对象进行了安全转换，显式地将categories和values转换为Python list，再通过|tojson过滤器注入到前端脚本。这种处理避免了由于SQLAlchemy查询对象延迟加载或自定义类型导致的JSON序列化失败问题。
前端statistics.html页面使用ECharts初始化四个图表实例。classPieChart以饼图展示对象类别分布，abnormalPieChart以饼图展示正常与异常比例，hourlyBarChart以柱状图展示每小时检测数量，dailyLineChart以折线图展示每日检测趋势。各图表的option配置统一通过function遍历传入的categories和values构建series中的data数组，设置了tooltip、legend和响应式尺寸。窗口resize时调用各图表的resize方法保证布局自适应。时间范围切换按钮以链接形式指向同一路由的不同range参数值，点击后页面刷新并重新渲染图表。统计分析页面截图如图6-5所示。
图6-5统计分析页面截图
6.2.6消息中心模块
消息中心模块是异常报警的直接出口，负责将所有系统通知集中呈现给用户。
后端/messages路由获取当前用户的所有消息，按创建时间倒序排列，通过Paginate分页每页显示20条。视图函数同时计算未读消息总数，以unread_count变量传递给模板，用于前端徽标和筛选显示。已读操作通过/api/messages/<int:message_id>/read接口完成，该接口验证消息归属后设置is_read为True并提交数据库，返回JSON成功响应。
前端messages.html页面以Bootstrap的list-group组件渲染消息列表。每条消息项通过id属性标识，根据is_read状态动态添加bg-light背景类和“新”角标。未读消息项的右侧显示“已读”和“删除”两个操作按钮，点击“已读”触发markAsRead函数，该函数通过fetch发送POST到上述API端点，成功后直接重新加载页面；删除操作类似，先弹出确认框，确认后调用删除API并刷新。页面顶部在unread_count大于0时显示“全部已读”按钮，用户可一键标记所有消息为已读。消息中心与异常报警模块紧密结合，确保检测到的异常事件能够在秒级延迟内以可读文本的形式送达用户眼前，效果截图可参见图6-6。
图6-6消息中心页面截图
6.2.7用户管理模块
用户管理模块是管理员专属功能，提供对系统账号的全生命周期管理。
后端/admin/users路由首先通过current_user.is_admin()进行权限校验，非管理员直接重定向至仪表盘。通过后将User表全部用户按创建时间降序排列，分页传递给admin/users.html模板。添加用户通过/admin/users/add路由完成，GET请求返回包含用户名、邮箱、密码和角色选择的表单页面，POST请求接收表单数据，进行用户名和邮箱的唯一性校验，通过后实例化User对象，调用set_password加密密码，存入数据库，同时写入一条create_user类型的审计日志。
编辑用户通过/admin/users/<int:user_id>/edit路由完成，GET请求预填用户名、邮箱、角色和启用状态到编辑表单，POST请求接收更新后的数据。若密码字段非空则调用set_password更新密码，否则保持原密码不变。is_active字段通过checkbox的on/off值控制，数据库中使用Boolean类型映射。用户管理页面列表展示了用户名、角色徽章、启用状态、创建时间和最近登录时间，每行末尾提供编辑按钮跳转到编辑页。整个模块涉及的用户增删改查操作均伴有审计日志记录，日志写入在同一个数据库事务中完成，确保操作与记录一致性。用户列表页面截图如图6-7所示。
图6-7用户管理页面截图
6.2.8系统配置模块
系统配置模块允许管理员在线调整检测置信度阈值、摄像头源和报警规则等运行参数，无需重启服务即可生效。
数据库层面，配置项存放在config_hms表中，每个配置由唯一key标识。系统初始化时通过create_tables函数插入四条默认配置：detection_confidence默认0.5，camera_source默认0，alert_enabled默认true，alert_email默认为空。后端/admin/settings路由返回所有SystemConfig记录的列表渲染到settings.html模板。
管理员在设置页面修改参数并提交表单后，后端遍历请求体中的键值对，逐一更新对应config记录的value字段，并将updated_at时间戳更新为当前时间。每次更新操作同时写入一条update_config类型的审计日志，记录变更项和变更内容。此外，对于检测置信度等关键参数，系统在读取配置时并非每次查询数据库，而是通过Config类的静态属性在启动时加载，若需运行时动态更新，则需要在视图函数中额外调用Config.init_app更新应用配置对象。报警规则目前以文本域形式存储，可扩展为JSON结构规则链。
前端settings.html页面使用Bootstrap表单组件，每个配置项对应一个输入框、下拉菜单或文本域。提交按钮将整个表单以POST方式发送，页面刷新后显示最新的配置值。系统配置页面截图如图6-7所示。
图6-8系统配置页面截图
通过上述八个模块的协同实现，本系统构建了一条从视频采集、实时检测、异常判别、报警生成，到历史回溯、统计分析和系统管理的完整数据链路。各模块均遵循前后端分离的原则，前端仅负责页面渲染和用户交互，业务逻辑和数据处理集中于Flask后端，检测计算以独立线程异步进行，较好地满足了家庭安防场景对实时性、易用性和可维护性的要求。
扫一扫
271
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
