Forwarded from Quant Valerian
Про лидершип
Несмотря на мемы про природный лидершип, мне все-таки есть, что сказать по этому поводу.
В этой ветке мало теории. Поэтому ща одним постом выдам вам базу, которая на 90% покрывает всё, что я видел на эту тему.
Очень много армейского. Видимо, там очень важная компетенция, считается. Прям брошюры есть от армий разных стран. Содержание там примерно следующее:
- Leadership by example
- Веди себя нормально по отношению к подчиненным
Больше там ничего нет.
Вести себя нормально дано не всем. Очень много людей, которым нужно самоутверждаться за счет других, всюду показывать свою лычку начальника и вообще демонстрировать КТО ЗДЕСЬ ВЛАСТЬ.
Если вы такой (в текущий момент времени), не рекомендую идти в тимлиды, потому что нормальную команду собрать не получится. Вас либо размажут и сожрут взрослые дяди, либо будете сидеть и загнивать в сомнительном обществе.
А вот быть примером нужно учиться. Но чтобы научиться этому, нужно, блин, стараться. С майндсетом "я начальник, ты дурак" точно не получится. Нужно вести себя так, как ты хочешь, чтобы работали твои ребята:
- решали проблемы, а не закапывали под ковер
- бежали к цели, а не плыли по течению
- решали задачи в срок
- выполняли закоммиты
- признавали ошибки
- не опаздывали на встречи...
Вот, что вам надо — то выберите и делайте сами. Долго. Всегда.
Но как мне занять лидерскую позицию? Как получить уважение? А что, если я вообще не программист, а они все победители олимпиад?
А у тебя работа не программировать, а управлять. Вот ты покажи, что ты свою работу хорошо делаешь, прям вот круто, тогда и уважение получишь. Авторитет зарабатывается трек-рекордом. Тебе нужно быть последовательным, выполнять обещания, не отступать от заявленных правил.
Обещал уволить за еще один подобный факап? Сам виноват, теперь увольняй.
Обещал дать премию за успешное закрытие проекта? Не важно, как его закрыли, есть факт — давай деньги!
Обещал, что к следующему разу решишь вопрос? Придется решить. И прям к следующему разу.
Буквально все эти вещи выше — это про то, что вам важно, про приоритеты. Если тебе важно быть лидером — бери себя в руки и делай. Если тебе важно, чтобы работа работалась — работай сам, покажи пример. Люди верят не словам, а действиям. А когда ты раз сказал одноЮ а сделал другое, два... На третий раз никто уже и слушать не будет. А это буквально потеря авторитета.
P.S.:
Хотя на первом этапе знакомства с командой рассказы, какой ты крутой программист дают некоторую фору, дальше нужно всё-таки показать, какой ты управленец. А программировать можно и посредственно.
Несмотря на мемы про природный лидершип, мне все-таки есть, что сказать по этому поводу.
В этой ветке мало теории. Поэтому ща одним постом выдам вам базу, которая на 90% покрывает всё, что я видел на эту тему.
Очень много армейского. Видимо, там очень важная компетенция, считается. Прям брошюры есть от армий разных стран. Содержание там примерно следующее:
- Leadership by example
- Веди себя нормально по отношению к подчиненным
Больше там ничего нет.
Вести себя нормально дано не всем. Очень много людей, которым нужно самоутверждаться за счет других, всюду показывать свою лычку начальника и вообще демонстрировать КТО ЗДЕСЬ ВЛАСТЬ.
Если вы такой (в текущий момент времени), не рекомендую идти в тимлиды, потому что нормальную команду собрать не получится. Вас либо размажут и сожрут взрослые дяди, либо будете сидеть и загнивать в сомнительном обществе.
А вот быть примером нужно учиться. Но чтобы научиться этому, нужно, блин, стараться. С майндсетом "я начальник, ты дурак" точно не получится. Нужно вести себя так, как ты хочешь, чтобы работали твои ребята:
- решали проблемы, а не закапывали под ковер
- бежали к цели, а не плыли по течению
- решали задачи в срок
- выполняли закоммиты
- признавали ошибки
- не опаздывали на встречи...
Вот, что вам надо — то выберите и делайте сами. Долго. Всегда.
Но как мне занять лидерскую позицию? Как получить уважение? А что, если я вообще не программист, а они все победители олимпиад?
А у тебя работа не программировать, а управлять. Вот ты покажи, что ты свою работу хорошо делаешь, прям вот круто, тогда и уважение получишь. Авторитет зарабатывается трек-рекордом. Тебе нужно быть последовательным, выполнять обещания, не отступать от заявленных правил.
Обещал уволить за еще один подобный факап? Сам виноват, теперь увольняй.
Обещал дать премию за успешное закрытие проекта? Не важно, как его закрыли, есть факт — давай деньги!
Обещал, что к следующему разу решишь вопрос? Придется решить. И прям к следующему разу.
Буквально все эти вещи выше — это про то, что вам важно, про приоритеты. Если тебе важно быть лидером — бери себя в руки и делай. Если тебе важно, чтобы работа работалась — работай сам, покажи пример. Люди верят не словам, а действиям. А когда ты раз сказал одноЮ а сделал другое, два... На третий раз никто уже и слушать не будет. А это буквально потеря авторитета.
P.S.:
Хотя на первом этапе знакомства с командой рассказы, какой ты крутой программист дают некоторую фору, дальше нужно всё-таки показать, какой ты управленец. А программировать можно и посредственно.
Forwarded from Quant Valerian
Ожидания и реальность
Намедни обсуждали с коллегами ожидания от грейдов в нашей компании. Мои ожидания оказались где-то на пол грейда ниже, чем у соседа. Но даже с учетом этого, мои ожидания не всегда совпадают с реальностью в моих командах. Иногда думаю, что либо нанимаю плохо, либо в какой-то другой плоскости ожидаю навыков от людей — не знаю. Работа, главное, делается, но моя фантазия, что без меня делалось бы так же круто — это, похоже, фантазия. А про эту фантазию я уже даже пост хотел сегодня запостить, лол.
Потом запосчу 🌚
Давайте попробуем устроить срач в комментах!
Я ожидаю, что:
1. Джун пишет, который его просят написать. Например: "вот тут напиши функцию, которая будет принимать заказ, считать в нем сумму стоимостей всех товаров и возвращать её"
2. Миддл может решить хорошо поставленную задачку (что и как надо сделать). Например: "в этом сервисе нужно поддержать отправку коллбэков, сделай корутинку, которая будет отправлять, роутинг по конфигу, протокол обсуди с принимающей стороной"
3. Миддл+ может решать небольшие проблемы (есть что, но нет как). Например: "в сервисе Х почему-то подскочило потребление CPU с последним релизом, поправь, пожалуйста"
4. Сеньор уже будет решать проблемы масштаба команды. Например: "соседи жалуются, что у нашей системы сервисов неудобный API и data race какой-то, предложи решение"
5. А стафф будет проблемы находить и приносить, будет уметь срезать углы, уметь задачки на шаги разбивать и делать по частям, аналитику какую-то делать. Ты ему уже даже не говоришь, что на что-то конкретное жалуются. Он сидит такой, смотрит в дэш, который сам нашел/собрал, видит там какие-то данные, по ним идентифицирует, что идет не так и идет чинить. Либо узнает боли при общении, про которые люди и не знали, что их вообще можно решить. Например: "Приходил бизнес, у них есть вот такая проблема, так больно, аж жопа горит. Что можно сделать?" И вот он идёт, смотрит, в чем причина, потом ищет возможные решения, звонит своему корешу, который работает в компании, которая эту проблему как-то решила, звонит всем вендорам и регуляторам — находит варианты решения, короче. Потом он взвешивает и показывает трейдофы бизнесу. А потом относит сеньору делать 😁
От более сеньорных чуваков у меня пока никаких ожиданий нет. Какие ваши мысли?
Намедни обсуждали с коллегами ожидания от грейдов в нашей компании. Мои ожидания оказались где-то на пол грейда ниже, чем у соседа. Но даже с учетом этого, мои ожидания не всегда совпадают с реальностью в моих командах. Иногда думаю, что либо нанимаю плохо, либо в какой-то другой плоскости ожидаю навыков от людей — не знаю. Работа, главное, делается, но моя фантазия, что без меня делалось бы так же круто — это, похоже, фантазия. А про эту фантазию я уже даже пост хотел сегодня запостить, лол.
Потом запосчу 🌚
Давайте попробуем устроить срач в комментах!
Я ожидаю, что:
1. Джун пишет, который его просят написать. Например: "вот тут напиши функцию, которая будет принимать заказ, считать в нем сумму стоимостей всех товаров и возвращать её"
2. Миддл может решить хорошо поставленную задачку (что и как надо сделать). Например: "в этом сервисе нужно поддержать отправку коллбэков, сделай корутинку, которая будет отправлять, роутинг по конфигу, протокол обсуди с принимающей стороной"
3. Миддл+ может решать небольшие проблемы (есть что, но нет как). Например: "в сервисе Х почему-то подскочило потребление CPU с последним релизом, поправь, пожалуйста"
4. Сеньор уже будет решать проблемы масштаба команды. Например: "соседи жалуются, что у нашей системы сервисов неудобный API и data race какой-то, предложи решение"
5. А стафф будет проблемы находить и приносить, будет уметь срезать углы, уметь задачки на шаги разбивать и делать по частям, аналитику какую-то делать. Ты ему уже даже не говоришь, что на что-то конкретное жалуются. Он сидит такой, смотрит в дэш, который сам нашел/собрал, видит там какие-то данные, по ним идентифицирует, что идет не так и идет чинить. Либо узнает боли при общении, про которые люди и не знали, что их вообще можно решить. Например: "Приходил бизнес, у них есть вот такая проблема, так больно, аж жопа горит. Что можно сделать?" И вот он идёт, смотрит, в чем причина, потом ищет возможные решения, звонит своему корешу, который работает в компании, которая эту проблему как-то решила, звонит всем вендорам и регуляторам — находит варианты решения, короче. Потом он взвешивает и показывает трейдофы бизнесу. А потом относит сеньору делать 😁
От более сеньорных чуваков у меня пока никаких ожиданий нет. Какие ваши мысли?
Forwarded from Pavel Zloi
Всем привет!
После релиза R1-тюна на YandexGPT 5 Lite получил солидныйпинок фидбэк от ML-сообщества. Если кратко: по мнению сообщества моя модель - не R1, потому что я ограничился SFT без RL, в довесок мне выдали охапку ссылок на различные исследования и публикации, так что последние два дня я практически всё свободное время впитывал новую информацию аки губка.
Начну с первой партии ссылок и некоторыми моими комментариями о прочитанном.
SFT Memorizes, RL Generalizes: A Comparative Study of Foundation Model Post-training (arXiv:2501.17161)
Кратенько: Исследователи сравнили SFT и RL на задачах арифметики и анализе изображений. "Чистый" SFT идеален для запоминания формата ответов и на данных в пределах домена (ID in-domain), но фейлится на данных вне тренировочного домена (OOD out-of-domain). "Чистый" RL (особенно с outcome-based reward) обобщает даже на невиданные ранее сценарии (OOD), но плохо соблюдает формат ответа.
От себя: В общем надо делать SFT+RL пайплайн для наилучшего эффекта.
Towards Reasoning in Large Language Models: A Survey (arXiv:2212.10403)
Кратенько: Небольшой обзор про ризонинг в LLM. Чем крупнее модель, тем лучше она "цепляет" паттерны рассуждений. Плюс подчеркивается неопределенность в отношении истинного ризонинга у моделей, не является ли это просто переиспользованием шаблонов из обучающего датасета.
От себя: В публикации мне понравилась про декомпозицию сложных задач на множество маленьких (типа генерация шагов решения), чтобы получались эдакие Chain-of-Thoughts последовательности ризононига, и вроде как даже слабые модели неплохо с этим справляются, надо будет поискать датасеты подходящие.
Towards Large Reasoning Models: A Survey of Reinforced Reasoning with Large Language Models (arXiv:2501.09686)
Кратенько: Подробный разбор всех шагов необходимых для обучения ризонинг модели с упором на финальный alignment этап и методы вознаграждения (обратная связь).
От себя: В данной публикации понравилось про шаги обучения модели до reasoning уровня: 1. pre-train (на text corpora); 2. fine-tune (sft на инструкциях с правильным форматом); 3. alignment (на ризонинг датасетах). Далее было очень подробно про RLHF для многоэтапных CoT последовательностей и разные виды подобного обучения и под конец про алгоритмы поиска наилучшего ответа (мой любимый кворум упоминается), там из примечательного был Lookahead Search (arXiv:2403.02502).
Understanding Reasoning LLMs (сайт)
Кратенько: Разбор кейса DeepSeek-R1, в RL было несколько наград: проверка кода через LeetCode, соблюдение формата ответа (как я понял чтобы был <think> тег) и языка на котором модель отвечает (типа чтобы не переходила на китайский слишком часто).
От себя: Очень понравилась публикация, в ней подробнейшем образом разобрана тема ризонинга на примере модели DeepSeek-R1, разобраны отдельные шаги начиная с того как была получена через RL-only тюн первая R1-Zero, потом как с её помощью сгенерировали более сложный RL датасет и как потом при его помощи выполняли обучение полновесной R1 модели.
To be continued...
После релиза R1-тюна на YandexGPT 5 Lite получил солидный
Начну с первой партии ссылок и некоторыми моими комментариями о прочитанном.
SFT Memorizes, RL Generalizes: A Comparative Study of Foundation Model Post-training (arXiv:2501.17161)
Кратенько: Исследователи сравнили SFT и RL на задачах арифметики и анализе изображений. "Чистый" SFT идеален для запоминания формата ответов и на данных в пределах домена (ID in-domain), но фейлится на данных вне тренировочного домена (OOD out-of-domain). "Чистый" RL (особенно с outcome-based reward) обобщает даже на невиданные ранее сценарии (OOD), но плохо соблюдает формат ответа.
От себя: В общем надо делать SFT+RL пайплайн для наилучшего эффекта.
Towards Reasoning in Large Language Models: A Survey (arXiv:2212.10403)
Кратенько: Небольшой обзор про ризонинг в LLM. Чем крупнее модель, тем лучше она "цепляет" паттерны рассуждений. Плюс подчеркивается неопределенность в отношении истинного ризонинга у моделей, не является ли это просто переиспользованием шаблонов из обучающего датасета.
От себя: В публикации мне понравилась про декомпозицию сложных задач на множество маленьких (типа генерация шагов решения), чтобы получались эдакие Chain-of-Thoughts последовательности ризононига, и вроде как даже слабые модели неплохо с этим справляются, надо будет поискать датасеты подходящие.
Towards Large Reasoning Models: A Survey of Reinforced Reasoning with Large Language Models (arXiv:2501.09686)
Кратенько: Подробный разбор всех шагов необходимых для обучения ризонинг модели с упором на финальный alignment этап и методы вознаграждения (обратная связь).
От себя: В данной публикации понравилось про шаги обучения модели до reasoning уровня: 1. pre-train (на text corpora); 2. fine-tune (sft на инструкциях с правильным форматом); 3. alignment (на ризонинг датасетах). Далее было очень подробно про RLHF для многоэтапных CoT последовательностей и разные виды подобного обучения и под конец про алгоритмы поиска наилучшего ответа (мой любимый кворум упоминается), там из примечательного был Lookahead Search (arXiv:2403.02502).
Understanding Reasoning LLMs (сайт)
Кратенько: Разбор кейса DeepSeek-R1, в RL было несколько наград: проверка кода через LeetCode, соблюдение формата ответа (как я понял чтобы был <think> тег) и языка на котором модель отвечает (типа чтобы не переходила на китайский слишком часто).
От себя: Очень понравилась публикация, в ней подробнейшем образом разобрана тема ризонинга на примере модели DeepSeek-R1, разобраны отдельные шаги начиная с того как была получена через RL-only тюн первая R1-Zero, потом как с её помощью сгенерировали более сложный RL датасет и как потом при его помощи выполняли обучение полновесной R1 модели.
To be continued...
Forwarded from Pavel Zloi
И так, продолжаем разговор, ссылок набралось порядочно, так вот вторая пачка публикаций, их краткое саммари и мой небольшой комментарий.
Curated collection of papers and resources on how to unlock the reasoning ability of LLMs and MLLMs (ссылка)
Кратенько: По ссылке коллекция из 130+ ссылок на статьи про датасеты и техники обучения ризонингу вышедшие начиная с 2022 года, так что всё достаточно свежее, есть обзорные статьи, есть разные околотехнические статьи с анализом работы тех или иных моделей, есть статьи про техники обучения и тестирования ризонинга и так далее.
От себя: В проекте собрана великолепная подборка различных публикаций и проектов, однако, отдельно хочу отметить заинтересовавший меня проект google-research/cascades, который позволяет формировать "каскадные" CoT цепочки вызывая внешние тулы и используя механизмы обратной связи.
Training Language Models to Self-Correct via Reinforcement Learning (arXiv:2409.12917)
Кратенько: Эта публикация про метод Self-Correct via Reinforcement Learning (SCoRe), использующий RL для улучшения способности языковых моделей к самокоррекции через генерацию собственных данных, что по тестам позволило достичь хороших результатов на бенчмарках MATH и HumanEval.
От себя: Очень любопытная статья,. по тексту сложилось мнение что SCoRe это что-то среднее между RL и RLHF (только вместо хумана обучаемая модель). Как я понял модель в процессе обучения делает две генерации, после первой проверяет себя и генерируют инструкцию самокоррекции, после второй рассчитывается то насколько ответы похожи на правильный из датасета (при этом не показывая модели какой правильный) и из этого формируется RL-награда, финальная цель которой обучить модель либо с первого раза отвечать "как надо" либо с одной подсказкой.
Marco-o1: Towards Open Reasoning Models for Open-Ended Solutions (arXiv:2411.14405)
Кратенько: Эта публикация представляет модель Marco-o1 и методы её RL обучения используя Chain-of-Thought, MCTS и механизмы рефлексии.
От себя: В данной публикации очень подробно описан весь процесс, который сводится к SFT обучению на CoT инструкциях, после чего RL обучению который предполагает, что модель сама будет генерировать возможные варианты ответа (дерево решений), после через MCTS (Monte Carlo Tree Search) выбирать наиболее эффективный (через оценку top-k и softmax). Процесс "рассуждения" продолжается до тех пока не будет достигнут приемлемый результат.
Puzzle Solving using Reasoning of Large Language Models: A Survey (arXiv:2402.11291)
Кратенько: Любопытный обзор исследований, оценивающих способности LLM в решении головоломок.
От себя: Из интересного классификация видов загадок и обзор датасетов под каждый из примеров, но отдельно хочу отметить упоминаемую работу "Graph of Thoughts: Solving Elaborate Problems with Large Language Models" (arxiv:2308.09687) о фреймворке, который позволяет построить не просто цепочку, а граф размышлений.
Продолжение продолжит продолжаться...
Curated collection of papers and resources on how to unlock the reasoning ability of LLMs and MLLMs (ссылка)
Кратенько: По ссылке коллекция из 130+ ссылок на статьи про датасеты и техники обучения ризонингу вышедшие начиная с 2022 года, так что всё достаточно свежее, есть обзорные статьи, есть разные околотехнические статьи с анализом работы тех или иных моделей, есть статьи про техники обучения и тестирования ризонинга и так далее.
От себя: В проекте собрана великолепная подборка различных публикаций и проектов, однако, отдельно хочу отметить заинтересовавший меня проект google-research/cascades, который позволяет формировать "каскадные" CoT цепочки вызывая внешние тулы и используя механизмы обратной связи.
Training Language Models to Self-Correct via Reinforcement Learning (arXiv:2409.12917)
Кратенько: Эта публикация про метод Self-Correct via Reinforcement Learning (SCoRe), использующий RL для улучшения способности языковых моделей к самокоррекции через генерацию собственных данных, что по тестам позволило достичь хороших результатов на бенчмарках MATH и HumanEval.
От себя: Очень любопытная статья,. по тексту сложилось мнение что SCoRe это что-то среднее между RL и RLHF (только вместо хумана обучаемая модель). Как я понял модель в процессе обучения делает две генерации, после первой проверяет себя и генерируют инструкцию самокоррекции, после второй рассчитывается то насколько ответы похожи на правильный из датасета (при этом не показывая модели какой правильный) и из этого формируется RL-награда, финальная цель которой обучить модель либо с первого раза отвечать "как надо" либо с одной подсказкой.
Marco-o1: Towards Open Reasoning Models for Open-Ended Solutions (arXiv:2411.14405)
Кратенько: Эта публикация представляет модель Marco-o1 и методы её RL обучения используя Chain-of-Thought, MCTS и механизмы рефлексии.
От себя: В данной публикации очень подробно описан весь процесс, который сводится к SFT обучению на CoT инструкциях, после чего RL обучению который предполагает, что модель сама будет генерировать возможные варианты ответа (дерево решений), после через MCTS (Monte Carlo Tree Search) выбирать наиболее эффективный (через оценку top-k и softmax). Процесс "рассуждения" продолжается до тех пока не будет достигнут приемлемый результат.
Puzzle Solving using Reasoning of Large Language Models: A Survey (arXiv:2402.11291)
Кратенько: Любопытный обзор исследований, оценивающих способности LLM в решении головоломок.
От себя: Из интересного классификация видов загадок и обзор датасетов под каждый из примеров, но отдельно хочу отметить упоминаемую работу "Graph of Thoughts: Solving Elaborate Problems with Large Language Models" (arxiv:2308.09687) о фреймворке, который позволяет построить не просто цепочку, а граф размышлений.
Продолжение продолжит продолжаться...
Forwarded from Dealer.AI
Немного про LLM и реальность в проде (бизнес кейсы).
Дядя тут быканул на один постик про оркестрацию, метамодели и роутинг моделек вокруг/с LM. Закономерно получилотрицательную ОС. Но все же, чтобы там не думали, что автор с НИИ и все же прод.опыт имеющий, а не тварь дрожащая , расскажет вам Дядя про реальность чутка.
Интро. Борд хочет, чтобы all in на LLM и кидает в вас задачу на проникновение современных БЯМ в бизнес процессы, тех.решения и платформы. Ведь ему со всех углов уже налили в уши, что это рокет саенс и золотая пуля.Нет.
И вот Вы бедняга, берете под козырек тащить это в уже устоявшиеся пайпы, системы и процессы.
Кейс 1. Система распознавания намерений. Хочется взять описания основных сценариев взаимодействия с клиентом, ака интенты, взять фразы в чате юзера и сказать: LMушка а вызови подходящий сценарий по описанию и запросу. И по-началу у вас будет это работать, но есть нюанс. На десятке интентов это может и ок. Если ваша LMка норм,то даже и соточку потянет. Но в системе интентов бывает сотни сценариев, и некоторые модельки тут уже не тянут. Да еще и глючат при генерации названия интента. И поэтому хитрые прод. инженеры используют хаки. Например, мы вот имели ж до этого систему на классификаторах и tfidf/fasttext/bert и хорошо оно работало итак без LLM для сотни и даже тыс. интентов. А давайте, чтобы убрать глюки и проблемы масштабируемости просто будем с этих модулей старых выдавать топК кандидатов. Берем К кандидатов, их описание и фразу юзера, кидаем в LLM и профит она из ограниченного списка, с recall@K которого 0.95+ выберет вам с 100% вероятностью нужный ответ. И фигак ты и кпэ закрыл и как бы LMка в проде. А чтобы это было чисто на LMке тебе придется еще думать про скейлинг, сегодня у тебя 10 интентов, а завтра 20 и перетюнить LM ты задолбаешься, классификаторы быстрее ретюн.Конечно можно лорку гонять, да.
Ах и да, тут ещё важно,что на запросы отвечает всеравно старый добрый сценарный движок или qa система. Да, да это оч близкий подход к RAG.
Кейс 2. Поиск и LLM. Мы же понимаем,что из весов LM поисковик так себе? Тут возникает вопрос актуальности данных,постоянного из-за этого переобучения, да и еще до кучи — глюки. Поэтому тут как раз, был придуман RAG. А LMка получает роль или ризонера по выдаче или вообще пишет тлдр по выдаче. До кучи, конечно, это над присыпать ссылками на источники, чтобы повысить доверие, да еще пошарить с вами ответственность за верификацию выдачи. Но иногда, ребята идут дальше, например делают технологию блендера, когда ответ из весов LM и выдачи с поиска (иной любой системы) еще скорится доп.алгоритмом и выбирается лучший ответ. К примеру, тут вот ребята с Яндекс создавали рекламные тайтлы, используя такой подход.
Кейс 3. Про читчат и ассистентов.
Когда появились LMки аля ChGPT все говорили, что это новая эра для ассистентов. Но в итоге, эти LM-based системы всеравно у серьезных игроков опираются на тот самый блендер между старыми отлаженными модулями: intent recognition, retrieval и дерево сценариев. А роль БЯМ или переписывать ответы, или выбирать из уже порезанной выдачи ретривала/интент классификации и в остальных случаях вести беседу самостоятельно e2e. Вообщем в целом жизнеспособность only e2е LLM в таких задачах спорно. По крайней мере сейчас. У знакомых вообще долгое время retrieval based диалоговая система не уступала LLM-based причем метрику оценки формировала команда БЯМ. Да LLM дает больше разнообразия ответов, интересности, зато ретривал релевантности. Поэтому и тут-то тоже блендер схема зашла на ура.
К чему я это все, да оркестрация старых + склейка с новыми системами важна. Переиспользование старых стабильных, надежных и высокоэффективных модулей тоже не зазорно. Можно ли это блендить и мерджить с LLM? Нужно. И не стоит делать all in на LLM. Сложно ли это сделать? Да нелегко, но дорогу осилит идущий.
Дядя тут быканул на один постик про оркестрацию, метамодели и роутинг моделек вокруг/с LM. Закономерно получил
Интро. Борд хочет, чтобы all in на LLM и кидает в вас задачу на проникновение современных БЯМ в бизнес процессы, тех.решения и платформы. Ведь ему со всех углов уже налили в уши, что это рокет саенс и золотая пуля.
И вот Вы бедняга, берете под козырек тащить это в уже устоявшиеся пайпы, системы и процессы.
Кейс 1. Система распознавания намерений. Хочется взять описания основных сценариев взаимодействия с клиентом, ака интенты, взять фразы в чате юзера и сказать: LMушка а вызови подходящий сценарий по описанию и запросу. И по-началу у вас будет это работать, но есть нюанс. На десятке интентов это может и ок. Если ваша LMка норм,то даже и соточку потянет. Но в системе интентов бывает сотни сценариев, и некоторые модельки тут уже не тянут. Да еще и глючат при генерации названия интента. И поэтому хитрые прод. инженеры используют хаки. Например, мы вот имели ж до этого систему на классификаторах и tfidf/fasttext/bert и хорошо оно работало итак без LLM для сотни и даже тыс. интентов. А давайте, чтобы убрать глюки и проблемы масштабируемости просто будем с этих модулей старых выдавать топК кандидатов. Берем К кандидатов, их описание и фразу юзера, кидаем в LLM и профит она из ограниченного списка, с recall@K которого 0.95+ выберет вам с 100% вероятностью нужный ответ. И фигак ты и кпэ закрыл и как бы LMка в проде. А чтобы это было чисто на LMке тебе придется еще думать про скейлинг, сегодня у тебя 10 интентов, а завтра 20 и перетюнить LM ты задолбаешься, классификаторы быстрее ретюн.
Ах и да, тут ещё важно,что на запросы отвечает всеравно старый добрый сценарный движок или qa система. Да, да это оч близкий подход к RAG.
Кейс 2. Поиск и LLM. Мы же понимаем,что из весов LM поисковик так себе? Тут возникает вопрос актуальности данных,постоянного из-за этого переобучения, да и еще до кучи — глюки. Поэтому тут как раз, был придуман RAG. А LMка получает роль или ризонера по выдаче или вообще пишет тлдр по выдаче. До кучи, конечно, это над присыпать ссылками на источники, чтобы повысить доверие, да еще пошарить с вами ответственность за верификацию выдачи. Но иногда, ребята идут дальше, например делают технологию блендера, когда ответ из весов LM и выдачи с поиска (иной любой системы) еще скорится доп.алгоритмом и выбирается лучший ответ. К примеру, тут вот ребята с Яндекс создавали рекламные тайтлы, используя такой подход.
Кейс 3. Про читчат и ассистентов.
Когда появились LMки аля ChGPT все говорили, что это новая эра для ассистентов. Но в итоге, эти LM-based системы всеравно у серьезных игроков опираются на тот самый блендер между старыми отлаженными модулями: intent recognition, retrieval и дерево сценариев. А роль БЯМ или переписывать ответы, или выбирать из уже порезанной выдачи ретривала/интент классификации и в остальных случаях вести беседу самостоятельно e2e. Вообщем в целом жизнеспособность only e2е LLM в таких задачах спорно. По крайней мере сейчас. У знакомых вообще долгое время retrieval based диалоговая система не уступала LLM-based причем метрику оценки формировала команда БЯМ. Да LLM дает больше разнообразия ответов, интересности, зато ретривал релевантности. Поэтому и тут-то тоже блендер схема зашла на ура.
К чему я это все, да оркестрация старых + склейка с новыми системами важна. Переиспользование старых стабильных, надежных и высокоэффективных модулей тоже не зазорно. Можно ли это блендить и мерджить с LLM? Нужно. И не стоит делать all in на LLM. Сложно ли это сделать? Да нелегко, но дорогу осилит идущий.
Telegram
Dealer.AI
Не поиском едины.
Вчера вечером посмотрел интересное от Яндекса.
Митап ML в Белграде. Команда поиска рассказывала о своём опыте с LLM.
Мне были интересны первые два доклада. Поэтому мои заметки ниже.
Доклад 1. Про генерацию рекламных предложений в…
Вчера вечером посмотрел интересное от Яндекса.
Митап ML в Белграде. Команда поиска рассказывала о своём опыте с LLM.
Мне были интересны первые два доклада. Поэтому мои заметки ниже.
Доклад 1. Про генерацию рекламных предложений в…
Forwarded from black_samorez
Выложили запись моего семинара про оптимальнось квантизованного претрена с помощью QuEST.
YouTube
Andrei Panferov - QuEST: Stable Training of LLMs with 1 Bit Weights and Activations
Presenting a new low-bitwidth LLM pre-training scheme called QuEST and demonstrating its optimality at 4 bit training.
Bio: PhD student at ISTA and ELLIS researching novel approaches for efficient LLM training and inference.
Bio: PhD student at ISTA and ELLIS researching novel approaches for efficient LLM training and inference.
Forwarded from Data Blog
Привет, друзья!
✔️ Выложила видео про CAM на YouTube. Давно не было и вот он — базовый и живой, с котом, обзор!
CAM
Идея CAM очень простая, но универсальная. Давайте на основе карт, которые мы можем достать из модели посмотрим, какие регионы изображения наиболее значимы для классификации конкретного класса?
Это помогает интерпретировать, на какие признаки обращает внимание модель при прогнозировании в задаче классификации.
CAM извлекать не всегда просто. Поэтому в видео я разобрала неклассический случай построения карты — на примере VGG.
CAM advanced
Кроме того, извлекая не только карты, связанные с классом, но и просто карты (Activation Maps), можно увидеть, как постепенно признаки меняются внутри сети. Такой способ я описывала в туториале про YOLO. Как видите, идея масштабируется от простых моделек, вроде ResNet, до моделек более «звучных» на текущий период!
Зову смотреть! =)
Мы с котом старались!
Отличного вечера,
Ваш Дата-автор!
✔️ Выложила видео про CAM на YouTube. Давно не было и вот он — базовый и живой, с котом, обзор!
CAM
Идея CAM очень простая, но универсальная. Давайте на основе карт, которые мы можем достать из модели посмотрим, какие регионы изображения наиболее значимы для классификации конкретного класса?
Это помогает интерпретировать, на какие признаки обращает внимание модель при прогнозировании в задаче классификации.
CAM извлекать не всегда просто. Поэтому в видео я разобрала неклассический случай построения карты — на примере VGG.
CAM advanced
Кроме того, извлекая не только карты, связанные с классом, но и просто карты (Activation Maps), можно увидеть, как постепенно признаки меняются внутри сети. Такой способ я описывала в туториале про YOLO. Как видите, идея масштабируется от простых моделек, вроде ResNet, до моделек более «звучных» на текущий период!
Зову смотреть! =)
Мы с котом старались!
Отличного вечера,
Ваш Дата-автор!
YouTube
Построение карты активации классов (Class Activation Map)
В этом туториале разобраны карты активации классов (Class Activation Maps, CAM) — метод из области объяснимый ИИ (Explainable AI).
В процессе туториала, вы:
1. Научитесь извлекать части нейронной сети и цеплять к ним пользовательские функции для извлечения…
В процессе туториала, вы:
1. Научитесь извлекать части нейронной сети и цеплять к ним пользовательские функции для извлечения…
Forwarded from Data Blog
Привет, Друзья!
Копалась в интернете — нашла золото: библиотека NNsight
Смысл:
За счет некоторых оптимизаций, они позволяют обвешивать Hf модельки так, чтобы извлекать скрытые состояния для дальнейшего анализа.
Преимущества:
Скорость запуска и удобный интерфейс. Плюс понятные туториалы с красивыми картинками.
Практика:
1. Убедиться в скорости запуска моделей не успела, а вот в удобстве интерфейса — да. За счет того, что библиотека обвешана туториалами, удобно как минимум в образовательных целях пробовать их для себя.
На то, чтобы восстановить метод Logit Lens без либы у меня ушло +/- 3 часа (два — просто на визуализацию результата), так что, повторюсь, если хотите просто «потрогать метод» — must have.
2. Не все модели с Hf грузятся.
Примечание:
Как пишут авторы, библиотека находится на стадии становления. Ребятам удачи, действительно классный проект, и я не могла пройти мимо.
А завтра пятница, и я желаю вам провести её так, чтобы вечер был полностью ваш!
Со всем самым добрым,
Ваш Дата-автор!
P.S. Спасибо за поддержку на YouTube! Вы — лучшие ❤️
Копалась в интернете — нашла золото: библиотека NNsight
Смысл:
За счет некоторых оптимизаций, они позволяют обвешивать Hf модельки так, чтобы извлекать скрытые состояния для дальнейшего анализа.
Преимущества:
Скорость запуска и удобный интерфейс. Плюс понятные туториалы с красивыми картинками.
Практика:
1. Убедиться в скорости запуска моделей не успела, а вот в удобстве интерфейса — да. За счет того, что библиотека обвешана туториалами, удобно как минимум в образовательных целях пробовать их для себя.
На то, чтобы восстановить метод Logit Lens без либы у меня ушло +/- 3 часа (два — просто на визуализацию результата), так что, повторюсь, если хотите просто «потрогать метод» — must have.
2. Не все модели с Hf грузятся.
Примечание:
Как пишут авторы, библиотека находится на стадии становления. Ребятам удачи, действительно классный проект, и я не могла пройти мимо.
А завтра пятница, и я желаю вам провести её так, чтобы вечер был полностью ваш!
Со всем самым добрым,
Ваш Дата-автор!
P.S. Спасибо за поддержку на YouTube! Вы — лучшие ❤️
Forwarded from Душный NLP
SpinQuant: LLM quantization with learned rotations. Часть 1/2
Решение из сегодняшней статьи от Meta* — конкурент другой разработки по квантизации в низкую битность, QuaRot. Но в SpinQuant, кроме весов и активаций, квантуется ещё и KV-кэш. Иными словами, это SOTA-результат w4a4kv4-квантизации, который показывает очень хороший перфоманс даже на «макбуках».
Главная идея — победить проблемы выбросов (поканальных отклонений в активациях attention), добавив матрицы поворота до и после каждого линейного слоя модели. После этого квантизация проводится как обычно, но без потери качества — спасибо обучаемым, а не случайным, как в QuaRot, матрицам вращения (розовые R₁ на рисунке).
Но ничего не бывает бесплатно: умножение — отдельная операция, которая требует дополнительных ресурсов. Чтобы сэкономить в момент инференса, матрицы вращения R₁ вмёрживаются в матрицы весов W умножением. Но так получается сделать не для всех вращений: например, матрицы R₃ и R₄ вставляют в слой отдельной операцией и, как в статье QuaRot, — используют случайные матрицы Адамара.
*Компания Meta признана экстремистской организацией в России.
Разбор подготовил❣ Роман Горб
Душный NLP
Решение из сегодняшней статьи от Meta* — конкурент другой разработки по квантизации в низкую битность, QuaRot. Но в SpinQuant, кроме весов и активаций, квантуется ещё и KV-кэш. Иными словами, это SOTA-результат w4a4kv4-квантизации, который показывает очень хороший перфоманс даже на «макбуках».
Главная идея — победить проблемы выбросов (поканальных отклонений в активациях attention), добавив матрицы поворота до и после каждого линейного слоя модели. После этого квантизация проводится как обычно, но без потери качества — спасибо обучаемым, а не случайным, как в QuaRot, матрицам вращения (розовые R₁ на рисунке).
Но ничего не бывает бесплатно: умножение — отдельная операция, которая требует дополнительных ресурсов. Чтобы сэкономить в момент инференса, матрицы вращения R₁ вмёрживаются в матрицы весов W умножением. Но так получается сделать не для всех вращений: например, матрицы R₃ и R₄ вставляют в слой отдельной операцией и, как в статье QuaRot, — используют случайные матрицы Адамара.
*Компания Meta признана экстремистской организацией в России.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заскуль питона (Data Science)
Bayessian vs Frequient A/B testing [презентация]
Видео на Youtube: Александр Сахнов — Почему вам не стоит использовать байесовское A/B-тестирование
Нашел вначале шикарную презентацию от X5 по сравнению байесовского и частотного подхода к применению A/B тестов, потом нашел само видео)
Есть код на Python, можно сравнить методы на данных и посмотреть, как использовать.
Опровергаются различные мифы по поводу байесовского тестирования (про Peeking Problem, большую чувствительность, множественное тестирование)
В начале идет описание частотного A/B тестирования и пайплайн проведения:
1. Фиксирование допустимых вероятностей ошибок первого и второго рода
2. Фиксирование ожидаемого результата
3. Оцениваем по истории дисперсии
4. Оцениваем необходимый размер групп
5. Проводим эксперимент
6. Собираем данные и вычисляем p-value
7. Оцениваем результат
Говорится о сложности интерпретации p-value. Вводится статистика, у которого какое-то предельное распределение. По реализации выборки мы считаем реализацию статистики и смотрим куда попала. Про это я писал у себя в посте. Бизнесу нужно принять бинарное решение (внедряем / не внедряем).
Затем описывается пайплайн байесовского A/B тестирования:
1. Определение априорных распределений (для неизвестных для нас параметров). Далее мы переходим к апостериорному распределению с помощью правдоподобий и теоремы Байеса
2. Определение размера групп. Размер групп можем взять из частотного метода
3. Проведение эксперимента
4. Собираем данные и что-то вычисляем
5. Оцениваем результат
Частотный подход: Какая вероятность получить такое или более экстремальное значение статистики при верности H0?
Байесовский подход: Какая вероятность, что среднее уменьшилось / увеличилось по совместному апостериорному распределению?
Далее оцениваются ошибки первого и второго рода в частотном и байесовском методе. Мы можем задавать априорное распределение через uninformative prior, тогда оба метода показывают одинаковые результаты в симуляциях. Использование дополнительных знаний через prior не позволило на симуляциях контролировать ошибки первого и второго рода.
В частотном A/B-тесте у всех одни и те же результаты, но в Байесе все зависит от априорных знаний. Если два аналитика зададут разные априоры, они могут получить разные выводы по одному и тому же тесту! Представьте, что в A/B платформе такое внедряется — один продакт видит значимый эффект, а другой — нет. Как принимать решения?
Байесовские методы позволяют решать различные задачи. Например, многорорукие бандиты, EM-алгоритмы и многое другое.
🐳 Наберется 100 реакций, в следующем посте буду писать про байесовское тестирование более подробно
А вы используете байесовские методы? Если да, то какие? Пишите в комментариях.
Видео на Youtube: Александр Сахнов — Почему вам не стоит использовать байесовское A/B-тестирование
Нашел вначале шикарную презентацию от X5 по сравнению байесовского и частотного подхода к применению A/B тестов, потом нашел само видео)
Есть код на Python, можно сравнить методы на данных и посмотреть, как использовать.
Опровергаются различные мифы по поводу байесовского тестирования (про Peeking Problem, большую чувствительность, множественное тестирование)
В начале идет описание частотного A/B тестирования и пайплайн проведения:
1. Фиксирование допустимых вероятностей ошибок первого и второго рода
2. Фиксирование ожидаемого результата
3. Оцениваем по истории дисперсии
4. Оцениваем необходимый размер групп
5. Проводим эксперимент
6. Собираем данные и вычисляем p-value
7. Оцениваем результат
Говорится о сложности интерпретации p-value. Вводится статистика, у которого какое-то предельное распределение. По реализации выборки мы считаем реализацию статистики и смотрим куда попала. Про это я писал у себя в посте. Бизнесу нужно принять бинарное решение (внедряем / не внедряем).
Затем описывается пайплайн байесовского A/B тестирования:
1. Определение априорных распределений (для неизвестных для нас параметров). Далее мы переходим к апостериорному распределению с помощью правдоподобий и теоремы Байеса
2. Определение размера групп. Размер групп можем взять из частотного метода
3. Проведение эксперимента
4. Собираем данные и что-то вычисляем
5. Оцениваем результат
Частотный подход: Какая вероятность получить такое или более экстремальное значение статистики при верности H0?
Байесовский подход: Какая вероятность, что среднее уменьшилось / увеличилось по совместному апостериорному распределению?
Далее оцениваются ошибки первого и второго рода в частотном и байесовском методе. Мы можем задавать априорное распределение через uninformative prior, тогда оба метода показывают одинаковые результаты в симуляциях. Использование дополнительных знаний через prior не позволило на симуляциях контролировать ошибки первого и второго рода.
В частотном A/B-тесте у всех одни и те же результаты, но в Байесе все зависит от априорных знаний. Если два аналитика зададут разные априоры, они могут получить разные выводы по одному и тому же тесту! Представьте, что в A/B платформе такое внедряется — один продакт видит значимый эффект, а другой — нет. Как принимать решения?
Байесовские методы позволяют решать различные задачи. Например, многорорукие бандиты, EM-алгоритмы и многое другое.
🐳 Наберется 100 реакций, в следующем посте буду писать про байесовское тестирование более подробно
А вы используете байесовские методы? Если да, то какие? Пишите в комментариях.
Forwarded from Data notes
#дипломный_проект
#data_preprocessing
Часть 1.
В уже далеком 2016 году, когда я учился на вечерке ВМК, я работалМЛ сервисным инженером: ремонтировал и апгрейдил инфузионные насосы. Это небольшие, но напичканные электроникой аппараты, которые используются для очень точного дозирования препаратов на длительном отрезке времени, т.е. делают этакий очень долгий “укол” каким-либо препаратом, например, вводят 1 мл препарата в течение суток с определенной скоростью. Я надеюсь, что вживую вы их никогда не видели и уж тем более вам не доводилось испытывать на себе их действие.
За 5 лет работы я переремонтировал более 1.5 тысяч аппаратов, поэтому прекрасно знал все особенности как поломок, так и клиентов, которыми являлись либо гос, либо частные клиники. В мои обязанности входило составление акта обследования неисправного аппарата, где указывались поломки, их причины, нужные для ремонта запчасти и итоговая стоимость. Акт высылался клиенту, а он уже либо соглашался на ремонт, либо отказывался, если цена слишком высока и проще купить новый аппарат. В случае согласия на ремонт я обращался в бухгалтерию для выставления счета на оплату, который отправлялся клиенту.
Так как отказы от ремонта были нередки из-за слишком высокой цены на ремонт, а за диагностику выбить деньги было очень непросто (косяки head of service engineering), то я подумал, что, задав всего несколько вопросов клиенту перед отправкой на диагностику, можно заранее оценить порядок стоимости ремонта и, если она будет довольно высокой, то сразу предупредить клиента, что ремонт нецелесообразен и проще купить новый аппарат. А если наоборот, предполагаемая цена будет низкой, можно сразу после диагностики идти просить выставить счет, чтобы не тратить время на ожидание согласования от клиента.
Так родилась идея первого моего проекта по анализу данных с применением ML.
#data_preprocessing
Часть 1.
В уже далеком 2016 году, когда я учился на вечерке ВМК, я работал
За 5 лет работы я переремонтировал более 1.5 тысяч аппаратов, поэтому прекрасно знал все особенности как поломок, так и клиентов, которыми являлись либо гос, либо частные клиники. В мои обязанности входило составление акта обследования неисправного аппарата, где указывались поломки, их причины, нужные для ремонта запчасти и итоговая стоимость. Акт высылался клиенту, а он уже либо соглашался на ремонт, либо отказывался, если цена слишком высока и проще купить новый аппарат. В случае согласия на ремонт я обращался в бухгалтерию для выставления счета на оплату, который отправлялся клиенту.
Так как отказы от ремонта были нередки из-за слишком высокой цены на ремонт, а за диагностику выбить деньги было очень непросто (косяки head of service engineering), то я подумал, что, задав всего несколько вопросов клиенту перед отправкой на диагностику, можно заранее оценить порядок стоимости ремонта и, если она будет довольно высокой, то сразу предупредить клиента, что ремонт нецелесообразен и проще купить новый аппарат. А если наоборот, предполагаемая цена будет низкой, можно сразу после диагностики идти просить выставить счет, чтобы не тратить время на ожидание согласования от клиента.
Так родилась идея первого моего проекта по анализу данных с применением ML.