Промпт-инжиниринг: приёмы, которые действительно работают
Вокруг составления запросов накопилось много суеверий: волшебные фразы, обещания чаевых, требования «думать шаг за шагом» в каждом промпте. Часть приёмов работает, часть — просто оплачивается как лишние токены. Разберём, что относится к чему.
Что влияет сильнее всего
**Роль и формат.** Скажите, кто отвечает и в каком виде нужен результат: три абзаца, таблица, список из пяти пунктов, JSON с определёнными полями. Это самая дешёвая правка с самой большой отдачей.
**Примеры.** Один-два образца хорошего ответа объясняют модели задачу лучше, чем абзац описаний. Приём особенно силён там, где важен стиль или структура.
**Ограничения.** Прямые запреты работают надёжнее пожеланий: не использовать превосходные степени, не выдумывать характеристики, не выходить за двести слов.
**Разбиение на шаги.** Для задач с рассуждением помогает попросить сначала выписать факты, потом сделать вывод. Для простых задач это только удлиняет ответ.
Что почти не влияет
Вежливые обороты, обращения по имени, эмоциональные усиления вроде «это очень важно». На качество они не действуют, но исправно расходуются как токены при каждом запросе.
Отдельно стоит упомянуть длинные преамбулы о том, какая модель умная. Это чистый расход: системный промпт отправляется с каждым обращением, и лишние двести токенов при десяти тысячах запросов в сутки превращаются в два миллиона токенов в день ни за что.
Как писать системный промпт
Держите его коротким и проверяемым. Хорошая структура выглядит так:
- Кто отвечает и на каком языке.
- Из чего брать факты и что делать, если их нет.
- Формат ответа.
- Список запретов.
- Один пример правильного ответа.
Всё, что не попадает ни в один из пунктов, скорее всего лишнее.
Приём, который экономит больше всего
Ограничьте длину ответа явно. Ответ тарифицируется дороже входа, обычно в два-четыре раза, поэтому фраза «ответь одним абзацем» снижает счёт заметнее, чем сокращение контекста.
Проверьте гипотезу на своём проекте: сократите системный промпт вдвое и прогоните контрольный набор примеров. В большинстве случаев разницы в качестве не будет, а расход упадёт.
Как проверять правки
Меняйте по одному за раз и сравнивайте на одном и том же наборе из тридцати примеров. Без такого набора любые улучшения — вопрос вкуса, и через месяц никто не вспомнит, зачем в промпте появился третий абзац.
Записывайте версии промпта рядом с кодом, а не в переписке. Промпт — такая же часть системы, как запрос к базе данных, и должен жить в репозитории.
Разбор одного промпта
Допустим, нужно описание товара для каталога. Первая версия обычно звучит как «напиши продающее описание товара» — и получает в ответ рекламный текст с превосходными степенями, который никуда не годится.
Разберём, что добавить. Роль: «ты составляешь описания для каталога интернет-магазина». Формат: три абзаца, первый — что это, второй — из чего сделано, третий — кому подойдёт. Ограничения: не использовать слова «уникальный», «лучший», «инновационный»; не выдумывать характеристики, которых нет во входных данных; уложиться в сто восемьдесят слов.
Источник фактов: «используй только характеристики из блока ДАННЫЕ ниже». Что делать при нехватке: «если характеристики не хватает, пропусти её, не додумывай».
Получившаяся инструкция длиннее исходной строчки, но она пишется один раз, а работает на всём каталоге. И почти каждый её пункт закрывает конкретную ошибку, которую вы иначе будете править вручную в каждом тексте.
Проверять такую инструкцию нужно на десятке разных товаров, включая неудобные: позиции с минимумом характеристик и, наоборот, с длинным списком. Именно на краях формулировка обычно разваливается.
Частая ошибка
Попытка решить промптом задачу, которая решается кодом. Если нужно, чтобы ответ всегда содержал корректный номер заказа, не просите модель его не путать — подставьте номер сами после ответа. Формулировка снижает вероятность ошибки, код её исключает.
Полезно держать рядом с промптом короткий комментарий: зачем добавлен каждый пункт и какую ошибку он закрывает. Через полгода это спасает от соблазна «почистить лишнее» и вернуть проблему, которую однажды уже решили. Такой комментарий занимает три строки и стоит дешевле повторного разбора.