简介Kaggle平台泰坦尼克号生存预测是数据科学入门的经典项目这份资料将常用数据集与带详细注释的Python源代码打包在一起适合正在学习机器学习、希望从零完成一次完整建模流程的初学者也可供中级数据分析师快速复现基线方案。压缩包仅40KB共6个文件其中4个csv文件涵盖训练集、测试集及预处理后的特征表2个py脚本分别演示数据清洗、特征工程、模型训练与结果提交的完整链路代码注释对每步操作和参数选择都做了说明。目前已有1361人学习过该资料可作为Kaggle竞赛入门或课程大作业的参考实现。通过阅读和运行源码不但能掌握Pandas处理缺失值、编码分类变量等预处理技巧还能了解逻辑回归、随机森林等模型在真实数据上的应用以及如何利用交叉验证和网格搜索优化超参数最终形成一份可复现的泰坦尼克号解决方案。1. 泰坦尼克号不是入门题为什么这个1912年的沉船数据至今还在被反复训练Kaggle平台的泰坦尼克号数据集是下载次数最多的入门竞赛数据之一891条训练记录418条测试记录任务是根据舱位、年龄、性别等字段预测乘客是否生还。表面上是道简单的表格分类题实际上特别适合练“源代码注释”的功夫——答案遍地都是难点从来不是抄代码而是弄清每行特征工程为什么存在、每个参数为什么叫这个名字。这篇笔记写给两类人第一次接触Kaggle竞赛、想借这个数据集把“跑通”变成“读懂”的新手以及已经跑过脚本、但遇到数据泄漏、提交报错、分数复现不了的老手。下面按我拿到带注释源码时的阅读顺序把读数据、特征工程、建模、提交和排错串成一条完整路径。2. 先看懂赛题和数据字段注释、评价指标与代码阅读顺序2.1 Kaggle泰坦尼克号竞赛到底在预测什么从字段注释反向理解数据Kaggle竞赛官网对泰坦尼克号的描述很简短让参赛者根据乘客的个人信息预测在沉船事故中是否生还。但真正有价值的信息藏在字段注释里。train.csv的每一列都是一条线索注释写得准不准决定了后续特征工程的方向对不对。常见字段注释如下表字段含义缺失情况处理方向PassengerId乘客编号无缺失只做索引不进特征Survived是否生还1/0无缺失仅train标签列Pclass舱位等级1/2/3无缺失类别特征有序Name姓名无缺失提取Title等新特征Sex性别无缺失二值类别Age年龄train约177条缺失填充后作为连续特征SibSp同船兄弟姐妹/配偶数无缺失组合成FamilySizeParch同船父母/子女数无缺失组合成FamilySizeTicket票号无缺失高基数一般不直接用Fare票价test约1条缺失填充后连续特征Cabin客舱号约77%缺失拆首字母或标缺失Embarked登船港口train约2条缺失众数填充这里我要强调一个容易忽略的细节字段注释里SibSp的官方定义是“同船的兄弟姐妹或配偶数量”Parch是“同船的父母或子女数量”而不是字面上的“兄妹”和“父母”。网上许多版本的源代码把这两个字段的注释写反了或写窄了照着错误注释做特征工程FamilySize算出来的数就会偏。拿到数据先动手核对字段注释比急着打开源码更有用。为什么这个数据集只有891条训练样本还值得反复用因为它的字段设计非常接近真实业务里的“脏表格”有缺失、有高基数文本、有类别不平衡、有看似无用实则关键的文本列。在Kaggle平台上很多入门竞赛的数据都是规整过的泰坦尼克号是少数需要你自己决定“哪些列扔掉、哪些列拆开”的赛题这一点比样本量更有教学价值。2.2 评价指标为什么用accuracy二分类均衡性与提交门槛泰坦尼克号竞赛官方采用的评价指标是accuracy也就是预测正确的样本占全部样本的比例。很多新手会问为什么不用AUC、F1或者LogLoss原因有两点。第一这个任务的类别相对均衡。train.csv里生还者约342人遇难者约549人生还比例约38%不是那种99%对1%的极端不平衡场景accuracy不会被“全预测为多数类”的作弊解法推得很高。第二竞赛官方对提交格式做了硬性限制提交文件只需要PassengerId和Survived两列Survived只能是0或1不能用概率代替。这意味着你无法用输出连续概率再排名的方式参与Public Leaderboard排行模型输出的阈值处理必须在本地验证集上提前解决。这也解释了为什么带注释的参赛源代码普遍会把验证策略写在注释里用train.csv切出验证集在验证集上算accuracy再拿验证集上表现最好的模型去预测test.csv。注释如果只写了“准确率0.82”却没写用的哪个随机种子、哪次切分这个数字基本不具备复现价值。另外要提醒一句Public Leaderboard只用了test.csv的一部分做评分所以CV分数和LB分数本来就会有差异那些只在Public上好看、Private上翻车的源码多半是过拟合了Public榜单的噪声。靠本地验证集反馈别靠反复提交试错。还有一个容易被忽略的门槛Titanic的每日提交次数有限。早期参赛者靠反复提交试错现在这个路子行不通平台会限制提交次数逼着你把本地验证做扎实。这其实是一件好事——训练集就是你的考场验证集切分策略直接决定你能否正确估计真实效果。2.3 拿到“源代码注释”版本后先按这个顺序读代码我见过很多新手拿到一份带注释的泰坦尼克号源码第一件事是从第一行顺着一行行读读到第200行已经忘了开头在做什么。常见做法是先跑通再逆着读。具体顺序是先跑一遍拿到submission.csv确认环境没问题然后从入口函数往回找特征工程函数最后再读训练和预测部分。读取数据的代码是所有步骤的起点import pandas as pd train pd.read_csv(train.csv) test pd.read_csv(test.csv) print(train.shape) # (891, 12)训练集规模 print(test.shape) # (418, 11)测试集没有Survived列 print(train.info()) # 查看每列的非空数量与数据类型 print(train.head()) # 确认字段注释里的名字和实际列名一致这段代码背后的逻辑是先确认行数和列数再确认缺失情况。train.info()输出里Age、Cabin、Embarked的non-null count会明显小于891这比人工翻Excel判断缺失快得多。train.head()则是用来核对字段注释的比如有的源码把Cabin解释成“客舱编号”但实际数据里Cabin大量是NaN这时你就要意识到这个字段不能直接当成普通类别来用。参数说明read_csv的默认分隔符是逗号泰坦尼克号数据集不需要额外指定sep如果文件放在子目录把路径写成data/train.csv避免用绝对路径否则换一台机器就要改代码。train.info()里能看到每个字段的dtypeobject类型的字段后续要做编码处理float64类型可以直接进模型。读代码时还有个习惯值得养成把注释当成“为什么”来读而不是“是什么”。比如一行train[Age] train[Age].fillna(train[Age].median())如果注释只写“填充年龄缺失值”那是废话如果写“用中位数填充是因为年龄分布右偏均值会被高龄乘客拉高”这才是有价值的注释。你自己写代码时也按这个标准写注释后面第五、六章的排错会省很多时间。有团队会用注释率来评估代码可维护性但泰坦尼克号这种教学场景里注释质量比注释数量重要得多一段解释“为什么”的注释顶过十行描述“是什么”的注释。如果你拿到的是ipynb格式的Notebook单元格执行顺序比代码本身更容易出错。常见做法是先把Kernel重启后再Run All确认整本Notebook能从头跑到尾再动手读。一个藏了隐藏状态变量的Notebook某些单元格单独执行能通过整本跑却报错就是因为前面的单元格并没有真正执行过。3. 特征工程是这场竞赛的真正考点从原始字段到能进模型的数值特征3.1 缺失值处理Age、Embarked、Cabin三个字段的三种策略泰坦尼克号数据集的缺失值集中在Age、Cabin、Embarked三个字段。很多新手的第一个错误是直接dropna一行代码删掉所有含缺失值的行891行瞬间少掉两百多行信息损失太大。另一个常见做法是统一用0填充这个对Cabin勉强可用对Age和Fare会严重扭曲分布。常见做法是分字段处理。Age的缺失比例大约在20%用中位数填充比用均值稳定因为年龄分布右偏少数高龄乘客会把均值拉高。但要注意一个原则test.csv的填充统计量必须来自train.csv不能在test上单独算。原因很简单test是你假装看不到的未来数据用test的中位数填充本质上是把test的信息泄漏到了训练流程里。age_median_train train[Age].median() train[Age] train[Age].fillna(age_median_train) test[Age] test[Age].fillna(age_median_train) # 用train的统计量 embarked_mode_train train[Embarked].mode()[0] train[Embarked] train[Embarked].fillna(embarked_mode_train) test[Embarked] test[Embarked].fillna(embarked_mode_train) train[CabinMissing] train[Cabin].isna().astype(int) test[CabinMissing] test[Cabin].isna().astype(int) train[CabinLetter] train[Cabin].str[0].fillna(Unknown) test[CabinLetter] test[Cabin].str[0].fillna(Unknown)这段代码里有两个参数细节。train[Age].median()返回的是标量不是Series所以fillna可以直接用不会触发索引对齐问题。Embarked的mode()[0]取第一个众数是因为train里缺失的恰好两条样本都是最频繁出现的港口用众数填充是误差最小的做法。Cabin的处理则是把“是否缺失”本身当成特征因为泰坦尼克号上Cabin为空往往意味着乘客住在低等舱或行李区这个缺失信息本身就有预测力。CabinLetter提取首字母后常见做法是再看一眼分布如果某个字母类别太少就归并成Other。这部分需要根据实际输出决定不是所有源码都会写清楚所以注释里最好记录当时的分布情况方便下次复现。注意如果你要在多个模型间比较这类“看一眼再归并”的操作要固定下来否则每次结果都不一样。注意所有填充统计量只从train.csv计算test.csv只能用同一个值填充不能用test自身统计否则会造成信息泄漏。3.2 从Name里提取Title一个字段注释最多的特征工程技巧Name字段看起来是最没用的文本列但它包含了Title称谓比如Mr、Mrs、Miss、Master、Dr、Rev。Title和年龄、社会阶层高度相关Master通常是未成年男孩Miss和Mrs区分已婚未婚女性这在沉船生还概率上有显著差异。这是泰坦尼克号竞赛里性价比最高的一个特征几乎所有高分方案都会做。train[Title] train[Name].str.extract(r ([A-Za-z])\., expandFalse) test[Title] test[Name].str.extract(r ([A-Za-z])\., expandFalse) title_mapping { Mr: Mr, Mrs: Mrs, Miss: Miss, Master: Master, Dr: Rare, Rev: Rare, Col: Rare, Major: Rare, Countess: Rare, Don: Rare, Jonkheer: Rare, Lady: Rare, Capt: Rare, Sir: Rare } train[Title] train[Title].map(title_mapping).fillna(Rare) test[Title] test[Title].map(title_mapping).fillna(Rare)正则表达式r ([A-Za-z])\.匹配的是“空格连续英文字母句点”。Name里的呈现形式是“Braund, Mr. Owen Harris”所以正则能把Mr捕获出来。expandFalse让str.extract返回Series而不是DataFrame后面可以直接赋值给新列。title_mapping的映射逻辑是保留四个常见Title其余归入Rare。这里有个容易踩坑的地方test.csv里出现的Title集合可能和train.csv不完全相同。比如train里没有Donatest里却有如果直接用train的类别做编码Dona就会被sklearn判定为“unseen label”导致报错或者被OneHotEncoder静默忽略。上面的代码用map加fillna(Rare)兜底就是为了应对这个情况。这是一个典型的“训练集和测试集分布不一致”问题泰坦尼克号数据集的坑不在量大而在这种细节。3.3 家庭大小与是否独自一人构造组合特征的思路SibSp和Parch两个字段单独看预测力都不强但把它们组合成FamilySize后含义就清晰了家庭规模直接影响逃生时的互助概率。另一个常见的组合特征是IsAlone独自一人的乘客在恐慌环境里更难获得帮助这个特征在很多方案里能单独带来一到两个百分点的准确率提升。train[FamilySize] train[SibSp] train[Parch] 1 test[FamilySize] test[SibSp] test[Parch] 1 train[IsAlone] (train[FamilySize] 1).astype(int) test[IsAlone] (test[FamilySize] 1).astype(int)加1是因为要把乘客本人算进家庭规模。FamilySize等于1意味着船上没有同行的亲属IsAlone就是1否则是0。这两行代码本身没有复杂度真正需要注意的是特征工程的顺序先基于原始字段构造组合特征再做编码最后统一进模型。如果你先把SibSp和Parch分别做OneHotEncoding再组合FamilySize会得到一组冗余的高维稀疏特征模型训练变慢且容易过拟合。构造完新特征后原始字段的去留也有讲究。Sex、Pclass、Fare、Age、Title、FamilySize、IsAlone、Embarked、CabinLetter、CabinMissing是常见的最终特征集合。SibSp和Parch经过组合后可以从特征列表里移除Ticket字段因为基数太高每张票号基本唯一通常直接丢弃Name字段也只在提取Title时用一次之后不再进模型。3.4 编码与标准化类别特征进模型前的最后一公里模型不能直接吃字符串Sex、Title、Embarked、CabinLetter都要变成数值。常见做法是OneHotEncoder。逻辑回归对数值尺度敏感Fare和Age最好做标准化树模型对尺度不敏感但类别编码仍然要做。下面用ColumnTransformer把两类处理放在一个对象里方便后续放进Pipeline统一管理。from sklearn.preprocessing import OneHotEncoder, StandardScaler from sklearn.compose import ColumnTransformer feature_cols [Pclass, Sex, Age, Fare, Title, FamilySize, IsAlone, Embarked, CabinLetter, CabinMissing] cat_cols [Sex, Title, Embarked, CabinLetter] num_cols [Pclass, Age, Fare, FamilySize, IsAlone, CabinMissing] preprocessor ColumnTransformer([ (cat, OneHotEncoder(handle_unknownignore), cat_cols), (num, StandardScaler(), num_cols) ]) y_train train[Survived]这里有两个关键参数。OneHotEncoder的handle_unknownignore是关键中的关键test里出现train没见过的类别时它会把这一列全部编码为0而不是抛异常。StandardScaler先fit在train上再transform test用train的均值方差标准化test这是标准做法避免test信息反向影响训练。Pclass放进num_cols其实是把有序类别当连续值用实践上可以如果追求严谨可以把它挪到cat_cols里做OneHot代价是多两列稀疏特征模型效果差别不大。第4章会把preprocessor和模型包进Pipeline所以这里不提前执行fit_transform那些操作会由Pipeline在每一折交叉验证内部自动完成。4. 建模与调参用带注释的源代码跑通训练、验证与提交4.1 基线模型选择为什么先跑LogisticRegression而不是直接上XGBoost泰坦尼克号数据集只有891条训练样本特征维度撑死几十个。这种小数据集上XGBoost、LightGBM这类梯度提升树很容易过拟合而且调参空间大新手很难判断分数变化到底来自参数还是来自特征。常见做法是先跑一个LogisticRegression作为基线因为它的输出稳定、可解释性强还能用来验证特征工程是否有问题——如果逻辑回归的交叉验证分数在0.78以下说明特征构造方向大概率有问题此时换更强的模型只是把问题藏起来。有了3.4的preprocessor训练代码可以写得很干净。用Pipeline把预处理和模型串起来交叉验证时preprocessor会在每一折内部重新fit编码器和标准化器都不会看到验证折的数据。from sklearn.linear_model import LogisticRegression from sklearn.pipeline import Pipeline from sklearn.model_selection import cross_val_score model_pipe Pipeline([ (preprocessor, preprocessor), (clf, LogisticRegression(max_iter500, random_state42)) ]) scores cross_val_score(model_pipe, train[feature_cols], y_train, cv5, scoringaccuracy) print(scores.mean(), scores.std())max_iter500是为了保证逻辑回归能收敛sklearn默认max_iter是100当特征数变多或C值较小时偶尔会触发ConvergenceWarning。random_state42固定随机种子让每次交叉验证的切分结果一致。cv5表示五折交叉验证scores.mean()给出平均准确率scores.std()看折间波动标准差超过0.02说明特征或数据切分不稳定需要回头检查。交叉验证在这里的作用是模拟多次“训练-验证”避免单次train_test_split的偶然性。网上那些标注了“Public LB 0.79”的源码注释里基本都会写明cv分数和LB分数两个数字两者差太多就说明模型过拟合了train.csv的特定分布。4.2 交叉验证与超参数设置随机种子、正则化强度与早停基线模型跑通后下一步是调参。逻辑回归最值得调的参数是正则化强度CC越小正则化越强模型越保守C越大越倾向于拟合训练数据。用GridSearchCV做网格搜索时因为模型被包在Pipeline里参数名要写成clf__C这种带双下划线的形式。from sklearn.model_selection import GridSearchCV param_grid { clf__C: [0.01, 0.1, 1, 10], clf__penalty: [l2] } grid GridSearchCV( model_pipe, param_grid, cv5, scoringaccuracy ) grid.fit(train[feature_cols], y_train) print(grid.best_params_) print(grid.best_score_) # 把结果记在注释里例如 # C0.1, cv0.813, LB0.784penalty只试l2因为l1在特征少的时候意义不大而且l1会触发不同的求解器路径增加不必要的变量。random_state42在GridSearchCV内部也会传给每一次拟合保证不同C值之间只在正则化强度上有差异。best_score_是网格搜索内部交叉验证的最好分数这个数字可以和后续的树模型对比。这里必须说清楚Pipeline的一个好处preprocessor在每一折内重新fit避免编码器在交叉验证开始前就看过全部train数据。但要注意3.1里的Age填充还在Pipeline外面这是很多老代码的折中做法更严格的方案是把SimpleImputer放进Pipeline代价是代码变复杂。泰坦尼克号这个量级填充统计量泄漏的影响很小但你要知道这个偏差存在注释里最好写明“Age填充在Pipeline外完成”。如果你决定换随机森林或XGBoost随机种子同样要固定。随机森林的n_estimators从100开始调max_depth从3开始试先不要动min_samples_split。XGBoost则要注意early_stopping_rounds直接在训练集上拟合而不做早停在小数据集上几乎必然过拟合。泰坦尼克号这类数据树模型的提升空间有限重点仍然是验证特征而不是盲目堆模型复杂度。4.3 生成submission.csv提交格式、索引对齐与概率阈值模型训练完成最后一步是预测test.csv并生成提交文件。这一步的坑集中在索引对齐上。test.csv的PassengerId是418个不连续编号如果你在特征工程过程中做过dropna或reset_index预测结果的顺序可能和原始文件对不上。常见做法是提交前用断言检查长度、ID集合和标签取值。test_pred grid.best_estimator_.predict(test[feature_cols]) submission pd.DataFrame({ PassengerId: test[PassengerId], Survived: test_pred }) assert submission.shape[0] test.shape[0] assert set(submission[PassengerId]) set(test[PassengerId]) assert submission[Survived].isin([0, 1]).all() submission.to_csv(submission.csv, indexFalse)grid.best_estimator_是完整Pipelinepredict直接吃原始test[feature_cols]不需要手动调用preprocessor.transform这一步能帮你挡掉大量预处理不一致的坑。三个assert的作用是把“我以为对了”变成“程序确认对了”第一个检查行数第二个检查ID集合第三个检查标签取值只能是0或1。to_csv的indexFalse必须加如果不加提交文件里会多出一列Unnamed: 0Kaggle官方提交解析器会直接报错。关于概率阈值默认情况下predict用的阈值是0.5。但如果你发现验证集上生还者的预测概率普遍集中在0.4到0.6之间可以考虑在验证集上遍历阈值找一个让accuracy最大的值再用这个阈值从predict_proba的输出生成0/1标签。这类阈值调整效果通常很有限而且有在小验证集上过拟合的风险新手阶段不建议优先做。Kaggle对每日提交次数有限制不能把线上反馈当调试工具。常见做法是本地先用交叉验证确定模型再统一提交一次。每一版代码在注释里记录CV分数、特征列表和随机种子这样提交后无论Public分数高低都能回到本地复现。5. 泰坦尼克号避坑指南数据泄漏、索引错位与提交翻车的5个排查点这一章集中写泰坦尼克号源代码复现里最容易翻车的5个排查点。这几个坑看起来有点玄学其实都能在数据流里找到明确原因按“现象→原因→解决”的顺序记录方便你遇到时直接对照。5.1 现象交叉验证分数很高但Kaggle Public Leaderboard分数很低原因数据泄漏。最常见的一种是填充缺失值时用全量train计算统计量然后再做交叉验证。比如3.1里如果你先用train[Age].median()填充整个train再交给cross_val_score每一折验证集里有一部分样本的年龄其实来自训练折的统计量模型“见过”了验证集的信息CV分数虚高。另一种泄漏是把test.csv的信息在特征工程阶段混进来比如用test的Fare均值填充train的Fare缺失。解决把填充操作放进交叉验证的Pipeline里使用SimpleImputer替换手动fillna或者至少保证填充统计量只来自当前训练折。我用的最稳妥做法是写一个fill_age_with_fold(train_fold, val_fold)函数在每个fold内部重新计算中位数代码量多几行但CV分数诚实得多。还有一个更隐蔽的泄漏是把PassengerId当特征它看起来像纯编号但ID和乘客登船顺序相关模型能从中学到不该学的模式。另一个让CV和LB差距大的原因是折间波动大。cross_val_score默认对分类任务使用StratifiedKFold但如果你手动用了普通KFold某些折里生还样本比例会严重偏离整体891条样本量下分数浮动接近两个百分点是正常的。解决显式使用StratifiedKFold(n_splits5, shuffleTrue, random_state42)保证每折类别比例一致。5.2 现象预测结果全是0或者全是1原因三类。第一y_train传错了比如把PassengerId当成了标签模型拟合了和生死无关的编号。第二特征矩阵里混入了Survived列导致模型“作弊”学到一个完美特征但test里没有这一列预测时就退化成预测多数类。第三类别严重不均衡时模型为了最大化accuracy选择全部预测多数类但这在泰坦尼克号里不太可能因为生还比例不算极端。解决先打印标签分布和预测分布确认问题在哪一层import numpy as np print(train[Survived].value_counts(normalizeTrue)) # 标签分布 print(np.unique(test_pred, return_countsTrue)) # 预测分布 print(feature_cols) # 检查特征列表value_counts(normalizeTrue)看的是生还和遇难的比例np.unique直接数预测结果里的0和1。如果feature_cols里意外包含Survived或PassengerId立刻删掉。还有一个笨但有效的办法把特征工程函数的输出打印出来和原始数据逐列对比看有没有某列变成常数。比如CabinLetter全部被fillna(Unknown)对模型来说这列就等于没有提供任何区分度。5.3 现象提交后报错Expected 418 rows but got ... rows原因test.csv经过特征工程后行数变了。最常见的元凶是dropna()新手在test上执行test test.dropna()之后418行变成三百多行最终提交文件行数对不上。另一个常见原因是索引没有重置导致合并时产生错位虽然行数没变但PassengerId对错了人。解决在整套特征工程里约定“绝对不对test做dropna”。Age、Fare、Embarked全部用填充而不是删行。我在特征工程函数最后会放一行断言行数不对马上崩不让错误流到提交阶段assert len(test) 418, ftest rows changed: {len(test)}还有一个习惯值得养成每次对test做操作后立刻test test.reset_index(dropTrue).copy()。pandas里很多操作会打乱索引比如sort_values、dropna、布尔筛选如果不重置索引后续pd.concat或按位置赋值会按旧索引对齐产生看似正常实则错位的数据。5.4 现象注释里的字段和实际数据对不上原因网上流传的泰坦尼克号源码版本很多有的把Embarked注释成“登船地点”有的写成“港口编号”但train.csv里这一列的值是S、C、Q三个字母。如果注释说“港口编号”你会下意识去做数值编码把S当成0、C当成1、Q当成2这会让树模型产生错误的顺序关系。另一个经典错误是把Parch注释成“父母数量”实际官方定义是“同船的父母或子女数量”两者范围不一样。解决拿到代码后第一件事是用train.columns.tolist()和train.head()核对字段注释。注释和实际数据不一致时以实际数据为准并在自己的代码里把修正后的注释写清楚。写字段注释时最好带上取值样例比如“Embarked登船港口取值S/C/Q三个字母”这样下次回看或者交给别人时不会产生歧义。这也解释了为什么会有人在GitLab仓库里统计注释率把代码量和注释长度当成可维护性指标——但那个统计只能衡量数量衡量不了质量。注释和代码行为不一致的注释比没有注释更有害。我自己的标准是字段注释必须能在不打开数据的情况下描述清楚取值范围和业务含义。5.5 现象注册Kaggle账号时验证码无法显示下载数据集总是中断原因这类问题大多出在本地环境而不是Kaggle平台。浏览器缓存了旧页面资源、Cookie里混入了异常会话、系统时间不准确导致验证码服务校验失败、或者浏览器插件拦截了验证码脚本都是常见诱因。页面提示captcha must be filled out时通常意味着验证码组件根本没有成功加载出来。解决先换一个无痕窗口重新打开注册页绕开缓存和Cookie干扰再检查系统时间是否与当前时间一致时间偏差过大会导致验证码接口返回异常第三步是把浏览器语言切换成英语刷新页面个别验证码组件对非英文页面支持不好。如果这些都没用就换Chrome或Edge的默认配置停用广告拦截相关扩展后重试。注册完成后记得去注册邮箱确认验证邮件有时它会被误拦进垃圾箱点开确认链接账号才算激活。下载数据集时如果网页端经常中断常见做法是安装Kaggle官方CLI工具在终端里用kaggle competitions download -c titanic拉取下载过程比网页端稳定得多断线后重新执行会继续拉取。数据下载完成后把压缩包解压到固定目录train.csv和test.csv各就各位整套流程就和网页端没有关系了。6. 从跑通到上榜用特征重要性验证你的特征工程是否真的有效6.1 用Permutation Importance验证特征边际贡献跑通提交只是起点。要判断“源代码注释”这个方向值不值得继续投入最有效的方法是做一次特征重要性验证。Permutation Importance的思路是把某个特征在验证集上随机打乱观察模型accuracy掉多少。掉得多说明这个特征贡献大掉得少甚至上升说明这个特征可能是噪声。为了做这个验证我习惯单独切一个验证集避免特征重要性分数混入训练集的乐观偏差from sklearn.model_selection import train_test_split from sklearn.inspection import permutation_importance X_train_final, X_val, y_train_final, y_val train_test_split( train[feature_cols], y_train, test_size0.2, random_state42 ) best_model grid.best_estimator_ best_model.fit(X_train_final, y_train_final) result permutation_importance( best_model, X_val, y_val, n_repeats10, random_state42 ) for name, score in zip(feature_cols, result.importances_mean): print(f{name}: {score:.4f})n_repeats10表示每个特征打乱10次取平均降低随机性带来的波动。如果Sex、Title、Pclass排在前面Age和Fare排在中间Embarked和CabinLetter排在最后说明特征工程方向是对的。FamilySize和IsAlone如果排在倒数说明组合特征没有提供增量信息可以考虑去掉简化模型。6.2 用学习曲线判断当前是欠拟合还是过拟合另一个值得做的验证是学习曲线。用小规模训练子集观察模型分数随数据量增加的变化训练分数高但验证分数低是过拟合两条曲线都低是欠拟合。泰坦尼克号这个数据量学习曲线更多是用来判断特征工程是否榨干了数据信息而不是用来精调模型。6.3 提交前最后检查清单我在提交前会按顺序过一遍特征工程函数输出行数与训练测试集一致填充统计量全部来自trainfeature_cols里不含Survived和PassengerId随机种子固定并在注释里记录submission.csv只有两列且没有多余索引列本地CV分数和预期相符。说一件我自己的教训我最早的一份泰坦尼克号代码在注释里写了“Cabin缺失值用U填充”但代码里实际写的是fillna(0)注释和实现不一致。两周后我自己回看时被误导又在Cabin上做了一轮无谓的处理。从那以后我要求自己的注释必须能通过“把注释当代码读”的检验——如果注释描述的步骤没法照着还原成代码这行注释就是负债而不是资产。好的源代码注释是给未来的自己留的后悔药希望帮到你。本文还有配套的精品资源点击获取
简介Kaggle平台泰坦尼克号生存预测是数据科学入门的经典项目这份资料将常用数据集与带详细注释的Python源代码打包在一起适合正在学习机器学习、希望从零完成一次完整建模流程的初学者也可供中级数据分析师快速复现基线方案。压缩包仅40KB共6个文件其中4个csv文件涵盖训练集、测试集及预处理后的特征表2个py脚本分别演示数据清洗、特征工程、模型训练与结果提交的完整链路代码注释对每步操作和参数选择都做了说明。目前已有1361人学习过该资料可作为Kaggle竞赛入门或课程大作业的参考实现。通过阅读和运行源码不但能掌握Pandas处理缺失值、编码分类变量等预处理技巧还能了解逻辑回归、随机森林等模型在真实数据上的应用以及如何利用交叉验证和网格搜索优化超参数最终形成一份可复现的泰坦尼克号解决方案。1. 泰坦尼克号不是入门题为什么这个1912年的沉船数据至今还在被反复训练Kaggle平台的泰坦尼克号数据集是下载次数最多的入门竞赛数据之一891条训练记录418条测试记录任务是根据舱位、年龄、性别等字段预测乘客是否生还。表面上是道简单的表格分类题实际上特别适合练“源代码注释”的功夫——答案遍地都是难点从来不是抄代码而是弄清每行特征工程为什么存在、每个参数为什么叫这个名字。这篇笔记写给两类人第一次接触Kaggle竞赛、想借这个数据集把“跑通”变成“读懂”的新手以及已经跑过脚本、但遇到数据泄漏、提交报错、分数复现不了的老手。下面按我拿到带注释源码时的阅读顺序把读数据、特征工程、建模、提交和排错串成一条完整路径。2. 先看懂赛题和数据字段注释、评价指标与代码阅读顺序2.1 Kaggle泰坦尼克号竞赛到底在预测什么从字段注释反向理解数据Kaggle竞赛官网对泰坦尼克号的描述很简短让参赛者根据乘客的个人信息预测在沉船事故中是否生还。但真正有价值的信息藏在字段注释里。train.csv的每一列都是一条线索注释写得准不准决定了后续特征工程的方向对不对。常见字段注释如下表字段含义缺失情况处理方向PassengerId乘客编号无缺失只做索引不进特征Survived是否生还1/0无缺失仅train标签列Pclass舱位等级1/2/3无缺失类别特征有序Name姓名无缺失提取Title等新特征Sex性别无缺失二值类别Age年龄train约177条缺失填充后作为连续特征SibSp同船兄弟姐妹/配偶数无缺失组合成FamilySizeParch同船父母/子女数无缺失组合成FamilySizeTicket票号无缺失高基数一般不直接用Fare票价test约1条缺失填充后连续特征Cabin客舱号约77%缺失拆首字母或标缺失Embarked登船港口train约2条缺失众数填充这里我要强调一个容易忽略的细节字段注释里SibSp的官方定义是“同船的兄弟姐妹或配偶数量”Parch是“同船的父母或子女数量”而不是字面上的“兄妹”和“父母”。网上许多版本的源代码把这两个字段的注释写反了或写窄了照着错误注释做特征工程FamilySize算出来的数就会偏。拿到数据先动手核对字段注释比急着打开源码更有用。为什么这个数据集只有891条训练样本还值得反复用因为它的字段设计非常接近真实业务里的“脏表格”有缺失、有高基数文本、有类别不平衡、有看似无用实则关键的文本列。在Kaggle平台上很多入门竞赛的数据都是规整过的泰坦尼克号是少数需要你自己决定“哪些列扔掉、哪些列拆开”的赛题这一点比样本量更有教学价值。2.2 评价指标为什么用accuracy二分类均衡性与提交门槛泰坦尼克号竞赛官方采用的评价指标是accuracy也就是预测正确的样本占全部样本的比例。很多新手会问为什么不用AUC、F1或者LogLoss原因有两点。第一这个任务的类别相对均衡。train.csv里生还者约342人遇难者约549人生还比例约38%不是那种99%对1%的极端不平衡场景accuracy不会被“全预测为多数类”的作弊解法推得很高。第二竞赛官方对提交格式做了硬性限制提交文件只需要PassengerId和Survived两列Survived只能是0或1不能用概率代替。这意味着你无法用输出连续概率再排名的方式参与Public Leaderboard排行模型输出的阈值处理必须在本地验证集上提前解决。这也解释了为什么带注释的参赛源代码普遍会把验证策略写在注释里用train.csv切出验证集在验证集上算accuracy再拿验证集上表现最好的模型去预测test.csv。注释如果只写了“准确率0.82”却没写用的哪个随机种子、哪次切分这个数字基本不具备复现价值。另外要提醒一句Public Leaderboard只用了test.csv的一部分做评分所以CV分数和LB分数本来就会有差异那些只在Public上好看、Private上翻车的源码多半是过拟合了Public榜单的噪声。靠本地验证集反馈别靠反复提交试错。还有一个容易被忽略的门槛Titanic的每日提交次数有限。早期参赛者靠反复提交试错现在这个路子行不通平台会限制提交次数逼着你把本地验证做扎实。这其实是一件好事——训练集就是你的考场验证集切分策略直接决定你能否正确估计真实效果。2.3 拿到“源代码注释”版本后先按这个顺序读代码我见过很多新手拿到一份带注释的泰坦尼克号源码第一件事是从第一行顺着一行行读读到第200行已经忘了开头在做什么。常见做法是先跑通再逆着读。具体顺序是先跑一遍拿到submission.csv确认环境没问题然后从入口函数往回找特征工程函数最后再读训练和预测部分。读取数据的代码是所有步骤的起点import pandas as pd train pd.read_csv(train.csv) test pd.read_csv(test.csv) print(train.shape) # (891, 12)训练集规模 print(test.shape) # (418, 11)测试集没有Survived列 print(train.info()) # 查看每列的非空数量与数据类型 print(train.head()) # 确认字段注释里的名字和实际列名一致这段代码背后的逻辑是先确认行数和列数再确认缺失情况。train.info()输出里Age、Cabin、Embarked的non-null count会明显小于891这比人工翻Excel判断缺失快得多。train.head()则是用来核对字段注释的比如有的源码把Cabin解释成“客舱编号”但实际数据里Cabin大量是NaN这时你就要意识到这个字段不能直接当成普通类别来用。参数说明read_csv的默认分隔符是逗号泰坦尼克号数据集不需要额外指定sep如果文件放在子目录把路径写成data/train.csv避免用绝对路径否则换一台机器就要改代码。train.info()里能看到每个字段的dtypeobject类型的字段后续要做编码处理float64类型可以直接进模型。读代码时还有个习惯值得养成把注释当成“为什么”来读而不是“是什么”。比如一行train[Age] train[Age].fillna(train[Age].median())如果注释只写“填充年龄缺失值”那是废话如果写“用中位数填充是因为年龄分布右偏均值会被高龄乘客拉高”这才是有价值的注释。你自己写代码时也按这个标准写注释后面第五、六章的排错会省很多时间。有团队会用注释率来评估代码可维护性但泰坦尼克号这种教学场景里注释质量比注释数量重要得多一段解释“为什么”的注释顶过十行描述“是什么”的注释。如果你拿到的是ipynb格式的Notebook单元格执行顺序比代码本身更容易出错。常见做法是先把Kernel重启后再Run All确认整本Notebook能从头跑到尾再动手读。一个藏了隐藏状态变量的Notebook某些单元格单独执行能通过整本跑却报错就是因为前面的单元格并没有真正执行过。3. 特征工程是这场竞赛的真正考点从原始字段到能进模型的数值特征3.1 缺失值处理Age、Embarked、Cabin三个字段的三种策略泰坦尼克号数据集的缺失值集中在Age、Cabin、Embarked三个字段。很多新手的第一个错误是直接dropna一行代码删掉所有含缺失值的行891行瞬间少掉两百多行信息损失太大。另一个常见做法是统一用0填充这个对Cabin勉强可用对Age和Fare会严重扭曲分布。常见做法是分字段处理。Age的缺失比例大约在20%用中位数填充比用均值稳定因为年龄分布右偏少数高龄乘客会把均值拉高。但要注意一个原则test.csv的填充统计量必须来自train.csv不能在test上单独算。原因很简单test是你假装看不到的未来数据用test的中位数填充本质上是把test的信息泄漏到了训练流程里。age_median_train train[Age].median() train[Age] train[Age].fillna(age_median_train) test[Age] test[Age].fillna(age_median_train) # 用train的统计量 embarked_mode_train train[Embarked].mode()[0] train[Embarked] train[Embarked].fillna(embarked_mode_train) test[Embarked] test[Embarked].fillna(embarked_mode_train) train[CabinMissing] train[Cabin].isna().astype(int) test[CabinMissing] test[Cabin].isna().astype(int) train[CabinLetter] train[Cabin].str[0].fillna(Unknown) test[CabinLetter] test[Cabin].str[0].fillna(Unknown)这段代码里有两个参数细节。train[Age].median()返回的是标量不是Series所以fillna可以直接用不会触发索引对齐问题。Embarked的mode()[0]取第一个众数是因为train里缺失的恰好两条样本都是最频繁出现的港口用众数填充是误差最小的做法。Cabin的处理则是把“是否缺失”本身当成特征因为泰坦尼克号上Cabin为空往往意味着乘客住在低等舱或行李区这个缺失信息本身就有预测力。CabinLetter提取首字母后常见做法是再看一眼分布如果某个字母类别太少就归并成Other。这部分需要根据实际输出决定不是所有源码都会写清楚所以注释里最好记录当时的分布情况方便下次复现。注意如果你要在多个模型间比较这类“看一眼再归并”的操作要固定下来否则每次结果都不一样。注意所有填充统计量只从train.csv计算test.csv只能用同一个值填充不能用test自身统计否则会造成信息泄漏。3.2 从Name里提取Title一个字段注释最多的特征工程技巧Name字段看起来是最没用的文本列但它包含了Title称谓比如Mr、Mrs、Miss、Master、Dr、Rev。Title和年龄、社会阶层高度相关Master通常是未成年男孩Miss和Mrs区分已婚未婚女性这在沉船生还概率上有显著差异。这是泰坦尼克号竞赛里性价比最高的一个特征几乎所有高分方案都会做。train[Title] train[Name].str.extract(r ([A-Za-z])\., expandFalse) test[Title] test[Name].str.extract(r ([A-Za-z])\., expandFalse) title_mapping { Mr: Mr, Mrs: Mrs, Miss: Miss, Master: Master, Dr: Rare, Rev: Rare, Col: Rare, Major: Rare, Countess: Rare, Don: Rare, Jonkheer: Rare, Lady: Rare, Capt: Rare, Sir: Rare } train[Title] train[Title].map(title_mapping).fillna(Rare) test[Title] test[Title].map(title_mapping).fillna(Rare)正则表达式r ([A-Za-z])\.匹配的是“空格连续英文字母句点”。Name里的呈现形式是“Braund, Mr. Owen Harris”所以正则能把Mr捕获出来。expandFalse让str.extract返回Series而不是DataFrame后面可以直接赋值给新列。title_mapping的映射逻辑是保留四个常见Title其余归入Rare。这里有个容易踩坑的地方test.csv里出现的Title集合可能和train.csv不完全相同。比如train里没有Donatest里却有如果直接用train的类别做编码Dona就会被sklearn判定为“unseen label”导致报错或者被OneHotEncoder静默忽略。上面的代码用map加fillna(Rare)兜底就是为了应对这个情况。这是一个典型的“训练集和测试集分布不一致”问题泰坦尼克号数据集的坑不在量大而在这种细节。3.3 家庭大小与是否独自一人构造组合特征的思路SibSp和Parch两个字段单独看预测力都不强但把它们组合成FamilySize后含义就清晰了家庭规模直接影响逃生时的互助概率。另一个常见的组合特征是IsAlone独自一人的乘客在恐慌环境里更难获得帮助这个特征在很多方案里能单独带来一到两个百分点的准确率提升。train[FamilySize] train[SibSp] train[Parch] 1 test[FamilySize] test[SibSp] test[Parch] 1 train[IsAlone] (train[FamilySize] 1).astype(int) test[IsAlone] (test[FamilySize] 1).astype(int)加1是因为要把乘客本人算进家庭规模。FamilySize等于1意味着船上没有同行的亲属IsAlone就是1否则是0。这两行代码本身没有复杂度真正需要注意的是特征工程的顺序先基于原始字段构造组合特征再做编码最后统一进模型。如果你先把SibSp和Parch分别做OneHotEncoding再组合FamilySize会得到一组冗余的高维稀疏特征模型训练变慢且容易过拟合。构造完新特征后原始字段的去留也有讲究。Sex、Pclass、Fare、Age、Title、FamilySize、IsAlone、Embarked、CabinLetter、CabinMissing是常见的最终特征集合。SibSp和Parch经过组合后可以从特征列表里移除Ticket字段因为基数太高每张票号基本唯一通常直接丢弃Name字段也只在提取Title时用一次之后不再进模型。3.4 编码与标准化类别特征进模型前的最后一公里模型不能直接吃字符串Sex、Title、Embarked、CabinLetter都要变成数值。常见做法是OneHotEncoder。逻辑回归对数值尺度敏感Fare和Age最好做标准化树模型对尺度不敏感但类别编码仍然要做。下面用ColumnTransformer把两类处理放在一个对象里方便后续放进Pipeline统一管理。from sklearn.preprocessing import OneHotEncoder, StandardScaler from sklearn.compose import ColumnTransformer feature_cols [Pclass, Sex, Age, Fare, Title, FamilySize, IsAlone, Embarked, CabinLetter, CabinMissing] cat_cols [Sex, Title, Embarked, CabinLetter] num_cols [Pclass, Age, Fare, FamilySize, IsAlone, CabinMissing] preprocessor ColumnTransformer([ (cat, OneHotEncoder(handle_unknownignore), cat_cols), (num, StandardScaler(), num_cols) ]) y_train train[Survived]这里有两个关键参数。OneHotEncoder的handle_unknownignore是关键中的关键test里出现train没见过的类别时它会把这一列全部编码为0而不是抛异常。StandardScaler先fit在train上再transform test用train的均值方差标准化test这是标准做法避免test信息反向影响训练。Pclass放进num_cols其实是把有序类别当连续值用实践上可以如果追求严谨可以把它挪到cat_cols里做OneHot代价是多两列稀疏特征模型效果差别不大。第4章会把preprocessor和模型包进Pipeline所以这里不提前执行fit_transform那些操作会由Pipeline在每一折交叉验证内部自动完成。4. 建模与调参用带注释的源代码跑通训练、验证与提交4.1 基线模型选择为什么先跑LogisticRegression而不是直接上XGBoost泰坦尼克号数据集只有891条训练样本特征维度撑死几十个。这种小数据集上XGBoost、LightGBM这类梯度提升树很容易过拟合而且调参空间大新手很难判断分数变化到底来自参数还是来自特征。常见做法是先跑一个LogisticRegression作为基线因为它的输出稳定、可解释性强还能用来验证特征工程是否有问题——如果逻辑回归的交叉验证分数在0.78以下说明特征构造方向大概率有问题此时换更强的模型只是把问题藏起来。有了3.4的preprocessor训练代码可以写得很干净。用Pipeline把预处理和模型串起来交叉验证时preprocessor会在每一折内部重新fit编码器和标准化器都不会看到验证折的数据。from sklearn.linear_model import LogisticRegression from sklearn.pipeline import Pipeline from sklearn.model_selection import cross_val_score model_pipe Pipeline([ (preprocessor, preprocessor), (clf, LogisticRegression(max_iter500, random_state42)) ]) scores cross_val_score(model_pipe, train[feature_cols], y_train, cv5, scoringaccuracy) print(scores.mean(), scores.std())max_iter500是为了保证逻辑回归能收敛sklearn默认max_iter是100当特征数变多或C值较小时偶尔会触发ConvergenceWarning。random_state42固定随机种子让每次交叉验证的切分结果一致。cv5表示五折交叉验证scores.mean()给出平均准确率scores.std()看折间波动标准差超过0.02说明特征或数据切分不稳定需要回头检查。交叉验证在这里的作用是模拟多次“训练-验证”避免单次train_test_split的偶然性。网上那些标注了“Public LB 0.79”的源码注释里基本都会写明cv分数和LB分数两个数字两者差太多就说明模型过拟合了train.csv的特定分布。4.2 交叉验证与超参数设置随机种子、正则化强度与早停基线模型跑通后下一步是调参。逻辑回归最值得调的参数是正则化强度CC越小正则化越强模型越保守C越大越倾向于拟合训练数据。用GridSearchCV做网格搜索时因为模型被包在Pipeline里参数名要写成clf__C这种带双下划线的形式。from sklearn.model_selection import GridSearchCV param_grid { clf__C: [0.01, 0.1, 1, 10], clf__penalty: [l2] } grid GridSearchCV( model_pipe, param_grid, cv5, scoringaccuracy ) grid.fit(train[feature_cols], y_train) print(grid.best_params_) print(grid.best_score_) # 把结果记在注释里例如 # C0.1, cv0.813, LB0.784penalty只试l2因为l1在特征少的时候意义不大而且l1会触发不同的求解器路径增加不必要的变量。random_state42在GridSearchCV内部也会传给每一次拟合保证不同C值之间只在正则化强度上有差异。best_score_是网格搜索内部交叉验证的最好分数这个数字可以和后续的树模型对比。这里必须说清楚Pipeline的一个好处preprocessor在每一折内重新fit避免编码器在交叉验证开始前就看过全部train数据。但要注意3.1里的Age填充还在Pipeline外面这是很多老代码的折中做法更严格的方案是把SimpleImputer放进Pipeline代价是代码变复杂。泰坦尼克号这个量级填充统计量泄漏的影响很小但你要知道这个偏差存在注释里最好写明“Age填充在Pipeline外完成”。如果你决定换随机森林或XGBoost随机种子同样要固定。随机森林的n_estimators从100开始调max_depth从3开始试先不要动min_samples_split。XGBoost则要注意early_stopping_rounds直接在训练集上拟合而不做早停在小数据集上几乎必然过拟合。泰坦尼克号这类数据树模型的提升空间有限重点仍然是验证特征而不是盲目堆模型复杂度。4.3 生成submission.csv提交格式、索引对齐与概率阈值模型训练完成最后一步是预测test.csv并生成提交文件。这一步的坑集中在索引对齐上。test.csv的PassengerId是418个不连续编号如果你在特征工程过程中做过dropna或reset_index预测结果的顺序可能和原始文件对不上。常见做法是提交前用断言检查长度、ID集合和标签取值。test_pred grid.best_estimator_.predict(test[feature_cols]) submission pd.DataFrame({ PassengerId: test[PassengerId], Survived: test_pred }) assert submission.shape[0] test.shape[0] assert set(submission[PassengerId]) set(test[PassengerId]) assert submission[Survived].isin([0, 1]).all() submission.to_csv(submission.csv, indexFalse)grid.best_estimator_是完整Pipelinepredict直接吃原始test[feature_cols]不需要手动调用preprocessor.transform这一步能帮你挡掉大量预处理不一致的坑。三个assert的作用是把“我以为对了”变成“程序确认对了”第一个检查行数第二个检查ID集合第三个检查标签取值只能是0或1。to_csv的indexFalse必须加如果不加提交文件里会多出一列Unnamed: 0Kaggle官方提交解析器会直接报错。关于概率阈值默认情况下predict用的阈值是0.5。但如果你发现验证集上生还者的预测概率普遍集中在0.4到0.6之间可以考虑在验证集上遍历阈值找一个让accuracy最大的值再用这个阈值从predict_proba的输出生成0/1标签。这类阈值调整效果通常很有限而且有在小验证集上过拟合的风险新手阶段不建议优先做。Kaggle对每日提交次数有限制不能把线上反馈当调试工具。常见做法是本地先用交叉验证确定模型再统一提交一次。每一版代码在注释里记录CV分数、特征列表和随机种子这样提交后无论Public分数高低都能回到本地复现。5. 泰坦尼克号避坑指南数据泄漏、索引错位与提交翻车的5个排查点这一章集中写泰坦尼克号源代码复现里最容易翻车的5个排查点。这几个坑看起来有点玄学其实都能在数据流里找到明确原因按“现象→原因→解决”的顺序记录方便你遇到时直接对照。5.1 现象交叉验证分数很高但Kaggle Public Leaderboard分数很低原因数据泄漏。最常见的一种是填充缺失值时用全量train计算统计量然后再做交叉验证。比如3.1里如果你先用train[Age].median()填充整个train再交给cross_val_score每一折验证集里有一部分样本的年龄其实来自训练折的统计量模型“见过”了验证集的信息CV分数虚高。另一种泄漏是把test.csv的信息在特征工程阶段混进来比如用test的Fare均值填充train的Fare缺失。解决把填充操作放进交叉验证的Pipeline里使用SimpleImputer替换手动fillna或者至少保证填充统计量只来自当前训练折。我用的最稳妥做法是写一个fill_age_with_fold(train_fold, val_fold)函数在每个fold内部重新计算中位数代码量多几行但CV分数诚实得多。还有一个更隐蔽的泄漏是把PassengerId当特征它看起来像纯编号但ID和乘客登船顺序相关模型能从中学到不该学的模式。另一个让CV和LB差距大的原因是折间波动大。cross_val_score默认对分类任务使用StratifiedKFold但如果你手动用了普通KFold某些折里生还样本比例会严重偏离整体891条样本量下分数浮动接近两个百分点是正常的。解决显式使用StratifiedKFold(n_splits5, shuffleTrue, random_state42)保证每折类别比例一致。5.2 现象预测结果全是0或者全是1原因三类。第一y_train传错了比如把PassengerId当成了标签模型拟合了和生死无关的编号。第二特征矩阵里混入了Survived列导致模型“作弊”学到一个完美特征但test里没有这一列预测时就退化成预测多数类。第三类别严重不均衡时模型为了最大化accuracy选择全部预测多数类但这在泰坦尼克号里不太可能因为生还比例不算极端。解决先打印标签分布和预测分布确认问题在哪一层import numpy as np print(train[Survived].value_counts(normalizeTrue)) # 标签分布 print(np.unique(test_pred, return_countsTrue)) # 预测分布 print(feature_cols) # 检查特征列表value_counts(normalizeTrue)看的是生还和遇难的比例np.unique直接数预测结果里的0和1。如果feature_cols里意外包含Survived或PassengerId立刻删掉。还有一个笨但有效的办法把特征工程函数的输出打印出来和原始数据逐列对比看有没有某列变成常数。比如CabinLetter全部被fillna(Unknown)对模型来说这列就等于没有提供任何区分度。5.3 现象提交后报错Expected 418 rows but got ... rows原因test.csv经过特征工程后行数变了。最常见的元凶是dropna()新手在test上执行test test.dropna()之后418行变成三百多行最终提交文件行数对不上。另一个常见原因是索引没有重置导致合并时产生错位虽然行数没变但PassengerId对错了人。解决在整套特征工程里约定“绝对不对test做dropna”。Age、Fare、Embarked全部用填充而不是删行。我在特征工程函数最后会放一行断言行数不对马上崩不让错误流到提交阶段assert len(test) 418, ftest rows changed: {len(test)}还有一个习惯值得养成每次对test做操作后立刻test test.reset_index(dropTrue).copy()。pandas里很多操作会打乱索引比如sort_values、dropna、布尔筛选如果不重置索引后续pd.concat或按位置赋值会按旧索引对齐产生看似正常实则错位的数据。5.4 现象注释里的字段和实际数据对不上原因网上流传的泰坦尼克号源码版本很多有的把Embarked注释成“登船地点”有的写成“港口编号”但train.csv里这一列的值是S、C、Q三个字母。如果注释说“港口编号”你会下意识去做数值编码把S当成0、C当成1、Q当成2这会让树模型产生错误的顺序关系。另一个经典错误是把Parch注释成“父母数量”实际官方定义是“同船的父母或子女数量”两者范围不一样。解决拿到代码后第一件事是用train.columns.tolist()和train.head()核对字段注释。注释和实际数据不一致时以实际数据为准并在自己的代码里把修正后的注释写清楚。写字段注释时最好带上取值样例比如“Embarked登船港口取值S/C/Q三个字母”这样下次回看或者交给别人时不会产生歧义。这也解释了为什么会有人在GitLab仓库里统计注释率把代码量和注释长度当成可维护性指标——但那个统计只能衡量数量衡量不了质量。注释和代码行为不一致的注释比没有注释更有害。我自己的标准是字段注释必须能在不打开数据的情况下描述清楚取值范围和业务含义。5.5 现象注册Kaggle账号时验证码无法显示下载数据集总是中断原因这类问题大多出在本地环境而不是Kaggle平台。浏览器缓存了旧页面资源、Cookie里混入了异常会话、系统时间不准确导致验证码服务校验失败、或者浏览器插件拦截了验证码脚本都是常见诱因。页面提示captcha must be filled out时通常意味着验证码组件根本没有成功加载出来。解决先换一个无痕窗口重新打开注册页绕开缓存和Cookie干扰再检查系统时间是否与当前时间一致时间偏差过大会导致验证码接口返回异常第三步是把浏览器语言切换成英语刷新页面个别验证码组件对非英文页面支持不好。如果这些都没用就换Chrome或Edge的默认配置停用广告拦截相关扩展后重试。注册完成后记得去注册邮箱确认验证邮件有时它会被误拦进垃圾箱点开确认链接账号才算激活。下载数据集时如果网页端经常中断常见做法是安装Kaggle官方CLI工具在终端里用kaggle competitions download -c titanic拉取下载过程比网页端稳定得多断线后重新执行会继续拉取。数据下载完成后把压缩包解压到固定目录train.csv和test.csv各就各位整套流程就和网页端没有关系了。6. 从跑通到上榜用特征重要性验证你的特征工程是否真的有效6.1 用Permutation Importance验证特征边际贡献跑通提交只是起点。要判断“源代码注释”这个方向值不值得继续投入最有效的方法是做一次特征重要性验证。Permutation Importance的思路是把某个特征在验证集上随机打乱观察模型accuracy掉多少。掉得多说明这个特征贡献大掉得少甚至上升说明这个特征可能是噪声。为了做这个验证我习惯单独切一个验证集避免特征重要性分数混入训练集的乐观偏差from sklearn.model_selection import train_test_split from sklearn.inspection import permutation_importance X_train_final, X_val, y_train_final, y_val train_test_split( train[feature_cols], y_train, test_size0.2, random_state42 ) best_model grid.best_estimator_ best_model.fit(X_train_final, y_train_final) result permutation_importance( best_model, X_val, y_val, n_repeats10, random_state42 ) for name, score in zip(feature_cols, result.importances_mean): print(f{name}: {score:.4f})n_repeats10表示每个特征打乱10次取平均降低随机性带来的波动。如果Sex、Title、Pclass排在前面Age和Fare排在中间Embarked和CabinLetter排在最后说明特征工程方向是对的。FamilySize和IsAlone如果排在倒数说明组合特征没有提供增量信息可以考虑去掉简化模型。6.2 用学习曲线判断当前是欠拟合还是过拟合另一个值得做的验证是学习曲线。用小规模训练子集观察模型分数随数据量增加的变化训练分数高但验证分数低是过拟合两条曲线都低是欠拟合。泰坦尼克号这个数据量学习曲线更多是用来判断特征工程是否榨干了数据信息而不是用来精调模型。6.3 提交前最后检查清单我在提交前会按顺序过一遍特征工程函数输出行数与训练测试集一致填充统计量全部来自trainfeature_cols里不含Survived和PassengerId随机种子固定并在注释里记录submission.csv只有两列且没有多余索引列本地CV分数和预期相符。说一件我自己的教训我最早的一份泰坦尼克号代码在注释里写了“Cabin缺失值用U填充”但代码里实际写的是fillna(0)注释和实现不一致。两周后我自己回看时被误导又在Cabin上做了一轮无谓的处理。从那以后我要求自己的注释必须能通过“把注释当代码读”的检验——如果注释描述的步骤没法照着还原成代码这行注释就是负债而不是资产。好的源代码注释是给未来的自己留的后悔药希望帮到你。本文还有配套的精品资源点击获取
