Text Mining Framework (Java)

[mephistopheies]

а расскажите как вы делаете поиск персон в тексте?

[b0noII]

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

[zubasty]

Хорошо, что вы обрабатываете не немецкий язык!:)
Но проблемы будут и для русского. Ведь у нас с большой первой буквы пишутся почти все named entities, так что с таким методом (если я правильно вас понял) точность будет не очень. Если делаете поиск персон (да и вообще NER), лучше сразу обзавестись тестовым корпусом и отслеживать качество работы модуля.

[b0noII]

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

[andy722]

А как делается определение темы текста, не расскажете в двух словах?

[b0noII]

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

[ArtemZ]

Почему была выбрана именно джава? Она же известна как один самых медленных языков и глючных языков. соснули.рф/

[YUVladimir]

Смотря как готовить джаву — в банковской индустрии это стандарт де-факто, все работает быстро, а требования в банках жесткие, идет борьба за каждую микросекунду.
Да, кстати, почему глючная-то? :)

[b0noII]

К слову сказать изначально разработка была на Qt (C++) но именно из-за того что на С++ приходилось много времени уделять оптимизации ресурсов было решено перейти на более высокий язык где больше внимания можно уделить оптимизации именно алгоритмов.

[bald2b]

Из интереса скачал, скомпилировал. Сразу вопрос — зачем тесты запихали в src?
Ладно, написал запускалку

        Text text = new Text("book.txt"); // тестовый файл из комплекта
        List<Word> words = text.getWords();

И сразу тыща мульонов
model.NoContentException: Word Word(String word): word == null || word.length() < MINIMUM_WORD_LENGTH

При попытке распарсить другие тексты выходит
Exception in thread «main» java.lang.ArithmeticException: / by zero
at model.memory.short_time.Text.getConnectionLevelBetweenWords(Text.java:114)

При беглом просмотре кода обнаружилось что разработчики бсытро пчетатают: переменные с именами abstractionLeve, lengthDifferens, getSentansesCount, WordCompratorByWeight, SIMPL, getAbstractoinLevel
Есть и архитектурные непонятки — внезапно метод Word.equals меняет состояние объекта Word

Все очень сыро, еще пилить и пилить.

[b0noII]

Огромное спасибо, с Exception in thread «main» java.lang.ArithmeticException: / by zero сейчас разбираюсь как раз. model.NoContentException действительно часто падает когда нарывается на слово которое он не может (не должен) обработать

[b0noII]

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

[KilgortTraut]

То, что конструктору надо вскармливать тхт файлы — это не правильно. Раз он работает с текстом, то String. А вот логику перевода входящих данных в стринг надо вынести в отдельный модуль.

[b0noII]

Как раз планировал добавить более общий который принимает на вход BufferedReader

[spiff]

Если

// Получаем количество вхождений слова в текст
long count = word.getCount();

то почему

// Смотрим вес слова
double weight = text.getWordWeight(word);

а не

// Смотрим вес слова
double weight = word.getWeight();

Странный API, вот к чему я. Симметрии нет.

[b0noII]

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

[YUVladimir]

А чем не устроили широкоизвестные фреймворки по DataMining типа:

— WEKA
— Gate
— MinorThird

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

[b0noII]

Хочу на практике реализовать некоторые идеи которые у меня есть только в теории, пока. Т.е. это для меня не просто реализация библиотеки а получение данных для моей кандидатской. Более того, наличие других подобных FrameWork-ов дает возможность провести качественное сравнение после того как реализация моего TextMF достигнет финала

[YUVladimir]

Перечисленные библиотеки это что-то вроде Matlab, только для DataMining области.
Т.е. они содержать в себе много готовых реализаций из которых можно быстро собрать и попробовать любую идею.

[b0noII]

Мне как человеку который часто реализует разные идеи очень полезны указанные Вами WEAK/Gate/MinorThird, я сейчас как раз смотрю на Gate. Сам же использую Python NLTK для апробации идей на практике.

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

[zubasty]

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

[b0noII]

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

[kai]

А как у них с русским языком? Тот же Gate вроде с русским плохо дружит?

