Распознавание документов: OCR, IDP или Vision LLM — что выбрать

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

OCR, IDP и Vision LLM часто сравнивают как три поколения одной технологии. На практике они решают разные части задачи. OCR извлекает текст и геометрию, документные модели добавляют структуру и специализированные поля, а мультимодальная модель может гибче интерпретировать нестандартный документ. Ни один из этих уровней сам по себе не делает запись проверенной. Распознавание документов я оцениваю именно по этой цепочке: извлечение, доказательство значения, проверка и только затем запись.

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

OCR отвечает на вопрос, что написано на странице

Классический OCR полезен, когда главная задача — получить текст и координаты. Современные OCR-сервисы также возвращают layout, confidence и другие элементы страницы. Это хорошая основа для поиска, архива, последующего parsing и простых документов со стабильной структурой.

Но OCR не знает бизнес-смысла сам по себе. Строка «12 450,00» может быть итоговой суммой, налогом или значением в таблице. Чтобы безопасно записать её в поле «Сумма документа», нужен дополнительный контекст и проверка.

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

Проверяемые источники: Google Cloud — Document AI overview · Google Cloud — Enterprise Document OCR

IDP добавляет структуру документа и готовые типы полей

Intelligent Document Processing обычно строится вокруг нескольких этапов: OCR, классификация, извлечение структуры и полей, нормализация, валидация, human review. Документные платформы предлагают layout-модели и специализированные processors для распространённых форм.

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

Цена удобства — необходимость хорошо определить target schema. Если команда сама не договорилась, что считается номером документа, датой операции и основанием платежа, готовый processor не решит эту неоднозначность.

Проверяемые источники: Google Cloud — Document AI overview · Microsoft — Document Processing Models — Document Intelligence

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже

Vision LLM полезна там, где layout меняется, а смысл важнее шаблона

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

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

Для редких и вариативных документов Vision LLM может уменьшить количество ручного parsing. Но критичные поля всё равно проходят детерминированные проверки и, при необходимости, подтверждение человеком.

Проверяемые источники: Google Cloud — Document AI overview · Microsoft — Document Processing Models — Document Intelligence

Матрица выбора начинается с типа ошибки

Я бы классифицировал задачу по нескольким признакам: насколько стабилен layout, нужны ли таблицы, сколько типов документов, какие поля критичны, можно ли проверить значение по справочнику или арифметике, насколько дорого отправить исключение человеку.

Стабильный однотипный бланк может отлично работать на OCR плюс правилах. Поток первичных документов выигрывает от IDP с классификацией и human review. Нестандартные многостраничные материалы могут потребовать мультимодального слоя для интерпретации отдельных участков.

Смешанная архитектура нормальна. Не обязательно заставлять одну модель выполнять всё: распознавать, классифицировать, интерпретировать и принимать решение.

• стабильный layout и простые поля — начать с OCR и правил
• типовые бизнес-документы и таблицы — рассмотреть IDP/document processors
• сильная вариативность и смысловые вопросы — добавить Vision LLM как интерпретационный слой
• критичные реквизиты — проверять независимо от выбранного извлечения

Проверяемые источники: Google Cloud — Document AI overview · Microsoft — Document Processing Models — Document Intelligence · AWS — Tables — Amazon Textract

Универсальная точность почти ничего не говорит о готовности процесса

Цифра «точность 99%» без определения выборки и метрики мне мало помогает. В документе может быть пятьдесят полей, но для проведения важны четыре. Ошибка в необязательном комментарии и ошибка в сумме НДС имеют разную цену.

Я бы измерял качество на уровне поля и класса документа. Для каждого критичного реквизита нужны precision/recall или другой понятный критерий, доля ручной правки и причины исключений. Отдельно — straight-through rate только для документов, которые реально дошли до корректного конечного статуса.

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

Проверяемые источники: Google Cloud — Enterprise Document OCR · Microsoft — Document Processing Models — Document Intelligence

Human review должен показывать сомнительное поле, а не весь документ

Если система уверена в двадцати реквизитах и сомневается в одном, я не вижу смысла заставлять сотрудника перечитывать страницу целиком. В review queue полезно показать поле, распознанное значение, фрагмент исходника, причину проверки и допустимые справочные значения.

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

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

Проверяемые источники: Google Cloud — Document AI overview · AWS — Tables — Amazon Textract

Контрольные вопросы перед внедрением

Чем IDP отличается от OCR?

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

Можно ли заменить OCR Vision LLM?

Иногда мультимодальная модель способна решить задачу без отдельного OCR-этапа. Но для массового учётного процесса важны стоимость, воспроизводимость, координаты доказательства и field-level validation. Поэтому выбор лучше делать по конкретному документу и полям.

Какая точность нужна для автоматической обработки документов?

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

Я бы считал выбор технологии завершённым не после эффектного демо, а после ответа на три вопроса: какое критичное значение извлекаем, чем его подтверждаем и куда уходит сомнение. Если эта цепочка определена, OCR, IDP или Vision LLM становятся инструментами, а не предметом веры.

Для соседних проверок пригодятся для «распознавание документов»: Как автоматически извлекать данные из счетов, актов и договоров · Что делать, если AI неправильно распознал документ · Облачное или локальное распознавание документов: что выбрать компании.