#cv #gan

Reconstruction vs. Generation: Taming Optimization Dilemma in Latent Diffusion Models
[код и веса]

Выбор представления для обучения латентной диффузии - важнейший фактор качества и скорости обучения модели.

Более высокая размерность
латентного пространства улучшает качество реконструкции. Обычно она достигается путём увеличения числа каналов. VAE первых моделей семейства SD имели 4 канала, у FLUX и SD3 уже 16, а SANA - 32.

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

Интересно, что проблемы связанные с большой размерностью ранее обсуждали в основном для дискретных токенизаторов. Для них известно, что большие кодбуки плохо утилизируются. Авторы этой работы анализируют распределение латентов непрерывных VAE и приходят к такому же выводу. Идея работы в том чтобы заалайнить латенты с фичами visual foundation model, тем самым улучшив их качество с точки зрения обучения на них генеративных моделей.

Метод
Основной вклад работы - двухкомпонентный лосс, который алайнит VAE латенты Z с фичами DINOv2 F. Для этого Z линейно отображают в размерность F получая Z’, после чего:
1️⃣ Поэлементно минимизируют косинусное расстояние между Z’ и F
2️⃣ Минимизируют разницу косинусных расстояний между элементами Z’ и F

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

Эксперименты
За основу берут ванильный LDM сетап с VQ-GAN токенизатором (f16d32, f16d16), но без квантизации. На его латентах учат DiTы от 0.1B до 1.6В c полным фаршем из RF, подбора adam.beta2, bfloat16 и RMSNorm для стабилизации, SwiGLU и RoPE. Полученная серия моделей LightningDiT сходится к FID 1.35 на ImageNet 256, причем значение 2.11 получается всего за 64 эпохи.

Выводы
В статье настораживает почти полное отсутствие примеров реконструкций предложенных VAE и аблейшенов влияния примочек для DiT на рост качества относительно бейзлайнов. Нравится движение в сторону недоизученной темы оптимальных пространств для обучения генеративок

Spent last half a year rejecting the idea of switching to cursor.sh. Tried it today, and it has the most important feature that is missing from all other major competitors: You can directly use RAG within your prompt. Example use case: I need to convert class names from simplified nomenclature to a normal one, and they are stored in 3 different sources: website with documentation, json file with training data, csv file with labels. Only in cursor you can tag specific sources (and even specific places within those sources like fields in json etc.) and give as precise instructions as possible

О чём нам говорят результаты O3?

Пару недель назад были опубликованы первые эвалы новой флагманской модельки от OpenAI. Она совершила прорыв на semi-private eval в ARC и в нескольких других бенчмарках про код и математику, Какой вывод мы из этого можем сделать?

Я не знаю всех слухов и деталей, так что, поправьте в комментариях, если не прав. Сконцентируюсь на ARC, так как понимаю про него больше всего.

Прорыв при переходе от O1 к O3 произошёл от трёх изменений:

1) Увеличение ресурсов на Chain of Thought
2) Добавление тренировочных ARC-задач в обучение модели
3) Неизвестные нам изменения между моделями.

Отрывочные данные выглядят так, что ключ к успеху именно в первых двух пунктах.

В RLHF (я её не очень давно разбирал) существует 2 компоненты, отвечающие за её качество. Первая - это Reward Model (RM) - "оценщик" текста, который смотрит на него и предсказывает, несколько он "хорош". Задача оценки сильно проще задачи генерации, и такую модель обучают на больших объёмах человеческой разметки из разных источников.

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

Что делает Chain of Thought? Грубо говоря, модель генерирует рассуждение и множество вариантов ответов на запрос, а затем сама же выбирает из них финальный. Если бы RLHF работал хорошо и генератор умел генерировать текст, который ему же самому понравится в конце (т.е. и RM), то CoT бы ничего особо не давал.

Таким образом, если увеличение затрат с 20 долларов до 2000 на запрос серьёзно увеличивает профит (как в O3), то у меня для вас плохая новость - RL и тут работает, как обычно.

Тем не менее, не вижу ничего страшного. Для меня важной является принципиальная способность решить задачу, а не потраченный компьют. Если сегодня задачу можно решить за 2к долларов, значит, через 10 лет такой же алгоритм решит её за 100.

Когда тренировочные задачи из ARC добавили в обучающий датасет для O3, то задача для RM сильно упростилась. Бенчмарк вместо вопроса "Умеет ли модель решать принципиально новые задачи?" начинает задавать "Умеет ли модель решать новые задачи, похожие на обучающую выборку?". То, что O3 стала настолько лучше после добавления задач в тренировочный датасет, говорит о двух вещах:

1) Если добавлять принципиально новые задачи в тренировочный датасет, то модель как-то сможет обобщать их решения - это хороший знак
2) Если похожих задач в данных вообще нет, то модель будет работать гораздо хуже - это плохая новость для тех, кто хочет, чтобы модель с 1 пинка решала новую уникальные задачи, тем более, такие, которые в принципе не решены человеком.

Что касается использования на практике, то вряд ли я буду трогать O3 - сомневаюсь в том, что она выдаст что-то настолько интересное, за что можно заплатить 10+ долларов за ответ. Даже O1 с его 1 долларом за ответ мне было жалко дёргать, и я не смог вымолить у неё один нестандартный кусок кода за вечер. С бытовыми задачами генерации текста справлялась даже GPT-4, а писать код на работе помогает Copilot, который на основе O3 будет думать непозволительно долго. Посмотрим, как оно будет выглядеть после релиза.

@knowledge_accumulator

#python #code

Правильный ответ: Результат работы программы зависит от версии и интерпретатора Python.

