Интересное что-то
517 subscribers
2.71K photos
252 videos
138 files
4.51K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.iss.one/asisakov_channel
Чат: https://t.iss.one/youknowds_chat
Download Telegram
Страх и ненависть в Cursor

Тренды идут, а я не в трендах. Да и кодинг навыки в бытность мою лидом начали практиковаться значительно меньше 4-6 часов в день, необходимых для поддержания формы.
Потому, вдохновлённый опытом Валеры, моего любимого соратника-затейника, я самоорганизовался в недельный хак-интенсив безудержного AI кодинга.

Центральная идея
Глобально - Возможно ли за счёт скорости и экспертизы AI написать качественный код в сроки демки?
Если так, AI кодинг при должных навыках способен открыть прямой и быстрый прыжок от демо-прототипа к MVP.
Почему это важно:
Сейчас демки собираются либо на коленке, либо на морально волевых. И потом, как правило, переписывается под 0, часто уже другой командой, ибо говнокод, противно и нерасширябельно.
MVP - уже достаточно развитая система с проработанным и зафиксированным наборов бизнес-фичей, пригодная для стабильного запуска на малой аудитории, достаточно качественная и корректно организованная технически для комфортной итерационной разработки/развития в будущем.


С чем стартовал:

Ящик энергетосов и репо мне на растерзание. Как здесь, только страшнее, с повышенным содержанием сенситивных данных, хардкода ссылок и невменяемого .env. Это результат ~30 часов ИИ кодинга специалиста, не занимающегося промышленным программированием. Буду далее называть его легаси кодбазой.

Здравый смысл и начавший подёргиваться глаз подсказывали не ввязываться с этим кодом.
Тем не менее, это был вполне рабочий(!) проект, демонстрирующий все основные интересные мне сценарии. Некоторая исследовательская жилка ИИ артефактов всё-таки взыграла.
Да и потом, откуда ещё получить и поделиться бесценным опытом. Насколько бесценным? БД проекта выглядела вот так.
class DatabaseService:
"""Сервис для работы с JSON базой данных"""

def __init__(self):
self.lock = threading.Lock()

def load_database(self) -> Dict:
"""Загрузка базы данных из JSON файла"""
with self.lock:
if DATABASE_FILE.exists():
try:
with open(DATABASE_FILE, 'r', encoding='utf-8') as f:
data = json.load(f)
# Обеспечиваем структуру базы данных
if 'transcriptions' not in data:
data['transcriptions'] = {}
if 'users' not in data:
data['users'] = {}
if 'sessions' not in data:
data['sessions'] = {}
return data

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


Задачи интенсива
- Разработать систему транскрибации, как можно ближе сходящуюся к уровню MVP по зрелости и качеству кода и технической архитектуры.
Небходимые целевые фичи:
* Гугл авторизация
* Получение транскрипта файла (в базу взяли WhisperX)
* Получение разбиения по спикерам (pyannote)
* Аналитический отчёт по содержанию файла ( LLM + proдуманный prompt)
* Запись встреч (ввиду сжатых сроков пришли к идее google extension - запись вкладка+микро, что мне кажется гениальным в своей универсальности)
* Развёртывание на сервере, Docker базовая инфра

- Посчитать выигрыш в своей скорости относительно плана реализации вручную.
- Выявить для себя правила оптимального использования ИИ
- Разобрать кейс доработки "легаси" кодбазы.

Как оно было
С чем столкнулся, к чему пришёл, что посчитал и как оно в итоге - будет дальше.
Начало

Продолжу описывать процесс работы длиной в (предыдущую) неделю,мысли подходы в формате:
* Затраченное время
* Какие изменения вносил
* Какие выводы сделаны/инсайты получены


пнд-втр, 10+14=24ч.
- Загружен проект, проведена первичная оценка имеющейся кодбазы. У меня есть целый гуглдокумент на 9 страниц с говной, где я выписывал как на ревью все проблемы исходника.
Мы хотели во имя науки скормить его в таком виде ИИ чтоб он составил себе подробное ТЗ и по нему прошёлся, закрыв дыры
Эксперимент признан неудачным

Сводка самых критичных моментов:
- отсутствие БД(!), консистентного хранилища состояния.
- Фронт на сырых HTML шаблонах
- ЯндексS3 как единственное хранилище файлов (я не планировал использовать внешнее S3)
- Также наблюдалось огромное количество дыр в безопасности и производительности: по моим подсчётам, оно не должно было вытягивать больше 2-3 человек одновременно
- Модели кэшировались очень частично и вызывали зависания на несколько минут из-за подгрузки гигабайтов весов каждый первый запуск
- В некоторых кейсах происходили очень неявные критические баги. К примеру, если первая задача в систему не была с флагом на разделение спикеров, то ни одна последующая эту функцию запустить уже не сможет


Я очень недооценил на старте сырость исходника.
Вместе с тем, и это очень важно, Оно работало! Легаси кодбаза уже выступала в роли технического концепта желаемого функционала, а значит все ответы и фичи, хоть и реализованные криво уже были в ней, и моей задачей стал перепил структуры и организации кодбазы


Инсайты

- Я долго пытался понять, с какого бока приступить, это было очень сложной задачей - найти точку входа для изменений на легаси в 2-3к строк. Начал с фронта, философски отнесясь к бэкенду как к чёрной коробке с публичным контрактом, и потом уже переходить к бэку

- Фронт перепилился в TS+Vite приложение на удивление спокойно. Я, как совсем не фронтендер, не догадываюсь, какие ужасы там творились. Оно и к лучшему.
Самый важный инсайт - если позаботиться о хороших подробных описаниях-промптах и приложить референсы - ИИ может осилить даже объёмные структурные изменения.

- Хорошо показал себя метод, где сначала ИИ переписывает всё в один более большой файл и потом уже разбивает на несколько маленьких отдельной цепочкой рефакторинг промпт-задач

- Бэк представлял собой зрелище, не самое страшное в моей практике, но опасное ввиду неявно заложеннных бомб

ИИ плохо справляется с уменьшением сложности/вложенности кода и не всегда понимает проблему асинхронности, организации IO/Heavy задач.
Фокус на локальном решении текущей мелкой проблемы осложняет использование общих абстракций, моделей. Это должно фокусироваться отдельно через Rules, промпты.

Ненужная вложенность кода (функция обращается к функции которая обращается к функции и на каждом этапе размазан какой-то минимум важного кода) - характерная особенность ИИ стиля

- Очень приятный момент, можно спокойно писать "форму с логином" или "таймер в главном окне рядом с окном загрузки" - ИИ прекрасно оцифровывает и меняет нужные компоненты

- Курсор очень хорош в поиске и анализе кода. Можно спокойно спрашивать за незнакомый код и получать качественные вменяемые ответы

- Нужно следить за обезличенностью речи и не давать ему понять, что ты не согласен с решением/говнишься. ИИ тут же начинает всё срочно переделывать.

Никогда не спрашивайте ИИ напрямую, почему оно что-либо сделало, оно засчитает это за предъяву

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

- Под конец вторника оно всё ещё было ужасно, никак не хотело заводиться, а я это очень нервно воспринимаю. На 14ом часу работу едва ли не в кровавые слёзы. Эффективнее по нервам, качеству и скорее всего по времени был бы подход - начать делать полностью с нуля, подкидывая исходники как референс для ИИ вдохновения
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
ПОЛНЫЙ КУРС ПО SELENIUM

Добро пожаловать на бесплатный курс по 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 есть вот такой не менее дерзкий комментарий
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