OCR или LLM для распознавания документов: что выбрать и как проверить

Для типовых печатных документов с фиксированной вёрсткой достаточно классического OCR с правилами. Для документов, где поля плавают по странице, а текст свободный, нужна языковая модель поверх распознанного текста. Мультимодальную модель, читающую страницу «по картинке», берут там, где структура страницы важна, а OCR её теряет: сложные таблицы, рукописные пометки, штампы. На практике почти всегда получается гибрид: каждый подход закрывает свой участок, а общую надёжность дают проверки и порог уверенности.

В статье нет рейтинга моделей и обещаний «точности до N процентов»: такие цифры без вашей выборки документов ничего не значат. Есть порядок выбора, критерии приёмки и способы проверки, которые можно повторить на своих сканах. Если вам нужна готовая услуга, смотрите страницу про распознавание документов и ввод данных в учёт.

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

Под словом «распознавание» прячутся три разные схемы. Они по-разному ошибаются, поэтому и проверять их нужно по-разному.

1. OCR плюс правила и шаблоны

Движок OCR (например, открытые Tesseract или PaddleOCR либо коммерческий продукт) превращает изображение в текст с координатами и оценкой уверенности по словам. Дальше поля достаются правилами: регулярные выражения, привязка к якорям вроде «ИНН» или «Итого», шаблоны под конкретного поставщика. Схема быстрая, дешёвая, предсказуемая и проверяемая: ошибку всегда можно проследить до правила. Ломается там, где вёрстка меняется: новый поставщик, сдвинутая таблица, другой порядок полей. На каждый новый формат приходится писать шаблон.

2. OCR плюс языковая модель

OCR даёт текст, а LLM получает его вместе с описанием нужных полей (схемой) и возвращает структурированный ответ, например JSON. Модель понимает, что «Всего к оплате» и «Итого с НДС» бывают одним и тем же, и не требует шаблона под каждый формат. Она хорошо справляется со свободным текстом: договор, письмо, акт с описанием работ. Слабое место в том, что модель умеет «додумывать»: недостающую цифру в номере, строку, которой нет в документе. И результат зависит от качества OCR: если текст прочитан с ошибкой, модель аккуратно перескажет ошибку.

3. Мультимодальная модель, читающая страницу по картинке

Модель принимает изображение страницы и сама решает, где что находится. Это удобно для сложных таблиц, документов с рукописными пометками, штампами и необычной вёрсткой: структура страницы не теряется на этапе OCR. Но у подхода свои ограничения: страница в высоком разрешении превращается в большое число входных токенов, а при уменьшении картинки мелкий шрифт читается хуже. Поэтому страницы часто режут на фрагменты. Ошибки труднее объяснить, чем у правил, а уверенность модели в своих ответах неочевидна.

Сначала проверьте, нужно ли распознавание вообще

Самая дешёвая и самая точная обработка — та, которой нет. Прежде чем выбирать между OCR и LLM, ответьте на три вопроса.

1. Есть ли структурированная версия? Счета-фактуры, УПД и накладные, которые приходят через оператора электронного документооборота, обычно сопровождаются XML в формализованных форматах. Разбирать нужно его, а не картинку.
2. Есть ли у PDF текстовый слой? Документы, выгруженные из 1С или бухгалтерской программы в PDF, содержат текст как текст. Его достаём напрямую, без OCR, и получаем точные значения и координаты. Проверить просто: если текст в PDF выделяется мышью, слой есть.
3. Нужен ли весь документ? Иногда достаточно номера, даты и суммы для сверки с учётом. Это более простая задача, чем полная выгрузка всех строк таблицы.

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

Какой подход подходит для каких документов

Таблица типовая: для вашего потока документов её нужно проверять на выборке, а не принимать на веру.

Как измерять точность распознавания: эталонная выборка и поля

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

Считаем по полям, а не «в среднем»

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

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

Разделяем и виды ошибок: поле не найдено, найдено неверное значение, значение выдумано. Первое означает, что человек просто заполнит поле. Второе без проверок уйдёт в учёт. Третье — самое неприятное, и о нём следующий раздел. Считаем отдельно и долю документов, прошедших без правки человека, и точность в разрезе поставщиков и типов документов: сводная цифра скрывает, что один контрагент ломает половину потока.

Как поймать выдуманные данные: проверки против галлюцинаций

Языковая модель выдаёт правдоподобный результат даже тогда, когда исходные данные неполны: она может «достроить» номер документа, дописать позицию или подставить ИНН, которого на странице нет. Задавать температуру ноль и просить «не выдумывать» недостаточно: это делает ответ стабильным, но не верным. Ограничение формата вывода схемой обеспечивает валидный JSON, а не то, что значения в нём настоящие. Надёжно работают проверки снаружи модели.

