Извлечение полей не равно принятию решения
ИИ может превратить входящий документ в черновик карточки: определить тип, найти номер, дату, стороны и перечень позиций. Но аккуратный JSON ещё не означает, что сведения верны и документ можно исполнять. Полезная граница автоматизации проходит между подготовкой данных и подтверждением действия. Владелец процесса должен заранее определить, какие поля требуют обязательной проверки человеком.
Для начала выберите один класс документов и одно конечное действие, например подготовку карточки для внутреннего учёта. Не объединяйте распознавание, согласование договора и оплату в один непрозрачный шаг. Здесь рассматривается помощник для ввода и проверки: он не подписывает документы, не меняет реквизиты в доверенном справочнике и не запускает автоматические платежи.
Приём файла и происхождение результата
На входе проверяйте право загрузки, допустимые форматы и размер. Не доверяйте одному расширению или присланному Content-Type. OWASP File Upload Cheat Sheet рекомендует сочетать проверки и ограничивать доступ к хранилищу. Обработчик документов должен работать изолированно, а файл не должен становиться публичным только потому, что его загрузили для распознавания.
Присвойте документу внутренний идентификатор и сохраните связь с исходной версией. Для каждого извлечённого поля полезны страница, фрагмент подтверждения и способ получения: текстовый слой, OCR или ручное исправление. Если оператор открывает другую версию файла, прежнее подтверждение больше нельзя считать проверкой текущих данных. Это особенно важно для повторно присланных документов.
Схема задаёт форму, но не истинность
Опишите контракт результата: разрешённые поля, типы, обязательность, перечни допустимых значений и представление отсутствующих сведений. В документации JSON Schema для объектов отдельно определены properties, required и additionalProperties. Само перечисление поля в properties не делает его обязательным, а отсутствие поля не тождественно значению null. Эти различия должны совпадать с ожиданиями принимающей системы.
Проверяйте схему на сервере независимо от ответа модели. Неизвестные поля отправляйте в ошибку или обрабатывайте по явно заданному правилу. Не позволяйте модели добавлять управляющий признак «одобрено» только потому, что он встретился в документе. Служебный статус назначает приложение после предусмотренных проверок, а не извлечённый текст.
Следующий слой проверяет смысл: согласованность дат, наличие обязательных разделов, совпадение позиций и итогов по правилам процесса. Пример для учебного набора: документ содержит разные номера в шапке и приложении. Правильный результат такого испытания может быть «нужно уточнение», а не уверенный выбор одного значения. Отсутствующие сведения нельзя дописывать по аналогии с прошлым файлом.
Ручная проверка должна помогать замечать ошибки
Показывайте оператору исходный фрагмент рядом с полем и выделяйте противоречия. Разделите состояния «извлечено», «требует уточнения», «проверено» и «отклонено». Кнопка подтверждения должна относиться к конкретной версии карточки. После изменения важного поля повторно запросите проверку соответствующей части, сохранив историю прежнего решения.
Не используйте самоназванную уверенность модели как единственное основание пропустить человека. Обязательная проверка может зависеть от типа поля, нового шаблона документа или найденного противоречия. Для рискованных изменений предусмотрите отдельного уполномоченного сотрудника. У него должна быть возможность отклонить черновик и запросить новый исходник без борьбы с автоматически проставленным одобрением.
Измеряйте качество по полям и типам ошибок: пропуск, неверное значение, выдуманное дополнение, неправильная связь с источником. Сохраняйте причины ручных исправлений. Средняя точность не показывает, где процесс опасно ошибается. Сначала согласуйте допустимые ошибки для конкретной задачи, затем проверяйте систему на отдельном размеченном наборе, который не использовали для настройки.
Поддельные инструкции внутри документа
Входящий файл может содержать фразу, предлагающую игнорировать правила, сменить получателя или отправить данные наружу. Это содержимое документа, а не полномочия владельца системы. OWASP описывает косвенные prompt injection через внешние материалы. Отделение данных от инструкций полезно, но один запрет в промпте не обеспечивает полной защиты.
Ограничьте возможности обработчика технически: ему не нужны платёжные инструменты, произвольные сетевые запросы или право менять справочники. Выход модели считайте недоверенными данными, проверяйте перед сохранением и безопасно отображайте. Инструкция из файла не должна создавать новый этап согласования, разрешать экспорт или отключать ручную проверку. Такие решения остаются в серверной логике.
Чек-лист испытаний и критерии приёмки
- Подготовьте обычные и сложные документы: плохой скан, поворот страницы, отсутствующее поле, противоречивые значения и повторную загрузку. Для каждого заранее задайте ожидаемый результат.
- Проверьте отклонение некорректного JSON, неизвестных полей и недопустимых типов. Ошибка модели не должна превращаться в частично подтверждённую карточку.
- Добавьте тестовый документ с посторонней инструкцией. Убедитесь, что она не расширяет доступ, не вызывает внешнее действие и не меняет правила согласования.
- Испытайте ручное исправление, отклонение, повторную обработку и отзыв доступа. Проверьте, кто видит исходник, результат и журнал изменений.
- Подтвердите отсутствие автоматических платежей и иных несогласованных действий. При недоступности модели документ должен остаться в понятной очереди, а не получить выдуманный результат.
Приёмка требует прослеживаемости каждого важного поля, воспроизводимых проверок и понятной очереди исключений. Задайте владельца очереди, сроки разбора и порядок обработки новых шаблонов. Связанный пример обозначен как концепция приёма документов с ИИ, а не история подтверждённого внедрения. Вопросы полномочий дополняет статья о контроле доступа и качестве RAG. Границы действий фиксируются при проектировании ИИ-автоматизации.
Короткий FAQ
Можно ли доверять результату, прошедшему JSON Schema?
Схема подтверждает структуру. Правдивость значений проверяется отдельно по документу и правилам процесса.
Нужно ли проверять каждое поле вручную?
Глубину контроля определяет риск. Для критичных полей и новых сценариев обязательная проверка задаётся заранее.
Почему не дать модели сразу оплатить документ?
Распознавание не является полномочием на платёж. В описанном процессе таких инструментов у модели нет.