Alice AI ART 2.0: путь к unified‑модели, которая одинаково хорошо умеет генерировать и редактировать картинки

Привет, Хабр! На связи команда генеративных моделей в компьютерном зрении. Вместе с другими командами мы делаем мультимодального ассистента Алиса AI. Внутри него мы развиваем несколько вариантов визуальной генерации с помощью отдельной модели Alice AI ART. Два базовых сценария её работы — генерация по тексту (Text‑to‑Image, T2I) и редактирование по картинке с инструкцией (Image‑to‑Image, I2I). Именно о них пойдёт речь. 

Всё это время эти сценарии жили как два разных стека: свои базовые модели, свои данные, свои метрики и, честно говоря, своя отдельная боль в разработке и поддержке.

В этом году мы поставили себе цель, которая звучала просто, а на практике оказалась полугодовым приключением: не только подтянуть качество, а сделать одну модель, которая одинаково хорошо умеет и в T2I, и в I2I. Внутри мы называем такой режим unified или просто uni. Вас ждёт рассказ об отдельных экспериментах и наблюдениях, которые помогли нам сделать первый шаг в этом направлении и привели нас к Alice AI ART 2.0, — включая те, которые красиво не сработали (спойлер: их хватало).

Откуда мы стартовали и куда идём

Предыдущее поколение нашего генератора (Alice AI ART 1.0) можно назвать классическим T2I‑стеком — диффузионный свёрточный генератор с текстовым энкодером на базе LLM. Редактирование же жило рядом, на своих базовых моделях и своём пайплайне инференса. Эта раздвоенность стоила дорого: любое улучшение приходилось дважды переносить, данные готовились по‑разному, метрики T2I и I2I было тяжело сравнивать между собой, стадии обучения дублировались и были рассогласованы.

В какой‑то момент мы осознали простую вещь: пора не догонять самих себя двумя параллельными направлениями, а собрать единый фундамент. 

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

Но перед тем как обсуждать технические детали объединения, давайте сначала договоримся о том, что понимать под качеством.

Как мы измеряем качество

Прежде чем говорить о метриках, поговорим о том, на чём мы вообще их измеряем. И для T2I, и для I2I мы собираем основные корзины (main baskets) из реальных пользовательских запросов в Alice AI, Шедевруме и других продуктах, где работают наши модели. Эти корзины примерно повторяют распределение запросов в проде, но с небольшими поправками: мы чуть корректируем его под ожидаемое будущее распределение и вычищаем ошибочные запросы (например, те, что на самом деле должны были уйти в VLM, а не в генератор).

В I2I вместе с промптом приходят и картинки пользователей. Чтобы полностью исключить любую работу с персональными данными, которые пользователь мог прислать, мы целиком заменяем эти изображения снимками из открытых источников, стараясь сохранить их основные характеристики — качество, разрешение и суть содержимого.

Из обработанного набора запросов мы нарезаем по три выборки для T2I и I2I:

• Validation используется чаще всего — это рабочая корзина для повседневных экспериментов. 

• Test — своего рода hold‑out. К нему мы обращаемся раз в несколько недель, чтобы отследить реальный прогресс и убедиться, что не переобучились на validation. 

• Deploy трогаем ещё реже — только чтобы оценить качество предрелизных моделей. 

Все три и есть те самые основные корзины (main baskets) — ядро нашей аналитики.

В каждом наборе основных корзин — 500 примеров для T2I и 1000 для I2I. Разница в размере не случайна: в редактировании нужно покрыть заметно больше сценариев, и, если урезать корзину до 500, некоторые категории схлопнулись бы буквально до нескольких примеров.

Но даже 1000 примеров не всегда спасают. К тому же часть категорий запросов нам особенно важны — там, где мы рассчитываем принести пользователю больше всего пользы. В этом году это были любые манипуляции с текстом и с людьми на фото, а для I2I — ещё и стилизация. Под такие случаи мы завели отдельные корзины — слайсы (slices), в которых намеренно оверсэмплим специализированные категории, чтобы плотно следить за их качеством и растить его.

