autowzry-agent

模型架构重构

日期: 2025-11-22 类型: 架构优化

背景

原有模型设计过于简单，存在以下问题：

单一固定架构，无法适配不同场景
参数分配不合理（头重脚轻）
缺少BatchNorm等训练稳定性措施
降维策略粗暴（全局池化丢失位置信息）
缺少模型设计文档和原理说明

需要重新设计模型架构，参考其他MOBA AI（OpenAI Five、王者绝悟、AlphaStar）的经验。

设计讨论

核心原则确定

参数分配原则：70-80%卷积 + 20-30%全连接
- 卷积层负责特征提取（任务重，需要更多参数）
- 全连接层负责决策映射（任务轻，参数较少）
模块化接口：
- input_channels 由buffer决定（当前3，未来帧叠加会变6/9）
- num_actions 由action_space决定
- 模型接收5个独立参数，不依赖外部配置
三层模式系统：
- mini: 快速测试，资源受限
- full: 推荐使用，平衡性能
- high: 追求极致效果

关键设计决策

1. 卷积层设计

第一层stride=2：快速降维（540×960 → 270×480）
通道数递增：
- mini: 32→64→128
- full: 64→128→256→512→512
- high: 64→128→256→512→1024→1024
添加BatchNorm：提升训练稳定性

2. 降维策略

讨论了三种方案：

方案A：全局池化（无参数，但丢失位置信息）
方案B：大步长卷积（保留位置，但参数多）
方案C（采用）：1×1卷积 + (4,8)适度池化
- 参数仅增加整体模型10%
- 保留32个位置信息（4×8网格）
- 学习通道降维

关键洞察：”参数量要和整体模型对比，不能孤立看”

3. Dueling DQN架构

采用Dueling DQN分离状态价值和动作优势，提升训练稳定性。

实现内容

1. 重写模型文件

文件: core/lightweight_dqn.py

主要变更：

完全重写模型架构
实现三种模式（mini/full/high）
添加以下功能： ```python
- init(input_channels, input_height, input_width, num_actions, mode)
- forward(x) -> q_values
- save(path) # 保存模型和超参数
- get_params_breakdown() # 参数分布统计 ```

架构细节（以full模式为例）：

输入: C×540×960
├─ Conv1: C→64, stride=2, BN, ReLU
├─ Conv2: 64→128, stride=2, BN, ReLU
├─ Conv3: 128→256, stride=2, BN, ReLU
├─ Conv4: 256→512, stride=2, BN, ReLU
├─ Conv5: 512→512, stride=2, BN, ReLU
├─ Reduce: 512→128 (1×1 conv)
├─ Pool: (4,8) AdaptiveAvgPool
├─ Flatten
└─ Dueling Head: 512 hidden → num_actions

2. 更新配置系统

文件: config/config.py, config/agent.config.yaml

新增配置：

model:
  mode: mini  # 'mini'/'full'/'high'

移除配置：

input_channels - 移至buffer模块决定

3. 更新训练器

文件: core/trainer.py

主要变更：

从buffer获取 input_channels
从config获取 model_mode
模型初始化传入5个参数
checkpoint文件名包含模式标签：model_{mode}.pth
单文件覆盖策略（不保存epoch编号）

4. 更新buffer模块

文件: data/training_buffer.py

新增属性：

self.input_channels = 3  # 当前RGB图像，未来帧叠加会更新

5. 创建设计文档

文件: docs/design/MODEL_DESIGN.md

内容：

强化学习模型的特殊性
为什么用CNN而非全连接
模型深度选择（3-6层）
通道数递增原理
降维策略对比
参数分配原则
强化学习特有考虑（时序信息、探索利用、样本效率）
设计流程总结
常见误区
实践建议

配置更新

config/agent.config.yaml

model:
  mode: mini  # 模型规模: mini(快速测试), full(推荐), high(追求极致)

checkpoint:
  resume_model: ./checkpoints/model_mini.pth  # 与mode对应

training:
  use_target_network: true  # 使用目标网络，提升训练稳定性
  target_update_epochs: 5   # 每5个epoch更新目标网络
  samples_per_epoch: null   # 每epoch样本数，null=使用所有buffer数据

文档更新

1. README.md

删除”轻量级模型（88K参数）”
替换为”灵活的模型接口，易于替换和扩展”

2. docs/design/ARCHITECTURE.md

更新模型描述为规定性接口
说明5个输入参数及其来源
添加MODEL_DESIGN.md链接

3. config/agent.config.yaml

补充mode参数注释
补充target network参数注释

参数量对比

模式	卷积层参数	全连接参数	总参数	卷积占比
mini	~1.2M	~0.3M	~1.5M	80%
full	~7M	~2M	~9M	78%
high	~24M	~6M	~30M	80%

测试验证

更新测试配置 scripts/test_pipeline.py：

config_data = {
    'model': {
        'mode': 'mini'  # 测试使用mini模式
    }
}
MODEL_FILE = "test_model_mini.pth"

设计要点总结

为什么这样设计？

为什么用CNN？
- 全连接层参数量爆炸（8亿参数）
- CNN利用空间结构，参数共享
为什么3-6层？
- 太浅：表达能力不足
- 太深：训练困难，数据需求大
- MOBA任务复杂度适合中等深度
为什么通道数递增？
- 空间维度减小，通道数增加补偿信息
- 浅层提取简单特征，深层组合高级特征
为什么1×1卷积+池化？
- 全局池化丢失位置信息
- MOBA需要知道敌人方位
- 参数增加仅10%，性价比高
为什么70%卷积+30%全连接？
- 特征提取是核心任务
- 决策映射相对简单
- 避免头重脚轻导致过拟合

模块化设计

buffer决定输入：input_channels由数据格式决定
action决定输出：num_actions由动作空间决定
config控制规模：mode选择模型复杂度
模型独立接收参数：5个参数，不依赖外部模块

未来改进

下一步：帧叠加

在buffer中实现帧叠加
input_channels: 3 → 6（prev + current）
提供时序信息（运动方向、速度）

可选改进

结构化特征（按需添加，如血量、技能CD）
分层决策（如果发现move和attack冲突）
Attention机制（仅high模式考虑）

经验总结

先讨论再实现：架构设计需要充分讨论各方案优劣
参数量相对比较：不孤立看某个层，要和整体模型对比
模块职责清晰：buffer管输入，action管输出，config管规模
文档与代码同步：重大架构变更需要更新相关文档
保持灵活性：模型是可替换的组件，不是项目亮点