За последние полтора года я пересмотрел несколько сотен промптов — своих, коллег по цеху и из открытых репозиториев. И вот что бросается в глаза: лучшие результаты сегодня дают не те промпты, которые написаны как инструкция, а те, которые спроектированы как система. Статический шаблон на десять абзацев с «ролью, контекстом, форматом вывода» перестаёт быть конкурентным преимуществом. На смену приходит prompt-дизайн — подход, в котором промпт не пишется один раз, а собирается из динамических блоков, адаптируется под задачу и встраивается в агентный пайплайн.
Речь не о смене модного слова. Меняется сама логика работы с моделями.
Почему статические промпты буксуют
Классическая prompt-инженерия строилась на предположении: если дать модели достаточно подробную инструкцию, она выдаст стабильный результат. Anthropic в своём гайде по промптингу (Anthropic Prompt Engineering Guide, 2024) рекомендует чётко задавать контекст, указывать формат ответа и использовать примеры. Это работает — до тех пор, пока задача линейна, а модель одна.
Проблема в том, что современные рабочие процессы всё чаще строятся на цепочках вызовов, мультиагентных схемах и динамически подгружаемых данных. Один и тот же промпт для GPT-4o, Claude 3.5 Sonnet и Gemini 1.5 Pro ведёт себя по-разному. Более того, одна и та же модель с одним и тем же промптом может давать разные результаты в зависимости от того, какой контекст загружен в систему, какие инструменты подключены и в каком порядке передаются сообщения.
Исследователи из Microsoft (Wang et al., 2024) показали, что даже небольшие изменения в формулировке могут приводить к разнице в точности до 40% на бенчмарках вроде MMLU и GSM8K, но эти изменения не переносятся между моделями. То, что улучшает результат у Llama 3, может ухудшить его у Mistral. Статический промпт — это ставка на конкретную модель в конкретный момент времени.
Что такое prompt-дизайн на практике
Prompt-дизайн — это подход, при котором промпт перестаёт быть текстом и становится архитектурой. Вместо одного блока инструкций вы проектируете систему из нескольких компонентов:
- Динамический контекст — данные подгружаются из внешних источников (база знаний, RAG, API) в момент запроса.
- Модульные инструкции — роли, правила форматирования и примеры хранятся отдельно и собираются в зависимости от типа задачи.
- Контрольные точки — промежуточные проверки качества, ретрай-логика и переключение между стратегиями в зависимости от ответа модели.
Хороший пример — подход DSPy (Khattab et al., 2023), где промпты не пишутся вручную, а оптимизируются автоматически под конкретную модель и датасет. Вместо ручного подбора формулировок вы описываете модули и их связи, а система подбирает оптимальные инструкции. Это не замена инженеру, а новый слой абстракции.
Другой пример — LangChain Expression Language (LCEL), где цепочки промптов, моделей и парсеров собираются как граф, а не как линейный скрипт. Каждый узел может менять промпт в зависимости от предыдущего шага.
Сравнение двух подходов
| Характеристика | Prompt-инженерия (статическая) | Prompt-дизайн (динамический) |
|---|---|---|
| Структура промпта | Один текстовый блок | Модульные компоненты с подгрузкой |
| Адаптация под модель | Ручной подбор формулировок | Автоматическая оптимизация (DSPy) или переключение шаблонов |
| Устойчивость к изменениям | Низкая — обновление модели ломает промпт | Средняя — модули можно заменить по отдельности |
| Интеграция с инструментами | Через ручное описание в инструкции | Через программные вызовы (tool use, function calling) |
| Масштабирование на много задач | Требует отдельного промпта на каждую задачу | Один набор модулей для класса задач |
| Пример инструментов | ChatGPT, ручные шаблоны | DSPy, LangChain, Vellum, HumanLoop |
Практический рабочий процесс
Чтобы перейти к prompt-дизайну, не обязательно переписывать всю инфраструктуру. Достаточно начать с трёх шагов.
Шаг 1. Разделите контекст и инструкцию
Вместо одного промпта «Ты — эксперт по SQL. Вот схема базы. Напиши запрос» храните схему отдельно, а инструкцию — отдельно. При каждом запуске подгружайте актуальную схему из источника данных. Это снижает риск устаревания контекста и упрощает поддержку.
Шаг 2. Введите переменные для поведения
Вместо жёстко заданной роли используйте параметры: `{стиль_ответа}`, `{уровень_детализации}`, `{формат_вывода}`. Значения можно менять в зависимости от пользователя, задачи или A/B-теста. Vellum, например, позволяет управлять такими параметрами через UI без изменения кода.
Шаг 3. Добавьте обратную связь в цикл
Если модель выдала неверный формат или пропустила обязательное поле, не отправляйте пользователю ошибку — отправьте модели исправленный промпт с указанием на проблему. Это называется self-correction loop и существенно повышает надёжность в production.
Где подход упирается в ограничения
Prompt-дизайн не панацея. Он требует более сложной инфраструктуры, большего количества тестов и понимания того, как разные модели обрабатывают динамические контексты. Не все задачи оправдывают такую сложность.
Для разовых генераций — письма, пост в блог, перевод — статический промпт остаётся эффективным. Anthropic в своих примерах показывает, что хорошо написанный одноразовый промпт справляется с 80% задач. Вопрос в том, что делать с оставшимися 20%, где требуется надёжность, адаптация под разные модели и интеграция с внешними данными.
Ещё одно ограничение — прозрачность. Когда промпт собирается из нескольких модулей, сложнее понять, почему модель выдала конкретный ответ. Отладка требует логирования всех промежуточных состояний, что не всегда удобно.
Что попробовать уже сегодня
Начать можно без DSPy и LangChain. Возьмите один часто используемый промпт в вашем проекте и разбейте его на три части: системная инструкция, динамический контекст (данные, которые меняются), формат вывода. Затем сделайте так, чтобы контекст подгружался из внешнего источника, а не лежал в коде.
Если используете API с поддержкой tools (OpenAI, Anthropic, Gemini), перепишите часть инструкций в виде tool definitions. Это даёт модели более чёткое представление о доступных действиях и часто улучшает точность выполнения — особенно в задачах, где модель должна выбрать, что делать дальше.
Prompt-дизайн — это не магия и не серебряная пуля. Это признание того, что LLM — не статичный калькулятор, а среда исполнения, которая требует проектирования, а не написания инструкций. И чем раньше мы перестанем относиться к промптам как к тексту и начнём относиться к ним как к коду, тем меньше будет сюрпризов в production.