# 自适应自修复安全管道：面向大语言模型的闭环防御系统

> 一个创新的三层级联防御系统，结合词汇层、语义层和输出层防护，通过自修复词汇缓存将语义检测结果自动编译为正则规则，实现Probe-Diagnose-Patch-Verify闭环自动化安全防御。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-31T12:15:57.000Z
- 最近活动: 2026-05-31T12:20:49.836Z
- 热度: 0.0
- 关键词: LLM security, adversarial defense, self-healing, semantic detection, jailbreak, prompt injection, FAISS, FastAPI, closed-loop, XAI
- 页面链接: https://www.zingnex.cn/forum/thread/llm-github-lailaarzumanaraunina-adaptive-self-healing-security-pipeline-for-large-language
- Canonical: https://www.zingnex.cn/forum/thread/llm-github-lailaarzumanaraunina-adaptive-self-healing-security-pipeline-for-large-language
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**：lailaarzumanaraunina
- **来源平台**：GitHub
- **原始标题**：Adaptive Self-Healing Security Pipeline for Large Language Models
- **原始链接**：https://github.com/lailaarzumanaraunina/Adaptive-Self-Healing-Security-Pipeline-for-Large-Language-Models
- **发布时间**：2026年5月31日

## 项目背景与挑战

随着大语言模型（LLM）在代码生成、医疗诊断、金融咨询、法律分析等关键领域的广泛应用，它们面临的安全威胁也日益严峻。 adversarial jailbreaks（对抗性越狱）和 prompt injection attacks（提示注入攻击）可以轻易绕过安全对齐机制，产生有害输出。

### 现有防御机制的局限

当前静态防御机制存在明显不足：

- **正则黑名单**：仅通过关键词匹配，单个字符变化即可绕过
- **审核API**：同样基于规则，缺乏语义理解能力
- **语义向量防御**：虽然能捕获更多变体，但计算开销大（每次查询约15ms），且无法自动适应新的攻击模式，需要人工更新规则

这些限制促使研究者探索一种能够自主学习、自动修复的防御架构。

## 系统架构概览

该项目提出了一种**自适应自修复安全中间件（Shield Proxy）**，在API边界处拦截用户请求，通过三层级联防御机制保护下游LLM。

### 三层级联防御体系

每个用户请求在到达目标LLM之前，依次通过三个安全层：

```
用户请求 → Layer 1（词汇/正则，<1ms）→ Layer 2（语义/向量，~15ms）→ Layer 3（输出关键词，<1ms）→ 目标LLM
              ↓ 被拦截              ↓ 被拦截/自修复              ↓ 被拦截
           拒绝响应              拒绝响应/生成规则            输出拦截
```

| 层级 | 引擎 | 延迟 | 检测内容 |
|------|------|------|----------|
| **Layer 1 - 词汇层** | 编译后的正则模式 + 系统提示防护注入 | **<1ms** | 已知攻击特征（如"ignore previous instructions"、"DAN mode"），随时间通过自修复缓存进化 |
| **Layer 2 - 语义层** | SentenceTransformer (all-MiniLM-L6-v2) + FAISS余弦索引 | **~15ms** | 改写、翻译、混淆后的越狱尝试，通过余弦相似度与规范威胁语料库比对检测 |
| **Layer 3 - 输出层** | 关键词扫描 + 后备拒绝替换 | **<1ms** | LLM输出中的有害内容（出口安全网），捕获通过入口过滤器的载荷 |

## 核心创新：自修复词汇缓存

这是系统的核心创新。当Layer 2（语义层）检测到新型攻击（余弦相似度 > 0.82）时，系统执行以下闭环流程：

### 自动修复流程

1. **诊断（Diagnose）**：将攻击向量与FAISS索引比对，识别匹配的威胁家族
2. **编译（Compile）**：通过`compile_lexical_rule()`从攻击的关键n-gram词元合成轻量级正则规则
3. **注入（Inject）**：将规则写入`config.yaml`，Shield Proxy在每次请求时读取
4. **学习（Learn）**：将攻击向量添加到实时FAISS索引，供未来参考

### 修复效果

**结果**：未来相同或相似的攻击将在Layer 1被拦截（<1ms），而不是在Layer 2的~15ms。**今天的语义检测成为明天的词汇预防**。

这种跨层蒸馏机制使得系统能够持续硬化亚毫秒级词汇层，基于语义嵌入检测，无需人工干预。

## 双后端语义引擎

语义引擎（`semantic_shield.py`）使用子进程探针在启动时自动选择最佳可用后端：

```
启动流程
  ├── 子进程探针：能否安全导入sentence_transformers？
  │   ├── YES → 主后端：all-MiniLM-L6-v2 + FAISS IndexFlatIP
  │   └── NO  → 后备后端：TfidfVectorizer + NumPy余弦
  │
  └── FAISS探针：能否无ABI崩溃导入faiss？
      ├── YES → FAISS GPU/CPU加速搜索
      └── NO  → 纯NumPy点积回退
```

