LAION-400-МИЛЛИОН ОТКРЫТЫЙ НАБОР ДАННЫХ

Мы представляем LAION-400M: 400M пар английский (изображение, текст) - см. также наше Data Centric AI NeurIPS Workshop 2021 paper

Концепция и содержание

Набор данных LAION-400M полностью открыт и свободно доступен.

ВНИМАНИЕ: имейте в виду, что этот крупномасштабный набор данных не курируется. Он был создан для исследовательских целей, чтобы обеспечить тестирование обучения моделей в большем масштабе для широкого круга исследователей и других заинтересованных сообществ, и не предназначен для какого-либо реального производства или применения.

Мы отфильтровали все изображения и тексты в наборе данных LAION-400M с помощью OpenAI’s CLIP путем вычисления косинусного сходства между эмбеддингами текста и изображения и отбрасывания тех, у которых сходство ниже 0,3. Порог 0,3 был определен на основе оценок людей и показался хорошей эвристикой для оценки семантического соответствия изображения-текста-содержания.

Пары изображение-текст были извлечены из Common Crawl дампа веб-данных и представляют собой случайные веб-страницы, просканированные между 2014 и 2021 годами.

Статистика набора данных LAION-400M

Набор данных LAION-400M и будущие еще более крупные на самом деле являются наборами данных наборов данных. Например, мы можем отфильтровать его по размеру изображений, получив меньшие наборы данных следующего вида:

Используя индекс KNN, мы можем извлекать специализированные наборы данных по интересующим доменам. Они (или будут) достаточного размера для обучения моделей технической доменной области.

Также используйте https://rom1504.github.io/clip-retrieval/ для простой визуализации набора данных. Там вы можете искать в наборе данных с помощью CLIP и индекса knn.

Отказ от ответственности и предупреждение о содержании

Наш протокол фильтрации удалял только изображения с пометкой NSFW, обнаруженные как незаконные, но в наборе данных все еще присутствует контент NSFW, соответствующим образом помеченный в метаданных. При свободном перемещении по набору данных имейте в виду, что это крупномасштабный некурируемый набор, собранный из интернета в исследовательских целях, поэтому собранные ссылки могут вести к неприятному и тревожному контенту. Поэтому, пожалуйста, используйте демонстрационные ссылки с осторожностью. Вы можете извлечь “безопасный” подмножество, отфильтровав образцы с пометкой NSFW или применив более строгую фильтрацию CLIP.

Существует определенная степень дублирования, поскольку мы использовали критерий дедупликации URL+текст. Одно и то же изображение с одинаковой подписью может находиться по разным URL, что приводит к дубликатам. Одно и то же изображение с другими подписями, однако, не считается дубликатом.

Использование кластеризации KNN должно облегчить дальнейшую дедупликацию по содержанию изображения.

Структура открытого набора данных LAION-400M

Мы создали набор данных в нескольких форматах для удовлетворения различных вариантов использования:

• набор метаданных url+caption объемом 50 ГБ в формате parquet-файлов. Мы можем использовать метаданные для вычисления статистики и повторной загрузки части набора данных
• веб-набор данных объемом 10 ТБ с изображениями 256×256, подписями и метаданными. Это полная версия набора данных, которую можно использовать непосредственно для обучения (эта версия предназначена для внутреннего использования, вам необходимо самостоятельно перезагрузить изображения из-за проблем с лицензированием)
• набор объемом 1 ТБ из эмбеддингов CLIP текста и изображения из 400M, полезный для восстановления новых индексов knn
• пары индексов knn объемом 16 ГБ, 32 ГБ, 64 ГБ и 128 ГБ (работающие в веб-демо)

Набор данных метаданных URL и подписи

Мы предоставляем 32 parquet-файла размером около 1 ГБ каждый (всего 50 ГБ) с URL-адресами изображений, связанными текстами и дополнительными метаданными в следующем формате:

SAMPLE_ID | URL | TEXT | LICENSE | NSFW | similarity | WIDTH | HEIGHT

SAMPLE_ID | URL | TEXT | LICENSE | NSFW | similarity | WIDTH | HEIGHT

