Документ потрапляє в модель двома каналами. Текстовий шар - символи, які можна виділити курсором - читається напряму і точно. PDF-сторінки сучасні асистенти додатково бачать як зображення: так читаються графіки, схеми і скани. Точність цих каналів різна, тому головна вимога до формату проста: все, що має бути прочитано дослівно, має лежати в текстовому шарі. DOCX, TXT і Markdown складаються з нього повністю. PDF має його, коли створений з текстового редактора.
Скан, фото і PNG-скріншот - це пікселі. Сучасні моделі читають зображення справді добре: розпізнати документ на фото, розібрати скріншот, описати схему - робочі задачі. Межа проходить на точній обробці тексту: дрібний шрифт, печатки, рукописні вставки і низька якість зйомки дають помилки читання, які далі виглядають як впевнені факти. Картинка годиться для швидкого погляду; для реквізитів, цитат і правок потрібен текстовий шар.
Скинутий у чат скан хороші асистенти читають самі, без окремого прохання: хто зором прямо зі сторінки-зображення, хто вбудованим розпізнаванням (OCR) - залежно від сервісу. Зручність має зворотний бік: крок читання пікселів стає невидимим, і його помилки успадковуються ланцюжком далі мовчки. Класика - переплутані 0 і О, 1 і І, зʼїдені коми в сумах, пропущені рядки на печатках і рукописних вставках.
Окреме розпізнавання перед подачею все ще має сенс для довгих сканів і регулярних потоків: воно створює текстовий шар, який далі читається точно і дешево.
Тому правило не залежить від того, хто запускав розпізнавання - ти чи асистент: після OCR фінансових і реквізитних документів числа звіряються з оригіналом окремо. Для договорів і листів досить вибіркової перевірки пари абзаців. Чистий текстовий файл, коли він є, завжди надійніший за найкраще розпізнаний скан.
Таблиця - це структура: рядки, колонки, значення клітинок, іноді формули. CSV і XLSX передають цю структуру повністю. Скріншот таблиці передає лише картинку: модель відновлює з неї структуру на око, і на широких таблицях зʼїжджають колонки, губляться обʼєднані клітинки, зникають формули.
З структурованою таблицею модель може рахувати кодом - точно. З картинкою таблиці вона може лише передбачати цифри - окремий розбір, чому це різні речі.
Великий текстовий документ входить у вікно моделі цілком - різати його на шматки здебільшого зайве. Ризик у іншому: точність на матеріалі з середини великого документа падає раніше, ніж вичерпується вікно. Помилка з середини виглядає так само гладко, як точна відповідь.
У сервісів є пороги, і вони важливі саме для сканів. У чаті Claude візуальний аналіз PDF працює до 100 сторінок; довші PDF, до 1000 сторінок, читаються лише за текстовим шаром. Тому довгий скан без текстового шару там просто не прочитається - його ділять на частини або розпізнають заздалегідь. Щільні PDF важчі, ніж здаються: кожна сторінка як зображення коштує близько двох тисяч токенів. Пороги - стан на серпень 2026, вони регулярно змінюються.
Робочий прийом той самий, що і проти вигадок: питай про конкретні розділи і проси цитату зі сторінкою. Прив'язка до сторінки перетворює перевірку на секундну справу і одразу показує, чи модель взагалі дивилася в потрібне місце.
Один документ - один файл. Архіви розпаковуються в агентних режимах: там у асистента є пісочниця з власною машиною; звичайний чат архів здебільшого не приймає. І тут та сама механіка, що зі сканами: процес автоматичний і зазвичай успішний, але збої трапляються тихо - кириличні імена файлів ламаються, вкладені папки губляться, частина файлів пропускається без повідомлення. Розпакований набір файлів - передбачуваніший вхід. Назви файлів осмислені: "Договір_оренди_v3.docx" читається і моделлю, і тобою в історії чату; "Scan_0034.pdf" - ні. Версії документа не подаються разом без пояснення: дві схожі редакції поруч - готовий ґрунт для змішування пунктів.
Коли задача стосується кількох документів, назви їх у запиті явно: "порівняй редакцію v2 і v3, зміни покажи таблицею". Модель працює з тим, що названо; неназване вона добиратиме на власний розсуд.