Как стать автором
Обновить

Машинное обучение руками «не программиста»: классификация клиентских заявок в тех.поддержку (часть 1)

Время на прочтение19 мин
Количество просмотров27K
Всего голосов 20: ↑17 и ↓3+14
Комментарии24

Комментарии 24

Я прошел тот же путь. Задача была не класификация. Было обучение с учителем. Т. е. был доступен датасет с историческими данными обращений и направлениями в определенную рабочую группу (одну из 80) для решения. Определение группы. Остановился на достижении необходимого качества. Основная проблема с которой столкнулся — это подготовка данных и… «суржик». Обращения пользователей в моем случае — это обращения пользователей живущих в Украине. Тексты могут быть на украинском языке, на руссском и «суржике», т. е. смеси двух языков. Пытался решить проблему переводом на английский с определением исходного языка используя Google Cloud Translation API… Качество стало лучше, но не достаточно… Путей решения пока не вижу.
Кроме как «определять в начале язык» наверное и нет простого решения :) И отдельно классифицировать на своем языке.

ps «Классификация» и «Обучение с учителем» — это две разных категории, не противоречащих друг другу. Классификация — это тип задачи, которую решаем, «обучение с учителем» — тип обучения (есть известные ответы, или нужно найти зависимости и связи между объектами по описанию объектов).
Поясню еще — «суржик», это когда в одном предложении могут быть и русские и украинские слова с соответствующим написанием. Такие предложения люди в Украине воспринимают и понимают без проблем. И алфавит русского и украинского языков несколько отличен :-) Так что решение совсем не простое… И я его, в этой части к сожалению, не вижу…
В чем проблема, почему просто не использовать UNICODE внутри, а снаружи UTF-8? Если классификация на словах, то слова — это последовательности символов, разделенные сепаратором (есть такой класс символов в UNICODE). Будут английские, русский, украинский (по желанию и китайские) слова, выделенные из текста как признаки. В чем здесь трудность?
По умолчанию оно так и есть — просто разные слова. Но без «сливания» смыслов получится низкое качество, о чем пишет smazin. Т.е. то, на что в конце статьи указано (слова «печать», «пичать», «пичять» — считайте что одно и тоже слово на разных языках :), но в бОльшем масштабе.
Не понятно, почему низкое качество получится. Если не нужно выделять классы слов, т.е. приводить их в какую-то нормальную форму, то все опечатки и форму таки или иначе будут присутствовать в словаре, полученном на обучающей выборке. Для описанной в статье задачи никто не гарантирует, что приведение к нормальной форме повысит качество до 90%. Ну а для Вашей задачи вообще не понятно, к чем приведет такой улучшение. Качество для таких задач обычно улучшают расширением контекста. Самое простое решение — использовать словный n-граммы вместо слов (униграмм). Еще радикальнее — прогнать все тексты из обучающей выборки через word2vec и использовать вектора чисел, полученные для слов этим алгоритмом. Эти вектора учитывают синтаксическую синонимию (употребление слов в одном контексте), тогда к нормальной форме вообще не нужно ничего преобразовывать.
Вот то о чем вы пишите — на третьем курсе специализации проходят. А я прошел только 2 :) Ну и в целом, без конкретных данных гадать о причинах сложно.
Я дам три отчасти синтетических, отчасти реальных примера. Мне кажется это даст представление о чем писал я. Все три примера после анализа человеком адресуются в одну группу исполнения:
1.Русский:
"… От сотрудника прямого контакта поступил запрос: «Отсутствуе возможность активации номера ХХХХХХ (л/сХХХХХХХХХХ)» Просьба помочь в данном вопросе. Спасибо!..."
2. Украинский:
"… Від працівника прямого контакту надійшов запит: «Відсутня можливість активувати номер ХХХХХХ (о/рХХХХХХХХХХ)» Прохання допомогти у цьому питанню. Дякую!..."
3.«Суржик»:
"… От сотрудника прямого контакта поступил запрос: «Відсутня можливість активувати номер ХХХХХХ (л/сХХХХХХХХХХ)» Просьба помочь в данном вопросе. Спасибо!..."

Это три комбинации. Причем «суржик» может иметь больше вариаций. То что делал я, переводил пословно без учета контекста на английский с задачей распознания языка слова источника. Распозначание языка слова источника не всегда срабатывает. Или срабатывает неверно, может определить источник как скажем словацкий язык, с совершенно другим значением и как следствие — переводом… Вот здесь проблема таких задач…

