Введение

[kirill_ir]

Часть I · ~2 ч · Сложность: (базовый) · Пререквизиты: нет

Обзор модуля

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

Мы разделим систему на две принципиально разные половины: офлайн-конвейер (всё, что происходит заранее, без пользователя — обход веба, нормализация документов, построение индекса) и рантайм-обслуживание (всё, что случается за доли секунды после нажатия Enter — разбор запроса, поиск кандидатов, ранжирование, сборка страницы). Это деление — главный ментальный инструмент курса: почти любой вопрос «а где это происходит?» сводится к «офлайн или рантайм?».

Место модуля в сквозном конвейере курса — обход → индекс → факторы → ранжирование → выдача → постобработка → измерение — особое: он не описывает одно звено, а даёт карту всех звеньев сразу. Здесь же вводится сквозной приём «путь одного запроса», которым мы свяжем все 22 модуля: одна и та же история (пользователь что-то спросил) будет прослеживаться от момента, когда нужный документ только попал в индекс, до того, почему он оказался на конкретной позиции выдачи.

После модуля студент сможет на верхнем уровне объяснить устройство поисковой системы, отличать офлайн-обработку от рантайма, называть звенья конвейера в правильном порядке и понимать, какой трек курса (Студент / Инженер / SEO / Смешанный) ведёт куда.

Как читать по трекам

• Студент CS — читать целиком. Это фундамент терминологии; без него Части II–IV будут восприниматься фрагментарно. Лабы 0.2 и 0.3 обязательны.
• Инженер поиска/ML — читать целиком, особое внимание главе 0.2 (граница офлайн/рантайм, бюджеты латентности) и инженерным заметкам. Лаба 0.2 — must.
• SEO-специалист — читать целиком; это самый важный для вас вводный модуль. SEO-врезки покажут, на какие звенья конвейера вы реально влияете, а на какие — нет. Вывод формул в курсе можно будет смотреть обзорно, но карту звеньев нужно держать в голове.
• Смешанный/руководитель — читать целиком. Этого модуля плюс Части I часто достаточно, чтобы говорить с командой поиска на одном языке.

Карта модуля

• 0.1. Задача веб-поиска: масштаб, латентность, релевантность (базовый) — что именно мы решаем и почему это трудно: три фундаментальных ограничения и их конфликт.
• 0.2. Анатомия поисковой системы: офлайн-конвейер vs рантайм-обслуживание (базовый) — две половины системы, их компоненты и граница между ними.
• 0.3. Карта курса и сквозной приём «путь одного запроса» (базовый) — как устроен конвейер «обход → … → измерение», что такое треки и как мы будем прослеживать один запрос через весь курс.

Глава 0.1. Задача веб-поиска: масштаб, латентность, релевантность (базовый)

Цели обучения

После главы студент сможет:

• сформулировать задачу веб-поиска как формальное отображение «запрос → упорядоченный список документов»;
• назвать три фундаментальных ограничения (масштаб, латентность, релевантность) и объяснить, почему они конфликтуют;
• оценить порядки величин (сколько документов, сколько времени на ответ) и понять, почему «просто перебрать всё» невозможно;
• отличать релевантность от смежных понятий (полнота, точность, удовлетворённость пользователя).

Конспект

Что такое поиск как задача

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

Формально. Пусть C — корпус документов (collection), q — запрос пользователя (query). Поисковая система реализует функцию

Код: Выделить всё

search(q, C, u, ctx) → (d_1, d_2, …, d_k)

где результат — упорядоченный список из k документов (обычно k ≈ 10 на первой странице), u — пользователь (его язык, регион, история — если используется), ctx — контекст (время, устройство, тип сети). Ключевое слово — упорядоченный: поиск отличается от простой фильтрации тем, что обязан не только найти подходящее, но и расставить найденное по убыванию полезности. Перестановка двух верхних результатов — это уже другая, обычно худшая, выдача.

