Глава 8. Промптинг

Учебник «Большие языковые модели»

Третью часть учебника — о применении — мы начинаем с самого доступного инструмента: текста запроса. Хорошо сформулированный промпт часто заметно улучшает результат без обучения модели, хотя его разработка, контекст и дополнительные токены тоже имеют цену. Промптинг оброс мифологией («секретные волшебные фразы»), но в основе его лежат понятные вещи, прямо следующие из устройства модели, которое мы разобрали в первых двух частях. Отделим механику от фольклора.

8.1. Почему это вообще работает

Вспомним, чем является промпт для модели: началом последовательности, которую она продолжает наиболее правдоподобным (после пост-обучения — наиболее «полезным») образом. Отсюда первый принцип: промпт задаёт распределение. Всё, что в нём есть, — формулировки, примеры, стиль, даже тон — сдвигает вероятности продолжения. Расплывчатый запрос оставляет больше допустимых продолжений; точный лучше задаёт критерии, но сам по себе не гарантирует узкого распределения или верного ответа. Способность модели перенимать задачу из нескольких примеров прямо в контексте (in-context learning) была убедительно продемонстрирована в большом масштабе в работе о GPT-3 (Браун и др., 2020) — и весь промптинг, по существу, эксплуатация этого свойства.

8.2. Системный промпт

Многие диалоговые API размечают сообщения ролями и задают иерархию инструкций. Названия и приоритеты ролей — часть контракта провайдера: это могут быть system, developer, user и другие уровни. Модели пост-обучены (глава 5) следовать этой разметке, но она не является защитой от всех конфликтов и инъекций. В высокоприоритетную инструкцию кладут постоянное: кто такой ассистент, предметная область, правила и запреты, формат ответов, тон. В пользовательские сообщения — переменное: конкретные запросы и данные. Это разделение полезно и экономически: стабильный системный промпт — идеальный кандидат на кэширование (глава 7).

Три полезные исходные гипотезы для системного промпта. Первая: конкретность вместо заклинаний — «Ты опытный редактор ИТ-издания; проверяй терминологию, а неуверенность помечай [?]» работает, а «Ты самый лучший в мире редактор» обычно не задаёт проверяемого критерия. Вторая: описывайте желаемое поведение прямо — «пиши короткими абзацами» легче проверить, чем общий запрет «не пиши плохо»; точный запрет всё же нужен, если он существен. Третья: устраняйте противоречия и проверяйте длинный набор правил на контрольных примерах. Универсального предела длины нет.

8.3. Структура запроса

Модель читает промпт как единый поток токенов, поэтому явная разметка частей резко снижает риск перепутать инструкцию с данными. Хорошо работают XML-подобные теги (модели много видели их при обучении):

Ты редактор новостной ленты ИТ-портала.

<задача>
Определи, описывают ли две заметки одно и то же событие.
Ответь строго одним словом: ДА, НЕТ или НЕЯСНО.
</задача>

<заметка_1>
{текст первой заметки}
</заметка_1>

<заметка_2>
{текст второй заметки}
</заметка_2>

Заодно теги защищают от случайной «инъекции»: если внутри заметки встретится фраза, похожая на инструкцию, разметка помогает модели понять, что это данные (полноценной защитой это не является — глава 15). Порядок частей стоит выбирать по эксперименту из главы 7; стабильные части обычно ставят раньше переменных ради кэша, а критичные инструкции при необходимости кратко напоминают возле вопроса.

8.4. Примеры: few-shot

Несколько примеров «вход → правильный выход» часто улучшают качество и наглядно задают формат, но могут внести смещение или ухудшить результат. Правила отбора: примеры должны покрывать разнообразие реальных входов, включая граничные случаи (пустой вход, мусор, спорный случай); ошибки в примерах фатальны — модель может скопировать именно их; для классификации важен и баланс меток — если все примеры с ответом ДА, модель сдвинется к ДА. Типичное практическое число определяется тестами: добавляйте примеры, пока прирост на отложенной выборке оправдывает токены и задержку.

8.5. Сложные задачи и проверяемые промежуточные результаты

Для некоторых обычных, не reasoning-моделей просьба показать промежуточные шаги или few-shot-примеры с объяснениями улучшает многошаговые задачи — это классический результат о цепочках рассуждений (Вэй и др., 2022). Но показанное рассуждение не обязано быть достоверным протоколом внутреннего вычисления: убедительное объяснение может сопровождать неверный ответ.

