Федор Романенко. Поиск: что там внутри? Я.Студент в ВШЭ

2. Поиск: что там
внутри?
Федор Романенко
Качество поиска Яндекса,
ведущий менеджер-эксперт

3. Поиск
Как он ищет?

4. Как искать быстро?
Вы ищете во всем интернете? Так быстро?
• нет, мы скачиваем странички, обрабатываем и
кладем в индекс
• по индексу ищем быстро: 100мс, 200 млн. / день
• но неизбежна задержка: скачивание, обработка,
выкладывание на поиск, главное - переагрегация
4

5. Структура поиска
5

6. Поиск - фазы
•
•
•
•
•
•
•
•
6
подготовка индекса
поиск по инвертированному индексу
фильтрация с прюнингом для широких
легкое ранжирование - фастранк
ранжирование – матрикснет
смешивание TopN
сниппеты
классификация запроса и построение выдачи

7. Структура инвертированного индекса
Было: сортировка по документам и позициям
(word, d, s, w, f)+
Стало: по словам, потом - документам и позициям
(word, (d, s, w, f)+ )+
Классическая структура инвертированного индекса
Ключи:
prefix-compression( (key, offset)+ )
Скип-лист:
(d, offset)+
Инвертированный индекс:
( differential-compression( posting lists ) )+
7

8. Поиск – дерево запроса
(студент && ( мгу || (московский && государственный &&
университет) ) )
8

9. Поиск – ленивые итераторы
Дерево ленивых итераторов - идем по номерам документов по
возрастанию:
• узел - curDoc :="мин. номер документа >= curDoc"
• И - curDoc:=Max(curDoc(i))
• ИЛИ - curDoc:=Min(сurDoc(i))
(
[2, 3, 5,
13
[2,
6,
21
) и
[
3,
7,
14, 21
=>
[
3,
21
] или
]
]
]
Результат: документ + набор “хитов”
9

10. Фильтрация
Документ нашелся = допущен в ранжирование
• есть нужные слова запроса в тексте или
ссылках
• стоят на нужном расстоянии / подряд
• кворум для длинных запросов:
sum(idf(hits)) >= Q(sum(idf(query words)), query)
10

11. Оптимизации
Для одной машины (индекс 3M документов)
Прюнинг (для широких запросов)
• документы отсортированы по убыванию статранка
• рассматриваем не более 50K отфильтрованных
• ограничиваем время выполнения
ФастРанк (легкая формула)
• считаем легкую формулу на легких факторах
• отправляем в ранжирование Top 1000 лучших
11

12. Ранжирование
•
•
•
•
12
считаем все тяжелые факторы, всего 800
МатриксНет: 10K бинарных деревьев глубины 6
получаем ранг документа
выбираем Top10 по рангу

13. Метапоиск: слияние, кеширование и
сниппеты
•
•
•
•
•
13
управляем нагрузкой и репликами
собираем Top10 с каждой машины
считаем Top10(Top10(i))
кешируем
запрашиваем сниппеты для Top10

14. Построение выдачи
• собираем TopN от вертикальных поисков
(свежесть, видео, картинки)
• считаем классификаторы по
– оффлайн данным
– запросу
– ответам
– статистике ответа
• строим выдачу из вертикалей и
колдунщиков
14

15. Балансировка нагрузки
15

16. Надежность и производительность
• достигается распределением нагрузки и репликацией
• сетевые балансеры направляют запросы в 7 ДЦ (по IP)
• в ДЦ запрос попадает на 1 из 200 метапоисков (по IP)
• метапоиск отправляет на 1 из 100 кеширующих
метапоисков (по запросу)
• метапоиски мониторят загрузку и производительность
базовых поисков
• выбирают 2000 базовых из 10 реплик
• перезадают запрос, принимают решение о выдаче
частичного результата
16

17. Качество поиска
Разве еще не всё написали?

18. История
• Яндекс-поиск в интернете – 1997
• рост отдела качества поиска – 2006
• MatrixNet – 2009
• Турция – 2011
• 1000 инженеров – 2013
18