Примеры из всех корзин уходят в разметку — асессорскую или автоматическую — по критериям качества, о которых речь пойдёт ниже; у отдельных аспектов (например, у леттеринга) есть свои специализированные корзины. Иногда мы поглядываем и на академические бенчмарки, но неохотно: их относительно легко хакнуть, а оценки на них часто плохо коррелируют с тем качеством, которое реально видит пользователь.

Метрики T2I и I2I

Прежде чем сыпать числами, договоримся, что именно мы измеряем. Само собой, для T2I и I2I оси качества разные.

В случае T2I (текст → картинка) мы уделяем наибольшее внимание общему предпочтению пользователей и точному следованию запросам в целом. Отдельно выделяем аспект качества генерации текста — леттеринг (lettering).

Для I2I (картинка + инструкция → картинка) важно следить не только за изменениями, но и за сохранением того, что не должно меняться, поэтому система метрик немного отличается. Мы продолжаем внимательно следить за качеством исполнения запроса, но добавляем условия для сохранения черт исходного изображения и низкой дефектности изменённых регионов.

Ранжировать модели сразу по нескольким метрикам неудобно, поэтому как основной сигнал качества в T2I мы рассматриваем предпочтения, а в I2I мы считаем результат как минимум по каждому из критериев. Например, если дефектность и релевантность хорошие, но сохранение плохое, общий результат будем считать плохим.

Всё это считается либо с помощью асессорской разметки, либо автоматически через reward‑модели или VLM‑судью. И везде, где можно, мы смотрим на доверительные интервалы: на небольших корзинах разница в пару процентов часто оказывается просто шумом.

Чего мы хотели от нового релиза

Во‑первых, нам хотелось поднять качество отдельно в T2I и в I2I. 

В T2I мы целились на рост релевантности и отрисовки текста на картинке. В I2I старались поднять общее качество, но с акцентом на важных для наших пользователей задачах: любые изменения с участием людей и стилизация.

Во‑вторых, мы преследовали технологическую цель: свести две модели в одну.

Но тут важно помнить, что отдельное использование моделей по каждой задаче — это ещё и честный потолок качества. Если объединённая модель не будет качественно дотягивать до работы отдельной на её же задаче, значит, за объединение мы платим слишком дорого. 

Детали обсудили: теперь можно переходить к главному герою — unified‑модели.

Unified: зачем, почему и как 

Идея unified‑претрейна простая: показывать модели в одном обучении — и пары «текст → картинка», и тройки «картинка + инструкция → картинка». Гипотеза строится на том, что общий визуальный и текстовый прайор перетекает между задачами.

I2I‑задача редактирования по своей природе требует от модели понимания референса: входное изображение всегда содержит конкретный объект или сцену, которые нужно сохранить, трансформировать или дополнить. Чтобы корректно применить инструкцию («сделай стул деревянным», «замени фон»), модель должна научиться точно кодировать визуальное содержимое — форму, текстуру, пространственные отношения — и удерживать эти детали при генерации. Навык «читать картинку» напрямую улучшает и общее визуальное восприятие модели. 

T2I‑данные, в свою очередь, подтягивают релевантность. Промпты для генерации с нуля, как правило, значительно богаче и детальнее editing‑инструкций — они описывают всё, что должно быть на изображении, включая освещение, стиль, атмосферу, композицию. Модель, обученная воспроизводить такие развёрнутые описания, вырабатывает более глубокое понимание языка и его связи с визуальными элементами. Инструкции к редактированию, напротив, более короткие и локальные («добавь шляпу»), поэтому без T2I‑данных этот аспект прокачивается слабо.

А ещё через T2I проще расширить у модели понимание концептов. Под концептом мы понимаем любой именованный или безымянный объект, персонаж, свойство или стиль, с которым можно сопоставить визуальное воплощение: стул — концепт, «деревянная текстура» — концепт, Илон Маск — концепт, «арт‑декор» — концепт. То есть концепты — это единицы семантики, которыми оперирует модель при связывании текста и изображения. Это свойство входит в релевантность, хотя рассматривать его можно и отдельно.

