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

1. Введение

1.1 Контекст

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

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

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

1.2 Цель этого поста

Цель этого поста — представить работу, выполненную для моего клиента, с помощью реализующего ее кода, доступного в этой записной книжке.

Прогноз команды описания инцидента

incident_description_team_prediction.ipynb

127 KB

скачать-круг

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

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

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

2. Методология

2.1 Данные

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

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

Вот краткий обзор того, как могут выглядеть данные.

2.2 Проблема

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

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

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

2.3 Решение

Теперь, когда у нас есть определенная проблема, мы должны выбрать способ ее решения. Этот проект заключается в использовании методов обработки естественного языка (NLP) для преобразования наших данных из языка в числовые данные и возможности использования возможностей модели машинного обучения. Для этого были проверены различные методы NLP для кодирования языка, и было решено использовать вложения. В частности, была использована модель BERT, поскольку она считается лучшей моделью и имеет множество преимуществ.

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

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

3. Предварительная обработка

3.1 Предварительная обработка данных

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

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

3.1.1 Стоп-слова

Этот первый шаг состоит из удаления часто используемых слов в языке (например, the, a, an, и, of, …), которые не несут определенного значения или не имеют отношения к конкретному контексту анализа текста. Этот шаг уменьшает размер данных и повышает производительность моделей обработки текста за счет устранения фонового шума.

Библиотека NLTK предоставляет набор «стоп-слов», которые легко доступны в Интернете для выполнения этого этапа предварительной обработки. Также можно удалить некоторые слова из этого списка, если вы не хотите, чтобы они считались стоп-словами. Действительно, важно отметить, что удаление некоторых слов может изменить смысл текста, поэтому вы должны выбирать слова, которые нужно удалить, с осторожностью.

3.1.2 Пунктуация

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

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

3.1.3 Нижний регистр

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

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

3.1.4 Числа

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

3.2 Предварительная обработка этикеток

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

3.2.1 Распространение этикеток

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

Второй фактор — сложность проблемы. При работе с большим количеством меток вычислительная сложность модели может значительно возрасти.

Поскольку этот проект является всего лишь Proof of Concept, нет необходимости решать эти проблемы трудным путем. Что я сделаю, так это ограничу количество ярлыков, сгруппировав менее часто встречающиеся ярлыки в другие ярлыки. Таким образом я накапливаю вхождения редких меток и уменьшаю сложность вычислений.

3.2.2 Командные выступления

С помощью следующего кода мы видим, что все наши инциденты назначены в общей сложности 27 различным командам и что они действительно несбалансированы

3.2.3 Появления команд выше квантиля

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

В статистике квантиль — это значение, которое делит набор данных на равные части (например, медиана — это квантиль, который делит набор данных на две равные части). Квантиль 0,90 означает, что 90 % значений в наборе данных меньше или равны этому значению, а 10 % значений больше этого значения. Следовательно, в нашем примере квантиль 0,90 дает количество инцидентов, которые должны быть связаны с командой, так что 90% команд имеют меньше связанных с ней инцидентов.

Взяв квантиль 0,70, мы можем ограничить количество команд до 8.

3.2.4 Сопоставьте каждую команду с ярлыком

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

3.2.5 График распределения команд

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

3.3 Разделить данные

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

К счастью, библиотека sklearn предоставляет функцию train_test_split(), которая позволяет легко и эффективно разбивать набор данных. В следующем фрагменте кода показано, как использовать эту функцию для разделения набора данных на наборы для обучения и тестирования.

3.4 Сбалансируйте тренировочный комплекс

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

4. Модель

4.1 Токенизация

Хорошо ! Теперь данные подверглись нашему конкретному преобразованию, но для эффективного использования модели BERT источник также будет проходить через библиотеку BertTokenizer. Этот интегрированный токенизатор выполняет несколько шагов предварительной обработки для преобразования входного текста в специальный формат BERT:

  1. Каждое входное предложение разбивается на токены уровня слова и сопоставляется с их соответствующими идентификаторами в словаре BERT.
  2. Добавлены специальные маркеры для обозначения начала ([CLS]) и конца ([SEP]) каждого предложения с идентификаторами 101 и 102 соответственно.
  3. Предложения дополняются или усекаются до максимальной длины 512 токенов, при этом токенам заполнения ([PAD]) назначается идентификатор 0.
  4. Создается маска внимания, чтобы указать, каким токенам модель должна придавать вес во время обучения, при этом токенам заполнения присваивается значение 0.

