Vision RAG vs OCR 2026: який підхід краще для роботи з документами

З появою GPT-4V у 2023 році і подальшим розвитком мультимодальних моделей у технічних дискусіях регулярно звучить питання: чи потрібен OCR взагалі, якщо Vision-модель може читати документ напряму як зображення? У 2025–2026 роках це питання стало практичним — інструменти є, бенчмарки є, реальні проекти є. Час підбити trade-offs.

Ця стаття — для архітекторів які проектують або оптимізують документні RAG-пайплайни і хочуть зрозуміти, який підхід підходить для їхнього сценарію. Якщо вам потрібен технічний розбір того, як OCR-помилки руйнують chunking і embeddings — читайте попередню статтю серії: «Як OCR впливає на якість RAG-систем: технічний розбір».

Чому обробка документів — нетривіальна задача для AI

«Підключити AI до документів компанії» звучить просто. На практиці між цією фразою і працюючою RAG-системою стоїть кілька нетривіальних проблем, кожна з яких впливає на вибір архітектурного підходу.

Проблема 1: документи не є текстом

70–80% корпоративних даних — неструктуровані: скани, PDF-зображення, паперові форми. Навіть «цифровий» PDF може містити таблиці як зображення, сторінки зі складною версткою або вбудовані схеми. Жоден текстовий парсер не читає пікселі.

Проблема 2: структура документа несе сенс

У рядку накладної «50 | Кабель | 120 грн» зміст визначається позицією у таблиці. Якщо таблиця розпалася в лінійний текст — «50 Кабель 120 грн» — зв'язок між кількістю, назвою і ціною втрачено. OCR традиційно ігнорує просторові відносини між елементами.

Проблема 3: різнорідність архівів

Реальний корпоративний архів рідко буває однорідним. Там є чисті цифрові PDF, скани різної якості, документи зі складними макетами, рукописні нотатки, змішані форми. Рішення, яке ідеально працює для одного типу, може повністю провалитись на іншому.

Саме ця різнорідність робить вибір між OCR-first і Vision-first не академічним питанням, а архітектурним рішенням з реальними наслідками для якості і вартості системи.

OCR-first архітектура: класичний підхід і його межі

OCR-first — стандартний підхід для документних RAG-систем останніх 3–4 років. Логіка проста: конвертуємо зображення в текст, далі працюємо зі стандартним текстовим RAG-пайплайном.

Архітектура OCR-first

Документ (скан / PDF)
  ↓
Препроцесинг зображення (deskew, denoise, орієнтація)
  ↓
OCR-движок → plain text
  ↓
Постпроцесинг (нормалізація, видалення мусору)
  ↓
Chunking
  ↓
Text Embeddings (text-embedding-3-small, BGE, E5)
  ↓
Vector DB → Retrieval → LLM
  

Переваги OCR-first

Системні межі OCR-first

Детальний розбір того, де і як ці обмеження ламають chunking, embeddings і retrieval — у попередній статті серії: «Як OCR впливає на якість RAG-систем».

Vision-first архітектура: GPT-4o, Gemini, Qwen2.5-VL, olmOCR, Docling

Vision-first підхід замінює або обходить OCR-крок: документ передається у Vision-Language Model (VLM) як зображення, і модель сама витягує текст, структуру та контекст.

Архітектура Vision-first (TextRAG через Vision-парсинг)

Документ (скан / PDF / зображення)
  ↓
Рендеринг сторінок як зображень (pdf2image / PyMuPDF)
  ↓
VLM-парсинг → структурований текст (Markdown / JSON)
  ↓
Chunking (на основі збереженої структури)
  ↓
Text Embeddings → Vector DB → Retrieval → LLM
  

Архітектура VisRAG (embeddings з зображень)

Документ → сторінки як зображення
  ↓
Visual Embeddings (ColPali, ColQwen2, MuRAG-подібні моделі)
  ↓
Multimodal Vector DB (зображення + текстові запити)
  ↓
Retrieval → релевантні зображення сторінок
  ↓
VLM-генерація відповіді на основі знайдених зображень
  

