LLM API и интеграция

Как обновлять промпты при смене модели

Как обновлять промпты при смене модели

Промпт не переносится на новую модель один в один: первыми ломаются формат ответа, его длина, следование ролям и готовность действовать вместо уточняющих вопросов. Перенос проверяют выборкой из 30–50 реальных запросов — это занимает час, и менять при этом можно только что-то одно: либо модель, либо текст промпта. Остальное — следствия этих двух правил.

Дальше — почему текст промпта не переносится, таблица с признаками каждой поломки, порядок проверки на выборке, разбор правила «одно изменение за раз» и схема хранения промптов в версиях. Про переезд интеграции целиком есть отдельный разбор — как перейти на другую модель; про то, как не переписывать код под каждый релиз, — не переписывать интеграцию под релиз. Здесь речь именно о тексте промпта: что в нём ломается и в каком порядке это чинят.

Почему промпт не переносится один в один

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

Причин ровно три, и все они не про качество модели.

Разная реакция на формулировки. «Отвечай только JSON» одна позиция читает как запрет на любой другой вывод, другая — как пожелание, к которому можно добавить пояснение. Пока вы работали с первой, промпт выглядел надёжным.

Разные умолчания по длине и тону. У каждой позиции есть своя средняя манера: одна отвечает тремя строками, другая — тремя абзацами. Промпт, в котором длина не задана явно, опирался на умолчание старой позиции.

Разное поведение при неполном входе. Часть моделей при нехватке данных делает разумное предположение и отвечает, часть задаёт уточняющий вопрос. В сценарии без человека второе — поломка, хотя формально модель ведёт себя аккуратнее.

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

Блок промпта переносится на новую платформу, часть граней при переносе откалывается
Промпт не переезжает один в один: первыми откалываются формат ответа, его длина и следование ролям.

Что ломается первым

Порядок предсказуем, и по нему удобно проверять. Таблица — это диагностика: слева часть промпта, в середине признак, справа правка.

Что ломаетсяКак проявляетсяЧто править в промпте
Формат ответападает разбор, появляются пояснения вокруг структурызадать формат средствами протокола, добавить 2 примера
Длина ответасчёт вырос, ответы стали втрое длиннееявное ограничение в знаках или предложениях плюс пример
Следование системным правиламзапреты игнорируются в длинных диалогахправила короче и ближе к концу промпта, ключевые — повторить
Действие против уточнениямодель задаёт вопрос там, где раньше отвечалаправило поведения при неполном входе, пример ответа на неполный вход
Стиль и тонформально верно, но «чужим голосом»5 и больше примеров в нужной манере
Порядок шаговшаги переставлены или пропущеныпронумеровать шаги, потребовать вывод по шагам
Работа с исключениямиредкое правило применяется как общеевынести исключения отдельным блоком с условием применения

Таблица работает и отдельно от статьи: по ней можно пройти со своим промптом после переезда и не гадать, что чинить первым.

Формат ответа ломается заметнее всего

Это единственная поломка, о которой вы узнаёте сразу, — и потому самая безобидная. Разбор падает, ошибка приходит в журнал, инцидент понятен.

Типичная картина после переезда: модель отдаёт верную структуру, но оборачивает её в пояснение — «Вот результат:» перед данными и «Дайте знать, если нужно что-то ещё» после. Старая позиция этого не делала, и код разбора был написан наивно.

Чинится в два приёма. Первый — задать формат средствами протокола, а не просьбой в тексте; это надёжнее любой формулировки. Второй — два примера в промпте, где ответ начинается сразу со структуры. Механика строгого вывода разобрана в статье про строгий JSON от нейросети.

Заодно это повод укрепить разбор на вашей стороне: код, который переживает лишнюю строку вокруг структуры, переживёт и следующий переезд.

Длина ответа уезжает тихо

Длина — вторая по частоте поломка и первая по цене. Она не вызывает ошибок, поэтому обнаруживается через неделю по счёту.

Если в промпте не было явного ограничения, ответы наследуют умолчание модели. Переезд на позицию с другой манерой может удвоить средний ответ — и удвоить выходные токены при том же числе запросов. На дешёвой позиции вроде 8 ₽ за миллион токенов это терпимо, на 30 ₽ — уже статья расходов.

Правка простая: ограничение формулируется числом, а не словом. «Кратко» каждая модель понимает по-своему, «не более трёх предложений» — одинаково. Пример нужного объёма закрепляет правило надёжнее, чем сама формулировка.

Отдельно стоит проверить, не изменился ли характер расхода: доля рассуждений у моделей с внутренним размышлением попадает в счёт, даже когда ответ на вид короткий. Что здесь настраивается — в разборе уровней рассуждения.

Следование ролям и системным правилам

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

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

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

Здесь же проверяют запреты. Если у вас есть список тем, о которых модель не говорит, прогоните его целиком: запреты — та часть промпта, которая переносится хуже всего, и проверять её надо адресно.

Почему модель начала уточнять вместо действия

Потому что умолчание при неполном входе у новой позиции другое. Для чата это улучшение, для автоматического сценария — остановка конвейера.

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

