Я принес. Бреслав и Ложечкин: вся правда о грейдах, ревью и промоушенах

У нас в подкасте «Три тимлида заходят в бар» как-то был выпуск про ревью. Тем не менее мне было интересно послушать, что об этом думают и другие уважаемые господа.

Бреслав и Ложечкин как раз для меня являются таковыми, и не так давно я у них послушал про это выпуск https://t.me/breslavandlozhechkin/24.

Очень полезно послушать тем, кто работает в бигтехах и вообще крупных компаниях, а еще тем, кто рассматривает вариант там поработать.

На мой взгляд, тема раскрыта довольно честно и объективно. Взять хотя бы тему, что «справедливости» никакой в этом нет. Просто компании соревнуются между собой, чтобы «несправедливости» было поменьше (чтобы к ним ходили, а к другим не ходили) и при этом сокотрудовыжимательная часть все нужные объемы из людей добывала.

Да и в целом очень хорошо товарищи раскрыли то, как оно работает, какие правила игры, как с этим жить, что делать, если в таком участвовать не хочешь.

Это я вам почему принес? Потому что эти знания могут спасти от ряда душевных страданий, которые я порой встречаю в интернетах.

Люди идут в систему, где есть ревью и грейды, при этом сильно от этого страдают и жалуются, но ничего не делают, чтобы пойти туда, где эта система так не работает (возможно, потому что там будут платить меньше, но это не точно). А так вот послушаете, поймете, как оно работает, и либо подтюните свою стратегию и ожидания, либо поймете, что пора подыскать что-то другое. Всякий способ избавит от излишнего страдания.

Process design

Многие знают про собеседования типа system design. Тебе на вход дают примерный масштаб системы, объемы данных, пики нагрузки, требования по хранению данных, времени отклика, отказоустойчивости и т. д. Ты еще всякие другие требования доуточняешь и конструируешь, как и из чего будет построена система, чтобы всё работало как надо. Вроде понятная инженерная задача.

А что с процессами?
Однако нередко бывает в айтишном руководстве, что если какие-то рабочие процессы надо построить, то не глядя лепят скрам. Сильно реже Леше Пименову респектуют, а может, хотят «не как у всех» и заводят канбан (ну как заводят канбан, на скрам-доску добавляют WIP-лимит для задач).

А почему так?
Мне кажется, это от непонимания, что вообще еще бывает и какую конкретно пользу приносят любые внедряемые процессы. Просто где-то написано (или деды так делали), что нужно ретроспективу проводить каждый спринт, а в спринт класть задачи и их гвоздями прибивать, мол, если хотите другие, то подождите, пока спринт до конца закончится. Или 1-1 проводить ну прям с каждым человеком обязательно раз в неделю без каких-либо исключений, и тогда почему-то пипл-менеджмент будет у вас в порядке, а люди все будут счастливые и довольные.

Это типа как человек что-то где-то услышал, что Кафка — это круто и топ, поэтому в любую архитектуру он вставит Кафку не глядя.

Что делать?
Для понимания систем дизайна есть книга с кабанчиком или, мильен индусов на ютубе, которые довольно подробно рассказывают, что там как работает. Я еще даже пост делал о том, как к таким собесам готовиться https://t.me/general_it_talks/505.

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

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

⁃ У Фила Дельгядо есть доклад на тему рефлексии о рабочих процессах https://www.youtube.com/watch?v=xNdh6DCDkG8
⁃ Про проекты и процессы неплохая книга https://www.litres.ru/68332328/?lfrom=1219527110
⁃ Иван Селиховкин много всякого пишет @selihovkin и снимает https://www.youtube.com/channel/UC31GPSNxlyH90YRDxH_wStw
⁃ У Леши Пименова книга вышла про канбан https://www.litres.ru/book/aleksey-pimenov-32907598/kanban-metod-bazovaya-praktika-70276618/
⁃ Про топологию команд книга недавно пошумела https://teamtopologies.com/book
⁃ Виталий Шароватов делал мудрый доклад про пересмотр своих рабочих процессов https://t.me/vsharovatov/333
⁃ Или что-то более абстрактное и заковыристое типа Дёминга, Щедровицкого, Акоффа

Это примеры контента, который может расширить ваш управленческий кругозор, дать разную теорию и мысли о том, где что применимо. А дальше уже ваша ответственность хорошенько порефлексировать и понять, какое состояние у вас, что вообще бывает, что может подойти, попробовать, понять, что из попробованного подходит, а что нет, и заточить всё именно под свою ситуацию. Вот это будет дизайн процессов в команде, а не просто «Серега сказал, у него спринт три недели идет и ему норм, значит, и мне надо трехнедельные спринты в команде сделать».

Итог
Теоретическая подкованность может привести вас через осознанную практику к весьма хорошим результатам. И потом вы для любой команды на любом рабочем месте сможете получать эти хорошие результаты.

