Форматирование промптов
Полный курс: как структурировать промпт, подавать данные, описывать правила и контролировать формат ответа.
1. Организация промпта
- 1.1 Markdown-разметка
- 1.2 Разделители (--- === ###)
- 1.3 Заголовки и иерархия
- 1.4 КАПС и акценты
- 1.5 ASCII-рамки
- 1.6 Глоссарий
- 1.7 Таблицы (+40% точности)
- 1.8 Токенное разделение данных
2. Подача данных
- 2.1 XML-теги и семантика
- 2.2 Маркировка источников
- 2.3 System-2 Counting
- 2.4 Визуальные маркеры
- 2.5 JSON-структурирование
3. Описание правил
- YAML-конфиги
- TOML-секции
- Псевдокод IF/ELSE
- SWITCH/CASE
- MetaGlyph нотация
- Иерархия правил 🔴🟡🟢
- Prompt Decorators
4. Контроль формата ответа
- Плейсхолдеры [...] и {...}
- JSON-схема + типы
- TypeScript типизация
- Markdown-таблицы
- Лестница контроля
- Схема-Примеры-Задача
- Бэктики для кода
- Self-check
5. Лексика и синтаксис
- Наречия > прилагательные
- Синтаксис команды (императив vs вопрос)
- Полнота формулировки
- Конкретные примеры vs абстрактные
- Запреты и негативные примеры
- Эмоции вредят точности
- Слова-триггеры рассуждений
- Точность слов (синонимы ≠)
- Уверенность = ловушка
- Prefix-затравка
- Инверсия задачи
6. Few-shot примеры
- Формат примера > содержание
- Один качественный > много
- Порядок: последний = главный
- Контрастные пары (+ и −)
- Разнообразие форматов
- CoT в примерах: когда нужен
- Согласованность инструкция=пример
- Фрагменты вместо целых
- Роли вместо меток
7. Лайфхаки
- Chain-of-Thought: классика
- Когда CoT вредит
- Магические фразы
- Ставки на ответ
- U-кривая длины промпта
- Ответственность и последствия
- Простые лайфхаки
Не знаешь с чего начать? Начни здесь
Дерево выбора техники + шпаргалка "копируй сразу"
| Хочу... | Техника | Копируй |
|---|---|---|
| Разделить блоки промпта | Разделители | --- |
| Показать пример | Стрелка | Вход: X → Выход: Y |
| Изолировать данные от инструкций | XML-контейнер | <data>...</data> |
| Дать несколько примеров | Few-shot | === разделяет примеры |
| Табличные данные | Пайпы | | Col1 | Col2 | |
| Условную логику | Псевдокод | IF условие: → действие |
| Критичный запрет | КАПС в секции | ### КРИТИЧНО |
| Строгий формат ответа | JSON-схема | {"field": "type"} |
| Проверку перед выводом | Self-check | □ пункт проверки |
| Роль модели | XML-тег | <role>...</role> |
## Задача [что нужно сделать] --- ## Данные <input> [данные для обработки] </input> --- ## Правила - правило 1 - правило 2 --- ## Формат ответа [как должен выглядеть результат]
## Примеры (=== разделяет примеры) Вход: [пример 1 вход] → Выход: [пример 1 выход] === Вход: [пример 2 вход] → Выход: [пример 2 выход] --- ## Теперь обработай: [реальные данные]
<self_check> Перед отправкой проверь: □ [требование 1]? □ [требование 2]? □ [требование 3]? Если хоть один пункт НЕ выполнен — исправь ДО отправки. </self_check>
Роль: копирайтер Тон: дружелюбный/деловой/нейтральный Длина: ~500 символов Язык: русский Формат: JSON
ключ: значение — простая альтернатива YAML для параметров
опция1/опция2/опция3 — выбор из вариантов (слэш)
"точный текст" — кавычки для литералов (модель не изменит)
Простая задача (напиши текст, переведи) → минимум форматирования
Сложная задача (классификация с правилами, анализ данных) → полная структура
Чем больше типов информации в промпте (данные + примеры + правила + ограничения), тем важнее структура.
Организация промпта
Как структурировать сам текст промпта
"Форматирование — это не украшение. Это инструкции для внимания модели."
| Элемент | Синтаксис | Результат | Когда использовать |
|---|---|---|---|
| Жирный | **текст** |
текст | Ключевые термины, акценты |
| Курсив | *текст* |
текст | Примечания, названия |
| Код в строке | `код` |
код |
Переменные, команды, значения |
| Список | - пункт или • пункт |
• пункт | Перечисление требований |
| Нумерация | 1. шаг |
1. шаг | Последовательность действий |
| Цитата | > текст |
текст | Примеры, выдержки из документов |
Проанализируй **тональность** отзыва.
Возможные значения: `positive`, `negative`, `neutral`.
Критерии оценки:
- Наличие эмоциональных слов
- Общий контекст высказывания
- Явные оценочные суждения
> Пример отзыва: "Товар пришёл быстро, но упаковка была мятая"
Верни результат в формате `{"sentiment": "значение"}`
Используй `бэктики` для всего, что является значением, переменной или командой — модель воспринимает это как "техническое".
Структурированные промпты позволяют слабым моделям достигать уровня сильных. Форматирование важнее содержания — хорошо оформленный промпт компенсирует разницу между моделями.
✅ Надёжные разделители
| Разделитель | Когда | Пример контекста |
|---|---|---|
--- |
Между логическими блоками | Роль --- Задача --- Правила |
=== |
Между примерами (few-shot) | === Пример 1 === Пример 2 === |
### |
Секция с заголовком | ### Правила обработки |
*** |
Смысловой перелом | Конец инструкций *** Начало данных |
│ (pipe) |
Разбиение для подсчёта | System-2 Counting |
◆◆◆ |
Системные инструкции | Защита от prompt injection |
❌ Избегай этих разделителей
| Разделитель | Проблема |
|---|---|
~~~~ |
Путается с markdown code blocks (~~~) |
____ |
Визуально сливается, слабый сигнал |
.... |
Воспринимается как продолжение текста ("и так далее...") |
//// |
Путается с комментариями в коде |
| Только пустые строки | Слабый сигнал, может игнорироваться в длинных промптах |
Если используешь разделитель, СКАЖИ об этом. Одна строка описания стабилизирует точность — модель перестаёт угадывать где границы (исследование 2510.05152)
## Формат данных в этом промпте
- Примеры разделены символами "==="
- Секции разделены горизонтальной линией "---"
- Данные пользователя обёрнуты в тройные кавычки """
- Код обёрнут в тройные бэктики ```
---
## Примеры
===
Вход: "Отличный товар!"
Выход: {"sentiment": "positive"}
===
Вход: "Ужасное качество"
Выход: {"sentiment": "negative"}
===
---
## Задача
Обработай данные пользователя:
"""
Нормально, но дорого
"""
Без визуальных разделителей между секциями модель теряет 16-24% точности. HTML-формат лучше для поиска конкретных данных, plain text — для логических фильтров.
Разделители токенов (пробелы, запятые между элементами) драматически улучшают точность на аналитических задачах. Модель лучше "считает" когда элементы визуально разделены.
Ролевые разделители <USER:> и [INST] — мощный инструмент управления поведением модели. Используй их для чёткого разграничения ролей в диалоге.
Тонкая настройка форматирующих элементов (тип разделителя, нумерация, отступы) стабилизирует выход модели. Одни и те же инструкции с разным форматированием дают разброс до 30% — консистентность разделителей критична.
Модели экстремально чувствительны к типу разделителя. Замена одного символа (- на &) обрушила точность с 81% до 10%. Выбрал разделитель — используй его везде одинаково.
"Три дефиса стоят ноль токенов, но дают +24% точности."
Где использовать стрелку
| Контекст | Пример |
|---|---|
| Few-shot примеры | "не работает оплата" → Billing, high |
| Правила приоритета | premium → всегда high |
| Трансформация | Сырой текст → Структурированный промпт |
| Псевдокод | IF условие: → действие |
| Лестница выбора | Простая задача → минимум форматирования |
Пример: "оплата не работает" Категория: Billing Приоритет: high
"оплата не работает" → Billing, high
## Примеры "Не работает оплата картой" → Категория: Billing → Приоритет: high → Причина: упоминание оплаты === "Приложение вылетает при запуске" → Категория: Technical → Приоритет: medium → Причина: баг/ошибка
Стрелка → — визуально отделяет вход от выхода. Модель сразу понимает: слева что анализировать, справа что вывести.
Альтернативы: =>, -->, : — но Unicode-стрелка → самая читаемая.
"Стрелка → превращает пример в формулу: вход → выход."
| Уровень | Синтаксис | Назначение | Сколько на промпт |
|---|---|---|---|
# |
# Название промпта |
Главная тема / заголовок | 0-1 |
## |
## Роль, ## Задача |
Основные секции | 3-7 |
### |
### Критично |
Подсекции внутри блока | По необходимости |
# Генератор карточек товаров ## Роль Копирайтер маркетплейса с 5-летним опытом. --- ## Задача Напиши описание товара для Wildberries. --- ## Правила ### 🔴 Критично • Длина: 500-700 символов • Без слов "лучший", "уникальный" ### 🟡 Важно • Добавь 3-5 буллетов с характеристиками • Emoji: максимум 3 ### 🟢 Желательно • Упомяни материал и размеры
5-компонентная структура (Context, Constraints, Criteria, Cues, Chain) достигает лучшего качества с меньшим количеством токенов. Иерархия = экономия.
Если выделить всё — ничего не выделено. Используй КАПС только для ОДНОГО критичного запрета на промпт.
ВСЕГДА пиши НА РУССКОМ.
ОБЯЗАТЕЛЬНО добавь CTA.
НЕ ПРЕВЫШАЙ 500 символов.
• Добавь призыв к действию
• Длина: до 500 символов
• НИКОГДА не используй слово "уникальный"
Любой лишний "шум" в промпте (нерелевантный контекст, избыточное форматирование) снижает точность рассуждений. Когда ВСЁ написано КАПСОМ — модель не может выделить главное, и эффект пропадает. КАПС работает только как единичный акцент на фоне обычного текста.
Первые слова промпта работают как мощный "якорь" — определяют, как модель интерпретирует всё остальное. Если ставишь КАПС-акцент — размещай в начале или конце, не в середине. Информация в середине длинного контекста теряется (2505.21828, rating 88).
Когда запрещаешь конкретное слово — бери его в кавычки:
❌ Не используй слово уникальный — модель может интерпретировать по-разному
✅ Не используй слово "уникальный" — модель понимает: это ТОЧНОЕ значение
Кавычки работают как маркер литерала — то, что внутри, не изменяется.
Символы для рамок (копируй)
╔ ╗ ╚ ╝ ═ ║ ╠ ╣ ╦ ╩ ╬
┌ ┐ └ ┘ ─ │ ├ ┤ ┬ ┴ ┼
┏ ┓ ┗ ┛ ━ ┃ ┣ ┫ ┳ ┻ ╋
╔══════════════════════════════════════╗ ║ [ЗАГОЛОВОК] ║ ╠══════════════════════════════════════╣ ║ • [пункт 1] ║ ║ • [пункт 2] ║ ╚══════════════════════════════════════╝
Визуальное выделение критичных блоков (рамки, таблицы) снижает галлюцинации и повышает надёжность следования инструкциям. Рамка = "не игнорировать!"
## ГЛОССАРИЙ H1 = главный заголовок H2 = подзаголовок USP = уникальное торговое предложение CTA = призыв к действию (call to action) TA = целевая аудитория TOV = тон голоса (tone of voice) WB = Wildberries OZ = Ozon --- ## Задача Напиши H1 + USP + 3 варианта CTA для TA "молодые мамы 25-35". Платформа: WB. TOV: дружелюбный, без сленга.
Недоспецификация — главный источник ошибок. Глоссарий в начале промпта устраняет двусмысленность терминов и снижает вариативность ответов.
Когда данные имеют структуру "объект — свойства", таблица всегда лучше списка. Модель точнее связывает условия с сущностями.
Вот данные о сервисах: | Сервис | Цена ($) | Качество | Семейный доступ | |----------|----------|----------|-----------------| | Netflix | 16 | 4K HDR | Да | | Hulu | 12 | 1080p | Да | | Disney+ | 18 | 4K HDR | Нет | | HBO Max | 15 | 4K HDR | Да | --- Найди сервисы где: • Цена ≤ $15 • Есть семейный доступ • Качество 4K
Когда использовать таблицы
| Ситуация | Формат | Почему |
|---|---|---|
| Сравнение объектов по параметрам | Таблица | Строка = объект, столбец = свойство |
| Фильтрация по нескольким условиям | Таблица | Точное сопоставление условий |
| Последовательность шагов | Список | Важен порядок, не параметры |
| Неструктурированный текст | Prose | Нет чёткой структуры |
Таблица устраняет лингвистическую неоднозначность ("у кого какое свойство"). Строка = одна сущность, столбец = один атрибут. Attention-механизм точнее связывает условия.
|, переносы строк (исследование 2505.14178, rating 95)LLM работает с токенами, а не с отдельными символами. Когда элементы "склеиваются" в один токен (например, strawberry), модель не видит отдельные буквы. Решение: принудительно разделяй элементы пробелами, запятыми или переносами.
Символы разделения и когда их использовать
| Символ | Пример | Когда использовать |
|---|---|---|
, запятая |
a, b, c, d |
Списки элементов, перечисления |
| пайп |
имя | возраст | город |
Табличные данные, поля записи |
\n перенос |
Каждый элемент на новой строке | Длинные списки, структурированные данные |
--- линия |
Блок 1 --- Блок 2 |
Разграничение смысловых секций |
пробел |
s t r a w b e r r y |
Посимвольный анализ (подсчёт букв) |
Проанализируй: яблоко,груша,банан,апельсинТокенизатор может склеить несколько слов → потеря элементов
Проанализируй:
- яблоко
- груша
- банан
- апельсинКаждый элемент — отдельный токен → точный подсчёт
## Данные клиентов Иван | 25 | Москва | premium Мария | 32 | СПб | basic Алексей | 28 | Казань | premium --- Найди всех premium-клиентов младше 30 лет.
Каждый элемент, с которым должна работать модель, должен быть отдельным токеном. Используй | для полей, --- для секций, переносы строк для списков. Это кардинально повышает точность анализа.
Приведи все числа к единому формату перед подачей в промпт:
- Для высокой точности: научная нотация
+3.14e+02вместо314 - Для простых задач: убери разделители —
1250вместо1,250.00 - Добавь в промпт: "Все числовые значения приведены к формату [описание]"
Когда важно: финансовые данные, аналитика, логи — везде, где числа в разных форматах.
Удаление разделителей между документами/блоками данных значительно снижает точность. Даже простой --- или пустая строка между блоками — критичны. Без них модель путает границы контекстов и смешивает информацию из разных источников.
Динамическая адаптация разделителей под задачу даёт надёжность 98%+. Принцип: не один фиксированный разделитель на все случаи, а выбор подходящего (| для таблиц, --- для секций, === для примеров) — улучшает следование инструкциям.
Подача данных
Как передать модели информацию для обработки
"Теги — не разметка. Это КОМАНДЫ для внимания модели."
"XML-тег — это не разметка. Это команда: 'обрати внимание именно на ЭТО'."
Зачем нужны XML-теги
XML-теги создают чёткие границы между разными типами информации. Модель сразу видит: где контекст, где задача, где правила.
Ты маркетолог. У меня интернет-магазин обуви. Напиши пост для Instagram. Не больше 200 слов. Тон дружелюбный. Целевая аудитория — женщины 25-35. Добавь призыв к действию в конце.
Где заканчивается описание роли? Где начинаются правила? Модель угадывает.
<role>Ты маркетолог</role> <context>У меня интернет-магазин обуви</context> <task>Напиши пост для Instagram</task> <rules> • Не больше 200 слов • Тон дружелюбный • Целевая аудитория — женщины 25-35 • Добавь призыв к действию в конце </rules>
Каждый блок изолирован. Модель точно знает, что где.
Базовые теги — с них начинай
<context> Фоновая информация, ситуация, данные для анализа </context>
Что модель должна учитывать
<task> Конкретное действие: что именно сделать </task>
Ядро любого промпта
<rules> • Ограничение 1 • Ограничение 2 • Формат вывода </rules>
Границы и требования
<context> + <task> + <rules> — этого достаточно для 80% задач. Остальные теги добавляй по необходимости.
Технически работают оба варианта — XML поддерживает кириллицу. Но английские теги предпочтительнее:
- Модели обучены на англоязычном коде —
<context>распознаётся как "родной" токен - Экономия токенов:
context= 1 токен,контекст= 2-3 токена - Стандарт индустрии — все гайды и примеры на английском
<context> Компания продаёт мебель </context> <task> Напиши описание дивана </task>
<контекст> Компания продаёт мебель </контекст> <задача> Напиши описание дивана </задача>
Сводная таблица XML-тегов
| Компонент | Основной тег | Альтернативы | Когда использовать |
|---|---|---|---|
| Роль | <role> |
<persona>, <assistant> |
Всегда в начале промпта |
| Контекст | <context> |
<background>, <situation> |
Когда нужна фоновая информация |
| Задача | <task> |
<objective>, <goal> |
Обязательно — ядро промпта |
| Правила | <rules> |
<constraints>, <requirements> |
Ограничения и критерии качества |
| Вывод | <output> |
<format>, <response> |
Когда важен формат ответа |
| Пример | <example> |
<sample>, <demo> |
Сложные форматы, few-shot |
| Данные | <input> |
<data>, <content> |
Входные данные для обработки |
| Документ | <document> |
<doc>, <source> |
Цитируемые источники |
1. Модульность = стабильность (2505.13546, rating 90): Разделение на независимые блоки Role/Task/Context делает промпт устойчивым к изменениям. Можно менять один блок, не ломая остальные.
2. Снижение когнитивной нагрузки (2509.08090): Модель не тратит "внимание" на парсинг — структура уже очевидна. Результат: меньше галлюцинаций, точнее следование инструкциям.
3. Эффект "якоря" (2504.01216, rating 96): Теги <role> и <task> в начале промпта создают когнитивный якорь — модель возвращается к ним при генерации.
Вложенные XML-теги
Теги можно вкладывать друг в друга — это создаёт иерархию информации. Особенно полезно для сложных данных.
<document>
<metadata>
<title>Отчёт Q3 2024</title>
<author>Аналитический отдел</author>
<date>2024-10-15</date>
</metadata>
<content>
Выручка выросла на 15%...
</content>
</document>
<rules>
<content_rules>
• Только факты из источника
• Без предположений
</content_rules>
<format_rules>
• Абзацы до 3 предложений
• Заголовки для каждой темы
</format_rules>
<style_rules>
• Тон: деловой
• Без сленга и эмодзи
</style_rules>
</rules>
<examples>
<example type="positive">
Вход: "Это отличный продукт!"
→ Выход: sentiment: positive, score: 0.9
</example>
<example type="negative">
Вход: "Полное разочарование"
→ Выход: sentiment: negative, score: 0.85
</example>
<example type="neutral">
Вход: "Доставили вовремя"
→ Выход: sentiment: neutral, score: 0.7
</example>
</examples>
Используй: когда данные имеют естественную иерархию (документ→разделы, товар→характеристики, правила→категории).
Не перебарщивай: 2-3 уровня вложенности достаточно. Глубже — модель может запутаться.
Атрибуты тегов
| Атрибут | Назначение | Пример |
|---|---|---|
source="..." |
Указать источник данных | <context source="McKinsey 2024"> |
id="..." |
Маркировка для атрибуции | <doc id="report_q3"> |
lang="..." |
Язык содержимого | <text lang="en"> |
do_not_copy_language="true" |
Защита от языкового дрейфа | <en_source do_not_copy_language="true"> |
<documents> <doc id="1" source="Forbes 2024" lang="en"> Apple reported $394B revenue in 2024, marking a 5% increase from the previous year. The services segment grew 12%. </doc> <doc id="2" source="Reuters 2024" lang="en"> Samsung's smartphone market share declined to 19% in Q4, while Apple maintained 23% global share. </doc> <doc id="3" source="Analyst Report" lang="ru"> Маржинальность Apple Services достигла 70%, что делает сегмент ключевым драйвером прибыли. </doc> </documents> --- ## Инструкция Сравни компании. При цитировании укажи источник: [doc id=N]
id="N" — для ссылок на конкретный источник в ответе
source="..." — модель видит откуда данные, может оценить достоверность
lang="..." — помогает при мультиязычном анализе
Результат: модель может писать "[doc id=2] показывает, что..." — точная атрибуция.
8-секционный шаблон (Role → Context → Task → Steps → Output → Example → Clarification → Answer) сокращает количество итераций с 13 до 1.5. Эффект: модель сразу понимает, что от неё хотят.
Role + Task + Output + Example повышает точность с 86% до 98% на структурированных задачах.
Универсальный XML-шаблон промпта
<role> Ты — [специализация]. Твоя задача — [основная функция]. </role> <context> [Фоновая информация, ситуация, ограничения] </context> <task> [Конкретное задание: что именно нужно сделать] </task> <rules> • [Ограничение 1] • [Ограничение 2] • [Формат ответа] </rules> <output> [Ожидаемая структура вывода] </output> <example> Вход: [пример входных данных] Выход: [пример правильного ответа] </example>
Минималистичная альтернатива для задач без требований к стилю/тону:
<role>Ты — [специализация]</role> <task>[Чёткая формулировка задачи]</task> <rules> - Правило 1 - Правило 2 </rules> <format>[Ожидаемый формат вывода]</format> <errors>Типичные ошибки, которых избегать</errors>
РОЛЬ → ЗАДАЧА → ПРАВИЛА → ФОРМАТ → ОШИБКИ — 5 компонентов достаточно для большинства задач. Секция <errors> особенно полезна для задач классификации и извлечения данных.
Продвинутые техники
Когда базовых тегов недостаточно — используй продвинутые паттерны.
Namespace — группировка по типам
Проблема: когда промпт содержит 5-10+ тегов, они начинают "сливаться". Модель видит плоский список — <article>, <comments>, <content>, <format> — и не понимает, какие из них входные данные, какие правила, а какие описывают формат вывода.
Решение: префикс перед двоеточием создаёт пространство имён (namespace). Он группирует теги по функции: input: = входные данные, rules: = ограничения, output: = формат ответа. Модель сразу видит иерархию: "это всё входы, это всё правила".
Почему работает: namespace — это тот же принцип, что и папки на диске. Файл report.txt может быть в трёх местах: input/report.txt, drafts/report.txt, output/report.txt — и у каждого разная роль. Модели обучены на коде с namespace-паттернами (XML, Python modules, CSS), поэтому распознают их нативно.
<input:article>
Текст статьи для анализа...
</input:article>
<input:comments>
Комментарии пользователей...
</input:comments>
---
<rules:content>
• Используй ТОЛЬКО факты из input:article
• Не добавляй внешнюю информацию
</rules:content>
---
<output:format>
JSON: {"summary": "...", "facts": [...]}
</output:format>
Используй когда в промпте 5+ тегов и они могут пересекаться по смыслу. Частые ситуации:
- Multi-agent:
agent1:analysis,agent2:analysis— разные источники, одинаковый тип данных - Разные системы:
crm:customer,support:ticket— данные из разных БД - Версии:
v1:spec,v2:spec— сравнение версий документа
Не используй если тегов 3-4 и они все разные — обычных <context>, <task>, <rules> достаточно.
Готовые пары тегов для типовых задач
<draft>черновик</draft> <revision>правки</revision> <final>финал</final>
<problem>проблема</problem> <analysis>анализ</analysis> <solution>решение</solution>
<original>исходник</original> <critique>критика</critique> <improved>улучшено</improved>
7 обязательных компонентов: Context → Objective → Style → Tone → Audience → Response → Answer. Используй когда важен не только результат, но и как он подан (тон, стиль, аудитория).
Частые ошибки с XML-тегами
<xyz>, <aaa>, <block1> — модель их игнорирует. Работают только семантические теги с понятным названием: <context>, <draft>, <solution>
Каждый открывающий тег <tag> должен иметь закрывающий </tag>. Незакрытые теги ломают структуру и модель может неправильно интерпретировать границы блоков.
3+ уровня вложенности усложняют понимание. Если нужна сложная структура — лучше использовать JSON внутри одного тега, чем 5 уровней XML.
<doc id="petrov" author="Иван Петров" source="Интервью Forbes 2024"> "Рынок AI вырастет в 3 раза к 2027 году. Мы видим экспоненциальный рост." </doc> <doc id="sidorova" author="Мария Сидорова" source="Аналитика РБК"> "Не стоит переоценивать темпы роста AI. Есть ограничения инфраструктуры." </doc> --- ## Правила атрибуции При цитировании ОБЯЗАТЕЛЬНО указывай [doc_id]. Формат: "цитата" — [автор, источник] НИКОГДА не приписывай слова из одного документа автору другого.
Context Grounding (заземление)
Чтобы модель не выдумывала — ограничь её источником:
<context source="Отчёт Q3 2024"> [текст документа] </context> --- ПРАВИЛА: • Используй ТОЛЬКО информацию из <context> • Не добавляй внешние знания • Если информации нет в контексте — напиши: "Данные отсутствуют в документе" • При цитировании указывай: [из context]
Чтобы модель строго следовала документу: сначала заставь процитировать релевантный отрывок, потом — дать ответ на его основе. Двухэтапный подход снижает галлюцинации.
Структурированная подача внешнего контекста (RAG) даёт 98% точности даже на узких темах. При этом RAG-системы эффективнее ручного копирования всего текста в промпт.
Явное указание источников в структурированном формате повышает точность на 10-30%. Модель точнее атрибутирует информацию когда документы явно пронумерованы и ограничены маркерами.
[DOCUMENT 1 OF 3] текст первого документа [END DOCUMENT 1] [DOCUMENT 2 OF 3] текст второго документа [END DOCUMENT 2] [DOCUMENT 3 OF 3] текст третьего документа [END DOCUMENT 3]
Шаблон [DOCUMENT N OF M]...[END DOCUMENT N] явно сообщает модели общее количество источников и границы каждого.
У трансформеров нет "переменной-счётчика". Информация размазана по слоям. До 10 — точно. 15-20 — ошибки. 30+ — почти ноль точности.
| Сила модели | Точный подсчёт до | Рекомендуемый размер части |
|---|---|---|
| Слабая (7B параметров) | ~8 элементов | 5-7 |
| Средняя (13B-70B) | ~12 элементов | 8-10 |
| Сильная (GPT-4, Claude) | ~15 элементов | 10-12 |
Текст ниже разбит на части символом │ Инструкция: 1. Посчитай количество слова "типа" В КАЖДОЙ ЧАСТИ отдельно 2. Запиши промежуточные результаты 3. Суммируй в конце Формат ответа: Часть 1: [число] Часть 2: [число] Часть 3: [число] --- Итого: [сумма] Текст: [первые 10 предложений] │ [следующие 10] │ [следующие 10]
Вывод промежуточных результатов ТЕКСТОМ обязателен. Без этого модель не сможет корректно суммировать — она должна "увидеть" числа в своём же ответе.
Техника разбиения на части через разделитель │ научно валидирована. Вместо подсчёта 50 элементов сразу (где модель сбивается), делите на куски по 5-10 элементов — модель считает отдельно, потом суммирует.
Метод вставки счётчика прямо в процесс генерации. После каждого предложения модель видит: <использовано_слов=87> — и корректирует вывод, чтобы попасть в лимит.
Исследования подтверждают принцип:
- Чёткие категории повышают точность (2507.08250, rating 82) — модель лучше анализирует, когда задан фиксированный набор категорий
- Принудительный выбор стабилизирует результат (2410.16325, rating 95) — формат "распредели по категориям" даёт воспроизводимые ответы
- Модульные секции улучшают качество (2505.13546, rating 90) — структурированные промпты с раздельными блоками более надёжны
- Визуальные разделители помогают (2506.05739, rating 96) — любые чёткие границы между секциями улучшают следование инструкциям
Прямых исследований о влиянии эмодзи на качество ответов LLM в базе не найдено. Техника работает за счёт категоризации, а не самих иконок.
Почему экстраполяция обоснована:
- Эмодзи создают визуально различимые заголовки категорий
- Каждая категория становится отдельной "секцией" для анализа
- Принцип "ответь по каждому пункту" работает независимо от того, чем маркированы пункты
Альтернативы эмодзи: ### РИСКИ, [РИСКИ], **РИСКИ:** — любой визуальный маркер категории.
Проанализируй бизнес-план. Структурируй ответ: 💡 ИННОВАЦИИ — что нового и ценного 🚩 РИСКИ — что может пойти не так ⚠️ НЕОДНОЗНАЧНОСТИ — требует уточнения ✅ СИЛЬНЫЕ СТОРОНЫ — что уже работает ❌ СЛАБЫЕ СТОРОНЫ — что переделать 🎯 РЕКОМЕНДАЦИИ — следующие шаги
⚡ Производительность
🔒 Безопасность
📖 Читаемость
♻️ Рефакторинг
😰 Weaknesses
🌟 Opportunities
⚠️ Threats
💬 Цитаты
📊 Статистика
🔗 Источники
Исследования подтверждают:
- Соседство связанных фактов (2504.07087, rating 95) — JSON группирует атрибуты объекта рядом, а не разбрасывает по тексту
- +точность на длинных текстах (2410.10813, rating 94) — JSON-структура + инструкция "извлеки → ответь" улучшает работу с большим контекстом
- Полнота извлечения данных (2506.02589, rating 92) — JSON-формат повышает recall (полноту) при извлечении сущностей
- Think-of-Structure (2502.18878, rating 90) — метод ToS: сначала модель "думает" о структуре, потом генерирует
Часть 2 (здесь): JSON для ПОДАЧИ данных в промпт — контекст, факты, параметры.
Часть 4 (раздел 4.2): JSON-схема для КОНТРОЛЯ формата ответа модели.
Проанализируй клиента. Имя: Алексей Иванов, возраст 34 года, город Москва, должность Senior Developer в компании TechCorp, зарплата 350000 рублей, женат, двое детей, интересы: горные лыжи и программирование, последняя покупка была 15 января — MacBook Pro за 250000 рублей, до этого покупал iPhone...
Проанализируй клиента:
```json
{
"profile": {
"name": "Алексей Иванов",
"age": 34,
"city": "Москва"
},
"work": {
"position": "Senior Developer",
"company": "TechCorp",
"salary_rub": 350000
},
"family": {
"status": "married",
"children": 2
},
"interests": ["горные лыжи", "программирование"],
"purchases": [
{"date": "2026-01-15", "item": "MacBook Pro", "price": 250000},
{"date": "2025-11-20", "item": "iPhone 16", "price": 120000}
]
}
```
Определи: сегмент клиента, потенциальные upsell-продукты,
оптимальное время для контакта.
• Вложенные структуры (объект в объекте)
• Списки однотипных элементов
• Данные из API/БД
• Типы данных очевидны
• Легко парсить программно
• Связанные поля рядом
• XML — для вложенного текста
• Markdown-таблицы — для плоских списков
• CSV — для табличных данных
Исследование 2508.11454 (rating 87): Добавление референсных данных в JSON (средние по рынку, бенчмарки, исторические значения) позволяет модели делать более точные сравнительные выводы.
{
"current": {"revenue": 1200000, "margin": 15},
"benchmarks": {
"industry_avg": {"revenue": 800000, "margin": 12},
"top_10_percent": {"revenue": 2500000, "margin": 22}
},
"history": [
{"year": 2024, "revenue": 900000, "margin": 11},
{"year": 2025, "revenue": 1100000, "margin": 14}
]
}
Сколько примеров давать?
| Количество | Когда использовать | Пример задачи |
|---|---|---|
| 0 (zero-shot) | Простые задачи, модель уже знает формат | "Переведи текст на английский" |
| 1-2 | Показать специфичный формат вывода | "Извлеки данные в JSON" |
| 3-5 | Сложная классификация, edge cases | "Классифицируй тикеты по 5 категориям" |
| 5+ | Редко нужно, занимает контекст | Очень нестандартный формат |
Формат примера: вход → выход
## Примеры (=== разделяет примеры друг от друга) Вход: "Не работает оплата картой" → Категория: Billing → Приоритет: high → Причина: упоминание оплаты === Вход: "Приложение вылетает при запуске" → Категория: Technical → Приоритет: medium → Причина: баг/ошибка === Вход: "Хочу изменить email в профиле" → Категория: Account → Приоритет: low → Причина: настройки аккаунта --- ## Теперь обработай: "Двойное списание за подписку"
Ключевые элементы
=== — визуально отделяет примеры друг от друга
--- — отделяет секцию примеров от задачи
Мета-инструкция: "(=== разделяет примеры)" — объясни разметку
→ — показывает трансформацию вход→выход
Модель сразу понимает: слева — данные, справа — результат
Можно использовать для каждого поля результата
Пример 1: "оплата" = Billing Пример 2: "вылетает" = Technical Пример 3: "email" = Account Теперь классифицируй: ...
## Примеры (=== разделяет) "оплата" → Billing, high === "вылетает" → Technical, medium --- ## Задача: ...
CoT + Few-Shot = максимальная эффективность. Покажи не только результат, но и рассуждение в примере. Модель научится применять ту же логику.
## Примеры с рассуждением
Вход: "Не могу оплатить картой, выдаёт ошибку"
Рассуждение: Упоминается оплата + ошибка. Оплата → Billing.
Ошибка может быть Technical, но контекст — оплата.
Приоритет high, т.к. блокирует покупку.
→ Категория: Billing
→ Приоритет: high
===
Вход: "Хочу удалить свой аккаунт"
Рассуждение: Про аккаунт → Account. Не срочно, не баг.
Приоритет low.
→ Категория: Account
→ Приоритет: low
Помоги с первыми шагами. Если примеры содержат начало рассуждения ("Упоминается X → значит Y"), модель продолжит в том же стиле. Это улучшает качество ответов на сложных задачах.
"Один хороший пример стоит страницы инструкций."
Описание правил
Как задать модели ограничения и логику поведения
"Просьба — пожелание. Пример — намёк. Схема — ЗАКОН."
# Настройки генерации контента
output:
format: markdown
max_length: 1500 # символов
language: ru
style:
tone: friendly # friendly | formal | casual
emoji: true
max_emoji: 3
headers: true
constraints:
forbidden_words:
- уникальный
- лучший
- номер один
- не имеет аналогов
required_sections:
- intro # Вступление
- body # Основная часть
- cta # Призыв к действию
validation:
min_paragraphs: 3
max_paragraphs: 7
links_allowed: false
Когда правила читает человек, не парсер. Комментарии объясняют "почему", не только "что".
[meta] name = "product_card_generator" version = "2.1.0" author = "marketing_team" [output] format = "html" max_chars = 2000 language = "ru" [style] tone = "professional" emoji_allowed = true max_emoji = 3 [forbidden] words = ["лучший", "уникальный", "номер один"] phrases = ["лидер рынка", "не имеет аналогов"] [required] sections = ["title", "description", "specs", "cta"] min_specs = 3 max_specs = 7 [validation] check_length = true check_forbidden = true check_required = true
## Алгоритм обработки
IF length(text) > 500 слов:
1. Выдели 3-5 ключевых тезисов
2. Для каждого тезиса — краткий анализ
3. Общее резюме в конце
ELSE:
1. Анализируй текст целиком
2. Один абзац выводов
IF language(input) != "русский":
1. Определи язык источника
2. Переведи ключевые термины
3. Ответ — СТРОГО на русском
## Формат ответа
SWITCH тип_запроса:
CASE "вопрос":
→ Краткий ответ (1-2 предложения)
→ Развёрнутое объяснение
CASE "задача":
→ Пошаговое решение
→ Финальный ответ в рамке
CASE "анализ":
→ Структура: тезис → аргументы → вывод
→ Таблица если сравнение
CASE "код":
→ Только код, без объяснений
→ Комментарии внутри кода
DEFAULT:
→ Уточни тип запроса у пользователя
Структура промпта как программа с IF/ELSE, SWITCH/CASE, FOR работает значительно лучше естественного языка. Модель "выполняет" логику как код, а не интерпретирует текст.
Разбей сложную классификацию на цепочку простых бинарных вопросов (да/нет). Вместо "определи тональность" → "это позитивно? → есть критика? → есть сарказм?"
Оформи задачу как Python-функцию с типами и docstring:
def classify_ticket(
text: str,
categories: list[str] = ["Technical", "Billing", "Account"]
) -> dict:
"""
Классифицирует тикет поддержки.
Args:
text: Текст обращения клиента
categories: Допустимые категории
Returns:
{
"category": str, # одна из categories
"confidence": float, # 0.0-1.0
"reasoning": str # почему эта категория
}
Constraints:
- confidence < 0.7 → category = "Unknown"
- reasoning ≤ 50 слов
"""
Почему работает: модель обучена на миллионах Python-функций и понимает docstring как контракт. Type hints (→ dict, str, float) заставляют её выводить правильные типы.
НЕ подходит для творческих задач — жёсткая структура убивает вариативность. Используй для: классификации, извлечения данных, валидации.
BASIC-стиль с нумерованными строками:
10 EXTRACT facts from input 20 CHECK for contradictions 30 IF conflict THEN RESOLVE 40 OUTPUT result
Модель "выполняет" инструкции построчно с явным логированием каждого шага. Полезно для аудита рассуждений.
Промпт как код с синтаксисом и типами:
PERSONA: "Аналитик данных"
TYPES:
Rating = int[1-100]
Category = enum["A", "B", "C"]
VARIABLES:
$input: str
$threshold: Rating = 80
CONSTRAINTS:
- ответ ≤ 200 слов
- формат = JSON
WORKER:
1. PARSE $input
2. IF rating($input) > $threshold:
→ Category.A
ELSE:
→ Category.B
3. OUTPUT {category, confidence}
Явные секции (PERSONA, TYPES, VARIABLES, CONSTRAINTS, WORKER) делают промпт проверяемым — как код. 100% точности против 76% у обычного GPT-4o на сложных задачах с переменными.
Проблема: GPT-4o падает с 97% до 10% точности на задачах с миллионами комбинаций — модель не может откатиться назад при ошибке.
Решение: вместо Chain-of-Thought попроси модель перевести задачу в исполняемый Python-код:
## Инструкция
Переведи задачу в Python-код с библиотекой constraint.
Каждое условие из текста → комментарий + код.
Не решай сам — пусть solver найдёт ответ.
## Пример
Задача: "Найди числа от 1 до 100, которые делятся на 3 и 7"
```python
from constraint import Problem
p = Problem()
# числа от 1 до 100
p.addVariable("x", range(1, 101))
# делится на 3
p.addConstraint(lambda x: x % 3 == 0)
# делится на 7
p.addConstraint(lambda x: x % 7 == 0)
print(p.getSolutions())
```
Результат: с 10% до 89% точности на логических пазлах. Модель только переводит условия в код, а solver (SymPy, constraint, z3) систематически перебирает варианты.
DEFAULT — поведение по умолчанию в SWITCH/CASE:
SWITCH источник:
CASE "pdf": → извлеки текст
CASE "url": → скачай страницу
DEFAULT: → запроси формат у пользователя
FALLBACK — запасное значение если данные отсутствуют:тон: FALLBACK "нейтральный" цена: FALLBACK "по запросу" автор: FALLBACK "не указан"Модель использует FALLBACK когда поле пустое или неизвестно.
Проблема: LLM выдаёт первое пришедшее решение, не проверяя его на слабые места.
Решение: метод INoT (Introspective Negotiation of Thought) заставляет модель симулировать дебаты между виртуальными экспертами прямо внутри одного промпта.
## Сценарий интроспекции
<AGENT_1 role="Решатель">
→ Предложи решение задачи
</AGENT_1>
<AGENT_2 role="Критик">
→ Найди слабые места в решении AGENT_1
→ Укажи конкретные проблемы
</AGENT_2>
<AGENT_1>
→ Скорректируй решение учитывая критику
</AGENT_1>
REPEAT 2-3 раунда UNTIL консенсус
OUTPUT финальное_решение
Результат: +7.95% точности при -58.3% токенов по сравнению с обычным итеративным диалогом "ответ → твоя критика → новый ответ".
Для важных решений можно управлять тем, показывает ли модель внутренние дебаты:
## Режим интроспекции: VERBOSE | SILENT
IF режим = VERBOSE:
→ показывай каждый раунд дебатов
ELSE:
→ дебаты внутренне, только финал
<EXPERT_A domain="финансы">
→ оценка рисков инвестиции
</EXPERT_A>
<EXPERT_B domain="маркетинг">
→ потенциал роста продукта
</EXPERT_B>
<MODERATOR>
→ синтезируй позиции A и B
→ выдели точки согласия и конфликта
→ итоговая рекомендация
</MODERATOR>
OUTPUT {
решение: ...
уверенность: [1-10]
оставшиеся_риски: [...]
}
Вариации: добавь "адвоката дьявола", эксперта по этике, технического ревьюера — модель переключается между перспективами автоматически.
Символы (кликни для копирования)
Логика
Множества
Сравнения
Кванторы
Операции (MetaGlyph)
Надёжные: ∈ (до 91.3% на GPT-5.2), ⇒ (до 98.1% на Kimi K2), ¬ (работает везде)
Нестабильные: ∩ — max 21.4% (модели путают с "списком"). Решение: пиши через запятую: ∈(A), ∈(B), ¬(C)
Не работают: → как трансформация — 0% на всех моделях. Используй слово "select" или "filter".
Формула MetaGlyph
{данные} → {действие} where {условия} → {формат}
Примеры
products → filter where ∈(electronics), ¬(refurbished) → table
users → apply: ∈(admin) ⇒ access = full ∈(moderator) ⇒ access = limited ∈(user) ⇒ access = basic
companies → select where (∈(tech), ¬(hardware)) ∪ ∈(AI) → JSON{name, revenue}
data → (filter ∈(active)) ◦ (sort by date) ◦ (limit 10) → table
names ↦ lowercase, prices ↦ round(2) → output
Техника сжатия через символы научно подтверждена. Ключевые результаты по моделям:
- ∈ (membership): GPT-5.2 — 91.3% fidelity (лучший!), Gemini 2.5 — 49.9%, Kimi K2 — 36%
- ⇒ (if-then): Kimi K2 — 98.1% fidelity (!), Gemini — 33.5%, остальные ~0%
- ∩ (intersection): GPT-5.2 — 21.4%, остальные <3% (нестабилен!)
U-образная кривая: маленькие модели (3B) → умеренная точность, средние (7-12B) → хуже из-за instruction tuning, большие (1T+) → лучше всех. Kimi K2 на selection tasks с символами показал 100% accuracy — лучше чем с текстом (90.8%)!
1. Удаление малоинформативных токенов. 2. Замена частых фраз на коды (N-gram abbreviation): "чистая прибыль" → CP1. 3. Округление чисел. Таблицу кодов сохраняй в начале промпта.
Windows: Win + . → вкладка "Символы" → Математические
Mac: Ctrl + Cmd + Space → поиск "and", "or", "not"
Универсально: скопируй из таблицы выше или из Google "math symbols unicode"
ASCII-альтернатива: && вместо ∧, || вместо ∨, ! вместо ¬ — модели понимают оба варианта.
🧪 Тестовые данные — проверь сам
## Промпт
Фильтр товаров:
категория ∈ {электроника, бытовая_техника}
∧ 5000 ≤ цена ≤ 50000
∧ в_наличии = true
∧ рейтинг ≥ 4
∧ статус ≠ "снят с производства"
---
## Данные для обработки
1. iPhone 15 Pro | электроника | 89990₽ | в наличии | ★4.8
2. Блендер Philips | бытовая техника | 4200₽ | в наличии | ★4.5
3. Кресло офисное | мебель | 15000₽ | в наличии | ★4.2
4. Телевизор Samsung 55" | электроника | 45000₽ | нет в наличии | ★4.7
5. Микроволновка LG | бытовая техника | 8900₽ | в наличии | ★3.8
6. Наушники Sony WH-1000 | электроника | 25000₽ | в наличии | ★4.9
7. Утюг Bosch | бытовая техника | 3500₽ | в наличии | ★4.6
8. Принтер Canon | электроника | 12000₽ | снят с производства | ★4.4
---
## Ожидаемый результат — подходит только #6:
✗ #1 iPhone — цена 89990 > 50000
✗ #2 Блендер — цена 4200 < 5000
✗ #3 Кресло — категория "мебель" ∉ {электроника, бытовая_техника}
✗ #4 Телевизор — нет в наличии
✗ #5 Микроволновка — рейтинг 3.8 < 4
✓ #6 Наушники Sony — все 5 условий выполнены
✗ #7 Утюг — цена 3500 < 5000
✗ #8 Принтер — статус "снят с производства"
## Промпт
БЛОКИРОВАТЬ если:
(мат ∈ текст) ∨ (угрозы ∈ текст) ∨ (спам_ссылки > 0)
ПРЕДУПРЕЖДЕНИЕ если:
(caps_ratio > 0.5) ∧ ¬(цитата)
∨ (повторы_символов ≥ 5)
ПРОПУСТИТЬ если:
¬БЛОКИРОВАТЬ ∧ ¬ПРЕДУПРЕЖДЕНИЕ
∧ длина ∈ [10, 2000]
ПРИОРИТЕТ: БЛОКИРОВАТЬ → ПРЕДУПРЕЖДЕНИЕ → ПРОПУСТИТЬ
---
## Тестовые комментарии
1. "Отличный товар, спасибо за быструю доставку!"
2. "КУПИТЕ ВИАГРУ ДЁШЕВО http://spam.com/viagra"
3. "ПОЧЕМУ ТАК ДОРОГО??? ЭТО ЖЕ ПРОСТО ПЛАСТИК!!!"
4. "нууууууу такое себе"
5. "Цитирую поддержку: 'ВОЗВРАТ НЕВОЗМОЖЕН' — это нормально?"
6. "Ты тупой урод, я тебя найду"
7. "Ок"
8. "Заказывал для мамы на ДР, она в восторге. Рекомендую!"
---
## Ожидаемые решения:
#1 → ПРОПУСТИТЬ (чистый позитивный отзыв)
#2 → БЛОКИРОВАТЬ (спам-ссылка)
#3 → ПРЕДУПРЕЖДЕНИЕ (caps_ratio > 0.5, не цитата)
#4 → ПРЕДУПРЕЖДЕНИЕ (повтор "у" ≥ 5)
#5 → ПРОПУСТИТЬ (caps в цитате — исключение)
#6 → БЛОКИРОВАТЬ (угрозы)
#7 → БЛОКИРОВАТЬ по длине (< 10 символов)
#8 → ПРОПУСТИТЬ (норм)
## Правила ### 🔴 Критично (нарушение = провал задачи) • НИКОГДА не используй слово "уникальный" • НИКОГДА не превышай 700 символов • НИКОГДА не добавляй непроверенные факты ### 🟡 Важно (сильно влияет на качество) • Добавь 3-5 буллетов с характеристиками • Используй максимум 3 emoji • Тон: дружелюбный, но не панибратский ### 🟢 Желательно (улучшает, но не критично) • Упомяни материал изделия • Добавь размерную сетку если релевантно • Закончи призывом к действию
Модели предпочитают порядок инструкций "от сложного к простому". Сначала 🔴 критичные правила, потом 🟡 важные, в конце 🟢 желательные. Это значительно повышает точность следования.
Позиционное искажение: модель лучше помнит начало и конец промпта, середина "проваливается". Критичные правила — в начало ИЛИ в конец. Никогда не прячь важное в середину.
Длинные инструкции теряются в промпте. Декораторы — компактная альтернатива:
Пожалуйста, покажи свои рассуждения пошагово. Используй формальный деловой тон. Рассмотри проблему с разных точек зрения. Результат выведи в формате JSON.Модель может пропустить часть инструкций
+++Reasoning +++Tone(style=formal) +++Debate +++OutputFormat(type=json) [Твой вопрос здесь]Чёткие структурные якоря — ничего не потеряется
+++ и как это работает?
Механизм: LLM отлично распознают структурные паттерны — символы, которые выделяются на фоне естественного языка. Когда модель видит +++Reasoning, она понимает: "это не часть задачи, это директива поведения".
Почему именно +++:
- Контрастность — три плюса почти не встречаются в обычном тексте → "визуальный якорь"
- Ассоциация с кодом — напоминает @decorator в Python, модель обучена на коде
- Лёгкость парсинга — модель легко отделяет декораторы от промпта
Важно: Это не встроенная функция Claude/GPT — модель просто распознаёт паттерн. Работает на моделях, обученных на коде.
Работает: Claude 3+, GPT-4, GPT-4o
Может не работать: LLaMA, Mistral, GPT-3.5
Альтернатива: обычные текстовые инструкции
Базовые декораторы
| Декоратор | Заменяет инструкцию | Семья |
|---|---|---|
+++Reasoning |
"покажи свои рассуждения пошагово" | Cognitive |
+++Tone(style=formal) |
"используй формальный/деловой тон" | Expressive |
+++OutputFormat(type=json) |
"выведи результат в формате JSON" | Systemic |
+++Debate |
"рассмотри с разных точек зрения" | Cognitive |
+++Refine(iterations=3) |
"улучши результат итеративно" | Generative |
+++Import(topic="X") |
"используй знания из области X" | Systemic |
Стакирование декораторов
Декораторы комбинируются как слои. Порядок имеет значение — модель обрабатывает сверху вниз:
+++Debate +++Reasoning +++Refine(iterations=2) +++OutputFormat(type=markdown) Оцени стратегию выхода стартапа на новый рынок.
Логика стакирования: как думать → как выражать → как форматировать
Декораторы выносят поведенческие команды в компактные токены, отделяя их от задачи. Модель распознаёт их как "мета-инструкции" — приоритет выше, чем у текста в середине промпта.
Продвинутый уровень: явные роли и параметры
+++Debate без параметров — модель сама выберет перспективы. Но когда нужен контроль — укажи роли явно:
+++Debate(
roles=[
"Защитник: приводит аргументы ЗА, ищет доказательства",
"Скептик: ищет слабые места, требует evidence"
],
rounds=3,
respond_to_opponent=true,
early_stop_on_consensus=true,
show_process=true
)
+++OutputFormat(type=markdown, sections=["Раунд N", "Вердикт"])
Стоит ли внедрить AI-ассистента для клиентской поддержки вместо расширения штата?
• roles=[...] — явно задаёт перспективы агентов (вместо автоматических)
• respond_to_opponent=true — каждый агент отвечает на аргументы оппонента, не просто излагает позицию
• early_stop_on_consensus=true — если пришли к согласию раньше max rounds → стоп (экономия токенов)
• show_process=true — показать ход дебатов, а не только итог
+++Debate заменяет сложную XML-разметку интроспекции (INoT, раздел 3.3). Запись эквивалентна сценарию с агентами, но модель сама разворачивает дебаты внутренне.
Когда что использовать:
+++Debateбез параметров — быстрые проверки+++Debate(roles=[...], respond_to_opponent=true)— дискуссия с интроспекцией- Полный INoT с XML — критичные решения, где важна трассировка каждого шага
Если декораторы управляют поведением модели, то MetaGlyph (техника 3.4) — компактная нотация для логических условий: ∈, ¬, ∩, ∪. Обе техники заменяют многословный текст символами.
Контроль формата ответа
Как получить ответ в нужной структуре
"Формат — не упаковка. Это инструкция для мозга. Просишь JSON — модель ДУМАЕТ структурированно."
| Синтаксис | Кто заполняет | Когда использовать | Пример |
|---|---|---|---|
[текст] |
Модель | Шаблон для генерации | Привет, [имя клиента]! |
{переменная} |
Ты | Место для твоих данных | Проанализируй: {текст} |
[a/b/c] |
Модель выбирает | Ограниченный выбор | [позитив/негатив/нейтрал] |
[1-5] |
Модель | Числовой диапазон | Оценка: [1-5] |
[до 100 слов] |
Модель | С ограничением длины | Резюме: [до 100 слов] |
## Входные данные (ты заполняешь)
Товар: {product_name}
Категория: {category}
Цена: {price} ₽
Особенности: {features}
---
## Формат ответа (модель заполняет)
# [Продающий заголовок — до 60 символов]
[Эмоциональное описание — 2-3 предложения]
**Характеристики:**
• [характеристика 1]
• [характеристика 2]
• [характеристика 3]
💰 **Цена:** [цена] ₽
[Призыв к действию — 1 предложение]
"JSON-схема — это контракт. Модель либо выполняет, либо нарушает. Серединки нет."
Верни результат в JSON:
{
"sentiment": "positive" | "negative" | "neutral",
"confidence": число от 0.0 до 1.0,
"score": целое число от 1 до 5,
"keywords": массив строк (максимум 5 элементов),
"summary": строка (до 100 слов),
"issues": массив строк | null (если нет проблем)
}
Правила:
- sentiment: ТОЛЬКО одно из трёх значений
- confidence: дробное, один знак после запятой
- issues: массив ИЛИ null, НЕ пустой массив []
Проблема: LLM катастрофически плохи в генерации сложных форматов (XML, HTML, BPMN) — 40% ошибок синтаксиса.
Решение: Запрашивай промежуточный упрощённый JSON, а не конечный сложный формат. Модель перестаёт быть "компилятором" и становится "заполнителем шаблона".
❌ Плохо: "Сгенерируй BPMN-диаграмму в XML"
✅ Хорошо: "Верни JSON: {nodes: [{id, label, type}], edges: [{from, to}]}"
→ Конвертация в XML программно
Результат: Успешность редактирования данных вырастает в 3 раза.
type ReviewAnalysis = {
// Обязательные поля
sentiment: "positive" | "negative" | "neutral";
score: 1 | 2 | 3 | 4 | 5;
confidence: number; // 0.0-1.0
// Массивы
keywords: string[]; // max 5 items
pros: string[];
cons: string[];
// Опциональные поля
issues?: string[]; // только если score < 3
// Вложенный объект
recommendation: {
action: "buy" | "wait" | "skip";
reason: string; // до 50 слов
};
}
// Проанализируй отзыв и верни объект типа ReviewAnalysis
Сравни три варианта. Ответ ТОЛЬКО в формате таблицы: | Критерий | Вариант A | Вариант B | Вариант C | |----------|-----------|-----------|-----------| | Цена | [цена] | [цена] | [цена] | | Скорость | [1-5] | [1-5] | [1-5] | | Качество | [1-5] | [1-5] | [1-5] | | Поддержка | [да/нет/частично] | [...] | [...] | | **Итог** | [рекомендация] | [...] | [...] | После таблицы — один абзац с выводом (до 50 слов).
## СХЕМА
{
"category": "string — категория товара",
"sentiment": "positive" | "negative" | "mixed",
"score": 1-5,
"issues": ["string"] | null
}
---
## ПРИМЕРЫ
Примеры разделены "===":
===
Отзыв: "Супер пылесос! Рекомендую всем."
→ {"category": "пылесос", "sentiment": "positive", "score": 5, "issues": null}
===
Отзыв: "Камера хорошая, но батарея дохлая."
→ {"category": "камера", "sentiment": "mixed", "score": 3, "issues": ["батарея"]}
===
---
## ЗАДАЧА
Отзыв: "Телефон норм, но греется при играх"
→
Лучшие результаты достигаются комбинацией Chain-of-Thought (просьба рассуждать по шагам) и Few-Shot (2-3 примера). Схема-Примеры-Задача — именно эта комбинация.
Наибольший прирост качества — если помочь модели сделать первые шаги в текущей задаче, а не показывать примеры решения других задач. В примерах покажи начало рассуждения.
Напиши функцию сортировки на Python ```python
Модель видит незакрытый блок и стремится его закрыть. Внутри блока ```python ожидается код, не текст.
"Модель не умеет проверять себя автоматически. Но если ПОПРОСИШЬ — проверит."
## Задача [описание] --- ## Формат [схема] --- <self_check> Перед выдачей ответа проверь: □ Все обязательные поля заполнены? □ Типы данных соответствуют схеме? □ Нет запрещённых слов? □ Длина в пределах лимита? □ Язык ответа — русский? Если хоть один пункт НЕ выполнен — исправь ДО вывода. </self_check>
<self_check> Перед финализацией: □ Главный тезис раскрыт? □ Есть конкретные примеры/цифры? □ Нет повторов и воды? □ Лимит слов соблюдён? □ Есть CTA в конце? □ Тон соответствует TA? Если нет — доработай. </self_check>
Итеративная коррекция — чрезвычайно эффективный способ заставить LLM точно следовать инструкциям. Добавление шагов самокритики и исправления в промпт даёт более честные и точные ответы.
Вместо "думай по шагам и найди ответ" → "вот ответ [любой], проверь его, потом дай правильный". Меняем порядок: верификация перед генерацией улучшает точность.
Учи модель останавливаться и спрашивать вместо действовать в неопределённости. Добавь: "Если не уверен — напиши 'Нужно уточнение: ...' вместо угадывания".
Универсальный шаблон
Всё вместе. Копируй и адаптируй под задачу.
# ═══════════════════════════════════════════════════════
# PROMPT: [название]
# VERSION: 1.0.0
# ═══════════════════════════════════════════════════════
## ГЛОССАРИЙ
H1 = главный заголовок
CTA = призыв к действию
TA = целевая аудитория
---
## Роль
Ты — [роль с опытом и специализацией].
---
## Контекст
<context source="[источник]" id="doc1">
{данные_для_обработки}
</context>
---
## Задача
[Чёткое описание что нужно сделать]
---
## Правила
### 🔴 Критично
НИКОГДА [запрет 1]
НИКОГДА [запрет 2]
### 🟡 Важно
• [требование 1]
• [требование 2]
### 🟢 Желательно
• [рекомендация]
---
## Формат ответа
{
"field1": "тип | допустимые значения",
"field2": число 1-10,
"field3": ["массив строк"] | null
}
---
## Примеры
Примеры разделены "===":
===
Вход: [пример 1]
Выход: [результат 1]
===
Вход: [пример 2]
Выход: [результат 2]
===
---
<self_check>
□ Все поля заполнены?
□ Типы соответствуют схеме?
□ Запреты соблюдены?
□ Формат корректный?
</self_check>
Быстрая справка
Все техники в одной таблице
| Задача | Техника | Синтаксис |
|---|---|---|
| 1. Организация промпта | ||
| Акцент на слове | Жирный | **текст** |
| Значение/команда | Код в строке | `value` |
| Разделить блоки | Разделитель | --- |
| Разделить примеры | Разделитель + сказать | === + "разделены ===" |
| Навигация | Заголовки | ## Секция |
| Критичный запрет | КАПС | НИКОГДА (1 раз!) |
| Выделить блок | ASCII-рамка | ╔══╗ ║ ╚══╝ |
| Сократить термины | Глоссарий | CTA = призыв |
| 2. Подача данных | ||
| Семантика | XML-теги | <context>...</context> |
| Группировка | Namespace | input:, rules: |
| Источник | Атрибуты | source="...", id="..." |
| Не выдумывать | Заземление | "ТОЛЬКО из <context>" |
| Большие списки | Разбиение | Части по 10, разделитель │ |
| Категории | Иконки | 💡 🚩 ⚠️ ✅ ❌ |
| 3. Описание правил | ||
| Читаемые правила | YAML | key: value |
| Секции правил | TOML | [section] |
| Условия | Псевдокод | IF x THEN y ELSE z |
| Компактная логика | MetaGlyph | ∈(cat) ∩ ¬(spam) |
| Приоритеты | Иерархия | 🔴 🟡 🟢 |
| 4. Контроль формата ответа | ||
| Модель заполняет | Плейсхолдер | [текст] |
| Ты подставляешь | Переменная | {данные} |
| Выбор из списка | Плейсхолдер | [a/b/c] |
| Данные для API | JSON-схема | {"key": "type"} |
| Строгие типы | TypeScript | "a" | "b" | "c" |
| Сравнение | MD-таблица | | A | B | |
| Чистый код | Открытый бэктик | ```python |
| Проверка | Self-check | <self_check>□ ...</self_check> |
Символы для копирования
∈ (принадлежит) ¬ (НЕ) ∩ (И) ∪ (ИЛИ) → (в) ⇒ (если-то)
--- === *** ### │ ◆◆◆
╔ ╗ ╚ ╝ ═ ║ ╠ ╣ ┌ ┐ └ ┘ ─ │ ├ ┤
💡 🚩 ⚠️ ✅ ❌ 🎯 🔴 🟡 🟢 📌 💬 📊 🔗
📋 Чеклист форматирования промпта
"Пройдись по списку перед отправкой — сэкономишь 3-5 итераций."
1. Организация
2. Подача данных
3. Правила и логика
4. Формат ответа
Не обязательно использовать ВСЕ техники. Но чем больше — тем стабильнее результат.
🎯 Комбинирование техник: полные примеры
В реальных задачах техники работают вместе. Вот полный промпт, использующий несколько техник курса.
## Задача
Проанализируй отзывы клиентов и классифицируй проблемы.
---
<context>
Ты — аналитик службы поддержки. Твоя задача — выделить паттерны проблем и расставить приоритеты для команды.
</context>
---
## Входные данные
<reviews>
[
{"id": 1, "text": "Доставка опоздала на 3 дня", "rating": 2},
{"id": 2, "text": "Товар отличный, но упаковка мятая", "rating": 4},
{"id": 3, "text": "Курьер нахамил", "rating": 1}
]
</reviews>
---
## Правила классификации
IF отзыв про доставку/сроки:
→ категория: "delivery"
IF отзыв про качество товара/упаковки:
→ категория: "product"
IF отзыв про персонал/сервис:
→ категория: "service"
---
## Правила приоритета
rating ≤ 2 → приоритет: "high"
rating = 3 → приоритет: "medium"
rating ≥ 4 → приоритет: "low"
---
## Формат ответа
```json
{
"problems": [
{
"category": "delivery|product|service",
"priority": "high|medium|low",
"count": N,
"examples": ["цитата 1", "цитата 2"]
}
],
"summary": "краткий вывод в 1-2 предложения"
}
```
---
<self_check>
Перед ответом проверь:
□ Все отзывы классифицированы?
□ Приоритеты расставлены по rating?
□ JSON валидный?
□ Есть summary?
Если хоть один пункт НЕ выполнен — исправь ДО отправки.
</self_check>
✓ Заголовки ## — структура секций (раздел 1.3)
✓ Разделители --- — границы между блоками (раздел 1.2)
✓ XML <context> — роль модели (раздел 2.1)
✓ XML <reviews> — контейнер для данных (раздел 2.1)
✓ JSON внутри XML — структурированный вход (раздел 2.5)
✓ Псевдокод IF/ELSE — правила классификации (раздел 1.7)
✓ Стрелка → — показ результата (раздел 1.2.1)
✓ JSON-схема — формат ответа (раздел 2.5)
✓ <self_check> — проверка перед выводом (раздел 1.8)
## Задача Переведи текст с английского на русский, сохраняя стиль. --- ## Примеры "The quick brown fox" → "Быстрая рыжая лиса" "It's raining cats and dogs" → "Льёт как из ведра" --- ## Текст для перевода <text> We need to think outside the box to solve this problem. </text> --- ## Формат Только перевод, без пояснений.
✓ --- разделяет секции
✓ → показывает примеры трансформации
✓ <text> изолирует входные данные
✓ ## Формат задаёт ожидания от вывода
Лексика и синтаксис
Микро-лайфхаки на уровне слов: простые, элегантные, эффективные
Эта часть курса в разработке
Ждите выхода 2-й части курса
Few-shot: как подавать примеры
Правила составления, порядка и формата примеров
Эта часть курса в разработке
Ждите выхода 2-й части курса
Лайфхаки
Простые техники с непропорционально большим эффектом
Эта часть курса в разработке
Ждите выхода 2-й части курса
Ключевые фразы для запоминания
11 принципов форматирования в одном предложении
"Ноль новой информации — только структура."
О силе форматирования"Заголовки — якоря внимания модели."
Markdown и иерархия"Таблица связывает данные — модель видит пары."
Структурированные данные"XML-тег — контейнер с чёткими границами."
Семантическая разметка"Теги на английском, контент на любом языке."
Языковая оптимизация"Псевдокод превращает просьбу в алгоритм."
Логические структуры"Плейсхолдер — пустой бланк, который модель заполняет."
Контроль формата"Self-check — про консистентность в production."
Качество и надёжность"Наречие > прилагательное: 'анализируй точно' > 'будь точный'."
Выбор слов"Запрет активирует запрещённое — переформулируй позитивно."
Психология промптов"Каждое слово — сигнал. Тестируй формулировки."
Итерации и улучшениеМодель не понимает "смысл" — она реагирует на токены. Каждое слово активирует разные веса в нейросети. Выбирай слова осознанно — это твой API к модели.