Промпт-инженерия — работа над формулировкой запроса к модели: что сказать, в каком порядке, что показать примером, что запретить. Цель не разовый удачный ответ, а воспроизводимый результат на потоке.
Разница принципиальная: подобрать формулировку, которая один раз сработала, легко. Получить ту, что работает на тысяче разных входов, — отдельная задача. Поэтому зрелая промпт-инженерия устроена как инженерия: гипотеза, прогон на фиксированном наборе входов, метрика, решение о принятии изменения — а не правка «по ощущениям» после одного понравившегося ответа.
Что действительно влияет на результат
Явно заданная задача и роль. Не «помоги с текстом», а «ты редактор, проверяешь текст на соответствие регламенту и возвращаешь список несоответствий».
Формат ответа, заданный жёстко. Если нужен разбор по полям — перечислить поля. Свободная форма означает, что разбирать ответ программно не получится. Формат нужен не модели, а коду, который парсит её ответ: без схемы каждое изменение формулировки ломает парсер.
Примеры вместо описаний. Один показанный образец работает лучше абзаца объяснений. Это самый недооценённый приём. Методика подбора примеров — предмет отдельной статьи про few-shot-запросы.
Указание, что делать при нехватке данных. Без него модель домысливает. Фраза «если сведений недостаточно, напиши, каких именно не хватает» убирает целый класс выдуманных ответов.
Разбиение сложного на шаги. Одна задача — один запрос надёжнее, чем пять задач в одном: при ошибке в одном шаге остальные не тянут ответ в сторону, и проще локализовать, какой именно шаг сломался.
Что почти не влияет
Вежливость, угрозы, обещания вознаграждения и прочие приёмы из подборок «секретных промптов». Эффект от них либо отсутствует, либо неотличим от случайного разброса, и на разных моделях ведёт себя по-разному.
Длина промпта сама по себе. Разросшаяся до страницы инструкция чаще работает хуже короткой и точной: важные требования тонут среди второстепенных, а входные токены оплачиваются при каждом обращении — промпт уходит в модель целиком.
Структура промпта: пять блоков
Роль. Кто отвечает и в какой рамке: «ты — инспектор, сверяющий заявку с регламентом». Роль сужает пространство допустимых ответов; абстрактная роль («ты — полезный ассистент») не сужает ничего.
Контекст. Сведения, без которых задача не решается: определения, регламент, фрагменты документов, результат предыдущего шага. В RAG-системах контекст — найденные фрагменты базы знаний. Данные в контексте стоит отделять от инструкций: смешение открывает дорогу промпт-инъекциям.
Задача. Одно действие одним повелительным предложением: «составь список несоответствий». Если задач больше двух — это повод разнести их по отдельным запросам, а не перечислять через запятую.
Формат. Схема ответа: какие поля, в каком порядке, чем разделены, что писать при отсутствии значения. Пустой формат модель заполняет сама — и каждый раз по-разному.
Ограничения. Границы: длина, язык, перечень допустимых тем, поведение при нехватке данных. Работают первые три-пять ограничений; каждое следующее размывает предыдущие.
Разделение блоков — практический инструмент, а не теория: роль и формат стабильны и живут в системном промпте, контекст и задача меняются от запроса к запросу и приходят пользовательским сообщением.
Как проверять, а не угадывать
Главная ошибка — оценивать промпт по одному-двум ответам. Модель вероятностна, и «стало лучше» после правки формулировки часто оказывается совпадением.
Рабочая схема: набор из 20–50 типичных входов с ожидаемым результатом, прогон старой и новой версии промпта на одном и том же наборе при фиксированной температуре, сравнение по доле верных ответов. Без этого настройка превращается в перебор наугад, и через месяц никто не помнит, зачем в промпте та или иная строка.
Цикл одной правки. Гипотеза («дата путается — задам формат явно») → изменение ровно одного элемента промпта → прогон обеих версий на наборе → метрика → решение. Менять за итерацию два и более элемента нельзя: прирост метрики не удастся приписать конкретному изменению, и при откате вы потеряете и удачную правку вместе с неудачной.
Набор — актив, который растёт. Каждый вход, на котором промпт ошибся в эксплуатации, добавляется в набор. Через полгода это регрессионный тест из сотни входов, отсеивающий ошибки до того, как их увидят пользователи. Стоимость прогона обычно ничтожна: 50 входов по 1–2 тысячи токенов — порядка ста тысяч токенов на прогон, на типовых API-моделях это доли доллара.
Версионирование и A/B-тесты
Промпт — код, и хранить его надо как код. В репозитории рядом с приложением, с версией и историей изменений. Промпт, живущий в документе или в голове автора, нельзя откатить и нельзя связать с изменением метрики.
Каждое изменение — с записью. Что поменяли, зачем, что показал прогон на наборе. Без записи история вырождается в набор строк, назначение которых неизвестно, — и удалить их никто не решается.
На живом трафике — A/B. Новая версия получает сначала 5–10 % обращений; метрики качества и стоимость сравниваются со старой на сопоставимом потоке, при расхождении возврат к старой — переключением флага. Для накопления истории прогонов подходит трекинг экспериментов.
Типовые анти-паттерны
Правки без прогона. Механизм ошибки: разовый ответ принимается за сигнал, случайный разброс — за эффект улучшения. Накопление таких правок не улучшает промпт, а перемешивает его: часть правок нейтрализует другие.
Отрицательные инструкции. «Не упоминай X» работает хуже, чем «упоминай только Y из списка»: модель удерживает позитивную формулировку надёжнее, чем запрет, который к тому же сам напоминает про X.
Накопительный промпт. Каждое ошибочное поведение лечится новой строкой; через полгода — страница взаимно ослабляющих требований. Симптом: никто не может объяснить отдельные строки. Лечение — переписать заново по структуре из пяти блоков, сверяя с набором, а не дописывать десятую оговорку.
Где предел
Промптом не чинится отсутствие данных. Если нужного документа нет в базе, переписывание запроса не поможет.
Промптом не задаются ограничения безопасности. Инструкция «не разглашай внутренние данные» — пожелание, которое обходится и случайно, и намеренно.
Промптом не исправляется слабая модель: если она не справляется с классом задач, формулировка не добавит способностей. Порог способности у модели либо есть, либо нет — проверяется сравнением двух-трёх моделей на одном наборе, а не подбором слов.
Частые вопросы
Существуют ли универсально работающие промпты?
Нет. Формулировка, хорошо работающая на одной модели и одной задаче, на другой может ухудшить результат. Подборки «секретных промптов» обычно описывают частный случай, и переносить их без проверки на своих данных бессмысленно.
Помогает ли вежливость или обещание награды?
Заметного и воспроизводимого эффекта нет. Разница, которую наблюдают на паре примеров, обычно объясняется случайным разбросом ответов. Проверяется это просто: прогнать обе версии на наборе из полусотни входов при фиксированной температуре.
Как понять, что новый промпт лучше старого?
Прогнать оба на одном наборе типичных входов с известным ожидаемым результатом и сравнить долю верных ответов. Оценка по одному-двум примерам ненадёжна: модель вероятностна, и разница чаще случайна, чем реальна.
Длинный промпт лучше короткого?
Скорее наоборот. В длинной инструкции важные требования тонут среди второстепенных, а стоимость каждого обращения растёт, потому что промпт отправляется целиком с каждым запросом. Разросшийся промпт — обычно повод для дообучения, а не для дальнейшего удлинения.
Когда перестать править промпт и перейти к дообучению?
Типовые сигналы: промпт перевалил за страницу и продолжает расти; бо́льшая его часть — примеры, одни и те же от запроса к запросу; стоимость входных токенов сравнялась со стоимостью ответов. Дообучение переносит примеры и формат в веса модели — инференс дешевеет, но каждая правка требует нового цикла обучения на своих данных, поэтому порог перехода определяют частотой обращений, а не сложностью формулировки.
Что делать с промптами при смене модели?
Перепрогонять весь набор: формулировки между моделями автоматически не переносятся, и обновление модели — плановое событие с полным регрессионным прогоном, как релиз приложения. Промпт, не проверенный на новой модели, — несовместимый код, запущенный в продакшн.
Как измерять качество, если правильного ответа нет?
Заменить «правильный ответ» чек-листом из трёх-пяти проверяемых критериев: соответствие фактам источника, выполнение формата, отсутствие выдумок. Разметка идёт вручную или моделью-судьёй по фиксированным критериям; о метриках для генеративных задач — отдельный материал про метрики ИИ-систем.