[YUVladimir]

Для русского есть разные плагины, типа:
code.google.com/p/mystem-morphtagger/
GATE plugin for morphological analysis of russian language

[Stas911]

Хотелось бы увидеть сравнение вашего ПО с аналогами — вы проводили такой анализ?

[b0noII]

Сравнение небольшое есть, но полноценное сравнение проведу после первого релиза и оформлю как новую отдельную статью.

[Sardar]

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

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

[b0noII]

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

[Sardar]

Solr это универсальный движок для хранения и поиска в индексе. Индекс — это набор термов + их аттрибуты + позиции в тексте и много что еще. И все это еще и не плохо расширяется. Перед запуском Solr собирается из отдельных плагинов/классов, этакий контейнер логики. Плагины преабразуют исходные данные, будь то текст, гео-позиции или что либо еще, в набор индексируемых термов и дополнительные данные. Поиск — это анализ запроса (схож с анализом исходного текста), выделение термов для поиска, собственно сам поиск документов по термам, пост-анализ результатов если нужен.

Вы реализуете любые ваши алгоритмы data mining'a кака плагин к solr. А вот грамотный и быстрый поиск raw terms при минимальных затратах к памяти — это уже задача solr. А так, вы сейчас пытаетесь решить две независимых задачи в одном продукте, фокусируясь на одном (mining) и забивая на другой (поиск, у вас он медленный).

[b0noII]

Я думаю мне нужно все это опробовать что бы корректно прокомментировать ситуацию. У меня одна из проблем эта метод определения равенства при поиске терма. Быть может Вы знаете, это можно кастомизировать в Solar? Спасибо

[Sardar]

У меня одна из проблем эта метод определения равенства при поиске терма.

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

Почитайте это. Затем гляньте в код/javadoc для каждого фильтра. Вы увидите, что никакой магии нет. К примеру solr.EdgeNGramFilterFactory для каждого входящего терма генерит все префиксы как новые термы («тест» => «т», «те», «тес», «тест»), что позоволяет искать по префиксу. Да, это работает быстро. Да, это не стоит использовать для строк, но, к примеру хорошо идет для поиска в деревьях.

[b0noII]

Спасибо, сейчас почитаю

[Setti]

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

[b0noII]

Если на уровне FrameWork-а то эта функция у TextMF уже работает и можно использовать для, практически любого языка, и русского в том числе. А если вопрос о UI то данная функция будет реализована в следующей версии. Так же если речь идет о UI то могу порекомендовать мою программу Web Private Detective. Она старая, написана на Qt и под Windows не самая актуальная версия. Зато умеет строить отчеты в HTML и искать не просто персоны в тексте но и связи между ними. Переписанный алгоритм сейчас я портирую в свой TextMF и, как уже сказал, частично оно готово.

[Sardar]

Ой, ошибся формой. Модератор, пожалуйста удали этот коммент.

[b0noII]

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

[dustalov]

Добавил TextMF в каталог NLPub. Пожалуйста, проверьте корректность указания сведений.

Есть несколько вопросов-пожеланий.

Во-первых, почему именно Bitbucket, а не GitHub? Последний гораздо удобнее и популярнее. Во-вторых, под какой лицензией распространяется TextMF? Не обнаружил такой информации. В-третьих, имеется ли возможность её использования в сторонних приложениях? В-четвёртых, у вас в репозитории слишком много автогенерируемых файлов, логов, и внешних jar-файлов, которые вполне можно исключить средствами используемой SCM. В-пятых, почему бы не использовать Maven вместо Ant? Он гораздо более лучше™ одевается. В-шестых, мне кажется, что более правильно писать Topic Detection, чем Theme Searching. В-седьмых, вы можете привязать страницу вашего репозитория на Bitbucket к имеющемуся домену. Разумеется, на GitHub вы можете сделать так же.

Поздравляю с привлечением финансирования и желаю успехов в развитии продукта!

[b0noII]

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

Единственное это скорее всего не будем переезжать с Bitbucket так как все же уже начато все тут, и плюс хочется использовать mercurial.

И спасибо огромное за поздравления!