OCR или vision-модель для документов: как выбрать

Где возникает проблема

Проблема обычно начинается с простой ошибки: команда считает, что любой PDF - это просто текст в контейнере. На деле один файл может содержать обычный текстовый слой, скан после печати, фото страницы с телефона, печать поверх таблицы и рукописную пометку в углу.

Из-за этого один и тот же PDF дает разный результат в разных пайплайнах. Договор, выгруженный из учетной системы, OCR читает почти без потерь. Тот же договор после печати и повторного сканирования уже теряет буквы, путает цифры и сдвигает строки.

Разница видна даже между похожими документами. У одной анкеты ровные поля и чистый шрифт, у другой страница слегка повернута, часть текста бледная, а печать закрывает дату. Для OCR это уже совсем другой уровень сложности, хотя человек видит почти тот же документ.

Проблема усиливается, когда OCR режет страницу на блоки, строки, слова, а иногда и на отдельные символы. Такой разбор удобен для поиска текста, но часто ломает смысл страницы. Модель получает фрагменты без нормального контекста и уже не понимает, к какой ячейке относится число, какая подпись стоит под каким полем и перекрывает ли печать фамилию или просто лежит рядом.

В этот момент спор про OCR и vision перестает быть теорией. Если смысл живет не только в словах, но и в расположении элементов, чистый текстовый вывод становится беднее исходного документа. Особенно это заметно на таблицах, формах, многостраничных заявлениях и сканах с пометками.

Ошибка выбора всплывает уже на первых тестах. Команда берет двадцать документов, пятнадцать проходят хорошо, а пять внезапно разваливаются: поля перепутаны, суммы уехали в соседние строки, имя клиента склеилось с номером документа. Обычно дело не в промпте. Проблема возникает раньше - в том, как документ вообще подали в модель.

Хороший ранний сигнал - нестабильность на почти одинаковых страницах. Если одна страница извлекается точно, а следующая с тем же шаблоном дает другой JSON, причина часто не в LLM, а в том, что OCR уже потерял часть структуры. В некоторых файлах картинка и есть данные.

Когда хватает OCR

OCR хорошо работает на "скучных" документах. Если на странице ровный печатный текст, нормальный контраст и привычная структура, прогонять изображение через vision-модель часто просто незачем.

Обычный случай - счета, акты, заявления и анкеты с предсказуемой формой. Текст идет по строкам, поля стоят на своих местах, а системе нужны дата, сумма, ИИН, БИН, номер договора или адрес. В такой задаче OCR обычно быстрее, дешевле и проще в проверке.

Еще один хороший признак - стабильный поток. Если файлы приходят с одного сканера или из одного PDF-генератора, ошибки повторяются редко. В продакшене это удобно: проще настроить шаблоны, проверки по маске и контроль пустых полей.

Обычно OCR хватает, если текст напечатан ровно, на странице мало таблиц или они совсем простые, печати и подписи не перекрывают нужные поля, верстка почти не меняется от файла к файлу, а вам нужны не смысл и структура всей страницы, а несколько конкретных значений.

Есть и совсем практичный критерий. Если после OCR вы можете уверенно проверить результат правилами, значит схема подходит. Сумма должна быть числом, дата - в понятном формате, ИИН - из 12 цифр, номер счета - по известному шаблону. Когда такие проверки ловят почти все промахи, добавлять vision-слой чаще всего не нужно.

На однотипных формах OCR нередко выигрывает. Он дает более предсказуемый выход и не тратит лишние токены на фон, пустые поля и декоративные элементы страницы.

Простой пример - пачка ежемесячных счетов от одного поставщика. Макет одинаковый, нужных полей пять-шесть, качество сканов ровное. В такой ситуации разумнее взять хороший OCR, добавить постпроверки и не усложнять систему. Если из 100 файлов ручной разбор нужен только в паре случаев, этого обычно достаточно.

Когда лучше отправлять скан целиком

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

Чаще всего это видно на формах, договорах и анкетах. OCR может честно вытащить почти все слова, но потерять то, что для проверки важнее самих слов: где стоит подпись, на какой блок попала печать, к какой строке относится рукописная пометка, что было в левой колонке, а что в правой.

Если на странице есть печать, подпись или запись от руки, скан стоит отправлять целиком. OCR обычно превращает такую страницу в набор шумных фрагментов. Vision-модель читает не только символы, но и саму сцену: видит, что подпись стоит под согласием, а печать перекрывает часть реквизитов, а не висит где-то рядом.

