案例详情 - 从车载视频到结构化客流数据：公交场景 AI 工程化交付案例

案例概览

出于客户与数据隐私要求，案例中不展示客户名称、原始视频画面、车牌、站点、真实接口地址、服务器信息或未脱敏日志。

项目背景

公交运营场景每天会产生大量车载视频数据。客户希望从视频中自动提取乘客上下车、车厢内人员变化与车门区域客流等信息，并将分析结果接入现有业务系统，用于后续的数据统计、运营分析与业务决策。

这个项目的重点不是“检测画面里有几个人”，而是将原始视频数据转化为业务系统可以使用的结构化客流结果。系统需要接收外部任务、异步分析视频、组合多个模型完成判断，并把结果可靠地回传给客户系统。

解决方案

Model2System Studio 为该场景设计并实现了一套公交车视频智能分析系统。系统接收客户业务系统提交的视频分析任务，进入异步任务队列后，由 worker 自动完成视频下载、缓存、模型推理、片段分析、结果聚合与回调返回。

分析流程中集成了人员检测、车门检测、车厢区域识别与 ReID 等多个模型，并结合业务规则对乘客上下车行为进行判断。系统不仅关注模型识别效果，也完整处理了任务状态、异常日志、结果回调、监控指标与部署运行等生产环境问题。

为什么这不是普通检测 Demo

普通检测 Demo 通常只展示某一帧中的目标框，而真实公交客流识别需要回答的是：谁在什么时候从哪个门上车或下车，结果是否能被业务系统接收、追溯和复核。

因此，本项目在模型之外额外构建了门区稳定、轨迹跟踪、事件识别、OD 状态管理、证据链截图、异步任务队列、结果回调和监控部署等能力，使算法结果可以进入真实业务流程。

技术亮点

面向真实公交车载视频，本项目并不是简单地对单帧画面做目标检测，而是围绕“车门区域、乘客轨迹、上下车事件、跨站点关联和生产部署”构建完整算法链路。

从单帧检测升级为时序事件识别

系统将公交客流识别建模为“时序事件识别”问题。它不仅判断画面中是否有人，还会结合乘客轨迹、车门区域、运动方向与前后状态变化，识别真正发生的上车、下车事件，从而降低单帧误检、漏检对计数结果的影响。

门区稳定建模，减少系统性误计数

系统对车门区域进行了稳定建模，通过门框检测、稳定门位估计和抖动抑制，降低车辆抖动、摄像头角度变化和单帧检测波动带来的影响。上下车事件判断围绕稳定门区进行，而不是简单依赖画面坐标变化，从而减少“靠近门但未上下车”“门区定位抖动”等场景下的误计数。

两阶段事件识别，适配不同车辆和摄像头角度

系统采用两阶段事件识别策略。第一阶段从当前视频中提取稳定、可信的跨门区轨迹，自动生成本段视频的参考运动模式；第二阶段再将所有候选轨迹与参考模式进行对比，完成上下车计数和逐人事件输出。

这种设计使系统可以根据不同车辆、不同摄像头角度、不同门区位置自动适配运动模式，而不是依赖一套固定规则硬套所有视频。

DTW 轨迹匹配，提升拥挤和遮挡场景鲁棒性

针对乘客上下车过程中常见的停顿、拥挤、遮挡和运动速度不一致问题，系统在轨迹匹配中引入 DTW（动态时间规整）方法。它允许不同长度、不同速度的轨迹进行形态对齐，从而提升复杂场景下事件判断的鲁棒性。

BoTSORT + ReID，构建稳定的逐人轨迹基础

系统在检测基础上引入多目标跟踪与 ReID 特征，用于维护乘客在视频中的连续轨迹。相比仅按检测框逐帧统计，跟踪与 ReID 可以降低遮挡、交叉、短时丢失带来的 ID 切换问题，为逐人事件、上下车判断和 OD 匹配提供更稳定的轨迹基础。

简单来说，系统会尽量判断“前后出现的是不是同一个人”，而不是每一帧重新数一遍。

TripBank 支持跨任务 OD 连续关联

OD 匹配不是单段视频内的孤立问题，而是跨站点、跨任务、跨时间窗口的连续关联问题。系统设计了 TripBank 机制，将乘客轨迹特征和上下车状态存储在 Redis 状态中心，并提供本地快照兜底，使 OD 匹配可以在多个任务之间连续进行，同时支持重放、恢复和问题排查。

