AI 大模型语义缓存技术分享

1. 背景：大模型在安全检测领域落地的痛点

以 Web 攻击检测（SQL 注入、XSS、命令执行等）为例，将大模型直接用于 WAF 实时检测面临三个核心挑战：

而 WAF 生产环境的性能基线是：

2. 业内端侧应用方案对比

将大模型落地到端侧应用，业界通常有以下几种方案：

3. JXWAF 解决思路：计算左移 + 持续学习，从"解题"到"查答案"

WAF 的性能基线是硬约束：单请求延迟 <5ms、单核 QPS >5000、成本趋近于零。在这三条死限下，任何形式的"大模型实时推理"都是不可能的——模型推理的物理下限与基线之间存在数量级鸿沟，这是硬件物理规律决定的，不是优化能解决的。

量化、蒸馏、剪枝、精确缓存四种主流方案，本质上都在试图**"让现场解题更快"——把 2 小时的考试压缩到 1 小时。但 WAF 的规则是：看到题目的瞬间必须给出答案，不允许有任何思考时间。唯一的办法是提前知道答案**。

核心比喻：别想着考试时解题，考前就把答案抄好。

考前：把所有常见题型拿给老师（大模型），老师告诉你答案，你记在笔记本上
      → 笔记本上记的是："这种题型 → 答案选 A/B/C/D"

考试：看到题目 → 分析它属于笔记本上哪类题型 → 直接抄答案
      → 不推理，不算，只做"分析题型 + 查答案"

遇到新题型 → 先跳过，考后去问老师 → 老师给答案 → 补到笔记本上
      → 知道自己缺哪个题型，就去补哪个

考试比喻揭示了两个核心设计：

• 计算左移——把大模型推理从线上（实时请求）移到线下（考前、考后），线上只做轻量级的向量编码和缓存匹配。这不是"优化推理速度"，而是根本不在线上推理。
• 持续学习——传统模型的检测能力在部署那一刻就冻结了。JXWAF 不同：每处理一条缓存未命中的请求，后台大模型分析后答案自动追加到缓存。系统随流量持续积累，越用越强。

3.1 两个模型，两种职责

实现这两个设计，需要两种角色分工：

本质区别：传统方案训练的那个模型（如蒸馏学生模型）是用来"直接做检测"的——输入一句 Payload，直接输出"攻/正"判断。JXWAF 训练的向量化模型只做"语义编码"——输入一句 Payload，输出一个向量，用来和缓存里的已有向量序列进行匹配，判断它命中哪个已知攻击模式。检测结论仍然来自大模型的分析结果，向量化模型不参与决策。

类比：传统方案是在训练一个"迷你法官"，让他独立判案；JXWAF 是在训练一个"档案管理员"，他只负责告诉你"这个案子跟档案室里已有的某份案卷是一个类型"，至于结论是什么，直接查档案即可。

3.2 整体流程：线上序列匹配 + 后台答案生成

线上实时链路（毫秒级）：
请求 Payload → 向量化模型 → 语义向量序列匹配
                         ↓
                      命中？
                   ↙        ↘
                 YES          NO
                  ↓            ↓
           返回缓存答案      标记"新请求"
                              ↓
后台异步链路（秒级～分钟级）：
新请求队列 → 完整大模型分析 → 多轮验证 → 结果写入向量缓存

关键设计解读：

• 线上只做向量匹配，不做推理。 向量化模型将请求编码为语义向量后，直接与缓存中已有的向量序列匹配。命中则返回大模型已给出的结论，延迟控制在毫秒级。
• 后台异步分析，不阻塞线上链路。 未命中的新请求进入后台队列，由大模型完整分析其攻击意图，经多轮验证确认结论后，将结果写入向量缓存，后续同类请求即可命中。

3.3 与业内方案的对比总结

4. 核心技术实现：多维稀疏注意力机制

4.1 先看一个日常例子：注意力机制为什么能"看懂"意思

在介绍 JXWAF 的多维稀疏注意力机制之前，先简单介绍下注意力机制的实现原理。

假设两句话：

A：明天去杭州旅游，要带伞吗
B：杭州明天天气怎么样，出门要不要带雨伞

这两句话的核心语义都是：明天在杭州是否需要带伞。但字面上差异很大——"旅游"和"出门"不同，"伞"和"雨伞"不同，句式结构也不同（A 直接问，B 先问天气再问是否需要伞）。注意力机制能判断它们说的是同一件事，靠的是以下机制：

