企业官网建设流程全解析

简介：面向计算机相关专业学生与开发者的交通拥堵预测实战资源，基于Python实现道路时间段内车辆流量预测，适用于毕设、课程设计、项目初期立项或实际借鉴，也可作为数据挖掘与机器学习课程的补充练习。项目源自典型的交通拥堵预测任务：主干道布设855个传感器，每5分钟采集一次拥堵状态，一天形成288条记录，状态分为通畅、轻微、中度、重度四档，预测目标是接下来30分钟内所有传感器的拥堵状态。资源提供5天数据中的4天作为训练集、第5天作为测试集，并包含数据预处理、特征筛选、模型训练等代码，可帮助读者完成从数据清洗到最终预测输出的完整流程。压缩包共19个文件，以Python脚本、项目说明txt、测试集csv及分步打包zip为主，整体仅32KB，结构清晰，便于快速部署与二次修改。目前已有1190人学习下载，配套说明文档对实验方案、评估方式和输出格式有详细交代，适合作为智能交通方向入门与毕设参考。

1. 交通拥堵预测到底难在哪：时间段粒度和流量起伏的真相

交通拥堵预测难的地方，往往不在模型精度，而在时间段的划分口径。一个简单的历史均值模型，只要把早高峰 7:00-9:00、晚高峰 17:00-19:00 的粒度切准，预测效果就能立刻上一个台阶；反过来，模型再花哨，训练集和测试集没有按时间顺序切分，结果基本都是虚的。这套工具链围绕“基于 python 的道路时间段内的车辆流量预测”展开，覆盖从原始过车记录到 15 分钟粒度流量序列的清洗聚合、时间特征构造、模型选型评估，以及最后的区间预测和拥堵告警。它适合正在做毕设的本科生，也适合刚接触交通数据挖掘、想快速搭一个可复现预测基线的开发人员。训练集和测试集的存在让复现路径更清晰：按时间窗口切分、训练、验证、出指标，每一步都能对着数据检查。

2. 数据预处理与时间特征工程：把原始打点聚合成可预测的时段流量

交通流量的原始数据通常是过车记录，也就是每一辆车经过某个断面时留下一条时间戳记录。要预测“某段道路在某个时间段内的车流量”，第一步不是建模，而是把噪声很大的打点记录聚合成平稳的流量序列。这个环节直接决定后续模型的上限，值得多花时间。

2.1 先定聚合粒度：15分钟还是1小时对预测效果的影响

聚合粒度是最容易被忽略的决策。5 分钟粒度下，信号灯周期带来的波动会把曲线弄得毛刺密布，模型学到的是噪声；60 分钟粒度虽然平滑，但会把早高峰的起止时刻磨平，导致 8:00 的拥堵被摊到整个 8:00-9:00 小时里，预测结果看起来“平均”却无处可用。

我一般默认从 15 分钟粒度开始试。这样做有三个理由：一是 96 个时段数足够体现一天内的峰谷起伏；二是它和交通管理中常见的信号配时周期能对上；三是样本量足够，一天有 96 个点，一个月就有接近 3000 个样本，喂给树模型不会太局促。判断粒度是否合适，可以看滞后一天的自相关系数：15 分钟粒度下，滞后 96（一天）的自相关应该明显高于滞后 95 和 97；如果三个值差得不明显，说明数据里混入的噪声偏大，可以考虑改到 30 分钟。

实际聚合时要留意时区问题。原始时间戳如果带时区，先统一转成北京时间再加偏移；如果不带时区且来源是本地采集设备，一般默认就是本地时间，但要在说明文档里写清楚口径，否则后期对比不同路段的流量曲线时会莫名多出一小时的偏移。

2.2 构造时间特征与滞后特征：把“时段感”喂给模型

聚合完成后，特征工程的核心是把时间含义转化成模型能读懂的数值。树模型虽然能处理非线性关系，但它不理解“8:00 和 17:00 都是高峰”这类常识，所以需要显式地构造出这些规律。

第一组是周期特征。hour 和 minute 要拆开，不要让 hour*60+minute 挤成一列模型自己摸索；dayofweek 用 0-6 表示周一到周日；is_workday 根据周一至周五判断，法定节假日需要额外标注。第二组是滞后特征，这是流量预测里最见效的一类。滞后 96 代表“前一天同一时刻”的流量，滞后 672 代表“上周同一时刻”的流量。对拥堵场景来说，上周同一天同一时段的流量往往比过去一小时的平均值更有参考价值，因为工作日早高峰的规律具有明显的周周期性。第三组是滚动特征，比如过去 12 个时段（3 小时）的流量均值和标准差，用来刻画“当前已经堵到什么程度”的惯性。

