Промпт-инжиниринг

Промпт-инжиниринг (prompt engineering) — практика постановки задачи языковой модели так, чтобы ответ был предсказуемым и пригодным для дальнейшей работы. Вокруг темы много мистики про «волшебные фразы», но на практике решает не заклинание, а та же дисциплина, что при постановке задачи человеку: понятная цель, нужный контекст, заданный формат и критерии приёмки.

Разница с человеком в двух вещах. Модель не задаст уточняющий вопрос, если ей не разрешить, — она просто достроит недостающее сама. И она не помнит прошлый раз: всё, что нужно для ответа, должно быть в запросе.

Из чего состоит рабочий промпт?

• Роль и задача. Кто отвечает и что именно должен сделать. «Ты редактор, сокращаешь текст до 800 знаков, сохраняя все числа».
• Контекст. Материалы, на которые опираться, и границы: чего в ответе быть не должно.
• Формат ответа. Самый недооценённый пункт. Если ответ пойдёт в код, просите JSON с описанием полей. Если человеку — задайте структуру и длину.
• Критерии. Как отличить хороший ответ от плохого. Это же станет чек-листом при оценке.
• Примеры. Один-три образца «вход → правильный выход». Дают наибольший прирост качества на единицу усилий, особенно в задачах разметки и извлечения.
• Разрешение не знать. Явное «если данных недостаточно, напиши „недостаточно данных“ и перечисли, чего не хватает» — единственный способ получать отказ вместо выдумки.

Пример с числами

Задача: извлечь из 500 писем клиентов сумму сделки и срок. Первый промпт — «Найди в письме сумму и срок». Второй — с ролью, JSON-форматом, двумя примерами и разрешением вернуть null.

Обратите внимание, где произошёл главный скачок. Точность извлечения выросла умеренно — с 81% до 94%. А вот доля ответов, которые вообще удалось разобрать программно, подскочила с 64% до 99%, потому что во втором случае был задан жёсткий формат. В промышленных сценариях именно формат, а не «умность» промпта, определяет, работает конвейер или разваливается.

Какие приёмы реально работают?

• Примеры (few-shot). Показать два-три правильных разбора эффективнее, чем описывать правила словами.
• Пошаговое рассуждение. Просьба сначала разобрать задачу по шагам, а потом дать ответ, заметно помогает на логике и расчётах. У reasoning-моделей это встроено, и отдельная просьба им не нужна.
• Разделение ролей. Инструкция в системном сообщении, данные — в пользовательском. Так данные не воспринимаются как новые указания.
• Явные ограничения. «Не более 5 пунктов», «только из приведённого списка», «не добавляй вступление» — работают надёжнее вежливых просьб.
• Разбиение на шаги. Два простых вызова почти всегда стабильнее одного сложного, где модель должна сделать пять вещей сразу.

Где чаще всего ошибаются?

• Вежливость вместо конкретики. «Пожалуйста, постарайся хорошо» не несёт информации. «Максимум 3 предложения, без вводных» — несёт.
• Не задан формат. Свободный текст нельзя разобрать программно, и конвейер ломается на первой сотне записей.
• Всё в одном вызове. Извлечь, проверить, перевести и отформатировать за один раз — модель сделает часть работы хуже.
• Данные вперемешку с инструкцией. Если в тексте клиента написано «игнорируй предыдущие указания», модель может это исполнить. Данные нужно отделять и помечать.
• Нет замера. Без контрольного набора невозможно понять, улучшил промпт или ухудшил.

Связанные термины

• LLM — как устроена модель, которой адресован промпт.
• RAG — как подкладывать в промпт нужные документы автоматически.