系统流程

我们为该场景设计的核心流程包括：

1. 接收客户业务系统提交的视频分析任务。
2. 根据任务状态与处理能力进入异步队列。
3. 自动下载并缓存待分析视频。
4. 调用人员检测、车门检测、车厢区域识别与 ReID 等模型。
5. 对关键片段进行乘客状态分析与上下车判断。
6. 聚合视频片段结果，生成结构化客流分析数据。
7. 通过回调接口返回客户业务系统。
8. 记录日志、调试数据与监控指标，支持后续排查和优化。

核心技术能力

• 车载视频中的人员检测与跟踪。
• 门区稳定建模与上下车事件分析。
• 车厢内人员数量变化判断。
• 多模型组合推理，包括人员检测、门检测、ReID 与车厢区域模型。
• 两阶段事件识别与 DTW 轨迹匹配。
• BoTSORT + ReID 多目标跟踪。
• TripBank 跨任务 OD 连续关联。
• 逐人事件证据链与关键帧调试数据。
• 异步任务队列与多 worker 并发处理。
• 视频下载、缓存、分段分析与结果聚合。
• API 接入、任务状态管理与结果回调。
• 日志记录、本地调试 JSON 与问题排查机制。
• Prometheus / Grafana 监控指标接入。
• Docker 化部署与生产环境运行支持。
• GPU / 华为昇腾 Ascend 300i 等硬件环境适配。

输出结果与可追溯能力

系统输出的不只是总人数，而是围绕任务、时间片、门区、乘客轨迹和事件结果生成结构化数据。对于关键上下车事件，系统保留调试数据、关键帧和中间结果，便于后续验收、复核和问题定位。

这类证据链能力在真实项目中很重要：当业务方发现某段视频统计异常时，工程团队可以回到具体任务、具体片段、具体轨迹和具体事件，而不是只能重新跑一遍黑盒脚本。

项目难点

真实车载视频质量不稳定

车内光照、遮挡、拍摄角度、乘客密集程度、画面抖动和上下车动作不清晰都会影响识别效果。系统不能只依赖理想样本，需要围绕真实视频数据做持续分析和误差排查。

业务判断不等于单帧检测

公交客流分析不仅是检测画面里有几个人，还需要结合车门区域、时间片段、人员运动轨迹与前后状态变化判断上下车行为。最终输出必须符合客户业务系统的统计口径。

系统需要接入真实业务流程

分析服务需要支持外部系统提交任务、异步处理、状态记录、结果回调和异常恢复，而不是离线脚本。任务失败、视频异常、模型推理异常和回调异常都需要有可追踪的处理路径。

多模型协同带来工程复杂度

人员检测、车门检测、ReID、车厢区域识别等模型需要在同一条分析流程中稳定协作。模型之间的输入输出、推理性能、异常处理和结果聚合都需要工程化设计。

部署环境和性能要求复杂

项目需要考虑多进程 worker、任务队列、缓存、监控、日志、Docker 化部署和国产硬件适配等生产环境问题。交付重点不仅在模型效果，也在系统稳定性、可维护性和生产部署能力。

生产部署与国产算力适配

项目支持 Ascend 300i 环境下的 ACL 推理部署，并针对模型输出格式、buffer 尺寸、异常数值、API 兼容性和性能剖析做了工程化适配。

系统可在国产算力环境中完成视频分析任务，适合政企、交通、能源等对私有化和国产化部署有要求的场景。这部分能力也让项目不止停留在算法验证，而是能真正进入客户生产环境。

交付成果

本项目最终交付了一套可接入业务系统的公交车视频智能分析服务，包括算法分析流程、API 服务、异步任务队列、worker 处理流程、结构化结果输出、回调机制、监控指标、部署文档与测试支持。

该案例体现了 Model2System Studio 的核心能力：将 AI 模型从实验原型推进到可部署、可集成、可维护的生产系统。

可扩展方向

在公交客流统计基础上，同类系统可以继续扩展到多路 RTSP 视频接入、车厢拥挤度分析、站点维度客流统计、异常上下车行为识别，以及面向调度系统的数据看板。

对于交通、园区、工业和安全生产等场景，类似方法也可以复用到人员检测、区域计数、行为识别、风险告警和视频结果回传流程中。