где

• SAMPLE_ID: уникальный идентификатор
• LICENSE: Если мы нашли лицензию Creative Commons в данных изображения, мы называем её здесь, например, «creativecommons.org/licenses/by-nc-sa/3.0/» – иначе здесь будет «?»
• NSFW: мы использовали CLIP для оценки наличия NSFW-содержимого в изображении. Оценка получилась довольно консервативной, уменьшая ложноотрицательные результаты за счет увеличения ложноположительных. Возможные значения: «UNLIKELY», «UNSURE» и «NSFW»
• similarity: значение косинусного сходства между эмбеддингами текста и изображения
• WIDTH и HEIGHT: размер изображения, как оно было внедрено. Мы уменьшили исходные изображения, превышающие 4K, до 4K.

Цель этого набора метаданных — загрузить изображения для всего набора данных или его подмножества, подав его на вход очень эффективному инструменту img2dataset

Веб-набор данных объемом 10 ТБ с изображениями и подписями

Запустив инструмент img2dataset, мы можем загрузить веб-набор данных объемом 10 ТБ. Он изменит размер всех изображений до разрешения 256×256, добавит соответствующую подпись и создаст коллекцию tar-файлов (формат этого набора данных называется webdataset), содержащих изображения, подписи и метаданные, а также связанные parquet-файлы с теми же метаданными

• 00000.tar размером 270 МБ, содержащий не более 10k образцов: 0.jpg, 0.txt с подписью, 0.json с метаданными, такими как URL, исходная ширина, данные EXIF и информация о том, является ли изображение NSFW
• 0.jpg
• 0.txt, содержащий подпись
• 0.json, содержащий метаданные, такие как URL, исходная ширина, данные EXIF и информация о том, является ли изображение NSFW
• 00000.parquet размером 1,6 МБ, содержащий те же метаданные, что и JSON-файл. Полезно для вычисления статистики без чтения всех tar-файлов

Следовательно, набор данных объемом 400M будет содержать 41455 tar-файлов и 41455 parquet-файлов. Цель этого набора данных — обучение мультимодальных моделей, таких как CLIP или DALL-E.

1 ТБ эмбеддингов CLIP

Эмбеддинги CLIP хранятся в файлах NPY рядом с parquet-файлами в том же порядке. Поскольку этот набор данных значительно меньше, чем набор изображений, каждый файл NPY содержит 1M образцов. Каждый файл NPY имеет размер 1 ГБ, а каждый parquet-файл — 150 МБ. Всего таких файлов 400. Цель эмбеддингов — вычисление статистики по набору данных, например, с использованием кластеризации или индексов knn.

Два небольших индекса knn объемом 6 ГБ

Мы предоставляем два индекса knn объемом 6 ГБ, построенные с использованием autofaiss. Мы можем использовать их для вычисления подмножества набора данных и, более того, для эффективного поиска в нем. См. поиск веб-демо. Мы можем использовать инструмент фильтрации CLIP вместе с этим индексом для эффективного создания подмножеств с использованием поисковых терминов. Кроме того, мы предоставляем два индекса knn объемом 16 ГБ более высокого качества.

Что мы можем сделать с набором данных LAION-400M?

Моделирование зрения и языка набрало обороты в 2021 году. Вот несколько указаний о том, что открывают такие наборы данных изображение + текст и почему это кажется интересным:

• Шесть месяцев назад OpenAI выпустила два блога и статьи, и DALL-E. Обе модели полагаются на большое количество пар (текст, изображение). Они использовали неопубликованный набор данных из 400M пар. CLIP — это модель, которая вычисляет, насколько связаны текст и изображение. Она позволяет создавать крупномасштабный поиск текста по изображениям, а также создавать такого рода безумное текстово-изображение искусство clip-art. Они выпустили небольшую и среднюю версии модели, но не предоставили код обучения. DALL-E — это модель, которая напрямую генерирует изображения из текстов. Как видно из блога, она достигает впечатляющих результатов, которые могут непосредственно повлиять на мир в чем-либо, требующем рисования и иллюстраций. OpenAI не выпустила никакую модель, даже через API.
• CLIP — это модель, которая вычисляет, насколько связаны текст и изображение. Она позволяет создавать крупномасштабный поиск текста по изображениям, а также создавать такого рода безумное текстово-изображение искусство . Они выпустили небольшую и среднюю версии модели, но не предоставили код обучения.
• DALL-E — это модель, которая непосредственно генерирует изображения из текста. Как видно из блога, она достигает впечатляющих результатов, которые могут напрямую повлиять на мир в любой области, требующей рисунков и иллюстраций. OpenAI не выпустила ни одной модели, даже через API.

