Каждый раз, когда инженер вручную переписывает размеры с чертежа в Excel, где-то умирает DevOps-инженер. Серьёзно. Я видел заводы, где отдел из пяти человек неделями долбит цифры из PDF в ERP. Ошибки, опечатки, потерянные допуски — это не просто баги, это брак на производстве. Сегодня разберём, как собрать пайплайн, который сам найдёт все размерные линии, вытащит числа и единицы, а потом разложит в структуру. Без магии, с реальным кодом.
Ключевая мысль: CV + OCR + грамматика — не последовательность, а единый конвейер. Если упадёт детекция, OCR будет читать фон. Если OCR ошибётся — правила спасут не всегда. Нужна сквозная отладка.
Чёртова куча линий и символов
2D-чертёж — это не просто картинка. Там размеры, выноски, допуски, шероховатости, базы. Каждый элемент на своём слое, но в PDF или на скане все слои схлопнуты. Основная проблема: один чертёж может содержать 50-100 размеров, и каждый нужно не только распознать, но и понять — это длина, диаметр или угловой размер.
Типовой подход «скормил PDF в Tesseract — получил таблицу» разбивается о суровую реальность: шрифты, наклонный текст вдоль размерных линий, перечёркнутые цифры, перекрытия. Поэтому обычный OCR без понимания структуры не работает. Нужна полноценная архитектура, как в OCR-системах для ипотеки, только заточенная под чертежи.
Архитектура: три слоя защиты от хаоса
Наш пайплайн состоит из трёх этапов, каждый отвечает за свою часть неопределённости.
| Этап | Инструмент | Задача |
|---|---|---|
| 1. Детекция областей | YOLOv12 | Найти на изображении все size-блоки (размерные линии + текст + выноски) |
| 2. Распознавание текста | Fine-tuned TrOCR (large) | Извлечь строку символов внутри каждого бокса |
| 3. Постпроцессинг | Rule-based grammar + regex | Преобразовать строку в структурированный параметр: число, единица, допуск, тип размера |
1 Конвертация чертежа в объекты
Сначала нужно превратить PDF или DWG в изображение высокого разрешения (300-600 DPI). Использую pdf2image для PDF или ezdxf + matplotlib для DWG. Важно: не сжимать ниже 200 DPI — YOLO не найдёт мелкие размеры. Каждый лист режется на тайлы 1024x1024 с перекрытием 10% (чтобы не резать размерные линии).
Грабли: Если исходный PDF — not true vector (сканы), качество может быть ужасным. Нужна предобработка: адаптивная бинаризация, удаление шумов. Без этого YOLO будет выдавать ложно-положительные срабатывания на пятнах грязи.
2 YOLOv12 для поиска размерных блоков
YOLO — не для чтения текста, а для локализации. В нашем случае он должен найти прямоугольные области, содержащие размерную линию + текст. Почему не segment anything? Потому что скорость и ресурсы: нам нужно за~100 мс обработать тайл.
Тренировал я модель на синтетических данных: генерировал подложки с линиями и случайным текстом (шрифт GOST type A, 3–5 мм). Подход описан в статье «Как выжать максимум из YOLO для промышленного CV». Ключевые моменты:
- Классов всего три:
dimension_text(цифры с единицами),dimension_line(линия со стрелками),tolerance(допуск ±0.1). - Аугментация: повороты до 15°, обрезка, наложение шума. Без аугментации модель не обобщает на реальные чертежи.
- Post-NMS фильтр: боксы меньше 20×20 пикселей отбрасываются — это шум, а не размер.
# Пример инференса YOLO на одном тайле
from ultralytics import YOLO
model = YOLO('best_yolo12_drawing.pt')
results = model('tile_001.png', conf=0.5, iou=0.4)
# results[0].boxes -> xyxy, class, conf
3 Кастомный OCR: TrOCR переучиваем на чертёжный шрифт
Стандартный PaddleOCR или Tesseract, обученные на книжных текстах, чертёжные шрифты распознают плохо. Проблема в том, что цифры «1» и «7» в машиностроительных чертежах почти неотличимы (у «7» нет горизонтальной черты в некоторых стандартах).
Решение: взять предобученный TrOCR-large (Microsoft, 2022) и дообучить на собранном датасете. Датасет собирал так: рендерил 50 000 строк с размерами (диапазон 1–9999, единицы: мм, °, μм) шрифтами ISO 3098 и GOST 2.304. Пример строк: «∅25 ±0.2», «45°», «R12.5». Разметка — просто текст.
Подробнее о выборе OCR модели читайте в этом руководстве по open-source OCR. Я же предупрежу: TrOCR требует GPU даже для инференса (8 ГБ VRAM минимум). Если железа нет — используйте PaddleOCR с fine-tune на чертёжный синтетик, но точность будет чуть ниже.
# Fine-tune TrOCR (упрощённо)
seq2seq.train(
model_name='microsoft/trocr-large-printed',
train_dataset='train_ocr',
output_dir='./trocr_drawing',
per_device_train_batch_size=8,
learning_rate=5e-5,
num_train_epochs=5
)
4 Логика на правилах: превращаем текст в параметры
После OCR мы имеем список строк вида «2- 50±0,1», «90°», «M16». Теперь их надо спарсить. Правила — не хардкод, а грамматика. Я использую комбинацию regex + конечный автомат. Пример для типовой ситуации:
import re
pattern = r'''(?P[∅RDM])? # символ диаметра/радиуса и т.п.
(?P\d+(?:\.\d+)?) # число
(?Pмм|°|″|′)? # единица
(?:±(?P\d+(?:\.\d+)?))? # допуск
'''
def parse_dimension(text: str) -> dict:
match = re.match(pattern, text.strip(), re.VERBOSE)
if not match:
return {'raw': text, 'error': 'unparsed'}
return {
'type': 'linear' if not match.group('prefix') else match.group('prefix'),
'value': float(match.group('value')),
'unit': match.group('unit') or 'mm',
'tolerance': float(match.group('tolerance')) if match.group('tolerance') else None
}
Это только базовая обработка. В реальном проекте приходится учитывать позиционирование: если бокс находился рядом с размерной линией (её детектировал YOLO), мы знаем, что это длина, а не радиус. Геометрический контекст — ключ к структурному пониманию.
Такой же подход используется в Layout-aware системах, описанных в этой статье про ипотеку.
Как НЕ надо делать: типовые ловушки
За полгода внедрения я наступил на все грабли. Вот три самые болезненные:
- Не учитывать наклон текста. В чертежах текст часто пишется вдоль размерной линии под углом 15–75°. Если просто скормить горизонтальный кроп в OCR — точность падает в 2 раза. Решение: повернуть бокс по направлению размерной линии (используем мажорную ось линий из YOLO).
- Игнорировать перекрытия. Когда рядом написаны «2- 50» (два размера) — OCR может склеить. Нужно разбивать по пробелам или дефисам, но осторожно: «R12.5-0.5» — это радиус с допуском. Тут помогает грамматика.
- Думать, что DWG проще PDF. На деле из DWG вытащить текст легко, но координаты линий часто не соответствуют визуальному отображению из-за масштабов. Лучше рендерить в изображение, как в этом гайде по мебели, и работать уже с картинкой.
Куда копать дальше
Пайплайн, описанный выше, даёт точность около 92% на простых чертежах и 78% на сложных (с допусками, резьбами). Следующий шаг — заменить правила на lightweight Transformer для классификации типов размеров. Но это тема отдельной статьи.
Неочевидный совет: При оценке системы считайте не просто accuracy OCR, а структурную точность — сколько параметров полностью правильно (число + единица + допуск + тип). Часто модели хвалятся 99% accuracy на словах, но на уровне документа падают до 70%. Замеряйте сквозную метрику.
Автоматизация извлечения параметров из чертежей — задача, где нет серебряной пули. YOLO решает задачу детекции, TrOCR — распознавания, а грамматика — интерпретации. Каждый компонент настраивается под конкретный стандарт чертежей (ISO, ГОСТ, ANSI). Надеюсь, этот гайд сэкономит вам пару месяцев экспериментов. Если хотите поделиться своим кейсом — автоматизация разметки данных — хороший следующий шаг.