简介：这是一份面向数据科学初学者的Kaggle共享单车需求预测赛题实践代码包，基于Python实现。作者结合Coursera《数据科学导论》课程作业，围绕天气、时间、温度、工作日等特征，探索了10种不同机器学习算法用于逐小时租借量预测。代码允许用户自由指定算法、训练变量，并选择在完整训练集上训练生成提交文件，或对数据进行子集训练与测试，便于对比模型效果。压缩包内共5个文件，包括1个Python脚本、2个CSV数据文件（训练集与测试集）及2个Markdown说明文档，整体仅180KB。项目紧凑完整，适合入门者理解回归任务、特征处理和模型选择流程，目前已有417人学习使用。 刚接触Kaggle那阵子，我第一个完整跟完的比赛就是Bike-Sharing Demand。这个比赛题面简单，数据量不大，但真正做进去才发现，它把特征工程、时间序列思维和回归模型全揉在了一起。很多人以为这就是个入门练手题，实际上稍不注意就会踩到数据泄漏和分布偏移的坑。如果你正在找第一个Kaggle项目练手，或者想搞明白回归类比赛的完整流程，这篇经验贴应该能帮你少走不少弯路。
1. 比赛机制与评估指标的隐藏陷阱
1.1 预测租赁需求背后的真实业务场景
这个比赛预测的是华盛顿特区共享单车系统每小时的租赁数量，数据包括日期、季节、天气、温度、湿度、风速等，目标就是算出租了多少辆车。乍一看是个标准的表格回归问题，但真正上手之后你会发现，数据本身是有时间顺序的，而且租赁需求和通勤时段、天气突变、节假日高度相关。这意味着你不能把它当成纯粹的静态表格来建模，得时刻带着时间序列的视角去观察特征。
我当时没有急着写第一版模型，而是花了整整一天去分析业务背景。共享单车系统的特点就是早晚高峰的潮汐效应特别明显，工作日和周末的使用模式完全不同，季节变化对骑行意愿影响极大。理解了这些，你就知道该从哪里做特征工程，而不是上来就把所有列扔给模型。
1.2 RMSLE指标对预测方向的偏科惩罚
比赛用的评估指标是RMSLE，一开始我觉得就是把目标值取对数之后算均方根误差，没啥特别的。但真正跑起来才发现，这个指标对低估的惩罚比对高估更重。换句话说，真实值100，你预测成90的损失比预测成110要大不少。对新手来说，这个方向很容易被忽略，导致模型在激进的调参下不断压低预测值，分数反而越来越差。
我后来做了一个小实验，手动把验证集上的预测值整体乘以0.9和1.1，测出来的RMSLE变化完全不对称。这让我意识到，必须对目标变量做log变换，或者直接在LightGBM里把目标设成log1p的形式，让模型在一个对数空间里做拟合。这个改动本身就能带来稳定的分数提升，属于那种“方向对了后面才走得通”的基础操作。
2. 特征工程里的金子与雷区
2.1 记住删除casual和registered这两列
训练集里有三个和人数相关的字段：casual、registered和count，其中count是前两者之和，也就是我们要预测的目标。问题在于，casual和registered这两个拆分字段只存在于训练集，测试集里完全没有。如果你图省事把它们当作特征喂给模型，训练时的交叉验证分数会漂亮得离谱，但一到真正提交就会被打回原形，因为测试的时候根本拿不到这些列。
这就是典型的数据泄漏。我在跑第一版的时候就发现了这个坑，果断删掉了这两列，只用训练集和测试集都有的公共特征。别心疼那点分数，安全合规地建模才是比赛的长久之道。后来看了一些公共notebook，发现有人专门用这两列做了一些“伪特征”去刷分，但在我看来那种方法没有实际意义，脱离了比赛数据的真实约束。
2.2 时间戳拆解：最划算的一笔投入
datetime字段看起来就是普通字符串，但把它解析成小时、星期、月份、年份之后，模型能学到的规律一下子就丰富了。我做了这些特征：小时、星期几、是否工作日、是否节假日、月份，还有“是否处于早晚高峰”的组合标记。其中周期编码特别关键，星期几如果用0-6的整数直接喂给模型，模型会误以为6和0之间差距最大，但实际上周六和周日都是休息日，模式相近。
我用的是sin和cos的周期变换，把小时和星期都做了编码，这样模型就能理解时间的循环特性。这一步做完，验证集上的RMSLE肉眼可见地降了一截，比后面调任何模型参数都有效。做时间序列类问题时，时间分解永远是投入产出比最高的一步，别嫌麻烦，把能想到的粒度全部拆出来，让模型自己学规律。
2.3 天气与风速特征的泛化处理
天气描述这个字段在训练集和测试集里的类别分布不完全一致，这是我后期才发现的坑。训练集里“轻度雾霾”出现的次数很多，但测试集里可能换成了一种从未出现的描述，导致我用的独热编码直接失效。解决办法是先把出现频率很低的类别合并成一个“其他”类别，再进行编码，避免模型在测试时面对一堆全零向量。
风速为0的情况一开始我也犹豫过，后来确认了原始数据里确实存在无风天气，这不是异常值，所以只做了缺失值填充，没有强行剔除。处理这类特征时，我的原则是“先统计分布，再决定是否合并”，不要凭感觉删特征，一定要结合业务可解释性来判断。
3. 模型选择与验证策略的落地决策
3.1 为什么我放弃了随机森林和XGBoost
我最初用随机森林跑基线，效果中规中矩，但训练速度在调参时明显拖后腿。后来换成XGBoost，精度上去了，可每次网格搜索的时间成本还是偏高。最后决定全部切到LightGBM，最主要的原因就是它在保持精度的前提下训练快，而且leaf-wise的生长方式在这个中等规模的数据集上很占优势。
选型本质上是个多维度的取舍，不是单看精度。我在比赛里更看重迭代速度和调试便利性，LightGBM很多超参数可以边跑边调，早停和交叉验证的组合也很成熟。如果你还在纠结模型选什么，我的建议是先用LightGBM跑通一个完整流程，等想清楚业务约束后再回头测试不同模型也不迟。
3.2 交叉验证的两种切法，我都试了
关于验证策略，网上最常见的做法是直接用K折交叉验证，把数据随机打乱成5份。这种做法的优点是可以充分利用数据，但对带时间顺序的问题来说，随机打乱会让模型潜在地“偷看”未来信息，验证分数可能会虚高。我一开始也这么做了，后来专门跑了一次按时间顺序切割的验证方法，也就是前80%的时间段作为训练，后20%作为验证。
对比下来，时间序列切分的分数比随机K折要差一些，但更接近真实测试时的表现。我最后选择的是折中方案：用多次随机K折得到最优参数，再用时间序列切分做一次稳定性和过拟合检查。这样既能利用交叉验证调参，又能避免模型对时间分布过于乐观。
3.3 LightGBM关键参数的经验值
分享一组我调得比较顺的参数，不是绝对最优，但适合作为起点：
learning_rate：0.05，配早停轮数50num_leaves：31，先稳定再往大试feature_fraction：0.8，增加特征随机性bagging_fraction：0.8，配合bagging_freq=1lambda_l2：1.0，控制过拟合max_depth：-1，交给leaf-wise自己决定
每次调参只动一个参数，记录验证集分数变化，这样你才能理解每个参数的实际影响。我一开始习惯同时改好几个参数，后来发现根本分不清是谁起的作用，完全是浪费时间。
4. 测试集分布偏移的排查全过程
4.1 公开榜分数不升反降的根因分析
比赛进行到最后一周，我加了一个“天气描述”的独热编码，本地验证集分数小涨了一点，心里还挺高兴。结果提交到公开榜之后，分数反而下降了，这让我立刻意识到本地验证和线上测试之间出现了偏差。我停下手头所有调参工作，开始认真排查特征的分布情况。
统计之后发现，天气描述这个字段在测试集里有若干种类别从来没在训练集出现过。独热编码遇到这种新类别时，会把它变成全零向量，模型学到的对应权重就白费了。解决办法是提前合并低频类别，比如把所有出现次数小于5的天气描述全部归到“其他”这个类别，再重新做编码。调整之后，公开榜分数恢复到了本地验证的预期范围。
4.2 时间趋势的偏移与交叉特征补救
除了类别缺失，我还发现测试集的月份分布和训练集并不完全相同，训练集覆盖了大概两年的数据，测试集是后续的几个月，趋势和季节性肯定有差异。为了应对这种偏移，我构造了“小时+月份”和“星期+是否工作日”的交叉特征，让模型对不同时间片段的组合更敏感，而不是死记某一年某个时段的具体数值。
这个动作虽然没有大幅提升RMSLE，但明显提升了结果稳定性。我后来总结了一下，处理时间序列类的赛题，一定要在做特征工程的时候就问自己两个问题：这个特征在测试集上会不会出现不同的取值分布？如果出现了，模型会如何应对？把这两个问题想清楚，能省下不少后期debug的时间。
4.3 后处理阶段把预测值拉回合理区间
模型输出的预测值理论上应该大于等于0，但实际跑分会时不时出现负值，尤其在光照不足的冬季时段。我得在提交前把负值强制替换为0，同时对极端高的预测做了轻微截断，避免个别预测值拉低RMSLE。
这里有一个小技巧：如果你使用了log1p变换，那提交时一定要记得做expm1还原，这一步漏掉的话预测结果会完全错乱。我就见过不少人因为忘记做逆变换，分数直接起飞，找半天找不到原因。
5. 复盘后的方案沉淀与实用资源思路
5.1 我的最终方案与分数水平
最后提交的方案是：LightGBM + 时间分解特征 + 类别合并 + log目标变换，使用5折交叉验证调参，最后用全量数据重新训练并预测。RMSLE稳定在大约0.42附近。这个分数在大佬云集的榜单上其实很普通，但我自己复盘之后觉得，整个流程跑下来收获最大的不是名次，而是对数据泄漏、特征工程和验证策略的完整认知。
我给自己列了一个项目清单，方便之后做类似比赛时快速对齐思路：
- 删掉目标变量的拆分字段，防止数据泄漏
- 日期字段做周期编码和时间分解
- 低频类别合并后再独热
- 目标变量取log，模型在log空间里训练
- 用随机K折调参，用时间序列切分做稳定性检查
5.2 给新手的三条避坑建议
第一，拿到数据别急着建模，先做缺失值和分布统计，尤其是每个特征的类别数量和取值范围。第二，验证策略决定了你调参的方向，别只看一个指标就盲目优化，多试试不同策略得到的结果差异。第三，提交前检查特征在训练集和测试集中是否都存在，尤其是独热编码后的维度是否一致，这个小检查能替你挡掉很多无谓的分数波动。
最后再分享一个我后来每次做项目都会用的习惯：维护一份“特征可用性清单”，把每个特征的来源、变换方式、在训练集和测试集上的状态都记录下来。实测能省下大量重复排查的时间，尤其是当你同时尝试多套方案的时候，这个清单的价值会体现得特别明显。做数据科学项目，最怕的不是模型效果差，而是你根本不知道自己用了哪些特征、在哪个环节出错了。
本文还有配套的精品资源，点击获取
