Что попробовало, и истинные алгоритмы для предложения похожих статей там?

Question

Что попробовало, и истинные алгоритмы для предложения похожих статей там?

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

23

text machine-learning information-retrieval document-classification

задан Davide 6 December 2009 в 04:46

5 ответов

Это типичный случай Классификации документов , который изучается в каждом классе машинного обучения. Если вам нравится статистика, математика и информатика, я рекомендую вам взглянуть на неконтролируемые методы, такие как kmeans ++ , байесовские методы и LDA . В частности, байесовские методы довольно хороши в том, что вы ищете, их единственная проблема - медленность (но если вы не запустите очень большой сайт, это не должно вас сильно беспокоить).

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

Я рекомендую вам ознакомиться с неконтролируемыми методами, такими как kmeans ++ , Байесовские методы и LDA . В частности, байесовские методы довольно хороши в том, что вы ищете, их единственная проблема - медленность (но если вы не запустите очень большой сайт, это не должно вас сильно беспокоить).

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

Я рекомендую вам ознакомиться с неконтролируемыми методами, такими как kmeans ++ , Байесовские методы и LDA . В частности, байесовские методы довольно хороши в том, что вы ищете, их единственная проблема - медленность (но если вы не запустите очень большой сайт, это не должно вас сильно беспокоить).

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

4

ответ дан 29 November 2019 в 01:35

A small vector-space-model search engine in Ruby. The basic idea is that two documents are related if they contain the same words. So we count the occurrence of words in each document and then compute the cosine between these vectors (each terms has a fixed index, if it appears there is a 1 at that index, if not a zero). Cosine will be 1.0 if two documents have all terms common, and 0.0 if they have no common terms. You can directly translate that to % values.

terms = Hash.new{|h,k|h[k]=h.size}
docs = DATA.collect { |line| 
  name = line.match(/^\d+/)
  words = line.downcase.scan(/[a-z]+/)
  vector = [] 
  words.each { |word| vector[terms[word]] = 1 }
  {:name=>name,:vector=>vector}
}
current = docs.first # or any other
docs.sort_by { |doc| 
  # assume we have defined cosine on arrays
  doc[:vector].cosine(current[:vector]) 
}
related = docs[1..5].collect{|doc|doc[:name]}

puts related

__END__
0 Human machine interface for Lab ABC computer applications
1 A survey of user opinion of computer system response time
2 The EPS user interface management system
3 System and human system engineering testing of EPS
4 Relation of user-perceived response time to error measurement
5 The generation of random, binary, unordered trees
6 The intersection graph of paths in trees
7 Graph minors IV: Widths of trees and well-quasi-ordering
8 Graph minors: A survey

the definition of Array#cosine is left as an exercise to the reader (should deal with nil values and different lengths, but well for that we got Array#zip right?)

BTW, the example documents are taken from the SVD paper by Deerwester etal :)

3

ответ дан 29 November 2019 в 01:35

Некоторое время назад я реализовал нечто похожее. Возможно, эта идея уже устарела, но я надеюсь, что она может помочь.

Я запустил веб-сайт ASP 3.0 для программирования общих задач и начал с этого принципа: пользователь сомневается и будет оставаться на веб-сайте, пока он / она найдет интересное контент по этой теме.

Когда пользователь прибыл, я запустил объект ASP 3.0 Session и записал всю навигацию пользователя, как связанный список. В событии Session.OnEnd я беру первую ссылку, ищу следующую ссылку и увеличиваю столбец счетчика, например:

<Article Title="Cookie problem A">
    <NextPage Title="Cookie problem B" Count="5" />
    <NextPage Title="Cookie problem C" Count="2" />
</Article>

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

1

ответ дан 29 November 2019 в 01:35

You should read the book "Programming Collective Intelligence: Building Smart Web 2.0 Applications" (ISBN 0596529325)!

For some method and code: First ask yourself, whether you want to find direct similarities based on word matches, or whether you want to show similar articles that may not directly relate to the current one, but belong to the same cluster of articles.

See Cluster analysis / Partitional clustering.

A very simple (but theoretical and slow) method for finding direct similarities would be:

Preprocess:

Store flat word list per article (do not remove duplicate words).
"Cross join" the articles: count number of words in article A that match same words in article B. You now have a matrix int word_matches[narticles][narticles] (you should not store it like that, similarity of A->B is same as B->A, so a sparse matrix saves almost half the space).
Normalize the word_matches counts to range 0..1! (find max count, then divide any count by this) - you should store floats there, not ints ;)

Find similar articles:

select the X articles with highest matches from word_matches

4

ответ дан 29 November 2019 в 01:35

Другие вопросы по тегам:

text machine-learning information-retrieval document-classification

Похожие вопросы:

score 38 · Accepted Answer

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

Самый простой подход называется мешком слов . Каждый документ сокращается до разреженного вектора из {word: wordcount} пар, и вы можете добавить классификатор NaiveBayes (или какой-либо другой) к набору векторов, который представляет ваш набор документов, или вычислить оценки сходства между каждой сумкой и каждой другой сумкой (это называется классификацией k-ближайших соседей). KNN быстро выполняет поиск, но требует памяти O (n ^ 2) для матрицы оценок; однако для блога n не очень велико. Для чего-то размером с большую газету KNN быстро становится непрактичным, поэтому алгоритм классификации на лету иногда лучше. В этом случае вы можете рассмотреть векторную машину поддержки ранжирования . SVM удобны, потому что они не ограничивают вас линейными мерами сходства, и при этом работают довольно быстро.

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

Если общего набора слов недостаточно, вы можете абстрагировать его до уровня подобия «мешок из N грамм», где вы создаете вектор, представляющий документ на основе пар или троек слов. (Вы можете использовать кортежи из 4 или даже большего размера, но на практике это мало помогает.) Это имеет недостаток, заключающийся в создании векторов гораздо большего размера, и классификация, соответственно, потребует больше работы, но совпадения, которые вы получите, будут намного ближе синтаксически. OTOH, вероятно, вам это не нужно для семантического сходства; это лучше для таких вещей, как обнаружение плагиата. Разделение на части , или сокращение документа до упрощенных деревьев синтаксического анализа, также может быть использовано (есть алгоритмы классификации для деревьев), но это более полезно для таких вещей, как проблема авторства ("учитывая документ неизвестного происхождения , кто это написал?").

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