Two-Stage Architect Pattern
The Two-Stage Architect Pattern
Разделение креативного намерения и технической генерации в LLM-пайплайнах
Автор: Alex Nix Статус: Рабочий черновик — for public release
Abstract
Большинство LLM-управляемых креативных пайплайнов используют один промпт для производства generator-ready-выхода — один системный промпт, одна температура, одна роль. Для маленьких задач этого достаточно. Для продакшн-задач — multi-shot-кампейнов, нарративных storyboard'ов, consistent-series-генерации — single-prompt-подход даёт предсказуемые сбои: креативная монотония, технические malformations, непрозрачность дебага. Ни одно из этого не является проблемой качества модели; это проблемы архитектуры.
Эта статья описывает Two-Stage Architect Pattern: разделить работу на Creative Director LLM (прозаические концепты, высокая температура, exploratory) и Technical Architect LLM (структурированные промпты, ниже температура, compliant). Паттерн — идея с высоты птичьего полёта (разделить что от как) с конкретными техническими свойствами, делающими его надёжным в продакшне. Статья называет эти свойства, режимы отказа, которые они предотвращают, и оставшиеся открытые вопросы.
1. Мотивация
Один LLM, попрошенный произвести N generator-ready-промптов под multi-shot-задачу, выполняет четыре работы:
- Сгенерировать N разнородных креативных концептов
- Решить, какие измерения объединяют набор (окружение, субъект, mood)
- Отформатировать каждый концепт как generator-ready-промпт (структура, нумерация референсов, ограничения)
- Сохранять дисциплину формата по всем N выходам
Каждая работа хочет разного LLM-поведения:
- Работа 1 хочет креативной широты: высокая температура, exploratory-промптинг.
- Работа 2 хочет когерентности: температура нормальная, но объединение должно быть заявлено заранее, а не переоткрываться на каждый шот.
- Работа 3 хочет compliance: низкая температура, жёсткий формат.
- Работа 4 хочет детерминизма: самая низкая температура, явный контракт выхода.
Один LLM-вызов умеет любую из этих работ хорошо. Делать все четыре в одном вызове — компромисс: креативные концепты выходят повторяющимися, промпты выходят malformed, или и то и другое.
Two-Stage Architect Pattern разделяет работу на два вызова, каждый из которых делает одну сторону хорошо.
2. Паттерн
Вход: дескрипторы, референсы, user intent
│
▼
Стадия A — Creative Director (LLM)
Роль: editorial / creative director
Темп.: 0.6–0.8
Выход: N прозаических концептов в ОДНОМ общем окружении
│
▼
Стадия B — Technical Architect (LLM)
Роль: технический prompt-инженер (например, A.O.C. architect)
Темп.: 0.3–0.5
Вход: проза стадии A + структурированная метаданность
(image positions, descriptor constraints, refTypes референсов)
Выход: N generator-ready-промптов с явной структурой
Две стадии общаются через прозу, не через общую структуру данных. Выход Director'а — нарратив; вход Architect'а — этот нарратив плюс структурная метаданность, которая нужна Architect'у для эмиссии формата.
Два свойства делают разделение оправданным
Чёткость роли. «Будь креативным директором» и «будь техническим prompt-архитектором» тянут LLM в противоположные стороны. Первая хочет исследования; вторая хочет соответствия. Системный промпт, просящий и то, и другое, читается как «будь креативным, но также будь жёстким» — это путаный мандат. LLM-ы выдают свою лучшую работу, когда роль узкая.
Совпадение температуры. Креативная генерация хочет 0.6–0.8 — достаточно variance, чтобы пять концептов осмысленно отличались. Structured-эмиссия хочет 0.3–0.5 — достаточно низко, чтобы дисциплина формата держалась по всем N выходам. Один LLM-вызов на одной температуре компрометирует оба конца.
3. Почему Director — несущий элемент для consistency
Конкретная работа Director'а — производить N концептов внутри одного общего окружения. Это ограничение «одно окружение» делает multi-shot-консистентность структурной, а не aspirational.
Стадия Architect downstream получает одно описание окружения и пишет все N шотов внутри него. Каждый шот варьирует камеру, кадрирование и действие субъекта; ни один не варьирует окружение, состояние света или время суток. Continuity-правило, которое было бы хрупким как per-shot-инструкция, становится несущим, потому что установлено один раз, выше по пайплайну, в прозе, которую Architect не может переинтерпретировать.
Если бы Director был пропущен и Architect был бы попрошен сгенерировать N шотов прямо из структурированных входов, Architect бы переоткрывал окружение на каждый шот — дефолтное поведение LLM, когда его просят написать пять разных шотов, — дифференцировать по каждому доступному измерению, включая те, что должны были быть общими.
Director — это механизм, убирающий «дифференцировать по каждому измерению» из decision-space'а Architect'а.
4. Почему Architect — несущий элемент для формата
Конкретная работа Architect'а — эмитить N промптов в строгом формате: блоки заданной структуры (например, Anchor / Optics / Chemistry; см. aoc-framework-paper), разделённые низкоэнтропийным разделителем, с явной нумерацией референсов, без преамбулы, без markdown.
Креативный директор, попрошенный делать и это, выдаёт примерно 70% well-formed-выхода. Блоки уплывают по длине. Разделители варьируются. Номера референсов становятся «творческими». LLM возвращается к разговорному инстинкту, потому что именно это тренировало «creative director».
Лоwer температура Architect'а и узкий системный промпт дают примерно 98% well-formed-выхода. Оставшиеся 2% ловятся парсингом на выходе и retry'атся.
Соответствие формату — это то, что делает возможным автоматизированный пайплайн. 70% парсится в хрупкий пайплайн; 98% — в надёжный.
5. Дизайн-свойства, делающие паттерн надёжным
Дисциплина разделителя
Выход Architect'а — это N блоков, разделённых низкоэнтропийным разделителем — символом или последовательностью, которая правдоподобно не появится внутри блока. Литеральный ^ на отдельной строке — один рабочий выбор. ---, ### или JSON-массив-формат — альтернативы. Дисциплина: разделитель должен быть символом, который LLM не произведёт внутри блока, чтобы парсинг был тривиальным.
Явное позиционирование image / reference
Когда референсы прикреплены, системный промпт Architect'а включает секцию IMAGE ORDER (или эквивалент), перечисляющую референсы по позиции. Выходной промпт должен ссылаться на них по этим позициям. Паттерн избегает того, чтобы Architect изобретал reference-метки, которые последующие стадии затем должны переотображать.
Объявленные fallback'и
Когда референс, ожидаемый Architect'ом, отсутствует (нет background-референса, нет style-референса), Architect должен инлайн объявить fallback в каждом эмитируемом промпте. Молчаливая подстановка (LLM заполняет правдоподобное окружение, не сказав об этом) ломает downstream-дебаг. Объявленные fallback'и («no background reference provided; environment drawn from the Creative Direction») сохраняют trace.
Sweet spot температуры на 0.5
Из наблюдений: 0.5 — правильная температура для Architect-стадии. Выше — недисциплинированный выход; ниже — N почти одинаковых промптов. Стадия Creative Director выше по пайплайну работает на 0.6–0.8, чтобы дать тот variety, который Architect затем формализует.
6. Режимы отказа, которые паттерн предотвращает
| Сбой | Single-stage-симптом | Two-stage-решение | |---|---|---| | Креативная монотония | Все N шотов описывают лёгкие вариации одной сцены | Director производит разные концепты выше; Architect только формализует | | Дрейф формата | N промптов следуют N разным структурам | Узкая роль Architect'а + низкая температура + явный контракт | | Расхождение окружения | N шотов живут в N слегка разных локациях | Director производит одно окружение; Architect наследует его дословно | | Reference-галлюцинация | Промпты ссылаются на Image 4, когда есть только 3 | Секция IMAGE ORDER Architect'а + температура соответствия | | Непрозрачность дебага | У плохого выхода нет ясного слоя происхождения | Сбои изолируются к Director'у (креативное) или Architect'у (формат) | | Длинный системный промпт | Один системный промпт должен покрыть все заботы | Системный промпт каждой стадии короткий и сфокусированный |
7. Когда не использовать паттерн
- Single-shot-генерация. Польза паттерна — раскинуть одно креативное намерение по многим техническим выходам. Один выход не нуждается в двух вызовах.
- Задачи с тесно связанными креативно-техническими решениями. Некоторые задачи генерации чисто не разделяются на «что» и «как» — компактные краткие промпты, short-form creative writing, некоторые случаи code-generation. Паттерн добавляет overhead без выгоды.
- Раннее прототипирование. Разделение пайплайна на две стадии добавляет операционную сложность (два LLM-вызова, два системных промпта в сопровождении, больше поверхность отказов). Для ранней эксплорации хватает одного промпта.
8. Обобщения за пределы image-промптов
Паттерн — Director эмитит intent, Architect эмитит structure — применим к любому multi-output-LLM-пайплайну, где креативность и compliance находятся в напряжении:
- Генерация тестовых кейсов. Director: «emit 20 diverse test scenarios across this input surface». Architect: «reformat each into the test-framework's structured representation».
- Variant-синтез под UI. Director: «generate 8 distinct layout concepts that satisfy these constraints». Architect: «emit each as valid component markup».
- Генерация документации. Director: «outline 5 narrative angles on this feature». Architect: «expand each into the docs-site's markdown schema».
- Code-refactor-планирование. Director: «describe 3 refactor approaches in prose». Architect: «emit each as a structured diff plan».
- Agentic action-planning. Director: «consider 3 possible next-action strategies». Architect: «emit each as a concrete tool-call sequence».
Общая форма: N разнородных выходов, консистентных по каким-то измерениям, дисциплинированных по формату. Везде, где работа чисто разделяется по этой оси, разделение LLM-вызова окупается.
9. Открытые исследовательские вопросы
- Three-stage-варианты. Есть ли ценность в средней стадии (Producer? Editor?) между Director и Architect — например, согласовывающей N концептов Director'а с consistency-бюджетом до того, как они дойдут до Architect'а? Продакшн-имплементации обычно делают это внутри Architect'а; формальная средняя стадия могла бы изолировать заботу.
- Architect-only-ретраи. Когда Architect эмитит malformed-выход, retry только Architect'а (без повторного вызова Director'а) — очевидное восстановление. Но не вводит ли это восстановление креативное смещение со временем? Не проверено.
- Калибровка температуры Director'а. 0.6–0.8 — это наблюдение. Контролируемое исследование разнообразия концептов × rater-качества по температурам именно для Director-стадии было бы полезно.
- Эмуляция одним LLM. Может ли один LLM на одной температуре эмулировать two-stage-паттерн при достаточно структурированном chain-of-thought? Неформально: да, плохо. Формально: стоит измерить.
- Кросс-задачное обобщение. Паттерн хорошо работает для image-промптов и хорошо структурированных задач генерации. Обобщается ли он на высоко-креативные задачи (fiction, poetry) или «креативное / техническое» — слишком грубое разделение там?
10. Заключение
Two-Stage Architect Pattern — это маленький архитектурный ход, покупающий много надёжности. Разделение креативного намерения и технической эмиссии на два LLM-вызова — с подобранными температурами, подобранными ролями и прозаической передачей между ними — убирает четыре категориальных режима отказа (креативная монотония, дрейф формата, расхождение окружения, непрозрачность дебага), которые single-stage-пайплайн стабильно производит.
Это не silver bullet. Добавляет операционную сложность и расточителен для single-output-задач. Но для продакшн-пайплайнов, которые должны производить много выходов с общим креативным намерением и жёстким соответствием формату, этот паттерн — наименьшее обязательство, которое надёжно работает.
Цитирование
Nix, A. (2026). The Two-Stage Architect Pattern — Separating Creative Intent from Technical Generation in LLM Pipelines. Working paper.