第九章 · 配置与参数系统：从前端表单到攻击执行器

前面几章我们已经搭好了「攻击执行器（Attack Runner）」和「多任务评测体系」。
本章要解决一个更加工程化、但非常关键的问题：

前端点点点选出来的一堆配置，
如何安全、可控地转换成 Attack Runner 所需要的 参数字典？

这正是配置与参数系统的职责——包括：

扁平化表单模型（Pydantic Schema）
参数分组与缓存（CacheGroup1~5）
ID → 真实枚举值的映射（data_map）
参数合并与默认值填充（merge_params / bb_merge_params）
鲁棒性评级配置与校验（A~E 等级区间）

本章围绕你给出的 schemas.py 代码，系统梳理这一层的设计思路。

1. 设计目标：配置层要解决什么问题？

从前端视角出发，用户会做这些事情：

在下拉框中选择：
- 模型：ResNet50 / FasterRCNN / DeepLabV3 / CRNN / ArcFace
- 数据集：CIFAR10 / COCO / PASCAL / IIIT5K / LFW
- 任务类型：分类 / 检测 / 分割 / OCR / 人脸识别
- 攻击类型：FGSM / PGD / C&W / HSJ / ZOO / Square / FR Attack 等
- 攻击平台：PyTorch / Paddle / MindSpore / TensorFlow / Caffe
在表单中填：
- 攻击参数：eps / steps / alpha / max_queries / norm…
- batch 配置：batch_size / data_load_processes / timeout…
- 输出指标：top1 / mAP / mIoU / CER / EER…
- 鲁棒性评级区间：A/B/C/D/E 五档评分

这些输入有几个特点：

高度扁平（前端字段很多，但都在同一层）
存在多个逻辑分组（模型与数据集、batch 管理、攻击器、输出指标、评分）
可能缺失（用户不一定填完所有字段）
前端使用的是“ID/枚举值”，后端需要真实字符串或结构

因此，配置层需要完成三件事：

使用 Pydantic 模型描述「每一组配置」；
提供安全的「合并函数」，把缓存中的扁平字段合并成 Attack Runner 的 config dict；
对敏感配置做校验，尤其是鲁棒性评级区间的连续性。

2. 参数分组：CacheGroup1 ~ CacheGroup5

你在代码中把配置拆成了 5 个 CacheGroup，这是一个非常合理的分层。

2.1 CacheGroup1：模型与数据集基本信息

class CacheGroup1Request(BaseModel):
    model_name: Optional[str] = None
    dataset_name: Optional[str] = None
    task: Optional[int] = None
    dataset_subset_size: Optional[int] = None
    wb_task_plateform: Optional[int] = None

这一组包含：

模型名（字符串）：例如 "Cifar10_ResNet50.pth"，后面会 split(".")[0]
数据集名
任务类型（用 int 表示，后面通过 box_type_map 映射）
子集大小（dataset_subset_size）
任务平台 ID（后面通过 task_plateform_map 映射为 "Pytorch" 等）

设计点：

task 和 wb_task_plateform 用数字 ID（方便前端和 DB 存储），最终通过 data_map 转为字符串；
dataset_subset_size 给了一个入口，可以控制评测样本数，不影响前端展示。

2.2 CacheGroup2：batch 管理器配置

class CacheGroup2Request(BaseModel):
    batch_size: Optional[int] = None
    data_load_processes: Optional[int] = None
    random_load: Optional[bool] = None
    timeout_limit: Optional[int] = None

对应 Attack Runner 的 batch_manager_config：

batch_size：控制每个 batch 的样本数；
data_load_processes：DataLoader worker 个数；
random_load：是否随机抽样；
timeout_limit：每个 batch 的最大处理时间（毫秒）。

这组配置在 merge_params 中被打包成：

"batch_manager_config": {
    "batch_size": ...,
    "data_load_processes": ...,
    "random_load": ...,
    "timeout_limit": ...
}

保证 Runner 拿到的是一个封装良好的字典。

