RealCADBench: Benchmarking Parametric CAD Modeling from Industrial Design Intents

一句话概括

RealCADBench 是一个面向“真实工业设计意图到参数化 CAD 程序”的评测基准，包含 1.2 万余个来自工厂自动化场景的任务，用执行成功率、两种 IoU 和视觉语义一致性四个维度揭示：当前前沿大模型在参数化 CAD 建模上各有短板，没有全能冠军。

问题背景

参数化 CAD（如 FreeCAD、SolidWorks 里的特征树建模）本质上是“把设计意图翻译成一段可执行的建模脚本”。过去几年，大模型写代码的能力突飞猛进，人们自然希望它们也能“听懂”一句产品描述或一张工程图，然后自动生成 CAD 程序。

但怎么评价这件事？传统做法要么只看程序能不能跑通（executability），要么只算生成网格和真实模型的重叠度（IoU）。论文指出这些指标有两个盲区：第一，现有基准大多用合成数据或 CAD 原生格式（如 STEP/JSON 特征序列），离真实工业里“一张草图、一张照片、一段文字”的输入形态很远；第二，一个模型可能 IoU 很高，但画出来的零件缺了倒角、少了孔，或者装配时把零件放错了位置——这些“身份级”的视觉错误，IoU 根本反映不出来。

所以作者想做一个更接近工厂实际的基准：输入是真实设计意图（文字、2D 工程图、产品照片、渲染图），输出是能跑的 FreeCAD Python API 程序，最后用多维度指标来打分，而不是只看单一数字。

方法要点

RealCADBench 的构建有几个关键设计：

任务规模与来源。 总共 12,632 个任务，覆盖 19 个工厂自动化品类（比如传送带部件、传感器支架、气动元件外壳之类）。每个任务包含四种输入模态的组合：文本描述、2D 工程图、真实产品照片、渲染图像。任务分 Part（单零件）和 Assembly（装配体）两类。

评测切片。 完整跑所有任务成本太高，所以作者划出一个 1,770 任务的评测子集：其中 1,745 个是 Part 任务，按输入模态分成四个 regime（比如“仅文本”“文本+工程图”“文本+照片”等）；另有 25 个装配任务组成 RCB-Assm25，专门用来做装配对比。

统一执行环境。 所有模型都输出 FreeCAD API 的 Python 代码，由一个共享运行时执行并导出 3D 模型。这样至少保证了“能不能跑”是在同一套环境里比的。

四维评价体系。 ① Executability：程序能否无错执行并导出模型；② Solid IoU：实体体积重叠度；③ Surface IoU：表面网格重叠度；④ Judge：一个基于评分规则（rubric）的视觉语义身份评估器，由模型（或人）判断生成模型是否“看起来还是那个零件/装配”，能捕捉缺失细节、零件身份丢失、装配位置错误等问题。

被测模型。 包括 9 个独立前沿大模型（standalone）和 6 个前沿规模大模型（frontier-scale），后者可能还配合了 agent 式工具调用。

关键结论

没有模型四项全领先。 在 9 个独立大模型里，没有任何一个同时在 executability、Solid IoU、Surface IoU 和 Judge 上拿第一。论文摘要明确说“no model leads all four metrics”。
执行率不等于建模质量。 在 6 个前沿规模模型上，executability 范围是 0.565–0.812，看起来“能跑”的概率不低；但 Solid IoU 只有 0.2841–0.5379，Surface IoU 更是低到 0.112–0.217。也就是说，程序跑通了，但几何形状和真实零件差距很大。
综合最优不是单项最优。 按四个 regime 做平衡后的综合分（regime-balanced composite），第一名和四个单项指标的领先者都不是同一个模型。这说明“平均能力强”和“单项拔尖”是两种不同的模型特质。
装配场景下 agent 有得有失。 在 RCB-Assm25 上，Codex 配合 GPT-5.5 比单独用 GPT-5.5 提升了 executability 和两个 IoU，但 Judge 分数反而下降了 6.98 个百分点。也就是说，agent 工具调用让程序更“能跑”、几何更“像”，但视觉上装配体的身份感（比如零件相对位置、整体形态）反而变差了。
常见失败模式。 摘要点出三类反复出现的问题：细小结构缺失（如螺纹孔、倒角）、零件身份丢失（生成的东西看起来不像目标零件）、装配位置错误。这些恰恰是 IoU 类指标容易漏掉的错误。

读后思考 / 适用场景

这个基准最大的价值在于把“评价维度”从一维拉到四维。如果你只关心“模型能不能生成可执行的 CAD 程序”，executability 就够了；但在真实工业里，程序能跑只是第一步，形状对不对、细节全不全、装配位置准不准，才是工程师真正会验收的东西。RealCADBench 的 Judge 机制试图模拟这种“人看一眼就知道对不对”的验收方式，虽然 rubric 评分本身有主观性，但它确实抓住了 IoU 的盲区。

适用场景很明确：一是给大模型 CAD 生成方向的研究者当“考卷”，尤其是那些做多模态输入（文字+图纸+照片）的团队；二是给工业软件厂商评估“AI 辅助建模”功能时做参考——毕竟工厂自动化零件的形态相对规整，比自由曲面消费品更容易量化比较。

另外，这个基准用 FreeCAD API 作为统一输出格式，是个务实的选择：FreeCAD 开源、可脚本化、有 Python 接口，方便大规模自动执行。相比商业 CAD 的私有格式，这大大降低了评测门槛。

局限与开放问题

评测子集规模偏小。 1,770 任务里 Part 占 1,745，装配只有 25 个。装配体建模是 CAD 里更复杂、更贴近实际使用的场景，25 个样本的统计效力有限，摘要也承认这是一个“study”而非大规模基准。
Judge 的可靠性未充分展开。 摘要提到 Judge 是“rubric-based visual-semantic identity”，但没有给出它与人类专家评分的一致性数据。如果 Judge 本身有偏差，那“Judge 分数下降 6.98 个百分点”这类结论就要打折扣。
输入模态的“真实度”边界。 虽然任务来自真实工业设计意图，但 2D 工程图、产品照片这些输入是否覆盖了工厂里各种图纸规范、拍摄角度、光照条件？摘要未给出细节。
IoU 指标在 CAD 上的固有局限。 Solid IoU 和 Surface IoU 对微小特征（倒角、小孔）极不敏感——一个少了 0.5mm 倒角的模型，IoU 可能只差 0.001，但人眼一眼就能看出来。这也是为什么作者要引入 Judge，但 Judge 本身又带来新的主观性。
模型版本时效性。 论文里测的是 GPT-5.5 等模型，但大模型迭代极快，这个基准的“绝对分数”会迅速过时。它的长期价值在于评测框架本身，而不是某一次的具体排名。