В КУРСЕ?

Разбираемся в теме

Модель разобрала заявку: почему это ещё не означает, что задача создана?

В бизнесе языковую модель удобно использовать для разбора свободного текста: обращения клиента, заявки или заметки сотрудника. Однако осмысленный ответ модели и изменение в рабочей системе — разные этапы. Рассмотрим простой процесс создания задачи через API OpenAI, без подключения реальных сервисов и передачи клиентских данных.

Сначала определите, какой результат нужен приложению

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

Правильная структура не гарантирует правильного содержания

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

Функция приложения выполняет действие отдельно

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

Попробуйте на практике

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

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

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

Частые вопросы

Достаточно ли попросить модель всегда возвращать правильный формат?

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

Можно ли сразу дать модели все доступные функции бизнеса?

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

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

Зарегистрируйтесь, чтобы уточнить возможность доступа к этому материалу

Зарегистрироваться
← К списку материалов