2.3 CacheGroup3 / CacheGroup32：攻击器配置（白盒 / 黑盒）

你将攻击器配置拆成了两个类：

class CacheGroup3Request(BaseModel):
    device: Optional[str] = None
    attacker_id: Optional[int] = None
    attack_eps: Optional[float] = None
    attack_clamp: Optional[Tuple[float, float]] = None
    attack_steps: Optional[int] = None
    attack_alpha: Optional[float] = None
    attack_norm: Optional[str] = None

class CacheGroup32Request(BaseModel):
    device: Optional[str] = None
    attacker_id: Optional[int] = None
    attack_eps: Optional[float] = None
    attack_clamp: Optional[Tuple[float, float]] = None
    attack_steps: Optional[int] = None
    attack_max_queries: Optional[int] = None
    attack_norm: Optional[str] = None

CacheGroup3Request 更适合白盒攻击（PGD / C&W / FGSM 等）：
- 重点是 eps / steps / alpha / norm…
CacheGroup32Request 更适合黑盒攻击（ZOO / HSJ / Square 等）：
- 增加了 attack_max_queries

在 merge_params / bb_merge_params 中，会将这些字段转为 Attack Runner 需要的：

attacker_name：通过 wbattack_method_map / bbattack_method_map 把 attacker_id 映射成具体攻击名称；

attack_parameters：统一打包成：

{
    "eps": attack_eps / 255,
    "clamp": attack_clamp,
    "steps": attack_steps,
    "alpha": attack_alpha / 255,
    "max_queries": attack_max_queries,
    "norm": attack_norm
}

注意点：

把 eps / alpha 从「像素标度」转为「[0,1] 标度」是非常漂亮的一步；
attack_norm 保持字符串形式，例如 “Linf” / “L2”，在 Attack Runner 中已经做了大小写规范化处理。

2.4 CacheGroup4：输出指标配置

这一组字段极其扁平，但围绕「各任务输出指标开关」：

class CacheGroup4Request(BaseModel):
    img_cls_top1: Optional[bool] = None
    img_cls_top5: Optional[bool] = None
    obj_det_mAP50: Optional[bool] = None
    obj_det_mAP75: Optional[bool] = None
    obj_track_mota: Optional[bool] = None
    obj_track_idf1: Optional[bool] = None
    img_semseg_miou: Optional[bool] = None
    img_semseg_pixacc: Optional[bool] = None
    ocr_acc: Optional[bool] = None
    ocr_cer: Optional[bool] = None
    ocr_wer: Optional[bool] = None
    face_rec_accuracy: Optional[bool] = None
    face_rec_roc_auc: Optional[bool] = None
    face_rec_eer: Optional[bool] = None
    wb_perclass_matching_on: Optional[bool] = None
    wb_output_confidence: Optional[bool] = None

在合并函数中被组装成：

"wb_output_metrics": {
    "img_cls":  {"top1": ..., "top5": ...},
    "obj_det":  {"mAP50": ..., "mAP75": ...},
    "obj_track": {"mota": ..., "idf1": ...},
    "img_semseg": {"miou": ..., "pixacc": ...},
    "ocr": {"Acc": ..., "CER": ..., "WER": ...},
    "face_rec": {"Accuracy": ..., "ROC_AUC": ..., "EER": ...}
},
"wb_perclass_matching_on": ...,
"wb_output_confidence": ...

这层配置为评测引擎提供「细粒度开关」：

可以只计算 Top-1，不算 Top-5；
可以只关注 mAP75；
可以只开启 CER，而关闭 WER；
可以开启/关闭「逐类别匹配」与「置信度输出」。

2.5 CacheGroup5：鲁棒性评级配置（评分区间 + 校验）

这一组是整个配置系统里 最有「业务含义」 的部分：

