2026年的MCM美赛问题C标题里带着“星体相关数据”这个关键词一出来估计不少队伍心里都咯噔了一下。表面上看这是一道天文数据题好像离我们平时练的金融风控、电商预测很远可拆开揉碎之后你会发现它考的还是那几板斧数据清洗、特征工程、模型解释、写作自洽。我写这篇东西是想把这几天反复梳理的备战思路、我自己会用的代码框架和团队时间安排一次性摊开来说清楚。适合谁看准备打美赛的队伍尤其是队友里有代码能力但没有天文背景的同学哪怕你已经拿到题、甚至已经跑上模型了这篇文章里关于数据泄露和协作管理的部分也值得你留个心眼。1. 问题C为什么难先把定位搞明白1.1 数据题的评分权重到底在哪儿美赛问题C的定位从题型上说更像一场数据挖掘项目的现场答辩而不是纯数学推导。它通常没有标准答案评委打分时更看重你的逻辑链条是否完整拿到一份数据你发现了什么问题、做了哪些假设、用什么方法解决、结论是否可靠、换一个扰动条件结论还稳不稳。这一整套证据链最后浓缩在一篇二三十页的论文里。我带过几支队伍打数据题最大的教训是很多人把精力全砸在调模型上却忽略了评委真正会看的三个东西。第一摘要它基本决定了评委愿不愿意往下读第二可视化图表是否干净、坐标单位是否清楚、图注是否解释了关键发现第三可复现性你的结论能不能用论文里描述的步骤在合理时间内得到。我见过不止一次模型分数很漂亮但变量没有单位说明缺失值处理没记录灵敏度分析只有一张凑出来的图最后得分反而不如一个算法朴素但叙事完整的队伍。所以打问题C的第一步不是打开编辑器写代码而是想清楚你们要交一份什么样的“证据”。每写一段程序都要对应到论文里可以讲的一段逻辑。这个习惯从第一天就要有。1.2 天体数据题的特殊门槛“星体相关数据”听起来很吓人但拆开看绝大多数题目给的字段都不是天文学深层理论反而更像一张带物理单位的表格。常见字段无外乎赤经、赤纬、星等、有效温度、表面重力、金属丰度、恒星半径、恒星质量、距离、各类误差估计以及一个或几个目标变量比如“是否为确认行星”“星体分类”或某个连续物理参数。真正让天体数据区别于普通表格题的是三件麻烦事。第一单位不统一星等是反向指标数值越小越亮直接丢进线性模型会被系数方向误导表面重力通常以对数形式给出你不能再取一次log赤经可以是小时、度、弧度三种形态必须统一。第二误差列混在特征中这类列不是普通特征它本身代表测量质量如果你简单当成缺失值删掉会丢掉大量信息。第三样本标签极度不平衡比如“确认系外行星”可能只有几十个而“候选体”有几万个分类模型很容易变成“全都预测不是”。我的建议是别慌也不必恶补天体物理。你只需要像一个数据工程师那样先把每个字段的物理含义和取值范围搞懂再对照领域常识做特征。不理解某个字段时优先阅读题目附带的背景说明而不是去搜索深奥的恒星演化理论。大部分字段的理解成本半小时就能完成。2. 数据从哪来、怎么处理2.1 先做一张能救命的字段字典拿到数据后的第一件事不是跑模型也不是画相关性热力图而是建字段字典。所谓字段字典就是把每一列是什么、什么单位、什么范围、缺失率多少、怎么处理全部整理成一张表。这个动作看起来占时间却是整个团队后续讨论的基础。你想想如果队友A把“星等”当成数值越大越亮队友B把“温度误差”当成缺失值直接删掉两个人到写论文时才发现矛盾那才叫灾难。我自己常用的字段字典模板大概是这样的。字段名含义类型单位/说明缺失率处理建议star_id天体唯一标识字符串用于分组、去重0%检查重复ID作为GroupKFold分组依据ra赤经浮点小时或度需统一0.2%转弧度用于角度距离dec赤纬浮点度0.2%转弧度mag视星等浮点反向指标越小越亮3%线性模型前需注意方向teff有效温度浮点开尔文5%建议取log缺失用中位数err_teff温度误差浮点开尔文15%生成has_err标记再填补feh金属丰度浮点对数标度可正可负8%截断到合理范围logg表面重力浮点常用对数6%一般不再次取logobj_type目标标签类别确认/候选/否20%单独建模不能简单删行这张表的价值是让团队在“字段”这件事上对齐。我通常要求写完字典后三个人每人过目一遍标注出任何看不明白的列。很多问题在这一步就提前排掉了。2.2 清洗数据别让缺失值拖垮模型清洗的核心原则是区分“缺失”和“无效”。有些字段之所以缺失是因为该天体没有被精确测量这本身就是一条信息。比如误差列为空可能意味着源太暗、信号太弱、没有足够观测。如果直接把空值填成中位数相当于告诉模型这条记录没有任何异常这会抹掉真实的质量信息。我建议的流程是三步。第一步给每个误差列生成一个“是否缺失”的0/1标记保留缺失信息然后再对缺失值本身做填充对连续数值特征优先用同类别分组的中位数填补而不是全局均值因为恒星类型之间差异极大比如一颗红矮星和一颗热巨星的温度中位数完全不是一回事。第二步处理数值分布天体物理量经常跨越好几个数量级半径、质量、距离、温度统一取log会让模型更稳定。第三步异常值处理不要直接删除异常行更推荐做截断或标记成单独类别。删除异常值会把样本量变小还会在论文里引发评委对“为什么删、依据是什么”的质疑。还有一条容易被忽略任何用到整份数据的统计操作都必须放在训练集内部完成。很多人习惯先对整张表做标准化再切训练集和测试集这其实已经造成数据泄露。正确做法是用管道或先fit训练集再transform测试集后面我会在代码里展开。2.3 特征工程把物理量变成模型能吃的特征天体物理中很多关系是乘除法、幂次关系直接丢给线性模型并不合适。你不需要推导复杂的恒星演化方程但有几个组合方向值得做。第一个方向是对数运算。质量、半径、光度这些量取log后分布会更接近正态树模型虽然不怕单调变换但线性模型和距离类模型非常依赖。第二个方向是物理组合特征。比如恒星辐射能量与半径平方、温度四次方近似成正比你可以构造一个$\log L \approx 4\log R 4\log T$这样的合成特征。这里不需要常量只要方向合理模型就能捕捉到一些非线性关系。第三个方向是角度处理。赤经赤纬直接作为坐标在0度和360度附近会产生跳跃最好转成三维笛卡尔坐标分量或者至少把角度转成弧度再参与距离计算。第四个方向是类别特征的合并。如果字段里有光谱类型这种分类变量不要简单用0,1,2编号因为编号隐含了顺序关系。要么用独热要么结合其他物理量做目标编码。特征工程最重要的原则是每加一个特征都要在论文里写一句“为什么”。一个无法解释的特征即使让分数涨了在美赛这种看重叙述的评审体系里也可能是负分项。与其堆五十个模糊特征不如用二十个讲得清楚的。3. 建模思路与技术选型3.1 先走基线再谈花活很多队伍第一天就上随机森林网格搜索结果参数还没跑完思路已经乱成一锅粥。更稳的玩法是先用逻辑回归或线性回归把从数据到预测的整条流水线跑通。这一步会逼着你解决数据读取、字段清洗、标签编码、交叉验证这些基础问题也让你快速判断数据里到底有没有信号。基线的意义不是拿高分而是校准流程。比如一个二分类问题如果逻辑回归在验证集上的AUC接近0.5说明要么标签放错了要么特征没缩放要么目标变量和特征没关系。这个时候你该做的是回头查数据而不是换更强的模型。另外基线模型跑出来的系数方向也可以帮你做初步检查物理上“恒星温度越高某类行星越可能存在”这种假设如果系数方向反了大概率是数据单位有问题。评价指标方面分类题优先看AUC和LogLoss回归题看RMSE和MAE。美赛通常不会明确告诉你用什么指标所以论文里要自己定义一个主指标并用交叉验证报告均值和方差。一个只说“准确率98%”但样本严重不平衡的结论在评委眼里没有任何说服力。3.2 树模型、神经网络到底怎么选表格数据建模我默认优先梯度提升树比如scikit-learn里的随机森林、梯度提升或者其他常见实现。理由很简单对缺失值有一定容忍度能捕捉非线性关系训练速度快还能输出特征重要性。这些特性太适合美赛这种时间紧张、团队基础参差不齐的场景了。神经网络什么时候用只有当数据形态不适合表格建模时才值得考虑。比如题目给的是光变曲线序列、光谱像素序列或者图像数据那用LSTM、一维卷积或简单图像分类网络才有意义。如果题目只是几千行、几十列的表格神经网络反而容易过拟合调参时间也撑不住。我自己见过太多队伍为了“显得高级”硬上深度学习结果训练时间占了半天论文里的可解释性还几乎为零。就算要用神经网络也建议从多层感知机开始两到三层、每层几十个神经元加上Dropout。先把结果和树模型对比如果树模型明显更好就果断放弃神经网络。美赛比拼的不是模型复杂度而是模型和问题的匹配程度。3.3 集成与结果校准单模型有波动经验做法是模型融合。最简单的融合叫加权概率平均对分类问题把多个模型输出的概率按权重平均再做阈值判断。权重可以根据各自验证集AUC来定比如AUC高的模型权重大一些。更复杂一点是Stacking即用第一层模型在交叉验证上的预测结果作为新特征喂给第二层模型。这个玩法效果通常不错但写代码时容易泄露数据必须严格按照折外预测来做。还有一个值得一提的细节是概率校准。树模型输出的概率往往不够准也就是分数高不代表真实置信度高。如果你需要跟某个概率阈值打交道或者论文里要写“预测概率排名前百分之多少的样本具有较高置信度”可以用Platt缩放或等渗回归调整一下输出。美赛里校准不会直接加分但当你发现预测概率与真实频率明显不一致时它能让你的结果叙述更扎实。4. 代码实现与工具链4.1 工程结构别让队友乱成一锅粥四天时间三四个人如果不提前约定工程结构很容易出现“两个人在同一个文件上改来改去最后合并时崩溃”的经典事故。我的标准目录结构长这样data/ raw/ processed/ external/ notebooks/ 01_explore.ipynb 02_clean.ipynb 03_model.ipynb scripts/ make_dataset.py train_model.py outputs/ figures/ submission/ papers/ README.md约定很简单原始数据放在data/raw里谁都不能改清洗后的数据统一写到data/processednotebook只做探索和尝试正式跑模型的脚本放scripts所有图和提交文件放outputs并且统一命名比如model_v2_auc086.png。每次开会前看一眼目录结构就知道各自进展到哪了。固定随机种子也是必须的。所有涉及随机的操作包括数据切分、模型初始化、交叉验证都要显式设置random_state保证任何一个人重跑都能得到差不多的结果。这个习惯在最后写“模型可复现性”段落时会给你省掉大麻烦。4.2 数据预处理代码示例这里给出一个能直接改着用的预处理片段。我假设数据是一份CSV字段名跟上面表格类似但你拿到实际题之后改成你的列名就行。import pandas as pd import numpy as np df pd.read_csv(data/raw/stars.csv) # 先检查重复ID和基础信息 print(duplicated ids:, df[star_id].duplicated().sum()) print(shape:, df.shape) def clean_features(df): df df.copy() # 角度统一转弧度ra如果单位是小时要乘15再转度 # 如果单位本身就是度就不要乘15 df[ra_rad] np.deg2rad(df[ra] * 15) df[dec_rad] np.deg2rad(df[dec]) # 对数变换 df[logR] np.log1p(df[r_star].clip(lower0)) df[logT] np.log(df[teff]) # 金属丰度截断到合理范围避免极端值 df[feh_clip] df[feh].clip(-2.5, 2.5) # 误差缺失标记 中位数填补 df[has_err_temp] df[err_teff].isna().astype(int) df[err_teff] df[err_teff].fillna(df[err_teff].median()) return df df_clean clean_features(df) print(df_clean.head())这段代码本身不复杂但每个注释背后都对应一个预处理决定。比如为什么取log1p而不是log因为半径可能有一小部分为0或负值clip后取log1p更稳。为什么金属丰度要截断因为极端值会严重影响线性模型和距离计算。写成模板是为了让团队在讨论时能对着注释一个一个拍板。4.3 训练与评估流程预处理完成后进入建模。下面这段代码用随机森林跑一个5折交叉验证输出的AUC均值和标准差就是模型基线的核心指标。from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import StratifiedKFold from sklearn.metrics import roc_auc_score from sklearn.impute import SimpleImputer from sklearn.pipeline import Pipeline from sklearn.preprocessing import StandardScaler features [ra_rad, dec_rad, logR, logT, feh_clip, err_teff, has_err_temp] X df_clean[features] y df_clean[label] cv StratifiedKFold(n_splits5, shuffleTrue, random_state42) model Pipeline([ (imputer, SimpleImputer(strategymedian)), (scaler, StandardScaler()), (clf, RandomForestClassifier(n_estimators300, random_state42)), ]) scores [] for train_idx, val_idx in cv.split(X, y): X_tr, X_val X.iloc[train_idx], X.iloc[val_idx] y_tr, y_val y.iloc[train_idx], y.iloc[val_idx] model.fit(X_tr, y_tr) y_prob model.predict_proba(X_val)[:, 1] scores.append(roc_auc_score(y_val, y_prob)) print(AUC:, np.mean(scores), /-, np.std(scores))这里有一个特别需要注意的点如果你们发现同一颗星或同一个天体源在训练集和验证集里都出现那么上面的StratifiedKFold就不可靠了因为它会把同一组数据分到两边模型相当于提前见过答案。这种情况应该改用GroupKFold并把star_id作为分组字段。写论文时把“按天体ID分组”这件事讲清楚评委一眼就能看出你是懂数据泄露的。5. 常见问题与排查技巧实录5.1 数据泄露全场最隐蔽的坑数据泄露这个词在比赛里听到的概率远高于你想象。最常见的两种一种是先对全量数据做了标准化或填补再切训练集和测试集导致测试集的统计信息渗进训练过程另一种是特征里藏了标签的影子。比如数据中有一列叫“是否为候选体”而目标变量是“是否为确认行星”候选体本身和确认存在高度重叠模型训练完自然分数高得离谱可一旦上真实未知数据就崩。排查方法其实很笨但有效训练完成后把特征重要性最高的前十个特征列出来逐个问一句“它和标签之间的关联在现实世界中我们设计模型时真的知道吗”。如果某个特征本质上已经预告了标签就果断删掉。还有一个很典型的情况是时间泄漏。如果数据带有观测日期你要检查测试集的时间是否晚于训练集。一旦存在时间顺序就必须按时间切分绝不能随机切分否则模型就是在用“未来”预测“过去”。5.2 过拟合、样本不平衡与指标选择天体数据里的标签不平衡会很常见。假设只有3%的样本属于少数类你用默认参数训练随机森林大概率模型把所有样本都判定为多数类AUC却仍然可能不低。正确的做法是看混淆矩阵里的少数类召回率如果召回率接近0说明模型没有学到少数类模式。可以给模型加类别权重让少数类的错误惩罚更大可以调整预测阈值而不是默认的0.5也可以对多数类做欠采样。但我一般不建议随便用SMOTE这类合成采样因为天文数据有物理约束凭空合成的样本可能违背恒星演化关系写进论文里很难自圆其说。过拟合的常规表现是训练集AUC很高验证集AUC快速下降。这时先看树的深度和叶子节点数限制复杂度比加数据更有效。如果你们打算用神经网络早停法几乎是必备的也就是验证集指标不再提升时立刻停止训练。把训练曲线打印出来放到论文附录也是一项不错的“过程透明度”展示。5.3 协作管理与版本控制四天比赛里最大的敌人不是题目难而是混乱。我见过最典型的场景队友A在本地把数据清洗了一段代码队友B在另一份脚本里也改了同一段清洗逻辑两个人跑了不同的特征到第三天晚上发现模型对不上。从那以后我要求所有关键脚本从第一天就固定下来任何改动都要在文件头部注释里写明“改了什么、为什么改、谁改的”。不用纠结能不能用多高端的工具哪怕只是用同一个在线网盘加上一条强制规则原始数据只读中间数据写processed目录文件名带版本号和日期。这样一来即使有人改错了也能快速回退。另一个实用建议是每天固定开两次十五分钟的同步会早上一起来对任务晚饭前后对结果。写论文的人和写代码的人每天至少互相看一次对方的产出越早磨合最后通读论文时越不容易翻车。6. 论文写作与收尾6.1 摘要和问题重述怎么写美赛摘要不是写诗是在一页之内把“你们做了什么、为什么、结果如何”说清楚。我建议摘要包含五个要素问题背景和数据处理规模、主要建模方法、关键结果、灵敏度验证的简述、结论。好的摘要读完第一句话就知道你要解决什么问题读完第二句就知道你用了什么数据读完第三句就能看到你的核心数字。很多队伍把摘要写成了“本文研究了……建立了一个模型……”全是抽象词没有具体数字这种摘要基本会被评委直接跳读。问题重述阶段不要照抄原题。把原题拆成你真正要回答的三个子问题然后用你们自己的话复述一遍。三个子问题整篇论文都会反复回扣结构就清晰了。我通常建议把“问题重述”压缩到半页以内因为评委知道题目内容他们更关心你怎样理解。6.2 灵敏度分析别等最后一天才补灵敏度分析是美赛论文里区分“做完”和“做好”的分水岭。它能回答的核心问题是你的结论有多稳。常见的做法包括给输入特征加±5%的随机噪声观察预测结果波动把缺失值填补策略从“中位数”换成“均值”看最终AUC变化把模型从随机森林换成梯度提升树看关键结论的方向是否一致多换几个随机种子报告结果方差。要注意的是灵敏度分析不是说结果一定不能变。如果扰动后结果发生了明显变化你也应该诚实地写出来并讨论可能的原因比如数据信噪比低、样本量小。评委最反感的不是不稳定的模型而是模型不稳定却假装稳定。主动把不确定性摆出来反而显得你们对数据有更深的理解。6.3 最后一天的检查清单最后一天上午所有建模和实验应该已经冻结进入写作和检查模式。我的检查清单大概长这样所有图都有坐标轴标签和单位图注能独立说明问题每一张表都有表号正文有引用不出现“见下图”这种空话模型假设至少列三条每条都能回溯到数据或物理背景公式有编号变量有定义代码压缩包能按README跑通最好有其他队友做一次“盲跑”摘要严格控制在一页以内附录里写清楚团队分工。最后留三个小时做通读此时最好让写代码的人暂时忘掉模型只负责检查排版、错别字和逻辑死角。一篇逻辑自洽、图表规范但模型普通的论文在美赛里的得分往往高于模型很强但写作混乱的论文。说实话打了这么多年数据题我自己也踩过不少数据工程的坑。最磨人的不是算法不会而是第一天没把字段字典定下来第三天发现队友用的单位还是错的。如果今年你打算认真打一次问题C我建议把“数据工程先行”刻进团队纪律里。前期多花两小时整理字段、写干净预处理代码后面至少能省出一整天。愿你们在2026年的美赛里讲出一个有说服力、能复现、也让评委信服的故事。