whqxbs/llmiotsafe

Fork 0

Files

whqxbs e56494b487 initial commit

2026-05-12 17:01:39 +08:00

12 KiB

Raw Blame History

DPO 训练数据设计方案

1. 总体规划

1.1 数据规模

数据集	用途	数量	说明
`data/train_pref/`	DPO 训练	2500 对	preference pairs (chosen + rejected)
`data/dev_pref/`	验证/早停	300 对	从训练集中分出
`data/benchmark/`	测试（不动）	1200 episodes	已有的，完全隔离

1.2 隔离原则

Benchmark (测试集)                    Training (训练集)
─────────────────                    ─────────────────
35 个场景 (INS-01~05, DF-01~06...)   40 个新场景 (完全不同的 causal pattern)
35 个 FP 变体                         40 个新 FP 变体
4 种布局 (A/B/C/D)                    4 种新布局 (E/F/G/H) 或同布局不同配置
3 种画像                              3 种新画像变体
固定 query 模板                       重写的 query 模板

2. 训练场景设计（40 个新场景，与 benchmark 的 35 个完全不重叠）

2.1 Intrusion 类（8 个新场景）

ID	场景名	与 benchmark 的区别
T-INS-01	临时访客码在非预约时段使用	benchmark INS-05 是被盗凭证，这个是合法码被滥用
T-INS-02	连续多天同一时间段出现陌生运动模式	benchmark INS-01 是单次破窗，这个是持续性异常
T-INS-03	门锁解锁后无对应 occupancy 触发	benchmark 没有这种"缺失信号"型入侵
T-INS-04	阳台门深夜打开+室内无对应活动	benchmark INS-01 是窗户，这个是阳台门
T-INS-05	多个窗户传感器短时间内依次触发	benchmark 没有"扫描式"入侵模式
T-INS-06	门锁被远程解锁但住户手机不在家	需要推断"远程操作+无人在家"的矛盾
T-INS-07	安防系统被 Disarm 但无对应的门锁操作	系统被绕过的信号
T-INS-08	住户出门后家中出现规律性运动（每天同一时间）	跟 benchmark BA-05 不同——这个是规律性的

2.2 Fire/Gas 类（6 个新场景）

ID	场景名	与 benchmark 的区别
T-FG-01	多个房间温度同时异常上升（非单一热源）	benchmark FG-02 是单房间，这个是全屋
T-FG-02	灶具关闭后温度持续上升（余热异常）	benchmark FG-01 是忘关火，这个是关了但温度还涨
T-FG-03	烟雾传感器 ContaminationState 逐步恶化	benchmark DF-05 是突发故障，这个是渐进退化
T-FG-04	厨房 CO 浓度缓慢上升（不触发报警阈值）	benchmark FG-03 是直接 COAlarm，这个是亚阈值
T-FG-05	电器运行时间异常长（洗碗机 3 小时不停）	可能过热风险
T-FG-06	多个烟雾报警器的 InterconnectSmokeAlarm 触发	benchmark 没有互联报警场景

2.3 Water Damage 类（4 个新场景）

ID	场景名	与 benchmark 的区别
T-WD-01	漏水传感器间歇性触发（每隔几小时一次）	benchmark WD-01 是持续触发，这个是间歇性
T-WD-02	卫生间湿度持续升高但无人使用	隐蔽漏水的间接信号
T-WD-03	洗衣机运行结束后漏水传感器延迟触发	排水管问题
T-WD-04	多个房间的漏水传感器先后触发（水蔓延）	benchmark 只有单点漏水

2.4 Device Fault 类（8 个新场景）

ID	场景名	与 benchmark 的区别
T-DF-01	空调运行但温度不下降（制冷失效）	benchmark 没有空调故障
T-DF-02	两个相邻房间温度传感器读数差异突然增大	交叉验证型故障检测
T-DF-03	洗衣机 OperationalState=Running 但 CountdownTime 不减少	benchmark DF-06 是窗帘，这个是洗衣机
T-DF-04	运动传感器在确认无人时段持续报 Occupied	benchmark DF-03 是周期性，这个是持续性
T-DF-05	门窗传感器状态与窗帘位置矛盾	窗户关着但窗帘显示全开位置
T-DF-06	温度传感器读数出现物理不可能的跳变	瞬间从 23°C 跳到 -5°C
T-DF-07	灯的 OnOff 状态与 LevelControl 矛盾	OnOff=False 但 Level=200
T-DF-08	设备频繁离线重连（通信不稳定）	benchmark 没有通信层故障

