Так как учет контента и ссылок несколько различен, то будем считаь (исходя из названия темы) только ссылочную составляющую. Тогда это число найденных ключевиков в текстах ссылок, хотя тут будет масса оговорок ввиду того (как я это понимаю), что работает перереколдовка запроса в зоне ссылок и в числе "найденных" пассажей могут быть пассажи "неполные" (т.е. не содержащие ВСЕХ слов из запроса).
В "тошноте" критическая масса очень мала. Практически все оптимизированные страницы "перетошнены". С другой стороны, зависимость достаточно плавная от нагона спама, т.е немного поддадите, немного и изменится, много поддадите, много и изменится.
Тошнота и есть понижающий коэффициент, на него производится деление в модельной формуле. С другой стороны есть и повышающий коэффициент - число "найденных" спамных ключевиков, на него производится умножение. Кто кого "переплюнет" в этом и вопрос, для тех, кто не знает, как тошнота подсчитывается.
Кстати, когда я первый раз ту, старую, научную статью читал, то подумал, что за дурацкая формула, неужели ничего лучше придумать не могли? А вот сейчас, оказалось, что в борьбе с активными мусорщиками Интернета та формула (точнее ее модификация) очень и очень полезной оказалась :))))
Это как утверждение отсутствия замечаемого ПОЧТИ ВСЕМИ эффекта падения в выдаче для новых сайтов? :)
То, что у Вас его нет, не значит, что его нет у других :)
Обычно это означает, что число продвигаемых запросов не более 10-20 и из них только 2-3 действительно КОНКУРЕНТНЫХ высокочастотника.
Кстати, можно спросить сколько за "ура" надо платить в денежках и ресурсах?
Вопрос ведь в том, чтобы при ограниченных ресурсах результат приближался к оптимальному "ура" :)))
Помню я радовался, что стометровку за 13,5 сек пробежал. Для меня это тоже "ура" было. А кто-то в таком темпе почти марафоны бегает :)
Хоть горшком его назовите, если вам нравится слово фильтр, используйте это слово. От этого он не перестанет быть значимым фактором.
С моей точки зрения называть ЭТО фильтром нельзя, "тошнота" ничего не фильтрует (это следует из поставленных экспериментов), правильнее будет назвать коэффициентом в формуле подсчета релевантности.
Как я уже говорил, пока способ вычисления "тошноты" давать не буду, иначе дорвейщики "загудят". Но кому действительно интересно: поищите предшественников работ сотрудников Яндекса в районе "полнотекстовые базы данных", "ГПНТБ",... (10-8 летней давности). В тех работах этот коэффициент прямо указан, только называется несколько по другому :))))
Все в мире развивается по спирали.... Через какое-то время изобретается новый велосипед...
А у меня даже не пожелание, а просьба вообще этот слэш для морд убрать (в исходном коде выдачи для href). :)
По той же причине мне Апорт не нравится :)
Есть у меня в этом сермяжный интерес.
pheny, если разрешите, я дополню Ваше изложение.
Бонус, как таковой, отсутствует. Просто в динамике начинают индексироваться ссылки и фактически это вначале на пользу всем запросам, а затем Яндекс начинает учитывать, что страница становится "спамной" (все больше и больше ссылок индексируется) и вводит антиспамовый коэффициент в свои расчеты. Я его называю "тошнотой".
Эта тошнота сдерживает (но не предотвращает) рост релевантности по "спамным запросам", зато ухудшает результаты по "не очень спамным запросам".
Если ссылки ставились без знания, как Яндекс подсчитывает тошноту (у меня есть подозрения, что таковых среди оптимизаторов с гулькин нос), то очень часто бывает, что падают ВСЕ запросы, в том числе и спамные, так как надо еще угадать, как ставить ссылки, чтобы по крайней мере спамные запросы не падали..
Насчет склейки. Яндекс стал хитрее, и если на Ваших страницах и в ваших ссылках стоят только дубликаты предложений, уже имеющиеся в интернете, то Вы ее увидите, скорее всего, только с приставкой &rd=0
не знаю как удалить дубликат сообщения, по крайней мере удалю текст
Вы же сами сейчас и отвечаете на свой вопрос, что дело не в кеше, а в недоступности некоторых данных при формировании выдачи. Я имел в виду ответ на вопрос: что первично, что вторично? Так Вы же и сами пишите: вначале некоторые данные недоступны, посему выдача глюкнутая, а уже потом эта глюкнутая выдача записывается (остается) в кеш. И как раз в этом я с Вами соглашусь.
А кому охота терять время на обсуждение низкочастотников? Тут клиенты наседают, когда высокочастотник "опустился". Не до жиру, быть бы живу. Поэтому проблемы с высокочастотниками ЗАМЕТНЕЕ, в том числе и на форуме.
Под кешем можно понимать две вещи:
1. Программисткий (типа кеша Апаче) - просмотр, нет ли в temp директориях уже готового к выдаче файла, выданного ранее. С таким понятием кеша все ясно, в том числе и как он формируется, сколько времени живет,....
2. Просчет выдачи загодя. Например, для однословных запросов Яндекс может просчитать загодя релевантность страницы к любому однословному запросу, если это слово есть на странице и/или в ссылках на нее. И занести полученную релевантность в индекс. Время на такой подсчет, по сравнению с затратами на индексацию-мизерное. Зато на процентов 20 запросов ответ будет известен и на их выдачу уйдет мизерное время и без пересчетов. Но при таком раскладе, подсчет релевантности будет происходить (легко это организовать), когда все данные налицо и не глюкнутые. В таком случае при таком запросе, как "Подарки" при поиске во всем интернете странностей быть не должно
3.1 В любой сложной программе есть ошибки.
3.2 В любой сложной программе есть "слабые места", в которых она работает не так, как хотелось бы, а совсем наоборот., причем часто и исправить их невозможно, так как сам программист не знает, какой алгоритм применить.
3.3. В таком комплексе программ, как службы Яндекса, этих ошибок и слабых мест пруд пруди, совершенно с Вами согласен.
4. В кеше типа Апача могут быть и обязательно будут низкочастотники, только время их жизни маленькое. Не думаю, что Яндекс сразу удаляет из кеша низкочастотные запросы. Человек такой трудяга, что часто ищет одну и ту же длинную фразу несколько раз в течение 5-10 минут.
Да, меня тут уже наградили минусом за "чушь", которую я тут несу :)
Прошу прощения, предпочитаю сам анализировать и делать выводы. А какие они? Оптимизаторы самого высокого класса? И почему со слов, а не с доводов?
Кэш, как я его понимаю, это использование СТАРЫХ данных, но это не значит, что они НЕПРАВИЛЬНЫЕ (т.е. глюкнутые данные)....
А ГЛЮКНУТЫЕ данные совсем не обязательно кешировать. В конце концов в Яндексе не мазохисты работают.
Глюк и кэш понятия независимые.
Да и в глюк я с трудом верю, не говоря уже о кэше. Скорее всего был запланированный процесс пересчета части базы и ее переиндексации, а это процесс очень не быстрый... Можно считать издержками производства, не останавливать же сервис Яндекса совсем...
Рад тому, что почти земляки мои стали чаще попадаться. Как никак в Ст. Петергофе 4,5 года прожил и даже один год в новом Университете обучался... Да и красивые парки возле Биологического Института, у моря, всегда вспоминаю, не говоря уже о Петергофских фонтанах.
1. А почему именно 100, 70, ? В данных результат измерений, а не высосанные из пальца цифры. Главное - что какую бы линейку мы не взяли (download.ru,...), в пределах погрешности графики совпадают. Тестовый запрос для каждой "измерительной линейки" был разным, от "бухучета", до "математики", причем в запросе, как правило, было не одно слово, а взятые с оператором ИЛИ несколько слов. Плюс использовался для перекрестного контроля оператор процента %, параметр мягкости, оператор расстояния между словами,... И еще кое что :)
2. Корень из логарифма, насколько я знаю, можно смело относить на мой счет :))) И я считаю это своим достижением.
Собственно, любая монотонная функция может быть ранжирующей, но математики любят линейные функции, так вот именно эта функция "линеаризует" релевантность, т.е релевантность при такой функции становится пропорциональной числу найденных слов, умноженному на корень из логарифма веса (для однословных запросов). О "тошноте", как коэффициенте спама (или, иначе, "контрастности") мы здесь не говорим. Как и о "ступеньках".
3. Отличное совпадение разных измерительных линеек для такого спамного слова как "недвижимость" для топ10 говорит о том, что эта же формула для корня из логарифма веса используется и в ссылочном ранжировании.
4. Можно взять и другую функцию, как предложено выше, но она не будет линейна по числу найденных слов в ссылках и в тексте страницы!
Это неудобно, например, для ответа на вопрос: сколько еще мне слов "недвижимость" добавить в стоящие уже ссылки и текст страницы, чтобы догнать конкурента? Если известно, что я от него отстаю в два раза при использовании функции "корень из логарифма"? Ответ будет: в два раза больше :)
5. И, наконец, не верьте полностью пункту 4, так как он имеет одно ограничение: мы считаем, что коэффициент "тошноты" не изменится, если мы увеличим вдвое число слов "недвижимость", а это неверно! (при определенных условиях), т.к. такая вставка слов может изменить "тошноту" :)
