Чому AI не читає ваш скан — і як ми це вирішили

📚 Зміст

• Як все почалося: клієнт надіслав 20 сторінок
• Чому скан — це не документ для AI
• Три проблеми які ми знайшли в одному файлі
• Як ми навчили сервіс читати скани автоматично
• Що це означає для бізнесу
• Межа технології: коли навіть Vision OCR не рятує
• Висновок: гарантій немає, але є чесність

Як все почалося: клієнт надіслав тестовий пакет

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

Я завантажив файл, запустив індексацію і підготував список з 18 тестових питань — таких, відповіді на які точно були в документі і які я міг перевірити вручну. Результат виявився несподіваним:

Важливе уточнення: ці цифри — не показник сервісу, а показник якості вхідного документа. Той самий пайплайн на чистому текстовому PDF дає 95–99% точності. Проблема була не в моделі і не в логіці пошуку — а в тому що більшість сторінок потрапила в індекс як не читабельний мусор ще до того як AI взагалі отримав шанс відповісти. Саме це і є темою цього кейсу.

Але була і друга проблема — поведінкова: сервіс не казав «я не знаю». Він відповідав впевнено, посилався на конкретний фрагмент — але 44% відповідей містили цифри і факти яких у документі не існувало. Для юридичних документів де кожна цифра має значення — це критично.

Я почав розбиратись де саме втрачається якість. Перша підозра — модель або логіка пошуку. Але проблема виявилась раніше в пайплайні:

Скан PDF
  ↓
OCR                    // шар інʼєкції шуму
  ↓
Chunking               // текст вже спотворений
  ↓
Embeddings             // семантичне викривлення
  ↓
Vector DB              // незворотне поширення помилки

З 21 сторінки нормально проіндексувалось лише 5–6. Решта потрапила в базу як мусор — і саме з цього мусору AI будував впевнені відповіді. Далі розбираю що саме пішло не так і як ми це виправили.

Чому скан — це не документ для AI

Перше що я зробив після отримання файлу — відкрив його і спробував виділити текст курсором. Не вийшло. Документ виявився сканом: паперові сторінки збережені у PDF-обгортці без жодного текстового шару всередині.

Більшість людей не розуміють різниці між «PDF зі скану» і «текстовий PDF». Виглядають однаково. Відкриваються однаково. Але для AI-системи — це принципово різні речі:

Детальніше про підготовку різних типів документів до індексації — у статті Як підготувати документи для AI-асистента 2026 та в огляді OCR у сучасних AI-системах: від сканів до RAG.

Здавалося б, рішення просте: запустити OCR і завантажити результат. Але тут з'ясувалась проблема яку я не очікував: більшість сторінок була відсканована під кутом — 90°, 180° або 270° відносно нормального положення тексту. Це типова ситуація для старих архівів де документи сканували партіями без контролю орієнтації кожного аркуша.

Коли стандартний OCR зустрічає перевернуту сторінку — він або повертає порожній результат, або видає нечитабельний мусор який зовні виглядає як текст. Система отримувала рядки на кшталт:

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

І будувала відповіді на їх основі. AI не знав що це мусор — він просто використовував те що отримав з індексу.

Це не виняток. За оцінками аналітиків, ринок інтелектуальної обробки документів зростає на 30%+ щороку — саме тому що більшість компаній стикається з цією проблемою в масштабі: архіви де значна частина файлів або нечитабельна для AI, або читається з критичними помилками через неправильну орієнтацію і низьку якість сканів.

Три проблеми які ми знайшли в одному файлі

Щоб зрозуміти де саме втрачається якість, я зробив SQL-запит до бази і подивився на вміст чанків які реально потрапили в індекс. Картина була чіткою: документ містив три незалежні проблеми — і кожна з них окремо вже достатня щоб зіпсувати результат.

Проблема 1: перевернуті сторінки

Більшість сторінок була відсканована під кутами 90°, 180° і 270° — типова ситуація для пакетного сканування паперових архівів де оператор кладе аркуші стосом без перевірки орієнтації кожного.

Стандартний OCR при цьому видає мусор який зовні виглядає як текст:

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

Векторний пошук знаходив ці чанки як релевантні — вони формально існували в базі. AI отримував їх як контекст і синтезував відповідь. Результат: впевнені відповіді з цифрами яких у документі ніколи не було.

Проблема 2: низька якість сканування

Частина сторінок відсканована при поганому освітленні або з нерівномірним контрастом. За технічними стандартами OCR-систем, точність розпізнавання при роздільності 300+ DPI становить 98–99% — і суттєво падає нижче цього порогу. Це стосується будь-яких OCR-рішень, включно з Vision AI моделями.

