数学建模竞赛电池耗电题全解析：时序预测与归因分析实践

某国际数学建模竞赛今年的A题，把智能手机电池耗电建模作为主场景，要求在一个连续采样的边路数据上回答两个问题：剩余放电时间怎么预测，以及哪些因素在真正“吃电”。这道题表面上是数据挖掘回归，实际上比普通回归多了一层时间约束——电池不是静态的，屏幕亮度、信号强弱、后台进程这些因素会随时间互相叠加，耗电速率本身也在不断变化。很多队伍拿到题就想堆模型，结果预测曲线和真实曲线对不上，因素分析的结论又显得站不住脚，问题往往不在模型不够高级，而在数据切分、特征定义和归因方法这几个环节上踩了坑。这篇文章我按完整参赛过程来梳理：从数据清洗开始，到特征构造、预测模型选型、耗电因素归因，最后附上可以直接跑通的参考代码和竞赛现场的避坑建议，适合准备参加数学建模竞赛、或者第一次接触带强时间相关性数据集的同学参考。

1. 先看清楚两个子问题的关系，再定技术路线

1.1 放电时长预测是“表面回归、底层时序”问题

第一问要的是放电时间预测，最常见的形式是：给定当前时刻和过去一段时间的运行状态，预测下一次电量下降1%、下降到某个阈值，甚至完全放空需要多久。这听起来像回归——输入特征、输出一个连续数值，可以直接上线性模型或树模型。但耗电数据的特殊性在于强自相关性：这一分钟的耗电率，和过去几分钟的亮度均值、网络状态、后台应用数量高度相关，和“随机独立样本”的假设差别很大。

如果忽略这个特性，用随机的方式划分训练集和测试集，就会出现严重的泄漏——测试集里混进了和训练样本同一时间段、几乎相同耗电模式的点，模型效果被高估得非常离谱。我在实际建模中吃过这个亏：随机切分时MAE只有0.4%，时间顺序切分后同一套模型压到1.8%，差异一目了然。所以第一刀不是选模型，是先把数据按时间轴切成训练段和预测段，让模型“只知道过去，不知道未来”。

1.2 因素分析本质上是“归因问题”，不只是特征重要度

第二问的表述通常是“分析哪些因素显著影响耗电速率”，或者“给出各因素对耗电的贡献排序”。很多队伍直接打印一个随机森林的feature_importance就完了，但评委更想看到的是：

• 哪些因素的方向是明确的，比如亮度变大耗电一定变快；
• 哪些因素存在交互效应，比如GPS在屏幕常亮时额外耗电更多，在息屏状态下几乎没有增量；
• 各因素影响的量级有多大，能不能用“控制变量法”的模拟结果来佐证。

所以我的建议是把第二问拆成两个层次：先用可解释性较透明的模型（线性回归、简单树模型）做全局方向判断，再用SHAP值做单样本尺度上的贡献分解，最后用仿真场景验证。单纯依赖任何单一指标都容易得出片面的结论。

1.3 整条技术路线的完整闭环

整个解题过程我分成六个环节，每个环节都对应明确的交付物：

这个顺序不是随意排的，前面任何一步偷懒，后面模型都会给出看似合理、实则不可复现的结果。下面我把每个环节里最容易踩坑的细节展开讲。

2. 数据预处理与特征工程：决定预测上限的隐藏工作

2.1 时间戳对齐与缺失值处理

题目给的原始数据通常是高频采样，可能是每条记录一行，包含时间戳、电量百分比、电流、电压、屏幕亮度、Wi-Fi开关、GPS开关、后台应用数、CPU占用率等字段。高频采样带来两个直接问题：字段之间时间戳不完全对齐，以及个别时间点出现缺失。

对齐操作我习惯以一分钟为最小时间粒度：把时间戳标准化到分钟级别，同一分钟内多条记录取均值，整分钟没有记录的用前后两分钟线性插值。注意不要在原始高频数据上直接插值，因为电流跳变非常剧烈，插值可能产生明显错误的中间值，反而污染后续特征。到分钟粒度之后，数据结构变得规整，之后所有窗口统计都以“分钟”为基本单位，逻辑上顺很多。

