В Nanonets OCR можно загрузить PDF, JPEG или PNG, распознать текст, поля и табличные строки, проверить найденные значения рядом с оригиналом документа, исправить рамки и подписи, а затем выгрузить результат в CSV, XML или XLSX либо передать его в рабочий процесс через API и готовые интеграции.

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

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

Как устроено рабочее пространство

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

После открытия модели навигация делится на несколько смысловых зон. В Overview собраны сводные показатели, в Workflow Setup настраивается последовательность импорта, распознавания, преобразования, согласования и экспорта, в Extract Data лежат загруженные файлы и результаты, а в AI Training находятся метки, учебные документы и сеансы обучения. В Settings задаются режим обработки страниц, допустимые форматы и другие параметры модели. Меню Account Info отвечает за ключи API, команду, уведомления и административные настройки.

Экран Overview можно настроить под задачи отдела. Карточки показывают общее число файлов, количество одобренных и ожидающих проверки документов, неудачные и успешные экспорты, а также другие выборки, собранные по фильтрам. Нажатие на карточку переводит к соответствующим файлам в Extract Data. Это удобнее, чем каждый раз вручную задавать одинаковый набор условий, особенно когда руководителю нужен быстрый ответ, сколько счетов за период задержалось на проверке или не дошло до учётной системы.

При создании собственной сводной карточки задаётся понятное имя и набор условий. Например, карточка Failed Exports строится по параметру Export Status со значением Errored. Можно добавлять несколько фильтров, чтобы отделить ошибки конкретного направления, поставщика или периода. Ограничение панели важно учитывать при проектировании: сводки лучше посвящать решениям, которые требуют действия, а не дублировать каждую возможную комбинацию фильтров.

Выбор подходящего способа извлечения

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

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

Instant Learning полезен, когда документы поступают постоянно, а качество предполагается повышать через исправления операторов. После проверки и одобрения корректного файла модель получает обратную связь. Zero-shot или модель без начального набора примеров подходит для быстрого запуска, если названия и описания полей сформулированы однозначно. Чем абстрактнее подпись вроде код или номер, тем выше риск, что система выберет не тот фрагмент. Лучше указывать деловой смысл: номер счёта поставщика, дата оказания услуги, итог после налогов.

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

Загрузка документов и автоматический импорт

Ручная загрузка выполняется из Extract Data. Файл можно перетащить в область импорта или выбрать на устройстве. Для готовых моделей в документации отдельно указаны PDF, PNG и JPEG; общие настройки рабочих процессов также позволяют принимать TIFF, CSV, XLS, XLSX, TXT и DOCX. Однако доступность формата зависит от типа модели и включённых параметров, поэтому перед массовой передачей стоит проверить один файл каждого вида. Если таблица XLSX нужна как справочник для сопоставления, её не следует путать с изображением документа, которое требуется распознать.

Окно импорта одновременно показывает ручную загрузку и автоматические каналы. Среди типовых вариантов есть электронная почта, API, Dropbox, Google Drive, Zapier и Amazon S3. Конкретный набор блоков зависит от рабочего процесса и доступных интеграций. При настройке важно не просто авторизовать подключение, но и проверить, какие новые файлы он подхватывает, как часто обращается к папке, что делает с вложениями неподдерживаемого типа и как ведёт журнал ошибок.

Подготовка сканов перед отправкой

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

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

Импорт по электронной почте

Почтовый канал удобен для поставщиков и подразделений, которым не нужно давать доступ к рабочему пространству. После настройки выделенный адрес принимает вложения и отправляет их в модель. Журнал Email Run History показывает время получения, тему, имя вложения, принятие или отклонение, этап обработки и итоговый статус. Если документ не появился в очереди, сначала проверяют именно этот журнал: неподдерживаемое расширение, пустое письмо или ошибка обработки заметны там быстрее, чем при поиске файла в общем списке.

Импорт из облачной папки

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

Поля, подписи и структура результата

Настройка начинается в Manage Labels. Здесь создаются поля и заголовки таблиц, добавляются описания и при необходимости форматирование. Имя поля становится частью структуры выгрузки и ответа API, поэтому его лучше задавать заранее и придерживаться одного стиля. Для интеграции удобны короткие машинные имена без пробелов: invoice_number, vendor_name, total_amount. В описании, напротив, полезно писать обычным языком, что именно искать и чем значение отличается от похожих реквизитов.

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