Полезность документа d для запроса q называют релевантностью rel(d, q, u, ctx). Идеальная система упорядочивала бы документы строго по убыванию rel. Вся остальная сложность курса — это попытки приблизить неизвестную нам функцию rel дешёвыми, быстрыми, масштабируемыми оценками.

Три фундаментальных ограничения

Веб-поиск трудно реализовать не из-за одного препятствия, а из-за трёх одновременных, тянущих в разные стороны.

Код: Выделить всё

Ограничение                |  Суть                                                        |  Грубый порядок величины                       |  Что ломается, если игнорировать
---------------------------+--------------------------------------------------------------+------------------------------------------------+--------------------------------------------------------------
Масштаб (scale)            |  Корпус огромен и постоянно меняется                         |  миллиарды–сотни миллиардов документов         |  нельзя хранить «как есть», нельзя обходить линейно
Латентность (latency)      |  Ответ нужен почти мгновенно                                 |  бюджет на запрос — десятки–сотни миллисекунд  |  пользователь уходит; нельзя «честно» оценить каждый документ
Релевантность (relevance)  |  «Полезность» субъективна и зависит от запроса/пользователя  |  нет точной формулы                            |  технически быстрый, но бесполезный ответ

Интуиция. Представьте библиотеку из миллиардов книг, в которой каждую секунду появляются новые. Вам дают полсекунды и просят принести три самые полезные книги по фразе из двух слов. Перебрать все книги нельзя (масштаб + латентность). Понять «полезные для кого и зачем» — отдельная загадка (релевантность). Вся инженерия поиска — это компромисс между этими тремя.

Почему нельзя просто перебрать всё. Допустим, оценка релевантности одного документа стоит хотя бы 1 микросекунду. При корпусе в 10 миллиардов документов честный перебор одного запроса занял бы около 10^10 × 10^-6 = 10^4 секунд ≈ 2,7 часа. Пользователь ждёт сотни миллисекунд. Разрыв — на семь-восемь порядков. Отсюда два фундаментальных приёма курса:

1. Предвычисление (офлайн). Тяжёлую работу (обход веба, разбор документов, построение индекса) делают заранее, до запроса. Это глава 0.2 и вся Часть II.
2. Каскад и отсечение (рантайм). В реальном времени систему строят так, чтобы дорогие методы применялись только к маленькому числу кандидатов. Грубый дешёвый фильтр оставляет тысячи из миллиардов; средний — сотни; дорогая модель ранжирует десятки. Это «воронка» каскада (Модуль 12).

Инженерная заметка. Латентность измеряют не средним, а хвостами — p95, p99 (95-й и 99-й перцентили). Если средний ответ 80 мс, но один из ста запросов отвечает за 2 секунды — для пользователя система «тормозит». Поэтому бюджет латентности раздают по звеньям конвейера жёстко: например, понимание запроса — столько-то мс, выборка кандидатов — столько-то, ранжирование — столько-то, сборка страницы — остаток. Превысил бюджет на этапе — отдаёшь, что успел.

Релевантность ≠ полнота, точность и удовлетворённость

Новички часто путают близкие понятия. Разведём их.

• Точность (precision) — какая доля выданного действительно релевантна. «Сколько мусора в выдаче».
• Полнота (recall) — какая доля всего релевантного в корпусе попала в выдачу. «Сколько хорошего мы упустили».
• Релевантность — свойство конкретного документа относительно запроса, не свойство списка.
• Удовлетворённость пользователя — итоговая цель: решил ли человек свою задачу. Может расходиться с формальной релевантностью (релевантный, но медленно грузящийся или недоверенный документ оставит пользователя недовольным).

Пример. Запрос «лук». Документ про растение (овощ) и документ про оружие (для стрельбы) оба могут быть «релевантны» — но какому именно намерению? Один правильный ответ для всех не существует; релевантность зависит от пользователя и контекста. Хорошая выдача по неоднозначному запросу часто показывает оба толкования (это уже про разнообразие — Модуль 15).

