Як OCR впливає на якість RAG-систем: технічний розбір

Якщо ваша RAG-система повертає нерелевантні результати або впевнено галюцинує — перше місце де шукати проблему не в моделі, не в chunking-параметрах і не у векторній базі. Шукайте в тексті, який ви туди завантажили.

OCR-помилка — це не локальний дефект. Це ін'єкція шуму на вхід пайплайну, яка мультиплікується на кожному наступному кроці. Спотворений токен → хибний кордон речення → некоректний чанк → зміщений вектор → пропущений retrieval → галюцинована відповідь. Кожен крок підсилює попередній.

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

Pipeline обробки сканованого документа: від PDF до embeddings

Перш ніж розбирати де ламається — зафіксуємо повну карту пайплайну. Кожен крок нижче є потенційною точкою деградації якості.

Ключовий висновок з цієї карти: помилка OCR (крок 3) не локалізується на кроці 3. Вона дрейфує по всьому пайплайну і на кроці 9 проявляється як проблема з якістю відповіді — далеко від першопричини.

Саме тому більшість команд шукає не там: тюнять chunking, міняють embedding-модель, налаштовують reranker — а проблема залишається, бо сидить у вхідних даних.

Типові артефакти OCR: що саме ламається і чому

Нижче — реальна таксономія артефактів, з якими ви зіткнетесь у типових корпоративних архівах. Для кожного — приклад того, як виглядає артефакт і що він ламає далі по пайплайну.

1. Злиплі слова (word merging)

Причина: нерівномірний контраст між символами і фоном, низький DPI, стиснення JPEG.

Що ламає: sentence splitter не знаходить кордони речень; tokenizer embedding-моделі отримує OOV-токен замість двох відомих слів; retrieval за запитом «термін дії» не знаходить чанк з «терміндіїдоговору».

2. Заміна символів (character substitution)

Причина: схожість форм символів при низькій роздільності або поганому контрасті. Особливо часто — при змішаних кирилично-латинських шрифтах.

Що ламає: числові значення стають текстом; пошук за точним значенням («доза 2,5 мг») не матчиться з артефактом; у медичних і юридичних документах це критична помилка.

3. Фантомні символи та рядки (hallucinated content)

Причина: OCR намагається розпізнати будь-який піксельний патерн як символ. Перевернутий текст, шуми сканера, артефакти стиснення — все це конвертується в «текст».

Що ламає: мусор потрапляє у вектор як валідний контент; при retrieval LLM отримує нечитабельний контекст і або галюцинує, або каже «не знаю».

4. Зламана структура таблиць

Причина: класичний OCR не розуміє просторові відносини між клітинками. Він читає текст лінійно: зверху вниз, зліва направо, ігноруючи структуру колонок.

Що ламає: при chunking вся таблиця потрапляє в один блок лінійного тексту без розмітки; запит «яка ціна кабелю» не матчиться з безструктурним рядком; чанк не передає семантичний зв'язок між артикулом, назвою і ціною.

5. Помилкові переноси та розриви рядків

Причина: OCR не завжди розрізняє перенос слова і кінець рядка в тексті з колонками або вузькими полями.

Що ламає: «відповідаль-» і «ність» стають окремими токенами; злиплий переносом дефіс створює OOV-токен; числове значення «38 400» розбивається на два рядки і парситься як «38» і «400,00» — різні токени без контексту суми.

Як OCR-помилки руйнують chunking-стратегію

Chunking — це розбивка тексту на фрагменти, які будуть векторизовані і збережені в індекс. Якість чанку визначає якість retrieval: якщо чанк семантично некоректний, навіть ідеальний embedding не врятує ситуацію.

Розглянемо три основні chunking-стратегії і як OCR-артефакти ламають кожну з них.

Стратегія 1: Fixed-size chunking (за кількістю токенів)

Найпростіша стратегія: розбивати текст на чанки по N токенів з overlap. Проблема: вона цілком залежить від коректної токенізації.

Стратегія 2: Sentence-based chunking

Розбивка за реченнями (spaCy, nltk sentence splitter). Потребує коректних кінцівок речень: крапок, знаків питання, оклику з пробілом після.

OCR-артефакти систематично ламають детектування кордонів речень:

Стратегія 3: Semantic / recursive chunking

Більш просунуті підходи (recursive character splitter, semantic chunking з embedding-similarity) теоретично мають бути стійкішими до поверхневих артефактів. На практиці — ні.

Semantic chunking визначає кордони за зміною семантики між сусідніми реченнями. Якщо речення спотворені OCR-артефактами, embedding кожного речення зміщується — і алгоритм «бачить» семантичний розрив там де його немає, або не бачить там де він є.

Результат: чанки ріжуться в «семантично правильних» місцях для спотвореного тексту — але не для оригінального змісту.