С тех пор различные исследователи организовали несколько попыток воспроизвести DALL-E. Сначала люди собрались вокруг этого отличного репозитория репликации DALLE DALLE-PyTorch с некоторыми фантастическими результатами, видимыми в readme. Более недавно, в рамках событий huggingface, были достигнуты новые разработки (см. DALLE-mini report ), и онлайн-демо теперь доступно по адресу DALLE-mini demo..

Усилия по репликации всё ещё далеко от достижения такой же производительности, как у оригинального DALLE, и, кажется, возможно пойти ещё дальше. Некоторые люди также хотят создать лучший CLIP для получения ещё лучшего сгенерированного искусства.

Большая часть результатов, которых мы можем достичь с такими моделями, обусловлена большим объёмом данных. До LAION-400M крупнейший открытый набор данных для пар (изображение, текст) составлял порядка 10М (см. DALLE-datasets ), что достаточно для обучения захватывающих моделей, но недостаточно для достижения наилучшей производительности. Наличие публичного набора данных с сотнями миллионов пар поможет создать эти модели изображение+текст.

Анализ данных LAION-400M

Мы разметили 3456 образцов набора данных и получили следующие результаты:

• Правильные положительные NSFW: 4
• Правильные отрицательные NSFW: 3371
• Ложноположительные NSFW: 73
• Ложноотрицательные NSFW: 8
• Плохие подписи: 3 (0,09 %)

Сопоставление отличное, благодаря CLIP. Мы могли бы улучшить автоматическую маркировку NSFW в будущем; однако общий уровень NSFW достаточно низок (меньше 1%), чтобы это не было проблемой.

Технические детали

Получение набора данных состоит из двух значимых частей:

• распределённая обработка огромных наборов данных Common Crawl (многих петабайт), которая создаёт коллекцию соответствующих URL и подписей
• более лёгкая пост-обработка на одном узле, которую может выполнить любой за несколько дней и которая создаёт итоговый набор данных

1. Распределённая обработка Common Crawl

Мы получаем сырые веб-данные для создания нашего набора данных из Common Crawl. Common Crawl — это некоммерческая организация, посвящённая предоставлению копии интернета исследователям, компаниям и частным лицам бесплатно для исследований и анализа. Они регулярно публикуют дампы данных, похожих на HTML, полученных из миллиардов общедоступных веб-сайтов, найденных на сайте Common Crawl. Для создания пар изображение‑текст мы просматриваем данные из Common Crawl и извлекаем все HTML-теги IMG, содержащие атрибут alt text. Common Crawl предоставляет данные в нескольких форматах. Для нашей цели мы выбрали формат WAT. Файлы WAT содержат только метаданные просканированных сайтов, включая все ссылки и теги IMG, содержащиеся на веб-странице. Парсинг только этих метаданных значительно быстрее, чем парсинг всего HTML‑текста (предоставляемого в формате WARC).

Загрузка оригинальных изображений

Мы загружаем сырые изображения из URL, полученных из Common Crawl, с помощью асинхронных запросов и библиотек Trio и Asks. Они позволяют нам использовать многопоточность на одном процессоре. Обычно домашнее интернет‑соединение исчерпывается одним или двумя процессорами. Узел дата‑центра может масштабироваться, используя гарантированную скорость интернета с пулом многопроцессорной обработки гораздо быстрее, чем узел с одним процессором. В данный момент мы смогли задействовать 50 ядер при полном защищённом соединении 1 Гбит/с с публичным интернетом. Эта пропускная способность должна быть доступна узлу загрузки, а не распределяться между множеством узлов или приложений. Мы оптимизировали скрипт по скорости, смягчая различные ошибки, с которыми столкнулись. Обычно, чтобы удовлетворить требовательный высокопроизводительный узел, подобный описанному выше, необходимо принять дополнительные меры для обеспечения кэширования DNS. Мы обнаружили, что knot‑resolver, запущенный с двумя процессами и настроенный с опцией кэширования, может решить эту проблему.