С таблицами та же история. Когда распознавание ломает сетку, строка легко слипается с соседней, а столбец уезжает вправо. Для счета, выписки или акта это уже не мелкая ошибка, а другая сумма, другой товар или другой номер. Если документ держится на структуре, картинка обычно надежнее текста.

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

Отдельный случай - плохой скан. Если лист сняли под углом, край обрезали, на бумагу легла тень, а фон шумит, OCR быстро сдается или начинает додумывать буквы. Vision-модель в таких условиях часто держится лучше, потому что смотрит на страницу целиком, а не по кускам текста.

Практическое правило простое: если вам нужно понять не только "что написано", но и "где это находится и как связано", отправляйте изображение.

Что картинка дает сверх текста

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

Картинка сохраняет контекст: где стоит подпись, к какому блоку относится печать, рядом с каким полем поставили галочку. Для анкеты, договора или заявления это меняет смысл. Одна и та же фраза в верхней части страницы и внизу рядом с подписью - это уже разный контекст.

Хороший пример - форма с колонками. OCR может распознать все слова, но перепутать порядок чтения: сначала левую колонку, потом часть правой, потом сноску. Человек все равно поймет страницу по виду. Vision-модель тоже смотрит на расположение и обычно лучше удерживает форму целиком.

Это особенно заметно в таблицах. Текст из ячеек OCR вытащит, но нередко потеряет, к какой строке и какому столбцу относится число. Если в документе есть объединенные ячейки, вложенные таблицы или подписи мелким шрифтом, картинка дает модели больше опорных сигналов.

Есть и визуальные метки, которые вообще плохо живут как обычный текст: галочки в чекбоксах, штампы и круглые печати, зачеркнутые поля, рукописные пометки на полях, отметки вроде "не заполнять" поверх блока. OCR такие вещи либо пропускает, либо превращает в мусор.

Для банка, страховой или HR-команды это не мелочь. Галочка в одном квадрате и крест в другом могут менять решение по документу.

Разметка страницы тоже несет смысл. Отступы, рамки, подписи над полями, выноски мелким шрифтом, порядок блоков сверху вниз - все это помогает понять, что является заголовком, что комментарием, а что значением поля. OCR часто упрощает документ до линейного текста и теряет эти слои.

На практике разница хорошо видна на простой анкете клиента. OCR вернет имя, ИИН, адрес и фразу про согласие. Vision-модель чаще поймет еще и то, что согласие относится к отдельному блоку, печать стоит только на последней странице, а поле с адресом зачеркнули и вписали новое вручную.

Если ответ зависит не только от слов, но и от того, где именно они стоят, картинка дает больше смысла, чем чистый текст.

Как принять решение

Не спорьте о подходе в теории. Возьмите 30-50 реальных документов из вашего потока и проверьте оба варианта на одном и том же наборе. Это самый быстрый способ убрать догадки.

Сразу разложите документы на три группы: чистые, шумные и сложные. К чистым относятся ровные PDF и хорошие сканы с читаемым текстом. К шумным - кривые сканы, тени, сильное сжатие, фото с телефона. К сложным - таблицы, печати, подписи, рукописные пометки и страницы с несколькими смысловыми блоками.

Как провести тест

Не сравнивайте системы на разных задачах. Дайте OCR и vision один и тот же список полей: ФИО, ИИН, номер договора, дата, сумма, название организации, наличие печати, строки из таблицы. Тогда разница станет видна сразу.

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

Полезно считать пять метрик:

• точность по каждому полю;
• долю документов, где ответ годится без ручной правки;
• среднее время ответа;
• цену на один документ;
• число случаев, где модель уверена, но ошиблась.

Последний пункт часто недооценивают. Тихая ошибка хуже явного сбоя, потому что уходит дальше по процессу.

Когда оставить смешанную схему

Если чистые документы OCR обрабатывает быстро и дешево, не надо отправлять в vision все подряд. Но если в потоке много фото, анкет с печатями или сложных таблиц, стоит держать второй маршрут для трудных случаев.

Обычно рабочая схема выглядит так: сначала простая проверка качества файла, потом OCR для чистых страниц, а для шумных или спорных документов - vision. Такой маршрут часто дает лучший баланс по цене и качеству.

Если вы уже сравниваете несколько моделей через единый шлюз вроде AI Router, такой тест собрать проще. На airouter.kz можно прогонять один и тот же набор документов через разных провайдеров через один OpenAI-совместимый эндпоинт, не меняя SDK и базовую интеграцию. Для пилота это просто удобно.

