Обзор модуляЧасть VI · ~11 ч · Сложность: (средний)→(продвинутый) · Пререквизиты: Модуль 1, 9
Любое изменение в поисковой системе — новый фактор (Модуль 8), переобученная модель ранжирования (Модуль 9), правка каскада L0–L3 (Модуль 12), новый источник в федерации (Модуль 14) — должно быть измерено, прежде чем попадёт к пользователям. Без измерения вы летите вслепую: интуиция инженера про «так выдача стала лучше» ошибается чаще, чем хочется верить, а тонкая деградация в хвосте запросов не видна на глаз. Этот модуль — про то, как доказать (или опровергнуть), что изменение улучшило поиск, и как поймать ухудшение раньше пользователей.
В сквозном конвейере «обход → индекс → факторы → ранжирование → выдача → постобработка → измерение» этот модуль закрывает последнюю стадию — и одновременно замыкает цикл обратно в начало: метрики офлайн-оценки становятся целевой функцией для обучения ранжированию (Модуль 9), а сигналы онлайн-экспериментов и мониторинга подсказывают, какой фактор или источник чинить дальше. Измерение — это не «отдел качества в конце», а петля обратной связи, на которой держится вся итеративная разработка поиска.
Мы разделим оценку на два больших мира. Офлайн-оценка (глава 19.1) — это «золотой набор» запросов с разметкой асессоров, на котором мы считаем nDCG/MAP/ERR при каждом изменении модели, не трогая живых пользователей: быстро, дёшево, воспроизводимо, но смещено инструкцией асессора и неполнотой разметки. Онлайн-эксперимент (глава 19.2) — A/B-тест и интерливинг на реальном трафике: медленнее и дороже, зато меряет то, что пользователь реально делает, а не то, что асессор считает правильным. Затем мы перейдём к наблюдаемости пайплайна (19.3) — мониторингу, дашбордам и алертам, ловящим деградацию в продакшене, — и к тонкому вопросу долгосрочных эффектов (19.4): почему метрика, выросшая за неделю A/B, может означать ухудшение продукта через полгода.
После модуля вы сможете: спроектировать инструкцию для асессоров и схему пулинга; вручную посчитать nDCG@k, MAP, ERR и оценить межасессорное согласие (κ Коэна, α Криппендорфа); рассчитать необходимый размер выборки для A/B-теста по заданным MDE и мощности; правильно интерпретировать p-value и построить доверительный интервал для разницы метрик; объяснить, почему интерливинг чувствительнее A/B; собрать набор дашбордов и алертов на деградацию; и отличить краткосрочный выигрыш метрики от долгосрочной пользы.Интуиция. Офлайн-оценка отвечает на вопрос «согласен ли эксперт, что выдача правильная?». Онлайн-эксперимент — «стало ли пользователю реально лучше?». Это разные вопросы, и они регулярно расходятся. Зрелый поиск использует офлайн как быстрый фильтр гипотез, а онлайн — как финальный судья.
Как читать по трекам
- Студент CS — обязательно всё. Ядро — 19.1 (метрики и согласие) и 19.2 (статистика A/B: размер выборки, p-value, ДИ). Прорешайте обе лабы руками — расчёт nDCG/ERR и расчёт sample size — это переносимые навыки далеко за пределами поиска.
- Инженер поиска/ML — обязательно всё. Особое внимание: пулинг и его смещения (19.1), интерливинг и подводные камни A/B — пикинг, множественные сравнения, сетевые эффекты (19.2), весь модуль наблюдаемости (19.3) и ловушки краткосрочных метрик (19.4).
- SEO-специалист — обязательно интуиции, SEO-врезки, заблуждения. Ключевое: что ПС считает «хорошей выдачей» (метрики «здоровья»), почему клик ≠ удовлетворённость и что такое long-term-эффекты. Статистику A/B — обзорно.
- Смешанный/руководитель — Обзор, интуиции, итоги, и обязательно 19.4 (краткосрочные vs долгосрочные метрики) — это главный источник управленческих ошибок в поиске.
- 19.1. Офлайн-оценка: асессоры, инструкции, пулинг, метрики (nDCG, MAP, ERR), межасессорное согласие. (средний)
- 19.2. Онлайн-эксперименты: A/B-тесты, интерливинг, метрики, статистическая мощность и значимость. (продвинутый)
- 19.3. Наблюдаемость пайплайна: мониторинг, алерты деградации, дашборды. (средний)
- 19.4. Метрики «здоровья» выдачи и долгосрочные эффекты (long-term vs short-term). (продвинутый)
Цели обучения
После главы студент сможет:
- Объяснить, что такое «золотой набор» (judgments) и зачем нужна офлайн-оценка отдельно от онлайна.
- Спроектировать инструкцию для асессора и шкалу релевантности, минимизирующую разброс оценок.
- Применить пулинг (pooling) для построения разметки и понять, какое смещение он вносит.
- Посчитать вручную nDCG@k, MAP и ERR на примере и объяснить, чем ERR отличается от DCG.
- Оценить межасессорное согласие через κ Коэна и α Криппендорфа и сказать, когда разметке можно доверять.
- Связать офлайн-метрики с целевой функцией обучения ранжированию (Модуль 9).
Зачем нужна офлайн-оценка
Онлайн-эксперимент — золотой стандарт, но он дорог и медленен: на статистически значимый результат уходят дни–недели трафика, а проверить можно лишь несколько гипотез одновременно. Инженер же за день перебирает десятки вариантов фактора или гиперпараметров модели. Нужен дешёвый, быстрый, воспроизводимый способ отсеять заведомо плохие варианты, не показывая их пользователям.
Это и есть офлайн-оценка: фиксированный «золотой набор» (gold set, judgments) — набор запросов, для каждого из которых заранее размечена релевантность документов. Меняем модель → прогоняем её на этих запросах → считаем метрики → сравниваем с baseline. Всё локально, за минуты, воспроизводимо до бита.
Интуиция. Золотой набор — это «единичный тест» для ранжирования. Как юнит-тесты не заменяют продакшен-мониторинг, но ловят 90% регрессий мгновенно и бесплатно, так и офлайн-оценка не заменяет A/B, но отсекает мусорные гипотезы до того, как они дойдут до людей.
Асессоры и шкала релевантностиВнимание. Офлайн-метрика — это прокси. Она хорошо коррелирует с пользовательским качеством только если разметка качественная, набор репрезентативен по распределению запросов, а метрика отражает то, что важно пользователю. Расхождение офлайна и онлайна — норма; задача — сделать офлайн достаточно хорошим предиктором онлайна.
Асессор (assessor, rater, judge) — человек, который смотрит на пару (запрос, документ) и выставляет оценку релевантности. Шкала обычно градуированная (как в nDCG, Модуль 1):
Код: Выделить всё
Оценка | Метка | Смысл
--------+--------------------------+-------------------------------------------------------------------------------
4 | Perfect / Navigational | точный единственный ответ (официальный сайт бренда по навигационному запросу)
3 | Excellent | полностью удовлетворяет интент, авторитетный источник
2 | Good | релевантен, но не идеален (частично покрывает интент)
1 | Fair / Related | по теме, но слабо помогает
0 | Bad / Irrelevant | не релевантен / спам / битая страница
Инструкция для асессораИнженерная заметка. Шкалу выбирают балансируя между разрешением и согласием: чем больше градаций, тем точнее, но тем сильнее асессоры расходятся (труднее отличить «3» от «2», чем «релевантно» от «нет»). 5-балльная шкала — типичный компромисс для веб-поиска. Для специфических задач (нужен ровно один ответ) добавляют отдельную метку «навигационный/витальный» поверх шкалы.
Качество разметки определяется инструкцией (guidelines) не меньше, чем добросовестностью асессора. Плохая инструкция → большой разброс → бесполезный золотой набор. Хорошая инструкция:
- Определяет интент. Что вообще ищет пользователь этим запросом? Часто запрос неоднозначен (ягуар — животное / автомобиль), и инструкция требует оценивать релевантность по доминирующему интенту или по нескольким интентам с весами.
- Привязывает оценку к задаче пользователя, а не к «красоте» страницы. Документ релевантен, если решает задачу, стоящую за запросом, — а не если он «качественный вообще».
- Даёт калибровочные примеры на каждую оценку (anchor examples): «вот это 4, вот это 2, вот почему».
- Регламентирует пограничные случаи: устаревший контент, частичный ответ, правильный ответ на чужом языке, дубликаты, платный доступ, агрессивная реклама.
- Учитывает свежесть и местоположение, если запрос их подразумевает (погода, новости, рядом со мной).
Пример. Запрос как перезагрузить роутер. Инструкция должна явно сказать: страница с пошаговой инструкцией для любого роутера — Good (2); инструкция именно для модели пользователя — Excellent (3); форум, где вопрос задан, но не отвечен — Fair (1); реклама роутеров — Bad (0). Без таких якорей один асессор поставит форуму 2, другой 0 — и согласие рухнет.
Пулинг (pooling)SEO-врезка. Публичные руководства для асессоров — лучший открытый источник того, что ПС считает качеством: экспертность, авторитетность, достоверность источника, соответствие интенту, отсутствие обмана. Это не алгоритм ранжирования напрямую, но это «определение цели», под которую алгоритм обучается. Читать их полезнее, чем гадать о факторах.
Разметить все документы по запросу невозможно — их миллионы. Размечают только кандидатов из пула. Классическая схема пулинга по топам нескольких систем:
- Берём N ранжирующих систем (разные версии вашей модели, бейзлайны, конкурентные подходы).
- Каждая возвращает топ-k (например, top-100) по каждому запросу.
- Объединяем топы всех систем в один пул уникальных документов на запрос.
- Асессоры размечают только пул.
- Документы вне пула считаются нерелевантными по умолчанию.
Интуиция. Пулинг — это «скинемся кандидатами». Если документ хорош, его наверняка нашла хоть одна из многих систем и он попал в пул. Документы, которые не нашёл никто, скорее всего и правда плохи — потому их и помечают нулём, не размечая.
Внимание (смещение пула). Шаг 5 — источник коварного смещения. Новая система, которая находит хороший документ, не входивший в пул (потому что старые системы его не находили), получит за него ноль — её незаслуженно накажут. Поэтому золотой набор «стареет»: чем сильнее новые модели отличаются от тех, на которых строился пул, тем менее надёжна оценка. Лечение: периодически добавлять топы новых систем в пул и до-размечать.
Метрики офлайн-оценкиИнженерная заметка. Полнота пула важнее для recall-метрик (MAP), чем для top-heavy метрик (nDCG@10, ERR): последние смотрят на верхушку, где разметка обычно плотная. Поэтому для веб-поиска nDCG@10 устойчивее к неполному пулу, чем MAP по всему списку.
Базовые метрики (precision/recall, F1, MAP, MRR, nDCG) выведены в Модуле 1. Здесь — рабочий набор офлайн-оценки и новая метрика ERR.
nDCG@k (главная для веб-поиска). Напомним: при градуированной релевантности rel_i ∈ {0..4} выигрыш позиции дисконтируется логарифмом ранга.
Код: Выделить всё
DCG@k = Σ_{i=1..k} (2^rel_i − 1) / log2(i + 1)
IDCG@k = тот же DCG для идеального порядка (rel по убыванию)
nDCG@k = DCG@k / IDCG@k ∈ [0, 1]
MAP (для бинарной релевантности): среднее по запросам от Average Precision; AP усредняет precision в позициях релевантных документов (Модуль 1).
ERR (Expected Reciprocal Rank) — метрика с каскадной моделью пользователя. В отличие от DCG, где выигрыш позиции i не зависит от того, что стоит выше, ERR учитывает, что пользователь сканирует список сверху вниз и останавливается, найдя удовлетворяющий документ. Значит, ценность позиции i зависит от того, насколько хороши документы над ней.
Модель: переводим оценку в вероятность «пользователь удовлетворён этим документом»:
Код: Выделить всё
R_i = (2^rel_i − 1) / 2^rel_max # rel_max = максимум шкалы (напр. 4)
Код: Выделить всё
ERR = Σ_{i=1..k} (1/i) · R_i · Π_{j<i} (1 − R_j)
Интуиция. DCG спрашивает «сколько суммарной пользы в списке». ERR спрашивает «как быстро пользователь, скорее всего, закончит искать». Если на позиции 1 стоит идеальный документ, дальше уже почти неважно, что внизу, — пользователь не дойдёт. ERR это моделирует, DCG — нет.
Какую метрику когда брать:Пример (расчёт ERR@4). Выдача с оценками rel = [3, 0, 2, 1], шкала rel_max=4, 2^4=16.
Вероятности удовлетворения:
- R_1 = (2^3−1)/16 = 7/16 = 0.4375
- R_2 = (2^0−1)/16 = 0
- R_3 = (2^2−1)/16 = 3/16 = 0.1875
- R_4 = (2^1−1)/16 = 1/16 = 0.0625
Считаем накопленную «вероятность не остановиться выше» и вклады:
- поз.1: (1/1)·0.4375·1 = 0.4375. Остаток «не остановился» = 1−0.4375 = 0.5625.
- поз.2: (1/2)·0·0.5625 = 0. Остаток без изменений = 0.5625.
- поз.3: (1/3)·0.1875·0.5625 = 0.3333·0.10547 = 0.03516. Остаток = 0.5625·(1−0.1875)=0.45703.
- поз.4: (1/4)·0.0625·0.45703 = 0.25·0.028564 = 0.007141.
ERR@4 ≈ 0.4375 + 0 + 0.03516 + 0.007141 ≈ 0.4798.
Главный вклад дала первая позиция; нерелевантный документ на позиции 2 «съел» ход, но не остановил пользователя, и хорошие документы ниже почти не помогли, потому что до них «доходит» лишь часть пользователей.
Код: Выделить всё
Ситуация | Релевантность | Метрика
-----------------------------------------------+------------------+-------------
Веб-выдача, важен топ | градуированная | nDCG@10
Каскадное поведение, «один достаточный ответ» | градуированная | ERR
Найти всё релевантное (право, патенты) | бинарная | MAP, Recall
Нужен ровно один ответ (навигация, факт) | бинарная | MRR
Заблуждение. «nDCG и ERR — про одно и то же, можно брать любую.» Нет: ERR гасит вклад нижних позиций тем сильнее, чем лучше верхние (каскад), DCG — нет. Если две системы отличаются перестановками ниже первого отличного документа, ERR почти не заметит разницы, а nDCG заметит. Выбор метрики = выбор модели пользователя.
Связь с обучением ранжированию (Модуль 9)Заблуждение. «Раз метрика выросла офлайн — выкатываем.» Офлайн-рост — необходимое, но не достаточное условие. Он мог появиться из-за смещения пула (новая система угодила ровно в размеченные документы) и не дать ничего онлайн.
Золотой набор играет двойную роль: это и тест (офлайн-оценка), и источник обучающих меток для LTR. LambdaRank/LambdaMART (Модуль 9) прямо вшивают ΔnDCG в градиент — то есть учат модель оптимизировать ту самую офлайн-метрику. Отсюда важная гигиена:
Межасессорное согласиеВнимание (утечка). Если обучать и оценивать на одном наборе запросов — метрика будет завышена (переобучение). Запросы делят на train/validation/test по запросам (а не по парам (q,d)), иначе документы одного запроса попадут и в train, и в test, и оценка станет оптимистичной. Это прямой аналог группировки по запросу из Модуля 9.
Если два асессора по одной паре (q,d) ставят разные оценки — какой из них верить? И можно ли вообще доверять разметке? Это меряет межасессорное согласие (inter-annotator agreement).
Наивная метрика — доля совпадений (raw agreement): процент пар, где оценки совпали. Проблема: при несбалансированной шкале совпадения бывают случайно. Если 95% документов нерелевантны, два асессора, ставящие «0» наугад, совпадут в ~90% случаев, ничему не научившись.
κ Коэна (Cohen's kappa) корректирует на случайное согласие двух асессоров:
Код: Выделить всё
κ = (p_o − p_e) / (1 − p_e)
α Криппендорфа (Krippendorff's alpha) — обобщение: работает для многих асессоров, неполной разметки (не каждый размечал каждую пару) и порядковой шкалы (учитывает, что путаница «3↔2» мягче, чем «3↔0», через метрику расстояния между метками). Для градуированной релевантности α корректнее κ, потому что уважает порядок шкалы.Пример (κ). Два асессора разметили 100 пар бинарно (Rel/Bad).
- Совпали «Rel»: 40; совпали «Bad»: 45; разошлись: 15. → p_o = 0.85.
- Асессор A: Rel=50, Bad=50. Асессор B: Rel=45, Bad=55.
- p_e = (0.50·0.45) + (0.50·0.55) = 0.225 + 0.275 = 0.50.
- κ = (0.85 − 0.50)/(1 − 0.50) = 0.35/0.50 = 0.70.
Грубая шкала интерпретации: <0 хуже случайного; 0–0.2 плохое; 0.2–0.4 слабое; 0.4–0.6 умеренное; 0.6–0.8 существенное; >0.8 почти идеальное. κ=0.70 — существенное согласие, разметке можно доверять.
Интуиция. κ спрашивает «совпали или нет», α — «насколько далеко разошлись». Для оценок 0–4 ошибка на один балл не так страшна, как на четыре, и α это учитывает.
Частые заблужденияИнженерная заметка. Если согласие низкое — чините инструкцию, а не людей: добавьте якорные примеры, уточните пограничные случаи. Низкое α означает, что сама задача определена расплывчато, и любые метрики на этой разметке шумны. Практический приём: каждую пару размечают ≥3 асессора, итоговая метка — медиана/мода, а пары с высоким разбросом отправляют на арбитраж эксперту.
Заблуждение. «Один асессор на пару — достаточно, люди же эксперты.» Релевантность субъективна; одиночная разметка не даёт оценить согласие и шумна. Минимум 3 асессора + агрегация.
Заблуждение. «Высокая доля совпадений = хорошая разметка.» При перекосе классов совпадения случайны. Смотрите κ/α, а не raw agreement.
Лаба / практикаЗаблуждение. «Золотой набор разметили один раз — и пользуемся годами.» Пул стареет, интенты дрейфуют, появляются новые типы документов. Набор надо обновлять и до-размечать, иначе он систематически недооценивает новые системы.
Дано: один запрос и выдачи двух систем A и B (top-5), с оценками асессоров по шкале 0–4.
- A: rel = [3, 2, 3, 0, 1]
- B: rel = [4, 0, 2, 2, 1]
- Для каждой системы посчитайте DCG@5, IDCG@5 (идеальный порядок для своего мультимножества оценок), nDCG@5 (экспоненциальный gain).
- Посчитайте ERR@5 для обеих систем (rel_max=4).
- Какая система лучше по nDCG@5? А по ERR@5? Совпали ли вердикты? Объясните расхождение через каскадную модель.
- Сведите обе выдачи к бинарной релевантности (rel≥2 → релевантно) и посчитайте MAP по этому одному запросу (то есть AP каждой системы).
- Второй асессор переоценил выдачу B как [3,0,2,2,1] (понизил первый документ 4→3). Посчитайте κ Коэна между двумя асессорами по этим 5 оценкам B, огрубив до бинарной (≥2). Прокомментируйте, информативна ли κ на 5 точках.
Время: ~50 мин. Критерий «сделано»: все четыре метрики посчитаны верно (сверка с эталоном), расхождение вердиктов nDCG vs ERR объяснено через модель пользователя, отмечено, что κ на 5 точках статистически ненадёжна.
Контрольные вопросы
- Зачем нужна офлайн-оценка, если есть A/B-тесты? Назовите два её преимущества и одно ограничение.
- Что такое смещение пула и почему оно систематически вредит новым системам?
- Чем ERR отличается от DCG по модели пользователя? На каких выдачах вердикты разойдутся?
- Почему raw agreement обманчив, и что исправляет κ Коэна?
- Когда α Криппендорфа предпочтительнее κ?
- Почему train/test для LTR делят по запросам, а не по парам (q,d)?
- Как низкое межасессорное согласие должно влиять на ваши действия — чинить людей или инструкцию? Почему?
- Дайте nDCG@3 для rel=[0,3,3] (экспоненциальный gain): посчитайте DCG, IDCG, отношение.
Цели обучения
После главы студент сможет:
- Объяснить устройство A/B-теста в поиске: рандомизация, контроль/тритмент, единица рандомизации.
- Выбрать онлайн-метрики и понять, почему «больше кликов» — опасная цель.
- Описать интерливинг и объяснить, почему он на порядок чувствительнее A/B.
- Рассчитать необходимый размер выборки по MDE, базовому уровню, мощности и уровню значимости.
- Интерпретировать p-value и доверительный интервал корректно, без типичных ошибок.
- Распознать ловушки: подглядывание (peeking), множественные сравнения, сетевые эффекты, эффект новизны.
Анатомия A/B-теста
A/B-тест — рандомизированный контролируемый эксперимент. Часть трафика (контроль, A) получает текущую систему, часть (тритмент, B) — изменение. Если рандомизация честная, единственное систематическое различие между группами — это само изменение, поэтому разница в метриках причинно объясняется изменением.
Ключевые решения:
- Единица рандомизации. Чаще всего — пользователь (cookie/идентификатор), а не запрос: один человек должен стабильно видеть одну версию, иначе UX рваный и метрики на уровне пользователя (удержание, число сессий) не посчитать. Рандомизация по запросу даёт больше «наблюдений», но ломает пользовательские метрики и создаёт зависимость наблюдений.
- Распределение по группам — детерминированный хэш от user_id → бакет. Воспроизводимо, без перекоса.
- A/A-тест перед запуском: разбейте трафик на две одинаковые группы. Если метрики «значимо различаются» — ваша система измерения сломана (неверная рандомизация, неучтённая зависимость).
Онлайн-метрики поискаИнтуиция. A/B-тест — это контролируемый научный опыт на живых людях. Вся его сила в рандомизации: она уравнивает группы по всем мыслимым и немыслимым факторам (география, устройство, время), оставляя единственное различие — ваше изменение.
Что мерить? Метрики делят на уровни:
- Метрики выдачи/сессии: CTR (доля кликнувших), позиция первого клика, abandonment rate (доля сессий без клика), reformulation rate (доля запросов, переформулированных тут же).
- Метрики удовлетворённости (прокси): долгий клик (long/dwell click) — клик с долгим пребыванием на странице (≈ нашёл ответ) против pogo-sticking — клик и быстрый возврат к выдаче (≈ не подошло); time-to-success; доля сессий, завершившихся успехом.
- Метрики продукта/верхнего уровня: число сессий на пользователя, удержание (retention), доля повторных визитов.
Заблуждение (критическое). «Больше кликов = лучше поиск.» Опасно. Если выдача ухудшилась, пользователь может кликать больше — потому что первый результат не помог и приходится тыкать дальше. Рост CTR в отрыве от dwell-time и pogo-sticking может означать деградацию. Правильная цель — пользователь нашёл ответ быстро и с минимумом действий, что часто означает меньше кликов и переформулировок.
Интерливинг (interleaving)SEO-врезка. То же самое объясняет, почему ПС ценят long-click и наказывают pogo-sticking: метрика качества — «решил ли пользователь задачу», а не «кликнул ли он». Страница, которую открывают и тут же закрывают, — сигнал неудовлетворённости, даже если по ней кликали (см. поведенческие сигналы, Модуль 11).
A/B сравнивает группы пользователей. Интерливинг сравнивает две системы у одного и того же пользователя, смешивая их выдачи в один список и смотря, чьи результаты кликают чаще.
Team-Draft Interleaving (аналог «дворового набора команд»): системы A и B по очереди «выбирают» свой следующий лучший ещё не выбранный документ в общий список (порядок выбора рандомизируется). Каждый документ помечен, чья он «команда». Клик = очко команде. По многим сессиям считаем, чья команда набрала больше.
Интуиция. A/B спрашивает «какая группа людей довольнее» — а люди шумные и разные. Интерливинг спрашивает «у этого человека на этом запросе чьи результаты лучше» — сравнение внутри одного показа убирает межпользовательскую дисперсию. Меньше шум → меньше нужно трафика.
Инженерная заметка. Интерливинг типично на 1–2 порядка чувствительнее A/B: тот же вывод достигается на гораздо меньшем трафике / за меньшее время. Цена — он меряет только относительное ранжирование (что лучше для конкретной пары систем) и не годится для продуктовых метрик (удержание, изменения UI), где нужен полноценный A/B. Типичный конвейер: интерливинг как быстрый фильтр гипотез ранжирования → A/B на выживших для финального продуктового вердикта.
Статистика A/B: размер выборки, значимость, ДИВнимание. Интерливинг смешивает выдачи — нельзя интерливить изменения, ломающие визуальную целостность (другая разметка, сниппеты, блоки федерации): пользователь увидит «франкенштейна». Он хорош именно для перестановок ранжирования.
Это ядро главы. Разберём по порядку.
Нулевая гипотеза H0: изменение не влияет на метрику (разница средних = 0). Альтернатива H1: влияет. Эксперимент собирает данные, чтобы (возможно) отвергнуть H0.
Две ошибки:
- Ошибка I рода (α) — отвергли H0, хотя она верна (увидели эффект, которого нет; «ложная тревога»). Контролируется уровнем значимости, обычно α = 0.05.
- Ошибка II рода (β) — не отвергли H0, хотя H1 верна (проглядели реальный эффект). Мощность (power) = 1 − β, обычно целятся в 0.8.
Формула размера выборки (для разницы двух пропорций / средних, на группу):
Код: Выделить всё
n ≈ (z_{1−α/2} + z_{1−β})² · 2σ² / Δ²
- Δ — MDE (абсолютная разница, которую хотим различить);
- σ² — дисперсия метрики; для доли (конверсии) σ² = p·(1−p);
- z_{1−α/2} — критическое значение нормали: для α=0.05 (двусторонний) ≈ 1.96;
- z_{1−β} — для мощности 0.8 ≈ 0.84.
Пример (расчёт sample size). Базовый уровень успешных сессий p = 0.40. Хотим ловить абсолютный прирост Δ = 0.01 (с 40% до 41%) при α=0.05, мощности 0.8.
- (z_{1−α/2}+z_{1−β})² = (1.96 + 0.84)² = 2.8² = 7.84.
- σ² = p(1−p) = 0.40·0.60 = 0.24.
- n ≈ 7.84 · 2 · 0.24 / 0.01² = 7.84 · 0.48 / 0.0001 = 3.7632 / 0.0001 = 37 632 на группу.
Итого ≈ 75 264 пользователей. Если бы хотели ловить вдвое меньший эффект Δ=0.005, выборка выросла бы в 2²=4 раза (квадратичная зависимость от 1/Δ). Это главный рычаг: маленькие эффекты требуют огромного трафика.
p-value — вероятность увидеть наблюдаемую (или более экстремальную) разницу метрик, если H0 верна (эффекта нет). Если p < α, разницу называют статистически значимой и отвергают H0.Инженерная заметка. Зависимость n ∝ 1/Δ² объясняет, почему интерливинг так ценен: снижая σ² (дисперсию) за счёт сравнения внутри показа, он позволяет различать те же Δ на меньшем n. И почему нельзя гнаться за микро-улучшениями A/B-тестом: чтобы поймать +0.1%, нужны десятки миллионов пользователей.
Заблуждение (важнейшее). «p-value — это вероятность, что H0 верна» или «что эффект случаен». Нет. p-value — вероятность данных при условии H0, а не вероятность гипотезы при условии данных. p=0.03 не значит «с вероятностью 97% эффект реален». Это значит: «если бы эффекта не было, такие данные были бы редки (3%)».
Доверительный интервал (ДИ) разницы метрик информативнее одного p-value, потому что показывает размер эффекта и его неопределённость:Заблуждение. «p > 0.05 доказывает, что эффекта нет.» Нет: отсутствие значимости ≠ доказательство H0. Возможно, не хватило мощности (мал n или велик σ). Различайте «нет эффекта» и «не обнаружили эффект».
Код: Выделить всё
Δ̂ ± z_{1−α/2} · SE(Δ̂), где для разницы пропорций
SE(Δ̂) = sqrt( p_A(1−p_A)/n_A + p_B(1−p_B)/n_B )
Пример (ДИ). n_A=n_B=40 000. Контроль p_A=0.400, тритмент p_B=0.412. Наблюдаемая разница Δ̂ = +0.012.
- SE = sqrt( 0.4·0.6/40000 + 0.412·0.588/40000 ) = sqrt( 0.24/40000 + 0.2423/40000 )
- = sqrt( (0.24 + 0.2423)/40000 ) = sqrt(0.4823/40000) = sqrt(1.2058e−5) ≈ 0.003473.
- 95% ДИ: 0.012 ± 1.96·0.003473 = 0.012 ± 0.006807 = [0.00519, 0.01881].
Интервал не содержит 0 → разница значима на уровне α=0.05. И он показывает больше: эффект почти наверняка между +0.5% и +1.9% — это позволяет принять бизнес-решение (стоит ли выкатывать ради такого прироста), чего голое p<0.05 не даёт.
Ловушки онлайн-экспериментовЗаблуждение про ДИ. «95% ДИ означает: с вероятностью 95% истинное значение внутри этого интервала.» В частотной интерпретации — нет: истинное значение фиксировано, случаен интервал. Корректно: «если повторить эксперимент много раз, 95% построенных интервалов накроют истинное значение». На практике интерпретируют прагматично, но помните формальный смысл.
Внимание (подглядывание, peeking). Смотреть на p-value «каждый день и остановиться, как только p<0.05» — грубая ошибка. При многократных промежуточных проверках шанс случайно увидеть p<0.05 в какой-то момент сильно превышает 5%. Лечение: фиксируйте n и длительность заранее; для последовательного анализа используйте поправки (sequential testing, alpha-spending, Bayesian-подходы).
Внимание (множественные сравнения). Проверяете 20 метрик одновременно при α=0.05? В среднем одна покажет «значимость» чисто случайно. Лечение: поправка Бонферрони (α/m) или контроль FDR (Benjamini-Hochberg); заранее назначайте одну главную метрику (OEC, overall evaluation criterion) и считайте остальные вторичными.
Внимание (сетевые/интерференционные эффекты). Рандомизация по пользователю предполагает, что группы не влияют друг на друга. В поиске это обычно выполняется, но не всегда: если изменение влияет на общий кэш, обучение модели на агрегированных кликах (тритмент «загрязняет» данные для контроля) или на поведение в соц-фичах — независимость нарушена, и оценка эффекта смещена.
Частые заблужденияВнимание (эффект новизны и прайминга). В первые дни пользователи реагируют на изменение как таковое (новизна) или, наоборот, путаются (учебная кривая). Краткосрочная метрика искажена. Лечение: достаточная длительность, анализ только устоявшегося периода, когорты по давности захода.
Заблуждение. «Если результат значим (p<0.05), эффект важен.» Значимость ≠ величина. На огромной выборке статзначимым станет даже +0.01% — бесполезный для продукта. Смотрите размер эффекта и ДИ, а не только факт p<0.05.
Заблуждение. «A/B всегда лучше офлайна и интерливинга.» У каждого своя ниша: офлайн — мгновенный фильтр, интерливинг — чувствительный судья ранжирования, A/B — единственный способ померить продуктовые и долгосрочные метрики. Зрелый процесс использует все три каскадом.
Лаба / практикаЗаблуждение. «Остановим тест раньше, раз уже значимо.» Это и есть peeking — раздувает ошибку I рода. Либо фиксируйте план заранее, либо используйте корректный последовательный анализ.
Часть 1 — дизайн эксперимента (расчёт sample size).
Базовый CTR p=0.25. Хотите ловить абсолютный прирост Δ=0.005 при α=0.05 (двусторонний), мощность 0.8.
- Посчитайте n на группу по формуле. (Подсказка: σ²=p(1−p), множитель 7.84.)
- Если трафик 100 000 пользователей/день и тест 50/50, сколько дней нужно набирать выборку?
- Бизнес согласен на мощность 0.9 (z_{1−β}=1.2816). Пересчитайте n — на сколько вырос?
Тест закончился: n_A=n_B=120 000. p_A=0.250, p_B=0.258.
- Посчитайте Δ̂, SE(Δ̂), 95% ДИ разницы пропорций.
- Содержит ли ДИ ноль? Значим ли результат на α=0.05?
- Сформулируйте вывод для продукта: какой прирост и в каком диапазоне, стоит ли выкатывать. Затем объясните, почему добавление dwell-time/pogo-sticking в анализ обязательно перед решением.
Время: ~60 мин. Критерий «сделано»: sample size посчитан верно (часть 1.1 ≈ 117 600 на группу), ДИ построен правильно, вердикт по нулю в интервале согласован с интуицией про p-value, и студент явно проговорил, что CTR в отрыве от dwell-time может вводить в заблуждение.
Контрольные вопросы
- Почему единицей рандомизации обычно берут пользователя, а не запрос? Что ломается при рандомизации по запросу?
- Зачем проводить A/A-тест перед A/B?
- Объясните, почему рост CTR может означать ухудшение поиска.
- Почему интерливинг чувствительнее A/B? Какова цена этой чувствительности?
- Как n зависит от MDE? Что будет с выборкой, если уменьшить MDE втрое?
- Дайте корректное определение p-value и назовите два распространённых неверных.
- Чем ДИ информативнее одиночного p-value при принятии решения?
- Что такое peeking и почему он раздувает ошибку I рода? Как с ним бороться?
- Вы проверяете 15 метрик. Как защититься от ложных срабатываний?
Цели обучения
После главы студент сможет:
- Различать три столпа наблюдаемости (метрики, логи, трейсы) применительно к поисковому конвейеру.
- Спроектировать набор дашбордов по стадиям конвейера (обход → индекс → ранжирование → выдача).
- Настроить алерты на деградацию и объяснить компромисс «чувствительность vs ложные тревоги».
- Выбрать SLI/SLO для поиска и связать их с пользовательским опытом.
- Поймать деградацию качества (а не только доступности) метриками-прокси в реальном времени.
Три столпа и что мерить в поиске
Эксперименты (19.1–19.2) измеряют изменения. Наблюдаемость измеряет состояние работающей системы непрерывно — чтобы поймать деградацию, которую не предсказал ни один тест: упавший шард индекса, протухший кэш, сломанный источник в федерации (Модуль 14), модель ранжирования, выдающую мусор после плохого деплоя.
Три столпа:
- Метрики (metrics) — числовые временные ряды (latency, QPS, error rate, CTR). Дёшевы, агрегируемы, основа дашбордов и алертов.
- Логи (logs) — дискретные события с контекстом (что искал, что вернули). Для разбора конкретных инцидентов.
- Трейсы (traces) — путь одного запроса через стадии (L0→L1→L2→L3, федерация). Для поиска где в конвейере теряется время/качество.
Метрики по стадиям конвейераИнтуиция. Метрики говорят «что-то сломалось», логи — «что именно у этого запроса», трейсы — «на какой стадии». Вместе они отвечают на вопрос инцидента: что, где, почему.
Код: Выделить всё
Стадия | Что мониторить
------------------------------+---------------------------------------------------------------------------------------------------
Обход (Модуль 2) | темп обхода, доля ошибок загрузки, свежесть (возраст документа), размер очереди
Индекс (Модуль 4) | время индексации (doc→searchable lag), число живых документов, здоровье шардов, размер индекса
Понимание запроса (Модуль 5) | доля распознанных интентов, частота расширений/исправлений, доля «непонятых» запросов
Ранжирование (Модули 9, 12) | latency по уровням L0–L3, число кандидатов на уровне, доля таймаутов модели, распределение скоров
Федерация (Модуль 14) | доступность источников, доля таймаутов источника, доля показов каждого блока
Выдача | QPS, end-to-end latency (p50/p95/p99), error rate, доля пустых выдач, abandonment rate
Сервис может быть «зелёным» (200 OK, p99 в норме), но выдача стала хуже. Это сложнее ловить, чем падение. Прокси-сигналы качества в реальном времени:
- Резкий сдвиг CTR / abandonment на топовых запросах (срез по самым частотным запросам, где статистика набирается за минуты).
- Доля пустых/коротких выдач — скачок означает сломанный матчинг или слишком агрессивную фильтрацию.
- Распределение скоров ранжирования — внезапное «схлопывание» (все скоры близки) часто означает сломанную модель/факторы.
- Доля fallback-ов — сколько запросов скатилось на резервную дешёвую ветку (модель не уложилась в бюджет, источник недоступен).
- Pogo-sticking rate в агрегате — медленный рост = тихая деградация релевантности.
Алерты: чувствительность против шумаИнженерная заметка. Эффективный приём — canary / shadow. Canary: новая версия получает 1% трафика, её метрики сравниваются с основной в реальном времени; при деградации — автооткат. Shadow: новая версия получает копию реального трафика, но её выдача не показывается — сравниваем офлайн без риска для пользователя. Это «непрерывный мини-A/B» для защиты от деплоя.
Алерт должен сработать на реальную проблему и молчать на нормальном фоне. Слишком чувствительный → усталость от алертов (alert fatigue), дежурный начинает их игнорировать → пропускает настоящий инцидент.
Приёмы:
- Пороги на отклонение, а не на абсолют: «CTR упал на >X% относительно того же часа недельной давности» (учитывает суточную/недельную сезонность) вместо «CTR < const».
- Окна и гистерезис: алерт только если аномалия держится ≥M минут — гасит мгновенные всплески.
- Многоуровневость: warning (в чат) vs critical (будит дежурного).
- Прямая привязка к пользователю: алертить по симптому («доля успешных сессий упала»), а не только по причине («CPU 90%»). Симптомные алерты ловят неизвестные классы проблем.
Внимание (сезонность). Поисковый трафик и CTR сильно сезонны (день/ночь, будни/выходные, праздники). Алерт на абсолютный порог завалит дежурного ложными срабатываниями каждую ночь. Сравнивайте с тем же временем прошлой недели, а не со средним.
SLI/SLO для поискаSEO-врезка. Тихая деградация релевантности (без падения доступности) — это то, что пользователи и оптимизаторы замечают как «выдача поехала», когда внутренние симптомные метрики ещё не зазвенели. Хорошая наблюдаемость качества — это то, что отличает ПС, которая чинит регрессии за часы, от той, что узнаёт о них из жалоб неделями позже.
- SLI (Service Level Indicator) — измеримый показатель: доля запросов с latency < 300мс; доля непустых выдач; доступность.
- SLO (Service Level Objective) — целевое значение SLI: «99.9% запросов отвечают за <300мс за 28 дней».
- Error budget — допустимая доля нарушений (1 − SLO). Пока бюджет не исчерпан — катим фичи; исчерпан — замораживаем и чиним стабильность.
Частые заблужденияИнтуиция. SLO превращает «надёжность» из абсолюта («ноль ошибок») в бюджет. Стопроцентная надёжность недостижима и не нужна; error budget явно говорит, сколько риска можно тратить на новые фичи.
Заблуждение. «Зелёные дашборды (200 OK, latency в норме) = поиск работает хорошо.» Доступность ≠ качество. Выдача может деградировать при идеальных технических метриках. Нужны прокси качества (CTR-сдвиг, pogo-sticking, доля пустых).
Заблуждение. «Чем больше алертов, тем безопаснее.» Наоборот: шумные алерты вызывают усталость, и настоящий инцидент тонет. Меньше алертов, но симптомных и с привязкой к пользователю.
Лаба / практикаЗаблуждение. «Абсолютный порог проще и надёжнее.» Он игнорирует сезонность и заваливает ложными тревогами. Сравнение с базлайном того же периода — обязательно.
Дано: часовой ряд CTR топовых запросов за 8 дней (или сгенерируйте синтетику: суточная синусоида + недельный спад в выходные + шум; в один час 7-го дня впишите провал −20%).
Шаги:
- Постройте «нормальный профиль»: для каждого часа суток возьмите медиану по предыдущим неделям того же дня недели → ожидаемое значение и разброс (IQR / σ).
- Реализуйте детектор: алерт, если текущее значение ниже ожидаемое − k·σ (подберите k, например 3) и держится ≥2 часа.
- Проверьте, что детектор поймал вписанный провал и не сработал на нормальной ночной просадке и на выходных.
- Постройте ROC-подобный компромисс: меняя k от 1 до 5, постройте «поймано инцидентов vs ложных тревог». Выберите k, балансирующий чувствительность и шум.
Время: ~60 мин. Критерий «сделано»: детектор ловит инцидент, молчит на сезонности, и студент объяснил, почему сравнение с профилем «тот же час того же дня недели» устойчивее абсолютного порога.
Контрольные вопросы
- Чем метрики, логи и трейсы дополняют друг друга при разборе инцидента?
- Приведите три прокси-сигнала деградации качества (не доступности) в реальном времени.
- Что такое canary и shadow деплой? Чем они отличаются и зачем нужны?
- Почему алерт на абсолютный порог CTR плох? Чем заменить?
- Что такое error budget и как он управляет балансом «фичи vs стабильность»?
- Почему симптомные алерты («успешных сессий упало») ценнее причинных («CPU 90%»)?
- Как усталость от алертов снижает надёжность системы?
Цели обучения
После главы студент сможет:
- Объяснить, почему краткосрочная метрика A/B может расти при долгосрочном вреде продукту.
- Перечислить метрики «здоровья» выдачи: разнообразие, свежесть, доверие к источникам, отсутствие манипуляций.
- Описать механизмы расхождения short-term и long-term: эффект новизны, клик-приманка, петли обратной связи.
- Спроектировать holdout длительного действия и долгосрочные эксперименты.
- Сформулировать OEC, балансирующий немедленную вовлечённость и долгосрочное удержание.
Проблема: метрика, которая лжёт во времени
Самая дорогая ошибка в измерении поиска: оптимизировать метрику, которая растёт в краткосроке, но вредит в долгосроке. A/B-тест длится недели; некоторые эффекты проявляются месяцами.
Пример (классическая ловушка). Изменение продвигает кликбейт-заголовки и шок-контент. Краткосрочно: CTR растёт, вовлечённость растёт, A/B «зелёный». Долгосрочно: пользователи разочаровываются (контент не оправдывает заголовок), доверие к выдаче падает, удержание и число сессий снижаются — но через месяцы, когда тест давно закрыт и эффект приписали чему-то другому.
Метрики «здоровья» выдачиИнтуиция. Краткосрочные метрики меряют реакцию (кликнул, провзаимодействовал). Долгосрочные — отношение (вернулся, доверяет, считает поиск полезным). Можно купить реакцию ценой отношения — и это самоубийство в рассрочку.
Поверх «нашёл ли пользователь ответ» хорошие ПС следят за системными свойствами выдачи, которые не видны в CTR одной сессии, но определяют долгосрочное доверие:
- Разнообразие (diversity) — покрывает ли топ разные интенты/точки зрения, или схлопывается в один кластер (Модуль 15). Низкое разнообразие = пузырь, краткосрочно может не вредить кликам, долгосрочно сужает полезность.
- Свежесть (freshness) — доля актуального контента там, где он важен; не «застывает» ли выдача.
- Доверие к источникам (authority/trust) — доля выдачи от надёжных источников против сомнительных; устойчивость к манипуляциям (Модуль 16).
- Справедливость/баланс источников — не схлопывается ли выдача на узкий пул доменов; здоровье экосистемы контента.
- Отсутствие деградации хвоста — не улучшаем ли мы топ-запросы ценой длинного хвоста (агрегатная метрика может расти, а 30% редких запросов — деградировать).
Механизмы расхождения short-term ↔ long-termВнимание (хвост). Агрегатная метрика усредняет. Изменение может поднять частотные запросы и уронить редкие. Среднее вырастет, а большая доля пользователей с хвостовыми запросами получит хуже. Всегда смотрите метрики в разрезе по сегментам (частотность запроса, язык, регион, новизна пользователя), а не только агрегат.
- Эффект новизны и приедания (novelty / primacy). Новая фича сначала привлекает вниманием, метрика растёт; через недели интерес гаснет до базы (или ниже). Краткосрочный A/B переоценивает эффект.
- Клик-приманка (engagement-bait). Оптимизация немедленной вовлечённости вознаграждает провокацию и кликбейт, что подтачивает доверие.
- Петли обратной связи (feedback loops). Клики обучают модель (Модуль 11), модель влияет на то, что показывается, что влияет на клики. Усиление популярного душит разнообразие и новые хорошие документы (rich-get-richer); позиционное смещение закрепляется. Эффект накапливается за месяцы — за горизонтом обычного A/B.
- Обучение пользователя. Люди адаптируются к выдаче (учатся формулировать иначе); их поведение через полгода — другое.
Как мерить долгосрочноеЗаблуждение. «Если за 2 недели A/B метрика выросла и значима — изменение однозначно хорошее.» Нет. Эффект новизны и отложенный вред кликбейта невидимы за 2 недели. Краткосрочный значимый рост — необходимое, но недостаточное условие для продуктового решения.
- Длинные эксперименты / long-term holdout. Небольшую долю пользователей надолго (месяцы) держат на старой версии («контроль будущего»). Сравнивая её с теми, кто получил все накопленные изменения, видим кумулятивный долгосрочный эффект всех релизов — то, что покапельные двухнедельные A/B не ловят.
- Сегментные когорты по новизне. Отдельно смотреть новых vs старых пользователей: эффект новизны виден как расхождение, затухающее со временем.
- Surrogate-метрики долгосрочного удержания. Найти краткосрочный сигнал, исторически предсказывающий долгосрочное удержание (например, доля long-click без последующего возврата), и оптимизировать его как прокси долгосрочного.
- OEC (Overall Evaluation Criterion). Единая целевая метрика, сознательно комбинирующая немедленную пользу с прокси долгосрочного здоровья, чтобы команда не оптимизировала вовлечённость в ущерб доверию.
Интуиция. Long-term holdout — это «контрольная группа, которую не трогают год». Каждый отдельный релиз казался улучшением; holdout показывает, сложились ли улучшения в реальный долгосрочный рост или они взаимно гасились / разменивались на доверие.
Частые заблужденияSEO-врезка. Метрики здоровья объясняют, почему ПС со временем давят кликбейт, тонкий контент и манипулятивные сайты, даже если по ним кликают: краткосрочный CTR такого контента высок, но он подтачивает долгосрочное доверие пользователя к выдаче. Стратегия «сделать действительно полезную страницу» выигрывает именно на долгосрочной оптимизации ПС, а не на сиюминутном CTR.
Заблуждение. «Вовлечённость (engagement) = качество.» Вовлечённость можно раздуть провокацией и манипуляцией ценой доверия. Долгосрочное удержание и удовлетворённость — честнее, но мерятся дольше.
Заблуждение. «Если агрегатная метрика выросла, всем стало лучше.» Среднее скрывает деградацию сегментов (хвост запросов, новые пользователи, отдельные регионы). Смотрите разрезы.
Лаба / практикаЗаблуждение. «Петли обратной связи — теория, на практике не важны.» На практике именно они тихо схлопывают разнообразие и закрепляют позиционное смещение за месяцы. Их не видно в одном A/B, но они формируют систему.
Дано (мысленный + расчётный эксперимент): симуляция петли обратной связи на 10 документах по одному запросу.
- Истинные релевантности (скрыты от системы): r = [0.9, 0.85, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3, 0.2, 0.1].
- Стартовые показы случайны. Вероятность клика на показанный документ ранга pos: click = r_doc · pos_bias[pos], где pos_bias = [1.0, 0.6, 0.4, 0.3, 0.25, ...] (позиционное смещение, Модуль 11).
- Каждый «день» система ранжирует по накопленному CTR (клики/показы), показывает топ-k=5, набирает клики, обновляет статистику.
- Прогоните 50 «дней». Постройте, как меняется топ-5 и накопленный CTR документов.
- Покажите эффект rich-get-richer: документ, случайно попавший высоко вначале, набирает клики из-за позиции и закрепляется, даже если его истинная r ниже соседа, застрявшего внизу.
- Введите контрмеру: ε-исследование (с вероятностью ε=0.1 показывать случайный документ из хвоста) и debiasing CTR делением на pos_bias. Покажите, что итоговый порядок ближе к истинному r.
- Сформулируйте, как это связано с долгосрочным здоровьем: что краткосрочный CTR без debiasing закрепляет несправедливый порядок и душит хорошие документы из хвоста.
Время: ~75 мин. Критерий «сделано»: симуляция воспроизводит rich-get-richer без контрмер, ε-исследование + debiasing заметно приближают порядок к истинному, и студент явно связывает наивную оптимизацию CTR с долгосрочной деградацией разнообразия/справедливости.
Контрольные вопросы
- Приведите конкретный сценарий, где краткосрочная метрика растёт, а продукт долгосрочно деградирует.
- Назовите четыре метрики «здоровья» выдачи и зачем каждая нужна.
- Что такое эффект новизны и как он искажает короткий A/B?
- Как работает петля обратной связи клик→модель→показ→клик и к чему она ведёт?
- Что такое long-term holdout и какой вопрос он отвечает, а двухнедельный A/B — нет?
- Почему агрегатную метрику нельзя смотреть без разрезов по сегментам?
- Что такое OEC и зачем сознательно «зашивать» в него прокси долгосрочного здоровья?
- Как ε-исследование и debiasing CTR борются с rich-get-richer?
- Измерение — это петля обратной связи, замыкающая конвейер: офлайн-метрики становятся целью обучения (Модуль 9), онлайн-сигналы и мониторинг подсказывают, что чинить.
- Офлайн-оценка (золотой набор + асессоры + пулинг) — быстрый, дешёвый, воспроизводимый фильтр гипотез; её слабости — смещение пула, старение набора и зависимость от качества инструкции.
- Метрики ранжирования различаются моделью пользователя: nDCG — суммарная польза с позиционным дисконтом, ERR — каскадная остановка (верхние документы гасят вклад нижних), MAP/MRR — для бинарной/одноответной релевантности.
- Качество разметки проверяют согласием: raw agreement обманчив, κ Коэна корректирует на случай, α Криппендорфа уважает порядок шкалы и работает с многими асессорами.
- A/B-тест даёт причинный вывод через рандомизацию; единица — обычно пользователь; перед запуском — A/A-тест.
- Статистика A/B: размер выборки n ∝ σ²/Δ² (маленькие эффекты дороги), p-value — вероятность данных при H0 (а не гипотезы при данных), ДИ показывает размер эффекта и информативнее голого p-value.
- Интерливинг на 1–2 порядка чувствительнее A/B (сравнение внутри показа убирает межпользовательский шум), но меряет только относительное ранжирование.
- Ловушки: peeking, множественные сравнения, сетевые эффекты, эффект новизны — каждая раздувает ошибки и требует своей защиты.
- Наблюдаемость ловит деградацию в проде; доступность ≠ качество — нужны прокси-сигналы качества, алерты на отклонение от сезонного профиля, SLI/SLO/error budget, canary/shadow.
- Долгосрочные эффекты регулярно расходятся с краткосрочными: эффект новизны, кликбейт, петли обратной связи; ловятся long-term holdout, сегментными когортами, OEC с прокси здоровья выдачи.
- Золотой набор (gold set, judgments) — фиксированный набор запросов с заранее размеченной релевантностью документов для офлайн-оценки.
- Асессор (assessor) — человек, выставляющий оценку релевантности паре (запрос, документ).
- Пулинг (pooling) — построение разметки путём объединения топов нескольких систем; документы вне пула считаются нерелевантными.
- Смещение пула — систематическая недооценка систем, находящих хорошие документы вне размеченного пула.
- ERR (Expected Reciprocal Rank) — метрика с каскадной моделью пользователя: вклад позиции зависит от качества документов выше неё.
- κ Коэна (Cohen's kappa) — мера согласия двух асессоров с поправкой на случайное совпадение.
- α Криппендорфа (Krippendorff's alpha) — обобщённая мера согласия для многих асессоров, неполной и порядковой разметки.
- A/B-тест — рандомизированный контролируемый эксперимент: контроль vs тритмент на реальном трафике.
- A/A-тест — проверка системы измерения на двух одинаковых группах (должны быть неразличимы).
- Интерливинг (interleaving) — сравнение двух систем смешиванием их выдач в один список у одного пользователя.
- Team-Draft Interleaving — схема интерливинга с поочерёдным «набором» документов системами.
- MDE (Minimum Detectable Effect) — минимальный эффект, который эксперимент способен уверенно обнаружить.
- Мощность (power, 1−β) — вероятность обнаружить реальный эффект.
- p-value — вероятность наблюдать такие (или более экстремальные) данные при условии истинности H0.
- Доверительный интервал (ДИ) — интервал оценки разницы метрик с заданным уровнем покрытия.
- Peeking (подглядывание) — многократная промежуточная проверка значимости, раздувающая ошибку I рода.
- OEC (Overall Evaluation Criterion) — единая целевая метрика эксперимента, комбинирующая немедленную пользу и долгосрочное здоровье.
- Long-click / dwell-time — клик с долгим пребыванием на странице (прокси удовлетворённости); pogo-sticking — клик и быстрый возврат (прокси неудовлетворённости).
- SLI / SLO / error budget — индикатор уровня сервиса / целевое значение / допустимая доля нарушений.
- Canary / shadow деплой — выкатка на малую долю трафика с автооткатом / прогон копии трафика без показа пользователю.
- Петля обратной связи — цикл клик→обучение модели→показ→клик, закрепляющий популярное (rich-get-richer) и позиционное смещение.
- Long-term holdout — группа пользователей, надолго удерживаемая на старой версии, для измерения кумулятивного долгосрочного эффекта.
- Опирается на Модуль 1 — базовые метрики (precision/recall, F1, MAP, MRR, nDCG, PR-кривые): здесь они применяются к офлайн-оценке и дополняются ERR.
- Опирается на Модуль 9 — офлайн-метрики (nDCG) служат целевой функцией обучения ранжированию; гигиена train/test по запросам.
- Связан с Модулем 8 — каждый новый фактор проходит измерение перед выкаткой.
- Связан с Модулем 11 — поведенческие сигналы (клики, dwell-time) — основа онлайн-метрик и источник смещений (позиционное, петли обратной связи).
- Связан с Модулем 12 — мониторинг latency по уровням каскада L0–L3, доля таймаутов модели и fallback-ов.
- Связан с Модулем 14 — наблюдаемость источников федерации, доля их таймаутов и показов.
- Связан с Модулем 15 — разнообразие выдачи как метрика здоровья.
- Связан с Модулем 16 — устойчивость к манипуляциям и доверие к источникам как долгосрочные метрики здоровья.
- Классические работы и обзоры по офлайн-оценке IR: методология пулинга, свойства nDCG/MAP, вывод и интерпретация ERR (каскадная модель).
- Обзоры по межасессорному согласию: κ Коэна, взвешенная κ, α Криппендорфа и их свойства на порядковых шкалах.
- Литература по контролируемым онлайн-экспериментам в вебе: дизайн A/B, расчёт мощности и размера выборки, OEC, типичные ловушки (peeking, множественные сравнения, эффект новизны).
- Работы по интерливингу: team-draft и вероятностный интерливинг, анализ чувствительности относительно A/B.
- Материалы по наблюдаемости и SRE: SLI/SLO/error budget, симптомные vs причинные алерты, canary/shadow-деплой.
- Исследования долгосрочных эффектов в экспериментах: long-term holdout, surrogate-метрики удержания, петли обратной связи и их влияние на разнообразие и справедливость выдачи.
