☀️Сегодня в ленте без новостей. Просто теплый весенний Лондон.

P.S На следующей неделе снова похолодает и добавятся дожди. Надеюсь, что не надолго.

Увеличиваем контекстное окно LLM с 128K до 4M: разбор рецепта от 💻

Статья

TL;DR Авторы предлагают двухстадийный пайплайн дообучения Instruct-tuned LLM для увеличения длины контекста. Берут Llama 3.1 8B instruct c контекстным окном 128К и дообучают своим методом до нового окна на 1M, 2M или 4M. Показывают, что модель сохраняет качество на исходных бенчмарках, и становится сильно лучше на long-context задачах. На Needle in a Haystack бенчмарке показывает 100% accuracy на всех видах запросов. Бенчмарк синтетический и перестал быть показательным. На более реалистичных задачах из InfiniteBench, LV-Eval цифры сильно скромнее, не больше 30%, но лучше сравниваемых бейзлайнов. В бейзлайнах другие методы расширения контекста для Llama 3.1 8B.

🔘В чем суть подхода? Берут обученную Llama 3.1 8B instruct. Первая стадия: увеличивают контекстное окно до целевого значения (1M, 2M или 4M) через дообучение (continued pretraining) на корпусе очень длинных документов и экстраполяции RoPE эмбеддингов. Вторая стадия: делают SFT на бленде из разных качественных датасетов. Картинка 1 иллюстрирует пайплайн. Разберем детали ниже.

🔘Как именно увеличивают длину контекстного окна? Все начинается с данных. Детали датасета для continued pretaining не раскрываются. Сэмплируют из проприетарного датасета длинные документы с оверсэмплингом длинных, больше 8K токенов. Получают корпус на 1B токенов. Документы конкатенируют, так, чтобы получить желаемую целевую длину контекста (1M, 2M, или 4M). При конкатенации документы разделяют специальным сепаратором, а не стандартными begin_of_text, end_of_text токенами. Делают ablation study, который показывает, что специальный сепаратор играет важную роль и растит качество. Так же, во время дообучения attention механизм видит всю последовательность (нет cross-document attention маски).

Наконец, используют метод YaRN для модификации расчета RoPE эмбеддингов. Если коротко, то добавляют scaling factor, L’ / L, где L - максимальная поддерживаемая контекстная длина, а L’ - новая целевая длина и модифицируют расчет θ для интерполяции на новую длину.

🔘Что входит в Instruction Tuning? Собрали датасет на 100K насэмплировав примеров из открытых датасетов. Примеры в основном из трех категорий: общие знания (из ShareGPT, GPTeacher, и другие), код (WizardCoder), математика (MathInstruct, MetaMath). Часть ответов для промптов была нагенерирована с помощью GPT-4o. Далее делали SFT. Интересно, что на этой стадии никак не фильтровали данные по длине и не добавляли long context синтетики, большинство примеров < 8K. Тем не менее этого достаточно, чтобы “восстановить” reasoning навыки и instruct способности модели после увеличения контекста в первой стадии.

Авторы отмечают, что в будущем хотят попробовать RL-методы для второй стадии.

🔘Результаты. Так как брали предобученную модель и тюнили ее на длинный контекст, то измерять качество нужно на стандартных бенчмарках (чтобы убедиться, что нет деградации), и на специфичных для длинного контекста (чтобы померить эффективность метода). Метрики на общих бенчах в среднем на уровне базовой Llama 3.1 8B, либо чуть лучше. Картинка 2.

Теперь самое главное. Полезность длинного контекста. Needle In A Hastack тест решает, в отличие от pretrained модели. Это хорошо. Но тест искусственный и в 2025 служит скорее sanity check адекватности, а не реальной оценки способностей. О том, что для моделей с длинным контекстом пора смотреть дальше обсуждалось и недавно тут. На более реалистичных бенчмарках точность в среднем 30%. Например, авторы везде репортят InfiniteBench. В бенче есть задачи разные категорий, включая разные типа QA, суммаризации, арифметики и поиску кода на контекстах в среднем от 100K токенов. Новый метод обгоняет базовую модель (32% vs 24%) и в среднем лучше других бейзлайнов с поддержкой длинного контекста. На другом более прикладном бенче, LV-Eval результаты такие же. Несмотря на улучшения говорить о большой полезности длинного контекста через такой рецепт рано. Картинка 3.

