среда, 13 декабря 2017 г.

Новая логика работы операторов языка запросов Яндекса. Документные операторы

В своей предыдущей статье я проанализировал работоспособность операторов языка запросов Яндекса из группы «Морфология и поисковый контекст», о прекращении поддержки которых было официально объявлено Яндексом в январе 2017 года. Нововведения объяснялись «рядом важных изменений, направленных на увеличение производительности поиска, а именно изменением формата поискового индекса и связанным с ним изменением механизма разбора поисковых запросов». Вместе с тем изменения замечены и в работе другой группы операторов языка запросов Яндекса, а именно «Документные операторы». 
Несмотря на то, что в документации языка запросов указано, что документные операторы используются для уточнения поискового запроса, ограничивая область его применения, раньше все операторы этой группы корректно работали и при их прямом применении (или, другими словами, в связке с пустым поисковым запросом). Теперь же эту способность сохранили только операторы url:, site:, host:, rhost:, domain: и date: (назовем их документными операторами 1-го типа). Операторы же mime:, lang: и cat: (назовем их документными операторами 2-го типа) при прямом применении работоспособность явно потеряли:
Документные операторы 2-го типа работают корректно только в связке с непустым запросом, причем, как справа, так и слева от него. Правда, при использовании этих операторов слева от непустого поискового запроса в выдаче могут возникать любопытные артефакты:
Есть также одно исключение, когда эти операторы корректно работают в случае пустого запроса – в связке с документным оператором site:, причем, только справа от него:
При использовании же слева от оператора site: документные операторы 2-го типа просто игнорируются:
Точно также документные операторы 2-го типа игнорируются и в случае пустого запроса в связке с операторами url:, host:, rhost:, domain: и date:, не зависимо от расположения справа или слева от них.
В случае же непустого запроса и нескольких документных операторов, порядок следования запроса и операторов роли не играет. 
Представляется интересным также исследовать текущую работоспособность документных операторов, когда-либо упоминавшихся, но в разное время исчезнувших из официальной документации языка запросов.
Так, летом 2016-го года из раздела Яндекс.Помощи «Документные операторы» без каких-либо объявлений исчезли два оператора, сохранив, однако, на тот момент свою работоспособность:
  • title: – оператор поиска по заголовкам документов (тег title);
  • inurl: – оператор поиска по страницам, в адресе которых есть заданный фрагмент.
Сейчас оператор title:  явно перестал выполнять заявленную функцию, такое впечатление, что он просто игнорируется, не зависимо от того, используется ли он с пустым или непустым поисковым запросом:
А вот оператор inurl:, в отличие от него, свою работоспособность сохранил. Так же, как и документированные документные операторы 2-го типа, он не работает при применении с пустым поисковым запросом 
и работает в связке с непустым:
О других недокументированных операторах я в своё время писал в своих статьях «Сеанс поисковой магии. Недокументированные операторы языка запросов Яндекса» и «Недокументированные операторы языка запросов Яндекса. Продолжение сеанса поисковой магии». К сожалению, самые из них интересные операторы intext: и inlink: потеряли свою работоспособность в апреле 2017-го года, а операторы linkint: и anchorint: – еще раньше.
Из числа недокументированных работоспособными на текущий момент остаются только гораздо менее интересные для решения аналитических задач документные операторы:
  • idate: – оператор поиска по дате последней индексации документа;
  • style: – оператор поиска по адресам файлов таблиц стилей (значение атрибута href тега link c атрибутом stylesheet);
  • profile: – оператор поиска по адресам профилей метаданных (значение атрибута profile тега head)

Все эти операторы имеют свойства документных операторов 2-го типа. 

четверг, 2 ноября 2017 г.

Новая логика работы операторов языка запросов Яндекса. Морфология и поисковый контекст.

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


понедельник, 2 октября 2017 г.

Лайфхак №4. Альтернативный способ определения геозависимости запроса в Яндексе

