Вы пишете запрос, ждёте секунду — и получаете именно то, что нужно. Структура, тон, формат, детали — всё совпало. Это не магия, а результат понимания того, как модель «думает».
Тот же запрос с незначительной правкой — и модель галлюцинирует факты, игнорирует ограничения или пишет в стиле корпоративного меморандума вместо живого текста.
Разница не в модели. Разница в промте.
Из чего состоит работающий промт
1. Роль (Role)
Кем должна «стать» модель. Задаёт экспертизу, лексику, глубину рассуждений. Пример: «Ты — технический писатель с 10-летним опытом документирования API».
2. Задача (Task)
Чёткое описание желаемого результата. Что именно сделать, а что не делать. Плохо: «Напиши про промты». Хорошо: «Разбери 5 структур промта с примерами кода».
3. Контекст (Context)
Входные данные, ограничения, аудитория, примеры. Всё, что модель не знает сама. Может включать RAG-документы, историю диалога, глоссарий.
4. Формат (Format)
Структура ответа: JSON, Markdown, таблица, список, код, определённая схема. Жёсткое указание формата экономит парсинг и пост-обработку.
5. Ограничения (Constraints)
Длина, тон, запрещённые слова, обязательные элементы, правила безопасности. «Не используй пассивный залог», «Максимум 3 предложения на абзац».
Техники, которые меняют качество ответа
Few-shot prompting
Даёте 2–5 пар «вход → идеальный выход». Модель улавливает паттерн формата, стиля, логики. Лучше работает, чем любые инструкции.
Пример → Пример → Ваш запросRAG / Context stuffing
Помещаете релевантные документы в промт. Модель отвечает на основе ваших данных, а не обучающей выборки. Критично для фактуры, актуальности, приватности.
Документы + Вопрос → ОтветRole-playing / Persona
Назначаете модель в образ: эксперт, критик, собеседник, персона. Меняет лексику, глубину, точку зрения. «Ты — sceptical code reviewer, найди баги».
Persona + Task → Styled outputSelf-consistency
Запускаете один промт несколько раз при температуре >0, берёте самый частый ответ (majority vote). Снижает случайные ошибки на сложных задачах.
N runs → Vote → ConsensusTree of Thoughts
Модель генерирует несколько веток рассуждения, оценивает их, отсекает тупиковые, развивает перспективные. Для задач планирования, творчества, стратегии.
Branch → Evaluate → Prune → SolveГотовые паттерны: копируйте, адаптируйте, комбинируйте
Что портит результат: типичные ловушки
Слишком много инструкций сразу
Модель теряет фокус, игнорирует второстепенные пункты, смешивает приоритеты. Разбивайте на цепочку промтов: один — одна задача.
Неявные предположения о контексте
«Напиши письмо клиенту» — модель не знает: какой клиент, какая проблема, какой тон бренда, какая история. Контекст — не лишнее, это топливо.
Отсутствие формата выхода
Без явного формата модель выбирает свой (часто — простой текст). Укажите JSON-схему, Markdown-разметку, заголовки, запретите лишнее.
Температура 0.7 «по умолчанию»
Для извлечения фактов, кода, структурированных данных — temperature 0 или 0.1. Креативные задачи — 0.7–0.9. Параметр решает детерминизм.
Игнорирование system prompt
System prompt задаёт правила игры глобально. User prompt — конкретный ход. Не дублируйте роль в каждом user-сообщении, настройте system один раз.
Нет цикла «промт → оценка → правка»
Промт — это код. Он требует отладки. Запустите, проверьте на 10–20 кейсах, найдите паттерны ошибок, поправьте инструкции. Итерации дают качество.
Параметры генерации: что крутить и зачем
TTemperature
- 0.0–0.2: код, извлечение фактов, классификация, JSON
- 0.3–0.5: аналитика, суммаризация, переписывание
- 0.6–0.8: копирайтинг, идеи, диалоги, мозговые штурмы
- 0.9–1.0: поэзия, нестандартные решения, игра
PTop-p (nucleus)
Модель рассматривает только токены, суммарная вероятность которых не превышает p. Альтернатива temperature, часто даёт более предсказуемый «хвост».
- 0.1–0.3: фактические задачи, строгая схема
- 0.5–0.9: баланс разнообразия и качества
- Часто комбинируют с temperature
MMax tokens / Stop sequences
```
Совет: Для JSON всегда ставьте stop на «}» или закрывающий тег массива — гарантирует валидность.
Как довести промт до стабильного результата
Напишите «черновик промта»
Не ищите идеальную формулировку. Опишите задачу так, будто объясняете стажёру. Включите роль, цель, пример входа и выхода.
Запустите на 5–10 тест-кейсах
Разнообразные входы: типичные, граничные, сложные, с шумом. Сохраняйте пары вход-выход. Ищите системные ошибки, а не единичные промахи.
Классифицируйте ошибки
Не 따른 формат? Упустил ограничение? Галлюцинировал факт? Не тот тон? Каждой категории — своё лечение: добавить пример, уточнить constraint, дать контекст, снизить temperature.
Итерируйте промт, а не регенерируйте
Правьте инструкции, добавляйте few-shot, уточняйте формат. После каждой правки — прогон на тех же тест-кейсах. Фиксируйте дельту качества. Останавливайтесь, когда ошибок < 5%.
Подходы к промтингу: от простого к системному
1Zero-shot
Только инструкция, без примеров. Работает для простых, хорошо представленных в обучении задач: суммаризация, перевод, базовая классификация.
2Few-shot
2–5 примеров в контексте. Учит формат, стиль, неявные правила. Главный драйвер качества на структурированных задачах. Стоимость — токены контекста.
3System + Structured Prompting
Роль, правила, формат — в system prompt. Динамические данные — в user. Промт становится шаблоном с переменными. Масштабируется, версионируется, тестируется как код.
Чек-лист перед отправкой в продакшн
Структура
- Роль задана явно и уместна
- Задача сформулирована как инструкция, а не пожелание
- Контекст содержит всё необходимое, ничего лишнего
- Формат выхода описан схемой/примером
- Ограничения охватывают длину, тон, запреты
Качество
- Протестировано на 10+ репрезентативных кейсах
- Нет системных паттернов ошибок
- Edge cases обработаны (пустой ввод, шум, несоответствие схеме)
- Temperature и top-p подобраны под задачу
- Stop sequences предотвращают обрезку/мусор
Операционка
- System prompt вынесен в конфиг/версионирование
- Шаблон user prompt параметризован (переменные)
- Есть логирование: промт, параметры, ответ, латентность
- Настроен мониторинг качества (автооценка / human eval)
- Есть процедура отката на прошлую версию промта