Для zero-shot и instant learning особенно важны описания. Хорошее описание отвечает на три вопроса: где обычно находится значение, как оно выглядит и что не следует принимать за него. Например: Номер счёта, присвоенный поставщиком; обычно расположен в верхней части рядом с Invoice No.; не использовать номер заказа. Такая формулировка помогает отделить похожие последовательности цифр. Для даты стоит уточнить её назначение, а для суммы — указать, включает ли она налог и доставку.

Как размечать значение

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

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

Проверка распознанных значений

В раскрытом документе слева отображаются миниатюры страниц, в центре — оригинал, справа — Final Results, Raw OCR или JSON. Final Results предназначен для рабочей проверки: поля перечислены в структурированном виде, рядом видны статусы и возможные предупреждения. Raw OCR помогает понять, смог ли движок вообще прочитать нужную строку. JSON показывает технический результат с координатами, типами и служебными данными, что особенно полезно разработчику интеграции.

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

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

Final Results, Raw OCR и JSON

• Final Results — рабочая форма для просмотра и корректировки полей и таблиц.
• Raw OCR — полный распознанный текст, полезный при диагностике пропусков и странных символов.
• JSON — структурированный ответ для интеграции, проверки координат, типов элементов и статусов.

Если Final Results пуст, а в Raw OCR нужная строка присутствует, проблема чаще связана с определением поля, описанием или обучением. Если строки нет и в Raw OCR, причина обычно в качестве изображения, языке, мелком шрифте, повороте или сложном фоне. Это различие помогает не тратить время на переобучение, когда сначала нужно улучшить скан.

Меню файла содержит повторный запуск действий, историю, загрузку результата, добавление в AI Training и настройку итогового вида. Повторный запуск полезен после изменения форматирования или справочника, а добавление в обучение — после внимательной проверки документа. Нельзя считать одобрение простой кнопкой закрыть: оно влияет на последующие этапы и может стать учебным сигналом.

Извлечение таблиц и строковых позиций

Таблица в Nanonets — не просто блок текста. Система должна определить область, строки, столбцы и связь ячеек с заголовками. Для счёта это обычно описание позиции, количество, цена, налог и сумма; для банковской выписки — дата, описание операции, дебет, кредит и остаток. Даже при хорошем OCR табличная структура может нарушиться из-за объединённых ячеек, многострочных описаний, отсутствующих границ или переноса продолжения на следующую страницу.

При ручной разметке сначала обводят область таблицы и переключают выделение в табличный режим. Сетку можно показать кнопкой Show Grids, затем добавить или передвинуть разделители строк и колонок. После команды Extract data as table для ячеек создаются рамки. Ненужную часть значения можно исключить изменением размера рамки, а текст — поправить в правой панели. Важно помнить, что отредактированный текст не заставляет рамку автоматически подстроиться под новое содержимое.

Заголовок столбца задаётся отдельно от надписи в документе. Это позволяет преобразовать Код товара в item_id, Кол-во в quantity, а Стоимость с НДС в gross_amount. После назначения заголовка всем ячейкам под ним в выгрузке соответствует одна колонка. Если один и тот же смысл на разных формах подписан по-разному, единое имя упрощает экспорт и аналитику.

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

Практическая проверка таблицы

1. Сравните число строк в результате с числом реальных позиций.
2. Проверьте, не объединились ли описание и артикул в одну колонку.
3. Убедитесь, что итоговая строка не попала в перечень позиций.
4. Проверьте десятичные разделители, знаки минуса и обозначения валют.
5. Сверьте сумму строк с итогом, если такой контроль предусмотрен процессом.

Клавиатурная навигация ускоряет исправление: стрелки переходят между ячейками, Enter включает редактирование, Tab перемещает к следующей ячейке, Delete очищает содержимое. Можно вставлять значение в несколько выбранных ячеек, но копирование множества ячеек ограничено: при групповом выборе берётся только верхняя. Поэтому массовые изменения лучше выполнять через действия с данными, а не пытаться превратить панель проверки в полноценную электронную таблицу.

Обучение и улучшение модели

