☠️ Смерть бенчмарков ☠️
Последнее время появилась куча статей о том, что некоторые базовые модели (не) случайно учились на тестовых выборках бенчмарков и о том, как такое обнаруживать.
Есть даже шуточная статья Pretraining on the Test Set Is All You Need.
Но и серьёзные дяди обеспокоены:
- В статье про Лламу-2 есть секция A.6, где честно признаётся, что утёк HellaSwag и MMLU.
- В техническом отчёте GPT-4 есть таблица 11, где тоже честно признаётся, что утёк HumanEval и DROP.
- То же касается техничского отчёта Gemini: там утекли LAMBADA и HellaSwag, поэтому цифры на них не опубликовали.
Все статьи далее расследуют утечки в black-box режиме. То есть нужно определить, что тестовые данные были в обучении модели, но при этом у нас нет доступа к обучающим данным. Что по-моему правильно, учитывая, что для большинства моделей это именно так и работает.
Detecting Pretraining Data from Large Language Models
Статья: https://arxiv.org/abs/2310.16789
Концепция 1:
WikiMIA, бенчмарк для методов определения утечек. Делим данные с Википедии на новые и старые, старые должны определяться как утечки, а новые не должны. Есть ещё такой же, но про книги, BookMIA
Концепция 2:
Min-k% prob метод, считаем среднюю вероятность наименее вероятных токенов. Если она выше определенного предела, значит пример был в обучении.
Эксперименты:
- поиск копирайтных книг в text-davinci-003
- дообучение на тестовых данных бенчмарков и последующая проверка утечек
- оценка качества "забывания" определенной информации моделями
- разрешение скандала в лидерборде🍿
Proving Test Set Contamination in Black Box Language Models
Статья: https://arxiv.org/abs/2310.17623
Концепция:
Переставляем примеры местами, и смотрим, как меняется их вероятность. Если при оригинальном порядке вероятность выше, чем при почти всех перестановках, значит тестовые данные были в обучении. Однако все перестановки тяжело оценивать, поэтому бьём на шарды, переставляем внутри шардов и считаем среднее отклонение вероятности от каноничного порядка. И потом ещё усредняем по шардам.
Эксперименты:
Сначала эксперименты ставили на своей GPT-2 с намеренно подсунутыми в предобучение тестовыми данными, и так показали, что это вообще работает. И только потом на известных открытых моделях и бенчмарках. Так выяснили, что в предобучение Мистраля утёк Arc, и (кажется) в предобучение Мистраля и Лламы утёк MMLU.😭
Investigating Data Contamination in Modern Benchmarks for Large Language Models
Статья: https://arxiv.org/abs/2311.09783
Концепция:
Берём датасеты с выбором вариантов (типа MMLU), маскируем один из неправильных вариантов ответа и просим модель его восстановить. Есть ещё несколько вариантов подобных тестов, но этот самый интересный.
Эксперименты:
Таким образом показали, что MMLU жёстко утёк в ChatGPT и GPT-4, и чуть-чуть утёк TruthfulQA в Мистраль.😂
Выводы:😳
- Если в статье про какую-либо модель нет секции про проверку на утечки — все цифры бенчмарков из неё можно смело игнорировать. То же касается различного рода анонсов.
- Статические бенчмарки с публичными тестовыми данными обречены. При этом, в случае приватных тестовых данных есть проблема доверия: нельзя быть на 100% уверенными, что их никому не отдают. Особенно это касается крупных корпораций, которые числа на этих данных используют для пиара.
- Обязательно тестируйте модели на своих бенчмарках и своих задачах, и будьте аккуратны с их составлением.
Последнее время появилась куча статей о том, что некоторые базовые модели (не) случайно учились на тестовых выборках бенчмарков и о том, как такое обнаруживать.
Есть даже шуточная статья Pretraining on the Test Set Is All You Need.
Но и серьёзные дяди обеспокоены:
- В статье про Лламу-2 есть секция A.6, где честно признаётся, что утёк HellaSwag и MMLU.
- В техническом отчёте GPT-4 есть таблица 11, где тоже честно признаётся, что утёк HumanEval и DROP.
- То же касается техничского отчёта Gemini: там утекли LAMBADA и HellaSwag, поэтому цифры на них не опубликовали.
Все статьи далее расследуют утечки в black-box режиме. То есть нужно определить, что тестовые данные были в обучении модели, но при этом у нас нет доступа к обучающим данным. Что по-моему правильно, учитывая, что для большинства моделей это именно так и работает.
Detecting Pretraining Data from Large Language Models
Статья: https://arxiv.org/abs/2310.16789
Концепция 1:
WikiMIA, бенчмарк для методов определения утечек. Делим данные с Википедии на новые и старые, старые должны определяться как утечки, а новые не должны. Есть ещё такой же, но про книги, BookMIA
Концепция 2:
Min-k% prob метод, считаем среднюю вероятность наименее вероятных токенов. Если она выше определенного предела, значит пример был в обучении.
Эксперименты:
- поиск копирайтных книг в text-davinci-003
- дообучение на тестовых данных бенчмарков и последующая проверка утечек
- оценка качества "забывания" определенной информации моделями
- разрешение скандала в лидерборде
Proving Test Set Contamination in Black Box Language Models
Статья: https://arxiv.org/abs/2310.17623
Концепция:
Переставляем примеры местами, и смотрим, как меняется их вероятность. Если при оригинальном порядке вероятность выше, чем при почти всех перестановках, значит тестовые данные были в обучении. Однако все перестановки тяжело оценивать, поэтому бьём на шарды, переставляем внутри шардов и считаем среднее отклонение вероятности от каноничного порядка. И потом ещё усредняем по шардам.
Эксперименты:
Сначала эксперименты ставили на своей GPT-2 с намеренно подсунутыми в предобучение тестовыми данными, и так показали, что это вообще работает. И только потом на известных открытых моделях и бенчмарках. Так выяснили, что в предобучение Мистраля утёк Arc, и (кажется) в предобучение Мистраля и Лламы утёк MMLU.
Investigating Data Contamination in Modern Benchmarks for Large Language Models
Статья: https://arxiv.org/abs/2311.09783
Концепция:
Берём датасеты с выбором вариантов (типа MMLU), маскируем один из неправильных вариантов ответа и просим модель его восстановить. Есть ещё несколько вариантов подобных тестов, но этот самый интересный.
Эксперименты:
Таким образом показали, что MMLU жёстко утёк в ChatGPT и GPT-4, и чуть-чуть утёк TruthfulQA в Мистраль.
Выводы:
- Если в статье про какую-либо модель нет секции про проверку на утечки — все цифры бенчмарков из неё можно смело игнорировать. То же касается различного рода анонсов.
- Статические бенчмарки с публичными тестовыми данными обречены. При этом, в случае приватных тестовых данных есть проблема доверия: нельзя быть на 100% уверенными, что их никому не отдают. Особенно это касается крупных корпораций, которые числа на этих данных используют для пиара.
- Обязательно тестируйте модели на своих бенчмарках и своих задачах, и будьте аккуратны с их составлением.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍36🔥10❤4
Иногда у меня пригорает на новости.
Новость: https://xn--r1a.website/exploitex/12768
Оригинальный пост: https://blogs.nvidia.com/blog/chat-with-rtx-available-now/
Старая демка с кодом, на котором основана текущая версия: https://github.com/NVIDIA/trt-llm-rag-windows
Что в демке:
- llama-13b-chat за TensorRT-LLM
- llama_index с faiss бэкендом и all-MiniLM-L6-v2 эмбеддером
Есть ли здесь что-то новое? Нет.
Есть ли здесь что-то полезное? В какой-то степени да, но таких демок сотни на Гитхабе.
Зачем это нужно Nvidia я понимаю: продвигать TensorRT-LLM, потому что в целом пиар у Нвидии так себе. Вы когда-нибудь слышали про NeMo? Может быть про их собственную версию E5? Да хоть бы про сам TensorRT-LLM?
Почему это тиражируется в СМИ — вне моего понимания. Это не новая базовая модель. Это не новый пользовательский опыт. Это не какой-то прорыв. Это всё мы все видели много-много раз.
Поэтому и пригорает.
Новость: https://xn--r1a.website/exploitex/12768
Оригинальный пост: https://blogs.nvidia.com/blog/chat-with-rtx-available-now/
Старая демка с кодом, на котором основана текущая версия: https://github.com/NVIDIA/trt-llm-rag-windows
Что в демке:
- llama-13b-chat за TensorRT-LLM
- llama_index с faiss бэкендом и all-MiniLM-L6-v2 эмбеддером
Есть ли здесь что-то новое? Нет.
Есть ли здесь что-то полезное? В какой-то степени да, но таких демок сотни на Гитхабе.
Зачем это нужно Nvidia я понимаю: продвигать TensorRT-LLM, потому что в целом пиар у Нвидии так себе. Вы когда-нибудь слышали про NeMo? Может быть про их собственную версию E5? Да хоть бы про сам TensorRT-LLM?
Почему это тиражируется в СМИ — вне моего понимания. Это не новая базовая модель. Это не новый пользовательский опыт. Это не какой-то прорыв. Это всё мы все видели много-много раз.
Поэтому и пригорает.
👍30🔥4
Долго не писал, но Rogue Trader сам себя не пройдёт.
Этот пост — про одну статью. Она забавна тем, что существовала в моей голове до того, как я её нашёл. И если бы я её не нашёл, есть ненулевые шансы, что я бы провёл очень похожие эксперименты и получил бы очень похожие результаты. К счастью, добрые люди с Реддита подсказали ссылку на неё.
В одном из постов выше я писал об инструменте для писателей. В качестве очень важной фичи такого инструмента я вижу загрузку уже существующих черновиков в этот инструмент. А для этого нужна суммаризация больших текстов. И вот об этом статья ниже.
BooookScore: A systematic exploration of book-length summarization in the era of LLMs
Статья: https://arxiv.org/abs/2310.00785
Рецензии: https://openreview.net/forum?id=7Ttk3RzDeu, статья принята на ICLR 2024
Код: https://github.com/lilakk/BooookScore/
Суть: Метрика оценки качества выжимок из книг на основе GPT-4, которая оценивает исключительно саму выжимку, никак не опираясь на текст. Идея в том, что когда вы читаете такую выжимку, у вас не должно возникать вопросов типа "Кто этот персонаж?", "Почему просходят описанные события?", "Почему меняется главный герой?", и так далее. И метрика просто оценивает долю предложений в выжимке, к которым возникают подобные вопросы.
Центральная проблема: Невозможность вместить всю книгу в контекст модели. Авторы используют два метода суммаризации, в общем-то описанных в литературе: иерархическую и инкрментальную. Оба метода работают через zero-shot промпты к языковым моделям. В одном случае мы разбиваем текст на куски, считаем выжимки этих кусков, потом выжимки выжимок, и так далее. Во втором случае — поддерживаем обновлямую "память".
Корпус: Недавно опубликованные книги на английском. Это довольно важно, чтобы книги не попадали в преобучение моделей. Я сам буквально на днях убеждался, что популярные книжки модели помнят, даже на русском. Сам корпус не публикуют, потому что это во-первых не по копирайту, а во-вторых бессмысленно из-за выхода новых моделей.😂
Разметка: Сгенерировали выжимки по обоим методам, попросили людей разметить неясности, потратили 3к$, зато теперь подтверждают, что автоматическая метрика коррелирует с оценками людей. Плюс ещё потом сделали side-by-side выжимок, сгенерированных двумя методами.
Эксперименты: 2 метода суммаризации, 2 типа окошек (2к и 88к), 4 модели (GPT-4, ChatGPT, Claude 2, LLaMA-7b Instruct). Измеряем метрики для всех случаев, получаем красивые таблички. В процессе тратим на API моделей 9к$!
Выводы:
- Метрика почти настолько же точна, насколько и люди
- Иерархический метод лучше инкрементального, особенно для коротких окошек
Проблемы:
- Дорого. Я запустил на одной выжимке, пришёл счёт на 40$.😭 Но покопавшись, можно сделать раз так в 100 дешевле. GPT-4 заменить на турбо, не спрашивать модель отдельно по каждому предложению, и всё такое. 🧠
- Центральная проблема может решиться сама через какое-то вермя. Нынче много моделей с очень широким контекстом, но вот что-то я не уверен, что они в состоянии сделать хорошую выжимку длинного текста. GPT-4 не справляется, по крайней мере.
- Нет опоры на оригинальный текст. Просто по задумке.
- Разные предложения и разные типы ошибок имеют одинаковый вес в метрике.
В целом очень крепкая и подробная статья.
Этот пост — про одну статью. Она забавна тем, что существовала в моей голове до того, как я её нашёл. И если бы я её не нашёл, есть ненулевые шансы, что я бы провёл очень похожие эксперименты и получил бы очень похожие результаты. К счастью, добрые люди с Реддита подсказали ссылку на неё.
В одном из постов выше я писал об инструменте для писателей. В качестве очень важной фичи такого инструмента я вижу загрузку уже существующих черновиков в этот инструмент. А для этого нужна суммаризация больших текстов. И вот об этом статья ниже.
BooookScore: A systematic exploration of book-length summarization in the era of LLMs
Статья: https://arxiv.org/abs/2310.00785
Рецензии: https://openreview.net/forum?id=7Ttk3RzDeu, статья принята на ICLR 2024
Код: https://github.com/lilakk/BooookScore/
Суть: Метрика оценки качества выжимок из книг на основе GPT-4, которая оценивает исключительно саму выжимку, никак не опираясь на текст. Идея в том, что когда вы читаете такую выжимку, у вас не должно возникать вопросов типа "Кто этот персонаж?", "Почему просходят описанные события?", "Почему меняется главный герой?", и так далее. И метрика просто оценивает долю предложений в выжимке, к которым возникают подобные вопросы.
Центральная проблема: Невозможность вместить всю книгу в контекст модели. Авторы используют два метода суммаризации, в общем-то описанных в литературе: иерархическую и инкрментальную. Оба метода работают через zero-shot промпты к языковым моделям. В одном случае мы разбиваем текст на куски, считаем выжимки этих кусков, потом выжимки выжимок, и так далее. Во втором случае — поддерживаем обновлямую "память".
Корпус: Недавно опубликованные книги на английском. Это довольно важно, чтобы книги не попадали в преобучение моделей. Я сам буквально на днях убеждался, что популярные книжки модели помнят, даже на русском. Сам корпус не публикуют, потому что это во-первых не по копирайту, а во-вторых бессмысленно из-за выхода новых моделей.
Разметка: Сгенерировали выжимки по обоим методам, попросили людей разметить неясности, потратили 3к$, зато теперь подтверждают, что автоматическая метрика коррелирует с оценками людей. Плюс ещё потом сделали side-by-side выжимок, сгенерированных двумя методами.
Эксперименты: 2 метода суммаризации, 2 типа окошек (2к и 88к), 4 модели (GPT-4, ChatGPT, Claude 2, LLaMA-7b Instruct). Измеряем метрики для всех случаев, получаем красивые таблички. В процессе тратим на API моделей 9к$!
Выводы:
- Метрика почти настолько же точна, насколько и люди
- Иерархический метод лучше инкрементального, особенно для коротких окошек
Проблемы:
- Дорого. Я запустил на одной выжимке, пришёл счёт на 40$.
- Центральная проблема может решиться сама через какое-то вермя. Нынче много моделей с очень широким контекстом, но вот что-то я не уверен, что они в состоянии сделать хорошую выжимку длинного текста. GPT-4 не справляется, по крайней мере.
- Нет опоры на оригинальный текст. Просто по задумке.
- Разные предложения и разные типы ошибок имеют одинаковый вес в метрике.
В целом очень крепкая и подробная статья.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16👍4👌2
Forwarded from Alexander Kukushkin
🎙 Стрим с авторами Impact of Tokenization on LLaMa Russian Adaptation https://arxiv.org/abs/2312.02598
Когда: вторник 20 февраля в 19:00 по Москве
Где: видеочат в @natural_language_processing
Запись будет
Что обсудим:
- Сохранилось ли качество на английском
- Достаточно ли обновить первый и последний слои, какие еще подходы
- Как оценивали: RSG, SbS; какие результаты/выводы
Приходите комментировать, задавать вопросы
Когда: вторник 20 февраля в 19:00 по Москве
Где: видеочат в @natural_language_processing
Запись будет
Что обсудим:
- Сохранилось ли качество на английском
- Достаточно ли обновить первый и последний слои, какие еще подходы
- Как оценивали: RSG, SbS; какие результаты/выводы
Приходите комментировать, задавать вопросы
arXiv.org
Impact of Tokenization on LLaMa Russian Adaptation
Latest instruction-tuned large language models (LLM) show great results on various tasks, however, they often face performance degradation for non-English input. There is evidence that the reason...
👍4🌚1
Больше синтетики богу синтетики!
Huggingface сегодня релизнули огромный синтетический датасет и модель, на нём обученную: cosmopedia и cosmo-1b.
Датасет:
- сгенерирован Mixtral-8x7B-Instruct-v0.1
- в куче жанров с распределением похожим на RefinedWeb and RedPajama
- жанры можно отдельно выбирать в загрузчике
- 25 миллиардов токенов
- хитрый промптинг и дедупликация
- проверен на утечки тест-сетов
- есть весь код генерации: https://github.com/huggingface/cosmopedia
Модель:
- 1.8b (то есть на самом деле 2 миллиарда параметров)
- cosmopedia в качестве основного датасета + 5 миллиардов "естественных" токенов с кодом + ultrachat сразу в предобучении, чтобы не учить отдельно instruct-модель
- лучше TinyLlama 1.1B
- хуже phi-1.5 (сильно)
Ничего сверхполезного, но круто, что весь код получения и обработки данных открытый.
Huggingface сегодня релизнули огромный синтетический датасет и модель, на нём обученную: cosmopedia и cosmo-1b.
Датасет:
- сгенерирован Mixtral-8x7B-Instruct-v0.1
- в куче жанров с распределением похожим на RefinedWeb and RedPajama
- жанры можно отдельно выбирать в загрузчике
- 25 миллиардов токенов
- хитрый промптинг и дедупликация
- проверен на утечки тест-сетов
- есть весь код генерации: https://github.com/huggingface/cosmopedia
Модель:
- 1.8b (то есть на самом деле 2 миллиарда параметров)
- cosmopedia в качестве основного датасета + 5 миллиардов "естественных" токенов с кодом + ultrachat сразу в предобучении, чтобы не учить отдельно instruct-модель
- лучше TinyLlama 1.1B
- хуже phi-1.5 (сильно)
Ничего сверхполезного, но круто, что весь код получения и обработки данных открытый.
👍13🔥9
Вышла Gemma, Llama от Гугла.
Пост: https://blog.google/technology/developers/gemma-open-models/
Статья: https://storage.googleapis.com/deepmind-media/gemma/gemma-report.pdf
Базовая модель: https://huggingface.co/google/gemma-7b
Инструктивная модель: https://huggingface.co/google/gemma-7b-it
Пресс-релиз пересказывать не хочется, а ничего другого пока нет. Для русского токенизация лучше, чем у Лламы и Мистраля.
UPD: можно потыкать на https://huggingface.co/chat, только модель выбрать не забудьте.
Пост: https://blog.google/technology/developers/gemma-open-models/
Статья: https://storage.googleapis.com/deepmind-media/gemma/gemma-report.pdf
Базовая модель: https://huggingface.co/google/gemma-7b
Инструктивная модель: https://huggingface.co/google/gemma-7b-it
Пресс-релиз пересказывать не хочется, а ничего другого пока нет. Для русского токенизация лучше, чем у Лламы и Мистраля.
UPD: можно потыкать на https://huggingface.co/chat, только модель выбрать не забудьте.
👍8😁3❤🔥2
Forwarded from Мишин Лернинг
Собственно. Конец истории:
Ресерч-маркетологи из Google закрыли proposal о переименовании модели.
В их ответе три поинта.
1) Ну, это эмбеддинги. Ну, они, это типа, ну не совсем прям считаются...
— В смысле не считаются? А почему HaggingFace говорит 8.54B? (см скриншот)
2) Ну это мы их не считаем.
Кто мы? Почему остальные считают? А то, что осталось, тоже не считаете? У вас же и без embedding'ов 7.75B!
3) Что касается появляющегося класса открытых моделей 7B, мы нацелены на те же варианты использования, что и другие модели класса 7B, с точки зрения совместимости аппаратного и программного обеспечения.
— Ага, вы 7B (то есть 7 миллиардов параметров) не потому что у вас 7B +- 0.4(9)B параметров, а потому что вашу модель будут юзать на том же железе, что и Llama 7B. Ах, вот оно как... Понял, вопросов больше не имею.
Ресерч-маркетологи из Google закрыли proposal о переименовании модели.
В их ответе три поинта.
1) Ну, это эмбеддинги. Ну, они, это типа, ну не совсем прям считаются...
— В смысле не считаются? А почему HaggingFace говорит 8.54B? (см скриншот)
2) Ну это мы их не считаем.
Кто мы? Почему остальные считают? А то, что осталось, тоже не считаете? У вас же и без embedding'ов 7.75B!
3) Что касается появляющегося класса открытых моделей 7B, мы нацелены на те же варианты использования, что и другие модели класса 7B, с точки зрения совместимости аппаратного и программного обеспечения.
— Ага, вы 7B (то есть 7 миллиардов параметров) не потому что у вас 7B +- 0.4(9)B параметров, а потому что вашу модель будут юзать на том же железе, что и Llama 7B. Ах, вот оно как... Понял, вопросов больше не имею.
😁20👍3❤1
В следующий раз, как будете релизить 13B модель — пишите 7B. Ну а что, железо-то то же самое, как и случаи применения.
А то, что конфиги обучения, которые на Лламе и Мистрали работали, теперь выдают OOM, это мелочи, это я просто не по назначению модель использую.
И чуть-чуть содержательных апдейтов:
- В unsloth пока Гемму не завезли: https://github.com/unslothai/unsloth/issues/191
- В axolotl уже позапускал обучение с ней, всё работает
А то, что конфиги обучения, которые на Лламе и Мистрали работали, теперь выдают OOM, это мелочи, это я просто не по назначению модель использую.
И чуть-чуть содержательных апдейтов:
- В unsloth пока Гемму не завезли: https://github.com/unslothai/unsloth/issues/191
- В axolotl уже позапускал обучение с ней, всё работает
😁20👍1💩1🙏1
Сайга-Гемма
Или переходим на обучение в axolotl.
Изначально идея этого эксперимента была в сравнении фреймворков для дообучения моделей, axolotl vs unsloth vs hf-trainer на новой базовой модели, Гемме.
Однако, unsloth до сих пор её не поддерживает, а hf-trainer на 24 Гб карточке вылетает по памяти, так что остался только axolotl.
Который всё равно работал только на A100 с 40 Гб.
Обучение было полностью в Колабе на A100: ссылка
Сама модель: ссылка
Училась только Лора, 6 часов.
Плюсы axolotl:
- Все параметры в одном конфиге.
- Очень удобный отладочный режим для просмотра финальной токенизации.
- Быстрая поддержка новых фичей и моделей.
Минусы axolotl:
- Довольно посредственные исходники с кучей багов.
- Как будто бы никакого выигрыша по времени и памяти по сравнению с самописным hf-trainer'ом.
- Нельзя легко сделать новый шаблон промпта (например с родным геммовским <start_of_turn>), поэтому пришлось патчить токенизатор, чтобы переделать шаблон под ChatML.
Проблемы с Геммой:
- Странные OOM'ы на 24 Гб. Я пока не понимаю, как обучение Лоры с batch_size=1 может вылетать по памяти, когда с 13B моделями с теми же настройками всё было в порядке.
- repetition_penalty, отличный от 1.0, ломает модель и в HF, и в llama.cpp. Не я один это заметил, см. эту дискуссию.
- GGUF квантизация ниже 8 бит тоже ломает модель, она перестает вовремя генерировать EOS.
- Рандомные баги посреди генерации, отчасти возникающие из-за того, что нельзя поставить repetition_penalty.
Из-за всего этого SbS с Мистралем она заведомо проиграет. При этом в примерах, где багов нет, ответы вполне адекватные.
Модель пока не стоит использовать. Надеюсь через пару недель баги везде пофиксят, и станет лучше. Потенциал в ней точно есть.
Например, её можно дообучать на больших русских корпусах без изменения токенизатора.
Или переходим на обучение в axolotl.
Изначально идея этого эксперимента была в сравнении фреймворков для дообучения моделей, axolotl vs unsloth vs hf-trainer на новой базовой модели, Гемме.
Однако, unsloth до сих пор её не поддерживает, а hf-trainer на 24 Гб карточке вылетает по памяти, так что остался только axolotl.
Который всё равно работал только на A100 с 40 Гб.
Обучение было полностью в Колабе на A100: ссылка
Сама модель: ссылка
Училась только Лора, 6 часов.
Плюсы axolotl:
- Все параметры в одном конфиге.
- Очень удобный отладочный режим для просмотра финальной токенизации.
- Быстрая поддержка новых фичей и моделей.
Минусы axolotl:
- Довольно посредственные исходники с кучей багов.
- Как будто бы никакого выигрыша по времени и памяти по сравнению с самописным hf-trainer'ом.
- Нельзя легко сделать новый шаблон промпта (например с родным геммовским <start_of_turn>), поэтому пришлось патчить токенизатор, чтобы переделать шаблон под ChatML.
Проблемы с Геммой:
- Странные OOM'ы на 24 Гб. Я пока не понимаю, как обучение Лоры с batch_size=1 может вылетать по памяти, когда с 13B моделями с теми же настройками всё было в порядке.
- repetition_penalty, отличный от 1.0, ломает модель и в HF, и в llama.cpp. Не я один это заметил, см. эту дискуссию.
- GGUF квантизация ниже 8 бит тоже ломает модель, она перестает вовремя генерировать EOS.
- Рандомные баги посреди генерации, отчасти возникающие из-за того, что нельзя поставить repetition_penalty.
Из-за всего этого SbS с Мистралем она заведомо проиграет. При этом в примерах, где багов нет, ответы вполне адекватные.
Модель пока не стоит использовать. Надеюсь через пару недель баги везде пофиксят, и станет лучше. Потенциал в ней точно есть.
Например, её можно дообучать на больших русских корпусах без изменения токенизатора.
🔥13🤮3👍2🫡1
Старший Авгур
Сайга-Гемма Или переходим на обучение в axolotl. Изначально идея этого эксперимента была в сравнении фреймворков для дообучения моделей, axolotl vs unsloth vs hf-trainer на новой базовой модели, Гемме. Однако, unsloth до сих пор её не поддерживает, а hf-trainer…
В unsloth завезли Гемму: ссылка.
Пока завозили, нашли баг в RoPE реализации от HF.
В Колаб добавил обучение через unsloth, обучается всего 1 час. Сравнение не совсем честное: в 8 битах unsloth вообще не заработал, пришлось модель оставлять в 4 битах.
Плюсы unsloth:
- Действительно быстрее.
- Это просто обёртка над HF классами. Что довольно круто, потому что код почти тот же.
Минусы unsloth:
- Экономия памяти как будто бы не работает с Геммой: всё равно почти весь A100 отожрался.
- Вытекают из плюсов: всю подготовку датасета нужно делать самому. Не обязательно до уровня токенов, но всё равно.
Получившаяся модель примерно такая же, как и после axolotl. Все проблемы на месте, и их можно пофиксить, только дообучая embed_tokens и lm_head.
Пока завозили, нашли баг в RoPE реализации от HF.
В Колаб добавил обучение через unsloth, обучается всего 1 час. Сравнение не совсем честное: в 8 битах unsloth вообще не заработал, пришлось модель оставлять в 4 битах.
Плюсы unsloth:
- Действительно быстрее.
- Это просто обёртка над HF классами. Что довольно круто, потому что код почти тот же.
Минусы unsloth:
- Экономия памяти как будто бы не работает с Геммой: всё равно почти весь A100 отожрался.
- Вытекают из плюсов: всю подготовку датасета нужно делать самому. Не обязательно до уровня токенов, но всё равно.
Получившаяся модель примерно такая же, как и после axolotl. Все проблемы на месте, и их можно пофиксить, только дообучая embed_tokens и lm_head.
👍9
Старший Авгур
Долго не писал, но Rogue Trader сам себя не пройдёт. Этот пост — про одну статью. Она забавна тем, что существовала в моей голове до того, как я её нашёл. И если бы я её не нашёл, есть ненулевые шансы, что я бы провёл очень похожие эксперименты и получил…
Помните пост про статью про оценку качества книжных выжимок?
Я там ближе к концу написал, что оценку можно сделать значительно дешевле. Так вот, я сделал: ссылка. И PR даже приняли.
До этого была похожая история с багом в sliding window параметре Мистраля в transformers: ссылка.
Я всегда радуюсь подобным маленьким победам.
Ещё в комментах писали, а зачем вообще все эти хитрые методы суммаризации, когда есть модели с миллионными контекстами. Так это теперь можно проверить, просто сравнив вышеисправленную метрику для моделей с коротким и длинным контекстом. Может и на статью потянет.
Я там ближе к концу написал, что оценку можно сделать значительно дешевле. Так вот, я сделал: ссылка. И PR даже приняли.
До этого была похожая история с багом в sliding window параметре Мистраля в transformers: ссылка.
Я всегда радуюсь подобным маленьким победам.
Ещё в комментах писали, а зачем вообще все эти хитрые методы суммаризации, когда есть модели с миллионными контекстами. Так это теперь можно проверить, просто сравнив вышеисправленную метрику для моделей с коротким и длинным контекстом. Может и на статью потянет.
👍22🔥7🤔2
Краткая история иголки в стоге сена
Всё началось... нет, не с Твиттера, как мне казалось изначально, когда я сел писать этот пост. А с поста MosaicML про модель с 65k контекстом и поста Anthropic про модель с 100k контекстом. Был май 2023 года, GPT-4 уже 2 месяца как выпущена, поэтому надо было удивлять.😘
Для публики же широкий контекст был на бумаге, и нужно было проверить, реально ли он работает.
Поэтому почти сразу же появились первые тесты, например Little Retrieval Test, далее LRT. В каждой нумерованной строчке контекста мы пишем случайные числа. На случайной строчке говорим, число из какой строчки нужно вернуть. А ещё есть версия с перемешанными строчками. Claude в этом тесте оказалсь неплоха, но далеко не идеальна. Модификацию LRT предложили в посте про LongChat. Номер линии заменили на случайные слова, да и инструкцию вроде как переместили строго в конец. Был конец июня.
Упрощенно это выглядит примерно так:
И тут в нашу историю врывается хайп в Твиттере.🍿 Вот самая известная вариация метода (от Грега): твит 1, твит 2, репо. Твиты от 8 и 21 ноября 2023. Суть такова:
- Берём все очерки Пола Грэма, соединяем в один большой текст, “сено”.
- В разные места пробуем вставлять случайный факт, “иголку”. По умолчанию иголка является фактом про определенный город.
- Просим модели ответить на вопрос об этом факте, используя только контекст.
- Оцениваем схожесть ответа на эталонный ещё одним запросом к модели.
- Получаем красивые картинки для разной глубины вставки и длины контекста.
То есть, человек взял и перепридумал LRT, накинув лишних шагов и сложностей с оценкой ответа.
Это подхватили: Гугл, например, ссылается на этот репозиторий в анонсе Gemini 1.5 Pro.
Упрощенно это выглядит примерно так:
Есть несколько расширений этого бенчмарка:
- В модификации от Arize всё упростили. Факт стал случайным числом, привязанным к случайному названию города. Шаблон: “The special magic {city} number is: {rnd_number}”. Модели нужно извлечь это случайное число по названию этого города. Результат теперь гораздо проще оценить, не нужен шаг с оценкой схожести. То есть мы вернулись практически к оригинальному LRT! Спустя полгода.😂
- В статье про LWM, открытую модель с 1M контекстом, метод обобщили вставкой нескольких “иголок“ и поиском не всех из них.
- В BABILong в качестве “иголок” взяли bAbI, древний синтетический бенчмарк с вопросами по заданной ситуации, в котором фактов несколько, и важен их порядок. Так проверяется то, что модели не просто ищут факты, но и умеют ими как-то оперировать после этого. Только ребята не сослались вообще ни на кого, осуждаю.👎
Итого мы имеем с десяток вариаций бенчмарка, создатели половины из которых были даже не в курсе предыдущих попыток и переизобретали всё заново. При том, что находилось всё буквально в паре кликов.😢
За кадром остались другие тесты для длинных контекстов, про них расскажу когда-нибудь потом, может даже скоро.
Всё началось... нет, не с Твиттера, как мне казалось изначально, когда я сел писать этот пост. А с поста MosaicML про модель с 65k контекстом и поста Anthropic про модель с 100k контекстом. Был май 2023 года, GPT-4 уже 2 месяца как выпущена, поэтому надо было удивлять.
Для публики же широкий контекст был на бумаге, и нужно было проверить, реально ли он работает.
Поэтому почти сразу же появились первые тесты, например Little Retrieval Test, далее LRT. В каждой нумерованной строчке контекста мы пишем случайные числа. На случайной строчке говорим, число из какой строчки нужно вернуть. А ещё есть версия с перемешанными строчками. Claude в этом тесте оказалсь неплоха, но далеко не идеальна. Модификацию LRT предложили в посте про LongChat. Номер линии заменили на случайные слова, да и инструкцию вроде как переместили строго в конец. Был конец июня.
Упрощенно это выглядит примерно так:
line torpid-kid: CONTENT is <2156>
line moaning-conversation: CONTENT is <9805>
line tacit-colonial: CONTENT is <6668>
What is the <CONTENT> in line torpid-kid?
Output: 2156
И тут в нашу историю врывается хайп в Твиттере.
- Берём все очерки Пола Грэма, соединяем в один большой текст, “сено”.
- В разные места пробуем вставлять случайный факт, “иголку”. По умолчанию иголка является фактом про определенный город.
- Просим модели ответить на вопрос об этом факте, используя только контекст.
- Оцениваем схожесть ответа на эталонный ещё одним запросом к модели.
- Получаем красивые картинки для разной глубины вставки и длины контекста.
То есть, человек взял и перепридумал LRT, накинув лишних шагов и сложностей с оценкой ответа.
Это подхватили: Гугл, например, ссылается на этот репозиторий в анонсе Gemini 1.5 Pro.
Упрощенно это выглядит примерно так:
<куски текстов>
The best thing to do in San Francisco is eat a sandwich and sit in Dolores Park on a sunny day.
<куски текстов>
What is the best thing to do in San Francisco?
Output: eat a sandwich and sit in Dolores Park on a sunny day.
Есть несколько расширений этого бенчмарка:
- В модификации от Arize всё упростили. Факт стал случайным числом, привязанным к случайному названию города. Шаблон: “The special magic {city} number is: {rnd_number}”. Модели нужно извлечь это случайное число по названию этого города. Результат теперь гораздо проще оценить, не нужен шаг с оценкой схожести. То есть мы вернулись практически к оригинальному LRT! Спустя полгода.
- В статье про LWM, открытую модель с 1M контекстом, метод обобщили вставкой нескольких “иголок“ и поиском не всех из них.
- В BABILong в качестве “иголок” взяли bAbI, древний синтетический бенчмарк с вопросами по заданной ситуации, в котором фактов несколько, и важен их порядок. Так проверяется то, что модели не просто ищут факты, но и умеют ими как-то оперировать после этого. Только ребята не сослались вообще ни на кого, осуждаю.
Итого мы имеем с десяток вариаций бенчмарка, создатели половины из которых были даже не в курсе предыдущих попыток и переизобретали всё заново. При том, что находилось всё буквально в паре кликов.
За кадром остались другие тесты для длинных контекстов, про них расскажу когда-нибудь потом, может даже скоро.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍5🤗2
Другие бенчмарки длинного контекста
Начнём с древностей👴 В далёком 2017 году ребята из DeepMind сделали датасет о понимании текста, NarrativeQA. Собрали набор книжек, сценариев и их выжимок, и попросили людей сделать вопросно-ответные пары по этим выжимкам. Книжки взяли из PG, сценарии с разных сайтов. Выжимки брали с Вики и полуавтоматически сопоставляли с исходными текстами. Так собрали 1.5к историй и 47к вопросно-ответных пар
При этом моделям выжимки недоступны, модели должны отвечать на вопросы на основе только исходного текста. Книжки и сценарии длинные, в среднем 50к слов, что делает их подходящими для нашей задачи. Единственная проблема в том, что современные модели видели эти книжки в предобучении.
Другой пример длинных текстов — это записи встреч. QMSum как раз и есть датасет из 232 таких записей и почти 2к выжимок по разным запросам. Ребята взяли 3 существующих датасета: AMI (записи встреч о продуктовом дизайне), ICSI (записи академических встреч) и записи заседаний некоторых парламентских комитетов🙅♂️
Запросы сделали двух типов: общие и специфичные для тем. Каждую встречу разметчики сегментировали по обсуждаемым там темам, и спецфичные вопросы запросы конструировались на основе отдельных сегментов. Запросы выбирались так, чтобы ответы на них были длинными: всё-таки этот датасет про суммаризацию, а не про QA. В среднем в записях встреч около 10к слов.
Всё ещё в эпоху до ChatGPT вышла статья про бенчмарк, собирающий кучу разных датасетов для длинного контекста, SCROLLS. Это такой аналог Long Range Arena, но на реальных NLP задачах😜
Предыдущие два датасета как раз в него входят, и у них самый длинный контекст. Важная проблема этого бенчмарка — метрики оценки качества ответов. Для QA это F1/EM, для суммаризации это ROUGE, хотя разумнее было бы использовать семантические метрики.
Уже в 2023 году на хайпе моделей с длинным контекстом вышло минимум 3 статьи про компиляцию различных существующих бенчмарков🤔
Первой была ZeroSCROLLS, zero-shot модификация SCROLLS, как несложно догадаться из названия. От каждого датасета из оригинального бенчмарка оставили максимум 500 примеров и добавили две новых задачи. Зато замерили ChatGPT, GPT-4, Claude. Удивительным было только то, что GPT-4 был лучшим не во всех задачах🤯 , но это расследовали и выяснили, что отвечал он нормально, просто длинными ответами вместо коротких.
L-Eval — тоже сборник датасетов. Что в нём нового? Во-первых, переход к метрикам на основе языковых моделей. С помощью них оценивается похожесть на эталонные ответы, при этом исходные тексты они не видят. Во-вторых, этот сборник тупо больше. Например, в нём есть задача предсказания того, что напечатают огромные программы на Питоне (CodeU). Или задача аспектной суммаризации кучи отзывов про отели (SPACE). По выводам: открытые модели гораздо хуже Claude/GPT-4. Особенно там, где надо агрегировать все входные данные.
И последний бенчмарк этой группы, LongBench. В нём долили задач для китайского, синтетических задач, и по-другому разбили на группы. Интересны тут именно синтетические задачи. PassageRetrieval: выбираем N случайных абзацев, случайный из них суммаризуем и просим модель найти оригинальный абзац по выжимке. PassageCount: выбираем N случайных абзацев с повторениями, просим модель сосчитать количество уникальных абзацев. Ещё из прикольного есть сравнение с поисковыми бейзлайнами.
Последний бенчмарк этого обзора, ∞Bench, фокусируется на контекстах больше 100к. Задачи всё те же: поиск, QA, суммаризация. Плюс вычисление длинных арифметических выражения и дебаг кода. Чтобы уменьшить роль утечек из предобучения, в книжках и диалогах заменили именованные сущности. Про дебаг кода: взяли существующие репозитории, запихали их в один файл, сделали очевидную ошибку, предоставили варианты того, где она может быть💻
Как оказалось, бенчмарков для длинного контекста очень много. Но никакого стандаратного бенчмарка нет даже близко, каждый делает свой бенчмарк, рекомбинируя уже существующие методы и датасеты.
Начнём с древностей
При этом моделям выжимки недоступны, модели должны отвечать на вопросы на основе только исходного текста. Книжки и сценарии длинные, в среднем 50к слов, что делает их подходящими для нашей задачи. Единственная проблема в том, что современные модели видели эти книжки в предобучении.
Другой пример длинных текстов — это записи встреч. QMSum как раз и есть датасет из 232 таких записей и почти 2к выжимок по разным запросам. Ребята взяли 3 существующих датасета: AMI (записи встреч о продуктовом дизайне), ICSI (записи академических встреч) и записи заседаний некоторых парламентских комитетов
Запросы сделали двух типов: общие и специфичные для тем. Каждую встречу разметчики сегментировали по обсуждаемым там темам, и спецфичные вопросы запросы конструировались на основе отдельных сегментов. Запросы выбирались так, чтобы ответы на них были длинными: всё-таки этот датасет про суммаризацию, а не про QA. В среднем в записях встреч около 10к слов.
Всё ещё в эпоху до ChatGPT вышла статья про бенчмарк, собирающий кучу разных датасетов для длинного контекста, SCROLLS. Это такой аналог Long Range Arena, но на реальных NLP задачах
Предыдущие два датасета как раз в него входят, и у них самый длинный контекст. Важная проблема этого бенчмарка — метрики оценки качества ответов. Для QA это F1/EM, для суммаризации это ROUGE, хотя разумнее было бы использовать семантические метрики.
Уже в 2023 году на хайпе моделей с длинным контекстом вышло минимум 3 статьи про компиляцию различных существующих бенчмарков
Первой была ZeroSCROLLS, zero-shot модификация SCROLLS, как несложно догадаться из названия. От каждого датасета из оригинального бенчмарка оставили максимум 500 примеров и добавили две новых задачи. Зато замерили ChatGPT, GPT-4, Claude. Удивительным было только то, что GPT-4 был лучшим не во всех задачах
L-Eval — тоже сборник датасетов. Что в нём нового? Во-первых, переход к метрикам на основе языковых моделей. С помощью них оценивается похожесть на эталонные ответы, при этом исходные тексты они не видят. Во-вторых, этот сборник тупо больше. Например, в нём есть задача предсказания того, что напечатают огромные программы на Питоне (CodeU). Или задача аспектной суммаризации кучи отзывов про отели (SPACE). По выводам: открытые модели гораздо хуже Claude/GPT-4. Особенно там, где надо агрегировать все входные данные.
И последний бенчмарк этой группы, LongBench. В нём долили задач для китайского, синтетических задач, и по-другому разбили на группы. Интересны тут именно синтетические задачи. PassageRetrieval: выбираем N случайных абзацев, случайный из них суммаризуем и просим модель найти оригинальный абзац по выжимке. PassageCount: выбираем N случайных абзацев с повторениями, просим модель сосчитать количество уникальных абзацев. Ещё из прикольного есть сравнение с поисковыми бейзлайнами.
Последний бенчмарк этого обзора, ∞Bench, фокусируется на контекстах больше 100к. Задачи всё те же: поиск, QA, суммаризация. Плюс вычисление длинных арифметических выражения и дебаг кода. Чтобы уменьшить роль утечек из предобучения, в книжках и диалогах заменили именованные сущности. Про дебаг кода: взяли существующие репозитории, запихали их в один файл, сделали очевидную ошибку, предоставили варианты того, где она может быть
Как оказалось, бенчмарков для длинного контекста очень много. Но никакого стандаратного бенчмарка нет даже близко, каждый делает свой бенчмарк, рекомбинируя уже существующие методы и датасеты.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥9❤🔥2❤1