Немногим более года назад я опубликовал в своём блоге довольно любопытный способ определения геозависимости выдачи Яндекса одним запросом. Вообще традиционный способ определения геозависимости подразумевает минимум два запроса – надо    сравнить выдачи для разных регионов. Там, где они совпадают, делается вывод о геонезависимости. Однако, в последнее время выдача даже в одном и том же регионе по одним и тем же запросам, сделанным в разные моменты времени, может различаться вследствие различных причин, например, примеси «многорукого бандита». Что может привести к неверному выводу о геозависимости геонезависимого запроса. Таким образом, задача определения геозависимости выдачи именно одним запросом достаточно актуальна. 
Способ, предложенный мною год назад, в общем-то пока еще является рабочим (правда, с некоторых пор несколько ограниченно – только для запросов, где есть быстроботовская примесь), однако он использует операторы языка запроса Яндекса, которые больше не содержатся в официальной документации и о прекращении поддержки которых было официально объявлено в январе этого года. Идея этого способа заключалась в том, что геозависимые запросы имеют в сниппетах подсветку жирным шрифтом топонима региона выдачи. Поэтому основная задача заключалась в том, чтобы сформировать выдачу таким образом, чтоб в сниппеты первых 50 результатов выдачи (максимальное количество результатов, которое можно получить одним запросом) входил топоним, чтобы по наличию или отсутствию его подсветки сделать вывод о геозависимости запроса. Тогда это удалось сделать с помощью двойного использования операторов отрицания ~~, а также оператора title: (поиск в заголовке документа) и оператора << (неранжирующее И), но именно этим операторам в числе прочих в последствии было отказано в поддержке. На момент написания статьи прежний способ работает весьма специфически – в выдаче показываются только документы из быстроботовской примеси, однако, по ним вполне можно сделать анализ. Однако нельзя гарантировать наличия быстроботовской примеси для конкретного запроса, да и нет никакой уверенности, что и быстроботовская примесь не исчезнет в любой момент, как исчезла органическая выдача, кстати, еще буквально пару недель назад имевшаяся в наличии по сформированному подобным образом запросу.
Таким образом, возникает потребность в более надежном способе, не использующем неподдерживаемые официально операторы языка запроса. При этом было бы логично, используя прежнюю идею, найти иной способ ее реализации, т.е. обеспечить наличие в топе результатов поиска гарантированного формирования сниппета с топонимом. 
Изучая свойства геозависимости запросов, я обратил внимание на тот факт, что добавление к исходному запросу через документированный оператор | (логическое ИЛИ) какого-либо достаточно редкого термина (т.е. имеющего достаточно большое значение IDF – обратной частоты встречаемости в коллекции документов) никак не влияет изменение геозависимости запроса. Это наблюдение я и решил положить в основу альтернативного решения поставленной задачи формирования нужного сниппета. 
Добавление к исходному запросу нового термина дает нам массу возможностей в этом плане. Достаточно найти релевантный этому термину сайт, содержащий в теге title своих страниц какой-нибудь топоним, и построить выдачу для соответствующего региона, суженную на этот конкретный сайт. Поясню на примере. 
Возьмем в качестве исходных запросов примеры из прошлогодней статьи – доставка пиццы (как пример геозависимого запроса) и вкусный борщ (как пример геонезависимого). Убедимся, что пока еще работающиий старый способ это подтверждает. У первого запроса топоним Москва подсвечивается жирным шрифтом в московской выдаче (lr=213):
А у второго – нет:
В качестве дополнительного термина с большим IDF я взял термин arsenaltula – часть доменного имени официального сайта футбольного клуба «Арсенал» из города Тулы (arsenaltula.ru), т.к. в теге title главной страницы этого сайта содержится топоним Тула. И сформировал суженные на этот сайт (с помощью get-параметра URL страницы выдачи site) выдачи для региона Тула (lr=15) для исходных запросов с добавлением через оператор | (логическое ИЛИ) дополнительного термина. В первом случае ожидаемо получил подсветку жирным шрифтом топонима Тула в сниппете:
А во втором – подсветки топонима ожидаемо не обнаруживается:
Безусловный плюс данного метода – это возможность гарантированного формирования нужного сниппета практически для любого исходного запроса. Чего, кстати, в общем случае не мог гарантировать предыдущий метод. Однако есть и минус – все-таки нам приходится модифицировать исходный запрос, и гарантировать в общем случае, что такая модификация не повлияет на геозависимость исходного запроса, нельзя. Наиболее находящимися в зоне риска мне представляются запросы, содержащие термины с большим IDF. Однако на данный момент мне случаев смены геозависимости запроса вследствие его подобной модификации обнаружить не удалось. Так что пока что я склонен считать данный метод вполне рабочим. И что, самое главное – очень удобным.
В заключении хотелось бы упомянуть об одном глюке поисковой выдачи Яндекса, который необходимо учитывать при применении методики. Оказывается, не для каждого региона осуществляется подсветка топонима в сниппете для геозависимых запросов. Так, к примеру, мне прислали пример, что этого не происходит в регионе Орёл (lr=10):


четверг, 7 сентября 2017 г.

Алгоритм «Королёв» - очередная порка сеошников откладывается