SEO-врезка. Запомните: вы оптимизируете не «позицию вообще», а релевантность и полезность под конкретное намерение конкретного запроса. Документ, идеально отвечающий на одно намерение, может быть бесполезен для другого толкования того же слова. Понимание намерения запроса (Модуль 5) для SEO важнее, чем плотность ключевых слов.

Частые заблуждения

Заблуждение. «Поисковик во время запроса просматривает весь интернет.» Нет. Во время запроса он не видит ни одного «живого» сайта — он работает только с заранее построенным индексом (снимком, сделанным офлайн). Если страница не обошлась и не проиндексировалась раньше, в выдаче её не будет, как бы она ни была релевантна.

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

Лаба / практика

Оценка бюджетов и порядков (без кода, ~30 мин).

Дано: корпус N = 5×10^10 документов; целевой бюджет ответа p99 = 300 мс; на ответ уходит сетевой round-trip ~50 мс и сборка страницы ~20 мс.

Шаги:

1. Сколько миллисекунд остаётся «внутренним» этапам (понимание запроса + выборка + ранжирование)?
2. Если честная оценка одного документа стоит 0,5 мкс, сколько документов можно успеть оценить «дорогой» моделью в оставшемся бюджете, если на неё выделено 40% внутреннего времени? Сравните с N.
3. Во сколько раз нужно сократить число кандидатов на дешёвых этапах, чтобы дорогой этап уложился в бюджет? Запишите это как «воронку»: N → ? → ? → дорогая модель.

Ожидаемый результат: таблица бюджетов по этапам и осознание, что дорогая модель видит на 7–8 порядков меньше документов, чем есть в корпусе.

Критерий «сделано»: посчитан остаточный бюджет, оценено число «дорого оцениваемых» документов, нарисована воронка отсечения с конкретными числами.

Контрольные вопросы

1. Запишите задачу поиска как функцию. Почему её выход — упорядоченный список, а не множество?
2. Назовите три фундаментальных ограничения веб-поиска и приведите пример конфликта между двумя из них.
3. Почему латентность измеряют по p99, а не по среднему? Приведите числовой пример, где среднее «врёт».
4. Чем точность отличается от полноты? Может ли выдача иметь высокую точность и низкую полноту одновременно?
5. Оцените порядок величины: сколько займёт честный перебор корпуса в 10^10 документов при 1 мкс на документ?
6. Почему релевантность нельзя задать одной формулой на все запросы? Приведите неоднозначный запрос.
7. (Применение) Пользователь жалуется: «поиск выдаёт мусор сверху, но если долистать — там есть хорошее». Это проблема точности, полноты или ранжирования?

Глава 0.2. Анатомия поисковой системы: офлайн-конвейер vs рантайм-обслуживание (базовый)

Цели обучения

После главы студент сможет:

• разделить поисковую систему на офлайн-конвейер и рантайм-обслуживание и объяснить, что относится к каждой половине;
• перечислить основные компоненты обеих половин и их назначение;
• объяснить роль индекса как «контракта» между двумя половинами;
• определять для произвольной задачи («дедупликация», «разбор опечатки», «сборка сниппета»), в какой половине она решается.

Конспект

Две половины одной системы

Главная архитектурная идея: поисковая система живёт в двух временах.

• Офлайн-конвейер (offline / batch) работает без пользователя, заранее, на огромных потоках данных. Его цель — превратить хаотичный, постоянно меняющийся веб в компактную, быстро опрашиваемую структуру — индекс. Здесь допустимы минуты и часы обработки; масштаб важнее задержки.
• Рантайм-обслуживание (online / serving) работает с пользователем, по одному запросу, в жёстком бюджете десятков–сотен миллисекунд. Его цель — по запросу быстро достать кандидатов из индекса, оценить и собрать страницу. Здесь задержка важнее полноты обработки.

Интуиция. Офлайн — это как заранее составить и разложить по полкам каталог библиотеки: долго, тщательно, один раз (и регулярно обновляя). Рантайм — это библиотекарь, который по вашему вопросу мгновенно бежит к нужной полке. Если каталог плохой, никакой быстрый библиотекарь не спасёт; если каталог идеальный, но библиотекарь думает час — вы уйдёте.

