Подход «контракт системной инструкции» решает отдельную продуктовую задачу. Системная инструкция должна задавать устойчивые правила поведения продукта: назначение, приоритеты, запреты, формат и порядок обработки неопределённости.
Рамка «контракт системной инструкции» отделяет проверяемые решения от стилистических предпочтений.
OpenAI Model Spec описывает цепочку приоритетов для инструкций разных уровней. основание
Редакционная схема «контракт системной инструкции» проверяется на запросах про «роль модели в продукте» и данных конкретного продукта.
Рабочая постановка задачи
Постановка «контракт системной инструкции» начинается с пользователя и его следующего действия.
Цель «контракт системной инструкции» связывается с допустимой ошибкой и способом проверки.
Элемент «роль модели в продукте» уточняет границу решения «контракт системной инструкции».
Действие «описать продуктовый сценарий» превращает эту границу в рабочий артефакт.
Связка «роль модели в продукте — описать продуктовый сценарий» получает владельца и версию.
Элемент «разрешённые задачи» уточняет границу решения «контракт системной инструкции».
Действие «разделить обязательные правила и предпочтения» превращает эту границу в рабочий артефакт.
Связка «разрешённые задачи — разделить обязательные правила и предпочтения» получает владельца и версию.
Элемент «запрещённые действия» уточняет границу решения «контракт системной инструкции».
Действие «устранить взаимные противоречия» превращает эту границу в рабочий артефакт.
Связка «запрещённые действия — устранить взаимные противоречия» получает владельца и версию.
Руководство OpenAI рекомендует явно задавать инструкции и необходимый контекст. основание
Постановка «контракт системной инструкции» считается готовой вслед за проверки — в практике «Как писать системные инструкции для LLM» — неоднозначностей.
Состав решения и рамки компонентов
Конструкция «контракт системной инструкции» включает шесть наблюдаемых элементов.
Роль модели в продукте. Этот элемент задаёт часть рамки «контракт системной инструкции».
Для «роль модели в продукте» выполняется действие «описать продуктовый сценарий».
Проверка «роль модели в продукте» использует критерий «каждое правило имеет однозначный приоритет».
Разрешённые задачи. Этот элемент задаёт часть рамки «контракт системной инструкции».
Для «разрешённые задачи» выполняется действие «разделить обязательные правила и предпочтения».
Проверка «разрешённые задачи» использует критерий «ограничения проверяются тестовыми запросами».
Запрещённые действия. Этот элемент задаёт часть рамки «контракт системной инструкции».
Для «запрещённые действия» выполняется действие «устранить взаимные противоречия».
Проверка «запрещённые действия» использует критерий «формат можно валидировать автоматически».
Правила работы с источниками. Этот элемент задаёт часть рамки «контракт системной инструкции».
Для «правила работы с источниками» выполняется действие «добавить наблюдаемые критерии результата».
Проверка «правила работы с источниками» использует критерий «неизвестность приводит к предусмотренному поведению».
Формат ответа. Этот элемент задаёт часть рамки «контракт системной инструкции».
Для «формат ответа» выполняется действие «проверить инструкцию на конфликтных запросах».
Проверка «формат ответа» использует критерий «изменения имеют автора и версию».
Условия отказа и эскалации. Этот элемент задаёт часть рамки «контракт системной инструкции».
Для «условия отказа и эскалации» выполняется действие «версионировать утверждённый текст».
Проверка «условия отказа и эскалации» использует критерий «инструкция не содержит секретов».
Связи элементов «контракт системной инструкции» сохраняются в технической трассе.
Порядок внедрения и проверки
Процедура «контракт системной инструкции» меняет один существенный фактор за итерацию.
Шаг 1: описать продуктовый сценарий. Результат шага сохраняется отдельно.
Шаг «описать продуктовый сценарий» проверяет элемент «роль модели в продукте».
Шаг «описать продуктовый сценарий» исключает сбой «абстрактная роль без задачи».
Шаг 2: разделить обязательные правила и предпочтения. Результат шага сохраняется отдельно.
Шаг «разделить обязательные правила и предпочтения» проверяет элемент «разрешённые задачи».
Шаг «разделить обязательные правила и предпочтения» исключает сбой «смешение правил и примеров».
Шаг 3: устранить взаимные противоречия. Результат шага сохраняется отдельно.
Шаг «устранить взаимные противоречия» проверяет элемент «запрещённые действия».
Шаг «устранить взаимные противоречия» исключает сбой «запрет без безопасной альтернативы».
Шаг 4: добавить наблюдаемые критерии результата. Результат шага сохраняется отдельно.
Шаг «добавить наблюдаемые критерии результата» проверяет элемент «правила работы с источниками».
Шаг «добавить наблюдаемые критерии результата» исключает сбой «скрытая зависимость от интерфейса».
Шаг 5: проверить инструкцию на конфликтных запросах. Результат шага сохраняется отдельно.
Шаг «проверить инструкцию на конфликтных запросах» проверяет элемент «формат ответа».
Шаг «проверить инструкцию на конфликтных запросах» исключает сбой «невозможность проверить соблюдение».
Шаг 6: версионировать утверждённый текст. Результат шага сохраняется отдельно.
Шаг «версионировать утверждённый текст» проверяет элемент «условия отказа и эскалации».
Шаг «версионировать утверждённый текст» исключает сбой «абстрактная роль без задачи».
Google рассматривает проектирование промптов как итеративный процесс с ясными и конкретными указаниями. основание
Итерация «контракт системной инструкции» завершается решением ответственного, а не — применительно к теме «Как писать системные инструкции для LLM» — впечатлением.
Типовые сбои и диагностика
Диагностика «контракт системной инструкции» начинается с наиболее раннего наблюдаемого сбоя.
Абстрактная роль без задачи. Такой дефект относится к «роль модели в продукте».
Сбой «абстрактная роль без задачи» воспроизводится через действие «описать продуктовый сценарий».
Исправление «абстрактная роль без задачи» проверяется без смены остальных факторов.
Смешение правил и примеров. Такой дефект относится к «разрешённые задачи».
Сбой «смешение правил и примеров» воспроизводится через действие «разделить обязательные правила и предпочтения».
Исправление «смешение правил и примеров» проверяется без смены остальных факторов.
Запрет без безопасной альтернативы. Такой дефект относится к «запрещённые действия».
Сбой «запрет без безопасной альтернативы» воспроизводится через действие «устранить взаимные противоречия».
Исправление «запрет без безопасной альтернативы» проверяется без смены остальных факторов.
Скрытая зависимость от интерфейса. Такой дефект относится к «правила работы с источниками».
Сбой «скрытая зависимость от интерфейса» воспроизводится через действие «добавить наблюдаемые критерии результата».
Исправление «скрытая зависимость от интерфейса» проверяется без смены остальных факторов.
Невозможность проверить соблюдение. Такой дефект относится к «формат ответа».
Сбой «невозможность проверить соблюдение» воспроизводится через действие «проверить инструкцию на конфликтных запросах».
Исправление «невозможность проверить соблюдение» проверяется без смены остальных факторов.
Разбор «контракт системной инструкции» не затушёвывает исходный сбой качественным — применительно к теме «Как писать системные инструкции для LLM» — итоговым ответом.
Рабочий сценарий
Иллюстративный сценарий для «контракт системной инструкции»: Редактор внутренней базы знаний задаёт помощнику обязанность отвечать только по переданным документам, показывать недостаток основания и возвращать фиксированные поля для интерфейса.
Пример «контракт системной инструкции» не описывает опыт конкретной организации.
Сначала «роль модели в продукте» фиксируется через действие «описать продуктовый сценарий».
Затем «роль модели в продукте» проверяется критерием «каждое правило имеет однозначный приоритет».
Результат по «роль модели в продукте» сравнивается с исходной версией.
Сначала «разрешённые задачи» фиксируется через действие «разделить обязательные правила и предпочтения».
Затем «разрешённые задачи» проверяется критерием «ограничения проверяются тестовыми запросами».
Результат по «разрешённые задачи» сравнивается с исходной версией.
Сначала «запрещённые действия» фиксируется через действие «устранить взаимные противоречия».
Затем «запрещённые действия» проверяется критерием «формат можно валидировать автоматически».
Результат по «запрещённые действия» сравнивается с исходной версией.
Сначала «правила работы с источниками» фиксируется через действие «добавить наблюдаемые критерии результата».
Затем «правила работы с источниками» проверяется критерием «неизвестность приводит к предусмотренному поведению».
Результат по «правила работы с источниками» сравнивается с исходной версией.
Неудачный прогон «контракт системной инструкции» откатывается до повторной диагностики.
Успешный прогон «контракт системной инструкции» расширяется только после контрольной выборки.
Критерии качества
Качество «контракт системной инструкции» определяется совокупностью независимых признаков.
Каждое правило имеет однозначный приоритет. Признак проверяется на элементе «роль модели в продукте».
Критерий «каждое правило имеет однозначный приоритет» имеет порог и владельца решения.
Доказательство «каждое правило имеет однозначный приоритет» сохраняется рядом с версией системы.
Ограничения проверяются тестовыми запросами. Признак проверяется на элементе «разрешённые задачи».
Критерий «ограничения проверяются тестовыми запросами» имеет порог и владельца решения.
Доказательство «ограничения проверяются тестовыми запросами» сохраняется рядом с версией системы.
Формат можно валидировать автоматически. Признак проверяется на элементе «запрещённые действия».
Критерий «формат можно валидировать автоматически» имеет порог и владельца решения.
Доказательство «формат можно валидировать автоматически» сохраняется рядом с версией системы.
Неизвестность приводит к предусмотренному поведению. Признак проверяется на элементе «правила работы с источниками».
Критерий «неизвестность приводит к предусмотренному поведению» имеет порог и владельца решения.
Доказательство «неизвестность приводит к предусмотренному поведению» сохраняется рядом с версией системы.
Изменения имеют автора и версию. Признак проверяется на элементе «формат ответа».
Критерий «изменения имеют автора и версию» имеет порог и владельца решения.
Доказательство «изменения имеют автора и версию» сохраняется рядом с версией системы.
Инструкция не содержит секретов. Признак проверяется на элементе «условия отказа и эскалации».
Критерий «инструкция не содержит секретов» имеет порог и владельца решения.
Доказательство «инструкция не содержит секретов» сохраняется рядом с версией системы.
OWASP относит прямое и косвенное изменение поведения модели через входные данные к prompt injection. основание
Выпуск «контракт системной инструкции» блокируется заранее определёнными критическими дефектами.
Ограничения применимости
Ограничения «контракт системной инструкции» публикуются рядом с результатами проверки.
Модель может соблюдать инструкцию непоследовательно. Ограничение связано с «роль модели в продукте».
Риск «модель может соблюдать инструкцию непоследовательно» получает владельца и дату пересмотра.
Вывод по «модель может соблюдать инструкцию непоследовательно» не переносится автоматически на другой контекст.
Prompt injection нельзя устранять только текстом. Ограничение связано с «разрешённые задачи».
Риск «prompt injection нельзя устранять только текстом» получает владельца и дату пересмотра.
Вывод по «prompt injection нельзя устранять только текстом» не переносится автоматически на другой контекст.
Разные модели интерпретируют формулировки по-разному. Ограничение связано с «запрещённые действия».
Риск «разные модели интерпретируют формулировки по-разному» получает владельца и дату пересмотра.
Вывод по «разные модели интерпретируют формулировки по-разному» не переносится автоматически на другой контекст.
Правила продукта не заменяют внешние проверки. Ограничение связано с «правила работы с источниками».
Риск «правила продукта не заменяют внешние проверки» получает владельца и дату пересмотра.
Вывод по «правила продукта не заменяют внешние проверки» не переносится автоматически на другой контекст.
Слишком длинный текст усложняет диагностику. Ограничение связано с «формат ответа».
Риск «слишком длинный текст усложняет диагностику» получает владельца и дату пересмотра.
Вывод по «слишком длинный текст усложняет диагностику» не переносится автоматически на другой контекст.
Рамка «контракт системной инструкции» не заменяет профильную правовую экспертизу.
Критичное применение «контракт системной инструкции» требует независимого человеческого контроля.
Вывод
Подход «контракт системной инструкции» превращает общую рекомендацию в проверяемый контракт.
Элемент «роль модели в продукте» связывается с действием «описать продуктовый сценарий».
Действие «описать продуктовый сценарий» подтверждается критерием «каждое правило имеет однозначный приоритет».
Элемент «разрешённые задачи» связывается с действием «разделить обязательные правила и предпочтения».
Действие «разделить обязательные правила и предпочтения» подтверждается критерием «ограничения проверяются тестовыми запросами».
Элемент «запрещённые действия» связывается с действием «устранить взаимные противоречия».
Действие «устранить взаимные противоречия» подтверждается критерием «формат можно валидировать автоматически».
Главный результат «контракт системной инструкции» — воспроизводимое продуктовое решение.
Решение «контракт системной инструкции» показывает основание, ограничение и безопасный следующий шаг.
