ведь это — просто токенизатор, неоднозначности в таком виде он снимать не умеет.
Предложенный вами вариант будет интерпретирован как аббревиатура.
Токенизатор это только часть функционала библиотеки, основной функционал это — языковая модель.
Мой вопрос как раз и касался того, что токенизатор дал однозначный ответ в неоднозначной ситуации ещё до того, как модель была проанализирована. Вот эта неоднозначность: "На рис. 1 изображена ваза".
Токенизатор принял однозначное решение, что это — одно предложение.
Именно это меня заинтересовало в первую очередь, отсюда и возник вопрос, каков универсальный алгоритм принятия решения токенизатором в подобной ситуации. Для большей наглядности я дал чуть другой пример: "Смотри на этот рис. 4 месяц 1912 года стал трагедией для Титаника".
Принятие решения токенизатором о том, что это одно предложение — уже будет неверным.
В этом был мой вопрос.
После Вашего пояснения (я полностью с ним согласен и у себя в токенизаторе применяю почти такой же подход) о том, что при обработке и анализе важно учитывать, а не обнулять знаки препинания, ситуация с такой работой токенизатора будет «вводить в заблуждение» дальнейший алгоритм анализа текста.
Ну, я во всяком случае, получаю на своих тестах, именно такой результат. И мои тесты показывают, что словарь сокращений — путь назад от автоматизации.
Поскольку моё видение и тесты не есть истина в последней инстанции, мне и стала интересна Ваша логика для токенизатора. Кстати, по статистике — пояснительные сокращения после цифр в тексте появляются в десятки процентов раз больше, чем до.
Юрий — Вас подтолкнули на очень неоднозначный пример, но поскольку он решился именно с таким результатом, мне стала интересна логика принятия решения.
Если чуть подробнее, то в строке: "На рис. 1 изображена ваза, см. наш каталог." кроется двойная неоднозначность при токенизации и разборе:
токенизация: давайте попробуем другую фразу, скажем в «Смотри на этот рис. 4 месяц 1912 года стал трагедией для Титаника.». Здесь «рис» — это конец предложения, даже будучи сокращением слова рисунок.
анализ текста: при попытке лемматизации Вашего предложения или переделанного мной, на «рис.» мы получим минимум два значения — сокращение от рисунок и «рис» — как растение. При этом, контекст многих предложений не даст однозначного ответа, какое из двух слов имелось ввиду.
В этой связи у меня два вопроса:
— какова у Вас универсальная логика принятия решения при токенизации в данном случае?
— каков механизм разрешения неоднозначности, ну хотя бы для того, чтобы ответить однозначно на вопрос, что фраза «имеет верный контекст с точки зрения собранной языковой модели.»?
Хотел бы обратить внимание на позиции слов в предложении и в двуграммах, например по этим позициям
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), в которых слова переставленные местами относительно оригинального текста.
По факту, здесь был бы к месту словарь двуграмм, однако я не смог найти хороших (качественных) и больших словарей двуграмм на русском — чему я был сильно удивлен.
Физические нагрузки повышают уровень билирубина. В здоровом организме, при общем фоне изменения обмена веществ во время и сразу после физических нагрузок — это не ощущается. Для людей с повышенным уровнем билирубина, физические нагрузки могут дать значительный и быстрый рост, который сам «уходит» крайне медленно.
К уровню физических нагрузок в единицу времени человеку с повышенным уровнем билирубина надо привыкать опытным путем, другого пути, к сожалению, пока — нет.
Для Lifext — предсказательная аналитика дня, времени и объёма физических упражнений из графика физ. нагрузок больного может стать очень интересным и востребованным направлением. Но конкуренция в среде медицинского AI в ближайшие лет 5-10 будет страшная.
1. Даже если не натягивать предлагаемый подход на большие данные, всё равно не видно экономических преимуществ для компании от её внедрения — непонятно откуда возьмутся сокращение затрат на обработку данных или свободные серверные (продуктовые) ресурсы, если взять и просто трансформировать под новый подход существующие ресурсы — т.е. сохранить базу для сравнения.
2. Проблемы в ресурсах у компаний связаны, по большей части, не с бардаком в данных, а с объемом свободных ресурсов под параллельную высоконагруженную обработку при проверке гипотез или отладке, не важно — просто статистики, предсказательной аналитики или AI. Бардак данных может устраняться поэтапно, с учетом имеющихся ресурсов, с сохранением результатов каждого этапа и началом следующего на закомиченных данных после предыдущего. А вот аналитику кусками не пустишь, на качество результата очень сильно влияет.
При Синдроме Жильбера нет необходимости в снижении уровня билирубина, поскольку его повышенный фон является нормой для организма, а вот попытки приведения его в норму ниже средней, могут негативно сказаться на здоровье человека.
На протяжении всей статьи пытался увидеть среди плюсов технологии — увеличение производительности при использовании каждого продукта при трансформации существующих мощностей в новую архитектуру.
Ну предположим, что за счет предподготовки части данных в каждом продукте мы получим какой-то выигрышь в производительности, НО — что нам делать с решением вот этой обозначенной проблемы:
Потребности организаций в инновациях. Необходимость в быстрой проверке гипотез и частых экспериментах ведёт к большому количеству вариантов использования данных.
К своему сожалению я не просто не увидел за счет чего вдруг у меня нарисуются свободные ресурсы для проверки гипотез НА БОЛЬШИХ ДАННЫХ. Более того, за счет дублирования и частого обновления данных между продуктами сама модель потребует на постоянной основе достаточно много ресурсов на самообслуживание целостности и оперативности данных.
В чем будет реально серьезное увеличение затрат на высокопрофессиональные кадры в объеме куда большем, чем число админов по обслуживанию централизованной системы — из текста очевидно, а вот преимущества — совсем не очевидны.
Те-же вопросы сейчас решаются интеграциями на уровне информационных систем или непосредственно БД и это обходится многократно дешевле, чем содержание кучи DevOps'ов к каждому из которых ещё команда бизнес предметников нужна.
Это всё к вопросу о том, почему я ждал радикального высвобождения ресурсов. Для меня — если технология позволяет мне тратить на железо значительно меньше, чем я мог бы потратить за минусом зарплаты всех необходимых DevOps — то это верный путь.
Если же мы говорим, что мы по всем направлениям получаем только рост затрат — системный рост затрат, потому что растет не только объем данных, но и бизнес, а выигрыш только в качестве данных и (очень сомнительном) сокращении объема технического долга, то надо искать другой путь трансформации централизованных систем.
Для достижения однозначности по несловарным словам (с ошибками, с предлогами, через тире, через тире с ошибками и предлогами) только алгоритма Левенштейна оказалось недостаточно. Пришлось добавить дополнительную обработку по сходимости.
Левенштейн + дополнительный алгоритм сильно увеличили время обработки, но это оказалось на пользу. Сделано:
+ оптимизация по производительности;
+ параллельность;
+ рефакторинг.
Из минусов:
— время обработки разных текстов на одной и той же машине стало непредсказуемым из-за большого числа распараллеленных функций;
— тестирование из-за параллельности усложнилось.
В ходе доработок стал мечтать о том, чтобы в функциях объединения Pandas появились два дополнительных параметра max_workers и add_done_callback :)
И ответственно могу сказать, что то, что они называют «планированием» таковым не является.
Давайте попробуем вести обсуждение тем таким образом, чтобы объясняя предмет не унижать кого бы то ни было.
И их «крупные ERP» лучше всего оправить «на свалку истории»… Т.к. внедрены и/или используются они так, что лучше об этом тихо молчать
Можно я не буду вот это вообще комментировать…
Еженощное перепланирование ВСЕГО производства и цепочки поставок.
Еженошное — это не несколько раз в день, согласитесь. Ну и потом, сколько на КННАЗе изделий в одновременном запуске? И сколько там унифицированных ДСЕ? А они, напомните мне, не проектами ли каждый заказ запускают и планируют соответственно?
Что касается перепланирования неск. раз/день… Примеров нет. Потому, что, для большинства, это делать не надо.
Я не удивлен, просто непонятно зачем Вы это заявляли.
А вот насчет «для большинства это и не надо» — Вы не правы.
На предприятиях никто бы и не обсуждал никаких сокращений сроков перепланирования, MESS планирование до смен и т.д., если бы это всё было не надо.
Для такого перепланирования есть два фактора
1 — очевидный: всё, что не сделано в первую смену из положенного, перетекает на вторую, следовательно для второй нужен пересчет, следовательно пересчет нужен и для третьей (ночной или утренней). А ведь есть ещё компании, у которых каровая логистика просчитывается по межцеховой и межпроизводсвтенной транспортировке, которая напрямую зависит от выполненных планов и обновленных планов
2 — не столь очевидный, но присутствует на многих предприятиях, ВПК во всяком случае. В стране много крупных предприятий, которые в 90-е были вынуждены перейти к производству почти всего, что входит в их изделия — самостоятельно. Это привело к очень большой и сложной внутренней кооперации, которая, неизбежно, повлекла специализацию производств по номенклатуре и изделиям. Так внутри предприятий образовались выпускающие производства и специальные. Последние делают универсальную и унифицированную номенклатуру, а следовательно являются самой больной точкой перепланирования. Если в этих производствах происходит недовыполнение плана, то вся кооперация требует пересчета. При дву и трехсменной работе, пересчеты нужны до смен и отчет по выполнению до смен.
А теперь вернемся к вопросу повышения затрат. На сегодня, даже при двусменных работах никто уже не выводит кладовщиц, плановиков и распредов на вечерние и ночные смены. Все материалы стараются выдать в конце предыдущей смены на оставшиеся смены текущего дня, а данные о выполнении планов заводятся дискретно — раз в день, а во многих местах и того реже — часто просто на переходах любых, кое где — по сдаче выдаче со склада на склад ДСЕ (есть такие способы автоматизации, что НЗП ведется учетом только по факту перемещения по складам ДСЕ, а не по пооперационному перемещению). Так вот для пересчета хотя бы 2 раза в день, затраты предприятия значительно вырастают, потому что надо нанимать НА ПОСТОЯННУЮ РАБОТУ новых людей и платить им всегда заработную плату (оклады у этих категорий служащих) и кладовщикам, и плановикам и распредам и ИТ специалистам, которым придется работать в несколько смен.
Более того, Вы сразу влетаете в немного другой уровень железа, потому что если скажем на раскрутку всех планов до позаказного сейчас предприятия могут позволить себе тратить от 8-ми до 13-ти часов, то при таком расчете время схлопытвается максимум до 5-6 часов на весь пересчет и это при условии, что все данные по выполнению, вот эти вот перечисленные выше сотрудники во всех производствах и цехах успеют завести максимум за 1 час.
И это тоже деньги, и кстати очень немалые деньги с учетом двух резервов (горячего и холодного для полного восстановления).
По первому абзацу — работаем с очень крупной западной ERP и эффект обратный Вами заявленному.
В 2019-м был на шести крупных предприятиях ВПК страны, где тоже очень крупные ERP — это и предприятия холдинга Антея, и ТРВ, и Росатома. Так вот везде — увеличение частоты перепланирования приводит к значительному росту затрат.
Где именно подтверждено практикой — я бы очень хотел посетить такое предприятие, если оно производственное и работающее с ГОЗом.
По второму абзацу — можно тоже пример предприятия в России, где в крупной ERP с числом заказов в перепланировании в десятки тысяч и в маршруте не менее, ну хотя бы 3-х подразделений в заказе, перепланирование осуществляется по несколько раз в день?
Было бы очень интересно увидеть не только показатели улучшения времени при более частом перепланировании и актуализации данных о выполнении по производству, но и параллельного роста затрат на обеспечение этой оперативности.
На Ваших графиках очень бы хорошо смотрелась ещё одна линия — временные затраты на поддержание процесса.
Практика показывает, что у такого подхода к «повышению эффективности производства» есть тёмная сторона — затраты, которые при применении скажем еженедельного перепланирования резко возрастают и в стоимостном выражении, и по времени.
Причины просты — чем чаще план и отчет, тем больше нужно привлечь людей, которые не осуществляют производственной деятельности (диспетчеров, кладовщиков, распредов, плановиков, экономистов, специалистов ОТК, ИТшников и т.д.) — т.е. не создают прибыли.
Это — при идеальных условиях. А при наличии проблем в планировании (появление нового заказа с более высоким приоритетом при свободной НЗП и мат. запасах) порождает ещё и большой слой совещаний и переписки с привлечением уже ТОПов (час работы которых может быть весьма не дешев при отнесении этих затрат на конкретные заказы).
Сокращаю число нераспознанных слов:
+ Левенштейн — решен
+ несловарные приставки — решен
+ слова через дефис — обработка в процессе
+ Левенштейн и несловарные приставки для слов через дефисы — решен
Решение вопроса с аббревиатурами ключевых слов и выражений потребовало больше изменений, чем я изначально предполагал, но это пошло только на пользу.
Ниже обновленные ключи к этой статье, полученные доработанным алгоритмом, по тем же правилам (не признавать ключами выражений с числовыми данными, признавать ключами слова, повторяющиеся по тексту не менее 8 раз) + фильтр на ключи с маркером LATN:
полностью переработаны словари. Теперь основной словарь может быть изменен только программно вместе с обновлением исходного OpenCorpora – он трансформирован и дополнен данными не из словаря OpenCorpora. Дополнительные словари упрощены до списков лемм и/или аббревиатур в словаре специальных терминов, которые могут пополняться вручную;
введена многоуровневая процедура разрешения конфликтов неоднозначности определения леммы – возвращается одна (не несколько записей с вероятностью) конкретная строка с леммой;
введена процедура поиска устойчивых выражений из неключевых слов;
добавлены новые маркеры — теперь их 25 шт.;
в вывод добавлено много дополнительной информации по атрибутам словоформы. Если раньше в выводе было 10 полей, то теперь их 28.
добавлено восстановление текста после обработки;
добавлена маркировка восстановленных текстов с разными параметрами;
добавлено при маркировке и восстановлении текстов размещение по месту вхождения сгенерированных выражений, которых в таком виде в исходном тексте может и не быть.
Каждый новый расчет теперь иметь две папки (раньше была одна в корне подпапки):
data – папка с данными, о которых говорилось в статье выше. Те же файлы с тем же смыслом, но с большим объемом дополнительной информации по каждому слову;
marked – папка с размеченными восстановленными текстами в разных форматах.
Чуть расскажу по восстановленным размеченным файлам в папке 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 – список обозначений маркеров, если пусто то маркировать все.
>Я признаюсь, nrlpk на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
Это точно.
Ну так может быть Вам просто перестать что-то обсуждать с таким бестолковым парнем как я, тем более когда Вы решаете такие задачи всего за один день. И я конечно не дождусь от Вас реализации за один день? Впрочем, мы оба знаем ответ на этот вопрос…
А почему бы и не пообсуждать, если это для дела полезно?
Вам лучше поискать для подобных бесед собеседника соответствующего Вашим знаниям.
Ну так я вам конструктивную критику для этого и даю, чтобы вы исправились.
Сижу… Ищу конструктивную критику. Диву просто даюсь на конструктив, то проценты какие то из головы берете, а не из моей статьи, то вот это например
если не склеивать разные сокращения вместе, дают от силы долю процента качества (вы с такой точностью даже не можете это измерить сейчас, ха-ха, и не поймёте, помогают ли вам сокращения или мешают).
Если бы Вы посмотрели хоть один файл статистики, то без труда смогли бы понять реальную долю выражений с сокращениями. Не пришлось бы конструктивно из пальца какие-то доли процентов без сокращений придумывать.
То есть, вы не можете решить задачу с низким качеством за день, а мне подменили понятия и хотите чтобы я за день решил задачу с высоким качеством. А я говорил о том, что с вашим качеством я решаю такую задачу за день
А теперь представьте, что есть возможность выбрать слова или последовательности слов из текста в качестве ключевых, и кроме этого есть возможность выбрать из миллиона понятий, например, отобранных через аналог алгоритма 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 на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
Я пропущу первую, эмоциональную и не конструктивную часть Вашего комментария, и отвечу только на то, что имеет смысл обсуждать.
Я утверждаю, что бизнесу намного чаще нужна другая задача, не 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 слов стоящих рядом, можно гарантированно выбрать аббревиатуру, которая может существовать где-то в тексте или заголовке?
или теперь ещё один, новый — и что есть примеры получения качественных алгоритмов полученных на грязных отладочных и тестовых данных?
— «необходимо брать слова их статьи» (тогда почему у вас есть сокращения — это же не слова из статьи?),
Сокращения — это приведенные слова из статьи. Среди сокращений нет ни одного, которое бы было построено не из слов из статьи. Причем не просто из слов, любых выбранных произвольным порядком, а отобранных по четким и понятным правилам.
— «нельзя взвешивать заголовок выше чем статью, потому что вдруг заголовок будет неактуальным да и вообще непонятно почему» — ну так определяйте, похож ли заголовок на статью или это отвлечённый от темы статьи мем/каламбур для привлечения внимания, и стоит ли брать оттуда ключевые слова.
Именно поэтому в вопросе приоритетности слов заголовка я и сказал, что надо хорошо взвесить. Определение «похож» ли заголовок, слишком простое, для выдачи ему приоритета, неважно — похож он или нет, но следуя Вашей логике — это уже заголовок становится зависим (похож) от текста — и вся логика, изложенная Вами ранее
(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 минуты.
Ну и может не генерировать все возможные ключи, а предложить сразу оптимальные, а человек пусть потом добавляет или убирает, что хочет?
Я к этому и стремлюсь.
То есть, вы не знаете, что такое тестовый сет в машинном обучении? (И сколько должно быть в нём данных, чтобы получать более-менее объективные результаты?)
Чтобы нам не удариться в бесполезную дискуссию кто лучше/хуже что знает и т.д., на данный вопрос мне проще ответить — НЕТ.
Начну ответ с конца Вашего поста, поскольку вижу, что наша логика по поиску ключевых слов очень различается, поэтому я попытаюсь объяснить свою через примеры и аргументы.
(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?
У меня такое ощущение, что аббревиатуры вам совсем не надо было делать.
Я попробую построить свой ответ вокруг вот этой точно подмеченной, как одна из проблем, фразы. Пойду от простых моментов к наиболее спорным.
«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
Всю эту расшифровку я собственно привел по двум причинам
показать, что выражения (словосочетания) как раз выбираются, но далеко не по принципу два слова стоящие рядом и частота их повторения — это далеко не всегда есть ключи.
показать тонкости проблемы аббревиатуры.
Первая тонкость, зачем нужны аббревиатуры очень хорошо показывает себя на Natural Russian Language Processing by the Keys — если не превратить это выражение в корректную аббревиатуру, то:
оно не посчитается частотой упоминаний по тексту с названием nrlpk, которое также присутствует в тексте. И это просто удача, что оба этих выражения иностранные и так и так попали в ключи, а ведь могли бы быть каким-нибудь русским названием и его сокращением, которое смогло бы попасть в ключи только по принципу частоты упоминания по тексту в разных словоформах
непонятно как его показывать в ключах (хештегах), как слова без пробелов (как в инстаграмм например), типа naturalrussianlanguageprocessingbythekeys — насколько это вообще лучше? для меня лично это спорный вопрос. Для Хабра в частности, видимо тоже вопрос очень спорный, поскольку у них для разметки своих текстов предложен html-тэг
<abbr></abbr>
с возможностью расшифровки аббревиатуры хинтом.
Вопрос аббревиатур, который Вы поднимаете, у меня тоже вызывает много сомнений, но — пока он показал себя как наилучший вариант выхода из ситуаций, наподобие такой — в тексте "выставка цветов" и "выставку цветов" — отобранные выражения не будут равны друг другу, хотя это одно и тоже, и даже если провести декомпозицию выражения с последующей пословной токенизацией, лемматизацией и снова сделать выражением, то мы получим «выставка цветок», что меняет смысл выражения и становится нечитабельным, и при этом так и не решается проблема, а как же показать её в качестве ключа — выставкацветок или вц?
Хочется отметить, что при анализе использования аббревиатур в качестве ключей рассматривалось и положительное влияние на выборку по тексту и отрицательное. Например, в тексте, который мы рассматриваем, есть два разных выражения, которые корректно попали в ключи, но совпали по аббревиатуре, хотя и имеют разные значения. Это Pandas DataFrame или Python Dictionary — оба они получили аббревиатуру pd.
Однако, тестирование показало, что количество таких случаев в рамках одного текста встречается кратно реже, чем одинаковые выражения с разными формами слов.
Поэтому пока я остановился именно на варианте аббревиатур, хотя я с Вами полностью согласен в том, что вид у таких аббревиатур зачастую отталкивающий, чем расшифровывающий смысл, но идею Хабра по title в abbr возможно и можно превратить в более корректное именно представление ключа, а не его отбор.
поглядите может всё же на ключевые работы по keyword extraction
Ответ в моих комментариях выше.
Возможно Вы подскажите какой то пакет, который в этом вопросе на русском языке себя очень сильно зарекомендовал?
С момента размещения материала число маркеров выросло с 16 до 22, что, ожидаемо, повысило качество отбора ключей. Смотрим результат анализа этой статьи (позиция 48 старый алгоритм, 48-1 – обновленный). С обновленным алгоритмом число слов в мусоре снизилось с 41 до 13, и из ручной сверки один ключ вошел корректно (смотрим те же позиции 48 и 48-1).
При добавлении маркеров продолжил сохранять совместимость в маркировке граммем с pymorhy2 и добавил с той же смысловой нагрузкой:
LATN — токен состоит из латинских букв;
PNCT – пунктуация
Пунктуация понадобилась в рамках подготовки результата к многослойной маркировке текста.
В рамках этой работы и поиска ключей, внутри маркированных выражений сделана декомпозиция выражений с умным отбором ключей в окончательную выборку.
Декомпозиция дала более точное значение числа слов в тексте – сравнение анализа текста с разными алгоритмами это явно показывает. Характеристики текста тоже были уточнены.
Мой вопрос как раз и касался того, что токенизатор дал однозначный ответ в неоднозначной ситуации ещё до того, как модель была проанализирована. Вот эта неоднозначность: "На рис. 1 изображена ваза".
Токенизатор принял однозначное решение, что это — одно предложение.
Именно это меня заинтересовало в первую очередь, отсюда и возник вопрос, каков универсальный алгоритм принятия решения токенизатором в подобной ситуации. Для большей наглядности я дал чуть другой пример: "Смотри на этот рис. 4 месяц 1912 года стал трагедией для Титаника".
Принятие решения токенизатором о том, что это одно предложение — уже будет неверным.
В этом был мой вопрос.
После Вашего пояснения (я полностью с ним согласен и у себя в токенизаторе применяю почти такой же подход) о том, что при обработке и анализе важно учитывать, а не обнулять знаки препинания, ситуация с такой работой токенизатора будет «вводить в заблуждение» дальнейший алгоритм анализа текста.
Ну, я во всяком случае, получаю на своих тестах, именно такой результат. И мои тесты показывают, что словарь сокращений — путь назад от автоматизации.
Поскольку моё видение и тесты не есть истина в последней инстанции, мне и стала интересна Ваша логика для токенизатора. Кстати, по статистике — пояснительные сокращения после цифр в тексте появляются в десятки процентов раз больше, чем до.
Если чуть подробнее, то в строке: "На рис. 1 изображена ваза, см. наш каталог." кроется двойная неоднозначность при токенизации и разборе:
В этой связи у меня два вопроса:
— какова у Вас универсальная логика принятия решения при токенизации в данном случае?
— каков механизм разрешения неоднозначности, ну хотя бы для того, чтобы ответить однозначно на вопрос, что фраза «имеет верный контекст с точки зрения собранной языковой модели.»?
Заранее благодарен за ответ.
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), в которых слова переставленные местами относительно оригинального текста.
По факту, здесь был бы к месту словарь двуграмм, однако я не смог найти хороших (качественных) и больших словарей двуграмм на русском — чему я был сильно удивлен.
К уровню физических нагрузок в единицу времени человеку с повышенным уровнем билирубина надо привыкать опытным путем, другого пути, к сожалению, пока — нет.
Для Lifext — предсказательная аналитика дня, времени и объёма физических упражнений из графика физ. нагрузок больного может стать очень интересным и востребованным направлением. Но конкуренция в среде медицинского AI в ближайшие лет 5-10 будет страшная.
2. Проблемы в ресурсах у компаний связаны, по большей части, не с бардаком в данных, а с объемом свободных ресурсов под параллельную высоконагруженную обработку при проверке гипотез или отладке, не важно — просто статистики, предсказательной аналитики или AI. Бардак данных может устраняться поэтапно, с учетом имеющихся ресурсов, с сохранением результатов каждого этапа и началом следующего на закомиченных данных после предыдущего. А вот аналитику кусками не пустишь, на качество результата очень сильно влияет.
Ну предположим, что за счет предподготовки части данных в каждом продукте мы получим какой-то выигрышь в производительности, НО — что нам делать с решением вот этой обозначенной проблемы:
К своему сожалению я не просто не увидел за счет чего вдруг у меня нарисуются свободные ресурсы для проверки гипотез НА БОЛЬШИХ ДАННЫХ. Более того, за счет дублирования и частого обновления данных между продуктами сама модель потребует на постоянной основе достаточно много ресурсов на самообслуживание целостности и оперативности данных.
В чем будет реально серьезное увеличение затрат на высокопрофессиональные кадры в объеме куда большем, чем число админов по обслуживанию централизованной системы — из текста очевидно, а вот преимущества — совсем не очевидны.
Те-же вопросы сейчас решаются интеграциями на уровне информационных систем или непосредственно БД и это обходится многократно дешевле, чем содержание кучи DevOps'ов к каждому из которых ещё команда бизнес предметников нужна.
Это всё к вопросу о том, почему я ждал радикального высвобождения ресурсов. Для меня — если технология позволяет мне тратить на железо значительно меньше, чем я мог бы потратить за минусом зарплаты всех необходимых DevOps — то это верный путь.
Если же мы говорим, что мы по всем направлениям получаем только рост затрат — системный рост затрат, потому что растет не только объем данных, но и бизнес, а выигрыш только в качестве данных и (очень сомнительном) сокращении объема технического долга, то надо искать другой путь трансформации централизованных систем.
Может быть я что-то неверно понял в этой части?
Всё как всегда на Github – тест одного и того же текста на старом алгоритме 4-1 и на новом 4-3.
Для достижения однозначности по несловарным словам (с ошибками, с предлогами, через тире, через тире с ошибками и предлогами) только алгоритма Левенштейна оказалось недостаточно. Пришлось добавить дополнительную обработку по сходимости.
Левенштейн + дополнительный алгоритм сильно увеличили время обработки, но это оказалось на пользу. Сделано:
+ оптимизация по производительности;
+ параллельность;
+ рефакторинг.
Из минусов:
— время обработки разных текстов на одной и той же машине стало непредсказуемым из-за большого числа распараллеленных функций;
— тестирование из-за параллельности усложнилось.
В ходе доработок стал мечтать о том, чтобы в функциях объединения Pandas появились два дополнительных параметра max_workers и add_done_callback :)
Давайте попробуем вести обсуждение тем таким образом, чтобы объясняя предмет не унижать кого бы то ни было.
Можно я не буду вот это вообще комментировать…
Еженошное — это не несколько раз в день, согласитесь. Ну и потом, сколько на КННАЗе изделий в одновременном запуске? И сколько там унифицированных ДСЕ? А они, напомните мне, не проектами ли каждый заказ запускают и планируют соответственно?
Я не удивлен, просто непонятно зачем Вы это заявляли.
А вот насчет «для большинства это и не надо» — Вы не правы.
На предприятиях никто бы и не обсуждал никаких сокращений сроков перепланирования, MESS планирование до смен и т.д., если бы это всё было не надо.
Для такого перепланирования есть два фактора
1 — очевидный: всё, что не сделано в первую смену из положенного, перетекает на вторую, следовательно для второй нужен пересчет, следовательно пересчет нужен и для третьей (ночной или утренней). А ведь есть ещё компании, у которых каровая логистика просчитывается по межцеховой и межпроизводсвтенной транспортировке, которая напрямую зависит от выполненных планов и обновленных планов
2 — не столь очевидный, но присутствует на многих предприятиях, ВПК во всяком случае. В стране много крупных предприятий, которые в 90-е были вынуждены перейти к производству почти всего, что входит в их изделия — самостоятельно. Это привело к очень большой и сложной внутренней кооперации, которая, неизбежно, повлекла специализацию производств по номенклатуре и изделиям. Так внутри предприятий образовались выпускающие производства и специальные. Последние делают универсальную и унифицированную номенклатуру, а следовательно являются самой больной точкой перепланирования. Если в этих производствах происходит недовыполнение плана, то вся кооперация требует пересчета. При дву и трехсменной работе, пересчеты нужны до смен и отчет по выполнению до смен.
А теперь вернемся к вопросу повышения затрат. На сегодня, даже при двусменных работах никто уже не выводит кладовщиц, плановиков и распредов на вечерние и ночные смены. Все материалы стараются выдать в конце предыдущей смены на оставшиеся смены текущего дня, а данные о выполнении планов заводятся дискретно — раз в день, а во многих местах и того реже — часто просто на переходах любых, кое где — по сдаче выдаче со склада на склад ДСЕ (есть такие способы автоматизации, что НЗП ведется учетом только по факту перемещения по складам ДСЕ, а не по пооперационному перемещению). Так вот для пересчета хотя бы 2 раза в день, затраты предприятия значительно вырастают, потому что надо нанимать НА ПОСТОЯННУЮ РАБОТУ новых людей и платить им всегда заработную плату (оклады у этих категорий служащих) и кладовщикам, и плановикам и распредам и ИТ специалистам, которым придется работать в несколько смен.
Более того, Вы сразу влетаете в немного другой уровень железа, потому что если скажем на раскрутку всех планов до позаказного сейчас предприятия могут позволить себе тратить от 8-ми до 13-ти часов, то при таком расчете время схлопытвается максимум до 5-6 часов на весь пересчет и это при условии, что все данные по выполнению, вот эти вот перечисленные выше сотрудники во всех производствах и цехах успеют завести максимум за 1 час.
И это тоже деньги, и кстати очень немалые деньги с учетом двух резервов (горячего и холодного для полного восстановления).
В 2019-м был на шести крупных предприятиях ВПК страны, где тоже очень крупные ERP — это и предприятия холдинга Антея, и ТРВ, и Росатома. Так вот везде — увеличение частоты перепланирования приводит к значительному росту затрат.
Где именно подтверждено практикой — я бы очень хотел посетить такое предприятие, если оно производственное и работающее с ГОЗом.
По второму абзацу — можно тоже пример предприятия в России, где в крупной ERP с числом заказов в перепланировании в десятки тысяч и в маршруте не менее, ну хотя бы 3-х подразделений в заказе, перепланирование осуществляется по несколько раз в день?
На Ваших графиках очень бы хорошо смотрелась ещё одна линия — временные затраты на поддержание процесса.
Практика показывает, что у такого подхода к «повышению эффективности производства» есть тёмная сторона — затраты, которые при применении скажем еженедельного перепланирования резко возрастают и в стоимостном выражении, и по времени.
Причины просты — чем чаще план и отчет, тем больше нужно привлечь людей, которые не осуществляют производственной деятельности (диспетчеров, кладовщиков, распредов, плановиков, экономистов, специалистов ОТК, ИТшников и т.д.) — т.е. не создают прибыли.
Это — при идеальных условиях. А при наличии проблем в планировании (появление нового заказа с более высоким приоритетом при свободной НЗП и мат. запасах) порождает ещё и большой слой совещаний и переписки с привлечением уже ТОПов (час работы которых может быть весьма не дешев при отнесении этих затрат на конкретные заказы).
+ Левенштейн — решен
+ несловарные приставки — решен
+ слова через дефис — обработка в процессе
+ Левенштейн и несловарные приставки для слов через дефисы — решен
Ниже обновленные ключи к этой статье, полученные доработанным алгоритмом, по тем же правилам (не признавать ключами выражений с числовыми данными, признавать ключами слова, повторяющиеся по тексту не менее 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), где
Ну так может быть Вам просто перестать что-то обсуждать с таким бестолковым парнем как я, тем более когда Вы решаете такие задачи всего за один день. И я конечно не дождусь от Вас реализации за один день? Впрочем, мы оба знаем ответ на этот вопрос…
Вам лучше поискать для подобных бесед собеседника соответствующего Вашим знаниям.
Сижу… Ищу конструктивную критику. Диву просто даюсь на конструктив, то проценты какие то из головы берете, а не из моей статьи, то вот это например
Если бы Вы посмотрели хоть один файл статистики, то без труда смогли бы понять реальную долю выражений с сокращениями. Не пришлось бы конструктивно из пальца какие-то доли процентов без сокращений придумывать.
:))) Прощайте.
На сайте ВПК.name, по материалам которого я и веду тестирование, описываемая Вами задача уже решена, менее простым и трудоёмким способом. Там к каждой статье автоматически цепляются ключи уже лет 5-7 как. НО, как и в Вашем предложении, там есть большая проблема — это поддержание и развитие тех самых категорий или ключей в категориях, как это реализовано у них.
Это задача будет заведомо сужена ключами конкретной платформы. Кроме того, снова встает вопрос с качеством источников, к примеру — та же википедия, это далеко не лучший источник по качеству.
Это не плохо, и такие вещи, как «Джо», «Байден», «Джо Байден», «Байдену» могут быть учтены, при совсем небольших доработках и в nrlpk, но только в одном случае — если в тексте больше не было Джо.
А вот для того, чтобы «вице-президенту США» превратился в «Джо Байдена» нужны либо очень серьезный словарь соответствия, либо очень серьезная сеть ассоциаций, учитывающая временные интервалы описания в тексте — понимаете о чем я? Вице-президенты США меняются…
И первый вариант и второй требуют очень серьезных проработок, обучения моделей и большого набора альтернативных сценариев выбора вероятностей для ключа.
Я был бы тоже за такой реализации но, такого не может даже Яндекс, правда может Гугл.
Мы ведь не их алгоритмы обсуждаем? И да, там не word2vec и не sense2vec
Может быть Вы статью, на которую дали ссылку полностью прочитаете. Я Вам дам одну только цитату оттуда, поскольку она подтверждает то, что я пытался донести до Вас в своих постах выше
Ну а из остальной части текста, Вы узнаете, что обе сравниваемые модели имели предварительную подготовку данных, именно поэтому сравнение оказывается уместным.
О, простите…
Если Вами уже решена эта задача, или Вы готовы выдать её уже завтра к вечеру, то да, я буду вынужден признать бесполезность своей работы и, что зря тратил своё время и Ваше, и других читателей.
До завтрашнего вечера!
Желаю Вам получить стабильный результат по Байдену и от должности, и от места жительства, и от сына Бо — ну а почему бы и нет… Чем Вы хуже Гугл, в конце то концов…
Я признаюсь, nrlpk на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
Если бизнесу важнее любые слова в качестве ключевых к любому тексту, то эту задачу не надо автоматизировать, просто потому что задача любой к любому решается быстро и просто — random + random
Но комментирую я этот фрагмент потому, что в нем есть более интересная фраза — «бизнесу нужна другая задача».
Если бы решалась задача бизнеса, скажем того же Хабра, например для увеличения числа переходов между страницами, то система тоже была бы построена довольно не сложно: частотный словарь тэгов Хабра + словарь тегов во всех словоформах + словарь слов, которые могут служить синонимами или схожими по смыслу (как ключевое слово и keyword, которые синонимами не являются) + возможность добавить свой тэг.
Но я пытаюсь решить проблему людей, а не бизнеса!!! Люди не хотят думать о ключах, хотя в современных платформах без ключей им довольно тяжело расширить круг читающих их материалы. Вот я пытаюсь сделать так, чтобы они и продолжали о них не думать, но при этом всё-таки имели ключи.
Поэтому я не решаю проблемы бизнеса! Более того, я полагаю, что бизнес, который «замыкает» речи людей в рамках распространенных или общепринятых ключей (это то, к чему Вы сводите разговор своими примерами), скажем так, немного теряет от этого.
Если Вы перечитаете текст статьи, то именно эти мысли в ней и увидите. Да, я понимаю, что вижу не всё, а что-то должно попасть в ключи, при совпадении нескольких альтернатив, и да я осознанно снижаю процент качества, именно из-за этого и из-за того, что вообще ряда вещей не замечаю.
И именно для этого и ищется инвестор или новый владелец, потому что уже полученное качество, имеет достаточно высокий показатель.
А для конструктивной критики я открыл все результаты расчетов, чтобы у тех, кто действительно заинтересован, сам смог убедиться в результатах.
Проблема аббревиатур — не критичная проблема. Если выработать иной принцип преобразования, то она будет решена в очень короткий срок. Просто именно тут нужно некое коллективное мнение, потому что дальше, эти данные будут нужны для внутренних расчетов.
Тут уместно как раз поговорить о субъективности мнений.
Но я бы предложил Вам спросить своих знакомых, не имеющих отношения к ИТ и не англоговорящих, какие ключи они бы написали к фразе «тут Ваша фраза, к которой Вы бы подставили иностранные ключи» и посчитать сколько раз они назовут Вам иностранные ключевые слова и вообще назовут совпавшие с Вашим видением ключей.
Среди отобранных ключей нет, которые подходят лично Вам?
Я уже сказал, что ни Вы, ни я, не являемся целевой аудиторией, потому что у нас уже искаженное понятие о ключах, мы уже в шорах принятых стандартов их применения.
Безусловно, можно пытаться написать модель выбора ключей под эти шоры, но тогда алгоритм понятен и отталкиваться надо не от текста, а от имеющегося набора ключей, которые интересны конкретной платформе. И это совсем другая задача — выбрать из текста ключи максимально близкие к принятым на платформе и показать оптимальные под заданный критерий повторяемости по тексту и частности использования на платформе.
Но я в девятый раз повторю — nrlpk решает другую задачу, она показывает ключами то, что показал как ключи в своем тексте автор.
И когда я говорю о понятных алгоритмах, я имею ввиду не мне, а универсальных, работающих по единым принципам по любым текстам.
Я их и не искажаю, а говорю о том, что эти ключи отсутствуют в тексте и непосредственно из текста их выбрать нельзя, более того, 50% из них иностранные для русского текста и даже через синонимы в него попасть не могут.
и
и
Я очень не хочу дискуссии в таком ключе и пытаюсь её избежать уже в третий раз, но видимо где-то надо Вас остановить…
1. почитайте внимательно материал, который Вы комментируете — там нет цифр 95-100%.
3. для того, чтобы увеличивать тестовую выборку, нужно иметь выборку с эталоном. Тут дальше должно быть много нудных технических деталей, суть которых в итоге сведется к тому, что её не существует. И да
Ключевое слово — выбирают:
Таким образом Ваше предложение сводится к следующему:
Хм. Спасибо… Надеюсь сами Вы так не делаете.
Я не останавливаю тестов, цель хоть и не 1000, но и не ткущие показатели.
Я восхищен Вашей способностью генерировать непроверенные гипотезы, показывая их как достоверные и игнорировать все больные вопросы по таким гипотезам, которые я задаю Вам, ну например
или теперь ещё один, новый — и что есть примеры получения качественных алгоритмов полученных на грязных отладочных и тестовых данных?
Сокращения — это приведенные слова из статьи. Среди сокращений нет ни одного, которое бы было построено не из слов из статьи. Причем не просто из слов, любых выбранных произвольным порядком, а отобранных по четким и понятным правилам.
Именно поэтому в вопросе приоритетности слов заголовка я и сказал, что надо хорошо взвесить. Определение «похож» ли заголовок, слишком простое, для выдачи ему приоритета, неважно — похож он или нет, но следуя Вашей логике — это уже заголовок становится зависим (похож) от текста — и вся логика, изложенная Вами ранее
сразу разрушается об Ваши же дальнейшие, логичные рассуждения.
У меня нет в тексте Natural Language Processing — в тексте есть Natural Russian Language Processing. И я не представляю какой универсальной (для 90% случаев) логикой, возможно исключить одно, именно 2-е слово из текста?
Если Вы следовали логикам:
Так какая же машинная логика позволила Вам сказать, что из любых 6 слов стоящих рядом, можно гарантированно выбрать аббревиатуру, которая может существовать где-то в тексте или заголовке? Или, применительно к данному примеру, какой логикой Вы получили из Natural Russian Language Processing by the Keys именно Natural Language Processing?
Нет. Задача программы не заменить человека, а заменить часть его рутинной работы, по формированию ключей из текста, который он написал.
Вы пытаетесь расширить область программы, с фразы «ключей, из текста, который он написал» на фразу «ключей, на основе текста, который он написал».
Направление понятно и перспективно — альтернативная ветка для расчета вероятности каждого ключа. К ЭТИМ ВЕТКАМ в nrlpk идет подготовка в виде цифр.
На этот вопрос мой развернутый ответ есть в комментарии выше.
Хм, ну давайте тогда внимательно посмотрим на Ваше предложение, цитата из Вашего поста выше:
По пунктам, так сказать:
Из 4-х слов, 2 иностранные (т.е. 50%) и их в принципе нет в тексте статьи. Почему Вы предложили именно такие ключи, я понимаю, но — я не просто так написал Вам
Я дополню свои предыдущие слова — не просто за кадром, а только подменой через синонимы и частотность тегов исключительно для определенной платформы. ИМХО, это уже теория на грани подгона, под нужный результат, ИМХО.
Правда? А у меня даже простой выбор Хабов к этой статье занял больше 5 минут.
А по ключам, да ещё применительно к хабру, я бы застрял очень надолго.
Обращаю внимание, я в этой области хоть что-то понимаю. А 90% пользователей в этом всём просто «прохожие» — но это именно та аудитория, которая составляет в соц. сетях, СМИ и вообще Интернет активное большинство. Т.е. целевая аудитория — не мы с Вами.
Я к этому и стремлюсь.
Чтобы нам не удариться в бесполезную дискуссию кто лучше/хуже что знает и т.д., на данный вопрос мне проще ответить — НЕТ.
На примере этой статьи. Если бы я писал статью про 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?
Я попробую построить свой ответ вокруг вот этой точно подмеченной, как одна из проблем, фразы. Пойду от простых моментов к наиболее спорным.
По тексту без дополнительной обработки присутствуют слова: nusr, wiqm, lemm и unkn.
Логика их отбора в чистом виде такова: если автор поставил в текст иностранные слова для основного языка, значит он хотел обратить внимание на эти «термины» или «названия».
Ответ, по 2т 2ф2г чп чмо пнврт шо nlrp ни — будет ниже.
Слова «выуживающий» и «глазками» автор текста поставил в кавычки, выделил по тексту таким образом, чтобы читатель обязательно обратил на них внимание, т.е. по сути, он сказал — для меня, это не просто слова в тексте, для меня это важно.
Логика их отбора — если для автора это важно, значит для системы это ключ.
Вся система сейчас построена на правилах. Вы обратили внимание, что я нигде по тексту не упоминал, что работает ИИ, и в хабах к статье умышленно не выбрал ИИ. Потому что, пока есть что ещё можно выжать логикой.
Почему Вы решили, что это опечатки? А вот если по тексту так самолет Ан-2 и компания Ан. Тут система тоже должна отреагировать так, что это опечатки?
В данном конкретном случае, у pymorhy действительно есть две версии, базовая, которая была запущена изначально, так и называлась pymorhy, следующая стала называться pymorhy2.
Я уже проходил эту дискуссию сам с собой при анализе названий, и даже была версия ПО, которая могла взять например Ми-28Н Ночной Охотник — вместе, однако, когда далее по тексту я видел отдельно Ми-28Н и Ночной Охотник, то понял, что я не прав. И эта логика оказалась некорректной, поэтому была отключена.
Вот теперь вернемся к нашим (2т 2ф2г чп чмо пнврт шо nlrp ни) аббревиатурам — всё это, сгенерированные аббревиатуры «выражений» — словосочетаний в Ваших терминах, по разным алгоритмам для разных маркеров. Вы можете их сами увидеть в выборках в поле tword или word. Для удобства разбора я их приведу здесь:
Всю эту расшифровку я собственно привел по двум причинам
Первая тонкость, зачем нужны аббревиатуры очень хорошо показывает себя на Natural Russian Language Processing by the Keys — если не превратить это выражение в корректную аббревиатуру, то:
Вопрос аббревиатур, который Вы поднимаете, у меня тоже вызывает много сомнений, но — пока он показал себя как наилучший вариант выхода из ситуаций, наподобие такой — в тексте "выставка цветов" и "выставку цветов" — отобранные выражения не будут равны друг другу, хотя это одно и тоже, и даже если провести декомпозицию выражения с последующей пословной токенизацией, лемматизацией и снова сделать выражением, то мы получим «выставка цветок», что меняет смысл выражения и становится нечитабельным, и при этом так и не решается проблема, а как же показать её в качестве ключа — выставкацветок или вц?
Хочется отметить, что при анализе использования аббревиатур в качестве ключей рассматривалось и положительное влияние на выборку по тексту и отрицательное. Например, в тексте, который мы рассматриваем, есть два разных выражения, которые корректно попали в ключи, но совпали по аббревиатуре, хотя и имеют разные значения. Это Pandas DataFrame или Python Dictionary — оба они получили аббревиатуру pd.
Однако, тестирование показало, что количество таких случаев в рамках одного текста встречается кратно реже, чем одинаковые выражения с разными формами слов.
Поэтому пока я остановился именно на варианте аббревиатур, хотя я с Вами полностью согласен в том, что вид у таких аббревиатур зачастую отталкивающий, чем расшифровывающий смысл, но идею Хабра по title в abbr возможно и можно превратить в более корректное именно представление ключа, а не его отбор.
Ответ в моих комментариях выше.
Возможно Вы подскажите какой то пакет, который в этом вопросе на русском языке себя очень сильно зарекомендовал?
При добавлении маркеров продолжил сохранять совместимость в маркировке граммем с pymorhy2 и добавил с той же смысловой нагрузкой:
Пунктуация понадобилась в рамках подготовки результата к многослойной маркировке текста.
В рамках этой работы и поиска ключей, внутри маркированных выражений сделана декомпозиция выражений с умным отбором ключей в окончательную выборку.
Декомпозиция дала более точное значение числа слов в тексте – сравнение анализа текста с разными алгоритмами это явно показывает.
Характеристики текста тоже были уточнены.
Ну и чисто из любопытства, пропустил через nrlpk свой предыдущий комментарий с теми же параметрами (позиция 49 в списках), получилось, что под ним, должны бы были автоматически сгенерироваться следующие ключи: lemm, nltk, nrlpk, pymorhy, pymorhy2, python, unkn, анализ, задача, ключевой, машина, миг-29, наташа, ни, русский, слово, текст, увидел, язык.
В мусор ушло 6 слов – слова с орфографическими ошибками и не идентифицированные — пока…