DistilBERT против LSTM, с исследованием данных

Методы машинного обучения (ML) для обработки естественного языка (NLP) в наши дни дают впечатляющие результаты. Такие библиотеки, как Keras, PyTorch и HuggingFace NLP, делают применение последних исследований и моделей в этой области (относительно) простой задачей. В этой статье я реализую и сравниваю две разные архитектуры модели классификатора на основе NLP, используя данные системы отслеживания проблем браузера Firefox.

Ранее я построил аналогичный классификатор отчетов о проблемах. Тогда я обнаружил, что основанная на глубоком обучении архитектура модели LSTM (Long-Short-Term-Memory) очень хорошо справляется с этой задачей. Позже я добавил Механизм внимания поверх LSTM, улучшив результаты. Этот LSTM с вниманием — первый тип модели, который я выбрал для этой статьи.

Второй тип моделей — Трансформеры. Трансформеры стали очень популярны в НЛП за последние несколько лет, и их популярность породила множество вариантов. В этой статье я хотел получить представление о том, как они соотносятся с подходом LSTM, который я применял ранее.

В качестве модели-трансформера использую HuggingFace (HF) DistilBERT. Для LSTM я использую Keras с его слоями LSTM и Внимание с открытым исходным кодом. Я обучаю их обоих предсказывать, какому компоненту должен быть назначен входящий отчет об ошибке Firefox. Идея заключалась бы в том, чтобы помочь в задачах сортировки отчетов об ошибках.

Получение данных

Как уже было сказано, я использую трекер проблем для браузера Firefox в качестве источника своих данных. Поскольку я никоим образом не связан с Mozilla браузера Firefox, я просто использовал их Bugzilla REST API для его загрузки. В сценарии, где вы фактически работали бы в своей компании или с партнерской организацией, вы, вероятно, также могли бы просто внутренне запросить получение данных в виде прямого дампа из базы данных. Но иногда нужно просто найти способ. В данном случае это было довольно просто, с общедоступным API для поддержки загрузки. Вы можете найти код загрузчика на моем Github. Это всего лишь простой скрипт для загрузки данных по частям.

Изучение и очистка данных

Общие данные, которые я использую, содержат следующие атрибуты для каждой проблемы:

  • ID: уникальный номер проблемы, по всей видимости, для всех проблем продукта Firefox/Mozilla (не только для браузера).
  • Сводка: краткое описание проблемы. Это одно из текстовых полей, которые я буду использовать в качестве функций классификатора.
  • Описание: более подробное описание проблемы. Это другое текстовое поле, которое я буду использовать в качестве функций для классификатора.
  • Компонент: программный компонент в архитектуре браузера Firefox, которому была назначена проблема. Это будет моя цель прогнозирования и, следовательно, метка для обучения классификатора.
  • Повторяющийся номер выпуска, если он есть
  • Создатель: адрес электронной почты, имя, идентификатор пользователя и т. д.
  • Серьезность: от тривиальной до критической/блокирующей или от S1 до S4. Или какие-то случайные значения. Когда я смотрел на это, это выглядело как беспорядок :).
  • Последнее изменение (время изменения)
  • Ключевые слова: очевидно, вы можете выбрать любые ключевые слова, которые вам нравятся. Я нашел 1680 уникальных значений.
  • Статус: один из вариантов решено, проверено, ново, не подтверждено, повторно открыт или назначен
  • Решение: одно из следующих: Дубликат, исправлено, рабочая форма, неполное, недействительный, неисправляемый, истек срок действия, неактивный или перемещенный
  • Статус Open/Closed: 18211 открытых, 172552 закрытых на момент загрузки.

Выбор функций для предиктора

Моя цель состояла в том, чтобы создать классификатор, назначающий отчеты об ошибках компонентам на основе их описания на естественном языке. Первым полем, которое я рассмотрел для этого, было, естественно, поле description. Однако для этой цели есть еще одно такое же интересное поле — поле summary.

Глядя на значения, я могу просто увидеть, что есть некоторые отчеты о проблемах без (или пустого) описания:

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

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

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

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

Выбор компонентов для прогнозирования

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

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

Давайте посмотрим детали:

Это дает следующий список:

