Template-Dispatch Prompts

Есть один системный промпт, закрывающий четыре кейса. Потом шесть. Потом десять. Каждый новый кейс добавляет абзац правил «если X — то Y; если Z — то W». Промпт перерастает страницу. Очередной кейс приземляется и ломает правило, которое, как вы думали, принадлежало другому кейсу. Качество выхода расходится: LLM выбирает не тот кейс, применяет правильное правило слабо или тихо смешивает два. Когда что-то идёт не так, непонятно, ошибся ли LLM в выборе кейса или в применении его правил — поверхность для диагностики это один большой промпт.

Выход — не заставлять один промпт делать всё. Выбирать нужный промпт до LLM-вызова, по типизированному флагу. Каждый кейс получает свой короткий фокусированный промпт; LLM не видит логики ветвлений вообще.

Это и есть template-dispatch: типизированные флаги диспатчат на разные варианты системного промпта или разные заранее написанные template-строки, вместо одного универсального промпта, пытающегося обработать всё. Диспатч происходит в коде, до LLM. Каждый диспатченный вариант достаточно маленький, чтобы его реально читать.

Форма

Типизированный вход
  shot.type = "composite"
     │
     └──→ выбрать вариант system-prompt: "composite_system_prompt"
              (описывает ТОЛЬКО передний субъект; окружение из vision)
     └──→ выбрать формат user-prompt: "composite_user_format"

Типизированный вход
  product.categoryId = "clothing-shoes"
  product.visualizationId = "on-model"
     │
     └──→ выбрать template: PRODUCT_TEMPLATES["clothing-shoes"]["on-model"]
              (заранее написанный промпт с плейсхолдерами под детали продукта)
     └──→ заполнить плейсхолдеры из метаданных продукта
     └──→ передать генератору (без LLM-вызова, если template полностью специфицирован)

Почему диспатч, а не один универсальный промпт

Один промпт, пытающийся закрыть все случаи, становится:

• Длинным — правила всех случаев должны жить в системном промпте.
• Неоднозначным — LLM выбирает, какие правила применять, по нечётким сигналам.
• Хрупким — добавление нового случая рискует тронуть существующие.
• Тяжёлым в дебаге — когда выход неверный, это был выбор кейса или правила кейса?

Диспатч раскладывает задачу:

• Каждый вариант маленький и фокусированный.
• Кейсы независимы по конструкции; новый не трогает существующих.
• Когда выход неверный, диспатченный вариант изолирован и легко осматривается.
• Системные промпты достаточно короткие, чтобы их реально читать.

Оси диспатча на практике

Shot-type-диспатч (в видео-продакшн-пайплайне):

• full-ai → описать кадр целиком
• composite → описать только foreground-субъект; окружение приходит из vision / live-материала
• live → всё ещё выдаём редакторский промпт как редакторскую подсказку, но не диспатчим image-job

Category × visualization-диспатч (в продуктовом каталоге):

• 7 категорий (clothing-shoes, accessories, food-beverages, cosmetics, electronics, home, other)
• 3–4 визуализации на категорию (on-model, flat-lay, in-store, catalog-studio, overhead, lifestyle, studio, …)
• ~28 шаблонов всего

Шаблоны могут быть чистыми string-fill (без LLM) для детерминированных выходов, либо LLM-fill со структурированным контекстом, когда нужна творческая свобода.

Когда диспатчить

• Когда кейсы отличаются тем, что описывают. Composite-шоты описывают только foreground; full-ai-шоты — весь кадр. Это реальное различие, не стилистическая вариация.
• Когда у кейсов независимые наборы правил. Studio-шоты косметики имеют другие композиционные конвенции, чем on-model-шоты одежды.
• Когда ожидается рост каталога. Добавление новой категории продуктов должно быть локальной правкой одного шаблона, не рефактором единого промпта.

Когда не диспатчить

• Когда варианты отличаются незначительно. Если изменение правила — это «добавь одно предложение», это параметризация, не диспатч.
• Когда кейсы fluid и user-defined. Тогда кейсы лучше выразить как типизированную композицию, чем как template-диспатч.

Режимы отказа

• Расползание шаблонов. 28 шаблонов превращаются в 128, и поддержка коллапсирует. Контрмера: review-проход по каталогу раз в ~6 месяцев; near-duplicates обратно в параметризации.
• Неправильный диспатч. Типизированный флаг неверно установлен на предыдущем этапе, запускается не тот шаблон, выход тонко неверный. Контрмера: выносить имя выбранного шаблона в выход для observability.
• Дрейф шаблона от реальности. Заранее написанный шаблон для «clothing × on-model» не соответствует текущим визуальным трендам. Контрмера: шаблоны версионируются и ревьюятся; пересобирать посезонно, а не давать им гнить.
• LLM игнорирует диспатч. Если шаблон передан как один из нескольких внутри длинного системного промпта, LLM может проигнорировать диспатч. Контрмера: диспатч происходит до LLM-вызова; LLM видит только выбранный вариант.

Обобщается широко

• Tool-using-агенты. Каждый инструмент получает свой микро-системный промпт при вызове, не единый «вот все 200 инструментов».
• Domain-specific-чат-ассистенты. Юридическая / медицинская / финансовая вариации одного базового ассистента, диспатченные по domain-флагу.
• Form-generators. Каждый тип формы получает свой промпт, не одна универсальная form-generating LLM.
• Language-specific генерация. Per-language варианты промпта, диспатченные по локали, вместо одного multilingual промпта.

Сам паттерн: когда кейсы реально отличаются, дайте каждому свой фокусированный промпт; диспатчите до LLM-вызова, а не внутри него.