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