General                                 64153
Untriaged                               18207
Bookmarks & History                     13972
Tabbed Browser                           9786
Address Bar                              8120
Preferences                              6882
Toolbars and Customization               6701
Theme                                    6442
Sync                                     5930
Menus                                    4440
Session Restore                          4205
Search                                   4171
New Tab Page                             4132
File Handling                            3471
Extension Compatibility                  3371
Security                                 3277
Shell Integration                        2610
Installer                                2504
PDF Viewer                               2193
Keyboard Navigation                      1808
Messaging System                         1561
Private Browsing                         1494
Downloads Panel                          1264
Disability Access                         998
Protections UI                            984
Migration                                 964
Site Identity                             809
Page Info Window                          731
about:logins                              639
Site Permissions                          604
Enterprise Policies                       551
Pocket                                    502
Firefox Accounts                          451
Tours                                     436
WebPayments UI                            433
Normandy Client                           409
Screenshots                               318
Translation                               212
Remote Settings Client                    174
Top Sites                                 124
Headless                                  119
Activity Streams: General                 113
Normandy Server                            91
Nimbus Desktop Client                      83
Pioneer                                    73
Launcher Process                           67
Firefox Monitor                            61
Distributions                              56
Activity Streams: Timeline                 25
Foxfooding                                 22
System Add-ons: Off-train Deployment       15
Activity Streams: Server Operations         5

Количество проблем на компонент довольно сильно разбросано, а распределение сильно асимметрично (Общие имеют почти больше назначенных отчетов, чем все остальные вместе взятые). В частности, некоторые компоненты имеют очень мало отчетов, и, вероятно, любой классификатор не справится с ними.

Во-первых, давайте посмотрим, смогу ли я найти какие-либо компоненты, которые могут быть устаревшими и могут быть удалены. Это может произойти со временем по мере развития тестируемого программного обеспечения, когда некоторые функции (и их компоненты) будут удалены. Один из способов посмотреть на это — найти компоненты, которые долгое время не проявляли активности. Следующее должно показывать последнюю дату, когда для компонента была создана задача:

component
Activity Streams: Timeline              2016-09-14T14:05:46Z
Activity Streams: Server Operations     2017-03-17T18:22:07Z
Activity Streams: General               2017-07-18T18:09:40Z
WebPayments UI                          2020-03-24T13:09:16Z
Normandy Server                         2020-09-21T17:28:10Z
Extension Compatibility                 2021-02-05T16:18:34Z
Distributions                           2021-02-23T21:12:01Z
Disability Access                       2021-02-24T17:35:33Z
Remote Settings Client                  2021-02-25T17:25:41Z
System Add-ons: Off-train Deployment    2021-03-23T13:58:13Z
Headless                                2021-03-27T21:15:22Z
Migration                               2021-03-28T16:36:08Z
Normandy Client                         2021-04-01T21:14:52Z
Firefox Monitor                         2021-04-05T16:47:26Z
Translation                             2021-04-06T17:39:27Z
Tours                                   2021-04-08T23:26:27Z
Firefox Accounts                        2021-04-10T14:17:25Z
Enterprise Policies                     2021-04-13T02:38:53Z
Shell Integration                       2021-04-13T10:01:39Z
Pocket                                  2021-04-15T02:55:12Z
Launcher Process                        2021-04-15T03:10:09Z
PDF Viewer                              2021-04-15T08:13:57Z
Site Identity                           2021-04-15T09:20:25Z
Nimbus Desktop Client                   2021-04-15T11:16:11Z
Keyboard Navigation                     2021-04-15T14:40:13Z
Installer                               2021-04-15T15:06:46Z
Page Info Window                        2021-04-15T19:24:28Z
about:logins                            2021-04-15T19:59:31Z
Site Permissions                        2021-04-15T21:33:40Z
Bookmarks & History                     2021-04-16T09:43:36Z
Downloads Panel                         2021-04-16T11:39:07Z
Protections UI                          2021-04-16T13:25:27Z
File Handling                           2021-04-16T13:40:56Z
Foxfooding                              2021-04-16T14:08:35Z
Security                                2021-04-16T15:31:09Z
Screenshots                             2021-04-16T15:35:25Z
Top Sites                               2021-04-16T15:56:26Z
General                                 2021-04-16T16:36:27Z
Private Browsing                        2021-04-16T17:17:21Z
Tabbed Browser                          2021-04-16T17:37:16Z
Sync                                    2021-04-16T18:53:49Z
Menus                                   2021-04-16T19:42:42Z
Pioneer                                 2021-04-16T20:58:44Z
New Tab Page                            2021-04-17T02:50:46Z
Messaging System                        2021-04-17T14:22:36Z
Preferences                             2021-04-17T14:41:46Z
Theme                                   2021-04-17T17:45:09Z
Session Restore                         2021-04-17T19:22:53Z
Address Bar                             2021-04-18T03:10:06Z
Toolbars and Customization              2021-04-18T08:16:27Z
Search                                  2021-04-18T09:04:40Z
Untriaged                               2021-04-18T10:36:19Z

