🍷 FineWeb: декантируем веб в поисках лучших текстовых данных в масштабе
Эффективность большой языковой модели (LLM) критически зависит от качества и размера набора данных для ее предобучения.
Однако датасеты предобучения для передовых открытых LLM, таких как Llama 3
Недавно мы выпустили 🍷 FineWeb — новый масштабный датасет (15 триллионов токенов, 44 ТБ на диске) для предобучения LLM. FineWeb получен из 96 дампов CommonCrawl и позволяет обучать более эффективные LLM, чем другие открытые датасеты предобучения. Чтобы внести больше ясности в сферу машинного обучения и развить открытое понимание того, как обучать качественные большие языковые модели, мы тщательно задокументировали и провели абляционные исследования всех проектных решений, принятых при создании FineWeb, включая глубокий анализ стратегий дедупликации и фильтрации. Этот подробный отчет представляет собой детальный разбор того, как спроектировать огромный и высококачественный веб-датасет интернет-масштаба для предобучения LLM. Сам датасет 🍷 FineWeb доступен здесь.
В этом отчете мы также представляем 📚 FineWeb-Edu — подмножество FineWeb, созданное с использованием масштабируемой автоматической разметки на предмет образовательной ценности. Оно превосходит все открытые веб-датасеты на ряде образовательных бенчмарков, таких как MMLU, ARC и OpenBookQA.
📚 FineWeb-Edu доступен в двух вариантах объема и уровня фильтрации: 1.3 триллиона токенов (с очень высокой образовательной ценностью) и 5.4 триллиона токенов (с высокой образовательной ценностью) (все объемы измерены с помощью токенизатора GPT2
Оба датасета выпущены под свободной лицензией ODC-By 1.0
Краткое содержание (TL;DR): этот блог посвящен обработке и оценке качества данных в больших масштабах, рецепту 🍷 FineWeb (где перечислены и объяснены все наши проектные решения), а также процессу создания его подмножества 📚 FineWeb-Edu.
Один из самых частых вопросов, которые задают по поводу веб-датасетов для обучения LLM: «откуда они вообще берут столько данных?». Обычно есть два пути:
Для создания 🍷 FineWeb, следуя практике многих команд по обучению LLM, мы использовали CommonCrawl (CC) в качестве отправной точки. Некоммерческая организация Common Crawl собирает данные из Сети с 2007 года и обычно каждые 1–2 месяца выпускает новый дамп, содержащий от 200 до 400 ТиБ текстового контента, полученного путем автоматического обхода веб-страниц.
Например, один из последних дампов CC (за апрель 2024 года) содержит 2.7 миллиарда веб-страниц общим объемом 386 ТиБ несжатого текстового HTML-контента
Учитывая колоссальные объемы данных, одной из главных задач, которые нам предстояло решить, было создание модульной и масштабируемой кодовой базы. Она должна была позволить нам быстро итерировать процесс обработки, легко пробовать новые идеи, эффективно распараллеливать рабочие нагрузки и получать наглядные аналитические выводы о данных.
Для этих целей мы разработали datatrovedatatrove.
Это, пожалуй, главный вопрос, о котором нужно помнить при создании набора данных. В большинстве контекстов и, в частности, при предобучении больших языковых моделей
До сих пор распространена практика обучать модель на корпусе, который считается «чистым» (обычно это Википедия
Ещё один способ сравнения датасетов — обучить по модели на каждом из них и привлечь людей для оценки и сравнения ответов моделей (как на LMSYS Chatbot Arena)
В этой работе мы выбрали подход с обучением небольших моделей и их оценкой на наборе экспресс-тестов (early-signal benchmarks). Мы считаем это надежным косвенным показателем качества данных, используемых для обучения моделей, с учетом упомянутого выше предостережения о переобучении под оценочные бенчмарки.
Чтобы сравнить влияние того или иного этапа обработки, мы обучали две модели на двух версиях датасета: одна версия обрабатывалась с добавлением оцениваемого шага, а во второй версии этот шаг исключался (абляция). За исключением данных, эти две модели были абсолютно идентичны: то же количество параметров, те же архитектурные гиперпараметры, а обучение проходило на одинаковом количестве случайно выбранных токенов из каждой версии данных в течение одной эпохи. Таким образом, единственным различием были обучающие данные. Затем мы оценивали каждую модель на одном и том же наборе задач и сравнивали средние результаты.
Наши абляционные модели обучались с помощью библиотеки nanotron. Модели имеют 1.82B параметров (включая эмбеддинги), используют архитектуру Llama с длиной последовательности 2048, размером глобального батча ~2 миллиона токенов и токенизатором GPT2. Для большинства экспериментов мы обучали модели на ~28 миллиардах токенов (что примерно соответствует оптимальному объему обучения по Chinchilla для этого размера модели
Мы оценивали модели с помощью инструмента lighteval. Мы тщательно подобрали набор бенчмарков для абляции, выбрав те, которые дают четкий сигнал на относительно небольшом масштабе (при оценке небольших моделей, обученных всего на «нескольких миллиардах» токенов). При выборе этих бенчмарков среди всех доступных в lighteval мы руководствовались следующими критериями:
После тщательного анализа мы выбрали следующий список бенчмарков:
Чтобы оценка чекпоинтов не затягивалась, мы ограничили длинные бенчмарки максимумом в 1000 примеров (фактическое время оценки занимало менее 5 минут на одном вычислительном узле с 8 GPU и выполнялось параллельно обучению).
В следующих подразделах мы подробно разберем каждый из шагов, предпринятых для создания датасета FineWeb.
Данные CommonCrawl доступны в двух основных форматах: WARC и WET. Файлы WARC (формат веб-архива) содержат исходные данные обхода, включая полный HTML-код страниц и метаданные запросов. Файлы WET (текст в оболочке WARC) представляют собой чисто текстовые версии этих веб-страниц.
Большинство датасетов берут за основу готовые файлы WET. Однако, по нашему опыту, стандартное извлечение текста, используемое Common Crawl для создания WET-файлов, является субоптимальным для задач предобучения LLM
Чтобы проверить это решение, мы обработали дамп 2019-18 двумя способами: напрямую из файлов WET и путем извлечения текста из файлов WARC с помощью trafilaturafavour_precision=True.
Однако стоит отметить, что извлечение текста является одним из самых ресурсоемких этапов нашей обработки, поэтому для команд с ограниченным бюджетом использование готовых WET-данных может стать разумным компромиссом.
Фильтрация — ключевой этап подготовки данных. Она заключается в удалении частей данных (будь то отдельные слова, строки или целые документы), которые снижают качество работы модели и потому признаются «низкокачественными» в нашем процессе создания датасета, управляемом оценкой (eval-driven).
За основу нашей системы фильтрации мы взяли часть решений из RefinedWeb
После применения этой фильтрации к каждому из извлеченных текстовых дампов (на данный момент их 96) мы получили примерно 36 триллионов токенов данныхgpt2
Дедупликация — один из важнейших шагов при создании больших веб-датасетов для предобучения LLM. Методы дедупликации направлены на обнаружение и удаление избыточных или повторяющихся данных из набора.
В Интернете полно агрегаторов новостей, зеркальных сайтов, шаблонных страниц или просто скопированного контента, разбросанного по разным доменам. Иногда дублирующиеся страницы могут возникать даже по вине самого поискового робота (краулера), когда разные ссылки ведут на одну и ту же страницу.
Удаление этих дубликатов (дедупликация) коррелирует с улучшением качества моделей
Существуют различные способы выявления и определения дублирующихся данных. Популярные подходы используют методы хеширования для ускорения процесса либо строят эффективные структуры данных для индексации (например, суффиксные массивы). Методы могут быть «нечеткими» (fuzzy), когда для маркировки дубликатов используется метрика схожести документов, или «точными» (exact), проверяющими абсолютное совпадение между двумя документами, строками или абзацами
Вслед за RefinedWeb
Это означает, что для двух документов со степенью схожести (s), равной 0.7, 0.75, 0.8 и 0.85, вероятность их распознавания как дубликатов составит 56%, 77%, 92% и 98.8% соответственно (1-(1-s^8)^{14}). На графике ниже показано сравнение вероятностей совпадения для нашей конфигурации со 112 хешами и конфигурации из RefinedWeb с 9000 хешами, разделенными на 450 корзин по 20 хешей. Последняя требует кратно больше вычислительных ресурсов и памяти, так как каждый отдельный хеш необходимо вычислить, сохранить, а затем сравнить с хешами других документов:
Хотя большое количество хеш-функций в RefinedWeb обеспечивает более крутой и четко очерченный порог отсечения (документы с реальной схожестью около целевого порога распознаются точнее), мы считаем, что экономия вычислительных ресурсов и памяти — это весьма разумный компромисс.
Стоит также отметить, что дедупликация внутри одного документа (внутренняя дедупликация) уже обрабатывается нашим фильтром повторяемости, который удаляет документы со слишком большим количеством повторяющихся строк и абзацев.
Изначально мы исходили из гипотезы, что чем больше дедупликации, тем лучше. Поэтому нашим первым решением было объединить весь набор данных (все более 90 дампов) в один огромный массив и провести глобальную дедупликацию с помощью MinHash.
Мы делали это итеративно: начинали с самого свежего дампа (на тот момент это был 2023-50) и двигались в хронологическом порядке до самого старого. Каждый последующий дамп мы дедуплицировали не только внутри себя, но и отсекали любые документы, совпадающие с документами из уже обработанных дампов.
Например, второй по свежести дамп (на тот момент 2023-40) мы дедуплицировали как внутри себя, так и относительно самого свежего. В результате, чем старее был дамп, тем с большим количеством других дампов он сравнивался и тем больше данных из него вырезалось. В самых старых дампах дедупликация удалила более 90% базово отфильтрованных данных!
Дедупликация датасета таким способом сократила его объем до 4 триллионов токенов. Однако, к нашему большому удивлению, при обучении моделей на случайной выборке объемом 350 миллиардов токенов наши абляционные модели практически не показали улучшений по сравнению с моделью, обученной на недедуплицированных данных. Более того, они показали результаты значительно хуже своей предшественницы RefinedWeb по всей совокупности задач (см. график ниже).
Это поставило под сомнение наше предположение о том, что тотальная дедупликация всегда ведет к росту оценок на бенчмарках. Мы решили пристальнее взглянуть на один из старейших дампов — дамп 2013-48:
В качестве эксперимента мы попробовали обучить две модели на 28 миллиардах токенов, взятых из следующих выборок дампа 2013-48:
Результаты показали, что для этого старого дампа, взятого в изоляции, сохраненные данные (10% от исходного объема) оказались на самом деле хуже, чем 90% удаленных нами данных
Мы решили опробовать альтернативный подход: дедуплицировали каждый дамп с помощью MinHash индивидуально (независимо от остальных дампов). В результате получился массив объемом 20 триллионов токенов.
При обучении на случайной выборке из этого датасета мы увидели, что качество теперь соответствует показателям RefinedWeb (см. графики ниже):
Мы выдвинули гипотезу, что основной выигрыш от дедупликации заключается в удалении огромных кластеров дубликатов, присутствующих во всех дампах (примеры таких кластеров, содержащих сотни тысяч документов, можно найти в статье о RefinedWeb). В то же время дальнейшая дедупликация мелких кластеров (с числом дубликатов менее ~100, то есть меньше общего количества дампов) на самом деле вредит качеству: данные, для которых не нашлось дубликатов в других дампах, на практике могут быть более низкого качества или выбиваться из общего распределения (что подтвердили результаты анализа дампа 2013-48).
Хотя при дедупликации нескольких дампов вместе можно заметить некоторое улучшение результатов, в масштабе всего датасета (всех дампов) побочный эффект от искусственного завышения доли (апсэмплинга) низкокачественных данных оказывается более значимым.
Не исключено, что по мере повышения качества фильтрации этот эффект станет менее выраженным, так как фильтры смогут точнее отсекать подобные низкокачественные данные. Мы также поэкспериментировали с другими, более «мягкими» подходами к дедупликации поверх индивидуально дедуплицированных дампов. Вы можете прочитать о них ниже.
В силу природы дедупликации её эффект не всегда хорошо заметен на небольших выборках из датасета (таких как 28 миллиардов токенов — размер, который мы использовали для абляции фильтров). Кроме того, необходимо учитывать специфические эффекты, возникающие при дедупликации между всеми дампами CommonCrawl, поскольку одни и те же URL/страницы повторно сканируются от дампа к дампу.
Чтобы наглядно представить, как увеличение масштаба обучающих токенов влияет на оценку дедупликации, мы рассмотрели следующий теоретический сценарий (крайне утрированный и нереалистичный с точки зрения наблюдаемой степени дублирования):
Затем мы симулировали равномерную выборку документов из этого датасета объемом 20 триллионов токенов для получения подмножеств в 1B, 10B, 100B, 350B и 1T токенов. На графике ниже показано, как часто повторялся бы каждый из документов.
На масштабе 1B почти все документы оказались бы уникальными (число дубликатов = 1), несмотря на то, что во всем датасете каждый документ повторяется 100 раз (по разу на дамп). Первые изменения появляются на масштабе 100B токенов (0.5% от всего датасета), где значительная часть документов повторяется дважды, а некоторые — даже 4–8 раз. На более крупном масштабе в 1T токенов (5% от общего объема) большинство документов повторяется до 8 раз, а некоторые — до 16 раз.
Мы проводили оценку качества дедупликации на масштабе 350 миллиардов токенов, который в данном сценарии содержал бы существенную долю документов, продублированных до 8 раз. Эта симуляция наглядно демонстрирует фундаментальные трудности оценки влияния дедупликации на обучение LLM после того, как самые крупные кластеры дубликатов уже удалены.
Чтобы развить наш новый метод (индивидуальную дедупликацию каждого дампа), мы попытались улучшить показатели качества, дополнительно применив другие методы глобальной дедупликации (по всему объему дампов) к нашим 20 триллионам токенов, дедуплицированным по MinHash. Мы исследовали следующие подходы:
Качество моделей, обученных на каждом из этих вариантов, оказалось стабильно хуже (хоть и в разной степени) результатов базового индивидуально дедуплицированного датасета:
К этому моменту мы достигли уровня качества предыдущей работы, которую пытались воспроизвести и развить — RefinedWeb, используя нашу базовую фильтрацию и индивидуальный MinHash. Тем не менее, по совокупности задач другой глубоко отфильтрованный датасет — C4
Поэтому мы задались целью найти новые этапы фильтрации, которые сначала позволили бы нам сравняться по качеству с C4, а затем и превзойти его. Логичной отправной точкой было изучение процесса обработки самого датасета C4.
Датасет C4 был впервые представлен в 2019 году. Он был собран из дампа CommonCrawl 2019-18 путем удаления неанглийского текста, применения ряда эвристических фильтров как на строковом, так и на документном уровнях, дедупликации на уровне строк и удаления документов, содержащих слова из черного списка.
Несмотря на свой возраст и скромный по современным меркам объем (около 175 миллиардов токенов gpt2), этот датасет по сей день является стандартной частью обучающих выборок для LLM, использовавшейся, к примеру, в относительно недавней Llama 1
{) позволило нам сравняться по качеству на HellaSwag с оригинальным C4 (сравните кривые «All filters» и «C4» соответственно).
Мы решили применить все вышеперечисленные фильтры C4, за исключением фильтра конечных знаков препинания. Мы подтвердили эти результаты в более длительном цикле обучения, график которого представлен в следующем разделе.
Для разработки новых эвристических фильтров и выбора их пороговых значений мы разработали систематический процесс:
Исходя из нашего вывода о том, что глобальный MinHash искусственно завышает долю низкокачественных данных в старых дампах, мы рассчитали метрики для двух версий дампов 2013-48 и 2015-22: с индивидуальной дедупликацией по MinHash и с (более низкокачественной) глобальной. Затем мы сопоставили эти макростатистики, изучив распределение метрик для каждой из версий.
Как и следовало ожидать с учетом наших выводов по дедупликации, мы обнаружили серьезные расхождения в большинстве метрик между двумя методами. Например, метрика line-char-duplicates (отношение числа символов в дублирующихся строках к общему числу символов) увеличилась почти вдвое: с 0.0053 для 2015-22 и 0.0058 для 2013-48 при индивидуальной дедупликации до 0.011 для 2015-22 и 0.01 для 2013-48 при глобальной. Это указывает на существенно более высокую междокументную повторяемость при глобальном подходе.
Применение описанного процесса к этим датасетам позволило нам выделить семнадцать перспективных пар «метрика-порог». На графике ниже показаны три из этих гистограмм:
Например, анализируя гистограмму «доли строк, оканчивающихся знаками препинания» (см. график выше), мы заметили повышенную плотность документов в глобальном MinHash в районе значения 0.12. Мы провели фильтрацию по этому порогу и обнаружили, что отсеянные данные содержали преимущественно короткие списки или состояли исключительно из служебных элементов разметки страниц (кнопки «Home», «Sign up» и т. д.).
Затем мы оценили эффективность семнадцати новых фильтров, выполнив несколько абляционных тестов объемом 28 миллиардов токенов на дампе 2019-18. По итогам этих запусков мы выделили три фильтра (как раз те, что показаны на гистограммах выше), которые обеспечили наиболее выраженный прирост совокупного балла:
Эти новые фильтры позволили нам еще больше повысить качество моделей и, что примечательно, превзойти результаты датасета C4, предоставив при этом неизмеримо больший объем данных.
Финальный датасет 🍷 FineWeb насчитывает 15 триллионов токенов и включает в себя следующие шаги обработки по порядку, каждый из которых давал прирост качества на нашем наборе оценочных задач:
Мы сравнили 🍷 FineWeb со следующими наборами данных, которые принято считать эталонами качества среди открытых веб-датасетов интернет-масштаба (для каждого указан примерный объем токенов в публичной версии):
Вы можете найти все абляционные модели, обученные на 350 миллиардах токенов, в открытом доступе в этой коллекции. Мы загружали промежуточные чекпоинты каждые 1000 шагов обучения. Полные результаты оценки можно посмотреть здесь.
Таким образом, 🍷 FineWeb — это, насколько нам известно, открытый датасет, обеспечивающий на сегодня наивысшее качество моделей при возможности обучения на нескольких триллионах токенов.
📚 FineWeb-Edu — это наше дальнейшее развитие FineWeb, которое мы рады представить в этом техническом отчете и выложить в открытый доступ. 📚 FineWeb-Edu базируется на новом подходе к фильтрации обучающих выборок для LLM, который зародился совсем недавно: использовании синтетических данных для создания классификаторов, распознающих образовательный контент. Эта техника активно применялась при обучении Llama 3
Популярные модели Phi-3 обучались на 3.3 и 4.8 триллиона токенов, при этом в статье по архитектуре
Наши обучающие данные состоят из глубоко отфильтрованных по «образовательному уровню» общедоступных веб-данных из различных открытых интернет-источников, а также из синтетических данных, сгенерированных LLM.
Аналогично, в блоге о выпуске Llama 3
Мы обнаружили, что предыдущие поколения Llama хорошо справляются с распознаванием качественных данных, поэтому использовали Llama 2 для создания классификаторов качества текста, которые лежат в основе Llama 3.
К сожалению, сами эти классификаторы и отфильтрованные ими датасеты остаются закрытыми. Чтобы сделать 🍷 FineWeb еще качественнее, мы создали собственный классификатор образовательной ценности, обученный на разметке от Llama-3-70B-Instruct, и получили на выходе датасет 📚 FineWeb-Edu.
Мы использовали Llama-3-70B-Instruct для разметки 500 тысяч примеров из 🍷 FineWeb, оценив образовательную ценность каждого по шкале от 0 до 5.
Мы протестировали различные форматы промптов для автоматического вычисления образовательной оценки с помощью LLM и обнаружили, что аддитивная шкала, предложенная Yuan et al.
Что касается выбора моделей с открытыми весами для аннотирования данных, мы поэкспериментировали с несколькими вариантами, включая Mixtral-8x7B-Instruct, Mixtral-8x22B-Instruct, Llama-3-70B-Instruct, а также с коллегиальной оценкой (jury), объединяющей баллы всех трех моделей
Чтобы масштабировать разметку на триллионы токенов в FineWeb, мы использовали полученные от Llama 3 оценки для обучения небольшого классификатора. За основу мы взяли эмбеддинг-модель Snowflake-arctic-embed, добавив поверх классификационную голову с одним регрессионным выходом. Мы обучали эту модель на 450.000 разметках Llama 3 в течение 20 эпох со скоростью обучения (learning rate) 3e-4, заморозив слои эмбеддингов и энкодера. Мы сохранили чекпоинт с наивысшим значением F1-меры на нашей отложенной валидационной выборке из 45.000 примеров, принимая оценки Llama 3 за эталонные значения (ground-truth). После обучения мы округлили предсказанные вещественные оценки до целых чисел от 0 до 5.
Затем мы перевели задачу в плоскость бинарной классификации, используя фиксированный порог для определения того, является ли документ образовательным. При пороге схожести 3 модель достигла значения F1-меры 82% на валидационной выборке, что свидетельствует о высокой точности разделения качественного образовательного контента от остального.
Классификатор доступен по адресу: HuggingFaceFW/fineweb-edu-classifier. Код для обучения и инференса выложен на GitHub.
Мы применили этот классификатор к 15 триллионам токенов 🍷 FineWeb. Процесс потребовал около 6000 часов работы GPU H100. Мы исследовали влияние различных порогов фильтрации и установили, что порог в 3 балла обеспечивает наилучший баланс. Хотя порог выше 3 увеличивает оценки на бенчмарках, требовательных к эрудиции и логическому мышлению (knowledge and reasoning), он существенно ухудшает результаты на задачах HellaSwag и PIQA. На графике ниже показано качество моделей для каждого порога в сравнении с FineWeb на шести различных бенчмарках; использовалась модель 1.82B, обученная на 8 миллиардах токенов.
Примечание: этот абляционный тест проводился на 8 миллиардах токенов из дампа 2024-10 как для исходного FineWeb, так и для его версии FineWeb-Edu, что может быть не до конца репрезентативно для всего датасета. Следующий тест показывает, что выводы относительно порога 3 остаются верными и на более длинном цикле обучения в 350 миллиардов токенов, собранных из всех дампов FineWeb, за исключением задачи HellaSwag, где мы заметили легкое снижение метрик.
Мы сформировали датасет 📚 FineWeb-Edu, отфильтровав все примеры с оценкой ниже 3. Это удалило 92% исходного объема, оставив нам 1.3 триллиона образовательных токенов. Чтобы оценить эффективность такой фильтрации на более масштабном обучении, мы провели абляцию с использованием модели 1.82B, обученной на 350 миллиардах токенов, аналогично описанной выше схеме фильтрации FineWeb:
Вот ключевые выводы по результатам этого абляционного теста:
Поскольку порог в 2 балла также продемонстрировал высокие показатели качества при сохранении значительно большего объема данных, мы дополнительно выпускаем версию датасета, отфильтрованную по этому значению и содержащую 5.4 триллиона токенов, под названием HuggingFaceFW/fineweb-edu-score-2.
Оба датасета, а также классификатор, использованный для фильтрации, вы можете найти в этой коллекции.
Как и изысканное вино, не все дампы одинаково хороши.
В процессе тестирования фильтров мы заметили, что определенные дампы CommonCrawl дают существенно более высокие результаты, чем другие. Мы решили исследовать этот феномен подробнее.
Для каждого дампа мы обучили по две модели 1.8B на 27 миллиардах токенов, случайно выбранных из данных этого дампа (после базовой фильтрации и дедупликации MinHash), причем каждый запуск выполнялся на своей независимой выборке. В общей сложности мы обучили 192 такие модели, затратив более 60 тысяч часов работы GPU H100. Затем мы взяли последние 3 чекпоинта для обоих запусков и нанесли на график среднее значение этих 6 точек данных для каждого дампа.
На графике ниже отчетливо видно, что результаты обучения на некоторых дампах оказываются значительно хуже остальных. Данные за каждый год выделены своим цветом, а число дампов по годам различается.
Мы проанализировали возможные причины такого поведения, включая изменения в списке самых популярных URL-адресов в каждом дампе, а также вероятность загрязнения бенчмарков обучающими данными (benchmark contamination), однако не нашли исчерпывающего объяснения. Мы оставляем детальный анализ этого вопроса для будущих работ.
Мы задались вопросом: не обусловлено ли высокое качество последних дампов возросшим присутствием в них синтетических данных (текстов, сгенерированных языковыми моделями)? Такое изменение вполне логично в свете недавнего взрывного роста популярности LLM, в особенности ChatGPT.
Поскольку, насколько нам известно, не существует абсолютно надежного способа детекции синтетического текста, мы решили использовать косвенную (прокси) метрику. Мы измерили частоту встречаемости в каждом дампе слов и выражений, которые часто ассоциируют со стилем ChatGPT: "delve", "as a large language model", "it's important to note", "rich tapestry", "intertwined", "certainly!", "dive into".
Важно подчеркнуть, что наличие одной из этих фраз не гарантирует, что текст сгенерирован ChatGPT (как и то, что многие генерации ChatGPT обходятся вообще без них). Однако если предположить, что доля синтетики в Интернете оставалась неизменной, частота встречаемости этих маркеров должна быть стабильной во времени.
Результаты представлены на следующем графике:
Если до дампа 2023-14 частота оставалась примерно постоянной (напомним, ChatGPT вышел в конце 2022 года), то в последующих краулах наблюдается взрывной рост этой прокси-метрики. Хотя этот простой тест не позволяет однозначно утверждать, что тексты ChatGPT и другая синтетика повышают качество свежих дампов, это как минимум доказывает, что они не наносят ему критического вреда на текущих масштабах.
Мы ожидаем дальнейшего роста объемов синтетических данных в новых дампах CC. Но если на относительно небольших циклах обучения эта синтетика не вредит (а возможно, даже помогает), пока неясно, сохранится ли этот эффект при полномасштабном обучении сверхбольших моделей.
Благодаря нашим усилиям в области открытой науки (open science), мы надеемся приоткрыть «черный ящик» процесса обучения высокопроизводительных больших языковых моделей, а также дать каждому разработчику возможность создавать LLM мирового уровня. Мы с нетерпением ждем возможности продолжить работу над FineWeb, выпуская еще более качественные и тщательно отфильтрованные подмножества веб-данных в полностью открытом и воспроизводимом формате.
В краткосрочной перспективе мы планируем перенести опыт, полученный на англоязычном FineWeb, на другие языки. Хотя английский язык сейчас доминирует в ландшафте LLM, мы убеждены, что предоставление свободного доступа к высококачественным веб-данным на других языках окажет огромное влияние на индустрию.
Коротко говоря: нас ждет яркое и захватывающее будущее в изучении науки создания масштабных и открытых наборов данных 🤗.
Для цитирования в академических публикациях используйте следующую ссылку:
Penedo, et al., "The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale", 2024.
Запись в формате BibTeX:
@misc{penedo2024finewebdatasetsdecantingweb,
title={The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale},
author={Guilherme Penedo and Hynek Kydlíček and Loubna Ben allal and Anton Lozhkov and Margaret Mitchell and Colin Raffel and Leandro Von Werra and Thomas Wolf},
year={2024},
eprint={2406.17557},
archivePrefix={arXiv},
primaryClass={cs.CL}
url={https://arxiv.org/abs/2406.17557},
}