В AI Training отделены управление метками, учебные файлы и сеанс обучения. Раздел Training Files показывает статус проверки, число отмеченных меток, участие файла в обучении, дату загрузки и назначенного сотрудника. Такой контроль важен, потому что одобренный рабочий результат ещё не обязательно подходит как эталон. Для обучения следует выбирать документы, где все рамки и значения проверены особенно тщательно.

Файл можно открыть и подтвердить кнопкой Verify file. Для пачки документов доступны групповые действия: назначение сотруднику, изменение статуса, проверка или снятие проверки, удаление. Массовая проверка экономит время только после выборочного контроля качества. Если оператор подтвердил десять файлов с одной и той же ошибкой в метке, модель получит устойчивый неправильный сигнал.

Автоматическое и ручное добавление в обучение

Автоматическое добавление одобренных файлов удобно в зрелом процессе, где ручная проверка стандартизирована и ошибки редки. На этапе запуска безопаснее выбирать документы вручную через Add to AI Training. Это отделяет обычное исправление результата от формирования эталонной выборки. После изменения модели старые файлы можно повторно обработать, чтобы проверить, улучшилось ли извлечение на реальных примерах, а не только на учебном наборе.

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

Почему качество может ухудшиться

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

Если instant learning начинает давать пустые значения, сначала уточняют имя и описание поля, затем проверяют, что одобрены документы с правильными результатами. Если значение берётся не из того места, смотрят рамку и корректируют её. Если уверенность падает после появления новых поставщиков, добавляют проверенные примеры именно этих форм, а не повторяют старые документы.

Настройка последовательности обработки

Workflow Setup представляет процесс как цепочку блоков: Import, AI Model, Data Actions, Final Results, Approvals и Export. У каждого блока своя задача, поэтому ошибки проще локализовать. Если файл не появился, проверяют импорт; если поле извлечено неверно — модель и разметку; если дата имеет неправильный формат — действие; если документ завис у сотрудника — согласование; если данные не дошли до ERP — экспорт и историю запуска.

В блоке импорта добавляются почта, облачное хранилище, API и другие каналы. В AI Model выбирается используемый извлекатель и открывается просмотр схемы данных. Data Actions модифицируют результат: форматируют текст и даты, выполняют условия, обращаются к справочникам, добавляют вычисляемые поля или запускают пользовательский код. Final Results определяет, какие поля считаются итоговыми и будут доступны следующему этапу.

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

Final Results как контракт данных

В Final Results включаются только поля, которые должны уйти дальше. Это помогает скрыть служебные значения, промежуточные вычисления и дубли. Для каждого итогового поля видно, какие действия к нему применены. Например, invoice_date может проходить через распознавание и преобразование в единый формат, а total_amount — через очистку символов и числовую проверку. Если поле не нужно получателю, его лучше выключить здесь, а не удалять из модели, где оно может быть полезно для правил.

Форматирование и обогащение данных

Распознанное значение редко пригодно для прямой записи в учётную систему. Дата может быть записана как 7/3/24, 03-07-2024 или 7 марта 2024, сумма — содержать пробелы, запятые и знак валюты, а имя поставщика — отличаться регистром или юридическим суффиксом. Data Actions позволяют привести результат к ожидаемой форме до проверки и экспорта.

Условный блок запускает действие только при выполнении правила. Например, если поле не пустое, дата преобразуется к формату YYYY-MM-DD; если валюта отсутствует, она определяется по символу в сумме; если страна равна определённому значению, применяется местный формат номера. Результат можно записать поверх исходного поля или создать новое. Второй вариант безопаснее на этапе отладки: оператор видит исходное и преобразованное значение и может понять, где возникла ошибка.

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

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

Как тестировать действие

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

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

Правила проверки и согласование

Approval Stage объединяет условия, по которым файл требует внимания. Внутри этапа можно задать обязательную проверку всех документов либо назначать сотрудника только для файлов с флагами. Во втором режиме беспроблемные документы проходят дальше без ручного вмешательства, а исключения попадают в очередь. Это основной механизм, который превращает OCR из разовой операции в управляемый бизнес-процесс.

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

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