1. 关键 token 对齐

自注意力计算每对 token 的关联权重。预训练后的模型会把语义相似的词投影到相近方向，于是出现高权重对齐：

其中 "旅游"和"出门"、"伞"和"雨伞" 字面完全不同，但它们在预训练数据中频繁出现在类似的上下文（与"天气""出行""防雨"共现），模型学到了它们是可互换的。

2. 多层注意力逐步抽象意图

3. 权重分布揭示语义重心

深层注意力会自然聚焦：

• "杭州""明天""伞/雨伞" → 高权重（决策依赖条件）
• "吗""怎么样""要不要" → 低权重（功能词，不影响核心语义）

最终将所有 token 向量聚合为一个句子向量，被多层注意力精炼后只保留了核心语义——"在哪里、明天、要不要带伞"。

这个原理在 WAF 攻击检测中同样适用。以最简单的 SQL 注入为例：

请求 A：id=1' OR '1'='1
请求 B：id=999' OR 'x'='x

两个请求的攻击骨架完全一致——都是 ' OR 'x'='x 结构的永真注入，只是参数值不同（1 变 999，'1' 变 'x'）。

注意力机制在处理时：

• OR、=、' 等攻击关键 token → 高权重（决定是否为注入的核心结构）
• 1、999、'1'、'x' 等参数值 → 低权重（只是攻击骨架里的填充物）

最终聚合出的语义向量只保留"永真注入"这一核心判断，参数值的差异被自然抹平。这与天气例子中"杭州""明天""伞"获得高权重、"吗""怎么样"被压低的逻辑完全相同——注意力机制天然能区分"什么重要、什么是噪音"。

但代价是全量计算——一个 HTTP 请求中，参数值、参数名、URL 路径等大量无关 token 也参与注意力的两两计算，算力严重浪费。

4.2 多维稀疏注意力机制实现机制

JXWAF 的稀疏注意力采用完全不同的策略——先过滤，再计算：

标准大模型注意力：
  Token 序列：[id, =, 999, ', OR, ', 1, ', =, ', 1]
               ↓
  全部两两计算：id↔=, id↔999, id↔', ..., 999↔OR, ...（O(n²)，n=11）
               ↓
  所有 token 都参与注意力计算，再从结果中提取攻击骨架

