Pull to refresh
58
0
Viacheslav Kovalevskyi @b0noII

Google Cloud / DeepLearning

Send message
Спасибо, чтиво прошло мимо меня =( скачал.
Вторая часть уже вышла ;)
исправил, благодарю Вас.
Спасибо, не знал что у этой магической цифры есть и научное обоснование.
Честно говоря квантовая получается только работу, когда работаешь в таком режиме то очень устаешь и не отдыхе я просто отключаюсь (бегаю, гуляю, сплю, лентяйничаю) и не контролирую время. Но если у Вас выйдет и отдых «резать» напишите как Вы этого достигли.
Спасибо большое. Я как то и не подумал что есть и другие игроки на этом рынке.
Посмотрим, очень может быть что в первых релизах — окажутся (просто уверен в этом)
Вы абсолютно правы в отношении проблемы текущего словаря. Именно по этому мы ввели 2 определения: слово и семантическое слово.

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


После того как будет закончен семантический модуль мы сможем проводить семантический анализ каждого слова что даст возможность разбить обычное слово на семантические слова. Именно на этом этапе можно будет отделить «путы» от «пути», «путей», «путь». Так что уже в Alpha4 мы планируем поддерживать этот функционал.
Вы правы по поводу необходимости получения модели морфологии вначале. При подсчете качества мы именно так и делаем, не уверен почему в консольном клиенте морфология опускается и сразу строится словарь. Добавлю это в issue для CLI. Думаю основная проблема что у нас пока еще нету стандартного Pipeline модуля для работы с AIF так что на вход одного компонента можно подать выход другого минуя некоторые важные ступени.
Добрый день. После создания семантического модуля мы планируем сделать на его базе Cloud REST Service по анализу текстов. С его помощью любой желающий сможет построить семантическую сеть текста, вычленить главные объекты и посмотреть на связи.

Далее мы попробуем сделать UI который бы показывал все эти данные. Это поможет начать использование технологии конечными пользователями. Сам я использовал первую версию для обработки новостей. Намного проще глянуть на граф связей главных объектов новости и перечень фактов на базе которых новость построена чем перечитывать саму новость. Это существенно повысило мой КПД при работ с навозными потоками.

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

Все выше сказанное уже так или иначе было реализовано в рамках подготовки кандидатской, сейчас лишь переделываем это в человеческом виде и на Java 8. Но есть еще кое что, что возможно потенциально, но не было реализовано практически — создание на базе данной технологии чатом-бота. Но о том как это возможно и наших планах в двух словах не рассказать)
Sound really interesting!

Have small question:
if you have next tokens in text:
cat
cats
cat.

How you will separate 's' and '.'. Both of this characters could be in the end of different tokens?

Also, maybe you have interest and time to help in this project?
Именно потому что программы перевода используют этот подход они столь плохо переводят человеческие тексты где вполне могут использоваться термины не внесенные в банк знаний языково модели. Наша библиотека и остальные решаем разные задачи. Мы пытаемся построить разные связи в тексте и на их основе обработать текст, что позволяет работать намного лучше в условиях когда текст на входе не литературно идеальный. Попробуйте скормить OpenNLP библиотеке на вход дамп из чата игроков eve Online. Собственно изначально прототип прошлой версии решал задачу обработки чата где общались носители Украинского и Русского языков и при этом использовали «суржик».

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

Делать еще одну систему которая изначально ставит себя в те же рамки качества не хотелось, и мы пытаемся разработать новый подход к решению данной задачи. Что получится точно можно будет сказать когда выпустим первый релиз.
Очень корректное замечание. Мы пока что не планируем поддерживать группу языков к которой относится упомянутый Вами тайский. Не по тому что там алгоритм не будет работать, а потому что текущая имплементация пока не может причинить алгоритм к этим языкам. Поддержка подобных языков будет включена в план после выхода первой релизной версии AIF, так что не очень скоро =(
Но и это прекрасно решается если 90% текста все жа разделены запятыми;) Хотя в данной версии мы этого не делаем
В добавок к предыдущему комментарию — да Вы верно запускаете команду. Просто сообщение (текст) очень маленькое что бы его хватило выучить язык на котором оно написано.
Спасибо, глянул, к сожалению текст оказался достаточно мал для корректной работы программы. Для теста скачал книгу на Украинском: vk.com/doc29866988_335722041?hash=00089797d7cd249b90&dl=e4d4a5250e944d2db5