Фильтрация неподходящих пар изображение‑текст

После загрузки файлов WAT из Common Crawl мы фильтруем образцы следующими шагами:

• Мы отбросили все образцы с длиной альт‑текста менее пяти символов
• Мы отбросили все образцы с размером изображения менее 5 КБ
• Мы используем непрерывно обновляемые bloom‑фильтры для отбрасывания образцов, уже присутствующих в наборе данных. Bloom‑фильтры удаляют дубликаты путём конкатенации URL и альт‑текста.
• Мы используем непрерывно обновляемые bloom‑фильтры для отбрасывания образцов из URL, которые ранее таймаутились и, следовательно, кажутся недоступными (или хотя бы недоступными эффективно).
• Мы используем модель CLIP от OpenAI (версия ‘ViT-B-32‘) для вычисления эмбеддингов изображения и альт‑текста. Затем мы считаем косинусное сходство обоих векторов эмбеддингов и отбрасываем все образцы с сходством ниже 0,3. Мы выбрали этот порог после тестирования разных значений и использования оценок людей, насколько хорошо тексты соответствуют изображениям. Значения вроде 0,28 или 0,29 также казались приемлемыми во многих случаях, но после дополнительной проверки мы решили выбрать консервативное значение 0,3.
• Мы используем эмбеддинги CLIP изображений для оценки наличия NSFW‑содержимого. Для этого мы вычисляем эмбеддинги CLIP для списка категорий изображений, например «selfie», «illustration» или «landscape», которые также включают категории, указывающие на NSFW‑содержимое, такие как «porn» и «sex».
• Затем мы вычисляем косинусное сходство между эмбеддингом изображения, которое мы сейчас фильтруем, и каждым из этих ключевых слов категории. Если категория с наибольшим сходством и ключевое слово со вторым по величине сходством обе относятся к ключевым словам NSFW, мы помечаем образец как «NSFW». Если только одно из них относится к ключевому слову NSFW, мы классифицируем образец как «UNSURE». Если оба ключевых слова с наибольшим сходством не относятся к NSFW, мы помечаем образец как «UNLIKELY».
• На следующем шаге мы рассматриваем все образцы с меткой «NSFW» или «UNSURE» и отбрасываем те, в тексте которых встречаются любые ключевые слова, связанные с детьми, подростками или другим семантически связанным содержимым.
• На шаге 8 мы повторяем процедуру вычисления косинусного сходства из шага 6, но теперь используем тексты категорий, указывающие на содержимое, семантически связанное с детьми и подростками на уровне эмбеддингов CLIP. Если наибольшее сходство или второе по величине сходство между эмбеддингом изображения образца и текстом из предварительно вычисленных категорий относится к тексту, указывающему на содержимое, связанное с несовершеннолетними, мы отбрасываем этот образец.
• Наконец, мы повторяем процедуру из шага 8, используя тексты, семантически связанные с категориями животных, например «animal», «bird» и т.д.

Мы применяем эти строгие шаги фильтрации контента NSFW с потенциально незаконным содержимым, поскольку не можем гарантировать, что контент Common Crawl свободен от такого. Мы чувствуем себя обязанными сделать всё возможное, чтобы отфильтровать такой контент. Проверки образцов, отфильтрованных на этапах 7–9, показали, что наша процедура фильтрации очень консервативна и даёт много ложных срабатываний (образцов, которые она отбрасывает, но которые не являются проблематичными). Этот процесс приемлем, поскольку количество потенциальных образцов, ожидающих, пока мы их обработаем, огромно.

Системная архитектура