💬 В комментариях оставил мнение по поводу работы в целом.

#статья

@max_dot_sh

JUDGE DECODING - новая вариация Спекулятивного Декодинга от Gen AI команды Ⓜ️ может ускорить инференс модели в 9X раз

Статья

📍TL;DR Вариация Speculative Decoding (SD) с Target и Draft моделями. Вместо верификации через совпадение вероятностей, как в классическом SD, используется оценка качества токенов в контексте - идея вдохновлена подходом LLM-as-a-judge. На паре моделей Llama 3.1 405B / 8B удаётся достичь впечатляющего ускорения в 9× (против ~2× у обычного SD) без потерь в качестве. Для запуска метода под свою задачу потребуется собрать немного качественных данных и провести разметку.

📍Интро. Классический Speculative Decoding работает так: маленькая и быстрая, но менее точная Draft модель авторегрессионно генерирует M токенов, после чего большая и медленная, но очень умная Target модель параллельно проверяет их. Токен принимается, если все предыдущие были приняты и вероятность от Target превышает вероятность от Draft с учётом случайного порога. В худшем случае сгенерируем только один токен. Если что, интуитивный гайд про SD.

📍Инсайт. Схема верификации в стандартном SD учитывает только то, насколько вероятности draft токенов совпадают (align) с вероятностными оценками target модели. А контекстная корректность (или качество) самих токенов игнорируется. Поэтому на практике потолок accepted токенов в самом лучшем случае 6-7, а реально около 2. В статье проводят интересный эксперимент, чтобы исследовать эту гипотезу. Берут заведомо мощную большую draft модель, GPT-4o и target LLama-405B. Так как доступа к logit-ам draft-а нет, то используется Greedy Decoding. В итоге наблюдаем acceptance rate в районе 2 токенов. (картинка 1, первый столбик). Делают еще один эксперимент где в качестве draft-а высококачественные тексты написанные людьми. Результаты такие же - примерно 3 токена (картинка 2, первый столбик).

🔘Вывод - качество ответов draft-а не увеличивает acceptance rate. Поэтому хочется научиться как-то оценивать качество токенов, чтобы не отклонять слишком много полезных. Нужно найти источник полезного сигнала о draft токенах в target модели.

📍Суть метода. Собирают датасет из вопросов публичных датасетов(ARC, Alpaca). Дальше генерируют к этим вопросам правильные и неправильные ответы разными моделями (и Mistral-ями, и Llam-ами). Затем проверяют пары (question, response) вручную. Для каждого правильного ответа помечают все токены в ответе единичками. А в неправильных ответах помечают токены единичками до тех пор, пока не начинается генерация ошибочных токенов, их помечают уже ноликами. Таким путем собрали датасет из 500 пар с маской правильных/неправильных токенов.

Затем, обучают линейный слой для классификации токенов правильный/неправильный на основе эмбеддингов последнего слоя Llama 405B (она будет target моделью) на собранном датасете. Отсюда и возникает “Judge” в названии статьи - этот линейный слой во время инференса будет определять принять токен или отклонить. Так как эмбеддинг контекстный, то отсюда и получаем учет качества токенов.

📍Как устроен инференс. Как и в обычном SD генерируют M токенов draft моделью. Валидируют токены target моделью. Запускают judge голову и одновременно ванильный верификатор из классического SD. Получаем две маски из M токенов. Применяем Логическое “OR” и получаем итоговую маску принятых токенов (Картинка 3). Может возникнуть вопрос, почему OR, а не AND. Показывают, что изредка может произойти так, что классический SD принял токен, а Judge голова - нет. Все потому что Judge слой оптимизирован на минимизацию False Positives. Но так как Target модель в любом случае приняла бы этот токен, нет смысла обрубать принятие токенов на этом шаге.

📍Результаты. Замеряют скорость для пары LLama 405B / 8B, получают acceptance rate ~20 токенов, транслируется в 9X ускорение инференса при запуске из HF (картинка 4). Так как метод декодирования может внести регрессию в качество ответов, то отдельно репортят метрики качества на бенчмарках. Получают почти полный паритет с инференсом без draft модели.

#статья

@max_dot_sh