Отдельно просим модель вернуть для каждого значения цитату из текста и страницу. Цитату программа проверяет автоматически, в этом и смысл: модель могла выдумать и цитату, но проверка «такая строка есть в документе» ловит её без участия человека.

Пороги уверенности и ручная проверка

Задача системы — не угадать всё, а отделить уверенное от сомнительного. Сомнительное уходит оператору, а не проводится вслепую. Источники оценки уверенности:

• оценка OCR по словам и символам: движки её отдают, это самый прямой сигнал о плохом скане;
• вероятности токенов языковой модели, если сервер их отдаёт: низкая вероятность в цифрах суммы — повод проверить;
• согласие нескольких путей: если OCR с правилами и LLM вернули разное, документ спорный;
• результаты проверок: не сошлась арифметика или не прошёл формат — документ спорный, как бы уверенно ни отвечала модель.

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

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

Закрытый контур и объём: где можно обрабатывать документы

В документах есть персональные данные (ФИО, паспортные реквизиты в договорах, подписи) и коммерческая информация: цены, условия, реквизиты контрагентов. Отправка таких страниц во внешний облачный сервис распознавания или в API внешней модели — вопрос к службе безопасности и к требованиям закона о персональных данных (152-ФЗ). Если внешний контур не разрешён, используют движки OCR и модели, которые работают на вашем сервере. Сравнение схем описано в материале про свою LLM и внешний API, а как оценить, какое оборудование нужно под модель, — в материале про видеопамять для LLM. Развёртывание в закрытом контуре мы делаем в рамках услуги частных LLM.

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

Скорость и стоимость: считаем формулами, а не обещаниями

Заранее называть «рубль за страницу» бессмысленно: она зависит от модели, железа, длины текста и доли ручной работы. Но стоимость документа раскладывается на части, и каждую можно измерить на пилоте.

• Время обработки = время OCR + (число входных токенов ÷ скорость обработки запроса) + (число выходных токенов ÷ скорость генерации). Входных токенов много, а выходных мало (JSON с полями), поэтому для распознавания важнее скорость чтения запроса, чем скорость генерации.
• Стоимость вычислений на документ = цена часа сервера ÷ число документов в час для своей модели; для внешнего API — токены на входе и выходе умножить на тариф. Тарифы внешних сервисов называет провайдер, мы цен чужих продуктов не приводим.
• Стоимость ручной работы = доля документов в очереди × время оператора на документ × ставка оператора.
• Стоимость ошибки = вероятность необнаруженной ошибки × цена ошибки для учёта. Это слагаемое чаще всего перевешивает остальные, и именно его снижают проверки.

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

Гибрид как типовой ответ

На реальном потоке один подход не покрывает всё. Типовая схема выглядит так, и порядок здесь важен: каждый следующий шаг запускается, только если предыдущий не справился.

1. Если есть XML или текстовый слой, берём данные оттуда, без OCR.
2. Определяем тип документа: счёт, накладная, акт, договор, прочее.
3. Для сканов запускаем OCR с оценкой уверенности по словам.
4. Для известных стабильных шаблонов применяем правила. Они быстрые и проверяемые.
5. Для остальных текст OCR и схема полей идут в языковую модель, которая возвращает структурированный ответ с цитатами.
6. Сложные страницы (рукопись, плохое качество, нестандартные таблицы) читает мультимодальная модель, а результат сверяется с путём из шагов 3–5.
7. Валидаторы проверяют формат, арифметику, справочники и наличие значения в исходном тексте.
8. Порог решает: автоматическая загрузка в учёт или очередь оператора с подсвеченными полями.
9. Журнал фиксирует, что распознано, что исправил человек и почему; исправления пополняют эталонную выборку.

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

Что делаем мы и с чего начать

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

Пилот распознавания на выборке относится к лёгким: 150 000–400 000 ₽ и 2–8 недель по тарифам. Если до этого нужно понять, какие документы и системы вообще участвуют, начните с обследования за 200 000 ₽ (один-два процесса, 2–3 недели), его стоимость вычитается из следующего этапа. Точную цену называем после разбора вашего потока. Чего мы не делаем: не обещаем стопроцентной точности без участия человека и не ведём лицензируемые работы по защите информации.

Если вы ещё не готовы к пилоту, соберите архив документов и проверьте его по списку из статьи как подготовить данные для ИИ-пилота. Остальные направления разработки ИИ собраны на странице разработки ИИ.