Приведенный выше список отсортирован по времени, и все три компонента, связанные с «Потоки активности», имеют последние задачи, назначенные им 4–5 лет назад. При этом я добавил их в список компонентов, которые нужно удалить из набора данных. Кажется бессмысленным назначать им какие-либо новые проблемы с этой временной шкалой.

Компонент Ленты активности: временная шкала также был одним из компонентов в предыдущем списке, которому было назначено наименьшее количество задач. Двумя другими компонентами, создавшими очень мало проблем, были Foxfooding и Системные надстройки: внесистемное развертывание. Поскольку проблемы для компонента перечислены в хронологическом порядке, просмотр последних нескольких в обоих из них должен дать некоторое представление об их недавней активности.

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

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

Foxfooding описывается в системе отслеживания проблем Firefox как сбор проблем для последующей сортировки. Глядя на него, он показывает только последние проблемы. Я предполагаю, что более старые, возможно, были сортированы. Без дальнейших знаний я оставил его в наборе данных. Имея лучший доступ к экспертам в предметной области, я мог бы удалить его, поскольку похоже, что фактические проблемы в нем могут принадлежать многим другим компонентам (и перемещены после сортировки). Но я ожидаю, что это не имеет большого значения, поскольку в нем есть только несколько проблем.

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

Интерфейс WebPayments, кажется, начал тихо, привлек некоторое внимание и снова успокоился. В последний раз это внимание было обращено чуть более года назад, с сегодняшнего дня, в марте 2020 года. Я не знаю, актуально ли это до сих пор, поэтому я просто оставил его.

Наконец, список компонентов, которые я удалил для обучения в результате этого краткого анализа, был следующим:

  • Системные дополнения: внесистемное развертывание
  • Ленты активности: хронология
  • Ленты активности: операции сервера
  • Ленты активности: общие

Остальные компоненты, похоже, по-прежнему актуальны. В результате у меня осталось 48 целевых компонентов из исходных 52. Я обучил начальный набор моделей с этими 48 целевыми компонентами. Немного посмотрев на результаты, я удалил еще один компонент. Вы уже поняли, какой именно?

Это Untriated. Потому что untriaged — это просто список проблем, которые еще не назначены другим компонентам. Таким образом, с точки зрения машинного обучения эти проблемы не помечены. Насколько я понимаю, сохранение их в тренировочном наборе может только запутать обученный классификатор. Поэтому для дальнейших итераций обучения я также удалил задачи, назначенные Untriaged, оставив 47 целевых компонентов (меток).

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

Приведенный выше список показывает, что самая старая открытая и не проверенная проблема возникла более 20 лет назад (на момент написания этой статьи). В нем обсуждается правильный способ сокращения «секунды». По моему опыту, именно так со временем развиваются системы отслеживания проблем в проектах. Никто не хочет сказать, что эта проблема не имеет значения, и закрыть ее, но никто не хочет прилагать усилия или решать, что с ней делать. Или примите жару за слегка не относящееся к делу решение. А может просто забыли.

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

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

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

Обучение моделей

В этом разделе я кратко опишу модели, которые я использовал, и общий процесс, который я применил. Для некоторой уверенности в стабильности обучения я повторил обучение 10 раз для обеих моделей со случайно перемешанными данными. Общий набор данных, который я использовал, содержит 172556 строк данных (отчеты о проблемах) после удаления пяти компонентов, описанных выше.

Взгляд на модели

Во-первых, модели.

Керас LSTM

Записную книжку по настройке модели Keras LSTM и ее запуску можно найти на моем Github. Сводная функция Keras показывает структуру:

Входной слой принимает максимум 512 словесных токенов. Они поступают в слой встраивания слов на основе Перчатки, который преобразует входную последовательность токенов в 300-мерный вектор встраивания. Далее следует двунаправленный уровень LSTM, который имеет 128 узлов. Далее следует слой самостоятельного внимания, который направляет вывод внимания на другой двунаправленный уровень LSTM, который имеет 64 узла. Вывод отсюда поступает в слой взвешенного внимания, который передает его в последний выходной слой Dense. Много причудливых слов, если вы не знакомы с ним, но не беспокойтесь. В конце концов, им просто пользоваться, и будут представлены практические результаты.

Я рекомендую проверить документы слоя для получения дополнительной информации, если это интересно.

HuggingFace DistilBERT

HuggingFace DistilBERT больше похож на черный ящик. Блокнот для обучения и тестирования также есть у меня на Гитхабе. Резюме Keras для него дает:

Я предполагаю, что это какая-то пользовательская реализация Tensorflow в одном слое с точки зрения Keras. Соответствует моим предыдущим попыткам прочитать обо всех архитектурах трансформаторов, где все быстро расходятся во всех подробных деталях от общего имени высокого уровня, и мне остается только удивляться, почему никто не может предоставить понятную и интуитивно понятную промежуточный вид. Так или иначе. Визуальное представление этого в виде прямоугольников и стрелок в Keras еще лучше:

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

Выборка данных

Я разделил набор данных в каждом случае на 3 части. Модель была обучена на 70% данных (обучающая выборка), или на 124126 отчетах о проблемах. 20%, или 31032 отчета о проблеме (проверочный набор), использовались для оценки производительности модели во время обучения. 10%, или 17240, выдают отчеты для оценки окончательной модели после завершения обучения (набор тестов). Выборка в каждом случае была стратифицирована, что дало равную долю различных целевых компонентов в каждом наборе данных обучения, проверки и тестирования.

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

Точность обучения по эпохам

На следующих рисунках показаны потери и точность обучения для обучения моделей на одном наборе выборочных данных для обеих моделей. Первый тренинг HuggingFace для DistilBERT:

Я настроил тренажер HuggingFace для оценки модели через каждые 500 шагов, обеспечивая график с высокой степенью детализации выше. При том количестве данных, которое я использовал, и размере пакета 16, количество шагов в обучении HF за 3 эпохи составило 22881. На каждых 500 из них выполнялась оценка, и она показана точкой на графике выше. Как показано на рисунке, обучение было довольно последовательным, но выровнялось примерно на этапе 2.

Показатели обучения Keras LSTM за эпоху показаны ниже:

На этом рисунке эпоха 0,0 — это эпоха 1, а 1,0 — эпоха 2 и так далее. Это просто из-за того, как я использовал для этого массив с нулевым индексом. Название test также на самом деле относится к моему набору проверки в этом случае, я всегда путаю термины. Извини за это. Что еще более важно, я обучал эту модель для 4 эпох, и каждая точка на этом рисунке показывает результат оценки после эпохи. Проверка этой модели всегда достигала пика в эпоху 2.

Результаты

Результаты, пожалуй, самая интересная часть. В следующей таблице показаны 10 различных прогонов, в которых классификаторы LSTM и Transformer обучались на разных вариантах набора данных, как описано ранее:

Каждая строка в таблице — это отдельная тренировка на разных случайных перетасовках данных. В таблице есть следующие столбцы:

  • hf_best_epoch: эпоха, когда были зарегистрированы самые низкие потери (для проверочного набора) для HF. В Керасе это всегда была эпоха 2, поэтому я не включал для нее столбец.
  • hf_val_loss: потеря проверочного набора в hf_best_epoch, указанная HF.
  • hf_val_acc: точность набора проверки соответствует той же точке, что и hf_val_loss.
  • k_val_loss: потери набора проверки в конце наилучшей эпохи, заданные Керасом.
  • k_val_acc: точность проверочного набора в той же точке, что и k_val_loss.
  • hf1_test_acc: точность HF при использовании наилучшей модели для прогнозирования целевого компонента и использовании только верхнего прогноза.
  • k1_test_acc: то же, что и hf1_test_acc, но для модели Keras.
  • hf5_test_acc: то же, что и hf1_test_acc, но с учетом того, соответствует ли какой-либо из 5 лучших прогнозов правильному ярлыку. Думайте об этом как о предоставлении пользователю, проводящему сортировку, 5 основных предложений по компонентам, которым можно назначить проблему.
  • k5_test_acc: то же, что и h5_test_acc, но для модели Keras.

