Интересное что-то
518 subscribers
2.72K photos
253 videos
140 files
4.53K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Forwarded from Инжиниринг Данных (Dmitry)
Практически каждый проект в инжиниринге данных начинается с package manager (пакетный менеджер), как правило для Python.

С одной стороны у всех цель одна, а с другой стороны “кто в лес, кто по дрова”.

Мне попались 3 хорошие статьи от Dagster на эту тему (про сам Dagster там нет), в которых хорошо рассказывают как это работает и как сделать удобно и красиво.

Python Packages: a Primer for Data People (part 1 of 2)
Python Packages: a Primer for Data People (part 2 of 2)
Best Practices in Structuring Python Projects

Вообще там 11 частей, в каждом посте будут ссылки на все части, например есть и другие полезные:
High-performance Python for Data Engineering
Write-Audit-Publish in data pipelines
Breaking Packages in Python
CI/CD and Data Pipeline Automation (with Git)
Factory Patterns in Python
Type Hinting in Python
Environment Variables in Python

Если вы еще на “вы” со всеми этими менеджерами, зависимостями или не очень понимаете, что творится у вас на работе в репозитории, то будет полезно ознакомиться.
ℹ️ Докер и Кубер!

Увидел классное объяснение в комментах в одном из чатов про докер и кубернетес..

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

Вот докер - это сильно улучшенная виртуалка. Лучше тем, что меньше ресурсов жрет. Она тоже изолированная от основной ОС.

Кубернетес - это штука, которая позволяет удобно и автоматически управлять этими "виртуалками" внутри докера.

Представь, что программисту нужно для работы запустить Базу данных postgress + кеширующий Redis сервер + очередь сообщений RabbitMQ. И желательно, чтобы у всех разработчиков были установленны одинаковые версии этих инструментов и на сервере тоже были бы установленны точно такие же версии этих инструментов. Потому что, внезапно, если на сервере postgress 14, а кто-то из разработчиков устновит локально версию 17, то может оказаться, что у него локально что-то работает, а на сервере - не работает.

Так вот, чтобы добиться такого однообразия обычно в проекте у программистов есть docker-compose файл. Это файл позволяет запустить однократно сколько угодно этих docker "виртуалок" с одинаковыми настройками на каждом из компьютеров разработчиков локально.

На этом шаге мы добились того, что у всех программистов локально используется одни и те же версии инструментов. Но нам же нужно то, что программисты наделали как-то проверять? Для этого и создаются "стенды для демонстрации и тестов".

Тут нам и нужен кубернетес. Отличие его от docker-compose в том, что компоуз однократно запускает, то что описано в файле, а дальше ему насрать, что происходит с теми "докер виртуалками". А кубернетес он еще и проверяет, что эта "докер виртуалка" нормально работает и отвечает на запросы. И если вдруг одна из запущенных виртуалок перестанет подавать признаки жизни (перестанет, например, отвечать на ping больше 30 секунд), то кубернетес автоматически удалит такую зависшую виртуалку и запустит вместо неё новую.

Мы, сильно упрощая, на сервере тоже скармливаем такой же docker-compose файл, но kubernetes-у. И он запускает все необходимые виртуалки, следит, чтобы они были запущены и в случае любых проблем перезапускает их.

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

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

Максимально упрощенно это работает вот так :)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevFM
Осенью я посещал конференцию ArchDays и уже делился впечатлениями — восторга она у меня не вызвала. Однако было два доклада, которые мне понравились. Организаторы выложили записи в открытый доступ, и я с удовольствием делюсь этими докладами — они точно заслуживают внимания.

▫️Замечательный своей концептуальностью доклад Александра Поломодова “Архитектура в Т-Банке: вчера, сегодня, завтра
▫️И очень практический доклад Виталия Минко “Архитектурные практики на практике

#youtube
Forwarded from DevFM
"All you need is Postgres" – наверняка слышали этот боевой клич

Недавно наткнулся на целый репозиторий, где собрали кучу интересных задач и способов их решения прямо в Postgres.

Репозиторий оказалася очень залипательным, можно походить по ссылочкам, узнать какие штуки бывают. Так, например, узнал про PGlite — Postgres in WASM. Просто берёшь и запускаешь базу прямо в браузере. Без всяких линуксовых виртуальных машин. Ну очень интересно!

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

