# 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](https://proceedings.mlr.press/v235/du24e.html) | ICML 2024 | 证明多 agent 辩论提升事实准确性 | 他们是同构辩论（同一 prompt），我们是**异构对抗**（对立 prompt） |
| [Better LLM Reasoning via Dual-Play](https://arxiv.org/abs/2511.11881) | arXiv 2025 | 双角色对抗提升推理 | 他们做数学推理，我们做**安全推理** |
| [Adaptive Coopetition](https://openreview.net/forum?id=NwtIch8isF) | NeurIPS 2025 | 竞争+合作的多 agent 推理 | 他们用 verifier signal，我们用**对抗辩论** |
| [Adversarial Yet Cooperative](http://arxiv.org/abs/2601.04651v2) | arXiv 2025 | 对抗性多视角推理 | 他们做 RAG，我们做 **IoT 安全推理** |
| [Audit-LLM](https://arxiv.org/abs/2408.08902) | arXiv 2024 | 多 agent 协作做日志威胁检测 | 他们是协作式，我们是**对抗式**；他们做 insider threat，我们做 **IoT 物理安全** |

### 2.2 我们的创新点（与上述工作的差异化）

1. **异构对抗 vs 同构辩论**：ICML 2024 的 Multiagent Debate 让多个相同的 agent 辩论，我们让**立场预设对立**的 agent 辩论——Prosecutor 被明确要求"找异常"，Defender 被明确要求"找正常解释"。这不是随机分歧，而是**结构性对抗**。

2. **Evidence-Grounded Debate**：不是让两个 agent 空谈，而是要求每个论点必须**引用具体的设备事件（时间戳+设备ID+数值）**作为证据。Judge 的判定基于证据质量而非修辞质量。

3. **Domain-Specific（IoT 安全）**：现有辩论框架都是通用的（数学、事实核查、RAG），我们是首个将对抗辩论应用于 **IoT 设备日志安全推理**的工作。

4. **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. 你对威胁严重程度的评估

如果你确实找不到任何异常证据，你可以声明"未发现可控诉的异常"，但这应该是你穷尽所有可能性之后的结论。
```

**输出格式**：
```json
{
  "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 的完整输出
**输出格式**：
```json
{
  "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 输出
**输出格式**：
```json
{
  "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** |

### 消融实验设计

1. Prosecutor only（去掉 Defender 和 Judge）→ 验证 Prosecutor 保 Recall
2. Symmetric burden（对称举证）→ 验证非对称规则的必要性
3. Judge sees raw log（Judge 看原始日志）→ 验证"只看论据"的设计
4. Same prompt for both（同构辩论）→ 验证异构对抗的优势

---

## 9. 风险与 Plan B

| 风险 | 概率 | 缓解 |
|------|------|------|
| Prosecutor 太弱（找不到证据） | 低 | 它的 prompt 鼓励"宁可多报"，跟 DeepSeek baseline 类似 |
| Defender 太强（什么都能解释） | 中 | Judge 的非对称规则限制了 Defender 的"解释力" |
| Judge 偏向某一方 | 中 | 消融实验验证；可以试不同模型做 Judge |
| 3 次 API 调用成本高 | 低 | 比 EGPv2 的 4 次还少 |
| F1 没到 0.70 | 中 | 调整非对称规则的阈值；或加入第二轮辩论 |