BenchCAD - как устроен замер генерации CAD-программ
В основе BenchCAD сгенерированный датасет, разбитый по 106 типам деталей с общей параметрической структурой (каждый с тремя уровнями сложности) в семи функциональных группах: крепёж, передачи, силовые элементы, фитинги, панели, фурнитура и корпуса. Примерно у половины типов параметры берутся прямо из таблиц спецификаций/стандартов - 47 кодов ISO, DIN, EN, ASME и IEC. Для каждого типа эксперты написали генератор, выдающий готовую программу на CadQuery (Python). Всего 17 900 деталей; вроде как даже проверенные экспертами.
Всего есть три типа замеров:
1. Vision2Code. LLM получает четыре ортогональных вида детали и должна выдать программу на CadQuery; прогон идёт по всем 17 900 записям. Код конвертируется в STEP, оба тела нормируются по габаритам (3D BoundingBox) и переводятся в воксели. Дальше считается доля вокселей, занятых сразу в обоих телах, от числа занятых хотя бы в одном - это и есть IoU (Intersection over Union - отношение пересекающегося у двух моделей объёма вокселей к объединённому объёму). Иными словами в какой степени объекты совпадают: 1 - объёмы совпали полностью, 0 - тела нигде не пересеклись.
2. CodeEdit. Даётся исходный код на CadQuery и словесная инструкция по шаблону вроде "увеличь диаметр отверстия до 12 мм". Надо вернуть минимально изменённую программу, дающую целевую фигуру. Пар 748, разложены поровну по 106 семействам и четырём типам правок - размерные, добавляющие элемент, удаляющие и многошаговые. Это часть датасета была составлена вручную - формулировки инструкций вычитывал второй автор, а спорные пары прогоняли двумя сильными моделями и переписывали или выбрасывали те, где модели расходились в понимании задания.
3. VisionQA + CodeQA - две задачи, вопросы в которых заданы парами. Один и тот же вопрос сначала задают по картинке, потом по исходному коду, и 2 400 вопросов дают 4 800 прогонов. Почти все они числовые: около 60 процентов про отношения размеров, 35 процентов про количество элементов вроде числа зубьев, остальное порядковые. Парность выступает инструментом диагностики. Если модель отвечает по коду заметно лучше, чем по картинке, ломается распознавание, а не понимание конструкции; если плохо в обоих случаях, модель не читает сами операции CadQuery. Вопросы разложены по четырём уровням - узнать тип детали по видам, прочитать операции и порядок их применения, восстановить параметрическую структуру так, как написал бы конструктор, и спланировать всё это разом в исполнимый код.
В BenchCAD на чистое среднее IoU приходится только 0.60 от общего показателя, а остальное - это наличие essential-операций и некоторые другие метрики. То есть модели недостаточно угадать с геометрией (за это максимум тройка), она должна угадать также и обязательный для данного типа способ построения модели. Например, пружину можно набрать стопкой колец и получить похожий силуэт, но пружиной это не станет - шаг и сечение проволоки задать будет нечем. Поэтому на каждое семейство выписан список обязательных построений. Пружине сжатия засчитывается винтовое протягивание профиля или обычное; косозубой шестерне нужен переход между сечениями либо выдавливание с закруткой, и вдобавок хоть один способ задать профиль зуба.
Этот бенчмарк покрывает лишь одну из подпрактик конструкторской работы - проектирование геометрии отдельных деталей. Сборок, сопряжений и кинематики в там нет. Допуски, посадки и материалы не проверяются. Привязка к стандарту означает лишь, что параметры взяты из его диапазонов. Воксельный IoU ничего не говорит о технологичности - пройдёт ли деталь на фрезеровку, влезет ли болт. Измеряется только код на CadQuery.
Источник: https://arxiv.org/abs/2605.10865
Код MIT - https://github.com/BenchCAD/BenchCAD-main
Датасет - https://huggingface.co/datasets/BenchCAD/BenchCAD
#cad #cadquery #benchmark #llm
Post #335
595