Чего мы хотим достичь?

Мы хотим классифицировать тексты по заранее определенным категориям, что является очень распространенной задачей в НЛП. В течение многих лет классическим подходом к простым документам было создание признаков с помощью TF-IDF и объединение его с логистической регрессией. Раньше мы полагались на этот стек в Sinequa для текстовой классификации, и, предупреждаем о спойлере, с моделью, представленной здесь, мы превзошли наш базовый уровень с 5% до 30% для очень шумных и длинных наборов данных документов. У этого первого подхода были две основные проблемы: разреженность функций, которую мы решили с помощью методов сжатия, и проблема сопоставления слов, которую мы решили, используя мощные лингвистические возможности Sinequa (в основном через наш доморощенный токенизатор).

Позже был открыт ящик языковых моделей (предварительно обученных на огромных корпусах неконтролируемым образом и отлаженных для последующих контролируемых задач), и методы, основанные на TF-IDF, больше не были современными. Такие языковые модели могут быть word2vec в сочетании с LSTM или CNN, ELMo и, что наиболее важно, Transformer (в 2017 году: https://arxiv.org/pdf/1706.03762.pdf).

BERT - это языковая модель на основе Transformer, которая за последние пару лет стала очень популярной, поскольку она намного превзошла все базовые показатели НЛП и стала естественным выбором для построения нашей классификации текстов.

В чем тогда проблема?

Языковые модели, основанные на преобразователях, такие как BERT, действительно хороши для понимания семантического контекста (где методы набора слов не работают), потому что они были разработаны специально для этой цели. Как объяснялось во введении, BERT превосходит все базовые уровни НЛП, но, как мы говорим в научном сообществе, «бесплатного обеда нет». Такое обширное семантическое понимание модели, как предлагает BERT, сопровождается серьезной оговоркой: она не может работать с очень длинными текстовыми последовательностями. По сути, это ограничение составляет 512 токенов (токен - это слово или подслово текста), которые представляют более или менее два или три абзаца Википедии, и мы, очевидно, не хотим рассматривать только такую ​​небольшую часть текста для классифицируйте это.

Чтобы проиллюстрировать это, давайте рассмотрим задачу классификации всеобъемлющих обзоров продуктов на положительные или отрицательные. Первые предложения или абзацы могут содержать только описание продукта, и, вероятно, потребуется пройти дальше по обзору, чтобы понять, нравится ли рецензенту продукт на самом деле или нет. Если наша модель не охватывает весь контент, сделать правильный прогноз может быть невозможно. Следовательно, одно из требований к нашей модели - захват контекста документа при правильном управлении долгосрочными зависимостями между предложениями в начале и в конце документа.

С технической точки зрения, основное ограничение - это объем памяти, который увеличивается квадратично с увеличением количества токенов, а также с использованием предварительно обученных моделей, которые имеют фиксированный размер, определяемый Google (и др.). Это ожидается, поскольку каждый токен «внимателен» [https://arxiv.org/pdf/1706.03762.pdf] ко всем другим токенам и, следовательно, требует матрицы внимания [N x N], где [N] - количество токенов. Например, BERT принимает максимум 512 токенов, что вряд ли можно квалифицировать как длинный текст. А превышение 512 токенов быстро достигает пределов даже современных графических процессоров.

Другая проблема, которая возникает при использовании Transformers в производственной среде, - это очень медленный вывод из-за размера моделей (110M параметров для базы BERT) и, опять же, квадратичной стоимости. Итак, наша цель - не только найти архитектуру, которая вписывается в память во время обучения, но и найти такую, которая также достаточно быстро реагирует на логический вывод.

Последняя задача, которую мы здесь решаем, - это построить модель, основанную на различных типах функций: разумеется, длинном тексте, но также и дополнительных текстовых метаданных (таких как заголовок, аннотация…) и категориях (местоположение, авторы…).

Итак, как работать с действительно длинными документами?

Основная идея состоит в том, чтобы разбить документ на более короткие последовательности и передать эти последовательности в модель BERT. Мы получаем вложение CLS для каждой последовательности и объединяем вложения. Есть несколько возможностей выполнить слияние, с которыми мы экспериментировали:

  • Сверточные нейронные сети (CNN)
  • Сети с долгой краткосрочной памятью (LSTM)
  • Трансформеры (в совокупности Трансформеры, да :))

Наши эксперименты с различными стандартными корпусами классификации текстов показали, что использование дополнительных слоев Transformer для слияния произведенных встраиваний работает лучше всего без больших вычислительных затрат.

Хотите формальное описание, верно?

Мы рассматриваем задачу классификации текста с метками L. Для документа D его токены, заданные токенизацией WordPiece, можно записать X = (x₁,…, xₙ) с N общее количество токенов в D. Пусть K - максимальная длина последовательности (до 512 для BERT). Пусть I будет количеством последовательностей из K токенов или меньше в D, оно равно I = ⌊ N / K ⌋.

Обратите внимание, что если последняя последовательность в документе имеет размер меньше K, она будет дополнена 0 до индекса Kᵗʰ. Тогда если s ⁱ с i ∈ {1, .., I}, является i -ой последовательностью с элементами K в D у нас есть:

Отметим, что

BERT возвращает вложение CLS, но также вложение для каждого токена.

Давайте определим вложения для каждого токена, возвращаемого BERT для i-й последовательности документа, например:

где CLS - это вложение специального токена, вставляемого перед каждой текстовой последовательностью, подаваемой в BERT, это обычно рассматривается как вложение, суммирующее полную последовательность.

Для объединения последовательностей мы используем только CLSᵢ и не используем y. Мы используем преобразователи t T₁,…, Tₜ, чтобы получить окончательный вектор для передачи на последний плотный слой сети:

где ∘ - операция композиции функции.

Учитывая веса последнего плотного слоя W ∈ ℝᴸˣᴴ, где H - скрытый размер трансформатора и смещение b ∈ ℝᴸ

Вероятности P ∈ ℝᴸ задаются следующим образом:

Наконец, применение argmax к вектору P возвращает предсказанную метку. Краткое изложение вышеупомянутой архитектуры вы можете увидеть на рисунке 1.

Вышеупомянутая архитектура позволяет нам использовать BERT для задачи классификации текста, минуя ограничение максимальной длины последовательности преобразователей, в то же время сохраняя контекст в нескольких последовательностях. Давайте посмотрим, как совместить это с другими типами функций.

Как работать с метаданными?

Часто документ содержит больше, чем просто его содержание. Могут быть метаданные, которые мы разделим на две группы: текстовые метаданные и категориальные метаданные.

Текстовые метаданные

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

Для документа с аннотацией метаданных M. Позволять

быть вложениями CLS, созданными BERT для каждого метаданного. Тот же метод, что и выше, используется для получения вектора вероятности как:

Категориальные метаданные

Категориальные метаданные могут быть числовыми или текстовыми значениями, представляющими категорию. Числовые значения могут быть количеством страниц, тогда как текстовые значения могут быть именем издателя или географическим местоположением.

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

Мы кодируем категориальные метаданные в один вектор кросс-категорий, используя одноразовое кодирование. Затем это кодирование передается на уровень внедрения, который изучает векторное представление для каждой отдельной категории. Последним шагом является нанесение объединяющего слоя на полученную матрицу внедрения.

Мы рассмотрели максимальное, среднее и минимальное объединение и обнаружили, что использование среднего пула лучше всего подходит для наших тестовых корпусов.

Как выглядит полная архитектура?

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

Есть три подмодели: одна для текста, другая для текстовых метаданных и последняя для категориальных метаданных. Выходные данные трех подмоделей просто объединяются в один вектор перед тем, как передать его через слой исключения и, наконец, в последний плотный слой с активацией softmax для классификации.

Вы, наверное, заметили, что в архитектуре изображено несколько экземпляров BERT не только для ввода текста, но и для текстовых метаданных. Поскольку BERT имеет множество параметров для обучения, мы решили не включать отдельную модель BERT для каждой подмодели, а вместо этого разделять веса одной модели между подмоделями. Совместное использование весов, безусловно, уменьшает ОЗУ, используемое моделью (позволяя обучение с большим размером пакета, что в некотором смысле ускоряет обучение), но это не меняет время вывода, поскольку выполнения BERT по-прежнему будет столько же, независимо от того, являются ли их веса поделился или нет.

А как насчет времени вывода?

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

Пара примечаний к проведенным экспериментам:

  • Мы рассматриваем упрощенную модель, содержащую только текст.
  • Мы ограничили количество токенов, которые мы использовали для каждого документа, до 25 600 токенов, что примерно соответствует примерно 130 000 символов, если документ содержит текст на английском языке.
  • Мы проводим эксперименты с документами, максимальная длина которых описана выше. На практике документы имеют разные размеры, и поскольку мы используем тензоры динамического размера в нашей модели, время вывода для коротких документов значительно сокращается. Как показывает практика, при использовании документа, который вдвое короче, время вывода сокращается на 50%.

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

  1. Https://arxiv.org/abs/2006.04152, https://arxiv.org/pdf/2001.08950.pdf
  2. Https://blog.tensorflow.org/2020/04/tfrt-new-tensorflow-runtime.html
  3. Https://www.tensorflow.org/xla?hl=fr
  4. Https://medium.com/microsoftazure/accelerate-your-nlp-pipelines-using-hugging-face-transformers-and-onnx-runtime-2443578f4333

Что еще делать?

Линейные трансформаторы

Построение архитектуры, подобной трансформатору, которая не имеет квадратичной сложности по времени и памяти, в настоящее время является очень активной областью исследований. Есть несколько кандидатов, которых определенно стоит попробовать, когда будут выпущены предварительно обученные модели:

Предварительные испытания с очень многообещающей моделью Longformer не прошли успешно. Мы попытались обучить модель LongFormer, используя реализацию Hugging Face в TensorFlow. Однако похоже, что реализация еще не оптимизирована для памяти, так как ее невозможно было обучить даже на большом графическом процессоре с 48 ГБ памяти.

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

Мы уже закончили?

Да, спасибо, что оставались с нами до конца. Если у вас есть вопросы или замечания о нашей модели, не стесняйтесь комментировать. Мы были бы рады получить известия от вас.