Что изменилось в самой модели

Объединяя задачи, мы заодно сменили backbone генератора. Раньше это была свёрточная модель: она давала прекрасный размен вычислительной сложности обучения и инференса с качеством. Но добавлять в неё картиночный кондишен — та ещё боль. Для экспериментов с единой unified‑моделью мы перешли на близкий к ванильному MMDiT трансформер с single‑stream‑архитектурой. 

Ключевые архитектурные решения:

• Joint attention — текстовые и визуальные токены идут через общий attention, а не двумя раздельными ветками.

• U‑RoPE — позиционное кодирование, дружелюбное к разным разрешениям и к конкатенации картинка + текст (что особенно важно для I2I).

Single‑stream‑трансформер оказался довольно удобен для unified‑модели. И текст, и опциональная входная картинка — это просто токены в одной последовательности, поэтому одна архитектура без переделок обслуживает оба сценария.

А ещё мы увеличили размер модели относительно прежней свёрточной — стало больше ёмкости под совмещённую задачу T2I + I2I.

Как мы учили uni‑модель

Пайплайн обучения unified‑модели разделён на три этапа: 

• Претрейн (PT). 

• Supervised fine‑tuning (SFT). 

• Дистилляция для ускорения инференса. 

Ключевая особенность сетапа — общий для обеих задач претрейн. T2I‑ и I2I‑данные перемешаны в одном обучении, чтобы визуальный и текстовый прайоры были едиными. Флагманский unified‑прогон мы обучали, сохраняя промежуточные чекпойнты и гоняя на них полный набор замеров.

Во время долгих претрейнов полезно наблюдать динамику по ходу обучения, оценивая качество промежуточных чекпойнтов. При этом есть известная проблема: качество претрейн‑чекпойнта по многим метрикам может не согласовываться с тем, что получится после полного пайплайна PT → SFT → Distill. Для решения этой проблемы мы искали устойчивые к изменению качества метрики и обнаружили, что довольно неплохо можно ориентироваться на качество отрисовки текста. 

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

Кстати, lettering рос не сам по себе — под него мы отдельно готовили данные. Собрали выделенные датасеты с текстом для русского и английского языков, добавили синтетику с надписями через шаблонизацию и отдельный текстовый инпейнтинг. Удобно, что эта метрика достаточно устойчивая и быстрая в замере.

Однако не всё было гладко. Например, на одном из ранних чекпойнтов мы поймали странный артефакт: по леттерингу вроде всё хорошо, по парным сравнениям предпочтения — тоже, но генерации внезапно стали чуть более «блюрными». Так что, к сожалению, полностью доверять претрейн‑метрикам нельзя — надо всегда смотреть на результаты глазами и по возможности проводить дообучения SFT и distill для промежуточных чекпойнтов.

Главный аргумент за uni: перенос знаний из T2I в I2I

Самый показательный эксперимент и, собственно, то, ради чего всё затевалось. 

Мы взяли набор концептов, которые отсутствовали в наших данных для редактирования, но которые ранее собирались для T2I. Для наглядности выбрали ру‑специфику: самовар, хохлома, изба, Красная площадь, собор Василия Блаженного, двуглавый орёл. Затем подмешали немного T2I‑данных в совместное обучение и проверили, что станет с I2I.

Результат оказался такой, на какой мы и надеялись: концепты, выученные из T2I, становятся доступны в редактировании по инструкции. Запросы, явно включающие специфические концепты, начинают работать без необходимости повторять работу по сбору узких срезов данных.

Знания переносятся в режим редактирования: даже если модель уже что‑то знала о концепте, его качество в editing улучшается. И чем больше релевантных T2I‑данных в обучении, тем лучше перенос. Сейчас это наш главный практический довод в пользу unified‑моделей.

Архитектура: от LLM‑ к VLM‑энкодеру текста

