Промпт-инжиниринг обсуждают как искусство формулировок и набор приёмов. В рабочей системе он выглядит иначе: промпт — это часть кода, у которого есть версии, тесты и цена ошибки.
Отличий от работы в чате три, и они меняют всё:
Промпт один на тысячи запросов. В чате вы переформулируете, если не получилось. В конвейере промпт применяется к потоку и должен работать на всём разнообразии входов, включая нестандартные.
Результат читает программа. Формат важнее красоты.
Правка может сломать то, что работало. Улучшение одного класса случаев регулярно ухудшает другой, и без прогона это обнаруживается в эксплуатации.
Отсюда главный тезис: без набора проверочных случаев промпт-инжиниринг превращается в перебор наугад — «Тестирование модели на своей задаче».
Про промпт-инжиниринг как профессию и работу с моделью вручную есть отдельный разбор: «Какие задачи выполняют промпт-инженеры» и «Контекстная инженерия».
Что действительно влияет
По убыванию отдачи в моей практике.
1. Примеры
Самое действенное. Два-три реальных примера «вход — правильный выход» дают больше, чем страница описаний.
Требования: примеры должны быть реальными, покрывать разные случаи, включая трудный, и быть согласованными между собой. Противоречивые примеры хуже их отсутствия.
2. Точная постановка задачи
Не «извлеки важное», а перечень: что именно, в каком виде, что делать при отсутствии.
Самое частое улучшение здесь — явно описать, что делать в неоднозначной ситуации. Модель, которой не сказали, как поступать при нехватке данных, придумает — «Почему нейросеть выдумывает».
3. Схема вместо описания формата
Передача схемы надёжнее любых просьб в тексте — «Структурированный вывод модели».
4. Разбиение задачи
Одна задача — один запрос. Промпт, требующий одновременно классифицировать, извлечь данные и написать ответ, работает хуже трёх отдельных.
Дороже по числу обращений, заметно надёжнее по результату. Часто компенсируется тем, что простые шаги уходят на дешёвую модель.
5. Разрешение отказаться
Явное «если данных нет, верни такое-то значение». Резко снижает выдумывание. Работает только если в схеме ответа для этого есть место.
6. Порядок изложения
Инструкция в начале, данные после. На длинных входах положение важного текста влияет на результат: середина длинного контекста используется хуже краёв.
Что обычно не работает
Приёмы, которые повторяют из статьи в статью, а на измерениях они не подтверждаются.
Вежливость и «пожалуйста». Влияния на качество не обнаруживается.
Угрозы и обещания вознаграждения. «Это очень важно для моей карьеры» — фольклор.
Назначение роли ради роли. «Ты опытный юрист» само по себе даёт мало. Работает не роль, а конкретизация задачи и критериев, которую в неё иногда вкладывают.
Длинные описания стиля. Пример показывает стиль лучше, чем абзац о нём.
Требование «думай шаг за шагом» везде. На задачах, где рассуждение не нужно — классификация, извлечение полей, — оно удлиняет ответ, удорожает обращение и иногда ухудшает результат. На сложных задачах помогает, у современных моделей часто встроено.
Заглавные буквы и восклицательные знаки для важных требований.
Оговорка, которая здесь обязательна: «не работает» означает «в моих измерениях на бизнес-задачах прироста не видно». Модели различаются, и правильный ответ всегда один — проверить на своём наборе.
Устройство промпта в системе
Что стоит разделять:
| Часть | Меняется | Где хранить |
|---|---|---|
| Роль и общие правила | редко | в шаблоне |
| Описание задачи | при изменении требований | в шаблоне |
| Схема ответа | при изменении конвейера | в коде, вместе со схемой |
| Примеры | при обнаружении провалов | отдельно, чтобы менять без правки шаблона |
| Данные | каждый запрос | подставляются |
Разделение позволяет менять примеры, не трогая логику, и вести версии — «Версионирование промптов».
Разбор: как улучшали промпт по измерениям
Задача. Классификация обращений, точность на контрольном наборе — 71%. Требовалось выше.
Что пробовали и что получилось.
| Изменение | Результат |
|---|---|
| Добавили роль «ты опытный оператор поддержки» | без изменений |
| Развернули описания категорий | +3 п.п. |
| Добавили 5 реальных примеров, по одному на спорную категорию | +11 п.п. |
| Добавили «думай шаг за шагом» | −2 п.п., ответы длиннее |
| Перешли на схему с перечислением категорий | +4 п.п., нарушения формата исчезли |
| Разрешили категорию «не определено» | +2 п.п. по верным, доля ошибок упала заметнее |
| Разбили на два шага: сначала крупная категория, потом подкатегория | +5 п.п. |
Итог: 71% → 89% без смены модели.
Что дало основной вклад. Примеры и разбиение задачи. Оба приёма скучные и не выглядят как «инженерия промптов».
Что не сработало. Роль — совсем. «Думай шаг за шагом» — ухудшило: задача не требует рассуждения, а требование его породило, и модель начала находить обоснования для неверных категорий.
Что оказалось неожиданным. Разрешение отвечать «не определено» подняло точность незначительно, но резко снизило долю уверенных ошибок. Раньше модель выбирала ближайшую категорию из имеющихся; теперь спорные случаи уходили человеку. Для процесса это было важнее, чем прирост точности.
Что стоит забрать. Без набора проверочных случаев половина этих изменений выглядела бы улучшениями. Два из семи ухудшили результат, и обнаружить это можно было только измерением.
Правила работы с промптами в системе
- Одно изменение за раз. Иначе непонятно, что сработало.
- Прогон набора после каждого изменения. Ухудшившее — откатить.
- Проверять на классах случаев, а не в среднем. Улучшение одного класса часто ломает другой.
- Хранить историю. Что меняли, какой был результат — «Версионирование промптов».
- Не переносить промпты между моделями без проверки — «Миграция между моделями».
- Следить за длиной. Промпт растёт от правок и передаётся при каждом обращении — «Длина контекста и стоимость».
Частые вопросы
Что реально влияет на качество промпта?
Больше всего — реальные примеры «вход — правильный выход», точная постановка задачи с описанием неоднозначных ситуаций, передача схемы ответа вместо описания формата словами и разбиение сложной задачи на отдельные запросы. Эти приёмы скучны и дают основной прирост.
Работают ли приёмы вроде назначения роли или «думай шаг за шагом»?
Роль сама по себе в моих измерениях прироста не даёт: работает не она, а конкретизация задачи, которую в неё иногда вкладывают. Требование рассуждать помогает на сложных задачах и вредит на простых — удлиняет ответ и иногда порождает обоснования для неверных выводов. Проверять надо на своём наборе.
Почему нельзя просто подобрать промпт на глаз?
Потому что улучшение одного класса случаев регулярно ухудшает другой, и на глаз это незаметно: вы смотрите на несколько примеров, а система работает на потоке. Без набора проверочных случаев правки превращаются в перебор с непредсказуемым результатом.
Сколько примеров добавлять в промпт?
Обычно двух-пяти достаточно, и важнее их качество: реальные, покрывающие разные случаи, включая трудный, и не противоречащие друг другу. Больше примеров удлиняет промпт, который передаётся при каждом обращении, и прирост быстро выходит на плато.
Нужно ли переписывать промпты при смене модели?
Как правило да: формулировка, отточенная под одну модель, на другой обычно работает хуже. Разумный порядок — прогнать набор со старыми промптами, чтобы увидеть исходную точку, и подстраивать там, где просело.
Где хранить промпты?
Отдельно от кода, с версиями и привязкой к результатам на проверочном наборе. Промпт — это часть системы, которая меняется чаще всего, и без истории изменений через полгода неизвестно, почему он выглядит именно так и что будет, если что-то убрать.
Что дальше
Как измерять эффект правок — «Тестирование модели на своей задаче». Как хранить и выкатывать — «Версионирование промптов». Надёжный формат ответа — «Структурированный вывод модели». Когда правки промпта исчерпаны — «LoRA и QLoRA».
Отладка промптов по измерениям — часть работы по разработке и внедрению ИИ и автоматизации процессов.