电池寿命预测：从科学问题到软件交付的全链路案例
案例定位：本文是 Software Factory "一题一软件"方法论的完整演示——用 BatteryLife-AI 对应的 Case-003：电池寿命与热管理 走通一条可复制的全链路。读完它，你应该能把"一个科学问题"翻译成"一套可交付的 AI+HPC 软件"。
1. 科学问题定义（第一步：把问题说清楚）
电池寿命预测看似明确，实际一拆就散。先定义清楚四个要素：
| 要素 | 定义 | 工程含义 |
|---|---|---|
| 预测目标 | SOH（健康度）/ RUL（剩余寿命） | 回归任务 vs 分类任务 |
| 输入 | 充放电循环的电压/电流/温度曲线 | 时间序列，长度可变 |
| 预测时点 | 离线诊断 vs 在线滚动预测 | 决定特征窗口与推理频率 |
| 评估指标 | RMSE / 提前预警命中率 | 业务语言对齐 |
关键决策：第一阶段做"离线诊断"（给定历史数据判断健康状态），第二阶段做"在线预警"（实时监控提前 N 个循环预警）——两个问题复杂度不同，拆开交付。
2. 数据：公开数据集 + HPC 并行仿真
2.1 数据来源设计
单一数据集往往不够（样本少、工况单一），按"公开 + 自造"组合：
| 来源 | 内容 | 用途 |
|---|---|---|
| 公开数据集（如 NASA PCoE、Oxford、CALCE） | 不同温度/倍率下的老化循环 | 训练主模型 |
| HPC 并行仿真数据 | 参数化电化学模型批量生成"虚拟工况" | 补充长尾工况、验证泛化 |
| 实验室实测（如有） | 目标工况小样本 | 最终校准 |
2.2 HPC 侧：批量仿真管道
电化学模型（如等效电路/准二维 P2D）单次仿真分钟~小时级，上千工况必须走 Slurm 批处理：
# 参数空间采样 → 批量提交仿真
# 每个作业：跑一组工况参数，输出容量衰减曲线
for i in $(seq 1 1000); do
sbatch --array=$i simulate_one.sh # Slurm 作业数组
done要点：作业数组天然适配参数扫描（调度参考 07 章 · Slurm 异构调度）；仿真结果与参数元数据一起版本化，为训练和复现兜底。
3. AI 模型：从曲线到寿命预测
3.1 特征与模型选型
| 方案 | 输入 | 模型 | 优点 | 代价 |
|---|---|---|---|---|
| 基础版 | 手工特征（容量衰减率、内阻增长率） | XGBoost / 随机森林 | 可解释、训练快 | 特征工程依赖经验 |
| 进阶版 | 原始充放电曲线 | LSTM/GRU | 自动提特征 | 数据量要求高 |
| 生产版 | 曲线 + 工况元数据 | 时序模型 + 特征融合 | 泛化最好 | 工程复杂度最高 |
3.2 训练决策
- 窗口化：用固定长度循环窗口做滚动预测（如最近 50 个循环 → 未来 SOH）；
- 归一化：不同电池容量绝对值差异大，按初始容量归一，否则模型只会学到"大电池=大容量"；
- 早停与验证：按"电池 ID"划分训练/验证（严禁按循环随机切分——同一电池的相邻循环高度相关，随机切分会严重高估效果）。
4. HPC 验证：不只是"跑个测试"
验证环节承接智算与超算两侧：
- 交叉验证：训练好的模型在 HPC 生成的"虚拟工况"集上跑预测，验证长尾泛化；
- 参数搜索：模型超参（窗口长度、隐藏层、学习率）用并行搜索（Grid/Random/贝叶斯）在集群上批量跑——一次提交几十组训练作业；
- 可解释性抽查：对预测误差最大的样本做归因（哪个工况、哪段曲线），反哺数据补采。
这里有个容易被忽视的点：AI 模型的验证本身也是 HPC 工作负载——超参搜索和批量推理同样吃 GPU。全链路意味着"数据生成用 HPC，模型验证也用 HPC"，集群规划要一并考虑。
5. 软件交付：两阶段落地
v0 · 离线诊断
- 输入：历史充放电数据文件；
- 输出：SOH 估计、RUL 分布、健康度报告；
- 形态：命令行工具 + 报告生成，跑在数据侧即可。
v1 · 在线预警
- 输入：实时监控数据流；
- 输出：提前 N 循环的退化预警 + 风险等级；
- 形态：轻量推理服务（模型封装 API），定时/事件触发；
- 要点：预警阈值由业务定（宁可假报警不可漏报的场合适配高召回），推理服务化参考 12 章 · 推理引擎。
6. 踩坑与调优（实战经验）
"循环数"不等于"时间"：日历老化（存放衰减）和循环老化机理不同，只按循环建模会在低利用率场景严重高估寿命。生产上至少加"时间"特征维度。
电池个体差异 > 工况差异：同型号不同电芯离散性很大，纯数据驱动容易把"个体噪声"学成"规律"。对策：按电池 ID 分组验证 + 提供置信区间而非点估计。
离线准 ≠ 在线准：离线用的历史数据在在线场景是逐步到达的——特征分布会漂移。上线初期要做预测误差滚动监控，误差超阈值触发重训练或规则兜底。
别让"演示精度"绑架交付：论文级 RMSE 好看，但业务要的是"提前多少循环预警、命中率多少"。一开始就把指标翻译成业务语言，避免模型调优方向跑偏。
7. 全链路复盘
| 阶段 | 关键产物 | 验收标准 |
|---|---|---|
| 问题定义 | 四要素表 | 业务方与工程师口径一致 |
| 数据 | 公开数据 + HPC 仿真数据（版本化） | 覆盖目标工况长尾 |
| 模型 | 离线诊断模型 | 按电池 ID 验证的 RMSE 达标 |
| 验证 | 虚拟工况泛化报告 + 超参搜索结果 | 长尾工况误差可控 |
| 交付 | v0 工具 + v1 预警服务 | 业务指标（预警命中率）达标 |
工程启示：
- 这条链路（问题→数据→模型→验证→交付）对任何"AI for Science"题目都成立——换科学问题，只换 2.1 的数据来源和 3.1 的模型，骨架不变；
- "一题一软件"不是一次性的：每个环节都设计了迭代钩子（补采样、重训练、阈值调优），让软件随数据增长持续进化；
- 数据生成（HPC）、模型训练（智算）、验证推理（双栈）三者资源需求不同——这正是 AI-HPC 智算超算平台 统一调度的价值所在。