Comments 6
Очень интересно, спасибо за статью!
Напомнило про статью с описанием системы ICL'а от mr2dark «ICL Services использует основанную на машинном обучении систему для организации поддержки ИТ-пользователей».
Вообще-то, весьма слабые R-квадраты вы такие (зря) выкладываете… В целом подход-то ясен.
И еще, ну так, к слову пришлось, сами модели мало решают (что R-квадрат собственно и показал). Решают отинжениренные фичи.
Если тут можно рекомендовать, я бы зашел с другой стороны. Есть готовый gensim doc2vec, ну или keras embeddings layer, то есть векторизовать тексты описаний тикетов — важно было бы. И второе — просто и я постоянно этим пользуюсь — сделать логарифмирование таргета. Со временами тикетов должно сработать, модели чаще лучше фитятся.
Для параллельных вычислений когда данных много, используйте dask например, для sklearn есть параметр n_jobs.
И еще, ну так, к слову пришлось, сами модели мало решают (что R-квадрат собственно и показал). Решают отинжениренные фичи.
Если тут можно рекомендовать, я бы зашел с другой стороны. Есть готовый gensim doc2vec, ну или keras embeddings layer, то есть векторизовать тексты описаний тикетов — важно было бы. И второе — просто и я постоянно этим пользуюсь — сделать логарифмирование таргета. Со временами тикетов должно сработать, модели чаще лучше фитятся.
Для параллельных вычислений когда данных много, используйте dask например, для sklearn есть параметр n_jobs.
Поработайте с категориальными фичами, возможно значительно лучшите модель, как вы сами заметили — самый большой разброс был для проектных задач. И вообще в таком случае как тоже знакомый с кухней ITSM — проектные задачи лучше дробить на подтикеты, так вы полчите лучший контроль над исполнением и ускорите его, а потом и модель лчше станет работать.
И еще если вас инженеры например перемещаються между офисами — то имеет смысл добавить фичи свзяанные с локацией.
Так же из времени вытащите фичи связанные с месяами, сезонами, днями недели и частями дня (утро, день, вечер, ночь).
И еще если вас инженеры например перемещаються между офисами — то имеет смысл добавить фичи свзяанные с локацией.
Так же из времени вытащите фичи связанные с месяами, сезонами, днями недели и частями дня (утро, день, вечер, ночь).
Поработайте с категориальными фичами, возможно значительно лучшите модель, как вы сами заметили — самый большой разброс был для проектных задач. И вообще в таком случае как тоже знакомый с кухней ITSM — проектные задачи лучше дробить на подтикеты, так вы полчите лучший контроль над исполнением и ускорите его, а потом и модель лчше станет работать.
И еще если вас инженеры например перемещаються между офисами — то имеет смысл добавить фичи свзяанные с локацией.
Так же из времени вытащите фичи связанные с месяами, сезонами, днями недели и частями дня (утро, день, вечер, ночь).
И поработайте над отбором фич, возможно какие-то даже стоит выкинуть.
И конечно присоединяюсь к комментарию S_A
И еще если вас инженеры например перемещаються между офисами — то имеет смысл добавить фичи свзяанные с локацией.
Так же из времени вытащите фичи связанные с месяами, сезонами, днями недели и частями дня (утро, день, вечер, ночь).
И поработайте над отбором фич, возможно какие-то даже стоит выкинуть.
И конечно присоединяюсь к комментарию S_A
Молодцы, что пробуете столько вариантов!
Разброс между трейном и тестом очень велик, что обычно говорит либо о перетрене, либо о плохом разбиении, либо о неподходящей модели/фичах.
По-моему, стекинг начали очень рано, моделям явно не хватает качественных предикторов. У задач нет оценочного времени исполнения, заявленного постановщиком? Оно наверняка резко бы улучшило модель. Нет информации о родительском проекте, сфере реализации, количестве затронутых проектом фич и т.п.?
Обычно в учебных проектах стараются сначала дать модели объективные данные, напрямую связанные с задачей, желательно в числовом виде. То, что использовали бы вы сами для построения простой модели на бумаге. И лишь потом дотюнивают уже неплохую модель категориальными фичами, one-hot encoding, мета информацией. И уже эти неплохие сами по себе модели стекают, чтобы получить последние доли процента точности.
Разброс между трейном и тестом очень велик, что обычно говорит либо о перетрене, либо о плохом разбиении, либо о неподходящей модели/фичах.
По-моему, стекинг начали очень рано, моделям явно не хватает качественных предикторов. У задач нет оценочного времени исполнения, заявленного постановщиком? Оно наверняка резко бы улучшило модель. Нет информации о родительском проекте, сфере реализации, количестве затронутых проектом фич и т.п.?
Обычно в учебных проектах стараются сначала дать модели объективные данные, напрямую связанные с задачей, желательно в числовом виде. То, что использовали бы вы сами для построения простой модели на бумаге. И лишь потом дотюнивают уже неплохую модель категориальными фичами, one-hot encoding, мета информацией. И уже эти неплохие сами по себе модели стекают, чтобы получить последние доли процента точности.
Sign up to leave a comment.
Предсказываем время решения тикета с помощью машинного обучения