Помилка в одному символі числа повністю змінює відповідь. Якщо в документі «28.28 perms» а OCR прочитав «28.23» — AI відповість неправильно навіть якщо логіка пошуку спрацювала ідеально.

Проблема 3: злиплий текст без пробілів

Кілька сторінок містили стандартний confidential notice де через особливості друку або сканування всі слова злилися в суцільний рядок:

containconfidentialinformation,proprietary,and/orprivilegedmaterial

GPT-4o-mini не розпізнає такий текст як читабельний і повертає «[IMAGE - no text]». Сторінка повністю випадає з індексу. На цих сторінках були специфікації і технічні характеристики — саме те що клієнт хотів шукати.

Підсумок діагностики:

Ці цифри — характеристика конкретного проблемного документа, не сервісу. На чистому текстовому PDF той самий пайплайн дає 95–99%. Але саме такі «складні» архіви — норма для більшості компаній які накопичували документи роками без стандартів сканування.

Як ми навчили сервіс читати скани автоматично

Після діагностики стало зрозуміло: проблему потрібно вирішувати не на рівні підготовки документів клієнтом, а на рівні самого сервісу. Клієнт не повинен думати про те під яким кутом відсканований його архів. Він просто завантажує файл — і отримує результат.

Я розбив рішення на чотири послідовні кроки. Ось як виглядає оновлений pipeline:

Завантаження файлу
  ↓
Витяг тексту (Apache Tika)
  ↓
Детектор мусору            // >40% ALL CAPS → скан
  ↓ (якщо мусор)
Vision OCR (GPT-4o-mini)   // читає сторінку як зображення
  ↓ (якщо [IMAGE - no text])
Автокорекція орієнтації    // 90° → 180° → 270° → повтор
  ↓
Chunking → Embeddings → Vector DB
  ↓
Відповідь з жорстким промптом  // "не знаю" замість галюцинацій

Крок 1: детектор мусору

Стандартний парсер (Apache Tika) витягав текст з PDF але не міг відрізнити нормальний текст від мусору зі скану. Обидва виглядали як «є текст» — і обидва йшли в індекс.

Я додав простий детектор: сервіс аналізує перші 1000 символів витягнутого тексту і рахує частку слів написаних повністю великими літерами.

Поріг спрацювання: >40% ALL CAPS → документ позначається як скан і передається далі. Це відсіює головну причину галюцинацій ще до індексації.

Крок 2: Vision OCR через GPT-4o-mini

Стандартний OCR читає зображення як набір форм — він не розуміє контексту і не може відновити структуру таблиці якщо сканування нечітке. GPT-4o-mini отримує сторінку як зображення і розуміє її як людина: бачить таблицю як таблицю, колонку чисел як колонку чисел.

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

- Витягни весь текст без пропусків
- Збережи структуру таблиць через роздільник "|"
- Порожня клітинка → дефіс
- Цифри точно як написано, без округлення
- Якщо на сторінці тільки малюнок → "[IMAGE - no text]"

Без чітких правил модель могла округлювати цифри або об'єднувати колонки — відповідь виглядала б правдоподібно але була б неточною.

Крок 3: автоматична корекція орієнтації

Якщо на першому проході сторінка повернула «[IMAGE - no text]» — сервіс автоматично запускає три додаткові спроби:

0° → [IMAGE - no text]
  ↓ автоповорот
90° → [IMAGE - no text]
  ↓ автоповорот
180° → читабельний текст ✓ → зберігаємо

Як тільки модель знаходить читабельний текст — зупиняємось. Якщо жоден з чотирьох кутів не дав результату — сторінка позначається як зображення і пропускається без помилки.

Швидкість — єдиний реальний компроміс: кожна перевернута сторінка робить до 4 запитів до API замість одного. Для 21-сторінкового документу — близько 5 хвилин. Але це одноразова операція при завантаженні — після індексації відповіді приходять миттєво.

Крок 4: чесність замість галюцинацій

Технічні кроки вирішували якість індексації. Але залишалась поведінкова проблема: коли релевантних фрагментів не знаходилось — модель заповнювала прогалини із загальних знань замість того щоб сказати «не знаю».

Я оновив системний промпт і додав жорстке правило:

Якщо у знайдених фрагментах немає чіткої відповіді →
  "У документі не знайдено точної інформації на це питання.
   Спробуйте переформулювати або уточніть розділ документу."

Заборонені фрази-індикатори галюцинацій:
  - "зазвичай"
  - "як правило"
  - "типово для таких документів"

Якщо ці фрази з'являються у відповіді — це майже завжди означає що модель відповідає зі своїх тренувальних даних, а не з документа.

Результат після всіх змін