19. Алгоритм поиска?
Нет одного алгоритма, их десять тысяч
•
•
•
•
•
•
•
•
19
обход и индексация интернета
производительность
лингвистика
разработка факторов и анализ данных
очистка данных и антиспам
определение целевой метрики
алгоритмы машинного обучения
смешивание выдачи

20. Качество
• у почти всех алгоритмов есть "качество", т.е.
выбор из нескольких вариантов – плохих и
получше
• мы непрерывно занимаемся улучшением
качества
• будем им заниматься всегда
• качество измеряется числовыми метриками
• метрика хороша, если показывает наше
плохое качество
20

21. Базовая метрика качества поиска
Оценка «удовлетворенности» пользователя
Для ответа:
• Gain: rel(i) - релевантность одного документа [0..1]
• оценки: IR (0.0), R- (0.07), R+ (0.14), U (0.40), V (0.61)
Для десятки:
• Cumulative G: sum(1..10, rel(i)) - сложим для десятки
• Discounted CG: rel(1) + sum(2..10, rel(i) / log2(i)) - с
дискаунтом за позицию
• Normalized DCG - DCG / IDCG - нормализуем на
достижимый максимум
Для поиска:
• среднее по репрезентативной корзине запросов
21

22. Метрика pFound
Каскадная модель удовлетворенности
пользователя
• с вероятностью R удовлетворяется ответом
• с вероятностью (1-R)*0.15 устает
• с вероятностью (1-R)*0.85 читает дальше
22

23. Обучение с учителем
• асессоры оценивают ответы по инструкции
• инструкция (150 страниц) описывает наше
продуктовое видение
• 1000 асессоров
• 10 млн. ручных оценок за 2 года
• настоящих запросов все равно больше (200 млн/д)
• учим машину на примерах
23

24. Модель ранжирования
• факторы ранжирования (числа), считаются для пары
(запрос, документ)
• на них считаем формулу релевантности, берем top10
• модель: (f1(q, d), f2(q, d), ... , fn(q, d)) -> rank(q, d)
• специфическая модель: не призвана отражать реальный
мир, просто сложная штука с кучей параметров
24

25. Модель ранжирования MatrixNet
Сумма 10K «oblivious» деревьев решений глубины 6
25

26. MatrixNet - особенности
• количество параметров огромно: 10K * (6*2+64) ~ 1M
• сложная и гибкая, но не переобучается
...
-4025627,483990,-36437960,39979596,
-92842056,-50086892,-100233272,243162224,
-22282850,57163664,-24991620,-9889194,
...
vars[5699]
vars[5700]
vars[5701]
vars[5702]
=
=
=
=
fFactorInt[376]
fFactorInt[376]
fFactorInt[376]
fFactorInt[376]
...
,{376, .0f}
,{376, 0.6251018047f}
,{-1, .0}
,{376, 0.05682743713f}
,{376, 0.4546194971f}
...
26
>
>
>
>
1060970280 ? 1 : 0; // 0.738757
1061923687 ? 1 : 0; // 0.795584
1049721454 ? 1 : 0; // 0.284137
948291011 ? 1 : 0; // 6.37877e-05

27. Машинное обучение ранжирования
• сталкиваем Модель Пользователя и Модель
Ранжирования
• подбираем параметры модели ранжирования
• максимизируем метрику жадной оптимизацией
• MLR находит скрытые закономерности в данных и
ожидания пользователей в метрике
• метрика = удовлетворение модельного юзера,
работающего с моделью ранжирования
• использует возможность посчитать счастье на огромном
кол-ве отличающихся поисков без экспериментов
27

28. Много данных
Никак не влезет на одну машину

29. Откуда данные?
•
•
•
•
•
каждый ответ поиска (200 млн/день) и клики записываются
логи всех сервисов
данные от браузера и счетчиков Метрики
от партнеров
любые данные могут быть полезны в качестве
Огромная коллекция – 20ПБ (20 000 000 000 000 000 байт),
нужно уметь с ней работать!
29

30. Распределенные вычисления
•
•
•
•
•
•
большинство таблиц не влезает на одну машину
нужны распределенные вычисления
вручную можно внедрить 5 алгоритмов за карьеру
нужна надежность хранения
проблема эффективной загрузки серверов
общий кластер -> приоритизация и планирование
500 задач одновременно на 2000 серверах!
30

