From 8a62c461947a63e0dd430c90069af3f2ed37e5d1 Mon Sep 17 00:00:00 2001 From: ericwyuan Date: Thu, 20 Aug 2026 16:15:28 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20update=20PROGRESS.md=20-=20Gemini?= =?UTF-8?q?=E8=A7=86=E8=A7=89=E8=A7=A3=E6=9E=90=E6=8E=92=E6=9F=A5=E7=BB=93?= =?UTF-8?q?=E8=AE=BA+=E4=B8=9A=E5=8A=A1=E5=85=A8=E6=B5=81=E7=A8=8B?= =?UTF-8?q?=E5=9B=BE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- PROGRESS.md | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/PROGRESS.md b/PROGRESS.md index c4acee2..ef85fbc 100644 --- a/PROGRESS.md +++ b/PROGRESS.md @@ -1,6 +1,6 @@ # 项目进度追踪 -> 最后更新: 2026-08-20 15:45 +> 最后更新: 2026-08-20 16:30 ## 服务运行状态 @@ -161,6 +161,49 @@ 19. **chunk_size 变更防护** - Edge 端 upload_chunk 检测 total_chunks 变更（由 chunk_size 变化导致），自动清理旧分块防止混合不同大小分块导致 assemble 后文件损坏。NAS 端 _query_uploaded_chunks 比对 expected_total != edge_total 时跳过断点续传 20. **看门狗机制** - app.py 启动 daemon 看门狗线程，每 60s 检查 scheduler/dispatcher/poller 线程 is_alive()，崩溃自动 check_and_restart()。/api/status 改用 thread.is_alive() 替代 _running 标志，防止线程假死误报 +## Gemini 视觉解析排查 + 业务全流程梳理 (2026-08-20 16:30, commit f4e7424) + +**结论: Gemini 可以解析视频（多帧视觉分析），且有 40s 完成整段分析的实测记录，但当前被三重问题压制** + +### 排查过程 +1. 日志证据: 07:43:05 Gemini 返回了完整 JSON（耗时 40s，6 帧多图分析），但被本地 `parse_vlm_json` 拒收——"缺失字段: compute_provider" +2. 根因: `validate_schema` 把 `compute_provider` 列为必填，但提示词从不要求模型输出它（该字段是 orchestrator 解析成功后自行填充的记账字段）→ **Gemini 的有效响应被 100% 误杀**；NVIDIA 走单帧轻量解析绕过校验故不受影响 +3. 修复 (commit f4e7424): `compute_provider` 移出必填清单，归一为空数组由 `format_cloud_result` 覆盖填充，已部署 Edge + +### 当前外部服务状态（与代码无关的临时故障） +| 模型 | 状态 | 表现 | +|------|------|------| +| Gemini | ❌ 503 过载 | "high demand, temporary"，早间多次 503 | +| NVIDIA NIM | ❌ 500 推理连接错误 | llama-3.2-11b-vision 端点持续 Internal Server Error | +| Ollama qwen2.5:7b | ✅ 但纯文本 | 无法做视觉分析，故双云故障期间任务全失败 | + +task 298/300 失败均因双模型同时故障；NAS 端 FAILED 已重置 PENDING（22 个积压），模型恢复后自动重跑。 + +### 强杀服务引发的边缘情况（已自愈，无需修码） +- 强杀 processing 中的 worker 后，视频文件消失但队列行卡 PROCESSING → 新 run 的 60 次 seek 全部 0.07s 快速失败，但复用上一 run 残留的帧目录完成分析 +- 已通过手动 reset PROCESSING→PENDING 恢复；正常流程下不建议 kill -9 处理中的任务 + +### 业务全流程（当前架构） +``` +[摄像头 SurveillanceStation] → 30min/段 落盘 NAS /volume1/surveillance (360MB 1080p) + ↓ Scheduler (60s 扫描, 文件稳定 60s 判定) +[MariaDB process_tasks: PENDING] ← 每段视频一个任务 + ↓ Dispatcher (30s 轮询, 串行 limit=1) +① FFmpeg 预压缩: 480p/CRF28/veryfast, 360MB→22MB (16x), ~560s, 缓存24h +② 5MB 分块上传 Edge: 5 块, ~60-100s, 断点续传+3次块级重试 +[Edge SQLite task_queue: PENDING] (UNIQUE nas_task_id, 失败重派发自动重置) + ↓ Consumer 线程 (10s 轮询, TokenBucket 限速: Gemini 1000RPM/NVIDIA 40RPM) +③ 抽帧: 快速 seek 粗抽 60 候选 → MSE 帧差筛 6-12 关键帧 → 压缩 JPEG +④ 视觉分析: Gemini 多图(首选,~40s) → NVIDIA 单帧(降级,~30s) → 全失败则 FAILED +⑤ 融合: frame_details + global_summary + entities_json (compute_provider 记账) + ↓ Poller (30s 拉取 /api/edge/results, SUCCESS+FAILED 均回传) +[MariaDB monitor_events + event_details 落库, event_id 递增] + ↓ FAM-UI (Streamlit :8501) / Chat (Gemini→NVIDIA→Ollama 降级) +[用户查看事件时间线 / 命名成员 / 问答] +``` + +**单任务周期 ~12 分钟**（压缩 9.3min + 上传 1min + 分析 1min），瓶颈在 NAS ARM CPU 压缩速度。 + ## 视频上传问题根因排查与修复 (2026-08-20 15:45, commit 8cb5553) **问题定性**: 网络问题 + 逻辑问题双重叠加