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.
Forwarded from Data notes
Часть 2.
Обсудили с шефом, какие сценарии работы такой модели мы бы могли использовать в работе:
- Бинарная классификация: клиент согласится/не согласится ремонтировать аппарат
- Мультиклассовая классификация: низкая стоимость ремонта (делаем диагностику и сразу выставляем счет без согласования), средняя (делаем диагностику, но ждем подтверждения клиента о согласии на ремонт), высокая (прежде чем делать диагностику, говорим клиенту, что цена ремонта будет слишком высока и предлагаем вместо ремонта купить новый аппарат)
- Регрессия: модель прогнозирует саму стоимость ремонта
Что мы могли бы использовать как фичи для такой модели? Остановились на таком списке фичей, которые можно было бы узнать у клиента по телефону:
-
-
-
-
-
-
-
Чтобы решить, по какому из трех путей пойти, конечно же сначала нужно было проанализировать имеющиеся данные. А это оказалась та еще задачка: все акты хранились в SAP , из которого нельзя было просто взять и выгрузить Excel со всей нужной информацией. Можно было выгрузить акт, где указан сам клиент, дефекты, жалобы клиента, потенциальные причины поломки и цена ремонта с детализацией по отдельным работам и запчастям. Поскольку SAP дорабатывался двумя немцами, которые обслуживали всю Европу и РФ, то у них была полугодовая очередь даже на критически важные доработки. Поэтому рассчитывать на то, что они хотя бы поставят нас в очередь с сомнительным запросом для какого-то там ML, точно не стоило.
Поэтому я решил собрать все данные сам, и это оказалось очень непросто, но при этом увлекательно.
Обсудили с шефом, какие сценарии работы такой модели мы бы могли использовать в работе:
- Бинарная классификация: клиент согласится/не согласится ремонтировать аппарат
- Мультиклассовая классификация: низкая стоимость ремонта (делаем диагностику и сразу выставляем счет без согласования), средняя (делаем диагностику, но ждем подтверждения клиента о согласии на ремонт), высокая (прежде чем делать диагностику, говорим клиенту, что цена ремонта будет слишком высока и предлагаем вместо ремонта купить новый аппарат)
- Регрессия: модель прогнозирует саму стоимость ремонта
Что мы могли бы использовать как фичи для такой модели? Остановились на таком списке фичей, которые можно было бы узнать у клиента по телефону:
-
Сам клиент - отличная фича. Все учреждения по-разному обращаются с оборудованием-
Гос клиника или частная клиника: разница в отношении к оборудованию колоссальная! В российских гос больницах обычно подход “не мое - не жалко”, когда в частной у персонала просто вычитают стоимость ремонта из зарплат, если доказана его вина-
Серийный номер: чем он меньше, тем старше аппарат, тем больший износ у него. Плюс есть диапазоны номеров с известными дефектами в производстве, когда какой-то узел выходил из строя сильно быстрее.-
Тип поломки? Не качает, не горит экран, не включается вообще, не работает от батареи и прочие.-
После чего прибор перестал работать? Самые частые ответы здесь это: уронили, залили дезинфекционной жидкостью, перепад напряжения в сети, включили после долгого хранения на складе (прибор мог отсыреть и получить коррозию электронных плат) -
Пробовали ли ремонтировать самостоятельно? Да, это реальность РФ, когда в немецкий аппарат лезет больничный инженер, пытаясь заставить аппарат работать путем наколхоживания самодельных “запчастей” и тем самым сэкономить на ремонте. Так вот мало того, что по очевидным причинам категорически запрещено потом использовать в работе такой аппарат, так это еще зачастую увеличивало цену ремонта: стараясь починить самостоятельно, такие инженеры обычно доламывали то, что еще было исправно-
Был ли аппарат в ремонте ранее? Если да, то как давно? Это мы уже могли посмотреть в базе самостоятельно и здесь еще важно было уточнить, что в нем менялось - если менялся, например, главный привод (двигатель), то скорее всего в этот раз сломано что-то другое.Чтобы решить, по какому из трех путей пойти, конечно же сначала нужно было проанализировать имеющиеся данные. А это оказалась та еще задачка: все акты хранились в SAP , из которого нельзя было просто взять и выгрузить Excel со всей нужной информацией. Можно было выгрузить акт, где указан сам клиент, дефекты, жалобы клиента, потенциальные причины поломки и цена ремонта с детализацией по отдельным работам и запчастям. Поскольку SAP дорабатывался двумя немцами, которые обслуживали всю Европу и РФ, то у них была полугодовая очередь даже на критически важные доработки. Поэтому рассчитывать на то, что они хотя бы поставят нас в очередь с сомнительным запросом для какого-то там ML, точно не стоило.
Поэтому я решил собрать все данные сам, и это оказалось очень непросто, но при этом увлекательно.
Forwarded from Data notes
Часть 3.
Каким-то образом я добыл 6 тысяч номеров актов, имея номер акта можно было скачать PDF файл, причем только один за раз, процедура требовала одну минуту времени и десяток кликов мышкой. Поскольку у меня не было 6000 свободных минут, я написал автокликер, что-то вроде современного Selenium, который за несколько суток (не считая нескольких часов отладки, разумеется) скачал все нужные PDF файлы.
Далее нужно было вытащить инфу из PDF в текст. Нашел питоновский тул PDFminer, который решил эту задачу, сложил содержимое всех 6000 пдфок в один текстовый файл. Теперь предстояло при помощи магии регулярок распарсить все это добро и разложить в CSV по колонкам. Задача осложнялась довольно хаотичным расположением полей, которые нужно было идентифицировать (по сути, все, что было указано в нашем списке фичей + итоговая цена ремонта). Расположение зависело от порядка заполнения документа, например, сначала внесли дефекты, а потом их причины. Но могло быть и наоборот. В итоге полтора десятка if-else + столько же регулярок на питоне заработали после недели отладки, и долгожданный CSV был собран. Эх, вот бы тогда иметь AI-агентов, которые есть сегодня!
Анализ распределения цен ремонтов показал три четких кластера с низкой, средней и высокой ценой, причем в последнем из них высока была доля отказов от ремонта. В детали feature engineering вдаваться не буду, но там ничего необычного не было - все, можно сказать, по учебнику. Упомяну лишь, что пришлось приводить цены в рублях в цены в евро, т.к. мы все прекрасно знаем, что случилось в 2014 года с курсом рубля. Все перечисленные фичи были добавлены в логистическую регрессию для 3 классов, которая показала приемлемое качество и особенно хорошо отделяла последний, самый “дорогой” класс, что нам и было нужно.
Диплом был успешно защищен, а вот внедрение проекта не состоялось. Во-первых потому, что еще перед защитой я после 8 лет работы инженером нашел стажировку на позицию data scientist. А во-вторых, это уже была гораздо более трудная для меня на тот момент задача, требующая значительных изменений в порядке работы сервисного отдела. Однако, рассказ об этом проекте очень хорошо продавался на собеседованиях еще очень много лет! И поскольку на “добычу” и предобработку данных у меня суммарно ушло до 80% всего времени (я здесь не учитываю затраты на оформление проекта в дипломную работу) и только 20% на само моделирование, то с самого первого проекта я очень хорошо знаю, что подготовка данных зачастую важнее непосредственно моделирования.
Каким-то образом я добыл 6 тысяч номеров актов, имея номер акта можно было скачать PDF файл, причем только один за раз, процедура требовала одну минуту времени и десяток кликов мышкой. Поскольку у меня не было 6000 свободных минут, я написал автокликер, что-то вроде современного Selenium, который за несколько суток (не считая нескольких часов отладки, разумеется) скачал все нужные PDF файлы.
Далее нужно было вытащить инфу из PDF в текст. Нашел питоновский тул PDFminer, который решил эту задачу, сложил содержимое всех 6000 пдфок в один текстовый файл. Теперь предстояло при помощи магии регулярок распарсить все это добро и разложить в CSV по колонкам. Задача осложнялась довольно хаотичным расположением полей, которые нужно было идентифицировать (по сути, все, что было указано в нашем списке фичей + итоговая цена ремонта). Расположение зависело от порядка заполнения документа, например, сначала внесли дефекты, а потом их причины. Но могло быть и наоборот. В итоге полтора десятка if-else + столько же регулярок на питоне заработали после недели отладки, и долгожданный CSV был собран. Эх, вот бы тогда иметь AI-агентов, которые есть сегодня!
Анализ распределения цен ремонтов показал три четких кластера с низкой, средней и высокой ценой, причем в последнем из них высока была доля отказов от ремонта. В детали feature engineering вдаваться не буду, но там ничего необычного не было - все, можно сказать, по учебнику. Упомяну лишь, что пришлось приводить цены в рублях в цены в евро, т.к. мы все прекрасно знаем, что случилось в 2014 года с курсом рубля. Все перечисленные фичи были добавлены в логистическую регрессию для 3 классов, которая показала приемлемое качество и особенно хорошо отделяла последний, самый “дорогой” класс, что нам и было нужно.
Диплом был успешно защищен, а вот внедрение проекта не состоялось. Во-первых потому, что еще перед защитой я после 8 лет работы инженером нашел стажировку на позицию data scientist. А во-вторых, это уже была гораздо более трудная для меня на тот момент задача, требующая значительных изменений в порядке работы сервисного отдела. Однако, рассказ об этом проекте очень хорошо продавался на собеседованиях еще очень много лет! И поскольку на “добычу” и предобработку данных у меня суммарно ушло до 80% всего времени (я здесь не учитываю затраты на оформление проекта в дипломную работу) и только 20% на само моделирование, то с самого первого проекта я очень хорошо знаю, что подготовка данных зачастую важнее непосредственно моделирования.
Forwarded from Coder Doesn’t Know (Yakov Shmidt)
Пожалуй, это лучшая иллюстрация про Apache Kafka для маленьких и не только 🤩
https://www.gentlydownthe.stream/
https://www.gentlydownthe.stream/
Please open Telegram to view this post
VIEW IN TELEGRAM