Нагадаю контекст: ці цифри — результат на проблемному скані низької якості. Той самий пайплайн на чистому текстовому PDF дає 95–99%. Головне досягнення тут — не ріст точності з 17% до 50%, а повне зникнення впевнено неправильних відповідей. Для юридичних документів це важливіше ніж будь-яка інша метрика.

Що це означає для бізнесу

Після всіх змін клієнт більше не думає про формат файлу або орієнтацію сторінок. Він просто завантажує документ — сервіс сам розбирається що з ним робити: визначає чи потрібен Vision OCR, виправляє орієнтацію, індексує результат. Це одноразова операція. Після неї — звичайний пошук по документах без жодних додаткових витрат.

Для яких галузей це актуально

Проблема сканованих архівів не унікальна для юристів. Вона є у будь-якій галузі де документи накопичувались роками в паперовому вигляді — і тепер потрібен швидкий пошук по ним.

Спільне у всіх цих сценаріях: документи вже існують, їх багато, і вони різної якості. Ніхто не буде перескановувати архів заради впровадження AI. Саме тому сервіс має вміти працювати з тим що є — а не вимагати ідеальних файлів на вході.

Скільки коштує Vision OCR: реальний розрахунок

Головне що треба розуміти: Vision OCR — це одноразова витрата при завантаженні. Після того як документ проіндексовано, кожне питання до нього не потребує додаткових витрат на OCR. Ви платите один раз за обробку — і далі шукаєте скільки завгодно.

Вартість розраховується просто. GPT-4o-mini через OpenRouter коштує $0.15 за мільйон input-токенів і $0.60 за мільйон output-токенів. Одна сторінка формату A4 у Vision OCR — це приблизно 1 500–2 000 input-токенів (зображення) і 300–600 output-токенів (витягнутий текст).

Вартість обробки однієї сторінки:

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

Вартість обробки архіву (розрахунок по сторінках):

Для клієнта-юриста з яким починалась ця історія — архів на 10 000+ файлів де середній документ це 15–20 сторінок — це приблизно 150 000–200 000 сторінок. Вартість Vision OCR-обробки: $150–400 залежно від якості сканів. Ручна обробка того ж обсягу за $15/год зайняла б роки і коштувала б сотні тисяч доларів.

Важливе уточнення: ці цифри — вартість самого OCR-виклику до API. До них додається вартість підписки на сервіс і зберігання даних. Але навіть з урахуванням цього — автоматична обробка дешевша за ручну на два порядки.

Що Vision OCR не замінює

Автоматична обробка знижує поріг входу — але не усуває необхідність людського контролю там де це критично. Для медичних і юридичних документів де кожна цифра має правові наслідки — Vision OCR прискорює роботу, але не замінює верифікацію людиною.

Правильна модель використання: AI знаходить потрібний фрагмент за секунди, юрист або лікар верифікує відповідь в оригінальному документі. Це не "AI замість людини" — це "AI замість години пошуку вручну".

Межа технології: коли навіть Vision OCR не рятує

Vision OCR — це не магія. Він читає те що бачить. Якість вхідного зображення напряму визначає якість результату — і жодна модель не може відновити інформацію яку фізично неможливо прочитати.

Навіть після всіх покращень у тестовому документі залишились сторінки які сервіс не зміг прочитати нормально. Ось реальна картина по типах документів:

30% помилок у технічному або юридичному документі — це не «трохи неточно». Це неправильні цифри в специфікаціях, неправильні суми в договорах, неправильні дози в медичних протоколах. Саме тому якість вхідного скану — не технічна деталь, а бізнес-рішення.

GPT-4o-mini vs GPT-4o: коли варто перейти

GPT-4o-mini — модель яку я використовую за замовчуванням для Vision OCR. Вона швидка і економічна, але має межі на складних документах. GPT-4o дає помітно кращі результати — але коштує в 5–10 разів дорожче на обробку.

Помилка на символ (CER, Character Error Rate) — частка символів які модель прочитала неправильно. CER 10% означає що кожне десяте слово містить помилку. Для договору де написано «28.28 кв.м» — це може стати «28.23 кв.м» або «2В.28 кв.м». Юридично — різні документи.

Мій підхід: починати з GPT-4o-mini на всьому архіві. Сторінки де mini повернув «[IMAGE - no text]» або явно нечитабельний результат — повторно обробити через GPT-4o. Це дає баланс між якістю і вартістю: 90–95% сторінок обробляється дешево, складні випадки — точно.

Як протестувати архів перед масштабуванням

Найдорожча помилка при впровадженні RAG на сканованих архівах — завантажити всі документи одразу і дізнатися про проблеми вже після. Правильний підхід: спочатку виміряти на малій вибірці, потім масштабувати.

Ось покроковий процес який я рекомендую клієнтам перед повним впровадженням:

Крок 1: репрезентативна вибірка — 15–20 документів.
Не обирайте найкращі файли — обирайте типові. Архів зазвичай містить кілька категорій якості: свіжі скани з офісного сканера, старі скани з 1990-х, фотографії документів зі смартфона, факси. У вибірці має бути по 3–5 документів кожного типу. Якщо в архіві є рукописні документи або документи з печатками — вони теж мають бути у вибірці.

Крок 2: питання з відомими відповідями — 20–30 штук.
Не загальні («про що цей документ»), а конкретні і перевіряємі:

• «Яка загальна сума за договором від 12.03.2021?»
• «Який термін виконання робіт вказаний в акті №47?»
• «Яке прізвище підрядника у специфікації на сторінці 4?»

Саме такі питання виявляють реальну точність — особливо на числах і власних назвах де OCR-помилки найбільш критичні.

Крок 3: виміряйте три показники, не два.
Більшість тестів рахують лише «правильно / неправильно». Це недостатньо. Важливо розрізняти три категорії відповідей:

Третя категорія — найнебезпечніша. «Не знайдено» — це прийнятна відповідь системи. Впевнена неправильна відповідь — це проблема яку треба вирішити до масштабування.

Крок 4: рішення залежно від результату.
Після тестування можливі три сценарії:

Саме так я порадив діяти клієнту-юристу з яким починалась ця історія. Не «завантажуйте всі 10 000 файлів і подивимось» — а «протестуйте на 20 репрезентативних файлах і виміряйте точність на питаннях які важливі саме для вашої практики». Це єдиний спосіб зрозуміти реальну придатність архіву до того як вкладати час і бюджет у повне впровадження.

Детальніше про підготовку документів різних форматів до індексації — у статті Як підготувати документи для AI-асистента 2026. Про те як OCR-помилки впливають на весь RAG-пайплайн — у матеріалі OCR у сучасних AI-системах: від сканів до RAG.

Висновок: гарантій немає, але є чесність

Після завершення всіх змін я написав клієнту чесний звіт: документи складні, частина сторінок перевернута, частина пропущена через злиплий текст. Ось що вдалось зробити на тому самому проблемному файлі:

Я не обіцяв клієнту що все запрацює ідеально. Контекст важливий: 17% на вході — це не вирок сервісу, це вирок якості вхідного документа. Той самий пайплайн на чистому текстовому PDF дає 95–99%. Але для реального архіву де скани різної якості — 50% точності і нуль галюцинацій це вже інструмент яким можна користуватись. І саме така чесність, на мій погляд, і є правильним підходом до роботи з AI для бізнесу.

Чотири висновки з цього кейсу

1. Скан — це не документ для AI за замовчуванням.
Більшість компаній дізнається про це вже після того як завантажила весь архів. Перевірте простим тестом: відкрийте файл і спробуйте виділити текст курсором. Якщо не виходить — перед вами скан і він потребує OCR перед індексацією. Це не проблема — це відправна точка.

2. Галюцинації небезпечніші ніж «не знаю».
Сервіс який чесно каже «у документі не знайдено інформації» — набагато кориснішний ніж той що впевнено видає неправильні цифри. Особливо в юридичній, медичній і технічній сферах де точність критична. Кілька заборонених фраз у системному промпті і жорстке правило «якщо не знаєш — скажи» кардинально змінюють поведінку моделі. Це не складно — але більшість впроваджень цього не роблять.

3. Якість на вході визначає якість на виході — і це не метафора.
Компанії інвестують місяці у налаштування пайплайну, вибір embedding-моделі, оптимізацію chunking-стратегії — і отримують незадовільний результат тому що 40% архіву це скани низької якості. Перевірте якість вхідних документів раніше ніж почнете оптимізувати все інше.

4. Тест на реальних питаннях — єдиний чесний критерій.
Не кількість проіндексованих документів і не демонстрація на ідеальних файлах. 20–30 конкретних питань відповіді на які ви знаєте точно — і три категорії результату: правильно / «не знайдено» / впевнено неправильно. Ця проста методика скаже більше ніж будь-який маркетинговий бенчмарк.

Як я тепер починаю розмову з клієнтом

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

«Покажіть мені 5 документів з вашого архіву і скажіть які питання ви хочете задавати.»

П'ять документів і двадцять хвилин — і вже зрозуміло чи підійде технологія для конкретного архіву. Якщо документи читабельні і питання конкретні — можемо починати. Якщо ні — краще сказати про це чесно на старті ніж після місяця роботи.

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

• Як підготувати документи для AI-асистента: формати, OCR, чеклист 2026
• AI для юридичних компаній: безпека даних і конфіденційність
• Безпека AI: чеклист 20 питань перед впровадженням
• OCR у сучасних AI-системах: від сканів до RAG