Тут Professor недавно заметил у себя странные рефереры. Рефы были со страниц подсветки “найденных слов” Яндекса. Например, ищем Яндексе реклама в интернете, ссылка на “Найденные слова” выглядит как hghltd.yandex.ru/yandbtm?url=http://www.promodo.com/index-ru.html&text=реклама в интернете&reqtext=(реклама::1676 &/(-1 3) в::0 &/(-1 3) интернете::1313)//6&dsn=70&d=3153694 – в ней есть параметр reqtext, который переводится как (реклама::1676 &/(-1 3) в::0 &/(-1 3) интернете::1313)//6
Возникла мысль, что это реальный запрос, который отрабатывается вместо введенного, т.н. “колдунщик”. Нечеткий поиск, расстояния, веса.
Вот то, что после :: – похоже на вес слова в запросе. Например, в данном случае вес стоп-слова – ноль, а если бы был запрос реклама в, то стоп-слово имело бы ненулевой вес.
Я пробил 30 слов разных весов, получилось похоже на то, что вес~1/(число найденных страниц). Плюс-минус полпорядка 🙂 При этом точность была в пределах 0.3 порядка на не очень часто спрашиваемых словах, а на стоп-словах и очень частотных словах (напр. web, www) она прыгала сильно. Возможно, это с неточностью показа числа найденных страниц переплелось.
Короче, вес, видимо.
Он ограничен сверху – для “очень редких” запросов (лоренциан, гуано) = 2063133498.
Однако выдача немного не та, что на исходном запросе. По крайней мере у меня отличается, когда я смотрю последние сайты из 50, часто отличается… Хотя слабо очень.
Если вбить “заколдованный” запрос, и поменять веса ручками, то выдача не меняется. Он его переколдовывает обратно, блин! 🙂 А вот если поменять расстояние между словами – их не переколдовывает.
Яндексовские операторы:
| пробел или & | логическое И (в пределах предложения) |
| && | логическое И (в пределах документа) |
| /(n m) | расстояние в словах (-назад вперед) |
| &&/(n m) | расстояние в предложениях (-назад вперед) |
Но интереснее – как он переколдовывает.
Слово лоренциан переколдовал так:
(лоренциан::2063133498 &/(0 0) !!%лоренциан::2063133498) – т.е., поиск на нулевом расстоянии между словами. Т.е., как бы усилено влияние самого слова, что ли…
А уже гуано колдует как гуано::2063133498.
Если стоп-слово одно или одно из двух в запросе, оно колдунщиком учитывается с восклицательным знаком, а если одно из трех – нулевой вес ставится. Если два стопслова и два нормальных – учитываются.
Такое впечатление, что колдунщик устойчивые словосочетания понимает… Но как-то странно.
напольные покрытия => (напольные::78746 &&/(-7 7) покрытия::21744)//6 – поиск в пределах 7 предложений,
новый год => (новый::532 &/(-1 3) год::502)//6 – поиск в пределах нескольких слов от год новый до новый () () год,
офисная мебель => (офисная::16909 & мебель::5321)//6 – без расстояния в одном предложении…
Все-таки не особо он понимает устойчивые выражения. Тогда “новый год” он бы искал по фразе. Может, просто с частотностью каждого из слов связано?
Иногда переставишь слова местами, а он их по-другому колдует:
аренда квартир => (аренда::10297 & квартир::5104)//6,
квартир аренда => (квартир::5104 &&/(-3 3) аренда::10297)//6 – явно не устойчивое словосочетание, и начинает сразу искать в пределах 3 предложений… Но вот для пар существительно – прилагательное это не работает. А только существительное – существительное.
И так-то не всегда получается – строительство домов и домов строительство одинаково переколдовывает…
А то иногда переставляешь слова в запросе – и он там расстояния между ними вставляет… Например синтаксис язык запросов яндекса переколдовывает через & , а язык запросов яндекса синтаксис – синтаксис отделяет &&(-7 7). И так далее.
А то еще и от падежей зависит! синтаксис языка запросов яндекса (не язык!) – переколдовал иначе, яндекс отделил &(-2 4), т.е., в одном предложении… Все-таки устойчивые фразы он как-то понимает…
Нет, что-то очень хитрое это…
У кого какие мысли? Комментарии запрещены.
_____________
PS ссылка на панель Links – для показа
Колдунщик Яндекса: 34 комментария
Связи между числом и весом слова не уловил.
Что если число – это просто id слова в индексе?
Это объясняет малые значения для широкораспространенных в сети слов, т.к. они попали в индекс гораздо раньше, а слова типа "гуано" впервые были проиндексированы гораздо позже, отсюда и id у них побольше. Это объясняет и 0 для стоп-слов, т.к. они вообще в индекс не заносятся.
Или фигню сказал? Надо подумать….:)
А вот запросы действительно интересно формируются.
>Что если число – это просто id слова в индексе? Это объясняет малые значения для широкораспространенных в сети слов
-у меня тоже первой такая мысль была, но, во-первых, "слово первым проиндексировано" – это вряд ли. Вот ты попал на страницу, на ней что, первыми идут стоп-слова? Во-вторых, есть связь между этим числом и числом найденных страниц. И в третьих, ты разве не заметил, что у разных слов есть ОДИНАКОВЫЕ id? 🙂
>Он ограничен сверху – для "очень редких" запросов (лоренциан, гуано) = 2063133498
>ты разве не заметил, что у разных слов есть ОДИНАКОВЫЕ id? 🙂
Да, ты прав. Как то упустил этот момент.
Все очень походит на правду.
Молодцы, ребята.
Скорее всего это запрос для отбора кворума (отбора НАЙДЕННЫХ документов).
А ранжирование уже НАЙДЕННЫХ и ОТОБРАННЫХ идет немного по своему (видимо, обсчет идет по весам tf*idf для НАЙДЕННЫХ ПОЗИЦИЙ словоформ, часть присутствующих в документе словоформ войдут в НЕНАЙДЕННЫЕ словоформы, т.е. они повлияют на "контрастность" слов в документе, при ОТБОРЕ документов они учитываются в "контрастности", а при ранжировании не учитываются).
Пример, первый, который попался:
http://hghltd.yandex.com/yandbtm?url=http://okna.ss21.ru/&text=пластиковые окна&reqtext=(пластиковые::22287 & окна::6100)//6&dsn=233&d=810840
В заголовке вверху "Долговечность окон из ПВХ профилей" есть слово "окон", но оно НЕ НАЙДЕННОЕ. Предварительно при отборе документов учитывается для "контрастности", а при ранжировании выпадает. Часто "выпадать" могут "вторые и далее" слова в поисковом запросе.
Плюс к тому же, какое слово самое "тяжелое" в документе на этапе отбора документа – одно, а на этапе ранжирования – другое.
Для первых позиций в выдаче – различия в релевантности большие, поэтому порядок выдачи практически не меняется. А для дальних позиций в выдаче – релевантности близки и небольшие поправки в весах сказываются сильнее на порядок выдачи.
Еще такой вопрос, учитывает ли Яндекс такое расстояние как "абзац" или он его в зависимости от контекста определяет как определенное количество предложений?
В каких единицах измеряется расстояние при ранжировании? Есть ли какие-либо соотношения между словами и предложениями (типа 2 предложения плюс 7 слов равно 27 уе)?
Нельзя ли подобрать "__E0::6100)//6__" такие, что выдача становится адекватной обычному запросу по умолчанию. Плюс поиграться с весами слов в обычном языке запросов Яндекса
Но очень все тепло!
Возможное объяснение:
У Яндекса есть понятие "устойчивые связи между словами". Если связь устойчива – поиск в одном предложении, если нет -поиск в абзаце ( && ).
Возможно, при анализе цепочки поисковой фразы Яндекс посчитал, что "синтаксис" и "Яндекс" не очень связаны (в отличие от пары "Яндекс-Запросы").
Слову "синтаксис" везет больше в паре "синтаксис-язык" .
Все остальные пары тоже хорошо связаны:
"язык запросы", "запросы Яндекс".
Правда, мне пока не ясно, как "цепочка запроса" связана с "треугольной" матрицей связей для этого "многоместного оператора AND".
Тут, возможно, мы видим в переколдованном запросе УЖЕ РЕЗУЛЬТАТ ВЫБОРА цепочки после АНАЛИЗА этой треугольной матрицы. Интересно, не замечал ли Euhenio ИЗМЕНЕНИЕ ПОРЯДКА СЛОВ В поисковой фразе при "переколдовке"?
А зависимость от падежей указывает на учет падежей в "устойчивости связи слов".
Euhenio – большое спасибо за две темы про "колдунщика"
Чуть ли не самые полезные сообщения вообще по алгоритмам Яндекса.
Есть ли еще такого рода (КОНКРЕТНЫЕ!, Без воды! И без нравоучений и бесполезных советов) обсуждения алгоритма Яндекса?
Был бы признателен за ссылочку.
А то меня в searchengines отключили, могу только с умным видом молчать 🙂
>У Яндекса есть понятие "устойчивые связи между словами".
-это точно, кажется, даже где-то описывалось. Вот только как они это делают – по статистике запросов? по ассоциациям? по встречаемости в документах?
>Тут, возможно, мы видим в переколдованном запросе УЖЕ РЕЗУЛЬТАТ ВЫБОРА цепочки после АНАЛИЗА этой треугольной матрицы
-не понял… Это и есть тот самый многоместный оператор, вероятно. Т.е., типа его формулировки, что ли..
>Интересно, не замечал ли Euhenio ИЗМЕНЕНИЕ ПОРЯДКА СЛОВ В поисковой фразе при "переколдовке"?
-нет.
>А то меня в searchengines отключили
-а кто ты там был? 🙂
>Скорее всего это запрос для отбора кворума (отбора НАЙДЕННЫХ документов).
-не может этого быть. Колдунщик – это препроцессинг запроса. Никаких знаний о результате (наборе найденного) в нем не должно быть.
>|||У Яндекса есть понятие "устойчивые связи между словами".||| -это точно, кажется, даже где-то описывалось. Вот только как они это делают – по статистике запросов? по ассоциациям? по встречаемости в документах?
Надо экспериментики поставить для определения x-y. Как ставятся &/(-x y) или &&/(-x y) в зависимости от частотности слов, например, или от Яндекс-директ статистики, или от результатов поисков по ТОЧНОЙ фразе, или по ТОЧНОМУ запросу с указанием ТОЧНОГО расстояния между словами…
>|||Тут, возможно, мы видим в переколдованном запросе УЖЕ РЕЗУЛЬТАТ ВЫБОРА цепочки после АНАЛИЗА этой треугольной матрицы||| -не понял… Это и есть тот самый многоместный оператор, вероятно. Т.е., типа его формулировки, что ли..
Например, фраза из 3 слов А Б В. Для нее Яндекс делает матрицу 3*3 связей между словами. У Яндекса есть статистика встречаемости ПАР слов (А-Б,Б-В,А-В,А-А,…) в документах в зависимости от расстояния между словами. Если есть различимый максимум в такой функции, то есть и связь между словами. Яндекс мог бы выбирать диапазон, в который попадало бы 50% результатов и ставить его в переколдовку. Причем возможен такой вариант, что менял бы ПОРЯДОК слов (максимум при отрицательном расстоянии)… Это конечно, как возможный вариант. Плюс ОКРУГЛЕНИЕ результата до целого числа плюс учет ЖЕЛАНИЯ пользователя (не зря же он именно в ТАКОМ порядке слова поставил).
Если слов в запросе много, запрос может быть изменен путем изменения порядка слов и некоторой "оптимизацией" этого порядка и именно этот запрос потом подается как переколдованный. Если бы это было не так, тогда переколдованный запрос выглядел бы как комбинация запросов с перестановками слов и соединенными ИЛИ.
Пример. ЗАПРОС А Б В Г. Все абвг как-то связаны и все имеют различную связь.
Тогда переколдованный запрос в общем виде мог бы выглядеть как
(А Б В Г) ИЛИ (Б В Г Д) ИЛИ (А Б Г Д) ИЛИ…..
где между элементами АБВГ стояли бы операторы расстояний, которые наиболее подходят именно к этой комбинации слов…
Однако этого нет, и можно сделать вывод, что КАКАЯ из этого общего запроса выбирается комбинация в скобках – решает Яндекс на основе своего анализа треугольной матрицы, а затем выдает его как переколдованный.
>///А то меня в searchengines отключили/// -а кто ты там был? 🙂
Я то-там только наскоками… Миныч OR ikozlov
>|||Скорее всего это запрос для отбора кворума (отбора НАЙДЕННЫХ документов).||| -не может этого быть. Колдунщик – это препроцессинг запроса. Никаких знаний о результате (наборе найденного) в нем не должно быть.
Я неточно выразился. Мое понимание КВОРУМ===Множество всех документов, которое Яндекс считает НАЙДЕННЫМИ. А чтобы считать документ найденным, он должен найти в документе фразу (подфразу), вес которой превышает некоторое число. Как это число найти (нам) или как его считает Яндекс – вопрос. Достаточно ли для этого "жесткости" и "контрастностей", которые мы видим в reqtext?
Кстати, я в блог пришел потому, что искал reqtext и dsn, а также какие еще операторы в Яндексе доступны, кроме общеизвестных.
что то запросы типа
__что такое * __ как то странно Яндекс переколдовывает
Например
что !такое
что такое однокамерный стеклопакет
Неужели Яндекс включил искусственный интеллект?
Переиначил в
однокамерный стеклопакет ЭТО
А мы дураки, оптимизируем под ЧТО ТАКОЕ, а надо оптимизировать под ЭТО
:)))))))))))))
Ничего не скажешь – молодец Яндекс!!!
Обалдеть.
что такое однокамерный стеклопакет ->
(однокамерный::611879 & стеклопакет::170966 &/(1 1) !это::138)
И, кстати, без мягкости! //6 нету. Может, глюк? Мягкость должна быть. Или тестируют что новое?
Да я смотрю, здесь Яндекс такого НАВОРОЧАЛ!!! 🙂
Спасибо ему 🙂
Вот если бы он ввел еще такие вещи как
1. Вместо поиска слова искал бы его синонимы ! Плюс мог бы смешать ВСЕ синонимы в одном запросе с разными весами.
2. Провел бы компанию по обучению знаку "!" для тех юзеров, кто не хочет синонимов в результатах.
Вот бы всех оптимизаторов на уши поставил. Кстати, для самых умелых – это даже на руку – спрос на УМЕЛЫХ оптимизаторов сразу взлетит до небес.
И все оптимизаторы начнут почти с нуля.
Черт, времени нет, надо каталог книжной выставки "Книги России" готовить 🙁
Ну да ладно, потом посмотрю…
Ну, Яндекс 🙂
!!! "ЭТО ОЗНАЧАЕТ" !!!
PS Euhenio, не могли бы Вы скриптик свой подправить под русскую кодировку.
Был бы очень благодарен (в ссылки для расшифровки reqtext)
Скрипт подправлю, если мне скажут, как именно его править 🙂
Знак "!" – это точное соотвествие словоформы, плюс – это обязательное присутствие слова, иногда он оба знака пишет перед словом.
А насчет синонимов – имхо, вредно это для поиска. И так-то кто-то показывал, как вместо "человек года" Яндекс находил "люди лета". 🙂
Эта вещь здесь: http://forum.searchengines.ru/showthread.php?s=704c402de4a790cd5c36719cda6bc156&t hreadid=548
Кстати, то, что там написал Keva: очень похоже на "переколдовку", только в результате обработки "треугольной матрицы" подается не полный запрос в нормальной булевой форме:
>(А Б В Г) ИЛИ (Б В Г Д) ИЛИ (А Б Г Д) ИЛИ…..
а, извлеченный из полной последовательности подзапрос А Б В Г , наиболее вероятный (из анализа того, что написал, например Keva).
Причем Keva, видимо имел в виду, что в полный запрос могли бы подойти и
А Б Г Е и Е Г А Ф,…. т.е. слова, отсутствующие в самом оригинальном запросе.
А насчет апдэйтов Яндекса, надо оптимизаторам молиться, чтобы они были всегда. Тогда без куска хлеба не останутся. Надо бы даже стимулировать Яндекс апдэйтить почаще и посерьезней:)
Скриптик придется править самому 🙁 Как в том анекдоте…
Дама – гостю: Вы знаете, через час придет мой муж……
Гость: но мы ведь ничего такого не делаем!
—–вот именно!!! А время – идет!!!
Кому интересно, к "лоренциану" могу добавить "Котова" во фразе "Настя Котова", "Электромаш", "коннемара", "Нострадамуса"… и много других случаев.
Кстати "d=" – это не id документа, да и "dsn=" – это не номер сервера 🙂
И что-то хитрое мне мерещится в ДВОЙНОМ "!!"….
Что-то вроде при совпадении с ТОЧНОЙ формой – надо вес этой точной формы в квадрат возвести 🙂
А может просто умножить на два 🙂
Кто не верит – наберите "Нострадамуса", а потом "Нострадамус"…..
И сравните….
См. также "Топлов Александр"
>Кстати "d=" – это не id документа, да и "dsn=" – это не номер сервера
-ну, насчет dsn не знаю, а вот одинаковые d я получал, специально находя один и тот же урл по разным фразам, в подсветке был одинаковый d для этого документа. Отсюда – это id документа.
А что говорит против этого?
Внутренний голос 🙂
А зачем ему id если есть УРЛ, который однозначно определяет документ?
Что-то мне мерещится, что это характеристика документа, которая его характеризует с содержательной стороны.
Хотелось бы найти для одного и того же УРЛ разные d
Или точно доказать, что все УРЛ поголовно имеют один d
Например, жесткость почти всегда 6, но не всегда.
d может означать некоторую характеристику документа для запросов. Типа средний вес слова (предложения), разброс весов, вес заголовка,…
Или еще проще, контрольная сумма 🙁
Но может быть я и неправ и переоцениваю программиста. Тогда d = id
dsn=server_id
Надо сейчас статистику посмотреть какие dsn чвще встречаются и сколько по статистике цифр в d
-Вес какого слова, какого предложения, для каких запросов? 🙂 d, насколько я вижу, не зависит от запроса.
>А зачем ему id если есть УРЛ, который однозначно определяет документ
-а зачем ему передавать в подсветчик переколдованный запрос с весами, если алгоритм переколдовки известен Я. и подсветчик может колдовать сам? Точно так же – избыточная информация передается.
id только вместе с dsn может быть уникальным для документа
документов слишком много, уж явно больше 3 млн
dsn я проверил встречаются почти все в диапазоне от 0 по 283
жесткость вроде тоже от запроса не зависит, 6 и есть 6, однако…
я сейчас проверю меняется ли d со временем (типа за полгода)
а вдруг d=page_hash_code 🙂 для быстрого определения изменился ли документ, чтобы время экономить и ничего не подсвечивать, когда документ изменился.
В логах нашел за 20.09.2004 :
http://hghltd.yandex.ru/yandbtm?url=http://www.melnitsa.ru/index.php?action=group”>http://hghltd.yandex.ru/yandbtm?url=http://www.melnitsa.ru/index.php?action=group &id=29&text=Пикник группа&reqtext=(Пикник::467448 &&/(-7 7) группа::1808)//6&dsn=86&d=2464551
А сейчас это:
http://hghltd.yandex.com/yandbtm?url=http://www.melnitsa.ru/index.php?action=grou p&id=29&text=Пикник группа&reqtext=(Пикник::467448 &&/(-7 7) группа::1808) << (rhost="ru.melnitsa.www"::4384370:0 | rhost="ru.melnitsa.www.*"::4384370:0):0&dsn=156&d=1897940
Тут же рядом за сентябрь
http://hghltd.yandex.ru/yandbtm?url=http://www.melnitsa.ru/i
ndex.php?action=group&id=13&text=red snapper&reqtext=(red::17984 & snapper::2063133498)//6&dsn=68&d=2465890
Сейчас:
http://hghltd.yandex.com/yandbtm?url=http://www.melnitsa.ru/index.php/?action=gro up&id=13&text=red snapper&reqtext=(red::17984 & snapper::2063133498)//6&dsn=37&d=2431292
Да, логи – это интересно.
А нашелся ли один документ одновременно с разными d?
Теоретически в разные моменты времени документ может иметь разные идентификаторы. Представь – часть документов удалилась из базы (убита, склеена) – оставшийся набор айдишников надо сжать.
Такого не нашел.
Эволюцию Яндекса можно посмотреть на некоторых примерах…
Первые шаги по использованию dsn можно посмотреть здесь
http://www.gotour.ru/wstat7/monthly/2003/04/01/referrers.html
forum.rusc.ru/index.php?t=msg&goto=8635&#msg_num_17
Раньше, вроде, не видно.
Кстати, выражения типа:
http://www.yandex.ru/yandpage?q=1753713638&p=10&ag=h&qs=text=зТБОД-ФХТ См. http://www.gotour.ru/wstat7/monthly/2003/03/01/referrers.html
как раз и наводят на мысль о том, что d скорее не id, а что-то вроде контрольной суммы страницы или хэш код страницы. q очень похож на id
Вам лучше знать, Вы оптимизацией давно занимаетесь 🙂 Еще там же для примера:
http://hghltd.yandex.ru/yandbtm?url=http://www.gotour.ru/internet.html&text=туроп ератор Злато&su=http://www.yandex.ru/yandvft11?q=-1087673305&d=1441446
Это 2003 год
>мысль о том, что d скорее не id, а что-то вроде контрольной суммы страницы или хэш код страницы
-а это с практической точки зрения одно и то же. 🙂 Но если d менятется со временем, это не хэш.
>q очень похож на id
-q – это идентификатор сделанного юзером запроса. Для следующих страниц выдачи, одинаков, от запроса к запросу меняется. Короче, это кеширование результатов запроса.
спасибо, не знал 🙂
>это с практической точки зрения одно и то же. 🙂 Но если d менятется со временем, это не хэш.
Вполне может быть и хэш, только не УРЛа, а самой страницы. Ведь содержание страницы меняется со временем, точнее может меняться. И даже без изменения содержания, например, изменился адрес файла стилей или скриптов. Я хочу сказать, что это хэш код HTML кода страницы.
Основной довод "за" – не видно в выдаче d с величиной более 4 млн. плюс "полезность" этого числа для определения истинности "документ изменился".
Евгений, Вы правы. Получил точное доказательство, dsn d===id документа.
С другой стороны документы с одного сайта хранятся на разных dsn и, видимо адрес (id) документа на физической машине определяется хэш кодом URL.
Причем для подсветки берется именно dsn and d, а не УРЛ.
А вообще, Евгений, тут такие дела…
Похоже, ранжирование Яндекса для чистого текста без ссылок,титлов и заголовков у меня в руках 🙂
Но надо проверить, чтобы болтуном не прослыть… Как назло хороший договор с одним провайдером наклевывается. Плюс с районной администрацей на контакт надо идти, пока "горячо", а то время можно упустить 🙁
Я думал, что они посложнее формулы использовали…
Кое-что про кухню Яндекса говорят две ссылки
в данный момент они работают одновременно
http://hghltd.yandex.com/yandbtm?url=http://www.okna.ru/&text=(пластиковые окна) && (#url="www.okna.ru*" | #url="www.oknalux.ru*") &reqtext=((пластиковые::22287 & окна::6100) && (url="www.okna.ru*"::5392 | url="www.oknalux.ru*"::5392))//6&dsn=171&d=3679343&isu=1
http://hghltd.yandex.com/yandbtm?url=http://www.okna.ru/&text=компания && (#url="www.okna.ru*" | #url="www.oknalux.ru*") &reqtext=(компания::1122 && (url="www.okna.ru*"::5392 | url="www.oknalux.ru*"::5392))//6&dsn=1&d=3679343&isu=1
Забавно, еще примерчик переколдовки:
/что такое хуй/->
/хуй::55430 &/(1 1) !%это::359 &/(-2 4) %означает::16316 &/(-2 4) %аббревиатура::334021 &/(-2 4) %расшифровывается::183623/
если это поиск в найденном, то запрос не переформулируется
тема с перекодировкой на русский: http://seochase.com/viewtopic.php?t=5081&sid=59e8ed5c6996a3616d5515c50044e78c
Топик с утилиткой для счета по кворуму и для выдергивания "переколдованных" запросов из Yandex – http://forum.searchengines.ru/showthread.php?t=128567
Ну что, доигрались, господа изыскатели? Похоже, кердык колдунщику для масс. Параметр regtext с сегодняшнего дня в URL’е подсветчика пустой. Слабо верится в глюк, Яндекс закручивает гайки?
Ну почему же … Рано еще говорить, подождем пару апдейтов.