ScanToNeutral: от первого Revolve до нейтральной модели, ML‑разметки, двух CAD и экспериментального слоя NVIDIA Nemotron

Задача звучит обманчиво просто: взять старый бумажный чертёж, отсканировать его и получить параметрическую 3D‑модель. На практике между «увидеть линии» и «понять деталь» лежит всё то, что инженер‑конструктор обычно делает почти автоматически: отличает контур от размерной линии, основной вид — от разреза, реальную длину — от изображения с разрывом, а одну деталь — от нескольких исполнений на одном листе.

ScanToNeutral вырос именно из этой разницы. Сейчас это уже не один алгоритм, а конвейер, в котором компьютерное зрение, OCR, правила, ручная проверка и CAD‑адаптеры разделены на самостоятельные уровни. Ниже — не история «нейросеть всё решила», а инженерный разбор того, что сработало, что не сработало и почему архитектура проекта стала важнее конкретной модели ML.

Коротко о проекте на текущий момент

1. Главная проблема: чертёж — это не картинка из линий

Для человека (инженера‑конструктора) технический чертёж — язык. Для алгоритма на входе это растр: чёрные штрихи, текст, пятна, шум сканера. Ошибка первых версий была в том, что хотелось слишком рано перейти от пикселей к геометрии.

На листе одинаково «линейно» выглядят принципиально разные сущности:

• контур детали;

• осевая линия;

• размерная и выносная линии;

• штриховка разреза;

• граница местного вида;

• линия разрыва;

• рамка таблицы или основной надписи.

Даже если OCR идеально прочитал «Ø30d11» и «L», остаётся вопрос: к какому виду и к какому исполнению относятся эти данные. Поэтому в Dataset появился объект WorkingView: у каждого вида есть роль, тип, геометрия, ось или центр и признак участия в восстановлении 3D.

Именно на этом уровне удобно объяснять систему неспециалисту: прежде чем «рисовать 3D», программа должна понять, на какую часть листа вообще стоит смотреть.

2. С чего всё начиналось: один профиль, одна ось и Revolve

Первый MVP был намеренно узким. Я не пытался распознавать «любые машиностроительные чертежи», а взял класс деталей, где путь к 3D понятен: тела вращения. Для втулки или ступенчатого вала можно восстановить половину продольного профиля относительно оси и выполнить вращение на 360°.

Начальный прототип управлял Autodesk Inventor через API. Геометрия профиля поначалу была почти жёстко задана — это был способ проверить не ML, а конечную часть маршрута. И здесь обнаружился первый неприятный факт: CAD API сам по себе требует строгой инженерной дисциплины. Неправильно замкнутый профиль, неверная ориентация эскиза или неоднозначная операция ломают модель независимо от качества распознавания.

Отсюда выросло важное разделение: распознавание не должно напрямую «тыкать кнопки» CAD. Сначала оно формирует описание того, что поняло, и только потом другой модуль пытается построить модель.

3. Архитектурный перелом: CAD перестал быть центром системы

Когда появился второй целевой CAD — КОМПАС-3D, прежняя схема «распознали размер → сразу вызвали Inventor API» перестала масштабироваться. Так возник Neutral Schema: промежуточное описание детали, не привязанное к конкретному API.

В нейтральный слой постепенно попадают ось, профиль, отверстия, фаски, роли видов, исполнения, признаки разрывов и другие сущности. После этого два независимых адаптера строят модель в своих CAD (В дальнейшем этих адаптеров появится больше).

Это не только архитектурная аккуратность. Два адаптера дают полезный тест. Если одна и та же Neutral Schema приводит к разной геометрии в Inventor и КОМПАС-3D, ошибка локализуется намного быстрее: либо нейтральное описание неоднозначно, либо один из адаптеров интерпретирует его неверно.

4. Датасет оказался отдельным инженерным продуктом

После первых десятков размеченных листов выяснилось, что база ценнее очередной версии программы. Обновление приложения не должно перетасовывать train/val/test, перезаписывать исправленные аннотации или удалять «неудобные» примеры.

Поэтому база сделана постоянной и append‑only:

• исходные raw не изменяются;

• импорт использует SHA-256 для дедупликации;

• исправления уходят в новую ревизию, а прошлое сохраняется в history;

• сплиты остаются постоянными при добавлении новых данных;

• ошибочно импортированный лист можно исключить логически, но его DRW‑ID не переиспользуется.

Последний пункт кажется мелочью, пока не приходится сравнивать метрики двух моделей, обученных с разницей в неделю. Если состав тестовой выборки тихо изменился, сравнение становится почти бессмысленным.

5. Почему один детектор не работает: метрики, refiners и fail‑safe gates

Первой ML‑задачей стала не «реконструкция детали», а поиск рабочих видов. Это хороший пример того, как сложную задачу лучше разрезать на проверяемые этапы.

Цифры здесь важны не сами по себе. Recall@0.50 = 0,85 означает, что базовый детектор в тестовой выборке находит около 85% целевых видов при достаточно мягком критерии совпадения. Это уже полезно для предразметки, но ещё недостаточно для безусловной автоматической передачи в CAD.

Как менялся подход

Самый полезный результат этих экспериментов — не конкретная прибавка IoU, а привычка не доверять validation в одиночку. Несколько refiners выглядели лучше на validation, но хуже на независимом test. Поэтому эксперимент может получить статус rejected_on_test и не имеет права автоматически заменить baseline.

6. Два случая, которые ломают наивное распознавание: исполнения и разрывы

