Как яндекс находит плагиат. И как бороться со склейкой.

Чето я не знал такого. Что можно сравнить 2000 страниц и сделать вывод, что 100000000 между собой не связаны

Яндекс может клеить страницы и через пол года и через год.

И тем более у Яндекса не хватит времени кспивать сравнивать все дубли. Я показал это на выкладке.

Хорошо добавилась к милиарду одна страница нужно ее сравнить с милиардом страниц. Вторая еще с милиардом. Третью тоже с милиардом.

Я не говорю, что Яндекс не запоминает, что он сверил, а что нет.

Страницы меняються чаще чем создаються. Т.е. некоторые страницы вы пару раз редактируете и Яндекс их пускает в допрогон?

Ради одной страницы никто не будет производить милион операций сравнения.

Яндекс никак не может сверить даже 1% комбинаций. И на терории и напрактике это подтверждает практика.

Хеширования со сравнением кучу документов с кучей других не имеет ничего общего.

А мы базу не переиндексируем мы просто читаем индекс. Я это и имел в виду, если вы про это.

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

Помойму n на корень из n. На 4ре порядка снизит затраты. Но учитывая 1000 000 операций сравнения в секунду, который я выбрал с условиями задержек в сети и всего прочего, все равно много проходит времени.

Еще Яща банит лучше когда много одинаковых текстов. Т.е. все он не сверяет однозначно. + задержки в слейки иногда 1.5 - 2 года.

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

Речь идет о подщете выборки шинглов. Шингл и есть что то вроде Хеша.

Почему 1000 000 и причем здесь задержки сети? Операции идут в пределах кластера серверов.

К тому же операции сравнения чисел - самые быстрые из всех.

Hkey, представьте (мысленно) Яндекс прочитал документ и "индексирует" его. Документ он режет на предложения (по точкам и т.д.). Для каждого предложения считается хеш - целое число, которая определяет в какой позиции индекса Яндекса нужно хранить это предложение и информацию где это предложение проиндексировано (id документf и номер предложения).

Если предложение ранее не было в индексе, ячейка индекса (определяемая подсчитанным хешем) будет пусто, что означает: ДУБЛЕЙ предлжения НЕТ! Если ячейка занята, то это означает, что дубли есть и даются "координаты" дублей.

Не нравятся Вам "предложения" возьмите для индексации другие куски текста (всю страницу, например)...

И где Вы видите миллиард операций? Когда операция одна: подсчет хеша и проверка "ячейки индекса" с порядковым номером, равным подсчитанному хешу.

Пожалуйста прочитайте статьи Яндекса про шинглы, выборку шинглов и супер шинглы!

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

Есть предположение (в одной из статей написано "для веб документов используеться выборка 85 шинглов."), что некоторые документы перепроверяються более жестоко, даже, если супер шинглы разные! Как написано раньше.

"Не нравятся Вам "предложения" возьмите для индексации другие куски текста (всю страницу, например)..."

Хорошо сравниваю хеш 2 статей отличающающихся на один символ! Сравнил два получил два уникальных текста. Если бы Яндекс нахолил дубли так же... Дубли он находит и по шинглам и возможно еще по глобальным лексическим методам.

P.S. спасибо за конструктивную критику! Благодаря дискусии мы колективным разумом решаем поставленную задачу!