Практичний висновок по chunking

Жодна chunking-стратегія не компенсує системно забруднений вхідний текст. Постпроцесинг після OCR — обов'язковий крок перед будь-яким chunking. Без нього різниця між fixed-size і semantic chunking зникає: обидва будуть виробляти некоректні чанки, просто по-різному.

Вплив шуму на якість embedding-векторів

Embedding-модель перетворює текстовий чанк у числовий вектор у n-вимірному просторі. Семантично схожі тексти мають близькі вектори (висока cosine similarity). Semantic search шукає саме таку близькість.

OCR-шум впливає на вектор через два механізми:

Механізм 1: OOV-токени (out-of-vocabulary)

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

Механізм 2: Dilution ефект (розбавлення сигналу)

Embedding-модель усереднює сигнал по всіх токенах чанку (спрощено). Якщо 15–20% токенів у чанку — мусор без семантичного навантаження, вектор «розбавляється»: він стає менш точним представником справжнього змісту.

Практичний приклад: чанк із 400 токенів, де 80 — артефакти (злиплі слова, символи шумів, помилкові переноси). Ефективний семантичний сигнал — не 100%, а ~80%. Cosine similarity з коректним запитом знизиться пропорційно.

Знизиться не до нуля — але може впасти нижче порогу top-k retrieval. Якщо ви шукаєте top-5 чанків, зміщений чанк може опинитись на позиції 6 або 7 — і ніколи не потрапити в контекст LLM.

Наочна ілюстрація: кейс юриста з AskYourDocs

Повертаємося до кейсу з попередньої статті серії, але розбираємо його на рівні векторів.

Клієнт — юрист зі спеціалізацією у будівельному праві — надіслав 21 сторінку зі сканованого архіву. Більшість сторінок відскановані під кутом 90°, 180° або 270°. Стандартний OCR без корекції орієнтації читав їх як:

аМЫМ "9a18 40 S¥3IAVT ONIHLY3HS N33ML3E NOILD¥¥LSNOO

Цей мусор потрапив у векторну базу як валідний текст. Що відбулось з векторами:

З 21 сторінки нормально проіндексувалось 5–6. Решта існувала у векторній базі як статистичний шум — займала місце, але не давала корисного retrieval. При цьому система не повідомляла про проблему: вона повертала результати, просто з 5–6 сторінок замість 21.

Точність відповідей на тестових питаннях: 17%. Після впровадження Vision OCR з автокорекцією орієнтації: 50% — на тому самому проблемному документі.

Чому семантично релевантний чанк не потрапляє в retrieval

Навіть якщо чанк семантично правильний — він може не потрапити в результати retrieval через кілька механізмів, пов'язаних з OCR-шумом.

Сценарій 1: Ключове слово спотворене — пошук не матчить

Запит: «яка відповідальність за порушення строків»
Чанк у базі: «...відповідаль-ність за поруш-ення строків — штраф 0,1% за кожен день...»

Навіть якщо embedding-модель частково «розуміє» спотворені слова через subword-токени — cosine similarity між вектором запиту і вектором чанку буде нижчою за ідеальну. Якщо у вашому індексі є 50 інших чанків про «відповідальність» з чистим текстом — спотворений чанк опиниться нижче threshold і не потрапить у top-k.

Сценарій 2: Чанк «розбавлений» мусором до нерелевантності

Чанк B містить ту саму інформацію, але: «ЗО» замість «30» (кирилиця замість цифри), злиплий перенос «змо-менту», мусор «..;;..» в кінці. Його вектор відрізняється від вектора чанку A. Запит «строк виконання 30 днів» матчитиметься з A краще ніж з B — хоча обидва несуть однаковий зміст.

Сценарій 3: Правильний документ є, але не в top-k

Найнебезпечніший сценарій. Релевантний чанк існує в індексі — але через зміщений вектор він на позиції 8 або 12, а не в top-5. LLM отримує 5 менш релевантних чанків і або відповідає на основі часткової інформації, або галюцинує.

При цьому в логах все виглядає коректно: retrieval повернув k результатів, LLM згенерував відповідь. Ніякого сигналу про проблему немає — тільки неправильна відповідь.

Сценарій 4: False positive retrieval — мусор з високою similarity

Протилежна ситуація: мусорний чанк з перевернутої сторінки потрапляє в top-k через статистичний збіг токенів. LLM отримує нечитабельний контекст і або ігнорує його (добрий сценарій), або намагається побудувати відповідь на основі мусора (поганий сценарій).

Recall і Precision у RAG після поганого OCR: метрики та приклади

Для оцінки якості retrieval використовують дві базові метрики:

• Recall@k — частка релевантних документів, які потрапили в top-k результатів. Якщо є 3 релевантних чанки і всі 3 в top-5 — Recall@5 = 1.0.
• Precision@k — частка релевантних серед повернутих. Якщо у top-5 є 2 релевантних і 3 нерелевантних — Precision@5 = 0.4.

Як OCR-шум впливає на ці метрики

Приклад вимірювання: тест на реальних питаннях

Практичний спосіб виміряти вплив OCR на Recall — підготувати набір питань, відповіді на які ви знаєте точно, і перевірити чи потрапляють потрібні чанки в retrieval.

20–30 таких питань на репрезентативній вибірці архіву дають набагато точнішу картину ніж будь-який синтетичний benchmark.

Практичні методи покращення: препроцесинг, постпроцесинг, вибір OCR-движка

Нижче — конкретні дії, які дають вимірюваний ефект. Розбито за рівнями впливу.

Рівень 1: Препроцесинг зображення (перед OCR)

Рівень 2: Постпроцесинг тексту (після OCR, перед chunking)

Це найбільш ефективний і недооцінений рівень. Постпроцесинг дешевший за перезапуск OCR і дає вимірюваний ефект на retrieval.

Garbage detector: практична реалізація

Детектор мусору — простий, але дуже ефективний компонент. Логіка:

Рівень 3: Вибір OCR-движка

Стратегія вибору: дерево рішень

Коли OCR недостатньо і потрібен Vision-підхід

Навіть ідеально налаштований OCR-пайплайн має системні обмеження. Є клас документів, де жодне покращення препроцесингу не дасть задовільного результату для RAG.

Гібридний пайплайн: практична архітектура

Оптимальна стратегія для більшості реальних архівів — не «OCR або Vision», а маршрутизація:

Вхідний документ
  │
  ├─► Текстовий шар? ──► Так ──► Нативний парсер (PyMuPDF) ──► Chunking
  │
  └─► Ні (скан)
        │
        ├─► Препроцесинг (орієнтація, deskew, denoise)
        │
        ├─► OCR (Tesseract / PaddleOCR)
        │
        ├─► Garbage detector
        │        │
        │        ├─► Якість OK ──► Постпроцесинг ──► Chunking
        │        │
        │        └─► Якість низька ──► Vision OCR (GPT-4o-mini)
        │                                    │
        │                                    └─► Постпроцесинг ──► Chunking
        │
        └─► Логування: сторінка, CER-оцінка, шлях обробки
  

Цей підхід дозволяє обробляти 80–90% документів через дешевий self-hosted OCR і направляти лише проблемні сторінки до Vision OCR. Вартість Vision OCR при такій стратегії знижується в 5–10 разів порівняно з повним переходом.

Що Vision OCR не вирішує

Vision-підхід не є universal fix. Обмеження:

• Вартість при великих обсягах: 100 000 сторінок через GPT-4o-mini — ~$1 500–3 000.
• Затримка: API-виклик займає 2–10 секунд на сторінку. Для систем реального часу — неприйнятно.
• Rate limits: без enterprise-доступу паралельна обробка великого архіву обмежена.
• GDPR: документи відправляються зовнішньому провайдеру. Потребує DPA і може бути заблоковано compliance-політикою.
• Галюцинації VLM: на дуже пошкоджених документах VLM може «вигадати» нечитабельний контент. Потребує валідації.

Детальне порівняння OCR-first і Vision-first архітектур з trade-off аналізом — у наступній статті серії: «Vision RAG vs OCR: порівняння підходів до обробки документів».

Висновки

Деградація RAG через поганий OCR — це не проблема моделі. Це інженерна проблема вхідних даних, яка має конкретні точки виправлення.

Де саме ламається пайплайн — і що з цим робити

Пріоритетний порядок дій

Якщо ви зараз запускаєте або налагоджуєте RAG на сканованих документах — ось послідовність з найбільшим ROI:

1. Аудит архіву — яка частка сканів? Чи є перевернуті сторінки? Яка типова якість?
2. Додати корекцію орієнтації — навіть якщо більшість сторінок нормальні, одна перевернута сторінка в критичному документі коштує дорого.
3. Додати базовий постпроцесинг — нормалізація пробілів, з'єднання переносів, видалення рядків-мусору. Реалізується за кілька годин, дає вимірюваний ефект на retrieval.
4. Побудувати тестовий набір питань — 20–30 питань з відомими відповідями. Вимірювати Recall@5 до і після кожної зміни.
5. Додати garbage detector і маршрутизацію на Vision OCR для проблемних сторінок.
6. Тільки після цього — тюнити chunking-параметри, embedding-моделі, reranker.

Кроки 1–3 дають більше ефекту ніж зміна embedding-моделі з 1536 на 3072 вимірів. Але більшість команд починають з кроку 6 — і дивуються чому результат не покращується.