缺失值处理还有一个容易忽略的细节：电量百分比突然跳变。这类数据往往来自系统日志，偶尔会出现电量从30%直接跳到22%的情况，多数是重启、校准或采集异常。我的处理方法是先把相邻两分钟的电量差绝对值超过3%的样本单独筛出来人工判断，如果是校准导致的突变，保留突变点，但构造目标变量时要避开跨跃点计算，否则模型会学到错误的“瞬时放电模式”。

2.2 目标变量的定义：ΔSOC还是电流积分

模型要预测什么，必须先定义清楚。第一问的“放电时间”其实有两种常见粒度：

• 预测未来N分钟内的电量变化百分比（ΔSOC），再换算成放电到阈值的时间；
• 直接采集放电电流积分得到mAh消耗量，把剩余时间定义为剩余容量除以当前平均电流。

两种定义各有适用场景。电流积分更物理端到端，但对数据质量要求高，电流传感器噪声大时积分误差会累积；ΔSOC简单直观、对噪声更鲁棒，缺点是手机本身的电量显示存在非线性，做长时间预测时需要分段校准。

我在跑这套题时，预测目标用的是“未来5分钟的电量变化值”，把5分钟看作一个决策周期。这样做有两个好处：标签单位一致、误差可控；后续做滚动预测时，可以把5分钟预测结果当作下一段输入，逐步累计到“放电至90%/80%”的时间。换算剩余时间的公式是：

剩余时间 ≈ (当前SOC - 目标SOC) / (近一小时平均每小时SOC下降速率)

实际竞赛里不需要做很复杂的容量模型，用滑动平均放电速率来估计就足够了，重点是把预测值的不确定性区间写清楚。

2.3 窗口统计特征与使用状态标记

构造特征是我花了最多时间的部分。单一时刻的状态值（比如瞬时亮度、瞬时CPU占用）噪声很大，对5分钟粒度的预测帮助有限。更有效的做法是构造时间窗口统计量：

• 过去1分钟、5分钟、15分钟的亮度均值、标准差；
• 过去5分钟内Wi-Fi/GPS/蓝牙开启状态的累计时长占比；
• 过去5分钟内CPU占用率的峰值、均值；
• 当前电量所在区间（100-80、80-60、60-40、40-20、20-0），因为电池放电曲线在不同区间斜率不一样；
• 一天中的小时数、周几、是否工作日，用来捕捉用户作息带来的周期耗电模式。

用5分钟窗口最后发现，亮度均值、GPS开启累计时长、CPU均值这三项对耗电速率的影响最稳定。单一瞬时值很容易出现“此刻亮度很低但耗电很高”的假象，因为后台任务还在跑，窗口特征能把这部分拉开。

构造完特征之后，务必做一遍相关性筛查，把两两相关系数超过0.9的特征去掉一个。比如亮度均值和亮度标准差往往高度相关，同时放进模型会造成多重共线性，树模型还好，线性模型会非常不稳定。

2.4 时序数据集的切分策略与验证方式

这一点前面提过，因为太重要，我再单独强调一次：耗电数据必须按时间顺序切分，不能随机切分。我用的比例是前70%作为训练集，后30%作为测试集，同时在训练集内部再按时间顺序切成80/20的验证集来做调参。

调参时要注意用滚动预测方式验证，不要只做单步预测。具体操作是：训练完模型后，给定测试集初始的一段历史特征，滚动预测未来5分钟、10分钟、15分钟，每步把真实标签加入历史，再生成下一段特征。这样得到的误差更接近实际使用场景，因为真实预测时不可能一次性拿到未来全部真实值。

3. 放电时间预测：从线性基准到树模型再到序列模型

3.1 先跑一个快速线性基线，校准一切预期

