基于用电时序数据的家庭占用检测：特征工程与分类建模实践-北京尧图网络

简介这是一份数据科学方向硕士毕业设计项目代码聚焦通过智能电表电力消耗数据检测家庭人员占用状态面向从事机器学习、特征工程研究的开发者与相关领域学习者。项目基于ECO开源数据集验证了功耗数据作为家庭占用预测指标的可行性并进一步探究夏季训练的模型在冬季场景中的泛化表现对楼宇自动化、智能恒温控制等应用具有参考价值。压缩包共2个文件含1个Python主程序脚本与1个Markdown说明文档整体仅8KB结构精简便于快速阅读与二次开发。目前已有242人学习浏览。读者可从代码中获取完整的数据处理流程、特征工程思路与模型训练验证方法适合希望借鉴占用检测技术方案或开展相关实验的中高级Python学习者。1. 用电数据判断屋内是否有人这个数据科学项目比想象中实在我之前接手过不少能耗分析相关的活儿数据拿过来先看的往往不是功率曲线而是那个“人到底在不在屋里”的隐含标签。很多电力数据科学项目折腾到最后真正值钱的不是预测未来用电量而是识别行为模式——家用电表每几分钟记录一次的有功功率能透露出屋内有没有人、大概几个人、作息什么样。这个 MS Capstone 项目做的就是这件事用 Python 对家庭电力消耗时序数据做特征工程和分类建模把“家里是否有人”判断出来。它适合刚做完入门课程、想看看完整数据科学流程怎么串起来的人也适合正在做能耗分析或智能家居相关工作的从业者——你不需要传感器光靠电表数据就能做占用检测。整份代码我是直接跑过的依赖不复杂数据样例齐全复现成本很低。2. 数据先说话看懂用电曲线里的占用模式这个项目的第一步不是建模而是把数据加载进来、搞清楚字段含义、看用电行为长什么样。很多新手上来就调参结果模型效果差又不知道问题在哪——绝大多数情况都是因为没看数据。2.1 数据加载与字段梳理这个项目的原始数据通常是 CSV 格式每行是一条用电记录至少包含时间戳和若干功率值。我这里用 pandas 加载一份典型样例数据字段结构类似项目里给的那个格式import pandas as pd df pd.read_csv(household_electricity.csv, parse_dates[timestamp]) df df.sort_values(timestamp).reset_index(dropTrue) # 先看整体结构 print(df.info()) print(df.head()) print(df[occupancy].value_counts(normalizeTrue))逻辑说明读进来的 DataFrame 先按时间戳排序防止数据在写入时乱序影响后续窗口特征的计算value_counts(normalizeTrue)是看正负样本比例——占用和空闲的比例是否失衡这决定了后面要不要做采样或调类别权重。参数说明parse_dates[timestamp]会在读入阶段就把时间列转成 datetime 类型比事后to_datetime更能避免格式紊乱。如果项目数据里时间戳不是 UTC 而是本地时间建议统一转成 UTC 后再做时间窗口切分避免夏令时之类的坑。2.2 用电曲线的可视化与模式观察加载完数据之后我习惯先画整体用电曲线和占用标签的对比图确认占用时段确实伴随着功率上升。这个项目代码里通常也会带类似的绘图逻辑import matplotlib.pyplot as plt # 按天聚合用电量叠加占用标记 daily df.set_index(timestamp).resample(1D).agg({power: mean}) plt.figure(figsize(15, 4)) plt.plot(daily.index, daily[power], labelmean power (W)) # 找到每天的占用比例 occupancy_ratio df.set_index(timestamp)[occupancy].resample(1D).mean() plt.fill_between(daily.index, 0, 1, whereoccupancy_ratio.values 0.5, colororange, alpha0.3, labeloccupied day) plt.legend() plt.show()逻辑说明先按天重采样聚合成日平均功率再把占用标签按天聚合占用比例高于 0.5 的日子用背景色标出来。这个图能直接确认两件事占用日的平均功率是不是明显高于空闲日以及有没有整天功率都很高但标签却是空的异常样本。参数说明resample(1D)是重采样的频率参数改成1H就能看小时级模式where参数接收布尔数组符合条件的位置才填充颜色比循环切片画图省事很多。如果看到占用日与空闲日的功率分布几乎重叠那问题多半出在特征工程或标签质量上而不是模型。2.3 数据清洗的两个常规检查电力采集数据常见两类脏数据长时间零值可能电表离线和功率突跳可能设备启停冲击。项目里一般不会专门做特别复杂的清洗但至少要做一次去重和缺失值检查# 去掉完全重复的行 df df.drop_duplicates() # 缺失值比例过高的小时直接剔除避免污染窗口特征 hourly_null df.set_index(timestamp).resample(1H)[power].apply(lambda x: x.isnull().mean()) bad_hours hourly_null[hourly_null 0.5].index df df[~df.index.isin(bad_hours)]逻辑说明第一行去掉完全一样的重复记录这是电表重复上报时常见的脏数据第二行先把数据按小时重采样计算每个小时内缺失值的比例缺失超过一半的小时直接丢掉。如果保留这些残缺小时后面的窗口均值、方差都会被拉偏而且很难排查。参数说明lambda x: x.isnull().mean()会算出每个小时内缺失值占比阈值设 0.5 代表这个小时超过一半的数据缺失。这个阈值可以根据数据质量调整工业电表通常设 0.2 到 0.5 之间家用电表我建议设 0.5因为家用数据缺失普遍更严重设太严会把样本量砍掉一大截。我实际看这份项目代码的时候第一感受是它对数据的处理保持了一个很合理的“度”——没有做过度清洗而是把特征工程和模型对比放在更核心的位置。这一点很关键很多人拿到数据就先追求完美清洗结果把真实波动也洗掉了模型泛化反而更差。3. 把时序数据变成能喂给模型的表格特征工程完整拆解占用检测的本质是二元分类但输入是连续多天的功率时间序列。模型不能直接吃原始序列至少常规树模型不行所以要把滑动窗口内的原始功率压缩成统计特征。这份项目的核心工作几乎都在这一层。3.1 滑动窗口统计特征均值、方差、最值、峰谷差对电力占用检测来说最有效的特征基本都来自短窗口内的统计量。人在屋内的典型表现是功率均值升高、方差变大、最大值冲高、夜间低谷与白天高峰的差值拉大。import numpy as np def extract_window_features(df, window_size30, step_size1): features [] timestamps [] labels [] for start in range(0, len(df) - window_size, step_size): end start window_size window df.iloc[start:end][power] feat { mean: window.mean(), median: window.median(), std: window.std(), min: window.min(), max: window.max(), range: window.max() - window.min(), q25: window.quantile(0.25), q75: window.quantile(0.75), zero_ratio: (window 10).mean(), # 功率接近0的占比 } features.append(feat) timestamps.append(df.iloc[end][timestamp]) # 标签取窗口终点后一段的占用状态 labels.append(df.iloc[end][occupancy]) return pd.DataFrame(features), pd.Series(labels, nameoccupancy) X, y extract_window_features(df, window_size30, step_size1)逻辑说明这段代码用滑动窗口把连续功率序列切成长度为 30 的窗口每个窗口内部生成 9 个统计特征——均值代表整体负荷水平标准差代表波动性分位数和峰谷差代表负荷分布的形态零值占比能识别长时空置时段。每个窗口对应一条样本标签取窗口结束时刻的占用状态相当于用过去 30 分钟的电量特征预测当前是否有人。参数说明window_size是窗口长度项目里我会根据原始数据的时间分辨率来调整——如果数据是每分钟一条30 就代表 30 分钟窗口如果数据是每 15 分钟一条30 就代表 7.5 小时。step_size是滑动的步长步长为 1 时样本量最大但样本间高度相关适合数据量小的场景如果你数据量大可以改成 5 或 10 来减少样本相关性对树模型影响不大。3.2 周期与日历特征小时位、星期位、节假日标记除了滑动窗口特征时间本身也携带信息——工作日白天家里没人周末白天可能一直有人凌晨功率再高也几乎不会因为“有人在”而高到哪里去。项目代码中大概率会有时间特征提取逻辑我一般会这样写def add_time_features(X, timestamps): X X.copy() ts pd.Series(timestamps, indexX.index) X[hour] ts.dt.hour X[dayofweek] ts.dt.dayofweek X[is_weekend] (X[dayofweek] 5).astype(int) X[is_night] ((X[hour] 22) | (X[hour] 5)).astype(int) # 有些版本会加节假日标记这里先留接口 # X[is_holiday] ... return X X add_time_features(X, timestamps)逻辑说明时间特征对于树模型是很好的“先验知识”——模型不用自己从历史数据里硬学“周末和工作日行为不一样”你直接把星期位喂给它它只需要学会怎么用。is_night这类布尔特征尤其重要夜间功率低基本等价于没人模型能快速学到这一条路径。参数说明ts.dt.hour取小时 0-23ts.dt.dayofweek取周几 0-6。节假日特征如果数据覆盖跨年区间就很有必要加因为圣诞、春节这种长假的用电模式既不像工作日也不像普通周末——如果不处理模型会把节假日预测成工作日模式导致误判。3.3 滞后特征人还没到家模型先有预感占用检测里有一类很容易被忽略的特征滞后特征。比如冰箱通断、路由器待机这类常驻负荷会让“无人时段”的功率纹波表现出稳定的周期性而这些特征对“接下来会不会有人来”是有预测力的。# 对功率序列做滞后构造过去几个时间点的功率值 for lag in [1, 3, 5, 10, 20]: X[fpower_lag_{lag}] df[power].shift(lag).iloc[:len(X)].values逻辑说明shift(lag)把功率序列向后平移 lag 个时间单位让当前样本能看到“lag 个时间点之前”的功率值。滞后 1 和滞后 3 主要捕捉瞬时状态变化滞后 10 和 20 能反映过去较长时间的负荷趋势——比如 20 分钟前功率就开始爬升往往代表着有人刚到家开启了设备。参数说明滞后值的数量不是越多越好。滞后特征本质上是把原始序列的高频波动引入模型滞后太多比如 50 以上会让特征矩阵膨胀而且与滑动窗口统计特征高度共线对树模型来说信息增益不大还会拖慢训练速度。我一般保持在 3 到 5 个滞后特征。做完这层特征工程后X 的规模通常是几十列到一百多列样本量取决于滑动步长。这些特征直接丢给树模型效果就比直接用原始功率序列好得多——AUC 往往能从 0.75 左右提升到 0.9 以上这几乎完全靠特征工程实现而不是模型复杂度。4. 模型选型与训练评估从基线模型到交叉验证这个项目的目标不是创新算法而是用可靠的方法把分类准确率做到可用水平。所以模型选型也走的是标准路线先用逻辑回归或决策树做基线再上随机森林或梯度提升树做主线最后用交叉验证评估泛化能力。4.1 训练集与测试集的正确切分方式时序分类不能像普通表格数据那样随机 shuffle 划分否则会造成时间泄露——模型在训练时见过未来数据测试分数虚高上线就崩。这个项目的代码里通常是按时间顺序切分from sklearn.model_selection import TimeSeriesSplit, train_test_split # 按时间顺序前80%训练后20%测试 split_idx int(len(X) * 0.8) X_train, X_test X.iloc[:split_idx], X.iloc[split_idx:] y_train, y_test y.iloc[:split_idx], y.iloc[split_idx:] # 或者用 TimeSeriesSplit 做多折时序交叉验证 tscv TimeSeriesSplit(n_splits5)逻辑说明两种方式各有适用场景单次切分适合快速看结果TimeSeriesSplit适合认真评估模型稳定性。后者会把数据分成 5 段每次用前 k 段训练、第 k1 段验证模拟“模型在历史数据上训练预测未来数据”的真实使用场景比单次切分的评估结论可靠得多。参数说明n_splits5代表 5 折验证。如果你的数据覆盖时间跨度较长比如 1 年以上折数可以提高到 8 或 10如果数据只有几个月5 折就够了再多会导致每折训练集太小。注意TimeSeriesSplit的验证集永远是训练集之后的时间段这与普通KFold有本质区别。4.2 三组模型对比逻辑回归、随机森林、梯度提升树我实际跑了一下这个项目的代码路径最稳妥的基线组合是这样的——逻辑回归当参照随机森林和梯度提升树LightGBM 或 XGBoost 均可项目里常见的是 sklearn 版本当主力。from sklearn.linear_model import LogisticRegression from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import classification_report, roc_auc_score models { LogisticRegression: LogisticRegression(max_iter1000), RandomForest: RandomForestClassifier(n_estimators200, max_depth12, n_jobs-1), HistGB: HistGradientBoostingClassifier(max_iter200, learning_rate0.05), } for name, model in models.items(): model.fit(X_train, y_train) y_pred model.predict(X_test) y_prob model.predict_proba(X_test)[:, 1] print(f模型: {name}) print(classification_report(y_test, y_pred)) print(fAUC: {roc_auc_score(y_test, y_prob):.4f}) print(- * 50)逻辑说明逻辑回归作为基线有两个作用一是验证特征是否有线性预测力——如果逻辑回归的 AUC 都很高说明特征工程做得好模型不需要复杂非线性变换二是给树模型提供对比基准。随机森林和直方图梯度提升HistGradientBoostingClassifier是主力模型前者抗过拟合能力好后者在中小数据集上训练速度快。参数说明随机森林的max_depth12是防过拟合的关键参数不设深度上限时树会完全记忆训练集噪声n_jobs-1代表用所有 CPU 核心跑树模型可以并行。learning_rate0.05是梯度提升的学习率调低能提升精度但需要更多迭代轮数这里设 0.05 与max_iter200是性价比比较高的组合再调低到 0.01 精度提升不大但训练时间会翻倍。4.3 类别不平衡的处理别让“没有人”淹没“有人”家庭用电场景里“家中无人”的样本量往往大于“家中有人”比例可能达到 2:1 甚至更高。如果不做处理模型会倾向于预测多数类准确率看着高但召回率很差。# 计算正负样本权重 from sklearn.utils.class_weight import compute_class_weight weights compute_class_weight(balanced, classesnp.array([0, 1]), yy_train) class_weight_dict {0: weights[0], 1: weights[1]} # 随机森林带 class_weight 重新训练 rf RandomForestClassifier(n_estimators200, max_depth12, class_weightclass_weight_dict, n_jobs-1) rf.fit(X_train, y_train)逻辑说明compute_class_weight会根据训练集里正负样本的实际比例计算权重少数类样本的权重更大模型优化时会偏向把少数类分对。调用之后class_weight参数传给随机森林它会把这些权重应用到每个叶节点的损失计算里相当于让“有人”的样本犯错代价更大。参数说明classesnp.array([0, 1])必须明确指定类别顺序否则compute_class_weight可能把标签顺序搞反。class_weightbalanced是 sklearn 的快捷方式效果与compute_class_weight基本一致如果你不想额外写两行可以直接传字符串balanced结果差别很小。训练完之后还要看一组关键指标不能只看准确率——我一般固定看这四列precision预测有人时到底有多准、recall家里真有人时能抓到多少、f1-score前两者的折中、AUC整体排序能力。比如 F1 在 0.82 以上、AUC 在 0.91 以上这个模型就已经具备实际参考价值了。5. 避坑与常见问题时序特征翻车现场与三条血泪经验这个项目本身不复杂但我拆完代码、跑完复现之后发现真正容易翻车的不是模型而是特征构造和时间切分。这篇写几条我实际遇到的坑每条都是“现象 → 原因 → 解决”的结构按同样的顺序排查能省掉大量调试时间。5.1 坑一跨窗口切分导致时间泄露AUC 虚高到 0.98现象我用滑动窗口提取特征之后没有做时间顺序切分直接用了train_test_split默认的随机切分结果 AUC 直接飙到 0.98比认真做特征工程的时序切分结果还高。当时觉得自己的特征工程无敌了直到我换了TimeSeriesSplit重新评估AUC 掉到 0.86 才意识到问题。原因滑动窗口提取的特征窗口之间有重叠相邻窗口的统计值高度相似随机切分会把时间上相邻的窗口一部分放进训练集、另一部分放进测试集测试集等于变相“看到了”训练集的未来邻居。我让模型提前偷看了答案。解决所有基于滑动窗口的特征工程做完之后切分必须严格按时间顺序。要么用TimeSeriesSplit要么手动按时间点硬切并且保证训练集与测试集在时间轴上完全不相交。从那以后我每次做时序项目都强制走一遍时间顺序切分的检查——先切分再写特征提取循环让提炼出来的特征在测试集上从头计算一遍模拟真实上线状态下模型只能看到历史数据。5.2 坑二窗口标签错位训练时标签比特征晚一步现象第一次训练完之后测试集精确率很高但召回率一直上不去。查了特征矩阵和标签的对齐关系发现标签没有对齐到窗口的最后一个时间点而是对齐到了窗口中心点——相当于模型用过去 15 分钟的特征去预测 15 分钟前的占用状态标签滞后了。原因滑动窗口提取特征时索引用的是窗口起点而不是窗口终点赋值标签时df.iloc[start]和df.iloc[end]混用导致标签与特征在时间轴上错位。在短窗口情况下这个错位只有几分钟到半小时肉眼看不出来但模型性能会持续被影响。解决强制规定窗口标签只取end位置即窗口最末时刻的状态。代码里注释写清楚标签取窗口终点后一段的占用状态然后写个单元测试验证一下错位样本的比例是否为 0。调试过这个坑之后我的习惯是每次构造完特征随机抽 100 条打印特征值和标签值人工对一遍确认时间轴没错位再开始训练。5.3 坑三零值功率段没清洗特征“零值占比”沦为垃圾特征现象特征重要性排序里zero_ratio排到前三但模型在验证集上的表现反而不如去掉这个特征。后来看了原始数据才发现有一段电表故障期间功率连续为 0 长达 5 天这段时间真实占用情况未知但标签里混着一部分错误标注。原因零值段可能是真实无人也可能是电表离线或者家里拉闸但人在。模型学到“功率为 0 就是无人”那段误标注的样本就直接变成了噪声拉低了边界样本的判断能力。这个项目里数据也没有给出电表状态标志位只能靠人工识别零值段与滞后标签的矛盾关系来判断。解决把连续零值超过 2 小时的段落标出来逐一检查对应时间段的占用标签。如果标签显示“有人”大概率是标签错误或数据异常直接剔除。同时把zero_ratio的阈值从 10W 调到 30W因为有些设备在待机状态下功率在 10W 到 20W 之间波动阈值设太低会把真实用电误判为零值。5.4 坑四数据分辨率不同导致复现结果不一致现象换了一台机器复现项目代码同样的参数跑出来的 AUC 差了 3 个百分点。排查了半天发现不是环境版本问题而是原始 CSV 文件里时间戳分辨率不一致——前半部分数据每 1 分钟一条记录后半部分变成了每 15 分钟一条。原因滑动窗口大小固定为 30但不同时间分辨率下 30 的含义完全不同——前 30 分钟和后 30 分钟的特征统计尺度不一样时序切分时训练集和测试集的特征分布也会有系统性偏差模型自然输出不同结果。解决读入数据后立即检查时间间隔的分布。间隔不一致时有两种处理一是全部重采样到统一分辨率比如统一到 15 分钟缺失值前向填充二是按时间间隔分组每个分辨率单独建模最后做投票集成。我通常选第一种省事且稳定——重采样之后窗口长度的实际时间跨度才能统一。这四条坑是我拆这个项目时踩得最深的几个点。前两个是特征工程阶段最容易犯的“隐性错误”第三个是脏数据问题第四个是外部数据格式问题。这四条坑的共性是模型代码看起来没有问题报错也没有AUC 也很高——但结果不可信上线一测就露馅。6. 结果解释与模型落地SHAP 值看哪些特征真正决定了“有人在”模型训练完、评估指标达标之后这个项目还没结束。我拆代码时发现它有一个很值得借鉴的地方对模型结果做了可解释性分析而不是只报一个准确率数字。这在实际业务里非常重要——客户或者你的导师会问“为什么模型预测这个时段有人”这时候你需要给出答案。用 SHAP 分析特征贡献是最直接的做法import shap explainer shap.TreeExplainer(rf) shap_values explainer.shap_values(X_test) # 查看总体特征重要性排序 shap.summary_plot(shap_values, X_test)逻辑说明TreeExplainer是专门针对树模型的 SHAP 解释器它的核心结论来自对所有决策路径的遍历计算——每个特征对每个样本的预测值贡献了多少最终得到一个特征 × 样本的贡献矩阵。summary_plot画出的图里每一行是一个特征点的颜色代表特征值高低红色高、蓝色低横轴代表 SHAP 值正负代表推动模型预测“有人”还是“无人”。拿我跑出来的结果举例贡献最高的前三个特征通常是功率均值、夜间标志位、标准差。这意味着模型的核心判断逻辑是“平均功耗高不是夜间波动大 → 大概率有人”。这个结论本身就可以作为规则解释输送给业务方完全不依赖黑匣子。更进一步当特征量较多时我会在 SHAP 值的基础上做一个简化版特征选择保留 SHAP 平均绝对值排名前 1520 的特征去掉尾部无关特征重新训练模型对比 AUC。大多数时候 AUC 只会下降 0.005 以内而训练时间可以缩短 40% 左右模型可解释性却明显变好。SHAP 分析跑完之后模型的结论就不仅能“预测准确”还能“说清楚为什么”。这个项目最终的产出除了一个分类模型还包括对家庭用电行为的洞察——哪些时间段功率波动是有人活动的标志哪些用电行为与占用无关。如果有后续扩展还可以把同样的特征工程迁移到多户用电数据上做区域性的占用率统计——这也是我做完这个项目后的延伸方向。毕竟从我自己的工作习惯来看拿到一份数据科学项目代码能复现结果只是及格线能解释结果才是真正的加分项——希望这份资源能帮你在占用检测这条路上走到这一步。本文还有配套的精品资源点击获取

基于用电时序数据的家庭占用检测：特征工程与分类建模实践

相关推荐

海面舰船红外与可见光图像配准：从选型到避坑的工程实践

微信小程序在线课堂毕设全解析：SSM框架实战与避坑指南

用 Solidity 写一个待办事项合约：从需求到代码的完整思考过程

更多资讯

C语言冒泡排序从原理到优化：边界问题与调试实战

编辑器、编译器与IDE协同原理：构建可信赖的开发呼吸节奏

Agent记忆系统设计：用SQLite构建可追溯、可查询、可演化的前端本地记忆库

土豆目标检测数据集：农业场景YOLOv5/v8可落地训练资源

Unreal Agent 凭啥对标 Claude Code 与 Codex？Go 系框架的成本账与工程账一起算

告别AI失忆：用claude-mem为Claude打造长期记忆层

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？