Forwarded from Техножрица 👩💻👩🏫👩🔧
Доброе утро, дорогие девочки 💋 и фембойчики 💅. Спешу поделиться радостной новостью: вчера я выложила на архив новый препринт (short paper), в написании которого принимала участие - Quantifying Logical Consistency in Transformers via Query-Key Alignment: https://arxiv.org/abs/2502.17017 .
Статья посвящена анализу того, как разные головы внимания LLMок реагируют на логические задачки. Главный прием, который в ней используется, изображен на рис. 1 и аналогичен приему из нашей с коллегами статьи про использование Query-Key Alignment для MCQA (часть 1, часть 2). Мы подаем на вход модели текст логической задачки вместе с вариантом ответа "true" и считаем скалярное произведение токена "true" из Query на выбранной голове внимания, на последний токен перед словом "Answer:" из Key на той же голове внимания. Получается одно число. Далее то же самое повторяется для варианта ответа "false". Получается второе число. Если первое число больше второго, то мы считаем, что голова выбрала вариант "true", а если наоборот, то "false" (в некоторых задачах более уместно вместо "true" и "false" использовать "yes" и "no", но принцип остается таким же). Таким образом можно проэкзаменовать каждую голову внимания и посмотреть, насколько хорошо из её query и key извлекаются правильные ответы (условно говоря, насколько хорошо голова "решает" логические задачки).
Задачки различались по степени сложности: во-первых, по количеству логических шагов, которые нужно предпринять для нахождения ответа ("steps" на рис. 2), а во-вторых, по количеству нерелевантных, шумных элементов в условии ("distractors" на рис. 2).
В статье было проанализировано много разных моделей (от 1.5B до 70B), и везде нашлись головы, которые "решают" сложные (5 шагов/5 дистракторов) задачки лучше, чем сама модель (если ответ модели оценивать по логитам, аналогично тому, как это делается в MCQA задачах). Более того, часть таких "хороших" голов, отобранных на валидационной выборке одного датасета, сохраняет высокое качество и на других датасетах, являясь более-менее универсальными. Мы выдвигаем гипотезу, что именно эти головы могут отвечать за логические рассуждения в модели.
Этот феномен аналогичен тому, что происходит в MCQA задачах (см. ссылки на разбор статьи выше): модель находит правильный ответ на задачу/вопрос где-то на промежуточных слоях, но этот ответ, по каким-то причинам, не всегда доходит до финального слоя. При чем, что интересно, чем сложнее задача, тем чаще правильный ответ не доходит до выхода. А это значит, что все рассмотренные модели не полностью раскрывают свой потенциал и имеют пространство для улучшения.
#объяснения_статей
Статья посвящена анализу того, как разные головы внимания LLMок реагируют на логические задачки. Главный прием, который в ней используется, изображен на рис. 1 и аналогичен приему из нашей с коллегами статьи про использование Query-Key Alignment для MCQA (часть 1, часть 2). Мы подаем на вход модели текст логической задачки вместе с вариантом ответа "true" и считаем скалярное произведение токена "true" из Query на выбранной голове внимания, на последний токен перед словом "Answer:" из Key на той же голове внимания. Получается одно число. Далее то же самое повторяется для варианта ответа "false". Получается второе число. Если первое число больше второго, то мы считаем, что голова выбрала вариант "true", а если наоборот, то "false" (в некоторых задачах более уместно вместо "true" и "false" использовать "yes" и "no", но принцип остается таким же). Таким образом можно проэкзаменовать каждую голову внимания и посмотреть, насколько хорошо из её query и key извлекаются правильные ответы (условно говоря, насколько хорошо голова "решает" логические задачки).
Задачки различались по степени сложности: во-первых, по количеству логических шагов, которые нужно предпринять для нахождения ответа ("steps" на рис. 2), а во-вторых, по количеству нерелевантных, шумных элементов в условии ("distractors" на рис. 2).
В статье было проанализировано много разных моделей (от 1.5B до 70B), и везде нашлись головы, которые "решают" сложные (5 шагов/5 дистракторов) задачки лучше, чем сама модель (если ответ модели оценивать по логитам, аналогично тому, как это делается в MCQA задачах). Более того, часть таких "хороших" голов, отобранных на валидационной выборке одного датасета, сохраняет высокое качество и на других датасетах, являясь более-менее универсальными. Мы выдвигаем гипотезу, что именно эти головы могут отвечать за логические рассуждения в модели.
Этот феномен аналогичен тому, что происходит в MCQA задачах (см. ссылки на разбор статьи выше): модель находит правильный ответ на задачу/вопрос где-то на промежуточных слоях, но этот ответ, по каким-то причинам, не всегда доходит до финального слоя. При чем, что интересно, чем сложнее задача, тем чаще правильный ответ не доходит до выхода. А это значит, что все рассмотренные модели не полностью раскрывают свой потенциал и имеют пространство для улучшения.
#объяснения_статей
Forwarded from Fley's flow
Давно я ничего не писал – всё не видел достойных поводов для постов, однако сейчас такой появился.
Я сделаю небольшую серию публикаций на тему глобальной оптимизации:
Пример
Представьте, что у вас есть какая-то бизнес- или математическая задача. Например — купить мясо и напитки к столу на фиксированный бюджет. Цель — потратить минимум времени. Зададим переменные и ограничим их диапазон, чтобы совсем с ума не сходить:
x1: Сколько людей мы отправим: от 1 до 4
x2: Каких именно людей мы отправим: пускай будет выборка из 6 человек.
x3: День недели: пятница или суббота
x4: В какое время суток отправлять: с 8 до 16 часов
x5: На какой рынок отправиться: пускай будет 3 варианта наиболее удачных рынков в городе.
Давайте попробуем решить эту задачу, опираясь на жизненный опыт. Я опишу свои мысли, а вы можете прикинуть сами и потом читать дальше.
х2 — кого отправим: здесь нужны люди пунктуальные и желательно с большим опытом в организации таких мероприятий.
х3 — день недели: лучше в пятницу, чем в субботу, очевидно.
х4 — время суток: я бы выбрал 10 утра, потому что в это время уже все, кому надо, на работе, и отправленные на рынок люди уже проснулись и бодрствуют, тормозить не будут.
х5 — рынок: здесь не буду предполагать, но можно учесть местоположение людей, которых отправляем, и взять тот рынок, который по среднему расстоянию будет ближе всего.
Разумеется, это достаточно простая жизненная задача, однако к 20-25 годам у нас уже есть набор знаний и опыта, который позволяет оценить поведение этой функции в зависимости от переменных, и выбрать некоторую субоптимальную комбинацию параметров. Но как, очутившись в мире, где есть только люди, рынки и мясо для шашлыка, такой опыт можно получить и каким образом достичь цели быстрее всего? Перепробовать все комбинации — точно сработает, но долго. Попробовать случайные 5-6 — а достаточно ли это хороший подход?
Задача
Теперь с опорой на пример сформулируем общую задачу: есть функция многих переменных, f(x1, x2, ..., x_n), для которой мы предполагаем существование глобального минимума или максимума — нужно его найти.
Оптимизация гиперпараметров
С помощью примера выше мы показали, что в жизни таких задач очень много — практически каждый процесс можно сформулировать как задачу оптимизации, в том числе и эволюционный (это важное замечание). И раз уж я не владелец кафе а-ля Шашлычный Мир, а CV/ML-инженер, расскажу про реальную задачу, где нам нужна глобальная оптимизация.
Обучаем мы нейросеть, задаем различные гиперпараметры, начиная с оптимизатора, learning rate и batch size, заканчивая аугментациями и регуляризациями и смотрим на точность после обучения. Важно отметить, что в силу невозможности продифференцировать такую функцию, мы имеем более общую задачу и медленную сходимость. Как будем подбирать самую хорошую комбинацию? Жизненный опыт — это хорошо, но его долго получать, нет гарантий, что он верный и сработает как нам надо, а также его не так легко обосновать.
Люди, которые касались этой задачи, сразу же вспомнят про GridSearch – поиск по сетке, где мы задаем для каждого параметра набор значений, которые нужно перебрать каждый с каждым. Однако есть высокая вероятность не попасть даже в хороший локальный максимум. Ну и вспомним RandomSearch – поиск по случайным наборам параметров. Любопытно, что у него даже теоретически доказанная сходимость заметно лучше, чем у поиска по сетке, но он тоже не вызывает чувство спокойствия по поводу обоснованности сделанного выбора.
Как раз о таких методах, которые помогут спать спокойно, в следующих постах и пойдет речь.
#learn #hard #cases
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Knowledge Accumulator
A Conceptual Explanation of Bayesian Hyperparameter Optimization for Machine Learning [2018]
Неделю назад я писал пост про Evolution Strategies. Напомню его область применения:
1) Есть не очень большое пространство параметров
2) Есть функция качества этих параметров, но нет доступа к каким-либо градиентам
Эта область применения не так уж и редко встречается в реальной жизни, и чаще всего это происходит в контексте оптимизации гиперпараметров. В этом случае появляется ещё одно обстоятельство:
3) Функцию качества очень долго и дорого считать
В данной ситуации мы хотим максимально эффективно использовать этот ресурс, извлекать и переиспользовать максимальное количество информации из её замеров. Стандартный Evolution Strategies в этом плане достаточно туп - каждая итерация алгоритма происходит "с чистого листа", а точки для замера выбираются с помощью добавления шума.
Именно здесь на сцену выходит Bayesian model-based optimization. Это целое семейство методов, но все они работают по примерно одному и тому же принципу:
1) Мы пытаемся аппроксимировать распределение
2) Мы используем каждое наше измерение для обучения этой аппроксимации
3) Выбор следующих кандидатов происходит по-умному, балансируя между неисследованными областями в пространстве параметров и проверкой тех областей, в которых мы ожидаем получить хорошее значение функции
Исследуя всё больше и больше точек, мы получаем всё более точную аппроксимацию функции, как показано на картинке. Остаётся выбрать, каким образом моделировать распределение и выбирать кандидатов.
Один из вариантов, используемых на практике, выглядит так:
- При выборе следующих кандидатов мы максимизируем нечто похожее на "мат. ожидание"
- Для оценки
- В пунктах выше я упоминал "хорошие" и "плохие" значения. Порог, который их разделяет, выбирается как квантиль уже собранного нами множества значений objective.
При применении капельки математики получается, что Expected Improvement максимизируется в тех точках, в которых максимизируется` L(params) / G(params)
Описанная процедура гораздо хитрее и тяжелее, чем Evolution Strategies, но всё это несопоставимо дешевле и быстрее, чем каждый подсчёт значения Objective(params). Таким образом, метод хорошо подходит для таких ситуаций, как оптимизация гиперпараметров обучения, и используется в качестве одного из основных в библиотеке Hyperopt.
Метод, конечно, не идеален - он не учитывает зависимости параметров между собой. Это может ограничивать область применения и мешать методу работать для оптимизации более запутанных схем. Бесплатные обеды, как обычно, не завезли.
@knowledge_accumulator
Неделю назад я писал пост про Evolution Strategies. Напомню его область применения:
1) Есть не очень большое пространство параметров
2) Есть функция качества этих параметров, но нет доступа к каким-либо градиентам
Эта область применения не так уж и редко встречается в реальной жизни, и чаще всего это происходит в контексте оптимизации гиперпараметров. В этом случае появляется ещё одно обстоятельство:
3) Функцию качества очень долго и дорого считать
В данной ситуации мы хотим максимально эффективно использовать этот ресурс, извлекать и переиспользовать максимальное количество информации из её замеров. Стандартный Evolution Strategies в этом плане достаточно туп - каждая итерация алгоритма происходит "с чистого листа", а точки для замера выбираются с помощью добавления шума.
Именно здесь на сцену выходит Bayesian model-based optimization. Это целое семейство методов, но все они работают по примерно одному и тому же принципу:
1) Мы пытаемся аппроксимировать распределение
P(objective | params)2) Мы используем каждое наше измерение для обучения этой аппроксимации
3) Выбор следующих кандидатов происходит по-умному, балансируя между неисследованными областями в пространстве параметров и проверкой тех областей, в которых мы ожидаем получить хорошее значение функции
Исследуя всё больше и больше точек, мы получаем всё более точную аппроксимацию функции, как показано на картинке. Остаётся выбрать, каким образом моделировать распределение и выбирать кандидатов.
Один из вариантов, используемых на практике, выглядит так:
- При выборе следующих кандидатов мы максимизируем нечто похожее на "мат. ожидание"
P(objective | params), но интеграл берётся только по "хорошим" значениям objective - это называется Expected Improvement- Для оценки
P(objective | params) мы формулу Байеса и переходим к моделированию P(params | objective), которое в свою очередь является композицией из двух распределений P(params) - для "хороших" значений objective и для "плохих" - эти распределения называется`L(params) и `G(params).- В пунктах выше я упоминал "хорошие" и "плохие" значения. Порог, который их разделяет, выбирается как квантиль уже собранного нами множества значений objective.
При применении капельки математики получается, что Expected Improvement максимизируется в тех точках, в которых максимизируется` L(params) / G(params)
. Эти точки мы пытаемся найти, сэмплируя много раз из `L(params) и пересчитывая это соотношение. Вся эта схема называется Tree-structured Parzen Estimator.Описанная процедура гораздо хитрее и тяжелее, чем Evolution Strategies, но всё это несопоставимо дешевле и быстрее, чем каждый подсчёт значения Objective(params). Таким образом, метод хорошо подходит для таких ситуаций, как оптимизация гиперпараметров обучения, и используется в качестве одного из основных в библиотеке Hyperopt.
Метод, конечно, не идеален - он не учитывает зависимости параметров между собой. Это может ограничивать область применения и мешать методу работать для оптимизации более запутанных схем. Бесплатные обеды, как обычно, не завезли.
@knowledge_accumulator
Forwarded from Data, Stories and Languages
Ужасы поиска работы от Mimansa Jaiswal
Сегодня в твиттере я увидел весьма интересный тред об опыте поиска работы прошлой осенью от Mimansa Jaiswal. У неё есть PhD в Computer Science, опыт работы стажёром в Facebook AI, Allen и год опыта работы в ещё одной компании. Плюс 10+ опубликованных статей (часть во времена BERT, часто в настоящее время).
И вот она рассказывает, как осенью 2024 искала работу - подавалась в 200 компаний, было ~100 собеседований. Текст очень интересный - про подходы к поиску работы, про различия между стартапами и BigTech и многое другое.
Вот некоторые интересные моменты:
Общее:
• Искала работу связанную с ресерчем - общие применения LLM или работа над SOTA. Чисто инженерные позиции или разработка продуктов типа чат-ботов её не интересовали. Хотелось work-life balance и работа в Seattle или сравнимой локации.
• Основные способы поиска работы: подаваться через сайты компаний напрямую, писать рекрутёрам и hiring manager в LinkedIn, добывать рефералы
• Полно мини хоррор-историй о том, какие бывают общения с компаниями
Стартапы:
• Процессы собеседований сильно разнятся между компаниями. Из необычного: некоторые хотели проводить собеседования при личной стрече (не по созвону), некоторые хотели, чтобы кандидат несколько дней проработал у них (за оплату, конечно) как мини-триал вместо собеседований.
• Даже в таких молодых стартапах обычно было 5-6 раундов собеседований.
• Как можно ожидать, многие стартапы сразу озвучивали ожидания работать 6/7 дней в неделю или 12 часов в день.
• Нередко название позиции намекает на ресерч, а по факту оказывается, что нужна инженерная работа.
• Часто компании прекращают общение между этапами собеседований и перестают отвечать
• Стартапы обычно предлагают 150-250k$ gross в год и 0.2%–0.5% equity.
Unicorns (Anthropic, OpenAI, Scale):
• Дикое количество раундов у Anthropic - 10
• Не было раундов leetcode, часто можно было использовать дополнительные материалы (но без чат-ботов)
BigTech:
• Обычно процесс собеседований идёт 1.5-2.5 месяцев
• В Apple было... 12 раундов, у остальных компаний обычно около 6 +/- 2
• Процессы собесов были прозрачные, интервьюверы были профессиональными
• Некоторые компании всё-таки пропадали посередине общения
• В среднем компании предлагают 350-430k$ gross в год с учётом всех бонусов
Материалы для подготовки
#datascience
Сегодня в твиттере я увидел весьма интересный тред об опыте поиска работы прошлой осенью от Mimansa Jaiswal. У неё есть PhD в Computer Science, опыт работы стажёром в Facebook AI, Allen и год опыта работы в ещё одной компании. Плюс 10+ опубликованных статей (часть во времена BERT, часто в настоящее время).
И вот она рассказывает, как осенью 2024 искала работу - подавалась в 200 компаний, было ~100 собеседований. Текст очень интересный - про подходы к поиску работы, про различия между стартапами и BigTech и многое другое.
Вот некоторые интересные моменты:
Общее:
• Искала работу связанную с ресерчем - общие применения LLM или работа над SOTA. Чисто инженерные позиции или разработка продуктов типа чат-ботов её не интересовали. Хотелось work-life balance и работа в Seattle или сравнимой локации.
• Основные способы поиска работы: подаваться через сайты компаний напрямую, писать рекрутёрам и hiring manager в LinkedIn, добывать рефералы
• Полно мини хоррор-историй о том, какие бывают общения с компаниями
Стартапы:
• Процессы собеседований сильно разнятся между компаниями. Из необычного: некоторые хотели проводить собеседования при личной стрече (не по созвону), некоторые хотели, чтобы кандидат несколько дней проработал у них (за оплату, конечно) как мини-триал вместо собеседований.
• Даже в таких молодых стартапах обычно было 5-6 раундов собеседований.
• Как можно ожидать, многие стартапы сразу озвучивали ожидания работать 6/7 дней в неделю или 12 часов в день.
• Нередко название позиции намекает на ресерч, а по факту оказывается, что нужна инженерная работа.
• Часто компании прекращают общение между этапами собеседований и перестают отвечать
• Стартапы обычно предлагают 150-250k$ gross в год и 0.2%–0.5% equity.
Unicorns (Anthropic, OpenAI, Scale):
• Дикое количество раундов у Anthropic - 10
• Не было раундов leetcode, часто можно было использовать дополнительные материалы (но без чат-ботов)
BigTech:
• Обычно процесс собеседований идёт 1.5-2.5 месяцев
• В Apple было... 12 раундов, у остальных компаний обычно около 6 +/- 2
• Процессы собесов были прозрачные, интервьюверы были профессиональными
• Некоторые компании всё-таки пропадали посередине общения
• В среднем компании предлагают 350-430k$ gross в год с учётом всех бонусов
Материалы для подготовки
#datascience
X (formerly Twitter)
Mimansa Jaiswal (@MimansaJ) on X
I interviewed for LLM/ML research scientist/engineering positions last Fall. Over 200 applications, 100 interviews, many rejections & some offers later, I decided to write the process down, along with the resources I used.
Links to the process & resources…
Links to the process & resources…
Forwarded from epsilon correct
Claude Code
Вчера Antropic представили обновлённую модельку Sonnet 3.7 и вместе с ней локального агента Claude Code. Вместе с обновлением, которое значительно подняло метрики по выполнению кода, получилась пушка для как минимум хобби-разработчиков.
Агент работает по API, час работы выходит примерно 10-20$. Агент работает на локальной машине через свой терминал, запуская команды на локальной машине. За полтора часа работы у меня получилось "написать" ~5k строк C++ кода для системы быстрого построения графов при помощи locality-sensitive hashing проекций. Ничего сложного, но время разработки существенно скоратилось, а скаффолдинг можно и поправить.
За весь час я вообще не редактировал код, а давал только общие указания (напиши бенчмарк, напиши тесты). В результате получилась система, которая вроде бы даже работет – агент сам старается всё тестировать и себя проверять. В результате получилось написать то, на что у меня бы ушло недели две работы, да ещё и C++ вышел довольно читаемым.
Будущее, получается, уже совсем рядом – нужно только отстёгивать $20/час за такое удовольствие.
Вчера Antropic представили обновлённую модельку Sonnet 3.7 и вместе с ней локального агента Claude Code. Вместе с обновлением, которое значительно подняло метрики по выполнению кода, получилась пушка для как минимум хобби-разработчиков.
Агент работает по API, час работы выходит примерно 10-20$. Агент работает на локальной машине через свой терминал, запуская команды на локальной машине. За полтора часа работы у меня получилось "написать" ~5k строк C++ кода для системы быстрого построения графов при помощи locality-sensitive hashing проекций. Ничего сложного, но время разработки существенно скоратилось, а скаффолдинг можно и поправить.
За весь час я вообще не редактировал код, а давал только общие указания (напиши бенчмарк, напиши тесты). В результате получилась система, которая вроде бы даже работет – агент сам старается всё тестировать и себя проверять. В результате получилось написать то, на что у меня бы ушло недели две работы, да ещё и C++ вышел довольно читаемым.
Будущее, получается, уже совсем рядом – нужно только отстёгивать $20/час за такое удовольствие.
Forwarded from ML Underhood
YandexGPT 5 уже в опенсорсе и Алисе
Сегодня Яндекс показал миру новое поколение больших языковых моделей — YandexGPT 5. Старшая модель YandexGPT 5 Pro доступна в чате с Алисой и Yandex Cloud через API. Ну а претрейн-версия младшей модели YandexGPT 5 Lite Pretrain — уже лежит на Hugging Face.
Все подробности о процессе обучения можно прочитать в статье на Хабре. А в этом посте — главные факты о свежей опенсорсной модели Яндекса.
YandexGPT 5 Lite Pretrain — модель на 8 миллиардов параметров с длиной контекста 32 тысячи токенов. Претрейн проходил в два этапа: сначала модель обучили на 15 триллионах токенов текста на русском и английском языках, а потом использовали 320 миллиардов токенов высококачественных данных, включая образовательный контент.
На первом этапе датасет больше чем на половину состоял из веб-документов, остальное — код, математика и специфичные данные. Под последними подразумеваются синтетика (сгенерированные YandexGPT 4 вопросы на основе проверенных источников) и внутренние наработки компании (например, внутренняя база Яндекса Fact Snippet и новый корпус данных Переводчика).
На втором этапе датасет на четверть состоял из веб-страниц и почти в равных пропорциях содержал математику, код и образовательные данные. Также была небольшая часть аугментаций фактовых документов, другой синтетики и датасетов сервисов.
По сравнению с моделью предыдущего поколения, YandexGPT 4 Lite Pretrain, новая модель показывает ощутимый рост качества в решении математических задач и написании кода. А в сравнении с зарубежными аналогами, такими как LLaMa3.1-8B и Qwen-2.5-7B-base, она лидирует почти во всех типах задач.
Ещё раз приглашаем пощупать модель, почитать статью на Хабре с деталями обучения и не забыть поделиться впечатлениями в комментариях!
ML Underhood
Сегодня Яндекс показал миру новое поколение больших языковых моделей — YandexGPT 5. Старшая модель YandexGPT 5 Pro доступна в чате с Алисой и Yandex Cloud через API. Ну а претрейн-версия младшей модели YandexGPT 5 Lite Pretrain — уже лежит на Hugging Face.
Все подробности о процессе обучения можно прочитать в статье на Хабре. А в этом посте — главные факты о свежей опенсорсной модели Яндекса.
YandexGPT 5 Lite Pretrain — модель на 8 миллиардов параметров с длиной контекста 32 тысячи токенов. Претрейн проходил в два этапа: сначала модель обучили на 15 триллионах токенов текста на русском и английском языках, а потом использовали 320 миллиардов токенов высококачественных данных, включая образовательный контент.
На первом этапе датасет больше чем на половину состоял из веб-документов, остальное — код, математика и специфичные данные. Под последними подразумеваются синтетика (сгенерированные YandexGPT 4 вопросы на основе проверенных источников) и внутренние наработки компании (например, внутренняя база Яндекса Fact Snippet и новый корпус данных Переводчика).
На втором этапе датасет на четверть состоял из веб-страниц и почти в равных пропорциях содержал математику, код и образовательные данные. Также была небольшая часть аугментаций фактовых документов, другой синтетики и датасетов сервисов.
По сравнению с моделью предыдущего поколения, YandexGPT 4 Lite Pretrain, новая модель показывает ощутимый рост качества в решении математических задач и написании кода. А в сравнении с зарубежными аналогами, такими как LLaMa3.1-8B и Qwen-2.5-7B-base, она лидирует почти во всех типах задач.
Ещё раз приглашаем пощупать модель, почитать статью на Хабре с деталями обучения и не забыть поделиться впечатлениями в комментариях!
ML Underhood
Forwarded from Quant Valerian
Очередная итерация по повышению точности прогнозирования сроков проектов 🤓
В этой работе нами было показано
В какой-то раз, похоже, придется реально статью уже писать 😁
КОРОЧЕ, опять Канеманн меня вдохновил на идею. В главе «Взгляд извне» он рассказывает, что они с коллегами собрались написать учебник. Попланировали, поприкидывали, написали несколько глав.
❗️ВНИМАНИЕ!❗️Планинг покер!❗️ Канеманн попросил каждого участника независимо оценить срок, в который они закончат книгу. В среднем они оценили срок в два года.
А потом они спросили одного из членов группы, специалиста по спецкурсам, как исторически справлялись другие группы?💡
Он ответил, что в среднем книгу такого объема пишут минимум за семь лет, но не больше, чем за десять. Ещё он сказал, что их группа несколько слабее среднего по уровню подготовки и ресурсов.
Услышав это, они погрустнели.
И забили хер на эту информацию! 😁 В итоге, книгу они писали ещё восемь лет с того эпизода.😱
Что с этим делать?
Я уже рассказывал, что мы пользуемся статистикой. Кратко🤡 напомню:
1. Собираем диаграмму Гантта (там нарезано на MOVE a la стори, других задач там нет, даже самое мелкое внесено через MOVE) 😋
2. Оцениваем стори маечно (совсем мелочь / что-то невообразимо большое / всё остальное) 📏
3. Смотрим цикл-тайм (на самом деле lead time ) диаграммы в разрезе этих размеров (медианы и 85%%)👩🔬
4. Выделяем критический путь в Гантте (с учетом ресурсов) ☢️
5. Для критического пути считаем медиану (как сумму медиан задач) и 85%% (как сумму 85%%), вообще говоря, так нельзя делать математически, но нам для примерности сойдет (распределения там логнормальные примерно, я проверял на разных командах из разных частей компании) 🧮
6. Теперь мы знаем, когда закончим с вероятностью 50%, когда с вероятностью 85% — скорее всего где-то между этими значениями и получится 🤞
7*. Не надо закладывать никакие буферы, они учтены в статистике 🤌
Это работает, мы пробовали. Но не так хорошо, как на бумаге. Потому что люди (ну мы) туповаты 🤤 и, например, на старте проекта забывают, не учитывают какой-то кусок работы. Или приходит какой-нибудь аудитор/регулятор/юрист🤵🏼♂️ и наваливает вам 💩 еще обязательного в скоуп.
!!!НОВАЯ ИНФОРМАЦИЯ!!! 🎉
Поэтому предлагается ко взгляду извне (метод выше) добавить ещё субъективщины. И важно, что я говорю не о том, что мы ко всем проектам просто будем докидывать какой-то одинаковый (в абсолютах или процентах) запас. А о том, что у нас есть:
1. Чуйка (aka интуиция aka насмотренность) 🐕
2. Осознанное знание, как шли какие-то похожие проекты 👴🏻
И вот тут уже, имея опору в виде объективной априорной оценки, стоит опросить членов команды, что они думают о сроках. И эти данные использовать, как поправку. Конкретную методику я ещё не пробовал, поэтому мне нечего вам посоветовать. 🌝 Пока!
Из этой истории, btw, можно сделать вывод, что не работают не только стори поинты, но и планинг покер. Хотя для взвешивания быка 🐂 вроде работает. Разница в том, что при планировании работы, мы оцениваем себя, а от веса быка нам ни холодно, ни жарко.
В какой-то раз, похоже, придется реально статью уже писать 😁
КОРОЧЕ, опять Канеманн меня вдохновил на идею. В главе «Взгляд извне» он рассказывает, что они с коллегами собрались написать учебник. Попланировали, поприкидывали, написали несколько глав.
❗️ВНИМАНИЕ!❗️Планинг покер!❗️ Канеманн попросил каждого участника независимо оценить срок, в который они закончат книгу. В среднем они оценили срок в два года.
А потом они спросили одного из членов группы, специалиста по спецкурсам, как исторически справлялись другие группы?💡
Он ответил, что в среднем книгу такого объема пишут минимум за семь лет, но не больше, чем за десять. Ещё он сказал, что их группа несколько слабее среднего по уровню подготовки и ресурсов.
Услышав это, они погрустнели.
И забили хер на эту информацию! 😁 В итоге, книгу они писали ещё восемь лет с того эпизода.😱
Что с этим делать?
Я уже рассказывал, что мы пользуемся статистикой. Кратко
1. Собираем диаграмму Гантта (там нарезано на MOVE a la стори, других задач там нет, даже самое мелкое внесено через MOVE) 😋
2. Оцениваем стори маечно (совсем мелочь / что-то невообразимо большое / всё остальное) 📏
3. Смотрим цикл-тайм (
4. Выделяем критический путь в Гантте (с учетом ресурсов) ☢️
5. Для критического пути считаем медиану (как сумму медиан задач) и 85%% (как сумму 85%%), вообще говоря, так нельзя делать математически, но нам для примерности сойдет (распределения там логнормальные примерно, я проверял на разных командах из разных частей компании) 🧮
6. Теперь мы знаем, когда закончим с вероятностью 50%, когда с вероятностью 85% — скорее всего где-то между этими значениями и получится 🤞
7*. Не надо закладывать никакие буферы, они учтены в статистике 🤌
Это работает, мы пробовали. Но не так хорошо, как на бумаге. Потому что люди (ну мы) туповаты 🤤 и, например, на старте проекта забывают, не учитывают какой-то кусок работы. Или приходит какой-нибудь аудитор/регулятор/юрист🤵🏼♂️ и наваливает вам 💩 еще обязательного в скоуп.
!!!НОВАЯ ИНФОРМАЦИЯ!!! 🎉
Поэтому предлагается ко взгляду извне (метод выше) добавить ещё субъективщины. И важно, что я говорю не о том, что мы ко всем проектам просто будем докидывать какой-то одинаковый (в абсолютах или процентах) запас. А о том, что у нас есть:
1. Чуйка (aka интуиция aka насмотренность) 🐕
2. Осознанное знание, как шли какие-то похожие проекты 👴🏻
И вот тут уже, имея опору в виде объективной априорной оценки, стоит опросить членов команды, что они думают о сроках. И эти данные использовать, как поправку. Конкретную методику я ещё не пробовал, поэтому мне нечего вам посоветовать. 🌝 Пока!
Из этой истории, btw, можно сделать вывод, что не работают не только стори поинты, но и планинг покер. Хотя для взвешивания быка 🐂 вроде работает. Разница в том, что при планировании работы, мы оцениваем себя, а от веса быка нам ни холодно, ни жарко.
tenchat.ru
MOVE как атомарная единица бизнес-ценности — Олег Лыков на TenChat.ru
Целевой пакет/объем работ также является единицей обязательств.
В #Канбан-доске управления портфелем проектов буфер ограничения в потоке работ представлен колонкой "Принято".
Обязательства, которые попадают в колонку "Принято", являются именно такими: они…
В #Канбан-доске управления портфелем проектов буфер ограничения в потоке работ представлен колонкой "Принято".
Обязательства, которые попадают в колонку "Принято", являются именно такими: они…
Forwarded from MWS AI
Может ли LLM с 1 миллиардом параметров обойти LLM c 405 миллиардами?
Всем привет, сегодня хотел обсудить статью с многообещающим названием "Can 1B LLM Surpass 405B LLM?".
забегая вперед, ответ - да (можно увидеть на картинке 1), конечно, с оговоркой, что на некоторых задачах и при определенных условиях
что за задачи и условия? об этом и поговорим; задач в статье рассмотрено две, точнее два набора задач - MATH-500 и AIME24
теперь про условия, условие здесь самое важное - это дополнительные рассуждения модели в момент ответа на вопрос
для рассуждения в статье используют и Llama 3 и Qwen 2.5,, точнее по несколько разновеликих моделей из этих семейств
тут есть хитрость, рассуждения сейчас принято делить на несколько видов:
но сгенерировать набор гипотез мало, необходимо еще как-то из этих гипотез выбрать, а чтобы выбрать, необходимо сначала оценить, и тут коллеги разошлись на полную - используют 7 разных моделей, каждая из которых еще может быть в разных весовых категориях; эти модели могут использоваться по-разному - например, для оценки конечного результата Beam Search или каждого шага
дополнительно, они исследуют разные схемы выбора из нескольких оцененных вариантов, такие как - выбор самого частого варианта, выбор варианта с самой высокой оценкой и другие
после всех ухищрений с поиском оптимального сочетания всех факторов, они как раз и приходят к картинке 1 и положительному ответу на вопрос, но на мой взгляд тут на мой взгляд интересна картинка 3: она показывает, что общие затраты вычислений на все рассуждения маленькой моделькой и затраты на вычисление ответа большой моделью оказываются сопоставимы
это на мой взгляд фундаментально - качество зависит от того, сколько вы "думаете" над задачей, не так важно - большая у вас модель или маленькая; этому есть аналогия в живой природе - есть такой род пауков Portia (порция), которые демонстрируют сложность поведения сравнимую с кошкой, они своим небольшим нервным узлом, заменяющим им мозг, могут рассчитывать сложные прыжки, например, хотя количество нейронов у них в сотни раз меньше; делают они это за счет обработки задачи по частям, то есть они сначала долго сидят и думают, а потом - как прыгнут!
Всем привет, сегодня хотел обсудить статью с многообещающим названием "Can 1B LLM Surpass 405B LLM?".
забегая вперед, ответ - да (можно увидеть на картинке 1), конечно, с оговоркой, что на некоторых задачах и при определенных условиях
что за задачи и условия? об этом и поговорим; задач в статье рассмотрено две, точнее два набора задач - MATH-500 и AIME24
MATH-500 - это 500 математических задач уровня старшей школы, которые предназначены для решения школьниками в классе, AIME24 - это 24 олимпиадных задачи также уровня старшей школы; в последнее время эти два набора стали популярны для оценки моделей по математике
теперь про условия, условие здесь самое важное - это дополнительные рассуждения модели в момент ответа на вопрос
для рассуждения в статье используют и Llama 3 и Qwen 2.5,, точнее по несколько разновеликих моделей из этих семейств
тут есть хитрость, рассуждения сейчас принято делить на несколько видов:
выбор из нескольких параллельно сгенерированных вариантов (Best of N, BoN), построения дерева рассуждений (Beam Search) и выбор из нескольких таких деревьев (Diverse Verifier Tree Search, DVTS), они все показаны на картинке 2; у каждого из этих вариантов есть свои гиперпараметры, например, количество вариантов для BoN или деревьев для DVTS
но сгенерировать набор гипотез мало, необходимо еще как-то из этих гипотез выбрать, а чтобы выбрать, необходимо сначала оценить, и тут коллеги разошлись на полную - используют 7 разных моделей, каждая из которых еще может быть в разных весовых категориях; эти модели могут использоваться по-разному - например, для оценки конечного результата Beam Search или каждого шага
дополнительно, они исследуют разные схемы выбора из нескольких оцененных вариантов, такие как - выбор самого частого варианта, выбор варианта с самой высокой оценкой и другие
после всех ухищрений с поиском оптимального сочетания всех факторов, они как раз и приходят к картинке 1 и положительному ответу на вопрос, но на мой взгляд тут на мой взгляд интересна картинка 3: она показывает, что общие затраты вычислений на все рассуждения маленькой моделькой и затраты на вычисление ответа большой моделью оказываются сопоставимы
это на мой взгляд фундаментально - качество зависит от того, сколько вы "думаете" над задачей, не так важно - большая у вас модель или маленькая; этому есть аналогия в живой природе - есть такой род пауков Portia (порция), которые демонстрируют сложность поведения сравнимую с кошкой, они своим небольшим нервным узлом, заменяющим им мозг, могут рассчитывать сложные прыжки, например, хотя количество нейронов у них в сотни раз меньше; делают они это за счет обработки задачи по частям, то есть они сначала долго сидят и думают, а потом - как прыгнут!
на этой оптимистической ноте я бы хотел закончить свой рассказ; в комментариях накидывайте варианты статей для будущих разборов🔚
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from настенька и графики
Как подойти к дизайну визуализации?🪜
Вчера в рассылке писала про модель Тамары Мунзнер, которая предлагает учитывать разные уровни вложенности в процессе визуализации. Идея в том, что ошибка на предыдущем уровне ломает все на следующем, поэтому важно идти по ступенькам:
👩💻1. Понимание домена – кто целевая аудитория и что они делают?
Самое опасное тут – неправильно понять конечные цели пользователей. Решать можно через качественный сбор требований:
- Dashbaord Canvas Ромы Бунина
- Про пользовательские интервью от Nielsen Group
- Jobs to be Done
🔎2. Задача и данные – какие данные мы показываем и зачем люди на них смотрят?
Из опасностей – выбор не тех данных и трансформация к ним, непревильно подобранные аналитические вопросы к данным
- Lean Anlaytics
- Как измерять?
- Дата команды и пониманием метрик бизнеса
- Одинаковые данные, разные вопросы
📊3. Визуальное представление – как это визуализировано?
Важен правильный выбор визуализаций.
- Как выбрать график?
- Эффективность базовых графиков
- Когнитивные искажения
🛠4. Валидация алгоритма – можем ли мы это сделать?
Проверка, что с визуализаций реально взаимодействовать и она технически реализуема.
- Про перфоманс дэшбордов в Tableau и перфоманс тестирование
Вчера в рассылке писала про модель Тамары Мунзнер, которая предлагает учитывать разные уровни вложенности в процессе визуализации. Идея в том, что ошибка на предыдущем уровне ломает все на следующем, поэтому важно идти по ступенькам:
👩💻1. Понимание домена – кто целевая аудитория и что они делают?
Самое опасное тут – неправильно понять конечные цели пользователей. Решать можно через качественный сбор требований:
- Dashbaord Canvas Ромы Бунина
- Про пользовательские интервью от Nielsen Group
- Jobs to be Done
🔎2. Задача и данные – какие данные мы показываем и зачем люди на них смотрят?
Из опасностей – выбор не тех данных и трансформация к ним, непревильно подобранные аналитические вопросы к данным
- Lean Anlaytics
- Как измерять?
- Дата команды и пониманием метрик бизнеса
- Одинаковые данные, разные вопросы
📊3. Визуальное представление – как это визуализировано?
Важен правильный выбор визуализаций.
- Как выбрать график?
- Эффективность базовых графиков
- Когнитивные искажения
🛠4. Валидация алгоритма – можем ли мы это сделать?
Проверка, что с визуализаций реально взаимодействовать и она технически реализуема.
- Про перфоманс дэшбордов в Tableau и перфоманс тестирование
Substack
Nested Model for Visualization
Understanding Tamara Munzner’s Nested Model for Visualization Design and Validation
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
#Инструменты Docker✅
Docker медленно, но очень верно становится обязательным приложением для Data Science(особенно, в связке в kuber). Возможность сохранять особенности своего окружения, при этом разворачивать проекты на своем устройстве делает Docker на 1000 процентов обязательный для человека в IT😍
Поэтому в этом посте я собрал бесплатные материалы для изучения, для тех, кто давно хотел, но руки не доходили:
1. Karpov.cources
Классный курс, сам его проходил (буквально пару недель назад), немного душноватну а как еще с docker
2. Docker для начинающий на Stepik + практический опыт
3. Docker, GIT и Gitlab CI для начинающих от преподавателей МФТИ
4. Ну и куда же без хабра
Надеюсь, данный пост вам был полезен, и вы сможете улучшить свои навыки🫡
Всех обнял, приподнял💗
Docker медленно, но очень верно становится обязательным приложением для Data Science(особенно, в связке в kuber). Возможность сохранять особенности своего окружения, при этом разворачивать проекты на своем устройстве делает Docker на 1000 процентов обязательный для человека в IT
Поэтому в этом посте я собрал бесплатные материалы для изучения, для тех, кто давно хотел, но руки не доходили:
1. Karpov.cources
Классный курс, сам его проходил (буквально пару недель назад), немного душноват
2. Docker для начинающий на Stepik + практический опыт
3. Docker, GIT и Gitlab CI для начинающих от преподавателей МФТИ
4. Ну и куда же без хабра
Надеюсь, данный пост вам был полезен, и вы сможете улучшить свои навыки
Всех обнял, приподнял
Please open Telegram to view this post
VIEW IN TELEGRAM