Для координации взаимодействия множества скриптов сканирования (называемых рабочими) в нашем проекте мы используем сервер, который отслеживает обработанные WAT-файлы и то, какой рабочий получает какой необработанный WAT. Мы называем этот координирующий сервер трекером. Его функции включают предоставление заданий как рабочим для загрузки, так и рабочим для вывода, подтверждение запросов на очистку от DL-стадии сервера, поддержание ACL для сервера Bloom и некоторые другие. Мы также используем несколько стадийных серверов в качестве буферов для заданий, которые находятся в пути к месту хранения. Стадии серверы постоянно обновляют фильтры в центральном сервере Bloom, где мы используем RedisBloom по соображениям высокой производительности.

Рабочий процесс

В ходе развития нашего проекта сканирования мы применили два различных рабочих процесса:

Этот рабочий выполняет все вычислительные шаги в течение одного задания, а затем передает результат на стадию сервера. Затем он ставит результаты в очередь для выпуска в зону хранения.

Вскоре мы обнаружили, что лучший способ использовать ресурсы — это разделить рабочую нагрузку на задачи CPU + сетевые задачи (этапы загрузки) и задачи GPU (этапы вывода CLIP). Таким образом, двухэтапный подход использует «CPU-рабочих» для загрузки изображений, создания пар изображение-текст и сохранения промежуточного результата на стадию сервера. Затем «GPU-рабочие» берут задания, объединяют несколько из них, чтобы сгруппировать около 20 000 пар в один файл с окончательным результатом. Двухэтапный рабочий процесс оказался наиболее эффективным, с скоростью до 25 миллионов пар, добавляемых в датасет в день, при использовании 100 CPU-рабочих с одним ядром и одного GPU-рабочего с графической картой NVidia RTX 3090, использующей все 16 линий шины PCIe. GPU-узел также нуждается примерно в 24 потоках CPU, чтобы поспевать за мощностью обработки GPU.

Удаление оповещений об злоупотреблениях

Во время загрузки мы столкнулись с оповещениями об злоупотреблениях от ручных и автоматизированных инструментов, которые защищают веб-сайты. После некоторого периода обучения мы сократили большинство проблем, используя эти методы смягчения:

• Самым эффективным на данный момент был способ использования централизованных фильтров Bloom, которые устраняют повторяющиеся запросы к дублирующимся URL-адресам. Конечно, эффективность этих фильтров резко зависит от того, насколько быстро они обновляются и используются рабочими. По определению, наличие нескольких рабочих для загрузки, выполняющих задания параллельно, делает их подверженными перекрывающимся запросам к одному и тому же URL-адресу, даже если фильтры Bloom обновлены в начале задания.
• Поэтому второй метод значительно сократил проблему параллельных рабочих путем рандомизации заданий на уровне сервера-трекера. При выполнении заданий последовательно (с использованием самых старых WAT-файлов из 2013 года) мы обнаружили, что соседние задания значительно перекрывались. Когда мы рандомизировали задания, мы увидели резкое уменьшение такого перекрытия.

Кто это запустил?

Мы хотим поблагодарить :

• людей из LAION, через множество рабочих узлов повсюду в облаке
• сообщество Reddit, хранящее данные
• а также всех наших друзей и родственников, которые не знали, чем они помогают

за запуск рабочих процессов для создания этого огромного датасета за несколько месяцев.

2. Постобработка датасета

После того, как распределенный конвейер завершил работу, в результате чего получился значительный датасет с подписью+URL, настало время упаковать его наилучшим образом. Цель этого второго конвейера — создать версию датасета, которая легко используется для мультимодального обучения. Для этого мы создали инструменты, которые любой может запустить из коллекции подписей+URL. Точная команда для запуска доступна в cah-prepro (которая использует в основном и clip-retrieval )

Предварительная обработка CSV-файлов с помощью Pyspark