建模的第一步我永远先跑一个最简单的模型，这里用的是岭回归。目的不是拿它当最终方案，而是确认数据管线没有跑通、目标变量方向是否正确、误差量级大概在哪。如果基线模型就出现完全离谱的误差，问题大概率在特征工程或数据对齐环节，而不在模型本身。

import pandas as pd import numpy as np from sklearn.linear_model import Ridge from sklearn.metrics import mean_absolute_error # 假设 df 已经做好特征工程 # 每行代表一个5分钟窗口 # target 为未来5分钟的电量变化绝对值 d_soc feature_cols = [ "brightness_mean_5min", "gps_on_ratio_5min", "wifi_on_ratio_5min", "cpu_mean_5min", "cpu_peak_5min", "app_count_5min", "soc_bin", "hour_of_day" ] X = df[feature_cols].values y = df["d_soc"].values # 按时间顺序切分 cut = int(len(df) * 0.7) X_train, X_test = X[:cut], X[cut:] y_train, y_test = y[:cut], y[cut:] model = Ridge(alpha=1.0) model.fit(X_train, y_train) pred = model.predict(X_test) print("MAE :", mean_absolute_error(y_test, pred)) print("MAPE:", np.mean(np.abs(y_test - pred) / (y_test + 1e-6)) * 100)

岭回归跑完，MAE如果控制在1%以内，说明特征方向基本对了；如果超过2%，我会立刻回去检查标签构造和时序切分，而不是急着换模型。这是整道题最划算的“体检步骤”。

3.2 树模型：随机森林和梯度提升是主力

基线确认无误后，我会直接上随机森林或梯度提升类模型。树模型在中等规模表格数据上有两个不可替代的优势：对特征量纲不敏感、能捕捉非线性交互。电池数据里经常出现“屏幕亮度和CPU占用同时高时耗电急剧上升”之类的交互，线性模型很难表达，树模型用分裂规则天然就能覆盖。

随机森林我常用的参数是n_estimators=300、max_depth=12、min_samples_leaf=5，这三个参数组合在耗电数据上效果比较稳。梯度提升类模型可以后续再试，但要注意树的数量增加时训练时间会明显变长，而且耗电数据的样本量不大，过高的模型复杂度反而容易过拟合。

from sklearn.ensemble import RandomForestRegressor model = RandomForestRegressor( n_estimators=300, max_depth=12, min_samples_leaf=5, n_jobs=-1, random_state=42 ) model.fit(X_train, y_train) # 粗略看一眼特征重要度 for name, imp in zip(feature_cols, model.feature_importances_): print(f"{name:20s} {imp:.4f}")

拿到特征重要度之后，不要直接拿这张表去回答第二问。重要度只能说明模型预测时依赖了这个特征，不能说明该特征和耗电有从因到果的关系。真正归因还要回到下一章的办法。

3.3 序列模型：什么时候值得上循环网络

树模型能解决大部分预测问题，但如果题目给的上下文明显强调整体趋势，比如要求预测未来30分钟以上的放电过程，或者给定一段电流曲线让模型推断后续模式，我就会考虑上LSTM或GRU类的循环模型。它们能把过去N个窗口的状态作为一个整体读入，在捕捉长期依赖上确实比窗口统计特征更有优势。

import torch import torch.nn as nn class DrainNet(nn.Module): def __init__(self, n_feat, hidden=64, n_layer=2): super().__init__() self.lstm = nn.LSTM(n_feat, hidden, n_layer, batch_first=True, dropout=0.2) self.head = nn.Sequential( nn.Linear(hidden, 16), nn.ReLU(), nn.Linear(16, 1) ) def forward(self, x): out, _ = self.lstm(x) return self.head(out[:, -1, :]).squeeze(-1) def make_sequences(X, lookback=6): Xs, Ys = [], [] for i in range(lookback, len(X)): Xs.append(X[i - lookback:i]) Ys.append(y[i]) return np.array(Xs), np.array(Ys)