Сравнение точности в трансформаторах и LSTM

Результаты из приведенной выше таблицы совершенно ясны, и версия Transformer превосходит версию LSTM в каждом случае. Разница в точности предсказания топ-1 составляет около 0,72 против 0,75, или 72% против 75% в пользу архитектуры Transformer. Для топ-5 разница составляет около 96% против 97% точности. Разница в потерях составляет около 0,91 против 0,84, опять же в пользу трансформатора.

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

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

Более глубокий взгляд на ошибочные классификации

Помимо слепого взгляда на значения точности или даже на значения потерь, часто весьма полезно посмотреть немного глубже на то, что классификатор понял правильно, а что нет. То есть то, что неправильно классифицируется. Посмотрим.

Далее я представлю несколько таблиц по моделям и их ошибочным классификациям. Эти таблицы содержат следующие столбцы:

  • всего: общее количество отчетов о проблемах для этого компонента во всем наборе данных.
  • test_total: количество отчетов о проблемах для этого компонента в наборе тестов.
  • fails_act: количество проблем для этого компонента, которые были ошибочно классифицированы как что-то другое. Например, было 1000 отчетов о проблемах, которые на самом деле относились к компоненту Общие, но классифицировались как что-то другое.
  • fails_pred: количество проблем, предсказанных для этого компонента, но фактически возникших для другого компонента. Например, 1801 проблема была предсказана как Общая, но их правильная метка была каким-то другим компонентом.
  • total_pct: значение столбца total_pct, разделенное на общее количество выпусков (172556). Процент, который представляет этот компонент от всех выпусков.
  • test_pct: то же, что и total_pct, но для набора тестов.
  • act_pct: сколько процентов от test_total составляет fails_act.
  • pred_pct: сколько процентов от test_total составляет fails_pred.

Ошибки классификации прогнозов Keras LSTM Top-1

Во-первых, статистика отказов для классификатора Keras LSTM и его первые 1 прогнозы:

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

Что-то, что я нахожу здесь несколько неожиданным, заключается в том, что, несмотря на то, что General гораздо чаще встречается в наборе проблем, ему не приписывают слишком большую долю ошибочно классифицированных проблем (act_pct + pred_pct). Часто такая доминирующая метка в обучающем наборе также доминирует в прогнозах, но приятно видеть, что в данном случае это не так уж и плохо.

Вместо этого в этом списке есть другие, которые больше выделяются. Например, Интеграция с оболочкой выглядит довольно плохо: 83% (217 из 261) фактических проблем набора тестов неправильно классифицированы для какого-либо другого компонента (act_pct). Можно было бы подумать, что это связано с меньшим количеством проблем в обучающем наборе, но многие компоненты с еще меньшим количеством проблем намного лучше. Например, тот, что виден в таблице выше, Installer, имеет только 32% (act_pct) коэффициент сбоев.

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

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

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

Keras LSTM Топ-5 ошибочных классификаций прогнозов

Помимо прогнозов топ-1, я также собрал прогнозы топ-5. Top-5 означает, что 5 предсказанных компонентов считаются проблемой, и считается, что прогноз правильный, если любой из этих 5 является ожидаемым (правильным) ярлыком. Ниже приведены аналогичные статистические данные для топ-5, как и для топ-1:

В остальном это похоже на top-1, но столбец fails_pred имеет большие значения, потому что для каждого отчета о проблеме было подсчитано 5 прогнозов. Таким образом, даже если один из 5 был правильным, остальные 4 будут рассчитаны здесь в fails_pred.

По остальным значениям результаты явно лучше для топ-5, чем для топ-1. Например, General имеет значение fails_act всего 3, в то время как в топ-1 оно равно 1000. Вероятно, из-за своего доминирующего размера он попадает во многие топ-5. Это снижение с 1000 до 3 является большим улучшением, но общая точность топ-5 составляет всего 97%, а не 99,9%, поскольку компоненты с меньшим количеством экземпляров по-прежнему получают большее количество неправильных классификаций. Например, интеграция с оболочкой по-прежнему имеет около 17 % act_pct, даже если первое место сократилось до пятого. Гораздо лучше, но тоже почти не 0% отказов.

