Сегодня мы расскажем о механизме, который позволяет поиску Яндекса находить именно то, что имел в виду пользователь, как бы кратко и небрежно он ни сформулировал свой запрос.

В мире поиска такой механизм называют расширением поискового запроса. Термин достаточно широкий, включает в себя переформулировки, синонимы, транслит и даже однокоренные слова (последние иногда ошибочно называют поддержкой морфологии).

Из каких частей этот механизм состоит? Что помогает ему угадывать? И почему на каждую из его редких ошибок приходятся тысячи запросов, на которых он сильно помог?


Почему нельзя просто так взять и расширить запрос.

Поиск по каталогу музыки — это задача, которую можно решать разными путями, как с точки зрения пользователя, так и технологически. Яндекс уже довольно давно научился искать и по названиям композиций, и по текстам песен. На сказанные голосом запросы про музыку мы тоже умеем отвечать в Яндекс.Поиске под iOS и Android, сегодня же речь пойдёт о поиске по аудиосигналу, а если конкретно — по записанному с микрофона фрагменту музыкального произведения. Именно такая функция встроена в мобильное приложение Яндекс.Музыки:



В мире есть всего несколько специализированных компаний, которые профессионально занимаются распознаванием музыкальных треков. Насколько нам известно, из поисковых компаний Яндекс стал первым, кто стал помогать российскому пользователю в решении этой задачи. Несмотря на то, что нам предстоит ещё немало сделать, качество распознавания уже сопоставимо с лидерами в этой области. К тому же поиск музыки по аудиофрагменту не самая тривиальная и освещённая в Рунете тема; надеемся, что многим будет любопытно узнать подробности.

Сегодня мы завершаем серию публикаций о фреймворке FML, в которых рассказываем о том, как и для чего автоматизировали в Яндексе применение технологий машинного обучения. В сегодняшнем посте мы расскажем:

• почему нужно следить за качеством факторов и как мы это делаем;
• как FML помогает в задачах распределённых вычислений над поисковым индексом;
• каким образом и для чего наши технологии машинного обучения уже применяются и могут быть применены как в Яндексе, так и вне его;
• какую литературу можно посоветовать для более глубокого погружения в затронутую проблематику.

Мы продолжаем серию публикаций о нашем фреймворке FML, который автоматизировал работу с машинным обучением и позволил разработчикам Яндекса использовать его в своих задачах проще и чаще. Предыдущий пост рассказывал о том, что такое функция ранжирования и как мы научились строить её, имея на входе лишь достаточно большое число оценок от асессоров и достаточно разнообразный набор признаков (факторов) документов по большому количеству запросов.

Из этого поста вы узнаете:

1. Почему нам нужно подбирать новую формулу ранжирования очень часто, и как именно нам в этом помогает FML;
2. Как мы разрабатываем новые факторы и оцениваем их эффективность.

Сегодня мы начинаем публиковать серию постов о машинном обучении и его месте в Яндексе, а также инструментах, которые избавили разработчиков поисковой системы от рутинных действий и помогли сфокусироваться на главном — изобретении новых подходов к улучшению поиска. Основное внимание мы уделим применению этих средств для улучшения формулы релевантности, и более широко — для качества ранжирования.

Сейчас всё больше мобильных приложений становятся геозависимыми. Одни просто не имеют смысла без знаний о местоположении пользователя, другие становятся с ним удобнее. Это так называемые Location Based Services (LBS): навигаторы, форскверы, инстаграмы с геотегами фотографий и даже приложения-напоминалки, которые срабатывают около конкретного места, например, рядом с офисом или магазином.

Для сервисов и приложений Яндекса мы создали собственную реализацию метода определения местоположения без GPS — Яндекс.Локатор. Он экономит время пользователя и делает наши приложения чуточку умнее. В Навигаторе и Картах она избавляет от ввода начальной точки маршрута, даже если вы на крытой парковке. А при выборе фильма в Киноафише или товара в мобильном Маркете помогает сразу показать, где их найти именно в вашем районе города. Ну и, разумеется, при поиске кафе и банкоматов — позволяет показывать вам сразу ближайшие, даже когда вы в метро.


Технологию мы давно открыли в виде бесплатного API. Сегодня хотим рассказать, как она устроена.

Информация о пробках появилась на Яндексе в 2006 году. Начинали мы с необходимого — научились строить схему загруженности городских улиц и учитывать текущую ситуацию при прокладывании маршрутов. Автомобилисты, ориентируясь перед выездом на эту информацию, уже могли сэкономить время в пути:


Затем, чтобы помогать водителям непосредственно во время движения, мы добавили в мобильные Яндекс.Карты (и, как следствие, в Яндекс.Навигатор) автоматическое перестроение маршрута. Приложения научились адаптировать маршрут при каждом заметном изменении ситуации в городе.

Собрав на десктопе и в мобильном информацию про «сейчас», мы перешли к решению вопроса «а как будет потом?»:


Первым шагом стала статистическая карта пробок — на ней можно посмотреть, как в среднем стоит и едет город в конкретный час конкретного дня недели. Мы предполагали, что у карты «обычных» пробок может быть полезный побочный эффект — возможность по ним спрогнозировать заторы на ближайшее время. Но практика показала, что усреднённая картина помогает примерно спланировать только, например, завтрашнюю поездку в аэропорт — но не помогает выезжающим сейчас избежать новых пробок. По нашим измерениям, даже в конце часового маршрута картина пробок на момент выезда обычно ближе к фактической, чем усреднение:



Неделю назад на Яндекс.Картах появилась возможность посмотреть изменения пробок в ближайший час — следующий наш шаг в решении вопроса про будущее. Для тех, кто в этом году не смог приехать на Yet another Conference, мы сегодня расскажем, что у нашего прогноза внутри, и как оно там оказалось.