Это как с тренажерным залом. Одно дело ты просто делаешь из года в год одни и те же подходы и повторения из журнала «Сила и красота», а другое – понимаешь, как работает тело, как распределяется нагрузка, какие особенности у каждого упражнения, что можешь и любую кастомную программу тренировок себе составить, и даже упражнение какое-то изобрести, если у тебя есть для этого повод (травма или иное ограничение).

Учитесь, думайте, делайте хорошо, а плохо, конечно же, не делайте.

Databases in 2024: A Year in Review

Да, ещё один пост о базах :)

Любопытная, лёгкая и иногда захватывающая статья, посвящённая ретроспективе в области баз данных за 24 год.

Начинает автор с забавного: как Redis поменял лицензию более строгую, а Elasticsearch, наоборот, откатился на более открытую лицензию. Причиной всему облачные провайдеры, типа AWS, которые берут продукты и начинают их поставлять как сервис, тем самым мешая зарабатывать деньги компании-разработчику базы.

От себя добавлю, что уже давно есть более интересные альтернативы редису, о которых мы писали: DragonFly и KeyDB.

Продолжая статью, автор переходит в категорию "захватывающее" – о борьбе Snowflake и Databricks. Эти взаимоотношения можно описать, как в той самой поговорке про жабу и гадюку. В результате такой конкуренции продукты улучшаются и нам, как потребителям, это, конечно, на руку.

В этом году особенно часто на моём радаре появлялась DuckDB, которая упоминается в статье. Интересная база данных для аналитических запросов. Легко поднимается, написано куча расширений для Postgres, в результате достаточно просто начать использовать.

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

#database

#paper #books

KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache
[Статья] [Код]

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

Группа исследователей (с забавным примечанием The order of authors is determined by flipping a coin 🪙) из разных мест на послендем ICML представила статью со звучным названием KIVI (терминал оплаты, фрукт и птица пишутся по-другому).

Метод

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

Дабы эффективно квантизовать кэши, авторы анализируют распределение активаций в KV-кэшах и обнаруживают, что в активациях k-проекций имеют место ярко выраженные выбросы, в то время как в v паттерн хаотический. Перебирая варианты с потокенной и поканальной квантизацией, исследователи приходят к выводу, что ключи лучше всего квантизовать поканально, а values - потокенно.

При поканальной квантизации придется пересчитывать значения всех прошлых кэшей при пересчете диапазона. Потому предлагается хранить неквантизуемый буфер из самых свежим токенов (размера 128) и, как только буфер наполнится, квантизовать данную группу, и начать следующий. Для длинных контекстов накладные расходы от такого буфера небольшие.

Эксперименты

Метод валидируют на бенчах из LM-Eval, LongBench (наборе задач на длинный контекст) и Needle-in-a-Haystack (где нужно достать вытащить нужный факт из длинного промпта) на моделях Llama-2, Mistral.

Наивная квантизация в 2 бита сильно страдает по качеству, а предложенный подход работает с совсем небольшой просадкой. Есть, правда, маленький нюанс, что 2-битная квантизация использует размер группы 32 с fp zero-point, что означает на практике 3 бита 😅. Needle-in-a-Haystack решается почти идеально.

Поддержание неквантизованного буфера свежим токенов важно для лучше качества (свежие токены влияют сильнее, чем далекие, в большинстве задач).

При работе с большими контекстами доминирующим фактором, определяющим скорость работы, при авторегрессивной генерации становится подгрузка кэшей (уже не весов модели). За счет их сжатия удается ускорить генерацию до 3.5 раз.

Вывод

Сжатие кэшей - богоугодное дело. А дабы эффективно квантизовать кэши полезно смотреть на распределение того - что сжимаешь.

#llm #code

Mistral обновили Codestral

Новая версия 25.01 значительно умнее и в два раза быстрее, из-за обновлённого токенизатора и улучшенной архитектуры. Окно контекста расширили до 256к токенов. Заявляют первое место на Copilot Arena, но результаты пока что не опубликовали.

С бенчами опять шалят - Qwen 2.5 Coder в сравнении отсутствует, семейство Llama тут представляет не Llama 3.3, а Codellama 70B полуторагодичной давности.

С моделями DeepSeek, на этот раз, всё же сравнивают, но только с моделями меньше 100B параметров, из-за чего сильные MoE модели из сравнения выпадают. А ведь Codestral стоит на уровне скидочных цен DeepSeek V3 - $0.09/$0.30 за вход/выход, не на уровне моделек поменьше. Но у Mistral нету context caching, что сильно повышает цену при реальном использовании модели в кодинге (в Copilot сценариях часто входных токенов 95%+). Ждём независимых бенчей чтобы понять реально соотношение цены и качества.

Весов в открытый доступ не дают, даже по кастрированной лицензии. Попробовать бесплатно можно через плагин continue.dev, он доступен для VS Code и JetBrains.

@ai_newz

#llm #cv