У VisRAG-підході embedding рахується не з тексту, а з самого зображення сторінки. Retrieval відбувається у мультимодальному просторі: текстовий запит зіставляється з векторами зображень. Дослідження VisRAG (ICLR 2025) показує, що цей підхід дає 20–40% приріст end-to-end результату порівняно з традиційним TextRAG на мультимодальних документах — завдяки збереженню layout-інформації, яку текстовий OCR-пайплайн втрачає.

Огляд актуальних Vision-інструментів (2025–2026)

Де OCR втрачає структуру: таблиці, колонки, хедери

Щоб зрозуміти де Vision виграє — потрібно конкретно побачити де OCR програє. Розглянемо три найпоширеніших failure mode.

Failure mode 1: таблиці з об'єднаними клітинками

Запит «який прибуток за Q1–Q2 2024» у OCR-варіанті не матчиться: «Q1–Q2 2024» і «1 100 000» знаходяться в різних позиціях лінійного тексту без структурного зв'язку. У Vision-варіанті — таблиця збережена, retrieval знаходить правильний рядок.

Failure mode 2: багатоколонкова верстка

Двоколонковий документ (наприклад, медична картка або наукова стаття) читається OCR зліва направо по всій ширині сторінки. Результат: речення з лівої і правої колонки чергуються в одному потоці тексту. Sentence splitter ріже в неправильних місцях. Чанки містять змішаний контекст з двох несуміжних тем.

Vision-модель ідентифікує колонки як окремі текстові блоки і читає кожну незалежно. За порівняльним бенчмарком Procycons (2025), Docling з TableFormer коректно обробляє складні таблиці там, де Unstructured (OCR-based) дає column shifts і неповну ToC.

Failure mode 3: ієрархічні хедери і reading order

Технічна специфікація з розділами H1 → H2 → H3 → параграф після OCR перетворюється на суцільний текст без ієрархії. Semantic chunking не «знає» що цей параграф належить до розділу «4.2.1 Вимоги до безпеки» — бо структурна розмітка втрачена. Retrieval за запитом «вимоги до безпеки» може пропустити правильний чанк або повернути нерелевантний.

olmOCR і Docling зберігають reading order і ієрархію заголовків у виводі — це дозволяє chunk-стратегії орієнтуватись на структурні кордони документа, а не тільки на розмір тексту.

Де Vision-моделі виграють: складна верстка, схеми, рукописний текст

Кейс: медична документація зі змішаним контентом

У практиці AskYourDocs ми обробляли архів медичного центру: скановані картки пацієнтів, де кожна сторінка містила друкований шаблон, рукописні записи лікаря, штамп відділення і вставлені результати аналізів у вигляді зображень.

OCR-пайплайн давав задовільний результат лише на друкованій частині (~60% сторінки). Рукописні записи лікаря (критичні для клінічного контексту) розпізнавались з CER ~8–12% — гірше за середній показник через специфіку медичної термінології у рукописному вигляді. Вставлені результати аналізів як зображення — повністю недоступні.

Після переходу на GPT-4o-mini з деталізованим промптом для медичної документації: точність на рукописних полях зросла до прийнятного рівня, результати аналізів стали доступними для retrieval. Загальний Recall@5 на тестовому наборі клінічних питань зріс з 0.34 до 0.71.

Обмеження: вартість зросла у ~15×; обробка вимагала DPA з OpenAI і окремого юридичного погодження. Для невеликого архіву (3 000 карток) це було прийнятно. Для 50 000+ — потрібен self-hosted варіант.

Порівняння якості retrieval: TextRAG vs VisRAG

Обидва підходи принципово різняться не тільки на рівні парсингу, але й на рівні того, що саме векторизується і як відбувається retrieval.

TextRAG: текстові embeddings після OCR або Vision-парсингу

У TextRAG-пайплайні (незалежно від того, отримали ви текст через OCR або Vision-парсинг) — векторизується текст. Embedding-модель (text-embedding-3-small, BGE, E5) перетворює текстовий чанк на вектор. Retrieval — ANN-пошук у текстовому просторі.

Проблема: якщо layout-інформація (позиція елементів на сторінці, ієрархія, таблична структура) не збережена у тексті — вона втрачається для retrieval. OCR → text embeddings — два кроки з втратою інформації.

VisRAG: embeddings з зображень сторінок

VisRAG (arXiv 2410.10594, ICLR 2025) пропонує принципово інший підхід: embedding рахується не з тексту, а з самого зображення сторінки через Vision-Language Model (ColPali, ColQwen2 та аналоги). Retrieval — пошук у мультимодальному просторі: текстовий запит зіставляється з векторами зображень.