class CacheGroup5Request(BaseModel):
    success_rate: Optional[bool] = None
    accuracy_degree: Optional[bool] = None
    confidence_degree: Optional[bool] = None
    key_defect: Optional[bool] = None

    rating_A: Optional[Tuple[int, int]] = None
    rating_B: Optional[Tuple[int, int]] = None
    rating_C: Optional[Tuple[int, int]] = None
    rating_D: Optional[Tuple[int, int]] = None
    rating_E: Optional[Tuple[int, int]] = None
    
    wb_output_key_defect: Optional[bool] = None

这里有两个层面：

指标开关：
- 是否参与鲁棒性评分（成功率 / 准确度 / 置信度 / 关键缺陷）；
等级区间：
- A / B / C / D / E 五档评分区间，例如：
  - A: [90, 100]
  - B: [75, 90]
  - C: [60, 75]
  - D: [30, 60]
  - E: [0, 30]

2.5.1 每个区间内部的合法性校验

@validator('rating_A', 'rating_B', 'rating_C', 'rating_D', 'rating_E')
def check_rating_order(cls, rating_tuple):
    if rating_tuple and rating_tuple[0] > rating_tuple[1]:
        raise ValueError(...)
    return rating_tuple

含义：

如果用户把 A 设置成 (95, 90)，则立即抛出错误；
保证「区间下限 ≤ 上限」。

2.5.2 区间之间的连续性校验

@model_validator(mode='after')
def check_rating_continuity(self) -> 'CacheGroup5Request':
    rating_order = ['rating_E', 'rating_D', 'rating_C', 'rating_B', 'rating_A']
    
    for i in range(len(rating_order) - 1):
        lower_tier_name = rating_order[i]
        higher_tier_name = rating_order[i+1]
        
        lower_tier_value = getattr(self, lower_tier_name)
        higher_tier_value = getattr(self, higher_tier_name)
        
        if lower_tier_value and higher_tier_value:
            if lower_tier_value[1] != higher_tier_value[0]:
                raise ValueError(...)
    return self

逻辑含义：

要求区间连续，例如：
- E: [0, 30]
- D: [30, 60]
- C: [60, 75]
- B: [75, 90]
- A: [90, 100]
如果用户设置：
- E: [0, 25]
- D: [30, 60] 则会被拒绝（25 != 30）。

这是一个非常具有产品属性的设计：

平台可以允许企业根据自己标准自定义「A~E 等级」的区间，
但不允许出现「区间重叠」或「区间断档」。

3. 全局配置：WbConfig / BbConfig

除了上述 CacheGroup（用于「缓存临时参数」），你还设计了两个「持久化配置」模型：

WbConfig / WbConfigUpdate（白盒攻击全局配置）
BbConfig / BbConfigUpdate（黑盒攻击全局配置）

它们包含：

data_storage_path：结果存储路径
指标开关（attack_success_rate / prediction_accuracy / prediction_confidence）
典型样本数量：typical_attack_sample_count
一组默认的 rating_A ~ rating_E，以及 success_rate 等开关

可以理解为：

WbConfig / BbConfig 是「全局默认模板」，
CacheGroupX 是「本次任务的用户覆盖配置」，
merge 之后传给 Attack Runner 的是「合并后的有效配置」。

4. 参数合并：`merge_params` 与 `bb_merge_params`

最关键的 glue 层逻辑就是这两个函数，它们把所有扁平字段拼成 Attack Runner 需要的结构。

4.1 白盒：`merge_params`

核心步骤：

处理模型与任务：

param_dict["model_name"] = param_cache["model_name"].split(".")[0]
param_dict["dataset_name"] = param_cache["dataset_name"].split(".")[0]
param_dict["task"] = box_type_map[str(param_cache["task"])]
param_dict["wb_task_plateform"] = task_plateform_map[str(param_cache["wb_task_plateform"])]
param_dict["dataset_subset_size"] = param_cache.get("dataset_subset_size", 100)

注入 batch 管理配置：

param_dict["batch_manager_config"] = {
    "batch_size": param_cache["batch_size"],
    "data_load_processes": param_cache["data_load_processes"],
    "random_load": param_cache["random_load"],
    "timeout_limit": param_cache["timeout_limit"],
}

