Two-Stage Architect Pattern

Пишете один мега-промпт: «Будь креативным директором. Сгенерируй пять кинематографических концептов под этот продукт, на выходе JSON-массив с этими полями». Концепты возвращаются скучными и однородными — ограничение JSON-режима тянет модель к compliance, а та же температура, что дала бы интересную прозу, ломает схему. Поднимаете температуру — получаете интересные концепты и кривой JSON. Опускаете — JSON чистый, а концепты пресные. Один и тот же промпт просит LLM быть одновременно исследовательской и формально послушной.

Разделите работу. Один LLM-вызов — креативный директор: высокая температура, проза на выходе, без схемы. Второй LLM-вызов — технический архитектор: ниже температура, структурированный выход, без креативной нагрузки.

Это и есть two-stage architect pattern: креативное намерение и техническая генерация разделены между двумя отдельными LLM-вызовами с разными ролями, температурами и форматами выхода. «Креативный директор» (LLM) пишет прозу-концепты. «Технический архитектор» (LLM) превращает их в структурированные промпты для генератора.

Форма

Вход (дескрипторы, референсы, user intent)
   ↓
Стадия A — Креативный директор (LLM, высокая темп., проза)
   │       Роль: editorial / creative director
   │       Выход: N прозаических концептов в ОДНОМ общем окружении
   ↓
Стадия B — Технический архитектор (LLM, ниже темп., структура)
            Роль: технический prompt-инженер
            Выход: N промптов для генератора с явной структурой

Две стадии общаются через прозу, не через общую структуру данных. Выход Director'а — нарратив; вход Architect'а — этот нарратив плюс структурированная метаданность (позиции изображений, правила дескрипторов, ограничения).

Почему разделение важно

• Разные температуры хотят разных задач. Креативная генерация хочет 0.6–0.8; техническая форма — 0.3–0.5. Один LLM на одной температуре компрометирует и то, и другое.
• Разные роли хотят разных системных промптов. «Будь креативным директором» и «Будь техническим архитектором» тянут в противоположные стороны: один хочет исследовать, другой — соответствовать.
• Разные режимы отказа изолированы. Если концепты повторяются — это проблема Director'а. Если промпты выходят малформированными — это проблема Architect'а. Дебаг на шаг быстрее, чем с монолитным промптом.
• Общее окружение обеспечивается формой. Director выдаёт одно описание окружения; Architect получает его дословно. Continuity по веером раздаваемому выходу — структурное свойство, а не подсказка, спрятанная в длинном системном промпте.

Конкретный пример

Campaign-пайплайн, разворачивающий пять кадров из одного продуктового брифа:

• Стадия A (Креативный директор, темп 0.6): «Ты — креативный директор продуктовой фотографии. Сгенерируй 5 редакторских концептов под этот продукт, все в одном непрерывном окружении. Концепты отличаются действием субъекта и акцентами камеры; окружение остаётся тем же.»
• Стадия B (Architect, темп 0.5): «Ты — Architect промптов. Конвертируй эти 5 концептов в 5 структурированных промптов. Используй позиции IMAGE ORDER точно. Блоки разделены ^ на отдельной строке. Без преамбулы.»

Выход стадии A — ключевая опора общего окружения. Работа стадии B — формат, нумерация референсов и техническая дисциплина.

Композиция с другими архитектурами

• Director-стадия часто производит общее окружение, на котором работает continuity-правило последующих промптов.
• Architect-стадия часто выдаёт промпты в формате типизированной композиции референсов — каждый image-input генератора объявлен инлайн.
• Финальные промпты обычно оборачиваются Lock-слоем структурной фиделити перед попаданием в генератор.

Когда не использовать

• Single-shot-генерация без веера. Польза паттерна — раскинуть одно креативное намерение по многим технически дисциплинированным выходам. Один шот не нуждается в двух LLM-вызовах.
• Тесно связанные креативное и техническое измерения — например, компактные image-промпты, где нечего разделять.

Паттерн оправдывает себя там, где одно креативное направление веером раскрывается во много технически дисциплинированных выходов. Иначе — overhead.