Где работает смешанная схема

На практике редко нужен выбор "только OCR" или "только vision". Чаще лучше работает двухслойный подход: сначала вынимаете текст там, где страница чистая и читается без сюрпризов, а изображение подключаете только для сложных случаев.

Хорошие сканы, цифровые PDF и простые формы почти всегда стоит сначала прогонять через OCR. Это дешевле, быстрее и проще для последующей проверки. OCR-текст удобно использовать как базовый слой для поиска полей, нормализации дат, сумм и номеров документов.

Проблемы начинаются там, где ответ зависит не только от слов, но и от того, где они стоят на странице. Таблица может сломаться в обычном OCR, печать может закрыть часть строки, а галочка в чекбоксе вообще не превратится в нормальный текст. В таких страницах изображение дает модели контекст, который OCR теряет.

Смешанная схема полезна, когда у вас есть явные правила переключения. Их лучше прописать заранее, а не решать на глаз после первых ошибок. Например, включать vision, если OCR дает низкую уверенность или много странных символов; передавать изображение страницы, если макет влияет на ответ; переводить страницу в vision, если после OCR пропали обязательные поля; использовать vision для многоколоночных страниц и анкет с мелкими примечаниями на полях; оставлять OCR по умолчанию для обычных страниц без сложной верстки.

Даже когда вы включаете vision, OCR-текст не стоит выбрасывать. Часто дешевле и точнее передать оба слоя: текст как быстрый черновик, картинку как способ проверить структуру и спорные места. Модель может взять номер договора из OCR, а по изображению понять, что рядом стоит не подпись клиента, а штамп канцелярии.

Для команды это обычно выглядит как простая политика маршрутизации. Чистые страницы анкеты идут в текстовый пайплайн, а страницы с таблицей доходов и сканом печати - в vision-модель. Если вы используете AI Router, такие правила удобно держать в одном месте и переключать модели без переделки всего кода.

Такой подход снижает расходы и уменьшает число тихих ошибок. За vision вы платите только там, где картинка действительно меняет ответ.

Пример на одной анкете

Представим анкету клиента в банке: одна страница, печатная форма, часть полей заполнена от руки. На первый взгляд задача простая. Нужно вытащить ФИО, номер документа, дату рождения и пару ответов из таблицы с чекбоксами.

OCR с такой формой справляется частично. Он уверенно читает ФИО и номер документа, потому что эти поля напечатаны крупно и стоят в ожидаемом месте. Если цель только в том, чтобы забрать текст из ровных строк, этого уже может хватить.

Проблемы начинаются там, где смысл живет не в самих словах, а в их расположении. В анкете есть таблица с вариантами ответа, и OCR путает строки: значение из одной колонки прилипает к соседней. Еще хуже с чекбоксом. Текст рядом он видит, а саму галочку может пропустить или принять за мусор.

Для банка это уже серьезная ошибка. Если система не заметила отмеченное согласие, тип занятости или статус резидентства, дальше по цепочке пойдет неверная анкета. Человеку потом придется сверять скан вручную, хотя текст вроде бы распознался без явных проблем.

Vision-модель смотрит на такую страницу иначе. Она видит не только слова, но и форму целиком: где находится поле, к какому блоку относится подпись, стоит ли отметка в чекбоксе, пересекает ли печать часть таблицы, не съехала ли строка при сканировании. Печать для нее тоже часть смысла, а не просто шум поверх текста.

На одной и той же анкете итог может отличаться заметно. OCR вернет аккуратный текст, но потеряет связь между полями. Vision-модель чаще сохранит контекст страницы и поймет, что галочка относится именно к нужному пункту, а печать частично закрывает ячейку, но не меняет ответ.

Поэтому выбор зависит не от того, сколько текста в документе. Он зависит от того, где хранится смысл. Если смысл сидит в строках и абзацах, OCR обычно дешевле и проще. Если он сидит в разметке формы, отметках, печатях и связи между зонами страницы, лучше выбрать картинку или смешанную схему.

Частые ошибки

Самая дорогая ошибка - смотреть только на среднюю точность по всему набору файлов. Среднее число успокаивает, но прячет провалы на редких и тяжелых документах. Если 90% счетов читаются хорошо, а 10% анкет с печатями и кривыми сканами ломают пайплайн, в продакшене вы будете разбирать именно эти 10%.