Ошибки в классификации HuggingFace DistilBERT Top-1

Давайте перейдем к результатам DistilBERT для прогноза топ-1. Опять же, подробности смотрите в моем Блокноте Github и два скрипта к нему. Общие значения для этой модели явно лучше, чем для LSTM, как было показано ранее в общей статистике. Однако я вижу в этом несколько иную тенденцию по сравнению с LSTM. Эта модель лучше сбалансирована.

Количество неудачных прогнозов для доминирующего компонента General выше, чем для модели LSTM. Например, fails_act здесь равно 1063, в то время как в топ-1 модели LSTM это было 1000. Однако, поскольку общая точность для этой модели была немного лучше (72% LSTM против 75% для этой ), это уравновешивается другими компонентами, имеющими более высокие оценки. Это то, что я имею в виду под более сбалансированным. Ошибки менее сосредоточены на нескольких компонентах.

Например, fails_act для неприятной Shell Integration здесь для DistilBERT упал до 185, в то время как в результатах LSTM он был 217. Все еще не отлично, но намного лучше, чем LSTM. Большинство других компонентов также ниже, за некоторыми исключениями. Так что эта модель кажется в целом более точной, но и более сбалансированной.

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

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

Топ-5 ошибочных классификаций прогнозов HuggingFace DistilBERT

И результаты для топ-5 DistilBERT:

Подобно топ-1, этот имеет более высокий fails_act для General, но в основном более низкий для остальных, что приводит к более сбалансированному результату, наряду с более высоким общая точность (96% LSTM против 97% у этой модели/DistilBERT).

Краткий обзор различий между моделями

Результаты, которые я представил, вероятно, могут быть немного оптимизированы. Я не проводил никакой оптимизации гиперпараметров или настройки архитектуры модели, поэтому я предполагаю, что и модель LSTM, и модель Transformer могли быть дополнительно оптимизированы. Также может быть полезно попробовать другие варианты ВЧ трансформатора. Однако мой опыт показывает, что выигрыш от оптимизации не обязательно огромен. Моя цель в этой статье состояла в том, чтобы создать практический классификатор с нуля и сравнить модную архитектуру Transformers с моими предыдущими экспериментами с Attention LSTM. Для этого я считаю, что текущие результаты в порядке.

В целом, я считаю, что результаты показывают, что Transformer в целом дает лучшую производительность классификации, но также является более сбалансированным. LSTM по-прежнему дает хорошие результаты, но если бы ресурсы были доступны, я бы выбрал Transformer.

Один момент, который я нахожу интересным в различиях моделей, заключается в том, что LSTM, кажется, немного лучше справляется с доминирующим компонентом General, в то время как Transformer, кажется, лучше справляется с другими. Этот анализ был основан на одной паре из 10 вариантов, которые я тренировал, поэтому, если бы у меня было больше времени и ресурсов, просмотр различных вариантов обучения, вероятно, все же дал бы больше уверенности.

Одним из способов применения таких различий в производительности модели было бы создание обучаемого ансамбля. В такой комбинированной модели обе модели LSTM и Transformer будут способствовать прогнозированию. Эти модели кажутся хорошими кандидатами, поскольку они имеют взаимное разнообразие. Это означает, что один из них дает лучшие результаты в одних частях данных, а другой — в другой. В практических производственных системах ансамбли могут быть слишком сложными для относительно небольшого усиления. Тем не менее, в таких соревнованиях, как Kaggle, где важны доли процента в результатах, это было бы хорошим пониманием для изучения.

Предиктор в действии

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

Когда я представил свой классификатор компании Qt на основе данных их системы отслеживания проблем, у меня были аналогичные данные с некоторыми более старыми классификаторами (RF, SVM, TF-IDF, …) и LSTM. Тогда я обнаружил, что классификатор LSTM дает удивительно хорошие результаты (похожие на здесь). Я сделал презентацию этого, показал хорошие результаты, и у людей, естественно, возник вопрос: как это на самом деле работает с отчетами о проблемах, которых я раньше не видел?