Для выполнения этих шагов мы можем использовать метод tokenizer.encode_plus(), который возвращает объект BatchEncoding со следующими полями:

  • input_ids : список идентификаторов токенов.
  • token_type_ids : список идентификаторов типов токенов.
  • Attention_mask : список бинарных значений, указывающих, какие токены должны учитываться моделью во время обучения.

4.2 Разделить данные (снова)

Теперь, когда все данные, которые будут использоваться моделью, соответствуют требуемому формату, необходимо разбить набор данных во второй раз. Действительно, на этот раз тренировочный набор будет разделен на 2 набора данных: настоящий тренировочный набор (80%) и проверочный набор (20%).

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

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

4.3 Инициализация обучения

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

Сначала реализуются несколько метрик, чтобы соответствовать нашей проблеме с несколькими классами.

Затем создается оптимизатор, предоставляя ему итерацию, содержащую параметры для оптимизации, а также конкретные параметры, такие как скорость обучения и эпсилон (значения выбираются на основе рекомендаций из статьи BERT). Наконец, создается график скорости обучения. Его эффект заключается в линейном снижении скорости обучения от начального значения до 0. Также в оптимизаторе вы могли бы заранее установить период прогрева, в течение которого линейно увеличивается скорость обучения от 0 до начального значения за определенное количество шагов.

4.4 Фаза обучения

Этап тонкой настройки, как и в представленном ниже коде, состоит из двух основных частей: цикла обучения и функции оценки.

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

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

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

Давайте посмотрим, как работают эти 2 шага, не вдаваясь в подробности, но, по крайней мере, дадим вам общее представление о том, как работает обучение.

4.4.1 Функция оценки

Давайте сначала посмотрим на функцию оценки.

Функция оценки принимает объект DataLoader в качестве аргумента, который будет передавать данные проверки пакетами. Сначала он устанавливает модель в режим оценки с помощью model.eval(), которая гарантирует, что параметры модели не будут обновляться во время оценки.

Затем он инициализирует переменные loss_val_total, прогнозы и true_vals для хранения общих потерь при проверке, прогнозируемых логитов и истинных меток соответственно.

Затем функция входит в цикл по пакетам из val_dataloader. В рамках каждой итерации пакет перемещается на соответствующее устройство (например, GPU) с помощью to(device). Входные данные для модели задаются с помощью словаря, который содержит входные идентификаторы, маски внимания и метки.

Внутри блока with torch.no_grad() входные данные передаются модели в виде аргументов ключевого слова. Результирующие выходные данные содержат потери и логиты. Потери накапливаются в loss_val_total, в то время как логиты и метки отделяются от вычислительного графа, перемещаются в ЦП и добавляются к прогнозам и истинным значениям соответственно.

После обработки всех пакетов вычисляется средняя потеря при проверке путем деления loss_val_total на количество пакетов, содержащихся в val_dataloader. Списки predictions и true_vals изменяются по первой оси с помощью np.concatenate для получения отдельных массивов.

Наконец, функция возвращает средние потери при проверке, прогнозы и истинные метки.

4.4.2 Цикл обучения

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

Этот цикл выполняется через указанное количество эпох. В каждой эпохе модель устанавливается в режим обучения с помощью model.train(), а переменная инициализируется для хранения общих потерь при обучении.

Индикатор выполнения создается с помощью библиотеки tqdm для визуализации итераций по загрузчику train_dataloader, который предоставляет обучающие данные в пакетах. Внутри каждой итерации градиенты модели сбрасываются с помощью model.zero_grad().

Затем, аналогично функции оценки, пакет перемещается на устройство, входные данные помещаются в словарь входных данных и передаются модели через аргументы ключевого слова. Результирующие выходные данные содержат потери, которые накапливаются в loss_train_total, в то время как градиенты вычисляются с помощью вызова loss.backward().

После этого неплохо было бы ограничить норму градиента до 1,0 с помощью функции clip_grad_norm_(), чтобы предотвратить их взрыв.

Наконец, оптимизатор обновляется с помощью optimizer.step(), планировщик скорости обучения продвигается вперед с помощью scheduler.step(), а индикатор выполнения обновляется для отображения текущего тренировочный проигрыш.

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

4.5 Прогноз

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

4.6 Вложения

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

Единственное, что вам нужно сделать, это маркировать образец так же, как в обучении и прогнозировании. Затем, передав модели sample_token_ids и sample_attention_mask, она выдает различные выходные данные, включая hidden_states. Эти скрытые состояния представляют контекстуальные представления каждого токена на разных уровнях модели.

