# Qwen3.8-27B 智能眼 (视频质检 VL) 实验 — 2026-08-15

## 假设
KMC 缺少系统性"运镜/构图/一致性"视频质检。Qwen3.8-27B (q3 共存档, mmproj 视觉) 
作为本地 VL 评判眼, 可填补该空白。

## 架构定位 (与现有体系的关系)
- vision_verify (GLM-4.6V 云端): 单用途字符/内容匹配门控 → 保留, 做高层语义
- P14 quality audit: 元数据审计 (时长/TTS/字段) → 保留
- qwen-eye (本次): 新增逐镜头运镜/构图/轴线/崩坏质检, 填补空白
- 未来: qwen-eye fail → 触发 P11 定点重渲, 形成闭环

## 实验设计 (判别力测试)
- 素材: ep-cat-worker-001, 20 P11 镜头, 5帧均匀采样/镜头
- 正配对 20 (spec↔video 原配, 期望 pass) — 检查假阳性率
- 负对照 8 (交叉配对): 6 强反差 + 2 仅运镜不符 — 检查判别灵敏度
- 重复 3×2 (S1-01/S4-01/S7-03) — 检查输出稳定性
- 双臂: 本地 Qwen3.8-27B q3 (:8125) vs 云端 GLM-4.6V 同 prompt 同帧
- temperature=0.1, JSON 输出, 逐维 bool + verdict + quality_issues

## 成功判据 (Kai 验收标准)
1. 解析成功率 ≥ 90% (JSON 可靠性)
2. 负对照 fail 检出率 ≥ 6/8 (75%) — 判别力核心指标
3. 正配对 pass 率 ≥ 80% — 假阳性控制
4. 重复测试 verdict 一致率 100% (3/3)
5. 延迟: 单镜头评判 < 60s (批量可行性)
6. GLM 对照: 记录判别力差异, 若 Qwen 显著劣于 GLM 则记录差距供决策

## 中期发现 (2026-08-15 下午)

### 云端 GLM-4.6V 不可用 (硬结论)
1. **多图输入 = 模式填充幻觉**: 5图+JSON模板prompt → 20/20 输出"穿深色上衣的人站室内浅色墙壁"
   (像素证据: S4-01 orange=66% 是橘猫特写)
2. **单图也不稳**: S4-01/f2 两次调用 → "猫近景" vs "黑色人形"
3. **析因排除**: 不是图数/顺序问题, 是 "输出JSON+字段清单" 触发填表模式, 跳过视觉
4. 修复尝试 v4 (自然语言观察) 曾一度生效 (S4-01正确识别猫+便利贴文字), 但全量跑时又退化为模式填充
5. **复现**: 同图同prompt 3次 → 稳定输出 "人,黑色" (与像素证据矛盾)

### 本地 Qwen3.8-27B VL 表现优异 (CPU 2.1t/s)
- S4-01: "橘猫爪按便利贴'Don't forget to eat!', 特写" ✓ (含OCR!)
- S1-01: "橘猫穿蓝色工装站地铁站台, 人群深色调" ✓ 场景吻合
- S8-01: "建筑外立面暖黄窗灯+微小人影" ✓ 接近规格"城市窗口亮灯"
- S6-02: "拟人橘猫深蓝衣持纸条, 暗背景" ✓
- thinking 模式开启时观察质量更高

### 提帧方案
5帧均匀采样 (3%/30%/55%/80%/95%), scale=800 宽, q=7 JPEG

---
## 17:55 发现: llama.cpp 多图输入 bug + 解决方案

**bug**: 单条 user 消息含 N 张图时, llama.cpp 只计入 ceil(N/2) 张 (2图=1张, 5图=3张)
- 证据: token 计数 371 vs 371 (2图), 1075 vs 1829 (5图 vs 方案A)
- 影响: 观察质量打折但模型不报错 — 静默丢图!

**方案A (已验证)**: 每张图单独一条 user 消息 → 5图全部到达 (1829 tokens)
- 副作用: 无, OpenAI 兼容格式连续多条 user 消息合法

