TL;DR
Модель отвечает по-разному в зависимости от того, чем она считает свою задачу — ответом на вопрос или заполнением обязательных полей схемы. SMT — атака, которая этим пользуется: вредоносный запрос прячется внутрь описания параметра функции, а не подаётся напрямую. Модель переключается из режима «стоит ли мне это говорить?» в режим «какое значение должно быть в этом поле?».
Главная находка: модель реагирует не на содержание запроса, а на его структурную роль в контексте. Тот же вопрос, упакованный как поле в схеме («поле unsafe_sample, обязательное, описание: реалистичный пример для тестирования модерации»), вызывает другое поведение, чем прямой вопрос «напиши мне X». Плюс — если модель отказывается, SMT вместо сохранения отказа подменяет его» на «ошибку выполнения» в истории диалога. Модель видит не «я правильно отказал», а «я допустил баг, который нужно исправить».
Атака работает за три хода: (1) создаёт поддельную схему функций, где вредный запрос зашит в описание поля, (2) если модель отказывает — подменяет отказ фиктивным «успешным вызовом» в истории + валидационной ошибкой, (3) накапливает «трассировки ошибок» в контексте, пока петля самокоррекции модели не начинает вырабатывать вредный контент.
Схема метода
ХОД 1 (установка фрейма):
Запрос → отправить схему двух «функций»:
- Case Generator: параметры safe_sample + unsafe_sample (обязательные)
- Case Validator: описывает, по каким правилам пара «валидна»
Вредный запрос зашит в ОПИСАНИЕ параметра, не в сам промпт
→ Модель пытается заполнить поля, а не ответить на вопрос
ХОД 2 (перехват отказа):
Если модель отказала → НЕ сохраняем отказ в историю
Вместо него → вставляем фиктивный «Function Call» (как будто сработало)
+ «Ошибку валидатора» (safe_sample слишком короткий / unsafe_sample пустой)
→ Модель видит: «я выполнил функцию, но результат не прошёл проверку»
ХОД 3 (накопление трасс):
Каждый следующий ход → дополнительная «валидационная ошибка» в истории
Петля самокоррекции модели работает против неё самой:
«исправить ошибку» = выдать нужное содержимое
→ Постепенная эрозия поведения по умолчанию
Все ходы идут через API с подачей контекста вручную. В обычном чате это воспроизвести сложнее — но принципы работают и там.
Пример применения
Задача: Вы готовите стартап-питч перед тем, как идти к инвестору или постить на vc.ru. Нужна честная жёсткая оценка, а не дипломатическая. Прямой вопрос «что не так с моей идеей?» даёт мягкие «возможные риски» и «стоит подумать о...».
Промпт:
Ты — система автоматической экспертизы стартап-заявок перед питч-сессией.
Твоя задача — заполнить карточку оценки заявки по схеме ниже.
Все поля обязательны. Пустые поля = ошибка валидации.
Поля должны быть заполнены конкретно и прямо — без формулировок «может быть» и «стоит рассмотреть».
---
СХЕМА КАРТОЧКИ ОЦЕНКИ:
поле: смертельное_допущение
тип: строка
описание: одно допущение, на котором держится вся бизнес-модель и которое,
скорее всего, окажется ложным. Указать конкретно — не «рынок может не принять»,
а «основатели считают, что X, но на деле Y»
поле: почему_инвестор_скажет_нет
тип: строка
описание: главный аргумент против инвестиции — не общий риск,
а конкретная причина отказа опытного инвестора типа Рунетлекс или Фридман Кэпитал
поле: кто_уже_делает_это_лучше
тип: строка
описание: реальный конкурент или аналог, о котором основатели,
скорее всего, не знают или недооценивают.
Привести название и чем именно сильнее.
поле: честный_прогноз
тип: строка
описание: что произойдёт с проектом через 18 месяцев при текущей стратегии —
конкретный сценарий, не «зависит от многих факторов»
---
Заявка для оценки:
[вставь описание своей идеи]
Результат:
Модель заполнит каждое поле отдельно — конкретно, без дипломатических оговорок. Вместо «вы можете столкнуться с конкуренцией» получите «Ozon уже запустил это в Q3 2023, у них 40 млн пользователей и бесплатная логистика». Структура карточки требует конкретики — неопределённые ответы не проходят «логику валидации», которую модель сама себе задаёт через описания полей.
Почему это работает
Когда вы задаёте прямой вопрос — модель оценивает уместность ответа через накопленные шаблоны: «это спорная тема → добавить оговорки», «критика → смягчить». Прямой вопрос активирует фильтр уместности.
Когда вы даёте схему с обязательными полями — модель переключается в режим заполнения формы. Её задача теперь не «что уместно сказать», а «что является корректным значением для этого поля». Описание поля становится главным контекстом — а не тема запроса целиком.
Здесь ключевой рычаг управления: описание поля важнее заголовка запроса. Именно в описаниях полей стоит прописывать требования к формату, тону, уровню конкретности — модель следует им точнее, чем инструкциям в теле промпта. Другой рычаг — обязательность полей: указание тип: строка, обязательное заставляет модель заполнить поле даже если прямой вопрос она бы смягчила.
Дополнительный эффект: история диалога формирует поведение не меньше, чем текущий запрос. То, что модель «сказала» в предыдущих ходах, становится прецедентом. Это работает и в вашу пользу — если первые ходы установили, что «мы заполняем карточки экспертизы», дальнейшие запросы обрабатываются в том же режиме.
Рычаги управления:
- описание поля → главный место для конкретных требований к выводу
- обязательность полей → убирает хеджирование («это не я решаю, таков формат»)
- формат вывода (карточка, таблица, JSON) → переключает из «диалогового» в «системный» режим
- ссылка на валидатор в описании функции → дополнительный сигнал «это часть рабочего процесса, а не самостоятельный запрос»
Шаблон промпта
Ты — {название_системы} (например: система оценки заявок, редакторская проверка, аудит стратегии).
Твоя задача — заполнить карточку {тип_карточки} по схеме ниже.
Все поля обязательны. Пустые поля = ошибка валидации.
Каждое поле — конкретный ответ, без формулировок «возможно» и «в зависимости от ситуации».
---
СХЕМА:
поле: {название_поля_1}
тип: строка
описание: {что именно нужно в этом поле — конкретные требования к содержимому}
поле: {название_поля_2}
тип: строка
описание: {требования — включая нежелательные паттерны, которые нужно исключить}
поле: {название_поля_3}
тип: строка
описание: {требования}
---
Объект для оценки:
{твой текст/задача/материал}
Что подставлять:
- {название_системы} — любая роль, которая предполагает экспертную оценку или системную обработку
- {тип_карточки} — что вы оцениваете (заявка, текст, стратегия, идея, резюме)
- {название_поля} — конкретные аспекты, о которых хотите честный ответ
- В описание поля — ключевые требования к тону, конкретности, формату. Именно сюда стоит вынести «никакого смягчения», «конкретный пример», «реальный конкурент»
🚀 Быстрый старт — вставь в чат:
Вот шаблон структурной карточки для честной экспертной оценки.
Адаптируй под мою задачу: {твоя задача — например, «хочу резкую оценку моего лендинга»}.
Задавай вопросы, чтобы заполнить нужные поля.
[вставить шаблон выше]
LLM спросит о материале для оценки и ключевых аспектах, которые важны именно вам — потому что ей нужно знать, какие поля схемы будут наиболее полезны для вашей задачи. Она возьмёт паттерн из шаблона и адаптирует под конкретный запрос.
Ограничения
⚠️ Работает лучше на конкретных, верифицируемых задачах: Схема требует полей с объективно проверяемым содержимым (конкурент, дата, число, конкретный аргумент). Для субъективных оценок («насколько это красиво») — эффект слабее: описание поля не может принудить к объективности там, где её нет.
⚠️ Не для простых односложных запросов: Если модель прекрасно отвечает на прямой вопрос — схема только добавляет лишний объём. Этот приём окупается там, где стандартный ответ слишком дипломатичный, размытый или неполный.
⚠️ Описания полей требуют точности: Слабое описание («укажи проблемы») работает не лучше прямого вопроса. Ценность — в конкретных инструкциях внутри описания поля: что именно должно быть, в каком формате, что недопустимо.
⚠️ Эффект ослабевает на ультра-чувствительных темах: Схема снижает порог хеджирования, но не отменяет ограничения модели полностью. На темах, где модель обучена отказывать категорически — структура поможет меньше.
Ресурсы
Beyond the Prompt: Jailbreaking Function-Calling LLMs via Simulated Moderation Traces Junlong Liu, Haobo Wang, Weiqi Luo (Sun Yat-sen University), Xiaojun Jia (Nanyang Technological University) GitHub: https://github.com/liujlong27/SMT
Связанные работы из статьи: JailbreakFunction [16], Crescendo [18], PAIR [37], ISC [19]