LLM API и интеграция
Как обновлять промпты при смене модели
Промпт не переносится на новую модель один в один: первыми ломаются формат ответа, его длина, следование ролям и готовность действовать вместо уточняющих вопросов. Перенос проверяют выборкой из 30–50 реальных запросов — это занимает час, и менять при этом можно только что-то одно: либо модель, либо текст промпта. Остальное — следствия этих двух правил.
Дальше — почему текст промпта не переносится, таблица с признаками каждой поломки, порядок проверки на выборке, разбор правила «одно изменение за раз» и схема хранения промптов в версиях. Про переезд интеграции целиком есть отдельный разбор — как перейти на другую модель; про то, как не переписывать код под каждый релиз, — не переписывать интеграцию под релиз. Здесь речь именно о тексте промпта: что в нём ломается и в каком порядке это чинят.
Почему промпт не переносится один в один
Промпт — это текст, а не программа. Одна и та же формулировка у разных моделей имеет разный вес, и переезд обнажает всё, что раньше держалось на особенностях конкретной позиции.
Причин ровно три, и все они не про качество модели.
Разная реакция на формулировки. «Отвечай только JSON» одна позиция читает как запрет на любой другой вывод, другая — как пожелание, к которому можно добавить пояснение. Пока вы работали с первой, промпт выглядел надёжным.
Разные умолчания по длине и тону. У каждой позиции есть своя средняя манера: одна отвечает тремя строками, другая — тремя абзацами. Промпт, в котором длина не задана явно, опирался на умолчание старой позиции.
Разное поведение при неполном входе. Часть моделей при нехватке данных делает разумное предположение и отвечает, часть задаёт уточняющий вопрос. В сценарии без человека второе — поломка, хотя формально модель ведёт себя аккуратнее.
Отсюда и общая мысль: промпт всегда содержит скрытые допущения о модели, под которую его писали. Переезд просто делает их видимыми.