Один из способов ответить на этот вопрос — попытаться объяснить, что обучающие данные не включали проверку или тестовый набор, и, таким образом, они уже точно измеряют, насколько хорошо они будут работать с данными, которых он раньше не видел. Но не все так хорошо знакомы с терминологией или концепциями машинного обучения. Чтобы лучше ответить на этот вопрос, я затем открыл трекер проблем за этот день, взял одну из самых новых, еще не проверенных проблем (без назначенного компонента) и скопировал ее текст. А затем запустил классификатор в реальном времени для этого текста. Спросили, считают ли люди, что это хороший результат. Мы можем смоделировать это и здесь.

Я взял отчет о проблеме, поданный 13 мая (сегодня, в 2021 году), так как мой набор данных для обучения был загружен 21 апреля. В отличие от живой демонстрации, вы просто должны мне доверять :).

Для этого эксперимента я выбрал номер выпуска 1710955. Метка компонента, присвоенная ему разработчиками, — Система обмена сообщениями. Ниже показаны первые 5 прогнозов проблемы с использованием модели HF DistilBERT. Сначала в качестве функций использовалось только поле summary, а затем в качестве функций использовались как summary, так и описание.

В верхней строке выше показана система обмена сообщениями в качестве главного прогноза, что в данном случае верно. Второе место занимает Страница быстрого доступа. Средняя линия показывает, что с одним только полем summary система обмена сообщениями правильно прогнозируется как главный компонент с вероятностью 98,6%, за которым следует страница новой вкладки. на уровне 84,7%. В третьей и последней строке выше показано, как при добавлении поля description к функциям предсказанная первая пятерка остается прежней, но классификатор становится более уверенным с системой обмена сообщениями с учетом 99,1 %. вероятность, а Страница быстрого доступа опустилась до 62,5 % на второе место.

Текст поля summary для этого отчета о проблеме выглядит просто так: Изменить подключение обновления MR1 к Pin, затем Default, затем Theme screens. Проверьте отчет о проблеме для получения более подробной информации и описания. Я думаю, довольно впечатляюще предсказать компонент из такого короткого сводного текста, хотя я предполагаю, что некоторые слова в нем могут быть довольно специфическими.

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

Выводы

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

В конце концов, написание этой статьи было интересным упражнением по испытанию архитектуры Transformer для набора данных реального мира и получению информации в сравнении с архитектурой LSTM, которую я использовал ранее. Будет ли кто-то использовать что-то подобное в реальном мире? Я не знаю. Я думаю, такие приложения зависят от масштаба и реальных потребностей. В очень больших компаниях с очень большими продуктами и отделами разработки я вижу, что это может оказать полезную помощь. Или интегрировать как часть платформы отслеживания проблем для дополнительной функциональности. Подумайте о преимуществах использования для рекламы вашего продукта новейших моделей глубокого обучения и искусственного интеллекта для анализа ваших проблем. :)

Помимо сравнения с моей предыдущей работой по созданию аналогичного классификатора ошибок для системы отслеживания проблем компании Qt, я также нашел другую статью, написанную примерно в то же время, когда я писал свое предыдущее исследование, по аналогичной классификации системы отслеживания проблем, которая называется DeepTriage. Я хотел использовать его для сравнения, но их цель состояла в том, чтобы предсказать разработчика, которому будет назначена проблема, поэтому я пропустил это. Это все еще было полезно для того, чтобы дать некоторое представление о том, где найти доступные средства отслеживания проблем и как они использовали данные для функций.

Однако, когда я искал в Интернете слово DeepTriage после этой статьи, я нашел другую статью с таким же названием. DeepTriage для сортировки облачных инцидентов. Да, в своих предыдущих статьях о метаморфическом тестировании систем на основе машинного обучения я отмечал, сколько статей DeepXXX. Очевидно, сейчас так популярно называть свои исследования DeepXXX, что вы даже повторно используете имена. В любом случае, это был документ от Microsoft, в котором говорилось о стоимости и необходимости быстрой сортировки в центрах обработки данных, несбалансированных наборах данных и всем таком. И как они используют этот тип техники в Azure с 2017 года с тысячами команд. Итак, как я уже сказал, это, вероятно, станет полезным, как только ваш масштаб и реальные требования догонят вас.

Что ж, моя цель состояла в том, чтобы поиграть с трансформерами и, возможно, привести пример построения классификатора из реальных данных НЛП. Я думаю, что я сделал хорошо. Ваше здоровье.