Forwarded from ITипичные аспекты Артёма
Начало
Продолжу описывать процесс работы длиной в (предыдущую) неделю,мысли подходы в формате:
* Затраченное время
* Какие изменения вносил
* Какие выводы сделаны/инсайты получены
пнд-втр, 10+14=24ч.
- Загружен проект, проведена первичная оценка имеющейся кодбазы. У меня есть целый гуглдокумент на 9 страниц с говной, где я выписывал как на ревью все проблемы исходника.
Мы хотели во имя науки скормить его в таком виде ИИ чтоб он составил себе подробное ТЗ и по нему прошёлся, закрыв дыры
Эксперимент признан неудачным
Сводка самых критичных моментов:
- отсутствие БД(!), консистентного хранилища состояния.
- Фронт на сырых HTML шаблонах
- ЯндексS3 как единственное хранилище файлов (я не планировал использовать внешнее S3)
- Также наблюдалось огромное количество дыр в безопасности и производительности: по моим подсчётам, оно не должно было вытягивать больше 2-3 человек одновременно
- Модели кэшировались очень частично и вызывали зависания на несколько минут из-за подгрузки гигабайтов весов каждый первый запуск
- В некоторых кейсах происходили очень неявные критические баги. К примеру, если первая задача в систему не была с флагом на разделение спикеров, то ни одна последующая эту функцию запустить уже не сможет
Я очень недооценил на старте сырость исходника.
Вместе с тем, и это очень важно, Оно работало! Легаси кодбаза уже выступала в роли технического концепта желаемого функционала, а значит все ответы и фичи, хоть и реализованные криво уже были в ней, и моей задачей стал перепил структуры и организации кодбазы
Инсайты
- Я долго пытался понять, с какого бока приступить, это было очень сложной задачей - найти точку входа для изменений на легаси в 2-3к строк. Начал с фронта, философски отнесясь к бэкенду как к чёрной коробке с публичным контрактом, и потом уже переходить к бэку
- Фронт перепилился в TS+Vite приложение на удивление спокойно. Я, как совсем не фронтендер, не догадываюсь, какие ужасы там творились. Оно и к лучшему.
Самый важный инсайт - если позаботиться о хороших подробных описаниях-промптах и приложить референсы - ИИ может осилить даже объёмные структурные изменения.
- Хорошо показал себя метод, где сначала ИИ переписывает всё в один более большой файл и потом уже разбивает на несколько маленьких отдельной цепочкой рефакторинг промпт-задач
- Бэк представлял собой зрелище, не самое страшное в моей практике, но опасное ввиду неявно заложеннных бомб
ИИ плохо справляется с уменьшением сложности/вложенности кода и не всегда понимает проблему асинхронности, организации IO/Heavy задач.
Фокус на локальном решении текущей мелкой проблемы осложняет использование общих абстракций, моделей. Это должно фокусироваться отдельно через Rules, промпты.
Ненужная вложенность кода (функция обращается к функции которая обращается к функции и на каждом этапе размазан какой-то минимум важного кода) - характерная особенность ИИ стиля
- Очень приятный момент, можно спокойно писать "форму с логином" или "таймер в главном окне рядом с окном загрузки" - ИИ прекрасно оцифровывает и меняет нужные компоненты
- Курсор очень хорош в поиске и анализе кода. Можно спокойно спрашивать за незнакомый код и получать качественные вменяемые ответы
- Нужно следить за обезличенностью речи и не давать ему понять, что ты не согласен с решением/говнишься. ИИ тут же начинает всё срочно переделывать.
Никогда не спрашивайте ИИ напрямую, почему оно что-либо сделало, оно засчитает это за предъяву
- Курсору можно относительно доверять в аспекте консистентности изменений, в большинстве случаев он ничего не забудет поменять. Впечатляет, что я забываю менять какие-то импорты или куски логики в соседних файлах чаще чем ИИ
- Под конец вторника оно всё ещё было ужасно, никак не хотело заводиться, а я это очень нервно воспринимаю. На 14ом часу работу едва ли не в кровавые слёзы. Эффективнее по нервам, качеству и скорее всего по времени был бы подход - начать делать полностью с нуля, подкидывая исходники как референс для ИИ вдохновения
Продолжу описывать процесс работы длиной в (предыдущую) неделю,мысли подходы в формате:
* Затраченное время
* Какие изменения вносил
* Какие выводы сделаны/инсайты получены
пнд-втр, 10+14=24ч.
- Загружен проект, проведена первичная оценка имеющейся кодбазы. У меня есть целый гуглдокумент на 9 страниц с говной, где я выписывал как на ревью все проблемы исходника.
Мы хотели во имя науки скормить его в таком виде ИИ чтоб он составил себе подробное ТЗ и по нему прошёлся, закрыв дыры
Эксперимент признан неудачным
- отсутствие БД(!), консистентного хранилища состояния.
- Фронт на сырых HTML шаблонах
- ЯндексS3 как единственное хранилище файлов (я не планировал использовать внешнее S3)
- Также наблюдалось огромное количество дыр в безопасности и производительности: по моим подсчётам, оно не должно было вытягивать больше 2-3 человек одновременно
- Модели кэшировались очень частично и вызывали зависания на несколько минут из-за подгрузки гигабайтов весов каждый первый запуск
- В некоторых кейсах происходили очень неявные критические баги. К примеру, если первая задача в систему не была с флагом на разделение спикеров, то ни одна последующая эту функцию запустить уже не сможет
Я очень недооценил на старте сырость исходника.
Вместе с тем, и это очень важно, Оно работало! Легаси кодбаза уже выступала в роли технического концепта желаемого функционала, а значит все ответы и фичи, хоть и реализованные криво уже были в ней, и моей задачей стал перепил структуры и организации кодбазы
Инсайты
- Я долго пытался понять, с какого бока приступить, это было очень сложной задачей - найти точку входа для изменений на легаси в 2-3к строк. Начал с фронта, философски отнесясь к бэкенду как к чёрной коробке с публичным контрактом, и потом уже переходить к бэку
- Фронт перепилился в TS+Vite приложение на удивление спокойно. Я, как совсем не фронтендер, не догадываюсь, какие ужасы там творились. Оно и к лучшему.
Самый важный инсайт - если позаботиться о хороших подробных описаниях-промптах и приложить референсы - ИИ может осилить даже объёмные структурные изменения.
- Хорошо показал себя метод, где сначала ИИ переписывает всё в один более большой файл и потом уже разбивает на несколько маленьких отдельной цепочкой рефакторинг промпт-задач
- Бэк представлял собой зрелище, не самое страшное в моей практике, но опасное ввиду неявно заложеннных бомб
ИИ плохо справляется с уменьшением сложности/вложенности кода и не всегда понимает проблему асинхронности, организации IO/Heavy задач.
Фокус на локальном решении текущей мелкой проблемы осложняет использование общих абстракций, моделей. Это должно фокусироваться отдельно через Rules, промпты.
Ненужная вложенность кода (функция обращается к функции которая обращается к функции и на каждом этапе размазан какой-то минимум важного кода) - характерная особенность ИИ стиля
- Очень приятный момент, можно спокойно писать "форму с логином" или "таймер в главном окне рядом с окном загрузки" - ИИ прекрасно оцифровывает и меняет нужные компоненты
- Курсор очень хорош в поиске и анализе кода. Можно спокойно спрашивать за незнакомый код и получать качественные вменяемые ответы
- Нужно следить за обезличенностью речи и не давать ему понять, что ты не согласен с решением/говнишься. ИИ тут же начинает всё срочно переделывать.
Никогда не спрашивайте ИИ напрямую, почему оно что-либо сделало, оно засчитает это за предъяву
- Курсору можно относительно доверять в аспекте консистентности изменений, в большинстве случаев он ничего не забудет поменять. Впечатляет, что я забываю менять какие-то импорты или куски логики в соседних файлах чаще чем ИИ
- Под конец вторника оно всё ещё было ужасно, никак не хотело заводиться, а я это очень нервно воспринимаю. На 14ом часу работу едва ли не в кровавые слёзы. Эффективнее по нервам, качеству и скорее всего по времени был бы подход - начать делать полностью с нуля, подкидывая исходники как референс для ИИ вдохновения
Forwarded from Artem Ryblov’s Data Science Weekly
How to avoid machine learning pitfalls by Michael A. Lones
Mistakes in machine learning practice are commonplace, and can result in a loss of confidence in the findings and products of machine learning.
This guide outlines common mistakes that occur when using machine learning, and what can be done to avoid them.
Whilst it should be accessible to anyone with a basic understanding of machine learning techniques, it focuses on issues that are of particular concern within academic research, such as the need to do rigorous comparisons and reach valid conclusions.
It covers five stages of the machine learning process:
- What to do before model building
- How to reliably build models
- How to robustly evaluate models
- How to compare models fairly
- How to report results
Link: arXiv
Navigational hashtags: #armarticles
General hashtags: #ml #machinelearning #mlsystemdesign
@data_science_weekly
Mistakes in machine learning practice are commonplace, and can result in a loss of confidence in the findings and products of machine learning.
This guide outlines common mistakes that occur when using machine learning, and what can be done to avoid them.
Whilst it should be accessible to anyone with a basic understanding of machine learning techniques, it focuses on issues that are of particular concern within academic research, such as the need to do rigorous comparisons and reach valid conclusions.
It covers five stages of the machine learning process:
- What to do before model building
- How to reliably build models
- How to robustly evaluate models
- How to compare models fairly
- How to report results
Link: arXiv
Navigational hashtags: #armarticles
General hashtags: #ml #machinelearning #mlsystemdesign
@data_science_weekly
Forwarded from Кодим на Коленке | Уроки по программированию
Пишем Микросервисы на Python + Брокер RabbitMQ
Базовый гайд для тех, кто только знакомится с микросервисами на Python. Пишем систему уведомлений на микросервисной архитектуре. Стек: FastAPI, Aiogram, FastStream, RabbitMQ.
🗝 Урок живет здесь
Кодим на Коленке | #RabbitMQ
Базовый гайд для тех, кто только знакомится с микросервисами на Python. Пишем систему уведомлений на микросервисной архитектуре. Стек: FastAPI, Aiogram, FastStream, RabbitMQ.
🗝 Урок живет здесь
Кодим на Коленке | #RabbitMQ
YouTube
Пишем Микросервисы на Python + Брокер RabbitMQ
Базовый гайд для тех, кто только знакомится с микросервисами на Python. Пишем систему уведомлений на микросервисной архитектуре. Стек: FastAPI, Aiogram, FastStream, RabbitMQ.
🎓 Мы обучаем Python Backend-разработке так, чтобы ты писал код как инженер. Заходи…
🎓 Мы обучаем Python Backend-разработке так, чтобы ты писал код как инженер. Заходи…
Forwarded from Кодим на Коленке | Уроки по программированию
ПОЛНЫЙ КУРС ПО SELENIUM
Добро пожаловать на бесплатный курс по Selenium, в данном видеокурсе/плейлисте будут рассмотрены практически все аспекты Selenium, включая фишки, лайфаки и прочее!
🗝 Курс живет здесь
Кодим на Коленке | #Python
Добро пожаловать на бесплатный курс по Selenium, в данном видеокурсе/плейлисте будут рассмотрены практически все аспекты Selenium, включая фишки, лайфаки и прочее!
🗝 Курс живет здесь
Кодим на Коленке | #Python
Forwarded from rizzearch
Model-Preserving Adaptive Rounding
Альберт Тсенг может быть вам знаком по методам квантизаций qtip, quip/quip# и обучении ллм в mxfp4 , но не такому как quartet. он снова сделал квантизацию и получил алгоритм YAQA (Yet Another Quantization Algorithm)
GPTQ/LDLQ и AWQ методы производят квантизацию через прокси лосс разницы между активациями для отдельного слоя - layerwise mse + там присутствует гессиан для каждого слоя, который можно выразить через layer_input.T @ layer_input
здесь авторы возвращаются к более общей формулировке минимизации КЛ дивергенции между аутпутами оригинальной и сжатой моделями, выраженной через второй порядок → встает опять вопрос как посчитать более грамотно гессианы для каждого линейного слоя, которые все равно будут огромными из-за размерностей в современных ллм → надо снова аппроксимровать
используются те факты, что гессиан КЛ = fisher information matrix, которую можно эмпирически посчитать через gradient_loss.flatten() @ gradient_loss.flatten().T (один бекворд пасс) + произведение кронекера эквивалетно произведению с рангом 1, что можно получить через hessian-vector products, которые опять-таки хорошо компануются с бекворд пассом, упомянутым ранее, а следовательно и FSDP
вот так авторы и приближают оригинальный гессиан - через несколько итераций (до 3, power iterations) кронекер матрицами. при том они выводят 2 способа А и В
- А: дешевле (30 гпу-часов для 10В модели на 20М токенах), смещен, ниже разброс
- В: подороже (50 гпу-часов на 120М токенах), несмещен, но выше разброс → выше качество
второй получается лучше тем, что в нем нет предположения о независимости токенов внутри последовательностей (градиенты высчитываются по последовательностям). однако вариант А все равно получается лучше существующих методов в аппроксимации гессиана
также поскольку в сравнении с оригинальным LDLQ в учет идет не только фидбек от входных фичей (активаций), но еще и от выходных фичей, ибо оптимизируется end2end кл дивергенция оригинальной модели, то авторы расширяют понятие адаптивного округления → получаем, что LDLQ - частный случай YAQA
по экспериментам - проверяются на лламе и гемме, где к yaqa используют квантизатор qtip и домножение на матрицы Адамара для сглаживания. по всем битрейтам примерно на треть деркзо бьет все, что есть. точнее - все, с чем сравнивались, ибо насчет PV-Tuning & AQLM есть вот такой не менее дерзкий комментарий
👀 paper, code
Альберт Тсенг может быть вам знаком по методам квантизаций qtip, quip/quip# и обучении ллм в mxfp4 , но не такому как quartet. он снова сделал квантизацию и получил алгоритм YAQA (Yet Another Quantization Algorithm)
GPTQ/LDLQ и AWQ методы производят квантизацию через прокси лосс разницы между активациями для отдельного слоя - layerwise mse + там присутствует гессиан для каждого слоя, который можно выразить через layer_input.T @ layer_input
здесь авторы возвращаются к более общей формулировке минимизации КЛ дивергенции между аутпутами оригинальной и сжатой моделями, выраженной через второй порядок → встает опять вопрос как посчитать более грамотно гессианы для каждого линейного слоя, которые все равно будут огромными из-за размерностей в современных ллм → надо снова аппроксимровать
используются те факты, что гессиан КЛ = fisher information matrix, которую можно эмпирически посчитать через gradient_loss.flatten() @ gradient_loss.flatten().T (один бекворд пасс) + произведение кронекера эквивалетно произведению с рангом 1, что можно получить через hessian-vector products, которые опять-таки хорошо компануются с бекворд пассом, упомянутым ранее, а следовательно и FSDP
вот так авторы и приближают оригинальный гессиан - через несколько итераций (до 3, power iterations) кронекер матрицами. при том они выводят 2 способа А и В
- А: дешевле (30 гпу-часов для 10В модели на 20М токенах), смещен, ниже разброс
- В: подороже (50 гпу-часов на 120М токенах), несмещен, но выше разброс → выше качество
второй получается лучше тем, что в нем нет предположения о независимости токенов внутри последовательностей (градиенты высчитываются по последовательностям). однако вариант А все равно получается лучше существующих методов в аппроксимации гессиана
также поскольку в сравнении с оригинальным LDLQ в учет идет не только фидбек от входных фичей (активаций), но еще и от выходных фичей, ибо оптимизируется end2end кл дивергенция оригинальной модели, то авторы расширяют понятие адаптивного округления → получаем, что LDLQ - частный случай YAQA
по экспериментам - проверяются на лламе и гемме, где к yaqa используют квантизатор qtip и домножение на матрицы Адамара для сглаживания. по всем битрейтам примерно на треть деркзо бьет все, что есть. точнее - все, с чем сравнивались, ибо насчет PV-Tuning & AQLM есть вот такой не менее дерзкий комментарий
We do not directly compare to PV-Tuning since there are no public PV-Tuning models with either the QTIP or INT4 quantizer. However, LDLQ with the QTIP quantizer already outperforms PV-Tuning with the learnable AQLM quantizer on Llama 3.1, so we expect YAQA with QTIP to outperform PV-Tuning as well
👀 paper, code
Forwarded from rizzearch
Reinforcement Learning with Action Chunking
action chunking все больше набирает популярность из-за своей практичности в имитейшн лернинг - можно сказать, что для роботики это уже необходимый элемент в пайплайне, включая pi
и вот сергей левин со своими студентами нацелился на применение этого трюка для классического пайплайна actor-critic q-learning’a. формулы обобщаются при том довольно интуитивно понятно и перестают быть марковскими - везде одно действие меняется на чанк действий, что даже улучшает понятие n-step return’a, где использовали для расчета значения критика n шагов вперед вместо одного, ибо тогда убирается смещение off-policy действий этого чанка действий
имплементится это через диффузию и флоу матчинг с ограничением на приверженность behavior policy в offline и offline-to-online рл сетапах. при том в сетапе с диффузией КЛ ограничение между политиками реализуют через best-of-n sampling (BFN), а с флоу матчингом сшивание идей происходит более гладко, без изменений в ключевых местах алгоритма FQL. экспы проводят над RLPD, где внутри онлайн степов батч состоит наполовину из онлайн и оффлайн буфферов
при том предикт по чанкам улучшает момент эксплорейшна, ибо, как спекулируют авторы, действия внутри одного чанка становятся более связанными относительно друг друга (в сравнении с 1-step методами) → при инференсе можем ожидать поведение получше + sample efficiency
пока и остается большой вопрос по поводу размера чанка, который сильно влияет на перформанс (на OGBench 10 действий в одном чанке у авторов лучше чем 25), а по балансу между рантаймом и sample efficiency неплохо было бы перепроверить, действительно ли обучение происходит быстрее бейзлайнов
👀 paper, code
action chunking все больше набирает популярность из-за своей практичности в имитейшн лернинг - можно сказать, что для роботики это уже необходимый элемент в пайплайне, включая pi
и вот сергей левин со своими студентами нацелился на применение этого трюка для классического пайплайна actor-critic q-learning’a. формулы обобщаются при том довольно интуитивно понятно и перестают быть марковскими - везде одно действие меняется на чанк действий, что даже улучшает понятие n-step return’a, где использовали для расчета значения критика n шагов вперед вместо одного, ибо тогда убирается смещение off-policy действий этого чанка действий
имплементится это через диффузию и флоу матчинг с ограничением на приверженность behavior policy в offline и offline-to-online рл сетапах. при том в сетапе с диффузией КЛ ограничение между политиками реализуют через best-of-n sampling (BFN), а с флоу матчингом сшивание идей происходит более гладко, без изменений в ключевых местах алгоритма FQL. экспы проводят над RLPD, где внутри онлайн степов батч состоит наполовину из онлайн и оффлайн буфферов
при том предикт по чанкам улучшает момент эксплорейшна, ибо, как спекулируют авторы, действия внутри одного чанка становятся более связанными относительно друг друга (в сравнении с 1-step методами) → при инференсе можем ожидать поведение получше + sample efficiency
пока и остается большой вопрос по поводу размера чанка, который сильно влияет на перформанс (на OGBench 10 действий в одном чанке у авторов лучше чем 25), а по балансу между рантаймом и sample efficiency неплохо было бы перепроверить, действительно ли обучение происходит быстрее бейзлайнов
👀 paper, code