Как я учу компьютер читать старые чертежи — и почему одного OCR оказалось мало

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

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

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

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

Параметр	Состояние на момент подготовки статьи
Цель и фокус	Скан/PDF → Neutral Schema → параметрическая модель; сейчас — тела вращения
CAD (Программа проектирования)	Autodesk Inventor и КОМПАС-3D через отдельные адаптеры
Dataset (База данных)	229 активных чертежей; в текущем аудите 29 проверено, 200 ожидают проверки
Исполнения и разрывы	2 групповых чертежа и 2 таблицы исполнений; 5 чертежей с разрывами, 6 областей
Working View Detector, baseline (детектор рабочей области и базовых линий)	mAP@0.50 = 0,7834; Recall@0.50 = 0,85; mean best IoU = 0,694
NVIDIA Nemotron (рассматривается как дополнение в проект)	R&D‑контур, не production

Рис. 1. Один исходный чертёж — две CAD‑модели. Важный момент: цель не в «похожей картинке», а в едином нейтральном описании, из которого строятся Inventor и КОМПАС-3D, а также и другие CAD системы и нейтральные STEP

Рис. 2. Архитектура в одном экране: распознавание отделено от CAD, а Nemotron вынесен в экспериментальную ветку и не может обойти валидатор

Три вывода, к которым проект пришёл довольно быстро 1) чертёж приходится понимать иерархически; 2) результаты распознавания лучше хранить в CAD‑независимой Neutral Schema; 3) ML (машинное обучение) полезен там, где правила хрупкие, а инженерные ограничения и финальная проверка должны оставаться детерминированными.

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3. Реальный сложный лист в ScanToNeutral ML: основной продольный вид, разрыв детали и таблица исполнений одновременно. Такой пример плохо укладывается в схему «OCR + один bbox»

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

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

чертёж → ось → ступени профиля → замкнутый эскиз → Revolve → 3D

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

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

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

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

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

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

Ключевой урок Не привязывать «понимание чертежа» к API конкретной CAD. CAD должен быть исполнителем уже проверенного инженерного описания, а не местом, где одновременно принимаются решения о семантике.

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

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

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

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

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

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

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

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

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

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

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

Рис. 4. Baseline хорошо находит сам объект (Recall@0.50 = 0,85), но точная рамка заметно слабее (Recall@0.75 = 0,40). Для оператора это означает: примерно 15% целевых видов baseline может пропустить уже на мягком пороге, а строгая локализация остаётся отдельной задачей

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

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

Подход	Что выяснилось	Что осталось в системе
Геометрические эвристики	Быстро работают, но ломаются на вариативных листах	Проверки и fallback‑логика
Один bbox‑детектор	Вид находит, но края длинных деталей определяет неточно	Baseline + независимая оценка
Универсальный BBox Refiner	Может улучшить validation и одновременно ухудшить test	Только через fail‑safe gate
Специализированный axial refiner	Лучше соответствует длинным телам вращения	Отдельный экспериментальный профиль
Полный автомат	Ошибки слишком дороги на CAD‑этапе	Confidence + очередь оператора

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

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

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

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

Рис. 5. Разрыв объясняет, почему видимая длина не должна напрямую превращаться в длину 3D‑модели

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

Рис. 6. Текущий аудит базы. Важны не только положительные примеры: 24 проверенных чертежа подтверждены как «без разрывов», и это тоже обучающие данные

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

Рис. 7. GDS и BDS — отдельные проверки для исполнений и разрывов. Консольный отчёт оставлен намеренно: по нему легко увидеть, что именно считается «проверенным», а что ещё ждёт ревизии

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

Важно На данный момент Nemotron — архитектурный эксперимент, а не production‑контур ScanToNeutral. Он не участвует в построении CAD‑модели без промежуточной проверки.

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

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

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

{ “working_views”: [“V1”, “V2”], “dimensions”: [“Ø30d11”, “L”, “8”], “execution_table”: true, “break_marker”: “wave_break” }

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

{ “primary_view”: “V1”, “execution_relation”: {“V2”: “execution_01”}, “uncertain”: [“dimension_L”], “confidence”: 0.87  }

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

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

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

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

Рис. 8. Типичная инженерная реальность: функциональность написана, но точка входа забыта. После этого появился отдельный hotfix и E2E‑проверка всего маршрута

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

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

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

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

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

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

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

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

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

Работает сейчас	R&D / следующий этап
• постоянный Dataset и ревизии аннотаций	• автоматический детектор разрывов после накопления примеров
• WorkingView, оси и SheetRegions	• более глубокое восстановление профиля, отверстий, фасок, пазов и резьбы
• baseline‑детектор рабочих видов	• производственная семантика: материал, шероховатость, допуски, технические требования
• ручная проверка групповых чертежей и исполнений	• Nemotron как семантический слой и сравнение с чистым CV‑конвейером
• разметка break_marker и affects_3d	• расширение от втулок/валов к более разнообразным телам вращения
• Neutral Schema и генерация в Inventor/КОМПАС для поддержанных тел вращения

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

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

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

Иерархия семантики + строгая валидация + удобная разметка Сначала понять структуру листа и роли видов, затем извлечь геометрию, после этого проверить инженерные ограничения — и только потом вызывать CAD. ML ускоряет неопределённые этапы, но не должен скрывать ошибку за красивым confidence.

Ещё один вывод — интерфейс разметки является частью 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, а также разбор таблиц и русскоязычных технических документов.