Что такое prompt engineering и почему он вообще нужен
Большая языковая модель не «понимает» задачу в человеческом смысле. Она предсказывает следующий токен на основе всего, что было подано на вход. Качество ответа напрямую зависит от того, как сформулирован запрос, в каком порядке подана информация и какие ограничения заданы. Prompt engineering — это набор приёмов, которые позволяют управлять поведением модели без изменения её весов.
Ни одна из описанных ниже техник не является магией. Все они сводятся к одному принципу: чем точнее и структурированнее входной контекст, тем выше вероятность получить нужный результат с первого раза.
Системный промпт: роль, формат, ограничения
Системный промпт (system prompt) — это инструкция, которая подаётся модели до начала диалога. В большинстве API она передаётся отдельным полем с ролью
system и не видна конечному пользователю напрямую, но влияет на каждый последующий ответ.Что стоит включать в системный промпт
- Роль и экспертиза. Указание, кем модель должна себя считать: «Ты — технический редактор», «Ты — senior DevOps-инженер». Это задаёт регистр, глубину и терминологию.
- Формат ответа. Явное указание: «Отвечай в формате JSON», «Используй Markdown-таблицы», «Не более трёх абзацев».
- Ограничения. Чего делать нельзя: «Не выдумывай источники», «Не давай медицинских рекомендаций», «Если не знаешь — скажи об этом».
- Стиль и тон. «Пиши кратко», «Избегай канцелярита», «Обращайся на ты».
Типичные ошибки в системных промптах
| Ошибка | Почему вредит | Как исправить |
|---|---|---|
| Слишком длинный промпт с противоречиями | Модель усредняет конфликтующие инструкции | Сократить до ключевых правил, убрать дубли |
| Негативные формулировки без позитивной альтернативы | «Не будь многословным» не говорит, каким быть | Заменить на «Отвечай в 2–3 предложениях» |
| Инструкции, дублирующие пользовательский запрос | Модель может запутаться в приоритетах | Системный промпт — для глобальных правил, пользовательский — для конкретной задачи |
| Отсутствие примеров формата | Модель угадывает структуру | Добавить один шаблон ожидаемого вывода |
Приоритет инструкций
В большинстве реализаций системный промпт имеет наивысший приоритет. Однако это не абсолютная защита: при достаточно длинном пользовательском вводе модель может «забыть» ранние инструкции из-за ограничений контекстного окна. Это не уязвимость в классическом смысле, а следствие архитектуры трансформера — внимание к началу контекста ослабевает при очень длинных последовательностях.
Few-shot prompting: примеры как спецификация
Few-shot — это техника, при которой в промпт добавляются примеры пар «вход → выход». Модель не обучается на них в привычном смысле, но использует их как контекстную подсказку для определения формата, стиля и логики.
Когда few-shot работает лучше всего
- Нестандартный формат вывода. Например, нужно получить JSON с определёнными ключами или специфическую разметку.
- Классификация с неочевидными границами. Примеры показывают, где проходит грань между классами.
- Стилистическая адаптация. Модель копирует тон и структуру из примеров.
- Задачи с неявными правилами. Например, извлечение именованных сущностей по кастомной схеме.
Структура few-shot промпта
Код:
Системный промпт: Ты классифицируешь обращения клиентов по категориям.
Категории: billing, technical, account, other.
Пример 1:
Вход: «Мне пришёл двойной счёт за март»
Выход: billing
Пример 2:
Вход: «Не могу войти в личный кабинет после смены пароля»
Выход: account
Пример 3:
Вход: «Приложение вылетает при загрузке фото»
Выход: technical
Задача:
Вход: «Хочу удалить свой аккаунт и все данные»
Выход:Сколько примеров нужно
Единого правила нет. Эмпирические наблюдения:
- 2–3 примера достаточно для простых задач классификации.
- 5–8 примеров полезны, когда границы между классами размыты.
- Больше 10 примеров редко дают прирост, но расходуют контекстное окно.
Важно: примеры должны быть репрезентативными. Если все примеры одного класса, модель будет смещена в его сторону.
Zero-shot vs few-shot
Zero-shot — это запрос без примеров. Для простых задач («переведи на английский», «суммируй текст») zero-shot работает не хуже. Few-shot оправдан, когда модель стабильно ошибается без примеров или когда формат ответа нестандартный.
Chain-of-Thought (CoT): рассуждение вслух
Техника заключается в том, чтобы попросить модель рассуждать пошагово перед тем, как дать финальный ответ. Впервые описана в работе Wei et al. (2022) и с тех пор стала стандартным приёмом для задач, требующих логики.
Как применять
Достаточно добавить в промпт фразу вроде:
Код:
Рассуждай пошагово, прежде чем дать окончательный ответ.Или в few-shot формате показать пример рассуждения:
Код:
Вопрос: В магазине 23 яблока. Продали 7, привезли ещё 12. Сколько осталось?
Рассуждение: Было 23. Продали 7 → 23 - 7 = 16. Привезли 12 → 16 + 12 = 28.
Ответ: 28.Когда CoT помогает, а когда мешает
| Тип задачи | Эффект CoT |
|---|---|
| Арифметика, логика, многошаговые рассуждения | Значительный прирост точности |
| Простая классификация, извлечение фактов | Минимальный эффект или замедление |
| Генерация текста, перевод | Может добавить лишний «шум» в ответ |
| Задачи с жёстким форматом вывода | Требует отдельной инструкции «после рассуждения дай ответ в формате X» |
Ограничения CoT
- Модель может «рассуждать» убедительно, но прийти к неверному выводу. Пошаговое рассуждение не гарантирует корректность.
- Увеличивает длину ответа и расход токенов.
- Для моделей с обучением на цепочках рассуждений (reasoning models) явный CoT-промпт может быть избыточным — они и так рассуждают внутренне.
Структурирование контекста: порядок и разделители
Порядок информации имеет значение
Модели лучше «помнят» начало и конец контекста (эффект, известный как lost in the middle). Практические следствия:
- Самые важные инструкции ставьте в начало системного промпта или в самый конец пользовательского сообщения.
- Длинный справочный материал лучше размещать в середине, а ключевой вопрос — после него.
Разделители и теги
Когда в промпт подаётся внешний текст (документ, код, данные), отделяйте его явными маркерами:
Код:
Проанализируй текст, заключённый в тройные кавычки.
"""
{текст документа}
"""
Ответь на вопрос: {вопрос}Это снижает риск того, что модель перепутает инструкцию с данными. В качестве разделителей используют тройные кавычки, XML-теги (
<context>...</context>), Markdown-заголовки или любые последовательности, которые не встречаются в самих данных.Техника «роль + задача + формат + ограничения»
Компактный шаблон, который покрывает большинство рабочих сценариев:
Код:
Роль: Ты — инженер по надёжности (SRE).
Задача: Проанализируй лог ошибки и предложи три гипотезы причины.
Формат: Нумерованный список, каждая гипотеза — одно предложение + команда для проверки.
Ограничения: Не предполагай доступ к продакшену. Если данных недостаточно — укажи, что нужно собрать.Такая структура работает как чек-лист: если модель «ушла» от задачи, обычно достаточно проверить, какой из четырёх элементов пропал или размыт.
Итеративная отладка промптов
Промпт — это код. Его нужно тестировать и рефакторить.
Практический цикл
- Зафиксируйте входные данные. Возьмите 5–10 реальных примеров, на которых модель сейчас ошибается.
- Сформулируйте гипотезу. Почему ошибка происходит: не хватает контекста, неоднозначная формулировка, нет примера формата?
- Внесите одно изменение. Не меняйте всё сразу — иначе не поймёте, что помогло.
- Прогоните на тех же примерах. Сравните до и после.
- Зафиксируйте результат. Если стало лучше — сохраняйте версию. Если хуже — откатывайте.
Типичные ошибки при отладке
- Переобучение на один пример. Промпт, идеально работающий на одном кейсе, ломается на остальных.
- Накопление инструкций. Каждая итерация добавляет новое правило, и через 10 итераций промпт становится противоречивым.
- Игнорирование температуры. При
temperature=0модель детерминированна (насколько это возможно для данной реализации). Если результат «плавает», проблема может быть не в промпте, а в настройках сэмплирования.
Что НЕ работает или работает нестабильно
- «Дыши глубже» / «Это очень важно для моей карьеры». Эмоциональные манипуляции не имеют устойчивого эффекта на качество. В некоторых бенчмарках наблюдался незначительный прирост, но он не воспроизводится стабильно.
- Повторение инструкции много раз. Один раз в системном промпте достаточно. Многократное повторение расходует токены и может создать конфликт приоритетов.
- Просьба «не галлюцинировать». Модель не имеет внутреннего механизма проверки истинности. Лучше просить: «Если не уверен, скажи, что не знаешь» — и подкреплять это примерами.
- Слишком сложные цепочки в одном промпте. Если задача разбивается на 5+ последовательных шагов, лучше разбить на несколько вызовов (pipeline), чем пытаться уместить всё в один запрос.
Влияние параметров генерации на результат промпта
Даже идеальный промпт может дать плохой результат при неверных параметрах:
| Параметр | Низкое значение | Высокое значение |
|---|---|---|
temperature | Детерминированный, повторяющийся вывод | Креативный, но может «уходить» от задачи |
top_p | Модель рассматривает только наиболее вероятные токены | Учитывает более широкий спектр вариантов |
max_tokens | Ответ может обрезаться | Избыточно большой лимит не вредит, но увеличивает стоимость |
stop | Позволяет остановить генерацию на нужном маркере | — |
Для задач с жёстким форматом (JSON, код, классификация) обычно используют
temperature в диапазоне 0–0.3. Для креативных задач — 0.7–1.0.Как проверить, что промпт работает
- A/B на фиксированном наборе. Прогоните старый и новый промпт на одних и тех же 10–20 примерах. Сравните вручную или метрикой.
- Граничные случаи. Пустой вход, очень длинный вход, вход на другом языке, вход с инъекцией инструкций.
- Стабильность. Запустите один и тот же запрос 5 раз при
temperature > 0. Если ответы сильно расходятся — промпт недостаточно конкретен.
- Стоимость. Посчитайте токены. Иногда упрощение промпта даёт тот же результат за половину цены.
Краткий чек-лист перед отправкой промпта в продакшен
- Системный промпт содержит роль, формат и ограничения.
- Примеры (если есть) репрезентативны и покрывают граничные классы.
- Внешние данные отделены от инструкций разделителями.
- Ключевая инструкция находится в начале или в конце контекста.
- Параметры
temperatureиmax_tokensподобраны под задачу.
- Промпт протестирован на 10+ реальных примерах, включая негативные кейсы.
- Есть план действий, если модель откажется отвечать или вернёт невалидный формат.