特征构造时有一条红线：不能用未来数据构造特征。滚动均值只能从过去往现在推，不能把中心时刻两侧的窗口都包进去，否则就会造成特征穿越，测试集上的指标会好看得不像话，一旦上线立刻翻车。

2.3 训练集和测试集必须按时间顺序切分

流量预测是时间序列任务，训练集和测试集不能像普通分类那样随机打散。随机切分会让模型在训练阶段“偷看”到测试时段前后的流量走势，评估结果严重虚高。正确的做法是选定一个日期分界点，分界点之前全部进训练集，之后全部进测试集。

我一般会按 8:2 的比例切分，但不用样本数去数，而是直接按日期切。比如数据覆盖 2024 年 1 月 1 日到 3 月 31 日，那就以 3 月 1 日为界，1-2 月训练，3 月测试。这样切的好处是保留了连续一周以上的测试窗口，能够完整看到一周内不同天类型的预测误差；代价是训练集和测试集各自覆盖的时间范围不完全相同，天气、突发事件等外部因素会有差异。想减少这种差异，可以把测试窗口放到国庆、春节等大节假日之后的一周，避免测试集里全是被节假日打乱的时段规律。

还需要留一小段验证集或者做时间序列交叉验证。常见做法是把训练集末尾的 10-14 天再切出来做验证集，用来调参；测完参数后，再用全量训练集训练最终模型，只在测试集上评估一次。测试集只准碰一次，这是铁律。

2.4 数据字段异常检测：缺失值、重复行和极端尖峰的处理

聚合之前先查异常。最常见的问题是重复行：同一秒内同一个断面出现多条记录。原因通常是两个采集设备的数据在合并时没有去重，或者车辆在断面附近停留被重复抓拍。去重逻辑要谨慎，不能简单全表去重，而是按“时间戳+断面ID”去重，先保留第一条记录再重新聚合，否则会把不同断面本来就该同时存在的多条过车记录误删。

缺失时段要用 np.nan 填充而不是直接填 0，意义差很多。某个 15 分钟窗口没有记录，可能是设备断线，也可能是真的没车。设备断线导致的缺失如果填 0，会让模型把“凌晨 3 点没车”和“晚高峰设备故障”混为一谈；先填 nan，再用前后时段均值插值，是更稳的处理方式。

极端尖峰也要单独处理。正常路段的 15 分钟流量在一天内有相对稳定的上下界，如果出现超过均值 5 倍以上的值，一般不是真实拥堵而是数据上报错乱。我会用滚动中位数加 3 倍滚动 MAD（中位数绝对偏差）作为判断线，超出的点先标记出来人工确认；确认是异常后剔除，用前后时段均值替换。注意不要用 3 倍标准差，因为流量分布本身右偏，标准差方法会误删很多真实的早高峰尖峰。

3. 流量预测模型的选型与评估：从基线模型到机器学习模型的阶梯

很多人在拿到数据后直接上 LSTM，理由是“时序问题就该用循环神经网络”。这个选择在论文里讲得通，但落地时通常得不偿失。流量预测的特征大多是时间派生特征，表格型数据结构下，梯度提升树往往用更少的时间达到更好的精度；深度学习只有在数据量非常大、序列依赖非常强的场景下才有明显优势。所以我的建模路线是先定基线，再上树模型，最后把深度学习作为对比项写进报告。

3.1 历史均值基线：没有模型时的最低标准

历史均值基线是一个不该被跳过的步骤。做法很简单：按“周几+时段”分组，计算历史流量的均值作为预测值。比如预测周一 8:15 的流量，就取过去所有周一 8:15 的流量均值。这个模型的 MAPE 通常能到 25%-35%，已经能反映基本的交通规律。

基线的作用有两个。第一，它是后续一切模型的合格线。新模型的指标如果连历史均值都打不过，说明特征工程或模型设计有问题，调参没有意义；第二，它是说明文档里“对照实验”的基础。毕设答辩时，评审老师大概率会问“你的模型比简单方法好多少”，没有这个对照，光说“MAPE 是 18%”缺乏说服力。

