Forwarded from Ai molodca (Dobrokotova)
Как победить это сообщение в VEO3. Мой опыт.
Кто уже генерит в VEO, через раз сталкивается с этим сообщением. Спустя $350 и кучу нервов я, кажется, нашел решение.
Соль: чтобы ваш промт с русской озвучкой прошел, достаточно простого советского... ~650 символов в промте и выше. Все, что меньше — не проходило. Вот и весь секрет (нейроинфоцыгане — сорри).
Дописывайте промт любой LLM'кой, делитесь результатами — вдруг это только у меня работает.
P.S: кстати, VEO3 заработал на Англию, если проблемы c VPN на США — ваша остановочка.
Кто уже генерит в VEO, через раз сталкивается с этим сообщением. Спустя $350 и кучу нервов я, кажется, нашел решение.
Соль: чтобы ваш промт с русской озвучкой прошел, достаточно простого советского... ~650 символов в промте и выше. Все, что меньше — не проходило. Вот и весь секрет (нейроинфоцыгане — сорри).
Дописывайте промт любой LLM'кой, делитесь результатами — вдруг это только у меня работает.
P.S: кстати, VEO3 заработал на Англию, если проблемы c VPN на США — ваша остановочка.
Forwarded from Ai molodca (Dobrokotov)
Промтер для VEO-3 💅
На основе собственных выводов и гайдов из интернета создал GPTs-бота для промптинга.
Опишите желаемое (или загрузите изображение) — бот выдаст вам три промпта (обычный, улучшенный, креативный) и рекомендации.
Бот будет дополняться по мере накопления знаний; приглашаю протестировать.
P.S. Когда его создавал, обнаружил, что моим прошлым ботом (для Luma/Kling/Gen) воспользовались более 25 000 раз — мелочь, а приятно💀 .
На основе собственных выводов и гайдов из интернета создал GPTs-бота для промптинга.
Опишите желаемое (или загрузите изображение) — бот выдаст вам три промпта (обычный, улучшенный, креативный) и рекомендации.
Бот будет дополняться по мере накопления знаний; приглашаю протестировать.
P.S. Когда его создавал, обнаружил, что моим прошлым ботом (для Luma/Kling/Gen) воспользовались более 25 000 раз — мелочь, а приятно
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from LLM под капотом
Знаете, как опытные дизайнеры используют AI?
Они говорят, что AI - это творческая и непредсказуемая штука:
(цитата из внутренней переписки, переведена GPT-4.5)
И чтобы работать с пространствами вероятностей, дизайнеры сначала вместе с AI составляют планы и описания желаемых результатов. Они фиксируют в плане те вещи, которые должны четко быть отражены в результатах. А те моменты, где нужна непредсказуемость и вариативность - оставляют на “откуп” моделям.
Потом они запускают план несколько раз и выбирают понравившийся вариант. Если во всех реализациях схожие ошибки - они правят план и перезапускают.
Аналогично используют AI и копирайтеры (люди, которые пишут тексты). Сначала они вместе с AI собирают планы для написания текста (outlines), в которых прописывают важные факты, цитаты, структуру - все те вещи, которые нужно фиксировать. А потом отдают план LLM-ке на “разворачивание” в черновик текста. Причем, генерируют несколько вариантов текста, чтобы выбрать наиболее симпатичный для дальнейшей доводки.
Везде работает один и тот же принцип:
(1) сначала разрабатываем план реализации, который фиксирует важные для нас вещи. В процессе можно и нужно использовать AI
(2) когда план нас устраивает, то отдаем его LLM на реализацию
(3) запускаем параллельно несколько попыток реализации - мы выберем наиболее понравившуюся
(4) если все попытки кажутся неудачными - выкидываем изменения и дополняем план. План редактировать удобнее - т.к. там все изменения в одном месте, а не раскиданы по решению. Дальше, см пункт (2)
Команды разработчиков, которые успешно используют AI+Coding инструменты на больших проектах, тоже используют ту же парадигму:
(1) вместо ожидания идеального результата с первой попытки они работают с пространствами вероятностей - сначала прописывают все важное в плане, проверяют, а потом отдают на реализацию в коде.
(2) естественно, что бОльшую часть работы по написанию плана берет на себя AI
(3) при этом они не жалеют нервные клетки у AI и запускают сразу несколько вариантов одной и той же задачи, чтобы потом выбрать наилучший ответ.
Подробнее про процесс использования AI+Coding в проектах посложнее - написано в посте Как разрабатывать большие проекты с кучей зависимостей?
А вы уже пробовали подход с планами и множественными реализациями? Расскажете, как оно получилось?
Ваш, @llm_under_hood 🤗
Они говорят, что AI - это творческая и непредсказуемая штука:
Попробуйте несколько раз повторить один текстовый запрос, и вы увидите аналогичную ситуацию: идентичные вводные данные редко приводят к одинаковым результатам… Эта внутренняя случайность кардинально меняет нашу работу как UX-дизайнеров… Новые цели: курирование «пространств вероятностей» вместо построения идеальных путей
(цитата из внутренней переписки, переведена GPT-4.5)
И чтобы работать с пространствами вероятностей, дизайнеры сначала вместе с AI составляют планы и описания желаемых результатов. Они фиксируют в плане те вещи, которые должны четко быть отражены в результатах. А те моменты, где нужна непредсказуемость и вариативность - оставляют на “откуп” моделям.
Потом они запускают план несколько раз и выбирают понравившийся вариант. Если во всех реализациях схожие ошибки - они правят план и перезапускают.
Аналогично используют AI и копирайтеры (люди, которые пишут тексты). Сначала они вместе с AI собирают планы для написания текста (outlines), в которых прописывают важные факты, цитаты, структуру - все те вещи, которые нужно фиксировать. А потом отдают план LLM-ке на “разворачивание” в черновик текста. Причем, генерируют несколько вариантов текста, чтобы выбрать наиболее симпатичный для дальнейшей доводки.
Везде работает один и тот же принцип:
(1) сначала разрабатываем план реализации, который фиксирует важные для нас вещи. В процессе можно и нужно использовать AI
(2) когда план нас устраивает, то отдаем его LLM на реализацию
(3) запускаем параллельно несколько попыток реализации - мы выберем наиболее понравившуюся
(4) если все попытки кажутся неудачными - выкидываем изменения и дополняем план. План редактировать удобнее - т.к. там все изменения в одном месте, а не раскиданы по решению. Дальше, см пункт (2)
Команды разработчиков, которые успешно используют AI+Coding инструменты на больших проектах, тоже используют ту же парадигму:
(1) вместо ожидания идеального результата с первой попытки они работают с пространствами вероятностей - сначала прописывают все важное в плане, проверяют, а потом отдают на реализацию в коде.
(2) естественно, что бОльшую часть работы по написанию плана берет на себя AI
(3) при этом они не жалеют нервные клетки у AI и запускают сразу несколько вариантов одной и той же задачи, чтобы потом выбрать наилучший ответ.
Подробнее про процесс использования AI+Coding в проектах посложнее - написано в посте Как разрабатывать большие проекты с кучей зависимостей?
А вы уже пробовали подход с планами и множественными реализациями? Расскажете, как оно получилось?
Ваш, @llm_under_hood 🤗
Forwarded from LLM под капотом
Как мне OpenAI сегодня сэкономил 8 часов
Я недавно упоминал кейс про 700000 строчек дремучего 4GL кода 30-летней давности. Этот код надо переписать на Java/Kotlin так, чтобы пользователи в 13 странах не заметили подмены и продолжали работать как и раньше.
Чтобы начать оценивать реальность переписывания, надо самостоятельно запустить этот монолит. И это при том, что документацию про запуск в тендер не включили, есть только git с исходниками. Про один из параметров запуска сказать забыли, а он срабатывает при обращении системы к служебным таблицам, куда тоже нет доступа. А БД - файловая, работает по хитрому протоколу через VPN, либо через JDBC, который прикручен сбоку.
При этом ни среду программирования, ни язык я раньше в глаза не видел. Да и вообще специалисты в них уже почти все на пенсии (почему и так горит переписывание).
Сегодня ChatGPT помог за несколько часов благополучно разобраться в коде, найти точки входа, отладить проблемы и запустить систему. Без чьей-либо помощи.
Запросы в ChatGPT выглядели примерно так:
(обращаем внимание на то, как c каждым ответом от ChatGPT понимание происходящего становится лучше)
(1) Вот что это вообще?
(2) Вот тебе список файлов и папок в верхних уровнях проекта. С какой стороны это запускать?
(3) Ну поставил я среду для разработки, какой скрипт наиболее вероятен в качестве точки входа?
(4) Скрипт ругается на отсутствие БД. Как поставить драйвера Progress 4GL под Windows?
(5) В чем различие между JDBC и ABL подключением к БД? Как проще пробросить настройки в сессию?
(6) Вот тебе входной скрипт ABL и релевантные параметры. Помоги отладить причину, почему терминал не пропускает мой логин.
(7) Встрой в приложение отладочное окно, которое покажет статус авторизации моего тестового логина в системной таблице и в ее второй версии от 2008 года
(8) Вот выхлоп отладочного окна. Выдай пару вариантов, почему у меня логин с валидным паролем может не проходить
(9) Напиши ABL скрипт, который достанет _Domain-name для моего пользователя из системной таблицы _Users (OE11+). JDBC не пользуйся - оттуда доступ закрыт.
(10) Как пробросить параметр SESSION:ICFPARAMETER в приложение ABL, запускаемое из PDSOE?
В принципе, я бы осилил весь процесс и сам, но убил бы пару дней на чтение форумов, устаревшей документации и освоение базового синтаксиса 4GL в контексте ABL и терминальных приложений.
А так, ChatGPT + DeepResearch просто за пару часов провели меня за ручку до поставленной цели.
Ваш, @llm_under_hood 🤗
Я недавно упоминал кейс про 700000 строчек дремучего 4GL кода 30-летней давности. Этот код надо переписать на Java/Kotlin так, чтобы пользователи в 13 странах не заметили подмены и продолжали работать как и раньше.
Чтобы начать оценивать реальность переписывания, надо самостоятельно запустить этот монолит. И это при том, что документацию про запуск в тендер не включили, есть только git с исходниками. Про один из параметров запуска сказать забыли, а он срабатывает при обращении системы к служебным таблицам, куда тоже нет доступа. А БД - файловая, работает по хитрому протоколу через VPN, либо через JDBC, который прикручен сбоку.
При этом ни среду программирования, ни язык я раньше в глаза не видел. Да и вообще специалисты в них уже почти все на пенсии (почему и так горит переписывание).
Сегодня ChatGPT помог за несколько часов благополучно разобраться в коде, найти точки входа, отладить проблемы и запустить систему. Без чьей-либо помощи.
Запросы в ChatGPT выглядели примерно так:
(обращаем внимание на то, как c каждым ответом от ChatGPT понимание происходящего становится лучше)
(1) Вот что это вообще?
(2) Вот тебе список файлов и папок в верхних уровнях проекта. С какой стороны это запускать?
(3) Ну поставил я среду для разработки, какой скрипт наиболее вероятен в качестве точки входа?
(4) Скрипт ругается на отсутствие БД. Как поставить драйвера Progress 4GL под Windows?
(5) В чем различие между JDBC и ABL подключением к БД? Как проще пробросить настройки в сессию?
(6) Вот тебе входной скрипт ABL и релевантные параметры. Помоги отладить причину, почему терминал не пропускает мой логин.
(7) Встрой в приложение отладочное окно, которое покажет статус авторизации моего тестового логина в системной таблице и в ее второй версии от 2008 года
(8) Вот выхлоп отладочного окна. Выдай пару вариантов, почему у меня логин с валидным паролем может не проходить
(9) Напиши ABL скрипт, который достанет _Domain-name для моего пользователя из системной таблицы _Users (OE11+). JDBC не пользуйся - оттуда доступ закрыт.
(10) Как пробросить параметр SESSION:ICFPARAMETER в приложение ABL, запускаемое из PDSOE?
В принципе, я бы осилил весь процесс и сам, но убил бы пару дней на чтение форумов, устаревшей документации и освоение базового синтаксиса 4GL в контексте ABL и терминальных приложений.
А так, ChatGPT + DeepResearch просто за пару часов провели меня за ручку до поставленной цели.
Ваш, @llm_under_hood 🤗
Forwarded from LLM под капотом
Как добавить памяти AI+Code агентам?
В посте про то, как разрабатывать сложные проекты, я писал про README, AGENTS и CONTEXT md файлы. При использовании в связке с двушаговой разработкой (через implementation plan), они хорошо помогают реализовывать довольно сложные фичи.
Но этот процесс основывается на костыли в виде человеческих процессов разработки на Github. Так разрабатывали и Linux Kernel и множество других OpenSource проектов.
А можно ли как-то дополнить процесс именно для удобства работы современных AI+Code систем?
Вот еще одна фишка, которая в итоге позволяет работать чуть более стабильно с чуть более сложными проектами.
Смотрите, и OpenAI Codex и
Например, можно выделить:
-
-
-
Все вместе в коде это может выглядеть, скажем, вот так:
Это создает долгосрочный слой памяти прямо в коде, который позволяет агентам самостоятельно задавать вопросы по тексту или оставлять себе заметки. Или самостоятельно разбивать сложные задачи на более простые (через `AICODE-TODO`)
В итоге получается чуть стабильнее работать с чуть более сложными проектами.
Ваш, @llm_under_hood 🤗
PS: сам код на экране промежуточный - в процессе работы Codex-a. Он демонстрирует то, как AI+Coding системы пользуются подобными комментариями по мере подготовки финального PR.
В посте про то, как разрабатывать сложные проекты, я писал про README, AGENTS и CONTEXT md файлы. При использовании в связке с двушаговой разработкой (через implementation plan), они хорошо помогают реализовывать довольно сложные фичи.
Но этот процесс основывается на костыли в виде человеческих процессов разработки на Github. Так разрабатывали и Linux Kernel и множество других OpenSource проектов.
А можно ли как-то дополнить процесс именно для удобства работы современных AI+Code систем?
Вот еще одна фишка, которая в итоге позволяет работать чуть более стабильно с чуть более сложными проектами.
Смотрите, и OpenAI Codex и
Cursor.sh с терминальными утилитами очень любят использовать grep - утилиту для поиска текста в файлах. Поэтому можно разрешить им оставлять однострочные комментарии с каким-нибудь префиксом, который они смогут быстро найти, например AICODE-. И обязательно попросить искать эти комментарии в файлах перед началом работы с ними.Например, можно выделить:
-
AICODE-NOTE - заметка или комментарий для AI+Code системы-
AICODE-TODO - задачка себе на сессию попозже-
AICODE-ASK - вопрос от системы человеку, чтобы он ответил и потом пометил как AICODE-NOTEВсе вместе в коде это может выглядеть, скажем, вот так:
const LOGIN_START='\\x1b]9;LOGIN=START\\x07', LOGIN_END='\\x1b]9;LOGIN=END\\x07';
let inLogin=false, buf='';
// AICODE-NOTE: Complex OSC sequence parsing - this is the core login overlay logic
// AICODE-ASK: Could this parsing be more robust? What if sequences are split across messages?
socket.addEventListener('message', ev=>{
const chunk = ev.data instanceof ArrayBuffer
? new TextDecoder().decode(ev.data) : ev.data;
buf += chunk;
while (true) {
const s = buf.indexOf(LOGIN_START), e = buf.indexOf(LOGIN_END);
if (s!==-1 && (s<e || e===-1)) {
if (!inLogin && s>0) term.write(buf.slice(0,s));
buf = buf.slice(s+LOGIN_START.length); showOverlay(); inLogin=true; continue;
}
if (e!==-1) {
if (!inLogin && e>0) term.write(buf.slice(0,e));
buf = buf.slice(e+LOGIN_END.length); hideOverlay(); inLogin=false; continue;
}
break;
}
if (!inLogin && buf){ term.write(buf); buf=''; }
});
Это создает долгосрочный слой памяти прямо в коде, который позволяет агентам самостоятельно задавать вопросы по тексту или оставлять себе заметки. Или самостоятельно разбивать сложные задачи на более простые (через `AICODE-TODO`)
В итоге получается чуть стабильнее работать с чуть более сложными проектами.
Ваш, @llm_under_hood 🤗
PS: сам код на экране промежуточный - в процессе работы Codex-a. Он демонстрирует то, как AI+Coding системы пользуются подобными комментариями по мере подготовки финального PR.
Forwarded from Information Retriever
ARGUS.pdf
5.2 MB
Data Fest 2025.
Выступил! Получилось за 36 минут рассказать 76 слайдов. Чтение лекций в ШАДе натренировало меня говорить быстро, но лекторским монотонным голосом :) Я чуть-чуть подустал за ближайшие полтора месяца, это по выступлению хорошо заметно — ни одной улыбки, даже шутки говорил с каменным лицом :)
Запись выступления можно посмотреть здесь: https://m.vkvideo.ru/video-164555658_456241373 (ссылку на ютуб выложу как только появится), по таймингам — начинается где-то на 4h:32m.
Что обсуждали в кулуарах:
* Аргуса. Долгое время это был внутренний яндексовый термин, теперь когнитивный диссонанс возникает каждый раз, когда его кто-то вне Яндекса произносит :)
* Рекомендательные трансформеры и всё, что с ними связано. Вообще, в этот раз очень много хороших вопросов задавали. Чувствуется что понимание рекомендательных трансформеров растёт, гораздо больше ребят в этом начинает хорошо разбираться! А ещё было даже такое, что заметили связь между моим решением vk recsys challenge и Аргусом :)
* Графовые нейросети, мультимодальные векторы, семантические айдишники. У ребят из R&D команды vk (Максима Утушкина и Ильи Алтухова) были клёвые доклады!
* Обсуждали статьи, а именно — подачу статей на конфу RecSys. Это была почти психотерапия, на которой можно было пожаловаться на ревьюверов :)
Презентацию прикладываю.
Выступил! Получилось за 36 минут рассказать 76 слайдов. Чтение лекций в ШАДе натренировало меня говорить быстро, но лекторским монотонным голосом :) Я чуть-чуть подустал за ближайшие полтора месяца, это по выступлению хорошо заметно — ни одной улыбки, даже шутки говорил с каменным лицом :)
Запись выступления можно посмотреть здесь: https://m.vkvideo.ru/video-164555658_456241373 (ссылку на ютуб выложу как только появится), по таймингам — начинается где-то на 4h:32m.
Что обсуждали в кулуарах:
* Аргуса. Долгое время это был внутренний яндексовый термин, теперь когнитивный диссонанс возникает каждый раз, когда его кто-то вне Яндекса произносит :)
* Рекомендательные трансформеры и всё, что с ними связано. Вообще, в этот раз очень много хороших вопросов задавали. Чувствуется что понимание рекомендательных трансформеров растёт, гораздо больше ребят в этом начинает хорошо разбираться! А ещё было даже такое, что заметили связь между моим решением vk recsys challenge и Аргусом :)
* Графовые нейросети, мультимодальные векторы, семантические айдишники. У ребят из R&D команды vk (Максима Утушкина и Ильи Алтухова) были клёвые доклады!
* Обсуждали статьи, а именно — подачу статей на конфу RecSys. Это была почти психотерапия, на которой можно было пожаловаться на ревьюверов :)
Презентацию прикладываю.
Forwarded from Samvel K
Репка: Курс ШАДа по RecSys 2025 года (без видео, но со слайдами и ноутбуками)
GitHub
GitHub - yandexdataschool/recsys_course: Recommender Systems course in YSDA.
Recommender Systems course in YSDA. Contribute to yandexdataschool/recsys_course development by creating an account on GitHub.
Forwarded from epsilon correct
У High-Dimensional Probability Вершинина стал доступен драфт второго издания. Добавили больше 200 упражнений и сделали книгу более удобоваримой. 🥁
Как по мне, лучшая книга по основам вероятностных методов в приложениях к нашему с вами любимому датасаенсу.
pdf
Как по мне, лучшая книга по основам вероятностных методов в приложениях к нашему с вами любимому датасаенсу.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from CV Time
Yandex Alchemist: открытый датасет для буста text-to-image генерации
Раньше T2I-модели обучали в один этап — претрейн на большом, довольно грязном датасете интернет-данных. В 2023 году Meta в техрепорте EMU предложили делать файнтюн на маленьком датасете исключительного качества и за счёт этого существенно бустить результат генерации. Правда, они ничего не сказали о том, как такой датасет собрать.
Команда YandexART тоже занималась этой задачей, и сегодня мы делимся результатами своей работы — датасетом Alchemist. Он состоит из 3 350 пар «картинка-текст» и имеет лицензию Apache 2.0, пользуйтесь.
Alchemist сокращает дистанцию между крутыми потюненными закрытыми моделями и открытыми, для которых такой тюнинг недоступен. Ранее сообществу был доступен только пофильтрованный на эстетичность кусочек LAION и файнтюн-датасеты под узкий домен, например аниме или живопись. LAION часто не давал существенного прироста качества, а файнтюны под узкий домен ограничивали возможности генерации за его пределами.
Ниже мы подробно рассказываем, как получить датасет уровня Alchemist, имея лишь сырой набор интернет-данных. Отметим, что весь пайплайн — про картинки. Мы считаем, что так правильно: тексты потом лучше сгенерировать синтетические.
Итак, стартуя с датасета на 10 млрд примеров, мы выбрали картинки высокого разрешения без NSFW-контента и удалили те, что содержали вотермарки, имели низкое качество и были неэстетичны. Когда осталось примерно 300 млн изображений, дальнейшее выкручивание порогов фильтрации не помогало: модели недостаточно чувствительны, чтобы отделять хорошие картинки от великолепных. Выбирать руками лучшее из такого большого набора — тоже сомнительная затея.
На этом этапе мы предположили, что предобученная диффузионка может сама знать, какие картинки хорошие, а какие — не очень. Пробовали подходы из области dataset pruning, например, пропускать картинки через модель и смотреть на значение лосса. Оказалось, что так отбираются только самые простые изображения — абстрактные иллюстрации, вроде обоев на рабочий стол. В них немного деталей и их легко моделировать, но на файнтюне от них мало толку.
В итоге нам пришлось придумать свой метод, суть которого в следующем.
1. Возьмём 1000 картинок из наших 300 млн и разметим на условно плохие (LQ) и хорошие (HQ). Хорошими будем считать те, у которых высокие эстетичность и техническое качество, умеренная наполненность контентом.
2. Смастерим общий промт, который будет содержать перечисление желаемых характеристик: “aesthetic”, “high quality” и т. д.
3. Дальше будем брать LQ- и HQ-картинки, зашумлять их до какого-то t, подавать в нашу предобученую диффузионку вместе с промтом и смотреть, что происходит со значениями в cross-attention.
Оказывается, что на основе нашей небольшой и грубой разметки можно выделить комбинации активаций в cross-attn и токенов, которые будут хорошо отделять изображения с нужными нам свойствами. Если просуммировать эти значения, получим скаляр, который и будет нашим скором качества изображения. Проскорив таким образом 300 млн картинок, мы выбрали топ-3350 — это картинки из нашего датасета.
Дальше осталось сделать тексты — исходные из интернета могут быть ошибочны, содержать лишнюю или упускать нужную информацию. Наше наблюдение: лучше всего работают умеренно подробные промты, похожие на те, которые пишет скорее увлечённый пользователь, чем профессиональный промпт-инженер. YandexVLM как раз умеет подстраиваться под нужный формат. С её помощью мы сгенерировали тексты для каждой картинки, получив датасет Alchemist.
Чтобы убедиться в обобщаемости датасета и метода, мы сделали и выложили файнтюны SD 1.5, SD 2.1, SDXL-base 1.0, SD 3.5 Medium и Large. У всех файнтюнов растёт эстетичность и наполненность генераций, которую мы называем “image complexity”. Подробнее о методике и экспериментах читайте в препринте.
Статью подготовили❣ Валерий Старцев, Александр Устюжанин, Алексей Кириллов, Дмитрий Баранчук, Сергей Кастрюлин
CV Time
___
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
Раньше T2I-модели обучали в один этап — претрейн на большом, довольно грязном датасете интернет-данных. В 2023 году Meta в техрепорте EMU предложили делать файнтюн на маленьком датасете исключительного качества и за счёт этого существенно бустить результат генерации. Правда, они ничего не сказали о том, как такой датасет собрать.
Команда YandexART тоже занималась этой задачей, и сегодня мы делимся результатами своей работы — датасетом Alchemist. Он состоит из 3 350 пар «картинка-текст» и имеет лицензию Apache 2.0, пользуйтесь.
Alchemist сокращает дистанцию между крутыми потюненными закрытыми моделями и открытыми, для которых такой тюнинг недоступен. Ранее сообществу был доступен только пофильтрованный на эстетичность кусочек LAION и файнтюн-датасеты под узкий домен, например аниме или живопись. LAION часто не давал существенного прироста качества, а файнтюны под узкий домен ограничивали возможности генерации за его пределами.
Ниже мы подробно рассказываем, как получить датасет уровня Alchemist, имея лишь сырой набор интернет-данных. Отметим, что весь пайплайн — про картинки. Мы считаем, что так правильно: тексты потом лучше сгенерировать синтетические.
Итак, стартуя с датасета на 10 млрд примеров, мы выбрали картинки высокого разрешения без NSFW-контента и удалили те, что содержали вотермарки, имели низкое качество и были неэстетичны. Когда осталось примерно 300 млн изображений, дальнейшее выкручивание порогов фильтрации не помогало: модели недостаточно чувствительны, чтобы отделять хорошие картинки от великолепных. Выбирать руками лучшее из такого большого набора — тоже сомнительная затея.
На этом этапе мы предположили, что предобученная диффузионка может сама знать, какие картинки хорошие, а какие — не очень. Пробовали подходы из области dataset pruning, например, пропускать картинки через модель и смотреть на значение лосса. Оказалось, что так отбираются только самые простые изображения — абстрактные иллюстрации, вроде обоев на рабочий стол. В них немного деталей и их легко моделировать, но на файнтюне от них мало толку.
В итоге нам пришлось придумать свой метод, суть которого в следующем.
1. Возьмём 1000 картинок из наших 300 млн и разметим на условно плохие (LQ) и хорошие (HQ). Хорошими будем считать те, у которых высокие эстетичность и техническое качество, умеренная наполненность контентом.
2. Смастерим общий промт, который будет содержать перечисление желаемых характеристик: “aesthetic”, “high quality” и т. д.
3. Дальше будем брать LQ- и HQ-картинки, зашумлять их до какого-то t, подавать в нашу предобученую диффузионку вместе с промтом и смотреть, что происходит со значениями в cross-attention.
Оказывается, что на основе нашей небольшой и грубой разметки можно выделить комбинации активаций в cross-attn и токенов, которые будут хорошо отделять изображения с нужными нам свойствами. Если просуммировать эти значения, получим скаляр, который и будет нашим скором качества изображения. Проскорив таким образом 300 млн картинок, мы выбрали топ-3350 — это картинки из нашего датасета.
Дальше осталось сделать тексты — исходные из интернета могут быть ошибочны, содержать лишнюю или упускать нужную информацию. Наше наблюдение: лучше всего работают умеренно подробные промты, похожие на те, которые пишет скорее увлечённый пользователь, чем профессиональный промпт-инженер. YandexVLM как раз умеет подстраиваться под нужный формат. С её помощью мы сгенерировали тексты для каждой картинки, получив датасет Alchemist.
Чтобы убедиться в обобщаемости датасета и метода, мы сделали и выложили файнтюны SD 1.5, SD 2.1, SDXL-base 1.0, SD 3.5 Medium и Large. У всех файнтюнов растёт эстетичность и наполненность генераций, которую мы называем “image complexity”. Подробнее о методике и экспериментах читайте в препринте.
Статью подготовили
CV Time
___
Meta признана экстремистской организацией, а Facebook и Instagram запрещены на территории РФ
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Concise Research (Sergey Kastryulin)
A Comprehensive Study of Decoder-Only LLMs for Text-to-Image Generation
В области text-to-image генерации давно стоит вопрос: какой текстовый энкодер использовать лучше? Сейчас каждый делает на свой лад: кто-то по инерции использует CLIP и T5 (как в DALL-E и Imagen), кто-то переходит на LLM decoder-only трансформеры (Lumina, SANA) без особой экспериментальной аргументации
В этой работе авторы:
▶️ Берут 12 текстовых энкодеров, включая CLIP, T5, Mistral разных размеров + instruct версию, Gemma и Qwen, а также эмбедеры на их основе
▶️ Учат 27 SDv2-like диффузионок к U-Net архитектурой на семпле 46М из LAION-Aesthetics
▶️ Замеряют результаты на GenAI-Bench — это такой набор 1,600 очень подробных промтов, после генераций по которым VLM оценивает навыки генератора
Для контекста важно вспомнить, что для использования CLIP и T5 обычно берут эмбединг их последнего слоя. Ранние работы по использованию LMок для диффузии делали также
Итак, что удалось выяснить:
▶️ У LLMок эмбед последнего слоя плохой из-за оверфита под задачу предсказания последнего токена. Эмбеды средних слоёв существенно информативнее и дают лучшее качество обученной с их использованием диффузии
▶️ Если комбинировать несколько средних слоёв, то это ещё сильнее бустит качество и позволяет обгонять T5 и CLIP
▶️ Выходы моделей-эмбедеров бывают разного качества: bge-Gemma2 — крутая, остальные рассмотренные — не очень. По умолчанию лучше использовать обычные LMки
▶️ Для моделей-эмбедеров тоже можно комбинировать несколько средних слоёв, это тоже улучшает качество
▶️ Модели большего размера (7B или 9B против 1.5B или 2B) работают лучше, но буст не драматический
А еще авторы говорят, что было бы классно комбинировать представления эмбедеров и обычных LM’ок для дальнейшего улучшения качества, но оставляют верификацию этого на future work
В статье очень мало картинок, но те что есть показывают, что модели на основе правильно использованных представлений LMок лучше справляются с учётом мелких деталей промтов и отрицаниями
В области text-to-image генерации давно стоит вопрос: какой текстовый энкодер использовать лучше? Сейчас каждый делает на свой лад: кто-то по инерции использует CLIP и T5 (как в DALL-E и Imagen), кто-то переходит на LLM decoder-only трансформеры (Lumina, SANA) без особой экспериментальной аргументации
В этой работе авторы:
Для контекста важно вспомнить, что для использования CLIP и T5 обычно берут эмбединг их последнего слоя. Ранние работы по использованию LMок для диффузии делали также
Итак, что удалось выяснить:
А еще авторы говорят, что было бы классно комбинировать представления эмбедеров и обычных LM’ок для дальнейшего улучшения качества, но оставляют верификацию этого на future work
В статье очень мало картинок, но те что есть показывают, что модели на основе правильно использованных представлений LMок лучше справляются с учётом мелких деталей промтов и отрицаниями
Please open Telegram to view this post
VIEW IN TELEGRAM