• Почему мониторинг простоев тянет бизнес на дно?
    0
    А вот рядовые сотрудники Росатома аббревиатуру ПСР расшифровывают несколько иначе — Перспективный Сексуальный Робот.

    И в этой расшифровке оказывается заложено довольно много скрытого смысла, отражающего сформировавшиеся условия труда рядовых сотрудников (не руководства) после внедрения ПСР. Для пущего понимания — на одном из заводов Росатома у рабочих (станочников) отобрали стулья и табуретки, чтобы они не могли сидеть во время смены, видимо мотивируя их что-то делать ещё пока ЧПУ выполняет свои операции.
  • Цифровая трансформация завода (ч. 3): волшебные интерфейсы и оживление железа
    0
    Кармы поставить плюс нет — извини, НО пишу здесь, потому что не могу не порадоваться за качественный и грамотный подход к самому процессу выявления и анализа проблем.

    Поездка за 150 км к пользователю вообще считаю героизмом, поскольку на своих рабочих местах подчиненных за 500м. палкой выгонять надо сходить, особенно теперь — короновирус же :)
  • 6 способов значительно ускорить pandas с помощью пары строк кода. Часть 2
    0
    Ситуация вообще интересная скалывается.
    Мне кажетя, что в pandas сами ищут способ как им ускориться и как им внутренне оптимизироваться и процесс в самом разгаре. Они либо породят рядом с DataFrame ещё и DataFrameParallel, либо вольют в себя, что-то, что максимально идентично им по идеологии.

    Но сперва свои, уже имеющиеся, типы доведут до 100% поддержки своими же методами и методы доведут до работы с этими типами при участии нескольких полей идентичных и разных типов.

    В целом, моя личная ситуация позволяет мне подождать, когда Pandas сделают всё внутри себя, но если за годик в пандах ничего не изменится, то идти в Modin.
  • Выбираем самый удобный редактор кода Python
    0
    Spyder без анаконды.
  • Что не так с Хабром
    0
    Странно, что никто не комментирует не того, о чем статья, НО — не менее важного в статье

    Но нам с вами бабосики платят не за код, а за решение проблем бизнеса


    Лично меня этот острый камень интересует куда больше, чем то, что твориться не только на Хабре, а во всем Рунете (да я полагаю во всём Инете).

    Тема разработок, которые напрямую не дают эффекта бизнесу, или вообще являются, на данном этапе, чистым убытком для бизнеса с «надеждой», что это выстрелит через N месяцев/лет — по факту является ключевой для ИТ в компаниях, которые не являются производителями ИТ продуктов.

    Но её везде усиленно обходят, в то время как именно понимание — за что платят программерам и является основой для инвест бюджетов ИТ подразделений.

    Вот эту тему — было бы куда интереснее пообсуждать.
  • СОРМ. Минпромторг. Они своими Законами создают технологический прорыв Микроэлектоники в России?
    0
    1. Не, не занижена.
    2. Я знаю пяток мест.


    Intel отложил переход на 7 нм из-за высокой цены и большого брака при производстве и будет передавать производство в TSMC.
    AMD делает свои там-же, потому что другие, с кем они работают делают только 12 нм.

    А Вы знаете 5-ок мест?

    Мы всю дорогу говорим о разработке под производство на Тайване


    Для России это не выход из ситуации. Читайте мой пост в этой ветке
  • СОРМ. Минпромторг. Они своими Законами создают технологический прорыв Микроэлектоники в России?
    0
    Я вроде процитировал часть поста, которую комментирую.

    Разработка чипа по нормам 5-7 нм за 20-300 млн. да хоть фунтов стерлингов — это для отрасли копейки, НО
    1. я не верю в эту сумму, она сильно занижена
    2. неизвестно, кто в России способен, без импорта лицензий и оборудования разработать такой чип — и тут вопрос даже не во времени, а в принципе!
    3. если вдруг в России есть структура способная на это, то на самостоятельную разработку (без производства, а только с подготовкой к нему) уйдет N лет, за которые лидеры уйдут ещё дальше — и вот это критично даже с наличием лицензий и оборудования, которое никто России не поставит ни при каких обстоятельствах в настоящее время.
  • СОРМ. Минпромторг. Они своими Законами создают технологический прорыв Микроэлектоники в России?
    0
    Разработка процессора по нормам 5-7 нм встанет вам в 200-300 миллионов.

    По меркам отрасли — это копейки, и даже не важно в какой валюте.
    Наиболее проблемный вопрос в данном случае, ИМХО — время разработки.
  • Судьбы героев
    +3
    Кризисные периоды и наступают именно тогда и именно потому, что всё встает на отработанные, созданные другими (читай героями) рельсы и катится, пока ситуация вокруг не изменится. А поскольку она меняется всё время, то катятся считайте всё время вниз — до следующего героя.
  • Судьбы героев
    +2
    Герои со всех сторон положительные, превозмогают, совершают подвиг.


    Вот абзац в тексте, который многое ставит на свои места

    Или по-другому. Неуправляемые. Нарушающие все мыслимые и немыслимые правила. Не укладывающиеся в сроки. Требующие к себе особого отношения. Выскочки. Непонятные, пугающие, выводящие из себя.


    Да, и — да. К сожалению — обратная сторона медали всегда есть и в данном случае она не меньше геройства, а иногда даже больше. Иногда она выбешивает даже тех, кто прикрывает героев. Но цена вопроса — либо тебя затащат на гору, либо будут многие и много говорить о том, что это невозможно сделать.
  • Судьбы героев
    –4
    Жизненный материал — российский вывод. К сожалению, всё больше героев стали смотреть не в сторону России, именно из-за последнего абзаца, а не из-за врагов вокруг. Врагов они не замечают, а вот решения руководства, как следствие выводов — сказываются сразу.
  • СОРМ. Минпромторг. Они своими Законами создают технологический прорыв Микроэлектоники в России?
    +1
    Проблема в том, что мы ставим приоритетом «пользователя», а государство ставит приоритетом отрасль. Если микроэлектронику не вывести на гражданский рынок, она тихо умрет, потому что военка прокормит только часть — она собственно и умирает по этой причине.

    Выход на международный гражданский рынок без прохождения детских болезней и освоения своего рынка с выходом на доминирование на нём — невозможен.

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

    Да — мы все будем не рады, и нам всем будет капец как больно смотреть на то, что будут предлагать, НО — либо у нас появится свой тяжелый, конкурентный софт, а без своего железа, нам его не сделать — ограничат на взлете, либо мы уйдем в безвозвратное ИТ рабство, и ни какие прибыли не покроют покупку лицензий в нужном количестве и техподдержку…
  • Сравниваем работу open source Python — библиотек для распознавания именованных сущностей
    0
    >а вот для правильной работы с дефисами, тире и точками нейронку можно сделать (и делают).

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

    >Возможно, вы не сталкивались с данным режимом, но он намного более типичен, чем ваш режим.

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

    Мой результат получен вообще без нейросети, он на ML и алгоритмах, и ИИ я пока даже не хочу прикручивать, потому что, на мой взгляд, надо сперва какую то доп. разметку сделать более расширенную и более качественную, потом новую качественную частотность получить, потом ещё прогон переразметки сделать — а вот уже потом, тренировками заниматься.

    Я совсем недавно сталкивался с прототипом промышленного (для промышленных предприятий) решения, которое обучалось на малом объеме данных, а остальные были получены синтетическим путем. Видел результат, видел прогноз от машины по результатам — это всё очень печально и по моему просто трата времени, хайп какой-то.

    >Так это вы маленькую нейронку по сути и сделали. В нейросети ровно та же статистика и накапливается.

    Только ресурсов для обучения требует больше и постоянного пересмотра модели с учетом накопления данных — разница получается более, чем заметной, а вот результат, не очевиден

    >отдельные лишние слова ( 00 копеек, власть москвы ), или вот выделили «8-800»

    Для nrlpk это как раз и есть СУТЬ того, для чего он создан.

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

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

    Там не 8-800, а 8-000 — это по тексту было 8 000 — разорванное числовое значение, которое nrlpk соединил в цельное выражение классифицировав его как NUSR (числовое выражение), а каждый его элемент в отдельности классифицировал как — NUMR (число). Смотрите детальные данные на github там все подробности как на ладони.

    >Это просто вопрос терминологии. Если у вас N-gram LM, то для вас это статистика, а вот если опираетесь на knowledge base, то это уже можно называть знанием.

    назвать можно, но знанием оно от этого не становится. Мы же понимаем, что один N-gramm алгоритм не решает ни одной задачи NLP.
  • Сравниваем работу open source Python — библиотек для распознавания именованных сущностей
    0
    Я имею представление, как они работают.
    У меня вопрос был в другом. Зачем их применять вот прямо везде, где ни попадя?

    Если уже есть качественная разметка по NER — зачем мне нейросеть учить, когда можно после токенизаци просто состыковать слова в лоб + биграммы + n-граммы и выбрать с наилучшим результатом. По ресурсам это кратно быстрее и кратно менее затратно. В чем глубина замысла?

    С «мерой», это моя орфо ошибка — по тексту если посмотрите выше, там МЭР — отсюда и был вопрос как ИИ различит «мэра города Сергея Собянина» — читай ФИО и «главу поселка Максима Горького» — читай ГЕО.

    И Вы можете дать пример токенизации, которая работает на ИИ? Т.е. не алгоритмами и условиями токенизацию делают по предложениям и словам, а именно через обученную нейронку (под капотом)?

    И, если у Вас для NER задачи, качественная разметка будет только на трейне, то Ваш трейн должен быть по размерам и охвату сопоставим со всем будущим продакшином, иначе вы рискуете получать результат с вероятностями ниже приемлемых и будете вынуждены его брать в работу, за неимением иного. Смотрите мой пример выше в этом комменте.
    Когда речь идет просто о сопоставлении или предсказании последовательности — это одна задача и да, зависимости он определяет гораздо лучше любого алгоритма и уж точно лучше человека, НО — когда речь идет о точных понятиях, тут всё куда сложнее.

    Вы результаты выше в статье видите — они Вам нравятся? Лично мне — нет, кроме PullEnti

    И — ИИ не знает, что у города нет меры, просто статистика их совпадений ниже других вариантов, что по факту, для определенных контекстов может стать ошибкой.
  • Распознавание дат, написанных естественным языком, средствами Python3
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    В статье «Сравниваем работу open source Python — библиотек для распознавания именованных сущностей» присутствовал тестовый текст на русском языке. Вот он:

    Власти Москвы выделили 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. Текст интересный и с адресами, и с ФИО, и с ошибками в тексте — и результат не менее интересный получился.
  • 6 способов значительно ускорить pandas с помощью пары строк кода. Часть 2
    0
    Большое спасибо! Главное — очень вовремя, ну лично для меня, получилось.
  • Сравниваем работу open source Python — библиотек для распознавания именованных сущностей
    0
    Чисто из любопытства прогнал тестовый текст на русском из этой статьи через nrlpk. Результат:

    00 копеек
    01.05
    10.01.1970
    110 млрд
    8-000
    www.sobyanin.ru
    ак47
    алтуфьевское шоссе д 51
    ваз2107
    власть москвы
    втб24
    город санкт-петербург, ул крузенштерна, дом 5/1а
    иванов костантин петрович
    мпз
    мэра города сергея собянина
    подпоручик кижей
    рф

    Все детали на github
    Меня далеко не очень удовлетворило в результате и есть над чем подумать, НО…

    Меня мучают два вопроса, если автор статьи сможет их разъяснить, я был бы очень признателен:
    1. Для качественного результата в задаче NER, нужна предварительная качественная NER разметка. Причем, она должна быть не просто качественной, а ещё и обширной, иначе по многим объектам не будет идентификации, а по многим будут неоднозначности, или придется глубоко учитывать контекст, а это уже совсем другой уровень (или класс) задачи. К примеру плохая или отсутствующая разметка, как например в моем случае не сможет дать качественный ответ обоих случаях на «мера города Сергея Собянина» и «главы поселка максима Горького». В моем случае «мера города Сергея Собянина» идентифицировался как адрес. Но если уже будет качественная NER разметка, то зачем нужен ИИ для решения именно NER задачи?
    2. Качество токенизации сложных текстов напрямую зависит от того насколько используются предварительно выделенные, размеченные и идентифицированные сущности и формы сокращений в них. При отсутствии такой информации, токенизация по предложениям. А дальше по словам пойдет некорректно, и как следствие в той же задаче NER появятся неверные (а точнее будет отсутствовать верные) значения. И здесь снова тот же вопрос — где здесь место ИИ?
  • 6 способов значительно ускорить pandas с помощью пары строк кода. Часть 1
    0
    Буду ждать сказа о Modin — хочу присмотреться к нему, как альтернативе параллельности для pandas в принципе. Смотрю он активно поддерживается и заявленное покрытие функциональности панд — в среднем 80%, кроме read.
  • 6 способов значительно ускорить pandas с помощью пары строк кода. Часть 1
    0
    В какой то момент я перевел всю задачу в Pandas на параллельность — все тяжелые, как мне казалось, места. Да — получил ускорение, где-то даже больше ожидаемого, НО отлаживаться стало гораздо, горяздо тяжелее.

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

    По поводу же apply, есть такая статья How to simply make an operation on pandas DataFrame faster, которая дает больше альтернативных вариантов по замене apply, чем данная статья, при этом и сам прямой numpy дает очень хорошие показатели.
  • СКУД: проблемы, решения и управление рисками безопасности
    0
    Близкое расстояние — сколько это?

    Я не просто так задаю эти вопросы. Совсем недавно мы обсуждали вопросы СКУДа с двумя компаниями и в том числе вопросы идентификации пол лицу. По их заверениям, камеры, которые способны обеспечить гарантированное распознавание на уровне не ниже 0,95 стоят больше 100 т.р.

    Более того, в декабре 2019 я был на конференции по цифровизации, где выступала команда, отрабатывавшая распознавание и сортировку алмазов с помощью ИИ и соответственно камер. Для того. чтобы обеспечить всё тот-же уровень достоверности — 0,95 — 0,97 они были вынуждены поставить под разными углами около 20 камер и все эти камеры были высокого разрешения.
    Камеры переставляли местами несколько раз и меняли их марку — связано это было с разным уровнем освещения и непредсказуемым углом расположения идентифицируемого объекта.

    Сейчас Вы говорите, что есть практический опыт, когда ОДНА камера в 2 Мп, установленная под нужным углом, способна не только нивелировать эффект разной освещенности и разного угла подхода человека или поворота головы (я не говорю уже о свежих травмах на лице, дополнительных аксессуарах — типа очков), но и провести сверку лица по одному фото в базе с точностью на уровне 0,9.

    А можно название предприятия где это работает? и контакт, с кем можно пообщаться более детально в самой компании, где это реализовано именно с такими камерами?
  • СКУД: проблемы, решения и управление рисками безопасности
    0
    Камеры подходят любые IP 2 Мп.

    Распознавание лиц под разным углом с разным уровнем освещения камера 2 Мп??? И как её надо установить относительно наилучшей точки сканирования на траектории прохода сотрудника, чтобы она могла провести идентификацию с точностью хотя бы 0,9?
  • Альтернативное понимание контекста с помощью статистической языковой модели
    0
    ведь это — просто токенизатор, неоднозначности в таком виде он снимать не умеет.

    Предложенный вами вариант будет интерпретирован как аббревиатура.

    Токенизатор это только часть функционала библиотеки, основной функционал это — языковая модель.


    Мой вопрос как раз и касался того, что токенизатор дал однозначный ответ в неоднозначной ситуации ещё до того, как модель была проанализирована. Вот эта неоднозначность: "На рис. 1 изображена ваза".

    Токенизатор принял однозначное решение, что это — одно предложение.

    Именно это меня заинтересовало в первую очередь, отсюда и возник вопрос, каков универсальный алгоритм принятия решения токенизатором в подобной ситуации. Для большей наглядности я дал чуть другой пример: "Смотри на этот рис. 4 месяц 1912 года стал трагедией для Титаника".

    Принятие решения токенизатором о том, что это одно предложение — уже будет неверным.
    В этом был мой вопрос.

    После Вашего пояснения (я полностью с ним согласен и у себя в токенизаторе применяю почти такой же подход) о том, что при обработке и анализе важно учитывать, а не обнулять знаки препинания, ситуация с такой работой токенизатора будет «вводить в заблуждение» дальнейший алгоритм анализа текста.

    Ну, я во всяком случае, получаю на своих тестах, именно такой результат. И мои тесты показывают, что словарь сокращений — путь назад от автоматизации.

    Поскольку моё видение и тесты не есть истина в последней инстанции, мне и стала интересна Ваша логика для токенизатора. Кстати, по статистике — пояснительные сокращения после цифр в тексте появляются в десятки процентов раз больше, чем до.
  • Альтернативное понимание контекста с помощью статистической языковой модели
    0
    Юрий — Вас подтолкнули на очень неоднозначный пример, но поскольку он решился именно с таким результатом, мне стала интересна логика принятия решения.

    Если чуть подробнее, то в строке: "На рис. 1 изображена ваза, см. наш каталог." кроется двойная неоднозначность при токенизации и разборе:
    1. токенизация: давайте попробуем другую фразу, скажем в «Смотри на этот рис. 4 месяц 1912 года стал трагедией для Титаника.». Здесь «рис» — это конец предложения, даже будучи сокращением слова рисунок.
    2. анализ текста: при попытке лемматизации Вашего предложения или переделанного мной, на «рис.» мы получим минимум два значения — сокращение от рисунок и «рис» — как растение. При этом, контекст многих предложений не даст однозначного ответа, какое из двух слов имелось ввиду.

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

    Заранее благодарен за ответ.
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    Хотел бы обратить внимание на позиции слов в предложении и в двуграммах, например по этим позициям
    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), в которых слова переставленные местами относительно оригинального текста.
    По факту, здесь был бы к месту словарь двуграмм, однако я не смог найти хороших (качественных) и больших словарей двуграмм на русском — чему я был сильно удивлен.
  • Билирубин — молекула, ответственная за желтуху
    0
    Физические нагрузки повышают уровень билирубина. В здоровом организме, при общем фоне изменения обмена веществ во время и сразу после физических нагрузок — это не ощущается. Для людей с повышенным уровнем билирубина, физические нагрузки могут дать значительный и быстрый рост, который сам «уходит» крайне медленно.

    К уровню физических нагрузок в единицу времени человеку с повышенным уровнем билирубина надо привыкать опытным путем, другого пути, к сожалению, пока — нет.

    Для Lifext — предсказательная аналитика дня, времени и объёма физических упражнений из графика физ. нагрузок больного может стать очень интересным и востребованным направлением. Но конкуренция в среде медицинского AI в ближайшие лет 5-10 будет страшная.
  • Переход от монолитного Data Lake к распределённой Data Mesh
    0
    1. Даже если не натягивать предлагаемый подход на большие данные, всё равно не видно экономических преимуществ для компании от её внедрения — непонятно откуда возьмутся сокращение затрат на обработку данных или свободные серверные (продуктовые) ресурсы, если взять и просто трансформировать под новый подход существующие ресурсы — т.е. сохранить базу для сравнения.
    2. Проблемы в ресурсах у компаний связаны, по большей части, не с бардаком в данных, а с объемом свободных ресурсов под параллельную высоконагруженную обработку при проверке гипотез или отладке, не важно — просто статистики, предсказательной аналитики или AI. Бардак данных может устраняться поэтапно, с учетом имеющихся ресурсов, с сохранением результатов каждого этапа и началом следующего на закомиченных данных после предыдущего. А вот аналитику кусками не пустишь, на качество результата очень сильно влияет.
  • Билирубин — молекула, ответственная за желтуху
    0
    При Синдроме Жильбера нет необходимости в снижении уровня билирубина, поскольку его повышенный фон является нормой для организма, а вот попытки приведения его в норму ниже средней, могут негативно сказаться на здоровье человека.
  • Переход от монолитного Data Lake к распределённой Data Mesh
    0
    На протяжении всей статьи пытался увидеть среди плюсов технологии — увеличение производительности при использовании каждого продукта при трансформации существующих мощностей в новую архитектуру.
    Ну предположим, что за счет предподготовки части данных в каждом продукте мы получим какой-то выигрышь в производительности, НО — что нам делать с решением вот этой обозначенной проблемы:

    Потребности организаций в инновациях. Необходимость в быстрой проверке гипотез и частых экспериментах ведёт к большому количеству вариантов использования данных.


    К своему сожалению я не просто не увидел за счет чего вдруг у меня нарисуются свободные ресурсы для проверки гипотез НА БОЛЬШИХ ДАННЫХ. Более того, за счет дублирования и частого обновления данных между продуктами сама модель потребует на постоянной основе достаточно много ресурсов на самообслуживание целостности и оперативности данных.

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

    Те-же вопросы сейчас решаются интеграциями на уровне информационных систем или непосредственно БД и это обходится многократно дешевле, чем содержание кучи DevOps'ов к каждому из которых ещё команда бизнес предметников нужна.

    Это всё к вопросу о том, почему я ждал радикального высвобождения ресурсов. Для меня — если технология позволяет мне тратить на железо значительно меньше, чем я мог бы потратить за минусом зарплаты всех необходимых DevOps — то это верный путь.

    Если же мы говорим, что мы по всем направлениям получаем только рост затрат — системный рост затрат, потому что растет не только объем данных, но и бизнес, а выигрыш только в качестве данных и (очень сомнительном) сокращении объема технического долга, то надо искать другой путь трансформации централизованных систем.

    Может быть я что-то неверно понял в этой части?
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    Начну с результата – тест на самом сложном тексте, что у меня есть дал

    Всё как всегда на Github – тест одного и того же текста на старом алгоритме 4-1 и на новом 4-3.

    Для достижения однозначности по несловарным словам (с ошибками, с предлогами, через тире, через тире с ошибками и предлогами) только алгоритма Левенштейна оказалось недостаточно. Пришлось добавить дополнительную обработку по сходимости.

    Левенштейн + дополнительный алгоритм сильно увеличили время обработки, но это оказалось на пользу. Сделано:
    + оптимизация по производительности;
    + параллельность;
    + рефакторинг.

    Из минусов:
    — время обработки разных текстов на одной и той же машине стало непредсказуемым из-за большого числа распараллеленных функций;
    — тестирование из-за параллельности усложнилось.

    В ходе доработок стал мечтать о том, чтобы в функциях объединения Pandas появились два дополнительных параметра max_workers и add_done_callback :)
  • Источник эффективности производственного предприятия
    0
    И ответственно могу сказать, что то, что они называют «планированием» таковым не является.

    Давайте попробуем вести обсуждение тем таким образом, чтобы объясняя предмет не унижать кого бы то ни было.

    И их «крупные ERP» лучше всего оправить «на свалку истории»… Т.к. внедрены и/или используются они так, что лучше об этом тихо молчать

    Можно я не буду вот это вообще комментировать…

    Еженощное перепланирование ВСЕГО производства и цепочки поставок.

    Еженошное — это не несколько раз в день, согласитесь. Ну и потом, сколько на КННАЗе изделий в одновременном запуске? И сколько там унифицированных ДСЕ? А они, напомните мне, не проектами ли каждый заказ запускают и планируют соответственно?

    Что касается перепланирования неск. раз/день… Примеров нет. Потому, что, для большинства, это делать не надо.

    Я не удивлен, просто непонятно зачем Вы это заявляли.
    А вот насчет «для большинства это и не надо» — Вы не правы.

    На предприятиях никто бы и не обсуждал никаких сокращений сроков перепланирования, MESS планирование до смен и т.д., если бы это всё было не надо.

    Для такого перепланирования есть два фактора
    1 — очевидный: всё, что не сделано в первую смену из положенного, перетекает на вторую, следовательно для второй нужен пересчет, следовательно пересчет нужен и для третьей (ночной или утренней). А ведь есть ещё компании, у которых каровая логистика просчитывается по межцеховой и межпроизводсвтенной транспортировке, которая напрямую зависит от выполненных планов и обновленных планов
    2 — не столь очевидный, но присутствует на многих предприятиях, ВПК во всяком случае. В стране много крупных предприятий, которые в 90-е были вынуждены перейти к производству почти всего, что входит в их изделия — самостоятельно. Это привело к очень большой и сложной внутренней кооперации, которая, неизбежно, повлекла специализацию производств по номенклатуре и изделиям. Так внутри предприятий образовались выпускающие производства и специальные. Последние делают универсальную и унифицированную номенклатуру, а следовательно являются самой больной точкой перепланирования. Если в этих производствах происходит недовыполнение плана, то вся кооперация требует пересчета. При дву и трехсменной работе, пересчеты нужны до смен и отчет по выполнению до смен.

    А теперь вернемся к вопросу повышения затрат. На сегодня, даже при двусменных работах никто уже не выводит кладовщиц, плановиков и распредов на вечерние и ночные смены. Все материалы стараются выдать в конце предыдущей смены на оставшиеся смены текущего дня, а данные о выполнении планов заводятся дискретно — раз в день, а во многих местах и того реже — часто просто на переходах любых, кое где — по сдаче выдаче со склада на склад ДСЕ (есть такие способы автоматизации, что НЗП ведется учетом только по факту перемещения по складам ДСЕ, а не по пооперационному перемещению). Так вот для пересчета хотя бы 2 раза в день, затраты предприятия значительно вырастают, потому что надо нанимать НА ПОСТОЯННУЮ РАБОТУ новых людей и платить им всегда заработную плату (оклады у этих категорий служащих) и кладовщикам, и плановикам и распредам и ИТ специалистам, которым придется работать в несколько смен.

    Более того, Вы сразу влетаете в немного другой уровень железа, потому что если скажем на раскрутку всех планов до позаказного сейчас предприятия могут позволить себе тратить от 8-ми до 13-ти часов, то при таком расчете время схлопытвается максимум до 5-6 часов на весь пересчет и это при условии, что все данные по выполнению, вот эти вот перечисленные выше сотрудники во всех производствах и цехах успеют завести максимум за 1 час.

    И это тоже деньги, и кстати очень немалые деньги с учетом двух резервов (горячего и холодного для полного восстановления).
  • Источник эффективности производственного предприятия
    0
    По первому абзацу — работаем с очень крупной западной ERP и эффект обратный Вами заявленному.
    В 2019-м был на шести крупных предприятиях ВПК страны, где тоже очень крупные ERP — это и предприятия холдинга Антея, и ТРВ, и Росатома. Так вот везде — увеличение частоты перепланирования приводит к значительному росту затрат.
    Где именно подтверждено практикой — я бы очень хотел посетить такое предприятие, если оно производственное и работающее с ГОЗом.

    По второму абзацу — можно тоже пример предприятия в России, где в крупной ERP с числом заказов в перепланировании в десятки тысяч и в маршруте не менее, ну хотя бы 3-х подразделений в заказе, перепланирование осуществляется по несколько раз в день?
  • Источник эффективности производственного предприятия
    +1
    Было бы очень интересно увидеть не только показатели улучшения времени при более частом перепланировании и актуализации данных о выполнении по производству, но и параллельного роста затрат на обеспечение этой оперативности.

    На Ваших графиках очень бы хорошо смотрелась ещё одна линия — временные затраты на поддержание процесса.

    Практика показывает, что у такого подхода к «повышению эффективности производства» есть тёмная сторона — затраты, которые при применении скажем еженедельного перепланирования резко возрастают и в стоимостном выражении, и по времени.

    Причины просты — чем чаще план и отчет, тем больше нужно привлечь людей, которые не осуществляют производственной деятельности (диспетчеров, кладовщиков, распредов, плановиков, экономистов, специалистов ОТК, ИТшников и т.д.) — т.е. не создают прибыли.

    Это — при идеальных условиях. А при наличии проблем в планировании (появление нового заказа с более высоким приоритетом при свободной НЗП и мат. запасах) порождает ещё и большой слой совещаний и переписки с привлечением уже ТОПов (час работы которых может быть весьма не дешев при отнесении этих затрат на конкретные заказы).
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    Сокращаю число нераспознанных слов:
    + Левенштейн — решен
    + несловарные приставки — решен
    + слова через дефис — обработка в процессе
    + Левенштейн и несловарные приставки для слов через дефисы — решен
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    Решение вопроса с аббревиатурами ключевых слов и выражений потребовало больше изменений, чем я изначально предполагал, но это пошло только на пользу.

    Ниже обновленные ключи к этой статье, полученные доработанным алгоритмом, по тем же правилам (не признавать ключами выражений с числовыми данными, признавать ключами слова, повторяющиеся по тексту не менее 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 – список обозначений маркеров, если пусто то маркировать все.
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    >Я признаюсь, nrlpk на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
    Это точно.

    Ну так может быть Вам просто перестать что-то обсуждать с таким бестолковым парнем как я, тем более когда Вы решаете такие задачи всего за один день. И я конечно не дождусь от Вас реализации за один день? Впрочем, мы оба знаем ответ на этот вопрос…

    А почему бы и не пообсуждать, если это для дела полезно?

    Вам лучше поискать для подобных бесед собеседника соответствующего Вашим знаниям.

    Ну так я вам конструктивную критику для этого и даю, чтобы вы исправились.

    Сижу… Ищу конструктивную критику. Диву просто даюсь на конструктив, то проценты какие то из головы берете, а не из моей статьи, то вот это например

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

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

    То есть, вы не можете решить задачу с низким качеством за день, а мне подменили понятия и хотите чтобы я за день решил задачу с высоким качеством. А я говорил о том, что с вашим качеством я решаю такую задачу за день

    :))) Прощайте.
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    А теперь представьте, что есть возможность выбрать слова или последовательности слов из текста в качестве ключевых, и кроме этого есть возможность выбрать из миллиона понятий, например, отобранных через аналог алгоритма 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 на данном этапе по качеству работы с текстами не имеет шансов сравниваться с алгоритмами Гугла, хоть и писал я его далеко не один день — тут мне и до Вас слишком далеко.
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    Я пропущу первую, эмоциональную и не конструктивную часть Вашего комментария, и отвечу только на то, что имеет смысл обсуждать.

    Я утверждаю, что бизнесу намного чаще нужна другая задача, не 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 слов стоящих рядом, можно гарантированно выбрать аббревиатуру, которая может существовать где-то в тексте или заголовке?

    или теперь ещё один, новый — и что есть примеры получения качественных алгоритмов полученных на грязных отладочных и тестовых данных?
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    — «необходимо брать слова их статьи» (тогда почему у вас есть сокращения — это же не слова из статьи?),


    Сокращения — это приведенные слова из статьи. Среди сокращений нет ни одного, которое бы было построено не из слов из статьи. Причем не просто из слов, любых выбранных произвольным порядком, а отобранных по четким и понятным правилам.

    — «нельзя взвешивать заголовок выше чем статью, потому что вдруг заголовок будет неактуальным да и вообще непонятно почему» — ну так определяйте, похож ли заголовок на статью или это отвлечённый от темы статьи мем/каламбур для привлечения внимания, и стоит ли брать оттуда ключевые слова.


    Именно поэтому в вопросе приоритетности слов заголовка я и сказал, что надо хорошо взвесить. Определение «похож» ли заголовок, слишком простое, для выдачи ему приоритета, неважно — похож он или нет, но следуя Вашей логике — это уже заголовок становится зависим (похож) от текста — и вся логика, изложенная Вами ранее

    (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»


    По пунктам, так сказать:
    1. «ключевые слова» — русский и есть по тексту
    2. «выделение ключевых слов» — русский и их нет по тексу
    3. «keyword extraction» — иностранные и их нет в тексте
    4. «keywords» — иностранное и его нет в тексте


    Из 4-х слов, 2 иностранные (т.е. 50%) и их в принципе нет в тексте статьи. Почему Вы предложили именно такие ключи, я понимаю, но — я не просто так написал Вам

    правда, как выйти на такие ключи в русском тексте, остается за кадром.


    Я дополню свои предыдущие слова — не просто за кадром, а только подменой через синонимы и частотность тегов исключительно для определенной платформы. ИМХО, это уже теория на грани подгона, под нужный результат, ИМХО.

    Чего????????? Это максимум минуту занимает.


    Правда? А у меня даже простой выбор Хабов к этой статье занял больше 5 минут.
    А по ключам, да ещё применительно к хабру, я бы застрял очень надолго.

    Обращаю внимание, я в этой области хоть что-то понимаю. А 90% пользователей в этом всём просто «прохожие» — но это именно та аудитория, которая составляет в соц. сетях, СМИ и вообще Интернет активное большинство. Т.е. целевая аудитория — не мы с Вами.

    Зачем???????? Если статья пишется 2 часа, то 5% времени — это 6 минут!

    1. Хорошая статья, к сожалению, за два часа не пишется.
    2. Вы взяли для оценки не ту цифру. Сокращение может составить 20-35%, что даже от 2 часов составляет уже 24 — 42 минуты.


    Ну и может не генерировать все возможные ключи, а предложить сразу оптимальные, а человек пусть потом добавляет или убирает, что хочет?


    Я к этому и стремлюсь.

    То есть, вы не знаете, что такое тестовый сет в машинном обучении? (И сколько должно быть в нём данных, чтобы получать более-менее объективные результаты?)


    Чтобы нам не удариться в бесполезную дискуссию кто лучше/хуже что знает и т.д., на данный вопрос мне проще ответить — НЕТ.
  • Задача: извлечь ключевые выражения из текста на русском языке. NLP на Python
    0
    Начну ответ с конца Вашего поста, поскольку вижу, что наша логика по поиску ключевых слов очень различается, поэтому я попытаюсь объяснить свою через примеры и аргументы.

    (a) ключевые слова, которые обозначают тему статьи


    На примере этой статьи. Если бы я писал статью про NLP — то по телу статьи я просто неизбежно бы употреблял аббревиатуру NLP, НО — статья про инструмент, который работает в классе NLP, и NLP здесь не ключевой момент, поэтому в теле статьи это слово не употребляется ни разу.

    Все остальные слова заголовка вошли в ключи.

    НО, насколько я понимаю, Ваш вопрос имеет немного иной смысл. Вы хотите, чтобы формирование ключей отталкивалось от заголовка, как приоритета в подборе ключей?

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

    Однако я соглашусь с Вами, что заголовок статьи, если он есть, также должен попадать под анализ через инструмент и его выражения также должны участвовать в ключах, и да — вероятно, что они должны получить статус приоритета в ключах — последний вывод надо хорошенько взвесить!

    (b) ключевые слова, которые потом будут с наибольшей вероятности использоваться при поиске. Если ваша статья про извлечение ключевых слов, то в ключевых словах должно быть «ключевые слова», «выделение ключевых слов», «keyword extraction», «keywords»


    Вы абсолютно верно говорите о том, что должно бы получиться в итоге, рассуждая как специалист, много и глубоко работающий с Интернет. НО — давайте уйдём от логики человека, специалиста и включим логику машины. Логика машины звучит так:
    1. я могу выбрать любые сущности из текста, если они есть в тексте
    2. для такого выбора мне нужны заданные алгоритмы отбора.

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

    Суть моего продукта — немного о другом, на самом деле. Мой продукт — это первые два пункта машинной логики и один главный пункт логики человека. Главный пункт логики человека, который пишет статью:
    1. статьей я хочу донести суть того, о чем в ней и пишу.

    Человек, при написании статьи не обязан заботиться о том, какие у него в итоге из неё получаться ключи.

    Смотрите, что я пытаюсь решить. Как это сейчас, скажем на Хабре:
    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?