基线的坑在于它对特殊日期完全失灵。节假日、大型活动、恶劣天气这些场景，历史均值会被“平均”掉，预测结果温和但没用。这也正好说明，如果一个模型只在普通工作日做评估，永远测不出真实水平。

3.2 树模型是多数场景的最优选：LightGBM 的参数选择

处理好特征之后，梯度提升树是流量预测里效果最稳的选择。XGBoost 和 LightGBM 都能用，我倾向 LightGBM，原因是训练速度快、内存占用低，而且对缺省值有原生支持，流量数据里的 null 时段不需要额外处理。

LightGBM 的关键参数不需要一开始就追求最优。我的起步参数：n_estimators=1000，learning_rate=0.05，num_leaves=31，min_data_in_leaf=20，feature_fraction=0.8，bagging_fraction=0.8。这套参数在大多数路段数据上跑出来的结果已经能看。调参顺序有讲究：先固定 learning_rate，调 num_leaves 和 min_data_in_leaf 来抑制过拟合，再调 feature_fraction 和 bagging_fraction 增加随机性，最后调 n_estimators。

不需要做特征缩放，这是树模型的优势。流量数据里有的特征是 0-6 的星期，有的是 0-5000 的绝对流量，树模型做的是分裂阈值搜索，量纲不影响分裂逻辑。这一点也避免了归一化可能带来的数据泄露问题，后面避坑章再展开。

3.3 时序模型和深度学习的适用边界

Prophet 和 LSTM 各有明确的使用边界。Prophet 的优势在于自动处理趋势和年季节性，适合日粒度以上的宏观预测，比如预测下个月每天的断面流量；但放到 15 分钟粒度上，它对小时级尖峰的反应很迟钝，因为它的季节项是傅里叶拟合，高频细节会被平滑掉。LSTM 能捕捉序列依赖，但训练需要的数据量比树模型大得多。一个月的数据训练 LSTM，效果常常不如 LightGBM；数据量攒到半年以上，LSTM 才可能体现出序列建模的优势。而且 LSTM 对数据顺序极其敏感，训练前必须按时间排序，shuffle 会直接毁掉序列关系。

如果毕设时间有限，我建议主线用 LightGBM，把 Prophet 或 LSTM 作为对比模型写一节。报告里可以写清楚为什么在数据量有限时树模型更稳，这比强行堆一个 LSTM 并把测试指标写得很差要体面得多。

3.4 MAE、RMSE、MAPE：哪一个更能反映拥堵预测的好坏

评估指标的选择会直接影响模型调参方向。MAE 给出的是绝对误差，比如预测 1200 辆、实际 1100 辆，误差就是 100 辆，量纲直观，但看不出不同量级路段上的相对水平。RMSE 对误差做了平方，大的误差被放大，因此 RMSE 偏高的模型通常是在高峰期时段预测偏差大。对拥堵预测来说，这反而是需要的特性——平峰时段差几辆车没人关心，高峰时段差几百辆就会导致拥堵误判，所以 RMSE 比 MAE 更贴合业务目标。

MAPE 是百分比误差，便于跨路段对比，但它有个致命缺陷：当真实流量接近 0 时，MAPE 会趋近无穷大。凌晨两点的 15 分钟流量经常只有几辆车，一次 3 辆对 5 辆的预测误差就带来 40% 的 MAPE，把整体指标拉得很不好看。常见的解决办法是计算 MAPE 时过滤掉真实流量低于某个阈值（比如 20 辆/15 分钟）的时段，或者在报告里分别给出“全时段 MAPE”和“高峰时段 MAPE”，后者才是业务真正关心的数。

4. 用 Python 跑通车辆流量预测：数据划分、模型训练与验证代码

工具链的完整流程在代码层面有四个步骤：加载数据并可视化、构造特征与划分数据集、训练 LightGBM、评估结果。下面按步骤给出可直接运行的骨架代码，数据格式假设为包含 time、segment_id、count 三列的 CSV 文件，列名不同时改对应的字段名即可。

4.1 加载数据与可视化：先看清流量曲线的形态

拿到数据的第一步不要急着建模，先把全天流量曲线画出来，确认数据质量。以下代码读取原始过车记录并按 15 分钟重采样：