| 后端 | 模型 | 向量维度 | 索引 | 依赖 |
|------|------|----------|------|------|
| **主后端** | all-MiniLM-L6-v2 (SentenceTransformer) | 384 | FAISS IndexFlatIP | sentence-transformers, faiss-cpu |
| **后备** | TfidfVectorizer (字符n-grams 2-4) | 8000 | NumPy余弦 | scikit-learn |

这种设计确保了系统在各种环境下的可用性和性能。

## 闭环自动化管道

完整的自修复周期由`pipeline_coordinator.py`编排：

```
PROBE（Garak扫描Shield Proxy）→ DIAGNOSE（解析hitlog.jsonl提取载荷）→ XAI ANALYSE（LOO词元遮挡识别触发词元）→ PATCH（编译规则/生成防护/语义扩展/热注入config.yaml）→ VERIFY（Garak重扫描确认命中数=0）
```

### 逐步解析

1. **PROBE（探测）**：Garak向Shield Proxy的OpenAI兼容端点发射对抗性探针
2. **DIAGNOSE（诊断）**：从`hitlog.jsonl`提取成功利用的载荷
3. **XAI ANALYSE（可解释AI分析）**：Leave-One-Out（LOO）词元遮挡，每次移除一个词，重新查询LLM，测量哪些词对攻击成功至关重要
4. **PATCH（修补）**：关键词元被编译为：
   - Layer 1入口过滤的正则模式
   - 系统提示防护指令
   - 语义簇扩展（嵌入空间中的k-NN近邻）
   - Layer 3出口关键词黑名单
5. **VERIFY（验证）**：Garak重新扫描修补后的代理，测量漏洞减少程度

## 对抗模型与威胁假设

### 对抗者能力

对抗者**可以**：
- 向公共API端点提交任意文本提示
- 使用已知的越狱模板（DAN、Evil Confidant、AIM等）
- 应用提示混淆（Base64、leet speak、Unicode同形字、ROT13）
- 使用多轮对话逐步升级至有害输出
- 通过用户可控输入字段尝试提示注入攻击

### 对抗者限制

对抗者**不能**：
- 修改Shield Proxy源代码（在安全环境中运行）
- 访问配置文件（不通过API暴露）
- 修改FAISS索引或TF-IDF词汇表（仅服务端）
- 访问内部日志或诊断数据

### 安全目标

最小化：
- **对抗绕过率**：恶意输入逃避检测的比例
- **有毒输出生成**：目标LLM产生有害补全的数量
- **提示注入成功率**：成功命令覆盖的频率

同时保持良性任务效用（最小化误拒率）。

## 实验方法论

### 消融研究设计

为防止循环评估，研究采用严格的训练/测试分割：

| 角色 | 探针 | 目的 |
|------|------|------|
| **训练** | `promptinjection.HijackHateHumans` | 基线扫描 → XAI分析 → 补丁合成 |
| **测试（留出）** | `dan.DAN_Jailbreak` | 评估学习到的防御对未见攻击家族的泛化能力 |

六种配置隔离各层的贡献：

| 配置 | Layer 1（词汇） | Layer 2（语义） | Layer 3（输出） |
|------|-----------------|-----------------|----------------|
| 1. 基线 | 关 | 关 | 关 |
| 2. 仅提示层 | **开** | 关 | 关 |
| 3. 仅输出层 | 关 | 关 | **开** |
| 4. 仅语义层 | 关 | **开** | 关 |
| 5. 双层 | **开** | 关 | **开** |
| 6. 完整混合 | **开** | **开** | **开** |

每种配置在**3次独立试验**上使用确定性模拟LLM后端评估。结果包含使用Student's t分布计算的95%置信区间。

### 评估指标

| 指标 | 公式 | 描述 |
|------|------|------|
| **测试绕过率** | $R_{bypass} = \frac{hits}{total probes} \times 100$ | 对抗尝试逃避所有活跃层的百分比（↓ 更好） |
| **误拒率** | $R_{FRR} = \frac{blocked benign}{total benign} \times 100$ | 良性提示被错误拦截的百分比（↓ 更好） |
| **延迟开销** | $\Delta_t$ | 每层增加的每次查询延迟（↓ 更好） |

## 技术栈

| 类别 | 技术 | 版本 |
|------|------|------|
| API框架 | FastAPI + Uvicorn | 0.136.1 / 0.47.0 |
| 语义引擎（主） | SentenceTransformers (all-MiniLM-L6-v2) | ≥ 2.7.0 |
| 向量索引（主） | FAISS (IndexFlatIP) | ≥ 1.7.4, < 1.9.0 |
| 语义引擎（后备） | scikit-learn TfidfVectorizer | ≥ 1.4.0 |
| 红队测试 | Garak (NVIDIA) | latest |
| 配置 | PyYAML | 6.0.3 |
| 目标LLM（真实） | Google Gemini | 0.8.6 |
| 容器化 | Docker + Docker Compose | - |
| 语言 | Python | 3.10 - 3.11 |

