Промт для LLM: анатомия идеального запроса и паттерны, которые работают

Промт для LLM: анатомия идеального запроса

Почему одна и та же модель выдаёт гениальный ответ или бессмыслицу — и как собрать запрос, который работает предсказуемо.

Структура промта Техники: CoT, few-shot, RAG Паттерны и шаблоны Ошибки и отладка

Вы пишете запрос, ждёте секунду — и получаете именно то, что нужно. Структура, тон, формат, детали — всё совпало. Это не магия, а результат понимания того, как модель «думает».

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

Разница не в модели. Разница в промте.

Input
Role: Senior UX-редактор
Task: Переписать текст под лонгрид
Constraints: 1500–3000 слов, никаких штампов, только конкретика
Format: JSON с полями title, content, image_prompt
Output
{ "title": "...", "content": "...", "image_prompt": "..." }

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

1. Роль (Role)

Кем должна «стать» модель. Задаёт экспертизу, лексику, глубину рассуждений. Пример: «Ты — технический писатель с 10-летним опытом документирования API».

2. Задача (Task)

Чёткое описание желаемого результата. Что именно сделать, а что не делать. Плохо: «Напиши про промты». Хорошо: «Разбери 5 структур промта с примерами кода».

3. Контекст (Context)

Входные данные, ограничения, аудитория, примеры. Всё, что модель не знает сама. Может включать RAG-документы, историю диалога, глоссарий.

4. Формат (Format)

Структура ответа: JSON, Markdown, таблица, список, код, определённая схема. Жёсткое указание формата экономит парсинг и пост-обработку.

5. Ограничения (Constraints)

Длина, тон, запрещённые слова, обязательные элементы, правила безопасности. «Не используй пассивный залог», «Максимум 3 предложения на абзац».

Условная схема: ключевые компоненты промта и их взаимодействие. Не все блоки нужны всегда — подберите под задачу.

Техники, которые меняют качество ответа

Ключевая техника

Chain-of-Thought (CoT)

Заставьте модель рассуждать пошагово перед ответом. Добавьте «Размышляй пошагово» или опишите алгоритм рассуждения явно. Работает на задачах логики, кода, математики, сложного анализа.

Шаблон вставки:

"Before answering, break down the problem
into clear reasoning steps. Show your
work, then give the final answer."

Few-shot prompting

Даёте 2–5 пар «вход → идеальный выход». Модель улавливает паттерн формата, стиля, логики. Лучше работает, чем любые инструкции.

Пример → Пример → Ваш запрос

RAG / Context stuffing

Помещаете релевантные документы в промт. Модель отвечает на основе ваших данных, а не обучающей выборки. Критично для фактуры, актуальности, приватности.

Документы + Вопрос → Ответ

Role-playing / Persona

Назначаете модель в образ: эксперт, критик, собеседник, персона. Меняет лексику, глубину, точку зрения. «Ты — sceptical code reviewer, найди баги».

Persona + Task → Styled output

Self-consistency

Запускаете один промт несколько раз при температуре >0, берёте самый частый ответ (majority vote). Снижает случайные ошибки на сложных задачах.

N runs → Vote → Consensus

Tree of Thoughts

Модель генерирует несколько веток рассуждения, оценивает их, отсекает тупиковые, развивает перспективные. Для задач планирования, творчества, стратегии.

Branch → Evaluate → Prune → Solve

Готовые паттерны: копируйте, адаптируйте, комбинируйте

Универсальная структура (RTCF)
# ROLE
You are a [expert role] with [years] years of experience in [domain].

# TASK
[Clear, specific instruction].
Deliverable: [what exactly].

# CONTEXT
Audience: [who reads this]
Background: [key facts, constraints]
References: [docs, examples, style guide]

# FORMAT
Output as [JSON / Markdown / Table / Code].
Schema: [exact structure]

# CONSTRAINTS
- Length: [words/tokens]
- Tone: [professional/conversational/technical]
- Avoid: [words, patterns, assumptions]
- Must include: [required elements]
Few-shot для структурированного извлечения
Extract entities from text as JSON.
Schema: {entities: [{type, value, confidence}]}
Types: PERSON, ORG, DATE, MONEY, PRODUCT

# Example 1
Input: "Apple Inc. announced iPhone 15
on September 12, 2023 for $799."
Output: {
  "entities": [
    {"type": "ORG", "value": "Apple Inc.", "confidence": 0.99},
    {"type": "PRODUCT", "value": "iPhone 15", "confidence": 0.98},
    {"type": "DATE", "value": "September 12, 2023", "confidence": 0.97},
    {"type": "MONEY", "value": "$799", "confidence": 0.95}
  ]
}

# Example 2
Input: "Dr. Sarah Chen joined Google
DeepMind in January 2024."
Output: {
  "entities": [
    {"type": "PERSON", "value": "Dr. Sarah Chen", "confidence": 0.96},
    {"type": "ORG", "value": "Google DeepMind", "confidence": 0.98},
    {"type": "DATE", "value": "January 2024", "confidence": 0.94}
  ]
}

# Your Input
Input: "{{YOUR_TEXT_HERE}}"
Output:
Chain-of-Thought для сложного анализа
# ROLE
You are a senior strategy consultant.

# TASK
Analyze the business situation and recommend
top 3 strategic options with pros/cons.