import pandas as pd import matplotlib.pyplot as plt # 读取原始过车数据，time 字段按时间列解析 df = pd.read_csv("flow_data.csv", parse_dates=["time"]) print(df.head()) print(df["count"].describe()) # 按时间排序并按15分钟重采样，求和得到每个时段的流量 df = df.sort_values("time") df = df.set_index("time") flow_15min = df["count"].resample("15min").sum() # 绘制某一天内96个时段的流量曲线 day = flow_15min.loc["2024-03-01"] plt.figure(figsize=(12, 4)) day.plot(marker=".") plt.title("2024-03-01 15min flow") plt.xlabel("time") plt.ylabel("vehicles / 15min") plt.tight_layout() plt.savefig("daily_flow.png", dpi=150)

这段代码先把 time 列解析成 Pandas 的 datetime 类型，然后按 15 分钟聚合。resample(“15min”) 是把高频过车记录变成 96 个时段点的核心操作；sum 表示该时段内总过车数，如果数据本身就是按时段聚合好的，就不需要再 resample，直接读进来即可。画出曲线后重点看两个地方：是否有明显的高峰双峰形态，以及是否存在突兀的尖峰或长段缺失。

4.2 构造特征矩阵与划分训练数据

特征构造按小时、星期、滞后值和滚动均值四个维度展开。下面代码生成训练用的特征矩阵，并按日期切分数据：

import numpy as np from datetime import time as dtime def make_features(series): df_feat = pd.DataFrame(index=series.index) df_feat["hour"] = series.index.hour df_feat["minute"] = series.index.minute df_feat["dayofweek"] = series.index.dayofweek # is_workday 只按周一到周五判断，节假日需要额外维护一个假期列表 df_feat["is_workday"] = series.index.dayofweek < 5 # 滞后特征：前一天同一时段，上周同一时段 df_feat["lag_96"] = series.shift(96) df_feat["lag_672"] = series.shift(672) # 滚动特征：过去3小时的均值和标准差 df_feat["rolling_mean_3h"] = series.shift(1).rolling(12).mean() df_feat["rolling_std_3h"] = series.shift(1).rolling(12).std() return df_feat flow_feat = make_features(flow_15min) flow_data = pd.concat([flow_feat, flow_15min.rename("target")], axis=1) flow_data = flow_data.dropna() # 以日期分界点切分，3月之前做训练，3月做测试 train = flow_data.loc[:"2024-02-29"] test = flow_data.loc["2024-03-01":] X_train = train.drop("target", axis=1) y_train = train["target"] X_test = test.drop("target", axis=1) y_test = test["target"] print(f"train: {X_train.shape}, test: {X_test.shape}")

shift(96) 取的是同一时间列向前移动 96 个 15 分钟的值，也就是前一天同一时段。滚动均值前先 shift(1) 是为了排除当前时段自身，避免用当前值预测当前值。dropna 会丢弃数据最初约 7 天没有滞后特征可用的样本，这个损耗在数据量充足时完全可以接受。

注意切分方式：这里没有用 train_test_split 的 random_state，而是用日期字符串切片。这是时间序列建模与普通机器学习最关键的区别。验证集此时还没有单独切出来，简单方案是把 train 最后的 14 天再切出来，先在这 14 天上调参。

4.3 LightGBM 训练流程与关键参数

训练 LightGBM 前先装依赖包，然后按 3.2 节的参数初始化模型，用早停控制迭代次数：

import lightgbm as lgb # 再切出一个验证集：训练集末尾14天作为调参依据 val = train.loc["2024-02-15":] train_main = train.loc[:"2024-02-14"] # 验证集用于早停，防止在训练集上过拟合 model = lgb.LGBMRegressor( n_estimators=1000, learning_rate=0.05, num_leaves=31, min_data_in_leaf=20, feature_fraction=0.8, bagging_fraction=0.8, random_state=42 ) model.fit( train_main.drop("target", axis=1), train_main["target"], eval_set=[(val.drop("target", axis=1), val["target"])], callbacks=[lgb.early_stopping(stopping_rounds=50)], ) # 早停得到的迭代次数就是最终模型应该用的轮数 best_iter = model.best_iteration_ print(f"best iteration: {best_iter}")

