Первый пилот по извлечению данных стоит ограничить одним типом документа и одной рабочей операцией. Например, проверить перенос согласованных полей из сертификатов в подготовленную таблицу, а не пытаться сразу автоматизировать весь документооборот.
Такой подход позволяет отдельно оценить качество извлечения, объём ручной проверки и требования к дальнейшей интеграции. Ниже — порядок подготовки пилота, который предлагаем использовать при обсуждении задачи.
Определите границы операции
Начните с текущего процесса: кто получает документ, где ищет значения, куда их переносит и кто отвечает за проверку.
Для первого типа документов важны регулярность обработки, понятный состав данных и наличие специалиста, который сможет подтвердить результат. Если под одним названием скрываются существенно разные формы, границу пилота нужно уточнить: какие варианты входят в проверку, а какие пока остаются за её пределами.
Постановка может выглядеть так: «Извлечь из выбранного типа сертификатов согласованный набор полей и передать результат на проверку специалисту». Это конкретнее, чем «научить ИИ читать документы», и не предполагает автоматическую запись непроверенных данных в рабочую систему.
Согласуйте поля и правила проверки
Для каждого поля определите ожидаемое значение и допустимый формат. Например, для даты нужно согласовать формат записи, а для номера документа — правила сохранения букв, разделителей и ведущих нулей, если они значимы для процесса.
Отдельно опишите ситуации, когда значение отсутствует, не читается или встречается в документе несколько раз. В таких случаях нужен понятный статус для проверяющего, а не правдоподобная догадка.
Критичность полей также следует определить заранее. Ошибка в идентификаторе партии может иметь иное значение для процесса, чем ошибка в необязательном примечании. Поэтому одной средней оценки качества недостаточно.
Сформируйте реалистичную выборку
Основу выборки должны составлять документы из реального рабочего потока, разрешённые к обработке. При отборе проверьте, представлены ли встречающиеся шаблоны, источники файлов, варианты качества сканов и случаи с неполными данными.
Не ограничивайтесь самыми удобными примерами. При этом редкие сложные случаи полезно учитывать отдельно: их наличие важно для проверки границ решения, но их доля в тесте может отличаться от доли в обычной работе. Это различие нужно учитывать при интерпретации результата.
Фиксированное число файлов без знакомства с документами назначать преждевременно. Размер выборки зависит от её разнообразия, числа проверяемых полей и требований к пилоту. Выводы должны оставаться в пределах тех вариантов, которые действительно были проверены.
Подготовьте эталонные ответы
Проверяющий специалист подтверждает значения в документах и отмечает исключения: отсутствующие поля, нечитаемые фрагменты и неоднозначные данные. Так появляется основа для оценки, с которой можно сопоставить результат извлечения.
Документы для настройки и итоговой проверки следует разделить. Контрольную часть не стоит использовать для постоянной доработки решения: иначе она перестаёт быть независимой проверкой.
Если специалисты по-разному трактуют поле, сначала необходимо согласовать правило. Без этого оценка будет смешивать ошибки извлечения и разногласия в самом процессе.
Зафиксируйте критерии до проверки
Для первого пилота рекомендуем оценивать:
— точность по каждому согласованному полю; — долю документов, требующих ручного разбора; — причины исключений и исправлений; — время проверки и доведения результата до рабочего состояния.
Сравнение с текущим процессом нужно проводить на сопоставимых документах и при одинаковых требованиях к готовому результату. Нельзя сравнивать время автоматического извлечения со временем полного ручного цикла, исключив последующую проверку и исправления.
Порог приемлемого качества определяет владелец процесса совместно с проверяющим специалистом. Его следует согласовать до итогового теста, а не выбирать после получения удобных цифр.
Отделите извлечение от интеграции
Успешное извлечение полей ещё не подтверждает готовность к записи данных в 1С, ERP или другую систему. До оценки интеграции нужны сведения о системе-источнике и системе-получателе, доступных API или выгрузках, правах доступа и требованиях к размещению и безопасности.
Результат первого пилота — основание для решения о следующем шаге. Он должен показать, какие документы обрабатываются, какие поля требуют контроля, где проходит граница автоматизации и полезен ли подход в выбранной операции. Это проверка гипотезы, а не обещание заранее заданной экономии.
Напишите «ЗАВОД» — разберём одну повторяющуюся операцию.