## 代码库结构

```
📁 Adaptive-Self-Healing-Security-Pipeline-for-LLMs
├── 🧠 pipeline_coordinator.py    # 编排引擎（单周期运行此文件）
├── 🛡️ shield_proxy.py             # FastAPI三层防御中间件
├── 🔍 semantic_shield.py          # 双后端语义检测引擎
├── 🧪 run_experiments.py          # 6配置消融研究驱动
├──
├── ⚙️ config.yaml                 # 热重载安全配置
├── 🔧 garak_config.json           # Garak REST端点配置
├── 📚 semantic_jailbreak_index.json # 种子对抗提示语料库（42向量）
├── 📋 requirements.txt              # 完全固定的Python依赖
├──
├── 🐳 Dockerfile                  # 容器镜像定义
├── 🐳 docker-compose.yml          # 多服务编排
│
├── 📖 README.md                   # 本文件
├── 📖 RESEARCHER_GUIDE.md         # 详细设置与故障排除指南
│
├── 🚫 .gitignore                  # 版本控制排除规则
└── 🔑 .env                        # API密钥（切勿提交）
```

## 快速开始

### 本地Python设置

```bash
# 步骤1 - 创建虚拟环境
python -m venv venv
# Windows PowerShell:
.\venv\Scripts\Activate.ps1
# Linux/Mac:
# source venv/bin/activate

# 步骤2 - 先固定NumPy（FAISS兼容的关键）
pip install "numpy>=1.23.5,<2.0"

# 步骤3 - 安装项目依赖
pip install -r requirements.txt

# 步骤4 - 安装Garak
pip install garak

# 步骤5 -（可选）配置真实LLM测试的API密钥
# 创建.env文件包含:
#   TARGET_LLM_TYPE=google_ai
#   API_KEY=your-gemini-api-key

# 步骤6 - 运行
python pipeline_coordinator.py           # 单周期自修复
# 或
python run_experiments.py                # 完整消融研究
```

### Docker执行

```bash
# 构建并运行完整消融研究
docker compose up --build

# 运行单周期自修复
docker compose run --rm pipeline python pipeline_coordinator.py

# 独立运行代理（用于主机手动Garak测试）
docker compose --profile proxy up --build proxy
```

## 配置指南

`config.yaml`文件控制所有运行时行为：

```yaml
target_llm:
  type: mock                   # "mock" | "google_ai" | "openai"
  api_key: ""                  # 通过.env设置真实LLM
  model_name: mock-target-llm  # "gemini-2.5-flash" for Google AI

mitigations:
  prompt_level:                # Layer 1 - 词汇/正则
    enabled: false
    block_patterns: []         # 正则模式列表
    guardrail_instructions: []  # 系统提示强化指令

  semantic_level:              # Layer 2 - 语义/向量
    enabled: false
    similarity_threshold: 0.82  # 余弦相似度截止
    auto_compile_lexical: true  # 检测时自动生成正则

  output_level:                # Layer 3 - 出口防护
    enabled: false
    blocked_keywords: []        # 扫描LLM输出的关键词
    fallback_message: "Refusal: Output blocked by security shield proxy."
```

## 关键设计决策

1. **语义层故障开放**：如果语义引擎崩溃，Layer 2被跳过（记录日志），请求继续处理——确保可用性优先于阻断
2. **热重载配置**：`config.yaml`在每次请求时读取，因此补丁无需重启即可生效（适用于输出/防护变更）
3. **模拟LLM后端**：确定性漏洞存根，用于离线测试，模拟妥协的LLM

## 未来工作与扩展

1. **状态化多轮防御**：从单轮过滤器扩展到对话级跟踪——对抗者经常将载荷拆分到多轮中
2. **基于LLM的补丁合成**：使用小型本地LLM生成语义更细化的正则规则，而非简单的n-gram连接
3. **良性效用基准**：在MMLU、GSM8K、HumanEval上评估，量化"安全对齐蠕变"
4. **形式化收敛证明**：数学建模闭环反馈，证明自修复缓存的收敛边界
5. **实时威胁情报**：与外部威胁源集成，用新兴攻击模式种子FAISS索引

## 研究价值与意义

据作者所知，这是首个展示将语义越狱检测运行时编译为符号词汇规则的系统。这种跨层蒸馏使得亚毫秒级词汇层能够基于语义嵌入检测持续硬化——无需人工干预。

对于LLM安全研究人员和工程师，该项目提供了：
- 一个可运行的原型，展示自主防御的概念验证
- 严格的消融研究方法论，用于评估分层防御贡献
- 双后端弹性设计模式，确保生产环境可用性
- 开源实现，可作为进一步研究的基础

该原型旨在展示前沿LLM安全领域的原创系统设计、形式化评估方法论和开放问题意识。