我们参加数学建模相关的竞赛已经有很多次了。可以说我们在初期接触它的时候并不顺利，往往都只能拿个省奖，甚至多此参赛陪跑。幸运的是我们坚持了下来，一直在比赛中摸索建模的有关技巧，也算是一些积累经验吧。

这次MathorCup数学建模比赛是我们参加的众多比赛中走的最远的一次。至于技巧当然是有一点的，但我觉得热爱和坚持很重要。因此你如果问我这个比赛容不容易获奖，我只能说去参加吧，获奖是有概率的。在你参加的过程中或者说在你训练的过程中，这个概率值会从无穷小出发呈波动式地逐渐逼近于1。

建模队伍一般是三人小队，当然也会有一人或两人的队伍。提醒一下单打独斗可是很累的。我们更倾向于三人小队，毕竟多个人多份力总归是好的。数学建模比赛的任务主要分为三个方面，建模、编程和写作。因此初期我们往往就觉得，只需要每个人学习一个方面的内容，比赛时配合好就能拿出一份很好的作品。在比赛中我们亲自体会了这种想法的愚蠢。

例如，写作手对建模手的建模思路、模型描述不到位，无形中换了一个模型；建模手不知道如何帮助编程手正确求解出结果；编程手不懂建模手的模型以致针对求解时费力；甚至求出的结果偏差太大不知道是模型的问题还是求解程序的问题等等。那么什么样的队伍才能做到较好的配合，实现1 + 1 + 1 > 3呢？

我们更倾向于三人能同时掌握建模和编程的内容，但各有所长的组队模式。我们的队伍采取建模手同时负责建模、写作和程序的大致逻辑设计，编程手负责程序的具体实现和模型讨论，写作手负责绘图、数据查找、简单数据整理、论文格式的调整美化等的任务分配模式。当然我也见过有队伍以编程手主负责写作和编程的，编程手与建模手一起建模，这就因队伍而异了。这需要队伍在训练中磨合。

比赛中我们面临的第一个任务就是选题。比赛题目一般会有多道不同类型的题目。因此队伍在训练的时候最好能找到自己擅长的两种题型，选择自己擅长的题型肯定会较为顺手。我们队伍的建模手擅长于物理题，编程手更偏好于数据分析题。如果物化题可实施性更高，我们会以建模手为主去进行解题，相反就以编程手为主去解题。

半路换题就等于宣判死刑。因此我们更喜欢在拿到题后的第一天去细读可选的每一道题，然后集体讨论不同题目大致需要建立什么模型、什么算法能用来求解、求解的难点在哪、实施的可行性等等，然后选择一道自己擅长的、可求解性更高的题目。

接下来我们会对选定的这道题的每一小题从头到尾去进行分析，比如这次MathorCup数学建模比赛的A题，它需要我们使用QUBO模型去研究信用评分卡的组合策略，那么我们就要思考如何根据已知信息去搭建模型（如何去设置变量，又如何构建变量之间的函数映射关系），怎样让搭建的模型转化为题目要求QUBO模型形式，怎样去求解拿到理想的组合方案，如何去说明拿到的组合方案是最佳的，如何在设计模型或算法中体现自己的特色（求解速度、精度、模型复杂度）等等，直到我们一步步打通了整个问题思路，我们才会着手去具体的实现。当然因为比赛时间有限（3-4天），这些工作需要我们在一天内完成。

我们参加的比赛叫数学建模比赛，因为模型的好坏在评判我们作品的质量时占有较大比重。那么什么样的模型才是好模型呢？我们在刚接触时一直盲目追求复杂的模型和高深算法，但慢慢我们发现复杂的模型或算法不一定好，简单的模型或算法不一定不好。

还以这次MathorCup数学建模比赛的A题举例吧——如果我们要求解10个信用评分卡组合，显然直接枚举是一个很不错的算法；但如果我们要求解1000个信用评分卡组合，这时枚举法就受限于时间成本被考虑的优先级降低，需要我们使用一些启发式算法（遗传算法、模拟退火、粒子群算法等等）；那如果我们要求解100个信用评分卡组合，这时我们就要衡量一下他们之间使用的优先级次序了。

因此在建模时，在一定精度下让模型简单化才是我们的改进方向，选择算法时对于时间成本和结果精度权衡才是关键所在，再者就是我们设计的模型或算法普适性如何等等。当然这只是我们对于模型的理解。

这次MathorCup数学建模比赛的参赛对我们来说收了很多知识，获得了较好的锻炼。同时也十分感谢组委会，给我们这次分享的机会，谈不上经验，一点参赛的体会，希望能对即将参加或是计划参加MathorCup数学建模比赛的同学有所帮助，并祝愿大家能够在比赛中取得优异的成绩，获得不同的收获！