347 lines
16 KiB
Markdown
347 lines
16 KiB
Markdown
# 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 | 中 | 调整非对称规则的阈值；或加入第二轮辩论 |
|