Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
А сам код открыт?
Нет.
Открытие кода будет препятствовать досиижению сразу двух целей:
Открытие кода будет препятствовать досиижению сразу двух целей:
- поиску стратегического инвестора или нового владельца
- выбранным направлениям развития продукта.
В самом начале работы я посмотрел на существующие (наиболее известные) пакеты под python, которые позволят или помогут решить задачу. Вообще их очень много, но по большей части они разбились на группы:
1. не поддерживают или не очень хорошо поддерживают русский язык
2. поддерживают русский язык, но ключевая задача — качественный морфологический анализ
3. поддерживают русский язык, но ключевая задача — выявление ключей заданной, узкой направленности, в ряде случаев, через словари.
По мере поиска и выбора я естественно вышел и на Наташу. К счастью они уже сделали анализ инструментов по работе с русским языком, с которым я на тот момент также познакомился.
В итоге мой выбор остановился на, как мне кажется, наиболее сильных пакетах в этой области — NLTK и pymorhy2.
NLTK отпал после токенизации предложений первых же трех текстов на русском языке.
pymorhy2 мне понравился. НО, он решает задачи морфологии, а моя задача была выявление ключевых слов до анализа, а позже уже и не слов, а ключевых выражений. Многие слова, из признанных мной ключами получат в Pymorhy2 дополнительную гарммему UNKN — токен неидентифицирован, и это, для решаемой pymorhy задачи, абсолютно верный вывод.
Но для моей задачи — МиГ-29 не UNKN, это однозначно ключевое слово, которое должно иметь значимую для дальнейшего анализа граммему.
Кроме того, в этом же тексте присутствует название программы nrlpk и ещё расшифровка — Natural Russian Language Processing by the Keys. Тот, кто писал текст умышленно сделал так, чтобы читателю было очевидно, что это — значимые сущности текста, и что это одно и тоже понятие.
Мне хотелось, чтобы и машина это «увидела», чтобы где-то (сейчас это в поле lemm) это и стало одним и тем-же.
Но для этого нельзя было допустить пословной токенизации до завершения анализа текста и выбора значимых выражений. И вот здесь мы разошлись в идеологии с pymorhy2.
Т.е. по сути, я просто решаю немного иную задачу.
1. не поддерживают или не очень хорошо поддерживают русский язык
2. поддерживают русский язык, но ключевая задача — качественный морфологический анализ
3. поддерживают русский язык, но ключевая задача — выявление ключей заданной, узкой направленности, в ряде случаев, через словари.
По мере поиска и выбора я естественно вышел и на Наташу. К счастью они уже сделали анализ инструментов по работе с русским языком, с которым я на тот момент также познакомился.
В итоге мой выбор остановился на, как мне кажется, наиболее сильных пакетах в этой области — NLTK и pymorhy2.
NLTK отпал после токенизации предложений первых же трех текстов на русском языке.
pymorhy2 мне понравился. НО, он решает задачи морфологии, а моя задача была выявление ключевых слов до анализа, а позже уже и не слов, а ключевых выражений. Многие слова, из признанных мной ключами получат в Pymorhy2 дополнительную гарммему UNKN — токен неидентифицирован, и это, для решаемой pymorhy задачи, абсолютно верный вывод.
Но для моей задачи — МиГ-29 не UNKN, это однозначно ключевое слово, которое должно иметь значимую для дальнейшего анализа граммему.
Кроме того, в этом же тексте присутствует название программы nrlpk и ещё расшифровка — Natural Russian Language Processing by the Keys. Тот, кто писал текст умышленно сделал так, чтобы читателю было очевидно, что это — значимые сущности текста, и что это одно и тоже понятие.
Мне хотелось, чтобы и машина это «увидела», чтобы где-то (сейчас это в поле lemm) это и стало одним и тем-же.
Но для этого нельзя было допустить пословной токенизации до завершения анализа текста и выбора значимых выражений. И вот здесь мы разошлись в идеологии с pymorhy2.
Т.е. по сути, я просто решаю немного иную задачу.
С момента размещения материала число маркеров выросло с 16 до 22, что, ожидаемо, повысило качество отбора ключей. Смотрим результат анализа этой статьи (позиция 48 старый алгоритм, 48-1 – обновленный). С обновленным алгоритмом число слов в мусоре снизилось с 41 до 13, и из ручной сверки один ключ вошел корректно (смотрим те же позиции 48 и 48-1).
При добавлении маркеров продолжил сохранять совместимость в маркировке граммем с pymorhy2 и добавил с той же смысловой нагрузкой:
Пунктуация понадобилась в рамках подготовки результата к многослойной маркировке текста.
В рамках этой работы и поиска ключей, внутри маркированных выражений сделана декомпозиция выражений с умным отбором ключей в окончательную выборку.
Декомпозиция дала более точное значение числа слов в тексте – сравнение анализа текста с разными алгоритмами это явно показывает.
Характеристики текста тоже были уточнены.
Ну и чисто из любопытства, пропустил через nrlpk свой предыдущий комментарий с теми же параметрами (позиция 49 в списках), получилось, что под ним, должны бы были автоматически сгенерироваться следующие ключи: lemm, nltk, nrlpk, pymorhy, pymorhy2, python, unkn, анализ, задача, ключевой, машина, миг-29, наташа, ни, русский, слово, текст, увидел, язык.
В мусор ушло 6 слов – слова с орфографическими ошибками и не идентифицированные — пока…
При добавлении маркеров продолжил сохранять совместимость в маркировке граммем с pymorhy2 и добавил с той же смысловой нагрузкой:
- LATN — токен состоит из латинских букв;
- PNCT – пунктуация
Пунктуация понадобилась в рамках подготовки результата к многослойной маркировке текста.
В рамках этой работы и поиска ключей, внутри маркированных выражений сделана декомпозиция выражений с умным отбором ключей в окончательную выборку.
Декомпозиция дала более точное значение числа слов в тексте – сравнение анализа текста с разными алгоритмами это явно показывает.
Характеристики текста тоже были уточнены.
Ну и чисто из любопытства, пропустил через nrlpk свой предыдущий комментарий с теми же параметрами (позиция 49 в списках), получилось, что под ним, должны бы были автоматически сгенерироваться следующие ключи: lemm, nltk, nrlpk, pymorhy, pymorhy2, python, unkn, анализ, задача, ключевой, машина, миг-29, наташа, ни, русский, слово, текст, увидел, язык.
В мусор ушло 6 слов – слова с орфографическими ошибками и не идентифицированные — пока…
У меня такое ощущение, что аббревиатуры вам совсем не надо было делать. кроме возможно нескольких узких тем, они только всех путают. «2т 2ф2г чп чмо пнврт шо nusr nlrp wiqm» — что это за хрень вообще? :) Аналогично, что за «lemm» и «unkn» у комментария? И что за суперценное слово «ни»? И как отражают смысл документа слова «выуживающий» и «глазками»? :)
В общем, заведите корпус побольше и по нему валидируйтесь и настраивайте свой алгоритм на правилах. А потом может даже добавите туда нейросети, чтобы получше стало с учётом синонимов и пониманием, какие слова важны, а какие нет. Опечатки, например, станете убирать: «pymorhy» и «pymorhy2». Сейчас вообще всё как-то плохо.
Да, и почему вы только на единичных словах сосредоточились? А где словосочетания?
//да и вообще, поглядите может всё же на ключевые работы по keyword extraction, опасаюсь, что вы занимаетесь велосипедостроением…
В общем, заведите корпус побольше и по нему валидируйтесь и настраивайте свой алгоритм на правилах. А потом может даже добавите туда нейросети, чтобы получше стало с учётом синонимов и пониманием, какие слова важны, а какие нет. Опечатки, например, станете убирать: «pymorhy» и «pymorhy2». Сейчас вообще всё как-то плохо.
Да, и почему вы только на единичных словах сосредоточились? А где словосочетания?
//да и вообще, поглядите может всё же на ключевые работы по keyword extraction, опасаюсь, что вы занимаетесь велосипедостроением…
У меня такое ощущение, что аббревиатуры вам совсем не надо было делать.
Я попробую построить свой ответ вокруг вот этой точно подмеченной, как одна из проблем, фразы. Пойду от простых моментов к наиболее спорным.
«2т 2ф2г чп чмо пнврт шо nusr nlrp wiqm» — что это за хрень вообще? :)… Аналогично, что за «lemm» и «unkn» у комментария?
По тексту без дополнительной обработки присутствуют слова: nusr, wiqm, lemm и unkn.
Логика их отбора в чистом виде такова: если автор поставил в текст иностранные слова для основного языка, значит он хотел обратить внимание на эти «термины» или «названия».
Ответ, по 2т 2ф2г чп чмо пнврт шо nlrp ни — будет ниже.
И как отражают смысл документа слова «выуживающий» и «глазками»? :)
Слова «выуживающий» и «глазками» автор текста поставил в кавычки, выделил по тексту таким образом, чтобы читатель обязательно обратил на них внимание, т.е. по сути, он сказал — для меня, это не просто слова в тексте, для меня это важно.
Логика их отбора — если для автора это важно, значит для системы это ключ.
В общем, заведите корпус побольше и по нему валидируйтесь и настраивайте свой алгоритм на правилах.
Вся система сейчас построена на правилах. Вы обратили внимание, что я нигде по тексту не упоминал, что работает ИИ, и в хабах к статье умышленно не выбрал ИИ. Потому что, пока есть что ещё можно выжать логикой.
Опечатки, например, станете убирать: «pymorhy» и «pymorhy2».
Почему Вы решили, что это опечатки? А вот если по тексту так самолет Ан-2 и компания Ан. Тут система тоже должна отреагировать так, что это опечатки?
В данном конкретном случае, у pymorhy действительно есть две версии, базовая, которая была запущена изначально, так и называлась pymorhy, следующая стала называться pymorhy2.
Я уже проходил эту дискуссию сам с собой при анализе названий, и даже была версия ПО, которая могла взять например Ми-28Н Ночной Охотник — вместе, однако, когда далее по тексту я видел отдельно Ми-28Н и Ночной Охотник, то понял, что я не прав. И эта логика оказалась некорректной, поэтому была отключена.
Да, и почему вы только на единичных словах сосредоточились? А где словосочетания?
Вот теперь вернемся к нашим (2т 2ф2г чп чмо пнврт шо nlrp ни) аббревиатурам — всё это, сгенерированные аббревиатуры «выражений» — словосочетаний в Ваших терминах, по разным алгоритмам для разных маркеров. Вы можете их сами увидеть в выборках в поле tword или word. Для удобства разбора я их приведу здесь:
- 2т — 25 тонн, строка в ключах 1256, кстати нынче по тексту чаще можно встретить 25 т или 25т
- 2ф2г — 25 февраля 2020 года строки в ключах 1216 и 1226
- чп — четко позиционирующих строка в ключах 1364
- пнврт — исключен по новому алгоритму, однако в старом фраза была «практические наблюдения в результате тестирования» строки в ключах 743 и 753
- шо — широкого охвата, строка в ключах 1410
- nlrp — новый алгоритм формирует более корректную аббревиатуру «nrlpk», что соответствут слову «nrlpk» по тексту строка в ключах 213, созданному из выражения по тексту Natural Russian Language Processing by the Keys строка в ключах 214, а для старого отбиралось выражение Natural Russian Language Processing строка в ключах 118
Всю эту расшифровку я собственно привел по двум причинам
- показать, что выражения (словосочетания) как раз выбираются, но далеко не по принципу два слова стоящие рядом и частота их повторения — это далеко не всегда есть ключи.
- показать тонкости проблемы аббревиатуры.
Первая тонкость, зачем нужны аббревиатуры очень хорошо показывает себя на Natural Russian Language Processing by the Keys — если не превратить это выражение в корректную аббревиатуру, то:
- оно не посчитается частотой упоминаний по тексту с названием nrlpk, которое также присутствует в тексте. И это просто удача, что оба этих выражения иностранные и так и так попали в ключи, а ведь могли бы быть каким-нибудь русским названием и его сокращением, которое смогло бы попасть в ключи только по принципу частоты упоминания по тексту в разных словоформах
- непонятно как его показывать в ключах (хештегах), как слова без пробелов (как в инстаграмм например), типа naturalrussianlanguageprocessingbythekeys — насколько это вообще лучше? для меня лично это спорный вопрос. Для Хабра в частности, видимо тоже вопрос очень спорный, поскольку у них для разметки своих текстов предложен html-тэг
<abbr></abbr>
с возможностью расшифровки аббревиатуры хинтом.
Вопрос аббревиатур, который Вы поднимаете, у меня тоже вызывает много сомнений, но — пока он показал себя как наилучший вариант выхода из ситуаций, наподобие такой — в тексте "выставка цветов" и "выставку цветов" — отобранные выражения не будут равны друг другу, хотя это одно и тоже, и даже если провести декомпозицию выражения с последующей пословной токенизацией, лемматизацией и снова сделать выражением, то мы получим «выставка цветок», что меняет смысл выражения и становится нечитабельным, и при этом так и не решается проблема, а как же показать её в качестве ключа — выставкацветок или вц?
Хочется отметить, что при анализе использования аббревиатур в качестве ключей рассматривалось и положительное влияние на выборку по тексту и отрицательное. Например, в тексте, который мы рассматриваем, есть два разных выражения, которые корректно попали в ключи, но совпали по аббревиатуре, хотя и имеют разные значения. Это Pandas DataFrame или Python Dictionary — оба они получили аббревиатуру pd.
Однако, тестирование показало, что количество таких случаев в рамках одного текста встречается кратно реже, чем одинаковые выражения с разными формами слов.
Поэтому пока я остановился именно на варианте аббревиатур, хотя я с Вами полностью согласен в том, что вид у таких аббревиатур зачастую отталкивающий, чем расшифровывающий смысл, но идею Хабра по title в abbr возможно и можно превратить в более корректное именно представление ключа, а не его отбор.
поглядите может всё же на ключевые работы по keyword extraction
Ответ в моих комментариях выше.
Возможно Вы подскажите какой то пакет, который в этом вопросе на русском языке себя очень сильно зарекомендовал?
Да я понимаю, какая аббревиатура откуда взялась, в конце концов, у меня у одного из заказчиков есть legacy решение 20-летней давности, которое извлекает ключевые слова, основываясь на частотности и стемминге, и простое эвристическое решение 3-летней давности, которое извлекает ключевые слова, но учитывает ещё и их связи. Так что я такое делал, смотрел, как оно работает, и смотрел похожие решения.
1) Если хотите объединять похожие слова — без словаря синонимов (можно взять word2vec) и синтаксического анализатора (генерирующего именованные фразы) вам не обойтись.
2) Померьте как-то автоматически качество, в конце концов. Интуиция часто врёт в этом вопросе, да и не позволяет ручной просмотр усреднять по многим тестам сразу. Кроме того, это наверняка ускорит ваш релиз-цикл.
3) Вам нужны эти ключевые слова для человека или для компьютера? Компьютер вполне сжуёт аббревиатуры, и они могут помочь при поиске похожих статей.
А вот человеку, как мне кажется, нужно обычно совсем другое — (a) ключевые слова, которые обозначают тему статьи, и (b) ключевые слова, которые потом будут с наибольшей вероятности использоваться при поиске. Если ваша статья про извлечение ключевых слов, то в ключевых словах должно быть «ключевые слова», «выделение ключевых слов», «keyword extraction», «keywords», а не «2т», «чп», и что-то непонятное из одних согласных, что читается как «японаврот». Согласны?
1) Если хотите объединять похожие слова — без словаря синонимов (можно взять word2vec) и синтаксического анализатора (генерирующего именованные фразы) вам не обойтись.
2) Померьте как-то автоматически качество, в конце концов. Интуиция часто врёт в этом вопросе, да и не позволяет ручной просмотр усреднять по многим тестам сразу. Кроме того, это наверняка ускорит ваш релиз-цикл.
3) Вам нужны эти ключевые слова для человека или для компьютера? Компьютер вполне сжуёт аббревиатуры, и они могут помочь при поиске похожих статей.
А вот человеку, как мне кажется, нужно обычно совсем другое — (a) ключевые слова, которые обозначают тему статьи, и (b) ключевые слова, которые потом будут с наибольшей вероятности использоваться при поиске. Если ваша статья про извлечение ключевых слов, то в ключевых словах должно быть «ключевые слова», «выделение ключевых слов», «keyword extraction», «keywords», а не «2т», «чп», и что-то непонятное из одних согласных, что читается как «японаврот». Согласны?
Начну ответ с конца Вашего поста, поскольку вижу, что наша логика по поиску ключевых слов очень различается, поэтому я попытаюсь объяснить свою через примеры и аргументы.
На примере этой статьи. Если бы я писал статью про NLP — то по телу статьи я просто неизбежно бы употреблял аббревиатуру NLP, НО — статья про инструмент, который работает в классе NLP, и NLP здесь не ключевой момент, поэтому в теле статьи это слово не употребляется ни разу.
Все остальные слова заголовка вошли в ключи.
НО, насколько я понимаю, Ваш вопрос имеет немного иной смысл. Вы хотите, чтобы формирование ключей отталкивалось от заголовка, как приоритета в подборе ключей?
Если это так, то я собственно начал работу над проектом именно с этой мысли. И в начале мне казалось, что это самый верный путь, пока я не увидел огромную кучу заголовков, которые плохо коррелируют с текстом, под этим заголовком — даже визуально, не что машинно. Вот например Сложность простоты или вот В России могут появиться летающие батареи. А у постов в соц. сетях или скажем у этого комментария вообще нет и не предусмотрен заголовок.
Однако я соглашусь с Вами, что заголовок статьи, если он есть, также должен попадать под анализ через инструмент и его выражения также должны участвовать в ключах, и да — вероятно, что они должны получить статус приоритета в ключах — последний вывод надо хорошенько взвесить!
Вы абсолютно верно говорите о том, что должно бы получиться в итоге, рассуждая как специалист, много и глубоко работающий с Интернет. НО — давайте уйдём от логики человека, специалиста и включим логику машины. Логика машины звучит так:
Если логику машины распространить на Ваше предложение то, она должна бы быть дополнена следующим пунктом:
Суть моего продукта — немного о другом, на самом деле. Мой продукт — это первые два пункта машинной логики и один главный пункт логики человека. Главный пункт логики человека, который пишет статью:
Человек, при написании статьи не обязан заботиться о том, какие у него в итоге из неё получаться ключи.
Смотрите, что я пытаюсь решить. Как это сейчас, скажем на Хабре:
1. написал текст (60-80% времени в зависимости от длины текста)
2. нажал предпосмотр (0% времени)
3. получил текст (0% времени)
4. сформировал ключи к нему (20% — 40% времени в зависимости от текста статьи и желания ухватить аудиторию, и это если не заморачиваться на подбор ключей через яндекс ворд или подбор наиболее посещаемых ключей в той соц. сети, в которой размещается статья или пост — при таком подходе, время на подбор ключей может быть сопоставимо с временем написания статьи)
5. нажал разместить.
Теперь к примеру Хабр + nrlpk:
1. написал текст — человек (60-80% времени в зависимости от длины текста)
2. нажал предпросмотр — человек (0% времени)
3. получил текст и ключи к нему — Хабр + nrlp (0% времени)
4. выключил ненужные ключи — Хабр + человек (5% времени)
5. нажал разместить — человек (0% времени)
Можно убрать одно лишнее действие и сократить 20-35% времени человека на размещение материала, без потери качества материала. За nrlpk здесь только часть пункта 3.
50/50 :)
Вы хотите, чтобы машина решила за человека (автора материала), что для него в его статье важнее? А может я, как автор, хотел, чтобы ключами здесь были «машинное обучение», «русский язык» и «nrlp» — потому, что мне автору, видится это именно так. Поэтому с Вашим доводом я согласен только на 50%, и более того, мне кажется, что такая подмена сможет эффективно работать на очень небольших по размеру и узкоспециализированных текстах.
Теперь по оставшимся 50%
Вы рассуждаете как специалист в этой области, смотрящий со стороны. Возможно для Вас это не очевидно, но присмотритесь к Вашему предложению — вы предлагаете, чтобы ключами к русскому тексту была половина иностранных слов. С точки зрения специалиста — плюсы предложения очевидны, правда, как выйти на такие ключи в русском тексте, остается за кадром.
Попробуйте поставить себя на место автора статьи вот с тем же требованием к ключам.
Разве не должны Вы, как автор текста, упомянуть в тексте, то, что Вы считает должно бы стать ключевыми мыслями Вашего материала? По моему — это было бы более, чем правильно. И это ключевая идея nrlpk.
Так вот в 50% я включил только то, что да — аббревиатуры читаются плохо, но я пока не вижу им достойной альтернативы. И это пока проблема…
Ох — за вопрос этот спасибо. Тема на самом деле очень неоднозначная. Я обсуждал «нужны ли вам ключи?» с частью своего окружения, которая не имеет отношения к ИТ, но пользуется соц. сетями.
Многим из них мне сперва пришлось объяснить, что ключи это классно, для того, чтобы их посты увидело как можно больше людей и можно было бегло глянув понять о чем текст. Услышана была всеми только первая часть фразы — про много людей…
А потом я останавливал их от попыток запихнуть в ключи каждое слово своих постов и вставить много популярных ключей, которые не имеют отношения к их постам.
При написании nrlpk я опирался на такую формулировку — ключи нужны человеку для оценки «а всё ли я сказал, что хотел» и машине — для связки текстов в один поток по ключам.
Это сильное заблуждение. Я тоже не сразу это заметил, но это факт.
Чем больше статей в обработке, тем больше эффект от повторения одинаковых аббревиатур к разным выражениям. Т.е. если в одном тексте приведение к аббревиатурам дает 1 совпадение аббревиатур на 35-40 текстов, то в 35-40 текстах будет уже с десяток совпадений.
Т.е. выход из ситуации с аббревиатурами всё равно придется какой-то искать.
Я не хочу на данной стадии «объединять похожие слова» и добавлять огромные и сложные (и даже неоднозначные) словари, требующие сопровождения. Точнее так, я не хочу их объединять через словари, мне бы хотелось поискать другой путь, но тут нужна небольшая команда — и это я бы оставил в рамках работы с инвестором или покупателем, поскольку планка входа в проект с реализацией этого алгоритма будет сильно выше, а вот процент роста качества результата — весьма неоднозначен, и крайне плохо предсказуем.
Словари это такая «удобная» тема, что по идее можно их создать подо всё -адреса, фио, компании, названия и т.д. А потом утонуть в их поддержке и в итоге отказаться от самой системы, затраты на поддержание которой превышают эффект от её применения.
Пока я объединяю слова по леммам и аббревиатурам — и это выдает 85-93% качества.
Для повышения качества отбора ещё не задействованы три механизма, стоящие в очереди разработки, которые не требуют увеличения числа словарей, в их числе и самообучение без ИИ (пока и это можно без ИИ). Но всё это тоже повышают планку вхождения для инвестора или покупателя.
Кстати, текущая доработка позволила сделать словарь специальных слов — необязательным.
Та часть качества, которая относится к оценке качества по выпавшим словам в мусор итак считается автоматически, а вот то, что не вошло или вошло неверно померить автоматически можно только имея инструмент, который отбирает всё и всегда верно.
Но если бы у меня был такой инструмент, то зачем бы мне было писать nrlpk?
(a) ключевые слова, которые обозначают тему статьи
На примере этой статьи. Если бы я писал статью про NLP — то по телу статьи я просто неизбежно бы употреблял аббревиатуру NLP, НО — статья про инструмент, который работает в классе NLP, и NLP здесь не ключевой момент, поэтому в теле статьи это слово не употребляется ни разу.
Все остальные слова заголовка вошли в ключи.
НО, насколько я понимаю, Ваш вопрос имеет немного иной смысл. Вы хотите, чтобы формирование ключей отталкивалось от заголовка, как приоритета в подборе ключей?
Если это так, то я собственно начал работу над проектом именно с этой мысли. И в начале мне казалось, что это самый верный путь, пока я не увидел огромную кучу заголовков, которые плохо коррелируют с текстом, под этим заголовком — даже визуально, не что машинно. Вот например Сложность простоты или вот В России могут появиться летающие батареи. А у постов в соц. сетях или скажем у этого комментария вообще нет и не предусмотрен заголовок.
Однако я соглашусь с Вами, что заголовок статьи, если он есть, также должен попадать под анализ через инструмент и его выражения также должны участвовать в ключах, и да — вероятно, что они должны получить статус приоритета в ключах — последний вывод надо хорошенько взвесить!
(b) ключевые слова, которые потом будут с наибольшей вероятности использоваться при поиске. Если ваша статья про извлечение ключевых слов, то в ключевых словах должно быть «ключевые слова», «выделение ключевых слов», «keyword extraction», «keywords»
Вы абсолютно верно говорите о том, что должно бы получиться в итоге, рассуждая как специалист, много и глубоко работающий с Интернет. НО — давайте уйдём от логики человека, специалиста и включим логику машины. Логика машины звучит так:
- я могу выбрать любые сущности из текста, если они есть в тексте
- для такого выбора мне нужны заданные алгоритмы отбора.
Если логику машины распространить на Ваше предложение то, она должна бы быть дополнена следующим пунктом:
- если нужны данные не из текста, то мне нужен источник — переводник ключей, отобранных из текста в ключи, которые нужны на выходе.
Суть моего продукта — немного о другом, на самом деле. Мой продукт — это первые два пункта машинной логики и один главный пункт логики человека. Главный пункт логики человека, который пишет статью:
- статьей я хочу донести суть того, о чем в ней и пишу.
Человек, при написании статьи не обязан заботиться о том, какие у него в итоге из неё получаться ключи.
Смотрите, что я пытаюсь решить. Как это сейчас, скажем на Хабре:
1. написал текст (60-80% времени в зависимости от длины текста)
2. нажал предпосмотр (0% времени)
3. получил текст (0% времени)
4. сформировал ключи к нему (20% — 40% времени в зависимости от текста статьи и желания ухватить аудиторию, и это если не заморачиваться на подбор ключей через яндекс ворд или подбор наиболее посещаемых ключей в той соц. сети, в которой размещается статья или пост — при таком подходе, время на подбор ключей может быть сопоставимо с временем написания статьи)
5. нажал разместить.
Теперь к примеру Хабр + nrlpk:
1. написал текст — человек (60-80% времени в зависимости от длины текста)
2. нажал предпросмотр — человек (0% времени)
3. получил текст и ключи к нему — Хабр + nrlp (0% времени)
4. выключил ненужные ключи — Хабр + человек (5% времени)
5. нажал разместить — человек (0% времени)
Можно убрать одно лишнее действие и сократить 20-35% времени человека на размещение материала, без потери качества материала. За nrlpk здесь только часть пункта 3.
«ключевые слова», «выделение ключевых слов», «keyword extraction», «keywords», а не «2т», «чп», и что-то непонятное из одних согласных, что читается как «японаврот». Согласны?
50/50 :)
Вы хотите, чтобы машина решила за человека (автора материала), что для него в его статье важнее? А может я, как автор, хотел, чтобы ключами здесь были «машинное обучение», «русский язык» и «nrlp» — потому, что мне автору, видится это именно так. Поэтому с Вашим доводом я согласен только на 50%, и более того, мне кажется, что такая подмена сможет эффективно работать на очень небольших по размеру и узкоспециализированных текстах.
Теперь по оставшимся 50%
Вы рассуждаете как специалист в этой области, смотрящий со стороны. Возможно для Вас это не очевидно, но присмотритесь к Вашему предложению — вы предлагаете, чтобы ключами к русскому тексту была половина иностранных слов. С точки зрения специалиста — плюсы предложения очевидны, правда, как выйти на такие ключи в русском тексте, остается за кадром.
Попробуйте поставить себя на место автора статьи вот с тем же требованием к ключам.
Разве не должны Вы, как автор текста, упомянуть в тексте, то, что Вы считает должно бы стать ключевыми мыслями Вашего материала? По моему — это было бы более, чем правильно. И это ключевая идея nrlpk.
Так вот в 50% я включил только то, что да — аббревиатуры читаются плохо, но я пока не вижу им достойной альтернативы. И это пока проблема…
3) Вам нужны эти ключевые слова для человека или для компьютера? Компьютер вполне сжуёт аббревиатуры, и они могут помочь при поиске похожих статей.
Ох — за вопрос этот спасибо. Тема на самом деле очень неоднозначная. Я обсуждал «нужны ли вам ключи?» с частью своего окружения, которая не имеет отношения к ИТ, но пользуется соц. сетями.
Многим из них мне сперва пришлось объяснить, что ключи это классно, для того, чтобы их посты увидело как можно больше людей и можно было бегло глянув понять о чем текст. Услышана была всеми только первая часть фразы — про много людей…
А потом я останавливал их от попыток запихнуть в ключи каждое слово своих постов и вставить много популярных ключей, которые не имеют отношения к их постам.
При написании nrlpk я опирался на такую формулировку — ключи нужны человеку для оценки «а всё ли я сказал, что хотел» и машине — для связки текстов в один поток по ключам.
Компьютер вполне сжуёт аббревиатуры, и они могут помочь при поиске похожих статей.
Это сильное заблуждение. Я тоже не сразу это заметил, но это факт.
Чем больше статей в обработке, тем больше эффект от повторения одинаковых аббревиатур к разным выражениям. Т.е. если в одном тексте приведение к аббревиатурам дает 1 совпадение аббревиатур на 35-40 текстов, то в 35-40 текстах будет уже с десяток совпадений.
Т.е. выход из ситуации с аббревиатурами всё равно придется какой-то искать.
1) Если хотите объединять похожие слова — без словаря синонимов (можно взять word2vec) и синтаксического анализатора (генерирующего именованные фразы) вам не обойтись.
Я не хочу на данной стадии «объединять похожие слова» и добавлять огромные и сложные (и даже неоднозначные) словари, требующие сопровождения. Точнее так, я не хочу их объединять через словари, мне бы хотелось поискать другой путь, но тут нужна небольшая команда — и это я бы оставил в рамках работы с инвестором или покупателем, поскольку планка входа в проект с реализацией этого алгоритма будет сильно выше, а вот процент роста качества результата — весьма неоднозначен, и крайне плохо предсказуем.
Словари это такая «удобная» тема, что по идее можно их создать подо всё -адреса, фио, компании, названия и т.д. А потом утонуть в их поддержке и в итоге отказаться от самой системы, затраты на поддержание которой превышают эффект от её применения.
Пока я объединяю слова по леммам и аббревиатурам — и это выдает 85-93% качества.
Для повышения качества отбора ещё не задействованы три механизма, стоящие в очереди разработки, которые не требуют увеличения числа словарей, в их числе и самообучение без ИИ (пока и это можно без ИИ). Но всё это тоже повышают планку вхождения для инвестора или покупателя.
Кстати, текущая доработка позволила сделать словарь специальных слов — необязательным.
2) Померьте как-то автоматически качество, в конце концов. Интуиция часто врёт в этом вопросе
Та часть качества, которая относится к оценке качества по выпавшим словам в мусор итак считается автоматически, а вот то, что не вошло или вошло неверно померить автоматически можно только имея инструмент, который отбирает всё и всегда верно.
Но если бы у меня был такой инструмент, то зачем бы мне было писать nrlpk?
Вы — человек, который может решать задачу наилучшим и наиболее полезным способом. А вы воспринимаете себя как придаток машины и придумываете для вашего решения искусственные ограничения (которые иногда сами же потом не соблюдаете):
— «необходимо брать слова их статьи» (тогда почему у вас есть сокращения — это же не слова из статьи?),
— «нельзя взвешивать заголовок выше чем статью, потому что вдруг заголовок будет неактуальным да и вообще непонятно почему» — ну так определяйте, похож ли заголовок на статью или это отвлечённый от темы статьи мем/каламбур для привлечения внимания, и стоит ли брать оттуда ключевые слова.
— «NLP не упомянуто, поэтому не буду его брать» — здрасти, у вас есть "автоматизированная обработка для преобразования списка в набор хештегов или ключевых слов к тексту." и Natural Language Processing в тексте.
Ну и подобное же алогичное домысливание присутствует всюду, и в разных формах:
>Вы хотите, чтобы машина решила за человека (автора материала), что для него в его статье важнее? А может я, как автор, хотел, чтобы ключами здесь были «машинное обучение», «русский язык» и «nrlp» — потому, что мне автору, видится это именно так.
А разве не в этом задача продукта, который вы разрабатываете?
И ответьте на вопрос: сформированные ключевые слова потом кому нужны? Вам как автору статьи? Или читателям? (Или всё-таки другому компьютеру?)
В зависимости от цели, возможно, реализация будет разная.
>вы предлагаете, чтобы ключами к русскому тексту была половина иностранных слов.
С чего бы это я такое предлагал? И зачем? Какие ключевые слова ценнее для читателей, те и лучше.
>4. сформировал ключи к нему (20% — 40% времени в зависимости от текста статьи и желания ухватить аудиторию, и это если не заморачиваться на подбор ключей через яндекс ворд или подбор наиболее посещаемых ключей в той соц. сети, в которой размещается статья или пост — при таком подходе, время на подбор ключей может быть сопоставимо с временем написания статьи)
Чего????????? Это максимум минуту занимает.
>4. выключил ненужные ключи — Хабр + человек (5% времени)
Зачем???????? Если статья пишется 2 часа, то 5% времени — это 6 минут!
Ну и может не генерировать все возможные ключи, а предложить сразу оптимальные, а человек пусть потом добавляет или убирает, что хочет?
>>2) Померьте как-то автоматически качество, в конце концов. Интуиция часто врёт в этом вопросе
>Та часть качества, которая относится к оценке качества по выпавшим словам в мусор итак считается автоматически, а вот то, что не вошло или вошло неверно померить автоматически можно только имея инструмент, который отбирает всё и всегда верно.
То есть, вы не знаете, что такое тестовый сет в машинном обучении? (И сколько должно быть в нём данных, чтобы получать более-менее объективные результаты?)
— «необходимо брать слова их статьи» (тогда почему у вас есть сокращения — это же не слова из статьи?),
— «нельзя взвешивать заголовок выше чем статью, потому что вдруг заголовок будет неактуальным да и вообще непонятно почему» — ну так определяйте, похож ли заголовок на статью или это отвлечённый от темы статьи мем/каламбур для привлечения внимания, и стоит ли брать оттуда ключевые слова.
— «NLP не упомянуто, поэтому не буду его брать» — здрасти, у вас есть "автоматизированная обработка для преобразования списка в набор хештегов или ключевых слов к тексту." и Natural Language Processing в тексте.
Ну и подобное же алогичное домысливание присутствует всюду, и в разных формах:
>Вы хотите, чтобы машина решила за человека (автора материала), что для него в его статье важнее? А может я, как автор, хотел, чтобы ключами здесь были «машинное обучение», «русский язык» и «nrlp» — потому, что мне автору, видится это именно так.
А разве не в этом задача продукта, который вы разрабатываете?
И ответьте на вопрос: сформированные ключевые слова потом кому нужны? Вам как автору статьи? Или читателям? (Или всё-таки другому компьютеру?)
В зависимости от цели, возможно, реализация будет разная.
>вы предлагаете, чтобы ключами к русскому тексту была половина иностранных слов.
С чего бы это я такое предлагал? И зачем? Какие ключевые слова ценнее для читателей, те и лучше.
>4. сформировал ключи к нему (20% — 40% времени в зависимости от текста статьи и желания ухватить аудиторию, и это если не заморачиваться на подбор ключей через яндекс ворд или подбор наиболее посещаемых ключей в той соц. сети, в которой размещается статья или пост — при таком подходе, время на подбор ключей может быть сопоставимо с временем написания статьи)
Чего????????? Это максимум минуту занимает.
>4. выключил ненужные ключи — Хабр + человек (5% времени)
Зачем???????? Если статья пишется 2 часа, то 5% времени — это 6 минут!
Ну и может не генерировать все возможные ключи, а предложить сразу оптимальные, а человек пусть потом добавляет или убирает, что хочет?
>>2) Померьте как-то автоматически качество, в конце концов. Интуиция часто врёт в этом вопросе
>Та часть качества, которая относится к оценке качества по выпавшим словам в мусор итак считается автоматически, а вот то, что не вошло или вошло неверно померить автоматически можно только имея инструмент, который отбирает всё и всегда верно.
То есть, вы не знаете, что такое тестовый сет в машинном обучении? (И сколько должно быть в нём данных, чтобы получать более-менее объективные результаты?)
— «необходимо брать слова их статьи» (тогда почему у вас есть сокращения — это же не слова из статьи?),
Сокращения — это приведенные слова из статьи. Среди сокращений нет ни одного, которое бы было построено не из слов из статьи. Причем не просто из слов, любых выбранных произвольным порядком, а отобранных по четким и понятным правилам.
— «нельзя взвешивать заголовок выше чем статью, потому что вдруг заголовок будет неактуальным да и вообще непонятно почему» — ну так определяйте, похож ли заголовок на статью или это отвлечённый от темы статьи мем/каламбур для привлечения внимания, и стоит ли брать оттуда ключевые слова.
Именно поэтому в вопросе приоритетности слов заголовка я и сказал, что надо хорошо взвесить. Определение «похож» ли заголовок, слишком простое, для выдачи ему приоритета, неважно — похож он или нет, но следуя Вашей логике — это уже заголовок становится зависим (похож) от текста — и вся логика, изложенная Вами ранее
(a) ключевые слова, которые обозначают тему статьи
сразу разрушается об Ваши же дальнейшие, логичные рассуждения.
— «NLP не упомянуто, поэтому не буду его брать» — здрасти, у вас есть «автоматизированная обработка для преобразования списка в набор хештегов или ключевых слов к тексту.» и Natural Language Processing в тексте.
У меня нет в тексте Natural Language Processing — в тексте есть Natural Russian Language Processing. И я не представляю какой универсальной (для 90% случаев) логикой, возможно исключить одно, именно 2-е слово из текста?
Если Вы следовали логикам:
- последовательных двуграмм и триграмм — то нет, она бы такой результат не дала
- графов (структурный или зависимый) — тоже не дают однозначного выброса именно второго слова;
- двуграмм и триграмм с произвольным порядком слов позволяет выйти на указанный Вами результат, но он порождает огромные погрешности при отсутствии частотного словаря, полученного на текстах только определенной тематики — т.е. не подходит под универсальный метод, а в данном конкретном случае объем шума от применения этого метода становится неприемлем.
Так какая же машинная логика позволила Вам сказать, что из любых 6 слов стоящих рядом, можно гарантированно выбрать аббревиатуру, которая может существовать где-то в тексте или заголовке? Или, применительно к данному примеру, какой логикой Вы получили из Natural Russian Language Processing by the Keys именно Natural Language Processing?
А разве не в этом задача продукта, который вы разрабатываете?
Нет. Задача программы не заменить человека, а заменить часть его рутинной работы, по формированию ключей из текста, который он написал.
Вы пытаетесь расширить область программы, с фразы «ключей, из текста, который он написал» на фразу «ключей, на основе текста, который он написал».
Направление понятно и перспективно — альтернативная ветка для расчета вероятности каждого ключа. К ЭТИМ ВЕТКАМ в nrlpk идет подготовка в виде цифр.
Вам как автору статьи? Или читателям? (Или всё-таки другому компьютеру?)
На этот вопрос мой развернутый ответ есть в комментарии выше.
>вы предлагаете, чтобы ключами к русскому тексту была половина иностранных слов.
С чего бы это я такое предлагал? И зачем? Какие ключевые слова ценнее для читателей, те и лучше.
Хм, ну давайте тогда внимательно посмотрим на Ваше предложение, цитата из Вашего поста выше:
Если ваша статья про извлечение ключевых слов, то в ключевых словах должно быть «ключевые слова», «выделение ключевых слов», «keyword extraction», «keywords»
По пунктам, так сказать:
- «ключевые слова» — русский и есть по тексту
- «выделение ключевых слов» — русский и их нет по тексу
- «keyword extraction» — иностранные и их нет в тексте
- «keywords» — иностранное и его нет в тексте
Из 4-х слов, 2 иностранные (т.е. 50%) и их в принципе нет в тексте статьи. Почему Вы предложили именно такие ключи, я понимаю, но — я не просто так написал Вам
правда, как выйти на такие ключи в русском тексте, остается за кадром.
Я дополню свои предыдущие слова — не просто за кадром, а только подменой через синонимы и частотность тегов исключительно для определенной платформы. ИМХО, это уже теория на грани подгона, под нужный результат, ИМХО.
Чего????????? Это максимум минуту занимает.
Правда? А у меня даже простой выбор Хабов к этой статье занял больше 5 минут.
А по ключам, да ещё применительно к хабру, я бы застрял очень надолго.
Обращаю внимание, я в этой области хоть что-то понимаю. А 90% пользователей в этом всём просто «прохожие» — но это именно та аудитория, которая составляет в соц. сетях, СМИ и вообще Интернет активное большинство. Т.е. целевая аудитория — не мы с Вами.
Зачем???????? Если статья пишется 2 часа, то 5% времени — это 6 минут!
- Хорошая статья, к сожалению, за два часа не пишется.
- Вы взяли для оценки не ту цифру. Сокращение может составить 20-35%, что даже от 2 часов составляет уже 24 — 42 минуты.
Ну и может не генерировать все возможные ключи, а предложить сразу оптимальные, а человек пусть потом добавляет или убирает, что хочет?
Я к этому и стремлюсь.
То есть, вы не знаете, что такое тестовый сет в машинном обучении? (И сколько должно быть в нём данных, чтобы получать более-менее объективные результаты?)
Чтобы нам не удариться в бесполезную дискуссию кто лучше/хуже что знает и т.д., на данный вопрос мне проще ответить — НЕТ.
>Сокращения — это приведенные слова из статьи. Среди сокращений нет ни одного, которое бы было построено не из слов из статьи. Причем не просто из слов, любых выбранных произвольным порядком, а отобранных по четким и понятным правилам.
То есть, вы почему-то разрешаете функцию преобразования, которая делает из слова сокращение, но не разрешаете функцию, которая делает из слова или фразы синоним на основе тезауруса или векторной близости. Не замечаете проблемы?
>а отобранных по четким и понятным правилам.
Так, а кому нужны чёткие и понятные правила? Вам, чтобы своё ЧСВ почесать?
Вы из бизнес-задачи «сделать наилучшие ключевые слова» получаете задачу «сделать понятный вам алгоритм, пусть плохонький, но чтобы вы его понимали на 100%».
Вот в чём проблема, в которую я вас тыкаю уже пару комментариев, но которую вы не хотите осознавать, предлагая, как в анекдоте, искать ключи там, где фонарь, а не там, где они на самом деле лежат.
Зачем вы ставите задачу именно в такой формулировке?
Я утверждаю, что бизнесу намного чаще нужна другая задача, не keywords extraction, а keywords assignment, где тексту могут присваиваться любые слова в качестве ключевых.
(За исключением SEO-оптимизации под Yandex и Bing, там полезно знать, какие ключи найдёт яндекс, чтобы по ним заоптимизировать текст и оценить рекламу, но им сокращения «ЧО» и «2ф2г» тоже не нужны, насколько я знаю.)
Но даже если вы делаете keywords extraction, определять, какие ключевые слова правильны, должны не вы одни, а несколько экспертов или заказчиков, чтобы избежать смещения качества в сторону вашей личной оценки, которая может не соответствовать оценкам других людей. Ну или нужно считать рекламные клики, если вы таргетируетесь по рекламе.
И я привожу пример того, что выбранные мной ключевые слова будут совсем другие, нежели у вас, показывая тем самым, что это смещение оценки качества точно есть.
Неужели вы ставите для себя цель сделать алгоритм, наиболее полезный только вам лично?
>Из 4-х слов, 2 иностранные (т.е. 50%) и их в принципе нет в тексте статьи.
И вот отсюда и растёт ваша очередная логическая ошибка. Если я предложил вам 4 ключевых слова/выражения, это не значит, что я считаю, что у статьи должны быть только 4 эти ключевых слова/выражения. Не искажайте мои слова, хорошо?
>>То есть, вы не знаете, что такое тестовый сет в машинном обучении? (И сколько должно быть в нём данных, чтобы получать более-менее объективные результаты?)
>Чтобы нам не удариться в бесполезную дискуссию кто лучше/хуже что знает и т.д., на данный вопрос мне проще ответить — НЕТ.
Это был риторический вопрос, я и так вижу, что вы плохо это понимаете.
Даже если вы делаете extractive keywords.
Объясняю: Если у вас 50 текстов, с большой вероятностью, вы не поймёте, стал ли после очередного улучшения ваш алгоритм лучше или хуже, потому что у вас очень большая погрешность измерения качества алгоритма. Чтобы уменьшить погрешность, нужно увеличить количество текстов хотя бы до тысячи, тогда вы почти наверняка сможете отловить изменение качества на 5%. А сейчас вы подогнали свой алгоритм под 50 рассматриваемых текстов и, насколько я понял, считаете, что у вас точность 95-100%.
(почитайте хотя бы, почему социологи опрашивают как минимум 1000 человек, например, здесь: postnauka.ru/faq/58454, а по метрикам — у вас есть ошибки первого и второго рода, возьмите хотя бы F1 score вместо точности, кстати, accuracy у вас или precision сейчас в качестве метрики? ).
Я вам предлагаю в качестве промежуточной бизнес-цели «поиграть в имитацию»: взять те ключевые слова, которые выбирают к статьям на хабре или в соц. сетях люди, и попытаться оценить качество вашего алгоритма. Как минимум возьмите 1000 текстов, можете отбирать руками те, где вам нравятся ключевые слова.
А потом может доберётесь и до алгоритмов, которые лучше среднего человека выбирают полезные ключевые слова.
То есть, вы почему-то разрешаете функцию преобразования, которая делает из слова сокращение, но не разрешаете функцию, которая делает из слова или фразы синоним на основе тезауруса или векторной близости. Не замечаете проблемы?
>а отобранных по четким и понятным правилам.
Так, а кому нужны чёткие и понятные правила? Вам, чтобы своё ЧСВ почесать?
Вы из бизнес-задачи «сделать наилучшие ключевые слова» получаете задачу «сделать понятный вам алгоритм, пусть плохонький, но чтобы вы его понимали на 100%».
Вот в чём проблема, в которую я вас тыкаю уже пару комментариев, но которую вы не хотите осознавать, предлагая, как в анекдоте, искать ключи там, где фонарь, а не там, где они на самом деле лежат.
Зачем вы ставите задачу именно в такой формулировке?
Я утверждаю, что бизнесу намного чаще нужна другая задача, не keywords extraction, а keywords assignment, где тексту могут присваиваться любые слова в качестве ключевых.
(За исключением SEO-оптимизации под Yandex и Bing, там полезно знать, какие ключи найдёт яндекс, чтобы по ним заоптимизировать текст и оценить рекламу, но им сокращения «ЧО» и «2ф2г» тоже не нужны, насколько я знаю.)
Но даже если вы делаете keywords extraction, определять, какие ключевые слова правильны, должны не вы одни, а несколько экспертов или заказчиков, чтобы избежать смещения качества в сторону вашей личной оценки, которая может не соответствовать оценкам других людей. Ну или нужно считать рекламные клики, если вы таргетируетесь по рекламе.
И я привожу пример того, что выбранные мной ключевые слова будут совсем другие, нежели у вас, показывая тем самым, что это смещение оценки качества точно есть.
Неужели вы ставите для себя цель сделать алгоритм, наиболее полезный только вам лично?
>Из 4-х слов, 2 иностранные (т.е. 50%) и их в принципе нет в тексте статьи.
И вот отсюда и растёт ваша очередная логическая ошибка. Если я предложил вам 4 ключевых слова/выражения, это не значит, что я считаю, что у статьи должны быть только 4 эти ключевых слова/выражения. Не искажайте мои слова, хорошо?
>>То есть, вы не знаете, что такое тестовый сет в машинном обучении? (И сколько должно быть в нём данных, чтобы получать более-менее объективные результаты?)
>Чтобы нам не удариться в бесполезную дискуссию кто лучше/хуже что знает и т.д., на данный вопрос мне проще ответить — НЕТ.
Это был риторический вопрос, я и так вижу, что вы плохо это понимаете.
Даже если вы делаете extractive keywords.
Объясняю: Если у вас 50 текстов, с большой вероятностью, вы не поймёте, стал ли после очередного улучшения ваш алгоритм лучше или хуже, потому что у вас очень большая погрешность измерения качества алгоритма. Чтобы уменьшить погрешность, нужно увеличить количество текстов хотя бы до тысячи, тогда вы почти наверняка сможете отловить изменение качества на 5%. А сейчас вы подогнали свой алгоритм под 50 рассматриваемых текстов и, насколько я понял, считаете, что у вас точность 95-100%.
(почитайте хотя бы, почему социологи опрашивают как минимум 1000 человек, например, здесь: postnauka.ru/faq/58454, а по метрикам — у вас есть ошибки первого и второго рода, возьмите хотя бы F1 score вместо точности, кстати, accuracy у вас или precision сейчас в качестве метрики? ).
Я вам предлагаю в качестве промежуточной бизнес-цели «поиграть в имитацию»: взять те ключевые слова, которые выбирают к статьям на хабре или в соц. сетях люди, и попытаться оценить качество вашего алгоритма. Как минимум возьмите 1000 текстов, можете отбирать руками те, где вам нравятся ключевые слова.
А потом может доберётесь и до алгоритмов, которые лучше среднего человека выбирают полезные ключевые слова.
Я пропущу первую, эмоциональную и не конструктивную часть Вашего комментария, и отвечу только на то, что имеет смысл обсуждать.
Если бизнесу важнее любые слова в качестве ключевых к любому тексту, то эту задачу не надо автоматизировать, просто потому что задача любой к любому решается быстро и просто — random + random
Но комментирую я этот фрагмент потому, что в нем есть более интересная фраза — «бизнесу нужна другая задача».
Если бы решалась задача бизнеса, скажем того же Хабра, например для увеличения числа переходов между страницами, то система тоже была бы построена довольно не сложно: частотный словарь тэгов Хабра + словарь тегов во всех словоформах + словарь слов, которые могут служить синонимами или схожими по смыслу (как ключевое слово и keyword, которые синонимами не являются) + возможность добавить свой тэг.
Но я пытаюсь решить проблему людей, а не бизнеса!!! Люди не хотят думать о ключах, хотя в современных платформах без ключей им довольно тяжело расширить круг читающих их материалы. Вот я пытаюсь сделать так, чтобы они и продолжали о них не думать, но при этом всё-таки имели ключи.
Поэтому я не решаю проблемы бизнеса! Более того, я полагаю, что бизнес, который «замыкает» речи людей в рамках распространенных или общепринятых ключей (это то, к чему Вы сводите разговор своими примерами), скажем так, немного теряет от этого.
Если Вы перечитаете текст статьи, то именно эти мысли в ней и увидите. Да, я понимаю, что вижу не всё, а что-то должно попасть в ключи, при совпадении нескольких альтернатив, и да я осознанно снижаю процент качества, именно из-за этого и из-за того, что вообще ряда вещей не замечаю.
И именно для этого и ищется инвестор или новый владелец, потому что уже полученное качество, имеет достаточно высокий показатель.
А для конструктивной критики я открыл все результаты расчетов, чтобы у тех, кто действительно заинтересован, сам смог убедиться в результатах.
Проблема аббревиатур — не критичная проблема. Если выработать иной принцип преобразования, то она будет решена в очень короткий срок. Просто именно тут нужно некое коллективное мнение, потому что дальше, эти данные будут нужны для внутренних расчетов.
Тут уместно как раз поговорить о субъективности мнений.
Но я бы предложил Вам спросить своих знакомых, не имеющих отношения к ИТ и не англоговорящих, какие ключи они бы написали к фразе «тут Ваша фраза, к которой Вы бы подставили иностранные ключи» и посчитать сколько раз они назовут Вам иностранные ключевые слова и вообще назовут совпавшие с Вашим видением ключей.
Среди отобранных ключей нет, которые подходят лично Вам?
Я уже сказал, что ни Вы, ни я, не являемся целевой аудиторией, потому что у нас уже искаженное понятие о ключах, мы уже в шорах принятых стандартов их применения.
Безусловно, можно пытаться написать модель выбора ключей под эти шоры, но тогда алгоритм понятен и отталкиваться надо не от текста, а от имеющегося набора ключей, которые интересны конкретной платформе. И это совсем другая задача — выбрать из текста ключи максимально близкие к принятым на платформе и показать оптимальные под заданный критерий повторяемости по тексту и частности использования на платформе.
Но я в девятый раз повторю — nrlpk решает другую задачу, она показывает ключами то, что показал как ключи в своем тексте автор.
И когда я говорю о понятных алгоритмах, я имею ввиду не мне, а универсальных, работающих по единым принципам по любым текстам.
Я их и не искажаю, а говорю о том, что эти ключи отсутствуют в тексте и непосредственно из текста их выбрать нельзя, более того, 50% из них иностранные для русского текста и даже через синонимы в него попасть не могут.
и
и
Я очень не хочу дискуссии в таком ключе и пытаюсь её избежать уже в третий раз, но видимо где-то надо Вас остановить…
1. почитайте внимательно материал, который Вы комментируете — там нет цифр 95-100%.
3. для того, чтобы увеличивать тестовую выборку, нужно иметь выборку с эталоном. Тут дальше должно быть много нудных технических деталей, суть которых в итоге сведется к тому, что её не существует. И да
Ключевое слово — выбирают:
Таким образом Ваше предложение сводится к следующему:
Хм. Спасибо… Надеюсь сами Вы так не делаете.
Я не останавливаю тестов, цель хоть и не 1000, но и не ткущие показатели.
Я восхищен Вашей способностью генерировать непроверенные гипотезы, показывая их как достоверные и игнорировать все больные вопросы по таким гипотезам, которые я задаю Вам, ну например
или теперь ещё один, новый — и что есть примеры получения качественных алгоритмов полученных на грязных отладочных и тестовых данных?
Я утверждаю, что бизнесу намного чаще нужна другая задача, не keywords extraction, а keywords assignment, где тексту могут присваиваться любые слова в качестве ключевых.
Если бизнесу важнее любые слова в качестве ключевых к любому тексту, то эту задачу не надо автоматизировать, просто потому что задача любой к любому решается быстро и просто — random + random
Но комментирую я этот фрагмент потому, что в нем есть более интересная фраза — «бизнесу нужна другая задача».
Если бы решалась задача бизнеса, скажем того же Хабра, например для увеличения числа переходов между страницами, то система тоже была бы построена довольно не сложно: частотный словарь тэгов Хабра + словарь тегов во всех словоформах + словарь слов, которые могут служить синонимами или схожими по смыслу (как ключевое слово и keyword, которые синонимами не являются) + возможность добавить свой тэг.
Но я пытаюсь решить проблему людей, а не бизнеса!!! Люди не хотят думать о ключах, хотя в современных платформах без ключей им довольно тяжело расширить круг читающих их материалы. Вот я пытаюсь сделать так, чтобы они и продолжали о них не думать, но при этом всё-таки имели ключи.
Поэтому я не решаю проблемы бизнеса! Более того, я полагаю, что бизнес, который «замыкает» речи людей в рамках распространенных или общепринятых ключей (это то, к чему Вы сводите разговор своими примерами), скажем так, немного теряет от этого.
Но даже если вы делаете keywords extraction, определять, какие ключевые слова правильны, должны не вы одни, а несколько экспертов или заказчиков, чтобы избежать смещения качества в сторону вашей личной оценки, которая может не соответствовать оценкам других людей.
Если Вы перечитаете текст статьи, то именно эти мысли в ней и увидите. Да, я понимаю, что вижу не всё, а что-то должно попасть в ключи, при совпадении нескольких альтернатив, и да я осознанно снижаю процент качества, именно из-за этого и из-за того, что вообще ряда вещей не замечаю.
И именно для этого и ищется инвестор или новый владелец, потому что уже полученное качество, имеет достаточно высокий показатель.
А для конструктивной критики я открыл все результаты расчетов, чтобы у тех, кто действительно заинтересован, сам смог убедиться в результатах.
Проблема аббревиатур — не критичная проблема. Если выработать иной принцип преобразования, то она будет решена в очень короткий срок. Просто именно тут нужно некое коллективное мнение, потому что дальше, эти данные будут нужны для внутренних расчетов.
И я привожу пример того, что выбранные мной ключевые слова будут совсем другие, нежели у вас, показывая тем самым, что это смещение оценки качества точно есть.
Тут уместно как раз поговорить о субъективности мнений.
Но я бы предложил Вам спросить своих знакомых, не имеющих отношения к ИТ и не англоговорящих, какие ключи они бы написали к фразе «тут Ваша фраза, к которой Вы бы подставили иностранные ключи» и посчитать сколько раз они назовут Вам иностранные ключевые слова и вообще назовут совпавшие с Вашим видением ключей.
Неужели вы ставите для себя цель сделать алгоритм, наиболее полезный только вам лично?
Среди отобранных ключей нет, которые подходят лично Вам?
Я уже сказал, что ни Вы, ни я, не являемся целевой аудиторией, потому что у нас уже искаженное понятие о ключах, мы уже в шорах принятых стандартов их применения.
Безусловно, можно пытаться написать модель выбора ключей под эти шоры, но тогда алгоритм понятен и отталкиваться надо не от текста, а от имеющегося набора ключей, которые интересны конкретной платформе. И это совсем другая задача — выбрать из текста ключи максимально близкие к принятым на платформе и показать оптимальные под заданный критерий повторяемости по тексту и частности использования на платформе.
Но я в девятый раз повторю — nrlpk решает другую задачу, она показывает ключами то, что показал как ключи в своем тексте автор.
И когда я говорю о понятных алгоритмах, я имею ввиду не мне, а универсальных, работающих по единым принципам по любым текстам.
И вот отсюда и растёт ваша очередная логическая ошибка. Если я предложил вам 4 ключевых слова/выражения, это не значит, что я считаю, что у статьи должны быть только 4 эти ключевых слова/выражения. Не искажайте мои слова, хорошо?
Я их и не искажаю, а говорю о том, что эти ключи отсутствуют в тексте и непосредственно из текста их выбрать нельзя, более того, 50% из них иностранные для русского текста и даже через синонимы в него попасть не могут.
Это был риторический вопрос, я и так вижу, что вы плохо это понимаете.
и
Чтобы уменьшить погрешность, нужно увеличить количество текстов хотя бы до тысячи, тогда вы почти наверняка сможете отловить изменение качества на 5%.
и
А сейчас вы подогнали свой алгоритм под 50 рассматриваемых текстов и, насколько я понял, считаете, что у вас точность 95-100%.
Я очень не хочу дискуссии в таком ключе и пытаюсь её избежать уже в третий раз, но видимо где-то надо Вас остановить…
1. почитайте внимательно материал, который Вы комментируете — там нет цифр 95-100%.
3. для того, чтобы увеличивать тестовую выборку, нужно иметь выборку с эталоном. Тут дальше должно быть много нудных технических деталей, суть которых в итоге сведется к тому, что её не существует. И да
Я вам предлагаю в качестве промежуточной бизнес-цели «поиграть в имитацию»: взять те ключевые слова, которые выбирают к статьям на хабре или в соц. сетях люди, и попытаться оценить качество вашего алгоритма.
Ключевое слово — выбирают:
- максимально подходящие;
- из того, что есть;
- мало, потому что некогда;
- не относящиеся к текстам, потому что у слова полно просмотров;
- ерунду, потому что лень думать.
- ни одного, не потому что их нет, а потому что не знаю зачем мне это надо и с чем это вообще едят.
Таким образом Ваше предложение сводится к следующему:
- возьми за эталон непроверенную тестовую выборку с любой платформы или с нескольких
- прими априори, что качество ключей к каждой статье 100%
- доработай алгоритмы так, чтобы твои ключи стали максимально близки к этим ключам
- если видишь отклонение больше, как у Вас — 5%, значит твой алгоритм плох.
Хм. Спасибо… Надеюсь сами Вы так не делаете.
Как минимум возьмите 1000 текстов
Я не останавливаю тестов, цель хоть и не 1000, но и не ткущие показатели.
А потом может доберётесь и до алгоритмов, которые лучше среднего человека выбирают полезные ключевые слова.
Я восхищен Вашей способностью генерировать непроверенные гипотезы, показывая их как достоверные и игнорировать все больные вопросы по таким гипотезам, которые я задаю Вам, ну например
Так какая же машинная логика позволила Вам сказать, что из любых 6 слов стоящих рядом, можно гарантированно выбрать аббревиатуру, которая может существовать где-то в тексте или заголовке?
или теперь ещё один, новый — и что есть примеры получения качественных алгоритмов полученных на грязных отладочных и тестовых данных?
>>Я утверждаю, что бизнесу намного чаще нужна другая задача, не keywords extraction, а keywords assignment, где тексту могут присваиваться любые слова в качестве ключевых.
>Если бизнесу важнее любые слова в качестве ключевых к любому тексту, то эту задачу не надо автоматизировать, просто потому что задача любой к любому решается быстро и просто — random + random
Опять занимаетесь искажением слов? Вот представьте, что есть 100 категорий, выбор ключевого слова тогда это выбор категории. Это валидная бизнес-задача.
А теперь представьте, что есть возможность выбрать слова или последовательности слов из текста в качестве ключевых, и кроме этого есть возможность выбрать из миллиона понятий, например, отобранных через аналог алгоритма sense2vec, а также все более редкие слова из википедии (термины). Да, можете добавить туда популярные имеющиеся теги на хабре. И вот всё из этого объединённого множества слов мы теперь подбираем ключевые слова.
explosion.ai/demos/sense2vec
Так расскажите мне, что именно при таком подходе теряется? Вы по-прежнему можете брать теги из текста. Наоборот, мне кажется, приобретается возможность объединить несколько разных слов синонимичным тегом. Если в статье написано в разных местах «Джо», «Джозеф», «Байден», «Джо Байден», «Байдену», «вице-президент», «вице-президенту США», то мне бы хотелось, чтобы статистика популярных слов учитывала эти разные написания, и я не понимаю, почему это плохо.
У вас же сейчас, как я понимаю, в теги попадёт по отдельности «ДБ», «Джо», «Байден». А может какое-то из них и вообще не выделится. А хотелось бы получить, пожалуй, два тега «Джо Байден» и «вице-президент США» — они, кстати, оба должны быть в словах википедии, второе как ссылка.
>или теперь ещё один, новый — и что есть примеры получения качественных алгоритмов полученных на грязных отладочных и тестовых данных?
да вот представьте себе, есть. добавление картинок с тегами из соц сетей увеличивает качество классификатора на imagenet с 80% до 82.5%-85%. таких картинок нужно больше, потому что там есть шум, но это количество в итоге как раз и даёт прирост.
medium.com/syncedreview/facebook-model-pretrained-on-billions-of-instagram-hashtags-achieves-sota-results-on-top-1-imagenet-ae8113bb3145
кроме того, таким образом часто поступают, когда вообще нет представления о правильных тегах. у вас, по моему мнению, как раз этот случай: нормального представления о правильных тегах нет. поэтому и предлагаю такой вариант (до тех пор, пока вы не найдёте «бизнес», которому данный классификатор, который в вашем эвритическом варианте пишется за день, нужен будет как «инвестиция»).
>Если бизнесу важнее любые слова в качестве ключевых к любому тексту, то эту задачу не надо автоматизировать, просто потому что задача любой к любому решается быстро и просто — random + random
Опять занимаетесь искажением слов? Вот представьте, что есть 100 категорий, выбор ключевого слова тогда это выбор категории. Это валидная бизнес-задача.
А теперь представьте, что есть возможность выбрать слова или последовательности слов из текста в качестве ключевых, и кроме этого есть возможность выбрать из миллиона понятий, например, отобранных через аналог алгоритма sense2vec, а также все более редкие слова из википедии (термины). Да, можете добавить туда популярные имеющиеся теги на хабре. И вот всё из этого объединённого множества слов мы теперь подбираем ключевые слова.
explosion.ai/demos/sense2vec
Так расскажите мне, что именно при таком подходе теряется? Вы по-прежнему можете брать теги из текста. Наоборот, мне кажется, приобретается возможность объединить несколько разных слов синонимичным тегом. Если в статье написано в разных местах «Джо», «Джозеф», «Байден», «Джо Байден», «Байдену», «вице-президент», «вице-президенту США», то мне бы хотелось, чтобы статистика популярных слов учитывала эти разные написания, и я не понимаю, почему это плохо.
У вас же сейчас, как я понимаю, в теги попадёт по отдельности «ДБ», «Джо», «Байден». А может какое-то из них и вообще не выделится. А хотелось бы получить, пожалуй, два тега «Джо Байден» и «вице-президент США» — они, кстати, оба должны быть в словах википедии, второе как ссылка.
>или теперь ещё один, новый — и что есть примеры получения качественных алгоритмов полученных на грязных отладочных и тестовых данных?
да вот представьте себе, есть. добавление картинок с тегами из соц сетей увеличивает качество классификатора на imagenet с 80% до 82.5%-85%. таких картинок нужно больше, потому что там есть шум, но это количество в итоге как раз и даёт прирост.
medium.com/syncedreview/facebook-model-pretrained-on-billions-of-instagram-hashtags-achieves-sota-results-on-top-1-imagenet-ae8113bb3145
кроме того, таким образом часто поступают, когда вообще нет представления о правильных тегах. у вас, по моему мнению, как раз этот случай: нормального представления о правильных тегах нет. поэтому и предлагаю такой вариант (до тех пор, пока вы не найдёте «бизнес», которому данный классификатор, который в вашем эвритическом варианте пишется за день, нужен будет как «инвестиция»).
А теперь представьте, что есть возможность выбрать слова или последовательности слов из текста в качестве ключевых, и кроме этого есть возможность выбрать из миллиона понятий, например, отобранных через аналог алгоритма sense2vec
На сайте ВПК.name, по материалам которого я и веду тестирование, описываемая Вами задача уже решена, менее простым и трудоёмким способом. Там к каждой статье автоматически цепляются ключи уже лет 5-7 как. НО, как и в Вашем предложении, там есть большая проблема — это поддержание и развитие тех самых категорий или ключей в категориях, как это реализовано у них.
И вот всё из этого объединённого множества слов мы теперь подбираем ключевые слова.
Это задача будет заведомо сужена ключами конкретной платформы. Кроме того, снова встает вопрос с качеством источников, к примеру — та же википедия, это далеко не лучший источник по качеству.
Если в статье написано в разных местах «Джо», «Джозеф», «Байден», «Джо Байден», «Байдену», «вице-президент», «вице-президенту США», то мне бы хотелось, чтобы статистика популярных слов учитывала эти разные написания, и я не понимаю, почему это плохо.
Это не плохо, и такие вещи, как «Джо», «Байден», «Джо Байден», «Байдену» могут быть учтены, при совсем небольших доработках и в nrlpk, но только в одном случае — если в тексте больше не было Джо.
А вот для того, чтобы «вице-президенту США» превратился в «Джо Байдена» нужны либо очень серьезный словарь соответствия, либо очень серьезная сеть ассоциаций, учитывающая временные интервалы описания в тексте — понимаете о чем я? Вице-президенты США меняются…
И первый вариант и второй требуют очень серьезных проработок, обучения моделей и большого набора альтернативных сценариев выбора вероятностей для ключа.
Я был бы тоже за такой реализации но, такого не может даже Яндекс, правда может Гугл.
Мы ведь не их алгоритмы обсуждаем? И да, там не word2vec и не sense2vec
да вот представьте себе, есть. добавление картинок с тегами из соц сетей увеличивает качество классификатора на imagenet с 80% до 82.5%-85%.
Может быть Вы статью, на которую дали ссылку полностью прочитаете. Я Вам дам одну только цитату оттуда, поскольку она подтверждает то, что я пытался донести до Вас в своих постах выше
Researchers discovered a number of other interesting phenomena through their experiments. For example, simply increasing the size of the pretraining dataset doesn’t directly deliver better results. On the ImageNet-1k classification task, networks pretrained on 1.5k hashtags outperformed those trained with a larger dataset because the 1.5k hashtags were selected to match the target task.
Ну а из остальной части текста, Вы узнаете, что обе сравниваемые модели имели предварительную подготовку данных, именно поэтому сравнение оказывается уместным.
до тех пор, пока вы не найдёте «бизнес», которому данный классификатор, который в вашем эвритическом варианте пишется за день
О, простите…
Если Вами уже решена эта задача, или Вы готовы выдать её уже завтра к вечеру, то да, я буду вынужден признать бесполезность своей работы и, что зря тратил своё время и Ваше, и других читателей.
До завтрашнего вечера!
Желаю Вам получить стабильный результат по Байдену и от должности, и от места жительства, и от сына Бо — ну а почему бы и нет… Чем Вы хуже Гугл, в конце то концов…
Я признаюсь, nrlpk на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
>>А теперь представьте, что есть возможность выбрать слова или последовательности слов из текста в качестве ключевых, и кроме этого есть возможность выбрать из миллиона понятий, например, отобранных через аналог алгоритма sense2vec
>На сайте ВПК.name, по материалам которого я и веду тестирование, описываемая Вами задача уже решена, менее простым и трудоёмким способом. Там к каждой статье автоматически цепляются ключи уже лет 5-7 как. НО, как и в Вашем предложении, там есть большая проблема — это поддержание и развитие тех самых категорий или ключей в категориях, как это реализовано у них.
Отличный комментарий в духе «А вот Рабинович тоже умеет петь оперы. Но только есть одна проблема — полная фигня получается».
Зачем вы мне это рассказывате? :)
>>И вот всё из этого объединённого множества слов мы теперь подбираем ключевые слова.
>Это задача будет заведомо сужена ключами конкретной платформы.
Это опять вы за всех решили, что эта задача будет сужена ключами конкретной платформы? А если не будет? Во всех социальных сетях можно писать любые хеш-теги, на хабре можно указывать ключевые слова. Кто что суживает?
>Кроме того, снова встает вопрос с качеством источников, к примеру — та же википедия, это далеко не лучший источник по качеству.
О, а это уже шикарный FUD-аргумент в духе «у вас опечатка в тексте, поэтому я не буду его анализировать». Вы серьёзно?
>>Если в статье написано в разных местах «Джо», «Джозеф», «Байден», «Джо Байден», «Байдену», «вице-президент», «вице-президенту США», то мне бы хотелось, чтобы статистика популярных слов учитывала эти разные написания, и я не понимаю, почему это плохо.
>Это не плохо, и такие вещи, как «Джо», «Байден», «Джо Байден», «Байдену» могут быть учтены, при совсем небольших доработках и в nrlpk, но только в одном случае — если в тексте больше не было Джо.
Опять вы начинаете вместо реальных попыток решения задачи делать мелкие модифицирования вашей реализации, а потом говорить, что они будут плохо работать? Вот же какая инерция мышления у вас.
>А вот для того, чтобы «вице-президенту США» превратился в «Джо Байдена» нужны либо очень серьезный словарь соответствия, либо очень серьезная сеть ассоциаций, учитывающая временные интервалы описания в тексте — понимаете о чем я? Вице-президенты США меняются…
И не говорите. Жуть, это же ваши выстраданные эвристики выкидывать придётся!
Посмотрите на github.com/salesforce/ctrl#source-attributions, вот пример учёта временных интервалов в тексте. Словарь, говорите, нужен, или онтология…
>И первый вариант и второй требуют очень серьезных проработок, обучения моделей и большого набора альтернативных сценариев выбора вероятностей для ключа.
Да вы что! Вот люди наверное серьёзные дела делают, нейросети подключают, сложные алгоритмы придумывают, но вы же так не можете, вам обязательно нужно руками на коленке подбирать эвристики и проверять их качество по целым 50 текстам.
>Я был бы тоже за такой реализации но, такого не может даже Яндекс, правда может Гугл.
Да, Яндекс интересуют конкретные коммерческие штуки, например, сделать разбиение по темам в яндекс.новости.
>Мы ведь не их алгоритмы обсуждаем? И да, там не word2vec и не sense2vec
А почему бы и не пообсуждать, если это для дела полезно?
>>да вот представьте себе, есть. добавление картинок с тегами из соц сетей увеличивает качество классификатора на imagenet с 80% до 82.5%-85%.
>Может быть Вы статью, на которую дали ссылку полностью прочитаете. Я Вам дам одну только цитату оттуда, поскольку она подтверждает то, что я пытался донести до Вас в своих постах выше
>Researchers discovered a number of other interesting phenomena through their experiments. For example, simply increasing the size of the pretraining dataset doesn’t directly deliver better results. On the ImageNet-1k classification task, networks pretrained on 1.5k hashtags outperformed those trained with a larger dataset because the 1.5k hashtags were selected to match the target task.
Да, я это читал, и другие слова оттуда тоже. Почитайте и вы, что ли, вместо того, чтобы первые попавшиеся цитаты выдирать.
Всё правильно, если сначала у нас было бы не 1500 тем, а больше, то нейросетевой алгоритм бы учился дольше, это известный феномен (зачастую — время достижения определённого качества прямо пропорционально количеству тем). Там есть рядом пример, где встречается 17000 тем, видно, что учится дольше, и всё равно качество на 1000 тем из ImageNet потом достаточно высокое.
Там проблема ещё связана с тем, что на картинке изображено всегда много вещей. Подобная структура нейросети с такой метрики выбирает один или несколько топовых ответов, поэтому теги, не относящиеся к одной из 1000 тем, иногда «забивают» более слабый сигнал по другим темам.
Но проблема то в том, что у вас нет рядом ImageNet для тренировки, у вас выбор лишь или использовать человеческие теги, или нет. Вы выбрали не использовать, и по вашей метрике качества, которая, по моему мнению, кроме вас никому не подходит, действительно так лучше.
>>Ну а из остальной части текста, Вы узнаете, что обе сравниваемые модели имели предварительную подготовку данных, именно поэтому сравнение оказывается уместным.
>до тех пор, пока вы не найдёте «бизнес», которому данный классификатор, который в вашем эвритическом варианте пишется за день
>О, простите…
>Если Вами уже решена эта задача, или Вы готовы выдать её уже завтра к вечеру, то да, я буду вынужден признать бесполезность своей работы и, что зря тратил своё время и Ваше, и других читателей.
Да, мной эта задача решена с качеством, подобным вашему решению по качеству, и такое действительно пишется левой пяткой, а дальнейшие эвристики не приводят к существенному росту качества, особенно, если сравнивать их по метрике, более полезной для бизнеса, или хотя бы считать не только False Negatives, но и False Positives, т.е. штрафовать за «лишние» ключевые слова, а не только за пропущенные.
И это делается реально за день, потому что все эти мелкие навороты с сокращениями, если не склеивать разные сокращения вместе, дают от силы долю процента качества (вы с такой точностью даже не можете это измерить сейчас, ха-ха, и не поймёте, помогают ли вам сокращения или мешают).
А более сложную систему с открытым словарём я буду постепенно писать как хобби, это уже более интересная задача. (ну, частично мне это оплатят, но у меня сейчас другие дела более приоритетные)
>До завтрашнего вечера!
Ой милота какая. Прям гениальный поворот.
>Желаю Вам получить стабильный результат по Байдену и от должности, и от места жительства, и от сына Бо — ну а почему бы и нет… Чем Вы хуже Гугл, в конце то концов…
То есть, вы не можете решить задачу с низким качеством за день, а мне подменили понятия и хотите чтобы я за день решил задачу с высоким качеством. А я говорил о том, что с вашим качеством я решаю такую задачу за день, и что решение задачи будет намного практически полезным, если задачу решать с более высоким качеством.
>Я признаюсь, nrlpk на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
Это точно. Не замечу сарказма, потому что с большой вероятностью действительно всё так, с вашими текущими методами далеко не уедешь.
Ну так я вам конструктивную критику для этого и даю, чтобы вы исправились.
А вы уже в унылый троллинг скатились тут.
Давайте лучше конструктивно обсуждать, как добиться более высокого качества.
Для начала — сменить метрику.
Потом проверить гипотезу о том, что людские теги для других людей более полезны, чем тот тип extractive keywords, что используете вы.
А потом заняться поиском методов для более хорошей реализации данной задачи.
>На сайте ВПК.name, по материалам которого я и веду тестирование, описываемая Вами задача уже решена, менее простым и трудоёмким способом. Там к каждой статье автоматически цепляются ключи уже лет 5-7 как. НО, как и в Вашем предложении, там есть большая проблема — это поддержание и развитие тех самых категорий или ключей в категориях, как это реализовано у них.
Отличный комментарий в духе «А вот Рабинович тоже умеет петь оперы. Но только есть одна проблема — полная фигня получается».
Зачем вы мне это рассказывате? :)
>>И вот всё из этого объединённого множества слов мы теперь подбираем ключевые слова.
>Это задача будет заведомо сужена ключами конкретной платформы.
Это опять вы за всех решили, что эта задача будет сужена ключами конкретной платформы? А если не будет? Во всех социальных сетях можно писать любые хеш-теги, на хабре можно указывать ключевые слова. Кто что суживает?
>Кроме того, снова встает вопрос с качеством источников, к примеру — та же википедия, это далеко не лучший источник по качеству.
О, а это уже шикарный FUD-аргумент в духе «у вас опечатка в тексте, поэтому я не буду его анализировать». Вы серьёзно?
>>Если в статье написано в разных местах «Джо», «Джозеф», «Байден», «Джо Байден», «Байдену», «вице-президент», «вице-президенту США», то мне бы хотелось, чтобы статистика популярных слов учитывала эти разные написания, и я не понимаю, почему это плохо.
>Это не плохо, и такие вещи, как «Джо», «Байден», «Джо Байден», «Байдену» могут быть учтены, при совсем небольших доработках и в nrlpk, но только в одном случае — если в тексте больше не было Джо.
Опять вы начинаете вместо реальных попыток решения задачи делать мелкие модифицирования вашей реализации, а потом говорить, что они будут плохо работать? Вот же какая инерция мышления у вас.
>А вот для того, чтобы «вице-президенту США» превратился в «Джо Байдена» нужны либо очень серьезный словарь соответствия, либо очень серьезная сеть ассоциаций, учитывающая временные интервалы описания в тексте — понимаете о чем я? Вице-президенты США меняются…
И не говорите. Жуть, это же ваши выстраданные эвристики выкидывать придётся!
Посмотрите на github.com/salesforce/ctrl#source-attributions, вот пример учёта временных интервалов в тексте. Словарь, говорите, нужен, или онтология…
>И первый вариант и второй требуют очень серьезных проработок, обучения моделей и большого набора альтернативных сценариев выбора вероятностей для ключа.
Да вы что! Вот люди наверное серьёзные дела делают, нейросети подключают, сложные алгоритмы придумывают, но вы же так не можете, вам обязательно нужно руками на коленке подбирать эвристики и проверять их качество по целым 50 текстам.
>Я был бы тоже за такой реализации но, такого не может даже Яндекс, правда может Гугл.
Да, Яндекс интересуют конкретные коммерческие штуки, например, сделать разбиение по темам в яндекс.новости.
>Мы ведь не их алгоритмы обсуждаем? И да, там не word2vec и не sense2vec
А почему бы и не пообсуждать, если это для дела полезно?
>>да вот представьте себе, есть. добавление картинок с тегами из соц сетей увеличивает качество классификатора на imagenet с 80% до 82.5%-85%.
>Может быть Вы статью, на которую дали ссылку полностью прочитаете. Я Вам дам одну только цитату оттуда, поскольку она подтверждает то, что я пытался донести до Вас в своих постах выше
>Researchers discovered a number of other interesting phenomena through their experiments. For example, simply increasing the size of the pretraining dataset doesn’t directly deliver better results. On the ImageNet-1k classification task, networks pretrained on 1.5k hashtags outperformed those trained with a larger dataset because the 1.5k hashtags were selected to match the target task.
Да, я это читал, и другие слова оттуда тоже. Почитайте и вы, что ли, вместо того, чтобы первые попавшиеся цитаты выдирать.
Всё правильно, если сначала у нас было бы не 1500 тем, а больше, то нейросетевой алгоритм бы учился дольше, это известный феномен (зачастую — время достижения определённого качества прямо пропорционально количеству тем). Там есть рядом пример, где встречается 17000 тем, видно, что учится дольше, и всё равно качество на 1000 тем из ImageNet потом достаточно высокое.
Там проблема ещё связана с тем, что на картинке изображено всегда много вещей. Подобная структура нейросети с такой метрики выбирает один или несколько топовых ответов, поэтому теги, не относящиеся к одной из 1000 тем, иногда «забивают» более слабый сигнал по другим темам.
Но проблема то в том, что у вас нет рядом ImageNet для тренировки, у вас выбор лишь или использовать человеческие теги, или нет. Вы выбрали не использовать, и по вашей метрике качества, которая, по моему мнению, кроме вас никому не подходит, действительно так лучше.
>>Ну а из остальной части текста, Вы узнаете, что обе сравниваемые модели имели предварительную подготовку данных, именно поэтому сравнение оказывается уместным.
>до тех пор, пока вы не найдёте «бизнес», которому данный классификатор, который в вашем эвритическом варианте пишется за день
>О, простите…
>Если Вами уже решена эта задача, или Вы готовы выдать её уже завтра к вечеру, то да, я буду вынужден признать бесполезность своей работы и, что зря тратил своё время и Ваше, и других читателей.
Да, мной эта задача решена с качеством, подобным вашему решению по качеству, и такое действительно пишется левой пяткой, а дальнейшие эвристики не приводят к существенному росту качества, особенно, если сравнивать их по метрике, более полезной для бизнеса, или хотя бы считать не только False Negatives, но и False Positives, т.е. штрафовать за «лишние» ключевые слова, а не только за пропущенные.
И это делается реально за день, потому что все эти мелкие навороты с сокращениями, если не склеивать разные сокращения вместе, дают от силы долю процента качества (вы с такой точностью даже не можете это измерить сейчас, ха-ха, и не поймёте, помогают ли вам сокращения или мешают).
А более сложную систему с открытым словарём я буду постепенно писать как хобби, это уже более интересная задача. (ну, частично мне это оплатят, но у меня сейчас другие дела более приоритетные)
>До завтрашнего вечера!
Ой милота какая. Прям гениальный поворот.
>Желаю Вам получить стабильный результат по Байдену и от должности, и от места жительства, и от сына Бо — ну а почему бы и нет… Чем Вы хуже Гугл, в конце то концов…
То есть, вы не можете решить задачу с низким качеством за день, а мне подменили понятия и хотите чтобы я за день решил задачу с высоким качеством. А я говорил о том, что с вашим качеством я решаю такую задачу за день, и что решение задачи будет намного практически полезным, если задачу решать с более высоким качеством.
>Я признаюсь, nrlpk на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
Это точно. Не замечу сарказма, потому что с большой вероятностью действительно всё так, с вашими текущими методами далеко не уедешь.
Ну так я вам конструктивную критику для этого и даю, чтобы вы исправились.
А вы уже в унылый троллинг скатились тут.
Давайте лучше конструктивно обсуждать, как добиться более высокого качества.
Для начала — сменить метрику.
Потом проверить гипотезу о том, что людские теги для других людей более полезны, чем тот тип extractive keywords, что используете вы.
А потом заняться поиском методов для более хорошей реализации данной задачи.
>Я признаюсь, nrlpk на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
Это точно.
Ну так может быть Вам просто перестать что-то обсуждать с таким бестолковым парнем как я, тем более когда Вы решаете такие задачи всего за один день. И я конечно не дождусь от Вас реализации за один день? Впрочем, мы оба знаем ответ на этот вопрос…
А почему бы и не пообсуждать, если это для дела полезно?
Вам лучше поискать для подобных бесед собеседника соответствующего Вашим знаниям.
Ну так я вам конструктивную критику для этого и даю, чтобы вы исправились.
Сижу… Ищу конструктивную критику. Диву просто даюсь на конструктив, то проценты какие то из головы берете, а не из моей статьи, то вот это например
если не склеивать разные сокращения вместе, дают от силы долю процента качества (вы с такой точностью даже не можете это измерить сейчас, ха-ха, и не поймёте, помогают ли вам сокращения или мешают).
Если бы Вы посмотрели хоть один файл статистики, то без труда смогли бы понять реальную долю выражений с сокращениями. Не пришлось бы конструктивно из пальца какие-то доли процентов без сокращений придумывать.
То есть, вы не можете решить задачу с низким качеством за день, а мне подменили понятия и хотите чтобы я за день решил задачу с высоким качеством. А я говорил о том, что с вашим качеством я решаю такую задачу за день
:))) Прощайте.
Ещё раз: вы тестируете сами по своей метрике, которая вряд ли нужна клиентам. По такой метрике можно 100% набить без проблем — просто объявляем каждый тег, который должен генерировать алгоритм по вашему «ТЗ», хорошим по-умолчанию, а плохими объявляем лишь ошибки обработки морфологии и синтаксиса и совпадения сокращений.
А вот любая моя оценка ваших тегов даёт качество меньше 50% (если из 40 ваших тегов я считаю правильным оставить 10, сколько будет precision и recall?), я пару текстов посмотрел неделю назад.
Я подобный генератор ключевых слов и тегов уже делал пару раз в разном виде, причём для разных языков. Доказывать вам свою квалификацию, отложив все другие дела, я не собираюсь. И тем более не понимаю, зачем вы постоянно подменяете понятия.
Я сказал, что со сравнимым вашему качеством генератор можно сделать за день работы, и я знаю, что это так. Вы с этим несогласны? У вас ушёл год? Ну, поздравляю, вот вы на троллинг и переключились, это защитная реакция, это нормально.
Я сказал, что существенного роста качества по сравнению с текущим качеством по любой более адекватной метрике вы не добьётесь с текущим подходом. Ну, подождём ещё год, может быть, до вас и это дойдёт, как и то, зачем вам нужна более адекватная метрика.
Давайте, всего хорошего.
А вот любая моя оценка ваших тегов даёт качество меньше 50% (если из 40 ваших тегов я считаю правильным оставить 10, сколько будет precision и recall?), я пару текстов посмотрел неделю назад.
Я подобный генератор ключевых слов и тегов уже делал пару раз в разном виде, причём для разных языков. Доказывать вам свою квалификацию, отложив все другие дела, я не собираюсь. И тем более не понимаю, зачем вы постоянно подменяете понятия.
Я сказал, что со сравнимым вашему качеством генератор можно сделать за день работы, и я знаю, что это так. Вы с этим несогласны? У вас ушёл год? Ну, поздравляю, вот вы на троллинг и переключились, это защитная реакция, это нормально.
Я сказал, что существенного роста качества по сравнению с текущим качеством по любой более адекватной метрике вы не добьётесь с текущим подходом. Ну, подождём ещё год, может быть, до вас и это дойдёт, как и то, зачем вам нужна более адекватная метрика.
Давайте, всего хорошего.
Решение вопроса с аббревиатурами ключевых слов и выражений потребовало больше изменений, чем я изначально предполагал, но это пошло только на пользу.
Ниже обновленные ключи к этой статье, полученные доработанным алгоритмом, по тем же правилам (не признавать ключами выражений с числовыми данными, признавать ключами слова, повторяющиеся по тексту не менее 8 раз) + фильтр на ключи с маркером LATN:
nrlpk, online, pd, анализ текста, впк, впк.name, выражение слов, выявление текста, глазок, граммема маркера, закономерность, ии, качество, ключевое выражение, ключевое слово, ключевой список, лень, маркирование, машина, мнение автора, набор данных, нестандартная граммема, площадка, попавший ключ, русский текст, русский язык, словарь, слово текста, сми, список слов, стабилизация, статистик, статья, тестирование результата, февраль года, хабре, число слов, широкий охват
Что было сделано за это время:
Результат, как и раньше, можно посмотреть на github
Как понять, что там?
Каждый новый расчет теперь иметь две папки (раньше была одна в корне подпапки):
Детально описано в Legend.md на github
Чуть расскажу по восстановленным размеченным файлам в папке marked:
Все формируется в utf-8.
Тексты могут быть восстановлены и промаркированы по довольно гибким правилам:
to_mark(base_df, sents=None, skipna=True, fillna='', pls=None, keys=None), где
Ниже обновленные ключи к этой статье, полученные доработанным алгоритмом, по тем же правилам (не признавать ключами выражений с числовыми данными, признавать ключами слова, повторяющиеся по тексту не менее 8 раз) + фильтр на ключи с маркером LATN:
nrlpk, online, pd, анализ текста, впк, впк.name, выражение слов, выявление текста, глазок, граммема маркера, закономерность, ии, качество, ключевое выражение, ключевое слово, ключевой список, лень, маркирование, машина, мнение автора, набор данных, нестандартная граммема, площадка, попавший ключ, русский текст, русский язык, словарь, слово текста, сми, список слов, стабилизация, статистик, статья, тестирование результата, февраль года, хабре, число слов, широкий охват
Что было сделано за это время:
- полностью переработаны словари. Теперь основной словарь может быть изменен только программно вместе с обновлением исходного OpenCorpora – он трансформирован и дополнен данными не из словаря OpenCorpora. Дополнительные словари упрощены до списков лемм и/или аббревиатур в словаре специальных терминов, которые могут пополняться вручную;
- введена многоуровневая процедура разрешения конфликтов неоднозначности определения леммы – возвращается одна (не несколько записей с вероятностью) конкретная строка с леммой;
- введена процедура поиска устойчивых выражений из неключевых слов;
- добавлены новые маркеры — теперь их 25 шт.;
- в вывод добавлено много дополнительной информации по атрибутам словоформы. Если раньше в выводе было 10 полей, то теперь их 28.
- добавлено восстановление текста после обработки;
- добавлена маркировка восстановленных текстов с разными параметрами;
- добавлено при маркировке и восстановлении текстов размещение по месту вхождения сгенерированных выражений, которых в таком виде в исходном тексте может и не быть.
Результат, как и раньше, можно посмотреть на github
Как понять, что там?
Каждый новый расчет теперь иметь две папки (раньше была одна в корне подпапки):
- data – папка с данными, о которых говорилось в статье выше. Те же файлы с тем же смыслом, но с большим объемом дополнительной информации по каждому слову;
- marked – папка с размеченными восстановленными текстами в разных форматах.
Детально описано в Legend.md на github
Чуть расскажу по восстановленным размеченным файлам в папке marked:
- файл key.txt – простой список уникальных ключей к тексту, сформированных по заданным правилам (в папке 52 по правилам, что я описал выше в этом посте);
- файл text.ml — содержит восстановленный текст с разметкой в виде (слово текста 1 как в оригинальном тексте, обозначение части речи этого слова) (слово текста 2 как в оригинальном тексте, обозначение части речи этого слова) знак препинания (слово текста 3 как в оригинальном тексте, обозначение части речи этого слова) и т.д.;
- файл text.json – файл в формате json, содержит предложения и слова текста со всеми не пустыми атрибутами каждого слова текста, вложенными в выражения, из которых они собраны;
- файл text.htm – файл в формате (псевдо) html (для чтения html парсером), содержит восстановленный текст, где каждому слову текста указаны все параметры и атрибуты слова в теге , вложенные в выражения с таким же тегом, из которых они собраны;
- файл text.xml – файл в формате xml, содержит предложения и слова текста со всеми непустыми атрибутами каждого слова текста, вложенными в выражения, из которых они собраны.
Все формируется в utf-8.
Тексты могут быть восстановлены и промаркированы по довольно гибким правилам:
to_mark(base_df, sents=None, skipna=True, fillna='', pls=None, keys=None), где
- sents – список номеров предложений, если пусто, то восстанавливать все;
- skipna – пропускать пустые значения атрибутов?
- fillna – значение для замены пустых значений атрибутов. Применимо для skipna=False
- pls – список обозначений частей речи, если пусто то маркированными все;
- keys – список обозначений маркеров, если пусто то маркировать все.
Сокращаю число нераспознанных слов:
+ Левенштейн — решен
+ несловарные приставки — решен
+ слова через дефис — обработка в процессе
+ Левенштейн и несловарные приставки для слов через дефисы — решен
+ Левенштейн — решен
+ несловарные приставки — решен
+ слова через дефис — обработка в процессе
+ Левенштейн и несловарные приставки для слов через дефисы — решен
Начну с результата – тест на самом сложном тексте, что у меня есть дал
Всё как всегда на Github – тест одного и того же текста на старом алгоритме 4-1 и на новом 4-3.
Для достижения однозначности по несловарным словам (с ошибками, с предлогами, через тире, через тире с ошибками и предлогами) только алгоритма Левенштейна оказалось недостаточно. Пришлось добавить дополнительную обработку по сходимости.
Левенштейн + дополнительный алгоритм сильно увеличили время обработки, но это оказалось на пользу. Сделано:
+ оптимизация по производительности;
+ параллельность;
+ рефакторинг.
Из минусов:
— время обработки разных текстов на одной и той же машине стало непредсказуемым из-за большого числа распараллеленных функций;
— тестирование из-за параллельности усложнилось.
В ходе доработок стал мечтать о том, чтобы в функциях объединения Pandas появились два дополнительных параметра max_workers и add_done_callback :)
- новые ключи
- сокращение результирующего мусора с 68 слов до 10-ти
Всё как всегда на Github – тест одного и того же текста на старом алгоритме 4-1 и на новом 4-3.
Для достижения однозначности по несловарным словам (с ошибками, с предлогами, через тире, через тире с ошибками и предлогами) только алгоритма Левенштейна оказалось недостаточно. Пришлось добавить дополнительную обработку по сходимости.
Левенштейн + дополнительный алгоритм сильно увеличили время обработки, но это оказалось на пользу. Сделано:
+ оптимизация по производительности;
+ параллельность;
+ рефакторинг.
Из минусов:
— время обработки разных текстов на одной и той же машине стало непредсказуемым из-за большого числа распараллеленных функций;
— тестирование из-за параллельности усложнилось.
В ходе доработок стал мечтать о том, чтобы в функциях объединения Pandas появились два дополнительных параметра max_workers и add_done_callback :)
Хотел бы обратить внимание на позиции слов в предложении и в двуграммах, например по этим позициям
2933|корпус спинки|корпус спинка|корпус спинку|2GRM|2745.0|142.0|21.0|nPNC|187.0|||||||||||||||||||3|2.0
2938|корпус спинки|спинка корпус|спинку корпуса|2GRM|2749.0|142.0|25.0|nPNC|188.0|||||||||||||||||||3|2.0
3024|корпус спинки|корпус спинка|корпусом Спинки|2GRM|2834.0|147.0|29.0|nPNC|189.0|||||||||||||||||||3|1.0
Есть двуграммы (например позиция 2938), в которых слова переставленные местами относительно оригинального текста.
По факту, здесь был бы к месту словарь двуграмм, однако я не смог найти хороших (качественных) и больших словарей двуграмм на русском — чему я был сильно удивлен.
2933|корпус спинки|корпус спинка|корпус спинку|2GRM|2745.0|142.0|21.0|nPNC|187.0|||||||||||||||||||3|2.0
2938|корпус спинки|спинка корпус|спинку корпуса|2GRM|2749.0|142.0|25.0|nPNC|188.0|||||||||||||||||||3|2.0
3024|корпус спинки|корпус спинка|корпусом Спинки|2GRM|2834.0|147.0|29.0|nPNC|189.0|||||||||||||||||||3|1.0
Есть двуграммы (например позиция 2938), в которых слова переставленные местами относительно оригинального текста.
По факту, здесь был бы к месту словарь двуграмм, однако я не смог найти хороших (качественных) и больших словарей двуграмм на русском — чему я был сильно удивлен.
В статье «Сравниваем работу open source Python — библиотек для распознавания именованных сущностей» присутствовал тестовый текст на русском языке. Вот он:
Из любопытства прогнал этот текст через свой nrlpk. Ниже результат с фильтрами по ключам, чтобы остались только именованные и числовые ключи:
00 копеек
01.05
10.01.1970
110 млрд
8-000
www.sobyanin.ru
ак47
алтуфьевское шоссе д 51
ваз2107
власть москвы
втб24
город санкт-петербург, ул крузенштерна, дом 5/1а
иванов костантин петрович
мпз
мэра города сергея собянина
подпоручик кижей
рф
Все детали как всегда на github. Текст интересный и с адресами, и с ФИО, и с ошибками в тексте — и результат не менее интересный получился.
Власти Москвы выделили 110 млрд рублей на поддержку населения, системы здравоохранения и городского хозяйства. Об этом сообщается на сайте мэра столицы www.sobyanin.ru в пятницу, 1 мая. По адресу Алтуфьевское шоссе д.51 (основной вид разрешенного использования: производственная деятельность, склады) размещен МПЗ? Подпоручик Киже управляя автомобилем ВАЗ2107 перевозил автомат АК47 с целью ограбления банка ВТБ24, как следует из записей.
Взыскать c индивидуального предпринимателя Иванова Костантипа Петровича дата рождения 10 января 1970 года, проживающего по адресу город Санкт-Петербург, ул. Крузенштерна, дом 5/1А 8 000 (восемь тысяч) рублей 00 копеек гос. пошлины в пользу бюджета РФ Жители требуют незамедлительной остановки МПЗ и его вывода из района. Решение было принято по поручению мэра города Сергея Собянина в связи с ограничениями из-за коронавируса.
Из любопытства прогнал этот текст через свой nrlpk. Ниже результат с фильтрами по ключам, чтобы остались только именованные и числовые ключи:
00 копеек
01.05
10.01.1970
110 млрд
8-000
www.sobyanin.ru
ак47
алтуфьевское шоссе д 51
ваз2107
власть москвы
втб24
город санкт-петербург, ул крузенштерна, дом 5/1а
иванов костантин петрович
мпз
мэра города сергея собянина
подпоручик кижей
рф
Все детали как всегда на github. Текст интересный и с адресами, и с ФИО, и с ошибками в тексте — и результат не менее интересный получился.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python