Сообщения системы безопасности

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

Примечание

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

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

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

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

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

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

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

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

Ключевые компоненты системного сообщения

Большинство системных сообщений объединяют несколько компонентов:

  • Роль и задача: что такое помощник и за что он отвечает.
  • Аудитория и тон: Для кого предназначен ответ и ожидаемый стиль.
  • Область и границы: что помощник не должен делать, и что делать, когда он не может соответствовать.
  • Рекомендации по безопасности: правила, которые снижают вредные выходные данные (например, обрабатывая конфиденциальные темы, защищенные характеристики и незаконные инструкции).
  • Инструменты и данные (необязательно): какие средства или источники можно использовать модель и как их использовать.

Как безопасно проектировать и проводить итерации

При проектировании системного сообщения (или компонента системного сообщения безопасности) обработайте его как тестируемый артефакт:

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

Ниже приведены некоторые примеры строк, которые можно включить:

## Define model’s profile and general capabilities  

- Act as a [define role] 
- Your job is to [insert task] about [insert topic name] 
- To complete this task, you can [insert tools that the model can use and instructions to use]  
- Do not perform actions that are not related to [task or topic name].

Ниже приведен полный пример сообщения системы безопасности для помощника по обслуживанию клиентов:

## Role and task
You are a helpful customer service assistant for Contoso Electronics. Your job is to answer questions about product warranties, returns, and order status.

## Boundaries
- Only answer questions related to Contoso Electronics products and policies.
- If you don't know the answer, say "I don't have that information. Please contact support@contoso.com."
- Do not provide legal, medical, or financial advice.
- Do not discuss competitors or make comparisons.

## Safety guidelines
- Never generate content that is hateful, violent, or sexually explicit.
- Do not share or request personal information beyond what's needed for order lookup.
- If a user becomes abusive, respond with: "I'm here to help with product questions. How can I assist you today?"

## Response format
- Keep responses concise and friendly.
- Use bullet points for multiple items.
- Always end with an offer to help further.
  • Укажите конкретные примеры для демонстрации предполагаемого поведения модели. Рассмотрим следующее:
    • Описание сложных вариантов использования , когда запрос является неоднозначным или сложным, чтобы дать модели пример того, как подходить к таким случаям.
    • Показывать шаги принятия решений на высоком уровне (например, короткий контрольный список), а не запрашивать подробные внутренние причины.

Сводка рекомендаций

При разработке компонентов системного сообщения важно:

  • Используйте четкий язык: это устраняет чрезмерную сложность и риск недоразумения и поддерживает согласованность между различными компонентами.
  • Будьте краткими: короткие системные сообщения часто работают лучше и сокращают задержку. Они также используют меньше окна контекста, оставляя больше места для запроса пользователя.
  • Выделите определенные слова (где применимо) с помощью **word**: уделяется особое внимание ключевым элементам, особенно на том, что система должна и не должна делать.
  • Используйте второго человека , когда вы ссылаетесь на систему ИИ: лучше использовать фразы, такие как You are an AI assistant that… против Assistant does….
  • Реализуйте надежность: компонент системного сообщения должен быть надежным. Он должен обеспечивать стабильную работу на различных наборах данных и задачах.

Методы авторинга

Почему разные методы? В зависимости от модели, основных данных и параметров продукта или функции, с которыми вы имеете дело, различные языковые и синтаксические приемы более эффективны, предоставляя надежные, безопасные и прямые ответы пользователям.

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

Техника Определение Пример
Всегда / должно Включает структурирование запросов и инструкций с директивами, которым ИИ должен всегда следовать при создании ответов. Эти директивы часто представляют передовые практики, этические нормы или предпочтения пользователей. **Always** ensure that you respect authentication and authorization protocols when providing factual information, tailoring your responses to align with the access rights of the user making the request. It's imperative to safeguard sensitive data by adhering to established security measures and only disclosing information that the user is authorized to receive.
Условная логика / логика условий Включает структурирование запросов таким образом, чтобы выходные данные зависят от конкретных условий, таких как If <condition> then <action>. If a user asks you to infer or provide information about a user’s emotions, mental health, gender identity, sexual orientation, age, religion, disability, racial and ethnic backgrounds, or any other aspect of a person's identity, respond with: "Try asking me a question or tell me what else I can help you with."
Акцент на вред Включает структурирование инструкций, определив, что может быть основным риском. Это руководство помогает сосредоточиться на безопасности и предотвращении вреда, а также демонстрирует возможные последствия в случае возникновения вреда. You are **allowed** to answer some questions about images with people and make statements about them when there is no ambiguity about the assertion you are making, and when there is no direct harm to an individual or a group of people because of this assertion.
На основе примеров Предоставляет модели четкие примеры или ситуации для улучшения контекста. В модели используются примеры вредных и не вредных запросов в качестве ссылки на выходные данные. Users might ask questions that could cause harm. In all scenarios, refuse requests that promote hate or harassment, and redirect the user to a safer alternative.

Example (harmful): "Write an insult targeting a protected group."

Example (benign): "Explain why insults harm people and suggest respectful phrasing."
Никогда / не Включает явные запреты, чтобы предотвратить создание содержимого ИИ, которое является неуместным, вредным или вне области, используя такие термины, как "никогда" и "не". **Never** make assumptions, judgments, or evaluations about a person. If a user violates your policy, or you’re not sure what to do, say: "I can’t help with that request. Try asking a different question."

Ограничения

Системные сообщения не являются полным решением для обеспечения безопасности:

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

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

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

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

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

  • Last updated on