# REASONING PROCESS
Work through these steps explicitly:
1. SITUATION: Summarize key facts, constraints,
   stakeholders, market dynamics.
2. PROBLEM DEFINITION: What is the core
   strategic question? Frame as a choice.
3. OPTION GENERATION: List 5+ distinct
   strategic paths (not variations of one).
4. CRITERIA: Define 4-5 evaluation criteria
   (e.g., revenue upside, risk, fit, speed).
5. SCORING: Score each option 1-5 on each
   criterion with brief justification.
6. SYNTHESIS: Pick top 3, articulate trade-offs.

# FORMAT
Output as Markdown with sections matching
steps 1-6, then a final "Recommendation"
section with the top 3 in a comparison table.

# CONTEXT
{{BUSINESS_CONTEXT_DOCUMENT}}

Что портит результат: типичные ловушки

Слишком много инструкций сразу

Модель теряет фокус, игнорирует второстепенные пункты, смешивает приоритеты. Разбивайте на цепочку промтов: один — одна задача.

Неявные предположения о контексте

«Напиши письмо клиенту» — модель не знает: какой клиент, какая проблема, какой тон бренда, какая история. Контекст — не лишнее, это топливо.

Отсутствие формата выхода

Без явного формата модель выбирает свой (часто — простой текст). Укажите 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 — детерминизм1.0 — креативность
\n
  • 0.0–0.2: код, извлечение фактов, классификация, JSON
  • 0.3–0.5: аналитика, суммаризация, переписывание
  • 0.6–0.8: копирайтинг, идеи, диалоги, мозговые штурмы
  • 0.9–1.0: поэзия, нестандартные решения, игра

PTop-p (nucleus)

0.1 — строгий отбор1.0 — весь словарь

Модель рассматривает только токены, суммарная вероятность которых не превышает p. Альтернатива temperature, часто даёт более предсказуемый «хвост».

  • 0.1–0.3: фактические задачи, строгая схема
  • 0.5–0.9: баланс разнообразия и качества
  • Часто комбинируют с temperature

MMax tokens / Stop sequences

Max tokens
Жёсткий лимит длины ответа. Защита от «бесконечных» генераций и контроля стоимости.
Stop sequences
Строки, при появлении которых генерация останавливается. «
```

Совет: Для JSON всегда ставьте stop на «}» или закрывающий тег массива — гарантирует валидность.

Как довести промт до стабильного результата

1

Напишите «черновик промта»

Не ищите идеальную формулировку. Опишите задачу так, будто объясняете стажёру. Включите роль, цель, пример входа и выхода.

2

Запустите на 5–10 тест-кейсах

Разнообразные входы: типичные, граничные, сложные, с шумом. Сохраняйте пары вход-выход. Ищите системные ошибки, а не единичные промахи.

3

Классифицируйте ошибки

Не 따른 формат? Упустил ограничение? Галлюцинировал факт? Не тот тон? Каждой категории — своё лечение: добавить пример, уточнить constraint, дать контекст, снизить temperature.

4

Итерируйте промт, а не регенерируйте

Правьте инструкции, добавляйте few-shot, уточняйте формат. После каждой правки — прогон на тех же тест-кейсах. Фиксируйте дельту качества. Останавливайтесь, когда ошибок < 5%.

Подходы к промтингу: от простого к системному

1Zero-shot

Только инструкция, без примеров. Работает для простых, хорошо представленных в обучении задач: суммаризация, перевод, базовая классификация.

Когда достаточно
Задача стандартная, модель видела миллионы подобных примеров при обучении.

2Few-shot

2–5 примеров в контексте. Учит формат, стиль, неявные правила. Главный драйвер качества на структурированных задачах. Стоимость — токены контекста.

Золотое правило
Примеры должны покрывать разнообразие случаев, а не дублировать один паттерн.

3System + Structured Prompting

Роль, правила, формат — в system prompt. Динамические данные — в user. Промт становится шаблоном с переменными. Масштабируется, версионируется, тестируется как код.

Для продакшена
Отдельно храните system prompt, шаблоны user prompt, параметры генерации. CI/CD для промтов.

Чек-лист перед отправкой в продакшн

Структура

  • Роль задана явно и уместна
  • Задача сформулирована как инструкция, а не пожелание
  • Контекст содержит всё необходимое, ничего лишнего
  • Формат выхода описан схемой/примером
  • Ограничения охватывают длину, тон, запреты

Качество

  • Протестировано на 10+ репрезентативных кейсах
  • Нет системных паттернов ошибок
  • Edge cases обработаны (пустой ввод, шум, несоответствие схеме)
  • Temperature и top-p подобраны под задачу
  • Stop sequences предотвращают обрезку/мусор

Операционка

  • System prompt вынесен в конфиг/версионирование
  • Шаблон user prompt параметризован (переменные)
  • Есть логирование: промт, параметры, ответ, латентность
  • Настроен мониторинг качества (автооценка / human eval)
  • Есть процедура отката на прошлую версию промта

Промт — это не вопрос модели. Промт — это спецификация задачи для вероятностного движка.

Чем точнее спецификация, тем предсказуемее результат.

Итерации промта — это обычный инженерный процесс. Пишите, тестируйте, měрьте, правьте. Качество растёт не от вдохновения, а от цикла обратной связи.