⚡ Коротко
- Скан — це фотографія. AI читає текст, а не картинки
- Перевернуті сторінки, низька якість і злиплий текст — три головні причини провалу індексації
- Ми навчили сервіс автоматично визначати орієнтацію і розпізнавати текст через Vision OCR
- Тепер клієнт завантажує будь-який скан — сервіс сам розбирається
- Але є межа: якість на виході залежить від якості на вході
📚 Зміст
Як все почалося: клієнт надіслав тестовий пакет
Кілька тижнів тому до мене звернувся юрист зі спеціалізацією у будівельному праві — він працює з великим архівом документів і шукав рішення для швидкого пошуку інформації по файлах. Після короткого спілкування він надіслав тестовий пакет: 20 сторінок зі свого архіву на 10 000+ файлів.
Це була хороша можливість перевірити AskYourDocs на реальному матеріалі з реальної практики. Я завантажив файл, запустив індексацію і підготував список тестових питань — таких, відповіді на які точно були в документі.
Частина відповідей була правильною. Але частина — містила цифри і факти яких у документі не було взагалі. Сервіс відповідав впевнено, з посиланням на конкретний фрагмент — але інформація була неточною.
Я почав розбиратись де саме втрачається якість. Виявилось що проблема не в моделі і не в логіці пошуку — а в тому як документ потрапляє в індекс. І тут відкрився цілий ланцюжок нюансів які варто знати кожному хто працює зі сканованими архівами.
Чому скан — це не документ для AI
Перше що я зробив після отримання файлу — відкрив його і спробував виділити текст курсором. Не вийшло. Документ виявився сканом: паперові сторінки сфотографовані і збережені у PDF-обгортці без жодного текстового шару всередині. Щоб підготувати його до індексації, я конвертував файл через OCR-інструмент — про те як це робити правильно є окрема детальна стаття: Як підготувати документи для AI-асистента 2026.
Більшість людей не розуміють різниці між "PDF зі скану" і "текстовий PDF". Виглядають однаково. Відкриваються однаково. Але для AI-системи — це небо і земля.
Текстовий PDF містить справжній текстовий шар — символи, слова, речення які можна виділити курсором і скопіювати. AI читає цей шар напряму і індексує з точністю 95–99%. Якщо ви відкриваєте документ і можете виділити будь-яке слово мишкою — це текстовий PDF і він підходить без жодної підготовки.
Скан — це фотографія паперового документа збережена у PDF-обгортці. Всередині — зображення. AI бачить картинку але не може прочитати що на ній написано. Навіть якщо текст на скані виглядає чітко і розбірливо для людського ока — для системи це просто набір пікселів без жодного змісту.
Але навіть після конвертації через стандартний OCR-інструмент з'ясувалась ще одна проблема яку я не очікував: частина сторінок була відсканована під кутом. Не просто трохи нахилена — а повністю перевернута: 90°, 180° або 270° відносно нормального положення тексту. Це трапляється часто коли документи сканують партіями на потокових сканерах або просто кладуть аркуші не тією стороною — особливо в старих архівах де сканування робили без контролю орієнтації.
Коли стандартний OCR зустрічає перевернуту сторінку — він або повертає порожній результат, або — що набагато гірше — видає нечитабельний мусор який зовні виглядає як текст. Саме такий "текст" потрапляв в індекс у нашому випадку: замість реального вмісту сторінок система отримувала рядки на кшталт аМЫМ "9a18 40 S¥3IAVT ONIHLY3HS N33ML3E і будувала відповіді на їх основі. AI не знав що це мусор — він просто використовував те що отримав.
Це пояснює чому якість відповідей була такою низькою навіть після конвертації. З 21 сторінки нормально проіндексувалося лише 5–6. Решта або містила мусор, або була повністю пропущена. І AI не говорив "я не знаю" — він впевнено відповідав на основі того що мав, вигадуючи деталі яких у документі не існувало.
За даними Grand View Research, ринок інтелектуальної обробки документів досяг $2.3 млрд у 2024 році і зростає на 33% щороку — саме тому що бізнес масово стикається з цією проблемою в масштабі. Мільярди сторінок в архівах компаній залишаються або нечитабельними для AI, або читаються з критичними помилками через неправильну орієнтацію і низьку якість вихідних сканів.
Три проблеми які ми знайшли в одному файлі
Щоб зрозуміти де саме втрачається якість, я почав аналізувати що реально потрапляє в індекс. Для цього зробив простий SQL-запит до бази даних і подивився на вміст чанків. Те що я побачив пояснило все.
Документ містив одразу три незалежні проблеми — і кожна з них окремо вже достатня щоб зіпсувати результат.
Проблема 1: перевернуті сторінки. Більшість сторінок у документі були відскановані під різними кутами — 90°, 180° і 270° відносно нормального положення. Це одна з найпоширеніших проблем при пакетному скануванні паперових архівів: оператор кладе аркуші стосом і не перевіряє орієнтацію кожного.
Стандартний OCR при цьому поводиться непередбачувано. Іноді він повертає порожній результат — і сторінка просто пропускається. Але частіше він намагається "прочитати" перевернутий текст і видає нечитабельний мусор який зовні виглядає як справжній текст: аМЫМ "9a18 40 S¥3IAVT ONIHLY3HS N33ML3E. Саме цей мусор потрапляв у векторну базу. AI не знав що це безглуздий набір символів — він сумлінно будував відповіді на тому що отримав.
Чому це критично: векторний пошук знаходив ці "чанки" як релевантні до запиту — адже вони формально існували в базі. AI отримував їх як контекст і намагався синтезувати відповідь. Результат — впевнені відповіді з цифрами і фактами яких у документі ніколи не було.
Проблема 2: низька якість сканування. Частина сторінок була сфотографована при поганому освітленні, з розмиттям або нерівномірним контрастом. Навіть якщо орієнтація правильна — OCR при низькій якості зображення читає символи з помилками. За даними клінічних досліджень при роботі з медичними документами, OCR досягає 99% точності при скануванні з роздільністю 300 DPI і вище. При нижчих показниках точність падає суттєво — і це стосується будь-яких OCR-систем включно з Vision AI моделями.
Чому це критично: помилка навіть в одному символі числа або назви може повністю змінити відповідь. Якщо у документі написано "28.28 perms" а OCR прочитав "28.23" або "2B.28" — AI відповість неправильно навіть якщо логіка пошуку спрацювала ідеально.
Проблема 3: злиплий текст без пробілів. Кілька сторінок містили стандартний confidential notice — юридичне застереження про конфіденційність яке зустрічається в кінці більшості ділових листів і документів. Але через особливості друку або сканування всі слова злилися в один суцільний рядок без пробілів: containconfidentialinformation,propristary,and/orprivilegedmaterial.
GPT-4o-mini — модель яку я використовую для Vision OCR — не розпізнає такий текст як читабельний. З його точки зору це не текст а артефакт зображення. Тому сторінка повертала відповідь "[IMAGE - no text]" і повністю випадала з індексу. На цих сторінках були важливі дані — специфікації продуктів і технічні характеристики — які клієнт хотів шукати.
Чому це критично: пропущена сторінка це не просто прогалина в індексі. Коли користувач задає питання по темі з пропущеної сторінки — AI не знаходить відповіді в базі і або чесно відповідає "не знаю", або — якщо системний промпт не налаштований достатньо жорстко — починає вигадувати на основі загальних знань.
Підсумок діагностики. З 21 сторінки документу нормально проіндексувалося лише 5–6. Решта або містила мусор з перевернутих сторінок, або була пропущена через злиплий текст і погану якість. Точність відповідей на тестових питаннях — близько 17%. І головна проблема була не в низькій точності, а в тому що AI не казав "я не знаю" — він давав відповіді з конкретними цифрами і назвами яких у документі не існувало.
Як ми навчили сервіс читати скани автоматично
Після діагностики стало зрозуміло: проблему потрібно вирішувати не на рівні підготовки документів клієнтом, а на рівні самого сервісу. Клієнт не повинен думати про те під яким кутом відсканований його архів або чи достатньо висока роздільність. Він просто завантажує файл — і отримує результат.
Я розбив рішення на чотири послідовні кроки. Кожен закриває конкретну проблему з тих що я знайшов у діагностиці.
Крок 1: детектор мусору — щоб не індексувати сміття.
Перша проблема яку потрібно було вирішити: стандартний парсер (Apache Tika) витягав текст з PDF але не міг відрізнити нормальний текст від мусору зі скану. Обидва виглядали як "є текст" — і обидва йшли в індекс.
Я додав простий але ефективний детектор: сервіс аналізує перші 1000 символів витягнутого тексту і рахує частку слів написаних повністю великими літерами. В нормальному діловому тексті таких слів зазвичай 10–20% — це абревіатури, заголовки, назви. У тексті з перевернутого скану — 50–70% і більше, бо OCR читає перевернуті рядкові літери як великі.
Якщо детектор бачить що більше 40% слів — ALL CAPS, він позначає документ як "мусор зі скану" і передає його у Vision OCR pipeline замість стандартної індексації. Це відсіває головну причину неправильних відповідей ще до того як будь-який текст потрапляє в базу.
Крок 2: Vision OCR через GPT-4o-mini — щоб читати зображення як людина.
Стандартний OCR читає зображення як набір форм і намагається зіставити їх з відомими символами. Він не розуміє контексту, не знає що "28.28" це число в таблиці а не випадковий набір цифр, і не може відновити структуру якщо сканування нечітке.
Vision AI — інший підхід. GPT-4o-mini отримує зображення сторінки і розуміє його як людина: бачить таблицю як таблицю, заголовок як заголовок, колонку чисел як колонку чисел. Я налаштував детальний промпт з конкретними правилами: витягни весь текст без пропусків, збережи структуру таблиць через роздільник "|", порожня клітинка — дефіс, цифри точно як написано без округлення, якщо на сторінці тільки малюнок або фото без тексту — написати "[IMAGE - no text]".
Детальний промпт критично важливий саме для технічних і юридичних документів де таблиці з числами є основним носієм інформації. Без чітких правил модель могла округлювати цифри, пропускати рядки або об'єднувати колонки — і відповідь виглядала б правдоподібно але була б неточною.
Крок 3: автоматична корекція орієнтації — щоб не пропускати перевернуті сторінки.
Навіть з Vision OCR залишалась проблема перевернутих сторінок. GPT-4o-mini так само як і стандартний OCR не може нормально прочитати текст якщо він перевернутий — і повертає "[IMAGE - no text]".
Рішення: якщо на першому проході сторінка повернула "[IMAGE - no text]" — сервіс автоматично запускає три додаткові спроби. Він повертає зображення на 90°, потім на 180°, потім на 270° — і після кожного повороту знову відправляє в GPT-4o-mini. Як тільки модель знаходить читабельний текст — зупиняємось і зберігаємо результат. Якщо жоден з чотирьох кутів не дав тексту — сторінка позначається як зображення і пропускається без помилки.
Це рішення збільшує час обробки документу — кожна перевернута сторінка робить до чотирьох запитів до API замість одного. Для 21-сторінкового документу обробка зайняла близько 5 хвилин. Але це одноразова операція при завантаженні — після індексації всі відповіді на питання приходять миттєво.
Крок 4: чесність замість галюцинацій — щоб AI казав "не знаю" коли не знає.
Технічні кроки вирішували проблему якості індексації. Але залишалась окрема проблема на рівні поведінки AI: навіть коли релевантних фрагментів не знаходилось — модель давала відповідь з вигаданими цифрами замість того щоб чесно сказати про відсутність інформації.
Причина: стандартна поведінка мовних моделей — бути корисними і давати відповідь. Якщо контекст з документу слабкий або нерелевантний — модель "заповнює прогалини" зі своїх загальних знань. Для загальних питань це нормально. Для технічних документів з конкретними числами — це критична помилка.
Я оновив системний промпт агента і додав жорстке правило: якщо у знайдених фрагментах немає чіткої і прямої відповіді — написати саме це: "У документі не знайдено точної інформації на це питання. Спробуйте переформулювати або уточніть розділ документу." — і зупинитись. Жодних додаткових пояснень, жодних "зазвичай в таких документах...", жодних цифр які модель "пам'ятає" з тренувальних даних.
Додатково заборонив фрази-індикатори галюцинацій: "зазвичай", "як правило", "типово для таких документів". Якщо ці слова з'являються у відповіді — це майже завжди означає що модель відповідає зі своїх знань а не з документу.
Результат після всіх змін. Точність відповідей на тому самому проблемному документі зросла з 17% до 50%. Половина тестових питань отримала правильні відповіді — на документі де більшість сторінок була перевернута або пошкоджена. Але головне досягнення не в цифрі точності, а в тому що зникли галюцинації: тепер якщо сервіс не знає — він так і каже. А клієнт може переформулювати питання або завантажити якісніший документ.
Що це означає для бізнесу
Після всіх змін сервіс став працювати принципово інакше з точки зору клієнта. Раніше щоб отримати нормальний результат — потрібно було вручну перевірити кожен файл, конвертувати скани через OCR-інструмент, перевірити орієнтацію сторінок і тільки потім завантажувати. Для архіву з 10 000 файлів це тижні ручної роботи.
Тепер pipeline виглядає інакше: клієнт завантажує файл — будь-який, в будь-якому стані. Сервіс сам перевіряє чи є в PDF текстовий шар. Якщо є і він читабельний — індексує напряму. Якщо виявляє мусор або скан — автоматично перемикається на Vision OCR. Якщо сторінки перевернуті — пробує всі чотири орієнтації. Якщо сторінка виявилась фотографією або кресленням без тексту — пропускає і переходить до наступної.
Для бізнесу який працює з паперовими архівами це означає конкретну економію. Юридична фірма з архівом договорів і судових рішень може завантажити скани напряму без підготовки. Медичний центр може додати відскановані протоколи і нормативи. Будівельна компанія — технічну документацію і акти. Жоден з цих сценаріїв не вимагає від клієнта технічних знань або ручної обробки файлів.
Важливо також розуміти економіку Vision OCR для великих архівів. Обробка одного документу через GPT-4o-mini коштує в середньому $0.20–0.40 залежно від кількості сторінок — це одноразова витрата при завантаженні. Після індексації всі відповіді на питання по документу не потребують додаткових витрат на OCR. Для архіву з 10 000 документів загальна вартість початкової індексації може скласти $2 000–4 000 — значно менше ніж вартість ручної обробки того самого обсягу.
Але перш ніж говорити про масштабування — є важливе застереження яке я вважаю принципово важливим сказати чесно.
Межа технології: коли навіть Vision OCR не рятує
Vision OCR — це не магія і не універсальне рішення. Він читає те що бачить. І якість того що він бачить напряму визначає якість результату.
У нашому тестовому документі навіть після всіх покращень залишились сторінки які сервіс не зміг прочитати нормально. Злиплий текст без пробілів — containconfidentialinformation — GPT-4o-mini так і не розпізнав як читабельний при жодній орієнтації. Сторінки з дуже низьким контрастом або розмиттям — давали часткові результати з пропущеними словами і числами.
За даними бенчмарку OCR-систем 2025 року, найкращі системи досягають 98–99% точності для чіткого друкованого тексту відсканованого з роздільністю 300 DPI і вище. Але для низькоякісних сканів — нечіткі краї, нерівномірний контраст, плями, пошкодження паперу — точність може падати до 60–70%. А 30% помилок у технічному або юридичному документі — це не просто "трохи неточно". Це неправильні цифри в специфікаціях, неправильні суми в договорах, неправильні дози в медичних протоколах.
Є ще одна межа яку важливо розуміти: GPT-4o-mini — потужна але не найточніша модель для складних сканів. Старші документи з нестандартними шрифтами, рукописні нотатки на полях, таблиці зі складною структурою — все це дається важче ніж чистий друкований текст. Перехід на GPT-4o (старшу модель) дає помітно кращі результати на складних документах але коштує в 5–10 разів дорожче на обробку.
Тому моя практична рекомендація перед масовим завантаженням великого архіву:
Спочатку візьміть 15–20 документів які репрезентують весь архів — різний вік, різна якість сканування, різні типи вмісту. Завантажте їх і підготуйте список конкретних питань відповіді на які ви точно знаєте. Перевірте скільки відповідей правильних, скільки неточних, скільки — "інформацію не знайдено". Якщо точність вас задовольняє для вашого сценарію використання — можна масштабувати. Якщо ні — є два шляхи: покращити якість вихідних сканів (пересканувати з вищою роздільністю) або перейти на сильнішу Vision-модель.
Саме так я порадив діяти клієнту-юристу з яким починалась ця історія. Не "завантажуйте всі 10 000 документів і подивимось" — а "протестуйте на 20 репрезентативних файлах і виміряйте точність на питаннях які важливі саме для вашої практики". Це єдиний чесний спосіб зрозуміти чи підійде технологія для конкретного архіву.
Детальніше про підготовку документів — у нашій статті Як підготувати документи для AI-асистента 2026.
Висновок: гарантій немає, але є чесність
Після завершення всіх змін я написав клієнту чесний звіт: документи які він надіслав — складні скани змішаної якості, частина сторінок перевернута, частина пропущена через злиплий текст. Після покращень точність зросла з 17% до 50% на тому самому файлі. Але для архіву з 10 000 документів такої ж якості — результат буде нестабільним і потребує попереднього тестування на репрезентативній вибірці.
Я не обіцяв що все запрацює ідеально. І саме це, як мені здається, і є правильний підхід до роботи з AI-інструментами для бізнесу.
За час розробки і тестування цього кейсу я сформулював для себе кілька висновків які вважаю важливими для будь-кого хто впроваджує AI-пошук по документах.
Якість на вході визначає якість на виході. Це звучить банально але насправді ігнорується в більшості впроваджень. Компанії інвестують в AI-платформу, налаштовують її, навчають команду — і отримують розчаровуючий результат тому що 40% архіву це скани низької якості з 1990-х років. Ніяка модель не витягне точну інформацію з нечитабельного джерела.
Галюцинації небезпечніші ніж "не знаю". Сервіс який чесно каже "у документі не знайдено інформації" — набагато кориснішний ніж той що впевнено видає неправильні цифри. Особливо в юридичній, медичній і технічній сферах де точність критична. Налаштування системного промпту на чесність — не менш важлива частина роботи ніж технічна частина індексації.
Тестування на реальних питаннях — єдиний об'єктивний критерій. Не кількість проіндексованих документів, не швидкість обробки, не красива демонстрація на ідеальних файлах. Підготуйте список з 20–30 конкретних питань відповіді на які ви знаєте точно — і перевірте скільки відповідей правильних. Цей показник скаже більше ніж будь-яка маркетингова цифра.
Автоматизація знижує поріг входу але не усуває обмеження фізичного світу. Vision OCR і автоматична корекція орієнтації — це реальне покращення яке економить години ручної роботи. Але якщо папір пожовтів, чорнило вицвіло або скан зроблений на телефон в темній кімнаті — жодна автоматизація не відновить інформацію яку фізично неможливо прочитати.
Цей кейс змінив те як я пояснюю сервіс потенційним клієнтам. Раніше я починав з можливостей. Тепер починаю з питання: покажіть мені 5 документів з вашого архіву і скажіть які питання ви хочете задавати. Це дозволяє одразу оцінити реальну придатність архіву і не витрачати час клієнта на впровадження яке не дасть очікуваного результату.
💬 Є питання або хочете обговорити конкретний сценарій — пишіть у Telegram.
📖 Читайте також