То, что в русском (и близких языках) слова довольно сильно меняются (все эти склонения/спряжения) не мешало?


Не смотрели, насколько важно сдалать лемматизацию?
(привести все слова в нормальную форму)

Не могу сказать, на сколько это поможет — но есть предположение, что поможет. Пока никаких других методов не применял — они на 3 курсе специализации, я до него не дошел ещё :)

Я сейчас прохожу курс на Курсере от мистера Ына, там всё на Питоне 3.5

Вы о каком из курсов? У него их теперь два. Если о первом (на который дана ссылка в публикации), то ещё полгода назад он был на Octave. Возможно, новая специализация (https://www.coursera.org/specializations/deep-learning) на Питоне (да, судя по программе — на Питоне).

Да, извините :)
Я теперь вспомнил сам, что там два курса.

А какой смысл пользоваться отложенной выборкой если вы на этапе подбора гиперпараметров используете кросс-валидацию? Это ведь с учётом того что кросс-валидация обычно проводится на n количестве фолдов что по сути является n раз использованной разной отложенной выборкой. Просто для спокойствия?
В примере из публикации, кросс-валидация проводится в пространстве словаря, составленного на обучающей выборке — т.е. каждый отложенный фолд уже внёс свой вклад в обучение. Что в целом — грешно, но для цели «выбрать лучший набор гиперпараметров» и сравнить алгоритмы — норм.
Для формирования векторов слов (то, что вы называете словарем) в sklearn есть класс CountVectorizer.

И дополнительно советую попробовать использовать TF-IDF. Соответствующий класс тоже есть в этой библиотеке. Предполагаю, что качество модели серьезно возрастет.

Для классификации таких данных в наших задачах (подобных) очень хорошо подошел SGDClassifier.
Можно попробовать еще ансамбль из SGD и SVC

И уж совсем для полноты картины пробуйте подбирать параметры классификаторов методом поиска по сетке параметров.

Советую прочитать эту книгу «Python и машинное обучение» Себастьян Рашка — в ней подробно на примерах разбираются практические задачи и детально поясняется, что, зачем, как и почему.
Спасибо. Всему свое время :) Ещё 4 курса специализации впереди.
> И уж совсем для полноты картины пробуйте подбирать параметры классификаторов методом поиска по сетке параметров.
этому вопросу в публикации уделено достаточно много. Вы точно прочитали всё до конца? :)
Не вникал в детали вашей реализации, но techus вам абсолютно правильно TF-IDF советует использовать. Странно, что в специализации с ним сразу не знакомят. Кажется, что если постараться, то «все» необходимое можно запихать в один курс: www.coursera.org/learn/vvedenie-mashinnoe-obuchenie, чтобы потом не пришлось ссылаться, на то, что еще много чего осталось освоить :)
Вопрос с разработчикам курса, но в целом я предпочту курс, где подробнее, но дольше, чем по верхам, но быстро. Хорошо, когда у всех есть выбор :)
А заявки все строго стандартизированы?
Не было проблем с падежами, окончаниями, формами слов?
Заявки в свободном стиле, как сформулирует пользователь. Падежи, окончания и формы слов — это не проблема, это задача. Впрочем, об этом написано в последнем абзаце :)

Почему ещё ни кто не вспомнил word2vec? Это способ кодировать слова с учётом контекста их употребления. Есть готовые решения. Позволяет заметно поднять качество модели.

Да вроде в комментариях писали об этом. Но я решил пока не использовать методы, с работой которых руки не дошли разобраться. Разберусь — напишу как они работают и на сколько улучшилась модель :)
на наших тестах (которые ты поставил под сомнение как менеджер:) использовался SVM. word2vec показал результаты хуже. лемматизацию делали, конечно.
ну и, как мне кажется, в наших системах очень желательно:
— использовать фичи из контекста: кто, когда подал заявку, какие заявки он подавал раньше и т.д.
— выделять факты: номера телефонов, емэйлы, даты, номера чего-то еще.
— критически смотреть на набор классов/тематик: почти всегда там есть какая-нибудь фигня
Зарегистрируйтесь на Хабре, чтобы оставить комментарий