ИИ для сканов и PDF: как собрать проверяемый OCR-процесс вместо магического импорта

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

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

Сначала установите тип файла

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

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

Отделите распознавание от извлечения полей

OCR возвращает распознанные символы, иногда с вероятностью и положением на странице. Следующий этап превращает их в структуру: дата, номер, сумма, единица измерения. Именно тут полезен языковой анализ, но модель должна выдавать подтверждение для каждого поля — исходный текст, страницу и отметку уверенности. Если значение не найдено явно, правильнее вернуть null или статус «проверить», чем дополнить его догадкой.

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

Сравните локальную и облачную обработку

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

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

Подготовьте набор для проверки

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

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

Встройте безопасную проверку

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

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

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

FAQ

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

Для работы агента с файлами установите ограничения до запуска по нашему гайду о приёмке изменений. Если документ требует веб-проверки, используйте отдельную цепочку поиска и подтверждений из разбора Search & Fetch.