Дело в том что в старых версиях CPython (до версии 3.10). оператор +=. работал с точки зрения интерпретатора как две операции. И несмотря на наличие GIL и отсутствие параллелизма получался data race и значение счетчика не соответствует ожидаемому.

В CPython 3.10 внесли изменения в интерпретатор и подобный код выдает стабильно правильное значение.

Но если видоизменить пример то все ломается:

class CounterWithConversion:
  def __init__(self):
    self.val = 0
  
  def change(self):
    self.val += int(1) # единственное отличие - операция преобразования типа

Этим квизом я хотел наглядно продемонстрировать, что не всегда наличие GIL защищает от неконсистентности. Использование мьютексов необходимо, чтобы гарантировать корректную работу программы.

Об этом интересном кейсе я писал статью на хабре, там внутри больше экспериментов + ссылка на коммит в интерпретатора CPython + ссылка на репозиторий с кодом, который можно запустить и проверить поведение. Даже в комментариях мы с ребятами придумывали варианты как бы еще сломать код и находили интересные кейсы😊

https://habr.com/ru/articles/764420/

Забыл рассказать про еще один вывод на который натолкнул меня пример с счетчиком в многопоточной среде.

Ранее мы разобрались в том что на уровне железа у нас есть определенные гарантии и мы когда пишем код знаем какое поведение с точки зрения работы с памятью ожидать (или наоборот) от программы на x86 или например ARM процессоре.

В языках программирования с этим сложнее. Вот если взять Python - пример выше демонстрирует что с точки зрения памяти в многопоточной среде нет каких то строгих и фиксированных правил. Корректный код на одной версии Python не обязательно будет корректным на другой версии, а если запускать на другом интерпретаторе то шансы словить багулю ещё выше. Пример с счетчиком лишь вершина айсберга.

Как с этим жить? Мой опыт говорит:
- Не использовать Concurrency без четкого понимания зачем.
- Если используешь то минимизировать общее состояние.
- Общее состояние которое осталось покрыть блокировками.

На этом завершаю разбор языка Python с точки зрения Concurrency, следующим языком будет либо Ruby либо Java😊

Если вам хочется больше примеров кода и практики то прикрепляю хорошие ссылки:
- Практический гайд по процессам и потокам (и не только) в Python - бенчмаркаю и делаю выводы о производительности процессов, потоков и корутин.
- Python behind the scenes #13: the GIL and its effects on Python multithreading - офигенный пост в рамках не менее офигенного цикла статей. Горячо рекомендую если не видели.

———

А если интересно как я изучал Python то здесь всё:
🐍 Как я изучал Python. Step 1 - Изучение языка.
🐍 Как я изучал Python. Step 2 - Инструменты и библиотеки.
🐍 Как я изучал Python. Step 3 - Concurrency

#python #books #code #courses

🐍 Как я изучал Python. Step 1 - Изучение языка.

Цикл постов посвящённый языкам программирования с которыми я работал в production близится к концу. Ранее я подробно рассказал о том как изучал Ruby и Go.
Пришло время Python - языка в который я перекатывался из Ruby и на котором до сих пор прохожу алгоритмические собеседования. В этом посте расскажу о погружении в базу и фундамент языка.

1️⃣ Full Speed Python: a book for self-learners

Великолепная бесплатная методичка с упражнениями. Читается за пару часов, не нудно, с обилием примеров. Мне особенно понравилось как автор красиво провел линию повествования от итераторов коллекций до генераторов и asyncio. Супер доходчиво и понятно.


2️⃣ Python Koans - Learn Python through TDD

Еще один ресурс для тех кому лень читать огромные книги и хочется учиться на практике. Нужно лишь склонировать репозиторий и исправлять код пока все тесты не станут зелеными. Комбо: Git + Python + Tests


3️⃣ Comprehensive Python Cheatsheet

Очень подробная бесплатная шпаргалка по различным конструкциям языка


4️⃣ WTF Python - сборник примеров "магии" и особенностей языка

На этом мой минимальный набор окончен. Пишите в комментарии, каким был ваш путь в изучении Python?)

В следующих постах расскажу про тулинг и экосистему😊

#python #books #courses

🐍 Как я изучал Python. Step 2 - Инструменты и библиотеки.

После изучения основных конструкций языка я начал погружаться в тулинг, так как понимал по опыту с Ruby - сам язык это всего лишь часть картины, и программисту важно не только писать код но и пользоваться инструментами написанными другими.

🔹The Hitchhiker’s Guide to Python! (MUST HAVE)
Великолепная бесплатная книга обо всем. Начиная с того как правильно установить язык на свой компьютер заканчивая best practices по написанию качественного кода. Если вы начинающий питонист - переходите по ссылке и на многие вопросы найдете ответы😊

🔹Python Packaging User Guide
Оказывается в официальной доке Python есть целый цикл статей о том как правильно оборачивать свой код в пакеты для дальнейшего переиспользования. Если перед вами стоит задача на работе требующая переиспользования кода советую присмотриться чтобы сделать всё по красоте

🔹Pyenv - Simple Python version management
Невероятно полезная утилита для размещения нескольких версий Python на одной машине. Удобно если работаешь с несколькими проектами + для тестирования различных корнер кейсов. Мне эта утилита помогла обнаружить undefined behaviour в Python, о котором я писал на Хабре.

Code Quality Tools
🔹Black - The uncompromising Python code formatter
🔹WemakePythonStyleGuide - The strictest and most opinionated python linter ever!

Как видите список не то чтобы большой, все таки не так долго по времени удалось поработать с Python, наверняка многие современные тулы я упустил из виду😁

Расскажите в комментариях про полезные инструменты и библиотеки которые помогают вам в ежедневной работе🙃

#python #courses