Часто команды тестируют подход на слишком чистых примерах: ровные PDF, хороший контраст, без теней, без пометок ручкой. Это почти никогда не похоже на реальный поток. В жизни приходят фото со смартфона, бледные копии, перекошенные страницы, таблицы с мелким шрифтом и подписи, которые залезают на текст.

Есть и еще одна тихая статья расходов - повторные прогоны. Один неуверенный ответ редко остается одним. Команда перезапускает OCR с другими настройками, режет страницу на части, потом отправляет тот же документ в vision-модель, а иногда просит оператора проверить спорные поля вручную. На бумаге один документ кажется дешевым, а по факту цена растет в два или три раза.

Чаще всего ошибки выглядят так: считают общий процент совпадений и не смотрят на провалы по типам документов; сравнивают модели на красивых PDF, а не на реальных сканах; не считают цену повторных запросов и ручной проверки; не разбирают отдельно таблицы, подписи, печати и штампы; кладут в один промпт договоры, анкеты, счета и накладные.

Последний пункт бьет сильнее, чем кажется. Когда вы смешиваете разные документы в один шаблон промпта, модель теряет ориентиры. Для анкеты ей нужно найти поля и рукописные пометки, для счета - строки таблицы, для договора - структуру разделов. Один и тот же запрос для всех этих случаев почти всегда дает более шумный результат.

Хорошая проверка выглядит скучно, но работает лучше. Разбейте документы на 4-5 классов, соберите плохие примеры, посчитайте не только точность, но и стоимость исправления ошибок. Если задача про таблицы и печати, тестируйте именно их. Тогда выбор будет опираться на реальный риск, а не на красивую демо-метрику.

Быстрый чек-лист

Когда вы решаете, как обрабатывать документы, возьмите 20-30 реальных файлов из своего потока и проверьте их по нескольким вопросам. Обычно этого хватает, чтобы убрать лишние споры внутри команды.

• Есть ли на странице то, что OCR читает с ошибками: печати, рукописные подписи, галочки в чекбоксах, штампы, фото внутри формы?
• Ломает ли OCR структуру: путает колонки, рвет таблицы, переносит подписи полей не туда, меняет порядок блоков?
• Нужен ли вам ответ по макету, а не только по словам?
• Можете ли вы включать vision только для сложных файлов?
• Устраивают ли вас задержка и цена?

Правило простое. Если на первые два вопроса вы почти всегда отвечаете "нет", начните с OCR. Если "да" встречается часто, ставьте смешанную схему. Если документ живет за счет формы, отметок и визуальных признаков, vision лучше ставить первым.

Что делать дальше

Не спорьте на уровне мнений. Возьмите 50-100 реальных документов из одного потока: например, анкеты, счета или заявления. В наборе должны быть и чистые PDF, и кривые сканы, и страницы с печатями, и документы с таблицами.

Сразу решите, как будете считать качество. Иначе разговор быстро упрется во вкус команды, а не в результат. Обычно достаточно четырех показателей: точность извлечения нужных полей, ошибки в таблицах, датах и суммах, доля документов, которые ушли на ручную проверку, и цена с временем обработки одного файла.

Не пытайтесь проверить все типы документов разом. Один процесс дает честную картину быстрее, чем большой архив, где смешаны договоры, анкеты и счета. Если вы автоматизируете анкеты, тестируйте только анкеты.

После этого опишите простые правила, по которым система выбирает маршрут. Текстовый PDF с ровной версткой часто можно отправлять в OCR или сразу в текстовый пайплайн. Плохой скан, печать поверх текста, подпись, таблица со сложной сеткой или фото документа с телефона лучше сразу вести в vision.

Пограничные случаи не надо угадывать вручную. Задайте явные условия: если OCR дал низкую уверенность, пропустил поля или сломал структуру таблицы, страница идет во второй шаг. Такая смешанная схема обычно дешевле, чем отправлять в vision все подряд.

Пилот лучше запускать на живом, но узком сценарии. Подойдет поток заявлений за одну неделю или один тип входящих документов из бэк-офиса. Так вы быстро увидите, сколько правок делают операторы, где растет цена и какие ошибки повторяются.

Если вы хотите сравнить несколько моделей и маршрутов без переписывания интеграции, пилот можно прогнать через AI Router. Это единый OpenRouter-совместимый шлюз с OpenAI-совместимым эндпоинтом, поэтому команде достаточно сменить base_url и оставить прежние SDK, код и промпты. Для части команд это еще и способ сразу учесть хранение данных в Казахстане, маскирование PII и аудит-логи, если такие требования есть уже на старте.