В коде мы извлекаем конечное скрытое состояние, обозначаемое output.hidden_states[-1], которое захватывает наиболее полное контекстуальное представление.

Чтобы получить единое вложение для всего текста, мы вычисляем среднее значение скрытых состояний по длине последовательности (dim=1). Эта операция объединения средних суммирует информацию из всех токенов в один вектор фиксированной длины, который представляет собой контекстуальное встраивание входного текста.

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

5. Результаты

Поскольку пример кода, предоставленный для этого сообщения в блоге, использует случайные данные, ни одна модель не сможет изучить значимые шаблоны. Поэтому результаты, которые я собираюсь представить здесь, являются полученными в реальном упражнении. В этом случае я использовал выборку из 100 000 инцидентов из полного набора данных с участием более 400 команд. Обратите внимание, что в процессе фильтрации команд использовался квантиль 95, чтобы ограничить анализ 10 конкретными командами и одной «другой» группой. После балансировки данных я получил полный образец набора данных (обучение + проверка + тестирование) с чуть менее чем 1000 инцидентов на команду.

5.1 Интерпретации

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

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

Я хотел бы подчеркнуть ограниченный объем данных в нашем обучающем наборе, доступном для такой нейронной сети. Используемая нами модель, а именно база BERT без оболочки, состоит из 12 слоев, 768 скрытых блоков и 12 головок, что в сумме дает 110 миллионов параметров. Эффективность этой модели в нашем случае объясняется переносом обучения. Благодаря тонкой настройке BERT мы можем использовать знания, полученные во время его начального обучения, сделанные на большом наборе данных под названием BookCorpus, который включает 11 038 неопубликованных книг и всю английскую Википедию. Приспосабливая эти приобретенные возможности к нашей конкретной проблеме, мы можем добиться отличной производительности.

5.2 Обсуждение

5.2.1 Ограничения и предубеждения

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

Затем, хотя его точность достаточно высока, не ожидается, что группа «другие» будет иметь действительно высокую точность, поскольку она охватывает все оставшиеся команды. Единственная его особенность — не быть частью 10 конкретных команд.

Наконец, обратите внимание, что показатель F1 выше в тестовом наборе. Это логично, так как этот набор данных не был сбалансирован и, следовательно, содержит большее количество «других» инцидентов. Тем не менее, на счет F1 не должно существенно влиять распределение команд.

5.2.2 Возможные улучшения

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

Кроме того, качество данных, используемых в этом упражнении, не является оптимальным. Тем не менее, в методах NLP удается использовать доступные данные в произвольном формате, даже если им не хватает строгости или последовательности.

И последнее, но не менее важное: первая область для улучшения — это, безусловно, количество инцидентов, которые охватывает этот проект. Действительно, в реальном PoC, ограничивая себя 10 конкретными командами, я охватываю лишь очень небольшой процент происходящих инцидентов, что делает проект совершенно бесполезным… Тем не менее, учитывая хорошие результаты, Я уверен, что этот проект можно развивать и дальше, чтобы охватить практически все команды. Даже если это означает использование этой модели в качестве консультанта, а не предоставление ей права напрямую определять назначенную команду. Собственно, это и было сделано! Аналогичная модель вместо того, чтобы возвращать одну команду, отображает 10 лучших команд с соответствующими вероятностями, чтобы помочь человеку назначить инцидент.

6. Заключение

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

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

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

Спасибо за чтение !

Антуан

7. Благодарность

Я благодарен своим коллегам, которые помогли мне с этим проектом и поделились своими знаниями, которые сильно повлияли на содержание этой статьи.

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

Я также хочу поблагодарить за вдохновение, которое я черпала из работ Николо Козимо и Сьюзен Ли. Их отличные посты в блогах на похожую тему вдохновили и повлияли на мое собственное письмо.

Точная настройка BERT для классификации текста

Пошаговое руководство по Python

На пути к науке о данных Николо Козимо Альбанезе

Многоклассовая классификация текстов с глубоким обучением с использованием BERT

Обработка естественного языка, НЛП, обнимание лица

На пути к науке о данныхСьюзен Ли

Я также хочу упомянуть, что я использовал ChatGPT, чтобы помочь мне написать этот пост в блоге. Хотя это повысило мою эффективность, важно не забывать проверять и проверять достоверность контента, созданного ИИ.

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

Прогноз команды описания инцидента

incident_description_team_prediction.ipynb

127 KB

скачать-круг