Граница между половинами — это индекс

Две половины общаются почти исключительно через индекс (и сопутствующие предвычисленные структуры: ссылочные метрики, эмбеддинги документов, признаки качества). Индекс — это контракт: офлайн обязуется положить туда всё, что рантайму понадобится для быстрого ответа; рантайм обязуется не лезть в «живой» веб.

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

Компоненты офлайн-конвейера

Код: Выделить всё

            ОФЛАЙН (заранее, без пользователя)
┌───────────────────────────────────────────────────────────┐
│  Веб → [Планировщик обхода] → [Загрузчик] → сырые страницы  │
│         ↓                                                   │
│  [Парсер/извлечение] → текст, ссылки, метаданные            │
│         ↓                                                   │
│  [Каноникализатор] → устранение дублей, выбор канона        │
│         ↓                                                   │
│  [Анализ ссылочного графа] → ссылочные метрики              │
│         ↓                                                   │
│  [Индексатор] → ОБРАТНЫЙ ИНДЕКС + хранилище признаков       │
└───────────────────────────────────────────────────────────┘
                          ↓ (публикация)
                    ░░░ ИНДЕКС ░░░  ← контракт между половинами

• Планировщик обхода (crawl scheduler) — решает, что и когда загружать: новые URL, переобход изменившихся, бюджет вежливости к сайтам (Модуль 2).
• Загрузчик (fetcher / crawler) — собственно скачивает страницы, уважая правила сайтов.
• Парсер и извлечение — достаёт из сырого HTML текст, ссылки, структуру, метаданные.
• Каноникализатор (canonicalizer) — обнаруживает дубликаты и почти-дубликаты, выбирает один «канонический» адрес (Модуль 3). Без этого индекс распухает от копий.
• Анализ ссылочного графа — вычисляет статические метрики авторитетности (например, в духе PageRank) по графу ссылок (Модуль 7).
• Индексатор (indexer) — строит обратный индекс (inverted index): отображение «слово → список документов, где оно встречается», плюс хранилище признаков документов. Это сердце офлайна (Модуль 4).

Компоненты рантайм-обслуживания

Код: Выделить всё

            РАНТАЙМ (на каждый запрос, ~десятки–сотни мс)
запрос q
   ↓
[Понимание запроса] → нормализация, опечатки, намерение, расширение (Модуль 5)
   ↓
[Выборка кандидатов / L0] → достать из индекса тысячи кандидатов (дёшево)
   ↓
[Каскад ранжирования L1→L2→L3] → отсекать и переоценивать всё дороже (Модуль 12)
   ↓
[Постранжирование] → группировка, разнообразие, антиспам (Модули 15, 16)
   ↓
[Сборка выдачи / SERP] → сниппеты, федерация источников, верстка (Модуль 14)
   ↓
страница пользователю
   ↓
[Логирование/измерение] → клики, эксперименты (Модули 11, 19) → обратно в офлайн

• Понимание запроса (query understanding) — нормализует запрос, исправляет опечатки, определяет язык и намерение, при необходимости расширяет синонимами.
• Выборка кандидатов (candidate retrieval, L0) — быстрый, дешёвый проход по индексу: из миллиардов остаётся несколько тысяч потенциально подходящих.
• Каскад ранжирования (L1→L3) — последовательность всё более точных и дорогих оценок на всё меньшем числе документов. Грубая модель режет тысячи до сотен, точная — сортирует десятки.
• Постранжирование (post-ranking) — правила поверх скоров: убрать дубли, обеспечить разнообразие, отфильтровать спам, применить ограничения.
• Сборка выдачи (SERP assembly) — формирование страницы: сниппеты, объединение результатов из разных источников (федерация), специальные блоки.
• Логирование и измерение — фиксация поведения (клики, время) — это «топливо» для обучения моделей и экспериментов, и оно замыкает цикл, питая офлайн.