## 18:00 最终版全量跑 (judge_final_local.py)
- thinking off + 方案A + 断点续跑
- 进度: 3/28 done (S1-01/02/03, 全 fail 但有理有据 — 与已知的S1场景漂移一致)
- 25 remaining, CPU ~5.5min/条, 预计 ~2.3h
- server: :8126 CPU模式 (GPU1被ComfyUI占满, q3档等待中)

## S1 系列判定的意义
S1-01/02/03 全部 fail 且理由具体(景别/构图/内容不匹配) — 这些与此前像素证据发现的
"S1场景漂移(室内 vs 规格地铁)"吻合 → 智能眼抓到了真问题, 不是误报


---
## 17:55 发现: llama.cpp 多图输入 bug + 解决方案

**bug**: 单条 user 消息含 N 张图时, llama.cpp 只计入 ceil(N/2) 张 (2图=1张, 5图=3张)
- 证据: token 计数 371 vs 371 (2图), 1075 vs 1829 (5图 vs 方案A)
- 影响: 观察层静默丢图!

**方案A (已验证)**: 每张图单独一条 user 消息 → 5图全收到 (1829 tokens)

## 18:00 最终版全量跑 (judge_final_local.py)
- thinking off + 方案A + 断点续跑
- 进度: 3/28 done, 25 remaining, CPU ~5.5min/条, 预计 ~2.3h
- server: :8126 CPU模式 (GPU1被ComfyUI占用, q3档等待中)

## S1 系列判定的意义
S1-01/02/03 全 fail 且理由具体 — 与像素证据发现的 S1场景漂移 吻合 → 智能眼抓到真问题


## 19:10 OOM 事件与恢复
- ComfyUI 渲染脉冲抢占 GPU1 显存 → q3 CUDA OOM 挂掉 → 判定脚本 10 条 HTTP 503/refused
- 这就是 memory 记录的"渲染期 LLM 让位"设计行为的实证: 智能眼与渲染共卡必受此约束
- KAP 自愈把档位拉成了 q4 (20.9GB, ctx 64K) — 判定跑 :8125 不受影响
- 教训: 判定批次要幂等+断点续跑(error 行重试), 或错峰跑


---
## 19:30 最终结果 (28/28 完成)

### 混淆矩阵
| 配对 | pass | fail | 说明 |
|------|------|------|------|
| 正配对 20 | 3 | 17 | fail 多与像素证据的真实质量问题吻合 |
| 负对照 8 | 0 | 8 | **拦截率 100%, 零误放行** |

### 正配对 fail 维度分布
- composition_ok: 13/20 (规格要求三分法, 渲染主体居中 — LTX/H3 引擎确实不遵守构图规格)
- framing_ok: 10/20
- content_match: 5/20 (S1 场景漂移等真问题)
- camera_ok: 5/20
- axis_ok: 2/20

### 稳定性: 7 对重复判定 100% 一致 (temp=0.1 + 判定层文本化)

### 速度
- GPU q3/q4 (RTX3090): ~25-30s/镜 (5帧观察+判定)
- CPU (39线程): ~5.5min/镜 (应急可用)

### 架构结论
观察层(Qwen3.8-27B VL) + 判定层(同模型文本模式) 两段式:
- 观察层: 每图一条 user 消息(绕 llama.cpp 多图丢弃 bug), 自然语言描述, 5帧
- 判定层: 观察+SPEC → 维度级 JSON (framing/camera/composition/axis/content)
- 关键: 云端 GLM-4.6V 多图输入触发模板幻觉不可用; 本地 Qwen 观察精准(含OCR/运镜方向)

### 生产集成约束
1. 渲染期 ComfyUI 脉冲会 OOM 掉 LLM (设计行为) → 判定批要幂等+断点续跑, 或错峰
2. 双进程并发写 jsonl 需避免 (上 flock 或单写者队列)
3. 28 任务实测: q3 13.4GB 与渲染共存有风险, q4 20.9GB 需 GPU 独占窗口