Document AI после OCR: как довести поля до доверия

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

Поэтому Document AI проектируем как конвейер: intake, OCR, extraction, validation, review и export. Если какого-то слоя нет, он всё равно появится. Только уже в виде ручной боли оператора.

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

Для пилота обычно хватает 20-50 документов разных типов и качества. Результат должен быть не только в JSON или Excel, но и в интерфейсе проверки: поле, значение, confidence, исходный фрагмент, ошибка правила и кнопка подтверждения.

Так быстро видно, где система уже экономит время, а где нужен другой OCR, дообучение, нормализация справочников или изменение шаблонов документов. Да, иногда проблема не в AI. Такое тоже бывает.

В Document AI доверие появляется не от высокого confidence на карточке, а от возможности проверить источник. Если система извлекла сумму, дату, ИНН, артикул или номер договора, оператор должен видеть фрагмент документа, страницу и правило, по которому поле принято или отправлено на проверку.

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

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

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

Golden set - это небольшой набор документов с ручной разметкой правильных полей. Он нужен, чтобы сравнивать версии OCR, промптов, extraction-модели и правил. Без golden set команда будет спорить по ощущениям: «вроде стало лучше» против «кажется, стало хуже».

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

В 1C, ERP, CRM или Excel должен уходить не «текст, который сказала модель», а структурированное решение: тип документа, поля, статус, причины review, ссылка на исходник, версия правила и кто подтвердил результат. Это позволяет аудитору или бухгалтеру восстановить путь документа.

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

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

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