Разработка системных сообщений (классическая модель)

В настоящее время просмотр:Версия портала Foundry (классическая версия) - Переключиться на версию для нового портала Foundry

Примечание

Содержание в новой документации Microsoft Foundry может открываться по ссылкам в этой статье вместо документации Foundry (классической версии), которую вы просматриваете сейчас.

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

Описание этой статьи

В этой статье основное внимание уделяется системному сообщению (иногда называемому системным запросом или метапроимптом) для взаимодействия на основе чата.

Если вам требуется более полное руководство по проектированию подсказок (несколько примеров, упорядочение и эффективность токенов), см. техники проектирования подсказок.

Необходимые условия

Чтобы использовать системные сообщения, необходимо получить доступ к ресурсу OpenAI Azure с развертыванием модели завершения чата. Инструкции по настройке см. в разделе Создание и развертывание ресурса Azure OpenAI.

Что такое системное сообщение?

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

  • Определите роль и границы помощника.
  • Задать тон и стиль общения.
  • Укажите форматы выходных данных (например, JSON).
  • Добавьте ограничения безопасности и качества для вашего сценария.

Системное сообщение может быть одним коротким предложением:

You are a helpful AI assistant.

Или это может быть несколько строк с структурированными правилами и требованиями к форматированию.

Важно

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

Как работают системные сообщения

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

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

Системные сообщения наиболее эффективны, если вы:

  • Удостоверьтесь, что указания выражены однозначно.
  • Избегайте конфликтующих правил.
  • Сделайте "поведение по умолчанию" явным (что предпринимает помощник, если он не имеет сведений или если запрос выходит за рамки).

Основные понятия

Роль и область

Определите, что такое помощник (роль) и что это и что не разрешено делать (область). Заявления о границах особенно важны для помощников, специализированных для определённых доменов.

Контракт на поставку

Если приложению нужны структурированные выходные данные, укажите выходной контракт (например, JSON с фиксированными ключами). Держите контракт небольшим и стабильным.

Ограничения безопасности

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

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

Примеры системных сообщений

В следующем примере показано системное сообщение и результирующий ответ модели.

Системное сообщение Пользователь Помощник
Вы помощник по искусственному интеллекту, который помогает людям находить информацию и реагировать на рифмы. Если пользователь задает вам вопрос, на который вы не знаете ответ, скажем так. Что вы можете сказать обо мне, Джон Доу? Дорогой Джон, с сожалением сообщаю,
Но у меня нет информации о вас сегодня.
Я просто ИИ с знаниями в моем мозгу,
Но без ваших входных данных, я не могу объяснить.
Так что расскажите мне больше о том, что вы ищете,
И я буду делать все возможное, чтобы дать вам уникальный ответ.

Ниже приведены несколько примеров, которые можно адаптировать.

Пример: помощник по технической поддержке с резервным вариантом

You are a technical support assistant for an internal product.
If you don't have enough information to answer, ask a clarifying question.
If you still can't answer, say you don't know.

Пример: извлечение структурированных сущностей

You extract entities from user text.
Return only JSON, using this schema:
{
   "name": "",
   "company": "",
   "phone_number": ""
}

Контрольный список дизайна

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

1. Начните с задания помощника

Укажите роль и ожидаемый результат для типичного запроса.

2. Определение границ

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

3. Укажите выходной формат

Если вам нужен определенный формат, укажите его четко и сохраните его согласованно.

4. Добавьте политику "в случае неуверенности"

Сообщите модели, что делать, когда:

  • Запрос пользователя неоднозначно.
  • Запрос выходит за рамки.
  • Модели недостаёт информации.

5. Тестирование, измерение и итерация

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

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

Распространенные ловушки

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

Ограничения

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

Дальнейшие действия