Кнопка Add a review stage добавляет новый блок, а уведомления предупреждают участников о назначенных документах. При проектировании не следует превращать процесс в цепочку обязательных подтверждений каждого файла. Цель правил — отделить рискованные случаи. Если все документы всегда проходят через трёх людей, автоматизация только переносит ручную работу в другой интерфейс.

Полезные сценарии флагов

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

Экспорт результатов

Для разовой работы результаты можно скачать из Extract Data. Перед выгрузкой выбираются файлы и при необходимости фильтруется период или статус. Поддерживаются CSV, XML и XLSX. Такой способ подходит для анализа, проверки пилотной выборки или передачи данных в систему, которая ещё не подключена напрямую. При таблицах следует проверить, как строки представлены в выбранном формате: отдельные листы, повторяющиеся строки или вложенная структура могут по-разному восприниматься целевым приложением.

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

Для FTP указываются хост, порт, имя пользователя и пароль, при необходимости включается TLS. Затем выбирается CSV, отдельный CSV для каждого файла, XML, Excel или исходный документ. Имя экспортируемого файла можно собирать из распознанных значений, например номера счёта и даты. Это удобно, но требует очистки запрещённых символов и обработки пустых полей, иначе файл может получить некорректное имя.

Триггер экспорта определяет момент отправки. On Inference запускает передачу сразу после распознавания; On All Validations Passing — после успешного прохождения проверок; On Approval — после ручного одобрения. Для финансовых данных безопаснее не отправлять результат до проверки критичных условий. Для индексации хранилища, где ошибка не создаёт проводку, допустим более ранний экспорт.

Вебхуки и API

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

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

Работа через API

API используется для загрузки файлов, запуска распознавания, получения результатов, работы с учебными данными и моделями. Базовые ответы возвращаются в JSON. Для аутентификации применяется ключ API: он передаётся как имя пользователя в Basic Authentication, а пароль остаётся пустым. Ключ нельзя помещать в клиентский JavaScript, мобильное приложение или публичный репозиторий; запросы должны идти через защищённый сервер организации.

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

Синхронная и асинхронная обработка

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

Документация рекомендует асинхронный подход для многостраничных и тяжёлых файлов. В интерфейсе модели также есть переключатель Sync и Async. Настройка не должна выбираться только по среднему размеру: один редкий PDF на сотню страниц способен создать тайм-аут в процессе, рассчитанном на трёхстраничные счета.

Ошибка 429 и управление нагрузкой

Ответ 429 означает достижение ограничения частоты. Правильная реакция — не запускать бесконечные мгновенные повторы. Клиент должен уменьшить параллелизм, поставить файл в очередь и применить увеличивающуюся задержку с небольшим случайным разбросом. Для больших документов полезно перейти на асинхронные вызовы. Логи должны сохранять код ответа, модель, размер файла и число попыток, иначе причина периодических провалов останется неясной.

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

Проверка ответа

Не следует считать HTTP-успех доказательством качества данных. После получения JSON проверяют наличие обязательных полей, типы, диапазоны сумм, номер страницы, координаты и статусы валидации. Пустое значение может быть допустимо для необязательного поля, но критично для номера счёта. Такой контроль остаётся обязанностью интеграции даже при высокой точности распознавания.

Многостраничные документы и параметры модели

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

Запись 1:2 означает первые две страницы, перечень 3,6,7 — только указанные, отрицательные номера отсчитываются от конца. Настройку следует проверить на копии документа, потому что ошибка в диапазоне выглядит как сбой OCR: система честно не обрабатывает страницу, которой нет в выборе. При изменении структуры входящего пакета старое правило может начать пропускать данные.

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

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

Модельные уровни и ограничения

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

Командная работа и контроль изменений

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

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

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

API-ключи создаются в Account Info → API Keys. Для разных интеграций лучше использовать отдельные ключи, если управление доступом это позволяет. Тогда компрометация одного подключения не требует менять все системы сразу. Ключи следует ротировать, а удаление старого выполнять только после проверки нового в тестовом запросе.

В интерфейсе нет пользы от десятков одинаково названных моделей. Описание процесса должно указывать назначение, подразделение и среду: например, AP invoices — production и AP invoices — test. Идентификатор модели хранится в конфигурации интеграции, а не копируется вручную из случайной строки при каждом запуске.

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

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

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

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

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

