Prompt Engineering

Ключевые принципы

Язык: английский по умолчанию. Русский — если явно указано или данные на русском.

High-signal токены: Каждый токен промпта должен нести информацию. Attention budget модели конечен — тратить его на сигнал, не на шум. Избегать воды, повторений, очевидных вещей которые модель и так знает.

Goldilocks zone (правильная высота): Промпт между двумя крайностями:

• Слишком низко: хардкод логики, if-else правила на каждый кейс → хрупкость, сложная поддержка
• Слишком высоко: размытые указания, ложное предположение общего контекста → модель не понимает что делать

Оптимум: достаточно специфично для направления поведения, достаточно гибко для применения эвристик в непокрытых кейсах.

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

Структура промпта

Форматирование: Markdown + XML

• Markdown — форматирование текста (списки, bold, italic)
• XML теги — семантическое разделение блоков

XML теги двусторонние (<tag>...</tag>), что предотвращает смешивание секций.

Выбор тегов

Теги подбираются под задачу. Имя тега отражает семантику содержимого.

Примеры (не обязательный набор):

• <background> — контекст, ситуация, предпосылки
• <task> — что нужно сделать
• <constraints> — ограничения
• <examples> — few-shot примеры
• <output_format> — формат ответа
• <domain_knowledge> — специфичные знания домена
• <evaluation_criteria> — критерии оценки

Секция role (опционально)

Роль полезна, когда нужна конкретная точка зрения:

• Эксперт в домене
• Критик/ревьюер
• Пользователь системы

Не нужна, если <background> уже даёт достаточный контекст.

Понимание вместо инструкций

Объяснять как и почему, не только что.

Вместо:

Отвечай кратко.

Лучше:

Целевая аудитория — занятые специалисты.
Им нужен быстрый ответ, не погружение в детали.

Когда модель понимает контекст и причины, она лучше справляется с ситуациями, не покрытыми явными инструкциями.

Итеративный подход

Промпт разрабатывается итеративно, не пишется сразу "идеальным":

1. Начать минимально — базовый промпт с задачей и ключевым контекстом
2. Тестировать на лучшей модели — увидеть baseline поведения
3. Добавлять по failure modes — инструкции и примеры появляются когда модель ошибается в конкретных кейсах
4. Не over-engineer заранее — не предугадывать проблемы, решать реальные

Антипаттерны

Хардкоды без требований

Не указывать конкретные числа (длина, количество), если заказчик не требовал.

Плохо:

Напиши описание продукта (3-5 предложений)

Хорошо:

Напиши описание продукта

Нерелевантные инструкции

Не добавлять:

• Ограничения, не относящиеся к задаче
• "Защитные" формулировки без реальной угрозы

Примеры: laundry list edge cases

Не пихать в <examples> список всех возможных edge cases. Вместо этого — курировать diverse, canonical examples, которые демонстрируют ожидаемое поведение.

Примеры — "картинки worth a thousand words". Несколько хороших примеров эффективнее десятка правил.

Примеры иллюстрируют паттерн и подход, а не хардкодят единственно верные значения.

Чеклист

• Каждый токен несёт сигнал (нет воды, повторений, очевидностей)
• Промпт в Goldilocks zone (не хардкод, не размытость)
• Вытекающие из задачи требования включены
• Нет нерелевантных ограничений
• Теги подобраны под семантику содержимого
• Есть объяснение "почему", не только "что"
• Примеры diverse и canonical, не laundry list edge cases