Для современных reasoning-моделей рекомендации иные. Например, руководство OpenAI советует формулировать задачу просто и прямо и не добавлять инструкцию «думай по шагам»: модель уже распределяет вычислительный бюджет сама, а такая подсказка способна помешать. Поэтому сначала следуйте документации конкретной модели и сравнивайте варианты на eval-наборе.

Приложению обычно полезнее запрашивать не скрытую цепочку мыслей, а проверяемые артефакты: итоговый ответ, краткое обоснование, вычисленные значения, цитаты на предоставленные источники, тесты или вызов калькулятора. Сложную задачу можно разбить на этапы с явными входами, критериями успеха и внешней проверкой каждого результата.

8.6. Типичные ошибки

Неявный контекст. «Поправь этот конфиг» без указания, что считать поломкой. Модель получает только явно переданный контекст: текст, изображение или результат инструмента, если API их поддерживает; остальной экран и намерения пользователя ей недоступны.

Две задачи в одной. «Переведи и заодно сократи и оцени качество» — смешение задач может размыть критерии. Отдельные этапы легче наблюдать и проверять, но увеличивают задержку, цену и накопление ошибок; сравните оба варианта на тестах.

Вопрос с подсказкой. «Ведь правда, вариант А лучше?» — пост-обученные модели услужливы (глава 5) и охотно соглашаются. Формулируйте нейтрально: «Сравни варианты А и Б по критериям…»

Вера в самоотчёт. Спросить модель «почему ты так ответила?» — значит получить правдоподобную реконструкцию, а не протокол вычислений; модель не имеет доступа к собственным весам и активациям. Самоотчёты полезны как гипотезы, но не как диагностика.

Игнорирование «не знаю». Если задача допускает отсутствие ответа, у модели должен быть законный выход: «если данных недостаточно, ответь НЕИЗВЕСТНО». Иначе вы сами загоняете её в галлюцинацию (глава 6): сэмплер обязан что-то выбрать.

8.7. Промпт как артефакт разработки

В работающей системе промпт — такой же артефакт, как код, и заслуживает той же дисциплины. Версионирование: промпты живут в git, а не в теле скрипта россыпью f-строк; вынос в отдельный модуль или файлы шаблонов делает изменения обозримыми (и совместимыми с кэшированием). Тестирование: набор контрольных входов с ожидаемыми выходами, прогоняемый при каждом изменении промпта и при каждой смене модели — поведение от модели к модели дрейфует, и «улучшение» промпта на трёх примерах регулярно оказывается ухудшением на тридцати. Систематически об этом — в главе 13. Наблюдаемость: сохраняйте идентификатор версии промпта, модели и параметры вызова. Сырые промпты и ответы могут содержать персональные данные, секреты и документы, поэтому их логирование требует минимизации, редактирования чувствительных полей, контроля доступа и срока хранения.

Хорошие сводки практических приёмов ведут сами вендоры — см. руководства по промптингу Anthropic и OpenAI; они регулярно обновляются под текущие поколения моделей.

8.8. Итоги

Промптинг — не заклинания, а явный контракт задачи: иерархия инструкций задаётся API, разметка помогает отделять инструкции от данных, примеры показывают формат и граничные случаи, а законный ответ «не знаю» снижает давление выдумать ответ. Для сложных задач запрашивайте проверяемые артефакты и учитывайте рекомендации конкретной модели. Промпты надо версионировать и тестировать, а телеметрию — собирать с учётом приватности.

В следующей главе спустимся на уровень ниже — к вызовам API: потоковая генерация, структурированный вывод, вызов функций, повторы и батчи.

Упражнения

1. Возьмите свою реальную задачу классификации текстов и напишите к ней промпт трижды: без примеров, с тремя примерами, с шестью (включая граничные). Прогоните на 20 контрольных входах и сравните точность.

2. Сформулируйте один и тот же вопрос нейтрально и с подсказкой («ведь правда…?»). Сколько из десяти прогонов модель соглашается с подсказкой в каждом варианте?

3. Найдите в своём рабочем промпте отрицательные инструкции («не делай…») и переформулируйте их положительно. Изменилось ли соблюдение?