Инженерная заметка. Граница не идеально жёсткая. Существует «почти-реальное время» (near-real-time): свежие документы (новости, посты) должны попадать в индекс за секунды, минуя медленный пакетный конвейер. Это отдельная ветка — реалтайм-индексация (Модуль 17). Но даже там сохраняется принцип: пользователь спрашивает индекс, а не живой веб.

Таблица: офлайн против рантайма

Код: Выделить всё

Признак              |  Офлайн-конвейер                    |  Рантайм-обслуживание
---------------------+-------------------------------------+---------------------------------
Когда работает       |  заранее, постоянно                 |  в момент запроса
Видит пользователя?  |  нет                                |  да
Бюджет времени       |  минуты–часы                        |  десятки–сотни мс
Что оптимизирует     |  полноту и качество обработки       |  задержку и точность ответа
Главный продукт      |  индекс и предвычисленные признаки  |  упорядоченная страница выдачи
Масштаб за раз       |  весь корпус                        |  один запрос → тысячи кандидатов

SEO-врезка. Карта «офлайн/рантайм» — это карта вашего влияния. На офлайн вы влияете тем, достижим ли и понятен ли ваш сайт обходу и каноникализации (доступность, отсутствие дублей, корректная разметка). На рантайм-ранжирование вы влияете лишь косвенно — через качество контента и сигналы, которые уже лежат в индексе. Запрос «почему меня нет в поиске» почти всегда решается в офлайн-половине (не обошли / посчитали дублем / не проиндексировали), а не «низким ранжированием».

Частые заблуждения

Заблуждение. «Индекс — это просто копия интернета.» Индекс — это переработанная структура (прежде всего обратный индекс «слово → документы» плюс признаки), оптимизированная под быстрый ответ, а не складированные копии страниц. По нему нельзя «погулять как по сайтам».

Заблуждение. «Если изменить страницу, выдача обновится сразу.» Изменение увидят только после переобхода и переиндексации — это офлайн-процесс с собственным расписанием. Между правкой и её влиянием на выдачу есть лаг.

Лаба / практика

Классификация задач по половинам (~30 мин).

Дан список из 12 задач поисковой системы (вперемешку):
исправление опечатки в запросе; дедупликация зеркал сайта; построение списка «слово → документы»; выбор сниппета для показа; расчёт ссылочной авторитетности; определение намерения запроса; отсечение спам-страниц из топа; скачивание новой страницы; расширение запроса синонимами; объединение результатов из веб- и видео-источников; вычисление эмбеддинга документа; A/B-эксперимент над новой моделью ранжирования.

Шаги:

1. Для каждой задачи отметьте: офлайн / рантайм / граница (оба).
2. Для трёх задач, отнесённых к рантайму, оцените, дорогая она или дешёвая (можно ли применять ко всем кандидатам или только к топу).
3. Найдите хотя бы одну задачу, которая «питается» рантайм-данными, но исполняется офлайн (подсказка: обучение моделей на логах).

Ожидаемый результат: таблица из 12 строк с обоснованием в одну фразу.

Критерий «сделано»: каждая задача классифицирована, отмечены пограничные случаи, найден цикл «рантайм-логи → офлайн-обучение».

Контрольные вопросы

1. Назовите по три компонента офлайн-конвейера и рантайм-обслуживания и их функции.
2. Почему индекс называют «контрактом» между половинами? Что будет, если офлайн «забыл» положить нужный признак?
3. Что физически просматривает система в момент запроса — веб или индекс? Какое следствие это имеет для новой страницы?
4. В какой половине решается дедупликация и почему именно там?
5. (Применение) Страница доступна, но в поиске её нет уже неделю. С какой половины начнёте диагностику и почему?
6. Чем отличается «почти-реальное время» от классического пакетного офлайна? Какой принцип при этом сохраняется?
7. Почему дорогую модель ранжирования нельзя применить к выборке кандидатов целиком?

Глава 0.3. Карта курса и сквозной приём «путь одного запроса» (базовый)

Цели обучения

После главы студент сможет:

• воспроизвести по памяти конвейер курса «обход → индекс → факторы → ранжирование → выдача → постобработка → измерение» и сопоставить звенья с модулями;
• объяснить, что такое сквозной приём «путь одного запроса» и зачем он нужен;
• выбрать для себя учебный трек и маршрут по модулям;
• проследить упрощённый путь конкретного запроса через все звенья.

Конспект

Конвейер курса как нить повествования

Весь курс нанизан на один конвейер:

Код: Выделить всё

обход → индекс → факторы → ранжирование → выдача → постобработка → измерение

Это не случайный порядок, а причинно-следственная цепочка: нельзя ранжировать то, чего нет в индексе; нельзя построить индекс без обхода; нельзя улучшать систему без измерения. Сопоставление звеньев с частями курса:

Код: Выделить всё

Звено конвейера               |  Что происходит                               |  Где в курсе
------------------------------+-----------------------------------------------+--------------------------------
Обход (crawl)                 |  находим и скачиваем документы                |  Часть II: Модули 2–3
Индекс (index)                |  строим обратный индекс и хранилище           |  Часть II: Модуль 4
Факторы (signals)             |  вычисляем сигналы: текст, ссылки, поведение  |  Части III–IV: Модули 5–11
Ранжирование (ranking)        |  каскадом упорядочиваем кандидатов            |  Часть IV: Модули 9, 10, 12, 13
Выдача (SERP)                 |  собираем страницу из источников              |  Часть V: Модули 14–15, 17–18
Постобработка (post-ranking)  |  антиспам, качество, ограничения              |  Часть V: Модуль 16
Измерение (evaluation)        |  метрики, эксперименты, обратная связь        |  Часть VI: Модули 19–21

Интуиция. Держите эту строчку из семи слов в голове как оглавление всего поиска. Любой новый алгоритм курса можно сразу «приколоть» к одному из звеньев — и станет понятно, зачем он и где исполняется (офлайн или рантайм из главы 0.2).

Сквозной приём: «путь одного запроса»

Чтобы 22 модуля не рассыпались на изолированные темы, мы используем единый нарратив. «Путь одного запроса» — это история одного гипотетического запроса, которую мы будем дополнять в каждом модуле, прослеживая его сквозь все звенья.

Пример (упрощённый путь запроса «как заварить зелёный чай»).
1. Задолго до запроса (офлайн). Планировщик обхода нашёл страницу кулинарного блога, загрузчик её скачал (Модуль 2). Каноникализатор понял, что версии с ?utm=... — это та же страница, и оставил один канон (Модуль 3). Индексатор разложил текст на слова и записал в обратный индекс: «чай → …, страница#771, …», «заварить → …», «зелёный → …» (Модуль 4). Анализ графа дал странице ссылочную авторитетность (Модуль 7).
2. Пользователь вводит запрос. Понимание запроса нормализует его, видит намерение «инструкция/how-to», возможно, расширяет «заварить ≈ приготовить» (Модуль 5).
3. Выборка кандидатов (L0). По обратному индексу мгновенно находятся тысячи страниц, содержащих слова запроса.
4. Каскад ранжирования. Дешёвый текстовый скор (BM25, Модуль 6) режет тысячи до сотен; модель learning-to-rank с признаками текста, ссылок и поведения (Модули 8–11, 9) сортирует десятки; самая дорогая нейромодель уточняет верхушку (Модули 10, 12).
5. Постобработка. Убираются дубли и спам, обеспечивается разнообразие источников (Модули 15, 16).
6. Сборка выдачи. Добавляются сниппеты, возможно — блок видео из другого источника (федерация, Модуль 14), учитывается регион/язык (Модуль 18).
7. Измерение. Кликнул ли пользователь, вернулся ли — попадает в логи и питает обучение моделей и A/B-эксперименты (Модули 11, 19).
Каждый модуль курса — это «зум» в один из этих шагов. К Capstone (Модуль 22) вы сможете рассказать такой путь сами, со всеми деталями.

Структура частей курса

Код: Выделить всё

