Pull to refresh

Comments 16

Спасибо, поправил :)

UFO just landed and posted this here

Я читаю их блог. Система "Антиплагиат" — это монстр, по сравнению с нашей задачей :)
Кроме того, я боюсь, что такие методы, как там используются используются, на коротких текстах обращениях (длиной до 50 слов) могут не сработать...

UFO just landed and posted this here

Я бы добавил отдельное обнаружение характерных паттернов.


  1. Трейсы ядра
  2. Трейсы питона
  3. Трейсы джавы
  4. Трейсы С++

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


Случай "файл/номер строки".
Стандартные тексты для errno

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


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

А, у вас специальный кейс. У нас в саппорте (хостера) показать трейс — как нефиг делать.

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

Целевой эмбеддинг можно натренировать при условии достаточного количества размеченных данных: "инцидент 1 похож на инцидент 2" / "инцидент 3 не похож на инцидент 4". Мы собрали немного размеченных данных — но этого не хватает для значимого обучения.


Я, кстати, пытался найти где-нибудь численные оценки минимально необходимого количества размеченных данных для тренировки сетей заданной архитектуры. Общий ответ — чем больше, тем лучше ( "спасибо, Кэп" ).
Может у кого-нибудь есть статейка в закладках почитать по этой теме?

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

Наверное, вы имеете ввиду стандартные эмбеддинги типа word2vec или Glove. Они, действительно, обучаются на корпусе по окружению. Но только они генерируют эмбеддинги для слов, а не предложений. Получить эмбеддинг текста — это еще один шаг, который можно сделать либо просто (усреднение эмбеддингов слов), либо сложнее (вектор фиксированной длины с элементами из эмбеддингов слов).


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


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

Однако чуда от системы unsupervised learning ожидать было нельзя. Коллеги жаловались на то, что иногда система предлагает совсем нерелевантные ссылки. Порой даже было сложно понять — откуда такие рекомендации берутся.

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

Ну, я бы не сказал, что модель не интерпретируема. Есть пары нормированных векторов, каждый компонент которых соответствует слову или n-грамме — косинусное расстояние определяет похожесть текстов.
Кроме того, использование TfidfVectorizer, как раз позволяет даже посмотреть какие слова значимы для корпуса и для каждого инцидента — это отдельная полезная функция.


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

А, ну то есть вы на самом деле знаете, почему система такое советовала. Это другое дело. :)

Ну да, мы выяснили — и приняли меры :)

Sign up to leave a comment.

Articles