Title: 我用 DeepSeek 网页版拿下 KDD Cup 冠军！ | BestBlogs.dev
URL Source: https://www.bestblogs.dev/article/f85a8552fc?amp%3Butm_medium=feed&%3Butm_campaign=resources&%3Bentry=rss_article_item
Published Time: 2026-08-10 22:01:00
Markdown Content: 原创 无敌叉烧包 2026-08-10 22:01 浙江
Datawhale干货 作者：无敌叉烧包**，Kaggle全球排名第一****
作者 目前位列 Kaggle 全球第一，现阶段主要关注 Agent 自动化建模的能力边界与实践难点。本次比赛由作者与队友共同参赛；队友曾在国内算法竞赛中累计获得 15 次冠军，也是上上届 TAAC 冠军。本文重点复盘作者使用 DeepSeek 完成建模与代码迭代的部分。
参加 KDD Cup 的初心
TAAC 一直是国内参赛规模非常夸张的算法赛事，对我也有特殊意义。第一次参赛时，我甚至才刚开始使用 NumPy 和 Pandas，靠着疯狂过拟合公榜一度冲进前十，最后又因为泛化不足掉了下来；好在队友提前做了防过拟合处理，排名才没有跌得太离谱。对一个非科班出身的人来说，那次比赛几乎是我算法竞赛生涯的起点，也在很大程度上帮助我后来进入了算法行业。
这一次参加 TAAC × KDD Cup 2026，主要有三个原因。
第一个原因，是在登顶 Kaggle 世界第一并连续保持这一排名约一年后，我开始把更多精力从亲自建模转向自动建模 Agent。过去这一年里，我已经很少再亲自从头建模，很多时候甚至会把“下一步应该尝试什么”也交给 Agent 自己思考，再通过实验结果筛选方向。我的长期目标，是构造一个能够自主参加真实 Kaggle 比赛，并依靠自身的理解、实验和决策能力登顶 Kaggle 世界排名第一的 Agent。
这次比赛还不是对完全自主 Agent 的验证。作为初期探索，我先通过 Vibe Coding 检验一个更基础的前提：在人负责把握研究方向和判断实验结果的情况下，大模型能否独立承担比赛中的主要代码工作。TAAC 的真实工业数据和严格复现要求，正适合作为练兵场。
第二个原因，是我一直听说 KDD Cup，却从未真正参加。这次 TAAC 与 KDD Cup 联合举办，赛事规模和奖金都足够有吸引力，对我来说是一次难得的机会，也可能是我最后一次认真参加这种周期较长的大型算法竞赛。
第三个原因，是我想验证：国产大模型能否不依赖国外旗舰模型，独立支撑一套冠军级工作流。比赛中很多选手晒出了 GPT、Claude 的 Token 用量，而我的建模、代码开发和实验迭代始终只使用 DeepSeek 网页版，没有调用 API，也没有在多个模 型之间切换。技术论文主要由 DeepSeek 辅助完成，GPT 只在最终提交前参与语言润色，随后再由我人工审核。
这不是一次严格控制变量的模型横向测评，但至少说明：是否使用最昂贵的国外旗舰模型，并不是决定最终上限的唯一 因素。国产大模型同样可以完成复杂代码工作，并支撑一套最终夺冠的竞赛流程。
最终结果：KDD Cup 2026 Tencent UniRec Challenge 工业赛道冠军
阅读导航
* ### 比赛与数据：这届比赛的规模、任务、数据和计算资源；
* ### 第一个工程验证：DeepSeek 如何解决多卡 batch size 不一致；
* ### QueryFormer 冠军方案：先看结论和证据，再进入五步技术细节；
* ### DeepSeek 实际工作流：人与大模型如何分工并形成实验闭环；
* ### 训练、论文与结语：MuonPlus、复现材料以及这次尝试的边界；
* ### 文末彩蛋：比赛开始前两个月，我就提前庆祝了——15w usd get。至于当时发生了什么，文末见。
今天颁奖现场实拍，我是sunshot团队
一般读者可以重点阅读结果、比赛介绍、工程案例、DeepSeek 工作流和文末彩蛋；希望复现或研究方案的读者，则可以继续阅读 QueryFormer 的消融实验与完整技术细节。
一、比赛与数据
2026 年，TAAC 与 KDD Cup 联合推出KDD Cup 2026 Tencent UniRec Challenge，将工业推荐系统中最核心、也最难公开复现的问题之一搬上了竞赛平台：在真实规模的腾讯广告数据上完成转化率预测（pCVR），判断用户点击广告后是否会进一步产生转化。
参赛规模可以先简单交代一下。本届赛事吸引了来自52 个国家和地区的 13,913 名选手，组成5,746 支队伍，覆盖全球907 所院校，学术界与工业界参赛者约占7:3。产业侧有快手KuaiRec相关团队、美团专业推荐团队和NVIDIA派出的多支队伍，也有来自Meta的资深推荐算法专家。换句话说，这不只是一场学生算法竞赛，对手里还有大量每天处理真实推荐流量的工业团队。（这组数字来自整届赛事的报名统计，并非工业赛道单独的有效参赛人数。）
不过真正决定这场比赛难度的，是赛题本身和它背后的数据。
赛题：把序列建模和特征交互统一起来
比赛主题是：
Towards Unifying Sequence Modeling and Feature Interaction for Large-scale Recommendation
简单来说，模型既要处理用户、广告和上下文之间复杂的特征交叉，也要从历史行为序列中识别用户兴趣。赛题希望参赛者打破两类信息分别建模、最后拼接的传统方式，探索一种可以统一处理序列与非序列特征的可堆叠架构。
比赛以ROC-AUC为主要指标，同时严格限制推理延迟并禁止模型融合。最终队伍还需要提交完整的训练代码、推理代码和技术报告，接受比赛方的复现检查。因此，方案不仅要准确，还必须收敛为一个能够在规定时间内完成推理的单模型。
数据：3500 万条样本、142 个字段、4 个业务域
比赛使用经过匿名化处理的腾讯广告业务数据，以 Parquet 格式存储。复赛训练集约有3500 万条样本、142 个特征字段，主要包括：
* 用户侧的离散特征和稠密特征；
* 广告侧的离散特征和稠密特征；
* 用户 ID、广告 ID 与时间信息；
* 来自 4 个不同业务域的用户行为序列；
* 是否转化、转化类型与转化时间等标签。
其中，离散特征包含大量高基数 ID，行为序列则记录了用户在不同业务域中的历史行为及其发生时间。所有字段均已匿名化，参赛者无法得知其对应的真实业务含义。这也是它和多数公开数据集竞赛不同的地方：样本量、字段数和 ID 分布都来自真实广告业务，但特征含义完全不可见，只能靠结构设计和实验结果去判断该怎么用。
平台与资源：数据不出平台，7 张卡
比赛统一在 AngelML 平台上进行，数据不能下载到本地，训练、推理和提交都需要在平台内完成。复赛阶段，我实际可以使用7 张 GPU：通常用 6 张卡进行分布式训练和消融实验，保留 1 张卡负责推理与提交，让模型训练和线上验证可以并行进行。
二、第一个工程验证：多卡 batch size 不一致
比赛方提供了一套高效且正确的 Baseline，已经打通数据读取、分布式训练和结果提交等基本流程，让我们可以直接进入实验。比赛第一天，我主要测试 batch size、torch.compile和 bfloat16 对训练效率的影响。
接入torch.compile时首先遇到了一个工程问题：DDP 中每张 GPU 读取的 Parquet Row Group 样本数不同，部分 GPU 会产生尺寸不足的 batch；输入形状变化又可能触发报错或重复编译，抵消编译加速的收益。
我的处理方式很直接：将完整的dataset.py、运行报错和修改目标一起交给 DeepSeek，并要求它返回一份可以直接替换的完整代码。
!Image 5: 请求 DeepSeek 将固定 batch size 机制迁移到多卡代码
DeepSeek 无法访问服务器或自行运行代码，只能看到我复制进去的上下文。它仍然识别出需要把carry机制迁移到 DDP 数据管线：使用buffer合并读取结果，只输出尺寸完整的 batch，剩余样本交给下一轮继续拼接。
核心流程可以简化为：
将 Row Group 贪心分配给当前数据量最少的 GPU
每张 GPU：
carry = 空
for 原始 batch：
merged = carry + 当前 batch
输出 merged 中所有完整 batch
carry = 剩余样本
丢弃最终仍不足一个 batch 的少量样本
使用 DDP Join 处理不同 GPU 的步数差异
大部分零散样本都会通过carry保留，只有遍历结束时仍不足一个 batch 的少量样本被丢弃。Row Group 的贪心分配用于平衡各卡数据量，DDPJoin则避免个别 GPU 提前结束后出现同步死锁。
修改后的代码保持了固定输入形状，解决了torch.compile的重复编译问题，实际运行效率也很高。更重要的是，它在比赛第一天验证了一个关键前提：即使没有终端和 Agent 能力，DeepSeek 网页版仍能在获得完整上下文后，完成涉及数据缓存、批次对齐和多卡训练的代码修改。
三、QueryFormer 冠军方案
先说结论
一句话概括 QueryFormer：先让用户、广告和非序列特征充分交互，形成质量更高的 Query，再用这些 Query 从多域行为序列中提取与当前广告最相关的信息。 !Image 6: QueryFormer 模型整体结构
模型从用户、广告、Dense 特征和多域行为序列中生成不同类型的 Token。左侧的 CoTransformerBlock 完成用户侧、广告侧以及两者之间的交互；中间的 QuerySeqCrossAttn 使用更新后的 Query 检索行为序列；右侧的 SeqQueryCrossAttn 则从序列生成初始 Query，再读取非序列信息。多列 Embedding Matrix 使用多套独立的 Tokenization Pipeline，从同一输入中学习不同视角的 Query 表示。
这些结构的代码和实验实现全部交给了 DeepSeek 网页版。我负责观察 Baseline、提出研究问题、确定实验方向并判断结果，DeepSeek 负责把思路转换成可以运行的完整模型代码。
设计依据：为什么优化 Query？
官方 Baseline 已经使用 Cross-Attention 从行为序列中提取信息，但 Query 主要由较简单的 MLP 投影生成。序列可以被理解为一个信息库，而 Query 决定模型从中读取什么；如果 Query 的质量不足，再长的行为序列也未必能转化成有效信息。
比赛期间，我重点参考了 EST 和 RankElastor。EST 的实验表明，非序列特征作为 Query 与行为序列交互，是统一推荐模型中最重要的信息传递通道之一。RankElastor 则从有效秩和表示坍塌的角度说明，扩大模型容量不能只依赖增加参数，还需要关注不同表示空间能否保持足够的表达能力。
因此，后续实验集中在一个问题上：能否在不显著增加序列建模成本的前提下，生成质量更高的 Query？这个问题最终构成了 QueryFormer 的核心。
证据：主要优化与消融结果
先用一张表概括最终保留的主要改动，再展开具体实现。
这些优化分别作用于 Query 的输入质量、生成与更新方式以及容量扩展。分别移除 4 个核心 Attention 模块造成的 AUC 损失之和为 0.00110，同时移除 4 个模块时同样下降 0.00110。这一现象与各模块负责不同阶段、收益没有明显重叠的设计预期一致，但不能单凭一次消融严格证明模块之间完全独立。
哪些实验没有进入最终方案？
并不是所有看起来合理的方向都带来了收益。
* 增加行为序列长度没有提升验证集表现，反而明显拖慢训练。更长的历史并不等于更多有效信息，也进一步支持了我们优先提高 Query 检索质量、而不是继续堆叠序列长度的选择。
* 增大 hidden_dim 会让模型收敛显著变快，最终效果也会变好。但这属于直接增加参数量和计算量的路线。为了让方案尽可能克制，也为了把收益集中在结构设计而不是暴力扩参上，我们直到最终都没有大幅增加模型参数。
* 将 Embedding Matrix 从 H=4 增加到 H=8仍有小幅提升，但边际收益已经明显下降，因此最终主配置选择了效果与效率更均衡的 H=4。
这些没有被保留或被克制使用的实验，同样构成了最终方案的一部分：它们帮助我们确认，比赛中的主要瓶颈并不是序列不够长或模型不够大，而是 Query 没有被充分建模。
细节：QueryFormer 的五步优化
下面按照实际实验顺序，介绍这些结构是如何逐步加入方案的。
#### 第一步：重新组织非序列特征
确定优化 Query 侧之后，首先需要解决的问题是：应该用什么样的非序列信息来生成 Query？
根据公开研究和工业实践，一个常见而有效的技巧，是将含义相近的非序列特征放在同一组中处理，再把每组特征映射成独立的 Token。这样可以尽量保留相关特征之间的局部关系，避免所有特征在进入模型时就被完全打散。
官方 Baseline 本身也支持这种模式。它提供了另一组参数，可以通过GroupNSTokenizer将相关的用户特征和广告特征分别组合，再将每一组投影成一个非序列 Token。
复赛阶段，比赛方新增了多组 Dense Embedding 特征。这些特征本身带来了不小的提升，但官方 Baseline 对 Dense 特征的处理相对直接：先将它们拼接在一起，再通过一个统一的 MLP 映射成表示。
问题在于，这些 Dense Embedding 并不一定来自同一种信息。虽然我们无法知道匿名字段具体对应什么业务含义，但从官方保留的字段边界和向量维度来看，它们显然由多组不同来源的向量组成。
如果将所有向量完全混合后交给一个 MLP，模型就需要同时学习组内关系、组间关系和不同来源特征的数值分布，可能会损失原有的结构信息。
因此，我们没有继续将所有 Dense 特征视为一个整体，而是按照它们原本的字段边界拆分成多组，分别进行处理。每一组 Dense Embedding 独立生成一个 Token，再将这些 Token 送入后续的 Query 交互模块。
在设计这部分结构时，我将 Dense 特征的维度、分组方式和现有模型代码提供给 DeepSeek，让它提出适合处理多源稠密特征的模块。
DeepSeek 给出了多种候选方案，我再通过实际实验逐一验证，最终选择了效果最好的DCN-V2。
因此，我们将不同来源的 Dense Embedding 按照原始字段边界拆分成多组，再分别使用 DCN-V2 进行处理，为每组特征生成独立的 Token。这样既保留了不同 Dense 特征原本的分组结构，也增强了模型对组内特征交互的建模能力。
完成非序列特征分组和 Dense 特征处理之后，我们的方案已经具备了最终榜单前五名的竞争力。
这次实验也进一步验证了此前的判断：Query 侧的提升不仅取决于后续使用什么 Attention，也取决于输入 Query 模块的非序列 Token 是否得到了合理组织。
#### 第二步：让用户和广告信息先充分交互
完成非序列特征的组织之后，下一步是提升 Query 本身的信息质量。
官方 Baseline 中的 Query 生成方式相对简单。用户、广告和上下文信息经过投影后，便被用于读取用户行为序列。在这个过程中，同一类 Token 之间以及用户 Token 与广告 Token 之间的交互仍然不够充分。
但在转化率预测任务中，用户和广告之间的匹配关系非常重要。同一个用户面对不同广告时，模型应该关注不同的历史行为；同一个广告面对不同用户时，对应的有效兴趣信号也会发生变化。
因此，我们首先加入了QuerySelfAttn。
QuerySelfAttn 分别在用户 Token 和广告 Token 内部进行 Self-Attention，让每个 Token 在进入后续交互之前，先感知同一侧的其他信息。
例如，一个用户特征不再只是孤立地表示某个匿名字段，而是可以结合其他用户特征共同形成上下文；广告侧的不同 Token 也可以先完成一次内部信息融合。
随后，我们加入了QueryCrossAttn，让用户 Token 和广告 Token 之间进行 Cross-Attention。
它的目标是让 Query 在读取历史行为之前，先明确当前任务中的两个核心对象：这是一个什么样的用户，以及当前需要预测的是一个什么样的广告。
消融实验显示，移除 QuerySelfAttn 后，验证集 AUC 下降了 0.00020；移除 QueryCrossAttn 后，验证集 AUC 下降了 0.00029。
这说明，无论是同类 Token 内部的信息交互，还是用户与广告之间的交互，都能够为后续的序列检索提供有效增益。
#### 第三步：让 Query 更准确地读取行为序列
有了包含用户和广告上下文的 Query 之后，下一步是使用它从用户行为序列中提取真正相关的信息。
我们为此加入了QuerySeqCrossAttn。
它使用广告侧的 Query 对用户历史行为序列进行 Cross-Attention，从 4 个业务域的行为中检索与当前广告最相关的部分。
这与简单地对整段序列进行平均池化不同。平均池化会把所有行为压缩到同一个向量中，而 QuerySeqCrossAttn 会根据当前广告动态决定应该关注哪些历史行为。
同一个用户面对不同广告时，即使输入的行为序列完全相同，模型提取出来的序列表示也可以不同。
移除 QuerySeqCrossAttn 后，验证集 AUC 下降了 0.00023，说明目标相关的序列检索确实是模型效果的重要来源。
#### 第四步：使用 Cross-Attention 生成 Query
前面的模块都在不断丰富 Query，但官方 Baseline 的初始 Query 依然主要通过 MLP 生成。
MLP 可以融合输入信息，但它的处理方式相对固定。对于每条样本，它都使用同一套投影规则生成 Query，缺少显式的信息选择过程。
因此，我们设计了SeqQueryCrossAttn，使用 Cross-Attention 代替简单的 MLP Query 生成方式。
具体来说，我们首先从每个行为序列中提取初始表示，再让这些初始 Query 通过 Cross-Attention 主动读取经过更新的非序列 Token。
这样生成的 Query 不再只是固定投影的结果，而是可以根据当前用户、广告、上下文和行为序列动态决定需要提取什么信息。
从消融结果来看，将 SeqQueryCrossAttn 替换回 MLP 后，验证集 AUC 从 0.84606 下降到 0.84568，下降了 0.00038，是 4 个核心 Attention 模块中影响最大的一项。
更有意思的是，两种 Query 生成方式在训练前期的差距并没有那么明显。但随着训练继续，MLP 版本在第三个 epoch 后开始退化，而 Cross-Attention 版本仍然可以继续提升。
这一现象表明 Cross-Attention 版本在训练后期表现得更加稳定，也与“动态读取当前样本信息”的设计预期一致；具体原因仍需要进一步实验验证。
#### 第五步：使用多列 Embedding Matrix 扩展 Query
完成 Query 生成与交互结构的设计之后，我们继续思考另一个问题：如何在不简单堆叠模型深度的情况下，进一步扩大 Query 的表达能力？
最终采用的方法，是引入多列Embedding Matrix。
传统结构通常只使用一套 Tokenization Pipeline，将输入特征映射成一组 Token。我们的方案则使用H套相互独立的 Tokenization Pipeline，让它们从同一份输入中生成多组不同的表示。
这些不同列看到的是相同的原始特征，但拥有独立的参数，因此可以学习不同的信息组织方式。可以将它们理解为多个不同视角：每一列都尝试用自己的方式组织非序列特征并生成 Query。
这些列并不是依次串行运行，而是被组织成统一的 Tensor，通过 batch-parallel 的方式一次完成计算。增加列数仍然会提高计算量，但可以更充分地利用 GPU 并行能力，比串行运行多套模型更适合比赛的推理约束。
实验结果呈现出非常稳定的 Scaling 趋势：
随着H从 1 增加到 8，验证集 AUC 持续提升，没有出现明显的性能回退。
综合模型效果和推理效率，我们最终将H=4作为主要配置。相比H=1，它将验证集 AUC 从 0.84540 提升到 0.84606，同时仍然可以满足比赛的推理效率要求。
至此，我们的完整思路已经逐渐清晰：
- 先将非序列特征合理分组；
- 使用 Self-Attention 完成用户侧和广告侧的内部交互；
- 使用 Cross-Attention 建模用户与广告之间的关系；
- 使用广告 Query 检索多域用户行为序列；
- 使用 Cross-Attention 生成更加动态的 Query；
- 使用多列 Embedding Matrix 扩展 Query 的表示视角。
四、DeepSeek 网页版的实际工作流
虽然 QueryFormer 的主要代码都由 DeepSeek 实现，但整个过程距离“完全自主 Agent”仍然有明显差距。DeepSeek 网页版无法访问比赛服务器，也不能直接读取文件、运行训练或观察 GPU 状态，因此我需要在浏览器与服务器之间搭建一条人工反馈链路。
实际工作流基本可以概括为：
我提出研究思路和实验目标
↓
将完整代码、约束条件和预期行为交给 DeepSeek
↓
DeepSeek 返回完整的可替换代码
↓
我将代码放到比赛服务器运行
↓
把报错、训练日志和实验结果反馈给 DeepSeek
↓
DeepSeek 分析问题并生成下一版代码
在这个过程中，我逐渐形成了几条比较稳定的使用习惯。
第一，尽可能提供完整上下文。相比只复制 一个报错，我通常会同时提供完整文件、报错信息、输入数据形状、运行环境和希望保留的原有功能。DeepSeek 无法主动查看项目，因此上下文是否完整，往往直接决定第一次修改能否成功。
第二，要求返回完整代码，而不是零散 Patch。网页 版无法直接修改服务器文件，如果只返回几个局部改动，人工合并时很容易遗漏依赖关系。让 DeepSeek 返回完整文件，反而更适合这种纯对话式的协作方式。
第三，一次只验证一个明确假设。我会先给出研究思路和实验目标，再让 DeepSeek 提出实现方案。代码运行后，将 AUC、LogLoss、训练速度或报错反馈给它，然后再决定下一步，而不是一次要求它同时修改大量互相影响的模块。
第四，把研究问题转化为足够具体的执行指令。这是比赛中一个很重要的观察：当完整代码、约束条件、修改目标和预期输出都已经明确时，不同头部 LLM 的执行结果往往会趋于接近。模型之间更明显的差距，通常出现在目标模糊、需要自主规划或缺少上下文的任务中；而在这种“明确需求—生成完整代码—运行反馈”的闭环里，DeepSeek 并没有表现出相较于 Opus 4.8、Fable 5 或 GPT-5.5 的明显劣势。这可能也是它能够独立支撑整套冠军方案实现的重要原因。当然，这只是比赛过程中的经验观察，并不是一次严格控制变量的模型横向评测。
第五，让实验结果而不是语言说服力做决定。DeepSeek 可以快速给出许多听起来合理的方案，但表达得自信并不代表实验一定有效。最终保留 DCN-V2、几组 Query Attention 以及多列 Embedding Matrix，依靠的都是实际实验结果，而不是模型对自己方案的解释。
因此，这次比赛中的分工非常明确：我主要负责提出研究思路、定义实验目标，并在浏览器和服务器之间传递信息；DeepSeek 负责把这些思路转换为完整代码，并根据运行反馈继续修改。它已经接管了主要的代码执行层，但实验调度、环境操作和研究方向仍然没有实现完全自动化。
五、Agent 参与得越深，方案就一定越强吗？
从目前的实践来看，不同建模方式的效果大致为：
传统人工建模 ≈ 人工研究 + Vibe Coding ＞ 人工指导方向 + Agent 自动迭代 ＞ Agent 完全自主迭代
Agent 已经能够高效完成复杂代码，但建模不只有写代码，还需要持续阅读资料、设计实验、分析日志、识别过拟合并决定下一步方向。目前 Agent 获取信息的渠道仍然有限，也缺少成熟的实验 Harness，难以独立完成从信息收集到实验决策的完整闭环。
因此，现阶段效果最好的方式仍然是：人负责研究方向和结果判断，Agent 负责代码实现与局部迭代。未来完全自主 Agent 的主要瓶颈，可能不再是代码能力，而是信息获取、实验管理和自主决策能力。
六、训练与论文
训练优化：为什么选择 MuonPlus
除了模型结构，优化器也是最终方案的重要组成部分。QueryFormer 使用MuonPlus优化 Attention、MLP 等 Dense 参数，同时保留 Adagrad 处理高基数稀疏 Embedding。
选择 MuonPlus 并非临时尝试。在此前的 CMI Sensor Data Challenge 和 NFL Big Data Bowl 2026 中，Muon 类优化器都是最终方案保留的核心训练组件：前者取得公榜、私榜双第一，后者取得公榜第一、私榜第二。它并不是获奖的唯一原因，但此前的实战结果证明了继续验证它的价值。
训练中，我们还配合使用 CosineAnnealingLR、梯度裁剪、EMA、bfloat16 和torch.compile。我负责提供此前经验、优化器方向与模型约束，DeepSeek 则完成 MuonPlus 的代码接入，并将其迁移到 QueryFormer 的双优化器训练框架中。
论文与复现材料
比赛的最终提交不只有预测结果，还需要完整的训练代码、推理代码和技术论文，并接受比赛方的复现检查。因此，在模型实验结束后，我们还需要将分散的代码、消融实验和 Scaling 结果整理成一套可以解释、复现和审查的材料。
论文的主体同样由 DeepSeek 辅助完成。我向它提供模型设计思路、实验数据、消融结果和需要强调的贡献点，由它协助整理文章结构、技术描述、实验表格和 LaTeX 内容。相比从空白文档开始写作，这种方式大幅减少了整理大量实验信息所需的时间。
不过，论文写作和代码生成面临同一个问题：语言流畅并不代表事实一定准确。模型名称、实验数字、模块关系以及结论强度都必须重新核对，否则很容易出现描述超过实验能够支持的情况。
因此，在最终提交之前，我使用 GPT 对论文进行了一次语言层面的润色，随后又进行了人工审核和修改。这里也需要明确：GPT 只参与了最终论文的表达优化，没有参与比赛中的模型设计、代码实现和实验迭代。整个建模与开发过程没有用到 GPT、Claude 写代码。
文末彩蛋：开赛前两个月先开香槟
最后放一个“半场开香槟”的彩蛋。
严格来说，我这甚至算不上半场开香槟，因为香槟开得实在太早了。2026 年 3 月 6 日，距离比赛正式开始还有接近两个月，一行比赛代码都还没写，我就提前庆祝了：15w usd get。
!Image 10: 比赛开始前约两个月提前庆祝夺冠
至于“就 get 了吗？”——当时当然还没有。模型没训练，数据没看，甚至比赛环境都还没摸清楚，奖金倒是先在想象中到账了。如果说比赛中途庆祝叫“半场开香槟”，那我这大概属于比赛还没开场，就已经在场外把香槟喝完了。
现在隔了几个月，终于可以认真补上后续：嗯，这次是真的 get 了。
从这个角度看，前面的全部内容，也可以理解为我为了不让这瓶提前两个月打开的香槟变成黑历史，做出的一系列补救工作。
结语
回到比赛开始时的问题：一个只有网页对话框、没有 API、没有终端、也没有 Agent 框架的大模型，究竟能够在真实算法竞赛中走多远？
这次比赛给出的结果是：它至少已经能够承担主要的代码实现工作。数据管线、模型模块、训练优化、错误修复以及最终方案的大部分工程实现，都可以通过“提供完整上下文—生成完整代码—运行并反馈结果”的方式完成。最终，QueryFormer 以测试集 AUC 0.83254 获得了 TAAC × KDD Cup 2026 工业赛道冠军。
这并不等于 DeepSeek 已经可以独立赢下一场比赛。它无法操作服务器，无法主动管理实验，也无法仅凭训练日志判断一个方向是否值得继续。人仍然需要提出研究问题、提供上下文、连接执行环境，并对实验结果负责。
同样，这次冠军也不是一次严格控制变量的大模型横向评测，不能简单得出 DeepSeek 在所有能力上超过 GPT 或 Claude 的结论。但它至少证明了一件更实际的事情：在一个复杂、长期、结果可以被客观排名检验的工业任务中，国产大模型已经可以独立承担主要代码工作，并支撑一套冠军级方案的实现。
对我来说，这次比赛更像是自动建模 Agent 路线的第一阶段验证。我们已经确认，大模型能够接管代码执行层；下一步需要解决的，是如何让它直接访问实验环境、管理 GPU、阅读训练日志、维护实验记录，并根据结果自主选择下一条研究路线。
真正的目标并不是让 Agent 帮人写出一个世界第一的方案，而是让它依靠自己的理解、实验和决策能力，进入真实的 Kaggle 比赛，并最终登顶 Kaggle 世界排名第一。
这次 KDD Cup 冠军不是这个目标的终点，而是它第一次显得具备了现实可能性。
[1]Guoming Li, Shangyu Zhang, Junwei Pan, Wentao Ning, Jin Chen, Gengsheng Xue, Chao Zhou, Shudong Huang, Haijie Gu, Menglin Yang. Expand More, Shrink Less: Shaping Effective-Rank Dynamics for Dense Scaling in Recommendation. KDD, 2026.arxiv.org/abs/2605.23191
[2]Mingyang Liu, Yong Bai, Zhangming Chan, Sishuo Chen, Xiang-Rong Sheng, Han Zhu, Jian Xu, Xinyang Chen. EST: Towards Efficient Scaling Laws in Click-Through Rate Prediction via Unified Modeling. arXiv:2602.10811, 2026.arxiv.org/abs/2602.10811
[3]Yuanzhe Zhou, Kirill Ogurtsov, Devin Anzelmo. 1st Place Solution. CMI — Detect Behavior with Sensor Data, Kaggle, 2025.www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/writeups/cmi-1st-place-solution
[4]Yuanzhe Zhou. 2nd Place Solution. NFL Big Data Bowl 2026 — Prediction, Kaggle, 2026.www.kaggle.com/competitions/nfl-big-data-bowl-2026-prediction/writeups/2nd-place-solution
!Image 11: 图片 一起“点**赞”三连↓**