Что ломается первым
Порядок предсказуем, и по нему удобно проверять. Таблица — это диагностика: слева часть промпта, в середине признак, справа правка.
| Что ломается | Как проявляется | Что править в промпте |
|---|---|---|
| Формат ответа | падает разбор, появляются пояснения вокруг структуры | задать формат средствами протокола, добавить 2 примера |
| Длина ответа | счёт вырос, ответы стали втрое длиннее | явное ограничение в знаках или предложениях плюс пример |
| Следование системным правилам | запреты игнорируются в длинных диалогах | правила короче и ближе к концу промпта, ключевые — повторить |
| Действие против уточнения | модель задаёт вопрос там, где раньше отвечала | правило поведения при неполном входе, пример ответа на неполный вход |
| Стиль и тон | формально верно, но «чужим голосом» | 5 и больше примеров в нужной манере |
| Порядок шагов | шаги переставлены или пропущены | пронумеровать шаги, потребовать вывод по шагам |
| Работа с исключениями | редкое правило применяется как общее | вынести исключения отдельным блоком с условием применения |
Таблица работает и отдельно от статьи: по ней можно пройти со своим промптом после переезда и не гадать, что чинить первым.
Формат ответа ломается заметнее всего
Это единственная поломка, о которой вы узнаёте сразу, — и потому самая безобидная. Разбор падает, ошибка приходит в журнал, инцидент понятен.
Типичная картина после переезда: модель отдаёт верную структуру, но оборачивает её в пояснение — «Вот результат:» перед данными и «Дайте знать, если нужно что-то ещё» после. Старая позиция этого не делала, и код разбора был написан наивно.
Чинится в два приёма. Первый — задать формат средствами протокола, а не просьбой в тексте; это надёжнее любой формулировки. Второй — два примера в промпте, где ответ начинается сразу со структуры. Механика строгого вывода разобрана в статье про строгий JSON от нейросети.
Заодно это повод укрепить разбор на вашей стороне: код, который переживает лишнюю строку вокруг структуры, переживёт и следующий переезд.
Длина ответа уезжает тихо
Длина — вторая по частоте поломка и первая по цене. Она не вызывает ошибок, поэтому обнаруживается через неделю по счёту.
Если в промпте не было явного ограничения, ответы наследуют умолчание модели. Переезд на позицию с другой манерой может удвоить средний ответ — и удвоить выходные токены при том же числе запросов. На дешёвой позиции вроде 8 ₽ за миллион токенов это терпимо, на 30 ₽ — уже статья расходов.
Правка простая: ограничение формулируется числом, а не словом. «Кратко» каждая модель понимает по-своему, «не более трёх предложений» — одинаково. Пример нужного объёма закрепляет правило надёжнее, чем сама формулировка.
Отдельно стоит проверить, не изменился ли характер расхода: доля рассуждений у моделей с внутренним размышлением попадает в счёт, даже когда ответ на вид короткий. Что здесь настраивается — в разборе уровней рассуждения.
Следование ролям и системным правилам
Правила из системного промпта на новой позиции соблюдаются иначе, особенно в длинных диалогах. Проверять это нужно на конце разговора, а не на первом сообщении.
Наблюдение из практики: чем длиннее контекст, тем слабее держатся правила, стоящие в самом начале. Промпт, который на старой позиции работал до сотого сообщения, на новой может поплыть к двадцатому. Лечится не удлинением правил, а сокращением: длинный свод требований соблюдается хуже, чем пять строк.
Второй приём — повторение ключевого ограничения ближе к концу запроса. Это стоит токенов, но дешевле, чем разбор инцидента с ответом, которого быть не должно. Структура системного промпта и типовые ошибки разобраны отдельно — как написать системный промпт.
Здесь же проверяют запреты. Если у вас есть список тем, о которых модель не говорит, прогоните его целиком: запреты — та часть промпта, которая переносится хуже всего, и проверять её надо адресно.
Почему модель начала уточнять вместо действия
Потому что умолчание при неполном входе у новой позиции другое. Для чата это улучшение, для автоматического сценария — остановка конвейера.
Выглядит это так: на вход приходит заявка без одного поля, и вместо ответа модель спрашивает, что подставить. В интерфейсе с человеком вопрос уместен. В фоновом сценарии его никто не прочтёт, и задача повиснет.
Правка состоит из двух частей:
- Правило по умолчанию. «При нехватке данных действуй по разумному предположению и назови его в отдельном поле». Так вы получаете и ответ, и отметку о допущении.
- Перечень исключений. Случаи, когда уточнять всё-таки нужно, называются списком. Всё, чего нет в списке, не повод для вопроса.
И пример: один образец, где на неполный вход дан готовый ответ с пометкой о предположении, действует сильнее абзаца правил.
Как проверить перенос за час
Выборкой из 30–50 реальных запросов, прогнанных на обеих позициях подряд. Это единственная проверка, которая отличает реальную поломку от разброса.
Порядок:
- Соберите запросы с известными правильными ответами. Настоящие, из журнала, включая неудобные и пограничные.
- Прогоните их на старой позиции. Это база отсчёта; без неё сравнивать не с чем.
- Прогоните тот же промпт без единой правки на новой позиции.
- Сравните три числа: долю верных ответов, среднюю длину ответа, долю ответов, не прошедших разбор.
- Прогоните дважды на каждой позиции. Разброс между запусками на одном промпте бывает больше, чем разница между моделями, — почему модель отвечает по-разному.
Час работы и сумма в пределах десятков рублей на дешёвых позициях. Методика прогона подробнее — в статье как тестировать нейросеть, критерии сравнения — в разборе как сравнивать модели.
Прогнать одну и ту же выборку на двух позициях дешевле, когда обе лежат в одном каталоге на одном ключе: в KeyDealer 53 позиции, 40 доступны сейчас, оплата российской картой в рублях, расход по обеим виден в общем журнале. Тогда проверка переноса промпта — это смена одной строки в конфигурации, а не второй договор и вторая интеграция.
Почему нельзя править промпт и модель одновременно
Потому что результат перестаёт что-либо значить. Это правило звучит занудно ровно до первого случая, когда стало хуже и непонятно от чего.
Разберём. Вы переехали на новую позицию и заодно переписали промпт. Доля верных ответов упала на восемь процентов. Дальше вариантов четыре: новая позиция слабее, новая формулировка хуже, оба фактора работают в минус, или один компенсирует другой. Отличить их без повторных прогонов нельзя, а повторные прогоны — это те же час и деньги, только потраченные дважды.
Рабочий порядок такой:
- Перенести промпт слово в слово и замерить.
- Починить то, что сломалось, по одной правке за раз, замеряя после каждой.
- Только потом браться за улучшения, не связанные с переездом.
Третий шаг чаще всего оказывается лишним: после переезда хочется «заодно всё причесать», но улучшения, смешанные с починкой, делают невозможным откат.
Как держать промпты в версиях
Отдельными файлами с номером версии, а не строками внутри кода. Это та же логика, что и с идентификатором модели: то, что меняется чаще кода, из кода выносят.
Минимальный набор полей рядом с текстом промпта:
- Номер версии и дата. Без этого невозможно сказать, какая версия работала в прошлый вторник.
- Идентификатор модели, на которой версия замерена. Промпт без привязки к позиции — половина информации.
- Результат последнего прогона. Доля верных ответов и средняя длина ответа на вашей выборке.
- Причина изменения. Одна строка: что чинили. Через полгода это единственное, что спасает.
Сама выборка хранится рядом с промптом и живёт столько же. Промпт без выборки нельзя ни проверить, ни перенести — можно только переписать заново.
Что ещё имеет смысл выносить из кода вместе с промптом — разобрано в статье не переписывать интеграцию под релиз; состав записи, по которой потом разбирают инцидент, — в логировании запросов к моделям.
Когда переезд бывает срочным
Срочный случай — когда старая позиция отключается по объявленному расписанию. Тогда порядок тот же, но времени на третий шаг нет.
Что делают в сжатые сроки: переносят промпт без правок, прогоняют выборку, чинят только то, что ломает сценарий целиком — формат и поведение при неполном входе. Длину и стиль оставляют на потом: они стоят денег и нервов, но не останавливают работу.
Даты объявленных отключений имеет смысл держать в календаре и смотреть заранее — календарь отключений моделей. Переезд, начатый за месяц, отличается от переезда за ночь только тем, что в первом случае есть шаг проверки.
Чего мы не утверждаем
Мы не утверждаем, что промпт после переезда обязательно ломается. Иногда он переносится без единой правки; узнать это можно только прогоном, и стоит такой прогон дешевле, чем предположение.
Мы не утверждаем, что более дорогая позиция понимает промпт лучше. Связь между ставкой и следованием инструкции не прямая, а разница между моделями на конкретной задаче измеряется вашей выборкой, а не общими рейтингами.
Мы не приводим вендорских замеров качества. Публиковать чужие цифры, которых мы не проверяли, значит выдавать их за факт, а через месяц они всё равно устареют.
Что нужно, чтобы попробовать
Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.
Проверка переноса промпта — недорогая процедура: пятьдесят запросов на двух позициях умещаются в сумму, которую не жалко потратить на определённость. Пять текстовых позиций после первого пополнения не тарифицируются, и отладить саму методику прогона можно на них.
Что держать в голове
Промпт содержит скрытые допущения о модели, под которую его писали. Переезд их обнажает, и это не дефект новой позиции, а свойство текста.
Порядок поломок устойчив: формат, длина, следование правилам, готовность действовать вместо вопроса. Чинят в этом же порядке, по одной правке за раз, замеряя после каждой.
Промпт без выборки нельзя перенести — только переписать заново. Как мы проверяем факты и почему у каждой цифры стоит дата — на странице о проекте. Завести ключ и прогнать перенос на своей выборке: keydealer.ru/login.
Частые вопросы
Почему промпт перестал работать после смены модели?
Потому что промпт — не программа, а текст, который каждая модель трактует по-своему. Формулировки, которые у прежней позиции работали как жёсткое правило, у новой читаются как пожелание. Чаще всего ломаются формат ответа, его длина и следование системным правилам.
Что ломается первым при переносе промпта?
Формат ответа, длина, следование ролям и готовность действовать вместо уточняющих вопросов — примерно в этом порядке. Формат замечают сразу, потому что падает разбор. Длину и склонность переспрашивать замечают позже, через счёт и жалобы пользователей.
Как проверить, что промпт перенёсся?
Прогнать 30–50 реальных запросов с известными правильными ответами на старой и новой позиции подряд и сравнить долю верных, среднюю длину ответа и долю ответов, не прошедших разбор. Час работы и сумма в пределах десятков рублей на дешёвых позициях.
Почему нельзя менять модель и промпт одновременно?
Потому что тогда непонятно, что именно дало результат. Если стало хуже, вы не знаете, виновата новая позиция или новая формулировка. Сначала переносят промпт без изменений и замеряют, потом правят текст по конкретным отклонениям.
Как хранить промпты, чтобы переезд был дешёвым?
В отдельных файлах с номером версии, привязкой к идентификатору модели и датой последнего замера, а не строками внутри кода. Рядом держат выборку для проверки и последний результат прогона. Тогда откат — это возврат к предыдущей версии файла.
Модель стала переспрашивать вместо того, чтобы выполнять. Что делать?
Добавить в промпт явное правило поведения при нехватке данных: действовать по разумному предположению и назвать его, а уточнять только в перечисленных случаях. Помогает и пример, где на неполный вход дан готовый ответ, а не вопрос.