Когда компания тестирует распознавание документов с помощью ИИ, проверка обычно выглядит довольно просто. Берут несколько счетов, актов, договоров или отчётов, загружают их в систему и смотрят: правильно ли модель нашла нужные реквизиты.
Вот сумма. Совпала.
Вот дата. Совпала.
Вот номер договора. Тоже правильно.
Если таких успешных примеров набралось достаточно много, возникает ощущение, что технология готова к работе.
Но в реальном процессе есть ещё один тест, который намного важнее красивой демонстрации: что сделает система, если нужного значения в документе вообще нет?
Хорошая автоматизация должна уметь не только находить информацию. Она должна уметь честно сказать: «не найдено».
Именно с этим у систем на базе языковых моделей возникают самые неприятные ошибки.
Найти неправильное число иногда хуже, чем ничего не найти
Представим годовой отчёт на несколько сотен страниц. Система должна извлечь из него набор финансовых показателей.
Спрашиваем выручку — модель находит правильное значение.
Спрашиваем прибыль — тоже правильно.
Просим найти численность сотрудников — значение есть, оно найдено верно.
После нескольких таких проверок кажется, что всё работает.
А затем запрашиваем показатель, которого в документе нет.
Проблема в том, что рядом почти наверняка есть много других чисел. Таблицы, проценты, показатели за предыдущий период, значения для отдельных подразделений. Модель может найти семантически похожий фрагмент и решить, что одно из этих чисел подходит под запрос.
На выходе получается аккуратный структурированный результат. Есть название показателя, есть число, иногда даже указана страница.
Только такого показателя в исходном документе не было.
Для человека, который вручную читает документ, отсутствие информации обычно очевидно. Для автоматизированного процесса выдуманное значение гораздо опаснее. Оно выглядит как обычные данные и может незаметно уйти дальше: в учётную систему, отчёт, таблицу, CRM или расчёт.
Поэтому ошибка вида «ничего не нашли» часто безопаснее ошибки вида «нашли то, чего не существует».
"Не найдено" — это полноценный правильный результат
При проектировании систем распознавания документов полезно изменить само отношение к результату.
Обычно мы мысленно предполагаем, что на входе есть документ, а внутри документа обязательно находится нужное поле. Задача ИИ — это поле найти.
В реальности возможны как минимум три варианта.
Значение есть, и система его правильно нашла.
Значение есть, но система его не нашла.
Значения в документе нет вообще.
Последний случай принципиально отличается от второго. Если модель не различает их между собой, она начинает компенсировать отсутствие информации догадкой.
Поэтому "NOT FOUND", пустое значение или статус «в документе отсутствует» нужно считать таким же нормальным результатом обработки, как найденную сумму или дату.
Это особенно важно в бухгалтерии и документообороте. Если на счёте плохо читается расчётный счёт, правильным результатом может быть пустое поле и отправка документа на проверку. Намного хуже получить двадцать убедительно выглядящих цифр, которые модель собрала из других частей документа.
Нельзя тестировать систему только на удобных документах
Из этого следует довольно простое правило приёмки.
Если система должна извлекать двадцать полей, нельзя проверять её только на документах, где все двадцать полей присутствуют и хорошо читаются.
Такой тест показывает лишь способность модели работать в идеальных условиях.
В контрольной выборке обязательно должны быть документы, где части данных нет. Нужны плохие сканы, фотографии под углом, несколько похожих чисел рядом, разные формы одного документа, старые шаблоны, таблицы со сложной структурой, исправленные версии и документы, в которых нужный реквизит отсутствует полностью.
Например, если мы распознаём счета, полезно специально добавить случаи, где не указан договор, отсутствует отдельный реквизит банка, номер документа читается неоднозначно или вместо привычного шаблона поставщик прислал фотографию с телефона.
Именно на таких документах становится понятно, умеет система работать или умеет только хорошо выглядеть на демонстрации.
Поиск и извлечение — это две разные задачи
При работе с большими документами полезно разделять как минимум два этапа.
Первый — найти участок документа, где предположительно находится нужная информация.
Второй — извлечь конкретное значение из найденного участка.
Если система ошиблась на первом этапе и принесла модели неправильную страницу, даже очень хорошая модель может извлечь из неё совершенно корректное число. Просто это будет корректное число не для того вопроса, который мы задавали.
Представим, что нужно найти показатель за 2026 год, а поиск достал таблицу за 2025-й. Модель может идеально прочитать её и вернуть значение без единой ошибки распознавания.
Формально извлечение сработало.
Бизнесовый результат неправильный.
Поэтому при тестировании полезно отдельно смотреть, нашла ли система правильный источник, и только потом — правильно ли извлекла из него значение.
Это особенно важно для договоров, отчётности, технической документации и больших многостраничных PDF.
Третий этап — обычная проверка результата
Даже правильно найденное и распознанное значение не обязательно нужно сразу отправлять дальше.
Очень многое можно проверить обычным кодом.
ИНН должен соответствовать определённому формату и проходить проверку контрольных цифр. БИК имеет фиксированную длину. Расчётный счёт состоит из определённого количества цифр. Дата должна существовать. Сумма не должна содержать буквы. Если система извлекла номер договора, можно проверить, существует ли такой договор в базе.
Для некоторых полей можно применять бизнесовые ограничения. Например, ожидаемая сумма не может быть отрицательной или отличаться от суммы документа в десять раз. Если такое произошло, это повод не просить модель «подумать ещё раз», а отправить случай на проверку.
Получается три независимых слоя:
найти источник → извлечь значение → проверить значение.
Чем лучше эти этапы отделены друг от друга, тем проще понять причину ошибки и тем безопаснее вся автоматизация.
ИИ не должен быть единственным источником уверенности в собственном ответе
Популярный подход выглядит так: попросить модель вернуть не только значение, но и уровень уверенности.
Например:
"Сумма: 128 400 ₽. Уверенность: 96%."
Выглядит удобно, но относиться к такой цифре как к объективной вероятности нельзя. Модель не измеряет свою точность так же, как измерительный прибор. Она лишь генерирует ещё одно значение на основании контекста и инструкции.
Уверенность может быть дополнительным сигналом, но гораздо полезнее иметь проверяемые признаки.
С какой страницы взято значение?
Какой фрагмент документа использован?
Был ли текст распознан напрямую или получен из изображения?
Прошла ли формальная проверка?
Есть ли в документе несколько похожих кандидатов?
Совпадает ли найденный контрагент со справочником?
Вот это уже данные, на основании которых система может решить: результат можно принять автоматически или его нужно показать человеку.
Источник значения должен сохраняться вместе со значением
Если автоматизация работает с важными документами, я бы вообще не сохранял результат распознавания без ссылки на его происхождение.
Недостаточно записать:
"Сумма: 128 400 ₽".
Полезнее хранить примерно такую структуру:
"Значение: 128 400 ₽"
"Источник: страница 3"
"Фрагмент: строка итоговой суммы"
"Статус проверки: пройдена"
"Требуется человек: нет"
Для пользователя интерфейс может быть намного проще. Но внутри системы желательно иметь возможность восстановить путь от результата обратно к исходному документу.
Это полезно не только для отладки ИИ.
Если через месяц бухгалтер обнаружит неправильное значение, можно будет понять, что именно произошло. Система нашла не ту страницу? Неправильно распознала цифру? Выбрала не тот документ? Или исходный файл изначально содержал ошибку?
Без такой трассировки всё превращается в спор с чёрным ящиком.
Особенно опасны похожие значения
Многие ошибки возникают не из-за плохого качества документа, а наоборот — из-за того, что в документе слишком много хороших кандидатов.
В отчётности рядом могут находиться значения за несколько лет.
В договоре — основная сумма, аванс, штраф, лимит ответственности и стоимость отдельного этапа.
В счёте — сумма без НДС, НДС и итоговая сумма.
В технической документации один и тот же показатель может приводиться для нескольких моделей оборудования.
Человек понимает значение заголовка, структуру таблицы и контекст. Автоматической системе эту связь ещё нужно сохранить.
Поэтому тест «модель правильно читает цифры» недостаточен. Нужно проверять, правильно ли она понимает, к чему конкретно относится каждая цифра.
Более сильная модель не отменяет тестирование
Можно решить, что все эти проблемы возникают только у небольших или дешёвых моделей, а достаточно подключить самую сильную — и вопрос закроется.
Качество действительно будет отличаться. Более сильная модель может лучше понимать сложные таблицы, контекст и неоднозначные формулировки.
Но архитектурно задача не меняется.
Если нужного значения нет, система всё равно должна уметь зафиксировать его отсутствие. Если найден неправильный фрагмент, более умная модель не всегда сможет понять, что ей дали не тот источник. Если результат можно проверить математически или по справочнику, нет причин заменять эту проверку доверием к модели.
Поэтому хороший процесс строится так, чтобы повышение качества модели улучшало процент автоматической обработки, но не было единственной защитой от ошибки.
Сегодня 80% документов проходят автоматически и 20% уходят человеку. Завтра новая модель позволяет безопасно пропускать 90%.
Архитектуру для этого переписывать не нужно.
Как правильно собирать контрольную выборку
Для пилота я бы не брал сотню случайных документов.
Лучше сознательно собрать несколько категорий.
Обычные документы хорошего качества нужны как базовая проверка. Затем нужны сложные, но корректные документы: нестандартные шаблоны, большие таблицы, несколько страниц, разные поставщики.
Отдельно необходимы документы с отсутствующими полями. Это принципиально важно: система должна показать, что умеет не отвечать.
Следующая группа — неоднозначные случаи, где есть несколько похожих значений.
И наконец, реальные плохие документы: фотография, скан низкого качества, помятый лист, рукописная пометка, частично закрытый реквизит.
Для каждого документа заранее фиксируется правильный результат.
После этого уже можно считать не субъективное «вроде работает», а нормальные показатели.
Какую долю существующих значений система нашла?
Сколько правильных значений извлекла?
Сколько раз придумала значение там, где его не было?
Сколько документов отправила на ручную проверку?
Вот последний вопрос особенно важен для экономики проекта.
Ошибки бывают разной стоимости
Допустим, система обрабатывает тысячу документов.
В первом варианте она автоматически проводит 990, но в десяти случаях незаметно ошибается.
Во втором — автоматически проводит 900, а ещё 100 честно отправляет сотруднику на проверку, причём среди автоматически принятых практически нет ошибок.
Первая система формально автоматизирует 99% документов.
Вторая — только 90%.
Но для бухгалтерии, финансов или юридически значимых процессов второй вариант может быть намного лучше.
Поэтому максимальный процент автоматизации не должен становиться основной целью проекта.
Нужно искать баланс между объёмом ручной работы и ценой пропущенной ошибки.
Для одного процесса допустимо автоматически принимать почти всё. Для другого даже единичное неправильное значение может стоить намного дороже всей экономии на ручной обработке.
Человеку должны попадать исключения, а не вся работа после ИИ
Из всего этого не следует, что каждый результат нужно вручную перепроверять.
Если после внедрения бухгалтер всё равно открывает каждый счёт и сверяет каждое распознанное поле с оригиналом, автоматизация получилась довольно странной.
Задача системы как раз в том, чтобы разделить поток.
Очевидные случаи проходят автоматически. Значения найдены в правильном месте, формальные проверки выполнены, данные согласуются со справочниками, противоречий нет.
Человеку уходят только исключения: поле отсутствует, два кандидата выглядят одинаково правдоподобно, проверка не прошла, документ слишком плохого качества или цена потенциальной ошибки слишком высока.
Тогда роль сотрудника меняется с ручного ввода данных на контроль сложных случаев.
Именно здесь обычно и появляется настоящая экономия.
Как принимать такой проект
Приёмка ИИ для документов не должна выглядеть как презентация из десяти удачных примеров.
Нужен контрольный набор, который команда разработки не сможет незаметно подстроить под систему. В нём должны быть как хорошие документы, так и отрицательные случаи, где нужной информации нет.
Для каждого результата желательно сохранять источник. Формально проверяемые поля нужно проверять обычным кодом. Отдельно следует считать ложные срабатывания — ситуации, когда система выдала значение, которого в документе не существовало.
И уже после этого можно определять порог автоматической обработки.
Например: если значение найдено, подтверждается источником, проходит формальную проверку и не конфликтует с другими данными — пропускаем автоматически. В остальных случаях создаём задачу сотруднику.
Такой процесс намного скучнее демонстрации, где модель за секунду разбирает сложный PDF.
Зато его можно безопасно подключать к реальной работе.
С чего начать
Если компания хочет автоматизировать счета, акты, договоры, отчётность или другие документы, я бы начинал не с вопроса «какая модель лучше всего распознаёт PDF».
Сначала нужно определить, какие именно поля требуются бизнесу и что произойдёт, если каждое из них будет распознано неправильно.
После этого собрать реальные документы и контрольные ответы. Причём обязательно включить случаи, где нужного значения нет.
Затем отдельно проверить поиск, извлечение и формальную валидацию. Понять, какие ошибки можно обнаружить автоматически и какие документы необходимо отдавать человеку.
И только после этого имеет смысл обсуждать процент автоматизации.
Потому что для бизнеса хороший ИИ — не тот, который всегда что-нибудь отвечает.
Хороший ИИ должен уметь вовремя ничего не придумать.
