Часть 1. Введение, архитектура модели и эксплуатационная инфраструктура

Как мы все знаем, слова обладают силой. Ими можно вдохновить людей, но можно и навредить. Мы в Badoo и Bumble стараемся оградить пользователей от неприятных ситуаций, поэтому внедрили инструмент Rude Message Detector. Это многоязычный детектор грубых высказываний, работающий на основе машинного обучения.

Благодаря детектору мы в режиме реального времени можем выявлять потенциально грубые сообщения и узнавать у пользователя, хочет ли он продолжить переписку
Благодаря детектору мы в режиме реального времени можем выявлять потенциально грубые сообщения и узнавать у пользователя, хочет ли он продолжить переписку

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

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

Архитектуры на основе трансформеров и базисные модели

С момента своего возникновения в 2017 году архитектуры на основе трансформеров превратились фактически в стандарт для наиболее совершенных приложений с обработкой естественного языка (Natural Language Processing, NLP). Как и рекуррентные нейросети, они спроектированы для обработки последовательных данных — когда очерёдность входящей информации влияет на её значение, например текст. Но у архитектур на основе трансформеров есть четыре важных отличия: 

  1. Они полностью избавлены от рекуррентности и свёрток.

  2. Нет необходимости обрабатывать данные в определённом порядке.

  3. Расширены возможности параллелизма.

  4. Они быстрее обучаются.

Всё это стало возможным благодаря механизму self-attention, способному вычислять относительную важность слов в предложениях, получая их как цельные входные данные. В этом - главное отличие архитектур на основе трансформеров от классических рекуррентных нейросетей, которые вычисляют взаимную важность слов и извлекают контекст серийно, слово за словом.

Трансформер состоит из энкодера и декодера
Трансформер состоит из энкодера и декодера

Архитектура на основе трансформеров позволяет обучать большие языковые модели, такие как BERT, GPT-2, GPT-3, которые после дообучения на конкретных задачах показывают лучшие результаты по сравнению с другими решениями. Доступность для AI-специалистов больших языковых моделей привела к переосмыслению возможностей масштабирования машинного обучения. Сегодня можно оперировать заранее обученными языковыми моделями: контекстные эмбеддинги уже дают прекрасное представление о входных необработанных признаках. 

Все эти вопросы недавно были рассмотрены во впечатляющей работе Центра исследований базисных моделей (Center for Research on Foundation Models, CRFM) в Стэнфорде. После определения понятия «базисные модели» в ней освещаются значимость и риски этого тренда, возникающие в основном из-за растущих возможностей этих больших, непонятных моделей и сложных архитектур, обученных на наборах данных невиданных размеров.

Архитектура и многоязычная проверка

XLM-RoBERTa (XLM-R) — превосходный пример базисной модели, оперирующей свыше 270 млн параметров и обученной на данных на 100 языках общим объёмом 2 ТБ. Для этого использовали 500 GPU в режиме самообучения (self-supervised). Маскированная языковая модель (Masked Language Model) прогнозирует наличие маскированного токена (masked token) во входном предложении. Она превзошла mBERT и продемонстрировала надёжную производительность при обработке языков с большим и малым количеством источников. Отсутствие языковых эмбеддингов во входных данных сделало эту модель подходящим вариантом для решения нашей задачи.

Перебрав разные опции с учётом бизнес-требований и производительности, мы осторожно адаптировали исходную архитектуру под трёхклассовую многометочную классификацию выражений, относящихся к оскорблениям по гендерным, расовым, классовым признакам. Чтобы убедиться в качестве данных и надёжности концепции, мы за семь месяцев собрали и разметили набор данных из 3 млн сообщений на более чем 15 языках. Для повышения качества разметки в такой деликатной задаче каждое сообщение проверялось несколькими людьми независимо друг от друга. Также мы выяснили, что ручная модерация помогает задать реалистичные исходные значения: если даже многочисленным сотрудникам трудно прийти к согласию в том или ином случае, то как можно ожидать уверенного решения от модели?

