Сначала определите узкую роль модели
Полезно ясно разделить распознавание информации и решение о действии. Например, модель может извлекать из текста название товара, количество и желаемую дату. Но отсутствие даты не должно автоматически превращаться в придуманное значение, а распознанное количество ещё не означает наличие товара на складе. Для каждого поля стоит определить допустимый формат и способ проверки. Дата должна существовать, количество соответствовать разрешённому диапазону, а товар сопоставляться с реальным справочником. Уверенная формулировка модели не заменяет этих проверок: генеративные системы способны выдавать правдоподобные, но неверные сведения. Если данных недостаточно или они противоречат друг другу, процессу нужен отдельный исход для уточнения, а не обязательное продолжение любой ценой.
Изменение данных требует понятных условий
Следующий этап должен опираться на правила процесса. Нужно знать, какие действия допустимы автоматически, какие требуют проверки человеком и какие вообще не входят в полномочия системы. Например, подготовка внутреннего черновика и подтверждение обязательства клиенту имеют разные последствия. Нельзя считать, что разрешение прочитать заявку автоматически разрешает все возможные действия с ней. Полезная схема явно обозначает границу: данные извлечены, проверки пройдены, необходимые согласования получены, действие выполнено. Если один этап не завершён, следующий не должен появляться в журнале как успешный. Для оценки качества нужны примеры обычных заявок, пропусков, противоречий и неожиданных формулировок. Проверка только на нескольких удобных сообщениях мало говорит о поведении в реальной работе.
Повтор после сбоя может создать дубликат
Представим, что система создала заявку во внешнем сервисе, но ответ потерялся. Для отправителя исход пока неизвестен. Повторный запрос без проверки способен создать вторую заявку. Поэтому идентификатор операции и правила обработки повторов являются частью надёжности, а не второстепенной технической деталью. Некоторые интерфейсы поддерживают идемпотентность: повтор одной и той же операции с предусмотренным идентификатором обрабатывается без повторного эффекта. Это свойство нужно проверять в документации конкретного сервиса. Простое добавление произвольного номера к тексту не создаёт такой гарантии. Если исход неясен, сначала восстанавливают состояние по доступным подтверждениям. Журнал должен различать успешное выполнение, явную ошибку и неизвестный результат.
Попробуйте на практике
Проверьте бумажную схему обработки вымышленной заявки: нужны три синих блокнота, дату не указали. Затем представьте, что после создания внутренней записи ответ сервиса не пришёл.
- Выпишите известные поля и отдельно отметьте отсутствующую дату. Не заполняйте её предположением модели.
- Укажите проверки до действия: существование нужного товара, допустимое количество, обязательность даты и полномочия автоматизации.
- Нарисуйте отдельную ветку для потерянного подтверждения. Запишите, как проверить наличие уже созданной записи по идентификатору операции.
- Определите, какие случаи передаются человеку: противоречивые данные, отсутствие обязательного поля или невозможность установить исход. Не обозначайте их как успешное выполнение.
Как проверить результат. В схеме отсутствующая информация остаётся неизвестной, а потерянный ответ не приравнивается к отсутствию записи. Повторное выполнение допускается только с учётом состояния и правил конкретного сервиса.
Частые вопросы
Если модель почти всегда отвечает правильно, можно убрать проверки?
Частота ошибок важна вместе с их последствиями. Даже редкая ошибка может быть существенной, поэтому проверки определяются задачей и допустимым риском.
Идентификатор операции сам по себе предотвращает дубли?
Нет. Его должен учитывать принимающий сервис или надёжная логика обработки. Правила повторов и срок действия такой защиты нужно понимать явно.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.