Зміст
Скріншот блок-схеми з презентації, фото дошки після мітингу, 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 з кратністю). Зображення діаграми класів на фото слайда потребує не лише тексту, а й розпізнавання зв'язків «наслідування» проти «агрегації». 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/XML; підрахунок вузлів проти візуальної перевірки; порівняння 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, редагування імен хостів або ручне перемальовування. draw.io не зберігає діаграму на своїх серверах, але трафік до API все одно є.
Чи потрібен GPU для власного пайплайна?
Для виклику хмарних API — ні. Для локального Qwen-VL або CV на великих обсягах — бажано. Класичний OpenCV + Tesseract живе на CPU.
Що робити, якщо вихідний .drawio ще існує?
Не розпізнавати. Відкрийте вихідник — це єдиний спосіб отримати 100% редагованість. Конвертація зображення — лише коли файл загублено.
Як перевірити якість автоматичної конвертації?
Порахуйте вузли й ребра на оригіналі й у коді; звірте всі підписи OCR; пройдіть кожну гілку умови; попросіть другу людину пройти сценарій за відновленою схемою.
Чи є сенс у донавчанні власної моделі?
Є, якщо у вас сотні схем одного корпоративного шаблону. Для разових задач дешевше приклади в інструкції моделі й ручна перевірка.
Додаткові матеріали
У блозі є суміжні публікації: OCR і ШІ для каталогізації документів на Drive, VLM і питання до діаграм (Chartographer), розбір вёрстки PDF і таблиць, еволюція веб-архітектури, гайд з agile-термінології, SEO/AEO/GEO для технічного контенту.
Висновок
Перетворити зображення схеми на редаговану діаграму в 2026 році реально для вузького класу задач — насамперед прості блок-схеми через VLM і Mermaid/draw.io XML. OCR, векторизація й CAD залишаються спеціалізованими інструментами для тексту, контурів і креслень, а не заміною розуміння нотації. Побудуйте процес: тип схеми → правильний маршрут → валідація → рев'ю людиною — і зберігайте вихідники діаграм у системі контролю версій, щоб не конвертувати растр повторно. Цього тижня візьміть одну типову схему з вашої документації, прогоніть через Flowchart2Mermaid або draw.io Generate і зафіксуйте, який відсоток вузлів довелося правити вручну — це ваш чесний базовий рівень для автоматизації.