31. Парадигма MapReduce
•
•
•
•
входная таблица с независимыми записями
Map(record) -> (key, value)+
сортировка по key
Reduce(key, (value)+) -> result(key)
• Map - выборка нужных данных, определение ключей
• Reduce - агрегация по ключу
31

32. MapReduce
Детальная схема MapReduce процесса
32

33. Пример WordCount
Найти 100 самых частотных слов в коллекции документов
• На входе: таблица с документами Docs
• Map: считаем слова в документе, =>
(word, tf)
• Reduce1: для word суммируем частоты tf =>
(hash(word) % 1000, (word, count))
• Reduce2: для 0..999 вычисляем Top100 самых частотных =>
("result", (word, count)+)
• Reduce3: сливаем 1000 Top100 пар (word, count) =>
("output", (word, count)+)
Простая реализация без оптимизаций (не тестировалась ;)
mapreduce -map "tr -cs '[:alnum:]' 'n'" -reduce "uniq –c"
–src Docs –dst Stat
mapreduce –read Stat | sort +0nr | head -n 100
33

34. Реализация MapReduce
Yandex MapReduce:
• тройная репликация или Reed Solomon Code
• сжатие чанков ZIP (сжатие 4.31)
• последовательная почанковая обработка
• умный шедулер
Real-Time MapReduce:
• нужен для свежести и RT-персонализации
• инкрементальное обновление результата при изменении
входных данных
• мгновенная инвалидация и пересчет по цепочке
• RT база данных в основе
34

35. Свежесть и разнообразие
Что вы имели в виду?

36. Свежесть
Страница в интернете, почему же она не находится?
Поиск страницы по узкому запросу:
• найти и проиндексировать
Поиск новостей на свежую тему:
• не так просто, само не найдется!
• свежее составляет 0.1% от базы, но нужно в 20% случаев
• не накопились факторы: ссылки и пользовательское
поведение
36

37. Real-Time робот
•
•
•
•
•
•
распределенная RT-архитектура
непрерывное обновление веб-графа
CrawlRank (aka OPIC) алгоритм - RT PageRank
адаптивный переобход хабов для поиска нового
десятки фидов об обновлениях
RT-индексация и поиск
Выкладываем лучшие документы с задержкой в
секунды
37

38. Новости по широкому запросу
• найти новости по [навальный] ранжированием не
получится
• вероятность << 0.1%
• если были новости, то нужно много свежего
• если нет, то свежее - вряд ли хорошее
• нужен "семантический" триггер
• величина "свежего интента“ - вероятность, что
пользователь с таким запросом хочет свежее
– [захват автобуса норвегия] = 90%
– [цискаридзе] = 40%
– [задорнов] = 10%
38

39. Детектор свежести
• классификатор наличия потребности в свежем
• самый большой в поиске, на 150 факторах:
– изменение частоты запросов
– появление новостных сюжетов
– увеличение кол-ва релевантных свежих
– клики на свежее
– всплеск слова в Твиттере
– новостные слова (взрыв, заявил, путин)
Структура свежего потока (доля, величина интента)
• 10% - немного свежего (0.2)
• 6% - много свежего (0.4)
• 2% - только свежее (0.9)
39

40. Разнообразие при неоднозначности
• один запрос - одна выдача - много интентов
• удовлетворить разных пользователей одной
страницей => разнообразие
• смешиваем вертикали: веб-поиск, свежесть, видео,
региональная ...
• метрика WidepFound (расширение pFound):
– вероятности интентов
– релевантности документов для интентов
40

41. Спектр - универсальное разнообразие
• учимся понимать запросы [объект потребность]:
[битлз mp3 скачать]
• считаем вероятности потребностей по логам
запросов
• смешиваем по запросу [битлз] выдачи для
–
–
–
–
41
[битлз слушать онлайн]
[битлз видео]
[битлз фото]
[битлз википедия]

42. Это для начала!

43. Федор Романенко
Ведущий менеджер-эксперт
качества поиска
+7-903-6841530
fedor57@yandex.ru
Спасибо!