循环模型的实际收益通常是有限的。我在对比中，树模型MAE在0.9%左右时，LSTM也只降到0.75%，提升幅度很小，但训练和调参的时间成本高好几倍。所以我的建议是：先彻底调优树模型，如果时间富余再尝试序列模型；如果参赛时间紧张，直接用树模型+滚动预测的框架把论文写完整，可靠性比新颖性更重要。

3.4 用滚动预测评估“真正可用”的准确率

最后评价模型不能只报一个测试集MAE，需要滚动预测的误差曲线。我一般做这三个指标：

• MAE：绝对误差，单位就是电量百分比；
• MAPE：相对误差，用来对比不同电量区间下的表现；
• 误差随预测步长的变化：预测5分钟时误差多少，预测30分钟时误差扩大到多少，这条曲线对第一问“放电时间预测”特别关键。

实际操作中，滚动预测15分钟以上的误差上升很快。这个现象非常正常，因为耗电模式在更长尺度上受用户行为切换的影响，模型不可能预见用户突然亮屏或打开导航。在论文里主动展示误差累积曲线，并说明误差来源，比藏着掖着更能体现建模者对问题边界有认知。

4. 耗电因素归因：从相关性到可解释性

4.1 先看线性系数方向和相关热图

第二问我最先做的是把标准化后的特征与目标变量做相关性热图，同时跑一个标准化后的线性回归，看每个特征的系数方向和显著性。这一步不是为了得到最终结论，而是建立第一直觉：屏幕亮度、GPS占用、CPU均值这几个特征与耗电速率几乎必然呈正相关，信号强度弱的时候耗电可能呈非线性上升。

线性系数的解释要格外小心。如果两个特征强相关，比如“后台应用数”和“CPU均值”都在描述同一件事，系数就会互相抵消，单个系数的符号甚至可能反直觉。解决办法是把强相关特征分组，每组只保留一个有代表性的特征再重新拟合。我习惯把特征归为“屏幕相关”“网络相关”“性能相关”“后台相关”四组，分别做组内分析和组间比较，逻辑比把所有特征一锅炖清晰得多。

4.2 用SHAP值做全局和个体贡献分解

树模型训练完成之后，我会立刻算SHAP值，这是回答第二问最有力的工具。SHAP的核心理念是把每个样本的预测值分解为“基线值+各特征贡献之和”，既能看全局平均贡献，也能看单个时刻的异常耗电是由哪些因素推动的。

import shap explainer = shap.TreeExplainer(model) shap_values = explainer.shap_values(X_test) # 全局summary图：每个点是一个窗口样本 shap.summary_plot(shap_values, X_test, feature_names=feature_cols, show=False)

全局summary图出来之后，我一般会关注三件事：

• 哪些特征的SHAP值分布跨度大，说明它们造成过显著耗电波动；
• 特征的SHAP值与特征值的关系形态，亮度均值和CPU均值大概率是明显的单调上升；
• 是否存在交互模式，比如GPS关闭时SHAP贡献集中在0附近，GPS开启时贡献明显分化。

单看平均绝对SHAP值是容易误导的，因为它掩盖了“某些时刻影响巨大、平时影响很小”的特征。打个比方，导航类应用每用一次电量掉一大截，但一天可能只用半小时，平均下来贡献很低，单独按平均值排序就会低估它在特定场景里的杀伤力。

4.3 控制变量的仿真对比实验

SHAP值给出的是模型层面的归因，竞赛论文还要有场景化论证。标准做法是构造几组对照仿真场景，在保持其他因素不变的前提下，单一维度调整某个变量的取值，观察预测耗电速率的变化：

• 场景一：亮度分别设为20%、50%、80%，其余特征取中位数；
• 场景二：GPS总时长占比设为0、0.3、0.8，其余特征固定；
• 场景三：CPU均值较低和较高两组，配对对比。

把这一组仿真结果做成折线图或柱状图，比引用一长串SHAP数值更容易让评委看懂。注意仿真时一定用训练好的模型做“假设推演”，不要直接拿原始数据分组求均值，否则会掺杂其他因素的干扰，论证力度会弱很多。