JXWAF 稀疏注意力：
  Token 序列：[id, =, 999, ', OR, ', 1, ', =, ', 1]
               ↓
  第一步：过滤无关 token（参数值和参数名）→ [', OR, ', =, ']（保留攻击关键字）
               ↓
  第二步：剩余 token 两两计算 → ', OR, ', =, ' 之间做注意力（O(k²)，k=5）

核心差异在于：大模型是先算再理解，JXWAF 是先排除再算。 过滤这一步之所以可行，是因为专家子模型已经从大模型蒸馏出了"哪些 token 与攻击相关"的 token 权重。

4.3 多维稀疏注意力的 token 权重来源：注意力蒸馏

JXWAF 的稀疏注意力并非从零独立训练，而是通过蒸馏已训练完成的大模型注意力模式得来。大模型在海量数据的预训练过程中，已经学会：

• 哪些 token 是 SQL 注入关键字（如 '、OR、UNION SELECT）
• 哪些 token 是攻击无关的参数值（如 999、abc、1）
• 攻击关键 token 之间的逻辑关联（如 ' 与 OR 紧邻构成注入条件，UNION 搭配 SELECT 形成联合查询）

JXWAF 将这些已经沉淀在大模型注意力层中的 token 权重蒸馏出来，定向迁移到 12 个轻量级专家子模型中：

蒸馏过程：

大模型注意力模式（海量安全语料预训练后的结果）
  │
  │  提取两方面的 token 权重：
  │  ① 哪些 token 与攻击相关（需要保留）
  │  ② 哪些 token 是攻击无关的（需要排除）
  │
  ▼
12 个轻量级专家子模型
  ├── SQL 注入专家：知道 ', OR, UNION, SELECT, -- 等需要关注
  │                 知道 999, abc, 1 等参数值需要排除
  ├── XSS 专家：知道 <, >, script, onerror, javascript 等需要关注
  ├── 命令注入专家：...
  └── ...（共 12 个攻击类型专家）

因此 SQL 专家不需要自己从头学习什么是注入关键字——它直接继承了大模型的 token 权重，知道看到一段 HTTP 请求时应该排除哪些 token、保留哪些 token。整个过程是注意力蒸馏，而非重新训练。

4.4 多维稀疏注意力编码流程

前面 4.1 用简单的永真注入展示了注意力如何区分攻击骨架与参数噪音。在实际检测中，一个 HTTP 请求进入 JXWAF 后，会被同时送入 12 个专家子模型并行编码——每个专家用自己的稀疏注意力独立处理该请求，最终产出一个向量序列（Vector Table），再与缓存中的已知攻击向量序列做匹配。

以 SQL 注入请求为例：

输入: GET /search?id=1' UNION SELECT 1,2,database()-- HTTP/1.1


1. Tokenization
   → [GET, /, search, ?, id, =, 1, ', UNION, SELECT, 1, ,, 2, ,, database, (, ), --, HTTP, /, 1.1]
   → 共 20 个 token


2. 12 个专家并行稀疏注意力编码——每个专家独立过滤 + 独立计算注意力
   ┌──────────────────┬────────────────────────────────┬──────────┐
   │ 专家              │ 过滤后保留的 token               │ 向量维度  │
   ├──────────────────┼────────────────────────────────┼──────────┤
   │ SQL 注入专家       │ ', UNION, SELECT, ,,, ,,      │ d        │
   │                   │ database, (, ), --  (9 token)   │          │
   ├──────────────────┼────────────────────────────────┼──────────┤
   │ XSS 专家           │ （无 XSS 相关 token，全部排除）   │ d        │
   ├──────────────────┼────────────────────────────────┼──────────┤
   │ 命令注入专家        │ （无命令注入相关 token，全部排除） │ d        │
   ├──────────────────┼────────────────────────────────┼──────────┤
   │ 路径穿越专家        │ search（路径相关，少量保留）     │ d        │
   ├──────────────────┼────────────────────────────────┼──────────┤
   │ ...（共 12 个）     │ ...                              │ d        │
   └──────────────────┴────────────────────────────────┴──────────┘


3. 生成 12×d 向量序列（Vector Table）
   ┌──────────────────┬─────────────────────────┐
   │ SQL 注入专家向量   │ [0.91, 0.87, ..., 0.05]  │ ← 高信息量向量（攻击骨架被完整编码）
   │ XSS 专家向量       │ [0.01, 0.00, ..., 0.01]  │ ← 近似零向量（无相关 token）
   │ 命令注入专家向量    │ [0.00, 0.01, ..., 0.00]  │ ← 近似零向量
   │ 路径穿越专家向量    │ [0.12, 0.08, ..., 0.02]  │ ← 低信息量向量（仅有微弱关联）
   │ ...              │ ...                       │
   └──────────────────┴─────────────────────────┘


4. 降噪 + 向量序列匹配
   Vector Table 中 12 个专家的向量先做降噪处理：
   → SQL 注入专家向量 [0.91, 0.87, ..., 0.05]  ← 保留（高信息量）
   → XSS 专家向量     [0.01, 0.00, ..., 0.01]  ← 丢弃（近似零向量）
   → 命令注入专家向量  [0.00, 0.01, ..., 0.00]  ← 丢弃
   → 路径穿越专家向量  [0.12, 0.08, ..., 0.02]  ← 丢弃（低于信号阈值）
   → ...

   降噪后得到固定序列：仅 SQL 注入专家向量 [0.91, 0.87, ..., 0.05]

   将精简后的向量序列与缓存中已标注攻击类型的向量序列做匹配
   → 综合判定：SQL 注入

经过稀疏注意力编码后，不同变体的同类攻击——比如 1' UNION SELECT 1,2,database()-- 和 1' UNION SELECT 1,2,'a','c',database()--——都会被 SQL 专家过滤掉参数值和填充列，只保留攻击骨架（UNION SELECT database()），因此两者的语义向量直接匹配。列数不同、填充值不同，但攻击骨架一致。

注意：标准大模型在注意力计算后还要执行推理（生成检测结论），而 JXWAF 向量化模型只做编码、不做推理。两者不是同一维度的对比——JXWAF 的优势不在于"注意力算得更快"，而在于根本不做推理，只产出向量序列用于匹配。

5. 实践效果与数据

5.1 线上性能

测试环境为阿里云 ECS 单节点，机型 ecs.c9i.xlarge（4 核 8G），以下为性能测试数据：

开启 AI防护后，HTTP QPS 仍达 3.1 万、HTTPS QPS 达 2.1 万——以约 30% 的性能损耗换取深度安全检测能力。

折算到单核：HTTP 7,790 QPS、HTTPS 5,336 QPS，均超出第 1 节提出的"单核 >5,000 QPS"生产基线。单节点日均可处理超 15 亿次请求。

对比开启和关闭防护功能，单请求平均延迟增加约 2ms，满足 <5ms 的设计目标。

5.2 业务数据与缓存效果

以某大型互联网公司为例，为应对护网期间的安全需求，WebTDS 接入了 1,500 + 线上域名，并上线了 AI 语义检测策略。系统每日处理总请求量超过 10 亿次，以下为工作日的实际生产数据：

关键解读：

• 99.998% 的命中率意味着每日 12.9 亿请求中，仅有约 2.2 万条无法命中缓存需进入后台大模型分析。这 2.2 万条经后台分析后自动追加到缓存，成为后续同类请求的"标准答案"——系统持续自我进化。
• 以 2.2 万条新增 / 12.9 亿总请求计算，日均缓存增长仅 0.0017%，说明经过前期积累后缓存已趋于饱和，绝大多数攻击变体已被覆盖。

5.3 大模型调用成本

后台大模型调用仅发生在缓存未命中的新请求上。以 DeepSeek-V4-Flash（非思考模式）的 API 定价计算：

关键解读：

• 12.9 亿请求中仅 0.002% 需要调用大模型，日成本仅约 4 元。如果所有请求都直接调用大模型 API，按同等单价计算日成本将超过 25 万元——语义缓存的成本节约达 6 万倍。
• 随着缓存持续积累、命中率进一步提升，日均 API 调用量将无限趋近于零，边际成本持续降低。这与第 1 节提出的"单次检测成本趋近于零"的设计目标完全吻合。

6. 总结

本文针对大模型在 WAF 实时检测场景中面临的高成本、高延迟、幻觉三大痛点，提出了一套完整的解决方案——大模型语义缓存。核心思路并非让大模型"算得更快"，而是将其从线上实时推理链路中彻底移除，转为后台异步的答案提供者，线上仅执行轻量级的向量编码与匹配。

两个核心设计：

• 计算左移：将大模型推理从线上移到线下。线上不做推理，只做向量编码和缓存匹配，延迟控制在 2ms 以内、单核 QPS 超过 5,000，满足 WAF 毫秒级检测的性能基线。
• 持续学习：缓存未命中的请求进入后台队列，由大模型分析后自动追加到缓存。缓存命中率在生产环境中达到 99.998%，系统随流量持续积累、越用越强。

技术实现： 通过注意力蒸馏，从大模型中提取 token 权重并迁移到 12 个专家子模型，构成多维稀疏注意力机制。每个专家只关注自己负责的攻击类型维度的 token，先过滤无关信息再做注意力计算，大幅压缩计算量；12 个专家并行编码产出向量序列，经降噪后与缓存做全局匹配，精度等同于大模型。

生产验证： 在 1,500+ 域名、日均 12.9 亿请求的真实业务场景下，缓存命中率 99.998%，单日大模型 API 成本仅约 4 元——相较于直接调用节省 6 万倍。性能、成本、确定性三项基线指标全部达标。

应用场景扩展：

AI Agent 安全护栏：对 Agent 的 Prompt 指令、系统命令和网络访问请求进行向量编码，与缓存中的已知攻击模式做毫秒级匹配，未命中时交后台大模型分析并持续沉淀，在不阻塞 Agent 响应速度的前提下防止 Prompt 注入、间接指令劫持、恶意命令执行等攻击。

办公网威胁检测：将员工访问内部系统及操作行为进行向量编码，覆盖数据异常访问、权限越权、异常行为序列等场景，与缓存中已知异常模式做毫秒级匹配，未命中时交后台大模型分析并持续补充特征库，实现对钓鱼行为、内鬼窃密等内部威胁的实时检测。

安全领域大模型强化训练数据：缓存未命中的请求经后台大模型分析后，形成“原始 Payload → 分析结论”的高质量标注对，每日自动积累，可反哺大模型 SFT 微调或强化训练，形成“检测 → 积累 → 训练 → 更强检测”的闭环。