Как никогда весь «сеошный» мир ждал запуска нового алгоритма ранжирования, анонсированного на 22 августа 2017 года. Ещё бы, подобные анонсы – вещь для Яндекса абсолютно нетипичная, обычно они предпочитают не распространяться о своих планах, и сообщают об очередном релизе алгоритма ранжирования постфактум. Из редких анонсов вспоминается, пожалуй, лишь только анонс на Yet another Conference on Marketing-2013 платформы «Острова», жизненный путь которой, впрочем, оказался весьма печальным – в итоге она так и не смогла выйти из режима бета-тестирования и через два года «мучений» была закрыта.
В общем-то, традиционно ничего хорошего сеошники от новых алгоритмов Яндекса не ждут. Еще слишком свежи в памяти раны, нанесенные алгоритмами «Минусинск» и «Баден-Баден». Поэтому одним из основных вопросов, витавшим в многочисленных дискуссиях в профессиональных сообществах, был вопрос о том, в какое место будет нанесен удар в этот раз.
Однако после презентации нового алгоритма, получившего наименование «Королёв» (напомню, что с 2008-го года новые алгоритмы ранжирования в Яндексе называют в честь городов), стало понятно, что сеошникам можно на некоторое время облегченно выдохнуть. Область применения нового алгоритма практически не затрагивает традиционные сеошные сферы интересов, в первую очередь к которым можно отнести коммерческую выдачу. «Королёв» оказался логическим продолжением алгоритма «Палех», представленного в ноябре 2016 года. И призван обслуживать длинный хвост микрочастотных запросов, как правило, задаваемых на естественном языке.  Особенностью таких запросов является то, что релевантные им документы могут не содержать многих из слов, входящих в запрос. Это ставит в тупик традиционные алгоритмы ранжирования, основанные на текстовой релевантности. Решение найдено в виде использования нейросетей, которые обучаются в том числе и на поведении пользователей. Здесь многое упирается в вычислительные мощности, но сотрудники Яндекса утверждают, что им удалось успешно справиться с этой задачей с помощью новых подходов к построению архитектуры нейронной сети.
Вообще подобный подход к решению задачи ранжирования длинного микрочастотного хвоста запросов не нов. Еще в 2015-м году стало известно о технологии, применяемой поисковой системой Google для поиска ответов на многословные запросы, заданные на естественном языке – RankBrain. Эта технология, так же основанная на машинном обучении, позволяет распознавать наиболее значимые слова в запросах, и анализировать контекст, в котором осуществляется поиск. Что позволяет находить релевантные документы, которые не содержат всех слов запроса.
У Яндекса же качество ответов на многословные микрочастотные запросы на протяжении долгого времени откровенно хромало. Судя по всему, понимая это, сотрудники Яндекса решили вплотную сосредоточиться на решении данной задачи. И придают этому решению настолько важное значение, что сочли новую технологию достойной для полномасштабной презентации.
Что же касается сеошников, то они, почувствовав, что новый алгоритм проходит мимо сферы их интересов, ищут развлечение в поиске примеров плохой выдачи по микрочастотному хвосту запросов на естественном языке. Полагаю, что на реальное широкомасштабное исследование качества такой выдачи мало кто не сподобится, но вот сопровождаемых ехидными комментариями примеров плохого качества выдачи по единичным запросам, похоже, будет сколько угодно. Собственно, эти примеры уже начали появляться, и SEO-специалисты, особенно из числа затаивших обиду на Яндекс за те или иные его действия, с удовольствием их тиражируют в соцсетях и обсуждают в профессиональных сообществах.
Впрочем, длинный хвост микрочастотных многословных запросов на естественном языке вполне может быть интересен «выжигателям» информационной семантики – создателям так называемых инфосайтов «на все случаи жизни». В общем-то, они и так стараются под как можно большее количество известных им запросов, которые удается заполучить с помощью различных методов сбора семантики, организовать точное вхождение в свои тексты. Там же, где точных вхождений не будет, т.е. для запросов, которые не всосал «семантический пылесос» создателей инфосайтов или для которых им не удалось обеспечить точных вхождений в контент, и начинается вотчина «Королёва», который призван искать соответствия между запросами и ответами в том случае, когда между ними мало пересечений по ключевым словам. В таких случаях "Королёв" несомненно повысит требования к качеству контента, и реально интересные читабельные статьи будут еще больше выигрывать у сборников вхождений ключевых фраз, разбавленных водой, т.к. именно в таких статьях могут содержаться полезные для нового алгоритма сигналы. Ну, а всем остальным сеошникам действительно можно расслабиться – очередная порка откладывается. Жертв и разрушений нет.

Blog Archive

Технологии Blogger.