2.5 Elderly 类（6 个新场景）

ID	场景名	与 benchmark 的区别
T-EL-01	老人连续多天活动范围缩小（只在一个房间）	渐进性退化
T-EL-02	老人用餐时间逐步推迟（作息漂移）	benchmark EL-04 是突然不起床，这个是渐变
T-EL-03	老人夜间在非卧室区域长时间停留	可能迷路/意识模糊
T-EL-04	老人出门频率突然下降（从每天到隔天到不出门）	社交退缩信号
T-EL-05	老人做饭时间异常短（从 30 分钟缩短到 5 分钟）	可能不再正常进食
T-EL-06	老人半夜反复开关同一个灯	可能意识混乱

2.6 Child 类（4 个新场景）

ID	场景名	与 benchmark 的区别
T-CH-01	儿童在家长睡觉后使用厨房电器	benchmark CH-02 是白天，这个是深夜
T-CH-02	儿童反复尝试打开被锁定的房间	好奇心驱动的危险行为
T-CH-03	儿童活动区域突然从儿童房转移到阳台	高处坠落风险
T-CH-04	放学后长时间只有浴室有活动信号	可能的自伤风险（需谨慎处理）

2.7 Behavioral Anomaly 类（4 个新场景）

ID	场景名	与 benchmark 的区别
T-BA-01	住户回家后不开灯不开空调直接进卧室	情绪/健康异常信号
T-BA-02	设备使用频率突然翻倍（强迫性行为）	benchmark BA-03 是灯光闪烁，这个是全设备
T-BA-03	住户连续多天不使用厨房（不做饭不吃东西）	生活能力下降
T-BA-04	两个住户的活动时间完全不重叠（回避行为）	家庭关系异常

3. 训练 FP 变体设计原则

每个训练场景都配一个 FP 变体，设计原则：

与 benchmark FP 的区别：

benchmark 的 FP 是"同一事件的正常解释"（如：窗户打开→住户通风）
训练集的 FP 要设计"不同但相似的正常模式"（如：临时访客码使用→预约的清洁工按时到达）

FP 难度分层：

30% Easy FP：明显正常（有直接的正常证据）
50% Medium FP：需要推理才能排除（证据模糊）
20% Hard FP：极其接近 TP（只有一个细微差异）

4. DPO Pair 构造方案

4.1 Chosen（正确回答）的来源

来源	比例	说明
规则生成	40%	根据 ground truth 直接构造标准答案（is_anomaly + threat_type + 推理链）
强模型生成	40%	用 DeepSeek V4 / Claude 跑训练集，筛选答对且推理链好的
人工编写	20%	对高难度场景手写高质量推理链

4.2 Rejected（错误回答）的来源

来源	比例	错误类型
模型实际错误	50%	用 Qwen3.5-9B baseline 跑训练集，收集错误输出
构造性错误	30%	人工/规则构造典型错误模式
对调错误	20%	把 TP 的 chosen 改成 is_anomaly=false（漏报），把 FP 的 chosen 改成 is_anomaly=true（误报）

4.3 构造性错误的具体类型

错误类型 1: 漏报（TP 场景判为正常）
  - "温度波动在正常范围内" ← 实际是 stuck-at 故障
  - "运动传感器触发可能是宠物" ← 实际是入侵

错误类型 2: 误报（FP 场景判为异常）
  - "温度上升可能是火灾" ← 实际是正常做饭
  - "凌晨运动可能是入侵" ← 实际是住户失眠

错误类型 3: 类型判错
  - 把 sensor_stuck 判成 fire_risk
  - 把 intrusion 判成 behavioral_anomaly

错误类型 4: 证据编造
  - 引用了日志中不存在的事件
  - 时间戳引用错误

错误类型 5: 推理链断裂
  - 结论跟证据不匹配
  - 跳过关键推理步骤

5. 数据分布设计

5.1 按场景类别

