Содержание
Скриншот блок-схемы из презентации, фото доски после митинга, PDF со схемой сети — всё это изображения. Редактируемая диаграмма — это модель: узлы, рёбра, типы фигур, метки, иногда слои и правила нотации. Переход между ними не сводится к «распознать текст» или «обвести контуры». В этом гайде разбираем типы схем, классические пайплайны (OCR, векторизация, CAD), подходы компьютерного зрения и то, что изменилось с мультимодальными моделями в 2025–2026 годах — вплоть до генерации Mermaid, PlantUML и XML для draw.io.
Ключевые выводы
Изображение и диаграмма — разные уровни абстракции. Пиксели или векторные контуры не содержат семантики «это решение в BPMN» или «это VLAN на L3». Без восстановления графа вы получите красивый SVG, но не редактируемую схему в draw.io.
OCR решает только подписи. Tesseract, Google Vision и аналоги хорошо вытаскивают текст с координатами, но не понимают, что стрелка от блока A к блоку B означает переход «Да». Для подписей — да; для структуры — нет.
Векторизация и CAD ближе к чертежам, чем к блок-схемам. Vector Magic и Scan2CAD дают линии и дуги в DWG/DXF или SVG-пути. Это ценно для планов помещений и механики, но не восстанавливает UML-класс или swimlane в BPMN без ручной доработки.
ИИ 2025–2026 — первый рабочий слой для «простых» схем. Vision-language модели (Gemini, Claude, GPT-4o) и специализированные системы вроде Flowchart2Mermaid переводят фото блок-схемы в текстовый Mermaid с приемлемым качеством на простых кейсах. Сложные нотации, плотная вёрстка и рукописные доски по-прежнему требуют человека в контуре.
Практичная цепочка — гибрид. Предобработка изображения → классификация типа схемы → маршрут (CAD / CV / VLM) → генерация целевого формата → валидация и ручная правка. Полностью без участия человека пока реалистично только для узкого класса: чистые блок-схемы с горизонтальной вёрсткой и читаемым шрифтом.
Какие бывают схемы и почему от типа зависит пайплайн
Не все «картинки со стрелками» одинаковы. Нотация задаёт ожидаемые примитивы, правила соединения и то, что считается ошибкой при конвертации.
Блок-схемы (flowchart) — прямоугольники решений и процессов, ромбы условий, стрелки с подписями «да/нет». Самый частый запрос на конвертацию из скриншота. Целевые форматы: Mermaid flowchart, draw.io, Visio. Здесь лучше всего работают VLM и связка «распознавание фигур + OCR подписей».
UML охватывает десятки диаграмм: классов, последовательностей, состояний, компонентов. У каждой — свой набор элементов (lifeline, activation, association с кратностью). Изображение диаграммы классов на фото слайда требует не только текста, но и распознавания связей «наследование» vs «агрегация». PlantUML и Mermaid покрывают подмножество UML; полный экспорт в Enterprise Architect или Sparx чаще делают вручную или через нативные импорты, а не через OCR.
BPMN 2.0 — стандарт для бизнес-процессов: задачи, шлюзы, пулы и дорожки (swimlanes), события. Визуально похоже на блок-схему, но семантика жёстче: тип шлюза (XOR, AND) нельзя угадать только по форме ромба без контекста нотации. Конвертеры из растра в BPMN XML редки; на практике команды либо перерисовывают в Camunda Modeler, либо используют ИИ как черновик с последующей валидацией аналитиком.
Сетевые и архитектурные схемы — иконки маршрутизаторов, облаков, зон безопасности, подписи IP и VLAN. Здесь важны символы из библиотек (Cisco, AWS, Azure). OCR вытащит IP-адреса; распознавание «это ALB, а не просто прямоугольник» — задача детекции иконок или VLM с промптом про облачную топологию. draw.io и diagrams.net богаты стенсилами; генерация XML с правильными стилями — отдельная боль.
Чертежи и планы (CAD) — линии, размеры, штриховки, слои. Это не граф в смысле блок-схемы, а геометрия с допусками. Сюда относят Scan2CAD, AutoCAD Raster Design, векторизация контуров. Целевой формат — DWG/DXF, не Mermaid.
Прочие типы — mind map, org chart, ER-диаграммы, DFD, Gantt. У каждого свой угол: иерархия для org chart, сущности и связи для ER. Универсального «распознай всё» не существует; классификатор типа схемы на входе пайплайна экономит часы ложных маршрутов.
Почему изображение и диаграмма — разные сущности
Файл PNG — решётка пикселей (или сжатое представление). Даже «векторный» PDF часто содержит текст как кривые без структуры документа. Редактируемая диаграмма в draw.io, Mermaid или Visio хранит объекты: id узла, тип фигуры, координаты, текст, список исходящих рёбер, стили.
Потеря семантики происходит в момент экспорта «для слайда». Дизайнер сгруппировал фигуры, растрировал тень, слил слои — и обратный путь невозможен без реконструкции. Отсюда три уровня «редактируемости»:
На нулевом уровне вы обрезаете картинку в редакторе — меняется только кадр. На первом получаете векторные контуры (SVG path) — можно менять заливку и масштаб, но не «перетащить стрелку на другой блок» как в диаграмме. На втором — граф: узлы и рёбра в модели. На третьем — нотация: BPMN-тип задачи, UML-стереотип, привязка к метамодели.
OCR работает на уровне текста в bounding box. Векторизация — между нулём и первым. CAD-инструменты тянут к первому–второму для линейной геометрии. Полноценный второй–третий уровень для произвольного растра — зона CV и ИИ плюс ручная верификация.
Ещё один частый кейс — скриншот из веб-редактора, где под капотом уже был JSON или XML, но пользователь видит только bitmap. Идеальное решение — достать исходник (файл .drawio, исходный Mermaid в репозитории), а не распознавать пиксели. Конвертация изображения — запасной путь, когда исходника нет.
OCR-подход: текст есть, структуры нет
Оптическое распознавание символов извлекает строки и их положение на странице. Для схем это даёт подписи внутри прямоугольников и на стрелках — полезно как второй проход после детекции фигур, но недостаточно как единственный шаг.
Классический стек: Tesseract (открытый, настраиваемый язык), Google Cloud Vision / Document AI, ABBYY FineReader, PaddleOCR и EasyOCR в Python-пайплайнах. Для презентаций и сканов с русским текстом критичны языковые пакеты и предобработка: выравнивание (deskew), бинаризация, увеличение DPI. Плохой контраст и сжатие JPEG убивают точность раньше, чем выбор модели.
Типичный OCR-пайплайн для схемы выглядит так: найти области с текстом (или прогнать OCR по всему кадру), отфильтровать мусор, сопоставить каждую строку с ближайшим прямоугольником по IoU или расстоянию до центра. Связи между блоками OCR не видит — для этого нужны линии и стрелки как отдельный класс объектов.
В продакшене OCR хорошо стыкуется с каталогизацией документов. Пример из практики — пайплайны на Google Apps Script с Drive OCR для PDF-архивов: текст извлекается пакетно, а структура диаграммы в таком сценарии не цель (умный реестр документов с OCR Drive). Для именно диаграмм имеет смысл комбинировать OCR с детекцией фигур или VLM.
Ограничения OCR на схемах: мелкий шрифт на слайдах, повёрнутый текст, формулы, иконки без текста, рукопись на доске. Двухъязычные подписи требуют явного ocrLanguage. После OCR всё равно нужен этап сборки графа — иначе вы получите Excel со списком фраз, а не draw.io.
Векторизация: от растра к контурам, не к семантике
Векторизация превращает растр в кривые Безье и полигоны: Potrace, Adobe Illustrator (Image Trace), Inkscape (Trace Bitmap), коммерческий Vector Magic. На выходе — SVG или EPS с заливками и обводками.
Для дизайнерских иллюстраций этого достаточно. Для блок-схемы каждый «прямоугольник» может стать десятком отдельных path после трассировки; стрелка — треугольником и линией без логической связи «from → to». Редактирование в Illustrator удобно визуально, но перенос в Mermaid или PlantUML вручную.
Полезные приёмы: трассировка с ограничением числа цветов, упрощение кривых, последующая кластеризация близких контуров в прямоугольники (скрипты на Python + Shapely). Это уже полуавтомат между первым и вторым уровнем редактируемости. Для слайдов с плоскими цветами Vector Magic часто даёт чище, чем бесплатный Potrace.
Векторизация не заменяет хранение исходника. Если команда регулярно теряет .drawio и живёт только в PNG, лучше внедрить дисциплину «диаграмма = файл в Git», а не наращивать трассировку.
CAD-подход: Scan2CAD, Raster Design и инженерные чертежи
Когда объект — план этажа, механический узел, топография, а не процессная нотация, в игру входят CAD-инструменты. Scan2CAD конвертирует растр в DWG/DXF: распознаёт линии, дуги, иногда штриховки. AutoCAD Raster Design (в составе AEC-коллекций) векторизует подложку для дальнейшего черчения поверх.
Эти системы оптимизированы под ортогональную геометрию и масштаб. Блок-схема с произвольными отступами и скруглёнными углами — не их сильная сторона. Зато для скана бумажного плана с размерами CAD-путь быстрее, чем пытаться скормить чертёж VLM как flowchart.
Пайплайн: скан → очистка шума → привязка масштаба → векторизация → ручная правка слоёв в AutoCAD или LibreCAD. Семантика «комната», «дверь» появляется только если вы ведёте объекты BIM поверх, а не из одного JPEG.
Для разработчиков ПО CAD-ветка релевантна реже, чем BPMN/UML, но встречается в гибридных командах (аппаратная часть + софт) и в документации по инфраструктуре дата-центра.
Компьютерное зрение: детекция фигур, линий и связей
До массового прихода VLM инженеры собирали пайплайны из классического CV. Идея: бинаризовать изображение, найти контуры (OpenCV), отфильтровать прямоугольники и ромбы, линии — преобразованием Хафа, стрелки — по наконечникам треугольников. Текст — OCR в найденных ROI.
В академической литературе и индустрии есть наборы для диаграмм и графиков: задачи ChartQA, распознавание диаграмм в PDF (PubLayNet, специализированные датасеты flowchart). Модели детекции (YOLO, Faster R-CNN) обучают на классах «process», «decision», «connector». Качество зависит от домена: синтетические схемы из Visio распознаются лучше, чем фото проектора.
Сложные места: пересечение линий, скругления, групповые рамки, нестандартные шрифты, полупрозрачность в экспорте из Figma. Связь «какой текст к какой фигуре» ломается при плотной вёрстке. Поэтому CV-пайплайны часто выдают промежуточный JSON (nodes/edges) и требуют UI для ручной склейки — как в старых инструментах импорта в Visio.
Связка CV + OCR + эвристики до сих пор выгодна, когда данные однородны (все схемы из одного генератора) и нужен on-prem без отправки в облачный LLM. Для разовых задач с произвольными картинками поддержка такого стека дороже, чем вызов VLM.
Исследования по VLM для графиков и диаграмм (например, работы в духе Chartographer для вопросов к диаграммам) показывают: модели понимают картинку для QA, но генерация точного кода — отдельная, более хрупкая задача (обзор VLM для диаграмм).
ИИ-подходы 2025–2026: VLM, специализированные системы и draw.io
С 2024–2025 года основной сдвиг — vision-language models: одна модель получает изображение и инструкцию «верни Mermaid flowchart» или «перечисли узлы и рёбра в JSON». GPT-4o, Gemini 1.5/2.x, Claude 3.5/4 с vision, открытые Qwen-VL, LLaVA — в продакшене выбирают по цене, латентности и политике данных.
Flowchart2Mermaid (arxiv 2512.02170, веб-приложение flowchart-to-mermaid) — показательный пример 2025 года: VLM генерирует Mermaid, дальше человек правит через inline-редактирование, drag-and-drop символов и текстовые команды («соедини A и B с подписью Да»). Это честный human-in-the-loop, без которого точность на сложных схемах падает.
draw.io в 2026 году встроил обновлённый Generate (иконка «искры»): генерация из текста и интеграция нескольких бэкендов (Gemini, Claude, ChatGPT), в том числе Mermaid-подобные диаграммы. Для Confluence Cloud ИИ по умолчанию выключен — нужна явная настройка администратора. Данные диаграммы на серверах draw.io не хранятся, но промпт уходит к провайдеру модели — важно для NDA.
Проекты с открытым кодом и сайд-проекты вроде smart-drawio-next комбинируют загрузку референсного изображения, стриминг генерации XML и встроенный редактор draw.io — удобный прототип цепочки «картинка → XML → правка».
Сильные стороны VLM: быстрый старт, переносимость между типами простых схем, естественный язык для правок. Слабые: галлюцинации (лишние узлы, пропущенные ветки), путаница похожих форм, игнор цветовой легенды, слабая работа с swimlane и нестандартными иконками. На фото доски с бликами качество резко падает.
Для корпоративного использования закладывайте: редактирование чувствительных схем перед отправкой, выбор региона API, логирование инструкций модели, обязательную проверку инженером или аналитиком. ИИ — ускоритель черновика, не нотариус.
Генерация Mermaid, PlantUML и draw.io XML
Текстовые форматы диаграмм удобны тем, что хранятся в Git, рендерятся в CI и правятся без мыши.
Mermaid (flowchart, sequenceDiagram, classDiagram, C4Context и др.) — дефакто стандарт для Markdown-репозиториев и многих wiki. Синтаксис компактный; ошибка парсера сразу видна в Mermaid Live Editor. VLM хорошо целятся в Mermaid, потому что в обучающих данных много примеров кода.
PlantUML богаче для UML и некоторых архитектурных нотаций; текст длиннее, зато точнее для классов и последовательностей. Конвертация из произвольного растра в PlantUML встречается реже, чем в Mermaid; чаще генерируют PlantUML из текста ТЗ, а не из картинки.
draw.io XML (mxGraphModel) — фактический стандарт для визуального редактора diagrams.net: позиции, стили, стрелки, библиотеки иконок. ИИ-инструменты (AIDrawIO, smart-drawio-next) стремятся выдавать именно XML, чтобы пользователь открыл файл и двигал блоки мышью. Постобработка XML (выравнивание, routing рёбер) часто нужна отдельными скриптами.
Типичная цепочка: изображение → VLM → Mermaid → рендер в SVG → импорт в draw.io или прямой image → XML. Обратный путь «Mermaid → редактируемый draw.io» поддерживается встроенным импортом Mermaid в draw.io с последующим разбором на фигуры.
Валидация после генерации: парсер Mermaid/PlantUML, подсчёт узлов vs визуальная проверка, сравнение OCR-подписей с текстом в коде. Автотесты на уровне «код компилируется» отсекают грубый мусор, но не логические ошибки ветвления.
Что работает на практике
По опыту команд и бенчмаркам вроде Flowchart2Mermaid, реалистичные ожидания такие.
Хорошо автоматизируется: чистый скриншот блок-схемы из Visio/draw.io/Google Slides; горизонтальная или вертикальная вёрстка; шрифт от 10 pt; контрастные чёрно-белые фигуры; число узлов до ~15–20; одна ветка условий без глубокой вложенности.
Плохо: фото доски под углом; скрин с градиентами и тенями; BPMN с пулами; сетевые схемы с десятками иконок вендора; сканы книжных страниц; любая схема, где смысл в цвете или типе линии, а не только в геометрии.
OCR отдельно имеет смысл, когда у вас уже есть векторный PDF с текстовым слоём — тогда не VLM, а извлечение текста и ручная сборка быстрее. Векторизация — когда нужен постер или печать, не логическая модель. CAD — планы и чертежи. VLM — черновик для документации и тикетов «перенеси схему из старого PPT».
Инвестиция в процесс часто важнее инвестиции в модель: хранить .drawio рядом с .png в репозитории, экспортировать Mermaid из источника правды, запретить «только картинка в Confluence». Конвертация растра — страховка, не норма.
Связанный опыт по извлечению структуры из документов (таблицы, вёрстка PDF) перекликается с диаграммами: без анализа вёрстки текста и блоков OCR даёт шум (OpenDataLoader PDF).
Идеальная автоматизированная цепочка преобразования
Ниже — эталонный пайплайн, который можно собрать из готовых сервисов и скриптов без единого монолита. Каждый шаг логируется; на выходе — артефакт для ревью.
Шаг 1. Приём и предобработка. Загрузка PNG/JPEG/PDF, конвертация в RGB, deskew, повышение резкости, при необходимости — удаление фона (для фото доски). Нормализация DPI к 150–300 для OCR и VLM.
Шаг 2. Классификация типа. Лёгкий классификатор (CNN или быстрый VLM-запрос): flowchart / UML / network / CAD / unknown. От типа зависит маршрут: CAD-ветка, CV+OCR или сразу VLM.
Шаг 3. Извлечение структуры. Для flowchart — VLM с жёсткой системной инструкцией (схема JSON: узлы, рёбра, метки) или прямой Mermaid. Параллельно OCR для сверки подписей. Для network — детекция иконок + OCR IP/имён. Для CAD — Scan2CAD или аналог.
Шаг 4. Нормализация и валидация. Парсинг Mermaid/PlantUML/XML; исправление синтаксиса линтером; проверка связности графа (нет висячих узлов, кроме явных терминалов); сравнение списка меток OCR и кода.
Шаг 5. Постобработка раскладки. Авто-раскладка (Graphviz, dagre, встроенные алгоритмы draw.io), выравнивание по сетке, перенумерация id.
Шаг 6. Human-in-the-loop. UI для сравнения «исходник | результат», правка узла/ребра, повторный промпт на подграф. Фиксация правок для дообучения или few-shot на будущее.
Шаг 7. Экспорт. Mermaid в Git, XML в draw.io, PNG/SVG для слайдов. Метаданные: версия модели, дата, автор ревью.
Такой конвейер можно упростить до «загрузил в Flowchart2Mermaid → поправил → экспорт в Git» для малой команды или развернуть on-prem с Qwen-VL для закрытых схем.
Частые вопросы
Можно ли обойтись только Tesseract?
Для полноценной диаграммы — нет. Tesseract даст текст и координаты. Связи между блоками нужно восстанавливать другими средствами. OCR имеет смысл как этап сверки подписей после VLM или CV.
Чем Vector Magic отличается от ИИ-конвертера?
Vector Magic и Image Trace строят векторные контуры без понимания «это шлюз BPMN». ИИ-конвертер пытается восстановить граф и выдать Mermaid или XML. Для логических схем предпочтительнее ИИ-слой; для иллюстраций — векторизация.
Поддерживает ли draw.io импорт из картинки напрямую?
Встроенный импорт растра кладёт bitmap на холст, это не семантическая конвертация. Для генерации из изображения используйте Generate / внешние VLM-инструменты и импорт XML или Mermaid.
Насколько точен Flowchart2Mermaid на реальных схемах?
На простых эталонных блок-схемах — высокая полезность черновика. На фото доски и плотных слайдах ошибки в ветвлениях и подписях часты; авторы системы закладывают ручное редактирование. Оценивайте на своей выборке из 10–20 типовых схем.
PlantUML или Mermaid для восстановления UML?
Mermaid проще для VLM и Markdown-репозиториев. PlantUML точнее для классических UML-диаграмм, если модель обучена на таком выходе. Часто генерируют Mermaid classDiagram, затем дорабатывают вручную.
Безопасно ли отправлять архитектурную схему в ChatGPT?
Промпт и изображение уходят провайдеру модели. Для NDA-схем — on-prem VLM, redaction имён хостов или ручная перерисовка. draw.io не хранит диаграмму на своих серверах, но трафик к API всё равно есть.
Нужен ли GPU для своего пайплайна?
Для вызова облачных API — нет. Для локального Qwen-VL или CV на больших объёмах — желательен GPU. Классический OpenCV + Tesseract живёт на CPU.
Что делать, если исходный .drawio ещё существует?
Не распознавать. Откройте исходник — это единственный способ получить 100% редактируемость. Конвертация изображения — только когда файл утерян.
Как проверить качество автоматической конвертации?
Считайте узлы и рёбра на оригинале и в коде; сверьте все подписи OCR; пройдите по каждой ветке условия; попросите второго человека пройти сценарий по восстановленной схеме.
Есть ли смысл в дообучении своей модели?
Имеет, если у вас сотни схем одного корпоративного шаблона. Для разовых задач дешевле примеры в инструкции модели и ручная проверка.
Дальнейшее чтение
В блоге есть смежные материалы: OCR и ИИ для каталогизации документов на Drive, VLM и вопросы к диаграммам (Chartographer), разбор вёрстки PDF и таблиц, эволюция веб-архитектуры (диаграммы как документация), гайд по agile-терминологии (BPMN и процессы в контексте команд), SEO/AEO/GEO для технического контента.
Заключение
Превратить изображение схемы в редактируемую диаграмму в 2026 году реально для узкого класса задач — в первую очередь простые блок-схемы через VLM и Mermaid/draw.io XML. OCR, векторизация и CAD остаются специализированными инструментами для текста, контуров и чертежей, а не заменой понимания нотации. Постройте процесс: тип схемы → правильный маршрут → валидация → ревью человеком — и храните исходники диаграмм в системе контроля версий, чтобы не конвертировать растр повторно. На этой неделе возьмите одну типовую схему из вашей документации, прогоните через Flowchart2Mermaid или draw.io Generate и зафиксируйте, какой процент узлов пришлось править вручную — это ваш честный базовый уровень для автоматизации.