Пайплайн извлечения параметров из 2D-чертежей: YOLO + OCR + правила | AiManual
AiManual Logo Ai / Manual.
11 Май 2026 Гайд

Автоматическое извлечение параметров из 2D-чертежей: пайплайн с YOLO, кастомным OCR и логикой на правилах

Детальный технический гайд: как объединить детекцию YOLOv12, кастомный TrOCR и грамматику для автоматического снятия размеров с PDF и DWG чертежей. Реальные кей

Каждый раз, когда инженер вручную переписывает размеры с чертежа в 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), мы знаем, что это длина, а не радиус. Геометрический контекст — ключ к структурному пониманию.

💡
Совет: Не пытайтесь покрыть все случаи одним regex. Сделайте композитную схему: парсеры для линейных, угловых, диаметральных размеров, резьб, допусков. Каждый парсер проверяет уверенность (confidence) — если низкая, помечаем на ручную проверку.
Такой же подход используется в Layout-aware системах, описанных в этой статье про ипотеку.

Как НЕ надо делать: типовые ловушки

За полгода внедрения я наступил на все грабли. Вот три самые болезненные:

  1. Не учитывать наклон текста. В чертежах текст часто пишется вдоль размерной линии под углом 15–75°. Если просто скормить горизонтальный кроп в OCR — точность падает в 2 раза. Решение: повернуть бокс по направлению размерной линии (используем мажорную ось линий из YOLO).
  2. Игнорировать перекрытия. Когда рядом написаны «2- 50» (два размера) — OCR может склеить. Нужно разбивать по пробелам или дефисам, но осторожно: «R12.5-0.5» — это радиус с допуском. Тут помогает грамматика.
  3. Думать, что DWG проще PDF. На деле из DWG вытащить текст легко, но координаты линий часто не соответствуют визуальному отображению из-за масштабов. Лучше рендерить в изображение, как в этом гайде по мебели, и работать уже с картинкой.

Куда копать дальше

Пайплайн, описанный выше, даёт точность около 92% на простых чертежах и 78% на сложных (с допусками, резьбами). Следующий шаг — заменить правила на lightweight Transformer для классификации типов размеров. Но это тема отдельной статьи.

Неочевидный совет: При оценке системы считайте не просто accuracy OCR, а структурную точность — сколько параметров полностью правильно (число + единица + допуск + тип). Часто модели хвалятся 99% accuracy на словах, но на уровне документа падают до 70%. Замеряйте сквозную метрику.

Автоматизация извлечения параметров из чертежей — задача, где нет серебряной пули. YOLO решает задачу детекции, TrOCR — распознавания, а грамматика — интерпретации. Каждый компонент настраивается под конкретный стандарт чертежей (ISO, ГОСТ, ANSI). Надеюсь, этот гайд сэкономит вам пару месяцев экспериментов. Если хотите поделиться своим кейсом — автоматизация разметки данных — хороший следующий шаг.

Подписаться на канал