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
Forwarded from Соне нравится (или нет)
Как человек, увлечённый развитием Fashion Tech и применением компьютерного зрения в индустрии моды, я внимательно слежу за новыми направлениями и подходами. Всем уже привычна задача Virtual Try-On (VTON), когда нейросети (диффузионные модели в данный момент) виртуально примеряют одежду на изображениях людей. Однако сейчас набирает популярность противоположное направление — Virtual Try-Off (VTOFF), задача извлечения одежды с моделей и получения её канонического изображения. Это не просто новая фишка, а перспективная задача с серьёзными техническими вызовами: в отличие от традиционного VTON, где модель цифровым образом «одевается», VTOFF стремится выделить и «снять» одежду, сохранив при этом её точную форму, текстуру и даже сложные паттерны ткани.
Кстати, на идущей прямо сейчас конференции CVPR-2025 были приняты пейперы, посвящённые именно Virtual Try-Off.
Зачем индустрии моды такой подход?
1. Создание идеального каталога — возможность быстро получить идеализированное изображение одежды, свободное от складок, позы и особенностей модели.
2. Точная визуализация и кастомизация — одежда, полученная через VTOFF, может быть легко переиспользована и виртуально адаптирована к новым условиям (поза, модель, фон).
3. Повышение эффективности производства контента — сокращение затрат на новые фотосессии и обработку изображений.
Вот пара интересных подхода к задаче Virtual Try-Off, которые стоит изучить уже сейчас:
TryOffDiff: Virtual Try-Off via High-Fidelity Garment Reconstruction using Diffusion Models
Основная цель: получить оригинальное изображение одежды (без тела, позы и искажений) из одной фотографии одетого человека.
Ключевые идеи:
TryOffAnyone: Tiled Cloth Generation from a Dressed Person
Основная цель: восстановить канонический вид одежды с фото одетого человека, представив её в виде тайлов (фрагментов), пригодных для переиспользования и редактирования.
Ключевые идеи:
Оба подхода — TryOffDiff и TryOffAnyone — подчёркивают, что Virtual Try-Off нельзя рассматривать как простое дополнение к VTON. Это отдельный класс задач, требующий других архитектурных решений, способных восстанавливать геометрию, структуру и текстильные особенности одежды в отрыве от тела, позы и сцены.
@sonya_aesthetics
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Пресидский залив
Технический фаундер — это человек, который может построить почти все.
И именно поэтому он часто строит не то😆
Часто по привычке такие фаундеры начинают строить не для людей, а что-то технологически красивое и интересное себе,
такое, про что условно можно написать пейпер на EMNLP👩🦰
Не специально, конечно. Но как результат получается не продукт вокруг боли, а витрина вокруг технологии, потому что это еще один инженерный челендж. Интеллектуально кайфовый, но не всегда нужный😁
Первая версия Aesty была жесть какая непонятная: куча параметров, кнопок, сценариев. Движок рекомендаций был классно проработан, примерки еще не было, но пользователи тем временем просто отваливались👋
Я называю это галлюцинациями технического фаундера —
влюбиться в свое технологическое решение раньше, чем по-настоящему понять проблему😍
Вот вам 4 примера:
1. Технология = value😐
Кажется, что если ты сделал что-то сложное, умное, кастомное в этом уже заложена ценность.
Но нет. Пользователя не так уж интересует, насколько изящна твоя архитектура и какие бенчмарки бьет твоя фэнси модель, куда интереснее, помогает ли это его проблемам?😐
Прежде чем приступать к реализации, я просто выкладываю мокап и смотрю, зацепит ли это вообще кого-нибудь. Примерка вот зацепила и мы ее добавили😏
2. Умная фича говорит сама за себя
Она не скажет, а затеряется и интерфейсе😳
Спаун внимания короткий, мануал читать никто не будет.
Если это не интуитивно — это не работает.
Я стараюсь не строить фичи до тех пор, пока четко не понимаю кто ее просил, как встроится в текущий флоу и какую боль она решает😎
3. Если юзер не понимает — это он глупый😐
Нет, это я нафантазировала⌨️
Если не кликают, значит, не нужно или мы нарисовали какую-то фигню
Я считаю, что любой интерфейс по умолчанию сломан, пока не доказано обратное🤡
4. Сейчас допилим вот это — и будет ценно
Качество, а не количество, польза должна быть очень бинарной и желательно в одну кнопку
Валидация перед реализацией🧠
Я стараюсь держать в голове одну простую мысль:
fall in love with the problem, not the solution😎
Го делиться в комментариях что забыла 🤗
@neural_prosecco
И именно поэтому он часто строит не то
Часто по привычке такие фаундеры начинают строить не для людей, а что-то технологически красивое и интересное себе,
такое, про что условно можно написать пейпер на EMNLP
Не специально, конечно. Но как результат получается не продукт вокруг боли, а витрина вокруг технологии, потому что это еще один инженерный челендж. Интеллектуально кайфовый, но не всегда нужный
Первая версия Aesty была жесть какая непонятная: куча параметров, кнопок, сценариев. Движок рекомендаций был классно проработан, примерки еще не было, но пользователи тем временем просто отваливались
Я называю это галлюцинациями технического фаундера —
влюбиться в свое технологическое решение раньше, чем по-настоящему понять проблему
Вот вам 4 примера:
1. Технология = value
Кажется, что если ты сделал что-то сложное, умное, кастомное в этом уже заложена ценность.
Но нет. Пользователя не так уж интересует, насколько изящна твоя архитектура и какие бенчмарки бьет твоя фэнси модель, куда интереснее, помогает ли это его проблемам?
Прежде чем приступать к реализации, я просто выкладываю мокап и смотрю, зацепит ли это вообще кого-нибудь. Примерка вот зацепила и мы ее добавили
2. Умная фича говорит сама за себя
Она не скажет, а затеряется и интерфейсе
Спаун внимания короткий, мануал читать никто не будет.
Если это не интуитивно — это не работает.
Я стараюсь не строить фичи до тех пор, пока четко не понимаю кто ее просил, как встроится в текущий флоу и какую боль она решает
3. Если юзер не понимает — это он глупый
Нет, это я нафантазировала
Если не кликают, значит, не нужно или мы нарисовали какую-то фигню
Я считаю, что любой интерфейс по умолчанию сломан, пока не доказано обратное
4. Сейчас допилим вот это — и будет ценно
Качество, а не количество, польза должна быть очень бинарной и желательно в одну кнопку
Валидация перед реализацией
Я стараюсь держать в голове одну простую мысль:
fall in love with the problem, not the solution
Го делиться в комментариях что забыла 🤗
@neural_prosecco
Please open Telegram to view this post
VIEW IN TELEGRAM