尧图网页设计 
简介微信舆情热度具有突发性强、非线性特征明显的特点传统ARIMA模型难以准确预测。这篇论文提出将小波分析、ARIMA与BP神经网络相结合的组合预测框架先对微信公众号文章数、阅读数、点赞数构成的时间序列进行小波4层分解去噪再依据AIC/BIC准则确定ARIMA模型阶数并通过BP神经网络修正非线性残差与突变值。实验以P2P网贷平台微信公众号传播指数Top50为训练样本最终在Top10热度指数上验证了模型精度。PDF文件共1个大小约3.15MB源自《统计与决策》期刊属于神经网络、机器学习与数据建模方向文中不仅介绍了ARIMA-BP混合建模的完整步骤还给出了参数定阶、BP隐含层选择、误差评估等关键实验细节适合舆情分析、时间序列预测及深度学习研究者学习参考。目前已有231人学习该资源借助文中代码思路与实验对比读者可快速复现并扩展这套组合预测方案。1. 基于ARIMA-BP神经网络模型的微信舆情热度预测这套组合到底解决了什么问题“基于ARIMA-BP神经网络模型的微信舆情热度预测”这个标题前半段是模型组合后半段是业务场景中间用微信连起来。在公众号运营和舆情分析里最常遇到的问题就是一篇文章刚发出几个小时能不能提前判断它接下来48小时还会不会涨。直接对阅读量做回归效果很差因为热度序列既包含线性衰减又包含非线性爆发。这套方案给出的是“分工”答案ARIMA负责把线性依赖、趋势和周期先消化干净BP神经网络再去吃ARIMA剩下的残差把非线性爆发捡回来。这套组合模型做小时级热度预测能把72小时MAPE从30%压到18%上下代价只是两次训练和一份调参表。适合公众号数据分析、舆情监控系统以及有内容投放需求的产品团队阅读。接下来的正文按“数据准备 → ARIMA → BP → 组合调参 → 避坑”推进每个阶段都给出可复现的代码和参数。2. 数据准备微信舆情热度指标怎么定义、序列怎么洗2.1 综合热度指标怎么定单看阅读量会踩两个坑微信舆情热度不是一个后台直接提供的字段。公众号后台能导出的是阅读量、在看、点赞、评论、分享这些原始指标而“热度”需要自己构造。很多人直接拿阅读量当热度这里有两个明显问题一是10万封顶爆文一旦到10万后台只显示上限真实传播量可能翻了好几番序列右上角被一刀切平二是阅读量随时间自然衰减同一个数值在发布第1小时和第30小时代表的意义完全不同直接建模会把时间信息混进数值本身。我一般按小时构造综合热度得分把多指标加权import pandas as pd import numpy as np # 后台导出的文章快照数据 df pd.read_csv(wechat_snapshot.csv) df[snapshot_time] pd.to_datetime(df[snapshot_time]) # 每小时保留该文章最后一次快照避免重复累计 df df.sort_values(snapshot_time) hourly ( df.groupby([article_id, pd.Grouper(keysnapshot_time, freqH)]) .tail(1) .sort_values(snapshot_time) ) # 阅读量的小时增量反映当前传播速度 hourly[read_inc] ( hourly.groupby(article_id)[read_count] .diff() .fillna(0) ) # 在看率在看数 / 阅读量衡量内容认可度 hourly[like_rate] hourly[like_count] / (hourly[read_count] 1) # 综合热度增量比存量更重要 hourly[heat_score] ( 0.4 * hourly[read_inc] 0.3 * hourly[like_rate] 0.2 * hourly[comment_count] 0.1 * hourly[share_count] ) # 全体文章按小时求和得到舆情总热度 heat_series ( hourly.groupby(snapshot_time)[heat_score] .sum() .resample(H) .sum() .fillna(0) )这里有两个细节值得展开。第一read_inc 是用 groupby(article_id).diff() 算出来的小时增量它代表“当前每小时新增了多少阅读”比累计阅读量更能刻画传播动力每篇文章第一行的 diff 结果是NaNfillna(0)之后不影响后续计算。第二like_rate 的分母加1是防除零的常规操作10万封顶的阅读量在这里也会被压扁但趋势走向还在。权重 0.4/0.3/0.2/0.1 是经验初值。稳妥做法是取过去30天数据把各指标与人工标注的“爆款等级”做相关分析按相关系数归一化后重新分配权重。需要注意的是如果数据源不是后台导出而是外部抓取微信公众号历史文章的取数接口限制比较多最省事的路径是优先用第三方舆情平台的API或者用自己的认证公众号后台定期导出少在同一IP上高频连续请求触发风控以后账号会被限制登录。2.2 清洗与平稳化log 变换、插值、差分三步走热度序列拿到手之后还不能直接进ARIMA。ARIMA建模的前提是序列平稳而微信热度序列天然不满足白天高、夜间低是24小时周期爆文带来突发尖峰整体还有缓慢的涨跌趋势。三步转换是通用的预处理路径。第一步log变换把几百到几万的量级压缩让模型不用去硬学指数级差异。第二步对缺失小时做线性插值尤其夜间有些平台没有快照缺值会让后续差分多出NaN。第三步做一阶差分消掉整体趋势。差分后是否平稳用ADF检验判断。# 1. 压缩量级 heat_log np.log1p(heat_series) # 2. 缺失小时线性插值前后都补 heat_log heat_log.interpolate(methodlinear, limit_directionboth) # 3. 一阶差分去掉趋势 heat_diff heat_log.diff().dropna() # 4. ADF 平稳性检验 from statsmodels.tsa.stattools import adfuller adf_stat, p_value, usedlag, nobs, crit, icbest adfuller(heat_diff) print(fADF p-value {p_value:.4f}) if p_value 0.05: print(平稳可以进入 ARIMA 定阶) else: print(不平稳需要增加差分阶数)在ARIMA-BP组合里差分阶数d不是越大越好。d1对绝大多数公众号热度序列足够如果ADF还不通过先检查是不是24小时周期性残留是的话优先考虑加季节差分或改用SARIMA而不是盲目把d推到2或3。d过高会把本来稳定的短期自相关信息洗掉后续BP拿到的残差基本都是噪声补偿能力形同虚设。插值这一步还有一个容易被忽略的边界limit_directionboth 保证序列开头和结尾的缺失值也能被补上。别小看这个参数序列开头缺几个点差分后模型可用的样本就少几个点。对于小时级数据一周就是一百多个样本量足够影响模型的稳定性。3. ARIMA 建模部分线性趋势提取与定阶实操3.1 ARIMA 在组合里负责什么线性依赖与非平稳ARIMA的三个字母对应三件事。AR自回归表达的是“当前时刻的热度受过去p个时刻影响”微信热度的惯性就落在这里前一小时热后一小时大概率也热。MA滑动平均表达的是“预测误差受过去q个时刻的扰动影响”用来吸收偶然扰动造成的偏差。I差分是让序列平稳化的手段通常d1。在ARIMA-BP组合里ARIMA只负责把线性部分做扎实。原因很直接如果让ARIMA去直接预测含有爆文尖峰的热度它的拟合曲线会在尖峰处出现系统性滞后——因为AR模型的本质就是用过去的加权平均外推遇到突然翻倍的增长天然慢半拍。反过来如果只上BP神经网络模型会努力同时拟合趋势和尖峰参数量、训练时间和过拟合风险一起上升可解释性也丢了。所以组合的分工是ARIMA吃线性趋势和周期BP吃ARIMA留下的残差。实际落地时我一般先在训练段上把ARIMA定好阶再让BP去学残差。残差的构造是这套流程的关键一步顺序不能反。如果先训BP再回来调ARIMA两边都在互相抢信息模型之间没有清晰的边界出了问题很难排查。3.2 定阶实操ACF/PACF 看图 auto_arima 自动搜索ARIMA定阶有两种常见做法。第一种是画ACF和PACF图人工判断PACF在p阶后截尾说明用AR(p)ACF在q阶后截尾说明用MA(q)。第二种是直接用auto_arima做信息准则搜索。对小时级微信热度经验是p和q基本不会超过7人工看图费时间把搜索范围限制在0到7让工具自动跑就够了。from statsmodels.graphics.tsaplots import plot_acf, plot_pacf import matplotlib.pyplot as plt fig, (ax1, ax2) plt.subplots(2, 1, figsize(12, 8)) plot_acf(heat_log, lags48, axax1, titleACF) plot_pacf(heat_log, lags48, axax2, titlePACF) plt.show()ACF/PACF看什么如果ACF呈缓慢拖尾衰减PACF在1到2阶后截尾倾向选AR阶数小的模型如果两者都拖尾说明AR和MA都要。但有个前提——序列必须已经平稳所以传入的是经过前面预处理的 heat_log不是原始值。lags48 是为了和24小时周期对齐便于观察是否存在按天的自相关峰。自动定阶的写法from pmdarima import auto_arima model_arima auto_arima( heat_log, start_p0, max_p7, start_q0, max_q7, d1, max_order12, seasonalFalse, information_criterionaic, stepwiseTrue, error_actionignore, traceTrue ) print(model_arima.summary()) # 样本内拟合值用于计算残差 fitted_vals model_arima.predict_in_sample() resid_series (heat_log - fitted_vals).dropna()参数说明max_p7 和 max_q7 的设定基于小时级数据的经验——虽然一天有24个点但热度的自相关不会隔太久依旧很强超过7阶属于过度记忆max_order12 限制 pq 总阶数防止模型搜出一个又长又怪的组合。information_criterionaic 在拟合优度和复杂度之间取平衡比BIC更适合预测场景。stepwiseTrue 走逐步搜索速度会明显快于全遍历。残差序列算出来之后需要再画一次它的自相关图。理想状态下残差应该接近白噪声但白噪声只是“线性关系被抽干”的信号不代表没有非线性规律。第一次搭这套模型的人会在这里困惑残差看起来乱糟糟的BP能学到什么答案是要赌它里面有非线性模式比如爆文的二次传播、晚间用户的集中互动。如果残差的自相关图在24小时处还有明显的峰说明季节性没被ARIMA完全消化这时候优先回头处理季节性再进BP才有效否则BP会替ARIMA背锅。4. BP神经网络部分把残差的非线性规律捡回来4.1 网络结构设计为什么输入窗口和残差序列有关BP神经网络在组合模型里的输入不是原始热度而是ARIMA的残差。残差序列 真实热度 - ARIMA拟合值。这个序列里剩下的东西理论上是ARIMA不擅长的非线性成分。网上能搜到的bp神经网络结构图大多画成了三层全连接但工程落地时真正要决定的是隐藏层数、每层神经元数和激活函数。我见过不少把结构堆到三四个隐藏层的做法在小样本时间序列上几乎必然过拟合。微信热度小时级数据一两个月也就一千多个样本点网络结构必须控制在两个隐藏层以内。我一般用的配置是输入层24个节点对应过去24小时的残差值第一隐藏层16个神经元tanh第二隐藏层8个神经元tanh输出层1个神经元linear输入窗口为什么定24微信舆论以天为周期窗口取24小时自然包含一个完整的周期样本。如果数据是分钟级窗口可能需要拉到240或更多小时级数据24足够了。窗口太短比如直接用当前残差预测下一时刻BP学不到任何短期形态窗口太长比如48样本数量会明显变少因为每个样本要占48个连续点。4.2 用 Keras 实现残差学习滑窗造样本与训练残差学习的关键是把一维残差序列切成“滑动窗口样本”。滑窗的做法是从第t-23到第t时刻的24个残差值作为输入第t1时刻的残差作为标签。滑动窗口让每个历史点都参与多次训练样本量得以扩充这也是小时级数据下不额外造数据的主要手段。import numpy as np from tensorflow.keras.models import Sequential from tensorflow.keras.layers import Dense def make_sequences(data, window24): X, y [], [] for i in range(window, len(data)): X.append(data[i - window:i]) y.append(data[i]) return np.array(X), np.array(y) # 用上一章算出的残差 resid_values resid_series.values X, y make_sequences(resid_values, window24) # 时间顺序切分训练集在前测试集在后 split int(len(X) * 0.8) X_train, X_test X[:split], X[split:] y_train, y_test y[:split], y[split:] # BP网络结构16 - 8 - 1 model_bp Sequential([ Dense(16, activationtanh, input_shape(24,)), Dense(8, activationtanh), Dense(1, activationlinear) ]) model_bp.compile(optimizeradam, lossmse, metrics[mae]) model_bp.summary() # 早停防止在小样本上把噪声背下来 from tensorflow.keras.callbacks import EarlyStopping es EarlyStopping(monitorval_loss, patience10, restore_best_weightsTrue) # 注意shuffle必须为False时间序列样本不能乱序 history model_bp.fit( X_train, y_train, validation_data(X_test, y_test), epochs100, batch_size32, shuffleFalse, callbacks[es], verbose1 )几个参数值得展开。第一个是 shuffleFalse时间序列的样本顺序本身携带信息随机打乱会让模型把“未来的残差”混进训练分布这是时间序列训练里最隐蔽的翻车点。第二个是激活函数tanh残差有正有负tanh的输出范围对称适合让网络表达“热度会上涨”还是“热度会回落”换ReLU对负向残差几乎不敏感输出容易被压到0附近。第三个是 batch_size32残差样本量通常只有几百到一两千batch太大一个epoch就十几步收敛慢32是稳妥初值。EarlyStopping 的 patience10 在 epochs100 下相当于给了十轮观察期。序列残差的学习曲线往往是缓慢下降的patience设太短会在接近谷底时被提前拉停。restore_best_weightsTrue 会保留验证集loss最低的那组权重而不是最后epoch的权重。训练结束后第一件事是看 history 里训练loss和验证loss的差距。如果训练loss远低于验证loss网络过拟合了先在结构上减层不要急着加数据增强——时间序列没有图像那样的翻转增强空间手工造数据只会把误差模态带偏。5. 模型组合与参数调优ARIMA打底、BP补残差的完整预测链路5.1 组合策略与预测函数串行叠加递推更新ARIMA和BP都训练好之后预测阶段的接法是串行叠加。具体来说对未来的每一个小时最终预测值 ARIMA的预测值 BP预测的残差。ARIMA直接把线性趋势推到未来BP以最近24个小时的残差为输入预测未来那一小时的残差补偿。这里有个工程细节预测未来第2、第3小时时残差窗口里还没有真实残差常见的做法是“递归更新”——用BP刚预测出的残差补进窗口作为下一时刻的输入。这个递归过程会有误差累积所以有效期一般控制在未来24到48小时左右不建议一口气预测七天。微信热度预测的实际业务也集中在24到72小时超过三天模型给出的数值只能当方向参考。def arima_bp_forecast(model_arima, model_bp, heat_log, steps48, window24): # 用训练段拟合值算残差 fitted model_arima.predict_in_sample() resid_series heat_log - fitted # 最近 window 个残差作为BP窗口 recent_resid list(resid_series.dropna().values[-window:]) # ARIMA 直接外推未来 steps 点 arima_forecast model_arima.predict(n_periodssteps) final_forecast [] for i in range(steps): # BP 对下一个残差的预测 x_input np.array(recent_resid[-window:]).reshape(1, -1) resid_pred model_bp.predict(x_input, verbose0)[0, 0] # 组合ARIMA基线 BP补偿 pred arima_forecast[i] resid_pred final_forecast.append(pred) # 递归更新预测出的残差进入窗口最老的残差退出 recent_resid.append(resid_pred) recent_resid.pop(0) return np.array(final_forecast)这段函数有两个边界条件要注意。第一recent_resid.pop(0) 是O(n)操作但在 window24 的场景下代价可忽略如果把 window 调到几百建议换成 collections.deque否则每次预测都会有一点额外开销。第二heat_log 传入的是预处理完毕的对数序列不是原始热度。函数输出的 final_forecast 也在 log 尺度上评估时需要 np.expm1 还原。在真实评估流程里不要拿全量数据拟合模型然后对同一个数据集做预测。正确顺序是先按时间切出 train 和 test在 train 上拟合ARIMA和BP再在 test 上跑预测函数。以下是一段可复制的评估骨架from sklearn.metrics import mean_absolute_error, mean_squared_error # 切出后48小时做测试 test_len 48 train_part, test_part heat_log.iloc[:-test_len], heat_log.iloc[-test_len:] # 用训练段重新拟合 ARIMA model_arima auto_arima( train_part, start_p0, max_p7, start_q0, max_q7, d1, seasonalFalse, information_criterionaic, stepwiseTrue, error_actionignore ) # 在 train_part 上按第4章代码训练 model_bp此处略写 # 预测并评估 pred_part arima_bp_forecast(model_arima, model_bp, train_part, stepstest_len) mae mean_absolute_error(test_part.values, pred_part) rmse np.sqrt(mean_squared_error(test_part.values, pred_part)) print(flog尺度 MAE{mae:.4f} RMSE{rmse:.4f}) # 还原回原始热度尺度 true_orig np.expm1(test_part.values) pred_orig np.expm1(pred_part) print(f原始尺度 MAE{np.mean(np.abs(true_orig - pred_orig)):.2f})log 尺度上的MAE 表达的是“对数热度偏差”原始坐标的MAE 更直观但也更受极值牵制。两组都打印上线汇报用原始尺度调参用 log 尺度不要让业务方直接拿 log 数值去理解预测误差。5.2 参数速查与调参方向把整篇文章涉及的参数归成一张速查表落到具体业务时可以照着初值先跑一版再按现象调整组件参数初值建议调参方向预处理聚合粒度小时流量平稳可降到分钟级预处理变换方式np.log1p尖峰特别多可尝试Box-CoxARIMAd1不平稳先查周期别直接加dARIMAp / q0~7自动搜残差ACF有峰时调大范围ARIMAseasonalFalse24小时峰明显时改TrueBP滑窗长度24能看出更长周期时调到48BP隐藏层16→8过拟合就减半欠拟合加倍BP激活函数tanh输出负数异常时改softplusBPepochs100以早停为准不硬控BPbatch_size32样本少就用16评估horizon48h业务要求72h也行这张表里最值得说的是 ARIMA 的 seasonal 参数。微信热度大概率存在24小时周期理论上 seasonalTrue 更准确但要在 auto_arima 里同时开季节性搜索速度会明显变慢。我的习惯是先关掉季节性跑通一版组合模型如果残差ACF在24小时附近还有峰再开 seasonal 并设 m24。先简单后复杂每一步都有对照出问题才知道是哪一块引起的。6. 避坑排查与滚动验证从能跑到好用6.1 五个高频踩坑记录先来五个我自己或身边团队真踩过的坑。踩坑 1预测曲线整体滞后一拍。现象预测值比真实值晚一到两个小时相关性看着很高但时序完全不对。 原因ARIMA的d1没有完全消除局部趋势或者BP的滑窗里旧信息权重过高。 解决先对差分后序列重跑ADF确认平稳再检查ARIMA残差自相关若仍有显著相关则放宽p、q范围。踩坑 210万文章把模型带崩。现象普通文章预测误差很小爆款一出现预测值直接偏离一个量级。 原因阅读量被10万截断序列上界被压平模型学到的上限就是10万。 解决热度得分里增加在看率、评论数等辅助指标把“是否破10万”作为二元特征拼进BP输入让网络学习到“上限被截断”这个状态。踩坑 3BP预测的残差基本恒为0。现象组合预测结果和纯ARIMA几乎一样BP完全没起作用。 原因残差已接近白噪声或者训练时残差没有做标准化网络收敛到了全0输出。 解决先画残差ACF确认还有可学信息训练前把残差做z-score标准化让网络输出分布偏离0。踩坑 4最终预测出现负热度。现象原始尺度还原后某些时段的热度为负明显不合理。 原因log尺度下BP预测出大的负残差组合值被压到负数。 解决预测结果用 np.maximum(0, pred) 截断更根本的做法是把BP输出层从 linear 换成 softplussoftplus 的输出天然非负。踩坑 5生产环境效果和离线测试差一大截。现象离线测试MAE达标上线第一周就崩监控图上预测曲线频繁穿帮。 原因样本外事件——临时活动、大V转发、平台规则变化模型没见过。 解决上线后在线上持续计算预测残差残差连续超过阈值就触发重训别指望一次训练吃一年。6.2 滚动回测与重训触发最后一道验证工序是滚动回测替代一次性切分测试集。一次性切分的问题是模型在某一段特定时间表现好不代表下一个自然周也表现好。滚动回测的做法是固定一个训练窗口比如最近30天每6小时滑动一次预测未来24小时并记录误差滑完整个历史后取误差均值。def rolling_backtest(heat_log, train_win720, step6, horizon24): errors [] start 0 while start train_win horizon len(heat_log): train heat_log.iloc[start : start train_win] test heat_log.iloc[start train_win : start train_win horizon] # 每轮新窗口重新走一遍ARIMABP拟合再调 arima_bp_forecast # 这里把上述步骤封装成 train_predict(train, horizon) 返回预测 pred train_predict(train, horizon) mae mean_absolute_error(test.values, pred) errors.append(mae) start step return np.mean(errors), np.std(errors)train_win720 对应30天小时级数据这是训练ARIMA和BP都比较合适的体量step6 表示每6小时重训一次模型防止模型在数据分布缓慢变化时失效。滚动回测的均值能反映模型在真实时间环境下的平均表现标准差能看出模型是否在某些时段特别不稳定。我现在的习惯是任何ARIMA-BP方案上线前先跑一轮滚动回测再对比纯ARIMA基线的误差如果组合模型比基线提升低于10%说明残差里根本没有非线性规律值得BP去学索性降级用纯ARIMA省一份维护成本。希望这个判断思路能帮你在自己的微信舆情热度预测项目里少走一段弯路。本文还有配套的精品资源点击获取 ARIMA-BP神经网络组合模型在微信舆情热度预测中的应用
简介微信舆情热度具有突发性强、非线性特征明显的特点传统ARIMA模型难以准确预测。这篇论文提出将小波分析、ARIMA与BP神经网络相结合的组合预测框架先对微信公众号文章数、阅读数、点赞数构成的时间序列进行小波4层分解去噪再依据AIC/BIC准则确定ARIMA模型阶数并通过BP神经网络修正非线性残差与突变值。实验以P2P网贷平台微信公众号传播指数Top50为训练样本最终在Top10热度指数上验证了模型精度。PDF文件共1个大小约3.15MB源自《统计与决策》期刊属于神经网络、机器学习与数据建模方向文中不仅介绍了ARIMA-BP混合建模的完整步骤还给出了参数定阶、BP隐含层选择、误差评估等关键实验细节适合舆情分析、时间序列预测及深度学习研究者学习参考。目前已有231人学习该资源借助文中代码思路与实验对比读者可快速复现并扩展这套组合预测方案。1. 基于ARIMA-BP神经网络模型的微信舆情热度预测这套组合到底解决了什么问题“基于ARIMA-BP神经网络模型的微信舆情热度预测”这个标题前半段是模型组合后半段是业务场景中间用微信连起来。在公众号运营和舆情分析里最常遇到的问题就是一篇文章刚发出几个小时能不能提前判断它接下来48小时还会不会涨。直接对阅读量做回归效果很差因为热度序列既包含线性衰减又包含非线性爆发。这套方案给出的是“分工”答案ARIMA负责把线性依赖、趋势和周期先消化干净BP神经网络再去吃ARIMA剩下的残差把非线性爆发捡回来。这套组合模型做小时级热度预测能把72小时MAPE从30%压到18%上下代价只是两次训练和一份调参表。适合公众号数据分析、舆情监控系统以及有内容投放需求的产品团队阅读。接下来的正文按“数据准备 → ARIMA → BP → 组合调参 → 避坑”推进每个阶段都给出可复现的代码和参数。2. 数据准备微信舆情热度指标怎么定义、序列怎么洗2.1 综合热度指标怎么定单看阅读量会踩两个坑微信舆情热度不是一个后台直接提供的字段。公众号后台能导出的是阅读量、在看、点赞、评论、分享这些原始指标而“热度”需要自己构造。很多人直接拿阅读量当热度这里有两个明显问题一是10万封顶爆文一旦到10万后台只显示上限真实传播量可能翻了好几番序列右上角被一刀切平二是阅读量随时间自然衰减同一个数值在发布第1小时和第30小时代表的意义完全不同直接建模会把时间信息混进数值本身。我一般按小时构造综合热度得分把多指标加权import pandas as pd import numpy as np # 后台导出的文章快照数据 df pd.read_csv(wechat_snapshot.csv) df[snapshot_time] pd.to_datetime(df[snapshot_time]) # 每小时保留该文章最后一次快照避免重复累计 df df.sort_values(snapshot_time) hourly ( df.groupby([article_id, pd.Grouper(keysnapshot_time, freqH)]) .tail(1) .sort_values(snapshot_time) ) # 阅读量的小时增量反映当前传播速度 hourly[read_inc] ( hourly.groupby(article_id)[read_count] .diff() .fillna(0) ) # 在看率在看数 / 阅读量衡量内容认可度 hourly[like_rate] hourly[like_count] / (hourly[read_count] 1) # 综合热度增量比存量更重要 hourly[heat_score] ( 0.4 * hourly[read_inc] 0.3 * hourly[like_rate] 0.2 * hourly[comment_count] 0.1 * hourly[share_count] ) # 全体文章按小时求和得到舆情总热度 heat_series ( hourly.groupby(snapshot_time)[heat_score] .sum() .resample(H) .sum() .fillna(0) )这里有两个细节值得展开。第一read_inc 是用 groupby(article_id).diff() 算出来的小时增量它代表“当前每小时新增了多少阅读”比累计阅读量更能刻画传播动力每篇文章第一行的 diff 结果是NaNfillna(0)之后不影响后续计算。第二like_rate 的分母加1是防除零的常规操作10万封顶的阅读量在这里也会被压扁但趋势走向还在。权重 0.4/0.3/0.2/0.1 是经验初值。稳妥做法是取过去30天数据把各指标与人工标注的“爆款等级”做相关分析按相关系数归一化后重新分配权重。需要注意的是如果数据源不是后台导出而是外部抓取微信公众号历史文章的取数接口限制比较多最省事的路径是优先用第三方舆情平台的API或者用自己的认证公众号后台定期导出少在同一IP上高频连续请求触发风控以后账号会被限制登录。2.2 清洗与平稳化log 变换、插值、差分三步走热度序列拿到手之后还不能直接进ARIMA。ARIMA建模的前提是序列平稳而微信热度序列天然不满足白天高、夜间低是24小时周期爆文带来突发尖峰整体还有缓慢的涨跌趋势。三步转换是通用的预处理路径。第一步log变换把几百到几万的量级压缩让模型不用去硬学指数级差异。第二步对缺失小时做线性插值尤其夜间有些平台没有快照缺值会让后续差分多出NaN。第三步做一阶差分消掉整体趋势。差分后是否平稳用ADF检验判断。# 1. 压缩量级 heat_log np.log1p(heat_series) # 2. 缺失小时线性插值前后都补 heat_log heat_log.interpolate(methodlinear, limit_directionboth) # 3. 一阶差分去掉趋势 heat_diff heat_log.diff().dropna() # 4. ADF 平稳性检验 from statsmodels.tsa.stattools import adfuller adf_stat, p_value, usedlag, nobs, crit, icbest adfuller(heat_diff) print(fADF p-value {p_value:.4f}) if p_value 0.05: print(平稳可以进入 ARIMA 定阶) else: print(不平稳需要增加差分阶数)在ARIMA-BP组合里差分阶数d不是越大越好。d1对绝大多数公众号热度序列足够如果ADF还不通过先检查是不是24小时周期性残留是的话优先考虑加季节差分或改用SARIMA而不是盲目把d推到2或3。d过高会把本来稳定的短期自相关信息洗掉后续BP拿到的残差基本都是噪声补偿能力形同虚设。插值这一步还有一个容易被忽略的边界limit_directionboth 保证序列开头和结尾的缺失值也能被补上。别小看这个参数序列开头缺几个点差分后模型可用的样本就少几个点。对于小时级数据一周就是一百多个样本量足够影响模型的稳定性。3. ARIMA 建模部分线性趋势提取与定阶实操3.1 ARIMA 在组合里负责什么线性依赖与非平稳ARIMA的三个字母对应三件事。AR自回归表达的是“当前时刻的热度受过去p个时刻影响”微信热度的惯性就落在这里前一小时热后一小时大概率也热。MA滑动平均表达的是“预测误差受过去q个时刻的扰动影响”用来吸收偶然扰动造成的偏差。I差分是让序列平稳化的手段通常d1。在ARIMA-BP组合里ARIMA只负责把线性部分做扎实。原因很直接如果让ARIMA去直接预测含有爆文尖峰的热度它的拟合曲线会在尖峰处出现系统性滞后——因为AR模型的本质就是用过去的加权平均外推遇到突然翻倍的增长天然慢半拍。反过来如果只上BP神经网络模型会努力同时拟合趋势和尖峰参数量、训练时间和过拟合风险一起上升可解释性也丢了。所以组合的分工是ARIMA吃线性趋势和周期BP吃ARIMA留下的残差。实际落地时我一般先在训练段上把ARIMA定好阶再让BP去学残差。残差的构造是这套流程的关键一步顺序不能反。如果先训BP再回来调ARIMA两边都在互相抢信息模型之间没有清晰的边界出了问题很难排查。3.2 定阶实操ACF/PACF 看图 auto_arima 自动搜索ARIMA定阶有两种常见做法。第一种是画ACF和PACF图人工判断PACF在p阶后截尾说明用AR(p)ACF在q阶后截尾说明用MA(q)。第二种是直接用auto_arima做信息准则搜索。对小时级微信热度经验是p和q基本不会超过7人工看图费时间把搜索范围限制在0到7让工具自动跑就够了。from statsmodels.graphics.tsaplots import plot_acf, plot_pacf import matplotlib.pyplot as plt fig, (ax1, ax2) plt.subplots(2, 1, figsize(12, 8)) plot_acf(heat_log, lags48, axax1, titleACF) plot_pacf(heat_log, lags48, axax2, titlePACF) plt.show()ACF/PACF看什么如果ACF呈缓慢拖尾衰减PACF在1到2阶后截尾倾向选AR阶数小的模型如果两者都拖尾说明AR和MA都要。但有个前提——序列必须已经平稳所以传入的是经过前面预处理的 heat_log不是原始值。lags48 是为了和24小时周期对齐便于观察是否存在按天的自相关峰。自动定阶的写法from pmdarima import auto_arima model_arima auto_arima( heat_log, start_p0, max_p7, start_q0, max_q7, d1, max_order12, seasonalFalse, information_criterionaic, stepwiseTrue, error_actionignore, traceTrue ) print(model_arima.summary()) # 样本内拟合值用于计算残差 fitted_vals model_arima.predict_in_sample() resid_series (heat_log - fitted_vals).dropna()参数说明max_p7 和 max_q7 的设定基于小时级数据的经验——虽然一天有24个点但热度的自相关不会隔太久依旧很强超过7阶属于过度记忆max_order12 限制 pq 总阶数防止模型搜出一个又长又怪的组合。information_criterionaic 在拟合优度和复杂度之间取平衡比BIC更适合预测场景。stepwiseTrue 走逐步搜索速度会明显快于全遍历。残差序列算出来之后需要再画一次它的自相关图。理想状态下残差应该接近白噪声但白噪声只是“线性关系被抽干”的信号不代表没有非线性规律。第一次搭这套模型的人会在这里困惑残差看起来乱糟糟的BP能学到什么答案是要赌它里面有非线性模式比如爆文的二次传播、晚间用户的集中互动。如果残差的自相关图在24小时处还有明显的峰说明季节性没被ARIMA完全消化这时候优先回头处理季节性再进BP才有效否则BP会替ARIMA背锅。4. BP神经网络部分把残差的非线性规律捡回来4.1 网络结构设计为什么输入窗口和残差序列有关BP神经网络在组合模型里的输入不是原始热度而是ARIMA的残差。残差序列 真实热度 - ARIMA拟合值。这个序列里剩下的东西理论上是ARIMA不擅长的非线性成分。网上能搜到的bp神经网络结构图大多画成了三层全连接但工程落地时真正要决定的是隐藏层数、每层神经元数和激活函数。我见过不少把结构堆到三四个隐藏层的做法在小样本时间序列上几乎必然过拟合。微信热度小时级数据一两个月也就一千多个样本点网络结构必须控制在两个隐藏层以内。我一般用的配置是输入层24个节点对应过去24小时的残差值第一隐藏层16个神经元tanh第二隐藏层8个神经元tanh输出层1个神经元linear输入窗口为什么定24微信舆论以天为周期窗口取24小时自然包含一个完整的周期样本。如果数据是分钟级窗口可能需要拉到240或更多小时级数据24足够了。窗口太短比如直接用当前残差预测下一时刻BP学不到任何短期形态窗口太长比如48样本数量会明显变少因为每个样本要占48个连续点。4.2 用 Keras 实现残差学习滑窗造样本与训练残差学习的关键是把一维残差序列切成“滑动窗口样本”。滑窗的做法是从第t-23到第t时刻的24个残差值作为输入第t1时刻的残差作为标签。滑动窗口让每个历史点都参与多次训练样本量得以扩充这也是小时级数据下不额外造数据的主要手段。import numpy as np from tensorflow.keras.models import Sequential from tensorflow.keras.layers import Dense def make_sequences(data, window24): X, y [], [] for i in range(window, len(data)): X.append(data[i - window:i]) y.append(data[i]) return np.array(X), np.array(y) # 用上一章算出的残差 resid_values resid_series.values X, y make_sequences(resid_values, window24) # 时间顺序切分训练集在前测试集在后 split int(len(X) * 0.8) X_train, X_test X[:split], X[split:] y_train, y_test y[:split], y[split:] # BP网络结构16 - 8 - 1 model_bp Sequential([ Dense(16, activationtanh, input_shape(24,)), Dense(8, activationtanh), Dense(1, activationlinear) ]) model_bp.compile(optimizeradam, lossmse, metrics[mae]) model_bp.summary() # 早停防止在小样本上把噪声背下来 from tensorflow.keras.callbacks import EarlyStopping es EarlyStopping(monitorval_loss, patience10, restore_best_weightsTrue) # 注意shuffle必须为False时间序列样本不能乱序 history model_bp.fit( X_train, y_train, validation_data(X_test, y_test), epochs100, batch_size32, shuffleFalse, callbacks[es], verbose1 )几个参数值得展开。第一个是 shuffleFalse时间序列的样本顺序本身携带信息随机打乱会让模型把“未来的残差”混进训练分布这是时间序列训练里最隐蔽的翻车点。第二个是激活函数tanh残差有正有负tanh的输出范围对称适合让网络表达“热度会上涨”还是“热度会回落”换ReLU对负向残差几乎不敏感输出容易被压到0附近。第三个是 batch_size32残差样本量通常只有几百到一两千batch太大一个epoch就十几步收敛慢32是稳妥初值。EarlyStopping 的 patience10 在 epochs100 下相当于给了十轮观察期。序列残差的学习曲线往往是缓慢下降的patience设太短会在接近谷底时被提前拉停。restore_best_weightsTrue 会保留验证集loss最低的那组权重而不是最后epoch的权重。训练结束后第一件事是看 history 里训练loss和验证loss的差距。如果训练loss远低于验证loss网络过拟合了先在结构上减层不要急着加数据增强——时间序列没有图像那样的翻转增强空间手工造数据只会把误差模态带偏。5. 模型组合与参数调优ARIMA打底、BP补残差的完整预测链路5.1 组合策略与预测函数串行叠加递推更新ARIMA和BP都训练好之后预测阶段的接法是串行叠加。具体来说对未来的每一个小时最终预测值 ARIMA的预测值 BP预测的残差。ARIMA直接把线性趋势推到未来BP以最近24个小时的残差为输入预测未来那一小时的残差补偿。这里有个工程细节预测未来第2、第3小时时残差窗口里还没有真实残差常见的做法是“递归更新”——用BP刚预测出的残差补进窗口作为下一时刻的输入。这个递归过程会有误差累积所以有效期一般控制在未来24到48小时左右不建议一口气预测七天。微信热度预测的实际业务也集中在24到72小时超过三天模型给出的数值只能当方向参考。def arima_bp_forecast(model_arima, model_bp, heat_log, steps48, window24): # 用训练段拟合值算残差 fitted model_arima.predict_in_sample() resid_series heat_log - fitted # 最近 window 个残差作为BP窗口 recent_resid list(resid_series.dropna().values[-window:]) # ARIMA 直接外推未来 steps 点 arima_forecast model_arima.predict(n_periodssteps) final_forecast [] for i in range(steps): # BP 对下一个残差的预测 x_input np.array(recent_resid[-window:]).reshape(1, -1) resid_pred model_bp.predict(x_input, verbose0)[0, 0] # 组合ARIMA基线 BP补偿 pred arima_forecast[i] resid_pred final_forecast.append(pred) # 递归更新预测出的残差进入窗口最老的残差退出 recent_resid.append(resid_pred) recent_resid.pop(0) return np.array(final_forecast)这段函数有两个边界条件要注意。第一recent_resid.pop(0) 是O(n)操作但在 window24 的场景下代价可忽略如果把 window 调到几百建议换成 collections.deque否则每次预测都会有一点额外开销。第二heat_log 传入的是预处理完毕的对数序列不是原始热度。函数输出的 final_forecast 也在 log 尺度上评估时需要 np.expm1 还原。在真实评估流程里不要拿全量数据拟合模型然后对同一个数据集做预测。正确顺序是先按时间切出 train 和 test在 train 上拟合ARIMA和BP再在 test 上跑预测函数。以下是一段可复制的评估骨架from sklearn.metrics import mean_absolute_error, mean_squared_error # 切出后48小时做测试 test_len 48 train_part, test_part heat_log.iloc[:-test_len], heat_log.iloc[-test_len:] # 用训练段重新拟合 ARIMA model_arima auto_arima( train_part, start_p0, max_p7, start_q0, max_q7, d1, seasonalFalse, information_criterionaic, stepwiseTrue, error_actionignore ) # 在 train_part 上按第4章代码训练 model_bp此处略写 # 预测并评估 pred_part arima_bp_forecast(model_arima, model_bp, train_part, stepstest_len) mae mean_absolute_error(test_part.values, pred_part) rmse np.sqrt(mean_squared_error(test_part.values, pred_part)) print(flog尺度 MAE{mae:.4f} RMSE{rmse:.4f}) # 还原回原始热度尺度 true_orig np.expm1(test_part.values) pred_orig np.expm1(pred_part) print(f原始尺度 MAE{np.mean(np.abs(true_orig - pred_orig)):.2f})log 尺度上的MAE 表达的是“对数热度偏差”原始坐标的MAE 更直观但也更受极值牵制。两组都打印上线汇报用原始尺度调参用 log 尺度不要让业务方直接拿 log 数值去理解预测误差。5.2 参数速查与调参方向把整篇文章涉及的参数归成一张速查表落到具体业务时可以照着初值先跑一版再按现象调整组件参数初值建议调参方向预处理聚合粒度小时流量平稳可降到分钟级预处理变换方式np.log1p尖峰特别多可尝试Box-CoxARIMAd1不平稳先查周期别直接加dARIMAp / q0~7自动搜残差ACF有峰时调大范围ARIMAseasonalFalse24小时峰明显时改TrueBP滑窗长度24能看出更长周期时调到48BP隐藏层16→8过拟合就减半欠拟合加倍BP激活函数tanh输出负数异常时改softplusBPepochs100以早停为准不硬控BPbatch_size32样本少就用16评估horizon48h业务要求72h也行这张表里最值得说的是 ARIMA 的 seasonal 参数。微信热度大概率存在24小时周期理论上 seasonalTrue 更准确但要在 auto_arima 里同时开季节性搜索速度会明显变慢。我的习惯是先关掉季节性跑通一版组合模型如果残差ACF在24小时附近还有峰再开 seasonal 并设 m24。先简单后复杂每一步都有对照出问题才知道是哪一块引起的。6. 避坑排查与滚动验证从能跑到好用6.1 五个高频踩坑记录先来五个我自己或身边团队真踩过的坑。踩坑 1预测曲线整体滞后一拍。现象预测值比真实值晚一到两个小时相关性看着很高但时序完全不对。 原因ARIMA的d1没有完全消除局部趋势或者BP的滑窗里旧信息权重过高。 解决先对差分后序列重跑ADF确认平稳再检查ARIMA残差自相关若仍有显著相关则放宽p、q范围。踩坑 210万文章把模型带崩。现象普通文章预测误差很小爆款一出现预测值直接偏离一个量级。 原因阅读量被10万截断序列上界被压平模型学到的上限就是10万。 解决热度得分里增加在看率、评论数等辅助指标把“是否破10万”作为二元特征拼进BP输入让网络学习到“上限被截断”这个状态。踩坑 3BP预测的残差基本恒为0。现象组合预测结果和纯ARIMA几乎一样BP完全没起作用。 原因残差已接近白噪声或者训练时残差没有做标准化网络收敛到了全0输出。 解决先画残差ACF确认还有可学信息训练前把残差做z-score标准化让网络输出分布偏离0。踩坑 4最终预测出现负热度。现象原始尺度还原后某些时段的热度为负明显不合理。 原因log尺度下BP预测出大的负残差组合值被压到负数。 解决预测结果用 np.maximum(0, pred) 截断更根本的做法是把BP输出层从 linear 换成 softplussoftplus 的输出天然非负。踩坑 5生产环境效果和离线测试差一大截。现象离线测试MAE达标上线第一周就崩监控图上预测曲线频繁穿帮。 原因样本外事件——临时活动、大V转发、平台规则变化模型没见过。 解决上线后在线上持续计算预测残差残差连续超过阈值就触发重训别指望一次训练吃一年。6.2 滚动回测与重训触发最后一道验证工序是滚动回测替代一次性切分测试集。一次性切分的问题是模型在某一段特定时间表现好不代表下一个自然周也表现好。滚动回测的做法是固定一个训练窗口比如最近30天每6小时滑动一次预测未来24小时并记录误差滑完整个历史后取误差均值。def rolling_backtest(heat_log, train_win720, step6, horizon24): errors [] start 0 while start train_win horizon len(heat_log): train heat_log.iloc[start : start train_win] test heat_log.iloc[start train_win : start train_win horizon] # 每轮新窗口重新走一遍ARIMABP拟合再调 arima_bp_forecast # 这里把上述步骤封装成 train_predict(train, horizon) 返回预测 pred train_predict(train, horizon) mae mean_absolute_error(test.values, pred) errors.append(mae) start step return np.mean(errors), np.std(errors)train_win720 对应30天小时级数据这是训练ARIMA和BP都比较合适的体量step6 表示每6小时重训一次模型防止模型在数据分布缓慢变化时失效。滚动回测的均值能反映模型在真实时间环境下的平均表现标准差能看出模型是否在某些时段特别不稳定。我现在的习惯是任何ARIMA-BP方案上线前先跑一轮滚动回测再对比纯ARIMA基线的误差如果组合模型比基线提升低于10%说明残差里根本没有非线性规律值得BP去学索性降级用纯ARIMA省一份维护成本。希望这个判断思路能帮你在自己的微信舆情热度预测项目里少走一段弯路。本文还有配套的精品资源点击获取