Часть I.   Основы            (0, 1)          — язык и теория IR
Часть II.  Офлайн-конвейер   (2, 3, 4)       — от веба к индексу
Часть III. Запрос/релевантность (5, 6, 7)    — понимание и текст/ссылки
Часть IV.  Факторы/ранжирование (8–13)        — ML, нейро, поведение, serving
Часть V.   Выдача (SERP)     (14–18)         — федерация, разнообразие, антиспам
Часть VI.  Оценка/этика      (19, 20, 21)    — метрики, SEO, ответственность
Часть VII. Синтез            (22)            — capstone

Треки: как читать курс под свою задачу

Один и тот же материал служит трём аудиториям. Трек — это маршрут с расставленными приоритетами, а не отдельная версия курса.

• Студент CS — фокус на алгоритмах и теории. Глубоко: Части I–IV, VI; инфраструктуру (13) и SEO-врезки можно обзорно.
• Инженер поиска/ML — фокус на реализации и serving. Всё, особенно Части II–V; этику — обзорно.
• SEO-специалист — фокус на факторах и выдаче. Обязательно Части I (обзор), III, V и прикладной Модуль 20; вывод формул LTR/нейросетей — обзорно.
• Смешанный/руководитель — картина целиком: Модуль 0, Части I, IV, V, VI; детальные выводы формул можно пропустить.

SEO-врезка. Ваш «золотой маршрут»: 0 → 1 (обзор) → 3 (каноникализация и дубли) → 5 (намерение запроса) → 8 (таксономия факторов) → 11 (поведенческие сигналы) → 16 (антиспам) → 20 (прикладной SEO). Это покрывает почти всё, на что вы реально влияете, и объясняет, почему «накрутки» из старых гайдов больше не работают.

Частые заблуждения

Заблуждение. «Модули можно читать в любом порядке.» Конвейер причинно-следственный: понимание Части IV (ранжирование) опирается на индекс из Части II и факторы из Части III. Перепрыгивать можно по трекам, но базовая стрелка «обход → … → измерение» задаёт зависимости.

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

Лаба / практика

Свой «путь одного запроса» (~40 мин).

1. Выберите собственный запрос (лучше слегка неоднозначный, например «питон»).
2. Пройдите по семи звеньям конвейера и для каждого напишите 1–2 предложения: что происходит с вашим запросом именно здесь. Отметьте, офлайн это или рантайм.
3. Отметьте, где неоднозначность запроса создаёт развилку (язык программирования vs змея) и в каком звене она, по-вашему, разрешается.
4. Укажите для каждого звена номер модуля курса, куда вы пойдёте за деталями.

Ожидаемый результат: таблица из 7 строк (звено → что происходит → офлайн/рантайм → модуль).

Критерий «сделано»: пройдены все семь звеньев, явно отмечена развилка неоднозначности и звено её разрешения, проставлены ссылки на модули.

Контрольные вопросы

1. Воспроизведите по памяти семизвенный конвейер курса. Почему «индекс» стоит раньше «ранжирования»?
2. Что такое приём «путь одного запроса» и какую проблему обучения он решает?
3. Сопоставьте звенья «факторы» и «ранжирование» с частями курса.
4. Почему измерение — это петля, а не конечная точка?
5. (Применение) Для запроса «лук» в каком звене конвейера разрешается, о растении речь или об оружии?
6. Выберите трек под себя и назовите три модуля, которые для вас приоритетны, и один — обзорный.
7. На каком этапе «пути запроса» исходный неоптимизированный сайт SEO-специалиста имеет шанс «выпасть» ещё до ранжирования?

Итоги модуля