#database
отличный туториал, как написать LLaMa 3 c нуля по шагам: https://github.com/naklecha/llama3-from-scratch

идейный продолжатель Андрея Карпатого, но тут вместо бородатого мужика - кавайная анимешная девочка, на мой взгляд - выбор очевиден
Forwarded from Bahamut
https://github.com/oobabooga/text-generation-webui/blob/main/requirements.txt

Например в этом файле вы можете увидеть собранные им под определенное окружение вилсы.
Самый простой и грубый способ.
Forwarded from Aspiring Data Science (Anatoly Alekseev)
#timeseries #ensembling #todo #hetboost

Что мне тут нравится, ансамблируются не просто МЛ-модельки, а еще и статмодельки.

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

У меня планируется исследование/сравнение продвинутых методов ансамблирования, и даже есть идея своего метода.
Это будет микс гетерогенного бустинга, ансамблевого отбора и стэкинга.

https://www.youtube.com/watch?v=xnF9QajUzv0
Forwarded from Aspiring Data Science Chat
Вышла приятная обзорка по методам посттренинга LLMов и по ризонингу. С красивыми табличками, схемками.

Много про разного вида RL который можно применять, цепочки рассуждений, test-time scaling и вот это все
Читаем!

LLM Post-Training: A Deep Dive into Reasoning Large Language Models
https://arxiv.org/abs/2502.21321

И конечно же листик пособирали, тоже приятный.

https://github.com/mbzuai-oryx/Awesome-LLM-Post-training

PS собираемся и собираем все крутое по нейронкам тут https://t.me/researchim
Forwarded from Knowledge Accumulator
Gumbel-Softmax - памятка себе на будущее

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

VAE - это автоэнкодер, состоящий из моделей q(z|x) и p(x|z), которые выдают распределение на скрытую компоненту z по входу x и наоборот. В базовом варианте z имеет нормальное распределение N(m;d), и энкодер выдаёт параметры этого распределения - средние m и ст. отклонения d.

При обучении подобной модели у нас возникает градиент ошибки по сэмплу из z. Как пробросить градиент назад в модели "сквозь" это сэмплирование? В лоб сделать это не получится, и для этого применяют простой советский Reparametrization Trick.

Его суть в том, что процесс сэмплирования отделяют от основной цепочки вычислений и оформляют как входную вершину вычислительного графа. В случае с нормальным распределением, мы сначала отдельно сэмплируем eps из N(0;1), а затем умножаем его на d и прибавляем m. По факту результат тот же самый, но он превращает нейросеть в цепочку детерминированных операций и позволяет пробрасывать градиент бэкпропом.

Gumbel-Softmax - то же самое, но для категориального распределения.

Вместо обычного VAE давайте взглянем на VQ-VAE - альтернативный вариант автоэнкодера, в котором вместо сжатия в нормальное распределение происходит сжатие в категориальное распределение на "коды". Внутри модели хранится Codebook, который превращает номер кода обратно в эмбеддинг во время декодинга.

Итак, в сердцевине модели находится такая цепочка вычислений: logits -> probs -> one-hot vector -> embedding. При переходе из probs к one-hot vector как раз и возникает сэмплирование из категориального распределения, сквозь которое нельзя пробросить градиент напрямую.

Gumbel-Softmax позволит приближенно осуществить этот переход с помощью детерминированной операции. Если к логарифму от вектора probs прибавить вектор из распределения Гумбеля (аналог N(0;1) в данном случае), то argmax итогового вектора будет распределён так же, как и исходное распределение.

Последняя проблема - argmax сам недифференцируем, поэтому его заменяют на софтмакс с маленькой температурой. В итоге, получая на вход [0.2;0.8], эта операция будет выдавать [0.001; 0.999] в 80% случаев и [0.999;0.001] в 20 процентах случаев.

Самый большой затык вызывает следующий вопрос - в чём профит этой штуки по сравнению с тем, чтобы просто использовать [0.2;0.8] в дальнейших операциях, если там всё равно не требуется строгий one-hot вектор?

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

А что делать в случае, когда нам реально нужен строгий one-hot вектор, например, если это RL и мы совершаем действие? Авторы оригинальной статьи предлагают комбинировать Straight Through Estimator и Gumbel Softmax, т.е. использовать [1; 0], а градиент пробрасывать так, как будто там был [0.999; 0.001]. Но я никогда не встречал применения такой схемы.

@knowledge_accumulator