Типизированная композиция референсов: у каждой картинки одна работа

Ваш пайплайн прикрепляет к генератору четыре референса: человек, поза, фон, одежда. Пишете промпт: «субъект в этой позе, в этой одежде, на этом фоне». Модель тянет одежду с референса человека и с референса одежды. С референса позы заодно цепляется причёска. С фона — посторонняя фигура. Промпт не сказал модели «используй референс 4 только для одежды, всё остальное в нём игнорируй» — она и не игнорировала. И диагностировать, какой именно референс вызвал какое загрязнение, нельзя, потому что все четыре были молчаливыми соавторами.

Исправлять нужно, давая каждому референсу явную типизированную роль и объявляя эту роль внутри текста промпта, который читает генератор — чтобы модель никогда не угадывала, какой референс отвечает на какой вопрос.

Типизированная композиция референсов — это промпт-архитектура для multi-input-генерации, в которой каждый референс несёт явную типизированную роль, а текст промпта инлайн называет, какой референс закрывает какое измерение. Останавливает silent-reference-галлюцинацию у источника.

Форма

Входные референсы
├── Image 1 → refType: "identity"       (лицо, тело, тон кожи — игнорировать одежду/фон)
├── Image 2 → refType: "pose"           (положение тела — игнорировать внешность/одежду/локацию)
├── Image 3 → refType: "background"     (окружение — игнорировать субъектов)
├── Image 4 → refType: "clothing"       (форма одежды, ткань, цвет — игнорировать модель в ней)
└── Image 5 → refType: "product"        (форма объекта, ориентация, текст — игнорировать контекст)

Системный промпт:
  IMAGE ORDER
  ─────────────
  Image 1: Identity reference
  Image 2: Pose reference (pose only — ignore person)
  Image 3: Background reference
  ...

  RULE: In every prompt, state explicitly which image contributes what.
  RULE: Do not use image numbers that don't exist in IMAGE ORDER.

Выдаваемый промпт (для генератора):
  "... using Image 1 for identity (face/body/skin), Image 2 for pose only
   (ignoring the person depicted), Image 3 for environment (ignoring any
   subjects present), ..."

Три несущие части

1. refType — типизированная роль на референс. Тип называет, какие измерения референс предоставляет, и косвенно — какие нет.
2. IMAGE ORDER — позиционная декларация, разделяемая между системным и выдаваемым промптами. Даёт каждому референсу стабильную явную идентичность.
3. Inline-декларация — LLM получает инструкцию называть внутри каждого промпта, что делает каждый прикреплённый референс. Никакого молчаливого использования.

Все три несущие. Уберите любую — silent-reference-галлюцинация возвращается.

Почему работает

Генеративные image-модели, получая N референсов, используют их все — в этом и смысл conditioning. Проблема не в «слишком много референсов», а в «нет инструкции, какой референс отвечает на какой вопрос». Референс одежды, который заодно содержит модель, становится вторым источником identity, пока явно не типизирован как clothing-only.

Паттерн превращает неявный контракт «use these images however seems sensible» в явный «Image 2 — это pose only, ignore the person depicted». Модель всё ещё делает judgment calls, но в гораздо более узком пространстве.

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

• Нетипизированное прикрепление референса. Референс без объявленной роли трактуется моделью как «use however seems relevant» — и тихо тянет не то измерение. Лечится: каждый референс получает refType на этапе ingest.
• Неявная типизация через позицию. «Image 1 — это всегда identity» ломается, когда некоторые пользователи не прикрепляют Image 1. Явный IMAGE ORDER с текущим состоянием на каждый вызов — несущий.
• Декларация только в системном промпте, не в выдаваемом. Если LLM знает про refType, но не пишет его в выходной промпт, генератор на следующей стадии это не видит. Инлайн-декларация — это то, что доходит до модели, которая важна.

Композиция

Паттерн чисто стыкуется с большими архитектурами:

• Часто оборачивается Lock-слоем, который повторяет IMAGE REFERENCE MAP в начале каждого финального промпта — типизация доходит до генератора на каждом вызове, не только в начале сессии.
• Обычно производится Architect-половиной каскада «креативный директор → технический архитектор».
• Композируется с reference-condensation: много типизированных референсов можно слить в один связный композитный референс, чтобы снизить attention-нагрузку.

Single-shot-имплементация паттерна — mixed-prompt-composition-builder — явная типизация identity / pose / background / clothing / product / technical в одном композитном промпте.

Обобщается за пределы image-генерации

Любой LLM-флоу, принимающий несколько типизированных входов, выигрывает:

• Code generation из нескольких файлов-контекстов — spec / test / existing module, у каждого объявлена роль.
• Document synthesis из нескольких источников — primary / supporting / rebuttal.
• Tool-using агенты с несколькими источниками данных — у каждого источника объявленная роль на этапе ingest.

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