Суть

Оказывается для этого достаточно запуcтить всего лишь такой набор команд:

git clone https://github.com/attardi/wikiextractor.git
cd wikiextractor
wget http://dumps.wikimedia.org/ruwiki/latest/ruwiki-latest-pages-articles.xml.bz2
python3 WikiExtractor.py -o ../data/wiki/ --no-templates --processes 8 ../data/ruwiki-latest-pages-articles.xml.bz2

и потом немного отполировать скриптом для пост-процессинга

python3 process_wikipedia.py

Результат — готовый .csv файл с вашим корпусом.

Понятное дело, что:

• http://dumps.wikimedia.org/ruwiki/latest/ruwiki-latest-pages-articles.xml.bz2 можно поменять на нужный вам язык, больше деталей тут [4];
• Всю информацию о параметрах wikiextractor можно найти в мануале (кажется даже официальная дока не обновлялась, в отличие от мана);

Скрипт с пост-процессингом конвертирует вики файлы в такую таблицу:

article_uuid — псевдо-уникальный ключ, порядок предложений по идее должен сохраниться после такого пре-процессинга.

Зачем

Пожалуй, на настоящий момент развитие ML-инструментов достигло такого уровня [8], что для построения работающей NLP модели / пайплайна достаточно буквально пары дней. Проблемы возникают только при отсутствии надежных датасетов / готовых эмбеддингов/ готовых языковых моделей. Цель данной статьи — немного облегчить вашу боль, показав, что для обработки всей Википедии (по идее самого популярного корпуса для тренировки эмбеддингов слов в NLP) хватит и пары часов. В конце концов, если достаточно пары дней, чтобы построить простейшую модель, зачем тратить куда больше времени на получение данных для этой модели?

Принцип работы скрипта

wikiExtractor сохраняет статьи из Вики в виде текста, разделенного <doc> блоками. Собственно, в основе скрипта лежит следующая логика:

• Берём список всех файлов на выходе;
• Делим файлы на статьи;
• Удаляем все оставшиеся HTML теги и специальные символы;
• С помощью nltk.sent_tokenize разделяем на предложения;
• Чтобы код не разросся до огромных размеров и остался читаемым, каждой статье присваиваем свой uuid;

В качестве препроцессинга текста просто (можно легко перепилить под себя):

• Удаляем небуквенные символы;
• Удаляем стоп-слова;

Датасет есть, что теперь?

Основное применение

Чаще всего на практике в NLP приходится сталкиваться с задачей построения эмбеддингов.

Для ее решения обычно используют один из следующих инструментов: :

• Готовые векторы / эмбеддинги слов [6];
• Внутренние состояния CNN, натренированных на таких задачах как, как определение фальшивых предложений / языковое моделирование / классификация [7];
• Комбинация выше перечисленных методов;

Кроме того, уже много раз было показано [9], что в качестве хорошего бейслайна для эмбеддингов предложений можно взять и просто усредненные (с парой незначительных деталей, которые сейчас опустим) векторы слов.

Другие варианты использования

• Используем случайные предложения из Вики в качестве негативных примеров для triplet loss-а;
• Обучаем энкодеры для предложений с помощью определения фальшивых фраз [10];

Немного графиков для русской Вики

Распределение длины предложений для Русской Википедии

Без логарифмов (по оси X значения ограничены числом 20)

В десятичных логарифмах

Ссылки

1. Fast-text векторы слов, натренированные на Вики;
2. Fast-text и Word2Vec модели для русского языка;
3. Потрясающая wiki extractor библиотека для питона;
4. Официальная страница с ссылками для Вики;
5. Наш скрипт для пост-процессинга;
6. Основные статьи про эмбеддинги слов: Word2Vec, Fast-Text, тюнинг;
7. Несколько текущих SOTA подходов:
   1. InferSent;
   2. Generative pre-training CNN;
   3. ULMFiT;
   4. Контекстные подходы для представления слов (Elmo);
8. Imagenet moment в NLP?
9. Бейслайны для эмбеддингов предложений 1, 2, 3, 4;
10. Определение фальшивых фраз для энкодера предложений;

Автор: Alexander

Источник