Параллельно мы работали и над той частью, которая кодирует пользовательский текст для генератора. Исторически это был LLM‑энкодер. Гипотеза состояла в том, что VLM‑энкодер, видевший и текст, и картинки, даст лучшую текстовую релевантность — и особенно поможет с генерацией текста. 

Технически замена выглядела так: берём базовый претрейн, выкидываем старые проекторы под энкодеры, ставим новые под другие размерности и сначала учим только их (адаптация проектора), а потом дообучаем всю модель. 

И вот тут нас ждал поучительный провал.

В первый заход мы инициализировали новые проекторы из N(0, 1). Результат был описан в комментариях к тикету предельно честно: «Экспы плохие, неправильный скейл параметров при инициализации».

Лечение мы нашли не в магии, а в аккуратности: подобрали масштаб инициализации под оригинальный проектор — около N(0, 0,038) — и динамика сразу стала здоровой. 

После фикса английский леттеринг по ходу адаптации энкодера рос монотонно, но уверенно: 0,40 → 0,55 → 0,60.

Промптилки: чиним запрос ещё до генератора

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

О том, какая форма удобна генератору, выходило несколько работ, например Structured Captions и Design Choices for Synthetic Captions. Консенсус: промптинг должен быть структурированным, то есть порождать JSON‑подобные структурированные описания, однозначно определяющие задачу для генератора. У этого формата представления текстов много плюсов: уменьшение энтропии информации в запросе, доуточнение деталей, ризонинг. 

Помимо статей, о пользе подхода говорят провайдеры проприетарных моделей. Например, в недавнем посте о модели Ideogram 4.0 авторы выделяют специальную главу про Structured JSON prompting.

Основной компромисс этого подхода и понятный, и неожиданный одновременно — качество против длины. Длинный переписанный промпт лучше с точки зрения релевантности, но это лишние токены, которые делают генерацию дороже. Поэтому мы целенаправленно резали лишние поля и сокращали выход. Сейчас мы, согласно схеме вначале, используем разные промптилки для T2I и I2I, но также видим потенциал в их объединении.

Промптилка — недооценённый рычаг. В экспериментах мы получали рост до 9% доли хороших редактирований (согласно описанной выше схеме оценки). Он объясняется по большей части ростом релевантности (до 12%). Увеличение достигалось просто за счёт переписывания запросов, без изменения генератора. Это больше, чем многие эксперименты с моделью и данными.

Где мы среди конкурентов: рейтинг Bradley — Terry

Напоследок — главное: как наша модель смотрится на фоне аналогов. 

Для удобства и единообразия сравнений с внешними моделями мы собрали попарные сравнения side‑by‑side с помощью асессорской разметки и свели их в единый рейтинг по модели Брэдли — Терри. Логика как у шахматного Эло: чем больше число, тем чаще модель выигрывает парные сравнения. 

Значения в таблицах отцентрированы примерно около 1000, в квадратных скобках — 95%‑й доверительный интервал. Все модели сравнивались на одном наборе запросов и по одной методике разметки. Генерацию (T2I) и редактирование (I2I) считали отдельно.

Генерация по тексту (T2I)

По генерации мы уверенно вторые: впереди только Gemini 3.1 Flash. Приятно и то, что новая модель ощутимо обогнала прошлый релиз (≈ 979 → 1051). 

Редактирование (I2I)

В редактировании поле плотнее. Модели со второй по пятую строчки лежат в пределах доверительных интервалов друг друга, так что борьба идёт буквально за единицы пунктов. По итоговому Result мы в этой плотной группе (≈ 1009), а по Relevance (следованию инструкции) уступаем только Nano Banana 2. То есть мы лучше всех остальных публичных моделей делаем именно то, что просит пользователь. Там же видна и зона роста: Preservation (сохранение нетронутых частей) пока средняя — это наш следующий приоритет.

