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 года с тысячами команд. Итак, как я уже сказал, это, вероятно, станет полезным, как только ваш масштаб и реальные требования догонят вас.
Что ж, моя цель состояла в том, чтобы поиграть с трансформерами и, возможно, привести пример построения классификатора из реальных данных НЛП. Я думаю, что я сделал хорошо. Ваше здоровье.