• Задача поиска — отобразить запрос в упорядоченный список документов по убыванию релевантности; это задача ранжирования, а не просто фильтрации.
• Поиск труден из-за трёх одновременных ограничений — масштаб, латентность, релевантность — которые конфликтуют; вся инженерия поиска есть компромисс между ними.
• Честный перебор корпуса невозможен (разрыв в 7–8 порядков); спасают предвычисление (офлайн) и каскадное отсечение (рантайм).
• Система делится на офлайн-конвейер (обход → … → индекс, без пользователя, минуты-часы) и рантайм-обслуживание (запрос → выдача, с пользователем, миллисекунды).
• Индекс — контракт между половинами; в момент запроса система опрашивает индекс, а не живой веб. Нет в индексе — нет в выдаче.
• Курс нанизан на конвейер обход → индекс → факторы → ранжирование → выдача → постобработка → измерение, где каждое звено — это модуль(и).
• Сквозной приём «путь одного запроса» связывает все модули в одну историю; к Capstone студент проходит этот путь самостоятельно.
• Треки (Студент / Инженер / SEO / Смешанный) — это приоритезированные маршруты по одному и тому же материалу.

Глоссарий модуля

• Корпус (collection) — множество всех документов, среди которых ведётся поиск.
• Запрос (query) — текст (или иной ввод) пользователя, описывающий информационную потребность.
• Релевантность (relevance) — полезность конкретного документа для конкретного запроса/пользователя/контекста.
• Масштаб / латентность / релевантность — три фундаментальных ограничения веб-поиска.
• Латентность (latency) — задержка ответа; измеряется перцентилями (p95, p99), а не средним.
• Точность (precision) — доля релевантного среди выданного.
• Полнота (recall) — доля выданного среди всего релевантного в корпусе.
• Офлайн-конвейер (offline pipeline) — предварительная пакетная обработка веба в индекс, без пользователя.
• Рантайм-обслуживание (online serving) — обработка отдельного запроса в реальном времени.
• Индекс (index) — предвычисленная структура (прежде всего обратный индекс) для быстрого поиска; контракт между офлайном и рантаймом.
• Обратный индекс (inverted index) — отображение «слово → список документов, где оно встречается».
• Каскад ранжирования (ranking cascade) — последовательность всё более точных и дорогих оценок на всё меньшем числе кандидатов (L0–L3).
• Выборка кандидатов (candidate retrieval) — дешёвый первый этап отбора кандидатов из индекса.
• Постранжирование (post-ranking) — правила поверх скоров: дедупликация, разнообразие, антиспам.
• Выдача / SERP (search engine results page) — итоговая страница результатов.
• Путь одного запроса — сквозной учебный приём: прослеживание единого запроса через все звенья конвейера.
• Трек — приоритезированный маршрут чтения курса под аудиторию (Студент / Инженер / SEO / Смешанный).

Связи с другими модулями

• Опирается на: ничего (входной модуль курса).
• Прямое продолжение: Модуль 1 «Теоретический фундамент (IR)» — формализует релевантность, модели поиска и метрики, заявленные здесь на уровне интуиции.
• Раскрывает звенья конвейера: обход — Модули 2–3; индекс — Модуль 4; факторы — Модули 5–11; ранжирование — Модули 9, 10, 12, 13; выдача — Модули 14–18; постобработка — Модуль 16; измерение — Модули 19–21.
• Сводится воедино: Модуль 22 «Capstone» — где «путь одного запроса» проходится студентом полностью.

Материалы для углубления

• Классические вводные обзоры по информационному поиску и архитектуре поисковых систем (учебники уровня introduction to information retrieval).
• Обзорные работы по архитектуре крупномасштабных веб-поисковых систем (без привязки к конкретным продуктам): двухфазная модель «офлайн-индексация / онлайн-обслуживание».
• Материалы по бюджетам латентности и хвостовым задержкам в распределённых системах (понятие p99, «tail latency»).
• Обзоры по каскадному (многоуровневому) ранжированию и компромиссу «полнота кандидатов vs стоимость оценки».

[kafkaenjoyer]

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

[andrei3]

наконец дошло зачем вообще делить на офлайн и онлайн части. раньше в голове был один черный ящик query in - results out, а тут видно что краулинг и индексация это batch который крутится заранее, а на запросе уже только лукап и ранжирование по готовому индексу. сразу понятнее почему latency держится в миллисекундах

[regex_admin]

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