команда:

java -jar ./aif-cli-1.1-jar-with-dependencies.jar -ess ./text_ukr2.txt


результат работы команды
log4j:WARN No appenders could be found for logger (com.aif.language.token.TokenSplitter).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Group: 'GROUP_2', characters: [; ,]
Group: 'GROUP_1', characters: [!: .]


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


Книги на Гутенбрге уже распознаны так что распознать их заново с другими настройками нельзя. А проблему я похоже обозначил не совсем корректно. Например в книге были распознаны кавычки вот так ” а не так ". В свое время мне пришлось писать скрипт который отображал книгу на символы с которыми могла работать NLP библиотека. Упомянутые OpenNLP и StanfordNLP из коробки не работали. А маппинг получилось сделать только написав в ручную скрипт.

Модель — это любая система, которая каким-то образом отражает реальную исследуемую систему. Математическая модель — это, грубо говоря, некоторая параметрическая функция, формула. Эта формула может быть простой и топорной, как линейная регрессия, а может быть и невероятно гибкой и сложной, как полный байесовский классификатор. Но она всегда есть, вы в том числе сами про неё упоминаете. Если вы собираетесь с этим где-то защищаться, то ни в коем случае не говорите, что у вас нет модели. Вместо этого опишите свою формулу, её параметры и алгоритмы функционирования (обучения, применения, оценки, etc.).


Вы правы, конечно же модель есть. Хотя языковой модели (в значении в котором употребляют ее в НЛП) нету. Собственно из-за того что в статье не обозначены четко термины и появилась эта путаница. В следующий раз подойдем к терминам более основательно.

Вы всё равно рассчитываете на какой-то класс языков, а не на все возможные. В некоторых языках нет разделителя между словами (хороший пример — немецкий с его слитными прилагательными), в других — практически всё зависит от контекста (китайский, например), в третьих вообще нет письменности. И главное, чем более общими будут ваши модели, тем медленнее и менее точно они будут работать. Как уже сказали ниже, there's no free lunch.


Да, у AIF есть множество ограничений и условий которые накладываются на входящий тексте. Постараемся их максимально формализовать;
Благодарю за столь емкий, а главное дельный комментарий.

Определение языковой модели было правильное: это P(words) и ничего более — даешь на вход набор токенов, получаешь его вероятность в данном языке. А вот дальше какая-то каша начинается. Перевод с помощью одних только языковых моделей не сделаешь (языковые модели там используются, чтобы выбирать более-менее человеческие предложения); не встречал, чтобы для задач NER или анализа тональности как-то языковые модели применялись, да и для токенизации тоже. Неправильно все статистические методы «языковой моделью» называть.


Вы правы по поводу того, что я был очень не осторожен в использовании термина «Языковая модель» и дилетантски расширил его за пределы того, что он обозначает на самом деле. Это связанно с тем, что для многих задач библиотеки типа OpenNLP используют то, что они называют models и эти модели есть для разных языков. Однако этим модели включают в себя намного больше, чем каноническое определение языковой модели.

Например OpenNLP модель Английского текста, которая используется для разбивки текста на предложения, включает в себя набор шаблонов предложений и их статистику (по поводу второго уже не помню, давно не заглядывал под «капот» их моделек). Под шаблонами они понимают регулярные выражения, создаваемые из размеченных корпусов. Процесс простой, но для вменяемого качества модели языка требует ОЧЕНЬ большого размера корпуса для обучения и при этом все равно завязан на конкретный язык и конкретные символы, используемые в языке.

