16 KiB
16 KiB
SafeHome 对抗辩论框架设计方案
Adversarial Deliberation for IoT Security Reasoning (ADISR)
1. 核心思想
一句话：让两个立场对立的 LLM 角色（Prosecutor 检察官 vs Defender 辩护人）各自从同一份设备日志中寻找支持自己立场的证据，然后由一个中立的 Judge（裁判）比较双方论据的质量和证据强度，做出最终判定。
为什么这能解决 Recall-FA 的矛盾：
当前所有方法的根本问题是让同一个决策者同时承担"不漏报"和"不误报"两个互相矛盾的目标。无论怎么调 prompt，模型要么偏敏感（DeepSeek baseline: 90% Recall, 84% FA）要么偏保守（EGPv2 thinking: 21% Recall, 3% FA）。
对抗辩论把这个矛盾解耦到两个角色上：
- Prosecutor 只负责"不漏报"——它的 KPI 是找到所有可能的异常证据
- Defender 只负责"不误报"——它的 KPI 是为每个"异常"找到合理的正常解释
- Judge 不需要自己分析日志，只需要比较双方已经整理好的证据
2. 学术定位与顶会支撑
2.1 理论基础
| 支撑论文 | 会议 | 核心贡献 | 我们的区别 |
|---|---|---|---|
| Improving Factuality through Multiagent Debate | ICML 2024 | 证明多 agent 辩论提升事实准确性 | 他们是同构辩论（同一 prompt），我们是异构对抗（对立 prompt） |
| Better LLM Reasoning via Dual-Play | arXiv 2025 | 双角色对抗提升推理 | 他们做数学推理，我们做安全推理 |
| Adaptive Coopetition | NeurIPS 2025 | 竞争+合作的多 agent 推理 | 他们用 verifier signal，我们用对抗辩论 |
| Adversarial Yet Cooperative | arXiv 2025 | 对抗性多视角推理 | 他们做 RAG，我们做 IoT 安全推理 |
| Audit-LLM | arXiv 2024 | 多 agent 协作做日志威胁检测 | 他们是协作式，我们是对抗式；他们做 insider threat，我们做 IoT 物理安全 |
2.2 我们的创新点（与上述工作的差异化）
-
异构对抗 vs 同构辩论：ICML 2024 的 Multiagent Debate 让多个相同的 agent 辩论，我们让立场预设对立的 agent 辩论——Prosecutor 被明确要求"找异常"，Defender 被明确要求"找正常解释"。这不是随机分歧，而是结构性对抗。
-
Evidence-Grounded Debate：不是让两个 agent 空谈，而是要求每个论点必须**引用具体的设备事件（时间戳+设备ID+数值）**作为证据。Judge 的判定基于证据质量而非修辞质量。
-
Domain-Specific（IoT 安全）：现有辩论框架都是通用的（数学、事实核查、RAG），我们是首个将对抗辩论应用于 IoT 设备日志安全推理的工作。
-
Asymmetric Burden of Proof（非对称举证责任）：不是简单的多数投票。在安全领域，漏报的代价 > 误报的代价，所以 Judge 的决策规则是非对称的——Prosecutor 只需要提供"合理怀疑"级别的证据就够了，Defender 需要提供"排除合理怀疑"级别的证据才能推翻。
3. 框架架构
3.1 整体流程
┌──────────────────────────────────────┐
│ Input Episode │
│ (Home Layout + Event Log + Query) │
└──────────────┬───────────────────────┘
│
┌──────────┴──────────┐
│ Evidence Extractor │ (共享的预处理步骤)
│ 提取关键事件摘要 │
└──────────┬──────────┘
│
┌──────────────┴──────────────┐
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ PROSECUTOR │ │ DEFENDER │
│ (检察官) │ │ (辩护人) │
│ │ │ │
│ 立场: 找异常 │ │ 立场: 找正常解释 │
│ 输出: │ │ 输出: │
│ - 异常假设 │ │ - 正常假设 │
│ - 支持证据 │ │ - 支持证据 │
│ - 威胁评估 │ │ - 反驳检察官 │
└────────┬────────┘ └────────┬─────────┘
│ │
└──────────────┬──────────────┘
│
▼
┌──────────────────────────┐
│ JUDGE │
│ (裁判) │
│ │
│ 输入: 双方论据 + 证据 │
│ 规则: 非对称举证责任 │
│ 输出: 最终判定 + 理由 │
└──────────────────────────┘
3.2 各角色详细设计
Stage 0: Evidence Extractor（证据提取器）
目的：从原始日志中提取关键事件摘要，减少后续角色的 token 消耗。
输入：完整的设备事件日志（~1700 条） 输出：压缩后的关键事件列表（~50-100 条），包括：
- 所有状态变化事件（灯开关、门锁操作、窗户开关等）
- 温度传感器的趋势摘要（而非逐条读数）
- 运动传感器的活动时段摘要
- 所有报警/错误事件
注意：这一步是确定性的规则提取，不用 LLM，避免信息丢失。
Stage 1: Prosecutor（检察官）
立场：假设存在异常，尽力找到支持证据。
System Prompt 核心指令：
你是一位安全检察官。你的职责是从设备日志中找出所有可能的安全异常证据。
你必须假设"存在异常"，然后寻找支持这个假设的证据。
你的工作标准：
- 宁可多报也不能漏报
- 任何偏离正常模式的信号都值得指出
- 你需要构建一个完整的"控诉论证"，包括：
1. 你认为存在什么异常（具体类型）
2. 支持你判断的直接证据（引用具体事件：时间戳+设备+数值）
3. 支持你判断的间接证据（推理链）
4. 你对威胁严重程度的评估
如果你确实找不到任何异常证据，你可以声明"未发现可控诉的异常"，但这应该是你穷尽所有可能性之后的结论。
输出格式：
{
"prosecution_verdict": "anomaly_detected" | "no_case",
"alleged_threat_type": "...",
"direct_evidence": [
{"timestamp": "...", "device": "...", "observation": "...", "significance": "..."}
],
"indirect_evidence": [
{"reasoning": "...", "supporting_events": ["..."]}
],
"severity_assessment": "critical/high/medium/low",
"prosecution_argument": "完整的控诉论证（2-3句话）"
}
Stage 2: Defender（辩护人）
立场：假设一切正常，为每个"异常"找到合理的正常解释。
System Prompt 核心指令：
你是一位安全辩护人。你将看到检察官提出的异常指控和证据。
你的职责是为这些"异常"找到合理的正常解释，证明它们不是真正的安全威胁。
你的工作标准：
- 优先寻找正常解释（日常行为、设备特性、环境因素）
- 指出检察官证据中的逻辑漏洞或过度解读
- 你需要构建一个完整的"辩护论证"，包括：
1. 对检察官每条证据的逐一反驳或替代解释
2. 支持"正常"判断的证据（引用具体事件）
3. 检察官论证中的逻辑弱点
如果检察官的证据确实无法反驳（如设备明确报警 HardwareFaultAlert=True），
你应该承认这一点，而不是强行辩护。
输入：Evidence Extractor 的摘要 + Prosecutor 的完整输出 输出格式：
{
"defense_verdict": "normal_explained" | "partially_explained" | "cannot_refute",
"rebuttals": [
{
"prosecution_claim": "检察官的某条指控",
"defense_explanation": "正常解释",
"supporting_evidence": ["支持正常解释的事件"],
"strength": "strong/moderate/weak"
}
],
"alternative_narrative": "完整的正常解释叙事（2-3句话）",
"concessions": ["承认无法反驳的点（如果有）"]
}
Stage 3: Judge（裁判）
立场：中立，基于双方证据质量做决策。
System Prompt 核心指令：
你是一位中立裁判。你将看到检察官和辩护人的完整论据。
你的职责是比较双方证据的质量和说服力，做出最终判定。
判定规则（非对称举证责任）：
1. 如果检察官提供了"直接设备证据"（报警事件、状态矛盾、操作失败），
且辩护人无法提供合理反驳 → 判定为异常
2. 如果检察官只有"间接推理证据"（行为模式偏离、时间异常），
且辩护人提供了合理的正常解释 → 判定为正常
3. 如果双方证据强度相当 → 判定为异常（安全领域的保守原则：宁可误报不可漏报）
4. 如果检察官声明"no_case" → 判定为正常
5. 如果辩护人声明"cannot_refute" → 判定为异常
注意：你不需要重新分析原始日志。你只需要评估双方已经提交的论据。
输入：Prosecutor 输出 + Defender 输出 输出格式：
{
"final_verdict": {
"is_anomaly": true/false,
"threat_type": "...",
"confidence": "high/medium/low"
},
"reasoning": {
"prosecution_strength": "strong/moderate/weak — 理由",
"defense_strength": "strong/moderate/weak — 理由",
"decisive_factor": "哪条证据/论点决定了最终判定",
"applied_rule": "使用了哪条判定规则（1-5）"
},
"threat_description": "一句话总结",
"recommended_actions": ["..."]
}
4. 关键设计决策
4.1 为什么不是 3 个 agent 投票？
投票（majority vote）的问题：
- 3 个同构 agent 容易产生相同的偏见（都保守或都敏感）
- 投票没有"为什么"——只有结果没有过程
- 无法利用安全领域的非对称性（漏报 > 误报）
对抗辩论的优势：
- 结构性保证了正反两面都被考虑
- Judge 能看到完整的推理过程，不只是结论
- 非对称举证责任天然适配安全场景
4.2 为什么 Defender 看 Prosecutor 的输出？
这不是"信息泄露"，而是有意设计：
- Defender 需要知道 Prosecutor 指控了什么，才能针对性反驳
- 这模拟了真实的法庭辩论——辩护人看到起诉书后才做辩护
- 如果 Defender 不看 Prosecutor 的输出，它只能泛泛地说"一切正常"，无法针对性反驳
4.3 为什么 Judge 不看原始日志？
- 减少 token 消耗（原始日志 ~1700 条事件）
- 避免 Judge 产生自己的偏见
- 强制 Judge 只基于双方提交的证据判断——这保证了可解释性
- 如果 Prosecutor 和 Defender 都漏掉了某个关键证据，那是它们的问题，不是 Judge 的
4.4 Evidence Extractor 为什么不用 LLM？
- 避免在第一步就引入 LLM 的偏见
- 规则提取是确定性的，可复现
- 减少一次 API 调用的成本
- 温度趋势摘要、活动时段统计这些用代码做更准确
4.5 非对称举证责任的具体含义
| 场景 | Prosecutor 证据 | Defender 反驳 | Judge 判定 |
|---|---|---|---|
| 门锁报警 | DoorLockAlarm 事件（直接证据） | "可能是误触" | 异常（直接证据无法用"可能"推翻） |
| 温度微升 | "温度比昨天高了1°C"（间接证据） | "夏季正常日间波动" | 正常（合理解释推翻了弱证据） |
| 凌晨运动 | "3AM 客厅有运动"（中等证据） | "住户可能失眠" | 异常（规则3：证据相当时倾向异常） |
| 无异常 | "no_case" | — | 正常（规则4） |
5. 与 EGPv2 的对比
| 维度 | EGPv2（串行流水线） | ADISR（对抗辩论） |
|---|---|---|
| 架构 | 串行：Triage→Investigator→Supervisor→Verifier | 并行对抗 + 裁判 |
| 决策机制 | 每个角色可否决 → 保守累积 | 对立论证 + 中立裁判 → 结构性平衡 |
| Recall 保障 | 无（任何角色都可能放过） | Prosecutor 的 KPI 就是不漏报 |
| Precision 保障 | 过强（4 层验证） | Defender 的 KPI 就是不误报 |
| API 调用次数 | 4 次（+ 可能的循环） | 3 次（固定） |
| 可解释性 | 中（最终只有一个结论） | 高（正反论据完整保留） |
| 论文新意 | 流水线（常见） | 对抗辩论（有顶会支撑但应用于 IoT 安全是新的） |
6. 预期效果分析
基于现有数据的推理：
- Prosecutor 单独跑 ≈ DeepSeek baseline 的效果（Recall ~90%, FA ~80%）——因为它被要求"找异常"
- Defender 单独跑 ≈ EGPv2 thinking 的效果（Recall ~20%, FA ~3%）——因为它被要求"找正常解释"
- Judge 综合判定 的预期：
- TP 场景：Prosecutor 有强证据，Defender 难以反驳 → 大部分判为异常 → Recall 70-85%
- FP 场景：Prosecutor 有弱证据，Defender 有强反驳 → 大部分判为正常 → FA 15-25%
- 预期 F1 0.70-0.80
7. 实现复杂度
| 组件 | 工作量 | 说明 |
|---|---|---|
| Evidence Extractor | 小 | 规则代码，从现有 event_sequence 提取摘要 |
| Prosecutor prompt | 小 | 一个 system prompt |
| Defender prompt | 小 | 一个 system prompt |
| Judge prompt | 小 | 一个 system prompt + 判定规则 |
| Runner | 中 | 串联 3 次 API 调用 + 解析 |
| Scorer 适配 | 小 | 从 Judge 输出提取 is_anomaly/threat_type |
总工作量比 EGPv2 小（3 个角色 vs 4 个角色，无循环），但效果预期更好。
8. 论文中的呈现方式
方法章节标题建议
"Adversarial Deliberation for IoT Security Reasoning"
或者更学术化：
"Structured Adversarial Reasoning with Asymmetric Burden of Proof"
实验对比矩阵
| Method | Type | Recall | FA% | F1 |
|---|---|---|---|---|
| Baseline (zero-shot) | Single prompt | ~70% | ~58% | 0.58 |
| EDRC | Structured prompt | ~80% | ~64% | 0.63 |
| EGPv2 | Serial pipeline | ~45% | ~26% | 0.51 |
| ADISR (ours) | Adversarial debate | ~80% | ~20% | ~0.75 |
消融实验设计
- Prosecutor only（去掉 Defender 和 Judge）→ 验证 Prosecutor 保 Recall
- Symmetric burden（对称举证）→ 验证非对称规则的必要性
- Judge sees raw log（Judge 看原始日志）→ 验证"只看论据"的设计
- Same prompt for both（同构辩论）→ 验证异构对抗的优势
9. 风险与 Plan B
| 风险 | 概率 | 缓解 |
|---|---|---|
| Prosecutor 太弱（找不到证据） | 低 | 它的 prompt 鼓励"宁可多报"，跟 DeepSeek baseline 类似 |
| Defender 太强（什么都能解释） | 中 | Judge 的非对称规则限制了 Defender 的"解释力" |
| Judge 偏向某一方 | 中 | 消融实验验证；可以试不同模型做 Judge |
| 3 次 API 调用成本高 | 低 | 比 EGPv2 的 4 次还少 |
| F1 没到 0.70 | 中 | 调整非对称规则的阈值；或加入第二轮辩论 |