После быстрого запуска скрипта для загрузки CSV-файлов первый шаг этого конвейера постобработки — это дедупликация по URL+подписи. Первый конвейер выполняет некоторую частичную дедупликацию с использованием фильтра Bloom, но это приблизительно, и некоторые дубликаты остаются. Выполнение этой постобработки с помощью Pyspark также позволяет сократить количество файлов метаданных со сотен тысяч до 32 файлов parquet размером 1,7 ГБ. См. этот скрипт дедупликации здесь. Pyspark был бы отличным способом для выполнения любой дальнейшей фильтрации, и мы provide предоставляем пример для вычисления некоторой статистики. Результатом является 32 файла parquet, содержащие столбцы, такие как URL, текст, NSFW, описанные в начале поста.

Img2dataset

Как только этот набор из 50 ГБ файлов parquet будет готов, мы сможем использовать инструмент для загрузки, изменения размера и хранения изображений и подписей в виде webdataset. Этот инструмент может загрузить 100 миллионов изображений за 20 часов на одном узле (1 Гбит/с, 32 ГБ оперативной памяти, 16 ядер i7), поэтому любой может запустить это для всего датасета или его меньшего подмножества. Формат, который выдает этот инструмент, — это коллекция tar-файлов (этот формат датасета называется webdataset), содержащих изображения, подписи, метаданные и соответствующие файлы parquet, содержащие те же метаданные

• 00000.tar размером 270 МБ, содержащий не более 10 000 образцов: 0.jpg (изображение), 0.txt (подпись), 0.json (метаданные, такие как URL, исходная ширина, данные EXIF, является ли изображение NSFW)
• 0.jpg
• 0.txt (подпись)
• 0.json (метаданные, такие как URL, исходная ширина, данные EXIF, является ли изображение NSFW)
• 00000.parquet размером 1,6 МБ, содержащий те же метаданные, что и JSON-файл. Полезно для вычисления статистики без чтения всех tar-файлов

Размер tar-файлов 270 МБ достигается при использовании опций img2dataset, указанных там download_images.sh (изменение размера всех изображений до 256×256 с паддингом для максимальной единообразности файлов и предотвращения потери информации). При использовании других опций у вас могут быть более крупные или более мелкие tar-файлы.

Извлечение CLIP и autofaiss

Наконец, цель tar-датасета — вычислить и упаковать эмбеддинги клипов, а также построить KNN-индекс для этих эмбеддингов. Инструмент clip-retrieval позволяет быстро вычислять 100 миллионов эмбеддингов за 20 часов с помощью одной видеокарты 3080, поэтому эту часть можно повторно запустить на всем датасете или его подмножестве с низкими затратами. Эмбеддинги хранятся в файлах NPY рядом с файлами parquet в том же порядке. Поскольку этот датасет гораздо меньше, чем датасет изображений, каждый файл NPY содержит 1 миллион образцов. Файлы NPY имеют размер 1 ГБ, а файлы parquet — 150 МБ. Всего таких файлов 400. Эти эмбеддинги помогают построить текстовый и изображенческий knn-индекс с помощью инструмента , что позволяет создать квантизованный индекс произвольного файла. Выбранный тип индекса составляет 6 ГБ, поэтому каждому легко загрузить его и выполнять быстрые (10 мс) запросы по всему датасету. Мы также сгенерировали другой тип индекса размером 16 ГБ. Благодаря мапингу памяти его также можно загрузить без использования оперативной памяти. Простая веб-демонстрация показывает результаты.

Лицензия

Мы распространяем датасет метаданных (файлы parquet) под самой открытой Creative Common CC-BY 4.0лицензией, которая не налагает особых ограничений. Изображения защищены авторским правом.

Участие

Вы можете внести вклад в проект, чтобы помочь нам выпустить следующие размеры датасета: 1 миллиард пар, 2 миллиарда пар и так далее.

Выберите один или несколько методов, которые подходят вам или вашей компании:

• пожертвуйте либо деньги, либо вычислительное время. Мы также запустили кампанию Go Get Funding.
• участвовать в разработке
• распространяйте информацию. В лучшем случае используйте датасет, получите хорошие результаты и упомяните его в своих статьях

Полезные ссылки:

• Прогресс датасета Crawling@Home Dashboard и leaderboard
• Пост в Reddit
• DALLE-PyTorch Discord сервер
• DALLE-PyTorch GitHub репозиторий

Спонсоры

Мы достигли этого благодаря щедрости следующих доноров: