В этом материале
Gemma 4 добавляет нативную system, поэтому прежним инструкциям внутри первого user нужен осознанный переход формата.
Gemma 4 вводит нативную поддержку system и другой отрисованный формат разговора. При переходе с Gemma 3 нужно осознанно обновлять построение промпта вместо простой замены идентификатора модели.
Прочитайте прежние и новые правила ролей
Руководство формата Gemma 4 описывает системные инструкции и новые разделители ходов. Прежнее руководство сообщает о ролях user и model и размещении системных указаний внутри первого пользовательского запроса.
Карточка Gemma 4 прямо выделяет нативную system как новую возможность. Инструкция внутри прежнего первого user не становится отдельным сообщением system автоматически после замены checkpoint.
Разделите объекты сообщений и отрисованные токены
Клиент может использовать структурированные роли, а tokenizer — выводить собственные обозначения и разделители модели. Документация Gemma 4 использует model в сериализованном формате. Это не следует смешивать со словарём ролей окружающего API.
Выполняйте сопоставление выбранным processor или шаблоном. Нельзя глобально заменять assistant на model в запросе API только из-за наличия второго слова в отрисованном примере. Исследуйте сформированный промпт именно выбранного checkpoint.
Уберите дубли старых инструкций
Предположим, прежний user начинается требованием краткого фиксированного формата. При переходе оно переносится в system. Оставшаяся копия в первом пользовательском сообщении создаёт повтор, а после последующих правок — возможное противоречие.
| Часть промпта | Проверка перехода |
|---|---|
| Системное указание | Находится в нужной новой роли |
| Первый запрос user | Содержит задачу без устаревшей копии |
| История assistant | Отрисовывается выбранным шаблоном |
| Разделители ходов | Соответствуют формату Gemma 4 |
| Префикс генерации | Правильно начинает следующий ответ модели |
Переход должен сохранять смысл инструкции, изменяя её размещение через поддерживаемый способ форматирования. Сравнивайте это с исходным требованием приложения, а не только с внешним видом строки.
Проверьте безобидный конфликтный пример
Подготовьте вымышленную задачу редакции с системным правилом вывода и цитируемым исходным материалом, похожим на инструкцию. Проверьте обработку цитаты как данных согласно предусмотренной политике приложения.
Это диагностический пример, а не доказательство полной устойчивости к атакам на промпт. Сохраните структурированные сообщения и отрисованный текст, чтобы связать неожиданный ответ с реальным входом вместо автоматического объяснения способностями модели.
Примите миграцию формата отдельно
Храните прежние и новые примеры, ревизии checkpoint и проверки окончательного ответа. Убедитесь в сохранении фактов задачи, требуемой форме вывода и правильном продолжении разговора после перехода.
Успешная миграция подтверждает нужное кодирование и использование нового промпта в исследованной задаче. Она не устанавливает универсальной иерархии инструкций, идентичности поведения всех сред или полной безопасности приложения. Замена модели и переход формата связаны, но доказательства приёмки каждого изменения должны оставаться отдельно проверяемыми. Это особенно полезно при дальнейшем обновлении шаблона либо клиентского адаптера.