Forwarded from Denis Sexy IT 🤖
В последнее время я все больше программирую с LLM, и теперь добавил в связку o1 Pro:
Когда Sonnet 3.6 с первого раза что-то не может починить, я беру ошибку и код который есть, и прошу o1 Pro разобраться – потом тупо копирую ее ответ в Cursor и он уже сам всё чинит/правит
И чем больше я использую O1 Pro для кода, тем больше замечаю, что ей очень важна разметка промпта и структура кода, поэтому я обновил немного свои тулы для LLM-программирования:
🗺️ Folder Map Generator – примитивно работает, вы ей папку, она вам дерево файлов и каталогов; нужно чтобы LLM правильно писала пути к файлам, так как любая модель путается; файлы не покидают вкладку браузера
📄 Text File Merger for LLM – эта штука стала еще умнее: можно руками указать какие типы файлов взять из папки, автоматом расставятся пути и открывающие/закрывающие теги имен файлов (нужно для думающих моделей), все это поможет быстро добавить нужный кусок проекта в LLM-контекст; файлы не покидают вкладку браузера
Но самое полезное, что если вы положите в папку пустой файл
***
В подтверждение моих слов про контекст, вот недавняя статья где команда смогла сильно бустнуть производительность АИ-ассистента для написания кода.
Вот краткая выдержка, общими словами:
1. Сначала, до кода, они дают LLM контекст проекта и просят его понять
2. Группируют похожие файлы по контексту
3. Просят модель прогнозировать, что именно затронет изменение кода
4. Передают ей историю изменений кода
Когда Sonnet 3.6 с первого раза что-то не может починить, я беру ошибку и код который есть, и прошу o1 Pro разобраться – потом тупо копирую ее ответ в Cursor и он уже сам всё чинит/правит
И чем больше я использую O1 Pro для кода, тем больше замечаю, что ей очень важна разметка промпта и структура кода, поэтому я обновил немного свои тулы для LLM-программирования:
🗺️ Folder Map Generator – примитивно работает, вы ей папку, она вам дерево файлов и каталогов; нужно чтобы LLM правильно писала пути к файлам, так как любая модель путается; файлы не покидают вкладку браузера
📄 Text File Merger for LLM – эта штука стала еще умнее: можно руками указать какие типы файлов взять из папки, автоматом расставятся пути и открывающие/закрывающие теги имен файлов (нужно для думающих моделей), все это поможет быстро добавить нужный кусок проекта в LLM-контекст; файлы не покидают вкладку браузера
Но самое полезное, что если вы положите в папку пустой файл
.ignore, то оба тула ее проигнорируют – то есть лишние папки/файлы можно убрать из контекста***
В подтверждение моих слов про контекст, вот недавняя статья где команда смогла сильно бустнуть производительность АИ-ассистента для написания кода.
Вот краткая выдержка, общими словами:
1. Сначала, до кода, они дают LLM контекст проекта и просят его понять
2. Группируют похожие файлы по контексту
3. Просят модель прогнозировать, что именно затронет изменение кода
4. Передают ей историю изменений кода
Denis Shiryaev Projects
Blazing Fast Folder Map Generator | Multi-threaded & Private
Generate clean ASCII directory trees locally—privacy-first, multi-threaded, and optimized for LLM prompts. Blazing fast folder maps with no data leaving your browser.
Forwarded from Нейронный Кот
Боремся с проклятыми токенами 😎
Люблю статьи от авторов phi — очень простые с топорными методами, но работают хорошо.
В тех репорте phi-4 показали, что
🔹 Проклятые (и благословенные) токены существуют
🔹 Предложили, как с этим бороться
Для задач, где есть правильный ответ, мы можем найти токены, которые негативно или позитивно влияют на вероятность успешного ответа
Как найти такие токены? — авторы называют их pivotal tokens
Считаем условную вероятность, что ответ будет правильным при заданном префиксе ответа. То есть просто эмпирически считаем, какой процент правильных ответов будет при префиксе `import Flask`
Таким макаром находим все pivotal tokens в нашем трейн сете. И учим модель различать хорошие токены от плохих. Для этого формируем пары
И запускаем DPO на этих парах. Еще раз: мы учим предсказывать только один токен! ⚠️
Если бы мы просто делали SFT или DPO на полных ответах, то учились бы предсказывать эти проклятые токены, которые негативно влияют на вероятность успешного ответа.
В таблице 9 можно посмотреть, как DPO на pivotal tokens (stage 1) накидывает в качестве по сравнению с обычным DPO и SFT
🤨 Меня удивило, что проклятыми токенами могут быть вполне безобидные токены в стиле предсказал "that" вместо "the" (см. скрины в треде)
📖 Статья
@neural_cat
Люблю статьи от авторов phi — очень простые с топорными методами, но работают хорошо.
В тех репорте phi-4 показали, что
🔹 Проклятые (и благословенные) токены существуют
🔹 Предложили, как с этим бороться
Для задач, где есть правильный ответ, мы можем найти токены, которые негативно или позитивно влияют на вероятность успешного ответа
p(success)Как найти такие токены? — авторы называют их pivotal tokens
Считаем условную вероятность, что ответ будет правильным при заданном префиксе ответа. То есть просто эмпирически считаем, какой процент правильных ответов будет при префиксе `import Flask`
Таким макаром находим все pivotal tokens в нашем трейн сете. И учим модель различать хорошие токены от плохих. Для этого формируем пары
prompt = promt + answer prefix
good response = good token
bad response = bad token
И запускаем DPO на этих парах. Еще раз: мы учим предсказывать только один токен! ⚠️
Если бы мы просто делали SFT или DPO на полных ответах, то учились бы предсказывать эти проклятые токены, которые негативно влияют на вероятность успешного ответа.
В таблице 9 можно посмотреть, как DPO на pivotal tokens (stage 1) накидывает в качестве по сравнению с обычным DPO и SFT
📖 Статья
@neural_cat
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Бреслав и Ложечкин: вся правда о грейдах, ревью и промоушенах
У нас в подкасте «Три тимлида заходят в бар» как-то был выпуск про ревью. Тем не менее мне было интересно послушать, что об этом думают и другие уважаемые господа.
Бреслав и Ложечкин как раз для меня являются таковыми, и не так давно я у них послушал про это выпуск https://t.me/breslavandlozhechkin/24.
Очень полезно послушать тем, кто работает в бигтехах и вообще крупных компаниях, а еще тем, кто рассматривает вариант там поработать.
На мой взгляд, тема раскрыта довольно честно и объективно. Взять хотя бы тему, что «справедливости» никакой в этом нет. Просто компании соревнуются между собой, чтобы «несправедливости» было поменьше (чтобы к ним ходили, а к другим не ходили) и при этом сокотрудовыжимательная часть все нужные объемы из людей добывала.
Да и в целом очень хорошо товарищи раскрыли то, как оно работает, какие правила игры, как с этим жить, что делать, если в таком участвовать не хочешь.
Это я вам почему принес? Потому что эти знания могут спасти от ряда душевных страданий, которые я порой встречаю в интернетах.
Люди идут в систему, где есть ревью и грейды, при этом сильно от этого страдают и жалуются, но ничего не делают, чтобы пойти туда, где эта система так не работает (возможно, потому что там будут платить меньше, но это не точно). А так вот послушаете, поймете, как оно работает, и либо подтюните свою стратегию и ожидания, либо поймете, что пора подыскать что-то другое. Всякий способ избавит от излишнего страдания.
У нас в подкасте «Три тимлида заходят в бар» как-то был выпуск про ревью. Тем не менее мне было интересно послушать, что об этом думают и другие уважаемые господа.
Бреслав и Ложечкин как раз для меня являются таковыми, и не так давно я у них послушал про это выпуск https://t.me/breslavandlozhechkin/24.
Очень полезно послушать тем, кто работает в бигтехах и вообще крупных компаниях, а еще тем, кто рассматривает вариант там поработать.
На мой взгляд, тема раскрыта довольно честно и объективно. Взять хотя бы тему, что «справедливости» никакой в этом нет. Просто компании соревнуются между собой, чтобы «несправедливости» было поменьше (чтобы к ним ходили, а к другим не ходили) и при этом сокотрудовыжимательная часть все нужные объемы из людей добывала.
Да и в целом очень хорошо товарищи раскрыли то, как оно работает, какие правила игры, как с этим жить, что делать, если в таком участвовать не хочешь.
Это я вам почему принес? Потому что эти знания могут спасти от ряда душевных страданий, которые я порой встречаю в интернетах.
Люди идут в систему, где есть ревью и грейды, при этом сильно от этого страдают и жалуются, но ничего не делают, чтобы пойти туда, где эта система так не работает (возможно, потому что там будут платить меньше, но это не точно). А так вот послушаете, поймете, как оно работает, и либо подтюните свою стратегию и ожидания, либо поймете, что пора подыскать что-то другое. Всякий способ избавит от излишнего страдания.
Telegram
Подкаст «Бреслав и Ложечкин»
Бреслав и Ложечкин #20 — Как устроен карьерный рост в корпорациях?
Поговорили про системы мотивации и performance management в корпорациях: что такое все эти level'ы, grade'ы, уровни, promotions, performance reviews, калибровки и т.д. Зачем они нужны, какие…
Поговорили про системы мотивации и performance management в корпорациях: что такое все эти level'ы, grade'ы, уровни, promotions, performance reviews, калибровки и т.д. Зачем они нужны, какие…
Forwarded from Тимлид Очевидность | Евгений Антонов
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
⁃ Или что-то более абстрактное и заковыристое типа Дёминга, Щедровицкого, Акоффа
Это примеры контента, который может расширить ваш управленческий кругозор, дать разную теорию и мысли о том, где что применимо. А дальше уже ваша ответственность хорошенько порефлексировать и понять, какое состояние у вас, что вообще бывает, что может подойти, попробовать, понять, что из попробованного подходит, а что нет, и заточить всё именно под свою ситуацию. Вот это будет дизайн процессов в команде, а не просто «Серега сказал, у него спринт три недели идет и ему норм, значит, и мне надо трехнедельные спринты в команде сделать».
Итог
Теоретическая подкованность может привести вас через осознанную практику к весьма хорошим результатам. И потом вы для любой команды на любом рабочем месте сможете получать эти хорошие результаты.
Это как с тренажерным залом. Одно дело ты просто делаешь из года в год одни и те же подходы и повторения из журнала «Сила и красота», а другое – понимаешь, как работает тело, как распределяется нагрузка, какие особенности у каждого упражнения, что можешь и любую кастомную программу тренировок себе составить, и даже упражнение какое-то изобрести, если у тебя есть для этого повод (травма или иное ограничение).
Учитесь, думайте, делайте хорошо, а плохо, конечно же, не делайте.
Многие знают про собеседования типа 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
⁃ Или что-то более абстрактное и заковыристое типа Дёминга, Щедровицкого, Акоффа
Это примеры контента, который может расширить ваш управленческий кругозор, дать разную теорию и мысли о том, где что применимо. А дальше уже ваша ответственность хорошенько порефлексировать и понять, какое состояние у вас, что вообще бывает, что может подойти, попробовать, понять, что из попробованного подходит, а что нет, и заточить всё именно под свою ситуацию. Вот это будет дизайн процессов в команде, а не просто «Серега сказал, у него спринт три недели идет и ему норм, значит, и мне надо трехнедельные спринты в команде сделать».
Итог
Теоретическая подкованность может привести вас через осознанную практику к весьма хорошим результатам. И потом вы для любой команды на любом рабочем месте сможете получать эти хорошие результаты.
Это как с тренажерным залом. Одно дело ты просто делаешь из года в год одни и те же подходы и повторения из журнала «Сила и красота», а другое – понимаешь, как работает тело, как распределяется нагрузка, какие особенности у каждого упражнения, что можешь и любую кастомную программу тренировок себе составить, и даже упражнение какое-то изобрести, если у тебя есть для этого повод (травма или иное ограничение).
Учитесь, думайте, делайте хорошо, а плохо, конечно же, не делайте.
Forwarded from DevFM
Databases in 2024: A Year in Review
Да, ещё один пост о базах :)
Любопытная, лёгкая и иногда захватывающая статья, посвящённая ретроспективе в области баз данных за 24 год.
Начинает автор с забавного: как Redis поменял лицензию более строгую, а Elasticsearch, наоборот, откатился на более открытую лицензию. Причиной всему облачные провайдеры, типа AWS, которые берут продукты и начинают их поставлять как сервис, тем самым мешая зарабатывать деньги компании-разработчику базы.
От себя добавлю, что уже давно есть более интересные альтернативы редису, о которых мы писали: DragonFly и KeyDB.
Продолжая статью, автор переходит в категорию "захватывающее" – о борьбе Snowflake и Databricks. Эти взаимоотношения можно описать, как в той самой поговорке про жабу и гадюку. В результате такой конкуренции продукты улучшаются и нам, как потребителям, это, конечно, на руку.
В этом году особенно часто на моём радаре появлялась DuckDB, которая упоминается в статье. Интересная база данных для аналитических запросов. Легко поднимается, написано куча расширений для Postgres, в результате достаточно просто начать использовать.
В оставшейся части статьи автор рассказывает набор новостей и фактов о самых различных базах, которые, наверняка, многие пропустили. Их тоже интересно посмотреть.
#database
Да, ещё один пост о базах :)
Любопытная, лёгкая и иногда захватывающая статья, посвящённая ретроспективе в области баз данных за 24 год.
Начинает автор с забавного: как Redis поменял лицензию более строгую, а Elasticsearch, наоборот, откатился на более открытую лицензию. Причиной всему облачные провайдеры, типа AWS, которые берут продукты и начинают их поставлять как сервис, тем самым мешая зарабатывать деньги компании-разработчику базы.
От себя добавлю, что уже давно есть более интересные альтернативы редису, о которых мы писали: DragonFly и KeyDB.
Продолжая статью, автор переходит в категорию "захватывающее" – о борьбе Snowflake и Databricks. Эти взаимоотношения можно описать, как в той самой поговорке про жабу и гадюку. В результате такой конкуренции продукты улучшаются и нам, как потребителям, это, конечно, на руку.
В этом году особенно часто на моём радаре появлялась DuckDB, которая упоминается в статье. Интересная база данных для аналитических запросов. Легко поднимается, написано куча расширений для Postgres, в результате достаточно просто начать использовать.
В оставшейся части статьи автор рассказывает набор новостей и фактов о самых различных базах, которые, наверняка, многие пропустили. Их тоже интересно посмотреть.
#database
Andy Pavlo - Carnegie Mellon University
Databases in 2024: A Year in Review
Andy rises from the ashes of his dead startup and discusses what happened in 2024 in the database game.
Forwarded from Дратути Антон
Мой сетап для чтения статей 😁
Итак, в течение своего путешествия я решил не только книжки почитать, да и статейки про VLM/MMLM. Уже положил штук 10, глянем, есть ли там что-то интересное😍 .
Я уже писал, что купил себе ipad mini для чтения и заметок. Спустя несколько месяцев могу утверждать, что не жалею о своём решении — это очень компактно и удобно, поставленные задачи решает🌿 .
Для чтения статей я использую Zotero. Там удобно оставлять заметки, использовать хайлайтер, отлично синхронизируется между всеми девайсами — у меня это ipad, iphone, macbook (но в целом, можно было подключить еще и ПК, на котором у меня ubuntu и windows).
Я активно юзаю систему тегов, чтобы помечать избранные статьи, чтобы различать прочитанные и нетронутые статьи. Использую папки, чтобы структурировать статьи по разным, интересным мне, разделам.
Также я использую расширение для браузера, которое позволяет сразу добавлять нужные мне статьи просто по клику🤯 .
Единственная проблема, с которой я столкнулся — это как сделать большое хранилище для синхронизации заметок, потому что 300Мб — ну это очень мало (у меня, при не очень активном использовании уже 1Гб накопился), а платить почти два бакса за 2Гб — это как-то расточительно. Я решил эту проблему достаточно быстро (хоть и не так, как хотел), если интересно — напишите и я сделаю еще один пост про это🤓 .
Если кто-то тоже использует Zotero, расскажите, какие плагины вы используете?
Итак, в течение своего путешествия я решил не только книжки почитать, да и статейки про VLM/MMLM. Уже положил штук 10, глянем, есть ли там что-то интересное
Я уже писал, что купил себе ipad mini для чтения и заметок. Спустя несколько месяцев могу утверждать, что не жалею о своём решении — это очень компактно и удобно, поставленные задачи решает
Для чтения статей я использую Zotero. Там удобно оставлять заметки, использовать хайлайтер, отлично синхронизируется между всеми девайсами — у меня это ipad, iphone, macbook (но в целом, можно было подключить еще и ПК, на котором у меня ubuntu и windows).
Я активно юзаю систему тегов, чтобы помечать избранные статьи, чтобы различать прочитанные и нетронутые статьи. Использую папки, чтобы структурировать статьи по разным, интересным мне, разделам.
Также я использую расширение для браузера, которое позволяет сразу добавлять нужные мне статьи просто по клику
Единственная проблема, с которой я столкнулся — это как сделать большое хранилище для синхронизации заметок, потому что 300Мб — ну это очень мало (у меня, при не очень активном использовании уже 1Гб накопился), а платить почти два бакса за 2Гб — это как-то расточительно. Я решил эту проблему достаточно быстро (хоть и не так, как хотел), если интересно — напишите и я сделаю еще один пост про это
Если кто-то тоже использует Zotero, расскажите, какие плагины вы используете?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Sergey Kastryulin
Мне больше заходит Goodnotes, там еще презентационный режим топовый на случай если хочется подключиться к zoom звонку и поделиться своим разбором с коллегами
Forwarded from O
Пришел к тому, что читая статьи не сохраняю их копии с выделенным текстом, вместо этого пишу конспекты.
Сначала собираю конспект через копи-паст, потом переформулирую текст более кратко и понятно для себя. Так проще повторять материал, и занимает меньше места. Здесь можно посмотреть что в итоге получается.
Сначала собираю конспект через копи-паст, потом переформулирую текст более кратко и понятно для себя. Так проще повторять материал, и занимает меньше места. Здесь можно посмотреть что в итоге получается.
Forwarded from Quant Valerian
Скучали? 😏
Прочитал по совету Жени Антонова Черную книгу скрама.
В книге всего-то 25 страниц, но очень выпукло подсвечены проблемы скрама. С некоторыми я сталкивался сам и даже вскольз упоминал о них в канале в начале 2023 года. О других я тоже много думал и даже писал ироничный пост. А некоторые для меня оказались новыми, но не менее убедительными.
Традиционно выполню функцию суммаризации нейросетей для вас.
1. Скрам не agile по определению (ведь если что-то изменить в скраме, то это уже не скрам), хотя его маркетинговый успех де-факто установил в сознании среднестатистического айтишника формулу «скрам = agile» 🙈
2. В скраме невозможно планировать скоуп к сроку. Можно только сказать, что к концу следующего спринта будет сделано не более чем X💩
3. Скрам подразумевает кроссфункциональные команды, где каждый может помочь другому, но что-то я давно не видел PM'а, который помогал бы разработчикам писать код👨💻
4. Коллективная (без-)ответственность. Так как индивидуальный перфоманс не замеряется, то нужна сработанная команда, чтобы коллективная ответственность помогала, а не мешала. Это автоматически запрещает нам брать скрам для вновь собранной команды. Тем временем в реальном мире именно скрам — это дефолтный выбор для новичков🦥
5. Не только лишь все продукты можно делать итеративно, без плана, лишь только некоторые можно. Если вам нужен ледокол, то начинать с плота достаточно бессмысленно. Скрам же считает, что вы никогда не знаете, что вам нужно, поэтому мы пытаемся летать в космос на батутах🚀
6. Скрам требует много времени заказчика. Заказчик зачастую этому не рад🤡
7. Скрам требует, чтобы весь окружающий мир подстраивался под него, ведь его самого менять нельзя. Об этом я тоже упоминал https://t.me/quant_valerian/440, что скрам и канбан игнорируют существование смежных команд и оптимизируют локальную команду😎
8. Навязанные консультанты. Ну об этом только ленивый не говорил. Скрам создан для того, чтобы продавать курсы по скраму. И сертификации. И консультации сертифицированных специалистов🤑
9. Скрам так много говорит о том, что не нужно тратить время на планирование, там разберемся. Этим аргументируется и невозможность дать оценку сроков схождения проекта. При этом само устройство скрама подразумевает огромные затраты на планирование и поддержание спринта. У автора получилось 30% рабочего времени команды при недельных спринтах🤪
10. Наименее понятная мне часть. Невозможный продакт оунер. Продукт оунер в скраме должен сочетать в себе аналитика, представителя бизнеса и маркетолога. Таких почти не бывает💪
Практически все эти проблемы решены в tameflow. Разве что кроме коллективной ответственности (об этом tameflow вообще ничего не говорит). Книжку советую к прочтению, это такой классический башорговский юморок с запашком — мне зашло!😁
Прочитал по совету Жени Антонова Черную книгу скрама.
В книге всего-то 25 страниц, но очень выпукло подсвечены проблемы скрама. С некоторыми я сталкивался сам и даже вскольз упоминал о них в канале в начале 2023 года. О других я тоже много думал и даже писал ироничный пост. А некоторые для меня оказались новыми, но не менее убедительными.
Традиционно выполню функцию суммаризации нейросетей для вас.
1. Скрам не agile по определению (ведь если что-то изменить в скраме, то это уже не скрам), хотя его маркетинговый успех де-факто установил в сознании среднестатистического айтишника формулу «скрам = agile» 🙈
2. В скраме невозможно планировать скоуп к сроку. Можно только сказать, что к концу следующего спринта будет сделано не более чем X
3. Скрам подразумевает кроссфункциональные команды, где каждый может помочь другому, но что-то я давно не видел PM'а, который помогал бы разработчикам писать код
4. Коллективная (без-)ответственность. Так как индивидуальный перфоманс не замеряется, то нужна сработанная команда, чтобы коллективная ответственность помогала, а не мешала. Это автоматически запрещает нам брать скрам для вновь собранной команды. Тем временем в реальном мире именно скрам — это дефолтный выбор для новичков
5. Не только лишь все продукты можно делать итеративно, без плана, лишь только некоторые можно. Если вам нужен ледокол, то начинать с плота достаточно бессмысленно. Скрам же считает, что вы никогда не знаете, что вам нужно, поэтому мы пытаемся летать в космос на батутах
6. Скрам требует много времени заказчика. Заказчик зачастую этому не рад
7. Скрам требует, чтобы весь окружающий мир подстраивался под него, ведь его самого менять нельзя. Об этом я тоже упоминал https://t.me/quant_valerian/440, что скрам и канбан игнорируют существование смежных команд и оптимизируют локальную команду
8. Навязанные консультанты. Ну об этом только ленивый не говорил. Скрам создан для того, чтобы продавать курсы по скраму. И сертификации. И консультации сертифицированных специалистов
9. Скрам так много говорит о том, что не нужно тратить время на планирование, там разберемся. Этим аргументируется и невозможность дать оценку сроков схождения проекта. При этом само устройство скрама подразумевает огромные затраты на планирование и поддержание спринта. У автора получилось 30% рабочего времени команды при недельных спринтах
10. Наименее понятная мне часть. Невозможный продакт оунер. Продукт оунер в скраме должен сочетать в себе аналитика, представителя бизнеса и маркетолога. Таких почти не бывает
Практически все эти проблемы решены в tameflow. Разве что кроме коллективной ответственности (об этом tameflow вообще ничего не говорит). Книжку советую к прочтению, это такой классический башорговский юморок с запашком — мне зашло!
Please open Telegram to view this post
VIEW IN TELEGRAM
Iselihovkin
книги
Forwarded from КПД
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 раз.
Вывод
Сжатие кэшей - богоугодное дело. А дабы эффективно квантизовать кэши полезно смотреть на распределение того - что сжимаешь.
[Статья] [Код]
Для того, чтобы работать с большим контекстом в условии ограниченных ресурсов необходимо как-нибудь да сжимать 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 раз.
Вывод
Сжатие кэшей - богоугодное дело. А дабы эффективно квантизовать кэши полезно смотреть на распределение того - что сжимаешь.