Языки мы добавляли последовательно каждую неделю, начав с английского и португальского. При этом мы отслеживали производительность модели на ранее добавленных языках и адаптировали гиперпараметры (batch size, learning rate, decay) постоянно растущего внутреннего набора данных. Этот гибкий подход оказался очень подходящим для управления AI-проектами такого масштаба. Он уже на самых ранних этапах оказывает влияние на процессы, позволяя управлять ожиданиями и облегчая приоритизацию новых языков.

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

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

Чтобы справиться с этими сложностями, мы реализовали валидационный процесс на основе решения TensorBoard, помогающего быстро находить возможности для улучшения обученной модели с помощью сравнения её текущего состояния с историческими и продакшен-версиями. После нескольких неудач и ошибок (да, такое случается) мы пришли к ограниченному набору метрик, которые нужно отслеживать, прежде чем запускать модель в эксплуатацию. Они тесно связаны с KPI, а также с требованиями и ограничениями процессов, запускаемых в зависимости от генерируемых моделью прогнозов.

Эксплуатационная инфраструктура и её влияние на бизнес

Благодаря партнёрству с нашими инженерами мы, команда Data Science, успешно разрабатываем различные решения на основе машинного обучения. Сейчас у нас есть набор внутренних сервисов для развёртывания и мониторинга моделей глубокого обучения на базе TensorFlow, обеспечивающих высокую производительность и полную наблюдаемость модели. Это помогло нам при работе над NLP-системой, рассматриваемой в этой статье, принимать взвешенные решения и сократить разрыв между проведением экспериментов и внедрением в эксплуатацию, что является распространённой проблемой для такого рода проектов.

Упрощённая архитектура внутреннего сервиса вывода результатов глубокого обучения
Упрощённая архитектура внутреннего сервиса вывода результатов глубокого обучения

Как и все модели на основе трансформеров, XLM-R требует ввода данных в виде токенов, но с применением немного изменённой версии популярного токенизатора SentencePiece. Чтобы воспользоваться нашим внутренним inference-движком, пришлось заново реализовать токенизатор для его запуска в качестве слоя в графе TensorFlow.

Нативная TensorFlow-реализация токенизатора требуется для XLM-RoBERTa. Она очень похожа на SentencePiece, но выполняет чуть больше действий над некоторыми токенами
Нативная TensorFlow-реализация токенизатора требуется для XLM-RoBERTa. Она очень похожа на SentencePiece, но выполняет чуть больше действий над некоторыми токенами

Нативная TensorFlow-реализация токенизатора требуется для XLM-RoBERTa. Она очень похожа на SentencePiece, но выполняет чуть больше действий над некоторыми токенами

Движок Rude Message Detector работает на нескольких GPU-нодах в двух географических зонах, он оптимизирует потребление ресурсов за счёт динамического батчинга входных данных. При необходимости мы можем поднимать и гасить ноды, подстраиваясь под изменения нагрузки на сервис. 

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

Заключение и планы

Мы стремимся сделать общение в наших приложениях максимально комфортным и безопасным. Но на пути улучшения пользовательского опыта нередко возникают трудности, особенно когда дело касается машинного обучения и обработки естественного языка. Мы создаём собственный многоязычный движок, способный защитить наших пользователей, на каком бы языке ни отправлялись оскорбительные сообщения. К счастью, в последние годы были разработаны впечатляющие архитектуры и методы, которые помогли нам в создании движка для Rude Message Detector.

Смена парадигмы в сфере искусственного интеллекта и безграничные возможности, которые он перед нами открывает, однако, могут повлечь за собой дополнительные трудности. Они могут быть связаны с нежелательными возможностями нейросетевых языковых моделей, обученных на непроверенном тексте из интернета. Примером может служить непредсказуемое поведение чат-ботов.

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

Комментарии (2)


  1. Andrey_Epifantsev
    02.02.2022 10:50

    А где-то можно постестить эту систему отдельно? И можно ли её заиспользовать в своём проекте?


    1. punkerpunker Автор
      02.02.2022 21:38

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