Правка состоит из двух частей:

  • Правило по умолчанию. «При нехватке данных действуй по разумному предположению и назови его в отдельном поле». Так вы получаете и ответ, и отметку о допущении.
  • Перечень исключений. Случаи, когда уточнять всё-таки нужно, называются списком. Всё, чего нет в списке, не повод для вопроса.

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

Как проверить перенос за час

Выборкой из 30–50 реальных запросов, прогнанных на обеих позициях подряд. Это единственная проверка, которая отличает реальную поломку от разброса.

Порядок:

  1. Соберите запросы с известными правильными ответами. Настоящие, из журнала, включая неудобные и пограничные.
  2. Прогоните их на старой позиции. Это база отсчёта; без неё сравнивать не с чем.
  3. Прогоните тот же промпт без единой правки на новой позиции.
  4. Сравните три числа: долю верных ответов, среднюю длину ответа, долю ответов, не прошедших разбор.
  5. Прогоните дважды на каждой позиции. Разброс между запусками на одном промпте бывает больше, чем разница между моделями, — почему модель отвечает по-разному.

Час работы и сумма в пределах десятков рублей на дешёвых позициях. Методика прогона подробнее — в статье как тестировать нейросеть, критерии сравнения — в разборе как сравнивать модели.

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

Почему нельзя править промпт и модель одновременно

Потому что результат перестаёт что-либо значить. Это правило звучит занудно ровно до первого случая, когда стало хуже и непонятно от чего.

Разберём. Вы переехали на новую позицию и заодно переписали промпт. Доля верных ответов упала на восемь процентов. Дальше вариантов четыре: новая позиция слабее, новая формулировка хуже, оба фактора работают в минус, или один компенсирует другой. Отличить их без повторных прогонов нельзя, а повторные прогоны — это те же час и деньги, только потраченные дважды.

Рабочий порядок такой:

  1. Перенести промпт слово в слово и замерить.
  2. Починить то, что сломалось, по одной правке за раз, замеряя после каждой.
  3. Только потом браться за улучшения, не связанные с переездом.

Третий шаг чаще всего оказывается лишним: после переезда хочется «заодно всё причесать», но улучшения, смешанные с починкой, делают невозможным откат.

Как держать промпты в версиях

Отдельными файлами с номером версии, а не строками внутри кода. Это та же логика, что и с идентификатором модели: то, что меняется чаще кода, из кода выносят.

Минимальный набор полей рядом с текстом промпта:

  • Номер версии и дата. Без этого невозможно сказать, какая версия работала в прошлый вторник.
  • Идентификатор модели, на которой версия замерена. Промпт без привязки к позиции — половина информации.
  • Результат последнего прогона. Доля верных ответов и средняя длина ответа на вашей выборке.
  • Причина изменения. Одна строка: что чинили. Через полгода это единственное, что спасает.

Сама выборка хранится рядом с промптом и живёт столько же. Промпт без выборки нельзя ни проверить, ни перенести — можно только переписать заново.

Что ещё имеет смысл выносить из кода вместе с промптом — разобрано в статье не переписывать интеграцию под релиз; состав записи, по которой потом разбирают инцидент, — в логировании запросов к моделям.

Когда переезд бывает срочным

Срочный случай — когда старая позиция отключается по объявленному расписанию. Тогда порядок тот же, но времени на третий шаг нет.

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

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

Чего мы не утверждаем

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

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

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

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.

Проверка переноса промпта — недорогая процедура: пятьдесят запросов на двух позициях умещаются в сумму, которую не жалко потратить на определённость. Пять текстовых позиций после первого пополнения не тарифицируются, и отладить саму методику прогона можно на них.

Что держать в голове

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

Порядок поломок устойчив: формат, длина, следование правилам, готовность действовать вместо вопроса. Чинят в этом же порядке, по одной правке за раз, замеряя после каждой.

Промпт без выборки нельзя перенести — только переписать заново. Как мы проверяем факты и почему у каждой цифры стоит дата — на странице о проекте. Завести ключ и прогнать перенос на своей выборке: keydealer.ru/login.

Частые вопросы

Почему промпт перестал работать после смены модели?

Потому что промпт — не программа, а текст, который каждая модель трактует по-своему. Формулировки, которые у прежней позиции работали как жёсткое правило, у новой читаются как пожелание. Чаще всего ломаются формат ответа, его длина и следование системным правилам.

Что ломается первым при переносе промпта?

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

Как проверить, что промпт перенёсся?

Прогнать 30–50 реальных запросов с известными правильными ответами на старой и новой позиции подряд и сравнить долю верных, среднюю длину ответа и долю ответов, не прошедших разбор. Час работы и сумма в пределах десятков рублей на дешёвых позициях.

Почему нельзя менять модель и промпт одновременно?

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

Как хранить промпты, чтобы переезд был дешёвым?

В отдельных файлах с номером версии, привязкой к идентификатору модели и датой последнего замера, а не строками внутри кода. Рядом держат выборку для проверки и последний результат прогона. Тогда откат — это возврат к предыдущей версии файла.

Модель стала переспрашивать вместо того, чтобы выполнять. Что делать?

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

Источники