类别	训练场景数	TP pairs	FP pairs	TN pairs	总 pairs
Intrusion	8	400	300	—	700
Fire/Gas	6	250	200	—	450
Water Damage	4	150	100	—	250
Device Fault	8	350	250	—	600
Elderly	6	150	100	—	250
Child	4	100	80	—	180
Behavioral	4	100	70	—	170
TN (纯正常)	—	—	—	200	200
合计	40	1500	1100	200	2800

5.2 按难度分布

难度	比例	说明
L1 (直接信号)	20%	让模型学会"有报警就报"
L2 (推理检测)	45%	核心训练重点
L3 (复合推理)	35%	提升上限

5.3 按错误类型分布

Rejected 错误类型	比例	目的
漏报	35%	提升 Recall
误报	30%	降低 FA
类型判错	15%	提升 threat_type 准确率
证据编造	10%	提升推理链质量
推理断裂	10%	提升推理链质量

6. Query 模板隔离

Benchmark 的 query（不能用于训练）：

SQ1: "请检查以下设备状态历史，判断 {room} 区域的传感器是否工作正常。"
SQ2: "以下是刚刚发生的事件。请判断这是否构成安全威胁，并说明理由。"
SQ3: "以下是过去 {N} 小时的设备活动日志。请分析是否存在异常行为模式。"

训练集的 query（重写，同任务不同措辞）：

SQ1 等价: "根据以下传感器数据记录，评估 {device_name} 的工作状态是否正常。"
SQ2 等价: "系统记录了以下设备状态变化。请评估这些变化是否指示安全风险。"
SQ3 等价: "以下是 {time_range} 内的设备活动记录。请识别其中是否存在可疑模式。"
SQ4 等价: "综合以下多个设备的状态信息，评估家庭整体安全状况。"
SQ5 等价: "监控系统标记了潜在异常。请分析情况并建议应对措施。"

7. 布局隔离方案

方案 A（推荐）：同布局不同设备配置

复用 Layout A/B/C/D 的房间结构，但：

设备数量不同（比如训练集的 Layout A 有 2 个温度传感器而非 3 个）
设备位置不同（比如烟雾报警器在卧室而非厨房）
增加 benchmark 没有的设备（如加湿器、扫地机器人的运行状态）

方案 B：全新布局

Layout E: 复式楼（上下两层）
Layout F: 开放式公寓（厨房客厅一体）
Layout G: 合租房（多个独立卧室共用客厅厨房）
Layout H: 带地下室的独栋

我建议用方案 A——因为布局本身不是训练重点，设备配置的微调就够了，省工作量。

8. 实施步骤

Step 1: 写 40 个新场景的 JSON 模板 (data/train_pref/scenarios/)
Step 2: 写 40 个对应的 FP 变体
Step 3: 修改 generate.py 支持从训练场景库生成 episodes
Step 4: 生成 2800 个训练 episodes
Step 5: 用 Qwen3.5-9B baseline 跑训练集，收集 rejected
Step 6: 用 DeepSeek/Claude 跑训练集，收集 chosen
Step 7: 组装 DPO pairs (chosen + rejected)
Step 8: QLoRA DPO 训练 Qwen3.5-9B
Step 9: 在 benchmark 1200 上评测

9. 预期效果

指标	训练前 (EDRC)	训练后 (DPO) 预期
Recall	80.5%	75-85%（保持）
FA%	64.3%	25-35%（大幅下降）
F1	0.628	0.70-0.78
Threat Type Acc	~50%	65-75%

DPO 的核心价值不是提升 Recall（EDRC 已经 80%），而是在保持 Recall 的同时大幅降低误报——因为训练数据中 30% 的 rejected 是误报案例，模型会学到"什么时候不该报"。

10. 风险与缓解

风险	概率	缓解
训练后 Recall 下降	中	rejected 中 35% 是漏报案例，平衡训练信号
过拟合训练场景	中	训练/测试场景完全隔离 + dev set 早停
2×A100 显存不够	低	QLoRA 4-bit，9B 模型只需 ~12GB
DPO 训练不稳定	低	用 TRL 的 DPOTrainer，成熟框架
效果不如预期	中	先跑 500 对 pilot，看趋势再扩

12 KiB Raw Blame History Unescape Escape