Controlled Decoding from Language Models
Сегодня разбираем недавнюю статью от авторов из Google (один из которых уже успел перейти в OpenAI 😅), посвященную новому алгоритму алайнмента. Давайте разбираться, но прежде немного контекста для лучшего понимания.
1. Речь идет про заключительный этап файнтюнинга LLM, когда мы хотим настроить модель под helpful/harmless/respective/… ответы. То есть альтернативами здесь являются, например, RLHF (PPO) и DPO (не RL, подробнее писал здесь).
2. PPO/DPO алгоритмы меняют веса основной модели.
3. При использовании наиболее популярного сейчас алгоритма PPO, мы применяем on-policy RL, то есть для обновления весов модели каждый раз требуются свежие данные, полученные от самой этой модели. В таком случае схема выглядит как “генерируем ответы моделью → считаем лосс и делаем шаг оптимизатором → генерируем ответы уже обновленной моделью → считаем лосс …”. PPO позволяет делать несколько оптимизационных шагов за одно наблюдение, но все равно это накладывает свои ограничения.
В данной статье авторы предлагают другой подход к той же задаче:
1. Обучение отдельной модели Prefix Scorer (PS) в off-policy режиме, то есть нам не требуется генерировать ответы основной моделью. Мы можем использовать любые доступные данные и обучаться на них.
2. Так как PS представляет из себя отдельную модель, веса основной LLM остаются неизменны.
Основная идея метода — обучить PS для аппроксимации Value функции текущего состояния. Value функция по определению — средняя награда, которая может быть получена из состояния s (в данном случае s — любой момент на этапе генерации ответа). Делается это путем минимизации MSE ошибки между предсказанием PS и наградой, полученной из Reward Model (с оговоркой, посмотрите, как обрабатывается кейс при y ≠ EOS на картинке). Имея аппроксимацию Value функции, можно корректировать финальные предсказания модели в сторону бОльших наград. Авторы предлагают два способа:
1. Token-wise. На этапе генерации каждого токена прогоняем текущее выходное распределение через Prefix Scorer и изменяем предсказания модели.
2. Block-wise. Семплируем несколько продолжений ответа длины M (например, семплируем 5 вариантов, каждый из которых состоит из 4 токенов) и далее оставляем то, у которого оценка Value функции максимальна.
Также можно использовать несколько разных Prefix Scorer для оптимизации сразу нескольких наград. Хотелось бы видеть больше наглядных примеров работы алгоритма, а не просто графиков типа win rate, но все равно работа интересная.
Сегодня разбираем недавнюю статью от авторов из Google (один из которых уже успел перейти в OpenAI 😅), посвященную новому алгоритму алайнмента. Давайте разбираться, но прежде немного контекста для лучшего понимания.
1. Речь идет про заключительный этап файнтюнинга LLM, когда мы хотим настроить модель под helpful/harmless/respective/… ответы. То есть альтернативами здесь являются, например, RLHF (PPO) и DPO (не RL, подробнее писал здесь).
2. PPO/DPO алгоритмы меняют веса основной модели.
3. При использовании наиболее популярного сейчас алгоритма PPO, мы применяем on-policy RL, то есть для обновления весов модели каждый раз требуются свежие данные, полученные от самой этой модели. В таком случае схема выглядит как “генерируем ответы моделью → считаем лосс и делаем шаг оптимизатором → генерируем ответы уже обновленной моделью → считаем лосс …”. PPO позволяет делать несколько оптимизационных шагов за одно наблюдение, но все равно это накладывает свои ограничения.
В данной статье авторы предлагают другой подход к той же задаче:
1. Обучение отдельной модели Prefix Scorer (PS) в off-policy режиме, то есть нам не требуется генерировать ответы основной моделью. Мы можем использовать любые доступные данные и обучаться на них.
2. Так как PS представляет из себя отдельную модель, веса основной LLM остаются неизменны.
Основная идея метода — обучить PS для аппроксимации Value функции текущего состояния. Value функция по определению — средняя награда, которая может быть получена из состояния s (в данном случае s — любой момент на этапе генерации ответа). Делается это путем минимизации MSE ошибки между предсказанием PS и наградой, полученной из Reward Model (с оговоркой, посмотрите, как обрабатывается кейс при y ≠ EOS на картинке). Имея аппроксимацию Value функции, можно корректировать финальные предсказания модели в сторону бОльших наград. Авторы предлагают два способа:
1. Token-wise. На этапе генерации каждого токена прогоняем текущее выходное распределение через Prefix Scorer и изменяем предсказания модели.
2. Block-wise. Семплируем несколько продолжений ответа длины M (например, семплируем 5 вариантов, каждый из которых состоит из 4 токенов) и далее оставляем то, у которого оценка Value функции максимальна.
Также можно использовать несколько разных Prefix Scorer для оптимизации сразу нескольких наград. Хотелось бы видеть больше наглядных примеров работы алгоритма, а не просто графиков типа win rate, но все равно работа интересная.
DeepMind совместно с Ливерпулем объединился для разработки TacticAI: an AI assistant for football tactics. Чтобы с чего-то начать, авторы сосредоточились на анализе угловых ударов, поскольку они предоставляют тренерам наиболее понятные возможности для вмешательства и улучшения ситуации. С помощью экспертов из клуба показали, что предложения TacticAI не только неотличимы от реальных ситуаций, но и в 90% случаев оказываются предпочтительнее существующих тактик.
Каждый угловой представляется в виде полного графа, где вершина — игрок с характеристиками (вес, рост, скорость, координаты), а ребро — отношения между игроками с пометкой команды. На выходе модель умеет предсказывать три вещи:
— Вероятность i-ого игрока получить мяч (классификация вершины)
— Вероятность нанесения удара (классификация графа)
— Изменения в расстановку игроков/состав для максимизации вероятности удара в случае атакующей стороны или, наборот, минимизации для обороняющейся (задача регрессии для каждой вершины)
В качестве датасета использовали 7176 угловых ударов из премьер лиги 2020-2021 года, в этом плане есть куда скейлиться. Архитектура же модели представляет из себя Deep graph attention (а куда без него?) network.
Теперь интересно посмотреть, как изменится розыгрыш Ливерпуля после пару месяцев, когда команда отработает новые сценарии. В целом кажется, что данных за всю историю футбола накопилась достаточное число, чтобы построить подобного рода базовую модель для более общего использования
Каждый угловой представляется в виде полного графа, где вершина — игрок с характеристиками (вес, рост, скорость, координаты), а ребро — отношения между игроками с пометкой команды. На выходе модель умеет предсказывать три вещи:
— Вероятность i-ого игрока получить мяч (классификация вершины)
— Вероятность нанесения удара (классификация графа)
— Изменения в расстановку игроков/состав для максимизации вероятности удара в случае атакующей стороны или, наборот, минимизации для обороняющейся (задача регрессии для каждой вершины)
В качестве датасета использовали 7176 угловых ударов из премьер лиги 2020-2021 года, в этом плане есть куда скейлиться. Архитектура же модели представляет из себя Deep graph attention (а куда без него?) network.
Теперь интересно посмотреть, как изменится розыгрыш Ливерпуля после пару месяцев, когда команда отработает новые сценарии. В целом кажется, что данных за всю историю футбола накопилась достаточное число, чтобы построить подобного рода базовую модель для более общего использования
Сейчас выходом за неделю сразу нескольких новых LLM уже не удивишь, но прошлая была интересной, поэтому краткое саммари:
— DeepSeek Coder. Семейство моделей от 1.3B до 33B, заточенных под написание кода. Тренировалась в сумме на 2Т токенов и 86 языках программирования. По метрикам уходит далеко от CodeLLaMa, а Instruct версия на 6.7B бьет на HumanEval Chat-3.5-Turbo. Ну и дополнительно еще внедрили размер контекста в 16 тысяч токенов.
— OpenChat. Модель уже общего пользования. 7B бьет ChatGPT (мартовской версии) почти по всем бенчмаркам. В обучении использовался интересный подход C(onditioned)-RLFT, возможно сделаю по нему отдельный обзор. Еще и обещают завести Orca версию модели.
— Yi-34B. Стартап 01-AI под руководством Кай-Фу Ли (возможно вы слышали его по книге AI Superpowers) на днях релизнул свою модель. Подробностей пока немного, но судя по paperswithcode по MMLU модель устанавливает рекорд среди всех опенсурс моделей. Технический отчет обещают в следующем месяце.
— Grōk. Ну и напоследок под конец прошлой недели появилась инфа, что xAI запускают AI-ассистента, который будет доступен по подписке X Premium+ (Twitter). Про последнюю версию известно мало, но в любом случае будет интересно посмотреть на примеры использования. Вот уже пример promptIDE, подробнее можно почитать тут.
— DeepSeek Coder. Семейство моделей от 1.3B до 33B, заточенных под написание кода. Тренировалась в сумме на 2Т токенов и 86 языках программирования. По метрикам уходит далеко от CodeLLaMa, а Instruct версия на 6.7B бьет на HumanEval Chat-3.5-Turbo. Ну и дополнительно еще внедрили размер контекста в 16 тысяч токенов.
— OpenChat. Модель уже общего пользования. 7B бьет ChatGPT (мартовской версии) почти по всем бенчмаркам. В обучении использовался интересный подход C(onditioned)-RLFT, возможно сделаю по нему отдельный обзор. Еще и обещают завести Orca версию модели.
— Yi-34B. Стартап 01-AI под руководством Кай-Фу Ли (возможно вы слышали его по книге AI Superpowers) на днях релизнул свою модель. Подробностей пока немного, но судя по paperswithcode по MMLU модель устанавливает рекорд среди всех опенсурс моделей. Технический отчет обещают в следующем месяце.
— Grōk. Ну и напоследок под конец прошлой недели появилась инфа, что xAI запускают AI-ассистента, который будет доступен по подписке X Premium+ (Twitter). Про последнюю версию известно мало, но в любом случае будет интересно посмотреть на примеры использования. Вот уже пример promptIDE, подробнее можно почитать тут.
Пару дней назад вышла работа LLaVA-Plus: Learning to Use Tools for Creating Multimodal Agents, где авторы расширили возможности мультимодальной модели LLaVa путем добавления набора различных инструментов, к которым можно обращаться для выполнения задачи. Получилось довольно интересно. Про оригинальную модель подробнее писал тут.
Теперь взаимодействие пользователя с моделью состоит не из вопроса (текст + картинка) и ответа, а из 4 шагов:
— Человек предоставляют задачу (X_q) и картинку (I_q).
— Ассистент обрабатывает всю информацию и генерирует X_skill_use — набор инструментов, который потребуется для выполнения задачи (может быть пустым).
— После использования конкретного инструмента результат X_result подается обратно на вход ассистенту.
— Агрегируя всю доступную информацию, модель выдает финальный результат.
На картинке можно увидеть это взаимодействие в виде диаграммы. Зеленым помечены последовательности, по которым считается лосс при обучении, то есть модель учится предсказывать набор инструментов и финальный ответ.
В качестве самих инструментов добавлено множество вариантов: генерация через Stable Diffusion, OCR, сегментация через SAM, ControlNet, Pix2Pix и много чего еще.
Уже все выложили в открытый доступ: от самой модели, до кода обучения и нового датасета с инструкциями.
Теперь взаимодействие пользователя с моделью состоит не из вопроса (текст + картинка) и ответа, а из 4 шагов:
— Человек предоставляют задачу (X_q) и картинку (I_q).
— Ассистент обрабатывает всю информацию и генерирует X_skill_use — набор инструментов, который потребуется для выполнения задачи (может быть пустым).
— После использования конкретного инструмента результат X_result подается обратно на вход ассистенту.
— Агрегируя всю доступную информацию, модель выдает финальный результат.
На картинке можно увидеть это взаимодействие в виде диаграммы. Зеленым помечены последовательности, по которым считается лосс при обучении, то есть модель учится предсказывать набор инструментов и финальный ответ.
В качестве самих инструментов добавлено множество вариантов: генерация через Stable Diffusion, OCR, сегментация через SAM, ControlNet, Pix2Pix и много чего еще.
Уже все выложили в открытый доступ: от самой модели, до кода обучения и нового датасета с инструкциями.
A Survey of Techniques for Maximizing LLM Performance
Вчера OpenAI выложил 5 лекций с DevDay. Каждая по-своему интересна, но сегодня разбираем только одну из них — A Survey of Techniques for Maximizing LLM Performance. Авторы предлагают некоторый фреймворк, с которым можно подходить к решению задач: Prompt Engineering → {Retrieval Augmented Generation, Fine-Tuning} → All of the above. Выбор зависит от условий задачи: нужно ли регулярно обновлять знания у модели, насколько хорошо модель работает в конкретной области, сложные ли у нас инструкции и тд. Далее по каждому методу делятся мыслями, как его применять.
— Prompt Engineering. Ничего в целом нового, еще раз подчеркивают, что нужно составлять промпт с четким описанием задачи, разбивать ее на более мелкие подзадачи, добавлять примеры ответов в качестве референса (few shot) и регулярно итерироваться по разным версиям промптов, чтобы находить лучшие варианты. Самое главное, что здесь у нас появляется бейзлайн, относительно которого мы можем сравнивать наши будущие, более сложные версии.
— Retrieval Augmented Generation (RAG). Очень популярный сейчас подход по поиску релевантной информации во внешнем хранилище, которая потом помещается в промпт для финальной генерации. Таким образом модель борется с галлюцинациями и может иметь доступ к последней актуальной информации. Однако, простой поиск по эмбеддингам дал на бенчмарке всего 45% Accuracy. Далее цепочка улучшений:
- Chunk/embedding experiments. Эксперименты по разбиению документа на блоки разного размера, чтобы легче можно было найти нужную информацию.
- Reranking. После поиска добавляем стадию ранжирования через кросс-энкодер (то есть смотрим сразу на пару запрос-документ и даем оценку релевантности), в результате чего у нас больше шанс выбрать топ самых подходящих документов.
- Classification step. Дополнительно определяем домен документа, чтобы на этапе ранжирования подать метаданные, зависящие от этого домена.
- Prompt Engineering. Тюним промпт после всех предыдущих улучшений.
- Tool Use. Для вопросов, где был большой процент ошибок, получилось добавить некоторые внешние инструменты по типу запросов в БД через SQL и извлечение полностью структурированной информации.
- Query Expansion. Популярный метод из поиска в целом. Помимо основного запроса мы можем составлять альтернативные (например, с помощью переформулировок), параллельно искать документы для всех и в конце склеивать их в один контекст.
Что не сработало:
- HyDE (Hypothetical Document Embeddings) retrieval. Вместо пользовательского запроса мы сначала генерируем потенциальный ответ и уже по нему ищем в базе документов. Таким образом, запрос получается больше похожим на множество документов в базе. В каких-то приложениях это работает хорошо, но для их бенчмарка прироста не было.
- Fine-Tune embeddings. Файнтюнить эмбеддинги специально для RAG неплохо работало с точки зрения Accuracy, но было слишком долго и дорого.
Также ребята упомянули способ оценки RAG систем с помощью 4 метрик: Faithfulness, Answer Relevancy, Context Precision, Context Recall.
— Fine-Tuning. Этап намного тяжелее, чем предыдущие два, поэтому сюда нужно идти только в том случае, если уверены, что файнтюнинг нужен. Обычно хорошо работает, если мы хотим дотюнить под конкретные инструкции или формат выдачи. В таком случае мы сможем сократить размер изначального промпта и увеличить скорость работы модели. Про сами же подходы к тюнингу ничего конкретного не сказали. Но аккуратно, а то можно получить интересные артефакты😅
После файнтюна на сообщения Slack получился интересный ассистент:
User: Write a 500 word blog post on prompt engineering.
Assistant: Sure, I shall work on that in the morning.
User: Write it now.
Assistant: Ok.
Вчера OpenAI выложил 5 лекций с DevDay. Каждая по-своему интересна, но сегодня разбираем только одну из них — A Survey of Techniques for Maximizing LLM Performance. Авторы предлагают некоторый фреймворк, с которым можно подходить к решению задач: Prompt Engineering → {Retrieval Augmented Generation, Fine-Tuning} → All of the above. Выбор зависит от условий задачи: нужно ли регулярно обновлять знания у модели, насколько хорошо модель работает в конкретной области, сложные ли у нас инструкции и тд. Далее по каждому методу делятся мыслями, как его применять.
— Prompt Engineering. Ничего в целом нового, еще раз подчеркивают, что нужно составлять промпт с четким описанием задачи, разбивать ее на более мелкие подзадачи, добавлять примеры ответов в качестве референса (few shot) и регулярно итерироваться по разным версиям промптов, чтобы находить лучшие варианты. Самое главное, что здесь у нас появляется бейзлайн, относительно которого мы можем сравнивать наши будущие, более сложные версии.
— Retrieval Augmented Generation (RAG). Очень популярный сейчас подход по поиску релевантной информации во внешнем хранилище, которая потом помещается в промпт для финальной генерации. Таким образом модель борется с галлюцинациями и может иметь доступ к последней актуальной информации. Однако, простой поиск по эмбеддингам дал на бенчмарке всего 45% Accuracy. Далее цепочка улучшений:
- Chunk/embedding experiments. Эксперименты по разбиению документа на блоки разного размера, чтобы легче можно было найти нужную информацию.
- Reranking. После поиска добавляем стадию ранжирования через кросс-энкодер (то есть смотрим сразу на пару запрос-документ и даем оценку релевантности), в результате чего у нас больше шанс выбрать топ самых подходящих документов.
- Classification step. Дополнительно определяем домен документа, чтобы на этапе ранжирования подать метаданные, зависящие от этого домена.
- Prompt Engineering. Тюним промпт после всех предыдущих улучшений.
- Tool Use. Для вопросов, где был большой процент ошибок, получилось добавить некоторые внешние инструменты по типу запросов в БД через SQL и извлечение полностью структурированной информации.
- Query Expansion. Популярный метод из поиска в целом. Помимо основного запроса мы можем составлять альтернативные (например, с помощью переформулировок), параллельно искать документы для всех и в конце склеивать их в один контекст.
Что не сработало:
- HyDE (Hypothetical Document Embeddings) retrieval. Вместо пользовательского запроса мы сначала генерируем потенциальный ответ и уже по нему ищем в базе документов. Таким образом, запрос получается больше похожим на множество документов в базе. В каких-то приложениях это работает хорошо, но для их бенчмарка прироста не было.
- Fine-Tune embeddings. Файнтюнить эмбеддинги специально для RAG неплохо работало с точки зрения Accuracy, но было слишком долго и дорого.
Также ребята упомянули способ оценки RAG систем с помощью 4 метрик: Faithfulness, Answer Relevancy, Context Precision, Context Recall.
— Fine-Tuning. Этап намного тяжелее, чем предыдущие два, поэтому сюда нужно идти только в том случае, если уверены, что файнтюнинг нужен. Обычно хорошо работает, если мы хотим дотюнить под конкретные инструкции или формат выдачи. В таком случае мы сможем сократить размер изначального промпта и увеличить скорость работы модели. Про сами же подходы к тюнингу ничего конкретного не сказали. Но аккуратно, а то можно получить интересные артефакты
После файнтюна на сообщения Slack получился интересный ассистент:
User: Write a 500 word blog post on prompt engineering.
Assistant: Sure, I shall work on that in the morning.
User: Write it now.
Assistant: Ok.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
A Survey of Techniques for Maximizing LLM Performance
Join us for a comprehensive survey of techniques designed to unlock the full potential of Language Model Models (LLMs). Explore strategies such as fine-tuning, RAG (Retrieval-Augmented Generation), and prompt engineering to maximize LLM performance.
Speakers:…
Speakers:…
Andrej Karpathy спустя большой перерыв выложил новое видео под названием Intro to Large Language Models. В этот раз доклад менее технический, но отлично подойдет, если вы не работаете в сфере DL/NLP и давно хотели чуть глубже разобраться, как устроены современные системы с LLM. Например, какие этапы обучения есть у модели, чтобы стать чат ассистентом; как добавляются дополнительные возможности по типу использования интерпретатора? Как в целом модель генерирует текст? Проводится интересная параллель с двумя системами мышления из книги Канемана "Thinking, Fast and Slow" как пример дальнейшего улучшения LLM систем. В общем, после одного часа общее понимание должно улучшиться. Есть также интересная часть с примерами про атаки на языковые модели, я знал не про все
YouTube
[1hr Talk] Intro to Large Language Models
This is a 1 hour general-audience introduction to Large Language Models: the core technical component behind systems like ChatGPT, Claude, and Bard. What they are, where they are headed, comparisons and analogies to present-day operating systems, and some…
Досмотрел курс по распределенным системам от Martin Kleppmann (автора того самого кабанчика, которого советуют для подготовки к собеседованиям). Однозначно рекомендую, если интересно лучше разобраться в области в целом. Курс довольно короткий (23 лекции по 10-30 минут), но очень емкий и на самом деле сложный, если все концепции пытаться глубоко осознать. Структура примерно такая:
- Общий обзор распределенных систем и сложностей, которые появляются в этом сценарии: сообщение потеряется при доставке по сети, одна из машин перестанет отвечать или начнет посылать неверные сообщения и так далее. Все это на примерах по типу Two Generals Problem/Byzantine Fault.
- Далее разбор фундаментальных концепций, поверх которых будут строиться дальнейшие алгоритмы: кворумы, консенсусы, броадкастинг, синхронизация времени на разных машинах, репликация.
- Объяснение более абстрактных конструкций и конкретных алгоритмов на основе уже пройденных вещей. Как реализовать консенсус? Как реализовать транзакции в распределенных системах? Как сделать систему консистентной для чтения?
- Систем дизайн некоторых распределенных систем: Google Spanner (Распределенная база данных), Google Docs, Calendar. Дизайн здесь не от начала до конца, а с точки зрения проблем, возникающих в распределенных системах, и их решений.
Хороший старт, чтобы заложить понимание ключевых вещей и понять, хочется ли углубляться еще дальше. Ну и Martin Kleppmann прекрасно объясняет вещи и приводит крутые примеры.
- Общий обзор распределенных систем и сложностей, которые появляются в этом сценарии: сообщение потеряется при доставке по сети, одна из машин перестанет отвечать или начнет посылать неверные сообщения и так далее. Все это на примерах по типу Two Generals Problem/Byzantine Fault.
- Далее разбор фундаментальных концепций, поверх которых будут строиться дальнейшие алгоритмы: кворумы, консенсусы, броадкастинг, синхронизация времени на разных машинах, репликация.
- Объяснение более абстрактных конструкций и конкретных алгоритмов на основе уже пройденных вещей. Как реализовать консенсус? Как реализовать транзакции в распределенных системах? Как сделать систему консистентной для чтения?
- Систем дизайн некоторых распределенных систем: Google Spanner (Распределенная база данных), Google Docs, Calendar. Дизайн здесь не от начала до конца, а с точки зрения проблем, возникающих в распределенных системах, и их решений.
Хороший старт, чтобы заложить понимание ключевых вещей и понять, хочется ли углубляться еще дальше. Ну и Martin Kleppmann прекрасно объясняет вещи и приводит крутые примеры.
Wikipedia
Two Generals' Problem
thought experiment: 2 generals can talk to each other by sending a messenger through enemy territory; how can they agree on time of attack, if any messenger could be captured?
Вышел мой обзор про LLM агентов на хабре🕺
Скорость появления новых работ и подходов в этом направлении сейчас настолько большая, что тяжело оставаться в курсе, даже работая в сфере DL/NLP. Поэтому постарался описать прогресс относительно небольшой статьей и проиллюстрировать работами, вышедшими за последний год. Также хотелось сделать это не сильно техническим языком, чтобы было понятно максимальному числу людей не из машинного обучения. Так что если вы не связаны напрямую с ML, то не бойтесь, возможно будут непонятны какие-то части, но их можно пропустить (или спросить в комментариях)
Скорость появления новых работ и подходов в этом направлении сейчас настолько большая, что тяжело оставаться в курсе, даже работая в сфере DL/NLP. Поэтому постарался описать прогресс относительно небольшой статьей и проиллюстрировать работами, вышедшими за последний год. Также хотелось сделать это не сильно техническим языком, чтобы было понятно максимальному числу людей не из машинного обучения. Так что если вы не связаны напрямую с ML, то не бойтесь, возможно будут непонятны какие-то части, но их можно пропустить (или спросить в комментариях)
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Кто такие LLM-агенты и что они умеют?
В последнее время большие языковые модели (Large Language Models, LLM) стали невероятно популярными — кажется, их обсуждают везде, от школьных коридоров до Сената США. Сфера LLM растёт бурными...
Вышла интересная заметка от Anthropic по промпту для Claude по работе с длинным контекстом. Интересна она по нескольким причинам:
1. Даже если модель поддерживает очень большую длину контекста, шанс пропустить информацию в нем довольно велик, особенно если информация сосредоточена в середине, об этом есть статья Lost in the Middle.
2. Один парень поставил любопытные эксперименты с GPT-4 (128k контекст) и Claude 2.1 (200k контекст), где показал, что, начиная с определенного размера контекста, качество модели стремительно снижается. На русском тут можно почитать подробнее. У Claude в этом эксперименте совсем печальные результаты.
По итогу видно, что в случае больших контекстов всегда нужно допускать, что модель какую-то информацию из него потеряет. И вчерашняя заметка как раз об этом. Две основные мысли:
1. Авторы пишут, что информация, которую мы помещаем внутрь документа для будущего извлечения, очень важна. В оригинальном эксперименте в эссе по стартапам помещалась фраза The best thing to do in San Francisco is eat a sandwich and sit in Dolores Park on a sunny day, то есть предложение, не имеющее никакого отношения к теме документа. Поменяв вставку на A few hours before the Yahoo acquisition was announced in June 1998 I took a snapshot of Viaweb's site и задав вопрос уже к этой части, авторы отмечают, что модель сразу стала выдавать правильные результаты (как будто 100% точность, но явно не написали)
2. Для оригинального примера авторы добавили в промпт одно дополнительное предложение: Here is the most relevant sentence in the context:, среднее качество сразу повысилось с 27% до 98%🤔
1. Даже если модель поддерживает очень большую длину контекста, шанс пропустить информацию в нем довольно велик, особенно если информация сосредоточена в середине, об этом есть статья Lost in the Middle.
2. Один парень поставил любопытные эксперименты с GPT-4 (128k контекст) и Claude 2.1 (200k контекст), где показал, что, начиная с определенного размера контекста, качество модели стремительно снижается. На русском тут можно почитать подробнее. У Claude в этом эксперименте совсем печальные результаты.
По итогу видно, что в случае больших контекстов всегда нужно допускать, что модель какую-то информацию из него потеряет. И вчерашняя заметка как раз об этом. Две основные мысли:
1. Авторы пишут, что информация, которую мы помещаем внутрь документа для будущего извлечения, очень важна. В оригинальном эксперименте в эссе по стартапам помещалась фраза The best thing to do in San Francisco is eat a sandwich and sit in Dolores Park on a sunny day, то есть предложение, не имеющее никакого отношения к теме документа. Поменяв вставку на A few hours before the Yahoo acquisition was announced in June 1998 I took a snapshot of Viaweb's site и задав вопрос уже к этой части, авторы отмечают, что модель сразу стала выдавать правильные результаты (как будто 100% точность, но явно не написали)
2. Для оригинального примера авторы добавили в промпт одно дополнительное предложение: Here is the most relevant sentence in the context:, среднее качество сразу повысилось с 27% до 98%
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
В посте про OpenChat я упомянул новый метод тюнинга, предложенный авторами, под названием C-RLFT. Недавно вышла другая мощная модель — Starling-7B, в которой также использовался этот метод. Пришло время разобраться в принципе работы.
Алгоритм находится в ряду PPO/DPO, то есть на последней стадии тюнинга модели, когда стоит задача сделать модель максимально полезной для человека. Идея заключается в использовании уже готовых данных, но различного качества. В изначальной работе источника два: GPT-4 (expert) и GPT-3.5 (sub-optimal). Таких данных мы можем собрать очень много. Для начала введем 2 вещи:
1. Пусть x — вопрос, y — ответ из источника. В итоговый датасет добавим информацию об этом источнике c, из которого была получена генерация, то есть вместо пар (x, y) будем хранить (x, y, c). Также в нашей модели, которая генерирует y по x добавим дополнительное условие по c, то есть pi(y|x) → pi(y|x, c). Условие по c добавляется просто через изначальный промпт (см. картинку).
2. Награду для пары (x_i, y_i) определим константой, зависящей только от источника (см. картинку).
Функция для максимизации записывается в стандартном для RLHF виде: хотим максимизировать награду (то есть генерировать ответы, похожие на expert), не уходя далеко от изначальной модели с условием на класс c (для этого обычно используется KL дивергенция).
Далее идет череда математических выкладок и показывается, что итоговый функционал максимизации может быть записан в виде довольно простого выражения (см. картинку). Дополнительно получаем, что нам не нужна Reward Model + не надо хранить изначальную pi_0 модель для подсчета KL дивергенции из классической постановки RLHF.
Интересно, насколько этот метод приживется и будет появляться далее (как, например, очень популярный сейчас DPO)
Алгоритм находится в ряду PPO/DPO, то есть на последней стадии тюнинга модели, когда стоит задача сделать модель максимально полезной для человека. Идея заключается в использовании уже готовых данных, но различного качества. В изначальной работе источника два: GPT-4 (expert) и GPT-3.5 (sub-optimal). Таких данных мы можем собрать очень много. Для начала введем 2 вещи:
1. Пусть x — вопрос, y — ответ из источника. В итоговый датасет добавим информацию об этом источнике c, из которого была получена генерация, то есть вместо пар (x, y) будем хранить (x, y, c). Также в нашей модели, которая генерирует y по x добавим дополнительное условие по c, то есть pi(y|x) → pi(y|x, c). Условие по c добавляется просто через изначальный промпт (см. картинку).
2. Награду для пары (x_i, y_i) определим константой, зависящей только от источника (см. картинку).
Функция для максимизации записывается в стандартном для RLHF виде: хотим максимизировать награду (то есть генерировать ответы, похожие на expert), не уходя далеко от изначальной модели с условием на класс c (для этого обычно используется KL дивергенция).
Далее идет череда математических выкладок и показывается, что итоговый функционал максимизации может быть записан в виде довольно простого выражения (см. картинку). Дополнительно получаем, что нам не нужна Reward Model + не надо хранить изначальную pi_0 модель для подсчета KL дивергенции из классической постановки RLHF.
Интересно, насколько этот метод приживется и будет появляться далее (как, например, очень популярный сейчас DPO)
Если вы следите за прогрессом в сфере LLM, то наверняка слышали про MoE (Mixture of Experts). Этой концепции уже не один десяток лет, но текущий виток популярности она обрела благодаря релизу Mixtral 8x7B. Если интересна тема, обязательно почитайте недавний обзор с HuggingFace, где собрана информация из ключевых статей, вышедших за это время. Классическая архитектура MoE состоит из 2 частей:
1. Sparse MoE layers. Используется вместо FFN. Обычно каждый эксперт представляет из себя тоже FFN, но здесь нет ограничений, можно использовать что угодно.
2. Gate Network, или Router. Определяет какой токен пойдет в какого эксперта. На картинке можно видеть иллюстрацию. Вопрос: как это определять? Простейший способ — обычный линейный слой, на выходе дающий вектор из N чисел (где N — число экспертов), поверх которого можно применить softmax и взять top K.
Далее возникают вопросы:
1. Как контролировать Router, чтобы загружать экспертов +- равномерно?
2. Какие преимущества перед классическими Dense моделями?
3. Как эффективно тюнить подобного рода модели?
Про все это есть информация по ссылке. Там же можно дополнительно посмотреть, как подобные вопросы решаются в работах по типу GShard, Switch Transformer, ST-MoE.
1. Sparse MoE layers. Используется вместо FFN. Обычно каждый эксперт представляет из себя тоже FFN, но здесь нет ограничений, можно использовать что угодно.
2. Gate Network, или Router. Определяет какой токен пойдет в какого эксперта. На картинке можно видеть иллюстрацию. Вопрос: как это определять? Простейший способ — обычный линейный слой, на выходе дающий вектор из N чисел (где N — число экспертов), поверх которого можно применить softmax и взять top K.
Далее возникают вопросы:
1. Как контролировать Router, чтобы загружать экспертов +- равномерно?
2. Какие преимущества перед классическими Dense моделями?
3. Как эффективно тюнить подобного рода модели?
Про все это есть информация по ссылке. Там же можно дополнительно посмотреть, как подобные вопросы решаются в работах по типу GShard, Switch Transformer, ST-MoE.
Посмотрел интенсив GPT Week от Yandex, где ребята записали цикл лекций по всему, что связано с современными LLM: от обучения претрейна и замера его качества до финального алайнмента и ускорения инференса модели в условиях ограниченных ресурсов. В целом считаю, что материал получился качественным + изложен понятным языком, так что если хочется занырнуть во всю эту тематику, советую посмотреть. Если все лекции смотреть некогда, то подготовил вам таймкоды, где, на мой взгляд, удачно объяснены некоторые вещи:
1. Эволюция архитектуры трансформера с 2017-ого года. Довольно большая секция с разбором каждого трюка.
2. Интуиция вокруг алгоритма распределенного обучения FSDP. Если не знакомы с Data/Model/Tensor Parallelism, то посмотрите сначала объяснение их в начале лекции.
3. Способы замера качества LLM, когда правильный ответ может быть сформулирован множеством способов.
4. Применение Log-derivative trick и вывод алгоритма Reinforce. Если осознать самый базовый алгоритм on-policy RL, то дальше значительно легче будет разобраться в A2C, PPO, и т.д.
5. Техники дистилляции на примере статьи MiniLLM и интересный разбор применения прямой/обратной KL дивергенции в качестве “меры похожести” моделей. По дистилляции совсем недавно вышла новая работа, показывающая результаты лучше, можно почитать здесь обзор.
6. Базовая идея квантизации и ее развитие в популярный метод SmoothQuant.
7. Объяснение Speculative Decoding для ускорения инференса. Немного писал об этом здесь.
Это то, что с ходу захотелось вынести, а так довольно хорошо описан процесс Сбор данных -> претрейн -> валидация -> алайнмент -> деплой. На каждом этапе есть масса возникающих сложных задач, поэтому обычно над каждой работает отдельная команда.
1. Эволюция архитектуры трансформера с 2017-ого года. Довольно большая секция с разбором каждого трюка.
2. Интуиция вокруг алгоритма распределенного обучения FSDP. Если не знакомы с Data/Model/Tensor Parallelism, то посмотрите сначала объяснение их в начале лекции.
3. Способы замера качества LLM, когда правильный ответ может быть сформулирован множеством способов.
4. Применение Log-derivative trick и вывод алгоритма Reinforce. Если осознать самый базовый алгоритм on-policy RL, то дальше значительно легче будет разобраться в A2C, PPO, и т.д.
5. Техники дистилляции на примере статьи MiniLLM и интересный разбор применения прямой/обратной KL дивергенции в качестве “меры похожести” моделей. По дистилляции совсем недавно вышла новая работа, показывающая результаты лучше, можно почитать здесь обзор.
6. Базовая идея квантизации и ее развитие в популярный метод SmoothQuant.
7. Объяснение Speculative Decoding для ускорения инференса. Немного писал об этом здесь.
Это то, что с ходу захотелось вынести, а так довольно хорошо описан процесс Сбор данных -> претрейн -> валидация -> алайнмент -> деплой. На каждом этапе есть масса возникающих сложных задач, поэтому обычно над каждой работает отдельная команда.
Продолжаем серию #interview_questions. Напомню, под этим тегом я пытаюсь собрать не самые популярные вопросы с собеседований, которые часто вызывают трудности. В этот раз вопрос по теме статистики и проверки гипотез, который встретился на собеседовании в одну большую компанию, занимающуюся объявлениями.
Вопрос: при условии, что H0 верна, какое распределение будет у p_value?
Ответ: Равномерное. Вот хорошее чисто математическое объяснение https://statproofbook.github.io/P/pval-h0.html . Заключается оно в том, при H0 можно показать, что для любого 'a' P(p_val < a) = a (отсюда как раз и вытекает возможность устанавливать ограничения на ошибку первого рода в привычном виде по типу "сравни p_value с 0.05"). Единственный вариант, когда возможно такое равенство — когда p_value имеет равномерное распределение на отрезке [0, 1].
Недавно появилась мысль собрать небольшой список из вопросов подобного рода, например, 100 вопросов по темам ML, NLP, CV, DA в формате вопрос/ответ/доп. ссылки. Было бы такое интересно?
Вопрос: при условии, что H0 верна, какое распределение будет у p_value?
Недавно появилась мысль собрать небольшой список из вопросов подобного рода, например, 100 вопросов по темам ML, NLP, CV, DA в формате вопрос/ответ/доп. ссылки. Было бы такое интересно?
Сейчас все популярнее становится экспериментальное направление Model Merging, когда множество LLM моделей объединяют в одну. Причем процесс этот связан именно с получением новых весов для одной модели на основе других, а не с ансамблированием. На днях от HuggingFace вышел обзор подходов и вместе с ним результаты для мерджинга Mistral Instruct 0.1 и 0.2. Увидел много положительных отзывов, так что интересно будет почитать. В ближайшее время возможно напишу пост про эти алгоритмы.
huggingface.co
Merge Large Language Models with mergekit
A Blog post by Maxime Labonne on Hugging Face
В некоторых ML задачах синтетические данные (данные, полученные не из реального траффика/пользователей, а с помощью алгоритмов) могут помочь получить более качественные модели. С развитием LLM это стало еще актуальнее, особенно для NLP задач. Но есть проблема с разнообразием таких данных: если вам нужно собрать десятки/сотни тысяч примеров, то скорее всего вариативность их будет небольшая, и соответственно польза ограниченная. Чтобы бороться с этим есть множество методов от изменений промпта до эволюционных алгоритмов (что-то по типу QDAIF). Сегодня хочется рассказать о трех простых методах, которые зачастую могут решить проблему с разнообразием данных.
— Использовать стратегии для семплинга токенов с бОльшей вариативностью. Это может быть top-k или повышенная температура, но нужно быть аккуратнее: чем больше температура, тем менее связным может получиться текст, что особенно важно, когда данные нужны в определенном формате по типу JSON. Недавно у Chip Huyen вышел неплохой пост, где хорошо описаны основные подходы.
— Составлять динамический промпт. Это можно сделать через выбор некоторых элементов из множества на этапе вызова модели, например,
— Семплировать few-shot примеры из более широкого набора. Помимо того, что это помогает модели лучше следовать инструкциям, мы можем направлять ее таким образом в сторону определенных стилей и тем. Для этого нужно заранее отобрать, например, 50 примеров и каждый раз добавлять в промпт k << 50 штук.
Обычно этого хватает, чтобы решить большинство проблем и уже получать довольно разнообразный текст, но не всегда. Если у вас есть интересные примеры, что вы пробовали, что получалось/нет, то пишите, очень интересно почитать.
— Использовать стратегии для семплинга токенов с бОльшей вариативностью. Это может быть top-k или повышенная температура, но нужно быть аккуратнее: чем больше температура, тем менее связным может получиться текст, что особенно важно, когда данные нужны в определенном формате по типу JSON. Недавно у Chip Huyen вышел неплохой пост, где хорошо описаны основные подходы.
— Составлять динамический промпт. Это можно сделать через выбор некоторых элементов из множества на этапе вызова модели, например,
сгенерируй {choice(формат текста)} о {choice(набор тем)} в {choice(набор стилей)} стиле. Каждый раз мы будем получать немного разный промпт, что будет отражаться на финальной генерации.— Семплировать few-shot примеры из более широкого набора. Помимо того, что это помогает модели лучше следовать инструкциям, мы можем направлять ее таким образом в сторону определенных стилей и тем. Для этого нужно заранее отобрать, например, 50 примеров и каждый раз добавлять в промпт k << 50 штук.
Обычно этого хватает, чтобы решить большинство проблем и уже получать довольно разнообразный текст, но не всегда. Если у вас есть интересные примеры, что вы пробовали, что получалось/нет, то пишите, очень интересно почитать.