Языки, качество изображения и сложные макеты

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

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

Что ухудшает результат

• низкое разрешение и сильное JPEG-сжатие;
• размытое фото, тень или блик на строках;
• наклон и перспективное искажение;
• печать поверх текста или рукописные исправления;
• мелкие таблицы с плотной сеткой;
• фоновые узоры, водяные знаки и слабый контраст;
• несколько документов на одной фотографии;
• смешение разных типов документов без маршрутизации.

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

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

Практический процесс обработки счетов

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

1. Создайте готовую или собственную модель и загрузите выборку разных поставщиков.
2. Определите поля и единые машинные имена.
3. Проверьте строки таблицы, итог и налог на нескольких типах макета.
4. Нормализуйте дату, валюту и число.
5. Сопоставьте поставщика со справочником.
6. Добавьте проверки дубликата, пустого номера и суммы выше лимита.
7. Назначьте очередь исключений и экспорт после успешного согласования.

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

Сопоставление строк с заказом на покупку требует нормализации артикулов, единиц измерения и количества. Если в счёте указана коробка, а в заказе — штуки, простое сравнение чисел даст ошибку. Nanonets может извлечь данные и применить правила, но бизнес-логику пересчёта организация должна определить сама.

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

Банковские выписки и финансовые таблицы

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

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

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

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

Чеки, заказы, накладные и формы

Чеки

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

Заказы на покупку

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

Транспортные документы

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

Анкеты и заявления

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

Ошибки и способы устранения

Файл не загружается

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

Файл загружен, но долго обрабатывается

Для большого многостраничного PDF включите асинхронную обработку и проверьте очередь. Убедитесь, что не отправляете один и тот же файл повторно из нескольких каналов. При API-загрузке уменьшите параллелизм и обработайте 429 с задержкой. Если задержка появилась после добавления сложного действия или внешнего справочника, посмотрите историю запуска каждого блока.

Поле остаётся пустым

Сравните Final Results и Raw OCR. Если текст не распознан, улучшите изображение или проверьте язык. Если текст есть, уточните имя и описание поля, добавьте примеры и убедитесь, что искомое значение не является повторяющейся таблицей. Для instant learning одобрите несколько корректно исправленных файлов.

Извлекается соседнее значение

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

Столбцы таблицы смешались

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

Экспорт не сработал

Откройте Workflow Run History и определите блок с ошибкой. Для облачного приложения обновите авторизацию, для FTP проверьте хост, порт, учётные данные и TLS, для API — ответ получателя. После исправления используйте Retry Export, а не загружайте документ заново без необходимости. Повторная загрузка может создать вторую запись и повторно запустить все действия.

Изменение поля ломает процесс

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

После изменения правила старые документы не обновились

Рабочие процессы обычно не пересчитывают исторические файлы автоматически. Запустите Re-run Actions или Retry Upload в зависимости от того, изменилось ли действие, справочник или модель. Делайте это на небольшой выборке, чтобы не повторить экспорт и не создать дубликаты во внешней системе.

Классификация документов и маршрутизация

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

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

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

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

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

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

Контроль качества на реальной выборке

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

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

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

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

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

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

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

Обслуживание модели и рабочего процесса

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

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

Изменения выполняют по одному логическому набору. Сначала корректируют описание поля или добавляют примеры, затем запускают обучение и тестируют контрольную выборку. Одновременная замена меток, таблицы, форматирования и экспорта не позволяет понять причину улучшения или ухудшения. Для каждого изменения полезно записывать цель, дату, ответственное лицо и результаты до и после.

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

Интеграции проверяют отдельно от модели. Регулярный тест должен подтверждать, что ключ API действует, вебхук принимает событие, FTP-сервер доступен, а поле назначения всё ещё существует. Хорошо распознанный документ не компенсирует истёкшую авторизацию. Для критичных каналов настраивают уведомление о серии ошибок и ограниченный повтор с защитой от дубликатов.

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

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

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

Ограничения, которые важно учитывать

Nanonets OCR предназначен для извлечения и маршрутизации данных, а не для редактирования содержимого PDF как документа. Здесь нет задачи перемещать абзацы, менять шрифт, собирать страницы, рисовать аннотации или готовить печатную форму. Когда пользователю нужно исправить сам PDF, объединить файлы, удалить страницы или отредактировать текст, потребуется специализированный PDF-редактор.

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

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

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

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

