Вы используете тезаурус для построения семантического индекса? И где можно почитать по подробнее об инструменте?
А на основе каких алгоритмов, построен инструмент?
Смотрите здесь: http://www.livejournal.com/community/ru_ir/7911.html
Как раз в статье я его описал (раз Яндекс почему то этого не сделал), но в интернете ее нет.
Не пойдет. Ципф-Мандельброт может сгодиться только как теоретическая основа. Вряд ли с его помощью можно отловить различных авторов. Да даже практически наверняка нельзя.
Шинглы достаточно просты а реализации. Можно также посмотреть SVM (Метод Опорных Векторов) http://svmlight.joachims.org/ (где то встречал статью, где описывается его применение к определению дубликатов, но думаю это не самый легкий вариант), а так же метод k-ближайших соседей (k-Nearest Neighbors, k-NN) (здесь например можно на русском посмотреть http://www.spc-consulting.ru/DMS/Machine%20Learning/MachineLearning/Overviews/KNearestNeighborsIntroductoryOverview%20.htm). Этот метод хорош тем, что при добавлении нового документа его не надо заново обучать на все выборке.
Есть еще куча всего. Но лучше все же воспользоваться шинглами - просто и эффективно. Только вот с выбором порога сходства замучаетесь. Но с другой стороны так во всех методах.
2bvd
Спасибо за ссылки. Отличные материалы.
Ну от чего же без лингвистики не построить обект? Если конечно не считать приведение к нормальной форме - лингвистикой, то можно обойтись и без нее. Работать с частотами одно-, двух-, трехсловных конънктов.
Но у меня ощущение, что лингвистический подход (в частности использование тезауруса для автоматического индесирования) - должен дать гораздо более лучшие результаты, чем использование исключительно статистических методов.
Совсем не факт. В таком случае количество сохраненных шинглов будет прямо пропорционально количеству всех шинглов (равному n-9 для 10-словного шингла, где n-число слов в тексте) для всего текста. Оно вам надо?
В таком случае либо Вы будите хранить избыточное количество шинглов для больших по объему текстов, либо недостаточное количество для малых.
Из этой ситуации можно выкрутиться используя ранжирование текстов и сохраняя для текстов одного ранга шинглы кратные одному числу. Но для того, чтобы можно было сравнивать документы разных рангов, нужно чтобы эти числа тоже были кратны (например 10, 20 и 40) для документов разбитых на три ранга в зависимости от объема.
Надеюсь изложил свою мысль не слишком сумбурно.
Да нет же. Страницы на границе рангов вполне могут быть "почти похожими". Я уж и не знаю как объяснить.
Хотя...
может быт, это и не такая плохая идея. Для повышения скорости можно сравнивать только документы объем которых различается не более чем в заранее заданное число раз. Так как если документы отличаются, например, больше чем в два раза то они не могут быть "почти похожими". Хотя, стоит оговорится, если необходимо помимо почти-дубликатов определять и включенность, то этот метод не прокатит.
...либо хранить все шинглы и при поиске брать только кратные искомому. Но это только для документов разных рангов! Для документов же одних рангов, будем брать все шинглы имеющие кратность соответствующую данному рангу. Например
док1 (ранг1):
19734298510
44578957880
36719111850
94235456700
док2 (ранг2):
54887592520
52856783240
Сравниваем только:
из док1 - 44578957880, 94235456700
из док2 - 54887592520, 52856783240
Сравнить 3-й с 1-м рангом при кратности шинглов 10 нельзя по принципиальным причинам (иначе Вам необходимо хранить для 3-го ранга шинглы кратные 10, что самом по себе убивает весь смысл в разделении на ранги).
3-й ранг сравнивается с 1-м точно так же как и 1-й с 3-м. Какая разница? Просто для сравнения из шинглов 1го ранга кратных 10 берутся только шинглы кратные 40-ка.
