Bbar0n234 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> уже даёт достаточный контекст.
Понимание вместо инструкций
Объяснять как и почему, не только что.
Вместо:
Отвечай кратко.
Лучше:
Целевая аудитория — занятые специалисты.
Им нужен быстрый ответ, не погружение в детали.
Когда модель понимает контекст и причины, она лучше справляется с ситуациями, не покрытыми явными инструкциями.
Итеративный подход
Промпт разрабатывается итеративно, не пишется сразу "идеальным":
- Начать минимально — базовый промпт с задачей и ключевым контекстом
- Тестировать на лучшей модели — увидеть baseline поведения
- Добавлять по failure modes — инструкции и примеры появляются когда модель ошибается в конкретных кейсах
- Не 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