Сергей, добрый день.
Затронули очень болезненную для меня тему.
Дико извиняюсь что написал ниже много букв, но без такой вводной не смогу получить правильного ответа.
У нас текущий бизнес процесс сильно завязан на классификацию мастер-данных (справочников), если чуть детальней-то речь про работу с вином: ежедневно приходит массив грязных зашумленных данных от внешних поставщиков информации о продажах вин в крупнейших розничных сетях по всей России с детализацией до точки продаж. Речь не только про продажи Российских вин, а о всех винах вообще (со всего мира).
Операторы получают новые вариации названий вин ежедневно и должны их классифицировать, т.е. правильно привязать в справочниках новые объекты на вина заведенный в стандартах нашей компании (а если не нашлось ничего похожего то создать такой класс и привязать к этому созданному)
Естественно поток информации настолько велик, что приходится задейстовать машинное обучение: там где модель уверенна выше чем на 99%, то классификация происходит автоматически, там где модель уверенна ниже- она участвует в системе в роли рекомендательного алгоритма с которым оператор либо соглашается либо нет.
Итого сейчас у нас 31925 классов, из них пустых (то о чем Вы писали -не разметили еще ассесоры)= 1761
Дисбаланс классов на картинке ниже
Отличие от классических задач текст-майнинга в следующем:
Вина именуются в системах наших сетевых ритейлеров чаще всего на кириллице как правило из франко-итальянских словоформ с "трудностями перевода" — где-то двойные буквы, где то одинарные(напр. количество букв "с" подряд может быть в любом месте произвольным: Вино игристое Ламбруско ТМ Массимо Висконти бел.слад. 0,75*6 Италия /Аква Вита ТК/)-решается регулярками
Длина строки при вводе в систему у сетевых ритейлеров ограничена и их операторы что бы уместиться не теряя общего смысла начинают сокращать (например приходит к нам такой вот треш: "Вин.ПР.РОБ.РИБ.Д.ДУЭ.ДО кр.сух.0.75л" который становится у нас в классе "Вино Протос Робле Рибера дель Дуэро кр сух 0,75")- решается Гуглом и вангованием на стеклянном шаре с привлечением Астрологов
Очень много шума в тексте (импортеры, сетевой артикул и т.д.) -решается поддержкой списка стоп-слов
Слияния слов (AVESвиноМЕРЛО МаулеВелле кр.сух.0.75л)-решается регулярками
Разная степень сокращений ключевых для моделей термов ({красн, кр, крас};{п/сл, полусл, п-слад},{крпсл}) — решается регулярками
Разная степень сокращений важных для моделей термов (Молоко любимой женщины; Мол.люб.жен...) — тут стеммер Портера приказал долго жить (из-за вышеописанных проблем), писал свой алгоритм обучения по термам, который рекурсивно ищет цепочку предок-наследник для термов с высокой степенью вероятности сокращенных до своих наследников и выдает на выходе такой вот справочник автозамены — "взять term и заменить на abbr отбросив цепочки с неоднозначными вариантами сокращений (там где может быть несколько разных предков)":
Далее по классике: токенизация, document-term matrix, tfidf, и удаление sparce-термов которые встречаются лишь в одном документе (не важно-в обучающей или предсказательной части матрицы).
И тут еще одна проблема: высокочастотные термы (красное, белое, розовое, сладкое, полусладкое, сухое, 0.75, 0.7, и т.д.) которые по понятным причинам имеют самый низкий tfidf оказывают решающую роль в классификации: если в векторном представлении бренды/винодельни или провиции произростания совпали но цвет вина или емкость оказались другими. то последствия такой ошибки классификации высоки — это мастер-данные к которым привязываются в системе продажи (в виде большого числа транзакций) и одна ошибка в цвете/емкости/сахарности транслируется многократно в отчетности.
Поэтому ничего не остается как такие ключевые высокочастотные термы с tfidf стремящимся к нулю докручивать до значений = 10000, что бы их вес был решающим.
Далее уже алгоритмы классификации: один — свой самописный (который возвращает еще и меру сходства с классом) и еще LIBLINEAR Собственно сам вопрос:
можно ли из вышеописанных алгортимов Вашей статьи взять какую то часть на вооружение и улучшить текущий процесс с учетом вышеописанных проблем?
"Появились, также, проблемы с совместимостью. Access Runtime решал вопрос запуска СУУ у пользователей без установленного полноценного платного MS Access."
у нас ms sql server + Access 2013 (большая часть бизнес логики реализована в формах через VBA) в связке через odbc native client
(Я знаю что это некрасивое решение но когда данных много а пользователей мало — вполне себе жизнеспособно)
Т.е. у каждого пользователя (а их к счастью мало) требуется проф.версия офис с Access на борту + установка тех.поддержкой соотв.драйвера odbc.
Если потребуется расширить список сотрудников (пока не говорим о теме данной статьи с web ) в рамках той же связки, эту связку потянет Access Runtime?
(версии Windows и Office у всех одинаковые)
средняя по средней- какая прелесть))
Особенно приятно удивление бизнеса из серии: "а шо это?" когда он (бизнес) начинает менять очередность измерений в заголовках строк сводной и видит изменение этой "средней".
выдача HH.ru по ключевым словам R + Data выдает (в мобильной версии) 5 страниц вакансий с навыками R, при этом первые 3 страницы — уже 45 вакансий с R (дальше не считал). Не очень вяжется с Вашим графиком где число вакансий с R в 2 раза ниже чем Scala/Matlab и чуть выше чем Excel "… в области big data и data science..."
Да, считает. Если бы в УУ оперировали только издержками, экономистам жилось бы куда проще))
Более того, УУ зачастую живет и прогнозами ибо ТОПам в принятии решений важен сценарный подход
Илья, приветствую.
Как обычно — рад «вестям с полей», мало кто в рунете пишет про R в реалиях бизнес-процессов, все больше студенческие проекты и частные эксперименты.
По #1 так же пришлось парсить один ресурс под скачивание 46000 номенклатурных позиций для создания мастер-данных БД. К счастью то же обошлось без Селениум, и набор пакетов был скромнее ибо простой постраничный вывод (более 2000 страниц): обошелся только rvest +dplyr
По #2: не увидел в пакетах e1071 или caret. как тюнинговались mtry и ntrees? через tuneRF?
просто интересно, можете обосновать Ваше удовольствие? т.к. наталкиваюсь уже не в первый раз на упоминание о неудобстве (конечно субъективном) работы пользователей с питоном
Илья, приветствую. Спасибо за очередную статью на животрепещущую тему.
В очередной раз решаю нетривиальную бизнес-задачу: в этот раз требуется объединение множества xls файлов ( 200 — 300 файлов по 15 мегов в среднем = 3-4,5 гига суммарно)
Споткнулся уже на старте: популярные пакеты R напрочь отказываются читать эти фалы ибо Excel 5.0/7.0 (BIFF5) format
Вот ругательство от library(xlsx):
d < — xlsx::read.xlsx(file=file.choose(),sheetIndex=1)
# Error in .jcall(«RJavaTools», «Ljava/lang/Object;», «invokeMethod», cl,:
# org.apache.poi.hssf.OldExcelFormatException: The supplied spreadsheet seems to be Excel 5.0/7.0 (BIFF5) format.
# POI only supports BIFF8 format (from Excel versions 97/2000/XP/2003)
Вот ругательство от library(readxl) #hadley
# fread: wanted 1 got 0 loc=15351296
Учитывая что есть крайне положительный опыт использования Microsoft:PowerQuery в сборке офиса 2013 в пару кликов объеденил все эти бинарники в единый файл (есть встроенный функционал перебора файлов из указанной папки), но беда в том что дальше этот массив можно отправить либо в модель PowerPivot либо на лист Excel (ограничение в миллион строк). К сожалению прямой экспорт в csv/txt и любые другие форматы PowerQuery не поддерживает. Учитывая что массив в несколько десятков миллионов записей на лист Excel не положить (что бы пересохранить в csv) — попал в тупик.
Неожиданно нашел направление куда рыть: вспомнил что Power BI Desktop содержит на борту:
1) Power Query
2) прямую поддержку R
Таким образом забрезжил свет в конце туннеля, по результатам отпишусь.
В тему данной статьи состоялась переписка с автором по применимости советов из этого поста к реальной рабочей задаче.
Есть корпус из 32536 документов (один документ = предложение из 2-10 термов) и словарь термов (дата фрейм: 1-й столбец — какой терм брать, 2-й столбец — на какой заменить)
Размер словаря = 4005 термов (используется в качестве стеммера с учетом отраслевой специализации)
Общая цель задачи — классификация документов
Ранее тупым перебором словаря в цикле с отдачей каждой пары значений в регулярку (gsub) на замену слов корпуса уходило примерно 230 секунд (тупо загружалось одно ядро)
Благодаря советам автора распараллеливание на 4 ядра дало ускорение в 10 раз (т.е. до 23 секунд).
+ к этому в процессе переписки с Ильей переосмыслил некоторые подходы, на будущее теперь есть хороший инструментарий «турбонаддува» R за что автору большое спасибо.
Илья, спасибо большое.
P.S. Использовались следующие пакеты:
library(dplyr)
library(tidyr)
library(magrittr)
library(purrr)
library(stringr)
library(tibble)
library(iterators)
library(foreach)
library(doParallel)
А как же такое?
Не очень понял чем Вам R не угодил? Откуда такая брезгливость?
Не понял — трансляции не предусмотрено?
А на чем графики рисовались?
простите, не смог удержаться
почему то подумалось про второе пришествие R Commander + Rattle + ggedit
Сергей, добрый день.
Затронули очень болезненную для меня тему.
Дико извиняюсь что написал ниже много букв, но без такой вводной не смогу получить правильного ответа.
У нас текущий бизнес процесс сильно завязан на классификацию мастер-данных (справочников), если чуть детальней-то речь про работу с вином: ежедневно приходит массив грязных зашумленных данных от внешних поставщиков информации о продажах вин в крупнейших розничных сетях по всей России с детализацией до точки продаж. Речь не только про продажи Российских вин, а о всех винах вообще (со всего мира).
Операторы получают новые вариации названий вин ежедневно и должны их классифицировать, т.е. правильно привязать в справочниках новые объекты на вина заведенный в стандартах нашей компании (а если не нашлось ничего похожего то создать такой класс и привязать к этому созданному)
Естественно поток информации настолько велик, что приходится задейстовать машинное обучение: там где модель уверенна выше чем на 99%, то классификация происходит автоматически, там где модель уверенна ниже- она участвует в системе в роли рекомендательного алгоритма с которым оператор либо соглашается либо нет.
Итого сейчас у нас 31925 классов, из них пустых (то о чем Вы писали -не разметили еще ассесоры)= 1761
Дисбаланс классов на картинке ниже
Отличие от классических задач текст-майнинга в следующем:
Вина именуются в системах наших сетевых ритейлеров чаще всего на кириллице как правило из франко-итальянских словоформ с "трудностями перевода" — где-то двойные буквы, где то одинарные(напр. количество букв "с" подряд может быть в любом месте произвольным: Вино игристое Ламбруско ТМ Массимо Висконти бел.слад. 0,75*6 Италия /Аква Вита ТК/)-решается регулярками
Длина строки при вводе в систему у сетевых ритейлеров ограничена и их операторы что бы уместиться не теряя общего смысла начинают сокращать (например приходит к нам такой вот треш: "Вин.ПР.РОБ.РИБ.Д.ДУЭ.ДО кр.сух.0.75л" который становится у нас в классе "Вино Протос Робле Рибера дель Дуэро кр сух 0,75")- решается Гуглом и вангованием на стеклянном шаре с привлечением Астрологов
Очень много шума в тексте (импортеры, сетевой артикул и т.д.) -решается поддержкой списка стоп-слов
Слияния слов (AVESвиноМЕРЛО МаулеВелле кр.сух.0.75л)-решается регулярками
Разная степень сокращений ключевых для моделей термов ({красн, кр, крас};{п/сл, полусл, п-слад},{крпсл}) — решается регулярками
Далее по классике: токенизация, document-term matrix, tfidf, и удаление sparce-термов которые встречаются лишь в одном документе (не важно-в обучающей или предсказательной части матрицы).
И тут еще одна проблема: высокочастотные термы (красное, белое, розовое, сладкое, полусладкое, сухое, 0.75, 0.7, и т.д.) которые по понятным причинам имеют самый низкий tfidf оказывают решающую роль в классификации: если в векторном представлении бренды/винодельни или провиции произростания совпали но цвет вина или емкость оказались другими. то последствия такой ошибки классификации высоки — это мастер-данные к которым привязываются в системе продажи (в виде большого числа транзакций) и одна ошибка в цвете/емкости/сахарности транслируется многократно в отчетности.
Поэтому ничего не остается как такие ключевые высокочастотные термы с tfidf стремящимся к нулю докручивать до значений = 10000, что бы их вес был решающим.
Далее уже алгоритмы классификации: один — свой самописный (который возвращает еще и меру сходства с классом) и еще LIBLINEAR
Собственно сам вопрос:
можно ли из вышеописанных алгортимов Вашей статьи взять какую то часть на вооружение и улучшить текущий процесс с учетом вышеописанных проблем?
"Появились, также, проблемы с совместимостью. Access Runtime решал вопрос запуска СУУ у пользователей без установленного полноценного платного MS Access."
у нас ms sql server + Access 2013 (большая часть бизнес логики реализована в формах через VBA) в связке через odbc native client
(Я знаю что это некрасивое решение но когда данных много а пользователей мало — вполне себе жизнеспособно)
Т.е. у каждого пользователя (а их к счастью мало) требуется проф.версия офис с Access на борту + установка тех.поддержкой соотв.драйвера odbc.
Если потребуется расширить список сотрудников (пока не говорим о теме данной статьи с web ) в рамках той же связки, эту связку потянет Access Runtime?
(версии Windows и Office у всех одинаковые)
средняя по средней- какая прелесть))
Особенно приятно удивление бизнеса из серии: "а шо это?" когда он (бизнес) начинает менять очередность измерений в заголовках строк сводной и видит изменение этой "средней".
Более того, УУ зачастую живет и прогнозами ибо ТОПам в принятии решений важен сценарный подход
Как обычно — рад «вестям с полей», мало кто в рунете пишет про R в реалиях бизнес-процессов, все больше студенческие проекты и частные эксперименты.
По #1 так же пришлось парсить один ресурс под скачивание 46000 номенклатурных позиций для создания мастер-данных БД. К счастью то же обошлось без Селениум, и набор пакетов был скромнее ибо простой постраничный вывод (более 2000 страниц): обошелся только rvest +dplyr
По #2: не увидел в пакетах e1071 или caret. как тюнинговались mtry и ntrees? через tuneRF?
просто интересно, можете обосновать Ваше удовольствие? т.к. наталкиваюсь уже не в первый раз на упоминание о неудобстве (конечно субъективном) работы пользователей с питоном
Осталось проверить на всем массиве
Надо протестировать ибо сильно актуально
В очередной раз решаю нетривиальную бизнес-задачу: в этот раз требуется объединение множества xls файлов ( 200 — 300 файлов по 15 мегов в среднем = 3-4,5 гига суммарно)
Споткнулся уже на старте: популярные пакеты R напрочь отказываются читать эти фалы ибо Excel 5.0/7.0 (BIFF5) format
# Error in .jcall(«RJavaTools», «Ljava/lang/Object;», «invokeMethod», cl,:
# org.apache.poi.hssf.OldExcelFormatException: The supplied spreadsheet seems to be Excel 5.0/7.0 (BIFF5) format.
# POI only supports BIFF8 format (from Excel versions 97/2000/XP/2003)
Учитывая что есть крайне положительный опыт использования Microsoft:PowerQuery в сборке офиса 2013 в пару кликов объеденил все эти бинарники в единый файл (есть встроенный функционал перебора файлов из указанной папки), но беда в том что дальше этот массив можно отправить либо в модель PowerPivot либо на лист Excel (ограничение в миллион строк). К сожалению прямой экспорт в csv/txt и любые другие форматы PowerQuery не поддерживает. Учитывая что массив в несколько десятков миллионов записей на лист Excel не положить (что бы пересохранить в csv) — попал в тупик.
Неожиданно нашел направление куда рыть: вспомнил что Power BI Desktop содержит на борту:
1) Power Query
2) прямую поддержку R
Таким образом забрезжил свет в конце туннеля, по результатам отпишусь.
Есть корпус из 32536 документов (один документ = предложение из 2-10 термов) и словарь термов (дата фрейм: 1-й столбец — какой терм брать, 2-й столбец — на какой заменить)
Размер словаря = 4005 термов (используется в качестве стеммера с учетом отраслевой специализации)
Общая цель задачи — классификация документов
Ранее тупым перебором словаря в цикле с отдачей каждой пары значений в регулярку (gsub) на замену слов корпуса уходило примерно 230 секунд (тупо загружалось одно ядро)
Благодаря советам автора распараллеливание на 4 ядра дало ускорение в 10 раз (т.е. до 23 секунд).
+ к этому в процессе переписки с Ильей переосмыслил некоторые подходы, на будущее теперь есть хороший инструментарий «турбонаддува» R за что автору большое спасибо.
Илья, спасибо большое.
P.S. Использовались следующие пакеты:
library(dplyr)
library(tidyr)
library(magrittr)
library(purrr)
library(stringr)
library(tibble)
library(iterators)
library(foreach)
library(doParallel)