Сравнение Nanonets OCR с аналогами

Программа	Лучше подходит для	Главное ограничение
Nanonets OCR	Настраиваемого извлечения полей, таблиц, проверок и интеграций в одном процессе	Сложные формы требуют контроля и настройки схемы
PDF Commander	Редактирования, объединения, преобразования и повседневной работы с отдельными PDF	Не заменяет промышленный поток извлечения данных и согласований
ABBYY Vantage	Корпоративного IDP с готовыми и настраиваемыми навыками для разных классов документов	Внедрение и настройка рассчитаны на корпоративный процесс
Rossum	Транзакционных документов, особенно счетов, с валидацией и обработкой исключений	Фокус уже, чем у универсального PDF-редактора или облачного OCR API
Google Cloud Document AI	Разработки масштабируемых приложений на инфраструктуре Google Cloud	Для законченного рабочего места оператора требуется дополнительная сборка решения
Amazon Textract	API-анализа текста, форм, таблиц, запросов и подписей в приложениях AWS	Готовый процесс согласования и интерфейс оператора нужно строить вокруг API

Для сотрудника, которому нужно изменить сам PDF, быстрее выбрать PDF Commander. Для отдела, который получает поток счетов и хочет настроить поля, ручную проверку, правила и экспорт без разработки всего интерфейса с нуля, ближе Nanonets OCR или Rossum. ABBYY Vantage уместен в крупном IDP-проекте с корпоративными требованиями и набором навыков. Google Document AI и Amazon Textract удобнее командам разработки, которые уже строят приложение в соответствующем облаке и готовы самостоятельно реализовать очередь, проверку, роли и интеграции.

Рекомендованный порядок запуска

1. Опишите итог. Зафиксируйте поля, таблицы, формат и систему-получателя.
2. Соберите выборку. Возьмите разные реальные шаблоны, а не копии одного документа.
3. Начните с малого. Проверьте готовый извлекатель или несколько ясно описанных полей.
4. Измерьте ошибки. Разделите проблемы OCR, определения поля, таблицы и бизнес-правил.
5. Настройте исключения. Добавьте флаги для пустых и рискованных значений.
6. Протестируйте экспорт. Проверьте повторную отправку, дубликаты и сбой авторизации.
7. Обучите операторов. Договоритесь, как исправлять рамки, значения и учебные файлы.
8. Запустите ограниченный поток. Сравнивайте результат с ручной обработкой.
9. Расширяйте по одному изменению. Добавляйте поля, действия и каналы после проверки.
10. Следите за метриками. Контролируйте очередь, ошибки, страницы и время до экспорта.

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

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

Ответы на практические вопросы

Можно ли получить только обычный текст из PDF?

Да, OCR умеет извлекать текст, а отдельный инструмент преобразует PDF или изображение в текст. Однако основной рабочий процесс Nanonets ценен именно структурой: поля, таблицы, проверки и экспорт. Для простого разового копирования текста сложная модель может быть избыточна.

Нужно ли обучать модель для каждого счёта?

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

Можно ли исправить неправильный результат вручную?

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

Как выгрузить таблицу в Excel?

Выберите нужные файлы в Extract Data и скачайте XLSX либо настройте автоматический экспорт в MS Excel через соответствующий блок. Перед передачей проверьте представление строк и заголовков, особенно при нескольких таблицах и многостраничном документе.

Как не отправить ошибочный счёт в ERP?

Добавьте правила для критичных полей, этап согласования и экспорт по триггеру успешных проверок или ручного одобрения. Не используйте On Inference для операции, которая создаёт финансовую запись без дополнительного контроля.

Что делать с новым шаблоном поставщика?

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

Можно ли повторно отправить результат после сбоя?

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

Как проверить расход обработки?

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

Подходит ли система для редактирования сканированного PDF?

Она извлекает текст и данные, но не предназначена для изменения верстки и содержимого PDF. Для редактирования текста, страниц, изображений и аннотаций нужен PDF-редактор.

Можно ли полностью убрать ручную проверку?

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

Итоговый рабочий подход

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

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

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

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