Forwarded from я обучала одну модель
Хочется еще упомянуть несколько важных свойств автоэнкодеров, которые авторы обнаружили в статье
– У фичей есть своя геометрическая структура, где похожия фичи оказываются близки к друг другу (что ожидаемо). Например, Золотые Ворота близки ко всем остальным достопримечательностям СФ, а отдаленно они связаны с другими популярными местами, типа статуи Иисуса в Рио-де-Жанейро
– Одинаковые фичи оказываются близки в автоэнкодерах всех размеров. Различие между ними в том, что в больших экодерах происходит feature splitting – если в маленькой модели мы найдем какое-то общее понятие, то в больших модель оно разобъется на что-то более конкретное. Вот тут есть интерактивный UMAP
– Нашелся также и scaling law:
Если концепт появляется один раз на миллиард токенов, то нам нужно пропорционально миллиарду активных фич в SAE, чтобы найти ту, которая бы уникально описывала этот концепт
– Для 82% фичей не нашлось сильно скоррелированных нейронов
– Хотя SAE тренировались только на тексте, они оказались способны реагировать и на картинки!
– Фичи отвечают как за абстрактные, так и за конкретные концепты. Например, одна и та же фича активируется на общие рассуждение о безопасности кода, и на конкретные примеры такого кода
– Если модели нужны промежуточные размышления, то активируются фичи, которые отвечают за “пропущенный концепт”. На конкретном примере: если модели нужно ответить на вопрос “Кто был главным соперником команды, в которой играл Коби Брайант”, то больше всего на финальный ответ “Boston Celtics” будут влиять фичи “Коби Брайант” -> его команда “Los Angeles Lakers” (пропущенный концепт) -> фича, отвечающая за спортивные противостояния. Я обожаю, когда в статьях такое находят! По-моему это отличная ответчочка на мнение, что LLM это стохастические попугаи и не понимают, что они генерируют
Спасибо, что дочитали этот лонгрид! Мне очень понравилась статья, и если вас тоже заинтриговала тема mechanistic interpretability, авторы предалагют вот этот гайд: https://neelnanda.io/mechanistic-interpretability/getting-started
– У фичей есть своя геометрическая структура, где похожия фичи оказываются близки к друг другу (что ожидаемо). Например, Золотые Ворота близки ко всем остальным достопримечательностям СФ, а отдаленно они связаны с другими популярными местами, типа статуи Иисуса в Рио-де-Жанейро
– Одинаковые фичи оказываются близки в автоэнкодерах всех размеров. Различие между ними в том, что в больших экодерах происходит feature splitting – если в маленькой модели мы найдем какое-то общее понятие, то в больших модель оно разобъется на что-то более конкретное. Вот тут есть интерактивный UMAP
– Нашелся также и scaling law:
Если концепт появляется один раз на миллиард токенов, то нам нужно пропорционально миллиарду активных фич в SAE, чтобы найти ту, которая бы уникально описывала этот концепт
– Для 82% фичей не нашлось сильно скоррелированных нейронов
– Хотя SAE тренировались только на тексте, они оказались способны реагировать и на картинки!
– Фичи отвечают как за абстрактные, так и за конкретные концепты. Например, одна и та же фича активируется на общие рассуждение о безопасности кода, и на конкретные примеры такого кода
– Если модели нужны промежуточные размышления, то активируются фичи, которые отвечают за “пропущенный концепт”. На конкретном примере: если модели нужно ответить на вопрос “Кто был главным соперником команды, в которой играл Коби Брайант”, то больше всего на финальный ответ “Boston Celtics” будут влиять фичи “Коби Брайант” -> его команда “Los Angeles Lakers” (пропущенный концепт) -> фича, отвечающая за спортивные противостояния. Я обожаю, когда в статьях такое находят! По-моему это отличная ответчочка на мнение, что LLM это стохастические попугаи и не понимают, что они генерируют
Спасибо, что дочитали этот лонгрид! Мне очень понравилась статья, и если вас тоже заинтриговала тема mechanistic interpretability, авторы предалагют вот этот гайд: https://neelnanda.io/mechanistic-interpretability/getting-started
Forwarded from gonzo-обзоры ML статей
You Only Cache Once: Decoder-Decoder Architectures for Language Models
Yutao Sun, Li Dong, Yi Zhu, Shaohan Huang, Wenhui Wang, Shuming Ma, Quanlu Zhang, Jianyong Wang, Furu Wei
Статья: https://arxiv.org/abs/2405.05254
Код: https://github.com/microsoft/unilm/tree/master/YOCO
Архитектурные новости. Авторы придумали архитектуру для LLM под названием decoder-decoder.
Напомним, что оригинальный трансформер (и например модели типа T5) был построен на полной архитектуре encoder-decoder, большая часть современных LLM (типа GPT) используют только decoder, и другая популярная ветка недавнего прошлого (модели семейства BERT) состоит только из encoder. Энкодер всегда был двунаправленным (bidirectional) и модели с таким двунаправленным компонентом (то есть encoder и encoder-decoder) имели проблемы с авторегрессионной генерацией — там для генерации нового токена сначала надо было заэнкодить всю последовательность из входа и уже нагенерённой части выхода. Можно конечно использовать только декодерную часть для генерации, но тогда сгенерённые токены не используют на полную мощь параметры энкодера. У decoder тут всё неплохо, при авторегрессионной генерации можно закешировать вектора KV (key и value в блоках внимания) и переиспользовать для генерации нового токена, не надо заново кодировать всю историю.
Но как говорится в сказании о Савитри, “есть один недостаток”. KV-кэш очень пухнет при росте длины генерируемой последовательности, он отжирает кучу памяти GPU и LLM-ки становятся memory-bound. Так для 65B модели (с grouped-query attention и квантизацией KV в 8 бит) для 512k токенов нужно 86Gb памяти, что перекрывает объём памяти H100-80GB. К тому же фаза prefill (см тут или хороший обзор тут), в которой надо обработать все входные токены промпта и вычислить для них значения KV, может занимать сотни секунд для очень длинных входов типа 1М (здесь, кстати, интересно, что Гугл с Gemini 1.5 придумал).
Весь трансформер из L слоёв разделяется поровну и первые L/2 слоёв реализуют self-decoder через efficient self-attention. Размер KV-кеша этой части константен, то есть O(1). Выход последнего слоя self-decoder даёт глобальный KV-кеш, куда ходит вторая половина, cross-decoder, реализованная через оставшиеся L/2 слоёв. Каждый блок получает на вход Q и через cross-attention идёт в этот глобальный KV-кеш. Здесь уже везде стандартное (почти, с GQA, https://arxiv.org/abs/2305.13245) multi-head attention с полным окном.
Под efficient self-attention в self-decoder авторы подразумевают sliding-window attention как в старом добром sparse transformer имени Ильи Суцкевера и ко (https://www.group-telegram.com/gonzo_ML/65). Как вариант, вместо него в self-decoder может использоваться RetNet (https://www.group-telegram.com/gonzo_ML/1753) под названием gRet (aka gRetNet или RetNet-3) с data-dependent гейтингом. Вроде бы такой же мы и разбирали когда-то давно в оригинальной статье.
В остальном блоки в этих слоях в целом стандартные, чередование внимания и FFN, с использованием pre-RMSNorm, SwiGLU, GQA.
Полученная архитектура называется YOCO (You Only Cache Once, так понимаю тут речь про кеширование в L/2 слое). Это всё похоже на encoder-decoder, но снаружи выглядит как декодер и обе части используют causal masking.
YOCO эффективнее обычного трансформера за счёт меньших требований к памяти, кеш для длинных последовательностей скейлится как O(N) вместо O(NL), то есть можно делать больше инференса и/или с более крупными батчами (что повышает throughput).
Ещё из интересных свойств YOCO есть то, что во время стадии prefill можно сделать early exit и не ходить в cross-decoder, это повышает скорость данной фазы. Поскольку в self-decoder находится половина слоёв, то это уже сокращение вычислений и времени в два раза. К тому же эффективная реализация внимания в self-decoder обычно быстра. Они приводят пример запроса с размером контекста в 512K, на котором prefill latency падает со 180 секунд (трансформер с flash-decoding и kernel fusion) до менее 6 секунд. И даже на длине 32K YOCO всё равно в три раза быстрее (на этой фазе, а не в целом end-to-end).
Yutao Sun, Li Dong, Yi Zhu, Shaohan Huang, Wenhui Wang, Shuming Ma, Quanlu Zhang, Jianyong Wang, Furu Wei
Статья: https://arxiv.org/abs/2405.05254
Код: https://github.com/microsoft/unilm/tree/master/YOCO
Архитектурные новости. Авторы придумали архитектуру для LLM под названием decoder-decoder.
Напомним, что оригинальный трансформер (и например модели типа T5) был построен на полной архитектуре encoder-decoder, большая часть современных LLM (типа GPT) используют только decoder, и другая популярная ветка недавнего прошлого (модели семейства BERT) состоит только из encoder. Энкодер всегда был двунаправленным (bidirectional) и модели с таким двунаправленным компонентом (то есть encoder и encoder-decoder) имели проблемы с авторегрессионной генерацией — там для генерации нового токена сначала надо было заэнкодить всю последовательность из входа и уже нагенерённой части выхода. Можно конечно использовать только декодерную часть для генерации, но тогда сгенерённые токены не используют на полную мощь параметры энкодера. У decoder тут всё неплохо, при авторегрессионной генерации можно закешировать вектора KV (key и value в блоках внимания) и переиспользовать для генерации нового токена, не надо заново кодировать всю историю.
Но как говорится в сказании о Савитри, “есть один недостаток”. KV-кэш очень пухнет при росте длины генерируемой последовательности, он отжирает кучу памяти GPU и LLM-ки становятся memory-bound. Так для 65B модели (с grouped-query attention и квантизацией KV в 8 бит) для 512k токенов нужно 86Gb памяти, что перекрывает объём памяти H100-80GB. К тому же фаза prefill (см тут или хороший обзор тут), в которой надо обработать все входные токены промпта и вычислить для них значения KV, может занимать сотни секунд для очень длинных входов типа 1М (здесь, кстати, интересно, что Гугл с Gemini 1.5 придумал).
Весь трансформер из L слоёв разделяется поровну и первые L/2 слоёв реализуют self-decoder через efficient self-attention. Размер KV-кеша этой части константен, то есть O(1). Выход последнего слоя self-decoder даёт глобальный KV-кеш, куда ходит вторая половина, cross-decoder, реализованная через оставшиеся L/2 слоёв. Каждый блок получает на вход Q и через cross-attention идёт в этот глобальный KV-кеш. Здесь уже везде стандартное (почти, с GQA, https://arxiv.org/abs/2305.13245) multi-head attention с полным окном.
Под efficient self-attention в self-decoder авторы подразумевают sliding-window attention как в старом добром sparse transformer имени Ильи Суцкевера и ко (https://www.group-telegram.com/gonzo_ML/65). Как вариант, вместо него в self-decoder может использоваться RetNet (https://www.group-telegram.com/gonzo_ML/1753) под названием gRet (aka gRetNet или RetNet-3) с data-dependent гейтингом. Вроде бы такой же мы и разбирали когда-то давно в оригинальной статье.
В остальном блоки в этих слоях в целом стандартные, чередование внимания и FFN, с использованием pre-RMSNorm, SwiGLU, GQA.
Полученная архитектура называется YOCO (You Only Cache Once, так понимаю тут речь про кеширование в L/2 слое). Это всё похоже на encoder-decoder, но снаружи выглядит как декодер и обе части используют causal masking.
YOCO эффективнее обычного трансформера за счёт меньших требований к памяти, кеш для длинных последовательностей скейлится как O(N) вместо O(NL), то есть можно делать больше инференса и/или с более крупными батчами (что повышает throughput).
Ещё из интересных свойств YOCO есть то, что во время стадии prefill можно сделать early exit и не ходить в cross-decoder, это повышает скорость данной фазы. Поскольку в self-decoder находится половина слоёв, то это уже сокращение вычислений и времени в два раза. К тому же эффективная реализация внимания в self-decoder обычно быстра. Они приводят пример запроса с размером контекста в 512K, на котором prefill latency падает со 180 секунд (трансформер с flash-decoding и kernel fusion) до менее 6 секунд. И даже на длине 32K YOCO всё равно в три раза быстрее (на этой фазе, а не в целом end-to-end).
Скоро я в коллаборации с Vikhrmodels релизну русскую general арену (на основе кода Arena-Hard-Auto. А еще готовлю несколько других крупных 🤗 релизов и статей (хабровских)...
А пока вам текущий стейт со всеми лучшими опенсорс (и не только моделями)
Датасет использованных русских промптов (500 штук), уже выложен и доступен по ссылке
P.S. Скоро восстановлю ведение канала, были не очень приятные обстоятельства для его ведения...
А пока вам текущий стейт со всеми лучшими опенсорс (и не только моделями)
Датасет использованных русских промптов (500 штук), уже выложен и доступен по ссылке
GrandMaster-PRO-MAX - Первый крупный высококачественный русскоязычный SFT датасет
Совместно с Vikhrmodels, представляю вам датасет для инструктивного обучения LLM полученный не с помощью переводов ответов моделей с английского языка. Он диверсифицирован по темам и позволяет моделям следовать самым разным инструкциям на разных языках (в основном на русском) и отвечать, так же, в основном на русском языке.
Ответы за ассистента в этом датасете полностью сгенерированы GPT-4-Turbo-1106 с нуля по исходным инструкциям от пользователя. Это позволило получить очень качественный русский язык в ответах без артефактов перевода. Исходные инструкции были взяты из различных источников, в том числе синтетических для подкрепления отдельных способностей вроде математики, программирования, следования формату и тд.
Кроме того, характерной особенностью является то, что модели обученные на этом датасете будут иметь уже "вшитую" способность к Chain-Of-Thought (CoT), за счет использования более сложного промпта для генерации большинства ответов (подробнее в карточке датасета).
Содержит примерно 142 тысячи уникальных пар инструкция - ответ. Денежный эквивалент генерации такого датасета с нуля - около 4к долларов.
Совместно с Vikhrmodels, представляю вам датасет для инструктивного обучения LLM полученный не с помощью переводов ответов моделей с английского языка. Он диверсифицирован по темам и позволяет моделям следовать самым разным инструкциям на разных языках (в основном на русском) и отвечать, так же, в основном на русском языке.
Ответы за ассистента в этом датасете полностью сгенерированы GPT-4-Turbo-1106 с нуля по исходным инструкциям от пользователя. Это позволило получить очень качественный русский язык в ответах без артефактов перевода. Исходные инструкции были взяты из различных источников, в том числе синтетических для подкрепления отдельных способностей вроде математики, программирования, следования формату и тд.
Кроме того, характерной особенностью является то, что модели обученные на этом датасете будут иметь уже "вшитую" способность к Chain-Of-Thought (CoT), за счет использования более сложного промпта для генерации большинства ответов (подробнее в карточке датасета).
Содержит примерно 142 тысячи уникальных пар инструкция - ответ. Денежный эквивалент генерации такого датасета с нуля - около 4к долларов.
huggingface.co
Vikhrmodels/GrandMaster-PRO-MAX · Datasets at Hugging Face
We’re on a journey to advance and democratize artificial intelligence through open source and open science.
NLP Wanderer
GrandMaster-PRO-MAX - Первый крупный высококачественный русскоязычный SFT датасет Совместно с Vikhrmodels, представляю вам датасет для инструктивного обучения LLM полученный не с помощью переводов ответов моделей с английского языка. Он диверсифицирован по…
Провел работу над ошибками, на которые мне указал @YallenGusev.
- Сделал дедубликацию с помощью e5 поверх всего датасета
- Добавил информацию о языках в промптах и ответах
- Добавил датасет системных промптов abacusai/SystemChat-1.1 - следовательно модели обученные на таком датасете смогут и с ним работать
- Добавил пофильтрованные промпты из переведенного d0rj/OpenHermes-2.5-ru
- Улучшил пайплайны фильтрации и постобработки промптов и ответов
Все так же, из всех новых датасетов я беру только промпты и генерирую ответы заного используя промпты-надстройки для управления качеством и языком ответа. Больше подробностей в карточке датасета.
Итого получилось 119398 пар, меньше, чем было изначально, зато куда более чистые. Датасет будет пополнятся и дальше, цель - 200к с большим количеством сильно диверсифицированных русских и английских промптов.
- Сделал дедубликацию с помощью e5 поверх всего датасета
- Добавил информацию о языках в промптах и ответах
- Добавил датасет системных промптов abacusai/SystemChat-1.1 - следовательно модели обученные на таком датасете смогут и с ним работать
- Добавил пофильтрованные промпты из переведенного d0rj/OpenHermes-2.5-ru
- Улучшил пайплайны фильтрации и постобработки промптов и ответов
Все так же, из всех новых датасетов я беру только промпты и генерирую ответы заного используя промпты-надстройки для управления качеством и языком ответа. Больше подробностей в карточке датасета.
Итого получилось 119398 пар, меньше, чем было изначально, зато куда более чистые. Датасет будет пополнятся и дальше, цель - 200к с большим количеством сильно диверсифицированных русских и английских промптов.
Лидерборд (со всеми вердиктами по каждой модели) и код для нашей русской офлайн LLM Арены вы можете найти тут, подробнее про ее фичи и как она работает, расскажу чуть позже (но в README уже почти все описано)
P.S. По ней кстати получается, что GPT-4o-mini хуже, чем GPT-4-Turbo, в отличие от онлайн арены 😏
P.S. По ней кстати получается, что GPT-4o-mini хуже, чем GPT-4-Turbo, в отличие от онлайн арены 😏
GitHub
GitHub - VikhrModels/ru_llm_arena: Modified Arena-Hard-Auto LLM evaluation toolkit with an emphasis on Russian language
Modified Arena-Hard-Auto LLM evaluation toolkit with an emphasis on Russian language - VikhrModels/ru_llm_arena
Про истоки и различия методов алайнмента LLM и SimPO
На картинке вы можете увидеть основные различия в текущих наиболее известных подходах к офлайн оптимизации преференсов из недавней статьи метода SimPO, который меня и вдохновил написать этот пост.
Давайте посмотрим, что вобще тут является основными элементами:
1. Логарифм сигмойды - это прямое следствие из модели Bradley-Terry, согласно ей все выражение это логарифм вероятности превосходства chosen ответа над rejected ответом, абсолютно та же логика используется в обучении отдельных Reward моделей. Логарифм появляется по той же причине по которой он есть в Log Loss - мы конструируем функцию максимального правдоподобия.
2. Самое важное во всех этих методах - оценка разницы наград за ответ, которая находится обычно внутри логарифма сигмойды.
Основная идея фундаментального здесь метода DPO - выражать функцию награды (в онлайн RLHF это отдельная Reward модель) через политику LLM (условно политикой тут называется вероятность генерации ответов в зависимости от весов модели, т.е. перемноженная вероятность всех сгенерированных токенов). В DPO их сразу две - оригинальная после SFT тюна (она же ref) и текущая поверх этого SFT тюна. Сама разница наград представлена как разница логпроба хорошего ответа и логпроба плохого ответа.
Главное тут понимать, почему вобще мы что-то вычитаем и откуда это берется. Ответ кроется снова в модели Bradley-Terry, на самом деле модель BT это функция Softmax оценивающая вероятность P(chosen>rejected), с ее хараткерным видом дроби, в двумерном случае мы можем просто переписать ее так, чтобы числитель был равен 1, а снизу получится как раз 1+exp(разница двух ревардов), тоесть получили обычный вид сигмойды в частном случае. Логпробы ответов же являются логитами после применения функции log_softmax для удобства их перемножения (можем просто суммировать логарифмы). Подробнее про общую математику преференс обучения и как она связана с теорией игр можно прочитать в статье еще одного интересного метода, про который я расскажу позже.
Допустим это все понятно, а тогда зачем нам столько методов и как они получаются?
Чаще всего авторы новых методов говорят о неоптимальности классического DPO с разных точек зрения. Например, то что за счет учета референсной модели он становится вычислительно тяжелым (нужно держать 2 модели в памяти), а еще делает не то что от него на самом деле хотят - не оптимизирует политику генерации ответов, а несколько другую политику связаную с референсой моделью. Кроме того изза своей офлайн природы этот метод довольно легко переобучается и часто плохо коррелирует с SbS бенчмарками, а если и коррелирует то засчет отсутствия встроенного штрафа за длинные ответы. Некоторые авторы также говорят о том, что DPO не закладывает margin между плохими и хорошими ответами, что так же портит общий результат. Да и вобще DPO требует предварительного SFT тюна, что некоторые авторы также находят неоптимальным. Если суммаризировать претензии - DPO вовсе не является полностью надежным методом алайнмента, несмотря на свою сильную математическую базу и все новые методы так или иначе пытаются развивать его идеи, чтобы лечить перечисленные проблемы.
Про все альтернативы я рассказывать не буду, про них вы можете почитать например тут, расскажу немного только про ту, которая судя по всему доказала что действительно имеет сильные преимущества над DPO, а именно - SimPO.
Метод состоит из простых трех вещей: он удаляет референсную модель из обучения и добавляет штраф на длину ответа, кроме того он вводит margin внутри Bradley-Terry, который становится гиперпараметром. Сами авторы говорят, что их метод является частным случаем обобщенного фреймворка алайнмента представленного DeepMind - GPO, как собственно и многие другие оффлайн методы.
Эмпирически SimPO показывает лучшие результаты среди всех остальных методов на разных SbS бенчмарках, включая бенчмарки со штрафом на длину (в комментариях будет табличка). Авторы сделали простой и удобный репозиторий с кодом и провели большое количество экспериментов, а также опубликовали все свои модели и датасеты.
На картинке вы можете увидеть основные различия в текущих наиболее известных подходах к офлайн оптимизации преференсов из недавней статьи метода SimPO, который меня и вдохновил написать этот пост.
Давайте посмотрим, что вобще тут является основными элементами:
1. Логарифм сигмойды - это прямое следствие из модели Bradley-Terry, согласно ей все выражение это логарифм вероятности превосходства chosen ответа над rejected ответом, абсолютно та же логика используется в обучении отдельных Reward моделей. Логарифм появляется по той же причине по которой он есть в Log Loss - мы конструируем функцию максимального правдоподобия.
2. Самое важное во всех этих методах - оценка разницы наград за ответ, которая находится обычно внутри логарифма сигмойды.
Основная идея фундаментального здесь метода DPO - выражать функцию награды (в онлайн RLHF это отдельная Reward модель) через политику LLM (условно политикой тут называется вероятность генерации ответов в зависимости от весов модели, т.е. перемноженная вероятность всех сгенерированных токенов). В DPO их сразу две - оригинальная после SFT тюна (она же ref) и текущая поверх этого SFT тюна. Сама разница наград представлена как разница логпроба хорошего ответа и логпроба плохого ответа.
Главное тут понимать, почему вобще мы что-то вычитаем и откуда это берется. Ответ кроется снова в модели Bradley-Terry, на самом деле модель BT это функция Softmax оценивающая вероятность P(chosen>rejected), с ее хараткерным видом дроби, в двумерном случае мы можем просто переписать ее так, чтобы числитель был равен 1, а снизу получится как раз 1+exp(разница двух ревардов), тоесть получили обычный вид сигмойды в частном случае. Логпробы ответов же являются логитами после применения функции log_softmax для удобства их перемножения (можем просто суммировать логарифмы). Подробнее про общую математику преференс обучения и как она связана с теорией игр можно прочитать в статье еще одного интересного метода, про который я расскажу позже.
Допустим это все понятно, а тогда зачем нам столько методов и как они получаются?
Чаще всего авторы новых методов говорят о неоптимальности классического DPO с разных точек зрения. Например, то что за счет учета референсной модели он становится вычислительно тяжелым (нужно держать 2 модели в памяти), а еще делает не то что от него на самом деле хотят - не оптимизирует политику генерации ответов, а несколько другую политику связаную с референсой моделью. Кроме того изза своей офлайн природы этот метод довольно легко переобучается и часто плохо коррелирует с SbS бенчмарками, а если и коррелирует то засчет отсутствия встроенного штрафа за длинные ответы. Некоторые авторы также говорят о том, что DPO не закладывает margin между плохими и хорошими ответами, что так же портит общий результат. Да и вобще DPO требует предварительного SFT тюна, что некоторые авторы также находят неоптимальным. Если суммаризировать претензии - DPO вовсе не является полностью надежным методом алайнмента, несмотря на свою сильную математическую базу и все новые методы так или иначе пытаются развивать его идеи, чтобы лечить перечисленные проблемы.
Про все альтернативы я рассказывать не буду, про них вы можете почитать например тут, расскажу немного только про ту, которая судя по всему доказала что действительно имеет сильные преимущества над DPO, а именно - SimPO.
Метод состоит из простых трех вещей: он удаляет референсную модель из обучения и добавляет штраф на длину ответа, кроме того он вводит margin внутри Bradley-Terry, который становится гиперпараметром. Сами авторы говорят, что их метод является частным случаем обобщенного фреймворка алайнмента представленного DeepMind - GPO, как собственно и многие другие оффлайн методы.
Эмпирически SimPO показывает лучшие результаты среди всех остальных методов на разных SbS бенчмарках, включая бенчмарки со штрафом на длину (в комментариях будет табличка). Авторы сделали простой и удобный репозиторий с кодом и провели большое количество экспериментов, а также опубликовали все свои модели и датасеты.
Немного про подходы к RAG: GraphRAG
Одна из самых для меня интересных тем это различные RAG архитектуры и техники. Недавно было создано немалое их количество. На мой взгляд, среди самых значимых:
- Разные способы нарезки чанков (посимвольный, семантический, структурный, ...)
- Извлечение всяческой метадаты из них и автоматический ретривал по ней
- Иерархический автомерджинг чанков
- Умное сжатие найденой информации (контекутальная компрессия)
- Всевозможные способы переписывания запроса (HyDE, Multi-Query, ...)
- Рекурсивный ретривал (с суммаризацией или агентами)
- Гибридные поиски с BM или colbert
- Саморефлексирующиеся системы
- И наконец даже end2end тренировка
Все эти новвоведения, во многом связаны с тем, что создатели метода GraphRAG (Microsoft) назвали проблемой локального и глобального поиска, которой страдает RAG в классическом варианте. Концептуально, это означает, что существует очень большое количество типов вопросов которые пользователь может задать о документе (от очень конкретных до очень абстрактных), при этом большинство RAG систем будут готовы ответить только на довольно конкретные вопросы и не знать информацию о датасете в целом. Представленый же авторами подход можно назвать некоторым обобщением и революцией в том как лучше делать RAG.
Сам GraphRAG глобально можно разделить на фазу подготовки данных и на фазу инференса запросов и все это в несколько этапов:
1. Дробим входные документы, разбив текста на чанки по (300-1200 символов)
2. С помошью LLM извлекаем из текстов триплеты (entity, entity, тип relationship), а также "claims" - дополнительные факты из текста (но тут я этот момент опущу)
3. Сохраняем их в графовую базу со всякой сопуствующей метадатой, например Neo4j, получив общий граф знаний всех наших чанков и документов.
4. Выделяем сообщества внутри общего графа, с помошью Hierarchical Leiden Algorithm
5. Для каждого сообщества создаем так называемые Community Reports с помошью той же LLM, а также их суммаризации для упрощения, так же делаются текстовые эмбединги этих суммаризацией
6. Дополнительно для каждого документа текста тоже создается эмбединг путем усреднения текстовых эмбедингов его чанков.
Дальше инференс (он немного отличается для Local и Global поиска, но логика почти одинаковая):
7. Имея запрос, выделяем из него сущности с помощью LLM, находим их в графовой бд и соотвествующие им Community Reports, описание связей и сами текста чанков.
8. Имея всю эту информацию + историю общения, фильтруем все найденое с помошью еще одного LLM запроса на релевантность и только после этого всю сводную информацию отправляем снова в LLM для финального ответа.
Если проанализировать, то основной целью всех этапов было максимизировать этап предобработки документов, используя мощь быстрых LLM, который обычно в RAG представлял из себя только нарезку, чистку и превращение в эмбединги.
Концептуально, авторы как будто выделяют всю возможную немусорную информацию из текста и аккуратно скармливают ее на ложечке LLM для получения ответа на нужный вопрос. При этом они также дают модели, то что отчасти раньше делали контекстуальная компрессия и автомерджинг - общее понимание темы вопроса из всего документа, так как графовый поиск не ограничивается информацией стоящей в тексте рядом и может переходить по ссылкам.
Теперь моя субъективная оценка: Глобально, мы видим развитие идей суммаризации информации и построение chunk-chunk связей, тогда как обычный RAG работает в основном с query-chunk связями. На мой взгляд, авторы молодцы, но очень сильно перестарались, и получилось крайне много полаганий на работу LLM, она очень часто вызывается даже на этапе инференса, что во многих реальных приложениях просто недопустимо да и конечно будет очень часто подводить. Я же не рекомендую тащить такие штуки в прод, а лишь лучше изучить применение контекстуальной компрессии и извлечения фактов и связей из документов с помошью LLM на этапе предобработки данных и конечно же посмотреть на код, статью и блогпост.
Одна из самых для меня интересных тем это различные RAG архитектуры и техники. Недавно было создано немалое их количество. На мой взгляд, среди самых значимых:
- Разные способы нарезки чанков (посимвольный, семантический, структурный, ...)
- Извлечение всяческой метадаты из них и автоматический ретривал по ней
- Иерархический автомерджинг чанков
- Умное сжатие найденой информации (контекутальная компрессия)
- Всевозможные способы переписывания запроса (HyDE, Multi-Query, ...)
- Рекурсивный ретривал (с суммаризацией или агентами)
- Гибридные поиски с BM или colbert
- Саморефлексирующиеся системы
- И наконец даже end2end тренировка
Все эти новвоведения, во многом связаны с тем, что создатели метода GraphRAG (Microsoft) назвали проблемой локального и глобального поиска, которой страдает RAG в классическом варианте. Концептуально, это означает, что существует очень большое количество типов вопросов которые пользователь может задать о документе (от очень конкретных до очень абстрактных), при этом большинство RAG систем будут готовы ответить только на довольно конкретные вопросы и не знать информацию о датасете в целом. Представленый же авторами подход можно назвать некоторым обобщением и революцией в том как лучше делать RAG.
Сам GraphRAG глобально можно разделить на фазу подготовки данных и на фазу инференса запросов и все это в несколько этапов:
1. Дробим входные документы, разбив текста на чанки по (300-1200 символов)
2. С помошью LLM извлекаем из текстов триплеты (entity, entity, тип relationship), а также "claims" - дополнительные факты из текста (но тут я этот момент опущу)
3. Сохраняем их в графовую базу со всякой сопуствующей метадатой, например Neo4j, получив общий граф знаний всех наших чанков и документов.
4. Выделяем сообщества внутри общего графа, с помошью Hierarchical Leiden Algorithm
5. Для каждого сообщества создаем так называемые Community Reports с помошью той же LLM, а также их суммаризации для упрощения, так же делаются текстовые эмбединги этих суммаризацией
6. Дополнительно для каждого документа текста тоже создается эмбединг путем усреднения текстовых эмбедингов его чанков.
Дальше инференс (он немного отличается для Local и Global поиска, но логика почти одинаковая):
7. Имея запрос, выделяем из него сущности с помощью LLM, находим их в графовой бд и соотвествующие им Community Reports, описание связей и сами текста чанков.
8. Имея всю эту информацию + историю общения, фильтруем все найденое с помошью еще одного LLM запроса на релевантность и только после этого всю сводную информацию отправляем снова в LLM для финального ответа.
Если проанализировать, то основной целью всех этапов было максимизировать этап предобработки документов, используя мощь быстрых LLM, который обычно в RAG представлял из себя только нарезку, чистку и превращение в эмбединги.
Концептуально, авторы как будто выделяют всю возможную немусорную информацию из текста и аккуратно скармливают ее на ложечке LLM для получения ответа на нужный вопрос. При этом они также дают модели, то что отчасти раньше делали контекстуальная компрессия и автомерджинг - общее понимание темы вопроса из всего документа, так как графовый поиск не ограничивается информацией стоящей в тексте рядом и может переходить по ссылкам.
Теперь моя субъективная оценка: Глобально, мы видим развитие идей суммаризации информации и построение chunk-chunk связей, тогда как обычный RAG работает в основном с query-chunk связями. На мой взгляд, авторы молодцы, но очень сильно перестарались, и получилось крайне много полаганий на работу LLM, она очень часто вызывается даже на этапе инференса, что во многих реальных приложениях просто недопустимо да и конечно будет очень часто подводить. Я же не рекомендую тащить такие штуки в прод, а лишь лучше изучить применение контекстуальной компрессии и извлечения фактов и связей из документов с помошью LLM на этапе предобработки данных и конечно же посмотреть на код, статью и блогпост.
Немного мыслей о новой модели O1 от OpenAI ✨
Что произошло: представленная вчера модель OpenAI теперь самостоятельно генерирует скрытые размышления и при составлении финального ответа на вопрос пользователя (который он видит), использует их для генерации и исправления собственных ошибок.
На удивление, при всех заявлениях СМИ о революционности этой модели, подход является абсолютно стандартным в LLM, на который довольно часто полагаются и сам релиз был вполне даже логичен и ожидаем. Ближайший аналог тому, что мы увидели - обычный промпт-инжинириг, в частности можно взять CoT (Chain-Of-Thought) в разных вариациях. Например, пользователи ChatGPT давно поняли, что если модель попросить хорошенько подумать, пообещать ей "денег" и тд, то она отвечает лучше. Кроме того, концепция ICL (In-Context Learning) предлагает показывать примеры ответов на вопросы в промпте, чтобы модель училась им следовать и улучшала свои ответы. А еще я упускаю такие штуки из этой же области как ReAсt который сильно схож с тем, что нам представили.
Вобще, было очень много работ и даже релизов на тему "переноса" умения работать со знаниями из этапа предобучения в этап инференса модели. Одним из самых интересных является недавняя победа опенсорс 7b модельки NuminaMath на Kaggle соревновании AIMO, где она решила 29 из 50 реальных задач из международной олимпиады по математике (IMO). А также статья от DeepMind о их модели AlphaProof которая получила серебряную медаль на уже реальных задачах IMO 2024. Самым громким и довольно спорным, но не менее интригующим стал релиз опенсорс модели Reflection-70B, которая довольна схожа с o1 по своему поведению, она умеет генерировать скрытые размышления со спец. токенами и давать финальный ответ на их основе. Все эти модели так или иначе полагаются как на знания заложенные в весах на этапе обучения так и на свои генерации во время инференса, при этом оба этапа являются крайне важными для достижения таких результатов.
Подробнее об этой концепции можно почитать в одних из первых статей на эту тему - CoT, ToRA, блогпост epochai про флопсы и качество, и в недавней статье от Google, очень хорошо исследующей test-time compute подходы в глубь, как минимум часть 5 и 7 этой статьи я советую прочитать из-за множества интересных выводов, на которых отчасти будет базироваться мое следующее утверждение.
Мне очень интересен этот процесс ухода от исключительно претрейна в сторону ризонинг-алайнмента моделей и перекладывания части ИИ компьюта на инференс и я вижу, что в нем сейчас есть реальное будущее из-за существующих на данный момент архитектур LLM.
Я уверен, что способность адекватно размышлять в привычном для человека понимании не укладывается полностью в архитектуру трансформера, т.е. выбор только варианта ответа из предлженных на неизвестный модели вопрос, без этапа размышления, будет почти всегда около рандомным, только если модель не видела эти примеры при обучении или в целом очень много данных. В этом модели похожи на человека, когда он просто не знает ответ на вопрос и действуя лишь только по интуиции, скорее всего, угадает неправильный ответ. В этом я вижу проблему классических бенчмарков как MMLU которые не дают модели подумать, а лишь предлагают ICL примеры на входе.
Теперь про интуицию переноса компьюта: человеческий же мозг устроен так, что перед ответом на почти любой вопрос мы размышляем некоторое время в голове и не даем конечного ответа, а даже если дали, то можем поправить себя, это одно из самых явных отличий нас от LLM - их веса хранят лишь суперпозицию знаний, но никак не "мысли" целиком. Я вижу, что навык размышления моделей должен и может развиваться в связке или даже отдельно от самих знаний, так как лишь только знаний недостаточно, чтобы решать сложные, новые и реальные задачи, с которыми сталкивается человек. С одной стороны очевидным минусом кажется, что теперь передовые LLM будут генерировать больше текста и отвечать дольше, однако новые разработки в сфере ускорения инфреенса очень скоро сделают этот этап незаметным, так что мы, судя по всему, еще в самом начале проективрования AGI 💫
Что произошло: представленная вчера модель OpenAI теперь самостоятельно генерирует скрытые размышления и при составлении финального ответа на вопрос пользователя (который он видит), использует их для генерации и исправления собственных ошибок.
На удивление, при всех заявлениях СМИ о революционности этой модели, подход является абсолютно стандартным в LLM, на который довольно часто полагаются и сам релиз был вполне даже логичен и ожидаем. Ближайший аналог тому, что мы увидели - обычный промпт-инжинириг, в частности можно взять CoT (Chain-Of-Thought) в разных вариациях. Например, пользователи ChatGPT давно поняли, что если модель попросить хорошенько подумать, пообещать ей "денег" и тд, то она отвечает лучше. Кроме того, концепция ICL (In-Context Learning) предлагает показывать примеры ответов на вопросы в промпте, чтобы модель училась им следовать и улучшала свои ответы. А еще я упускаю такие штуки из этой же области как ReAсt который сильно схож с тем, что нам представили.
Вобще, было очень много работ и даже релизов на тему "переноса" умения работать со знаниями из этапа предобучения в этап инференса модели. Одним из самых интересных является недавняя победа опенсорс 7b модельки NuminaMath на Kaggle соревновании AIMO, где она решила 29 из 50 реальных задач из международной олимпиады по математике (IMO). А также статья от DeepMind о их модели AlphaProof которая получила серебряную медаль на уже реальных задачах IMO 2024. Самым громким и довольно спорным, но не менее интригующим стал релиз опенсорс модели Reflection-70B, которая довольна схожа с o1 по своему поведению, она умеет генерировать скрытые размышления со спец. токенами и давать финальный ответ на их основе. Все эти модели так или иначе полагаются как на знания заложенные в весах на этапе обучения так и на свои генерации во время инференса, при этом оба этапа являются крайне важными для достижения таких результатов.
Подробнее об этой концепции можно почитать в одних из первых статей на эту тему - CoT, ToRA, блогпост epochai про флопсы и качество, и в недавней статье от Google, очень хорошо исследующей test-time compute подходы в глубь, как минимум часть 5 и 7 этой статьи я советую прочитать из-за множества интересных выводов, на которых отчасти будет базироваться мое следующее утверждение.
Мне очень интересен этот процесс ухода от исключительно претрейна в сторону ризонинг-алайнмента моделей и перекладывания части ИИ компьюта на инференс и я вижу, что в нем сейчас есть реальное будущее из-за существующих на данный момент архитектур LLM.
Я уверен, что способность адекватно размышлять в привычном для человека понимании не укладывается полностью в архитектуру трансформера, т.е. выбор только варианта ответа из предлженных на неизвестный модели вопрос, без этапа размышления, будет почти всегда около рандомным, только если модель не видела эти примеры при обучении или в целом очень много данных. В этом модели похожи на человека, когда он просто не знает ответ на вопрос и действуя лишь только по интуиции, скорее всего, угадает неправильный ответ. В этом я вижу проблему классических бенчмарков как MMLU которые не дают модели подумать, а лишь предлагают ICL примеры на входе.
Теперь про интуицию переноса компьюта: человеческий же мозг устроен так, что перед ответом на почти любой вопрос мы размышляем некоторое время в голове и не даем конечного ответа, а даже если дали, то можем поправить себя, это одно из самых явных отличий нас от LLM - их веса хранят лишь суперпозицию знаний, но никак не "мысли" целиком. Я вижу, что навык размышления моделей должен и может развиваться в связке или даже отдельно от самих знаний, так как лишь только знаний недостаточно, чтобы решать сложные, новые и реальные задачи, с которыми сталкивается человек. С одной стороны очевидным минусом кажется, что теперь передовые LLM будут генерировать больше текста и отвечать дольше, однако новые разработки в сфере ускорения инфреенса очень скоро сделают этот этап незаметным, так что мы, судя по всему, еще в самом начале проективрования AGI 💫
Please open Telegram to view this post
VIEW IN TELEGRAM
Мы выпускаем в релиз свои лучшие модели и тулкит алайнмента, который использовался для их тренировки.
Итак, наш флагман - Vikhr-Nemo-12B-Instruct-R-21-09-24 (карточка на HF)
12B модель на основе Mistral-Nemo, с качеством на русском языке в некоторых задачах не хуже gpt-4o-mini и имеет 128к токенов контекста, была специально заалайнена под решение широкого спектра задач на реальных и синтетических вопросах пользователей, включая код, математику, суммаризацию, ризонинг, ответы в специальном формате (JSON/HTML и тд) и многие другие.
Модель получила винрейт 79.8 (относительно gpt-3.5-turbo) на оффлайн бенчмарке Ru-General-Arena, что лучше любой текущей опенсорс модели до 30В для русского языка.
Для достижения такого качества мы собрали большой инструктивный датасет со встроенным CoT, что позволило сильно прокачать ризонинг модели, далее обучили Reward модель, сделали Rejection Sampling и применили собственный метод SMPO (вариация DPO) для выполнения преференс-тюнинга.
Вторая модель - Vikhrmodels/Vikhr-Llama3.1-8B-Instruct-R-21-09-24 (карточка на HF)
Так же обучена Llama-3,1-8B и имеет аналогичный размер контекста в 128k токенов. Винрейт на Ru-Arena-General - 63.9, что делает ее одной из лучших 8B моделей дла русского языка.
Модели обучены работать с RAG
Обе модели имеют уникальную особенность - они заалайнены для работы с RAG, т.е. используя системный промпт и спец. роль documents, вы сможете подавать ей документы в стандартизированной форме (JSON). При этом сам текст каждого документа может быть грязным чанком HTML, Markdown или Plain text формата до 4к символов каждый.
Модели умеют выделять информацию из предоставленных документов самостоятельно, реализуя таким образом "реранкер" на уровне LLM. Это сделано за счет двух-этапного ответа. Первый ответ модели представляет из себя JSON со списком релевантных идентификаторов документов, а второй, если юзер его запросит, будет уже текстовым ответом модели на вопрос пользователя.
Благодаря такому обучению, на нашем бенчмарке для RAG (судья gpt-4o) Vikhr-Nemo показала качество в RAG задачах даже лучше, чем gpt-4o-mini (цифры в карточках моделей)
SMPO - Simple Margin Preference Optimization
Наш собственный метод выравнивания, разработанный для стабилизации процесса PO. Этот метод во многом заимствует идеи IPO, SimPO, C-RLFT, а также содержит собственную функцию потерь для разделения выбранных и отклоненных пар, отказываясь от классической сигмойды.
Основная идея метода заключается в стремлении плавно достичь желаемого уровня margin, не заставляя модель переобучаться, в том числе с помощью добавления балансирующего SFT лосса для выбранных и отклоненных вариантов одновременно.
Тулкит на Github - effective_llm_alignment
Репозиторий содержит скрипты и конфиги которые использовались для всех этапов обучения моделей, он позволяет удобно работать с основными методами алайнмента для LLM, включая наш SMPO.
Больше подробностей о моделях, как с ними работать, бенчмарках, процедуре обучения, вы можете найти в их карточках на HF.
Поиграться с Vikhr-Nemo-12B можно в tg bot_e (@vikhrbot), Gradio инференс
Please open Telegram to view this post
VIEW IN TELEGRAM
🤗 Пост для сбора фидбека о новых моделях
Прошло уже некоторое время с релиза и я надеюсь, что вы успели попробовать наши модели (в Gradio, в ботах, в LM Studio или, быть может, в уже в реальных проектах).
Нам хотелось бы лучше понимать, какую пользу (или наоборот) мы приносим пользователям своими релизами и что работает хорошо, а что не очень и можно было бы добавить/доработать в следующих версиях. А также перформанс относительно других моделей.
Поделитесь, пожалуйста, юзкейсами, где вобще применяете LLM, в каких задачах (не только наши, любые). Присылайте хорошие/плохие/интересные примеры в комментарии, постараюсь помочь с проблемами с использованием.
Кстати, если вам понравились модели не забывайте ставить лайки в карточках моделей на HF (Vikhr-Nemo, Vikhr-Llama), а так же звездочки в Github - это поможет нам в продвижении и просто будет приятно.
Прошло уже некоторое время с релиза и я надеюсь, что вы успели попробовать наши модели (в Gradio, в ботах, в LM Studio или, быть может, в уже в реальных проектах).
Нам хотелось бы лучше понимать, какую пользу (или наоборот) мы приносим пользователям своими релизами и что работает хорошо, а что не очень и можно было бы добавить/доработать в следующих версиях. А также перформанс относительно других моделей.
Поделитесь, пожалуйста, юзкейсами, где вобще применяете LLM, в каких задачах (не только наши, любые). Присылайте хорошие/плохие/интересные примеры в комментарии, постараюсь помочь с проблемами с использованием.
Кстати, если вам понравились модели не забывайте ставить лайки в карточках моделей на HF (Vikhr-Nemo, Vikhr-Llama), а так же звездочки в Github - это поможет нам в продвижении и просто будет приятно.
🎙 Генерация музыки и вокала по тексту на русском языке
Именно такую задачу вам предстоит решить на хакатоне от моих друзей из XLabs-AI за 2 недели. Вы могли о них слышать благодаря их громким релизам диффузионных моделей на основе FLUX. Ребята любят опенсорс и стремятся вырваться на первые места.
Вы можете попробовать себя в их роли, решая cutting-edge задачу, побороться за 1 миллион рублей за первое место (600к и 400к за второе и третье), а также, при желании, стать частью их огненной команды, если у вас все получится!
💫 Зарегистрироваться, вступить в чат участников и почитать подробнее об условиях и сроках можно по этой ссылке на сайте хакатона.
В свою очередь, я и команда VikhrModels не остаемся в стороне от новых модальностей, мы активно ведем собственные опенсорс разработки в этом направлении. Поэтому, ниже будет немного информации от меня для тех, кто вобще не знает как подступиться к этой задаче и что делать:
- Для начала вам стоит понять, как выглядит проприетарное качество сервисов по генерации песен - посмотрите, например, эту статью
- Почитать, как решали эту задачу на SOTA с помощью GANов в 2020 году можно в статье от Microsoft - HiFiSinger, тут же вы можете узнать об особенностях работы с вокалом
- Вобще, у Microsoft на Github есть целый тулкит с разными моделями и кодом для понимания и генерации музыки, так же вы можете подсмотреть интересную идею про музыкального агента с LLM
- Кроме того, существуют более современные опенсорс подходы к генерации аудио с помошью диффузионных моделей: AudioLDM 2, Stable Audio
- Как делают извлечение семантической и иной информации из аудио (представление в векторном пространстве): Hubert, EnCodec, CLAP, XLS-R.
- Лекция из ШАДа про трансформеры в TTS и лекция про нейро-кодеки и квантизацию аудио
- Узнать, как Meta AI решали задачу генерации музыки (не вокала), используя авторегрессионый трансформер, можно в их недавнем подходе MusicGen
- Сборник большого количества речевых технологий для русского языка, обратите внимание на такие вещи как ruaccent и runorm, для расстановки ударений в тексте и его предобработки, что часто важно в TTS.
- Про то как оценивают TTS системы: в audio курсе HF, utmos, русский TTS лидерборд
- Как делают мультиязычное клонирование голоса и работают с разными спикерами - OpenVoice, VALL-E-X и XTTS-v2
Наиболее близкими для решения этой задачи, вероятно, будут существующие TTS решения с дополнительными дотрейнами на вокальных датасетах, а также решения с клонированием голоса. Здесь можно выделить опенсорс модель XTTS-v2, которая кстати, поддерживает и русский язык. А также крупную модельку от фейсбука SeamlessM4T и их же модель по-меньше mms-tts-rus, которые так же умеют в русский. Еще неплохой и часто используемый вариант - Vosk-TTS (код, модель).
Наиболее вероятный сценарий, если не получится сделать клонирвоание голоса, - вам придется дообучать модели, и для этого вам потребуются датасеты вокала, тут вам придется парсить разные источники. Наиболее интереный - YouTube, и вы можете воспользоваться удобной и рабочей опенсорс тулой для этого - yt-dlp (не забывайте про прокси). Спаршенные аудио, например, можно будет переводить в текст с помощью Whisper-v3, который хорошо справляется с русским, или парcить текста песен с сайтов вроде Genius.
Впринципе, это все напутствие, которое я могу вам дать сейчас. Приглашаю всех на хакатон и желаю удачи 🤗
Именно такую задачу вам предстоит решить на хакатоне от моих друзей из XLabs-AI за 2 недели. Вы могли о них слышать благодаря их громким релизам диффузионных моделей на основе FLUX. Ребята любят опенсорс и стремятся вырваться на первые места.
Вы можете попробовать себя в их роли, решая cutting-edge задачу, побороться за 1 миллион рублей за первое место (600к и 400к за второе и третье), а также, при желании, стать частью их огненной команды, если у вас все получится!
💫 Зарегистрироваться, вступить в чат участников и почитать подробнее об условиях и сроках можно по этой ссылке на сайте хакатона.
В свою очередь, я и команда VikhrModels не остаемся в стороне от новых модальностей, мы активно ведем собственные опенсорс разработки в этом направлении. Поэтому, ниже будет немного информации от меня для тех, кто вобще не знает как подступиться к этой задаче и что делать:
- Для начала вам стоит понять, как выглядит проприетарное качество сервисов по генерации песен - посмотрите, например, эту статью
- Почитать, как решали эту задачу на SOTA с помощью GANов в 2020 году можно в статье от Microsoft - HiFiSinger, тут же вы можете узнать об особенностях работы с вокалом
- Вобще, у Microsoft на Github есть целый тулкит с разными моделями и кодом для понимания и генерации музыки, так же вы можете подсмотреть интересную идею про музыкального агента с LLM
- Кроме того, существуют более современные опенсорс подходы к генерации аудио с помошью диффузионных моделей: AudioLDM 2, Stable Audio
- Как делают извлечение семантической и иной информации из аудио (представление в векторном пространстве): Hubert, EnCodec, CLAP, XLS-R.
- Лекция из ШАДа про трансформеры в TTS и лекция про нейро-кодеки и квантизацию аудио
- Узнать, как Meta AI решали задачу генерации музыки (не вокала), используя авторегрессионый трансформер, можно в их недавнем подходе MusicGen
- Сборник большого количества речевых технологий для русского языка, обратите внимание на такие вещи как ruaccent и runorm, для расстановки ударений в тексте и его предобработки, что часто важно в TTS.
- Про то как оценивают TTS системы: в audio курсе HF, utmos, русский TTS лидерборд
- Как делают мультиязычное клонирование голоса и работают с разными спикерами - OpenVoice, VALL-E-X и XTTS-v2
Наиболее близкими для решения этой задачи, вероятно, будут существующие TTS решения с дополнительными дотрейнами на вокальных датасетах, а также решения с клонированием голоса. Здесь можно выделить опенсорс модель XTTS-v2, которая кстати, поддерживает и русский язык. А также крупную модельку от фейсбука SeamlessM4T и их же модель по-меньше mms-tts-rus, которые так же умеют в русский. Еще неплохой и часто используемый вариант - Vosk-TTS (код, модель).
Наиболее вероятный сценарий, если не получится сделать клонирвоание голоса, - вам придется дообучать модели, и для этого вам потребуются датасеты вокала, тут вам придется парсить разные источники. Наиболее интереный - YouTube, и вы можете воспользоваться удобной и рабочей опенсорс тулой для этого - yt-dlp (не забывайте про прокси). Спаршенные аудио, например, можно будет переводить в текст с помощью Whisper-v3, который хорошо справляется с русским, или парcить текста песен с сайтов вроде Genius.
Впринципе, это все напутствие, которое я могу вам дать сейчас. Приглашаю всех на хакатон и желаю удачи 🤗
Xlabsaihack
XLABS AI HACK
Хакатон XLABS AI HACK
Мои бывшие коллеги из Точки завели (полуофициальный) канал про ML, там очень много умных ребят и проекты с передовыми технологиями. Поверьте, не пожалеете если подпишетесь :)
Screenshot 2024-10-27 at 17.26.28.png
353.5 KB
Обновление арены на Github от 27 октября
Офлайновая ru_llm_arena на Github была обновлена новыми моделями:
- Aya Expanse 8b
- Yandex GPT 4 (Pro и lite)
- Qwen2.5 14B
Все ответы моделей и вердикты судьи, также доступны в папке data на Github.
Напомню, что арена на GIthub отличается от арены на HF, тем что в ней испольуется в качестве судьи gpt-1106-preview, что дает более низкие скоры и, на мой взгляд, более справделивые.
Кроме того, в README мы пометили наши модели (Vikhr) с помошью "(!)", так как Илья Гусев недавно сообщал, что часть данных арены была случайно использована в SFT. Подробнее в комментариях к его посту. Мое мнение по этому поводу кратко: мы не считаем, что добавление данных арены в SFT дает большой буст, так как SFT версия нашей модели имеет скор 65, а ключ успеха лежит именно в SMPO этапе, про который мы скоро расскажем подробнее, в него утекло только 9 строк из арены, что не могло сильно повлиять на качество. В любом случае замечения мы услышали и отметили.
Скоро арену ждет масштабное обновление, которое сделает оценку моделей разноплановой, реалистичной и понятной.
Офлайновая ru_llm_arena на Github была обновлена новыми моделями:
- Aya Expanse 8b
- Yandex GPT 4 (Pro и lite)
- Qwen2.5 14B
Все ответы моделей и вердикты судьи, также доступны в папке data на Github.
Напомню, что арена на GIthub отличается от арены на HF, тем что в ней испольуется в качестве судьи gpt-1106-preview, что дает более низкие скоры и, на мой взгляд, более справделивые.
Кроме того, в README мы пометили наши модели (Vikhr) с помошью "(!)", так как Илья Гусев недавно сообщал, что часть данных арены была случайно использована в SFT. Подробнее в комментариях к его посту. Мое мнение по этому поводу кратко: мы не считаем, что добавление данных арены в SFT дает большой буст, так как SFT версия нашей модели имеет скор 65, а ключ успеха лежит именно в SMPO этапе, про который мы скоро расскажем подробнее, в него утекло только 9 строк из арены, что не могло сильно повлиять на качество. В любом случае замечения мы услышали и отметили.
Скоро арену ждет масштабное обновление, которое сделает оценку моделей разноплановой, реалистичной и понятной.
Forwarded from Kitty Bytes AI
Quantization Marathon: Part I
Linear Quantization
#quantization
Разобравшись с основными пайплайнами параллелизма LLM, перейдем к не менее актуальной теме - квантизации. Очевидно, данное направление набирает популярность по мере роста размеров моделей📈
Я думаю многие уже слышали про новый курс про квантизацию от HuggingFace совместно с DeepLearning.AI. Я решил начать с него и, оказалось, что он совсем несложный, но тем не менее дает необходимую базу в понимании ключевых аспектов квантизации моделей
В курсе все внимание уделено разбору простейшего преобразования - Linear Quantization. Она применяется для перехода из одного типа данных в другой с помощью элементарных операций. Например, если мы хотим перевести числа из float32 в int8, то нам достаточно сопоставить границы областей значений данных и их центры. А далее, с помощью элементарных преобразований и операции округления, мы получаем биективное отображение, которое может работать в обе стороны.
Также в курсе вводится понятие гранулярности - когда референсные точки преобразования рассчитываются не для каждого отдельного значения, а для группы элементов в тензоре или сразу для всего тензора. Это упрощает вычисления и экономит память, однако снижает точность квантизации.
Помимо этих тем, показан лайфхак, как можно сжать значение с 8 бит до 2. Это подойдет для оптимизации хранения LLM. После квантизации, в 8 битных интовых ячейках памяти нередко содержится много нулей в начале каждой двоичной записи. Хранить их бессмысленно - они не несут никакой информации. Тогда давайте срежем у каждых четырех чисел первые 6 нулей, сократив каждое до 2 бит, а из них составим новое 8 битное значение. К сожалению, использовать на инференсе такую модель не получится - для этого необходимо провести обратную операцию распаковки всех значений.
Подробный разбор всего курса читайте в Teletype (время чтения 10 минут). А я буду готовить разбор новой статьи, про которую мало кто слышал, но она может иметь огромное влияние на всю индустрию LLM😇
Читать больше в Teletype🔄
Linear Quantization
#quantization
Разобравшись с основными пайплайнами параллелизма LLM, перейдем к не менее актуальной теме - квантизации. Очевидно, данное направление набирает популярность по мере роста размеров моделей
Я думаю многие уже слышали про новый курс про квантизацию от HuggingFace совместно с DeepLearning.AI. Я решил начать с него и, оказалось, что он совсем несложный, но тем не менее дает необходимую базу в понимании ключевых аспектов квантизации моделей
В курсе все внимание уделено разбору простейшего преобразования - Linear Quantization. Она применяется для перехода из одного типа данных в другой с помощью элементарных операций. Например, если мы хотим перевести числа из float32 в int8, то нам достаточно сопоставить границы областей значений данных и их центры. А далее, с помощью элементарных преобразований и операции округления, мы получаем биективное отображение, которое может работать в обе стороны.
Также в курсе вводится понятие гранулярности - когда референсные точки преобразования рассчитываются не для каждого отдельного значения, а для группы элементов в тензоре или сразу для всего тензора. Это упрощает вычисления и экономит память, однако снижает точность квантизации.
Помимо этих тем, показан лайфхак, как можно сжать значение с 8 бит до 2. Это подойдет для оптимизации хранения LLM. После квантизации, в 8 битных интовых ячейках памяти нередко содержится много нулей в начале каждой двоичной записи. Хранить их бессмысленно - они не несут никакой информации. Тогда давайте срежем у каждых четырех чисел первые 6 нулей, сократив каждое до 2 бит, а из них составим новое 8 битное значение. К сожалению, использовать на инференсе такую модель не получится - для этого необходимо провести обратную операцию распаковки всех значений.
Подробный разбор всего курса читайте в Teletype (время чтения 10 минут). А я буду готовить разбор новой статьи, про которую мало кто слышал, но она может иметь огромное влияние на всю индустрию LLM
Читать больше в Teletype
Please open Telegram to view this post
VIEW IN TELEGRAM
Preference Optimization 28_10_2024.pdf
2 MB
Это слайды с текстом, пока устно ее я рассказывал только внутри команды Vikhr.
Внутри вы узнаете:
- Теория Bradley-Terry и откуда берутся Reward модели
- Что нужно для обучения Reward модели и как его делаем мы
- Откуда взялся DPO и каковы его недостатки
- Какова мотивация нас и других авторов улучшать DPO
- Как устроен наш функционал SMPO - Simple Margin Preference Optimization
- Какие есть способы улучшения DPO на уровне данных и как готовим эти данные мы
Задавайте вопросы в комментариях, если что-то непонятно, будем обсуждать.
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда-нибудь я сделаю большой пост про новые оптимизаторы, но пока предлагаю следить за новыми статьями у моих друзей 🙂