OCR, LLM или VLM: как выбрать обработку документов

Сначала определите результат

Распознавание отвечает на вопрос «что написано». Извлечение — «какое значение относится к нужному полю». Интерпретация — «какой вывод можно сделать». Прочитать все символы счёта ещё не значит правильно связать цену с позицией. Найти дату в договоре ещё не значит определить срок исполнения обязательства.

OCR — распознавание текста на изображении. Текстовая LLM обрабатывает переданный ей текст; для скана ей нужен этап получения текста. VLM — модель, работающая с изображением и текстом. Она может участвовать и в распознавании, и в извлечении, и в ответах о документе. Название технологии само по себе не определяет границы готового продукта.

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

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

Почему OCR и LLM можно использовать вместе

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

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

Проверяйте весь путь до принятого документа. Сохранённый JSON может соответствовать схеме и при этом содержать чужую сумму. Успешная передача через API подтверждает доставку данных, а не их верность.

Xiaomi-OCR-0: что подтверждено источниками

В официальном репозитории Xiaomi-OCR-0 выпуск весов отмечен 30 сентября 2026 года. Технический отчёт на arXiv подан 28 сентября 2026 года. Более поздние октябрьские сообщения о модели не делают этот выпуск октябрьским релизом.

Авторы описывают модель как VLM с 0,8 млрд параметров для разбора документов и задач понимания их содержимого. В репозитории перечислены получение структурированного Markdown, извлечение заданных полей в JSON и ответы на вопросы по изображениям документов.

Результаты тестов в отчёте и репозитории — измерения авторов на указанных ими наборах. Мы их не воспроизводили, модель для этой статьи не запускали. Они не доказывают точность на русскоязычных счетах конкретной компании и не дают готовой оценки стоимости обработки.

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

Матрица выбора по типам документов

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

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

Как построить проверяемый пилот

1. Опишите поток. Типы, объём, число страниц, языки, качество сканов, таблицы, новые отправители. Отдельно включите пустые, повреждённые и дублирующиеся файлы.
2. Создайте эталон. Для каждого файла зафиксируйте обязательные поля, строки таблиц, допустимое отсутствие значения и страницу-источник. Спорные значения согласует владелец процесса.
3. Разделите настройку и приёмку. Не проверяйте результат только на примерах, по которым подбирали правила. Связанные копии одного документа должны оставаться в одной группе; добавьте отложенные документы с другими шаблонами.
4. Запишите правила сравнения. Где допустима нормализация пробелов и дат, где нужно точное совпадение, как учитывать пропуск, лишнее поле и неверную связь ячеек. Реквизиты нельзя оценивать как «примерно похожие».
5. Сравните одинаковые условия. Зафиксируйте версии моделей, настройки, оборудование или сервис, повторные попытки и обработку длинных файлов. Отдельно измерьте задержку и ручное время.
6. Согласуйте критерии запуска заранее. Какие ошибки блокируют передачу, кто разбирает исключения, сколько времени допустимо ждать и какая стоимость приемлема. Универсального процента качества для всех процессов нет.

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

Учебный счёт: две ошибки после извлечения

Полностью синтетический пример. Счёт ДЕМО-042 от 05.11.2026 содержит две позиции: А — 2 штуки по 1 500 ₽, Б — 1 штука за 2 000 ₽. Итог — 5 000 ₽; в этом упрощённом примере нет налогов, скидок и доставки. Значения ниже придуманы для иллюстрации контроля. Это не вывод Xiaomi-OCR-0 или другой запущенной модели и не клиентский кейс.

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

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

Почему одного confidence недостаточно

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

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

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

Считайте стоимость принятого документа

Цена распознавания страницы не включает всю работу. Для одного и того же периода сложите вычисления или API, предобработку, повторные попытки, хранение, ручные проверки, исправления и сопровождение. Разделите сумму на количество документов, принятых по согласованным правилам. Затраты на отклонённые файлы тоже остаются в числителе.

Учебный расчёт, не тариф Dev Crabs: пусть обработка партии стоит 1 000 ₽, проверка и исправления — 2 500 ₽, сопровождение этой партии — 500 ₽. Из 100 входящих документов приняты 80. Тогда 4 000 / 80 = 50 ₽ за принятый документ. Деление только стоимости API на 100 дало бы 10 ₽ и скрыло бы основную часть работы.

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

Когда переходить от пилота к интеграции

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

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

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

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

Частые вопросы