攻击器配置与参数：

param_dict["device"] = param_cache["device"]
param_dict["attacker_name"] = wbattack_method_map[str(param_cache["attacker_id"])]
param_dict["attack_parameters"] = {}

if "attack_eps" in param_cache:
    param_dict["attack_parameters"]["eps"] = param_cache["attack_eps"] / 255
...

输出指标开关：

param_dict["wb_output_metrics"] = {...}
param_dict["wb_perclass_matching_on"] = param_cache["wb_perclass_matching_on"]
param_dict["wb_output_confidence"] = param_cache["wb_output_confidence"]

鲁棒性评分配置：

param_dict["wb_rating_method"] = {...}
param_dict["wb_robustness_rating"] = {...}
param_dict["wb_output_key_defect"] = param_cache["wb_output_key_defect"]

异常兜底（默认配置）：

如果合并过程中发生异常（例如缓存缺字段），则回退到一份「内置默认参数」：
- 使用 CIFAR10 + ResNet50 + FGSM
- 一套标准 metrics 与评分区间
- 这是保证系统「不会因为参数不完整而完全崩溃」的安全网。

4.2 黑盒：`bb_merge_params`

与白盒版本整体相同，只是：

使用 bbattack_method_map 映射攻击器；
黑盒默认攻击器为 "ZOO"；
攻击参数中使用了 attack_max_queries。

5. 与 Attack Runner 的衔接关系

经过 merge_params / bb_merge_params 之后，Attack Runner 拿到的是一个结构齐全的 dict：

model_name / dataset_name / task / wb_task_plateform
batch_manager_config
device
attacker_name
attack_parameters
wb_output_metrics
wb_perclass_matching_on
wb_output_confidence
wb_rating_method
wb_robustness_rating
wb_output_key_defect

这与我们在第七、八章中设计的 Attack Runner 和多任务评测体系是完全契合的：

Runner 可以直接用 model_name / dataset_name 来加载预置模型与数据集；
可以直接把 attack_parameters 传给 Attack Adapter（例如 PGD / C&W / ZOO）；
可以把 wb_output_metrics / wb_rating_method / wb_robustness_rating 交给评测与报告模块。

换句话说：

配置层是「前端表单 & 数据库」与「攻击执行器 & 报告系统」之间的粘合层（glue layer），
决定了整个系统的「可配置性」与「可运营性」。

6. 这一层设计带来的产品能力

回到产品视角，这套配置系统带来了几个具体能力：

用户可配攻击策略
- 可以针对不同任务选择不同攻击器与参数；
- 可以对黑盒场景设置 max_queries 上限。
用户可配评测关注点
- 某些用户只在意 Top1，另一些用户在意 CER / EER；
- 可通过配置层精细控制。
用户可配鲁棒性评级体系
- A~E 等级区间可自定义；
- 带有严格的连续性和合法性校验。
前端体验友好，后端结构稳定
- 前端用 ID / 选项；
- 后端统一映射为字符串和嵌套 dict，避免逻辑散乱。
支持多平台与多任务扩展
- 只要在 data_map 中加入新的平台/任务/攻击器映射；
- 或在 CacheGroup 中扩展少量字段；
- 就可以支持新类型的评测需求。

7. 小结

本章重点梳理了「配置与参数系统」的设计思路，它是连接：

前端表单 & 参数缓存
攻击执行器（WhiteBoxRunner / BlackBoxRunner）
多任务评测体系与报告系统

之间的关键一层。

通过：

Pydantic + 分组 Schema（CacheGroup1~5）
枚举映射（box_type_map / task_plateform_map / wbattack_method_map / bbattack_method_map）
严格的区间校验与默认值兜底
参数合并函数（merge_params / bb_merge_params）

此时已经拥有一个 可配置、可运营、可扩展 的参数体系，为整个平台的「产品化」与「工程化」奠定了基础。