一、背景：为什么传统规则体系开始失效
在企业数据中心出口、防火墙、API 网关与 AI 数据安全场景中，越来越多的数据以结构化或半结构化形式流动。
典型载体包括：
JSON
XML
Form 表单
Query 参数
Header
Cookie
gRPC / Protobuf 解码结果
数据库字段映射结果
与传统自然语言文本不同，这类流量中的敏感数据往往不是完整句子，而是：
字段名（field key）
字段路径（path）
短字段值（short value）
业务编号（business id）
缩写字段（abbreviation）
多字段关联关系（multi-field relation）
例如：
recvNm
custNm
patDiag
addrDtl
invoiceAmt
txnSeq
user_id
receiverName
对于手机号、身份证号、邮箱、IP、MAC、银行卡号等强规则数据类型，可以通过：
正则表达式
校验位
字典
固定格式规则
实现高效、稳定的识别。
但对于以下弱规则数据类型：
姓名
住址
工作单位
病历描述
教育经历
联系人
轨迹信息
住宿记录
仅依赖规则会出现大量误报和漏报。
典型问题包括：
字段命名高度不规范；
字段值过短，缺乏上下文；
中文短词歧义严重；
缩写、拼音、驼峰、下划线混杂；
同一字段在不同接口语义不同；
同一字段值在不同场景敏感性不同；
在线链路要求高吞吐、低时延与可降级能力。
传统 NLP 模型通常依赖：
分词 → 词向量 → CNN/RNN → 分类
但 API 字段并不是自然语言文本。
它们更像“结构化符号”。
因此，传统词向量方案在接口字段场景下会遇到：
OOV（未登录词）严重
分词不稳定
缩写无法泛化
拼音混杂难处理
字段过短缺乏上下文
这也是本文引入字符级 CNN（CharCNN）的核心原因。
二、核心思想：用字符级 CNN 做字段语义泛化
本文方案并不是“用 AI 替代规则”。
相反，它的核心思想是：
用轻量 CharCNN 增强现有规则体系，而不是推翻规则体系。
整个系统仍然以：
正则
字典
校验器
场景库
图谱
组合规则
冲突消除
作为主识别链路。
字符级 CNN 的职责只有两个：
字段语义泛化（Field-CharCNN）
候选置信度校准（Candidate-CharCNN）
也就是说：
规则负责召回；
场景负责增强；
图谱负责关联；
CharCNN 负责灰区校准。
它不是主识别器，而是增强器。
整体识别链路如下：
P0 value 值强规则识别
P1 key 字段名规则识别
P2 value + key 弱规则候选生成
P2.5 Field-CharCNN 字段语义泛化
P3 local_scene 局部场景增强
P4 global_scene 全局场景增强
P5 graph 图谱关系增强
P5.5 Candidate-CharCNN 候选置信度校准
P6 combination 组合规则增强
P7 suppression 误报抑制
P8 conflict_resolution 冲突消除
三、为什么是字符级 CNN，而不是词向量 CNN
传统词向量 CNN：
句子 → 分词 → 词向量 → CNN → 分类
这种方式适合自然语言。
但接口字段不是自然语言。
例如：
recvNm
custNm
addrDtl
patDiag
txnSeq
这些字段：
不是标准词；
大量缩写；
中英文混杂；
拼音混杂；
驼峰命名；
下划线命名；
存在业务简称。
词向量方案会面临：
OOV 问题
分词不稳定
缩写无法理解
拼音无法泛化
而字符级 CNN 直接处理原始字符：
r e c v N m
p a t D i a g
模型可以学习局部字符模式：
nm / name
addr / address
pat / patient
diag / diagnosis
txn / transaction
amt / amount
recv / receiver
cust / customer
因此，CharCNN 天然适合：
API 字段
缩写字段
拼音字段
中文字段
中英文混合字段
短字段
这是它相比词向量方案最大的优势。
四、整体架构设计
整个方案包含两个核心子模块：
1. Field-CharCNN
用于：
字段语义泛化
解决：
字段别名字典覆盖不足
新字段冷启动
缩写字段识别
拼音字段泛化
例如：
recvNm
rcvNm
custNm
patNm
xingming
lxr
shr
虽然这些字段未命中字典，但模型仍可泛化到“姓名”。
2. Candidate-CharCNN
用于：
候选置信度校准
解决：
弱规则误报
多类型冲突
场景歧义
灰区候选稳定性
例如：
{
"productName": "苹果"
}
规则可能误判为姓名。
但在商品场景下，应被抑制。
相反：
{
"receiverName": "张三",
"receiverPhone": "13800138000",
"receiverAddress": "北京市朝阳区测试路1号"
}
在收件人场景中，“张三”则应被增强为姓名。
五、Field-CharCNN：字段语义泛化模型
5.1 设计目标
Field-CharCNN 的目标不是直接输出敏感数据。
而是：
给字段提供“语义先验概率”。
例如：
{
"raw_key": "recvNm",
"path": "body.order.receiver.recvNm"
}
模型输出：
{
"姓名": 0.87,
"住址": 0.05,
"账号": 0.03
}
随后系统会把该结果转化为：
key_score += field_prior * weight
因此：
它不直接决定最终结果；
只是增强规则候选。
5.2 输入设计
Field-CharCNN 输入不仅是字段名。
而是字段上下文拼接后的字符序列。
包括：
raw_key
norm_key
path
parent_path
url_pattern
source
例如：
{
"raw_key": "recvNm",
"norm_key": "recvnm",
"path": "body.order.receiver.recvNm",
"url_pattern": "/api/order/detail",
"source": "body"
}
拼接后：
KEY=recvNm PATH=body.order.receiver.recvNm URL=/api/order/detail
5.3 模型结构
Field-CharCNN 采用轻量化一维卷积结构：
字符序列
↓
字符 ID 编码
↓
Char Embedding
↓
Conv1D(k=2,3,4,5)
↓
Global Max Pooling
↓
FC
↓
Sigmoid
推荐参数：
| 参数 | 建议值 |
|---|---|
| 输入长度 | 128~192 |
| embedding 维度 | 8~32 |
| 卷积核 | 2/3/4/5 |
| filters | 8~32 |
| 输出 | 多标签 Sigmoid |
采用多标签输出的原因是：
patientContactName
可能同时具备：
患者语义
联系人姓名语义
六、Candidate-CharCNN：候选置信度校准模型
6.1 为什么需要第二层模型
很多弱规则场景仅靠规则分数并不稳定。
例如：
{
"productName": "苹果"
}
可能同时命中：
姓名
品牌
商品
再例如：
{
"id": "202405110001"
}
它可能是：
订单号
Trace ID
Session ID
请求流水号
因此，仅靠规则分数很难稳定判断。
Candidate-CharCNN 的目标是：
对可信候选加分；
对疑似误报降权；
对冲突候选辅助判断；
对灰区结果做稳定校准。
6.2 输入设计
Candidate-CharCNN 输入的是“候选对象”。
包括：
candidate_type
value
raw_key
path
url_pattern
value_score
key_score
scene_score
graph_score
conflict_count
anchor_types
negative_hints
例如：
{
"candidate_type": "姓名",
"value": "苹果",
"raw_key": "productName",
"path": "body.goods.productName",
"negative_hints": ["product_field"]
}
模型输出：
{
"valid_prob": 0.08,
"adjustment": -20,
"suppress_prob": 0.91
}
最终：
final_score = raw_score + adjustment - suppression
6.3 双分支结构
Candidate-CharCNN 采用：
文本特征 + 数值特征 融合结构
字符特征
↓
CharCNN
↓
文本向量
\
concat → FC → valid_prob
/
数值特征
↓
MLP
其中：
CharCNN 分支
学习：
字段名
路径
候选类型
字符模式
MLP 分支
学习：
规则分
场景分
图谱分
冲突数量
强锚点数量
最终实现：
规则证据 + 语义模式 联合校准
七、性能控制：为什么它适合在线链路
很多人一看到“模型”就会担心：
在线防火墙能跑得动吗？
这是整个方案设计时最核心的问题之一。
答案是：
关键不在模型本身，而在触发策略。
本方案从设计上就不是“全量 AI 推理”。
而是：
规则主链路 + 灰区按需触发
核心原则：
强规则不跑模型；
高置信候选不跑模型；
低置信候选直接丢弃；
只有灰区候选进入 CharCNN。
建议策略：
raw_score >= 90 → 直接通过
raw_score <= 40 → 直接丢弃
40 < raw_score < 90 → 触发 Candidate-CharCNN
同时配合：
字段缓存
批量推理
Tiny 模型
INT8 量化
ONNX Runtime
OpenVINO / TensorRT
最终可以把模型触发比例控制在：
≤ 5%
这也是它能够适配在线防火墙链路的重要原因。
八、为什么它比“大模型”更适合这个场景
很多人会问：
为什么不用 LLM？
原因很简单。
接口字段识别的核心问题不是“理解长文本”。
而是：
短字段
缩写字段
高吞吐
低时延
强可控
强解释性
在线实时推理
例如：
recvNm
custNm
patDiag
txnSeq
这类输入本身极短。
使用大模型：
成本高；
延迟高；
不稳定；
不易灰区控制；
难以做强规则融合。
而字符级 CNN：
轻量；
可量化；
易缓存；
易批量推理；
可解释；
更适合结构化字段。
因此，在在线 API 数据识别场景下：
CharCNN 更像是“工程最优解”，而不是“模型能力最强解”。
九、证据链：为什么它具备可解释性
很多 AI 识别系统的问题在于：
给出结果，但无法解释为什么。
而安全产品必须可审计。
因此，本文方案要求：
所有 CharCNN 输出必须进入证据链。
例如：
{
"path": "body.order.receiver.recvNm",
"value": "张三",
"type": "姓名",
"final_score": 91,
"evidence": {
"field_charcnn_prior": {
"prob": 0.88,
"score_added": 17
},
"local_scene": [
"receiverPhone",
"receiverAddress"
],
"candidate_charcnn": {
"valid_prob": 0.94,
"adjustment": 12
}
}
}
这样做有几个重要意义：
便于安全审计；
便于策略解释；
便于误报分析；
便于模型调优；
便于规则回放。
十、工程边界：模型不能推翻规则
这是整个方案最关键的一条原则。
CharCNN 只是增强器。
不是最终裁决器。
因此必须遵守：
强规则校验通过不可被模型推翻；
弱规则不得仅凭模型直接输出；
模型结果不能单独进入阻断链路；
模型必须与规则共同形成证据链；
模型只增强已有候选，不凭空创造高风险标签。
这本质上是：
AI 辅助规则，而不是 AI 替代规则。
十一、实验评估建议
建议采用消融实验验证模型价值。
实验组：
| 组别 | 能力 |
|---|---|
| A | 纯规则 |
| B | 规则 + 字段归一化 |
| C | 规则 + 场景增强 |
| D | 规则 + 图谱增强 |
| E | + Field-CharCNN |
| F | + Candidate-CharCNN |
核心指标：
弱规则召回率
弱规则准确率
弱规则误报率
灰区命中率
模型触发比例
字段缓存命中率
P95 / P99 延迟
吞吐量
证据链完整率
重点关注：
未知字段召回是否提升；
误报是否下降；
灰区稳定性是否增强；
延迟是否满足在线链路要求。
十二、总结
字符级 CNN 并不是一个“替代规则”的 AI 方案。
它本质上是：
面向 API 结构化字段识别场景的一种轻量语义增强器。
相比传统词向量方案，它具有：
不依赖分词
更适合短字段
更适合缩写字段
更适合拼音字段
更适合中英文混合字段
更适合在线灰区校准
相比大模型方案，它具有：
更低延迟
更低成本
更强可控性
更强可解释性
更适合高吞吐在线链路
在整体架构中：
Field-CharCNN 负责字段语义泛化；
Candidate-CharCNN 负责候选置信度校准；
规则负责主召回；
场景与图谱负责上下文增强；
冲突消除负责最终稳定输出。
最终形成：
规则高效召回
+
CharCNN 泛化与校准
+
场景与图谱增强
+
证据链可解释输出
的一套在线弱规则数据识别体系。
这类架构的价值并不只是“提高识别率”。
更重要的是：
它在保证在线链路性能与稳定性的前提下，让规则体系获得了有限但极其关键的语义泛化能力。