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
Forwarded from Nik | Growth and Product
CAC:LTV. Как много в этой аббревиатуре для сердца предпринимателя слилось.🚬
На самом деле академический LTV считается криво, и как правило мало кому понятен😂
Поэтому я использую LTGM - Life time gross margin - сколько денег заработали с пользователя в течение его срока жизни как клиента.⌨️ - и вам советую использовать эту метрику.
Почему так? Потому что метрика любая должна быть легко интерпретируема, и понятна любому, а не только людям с финансовым образованием😂
Почему CAC - LTGM чуть ли не самая важная метрика в бизнесе? Потому что она дает вам самое четкое представление о том:
1. Сколько вы зарабатываете с одного клиента
2. Как быстро вы отбиваете затраты на его привлечение и совершение сделки
Далее исходя из этих двух переменных вы строите стратегию:
1. Либо апсейлов😐
2. Либо увеличения среднего чека😐
3. Либо снижения затрат на привлечение (что к слову, сложнее, чем увеличить средний чек).😔
Бенчмарки - при CAC:LTGM = 1:3 делается устойчивый бизнес.💰
При 1:10 или 1:20 делается тонна денег и знакомые задают вопрос, а легально ли ты вообще зарабатываешь🤨
К слову, чтобы достичь 1:10 нужен определенный набор навыков у фаундера🤑
Как только получилось достичь соотношения 1:3 и выше - заливаете деньгами воронку привлечения клиентов, и кайфуете (на самом деле нет, поскольку к скейлингу надо подготовить бэк оффис, в виде сапорта, онбординг команду и ИТ отдел. Но об этом в следующей серии)😘
На самом деле академический LTV считается криво, и как правило мало кому понятен
Поэтому я использую LTGM - Life time gross margin - сколько денег заработали с пользователя в течение его срока жизни как клиента.
Почему так? Потому что метрика любая должна быть легко интерпретируема, и понятна любому, а не только людям с финансовым образованием
Почему CAC - LTGM чуть ли не самая важная метрика в бизнесе? Потому что она дает вам самое четкое представление о том:
1. Сколько вы зарабатываете с одного клиента
2. Как быстро вы отбиваете затраты на его привлечение и совершение сделки
Далее исходя из этих двух переменных вы строите стратегию:
1. Либо апсейлов
2. Либо увеличения среднего чека
3. Либо снижения затрат на привлечение (что к слову, сложнее, чем увеличить средний чек).
Бенчмарки - при CAC:LTGM = 1:3 делается устойчивый бизнес.💰
При 1:10 или 1:20 делается тонна денег и знакомые задают вопрос, а легально ли ты вообще зарабатываешь
К слову, чтобы достичь 1:10 нужен определенный набор навыков у фаундера
Как только получилось достичь соотношения 1:3 и выше - заливаете деньгами воронку привлечения клиентов, и кайфуете (на самом деле нет, поскольку к скейлингу надо подготовить бэк оффис, в виде сапорта, онбординг команду и ИТ отдел. Но об этом в следующей серии)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Мальцев: Карьера с AI
Ребята, астрологи-инфобизнесмены объявили, что прошло уже 8% года и население с невыполненными целями удвоилось.🔥 .
Сейчас будет полезно сравнить факты и планы января. Проверить, что маршрут на 2025 реально построен и время прибытия к ожидаемым результатам полностью совпадает с вашим темпом работы.
В этом году у меня получился классный и размеренный старт, за что огромное спасибо моей команде и работе по методике из 8 «буду делать».
Детали и примеры к каждому пункту - в статье на vc.ru:
• Как быстро выйти на максимальную продуктивность в 2025?
• Как находить время на личные задачи, не срываться на встречи и перестать прокрастинировать?
• Как разобраться, для каких задач действительно полезны нейросети?
За 3 года взаимодействия с нейросетями я сформулировал для себя 3 правила работы с GPT
❤️ и 👍 - если пост полезен. Написал его по мотивам моих наблюдений за тем, как знакомые мне люди все еще раскачиваются после новогодних.
Мальцев: Карьера. Маркетинг. AI.
Please open Telegram to view this post
VIEW IN TELEGRAM
vc.ru
Как начать работу в новом году и не раскачиваться долго
Я отвечаю за маркетинг Яндекс Браузера (ex CMO Яндекс Путешествия, Playrix, eBay, Groupon, консультировал League of Legends, Tinkoff, Sber, VK) и буду рад делиться своим опытом. Подпишитесь на мой telegram-канал «Мальцев: Карьера. Маркетинг. AI», где раз…