early_stopping 的作用是：如果验证集上的指标连续 50 轮不再提升就提前结束，同时记录最优迭代次数。这样不需要手动猜 n_estimators，训练代码也更稳。learning_rate 设 0.05 不是最快速率，但配合 1000 轮的预算能获得更平滑的收敛曲线；num_leaves 是树复杂度控制的核心参数，数值越大模型越复杂，数据量小时容易过拟合。

4.4 预测结果评估与叠加可视化

预测、计算指标和可视化放在一起完成。MAPE 按全时段与高峰时段分别算，避免凌晨低流量对指标的干扰：

from sklearn.metrics import mean_absolute_error, mean_squared_error # 使用最优迭代轮数重新预测 y_pred = model.predict(X_test, num_iteration=best_iter) mae = mean_absolute_error(y_test, y_pred) rmse = np.sqrt(mean_squared_error(y_test, y_pred)) # 过滤低流量时段，7:00-22:00 且真实流量大于20 mask_peak = (X_test.index.hour >= 7) & (X_test.index.hour < 22) & (y_test > 20) mape_peak = np.mean(np.abs((y_test[mask_peak] - y_pred[mask_peak]) / y_test[mask_peak])) * 100 print(f"MAE: {mae:.1f} 辆/15分钟") print(f"RMSE: {rmse:.1f} 辆/15分钟") print(f"高峰MAPE: {mape_peak:.1f}%") # 叠加画图：真实值与预测值对比，选连续3天展示 plot_range = slice("2024-03-04", "2024-03-06") plt.figure(figsize=(12, 4)) plt.plot(y_test[plot_range].index, y_test[plot_range].values, label="actual", marker=".") plt.plot(y_test[plot_range].index, y_pred[plot_range], label="predicted", marker=".") plt.legend() plt.tight_layout() plt.savefig("pred_vs_actual.png", dpi=150)

mask_peak 的作用是把评估聚焦到业务真正关心的时段。流量预测的 Moon MAPE（全体样本的百分比误差）通常很高，因为凌晨几辆车的误差就会带来巨大百分比；高峰 MAPE 才是衡量“拥堵预测准不准”的关键口径。画图时选连续三天展示，可以直观看到工作日与周末的预测差异，以及早晚高峰时段的贴合程度。

5. 时间序列预测避坑指南：数据泄露、日期解析与切分边界问题

流量预测的坑大多不在模型参数上，而在数据处理的不经意操作上。以下五条都是反复出现的真实问题，每条按现象、原因、解决给出，做毕设和做工程都适用。

5.1 数据泄露：归一化时用了全局的 min 和 max

现象：模型在测试集上 MAPE 只有 6%，看起来好得不真实；把时间范围往后延一个月重新测试，指标立刻掉到 20% 以上。

原因：在 LightGBM 流程里本来不需要归一化，但很多人习惯性地用了 sklearn 的 MinMaxScaler，而且是在切分前对全量数据 fit。这样 scaler 的 min 和 max 是从整个数据区间算出来的，包含测试集信息，模型在测试集上等于提前见过了数据范围。

解决：确定模型方案后，如果确实需要缩放（比如后续要切换到神经网络），必须遵循“先切分、后缩放”的顺序。在训练集上 fit，再把同一个 scaler 变换到测试集上。更省事的做法是树模型路线不做任何缩放，直接避免这一类问题。

5.2 时间顺序混乱：随机打散数据导致预测试着偷看未来

现象：代码里用了 train_test_split(X, y, test_size=0.2, random_state=42)，模型指标高得出奇，但把测试集换成未来一个月的真实数据后，预测效果完全不可用。

原因：train_test_split 默认是随机抽样，测试集里会混入训练集时间范围内的样本。对一个有时间依赖的序列来说，模型实际上是在用“未来一段时间”的相邻样本做插值，而不是预测未来。流量序列的自相关性极强，相邻 15 分钟时段的流量高度接近，随机打散后这类“伪邻居”让预测难度大幅降低。

解决：时间序列必须用时间顺序切分。代码里用日期切片来切分数据，如 train = data.loc[:“2024-01-31”]，test = data.loc[“2024-02-01”:]，禁止使用随机切分函数。

5.3 日期解析失败：时间列包含混合格式

现象：读取 CSV 时 dayofweek 或 hour 列全变成 NaN 报错，或者曲线图的横坐标出现错乱，某天的 8:00 显示在文件末尾。

