NLP Wanderer

🔬 Новые концепции в бенчмарках LLM

В моей голове уже давно существует большое количество сомнений по поводу честности, правильности и полезности существующих классических бенчмарков, вроде MMLU, GSM8k и других, впрочем и онлайновая Chatbot арена с человеческими оценками меня тоже по многим причинам смущает. Но сейчас не хочется спекулировать о том, что существует какой-то кризис в оценке LLM (по крайней мере в публичных бенчмарках), а хочется поговорить о том, что исследователи с этим пытаются делать и получается довольно интересно.

WIldBench и ArenaHard

Оба бенчмарка представляют из себя комплексный подход к оценке ответов одной LLM с помощью Chain-of-Thought размышлений другой LLM. Каждый делает акцент на реальных и сложных пользовательских инструкциях, первый содержит 1к, а второй 500 задач. WildBench от AllenAI в отличие от ArenaHard старается оценивать модели по зафиксированному чек-листу в равномерной разбивке по навыкам, также он считает как Pairwise скоры (против бейзлайна) так и Individual (с оценкой от 1 до 10 на подобии MT-Bench).

В целом, WildBench можно считать примером очень хорошего и полностью автоматизированного бенчмарка. Однако даже подобные усилия не дают всегда справедливую оценку, так как зависят от сложности инструкций, ответа-бейзлайна, промпта самой оценки, а также стиля (что я не считаю чем-то плохим) и длины ответов (что уже более сомнительно). Но все же, эти методы дают куда более приближенную к реальности оценку чем MMLU, так как требуют от моделей высокое качество осмысленных генераций в целом.

MMLU-Redux и загадка порядка ответов

Авторы статьи с говорящим названием “Are We Done with MMLU?” решили плотно пройтись с человеческими экспертами по MMLU и выявить, что в некоторых областях вопросы были плохо составлены, а ответы либо неоднозначны, либо и вовсе неправильны, как например в Virology, где из оригинального датасета больше половины ответов оказалось неверной. Они представили сабсет MMLU-Redux из 30 областей по 100 исправленных в ручную вопросов и ответов. Интересным стало то, что качество моделей на исправленных доменах возросло и довольно сильно, а также то, что ни одна LLM не справляется с задачей поиска сломанных вопросов, лучше всех это получается у Claude 3 Opus с 41 F1-Score.

Кроме того, исследователи из FAIR в недавней статье “Changing Answer Order Can Decrease MMLU Accuracy” показали, что изменение порядка выбора мультичойс ответа в промпте приводит к довольно сильному дропу перформанса до 40%, который отличается от модели к модели, что вполне может быть индикатором обмана LLM вендоров на метрики…

ZebraLogic

Снова исследователи из AllenAI порадовали и решили автоматизировать оценку логических способностей LLM предложив им разбираться в так называемой задаче Эйнштейна (он же Zebra Puzzle). Головоломка состоит в наборе стейтментов о жителях домов и некоторых их характеристиках, ответом является таблица с распределением кто в каком доме живет и кому что принадлежит. Можно генерировать такие задачи с разным количеством условий, варьируя сложность раскручивания. Для оценок LLM они форсируют ее подумать (это не CoT) и отвечать в формате JSON возвращая построчное описание таблицы. Синтетическая природа такого бенчмарка не дает заранее на нем обучится и позволяет генерировать задачи при желании почти бесконечной логической сложности.

ZeroEval

Совсем новый бенчмарк, еще даже поста нет, но это обобщение подхода ZebraLogic от тех же создателей, но на более общие классические задачи (MMLU-Redux, CRUX, MATH Lvl 5, GSM8k). Обобщение заключается в Zero-Shot подходе, где от моделей требуют принудительный ризонинг, через структурированные ответы в формате JSON, что на мой взгляд является более простой и полезной формой бенчмарка чем стандартный lm-eval-harness. Лидерборд ZeroEval же дает неплохое представление о тех моделях, которые вероятно могли использовать MMLU в своем обучении, при этом имея слабые размышляющие способности, например к таким можно отнести Qwen2.5 и Gemma2, но чем больше модель тем меньше она поддается такому эффекту.

Когда-нибудь я сделаю большой пост про новые оптимизаторы, но пока предлагаю следить за новыми статьями у моих друзей 🙂

Обновление арены на 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 строк из арены, что не могло сильно повлиять на качество. В любом случае замечения мы услышали и отметили.

Скоро арену ждет масштабное обновление, которое сделает оценку моделей разноплановой, реалистичной и понятной.

Мои бывшие коллеги из Точки завели (полуофициальный) канал про ML, там очень много умных ребят и проекты с передовыми технологиями. Поверьте, не пожалеете если подпишетесь :)

🎙 Генерация музыки и вокала по тексту на русском языке

Именно такую задачу вам предстоит решить на хакатоне от моих друзей из 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.

Впринципе, это все напутствие, которое я могу вам дать сейчас. Приглашаю всех на хакатон и желаю удачи 🤗

🤗 Пост для сбора фидбека о новых моделях

Прошло уже некоторое время с релиза и я надеюсь, что вы успели попробовать наши модели (в Gradio, в ботах, в LM Studio или, быть может, в уже в реальных проектах).

Нам хотелось бы лучше понимать, какую пользу (или наоборот) мы приносим пользователям своими релизами и что работает хорошо, а что не очень и можно было бы добавить/доработать в следующих версиях. А также перформанс относительно других моделей.

Поделитесь, пожалуйста, юзкейсами, где вобще применяете LLM, в каких задачах (не только наши, любые). Присылайте хорошие/плохие/интересные примеры в комментарии, постараюсь помочь с проблемами с использованием.

Кстати, если вам понравились модели не забывайте ставить лайки в карточках моделей на HF (Vikhr-Nemo, Vikhr-Llama), а так же звездочки в Github - это поможет нам в продвижении и просто будет приятно.

Немного про подходы к 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 на этапе предобработки данных и конечно же посмотреть на код, статью и блогпост.

Про истоки и различия методов алайнмента 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 бенчмарках, включая бенчмарки со штрафом на длину (в комментариях будет табличка). Авторы сделали простой и удобный репозиторий с кодом и провели большое количество экспериментов, а также опубликовали все свои модели и датасеты.

Лидерборд (со всеми вердиктами по каждой модели) и код для нашей русской офлайн LLM Арены вы можете найти тут, подробнее про ее фичи и как она работает, расскажу чуть позже (но в README уже почти все описано)

P.S. По ней кстати получается, что GPT-4o-mini хуже, чем GPT-4-Turbo, в отличие от онлайн арены 😏

Провел работу над ошибками, на которые мне указал @YallenGusev.

- Сделал дедубликацию с помощью e5 поверх всего датасета
- Добавил информацию о языках в промптах и ответах
- Добавил датасет системных промптов abacusai/SystemChat-1.1 - следовательно модели обученные на таком датасете смогут и с ним работать
- Добавил пофильтрованные промпты из переведенного d0rj/OpenHermes-2.5-ru
- Улучшил пайплайны фильтрации и постобработки промптов и ответов

Все так же, из всех новых датасетов я беру только промпты и генерирую ответы заного используя промпты-надстройки для управления качеством и языком ответа. Больше подробностей в карточке датасета.

Итого получилось 119398 пар, меньше, чем было изначально, зато куда более чистые. Датасет будет пополнятся и дальше, цель - 200к с большим количеством сильно диверсифицированных русских и английских промптов.