Перевага: layout, колір, позиція, шрифт, структура таблиці — все це закодовано у векторі зображення. Жодного кроку з втратою інформації між оригінальним документом і embeddings.

Результати ICLR 2025: VisRAG перевершує традиційний TextRAG як на етапі retrieval, так і на етапі генерації, досягаючи 20–40% end-to-end приросту на мультимодальних документах. VisRAG 2.0 (жовтень 2025) додатково показує 27% покращення на visual QA benchmarks через evidence-guided multi-image reasoning.

Порівняння підходів по ключових метриках

Практичний висновок: VisRAG — перспективний напрям для мультимодальних документів, але у 2026 році він ще не є production-ready для більшості корпоративних сценаріїв. Vision → TextRAG (парсинг через VLM + текстові embeddings) — більш зрілий компроміс, що поєднує якість Vision-парсингу з передбачуваністю стандартного RAG-стеку.

Вартість: токени, латентність, інфраструктура

Для архітектора вартість — не тільки ціна API. Це сукупність compute, latency, operational complexity і scaling характеристик. Розберемо кожен вимір.

Вартість парсингу: OCR vs Vision API

Різниця між self-hosted OCR і GPT-4o для 100 000 сторінок — від 60× до 600×. При щоденному потоці 10 000 нових документів за рік — це мільйони сторінок. На такому масштабі вартість Vision API стає основним архітектурним обмеженням.

Латентність: що означає для різних сценаріїв

Для систем реального часу — автоматична обробка вхідних накладних, індексація документів в момент надходження — Vision API практично непридатний без enterprise-рівня доступу.

Інфраструктурна складність

Гібридний підхід: коли і як поєднувати OCR + Vision

Для більшості реальних корпоративних архівів оптимальним є не вибір між OCR і Vision, а розумна маршрутизація між ними. Це знижує вартість у 5–10× порівняно з повним переходом на Vision, зберігаючи якість на проблемних документах.

Архітектура гібридного пайплайну

Вхідний документ
  │
  ├─► Текстовий шар? → Так → Нативний парсер (PyMuPDF / Docling)
  │                                    ↓
  │                              Структурований текст
  │
  └─► Ні (скан або зображення)
          │
          ├─► Класифікатор типу документа
          │         │
          │         ├─► Стандартний документ (contract, invoice, report)
          │         │         ↓
          │         │   Self-hosted OCR (PaddleOCR / Tesseract)
          │         │         ↓
          │         │   Garbage detector (alphabet ratio, langdetect)
          │         │         │
          │         │         ├─► Якість OK → Постпроцесинг → Chunking
          │         │         └─► Якість низька → Vision fallback
          │         │
          │         └─► Складний документ (таблиці, схеми, рукопис)
          │                   ↓
          │             Vision OCR (GPT-4o-mini / olmOCR-2 / Docling)
          │                   ↓
          │             Структурований Markdown → Chunking
          │
          └─► Логування: тип, шлях обробки, CER-оцінка
  

Критерії маршрутизації: що направляти на Vision

Self-hosted Vision як GDPR-сумісна альтернатива

Для організацій, де дані не можна відправляти у хмарні API, але якість класичного OCR недостатня — olmOCR-2 (82.4 на olmOCR-Bench) і Docling з TableFormer дають production-придатну якість при повному self-hosting. Qwen2.5-VL-7B — ще один варіант для середнього балансу якість/compute (потребує GPU ~16GB VRAM).

Granite-Docling-258M від IBM — компактна альтернатива для resource-constrained середовищ: 258M параметрів при точності on par з моделями у кілька разів більшими (Apache 2.0, self-hosted).

Рекомендації: матриця вибору по типу документів і бюджету

Короткий decision tree для архітектора

Висновки

Вибір між OCR і Vision у 2026 році — це не вибір між старим і новим. Це вибір trade-offs, які залежать від конкретного архіву, бюджету і compliance-вимог.

Ключові висновки

Наступне питання після вибору архітектури парсингу — як оптимально векторизувати отриманий текст. Розмірність embedding-вектора, вибір моделі і вплив на якість retrieval — тема наступної статті серії.