Вы, по сути, решаете другую задачу — не задачу разбиения текста на предложения, а задачу нахождения символов, которые могут использоваться для разбиения текста на предложения в данном наборе текстов. Т.е. вы можете найти, что "¸" выполняет функцию точки, но не можете определить, является ли этот символ концом предложения в данном конкретном случае — например, «Бондаренко Н. В.» — первая точка — не разделитель, вторая — возможно, разделитель. Так? Все делилки текста на предложения решают именно эту задачу, а не вашу. Это не значит, что они плохие. Это также не значит, что то, что вы делаете — бессмысленно (иногда задача определения набора разделителей и правда может стоять). Но это другая задача. «Традиционная» задача сегментации выглядит сложнее и полезнее.


И вновь, вы правы. Мы рассматриваем разбитие текста на предложения в следующие этапы:
1. выделение символов, которые не используются для построения токенов (мы их называем техническими);
2. выделение из найденных символов группу символов, которые разбивают текст на предложения(.?!), и группу символов, которые разбивают само предложение на части(:;,);
3. определение в каких случаях первая группа символов используется для разделения текста на предложения, а в каких нет.

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

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

Есть методы языко-независимого построения делилок текста на предложения — см., например, Punkt; реализация в NLTK, например, доступна. Идея Punkt в том, чтоб по набору «сырых» текстов определить аббривеатуры / сокращения, характерные для языка, т.к. для большинства практических задач именно это является главной сложностью, а не то, что набор возможных разделителей неизвестен. Правда, не сказал бы, что работает очень уж хорошо.


С таким китом как NLTK само собой сравним, но для начала пилим сравнение с Java библиотеками и после, само собой, пойдем и к NLTK. Тем более я с большим трепетом отношусь к Python'у =) По поводу ссылки и Punkt; огромное спасибо, так как я данную статью не видел и не читал.

Так не бывает. Если не задавать никаких ограничений на набор допустимых решений, то получится мусор. См. No Free Lunch. Кроме самого сообщения нужно еще какое-то множество предположений о структуре этого сообщения, набор каких-то ограничений. Всегдя лучше, когда эти ограничения прописаны явно.


И вновь правы на все 100. Любой подход и формула, которую мы используем, имеет в себе заложенные нами ограничения на входящее сообщение и их действительно нужно указать явно. Ну, например, текущая версия AIF совершенно не работает в случае, если в языке совсем нету пробелов.

Дальше субъективно, обратная связь, как AIF2 выглядит со стороны. Сразу скажу — я не знаю, соответствует ли впечатление тому, что на самом деле. Но все же. Звучит «понимание» больно уж рекламно, причем рекламность рассчитана на людей, не имеющих знаний в области NLP. Библиотека, как я понял, пока умеет только находить возможные разделители слов и предложений для данного набора текстов по какому-то неописанному алгоритму (совет — в документации и вики описывать алгоритмы, а не детали установки java-пакетов). Что в некоторых синтетических специально подобранных примерах позволяет разбить текст на предложения лучше, чем это делают существующие делилки текста на предложения. Авторы используют термин «языковая модель» странным образом и не ссылаются на существующие unsupervised алгоритмы разбиения текста на предложения (обычно это знак того, что о них и не знают). Куча громких слов про семантику и понимание текста, про то, как все сейчас плохо, но никаких результатов, одни намерения. Ну и вербовка под все это дело новичков в NLP (которые под сомнение подходы ставить не будут?). Еще раз повторюсь — я без понятия, так ли все это на самом деле; код я не читал, в деталях не разбирался, но просто так это выглядит.


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

— более четко обозначить термины, которые мы используем и разделить каждый этап (например как разбитие текста на предложения) на под этапы;
— провести количественный анализ сравнивая, как минимум с одной альтернативной реализацией;
— описать уже существующую реализацию алгоритма на вики и перевод в статье;

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

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

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

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

Information

Rating
Does not participate
Location
Mountain View, California, США
Date of birth
Registered
Activity