原因：原始过车记录里 date 和 time 是分开的两列，一列是 2024-03-01，另一列是 08:15:23；或者部分行的时间写成了 3/1/2024 而不是 2024-03-01。Pandas 的 parse_dates 遇到混合格式会解析失败，把整列当成字符串。

解决：读取后先统一用 to_datetime 强制转换，并指定 format 参数；如果两列是分开的，先拼成一列再解析。检查解析结果是否包含 NaT，出现 NaT 就打印原始值确认格式。这一步做完确认 dtype 是 datetime64，再进入 resample 流程。

5.4 特征穿越：构造滞后特征时误用了未来数据

现象：模型指标比预期好很多，但滚动特征和滞后特征在分析时对不上号；把特征可视化后发现某个特征与目标值高度线性相关，相关系数接近 1。

原因：滚动特征计算时没有 shift(1)，rolling(12).mean() 把当前时段包含进去了。当前时段的流量是目标的组成部分，用它来预测它自己，本质上是把答案告诉模型。滞后特征 shift 方向搞反时也会出现相同问题，比如用了 shift(-96) 等于提前看了一天后的数据。

解决：构造特征时遵循“只用 t 时刻之前的数据预测 t 时刻”，滚动窗口前加 shift(1)，滞后值统一用正数 shift。写完后用一个简单检查：打印特征矩阵的最后几行，确认每一行特征对应的时间戳是目标时间戳之前。这个检查虽然在数据量大的时候比较枯燥，但能拦住大部分穿越问题。

5.5 训练验证重叠：滚动窗口时使用了重叠数据

现象：模型调参时验证集表现很好，但信心满满地部署到新一周数据后效果骤降，且误差集中在每周固定的一天。

原因：用滑动窗口交叉验证时窗口步长设置太小，训练集里包含了验证集的邻近时段；树模型学到的高自相关序列会让验证集误差虚低。另一种常见操作是提前把 target 滞后特征固定在某一天上，导致不同折的数据重叠。

解决：时间序列交叉验证要用 TimeSeriesSplit 或手动按不重叠的区块切分。例如训练窗口每次向后移动一周，验证窗口紧接其后且与前一个训练窗口不重叠。毕设项目中可以直接用固定日期切分法，一次训练、一次验证，避免复杂交叉验证带来的理解成本。

6. 进阶技巧：区间预测、多步预测与拥堵阈值告警

模型能输出一个预测均值只是第一步。真实场景里，决策者更关心的是“会不会堵、堵到什么程度”，这需要把点预测升级为区间预测，并用区间宽度辅助判断可信度。

LightGBM 原生支持分位数回归，代价非常小。训练时把 objective 设为 quantile，alpha=0.2 和 alpha=0.8，就能分别得到 20% 和 80% 分位的预测结果。两个分位预测之间的区间宽度反映模型对当前时段的不确定度。交通流量的不确定性有明显规律：早高峰起止时刻附近区间最宽，凌晨和午后区间最窄。有了区间之后，拥堵告警逻辑可以定义得更严谨：当 80% 分位预测值超过历史 95 分位流量时，发出“很可能拥堵”的预警；当均值超过阈值但 80% 分位未超过时，则标记为“存在拥堵风险”。第二种情况往往出现在特殊事件前，区间宽度大说明模型依据不足，这时人工排查比直接告警更合理。

多步预测是另一个常见需求。要预测未来 15 分钟，直接训练单步模型即可；要预测未来 2 小时，有两种路线。递归预测是把上一步的预测值作为特征输入下一步，实现简单但误差会随步数累积，流量尖峰时段尤其明显；直接多输出是训练一个模型同时输出未来 8 个时段（2 小时）的结果，损失函数对 8 个目标求平均，效果通常比递归稳定。我一般会先用直接多输出的方式，把预测范围限制在未来 4-8 个时段，避免输出维度太多导致模型容量不够。

这类项目收尾时建议把分位数模型和点预测模型分开保存，并给说明文档补一段参数记录：数据粒度、切分日期、特征清单、最佳迭代次数、高峰 MAPE 和阈值设定依据。文档的价值在几个月后重跑时才会体现，没有参数记录，重新训练很可能复现不出当初的指标。我个人的习惯是每次训练完在项目里建一个 baseline_metrics.txt，把历史均值基线和模型指标同时写进去，这样既不会被“自我感觉良好”误导，也方便答辩时直接展示对比过程。希望帮到你。

本文还有配套的精品资源，点击获取