Долго не писал, но 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