2023年那场“华为杯”中国研究生数学建模竞赛到现在我还能记得最后一天凌晨三点的画面电脑风扇嗡嗡转桌上三杯咖啡排成一排群里突然弹出一句“验证集过了”三个人几乎同时松了口气。后来成绩出来国一。这段时间不少学弟学妹来问准备经验问问题目怎么选、论文怎么写、队友怎么分工。趁着对细节还有记忆我把第二十届研赛的完整参赛过程做一次复盘不讲虚的只讲我们实际踩过的路、调过的参、熬过的夜以及那些事后想起来“如果早点知道就好了”的坑。数学建模竞赛和单纯编程比赛不一样它考的是问题拆解、数学抽象、工程实现、写作表达四件事的叠加态。拿一等奖的团队不一定每个维度都顶尖但一定做到了整体平衡没有明显短板。这篇复盘适合两类人看一类是第一次想冲奖、还在纠结怎么组队和训练的新手另一类是已经参赛但总觉得“差一点”的老手希望能帮你把最后那一点补上。1. 赛前准备团队是怎么搭起来并真正磨合好的1.1 队员分工不是按“数学、编程、写作”简单切大多数人都听过“建模比赛三人分工一人建模、一人编程、一人写论文”但真实参赛后你会发现这么切基本活不过第二天。真正高效的团队是所有人都要能建模所有人都要能分析数据只是各自有所长。我们当时的配置是这样的A同学擅长统计模型和算法实现负责主模型框架和核心代码B同学熟悉运筹优化和数值计算负责关键公式推导和备选模型验证我负责数据清洗、可视化、论文主笔同时充当“产品经理”——每天早中晚对齐一次把讨论结果变成文字稿。这种分工的好处是无论哪个人临时卡住另外两个人能马上补位。备赛时我们练过几次完整模拟发现一个规律**写论文的人如果完全不懂代码会被队友口头描述带偏编程的人如果完全不碰论文最后摘要里的方法描述会和实际代码对不上。**所以我们约定论文里每个核心公式必须由写代码的人复核一遍每个模型的输入输出必须由写论文的人跑一遍测试数据。这个习惯在最后交卷前救了我们一次后面会细说。1.2 赛前训练我们到底练了什么很多队伍赛前喜欢刷大量题目但我们更倾向于做“深度复盘式训练”。大概提前三个月每周拿出完整两天按真实比赛节奏模拟周五晚上六点拿到题周日晚上八点提交。每次模拟不追求做出完整的国奖级论文只固定练四件事。第一是快速读题和选题。九十秒内用一句话说出每道题“要我解决什么问题、给的什么数据、需要输出什么结果”然后按“数据可得性、方法熟悉度、工作量预算”排序。第二是数据探索的标准化流程先看缺失、看分布、看相关性、看量纲把这四步固化成模板避免拿到数据后想到哪算哪。第三是摘要倒逼式写作模拟结束前三个小时不管模型做没做完先把摘要写出来逼着团队把问题、方法、结果讲清楚。第四是**“冗余方案”储备**每道题都会多准备一个备选模型如果主力模型数据跑崩了立刻有Plan B。这套训练不能说一定能拿奖但至少让我们在正式比赛时遇到突发状况不慌。比如正式比赛第二天数据质量比预想差很多我们直接套用了训练时总结的清洗模板十分钟就梳理出问题而不是当场干瞪眼。2. 赛题分析拿到题目后的前三个小时决定成败2.1 读题与分类筛选如何快速判断“能不能做”正式比赛那天赛题一放出来我们先把所有题目浏览了一遍没有急着做任何一道。研究生数学建模的题目通常信息量很大第一眼觉得“能做”不代表真能做第一眼觉得“看不懂”也可能只是题目包装复杂。我们给自己定了一个标准如果一个题目可以用三句话向队友讲清楚“要预测什么、已知什么、约束是什么”这个题目就纳入候选如果讲不清楚哪怕感觉再简单也暂时放下。那一年我们最终选的是偏数据挖掘与运筹优化结合的题目具体题号不展开说但它的共性是数据量大、业务背景强、目标函数需要自己定义。这种题的优点是有大量现成算法可以组合缺点是容易陷入“为调参而调参”的泥潭。我们做完初步分类后对候选题目做了一次评分表评分项包括问题结构化程度、团队相关经验、数据规模可处理性、结果量化难度、文献熟悉程度。每个维度打1到5分最后选中的不是得分最高的而是“下限最高”的——即使模型做得一般也能通过严谨的分析框架拿到基础分。这里想强调一个容易被忽视的点**不要因为喜欢某个算法而选题目要因为题目适合某个算法而选。**有队伍看到题目可以用深度学习就觉得高大上结果数据量小、标注混乱训练出来的模型根本没法解释论文里怎么写都圆不回来。我们选的原则是“方法复杂度匹配问题复杂度”优先保证逻辑自洽。2.2 破题思路的收敛从发散到建立主线选定题目后的第一晚我们没有直接写代码而是花了大约三个小时做破题主线图。大白纸上画一条主流程从原始数据出发经过哪几个模块得到哪些中间结果最后如何输出方案。旁边写上每个模块可用的候选方法以及相应的风险点。比如如果第一步是分类我们会在纸上写“逻辑回归/SVM/随机森林/XGBoost——优先XGBoost但必须做特征标准化和缺失值处理”。如果中间有一个优化问题我们会写“线性规划/整数规划/启发式算法——先跑小规模精确解再上大邻域搜索”。这个图纸就是整个团队的方向盘后面三天所有讨论都围绕它展开。即使有人提出更炫酷的模型如果不在主线上也只记录进“备选池”不打断当前推进节奏。这个过程最重要的一点是尽早定义“提交什么”。竞赛论文不是实验报告必须有明确的“输入—输出”关系。很多队伍输在花了大量时间做探索性分析结果论文里堆了十几个图表却找不到一条完整的解题逻辑。我们的做法是以终为始先假装已经要写摘要了把“问题定义、采用方法、主要结果”先写个粗糙版本再反推需要做哪些实验。主线定下来之后剩下的事情其实都是执行。3. 核心建模与实现真正拉开差距的是工程能力3.1 数据清洗与特征构建第一道坑如果数据是干净的那所有队伍差距不大但研赛题目里的数据永远是“半脏”的。我们遇到过时间戳格式不统一、重复采样、单位混用、缺失值超过百分之三十、异常点群聚等现象。这一届也一样原始数据里明显包含了大量噪声。数据清洗我们固化为五步第一步做字段级探索记录每个特征的类型、缺失比例、分布形状第二步做时间对齐把所有表按主键和时点统一第三步做异常值过滤先通过箱线图和百分位粗略定位再结合业务逻辑判断是真实极端值还是采集错误第四步做缺失值填补区分随机缺失和结构化缺失前者用中位数或插值后者用分组填充或直接删除第五步做量纲处理能归一化就归一化。这个流程看起来简单但能保证我们不在数据层面浪费过多争论。特征构建上我们坚持一个原则**优先做“可解释的强特征”再叠加模型自动发现的复杂交互。**比如很多时序数据的统计量滑动均值、滑动方差、滞后差分、周期分量都是先手工构建出来放进模型看重要性有效就保留。这样做的好处是论文里可以清楚地写“基于业务理解构建了特征”而不是一句“模型自动学习特征”带过。特征数量并不是越多越好我们最终保留的特征大约二十个左右核心模型用XGBoost和LightGBM做筛选再用简单模型做对照确保没有某个高重要性特征纯粹因为泄漏而被选中。这里特别想提醒**特征泄漏是研赛最常见的隐蔽错误之一。**我们第一天构建特征时不小心把一个“未来时间段才产生的统计量”用到了当前样本的预测中结果验证集表现异常高。后来检查逻辑才发现论文里如果保留这个结果评委一眼就能看出不合理。排查泄漏的方法是对每个特征问一句“在真实预测场景中这一时刻我是否已经能拿到这个数字”不能就是泄漏。3.2 算法选型与模型融合按“解题链”组织数学建模竞赛不是单模型PK现场而是解题链的组合。我们这一题的解题链大致是数据预处理 - 目标函数定义 - 关键变量预测 - 优化方案求解 - 结果评估。每一环选择的算法都以前后衔接为主要考量而不是单独追求性能。在“关键变量预测”环节我们同时跑了线性回归、随机森林、XGBoost、LightGBM和一个带LSTM的序列模型用同样的特征和训练验证集做对比。结果显示树模型集成明显优于其他模型LSTM因为数据量不够反而过拟合。但我们没有直接扔掉LSTM而是把它当成另一个视角的“特征提取器”把它的中间隐层输出拼到树模型的特征里效果又提升了一点。这就是“异构特征融合”写论文时是一个很好的亮点。在“优化求解”环节题目里涉及一个组合优化问题规模不大也不小。我们先写了一个精确的整数规划模型用小规模样例验证正确性然后发现全量数据跑不动。接下来没有直接硬调求解器参数而是设计了一个“先聚类再加约束削减”的启发式框架把大问题拆成多个子区域每个子区域求出局部最优解再通过边界协调得到全局可行解。这个做法在论文里非常有说服力因为它体现了从精确方法到近似方法的完整演进过程评委会认为你懂优化。3.3 调参与验证避免过拟合的实操细节调参环节我们用的是最朴素有效的方法网格搜索 5折交叉验证 手工微调。第一轮先用粗粒度网格锁定最优参数的大致范围第二轮用细粒度网格继续搜索第三轮根据验证集误差曲线手工调整学习率和树深度。整个过程记录在共享表格里每一组实验都保留日志和结果方便最后写实验对比。但真正让我们拿到好成绩的关键不是调参技巧而是严格的时间序列验证方式。如果题目数据带时间先后顺序一律按照时间划分训练集和验证集绝不做随机打乱。即使模型内部有交叉验证也要保证交叉验证的分割方式尊重时间顺序。很多队伍在这里栽跟头随机打乱数据导致的“验证集虚高”最终在测试集上现原形。我们还会刻意保留一个“最终验证集”放在所有调参结束之后只用一次。这是为了模拟真实竞赛的测评环境避免在验证集上调参过多次造成隐式过拟合。最后一次验证分数比调参过程的最好分数低大约百分之二但这是正常的论文里如实写反而显得严谨。4. 论文写作与图表呈现阅卷老师的前30秒4.1 摘要写法一句话讲清问题、方法、结果数学建模竞赛的论文评审强度很高一个老师可能要看好几十份论文最多几分钟就要完成初筛。所以摘要基本决定了第一印象。我们的摘要改了不下十版最终结构固定为第一段讲现实背景和问题第二段概述整体建模思路按解题链顺序列出一二三个核心方法第三段给出关键定量结果最后一句说明模型推广性。字数控制在八百字左右不允许出现“本文”“我们大概”“可能”之类的模糊词。每一句话都要有信息量。比如“采用改进的XGBoost模型”这句话很多队伍会写但我们不写因为我们没有发明新的XGBoost。正确写法是“在XGBoost框架中引入滞后特征和区域聚类约束”这样评委一眼知道你做了什么具体工作。另外摘要里的数字必须和正文完全一致。我们会在最后一天专门安排一个人对数字每个表的统计量、每张图标的MSE或准确率逐项核对。看起来简单却是最容易翻车的地方。如果正文里的结果和摘要差一位小数评委一定会认为整个工作都不可靠。4.2 图表规范化让评审不需要看正文也能懂我们的目标是**任何一页图表单独拿出来都能让人看懂“坐标是什么、结论是什么”。**为此我们做了几条硬性规定。图必须有完整标题包含目标、方法、数据集坐标轴必须有单位多组比较图必须统一配色和量纲散点图必须标注相关系数或趋势线。表格一律用三线表重要数字加粗必要时在表注中解释统计检验结果。可视化工具我们主要用Python的Matplotlib和Seaborn偶尔用R的ggplot2画时间序列。配色选了一套红蓝对比的方案考虑到部分读者可能是色盲不用红绿搭配。字号统一在10到12之间确保打印清晰。每个图表生成后还会有一次“盲读测试”让团队里另一名成员不看正文只看图表的标题和图例复述这张图说明了什么。如果复述内容和本意不符这张图必须重画。最花时间的其实是“结果对比图”。我们会把不同模型的效果画在同一张图里用误差棒或箱线图展示稳定性并且加上一条垂直虚线表示业务目标基线。这样的图比放十个单独的图表更有效因为评委能直观看到“你的方法优于什么”。4.3 论文里的“逻辑链”比华丽词藻更重要很多队伍喜欢用大段文字解释算法原理仿佛把支持向量机的公式抄一遍就能加分。实际上评委更关心你对问题的理解和你的方案为什么有效。我们论文正文的每个方法介绍都遵循同一个模板这个方法要解决什么问题 - 为什么适用这个问题 - 模型的关键假设和适用条件 - 我们的具体改进。每个实验章节也是如此实验设置 - 评价指标 - 结果 - 结果分析 - 对后续环节的影响。这样写出来的论文像一条清晰的证据链而不是算法的堆砌。特别要注意的是一定要写“为什么不用其他方法”。比如我们明确写了“由于数据量较小且噪声较高未采用深度学习方法而是选择具有较好可解释性的集成树模型”这句话能直接回应部分评委心中的疑问也能显示你对方法边界有清醒认知。比单纯吹嘘效果要高明得多。5. 踩过的坑与排查实录5.1 时间失控的典型复盘第一天的节奏还算正常真正失控发生在第二天下午。我们原计划晚上六点完成特征构建但发现某个关键数据表存在严重的对齐问题一修就是三个小时。这时候如果继续硬写特征就会挤占后续模型训练的时间。我们的纠偏动作是立刻把“从全量建模”降级为“先跑通小规模子集上的完整流程”用百分之二十的数据把所有代码跑通确认结果格式正确再在当晚后台启动全量训练。这样既保证了主流程不阻塞又留出时间修数据。事后复盘发现几乎所有出问题的点都来自“数据与假设不一致”。比如我们以为某字段是整型实际读入后出现了空字符串和科学计数法混用。这也提醒我们数据探索阶段一定要做dtypes和unique检查不能只看前五行就默认格式正常。5.2 计算资源与崩溃恢复从“跑崩了”到“幸好有备份”我们队伍主要用本地GPU训练同时备用一台云服务器做验证实验。第二天凌晨跑深度学习序列模型时显存直接爆掉进程被杀。由于没有及时保存中间权重重新训练浪费了三个小时。这次教训之后我们定下规矩凡是超过十分钟的训练任务必须每五分钟保存一次checkpoint任何实验脚本在跑全量前先跑一个最小样例验证数据流和维度匹配。此外代码版本控制也相当重要。我们使用Git和私有的代码仓库每天结束前强制把当天所有脚本、结果图表、论文草稿提交一次。不是说要做什么花哨的CI/CD而是确保任何人电脑突然死机另一台电脑能立刻接管。第三天上午队友电脑蓝屏我们只花了十几分钟在新电脑上拉代码继续推进没有崩溃。5.3 协作与沟通论“留痕”的重要性比赛过程中最容易出现的分歧是“我觉得这个模型更好”“但我跑出来效果一般”。一开始我们靠口头争论后来改成“实验记录表”每一组实验都登记时间、模型、参数、验证集分数、代码路径、结论。分歧出现时不靠吵架靠数据。谁主张换方法谁就去跑一个快速实验把结果贴到共享表格里。这样做看似多花了时间实际上避免了大量无效争论。另一个坑是“以为队友懂了”。我经常遇到的情况是A同学说他理解了B同学的公式但写进论文时发现符号和变量定义完全对不上。后来我们强制要求**任何重要公式的传递都必须经过“复述”环节。**懂的人用自己的话讲一遍对方确认无误后再写入论文。讲不清楚的公式要么是没人懂要么是容易出错绝不能蒙混进论文。6. 关于一等奖的个人体会与扩展建议回头再看这次拿一等奖的经历我最大的感受是数学建模竞赛拼到最后拼的不是灵光一现而是谁的系统更少出错、谁的时间线更有弹性、谁的论文更让人信服。我们队伍里没有所谓天才型选手三个人的单项能力都算不上特别突出但组合在一起靠流程和复盘赢了下来。把这套方法论沉淀下来无论以后做科研还是工作都是极其宝贵的经验。如果让我给准备参赛的团队一个最核心的建议那就是**从第一天起就把“最终论文”当成唯一的产品来打磨。**所有实验、代码、图表、公式都是为了支撑这篇论文。建模到一半发现论文无处下笔大概率是建模思路本身出了问题要及时回头调整。另外我想延续一个小技巧最后两个小时不要安排任何新实验。把所有代码跑一遍主线流程确认每个图表的数字可以被复现再检查一次页码、附录、引用格式。我们最后一小时只做了一件事——用一台干净的笔记本电脑按论文描述重新跑了一遍关键脚本确认没有代码路径依赖。这个动作让我和队友在交卷前一刻非常安心。如果有人问什么才是“稳”我觉得这个动作就是稳。