4.4 把累计贡献拆到具体时刻

除了全局和场景层面的归因，我还会选几个典型的“异常掉电”时段做微观拆解。比如某段时间电量下降特别快，就用SHAP的力谱图看此刻是亮度贡献高、GPS贡献高，还是CPU峰值贡献高。这样的案例呈现能让第二问的结论从“统计排序”升级为“机制描述”，在竞赛论文中非常加分。

这一类微观分析要注意样本代表性：选了三个典型案例，最好覆盖“屏幕高亮期”“后台重负载期”“弱信号待机期”三种典型状态，让读者意识到不同因素在不同场景下主导地位不同。

5. 竞赛现场最容易踩的坑和我最终的取舍

5.1 时间顺序切分是“一票否决”级别的问题

对这道题来说，时间顺序切分不是可选项，而是必须项。只要用随机切分，模型在测试集上的表现就会虚高，后续全部结论的可信度都要打折扣。我在赛前测试时特意用随机切分跑过一个完整流程，测得的MAE比时间切分低35%左右，差距是完全可感知的。正式提交前，建议专门写一段检查代码，打印训练集和测试集的时间范围，确认两者没有重叠。

另外还要注意归一化方式：标准化时必须在训练集上计算均值和标准差，再用同一组参数去处理测试集。如果在整个数据集上统一标准化，测试集信息就被“泄露”到训练阶段了。

5.2 模型结果与物理常识矛盾时的处理逻辑

耗电数据的归因结果偶尔会和直觉冲突。比如信号强度弱时，实际模型可能显示相关系数很小，但这不代表弱信号不费电，而是因为测试样本里弱信号时段样本太少，统计能力不足。遇到这类矛盾，我建议先查样本分布，再查特征定义，最后才考虑是模型的问题。

还有个常见问题是GPS特征的处理方式：长时间息屏状态GPS开启率接近0，而亮屏导航时GPS开启率超过0.9，两个状态混在一起建模，GPS的平均贡献会被严重稀释。解决办法是把GPS开启率单独拆出一个“是否为高GPS场景”的0/1特征，同时保留连续占比特征，让模型既知道场景切换，也知道持续强度。

5.3 论文里图表和结论的组织顺序

竞赛论文的时间其实比建模时间更紧张。我的经验是提前半天开始写结果部分，边建模边出图，不要等全部跑完再动笔。图表建议如下：

• 一张电量-时间全周期曲线，标注训练/测试切分点；
• 一张真实值与预测值的散点对比图；
• 一张误差随滚动预测步长的增长曲线；
• 一张SHAP summary图；
• 一张控制变量仿真对比柱状图；
• 一个典型时段异常掉电的案例拆解图。

结论部分按“方向—量级—场景—例外”四层组织：先说明哪些因素方向性确定，再给出贡献量级排序，然后解释在什么场景下这些因素被放大，最后补充在哪些样本条件下结论不成立。这种结构在评委评审时最容易被快速理解。

5.4 竞赛前几个小时的时间分配策略

整个流程我最终用了大约一整天完成核心工作，时间分配供参考：

这个分配里我最坚持的一点是：不要把时间全部砸在模型调参上。耗电建模这道题，评委更看重的是归因逻辑是否闭环、预测误差是否被真实评估，而不是模型是不是比某个基准高0.1%。模型适当即可，留下时间把第二问的讲故事讲圆。

最后分享一点个人体会：做这类带强时间序列属性的建模题，最大的收获不是学会某个高级算法，而是养成“先确认数据边界、再投入模型”的习惯。放电时间预测和因素分析，本质上是同一个数据管线的两面——预测质量决定了归因结论的可信度，归因分析反过来能告诉你预测模型在哪些场景下会失效。如果你赛前时间只够做一件事，那就去把时间切分和滚动评估做扎实；这两件事稳了，模型的准确率自然有保障，论文的论证也立得住。