Продвинутый промпт-инжиниринг: chain-of-thought, few-shot, паттерны для аналитика

Вы написали промпт. LLM выдала ерунду. Вы дописали «пожалуйста, будь точнее». Стало чуть лучше. Потом вы потратили полчаса на перебор формулировок и получили сносный результат. Знакомо?

Базовый промпт-инжиниринг — это умение спросить так, чтобы тебя поняли. Об этом мы уже говорили подробно. А продвинутый — это когда вы не спрашиваете, а управляете когнитивным процессом модели. Вы говорите ей не «что сделать», а «как думать над ответом». Разница примерно как между «нарисуй кота» и «нарисуй кота: начни с контура головы, потом уши, потом глаза с учётом перспективы — и объясняй каждый шаг». Результат во втором случае будет на порядок точнее.

В этой статье разберём три техники, которые превращают LLM из гадалки в надёжный инструмент аналитика: chain-of-thought, few-shot prompting и структурные паттерны промптов. Всё с примерами под наши задачи, без абстрактных «напиши стихотворение».

Анатомия продвинутого промпта

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

graph TD
  A["Системный промпт
(роль + контекст)"] --> B["Основной запрос
(задача аналитика)"]
  B --> C["Few-shot примеры
(2-3 образца)"]
  C --> D["Chain-of-Thought
(пошаговое рассуждение)"]
  D --> E["Формат ответа
(JSON/таблица/текст)"]
  E --> F["Результат LLM
(структурированный ответ)"]
  A --> G["Ограничения
(что НЕ делать)"]
  G --> F
  B --> H["Входные данные
(контекст задачи)"]
  H --> F

  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style C fill:#f0a500,stroke:#c88400,color:#fff
  style D fill:#f0a500,stroke:#c88400,color:#fff
  style E fill:#7b68ee,stroke:#5a4db2,color:#fff
  style F fill:#50c878,stroke:#3a9a5c,color:#fff
  style G fill:#e0e0e0,stroke:#999,color:#333
  style H fill:#e0e0e0,stroke:#999,color:#333

На диаграмме — полная структура промпта. Системный промпт задаёт роль и общий контекст, основной запрос формулирует задачу. Few-shot примеры демонстрируют ожидаемый результат на образцах, а chain-of-thought заставляет модель рассуждать по шагам. Ограничения отсекают нежелательное поведение. Входные данные — это контекст задачи. Всё вместе поступает в LLM и даёт структурированный ответ. Теперь — подробно по каждому слою.

Chain-of-Thought: заставляем модель рассуждать

Chain-of-Thought (CoT) — это техника, при которой вы просите модель показать ход рассуждений перед тем, как дать финальный ответ. Не «дай ответ», а «подумай вслух шаг за шагом, потом дай ответ».

Почему это работает? LLM — это не база данных, которая ищет ответ по индексу. Это генератор наиболее вероятного продолжения текста. Если вы просите ответ сразу — модель «стреляет» одним наиболее вероятным токеном. Если вы просите рассуждение — модель генерирует цепочку промежуточных выводов, и каждый следующий опирается на предыдущий. Финальный ответ получается более обоснованным просто потому, что модель «прошла» через логические шаги, а не прыгнула сразу к выводу.

Базовый CoT: «давай подумаем шаг за шагом»

Простейшая форма — добавить в промпт фразу Давай подумаем шаг за шагом (или Let's think step by step — на английских моделях работает стабильнее). Пример для задачи аналитика:

Задача: определить, какие REST-эндпоинты нужны для функции «корзина покупок» в интернет-магазине.

Промпт без CoT: «Перечисли REST-эндпоинты для корзины покупок интернет-магазина»

Промпт с CoT: «Мне нужно спроектировать REST API для корзины покупок интернет-магазина. Давай подумаем шаг за шагом: какие операции пользователь может совершать с корзиной? Для каждой операции определи HTTP-метод, URL и пример тела запроса/ответа. Сначала перечисли все операции, потом для каждой дай спецификацию».

Разница в качестве ответа колоссальная. Без CoT модель может выдать 3 эндпоинта. С CoT — 5–7, с обоснованием каждого и учётом граничных случаев вроде «объединить корзины после логина».

Zero-shot CoT vs Manual CoT

Есть два подхода к CoT:

Для серьёзной аналитической работы почти всегда нужен Manual CoT. Вы как аналитик знаете предметную область и можете направить рассуждение модели в нужное русло, минуя типичные ловушки.

Практический пример CoT для аналитики требований

Допустим, нужно выявить нефункциональные требования к платёжному шлюзу. Вот как может выглядеть Manual CoT-промпт:

1
Ты — системный аналитик. Проанализируй описание платёжного шлюза
2
и выяви нефункциональные требования.
3

4
Рассуждай по следующему плану:
5
1. Определи, с какими внешними системами взаимодействует шлюз
6
2. Для каждого взаимодействия определи требования к
7
   производительности (таймауты, пропускная способность)
8
3. Выяви требования к безопасности для каждого канала связи
9
4. Определи требования к отказоустойчивости (что делать при
10
   недоступности платёжного провайдера)
11
5. Сформулируй требования к аудиту и логированию
12
6. На основе шагов 1–5 составь итоговый список НФТ в
13
   формате: ID | Категория | Требование | Критерий проверки
14

15
Описание платёжного шлюза:
16
[текст описания]

Обратите внимание: план рассуждения написан за модель. Вы не говорите «придумай, как анализировать» — вы даёте готовый мыслительный каркас, а модель наполняет его содержанием. Это и есть суть Manual CoT.

Few-shot prompting: показываем, а не объясняем

Few-shot prompting — это включение в промпт нескольких примеров того, какой результат вы ожидаете. Модель учится на лету: она видит паттерн в примерах и продолжает его для вашего нового входа.

Это не про «объясни на словах, что мне нужно» — это про «покажи 3 раза, что мне нужно, а теперь сделай так же для вот этого».

Сколько примеров нужно?

Для большинства аналитических задач достаточно 2–3 примеров. Один пример — это скорее подсказка, чем демонстрация паттерна. Пять и больше — риск перегрузить промпт и выйти за эффективную длину контекста (модель начинает «забывать» начало промпта). Оптимум — 2–3 качественных примера, покрывающих разные грани задачи.

Пример: форматирование пользовательских историй

Без few-shot:

«Напиши user story для функции восстановления пароля»

С few-shot:

1
Напиши user story для функции восстановления пароля по тому же шаблону,
2
что и примеры ниже.
3

4
Пример 1:
5
**Заголовок:** Просмотр баланса счёта
6
**Как:** клиент банка
7
**Я хочу:** видеть текущий баланс своего счёта в мобильном приложении
8
**Чтобы:** контролировать расходы без звонка в поддержку
9
**Критерии приёмки:**
10
- Баланс обновляется не позже чем через 5 секунд после входа
11
- Отображается валюта счёта
12
- При недоступности сервиса показывается последний известный баланс
13
  с пометкой «данные могут быть неактуальны»
14

15
Пример 2:
16
**Заголовок:** Фильтр заказов по статусу
17
**Как:** менеджер интернет-магазина
18
**Я хочу:** фильтровать список заказов по статусу (новый/в обработке/отправлен)
19
**Чтобы:** быстро находить заказы, требующие внимания
20
**Критерии приёмки:**
21
- Фильтр поддерживает множественный выбор статусов
22
- Список обновляется без перезагрузки страницы
23
- Выбранные фильтры сохраняются в URL для возможности поделиться ссылкой

Модель усваивает структуру, уровень детализации, стиль формулировок и даже подход к критериям приёмки. Важно: примеры должны быть релевантны вашей доменной области. Не показывайте пример из медицины, если работаете с финтехом — модель может утащить нерелевантные паттерны.

Few-shot + CoT: комбо

Самое мощное — это объединение обеих техник. Вы даёте примеры, в которых показан ход рассуждения, а потом просите модель повторить тот же мыслительный процесс для новой задачи:

1
Вот два примера анализа интеграционных точек между системами.
2
Обрати внимание на структуру рассуждения: сначала определяем
3
направление потока данных, потом протокол, потом требования
4
к надёжности.
5

6
Пример 1:
7
[полный пример с рассуждением и итоговой таблицей]
8

9
Пример 2:
10
[полный пример с рассуждением и итоговой таблицей]
11

12
Теперь проанализируй интеграцию между CRM и биллингом по той же схеме.

Это работает в разы лучше, чем любой из методов по отдельности. По моему опыту, комбинация CoT + 2–3 примера даёт стабильно высокое качество там, где одиночные техники мажут.

Паттерны промптов для типовых задач аналитика

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

Паттерн 1: «Декомпозиция требования»

Задача: разложить крупное функциональное требование на атомарные.

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

1
Роль: ты — системный аналитик, который специализируется на
2
       декомпозиции функциональных требований.
3

4
Задача: разложи требование ниже на атомарные составляющие.
5

6
План рассуждения (CoT):
7
1. Выдели ключевые сущности, которые фигурируют в требовании
8
2. Определи действия пользователя для каждой сущности
9
3. Выяви предусловия и постусловия для каждого действия
10
4. Определи возможные состояния и переходы между ними
11
5. Сгруппируй атомарные требования по функциональным блокам
12

13
Формат ответа: для каждого атомарного требования укажи
14
- ID (ФТ-XX)
15
- Заголовок
16
- Действующее лицо
17
- Предусловие
18
- Основной поток
19
- Альтернативные потоки (если есть)
20

21
Требование для анализа:
22
[текст требования]

Паттерн 2: «Выявление противоречий»

Задача: найти логические нестыковки в спецификации.

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

1
Роль: ты — ревьюер требований с фокусом на выявление противоречий.
2

3
Задача: проанализируй спецификацию и найди противоречия.
4

5
План рассуждения (CoT):
6
1. Составь список всех утверждений из спецификации
7
2. Для каждой пары утверждений проверь, могут ли они быть
8
   истинны одновременно
9
3. Проверь согласованность терминологии: используется ли
10
   один и тот же термин в одном значении во всём документе
11
4. Проверь числовые значения: не противоречат ли они
12
   друг другу (например, таймаут A < таймаут B, но A зависит от B)
13
5. Для каждого противоречия сформулируй вопрос к автору
14

15
Формат ответа: таблица
16
| # | Утверждение 1 | Утверждение 2 | Суть противоречия | Вопрос |
17

18
Ограничения:
19
- Не указывай стилистические замечания — только логические противоречия
20
- Если противоречий нет, так и напиши — не выдумывай
21

22
Спецификация:
23
[текст спецификации]

Паттерн 3: «API-контракт из сценария»

Задача: превратить текстовый сценарий использования в черновик OpenAPI-спецификации.

Эту задачу мы разбирали и в контексте проектирования REST API через LLM, но сейчас посмотрим на неё через призму продвинутого промптинга.

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

1
Роль: ты — системный аналитик, проектирующий REST API.
2

3
Задача: на основе пользовательского сценария составь спецификацию
4
эндпоинтов в формате OpenAPI-совместимой таблицы.
5

6
Пример (few-shot):
7

8
Сценарий: «Менеджер просматривает список заказов за период,
9
фильтрует по статусу и экспортирует в CSV»
10

11
Результат:
12
| Метод | URL | Описание | Параметры | Ответ 200 | Ошибки |
13
| GET | /orders | Список заказов | ?date_from, date_to, status | Order[] | 400, 401 |
14
| GET | /orders/export | Экспорт в CSV | ?date_from, date_to, status | file(CSV) | 400, 401 |
15

16
Теперь сделай то же самое для сценария ниже.
17

18
План рассуждения (CoT):
19
1. Выдели все действия пользователя из сценария
20
2. Для каждого действия определи HTTP-метод
21
3. Спроектируй URL согласно REST-принципам
22
4. Определи query-параметры для фильтрации
23
5. Определи коды ответов для успешного и ошибочных сценариев
24

25
Сценарий:
26
[текст сценария]

Паттерн 4: «Граничные случаи и негативные сценарии»

Задача: дополнить спецификацию граничными и негативными кейсами.

1
Роль: ты — системный аналитик, специализирующийся на тест-дизайне.
2

3
Задача: для каждого функционального требования ниже предложи
4
граничные случаи и негативные сценарии.
5

6
План рассуждения (CoT):
7
1. Для каждого входного параметра определи граничные значения
8
   (пустое, нуль, максимальное, на единицу больше максимума)
9
2. Для каждого действия определи, что происходит при:
10
   - Отсутствии обязательного поля
11
   - Некорректном формате данных
12
   - Истечении таймаута зависимого сервиса
13
   - Повторном выполнении действия (идемпотентность)
14
3. Проверь состояния гонки: что будет при двух одновременных запросах
15
4. Для каждого сценария предложи ожидаемое поведение системы
16

17
Формат ответа: таблица
18
| ID ФТ | Тип сценария | Входные данные | Ожидаемое поведение |
19

20
Требования:
21
[текст требований]

Когда промпт-инжиниринг не спасает

Примечательно, что есть класс задач, где даже самый изощрённый промпт не поможет. Это не серебряная пуля, и вот когда честнее выбрать другой подход:

• Задача требует точных вычислений. LLM не калькулятор. Если нужно посчитать налоги с точностью до копейки для 10 000 транзакций — используйте код, а не промпт.
• Контекст превышает окно модели. Можно разбить на части и скормить через RAG, но если нужен целостный анализ 500-страничного документа — промпт-инжиниринг бессилен. Тут нужен контекст-инжиниринг и правильный чанкинг.
• Задача требует гарантированной детерминированности. LLM вероятностна по природе. Один и тот же промпт может дать чуть разный результат. Для жёстко детерминированных операций используйте код.

Сравнение техник: шпаргалка

Стоит отметить: выбор модели тоже влияет на эффективность техник. Подробно о разных моделях и о том, какую выбрать под задачу аналитика, я рассказывал в отдельной статье.

Заключение

Продвинутый промпт-инжиниринг — это не магия и не подбор «правильных слов». Это инженерия: вы проектируете мыслительный процесс модели и подкрепляете его примерами. Инвестиция в качественный промпт окупается: 15 минут на написание Manual CoT + 2–3 few-shot примера экономят час ручной доработки ответа.

Начните с малого. Возьмите одну повторяющуюся задачу — например, декомпозицию требований — и напишите под неё один CoT-промпт с парой примеров. Отладьте на 3–4 реальных кейсах. А когда увидите результат — масштабируйте на остальные рабочие сценарии.

P.S. Модели становятся умнее, но принцип «что посеешь в промпте, то и пожнёшь в ответе» пока никто не отменял.