Асессорские замеры — это хорошо. Но как рост качества влияет на наших пользователей? Модель уже работает в Alice AI, и мы видим, что пользователям она нравится. Например, количество скачиваний результатов генераций и редактирования заметно подросло. Эффект особенно заметен на срезах работы с текстом (генерация с текстом или его удаление / добавление на картинку) — здесь скачивания выросли на 37%. Другая интересная динамика — изменение распределения между задачами. Мы научились лучше генерировать изображения с заданным персонажем — количество подобных запросов увеличилось на 23%. 

Что не взлетело

Раздел, который мы любим больше всего. Не каждая гипотеза обязана выстреливать, и честный список тупиков экономит время для следующих экспериментов.

Ревизитинг model merging (супов), про который мы рассказывали раньше. В наших прошлых экспериментах наивный подход с усреднением весов дал существенные приросты качества. Мы решили сделать отдельное большое исследование более сложных методов. 

Главный вывод не самый очевидный: несмотря на явное превосходство супов над отдельными SFT, более продвинутые методы вели себя нестабильно. Почти всегда находился метод, побеждающий наивное усреднение, но ни один из них не показал себя лучше в абсолюте. То есть умные методы слияния, выигрывающие в других доменах, на диффузии не способны стабильно побеждать «наивное среднее».

Под более сложными методами здесь имеем в виду целое семейство техник слияния: TIES, DARE, DELLA, Breadcrumbs, KnOTS, Iso‑CTS, RegMean. Мы проверяли их на нескольких открытых моделях (SD1.5, SDXL, SD3.5M) и разных наборах данных. 

Полезный побочный вывод: супы стабильно обходят SFT на смеси датасетов почти по всем метрикам, то есть смешивать веса всё равно стоит. Более умные методы могут улучшить результат, но делать ли перебор с ними — зависит от бюджета на инференс и аналитику.

Претрейн в высоком разрешении. Другой неудачный эксперимент был связан с претрейном сразу в высоком разрешении. Исторически, ради экономии вычислительных ресурсов, мы начинали обучать модели в разрешениях 256px или 512px, увеличивая его только на более поздних стадиях. Решение логичное для T2I, поскольку на изображениях такого разрешения уже содержится вся основная информация, а научиться доуточнять её можно и за файнтюн. 

Однако I2I заметно отличается по своей природе: часто требуемые изменения могут быть локальными и затрагивать небольшие участки картинок. При этом важные для сохранения регионы также могут быть небольшими, например лица людей, особенно на заднем плане. Мы были готовы потратить больше вычислений на улучшение качества в этом месте.

К сожалению, увеличение разрешения до порядка 1024px не привело к существенному улучшению в этих местах. Возможно, подобные проблемы можно пролечить таргетированным сбором данных, увеличением капасити модели или специальными трюками для улучшения локального качества.

Что дальше

Сейчас у нас в работе несколько направлений:

• Полная унификация. Объединение файнтюнов дистиллов и промптилок должно помочь получить ещё больше синергии и упростить продуктовый пайплайн.

• Более полная интеграция. Alice AI становится умнее с каждым днём, в её арсенале появляются новые тулы, а старые становятся удобнее и мощнее. Мы можем лучше интегрироваться с ними для ещё большего улучшения пользовательских сценариев.

• FP8 и дешёвый претрейн. Смотрим в эту сторону, чтобы итерации по uni‑данным стоили меньше.

Ещё год назад у нас было две модели, два стека и две метрики. Каждое улучшение приходилось переносить дважды, а любая правка данных отзывалась в двух местах сразу. Сейчас — одна модель, одна аналитика и общий фундамент для генерации и редактирования: то, что мы прокачиваем в T2I, теперь работает и в I2I, и наоборот. И что приятно, довольно длинный список того, что мы попробовали и ещё будем пробовать.

Но главный тест для модели — не бенчмарки, а руки пользователей. Alice AI ART 2.0 уже работает в Алисе AI и Шедевруме: можно сгенерировать картинку с нуля по тексту и отредактировать свою по инструкции. Забирайте, пользуйтесь и присылайте кейсы, где модель справилась хуже, чем вы ожидали, — именно из таких примеров вырастает следующая итерация. 

Источник: habr.com