1. 这个比赛到底在比什么ARC-AGI-3 开源赛还有 9 天截止如果你还没听说过这个比赛简单说它考验的不是让模型背多少知识而是让 AI 在面对完全陌生的推理任务时能不能像人一样“看懂规则、举一反三”。这和传统刷榜比赛有本质区别——没有海量数据可以拟合没有固定套路可以套用每一道题都是新的。我第一次接触 ARC 系列任务时最大的感受是“反直觉”。我们习惯了用大规模预训练加微调的方式去刷 benchmark但 ARC 的题目往往只有几个示例要求你从极少的样本中归纳出变换规则然后应用到测试输入上。这更像是在考“流体智力”而不是“晶体智力”。所以这个开源赛的核心价值不在于刷出多高的分数而在于探索一条不依赖大规模标注数据、不依赖暴力枚举的推理路径。适合谁来参考如果你是对 AI 推理、程序合成、少样本学习感兴趣的研究者或工程师这个比赛值得投入时间。如果你只是想找个比赛练手、拿个名次那可能会比较痛苦因为它的反馈周期长、调试难度大。但如果你愿意花时间理解任务本质、搭建一套可复用的推理框架这 9 天足够做出一个有价值的开源方案。2. 任务机制与核心难点拆解2.1 从少量示例中归纳变换规则ARC-AGI 的每道题通常给出 2 到 4 个训练对每个训练对包含一个输入网格和一个输出网格。网格是 0 到 9 的整数矩阵每个数字代表一种颜色。你需要从这些训练对中找出输入到输出的映射规律然后把这个规律应用到测试输入上生成正确的输出网格。听起来简单但难点在于规律可能是空间变换旋转、镜像、平移、颜色替换、对象计数、拓扑关系、对称性操作甚至是多个规则的组合。而且训练对的数量极少你无法通过统计方法去拟合。我试过用纯视觉模型去做效果很差因为模型会倾向于记住颜色分布而不是理解结构关系。一个更有效的思路是把网格解析成“对象”——连续的同色区域、独立的图形、边界框等然后在对象层面做推理。比如有一类常见题目是“找出与众不同的那个对象并标记它”如果你在像素层面做模型很难理解“与众不同”的含义但如果你先做连通域分析提取每个对象的形状、大小、位置、颜色再比较差异就更容易找到规律。2.2 为什么暴力枚举走不通有人可能会想既然规则空间有限那我穷举所有可能的变换组合不就行了理论上可行但实际上组合爆炸。假设有 20 种基础变换每道题可能用到 1 到 3 个变换的组合那就是 20 400 8000 种可能。每验证一个组合都需要在训练对上跑一遍时间成本极高。而且很多变换是参数化的比如平移的步长、旋转的角度参数空间更大。更关键的是ARC 的题目设计者刻意避免了“常见组合”。很多题目的规则是全新的甚至需要你从网格的语义内容中推断。比如有一道题是“把每个对象替换成它包含的洞的数量对应的颜色”这种规则你不可能预先枚举到。所以正确的方向不是枚举而是“生成假设并验证”。你可以维护一个假设空间每次从训练对中提取特征生成候选规则然后用其他训练对去验证逐步缩小范围。这个过程可以用程序合成的方法来做也可以用大语言模型来辅助生成规则描述。2.3 评测指标与提交要求ARC-AGI-3 的评测通常看两个指标准确率和效率。准确率就是测试集上完全正确的比例注意是“完全正确”输出网格必须和标准答案一模一样差一个格子都不行。效率方面有些赛道会限制推理时间或计算资源所以你不能无限制地跑搜索。提交格式一般要求你提供一个可执行程序或一个 API 接口输入是 JSON 格式的题目数据输出是预测的网格。具体细节需要看比赛页面的说明但核心要求是你的方案必须能自动处理任意新题目不能针对特定题目硬编码。注意很多新手会犯一个错误——在本地测试时把答案写死或者用题目 ID 去查表。这种做法在评测时会被直接判零分而且会被标记为作弊。开源赛虽然氛围宽松但基本的诚信还是要守住。3. 一套可落地的推理框架设计3.1 整体架构感知、假设、验证、执行我建议把整个方案拆成四个模块感知层、假设生成层、验证层和执行层。感知层负责把原始网格转换成结构化表示比如对象列表、关系图、对称性特征等。假设生成层根据感知结果提出可能的变换规则可以用规则模板、程序合成或大模型生成。验证层用训练对去检验假设是否成立筛掉不满足的。执行层把最终规则应用到测试输入上生成输出网格。这个架构的好处是模块解耦你可以单独优化每个部分。比如感知层可以加入更复杂的对象分割算法假设层可以接入更强的代码生成模型验证层可以设计更高效的剪枝策略。而且整个流程是可解释的你能看到每一步的中间结果方便调试。我实测下来感知层的质量对最终效果影响最大。如果对象分割错了后面的推理全是白搭。所以建议在感知层多花时间尤其是处理那些有噪声、有重叠、有嵌套的网格。3.2 对象抽象与关系建模对象抽象的核心是连通域分析。对于每个网格你可以用四连通或八连通来划分同色区域每个区域就是一个对象。然后提取对象的属性颜色、面积、边界框、质心、形状签名比如用 Hu 矩或简单的宽高比、是否对称、是否包含洞等。关系建模则是计算对象之间的关系距离、方向、包含、相邻、大小比较等。这些关系可以用图结构来表示节点是对象边是关系。有了图之后很多题目就变成了图上的推理问题比如“找出度数最大的节点”“找出与其他节点颜色不同的节点”等。这里有个经验不要只用一个尺度的对象。有些题目的对象是嵌套的比如一个大矩形里面有几个小方块。你可以做多尺度分割先分大对象再在大对象内部分小对象形成层次结构。这样能覆盖更多题型。3.3 规则假设的生成与剪枝规则假设的生成可以从几个来源入手。一是预定义的规则模板库比如“颜色替换”“几何变换”“对象筛选”“对象排序”等每个模板有参数你可以用训练对去拟合参数。二是程序合成用 DSL领域特定语言来描述变换然后搜索程序空间。三是用大语言模型生成自然语言描述的规则再翻译成可执行代码。剪枝策略很关键。每生成一个假设先在第一个训练对上验证不通过就直接丢弃。通过后再用第二个训练对验证以此类推。这样能快速筛掉大量错误假设。另外你可以维护一个假设的优先级队列优先验证那些更简单、更常见的规则因为奥卡姆剃刀在 ARC 中往往成立——简单规则更可能是正确答案。提示如果多个假设在所有训练对上都通过不要随便选一个。你可以看哪个假设在测试输入上产生的输出更“合理”比如网格尺寸是否符合预期、颜色分布是否自然等。有时候需要保留多个候选最后做集成。4. 实操流程与关键环节实现4.1 环境准备与依赖安装我一般用 Python 来做 ARC 相关的开发核心依赖包括 numpy 用于矩阵操作scipy 用于连通域分析networkx 用于图结构以及一个代码生成或 LLM 调用的库。如果你打算用大模型辅助生成规则可以接入公开的 API 或者本地部署一个小模型。pip install numpy scipy networkx matplotlibmatplotlib 是用来可视化网格的调试时非常有用。你可以在每一步把网格画出来看看对象分割对不对、规则应用后的效果如何。别小看可视化很多 bug 都是靠眼睛看出来的。4.2 数据加载与预处理ARC 的数据格式通常是 JSON每个任务包含 train 和 test 两个部分。train 是训练对列表每个对有 input 和 outputtest 是测试输入列表可能有一个或多个。你需要写一个加载器把 JSON 转成 numpy 数组并做基本的校验比如网格尺寸是否一致、颜色值是否在 0 到 9 之间。预处理还包括归一化。虽然 ARC 的颜色是离散的但你可以把颜色映射到类别标签方便后续处理。另外如果网格尺寸差异很大可以考虑做 padding 或缩放但要注意不要破坏空间关系。4.3 核心推理循环的代码实现下面是一个简化的推理循环框架展示了感知、假设、验证、执行的基本流程。实际使用时需要根据具体题型扩展。import numpy as np from scipy import ndimage def extract_objects(grid): objects [] for color in range(10): mask (grid color) labeled, num ndimage.label(mask) for i in range(1, num 1): coords np.argwhere(labeled i) obj { color: color, coords: coords, area: len(coords), bbox: (coords[:,0].min(), coords[:,0].max(), coords[:,1].min(), coords[:,1].max()) } objects.append(obj) return objects def generate_hypotheses(objects, train_pairs): hypotheses [] # 示例颜色替换假设 for pair in train_pairs: inp, out pair[input], pair[output] # 分析颜色映射关系 # ... return hypotheses def verify(hypothesis, train_pairs): for pair in train_pairs: pred apply_hypothesis(hypothesis, pair[input]) if not np.array_equal(pred, pair[output]): return False return True def solve(task): train_pairs task[train] test_input task[test][0][input] all_objects [extract_objects(p[input]) for p in train_pairs] hypotheses generate_hypotheses(all_objects, train_pairs) for h in hypotheses: if verify(h, train_pairs): return apply_hypothesis(h, test_input) return None这段代码只是骨架实际需要填充大量的规则模板和验证逻辑。但你可以看到核心思路就是“从训练对中提取特征生成候选规则验证后应用”。4.4 参数选择与调优经验在规则模板中很多参数需要选择比如平移的步长、旋转的角度、颜色映射的方式等。我的经验是优先选择“最小改动”的参数。比如如果训练对显示输入和输出只差一个格子的平移那就选步长为 1不要选步长为 2 或 3。奥卡姆剃刀在这里很管用。另外对于颜色替换不要假设是双射。有些题目是把多种颜色映射到同一种颜色或者只替换特定颜色。你需要从训练对中统计颜色共现关系推断映射规则。如果多个规则都通过验证可以计算每个规则在训练对上的“简洁度”比如规则中参数的数量、条件的复杂度等选最简洁的那个。这能提高泛化能力。5. 常见问题与排查技巧实录5.1 训练对通过但测试失败这是最常见的问题。原因通常是规则过拟合了训练对没有抓住本质。比如你发现训练对中所有输入都是 5x5 网格就假设输出也是 5x5但测试输入可能是 7x7。解决办法是在生成假设时尽量让规则与网格尺寸无关或者显式地处理尺寸变化。另一个原因是规则有隐藏条件。比如你发现“把红色对象移到左上角”但训练对中红色对象恰好是最大的测试中红色对象不是最大的规则就不适用了。你需要检查规则是否依赖了训练对中的偶然特征。5.2 对象分割错误导致推理失败如果网格中有多个同色对象相邻连通域分析可能会把它们合并成一个。这时候你需要考虑是否应该用八连通还是四连通或者引入形态学操作来分离对象。我试过用腐蚀操作先断开细连接再分割效果不错。还有一种情况是对象有洞。比如一个红色矩形中间有个蓝色小方块连通域分析会把红色部分分成一个带洞的对象但你可能需要把洞也识别出来。可以用ndimage.binary_fill_holes来填充洞然后比较填充前后的差异。5.3 规则空间太大导致搜索超时如果规则模板太多、参数范围太广搜索会非常慢。解决办法是分层搜索先搜索简单规则单步变换如果找不到再搜索组合规则两步变换。另外可以用训练对的数量来剪枝——如果一个假设在第一个训练对上就失败了直接丢弃不要浪费时间。还可以用缓存把已经验证过的假设和结果存起来避免重复计算。对于相同的输入网格如果之前已经计算过某个规则的应用结果直接查缓存。5.4 常见问题速查表问题现象可能原因排查方法解决思路训练对全过测试全错规则过拟合检查规则是否依赖尺寸、位置等偶然特征增加规则泛化性移除无关条件对象分割错误连通域合并或分裂可视化分割结果调整连通性、加入形态学操作搜索超时规则空间太大统计假设数量分层搜索、剪枝、缓存颜色映射错误假设了双射检查颜色共现矩阵允许非双射映射输出尺寸不对规则未处理尺寸变化对比训练对尺寸显式建模尺寸变换注意调试时一定要把中间结果可视化。我踩过的坑是以为对象分割没问题结果画出来一看两个对象被合并了。眼睛比代码更可靠。6. 9 天冲刺的节奏建议如果你现在才开始准备9 天时间不算充裕但足够做出一个有竞争力的方案。我的建议是前 3 天搭建基础框架包括数据加载、对象分割、规则模板库和验证循环。中间 3 天集中攻克高频题型比如颜色替换、几何变换、对象筛选把这些题型的准确率提上去。最后 3 天做集成和调优把多个规则组合起来处理复杂题目。不要试图覆盖所有题型ARC 的题目类型太多你不可能全部搞定。抓住高频题型把准确率做到 70% 以上就有机会拿到不错的名次。另外开源赛的评审可能还会看代码质量和创新性所以把你的思路和实现整理成文档放在仓库里这也是加分项。我个人在实际操作中的体会是ARC 比赛最考验的不是算法多复杂而是你对问题的理解有多深。多花时间看题目、分析规律比盲目写代码更有效。有时候一道题看懂了规则就自然浮现了。