Автор: Сергей Людкевич - независимый консультант, супермодератор форума о поисковых системах Searchengines.Guru.
Сфера профессиональных интересов - исследование алгоритмов ранжирования поисковых машин, разработка методик поискового продвижения сайтов.
В начале этого года Яндекс объявил о прекращении поддержки ряда операторов языка запросов. Я подробно писал об этом в своей статье «Кастрация языка запросов Яндекса». Отказ от поддержки ряда операторов объяснялся сотрудниками Яндекса изменением формата поискового индекса и связанного с ним изменением механизма разбора поисковых запросов. По прошествии некоторого времени хотелось бы проанализировать, какие изменения на самом деле произошли в логике работы операторов языка запросов Яндекса. Самый неприятный итог изменений – это то, что все указанные в анонсе операторы из группы «Морфология и поисковый контекст», а именно &, &&, <<, ~, (), !!, на данный момент действительно перестали работать (возможно, за исключением малоинтересного с точки зрения аналитики оператора !!). Эти операторы оказывали неоценимую помощь при исследовании поисковой выдачи, позволяя конструировать разнообразнейшие запросы для решения широкого спектра аналитических задач. Теперь же они явно не поддерживают свои функции. Оператор ~ теперь является аналогом документированного оператора – (минус), который осуществляет поиск документов, в которых отсутствует заданное слово, хотя раньше работал с точностью до предложения, т.е. позволял искать документы, в которых заданное слово не содержится в одном предложении со словом, указанным до оператора. Также аналогом оператора – (минус) сейчас является и оператор ~~, почему-то не упомянутый в анонсе Яндекса о прекращении поддержки операторов, но исчезнувший из официальной документации. Раньше с помощью оператора ~~ можно было исключать из поиска целые поисковые фразы, а также страницы и сайты (т.е. он работал с документными операторами), а теперь он применим только к отдельным ключевым словам. Впрочем, аналогия простирается лишь на случай, когда операторы применяются к последним словам запроса. Если же использовать их в середине, то получившиеся результаты поиска могут разниться и осмысленной логике не поддаются: Оператор &, призванный искать слова в пределах одного предложения, определенно этого не делает. В приведенном ниже примере, на сайте, по которому идет поиск, нет предложений, где бы встречались оба указанных слова, но тем не менее, выдача не пуста: Оператор поиска в пределах документа && тоже не выполняет своих функций. В приведенном примере на сайте, по которому идет поиск, нет документов, в которых встречаются оба слова из запроса. Тем не менее в выдаче фигурируют документы, где они встречаются поодиночке: Оператор << (неранжирующее ИЛИ) перестал ограничивать выдачу документами, релевантными запросу, находящемуся по правую сторону оператора. На приведенном примере справа находится «абракадабра», которая вообще не встречается ни в одном документе. Тем не менее, это не оказывает никакого влияния на число найденных документов: Проверим работу оператора группировки слов при сложных запросах (). Возьмем два запроса поиска по сайту с пустой выдачей: И сгруппируем их с помощью оператора () и документированного оператора | (логическое ИЛИ). Если группировка работает корректно, то выдача должна быть пуста. Однако это не так: Что же касается оператора поиска слова по начальной форме !!, то проверить его корректную работоспособность очень трудно. По крайней мере, можно убедиться, что применяя его к словам, которые сами по себе не являются начальной формой, можно найти документы только с точными вхождениями этих слов. А вот для слов, которые являются начальной формой слов, ищутся документы, где нет точного вхождения, но есть формы этого слова. С другой стороны, очень похоже на то, что начальная форма слова в запросе теперь учитывается по умолчанию (пищу для размышления привожу ниже на скриншотах). Но никакой практической ценности я в этом не вижу. | 
Комментариев нет:
Отправить комментарий