13 апреля, в рамках профессиональной конференции веб-разработчиков РИТ++ состоялся доклад Павла Браславского (Яндекс) на тему «Что такое близкие запросы, как их найти и использовать». Участникам конференции представилась уникальная возможность подробно ознакомиться с методом переформулировки частотных запросов и объединения их в близкие пары, методом, который уже взят на вооружение Яндексом, и в самом ближайшем будущем сделает поиск еще более качественным и еще более полным. В своем докладе Павел Браславский подробно остановился на том, что же такое «близкие запросы», и даже привел некоторую их классификацию. Существуют близкие запросы, переформулированные при помощи уточнения запросов (золотое кольцо – золотое кольцо с бриллиантом), расширения (золотое кольцо – ювелирные украшения), запросы на ту же тему (mercedes – audi), при помощи смены поисковой цели (купить санки – детский мир), при помощи перевода (коралловый клуб – coral club). На основании этой классификации докладчиком был произведен анализ поисковой выдачи некоторых популярных поисковых систем, с результатами которого он познакомил своих слушателей. Из представленных наглядных материалов (презентация в Power Point) стало ясно, что идея выделять близкие запросы, для того, чтобы потом предлагать пользователям хорошие связки и хорошие переформулировки, далеко не нова, и на самом деле используется многими поисковыми сервисами. Так например, Yahoo достаточно давно уже начала это делать и делает очень основательно. После того как пользователь вводит запрос, ему предлагается два примера, потом даже появляется панель для поиска хорошего запроса, если пользователь хочет в это дело углубиться. Причем предлагаются разные варианты: кроме запросов, содержащих изначальные запросы, здесь еще предлагаются связанные концепции - как бы уже более сложные запросы, причем их можно листать, их много и ими можно долго заниматься. Ask тоже достаточно рано и основательно начал этим заниматься. Например, если взять поисковой запрос «chevrolet», то Ask нам предложат варианты запросов содержащих слово «chevrolet», а также близкие концепции «jc», «pontiac», «general motors» и так далее. Раньше у Ask было деление на более узкие и более широки запросы. Если ввести тот же «chevrolet» в поисковую строку у Bing, нам предложат совсем другие ассоциации, только модели этой марки, и ни одной подсказки запроса, который бы не содержал в себе изначальный запрос. У Google это еще одно интерфейсное решение, то есть располагается внизу. Так, например, на запрос «hermione granger» у нас есть связанные запросы – это «harry potter», «ginny weasley», «емма watson» ну и так далее. В Яндекс.Картинках тоже используется метод связанных запросов. Так, на запросы «гарри поттер» и на запрос «дэниел рэдклифф» мы увидим одинаковые картинки, потому что наверняка людям, задающим подобные запросы будут интересны все эти изображения. Необходимость использования разнообразных подсказок докладчик видит в том, что для обычного пользователя сформулировать хороший запрос – это далеко не просто. Между тем именно от корректной формулировки напрямую зависит качество и быстрота поиска. В качестве примера Павел привел вопрос, который предлагался на кубке по поиску в Яндексе несколько лет назад. Вопрос звучал так: «назовите глагол из вопроса, помещенного на борту транспортного средства подопечных Фатиха Терима на первенстве континента». И продемонстрировал выдержку из реального лога - запросы одного человека с промежутком в какие-то доли секунд: фатих терим - евро 2008 – автобус команды фатиха терима … Надпись гласила «Вместит ли автобус страсть Турции». Если вернуться к формулировке информационной потребности, то мы видим, что запросы далеко ушли от ее формулировки. И всем прекрасно известно из своего опыта, что часто так бывает, что начальная формулировка проблемы очень сильно отличается от того запроса, который помог найти нужную информацию. Где же можно искать такие связанные вопросы, чтобы предлагать их пользователям? Самый логичный шаг – искать там, где есть много запросов, то есть в логах запросов. На самом деле это не единственный путь, есть подходы и работы, которые используют тексты ссылок, то есть можно собрать по вебу пары: текст ссылки и страницы на которые этот текст ссылается, и как показали исследования, то переформулировки запросов тех ссылок получаются по качеству не хуже, чем по большому логу. Тем более что логи это тот тип данных, которые есть только у больших поисковых машин. Или можно искать не запросы как таковые, а прямо формировать запросы по корпусу текстов. Так, например, первая версия такого сервиса у Яндекса была сделана по текстам, по которым ищутся картинки. С каждой картинкой ассоциировался некоторый текст, в нем были выделены устойчивые словосочетания – двух и трехсловия, и это позволяло предлагать именно этот вариант на все запросы, состоящие из одного и двух слов, входящих в эти трехсловия. Это очень похоже на то, что предлагает Bing, где очень хорошо выстраивается весь модельный ряд по машинам. Это довольно ограниченный подход, так как он не позволяет перейти к переформулировке, к другому запросу, который не содержит слов начального запроса. Напрашивается вывод, что проще и логичней всего устанавливать семантическую близость по логу запроса. Как это делается? Первый простой путь – это запросы, похожие по словам и буквам, то есть те запросы, у которых много общих слов (отличаются на одно слово), они скорее всего похожи и близки. Есть, конечно, исключения («водка» и «царская водка»). Другой тип близости – это по кликам. Если у нас есть два запроса, и выдача, и одинаковые документы, которые были кликнуты по разным двум запросам, то можно считать, что эти запросы в каком-то смысле синонимичны, если по ним пользователи кликают на одни и те же документы. На самом деле можно развить эту мысль и считать близость запросов по текстуальной близости выдачи. Например, сравниваются тексты, составленные из сниппетов результатов поиска по двум запросам, насколько они похожи. Но это очень слабая связь, клики намного надежней. И третье, это близость запросов в сессиях. Если один пользователь задает вопросы последовательно, на коротком расстоянии во времени, скорее всего они про одно и то же. Именно этот вид близости запросов и кажется разработчикам Яндекса наиболее эффективным. Павел Браславский привел также список требований, предъявляемых к тому, какими должны быть подсказки в Яндексе. Во-первых, у них должен быть близкий смысл, второе – в них не должно быть ошибок, опечаток, обрезанных и неполных словосочетаний, без смысловых дублей (типа шарон стоун и шерон стоун), в-третьих, недопустимо, чтобы на невинные запросы выходили ответы с порно, матом и оскорбительной лексикой. Как это делает Яндекс. Использует время задания запроса, уникальный верификатор пользователя, собственно текст запроса и очень минимальную информацию о кликах, то есть кликал ли пользователь в выдаче по этому запросу или нет. Первый этап – это чистка лога. То есть берется лог и из него убираются запросы с опечатками (очень сложная задача), убираются запросы из внутренней сети Яндекса, потому что это очень смещенная выборка, и те подсказки, которые бывают под поисковой строкой в Яндексе. Далее выделяются сессии. Существует целая наука, как выделять сессии, но Яндекс использует достаточно простой подход. Берутся запросы от одного пользователя во времени, и просто считается, что те запросы, которые далеко друг от друга отстоят, они находятся в разных сессиях. Никто не пытается выделить тему сессии, во внимание принимается только расстояние между запросами у одного пользователя. Например, фондовые биржи – ценные бумаги – финансирование и т.д. Дальше выделяются пары. Затем нормализуются все запросы так, чтобы их можно было сравнивать. Это тоже возможность обогатить данные, то есть бороться с их разреженностью. Исключаются стоп-слова, капитализация, все приводится к нормальной форме и сортируется по алфавиту. После того, как данные обработаны, получены сессии и получены учитываемые пары, строится матрица частоты переходов «запрос-запрос». То есть, между какими запросами и сколько есть переходов. После этого взвешиваются эти переформулировки, и объективно оцениваются. Докладчик пояснил, что самая большая проблема в том, что раньше были «девушки», а сейчас «одноклассники». То есть это самые частотные запросы, которые присутствуют в очень большом количестве сессий, практически в любой. Соответственно вероятность перейти в них очень велика. Соответственно оценивается совместная встречаемость пар и абсолютная частота переходов от одного запроса к другому, вместе с частотой каждого из запросов. Если они часто встречаются в паре и редко поодиночке - это хорошо. Если они часто встречаются как в паре, так и часто в других сочетаниях, то это не очень хорошо. Значит, это просто частотный запрос. Далее уже по этому весу можно ранжировать все пары и отсечь все ненужное. Объективно, обычно достаточно 8 или 9 ассоциаций на один запрос. Соответственно и выстраивается идекс, то есть по каждому запросу у Яндекса обязательно есть его какие-то переформулировки. Отдельно Павел Браславский коснулся вопроса оценки, как наиболее интересного момента в задачах информационного поиска. Рассказал о том, как сравнивались составленные по представленному им методу ассоциации с кластерами запросов Яндекс.Директа. О том, куда чаще всего кликают пользователи. По результатам оценки выяснилось, что пользователи в основном кликают на другой запрос на ту же тему. Это примерно 50% всех выборов. Далее идет уточнение. Эти два вида запросов составили самый большой класс. А потом уже идут другие варианты. «Если сравнить то, что показывают подсказки и то, на что кликают, можно увидеть, что практически все совпадает, хотя это и несколько лукавая методология – мы показываем то, что у нас есть в логе, и соответственно у пользователя особенного выбора нет. Но на самом деле, агрегируя данные многих пользователей, убирая оттуда мусор и шум, мы даем пользователям именно то, что им хочется» - начал подводить итоги Павел Браславский. Он считает, что подсказка - показ возможных запросов пользователю, это сейчас более осторожная и более распространенная стратегия, чем более ранние и более продвинутые стратегии замены запроса пользователя или его самостоятельной переформулировки. Докладчик уверен, что можно и не спрашивая пользователя заменить запрос, и это как раз и позволит учесть все разнообразие запросов. То есть у каждого пользователя будет дальше свой путь, он сам решит, куда дальше искать. Использование семантически близких запросов в общем и целом значительно улучшит качество поиска, потому что связав некорректную формулировку запроса с более корректной, Яндекс в обоих случаях выдаст пользователю наилучшие результаты. Ибо они будут показаны не только по первоначальному запросу, но и по хорошей переформулировке. Все это где-то и в чем-то уже реализовано Яндексом, но по большому счету – это ближайшее будущее информационного поиска, то, к чему мы стремимся.
Vova
