Обзор модуляЧасть VII · ~12 ч · Сложность: (продвинутый) · Пререквизиты: весь курс (Модули 0–21)
Этот модуль не вводит новых идей — он связывает всё, что вы изучили, в один работающий организм. До сих пор каждое звено конвейера «обход → индекс → факторы → ранжирование → выдача → постобработка → измерение» вы разбирали по отдельности: краулер (Модуль 2), каноникализатор (Модуль 3), обратный индекс (Модуль 4), понимание запроса (Модуль 5), BM25 и текстовая релевантность (Модуль 6), ссылочный граф (Модуль 7), таксономия факторов (Модуль 8), learning-to-rank (Модуль 9), нейропоиск (Модуль 10), поведенческие сигналы (Модуль 11), каскад L0–L3 (Модуль 12), инфраструктура (Модуль 13), метапоиск и федерация (Модуль 14), группировка и разнообразие (Модуль 15), постранжирование и антиспам (Модуль 16), свежесть (Модуль 17), локализация и персонализация (Модуль 18), измерение и эксперименты (Модуль 19), SEO (Модуль 20), этика (Модуль 21). Capstone требует увидеть систему целиком: как изменение в одном звене аукается в трёх других, где спрятаны бюджеты латентности и где теряется recall.
В сквозном конвейере этот модуль — смотровая площадка над всем маршрутом. Глава 22.1 проводит сквозную трассировку «путь одного запроса»: одна и та же пара (документ, запрос) прослеживается от момента, когда краулер впервые увидел URL, до того, почему документ оказался на 3-й позиции выдачи в 14:32 для пользователя из конкретного региона. Глава 22.2 даёт развёрнутое поэтапное техническое задание на учебный мини-поисковик (стенд) — реализуемый за разумное время проект, где каждый этап опирается на свой модуль и имеет явные критерии приёмки. Глава 22.3 описывает защиту проекта, типовые кейсы и рубрику оценивания, чтобы и студент, и проверяющий работали по одной шкале.
После модуля вы сможете не только реализовать поиск «от веба до позиции», но и объяснить причинно-следственные связи внутри него: почему документ не нашёлся (recall на L0), почему нашёлся, но низко (фактор/формула), почему его обогнал сосед (постранжирование, разнообразие), почему позиция изменилась завтра (свежесть, переобучение модели, дрейф клик-модели).
Как читать по трекамИнтуиция. Представьте, что весь курс — это разбор отдельных органов: сердце, лёгкие, печень. Capstone — это вскрытие живого организма в движении: вы прослеживаете, как один импульс (запрос) проходит по всем системам сразу, и собираете из деталей работающее тело (мини-поисковик).
- Студент CS — обязательно всё. Ядро — глава 22.1 (трассировка как способ проверить, что вы понимаете связи между алгоритмами) и этапы 1–5 проекта (краулер → индекс → BM25 → факторы → LTR). Реализуйте стенд руками; метапоиск и постранжирование (этапы 6–7) — минимум как заглушки.
- Инженер поиска/ML — обязательно всё, особенно инженерные заметки про бюджеты, кэш, воспроизводимость и измерение (этап 8). Стенд — повод отработать сквозную наблюдаемость (логирование «пути запроса») и офлайн-оценку. Реализуйте все 8 этапов.
- SEO-специалист — обязательно глава 22.1 целиком (она показывает, на какие звенья вы реально влияете и где «обрыв провода» убивает документ), этапы 1–4 и 6–7 проекта — хотя бы как наблюдатель. Вывод формул LTR — обзорно; зато трассировку «почему мой документ не на месте» разберите досконально.
- Смешанный/руководитель — Обзор, глава 22.1, рубрика 22.3. Проект — на уровне ТЗ и критериев приёмки: вы должны уметь поставить такую задачу команде и принять её.
- 22.1. Сквозной разбор «путь одного запроса»: от обхода и индексации документа до его позиции в выдаче (продвинутый)
- 22.2. Проект: учебный мини-поисковик (стенд) — поэтапное ТЗ от краулера до оценки (продвинутый)
- 22.3. Защита проекта, разбор кейсов и рубрика оценивания (средний)
Цели обучения
После главы студент сможет:
- Провести сквозную трассировку конкретного документа от обхода до позиции в выдаче, называя на каждом шаге ответственный компонент и модуль.
- Объяснить, где на маршруте документ может «потеряться» (recall) и где — «упасть в позиции» (precision/ранжирование).
- Различать офлайн-ветвь (обход → индекс → факторы) и онлайн-ветвь (запрос → каскад → выдача) и точку их встречи.
- Связать наблюдаемый симптом («документа нет в выдаче», «он слишком низко») с конкретным звеном-причиной.
- Использовать «путь запроса» как инструмент отладки реальной поисковой системы.
«Путь одного запроса» — это центральный учебный приём всего курса (он анонсирован в README). Идея проста: берём одну конкретную пару — документ D и запрос q — и проходим весь конвейер по шагам, не пропуская ни одного звена. На каждом шаге фиксируем три вещи: (1) что происходит с D, (2) кто отвечает (компонент + модуль), (3) как здесь можно потерять или сдвинуть документ.
Удобно разделить маршрут на две ветви, которые сходятся в индексе.
Код: Выделить всё
ОФЛАЙН-ВЕТВЬ (заранее, асинхронно):
[веб] → краулер → каноникализатор → индексатор → (факторы документа) → ИНДЕКС
│
ОНЛАЙН-ВЕТВЬ (в момент запроса, за десятки мс): ▼
q → понимание запроса → L0 отбор кандидатов ←──────────────────── читает ИНДЕКС
→ L1 быстрые факторы
→ L2 главная модель (LTR/нейро)
→ L3 реранк
→ метапоиск/федерация
→ группировка/разнообразие
→ постранжирование/антиспам
→ СТРАНИЦА ВЫДАЧИ (позиция D)
Сквозная трассировка по шагамИнтуиция. Офлайн-ветвь — это «подготовка склада»: товар (документ) приехал, его распаковали, описали, разложили по полкам. Онлайн-ветвь — «выдача заказа»: пришёл покупатель (запрос), кладовщик за секунды нашёл подходящее, сравнил варианты и выложил витрину. Если товар не разложили — его не выдадут, как ни старайся на витрине.
Возьмём конкретику. Документ D — страница рецепта, URL https://site.example/recipe/plov?utm=ad. Запрос q = «как приготовить плов». Прослеживаем.
Шаг 1. Обнаружение и обход (Модуль 2).
Планировщик обхода (crawl scheduler) узнаёт об URL из ссылки на уже известной странице или из карты сайта, проверяет правила обхода (robots), назначает приоритет и вежливый темп (politeness), скачивает HTML.
- Где теряется D: URL запрещён правилами обхода; страница не связана ссылками («сирота») и нет в карте сайта; краулер счёл её низкоприоритетной и не дошёл; сервер отдал ошибку/таймаут.
- Симптом наверху: документа вообще нет в выдаче, и в инструментах для вебмастеров он «не обойден».
Каноникализатор отбрасывает шум URL (?utm=ad), приводит к канонической форме, выявляет, что это дубль или почти-дубль другой страницы, и выбирает одного представителя кластера (canonical).
- Где теряется D: представителем кластера выбран не он, а другая копия; его контент схлопнут как near-duplicate (Модуль 3, shingling/SimHash).
- Симптом наверху: в выдаче «вместо моей» показывается другая версия страницы.
Индексатор парсит HTML, извлекает текст и зоны (title, заголовки, тело, анкоры), токенизирует, нормализует (Модуль 5 даёт тот же анализатор, что и для запроса!), строит/обновляет обратный индекс (inverted index): для каждого терма — постинг-лист с D и позициями. Сохраняет прямой документ-стор для сниппетов.
- Где теряется D: контент рендерится только JS, а индексатор не исполнил его; важные слова попали в зону с низким весом; рассинхрон анализаторов запроса и документа (слово «плов» в индексе нормализовано иначе, чем в запросе) — тогда L0 его не найдёт.
Шаг 4. Факторы документа считаются заранее (Модули 7, 8, 11, 17).Внимание. Анализатор документа и анализатор запроса (Модуль 5) обязаны совпадать. Если на индексации применили стемминг, а на запросе нет (или другой) — постинг-листы и термы запроса не сойдутся, и D выпадет уже на L0. Это классический «обрыв провода» между офлайн- и онлайн-ветвью.
Часть сигналов не зависит от запроса и вычисляется офлайн и кладётся рядом с документом: статический авторитет из ссылочного графа (PageRank-подобный, Модуль 7), агрегированные поведенческие признаки (Модуль 11), метки свежести/timestamp (Модуль 17), язык/гео (Модуль 18), сигналы качества/спама (Модуль 16).
- Где сдвигается D: низкий статический авторитет (мало входящих ссылок) — D стартует с гандикапом; помечен как «возможный спам/низкое качество» — получит штраф позже.
Шаг 5. Понимание запроса (Модуль 5).
Пришёл q = «как приготовить плов». Парсер запроса нормализует (тот же анализатор!), исправляет опечатки, снимает многозначность, расширяет синонимами, классифицирует интент (информационный → нужен рецепт/инструкция, а не магазин), определяет язык и регион.
- Где сдвигается D: классификатор интента переключает формулу ранжирования под класс запроса (Модуль 12) — для «как приготовить» в топ полезут пошаговые инструкции, и рецепт-D выигрывает; для коммерческого интента — проиграл бы.
Каскад начинается. По термам запроса (приготовить, плов; стоп-слово «как» может отсеяться) система пересекает/объединяет постинг-листы и/или делает ANN-поиск по эмбеддингам (Модуль 10). Из ∼10⁹ документов остаётся ∼10³–10⁵ кандидатов. D либо попал в кандидаты, либо нет.
- Где теряется D: термов запроса нет в его постинг-листах (см. Шаг 3); векторный отбор не дотянулся. Потеря recall на L0 необратима — ни одна последующая стадия документ не вернёт.
Шаг 7. L1 — быстрые факторы (Модули 6, 12).SEO-врезка. Попасть в кандидаты L0 — необходимое условие ранжирования. Никакая оптимизация заголовков и ссылок не поможет, если документ не извлекается на L0. Сначала проверяйте «индексируется и находится по слову», потом — позицию.
На ∼10³–10⁵ кандидатах считается дешёвый скор: BM25 (Модуль 6) по зонам, совпадение фраз, простые статические факторы из Шага 4. Кандидаты сортируются, до следующей стадии доходят ∼10²–10³.
- Где сдвигается D: слабый BM25 (редкие вхождения термов, длинный документ — нормировка длины), нет фразового совпадения. Если выпал из топ-n L1 — до умной модели не дойдёт.
На ∼сотнях кандидатов работает обучаемая модель ранжирования (learning-to-rank, Модуль 9) или нейромодель (Модуль 10). Она объединяет десятки/сотни факторов из таксономии (Модуль 8): текстовые, ссылочные (Модуль 7), поведенческие (Модуль 11), свежесть (Модуль 17), гео/перс (Модуль 18). Выдаёт точный скор.
- Где сдвигается D: модель обучена на разметке, где для «как приготовить» инструкции ценнее; D с хорошим поведенческим сигналом (досматривают рецепт) поднимается. Дрейф клик-модели (Модуль 11) меняет позицию со временем.
На горстке топ-документов работает самая дорогая модель/cross-encoder, уточняя порядок верхушки.
- Где сдвигается D: тонкая разница смысла; здесь решаются «фотофиниши» за 1–3 позиции.
К органической выдаче подмешиваются вертикали (картинки, видео, карты, свежие новости) — движок федерации решает, вставлять ли блок и на какое место. Веб-результат D может быть сдвинут вниз вставленным блоком.
- Где сдвигается D: над ним встал блок видео-рецептов; его «позиция 3» теперь визуально ниже.
Несколько страниц одного сайта схлопываются (host collapsing); выдача диверсифицируется, чтобы покрыть разные интенты («рецепт», «видео», «калорийность»).
- Где сдвигается D: с того же домена уже есть результат выше — D схлопнут под него; или выдаче «не хватало разнообразия», и D подняли как другой поджанр.
Финальные правила: штрафы за спам/накрутку, бусты/деусты по политике качества, фильтры безопасного поиска.
- Где сдвигается D: словил штраф из Шага 4 (помечен низкокачественным) — упал; либо, наоборот, чистый и поднялся относительно зашумлённых соседей.
Если запрос чувствителен к свежести — свежие документы получают буст; гео/язык/история пользователя корректируют порядок под конкретного человека и регион.
- Где сдвигается D: для пользователя из другого региона/на другом языке D мог бы и не попасть в топ — позиция персональна.
Собирается SERP. D занимает, скажем, позицию 3 в 14:32 для пользователя из заданного региона. Эта позиция — равнодействующая всех 13 шагов, а не свойство документа.
«Путь запроса» как инструмент отладкиЗаблуждение. «У документа есть позиция.» Нет: позиция существует только для пары (запрос, пользователь, момент, регион, устройство) и есть результат прохождения всего конвейера. Завтра при том же запросе она может быть другой (свежесть, переобучение L2, новый конкурент в индексе).
Сила приёма в том, что он превращает диагностику в последовательную проверку звеньев. Симптом → подозреваемое звено:
Код: Выделить всё
Симптом | Первый подозреваемый шаг
--------------------------------------------+---------------------------------------------------------------------
Документа вообще нет в выдаче | Шаг 1–3 (обход/каноникал/индексация) или Шаг 6 (L0 recall)
Показывается другая версия страницы | Шаг 2 (выбор canonical)
Находится по точной фразе, но не по смыслу | Шаг 6 (только лексический L0, нет векторного)
Низкая позиция при наличии слов | Шаг 7–8 (BM25/факторы/модель)
Был высоко, упал за ночь | Шаг 8 (переобучение/дрейф), Шаг 12 (новый штраф), Шаг 13 (свежесть)
Виден коллеге, не виден мне | Шаг 13 (персонализация/гео)
Над ним «чужой блок» | Шаг 10 (федерация вертикали)
Частые заблужденияИнженерная заметка. Чтобы такая отладка была возможна на реальной системе, нужна сквозная наблюдаемость: лог решения по каждому документу-кандидату на каждой стадии («дошёл до L1 со скором X, отсеян на L2 порогом Y, оштрафован правилом Z»). В мини-поисковике (глава 22.2) это требование вынесено в явный критерий приёмки — «трассируемость пути запроса».
Заблуждение. «Если документ в индексе — он будет в выдаче.» Между «в индексе» и «в выдаче» лежат L0-отбор (recall) и весь каскад. Документ может быть проиндексирован, но не извлечён на L0 (рассинхрон анализаторов, нет термов), и тогда наверху его нет.
Заблуждение. «Ранжирование — это одна формула.» Это конвейер из стадий (L0–L3) плюс постобработка (федерация, разнообразие, антиспам, персонализация). Итоговая позиция — суперпозиция, а не выход одной функции.
Лаба / практикаЗаблуждение. «Чтобы понять, почему документ низко, достаточно посмотреть на факторы документа.» Нужно знать, на каком шаге он отсеялся/просел. Хорошие факторы бесполезны, если потеря произошла раньше (на L0) или позже (штраф постранжирования).
Возьмите реальный публичный запрос и любую страницу из топа (или используйте свой стенд из 22.2). Постройте таблицу-трассировку из 14 шагов: для каждого шага запишите (а) что происходит с документом, (б) ответственный модуль курса, (в) гипотезу «где здесь документ мог бы потеряться/просесть». Затем для трёх симптомов из таблицы отладки сформулируйте конкретный диагностический эксперимент (что измерить/проверить, чтобы подтвердить или опровергнуть гипотезу).
Время ~90 мин. Критерий «сделано»: пройдены все 14 шагов без пропусков, каждый привязан к модулю; для трёх симптомов предложены проверяемые эксперименты, а не общие слова.
Контрольные вопросы
- В какой точке встречаются офлайн- и онлайн-ветви конвейера и почему именно там?
- Почему потеря документа на L0 необратима, а просадка на L2 — нет?
- Приведите два разных звена, на каждом из которых документ может «исчезнуть» из выдачи, и объясните разницу симптомов.
- Почему «позиция документа» — не свойство документа? Перечислите минимум четыре переменные, от которых она зависит.
- Как рассинхрон анализаторов запроса и документа проявится на маршруте и на каком шаге?
- Пользователь видит документ на позиции 5, коллега из другого города — не видит вовсе. Какой шаг проверять первым?
- Документ находится по точной фразе, но пропадает при перефразировке. Что это говорит об устройстве L0?
- Как сквозная наблюдаемость («лог пути») меняет процесс отладки по сравнению с осмотром только факторов документа?
Цели обучения
После главы студент сможет:
- Спроектировать и реализовать сквозной поиск из независимых этапов, каждый с явным контрактом вход/выход.
- Превратить теорию модулей 2–19 в работающий код на ограниченном корпусе.
- Сформулировать и проверить критерии приёмки для каждого этапа (а не «вроде работает»).
- Построить офлайн-оценку качества и измерять эффект изменений (Модуль 19).
- Обеспечить воспроизводимость и трассируемость пути запроса.
Стенд — это намеренно уменьшенная, но полная по структуре копия конвейера. Масштаб корпуса — от тысяч до десятков тысяч документов (хватает локальной машины), но все звенья присутствуют, пусть и в упрощённом виде. Язык-агностично; ориентир — Python + любой простой стор (файлы/SQLite). Ниже — поэтапное ТЗ. Каждый этап: цель → вход → выход → что делаем → критерий приёмки → отсылка к модулю. Этапы строятся друг на друге; рекомендуется делать строго по порядку и не переходить дальше, пока критерий приёмки текущего не выполнен.
Общие требования (применяются ко всем этапам)Инженерная заметка. Сквозной принцип всего стенда: контракты между этапами стабильны, реализации — заменяемы. Этап 5 (LTR) должен уметь встать на место этапа 3 (BM25) без переписывания краулера. Поэтому фиксируйте форматы артефактов (что лежит в индексе, какой JSON у кандидата, какие поля у фактора) с самого начала.
- Воспроизводимость: фиксированный seed, фиксированный корпус, команда «прогнать всё с нуля» работает на чистой машине.
- Трассируемость (см. 22.1): по флагу --trace система печатает путь конкретного документа по стадиям (дошёл/отсеян/скор/штраф).
- Конфиг, не магические числа: параметры (k1, b, веса факторов, размеры топов стадий) — в конфиге.
- Офлайн-оценка с этапа 1: даже до ранжирования держите файл с эталонной разметкой (запрос → релевантные документы), он понадобится на каждом следующем этапе.
- Цель: собрать локальный корпус документов и их метаданные.
- Вход: список стартовых URL (или готовый дамп — допустимо, чтобы не зависеть от сети) и правила обхода.
- Выход: хранилище сырых документов: doc_id, исходный URL, канонический URL, HTML/текст, метки времени, исходящие ссылки.
- Что делаем: обход по ссылкам с ограничением глубины и вежливым темпом; соблюдение robots; каноникализация URL и отсев точных дублей по хешу контента (упрощённый Модуль 3).
- Критерий приёмки: ≥ N документов собрано; повторный запуск не плодит дубли (идемпотентность каноникализации); граф исходящих ссылок сохранён (нужен этапу 4); лог «обойдено/пропущено/запрещено robots».
- Цель: построить обратный индекс и документ-стор.
- Вход: корпус из этапа 1.
- Выход: обратный индекс терм → постинг-лист (doc_id, tf, позиции, зона); прямой стор для сниппетов; словарь статистик (df, длины документов, avgdl).
- Что делаем: единый анализатор (токенизация, нижний регистр, нормализация/стемминг, стоп-слова) — тот же модуль применяется и к документам, и позже к запросам; разметка зон (title/h1/body/anchor).
- Критерий приёмки: по слову из документа он находится в постинг-листе; статистики (df, avgdl) считаются; анализатор вынесен в общую функцию (доказать, что запрос и документ проходят один код); boolean-поиск «И/ИЛИ» по термам возвращает корректное множество.
Этап 3. BM25 (Модуль 6)Внимание. Критерий «общий анализатор» — не формальность: это страховка от самого частого сквозного бага (Шаг 3/6 в 22.1).
- Цель: дать первый осмысленный ранжирующий скор.
- Вход: индекс и статистики из этапа 2; запрос.
- Выход: список (doc_id, bm25_score), отсортированный.
- Что делаем: реализовать BM25 с параметрами k1, b из конфига; зонирование (вес title выше body) — опционально как BM25F.
- Критерий приёмки: на мини-корпусе порядок совпадает с ручным эталоном из лабы Модуля 6; изменение b от 0 до 1 даёт ожидаемый эффект нормировки длины (проверить на длинном и коротком документе); прогон по эталонной разметке даёт ненулевые nDCG/MAP (базовая точка отсчёта для всех следующих этапов).
- Цель: добавить запросо-независимые сигналы.
- Вход: граф ссылок (этап 1), метки времени, BM25 (этап 3).
- Выход: для каждого документа — вектор факторов: bm25, статический авторитет (итеративный PageRank-подобный по сохранённому графу, Модуль 7), freshness (Модуль 17), длина/зоны, простые признаки качества.
- Что делаем: посчитать офлайн запросо-независимые факторы; собрать комбинированный скор-заглушку как взвешенную сумму (веса — в конфиге). Это «ручной LTR» перед настоящим.
- Критерий приёмки: PageRank-подобный вектор сходится (норма стабилизируется), сумма ≈ 1; авторитетные узлы (много входящих) получают больший вес; взвешенная сумма факторов измеримо двигает выдачу относительно чистого BM25 (показать на эталоне, лучше/хуже — обе ситуации обсудить).
- Цель: заменить ручные веса обучаемой моделью ранжирования.
- Вход: вектор факторов (этап 4) + эталонная разметка (запрос, документ, метка релевантности).
- Выход: обученная модель + функция score(features) → real, встроенная в каскад на место заглушки этапа 4.
- Что делаем: сформировать обучающую выборку (фичи на парах запрос–документ), обучить pointwise- или pairwise-модель (Модуль 9), строго разделить train/test (Модуль 19), сравнить с бейзлайном BM25 и ручной суммы.
- Критерий приёмки: на отложенном тесте nDCG/MAP не хуже ручной суммы (этап 4) и BM25 (этап 3); нет утечки (train и test по разным запросам); важность факторов выведена и осмыслена («что модель ценит»).
- Цель: показать сборку выдачи из нескольких источников.
- Вход: основной органический ранкер (этап 5) + ≥1 «вертикаль» (например, отдельный индекс свежих документов или картинок-заглушек).
- Выход: объединённый список с возможной вставкой блока вертикали на позицию.
- Что делаем: простое слияние с нормировкой скоров источников; правило «вставлять ли блок вертикали и куда» (триггер по интенту из Модуля 5).
- Критерий приёмки: скоры разных источников нормированы к сравнимой шкале; блок вертикали появляется только при заданном триггере; органические результаты не теряются, лишь сдвигаются (трассировка показывает сдвиг).
- Цель: довести список до «человеческой» выдачи.
- Вход: объединённый список (этап 6).
- Выход: финальный SERP топ-k.
- Что делаем: схлопывание по хосту (host collapsing, Модуль 15), простое разнообразие (не более M результатов одного поджанра/домена подряд), антиспам-штраф по простому правилу (Модуль 16, например за переспам ключевого слова — связь с заблуждением из Модуля 6).
- Критерий приёмки: один домен не занимает весь топ; документ, искусственно «переспамленный» в тесте, получает штраф и опускается; каждое правило логируется в трассировке (какой документ за что сдвинут).
- Цель: измерять качество и эффект изменений — а не верить на глаз.
- Вход: эталонная разметка (запрос → релевантность) и любой ранкер из этапов 3/4/5/7.
- Выход: отчёт с метриками (Precision@k, nDCG@k, MAP) по каждому этапу-ранкеру и сравнительная таблица «эволюция качества».
- Что делаем: реализовать метрики (Модуль 19), прогнать все версии ранкера на одной разметке, построить таблицу «BM25 → +факторы → LTR → +постранжирование», обсудить, где прирост, где регресс и почему; (бонус) макет A/B-сравнения двух конфигов.
- Критерий приёмки: метрики реализованы корректно (проверены на игрушечном примере с известным ответом); таблица эволюции построена; для каждого перехода между этапами дан причинно-следственный комментарий со ссылкой на соответствующий модуль.
Код: Выделить всё
Сводный конвейер стенда (этапы ↔ модули):
1 Краулер ───────── M2,M3
2 Индекс ────────── M4,M5
3 BM25 ──────────── M6
4 Факторы ───────── M7,M8,M17
5 LTR ───────────── M8,M9
6 Метапоиск ─────── M14
7 Постранжирование M15,M16
8 Оценка ────────── M19 (пронизывает все этапы)
Сквозное: трассировка (22.1) + воспроизводимость + конфиг
Частые заблужденияЗаблуждение. «Сначала напишу весь поиск, потом прикручу оценку.» Тогда вы не узнаете, какое изменение что улучшило. Оценка (этап 8) и эталонная разметка нужны с этапа 1: каждый последующий этап обязан показывать дельту метрики.
Заблуждение. «Стенд маленький, можно срезать каноникализацию/анализатор/трассировку.» Именно эти «скучные» звенья дают самые частые сквозные баги (см. 22.1). Их отсутствие делает проект неотлаживаемым.
Лаба / практикаЗаблуждение. «LTR без разметки — обучим на кликах сами себе.» На учебном стенде кликов нет; нужна явная эталонная разметка с разделением train/test, иначе метрика лжёт (утечка).
Реализуйте стенд до этапа 5 включительно (краулер → индекс → BM25 → факторы → LTR) на корпусе ≥ 2–5 тыс. документов и подготовьте эталонную разметку на ≥ 20 запросов. Постройте таблицу метрик для трёх ранкеров (BM25 / ручная сумма / LTR) на отложенном тесте. Включите режим --trace для одного запроса.
Время ~6–8 ч (распределённо). Критерий «сделано»: все четыре этапа проходят свои критерии приёмки; LTR на тесте не хуже бейзлайнов; трассировка печатает путь документа по стадиям; всё запускается одной командой с чистого состояния.
Контрольные вопросы
- Почему контракты между этапами фиксируют раньше реализаций?
- Зачем эталонная разметка нужна уже на этапе 1, а не на этапе 8?
- Какой единственный общий компонент обязаны делить этапы 2 и 5-онлайн, и почему?
- Как доказать, что в LTR нет утечки между train и test?
- Чем «ручная взвешенная сумма» (этап 4) полезна как ступень перед настоящим LTR?
- Что должна показывать трассировка --trace, чтобы быть полезной для отладки?
- Почему host collapsing и разнообразие относятся к постранжированию, а не к L2-модели?
- Какой минимальный набор метрик нужен, чтобы заявить «новая версия лучше»?
Цели обучения
После главы студент сможет:
- Подготовить и провести защиту сквозного проекта: демо + объяснение решений.
- Объяснить любое наблюдаемое поведение выдачи через причинно-следственную трассировку (22.1).
- Самостоятельно оценить проект по прозрачной рубрике и понять, чего не хватает.
- Разобрать типовые кейсы-инциденты и локализовать причину в конвейере.
Формат защиты
Защита проверяет не «запускается ли код», а понимание связей. Структура (≈20–30 мин):
- Демо (5–7 мин): живой прогон запроса от и до; показать выдачу и сразу — --trace для одного документа.
- Архитектура (5 мин): карта этапов ↔ модулей, контракты между этапами.
- Эволюция качества (5 мин): таблица метрик BM25 → факторы → LTR → постранжирование, с объяснением каждого перехода.
- Защита решений (Q&A): проверяющий задаёт «что будет, если…» и кейсы (ниже). Главный навык — отвечать через путь запроса, называя звено.
Типовые кейсы для разбора (инциденты)Инженерная заметка. Сильная защита звучит не «я добавил PageRank», а «freshness-фактор поднял свежие документы по чувствительным запросам на +X nDCG, но просадил вечнозелёные — поэтому я ограничил буст триггером интента из Модуля 5; вот трассировка». Связь решение → эффект → измерение → модуль.
Проверяющий даёт симптом, студент локализует звено и предлагает проверку:
- Кейс A. «Документ есть в корпусе, но не находится по очевидному слову». Подозрение: рассинхрон анализаторов (этап 2) или потеря на L0. Проверка: прогнать слово через анализатор запроса и документа, заглянуть в постинг-лист.
- Кейс B. «По запросу весь топ — с одного сайта». Подозрение: не работает host collapsing (этап 7). Проверка: трассировка правил постранжирования.
- Кейс C. «После добавления LTR метрика упала». Подозрение: утечка/переобучение или плохие фичи (этап 5). Проверка: разделение train/test, важность факторов, сравнение с бейзлайном.
- Кейс D. «Свежая страница не обгоняет старую по новостному запросу». Подозрение: freshness не подключён к формуле или не триггерится интентом (этапы 4/6, Модули 17/5).
- Кейс E. «Переспамленная страница в топе». Подозрение: нет антиспам-штрафа (этап 7, Модуль 16); напоминание про насыщение BM25 (Модуль 6).
- Кейс F. «У двух проверяющих разная выдача». Подозрение: персонализация/гео (Модуль 18) или невоспроизводимость (нет фиксированного seed/конфига).
Рубрика оцениванияПример. Кейс C на защите: студент показывает, что nDCG на train рос, а на test падал; делит запросы train/test без пересечения, переобучает — регресс исчезает. Это идеальный ответ: симптом → гипотеза (утечка) → проверка → исправление → измерение.
Сумма 100 баллов; порог зачёта — обычно 60. Каждый критерий оценивается по факту (демо + код + ответы).
Код: Выделить всё
# | Критерий | Что проверяется | Баллы
---+-----------------------------+-------------------------------------------------------------------------------------+-------
1 | Полнота конвейера | Присутствуют все 8 этапов (хотя бы минимально); ни одно звено не выпало | 20
2 | Корректность ядра | Индекс/анализатор согласованы; BM25 верен; PageRank сходится; метрики верны | 20
3 | LTR и измерение | Модель обучена без утечки; на тесте не хуже бейзлайнов; таблица эволюции качества | 15
4 | Постобработка выдачи | Федерация/схлопывание/разнообразие/антиспам работают и логируются | 10
5 | Трассируемость | --trace показывает путь документа по стадиям; помогает отладке | 10
6 | Воспроизводимость | Запуск с нуля одной командой; seed/конфиг; нет магических чисел | 10
7 | Понимание связей (защита) | Студент объясняет поведение через «путь запроса», решает кейсы A–F | 15
Уровни выполнения (для самопроверки)Внимание. Критерии 5–7 (трассируемость, воспроизводимость, понимание) часто недооценивают студенты — а это 40 баллов. «Работает на моей машине без объяснения почему» — это не сданный capstone.
- Базовый (60–74): этапы 1–5 и 8 работают, метрики честные, защита по трассировке проходит.
- Уверенный (75–89): + этапы 6–7, чистое измерение без утечек, осмысленная важность факторов, решены большинство кейсов.
- Отличный (90–100): + полная трассируемость и воспроизводимость, аккуратный разбор регрессов, обоснование каждого решения связкой эффект↔модуль, бонусы (BM25F, макет A/B, векторный L0).
Заблуждение. «Главное — чтобы поиск красиво выдавал результаты на демо.» Демо без объяснения и без измерения не доказывает понимания. Рубрика отдаёт 40 баллов за то, чего на красивой выдаче не видно: трассировку, воспроизводимость и разбор кейсов.
Лаба / практикаЗаблуждение. «Если метрика выросла — этап точно полезен.» Рост на train при падении на test — это переобучение, а не польза. Capstone требует мерить на отложенном тесте и уметь это объяснить.
Проведите взаимную защиту в паре: один играет автора, второй — проверяющего по рубрике и кейсам A–F. Заполните таблицу-рубрику на 100 баллов с конкретными замечаниями по каждому критерию, затем поменяйтесь ролями. Для двух самых слабых критериев сформулируйте план доработки.
Время ~60 мин. Критерий «сделано»: рубрика заполнена с обоснованием каждого балла; разобраны минимум четыре кейса из A–F; составлен план доработки слабых мест.
Контрольные вопросы
- Почему на защите ценится объяснение «через путь запроса», а не перечисление сделанных функций?
- В кейсе «весь топ с одного сайта» — какое звено и какой этап стенда проверять первым?
- Как на защите доказать, что прирост метрики от LTR реален, а не переобучение?
- Почему трассируемость и воспроизводимость весят в рубрике столько же, сколько ядро алгоритмов?
- Студент показал растущий nDCG только на train. Какой вердикт и почему?
- Сформулируйте, чем отличается ответ «отличного» уровня от «базового» на одном и том же кейсе.
- Какие два критерия рубрики чаще всего недооценивают и почему это дорого стоит?
- Какой минимальный набор артефактов нужно показать на демо, чтобы закрыть критерий «полнота конвейера»?
- Поиск — это единый конвейер из двух ветвей (офлайн: обход→индекс→факторы; онлайн: запрос→каскад→выдача), сходящихся в индексе; позиция документа — равнодействующая всех звеньев, а не его свойство.
- Приём «путь одного запроса» — главный инструмент и обучения, и отладки: он привязывает каждый симптом к конкретному звену-причине.
- Потеря на L0 (recall) необратима; просадки на поздних стадиях — поправимы. Сначала «находится ли», потом «на каком месте».
- Самый частый сквозной баг — рассинхрон анализаторов запроса и документа; общий код анализатора — обязательная страховка.
- Учебный стенд должен быть полным по структуре (все 8 этапов), пусть и маленьким по корпусу; контракты между этапами важнее конкретных реализаций.
- Оценка не пристёгивается в конце — эталонная разметка и метрики живут с первого этапа, каждый шаг доказывается дельтой качества на отложенном тесте.
- На защите оценивается понимание связей, трассируемость и воспроизводимость — 40 баллов рубрики за то, чего «красивая выдача» не показывает.
- LTR полезен, только если он измеримо не хуже бейзлайнов на тесте без утечки; рост на train ничего не доказывает.
- Путь одного запроса — сквозная трассировка пары (документ, запрос) через все звенья конвейера от обхода до позиции в выдаче.
- Офлайн-ветвь — часть конвейера, выполняемая заранее: обход, каноникализация, индексация, расчёт запросо-независимых факторов.
- Онлайн-ветвь — часть конвейера в момент запроса: понимание запроса, каскад L0–L3, постобработка, сборка выдачи.
- Стенд (учебный мини-поисковик) — уменьшенная, но структурно полная реализация конвейера для учебных целей.
- Контракт этапа — фиксированный формат входа/выхода между этапами, позволяющий менять реализацию без переписывания соседей.
- Трассируемость пути запроса — способность системы по запросу показать судьбу конкретного документа на каждой стадии (дошёл/отсеян/скор/штраф).
- Эволюция качества — сравнительная таблица метрик по версиям ранкера (BM25 → факторы → LTR → постранжирование).
- Рубрика — прозрачная шкала оценивания проекта по взвешенным критериям.
- Опирается на весь курс. Офлайн-ветвь: Модули 2 (краулинг), 3 (каноникализация), 4 (индексирование), 5 (анализатор/понимание), 7 (граф), 17 (свежесть). Онлайн-ветвь и ранжирование: 5 (интент), 6 (BM25), 8 (факторы), 9 (LTR), 10 (нейропоиск), 11 (клики), 12 (каскад L0–L3). Выдача: 14 (федерация), 15 (разнообразие), 16 (антиспам/постранжирование), 18 (персонализация). Измерение: 19. Прикладной взгляд: 20 (SEO). Ответственность: 21.
- Куда дальше. Capstone — финал курса. Дальнейший рост — углубление в выбранный трек: инженеру — Модули 12–13 (serving, инфраструктура) на проде; исследователю — 9–10 (LTR/нейро); SEO — 8, 16, 20 в связке с трассировкой из 22.1.
- Классические обзоры по архитектуре веб-поисковых систем и сквозному конвейеру (end-to-end IR pipelines).
- Учебные руководства по построению поисковых стендов на открытых корпусах и стандартных коллекциях для оценки.
- Работы и обзоры по офлайн-оценке ранжирования (nDCG/MAP, train/test-протоколы) — для корректного измерения эволюции качества.
- Методические материалы по проектному оцениванию инженерных capstone-проектов (рубрики, защита, разбор инцидентов).
