Forwarded from Мальцев: Карьера с AI
Ребята, астрологи-инфобизнесмены объявили, что прошло уже 8% года и население с невыполненными целями удвоилось.🔥 .
Сейчас будет полезно сравнить факты и планы января. Проверить, что маршрут на 2025 реально построен и время прибытия к ожидаемым результатам полностью совпадает с вашим темпом работы.
В этом году у меня получился классный и размеренный старт, за что огромное спасибо моей команде и работе по методике из 8 «буду делать».
Детали и примеры к каждому пункту - в статье на vc.ru:
• Как быстро выйти на максимальную продуктивность в 2025?
• Как находить время на личные задачи, не срываться на встречи и перестать прокрастинировать?
• Как разобраться, для каких задач действительно полезны нейросети?
За 3 года взаимодействия с нейросетями я сформулировал для себя 3 правила работы с GPT
❤️ и 👍 - если пост полезен. Написал его по мотивам моих наблюдений за тем, как знакомые мне люди все еще раскачиваются после новогодних.
Мальцев: Карьера. Маркетинг. AI.
Please open Telegram to view this post
VIEW IN TELEGRAM
vc.ru
Как начать работу в новом году и не раскачиваться долго
Я отвечаю за маркетинг Яндекс Браузера (ex CMO Яндекс Путешествия, Playrix, eBay, Groupon, консультировал League of Legends, Tinkoff, Sber, VK) и буду рад делиться своим опытом. Подпишитесь на мой telegram-канал «Мальцев: Карьера. Маркетинг. AI», где раз…
Forwarded from Kali Novskaya
🌸Курс AI Safety от DeepMind🌸
#nlp #про_nlp #ai_alignment
DeepMind выпустил серию коротких видео с мини-лекциями про безопасность в ИИ
— Введение в AI Safety
— Глава 2: 5 частей про проблему AI Alignment
— Глава 3, Технические решения: обучение моделей и мониторинг качества, интерпретируемость, более безопасные дизайн-паттерны, стресс-тестирование
— Глава 4, Подходы к управлению рисками: институциональный подход к ИИ-безопасности, лучшие практики, оценка экзистенциальных рисков
🟣 План курса: https://deepmindsafetyresearch.medium.com/introducing-our-short-course-on-agi-safety
(В конце есть две вакансии, в Лондоне и Нью-Йорке)
🟣 Youtube-плейлист: https://youtube.com/playlist?list=PLw9kjlF6lD5UqaZvMTbhJB8sV-yuXu5eW&si=mSHlo4s7u6Q_aXSy
#nlp #про_nlp #ai_alignment
DeepMind выпустил серию коротких видео с мини-лекциями про безопасность в ИИ
— Введение в AI Safety
— Глава 2: 5 частей про проблему AI Alignment
— Глава 3, Технические решения: обучение моделей и мониторинг качества, интерпретируемость, более безопасные дизайн-паттерны, стресс-тестирование
— Глава 4, Подходы к управлению рисками: институциональный подход к ИИ-безопасности, лучшие практики, оценка экзистенциальных рисков
(В конце есть две вакансии, в Лондоне и Нью-Йорке)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Valuable AI / Валентин Малых
я знал, что так будет, но не думал, что так скоро; плюс авторы сделали целый сайт, на котором публикуют свои обзоры своей сетки
arXiv.org
SurveyX: Academic Survey Automation via Large Language Models
Large Language Models (LLMs) have demonstrated exceptional comprehension capabilities and a vast knowledge base, suggesting that LLMs can serve as efficient tools for automated survey generation....
Forwarded from Тимлид Очевидность | Евгений Антонов
Шестой месяц. Управление процессами
Прошел шестой месяц курса Стратоплана «Руководитель отдела». Две трети позади
Контент первого, второго, третьего, четвертого и пятого месяцев я описывал ранее.
Это второй по счету месяц, в котором я не смог посетить онлайн. А очень жаль. Контент был важный и полезный, так что, лишившись практики в группах, я точно намерен наверстать это, особенно внимательно прикидывая это на рутинную работу.
О чем было
- Типы оргструктур (плоская, линейная, матричная, функциональная, проектная и т.д.). Надо понимать, когда какая нужна, плюсы и минусы разных подходов. Особенно важно в небольших компаниях, чтобы при росте уметь сформировать подходящую, а в больших компаниях, чтобы не страдать на тему «Ну почему же так? Ведь в моей прошлой маленько было иначе, и нормально же жили!»
- Ну и дальше всё связанное с оргструктурой и ролевой моделью. Типа не просто берите оргструктуру, наложите её на людей и погнали. А у вас должны быть роли лидеров, интеграторов, поддерживающие всякие, и разберитесь, кто какую роль будет закрывать в вашем конкретном случае, а не в базовом трафарете.
- Очевидная, вроде бы, история про систематизацию и формализацию бизнес-процессов. Кажется, что капитанство, однако очень часто нет процесса, а есть клубок в паре голов старожилов с лейблом «так исторически сложилось».
- Вторая тоже очевидная мысль, но редко проваливаемая — делегирование через бизнес-процесс. Хочешь делегировать и пойти заниматься другими делами? Сделай процесс, формализуй, опиши, научи и гуляй смело.
- Матрица «доверие-прозрачность». Золотая классика, всем рекомендую так работать. Чем понятнее и прозрачнее то, что вы делаете, тем больше к вам доверия и отношения как к профессионалу.
- Разные способы оптимизации бизнес-процессов, типа теории ограничений, 7 потоков потерь и прочего. Всё это очень интересно, но за один урок так, чисто по верхам рассмотрели, и дальше надо самим углубляться. Во что-то я когда-то уже ходил и пробовал, что-то так и осталось на поверхностном уровне.
- И кууууча всего про метрики продуктовые, канбановые, скрамовые, HEART, PROJECT, и т.д.
- Системы отчетности: кому, когда, как, в каком формате, на основе каких метрик.
- KPI и как они совместимы с работой. Например, видел в одной компании, как человеку поставили KPI для премии — ряд доработок и нового функционала на одном из важных сайтов компании. А разработчиков не дали. Вот и крутись как хочешь. Ну, как вы понимаете, премии, конечно же, не было 🙂
Какое мнение
Обычно я делаю описание того, какой контент был мне знаком, а какой нет. В этот раз мне было это сделать очень трудно, поэтому я выделил одной портянкой важные, на мой взгляд, темы.
С одной стороны, практически всё мне было известно и понятно. Только мало кто всё это разумно делает. Основной вызов для меня лично тут не в том, чтобы что-то новое узнать, а чтобы унести это в практику, да еще и никому не навредить. А то знаете эти приколы, когда кто-то наслушается на конфе про метрики, прибежит на работу и как давай внедрять во все места всё, что услышал? 🙂
Прошел шестой месяц курса Стратоплана «Руководитель отдела». Две трети позади
Контент первого, второго, третьего, четвертого и пятого месяцев я описывал ранее.
Это второй по счету месяц, в котором я не смог посетить онлайн. А очень жаль. Контент был важный и полезный, так что, лишившись практики в группах, я точно намерен наверстать это, особенно внимательно прикидывая это на рутинную работу.
О чем было
- Типы оргструктур (плоская, линейная, матричная, функциональная, проектная и т.д.). Надо понимать, когда какая нужна, плюсы и минусы разных подходов. Особенно важно в небольших компаниях, чтобы при росте уметь сформировать подходящую, а в больших компаниях, чтобы не страдать на тему «Ну почему же так? Ведь в моей прошлой маленько было иначе, и нормально же жили!»
- Ну и дальше всё связанное с оргструктурой и ролевой моделью. Типа не просто берите оргструктуру, наложите её на людей и погнали. А у вас должны быть роли лидеров, интеграторов, поддерживающие всякие, и разберитесь, кто какую роль будет закрывать в вашем конкретном случае, а не в базовом трафарете.
- Очевидная, вроде бы, история про систематизацию и формализацию бизнес-процессов. Кажется, что капитанство, однако очень часто нет процесса, а есть клубок в паре голов старожилов с лейблом «так исторически сложилось».
- Вторая тоже очевидная мысль, но редко проваливаемая — делегирование через бизнес-процесс. Хочешь делегировать и пойти заниматься другими делами? Сделай процесс, формализуй, опиши, научи и гуляй смело.
- Матрица «доверие-прозрачность». Золотая классика, всем рекомендую так работать. Чем понятнее и прозрачнее то, что вы делаете, тем больше к вам доверия и отношения как к профессионалу.
- Разные способы оптимизации бизнес-процессов, типа теории ограничений, 7 потоков потерь и прочего. Всё это очень интересно, но за один урок так, чисто по верхам рассмотрели, и дальше надо самим углубляться. Во что-то я когда-то уже ходил и пробовал, что-то так и осталось на поверхностном уровне.
- И кууууча всего про метрики продуктовые, канбановые, скрамовые, HEART, PROJECT, и т.д.
- Системы отчетности: кому, когда, как, в каком формате, на основе каких метрик.
- KPI и как они совместимы с работой. Например, видел в одной компании, как человеку поставили KPI для премии — ряд доработок и нового функционала на одном из важных сайтов компании. А разработчиков не дали. Вот и крутись как хочешь. Ну, как вы понимаете, премии, конечно же, не было 🙂
Какое мнение
Обычно я делаю описание того, какой контент был мне знаком, а какой нет. В этот раз мне было это сделать очень трудно, поэтому я выделил одной портянкой важные, на мой взгляд, темы.
С одной стороны, практически всё мне было известно и понятно. Только мало кто всё это разумно делает. Основной вызов для меня лично тут не в том, чтобы что-то новое узнать, а чтобы унести это в практику, да еще и никому не навредить. А то знаете эти приколы, когда кто-то наслушается на конфе про метрики, прибежит на работу и как давай внедрять во все места всё, что услышал? 🙂
Forwarded from Sinекура
Вышел мой большой пост про рассуждающие модели (large reasoning models, LRM), которые начались с OpenAI o1-preview в конце прошлого сентября, а самой громкой новостью начала года стал DeepSeek-R1.
https://synthesis.ai/2025/02/25/large-reasoning-models-how-o1-replications-turned-into-real-competition/
Как обычно, я постарался рассказать всю структуру происходящего:
— сначала про chain-of-thought методы и как они развивались;
— потом про o1 и новые законы масштабирования;
— в середине небольшое отступление про самые последние новости — модель s1, которая за $50 обучилась почти до того же уровня;
— а потом уже подробно о том, что происходит в DeepSeek-V3 и DeepSeek-R1;
— в частности, о том, как там используется RL и какой именно (здесь у DeepSeek тоже есть своё новшество, алгоритм GRPO).
Думаю, рассуждающие модели — это самое главное, что произошло в AI за последние несколько месяцев. И, как всегда в последнее время, прогресс невероятно быстрый: только появилось, а уже прочно вошло в обиход, у всех есть свои варианты reasoning models, а где-то уже есть и следующие уровни надстройки над этим вроде deep research. Надеюсь, пост тоже интересный получился — или хотя бы познавательный.)
https://synthesis.ai/2025/02/25/large-reasoning-models-how-o1-replications-turned-into-real-competition/
Как обычно, я постарался рассказать всю структуру происходящего:
— сначала про chain-of-thought методы и как они развивались;
— потом про o1 и новые законы масштабирования;
— в середине небольшое отступление про самые последние новости — модель s1, которая за $50 обучилась почти до того же уровня;
— а потом уже подробно о том, что происходит в DeepSeek-V3 и DeepSeek-R1;
— в частности, о том, как там используется RL и какой именно (здесь у DeepSeek тоже есть своё новшество, алгоритм GRPO).
Думаю, рассуждающие модели — это самое главное, что произошло в AI за последние несколько месяцев. И, как всегда в последнее время, прогресс невероятно быстрый: только появилось, а уже прочно вошло в обиход, у всех есть свои варианты reasoning models, а где-то уже есть и следующие уровни надстройки над этим вроде deep research. Надеюсь, пост тоже интересный получился — или хотя бы познавательный.)
Forwarded from Записки из горящего дома (Anastasia Abrashitova)
ЗВОНИЛ И НЕ ДОЗВОНИЛСЯ
Недавно жизнь занесла меня на Белградский митап QA. Кстати, очень приятное сообщество, всем его очень рекомендую. Надеюсь, я не сильно пошатнула ребят экзистенциальными вопросами к докладам.
И вот стою я в перерыве и ем пиццу, ибо откуда у меня днем время пообедать, догоняюсь. А рядом несколько QA обсуждают, кто такой старший QA, каким же он должен быть. И вот я их слушаю, слушаю, а потом предлагаю им свою теорию: что линейный специалист становится старшим, когда готов отвечать не за процесс, а за результат.
Помню, когда-то давно в одной моей команде был стажер. У него была задача договориться с разработчиком из соседней команды об интерфейсах взаимодействия. И вот утро, стендап, мы его спрашиваем, как дела с задачей, а он отвечает: "Я ему два раза звонил, и не дозвонился!" И серьезно видимо думает, что все правильно сделал.
Так вот, стажеру можно, а старшему нельзя. Потому что старший отвечает не за процесс — с кем ты там поговоришь, кому письмо напишешь, кому встречу назначишь, о чем вы поговорите. Старший отвечает за результат: интерфейсы согласованы. Можно было, не дозвонившись, написать в мессенджер или сходить ногами. Можно было связаться с тимлидом соседней команды и узнать, как выйти на контакт с нужным разработчиком. Можно было в конце концов попросить, чтобы интерфейсы с той стороны согласовал кто-то другой. Важно, чтобы они были согласованы, результат, а не процесс.
Младшему говорят, что и как делать.
Мидлу говорят, что делать.
Старшему говорят, какую задачу надо решить.
Ведущему говорят, в какой области надо приложить усилия, задачи он найдет себе сам.
Может показаться, что это только про софты, но нет. Без хардов этого тоже не достичь, просто харды в каждой профессии свои, а софты примерно одинаковые.
QA со мной, кстати, согласились.
#softskills
Недавно жизнь занесла меня на Белградский митап QA. Кстати, очень приятное сообщество, всем его очень рекомендую. Надеюсь, я не сильно пошатнула ребят экзистенциальными вопросами к докладам.
И вот стою я в перерыве и ем пиццу, ибо откуда у меня днем время пообедать, догоняюсь. А рядом несколько QA обсуждают, кто такой старший QA, каким же он должен быть. И вот я их слушаю, слушаю, а потом предлагаю им свою теорию: что линейный специалист становится старшим, когда готов отвечать не за процесс, а за результат.
Помню, когда-то давно в одной моей команде был стажер. У него была задача договориться с разработчиком из соседней команды об интерфейсах взаимодействия. И вот утро, стендап, мы его спрашиваем, как дела с задачей, а он отвечает: "Я ему два раза звонил, и не дозвонился!" И серьезно видимо думает, что все правильно сделал.
Так вот, стажеру можно, а старшему нельзя. Потому что старший отвечает не за процесс — с кем ты там поговоришь, кому письмо напишешь, кому встречу назначишь, о чем вы поговорите. Старший отвечает за результат: интерфейсы согласованы. Можно было, не дозвонившись, написать в мессенджер или сходить ногами. Можно было связаться с тимлидом соседней команды и узнать, как выйти на контакт с нужным разработчиком. Можно было в конце концов попросить, чтобы интерфейсы с той стороны согласовал кто-то другой. Важно, чтобы они были согласованы, результат, а не процесс.
Младшему говорят, что и как делать.
Мидлу говорят, что делать.
Старшему говорят, какую задачу надо решить.
Ведущему говорят, в какой области надо приложить усилия, задачи он найдет себе сам.
Может показаться, что это только про софты, но нет. Без хардов этого тоже не достичь, просто харды в каждой профессии свои, а софты примерно одинаковые.
QA со мной, кстати, согласились.
#softskills
Forwarded from Мягкие техники
Тап-аргументация
Это продолжение темы об аргументации. Вот первая заметка, в которой мы определили цель, сформулировали проблему и усилили её, чтобы босс оторвался от телефона и послушал.
Напомню, что всё это значит на примере:
___
ТАП-аргументация — это аббревиатура ключевых этапов аргументации: тезис, аргумент, поддержка.
Тезис — это утверждение или предложение, основное послание собеседнику.
Вот три шага, которые сделают из вашего тезиса настоящего мужикотавра:
Шаг №1: тезис однозначен. Он точно передаёт ключевую мысль так, чтобы оставалась только одна интерпретация твоих слов.
— Плохой тезис: «Я посмотрю эту задачу и позже дам знать.»
— Хороший тезис: «Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом.»
Шаг №2: тезис сформулирован ясно. Он состоит из понятных для аудитории слов и терминов.
— Плохой тезис: «Мы проведем небольшой кастдев, посмотрим на Гант (аналогично остальным инновационным инициативам), и в апреле вернусь к тебе с более детализированным, эмпирически обоснованным ответом.»
— Хороший тезис: «Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом.»
___
Продолжение будет в понедельник.
А с какими ошибками в построении тезисов вы сталкивались? Может, узнали себя или коллегу?
Это продолжение темы об аргументации. Вот первая заметка, в которой мы определили цель, сформулировали проблему и усилили её, чтобы босс оторвался от телефона и послушал.
Напомню, что всё это значит на примере:
Ситуация: пришёл босс и просит меня взять в работу его идею, обходя существующие процессы.
Цель (то, что я держу в голове на протяжении всего разговора): не брать задачи в бэклог, если они обходят установленные процессы. Даже если задача идёт от босса.
Проблема (то, что я озвучиваю на встрече): «Мы не можем взять эту задачу прямо сейчас.»
Усилитель проблемы (озвучиваю, если вижу, что собеседник слушает невнимательно или не понимает важность вопроса, либо если хочется вызвать эмоцию): «Босс, текущий бэклог уже полностью заполнен задачами, согласованными с тобой и смежными командами. Многие из них имеют строгие сроки и стратегическое значение. Если добавить твою задачу, это приведёт к двум вариантам: либо другие проекты будут задержаны, либо твоя задача останется нерешённой. В итоге возникнет хаос в управлении приоритетами, и эффективность команды снизится.»
___
ТАП-аргументация — это аббревиатура ключевых этапов аргументации: тезис, аргумент, поддержка.
Тезис — это утверждение или предложение, основное послание собеседнику.
Вот три шага, которые сделают из вашего тезиса настоящего мужикотавра:
Шаг №1: тезис однозначен. Он точно передаёт ключевую мысль так, чтобы оставалась только одна интерпретация твоих слов.
— Плохой тезис: «Я посмотрю эту задачу и позже дам знать.»
— Хороший тезис: «Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом.»
Однозначные советы по однозначности: проверить, указаны ли в тезисе место, количество, время, кто даст ответ, ограничения и т.д. Убедиться, что формулировки настолько ясны, что собеседник поймёт их так же, как и ты.
Шаг №2: тезис сформулирован ясно. Он состоит из понятных для аудитории слов и терминов.
— Плохой тезис: «Мы проведем небольшой кастдев, посмотрим на Гант (аналогично остальным инновационным инициативам), и в апреле вернусь к тебе с более детализированным, эмпирически обоснованным ответом.»
— Хороший тезис: «Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом.»
Почему сложная речь не работает?
Иногда мы начинаем заменять простые слова на сложные просто чтобы казаться умнее. Такой ход может сработать с одними, а других, наоборот, раздражает, ведь это выглядит как дешевая манипуляция. Лучше не применять дешевые трюки — выбирайте качественные методы!
Фанфакт: Трамп, например, использует в своих речах лексикон начальной школы, и, по мнению экспертов из Carnegie Mellon University, это помогает ему быть максимально понятным и побеждать в дебатах.
___
Продолжение будет в понедельник.
А с какими ошибками в построении тезисов вы сталкивались? Может, узнали себя или коллегу?
Forwarded from Мягкие техники
Шаг №3, тезис неизменен в процессе обсуждения — собеседник заявляет свою позицию и придерживается её в течение дискуссии.
Часто вижу как люди умышленно и не очень пользуются сменой тезиса в процессе спора. Обычно это происходит, когда одной стороне не хватает аргументов, но она принципиально не хочет соглашаться с другой.
1. Пример начального тезиса исполнителя
2. Исполнитель сменил тезис после того, как босс объяснил, что часть задач можно отложить
3. Исполнитель в третий раз сменил тезис, т. к. босс предложил декомпозировать задачу и оценить только первую часть
Кто-то скажет: «И что? Поторговались, договорились».
Проблема в том, что исполнитель показывает себя как ненадёжного собеседника, его слова необходимо «челленджить», т. к. он меняет ключевой тезис «на ходу» (читай: переобувается в воздухе). Он то ли ленивый, то ли недостатчно ответственный, то ли хитрый, то ли недостаточно опытен. В общем, он «Не свой».
В следующей заметке поговорим об аргументах.
___
С какими ошибками в построении тезисов вы сталкиваетесь? Может бы узнали себя или коллегу?
Часто вижу как люди умышленно и не очень пользуются сменой тезиса в процессе спора. Обычно это происходит, когда одной стороне не хватает аргументов, но она принципиально не хочет соглашаться с другой.
1. Пример начального тезиса исполнителя
Учитывая ограниченность моего временного ресурса и текущую операционную загрузку, я вынужден отложить детальный анализ данной задачи до момента, когда появится возможность уделить ей должное внимание — это, скорее всего, произойдет не ранее конца апреля.
2. Исполнитель сменил тезис после того, как босс объяснил, что часть задач можно отложить
Хорошо, допустим я найду время заняться этой задачей. Но из-за того, что многие ключевые участники уходят в отпуск, а праздники не за горами, мы вынуждены отложить подробное рассмотрение задачи.
3. Исполнитель в третий раз сменил тезис, т. к. босс предложил декомпозировать задачу и оценить только первую часть
Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом.
Кто-то скажет: «И что? Поторговались, договорились».
Проблема в том, что исполнитель показывает себя как ненадёжного собеседника, его слова необходимо «челленджить», т. к. он меняет ключевой тезис «на ходу» (читай: переобувается в воздухе). Он то ли ленивый, то ли недостатчно ответственный, то ли хитрый, то ли недостаточно опытен. В общем, он «Не свой».
В следующей заметке поговорим об аргументах.
___
С какими ошибками в построении тезисов вы сталкиваетесь? Может бы узнали себя или коллегу?
Forwarded from NoML Digest
Forwarded from Concise Research (Sergey Kastryulin)
Diffusability of Autoencoders
Латентная диффузия (LDM) - доминирующая парадигма генерации картинок и видео. Фреймворк LDM состоит из автоэнкодера (AE), кодирующего картинки или видео в латенты и диффузионного денойзера, который учат эти латенты расшумлять, а после - генерировать.
Большинство работ в контексте LDM посвящены диффузии, однако АЕ - не менее важный компонент системы. Энкодер АЕ задаёт распределение, которое выучит диффузия, а декодер определяет верхний предел качества реконструкции.
В этом посте речь пройдет про распределение латентов: как сделать его таким, чтобы максимизировать качество обученной на нем диффузии? Ниже представлены две одновременно вышедшие работы. Они решают проблему похожим образом, но исходят из разных предпосылок.
Improving the Diffusability of Autoencoders
Интуиция
Авторы используют интуицию о том что диффузия - это спектральная авторегрессия: на ранних шагах генерации модель предсказывает низкие частоты, после чего, обуславливаясь на них, генерирует всё более высокие. При этом, если АЕ продуцирует латенты со слишком большим количеством высоких частот, то это мешает ходу авторегрессии и, как следствие, генерации.
Инструменты анализа
Для оценки количества высоких частот авторы используют discrete cosine transform (DCT). Этот метод позволяет закодировать информацию последовательностью, каждый элемент которой хранит информацию о том сколько блоков картинки (или латента) содержат ту или иную частоту. Результат очень напоминает кодирующую матрицу JPEG, а её линеаризованный вариант - основа для большинства графиков в статье.
Анализ
Используя DCT, авторы показывают что:
🔜 Современные картиночные (FluxAE, CMS-AE) и видео (CogVideoX-AE, LTX-
AE) АЕ делают латенты более высокочастотными чем исходные картинки
🔜 Использование KL этому никак не препятствует
🔜 Увеличение числа каналов в латентах делает проблему более выраженной
Метод
Авторы считают, что моделям АЕ выгодно амплифицировать высокие частоты в латентах потому что качество их декодирования - ключевой критерий успеха обучения моделей. Для борьбы с этим предлагается простая регуляризация: давайте одновременно с подсчетом L1 и KL делать даунсемплинг (интерполяцию вниз) картинки и добавлять L1 для её реконструкции слагаемым в лосс. Таким образом зафорсится Scale Equivariance, которая будет мешать амплификации высоких частот
Эксперименты
Обучая разноразмерные DiT’ы поверх нескольких АЕ потюненных с регуляризацией, существенно снижаются FID/FDD и выравниваются DCT спектры. Сам тюн занимает всего 10к итераций с bs=32, что реально быстро и не дорого.
EQ-VAE: Equivariance Regularized Latent Space for Improved Generative Image Modeling
Интуиция
Авторы также замечают, что у современных АЕ отсутствует scale и rotation equivariance, однако их интуиция о том почему это плохо заключается в том что семантически близкие картинки не переводятся в семантически близкие латенты, что усложняет структуру латентного пространства, на которой учится диффузия
Метод
Вместо добавления регуляризационного слагаемого, авторы предлагают всегда учить модель на распределении картинок разного разрешения. Вариативность разрешений также достигается даунсемплиногом исходных картинок с переменным скейлинг фактором. Поскольку в изначальной постановке авторы используют смесь L1 и адверсариального лосса, то заскеленные картинки подаются в оба слагаемых
Эксперименты
Сетап и результаты похожи на описанные в предыдущей статье, хотя значения прироста FID чуть менее громкие. В сапмате интересные визуализации того как после файнтюна латенты становятся более гладкими
▶️ Discuss?
Всегда интересно, когда одновременно выходит несколько работ про примерно одно и то же. Это сильно повышает вероятность того, что в сказанном что-то есть
Латентная диффузия (LDM) - доминирующая парадигма генерации картинок и видео. Фреймворк LDM состоит из автоэнкодера (AE), кодирующего картинки или видео в латенты и диффузионного денойзера, который учат эти латенты расшумлять, а после - генерировать.
Большинство работ в контексте LDM посвящены диффузии, однако АЕ - не менее важный компонент системы. Энкодер АЕ задаёт распределение, которое выучит диффузия, а декодер определяет верхний предел качества реконструкции.
В этом посте речь пройдет про распределение латентов: как сделать его таким, чтобы максимизировать качество обученной на нем диффузии? Ниже представлены две одновременно вышедшие работы. Они решают проблему похожим образом, но исходят из разных предпосылок.
Improving the Diffusability of Autoencoders
Интуиция
Авторы используют интуицию о том что диффузия - это спектральная авторегрессия: на ранних шагах генерации модель предсказывает низкие частоты, после чего, обуславливаясь на них, генерирует всё более высокие. При этом, если АЕ продуцирует латенты со слишком большим количеством высоких частот, то это мешает ходу авторегрессии и, как следствие, генерации.
Инструменты анализа
Для оценки количества высоких частот авторы используют discrete cosine transform (DCT). Этот метод позволяет закодировать информацию последовательностью, каждый элемент которой хранит информацию о том сколько блоков картинки (или латента) содержат ту или иную частоту. Результат очень напоминает кодирующую матрицу JPEG, а её линеаризованный вариант - основа для большинства графиков в статье.
Анализ
Используя DCT, авторы показывают что:
AE) АЕ делают латенты более высокочастотными чем исходные картинки
Метод
Авторы считают, что моделям АЕ выгодно амплифицировать высокие частоты в латентах потому что качество их декодирования - ключевой критерий успеха обучения моделей. Для борьбы с этим предлагается простая регуляризация: давайте одновременно с подсчетом L1 и KL делать даунсемплинг (интерполяцию вниз) картинки и добавлять L1 для её реконструкции слагаемым в лосс. Таким образом зафорсится Scale Equivariance, которая будет мешать амплификации высоких частот
Эксперименты
Обучая разноразмерные DiT’ы поверх нескольких АЕ потюненных с регуляризацией, существенно снижаются FID/FDD и выравниваются DCT спектры. Сам тюн занимает всего 10к итераций с bs=32, что реально быстро и не дорого.
EQ-VAE: Equivariance Regularized Latent Space for Improved Generative Image Modeling
Интуиция
Авторы также замечают, что у современных АЕ отсутствует scale и rotation equivariance, однако их интуиция о том почему это плохо заключается в том что семантически близкие картинки не переводятся в семантически близкие латенты, что усложняет структуру латентного пространства, на которой учится диффузия
Метод
Вместо добавления регуляризационного слагаемого, авторы предлагают всегда учить модель на распределении картинок разного разрешения. Вариативность разрешений также достигается даунсемплиногом исходных картинок с переменным скейлинг фактором. Поскольку в изначальной постановке авторы используют смесь L1 и адверсариального лосса, то заскеленные картинки подаются в оба слагаемых
Эксперименты
Сетап и результаты похожи на описанные в предыдущей статье, хотя значения прироста FID чуть менее громкие. В сапмате интересные визуализации того как после файнтюна латенты становятся более гладкими
Всегда интересно, когда одновременно выходит несколько работ про примерно одно и то же. Это сильно повышает вероятность того, что в сказанном что-то есть
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Решил написать серию постов о недавно прочитанной книге. Я считаю её хорошей стартовой точкой для специалистов в области данных. В постах раскрою почему😊
———
Fundamentals of Data Engineering. Chapter #1: Data Engineering Described
🔵 Определение Data Engineering
DE - набор процессов включающий в себя: проектирование разработку и эксплуатацию систем принимающих сырые данные и производящих качественную, непротиворечивую информацию которую могут использовать другие системы и потребители (Аналитики, системы Machine Learning)
DE можно считать пересечением областей: Security, Data Management, DataOps, Data Architecture, Orchestration, Software Engineering.
🔵 Основные вехи Data Engineering
- Термин DWH (хранилище данных) был придуман Биллом Инмоном в 1989 году.
- IBM разработала реляционную базу данных и сам язык SQL.
- MPP и реляционные базы данных доминировали до тех пор, пока зарождающийся BigTech не задумался о том что пора бы начать экономить деньги.
- 2004: WhitePaper Google GFS. MapReduce положил начало парадигме сверхмасштабируемой обработки данных.
- 2006: Yahoo разработала Hadoop. AWS стало первым популярным общедоступным облаком.
- 2015: Появление Apache Spark. Охлаждение интереса к Hadoop стеку.
🔵 Цели Data инженера. На чем стоит фокусироваться специалисту?
1) постоянно проводить работу над cистемой по направлениям:
- Cost (стоимость)
- Agility (гибкость)
- Scalability (масштабируемость)
- Simplicity (простота)
- Reuse (повторное использование)
- Interoperability (совместимость)
2) максимизировать ценность и полезность данных.
3) работать над снижением рисков (безопасность, качество данных)
🔵 C кем взаимодействует Data Engineer?
С теми кто создает системы ответственные за генерацию / появление данных в продукте (upstream stakeholders):
- Software Engineers
- DevOps
- Data Architects
А также с потребителями информации произведенной Data продуктом (downstream stakeholders):
- Data Analysts
- Data Scientists
- Machine Learning Engineers
———
На этом всё, в следующем посте сделаю небольшое отвлечение, разберемся почему тема данных сейчас на хайпе, какую из этого них извлекают компании. В книге мне этого не хватило, автор сразу ушел в технику.
———
Fundamentals of Data Engineering. Chapter #1: Data Engineering Described
🔵 Определение Data Engineering
DE - набор процессов включающий в себя: проектирование разработку и эксплуатацию систем принимающих сырые данные и производящих качественную, непротиворечивую информацию которую могут использовать другие системы и потребители (Аналитики, системы Machine Learning)
DE можно считать пересечением областей: Security, Data Management, DataOps, Data Architecture, Orchestration, Software Engineering.
🔵 Основные вехи Data Engineering
- Термин DWH (хранилище данных) был придуман Биллом Инмоном в 1989 году.
- IBM разработала реляционную базу данных и сам язык SQL.
- MPP и реляционные базы данных доминировали до тех пор, пока зарождающийся BigTech не задумался о том что пора бы начать экономить деньги.
- 2004: WhitePaper Google GFS. MapReduce положил начало парадигме сверхмасштабируемой обработки данных.
- 2006: Yahoo разработала Hadoop. AWS стало первым популярным общедоступным облаком.
- 2015: Появление Apache Spark. Охлаждение интереса к Hadoop стеку.
🔵 Цели Data инженера. На чем стоит фокусироваться специалисту?
1) постоянно проводить работу над cистемой по направлениям:
- Cost (стоимость)
- Agility (гибкость)
- Scalability (масштабируемость)
- Simplicity (простота)
- Reuse (повторное использование)
- Interoperability (совместимость)
2) максимизировать ценность и полезность данных.
3) работать над снижением рисков (безопасность, качество данных)
🔵 C кем взаимодействует Data Engineer?
С теми кто создает системы ответственные за генерацию / появление данных в продукте (upstream stakeholders):
- Software Engineers
- DevOps
- Data Architects
А также с потребителями информации произведенной Data продуктом (downstream stakeholders):
- Data Analysts
- Data Scientists
- Machine Learning Engineers
———
На этом всё, в следующем посте сделаю небольшое отвлечение, разберемся почему тема данных сейчас на хайпе, какую из этого них извлекают компании. В книге мне этого не хватило, автор сразу ушел в технику.