Групповой чертёж показывает, почему «один лист = одна деталь» неверно. На одном листе могут находиться базовое исполнение, таблица вариантов и несколько геометрических отличий. В Dataset пришлось добавить drawing_scope, execution_definition, execution_ids, область execution_table и связи между видами.

Разрыв ломает другую наивную гипотезу: «длина объекта на картинке пропорциональна длине детали». Волнистые или зигзагообразные линии означают, что середина длинной детали на листе опущена. Для будущей 3D‑реконструкции это не графический шум, а семантический признак.

Сейчас разрыв хранится как отдельный ViewFeature: wave_break или zigzag_break, привязка к конкретному WorkingView и флаг affects_3d. Это позволяет отличить реальный смысловой разрыв от локального графического элемента, который не должен менять модель.

На момент подготовки статьи база содержит 229 активных аннотированных чертежей. В текущем цикле проверки обработано 29. Найдено 2 групповых чертежа с 2 таблицами исполнений и 5 чертежей с разрывами; размечено 6 областей разрыва, из них 5 влияют на восстановление 3D. Валидатор при этом отдельно показывает один незаполненный execution_ids — то есть статус не просто считает прогресс, а указывает конкретную структурную проблему.

7. Экспериментальный слой: NVIDIA Nemotron как семантический диспетчер

После CV/OCR остаются вопросы, которые плохо выражаются одним bbox: какой размер относится к какому исполнению, какой вид считать базовым, является ли отличие геометрии вариантом детали или локальным разрезом, какие признаки можно безопасно передать в Neutral Schema. Здесь большой мультимодальной модели потенциально есть работа — не «рисовать деталь», а связывать уже найденные факты.

Для эксперимента интересен NVIDIA Nemotron 3 Nano Omni 30B A3B: NVIDIA позиционирует его как открытую мультимодальную модель для текста, изображений, аудио и видео, в том числе задач document intelligence. Но в ScanToNeutral роль намеренно ограничена: модель формирует гипотезу, а не CAD‑команду.

Пример входа после специализированных детекторов:

Ожидаемый выход — тоже только структурированный:

Дальше начинается обычная инженерия: JSON проходит схему, проверку допустимых связей и геометрические ограничения. Если гипотеза противоречит данным или confidence недостаточен, она не попадает в Neutral Schema и возвращается оператору.

Отдельно рассматривается nemotron‑parse для таблиц и структуры документов. Здесь есть существенное ограничение: в текущем описании NVIDIA для модели заявлена поддержка английского языка. Поэтому для русскоязычных советских и российских чертежей её нельзя считать готовым OCR‑решением без отдельного теста; практичнее проверять её как вспомогательный layout/table parser и подавать уже распознанный русский текст другим способом.

8. Модуль работает, пользователь — нет: зачем ML‑проекту E2E‑тесты

Один из самых полезных багов проекта оказался почти комичным. После добавления Break Detection структура данных уже существовала, статус BDS был задуман, но команда BD не была зарегистрирована в основном меню. Внутренний модуль есть — пользователь получает Unknown menu choice: BD.

После этого тестировать только функцию стало явно недостаточно. Для новых возможностей теперь важен полный маршрут:

1. патч устанавливается поверх предыдущей версии;

2. команда видна в меню и CLI;

3. открывается правильная очередь;

4. разметка сохраняется;

5. повторный статус видит новые данные;

6. старый Dataset при этом не перезаписывается.

Для ML‑проекта это особенно важно: можно получить отличный detector.py, который фактически не добавляет ни одного полезного примера в Dataset.

9. Где проект находится сейчас: отдельно production, отдельно R&D

Главная ближайшая задача — не добавить ещё одну модель «потому что можно», а закончить ревизию текущей базы. Для break detector четыре‑шесть положительных областей — это демонстрация схемы, а не датасет. Нужны десятки и затем сотни подтверждённых примеров, причём вместе с отрицательными.

10. Что я вынес из проекта

Если свести опыт к одной формуле, получается не «чем больше нейросеть, тем лучше», а:

Ещё один вывод — интерфейс разметки является частью ML‑системы. Если оператору неудобно работать с A1/A0, долго переключать режимы или непонятно, что уже проверено, база перестаёт расти. Поэтому GD/GDS, BD/BDS, переход по DRW‑ID, zoom, работа с осями и отдельные аудит‑очереди важны не меньше, чем выбор backbone.

И наконец, отрицательный результат — тоже результат. Экспериментальный refiner, отвергнутый на test, чертёж без разрыва и hotfix после забытой команды — всё это остаётся в истории проекта. Так меньше шансов через месяц снова пройти тот же тупик.

Что дальше

Идеальный пользовательский сценарий по‑прежнему очень простой: загрузить PDF или фотографию чертежа, увидеть, что система поняла, подтвердить спорные места и выбрать CAD. Но под этой простой кнопкой должен находиться длинный проверяемый конвейер — от WorkingView до Neutral Schema и CAD‑валидатора.

В ближайших итерациях я хочу довести текущую разметку исполнений и разрывов, расширить поддерживаемую геометрию тел вращения и только после этого сравнить специализированный CV‑конвейер с вариантом, где Nemotron помогает связывать семантику. Критерий простой: не «насколько красиво модель объясняет ответ», а насколько меньше ошибок остаётся в Neutral Schema и сколько ручных исправлений экономит оператор.

Если вы занимались computervision для технической документации, CADAPI или пробовали мультимодальные модели на реальных чертежах — буду рад сравнению подходов в комментариях. Особенно интересен практический опыт локального запуска и квантизации Nemotron 3 NanoOmni, а также разбор таблиц и русскоязычных технических документов.