Таксономия факторов ранжирования

[kirill_ir]

Часть IV · ~9 ч · Сложность: (средний) · Пререквизиты: Модуль 4, 6, 7

Обзор модуля

К этому моменту мы умеем строить обратный индекс (Модуль 4), считать текстовую релевантность (Модуль 6) и извлекать авторитетность из ссылочного графа (Модуль 7). Каждый из этих механизмов производит числа — частные оценки того, насколько документ хорош по какому-то отдельному измерению. В реальной поисковой системе таких чисел не два-три, а тысячи. Совокупность этих чисел и есть факторы ранжирования (ranking features/factors) — вход модели, которая складывает их в итоговую оценку релевантности документа запросу.

Этот модуль — не про конкретные алгоритмы (они в Модулях 6, 7 и в Модуле 9 про learning-to-rank), а про инвентаризацию и классификацию. Мы строим карту факторного пространства: из чего состоит один фактор, по каким осям факторы делятся (статические/динамические, документ/хост/домен/запрос), на какие семейства группируются (текст, ссылки, поведение, нейро, время, гео, тематика/коммерция). Без такой карты невозможно ни проектировать модель ранжирования, ни отлаживать её, ни понимать, почему документ стоит на своей позиции.

В сквозном конвейере «обход → индекс → факторы → ранжирование → выдача → постобработка → измерение» этот модуль занимает стадию факторов: то промежуточное звено, где сырые данные индекса, графа и логов превращаются в признаковые векторы, готовые к скармливанию каскаду ранжирования (Модуль 12) и моделям обучения (Модуль 9). Фактор — это контракт между «хранилищем сигналов» и «моделью»: модель не видит документ, она видит только его факторный вектор.

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

Внимание. Все числовые доли весов групп в этом модуле — иллюстративные и ориентировочные. Реальные веса непубличны, меняются между запросами, классами запросов, странами и релизами модели, и вообще не существуют как единый фиксированный набор (см. главу 8.4). Цифры даны, чтобы передать порядок величин и приоритеты, а не как факт.

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

• Студент — обязательны главы 8.1 и 8.2 (что такое фактор и как его классифицировать — это словарь, на котором держится весь курс). Глава 8.3 — обязательна на уровне семейств и их интуиции. Глава 8.4 ((продвинутый)) — желательна: она объясняет, почему «список факторов» ≠ «модель».
• Инженер — всё обязательно. Особое внимание: глава 8.1 (стадия вычисления и способ потребления фактора — это про конвейер и латентность), инженерные заметки про фичестор, версионирование и backfill, и глава 8.4 (управление жизненным циклом факторов, мёртвые слоты как технический долг).
• SEO — главы 8.3 и 8.4 — ядро. Семейства факторов объясняют, на что вообще можно влиять; глава 8.4 объясняет, почему гнаться за «мёртвыми» факторами (старые ссылки, накрутка кликов) — пустая трата ресурсов. SEO-врезки разбросаны по всему модулю.
• Смешанный — последовательно весь модуль; формальные перечни осей в 8.2 можно бегло просмотреть при первом проходе и вернуться при работе с реальной моделью.

Карта модуля

• 8.1. Анатомия фактора — имя, группа/тег, стадия вычисления, способ потребления моделью. (средний)
• 8.2. Оси классификации — статические/динамические; документ/хост/домен/запрос. (средний)
• 8.3. Семейства факторов — текстовые, ссылочные, поведенческие, нейро, временные, гео, тематические/коммерческие. (средний)
• 8.4. «Живые» vs «мёртвые» слоты — почему наличие фактора ≠ влияние на выдачу. (продвинутый)

Глава 8.1. Анатомия фактора: имя, группа/тег, стадия вычисления, способ потребления моделью (средний)

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

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

• Дать определение фактору ранжирования как именованной функции от пары (запрос, документ) (или её проекций) с заданным типом и областью значений.
• Описать четыре атрибута анатомии фактора: имя/идентификатор, группа/тег, стадия вычисления, способ потребления моделью.
• Различить стадии вычисления фактора (оффлайн-предрасчёт, build-time, query-time) и объяснить их влияние на латентность и свежесть.
• Объяснить, как фактор потребляется моделью: как сырое число, как нормализованное/бинаризованное значение, как эмбеддинг, как кросс-признак.
• Спроектировать «паспорт фактора» — минимальный набор метаданных, нужный для его сопровождения.

Конспект

Что такое фактор формально

Интуиция. Фактор — это один «датчик», который смотрит на документ (иногда в паре с запросом) и выдаёт число. BM25 — датчик текстового совпадения. PageRank — датчик авторитетности. «Доля кликов по этому документу за 28 дней» — поведенческий датчик. Модель ранжирования не работает с документами напрямую — она работает с показаниями этих датчиков.

Формально фактор f — это функция

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

f : (q, d, ctx) → ℝ   (или → {0,1}, или → ℝ^k для векторных факторов)

где q — запрос (возможно, пустой для запросо-независимых факторов), d — документ, ctx — контекст (язык, регион, устройство, время). Значение фактора — это признак (feature). Набор значений всех факторов для конкретной пары (q, d) — это факторный (признаковый) вектор x ∈ ℝ^M, где M — число факторов (в зрелой системе — тысячи).

Модель ранжирования (Модуль 9) — это функция score = model(x), переводящая вектор в скаляр. Всё остальное в этом модуле — про то, как устроены компоненты x.

Заблуждение. «Фактор и сигнал — одно и то же.» В строгой терминологии сигнал (signal) — это источник информации (клики, текст, граф), а фактор/признак (feature) — конкретное числовое представление этого сигнала, скормленное модели. Из одного сигнала «клики» получают десятки факторов: CTR за 1 день, за 28 дней, dwell-time, доля long-clicks, last-click и т.д. В этом курсе мы используем «фактор» и «признак» как синонимы, а «сигнал» — для источника.

Атрибут 1. Имя/идентификатор

У каждого фактора есть стабильный машинный идентификатор (text.bm25.body, link.pagerank.host, behav.ctr.28d.region) и человекочитаемое описание. Идентификатор — это первичный ключ во всей инфраструктуре: по нему фактор адресуется в фичесторе, в конфиге модели, в логах, в А/Б-эксперименте.

Инженерная заметка. Имя фактора — это API. Переименовать «живой» фактор так же больно, как переименовать колонку в БД, на которую завязаны десятки потребителей. Поэтому идентификаторы фактора версионируют, а не переименовывают: bm25_body → bm25_body_v2, старый остаётся ради воспроизводимости старых моделей. Отсюда же растут «мёртвые слоты» главы 8.4: версия v1 остаётся в схеме навсегда.

Атрибут 2. Группа/тег

Фактор приписан к одному или нескольким семействам (глава 8.3) и помечен осевыми тегами (глава 8.2): статический/динамический, уровень сущности (документ/хост/домен/запрос), запросо-зависимый/независимый. Теги — не украшение: по ним

• группируют важность (feature importance) при анализе модели,
• применяют политики (например, «на коммерческих запросах занизить вес группы link.legacy»),
• управляют бюджетом латентности (query-time факторы дороги — их считают только для топ-кандидатов).

Атрибут 3. Стадия вычисления

Ключевой инженерный атрибут: когда значение фактора вычисляется. Это определяет и латентность поиска, и свежесть сигнала.

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

Стадия                   |  Когда считается                    |  Что туда попадает                                                       |  Свежесть                                |  Стоимость в запросе
-------------------------+-------------------------------------+--------------------------------------------------------------------------+------------------------------------------+----------------------------------------
Оффлайн-предрасчёт       |  Периодические батчи, асинхронно    |  PageRank, тематические векторы хоста, агрегаты кликов за 28 дней        |  Низкая (часы–дни)                       |  ~0 (чтение готового)
Build-time (индексация)  |  При построении/обновлении индекса  |  Длина документа, статические текстовые статистики, эмбеддинг документа  |  Средняя (привязана к циклу индексации)  |  ~0 (лежит рядом с постингом)
Query-time               |  В момент обработки запроса         |  BM25 (зависит от q), кросс-энкодерные нейрооценки, признаки пары (q,d)  |  Максимальная                            |  Высокая (считается на каждый кандидат)

Интуиция. Чем ближе вычисление к моменту запроса, тем «свежее» и точнее фактор — но тем дороже. Поэтому каскад ранжирования (Модуль 12) расставляет факторы по стадиям: на ранних, дешёвых стадиях L0/L1 — почти только предрассчитанные и build-time факторы (отбор тысяч кандидатов), а тяжёлые query-time нейрофакторы считают только на финальной стадии L3 для десятков-сотен документов.

Инженерная заметка. Бюджет латентности как закон распределения факторов. Если query-time фактор стоит 2 мс на документ, то применить его к 10 000 кандидатов — это 20 секунд, недопустимо. Применить к 100 финалистам — 200 мс, на грани. Поэтому правило: дорогой фактор живёт поздно в каскаде. Стадия вычисления фактора — это не свойство «природы» фактора, а инженерное решение о том, где в каскаде он окупается.

Атрибут 4. Способ потребления моделью

Одно и то же сырое значение можно подать модели по-разному, и это влияет на то, что модель сможет из него извлечь:

• Сырое число (raw) — bm25 = 7.3 как есть. Подходит для деревьев решений (GBDT), которым безразличен масштаб.
• Нормализованное / стандартизованное — приведение к [0,1] или к z-оценке. Критично для линейных моделей и нейросетей, чувствительных к масштабу.
• Бинаризованное / бакетизированное (binned) — «PageRank в топ-1%?», «длина < 100 слов?». Превращает непрерывный фактор в категориальные пороги; помогает деревьям и ловит нелинейности.
• Эмбеддинг (vector feature) — фактор сам по себе вектор (например, нейропредставление документа из Модуля 10/нейропоиска). Потребляется как блок входов или через скалярное произведение с вектором запроса.
• Кросс-признак (cross/interaction feature) — комбинация двух факторов: bm25 × is_commercial_query, ctr / pagerank. Кодирует «фактор A важен только при условии B». Деревья ловят такие взаимодействия автоматически; линейным моделям их подают явно.

Пример. Один сигнал — четыре фактора. Сигнал «свежесть документа» (дата публикации). Из него рождаются: (1) сырой age_days; (2) бакет {<1ч, <1д, <7д, <30д, старше}; (3) кросс-признак age_days × query_is_news (свежесть важна только для новостных запросов!); (4) булев is_stale = age_days > 365. Это четыре разных фактора из одного сигнала, и у каждого свой вес в модели.

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

Паспорт фактора

Сведём анатомию в «паспорт» — минимальный набор метаданных, который сопровождает каждый зрелый фактор:

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

id:            behav.ctr.28d.region
description:    Доля кликов по документу за 28 дней, нормированная по региону
family:         поведенческое
axes:           динамический; уровень=документ; запросо-зависимый(слабо)
stage:          оффлайн-предрасчёт (батч 1/сутки)
type:           ℝ ∈ [0,1]
consumption:    raw + bucket(5)
owner:          team-behavior
status:         ACTIVE        # ACTIVE | DEPRECATED | DEAD
introduced:     model-v37
last_reviewed:  2026-01

Поле status — мост к главе 8.4: оно отвечает на вопрос «жив ли слот».

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

Заблуждение. «Раз фактор посчитан и лежит в индексе — модель его использует.» Нет. Между «фактор вычислен и записан» и «фактор имеет ненулевой вес в активной модели» — пропасть. Вычисление и потребление развязаны: фактор может быть DEAD (вес ≈ 0), но продолжать считаться по инерции конвейера. Это и есть тема 8.4.

Заблуждение. «Чем больше факторов, тем лучше ранжирование.» Не линейно. Лишние, коррелированные или шумные факторы повышают риск переобучения, удорожают вычисление и усложняют отладку. Зрелые системы периодически удаляют факторы, а не только добавляют.

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

Задача. Составьте «паспорта» для 8 факторов из одного сигнала «клики». Дано: лог кликов (query, doc, clicked, dwell_ms, position).

Шаги:

1. Придумайте ≥8 различных факторов из этого сигнала (CTR за разные окна, dwell-производные, position-debiased CTR, доля long-clicks и т.д.).
2. Для каждого заполните паспорт (id, описание, оси, стадию, тип, способ потребления).
3. Для каждого ответьте: query-зависимый он или нет? На какой стадии каскада применим (L0–L3)?
4. Оцените, какие два фактора сильнее всего коррелируют, и аргументируйте, нужен ли в модели один из них или оба.

Псевдокод агрегата CTR с дебиасингом по позиции:

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

ctr_debiased(doc) = clicks(doc) / Σ_imp ( examine_prob(position_imp) )
# examine_prob — модель внимания к позиции из клик-модели (Модуль про поведение)

Время ~50 мин. Критерий «сделано»: ≥8 непротиворечивых паспортов; для каждого корректно определены оси и стадия; найдена и объяснена пара коррелированных факторов.

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

1. Чем сигнал отличается от фактора? Приведите пример, где из одного сигнала выходит ≥3 факторов.
2. Почему дорогой query-time фактор нельзя применять на ранней стадии каскада? Оцените порядок стоимости на числовом примере.
3. Какие способы потребления фактора критичны для линейной модели и почему они менее важны для GBDT?
4. Что такое кросс-признак? Сконструируйте такой, который кодирует «свежесть важна только для новостных запросов».
5. Зачем фактору поле status в паспорте? Что произойдёт, если его не вести?
6. Почему идентификатор фактора нельзя переименовывать, а нужно версионировать?
7. Документ-кандидат прошёл L0 по дешёвым факторам, но «отвалился» на L3. Какие стадии факторов сработали на L0 и L3?

Глава 8.2. Оси классификации: статические/динамические; документ/хост/домен/запрос (средний)

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

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

• Классифицировать любой фактор по двум главным осям: динамика (статический/динамический) и уровень сущности (документ/хост/домен/запрос/пара).
• Объяснить, почему запросо-зависимость фактора определяет стадию его вычисления и место в каскаде.
• Различить уровни агрегации (документ vs хост vs домен) и понять механизм наследования сигнала вверх/вниз по иерархии.
• Предсказать, как осевые теги фактора влияют на его свежесть, стоимость и устойчивость к манипуляции.

Конспект

Оси — это перпендикулярные измерения, по которым раскладывается любой фактор независимо от его семейства. Семейство (глава 8.3) отвечает на вопрос «откуда сигнал», оси — «как он устроен по динамике и масштабу».

Ось 1. Статический ↔ динамический

• Статический (query-independent, статический) — значение не зависит от запроса и меняется медленно: PageRank хоста, язык документа, длина текста, тематический вектор. Предрассчитывается оффлайн, читается за константу.
• Динамический (query-dependent или быстро меняющийся) — значение зависит от запроса и/или быстро эволюционирует: BM25 (зависит от слов запроса), нейрооценка пары (q,d), всплеск свежести по «горящей» теме.

Интуиция. Статический фактор — «свойство документа само по себе» (как масса тела). Динамический — «свойство в контексте» (как вес тела, зависящий от того, на какой планете взвешиваем). Запрос — это «планета».

Тонкость: «запросо-независимый» и «статический» — не одно и то же, хотя часто совпадают. CTR документа запросо-зависим (по разным запросам кликают по-разному), но агрегируется батчем — то есть «медленный». Поэтому корректнее держать две под-оси:

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

                        |  Запросо-независимый    |  Запросо-зависимый
------------------------+-------------------------+------------------------------
Медленный (предрасчёт)  |  PageRank, язык, длина  |  CTR(q,d) за 28 дней
Быстрый (query-time)    |  — (редко)              |  BM25, нейрооценка пары (q,d)

Инженерная заметка. Запросо-зависимость — главный водораздел стоимости. Запросо-независимый фактор считается один раз на документ (амортизируется по всем запросам). Запросо-зависимый — на каждую пару (q,d), то есть заново для каждого запроса и каждого кандидата. Отсюда правило каскада: чем «правее» (дороже, query-time) фактор, тем меньше документов до него доживает.

Ось 2. Уровень сущности: документ ↔ хост ↔ домен ↔ запрос

Сигнал привязывается к разным уровням иерархии веба:

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

домен          example.com                  (самый широкий)
  └ хост        blog.example.com
      └ путь    blog.example.com/2026/...
          └ документ  конкретная страница    (самый узкий)

• Факторы уровня документа — про конкретную страницу: её BM25, её эмбеддинг, её свежесть, её клики.
• Факторы уровня хоста — агрегат по поддомену: средняя авторитетность хоста, его тематический профиль, его историческое качество.
• Факторы уровня домена — ещё шире: возраст домена, доменный траст, общая репутация.
• Факторы уровня запроса — про запрос, не про документ: его частотность, навигационность/коммерческость/свежестная-чувствительность, язык, геопривязка. Они одинаковы для всех кандидатов данного запроса, но критически меняют веса других факторов (через кросс-признаки).
• Факторы уровня пары (q,d) — собственно мера соответствия запроса документу (BM25, нейрооценка). Это «сердце» релевантности.

Пример. Наследование сигнала вверх и вниз. Новая страница на авторитетном хосте ещё не имеет собственных кликов и ссылок. Откуда взять её ранг? Через наследование от хоста/домена: документ заимствует часть авторитетности и тематического профиля родителя. Наоборот, качество хоста — это агрегат вниз→вверх по его документам. Так система борется с холодным стартом (cold start) новых страниц.

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

SEO-врезка. Разделение уровней объясняет два частых наблюдения. Первое: «почему новая страница на сильном сайте сразу неплохо ранжируется» — наследование хост/домен-факторов. Второе: «почему один спамный раздел тянет вниз весь сайт» — деградация хостового агрегата качества. Работать нужно и над страницей (документ-уровень), и над общим качеством хоста (хост/домен-уровень) — это разные группы факторов.

Сводная классификация одного фактора

Любой фактор получает кортеж тегов. Примеры:

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

Фактор               |  Динамика      |  Запросо-завис.  |  Уровень     |  Стадия
---------------------+----------------+------------------+--------------+----------------------------
PageRank хоста       |  статический   |  нет             |  хост        |  оффлайн
BM25 по body         |  динамический  |  да              |  пара (q,d)  |  query-time
CTR(q,d) 28д         |  медленный     |  да              |  документ    |  оффлайн-батч
возраст домена       |  статический   |  нет             |  домен       |  оффлайн
query_is_commercial  |  —             |  — (про запрос)  |  запрос      |  query-time (классификатор)
нейрооценка (q,d)    |  динамический  |  да              |  пара (q,d)  |  query-time (L3)

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

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

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

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

Задача. Дан список из 20 факторов (выдаётся текстом: смесь текстовых, ссылочных, поведенческих, временных). Для каждого проставьте кортеж осей (динамика, запросо-зависимость, уровень, стадия) и обоснуйте.

Затем:

1. Постройте таблицу «уровень × запросо-зависимость» и разложите факторы по ячейкам.
2. Выделите факторы, которые можно посчитать оффлайн, и факторы, обязательно query-time. Объясните, как это распределяет их по стадиям L0–L3.
3. Найдите фактор-кандидат на «наследование от хоста» и опишите механизм холодного старта для него.

Время ~40 мин. Критерий «сделано»: корректные кортежи для ≥18 из 20; верное распределение по стадиям; внятно описан механизм наследования.

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

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

Глава 8.3. Семейства факторов: текстовые, ссылочные, поведенческие, нейро, временные, гео, тематические/коммерческие (средний)

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

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

• Перечислить основные семейства факторов и назвать характерные сигналы каждого.
• Сопоставить каждое семейство с его местом в конвейере и предыдущими модулями курса.
• Оценить относительную важность семейств в современной системе (иллюстративно) и объяснить исторический сдвиг весов.
• Связать устойчивость семейства к манипуляции с его весом в модели.

Конспект

Семейство (family/group) отвечает на вопрос «откуда сигнал». Перечислим семь основных семейств, для каждого — сигналы, происхождение в курсе, устойчивость к накрутке.

Текстовые факторы (lexical/text)

Мера лексического совпадения запроса и документа. BM25 и его варианты по зонам (title/body/anchor), близость термов (proximity), покрытие запроса, точные фразовые совпадения, поля метаданных. Происхождение — Модуль 6.

Интуиция. Базовый «честный» сигнал: документ говорит о том же, о чём спросили. Легко считается, хорошо интерпретируется, но легко подделывается (переспам), поэтому его вес ограничивают и страхуют антиспамом.

Нейросетевые (семантические) факторы (neural/semantic)

Эмбеддинги документа и запроса, их близость; кросс-энкодерные оценки пары (q,d); семантическое сопоставление поверх синонимии и перефразировок. Происхождение — нейропоиск (Модуль 10). Ловят смысл там, где лексика расходится («как починить кран» ↔ «ремонт смесителя»).

Инженерная заметка. Bi-encoder (раздельные эмбеддинги q и d, близость скалярным произведением) дёшев — эмбеддинг d предрассчитывается, поэтому работает на ранних стадиях как ANN-отбор. Cross-encoder (совместная обработка q и d) точнее, но дорог — только L3 на десятках финалистов.

Ссылочные факторы (link)

PageRank и производные, авторитетность хоста/домена, anchor-текст, трастовые метрики. Происхождение — Модуль 7. Важно: большая часть классических ссылочных факторов сегодня — низковесные или «мёртвые» (см. 8.4 и Модуль 7.4), так как легко манипулируются.

Поведенческие факторы (behavioral/click)

Сигналы взаимодействия пользователей с выдачей: CTR (позиционно-дебиасенный), dwell-time, long-clicks vs pogosticking (быстрый возврат), доля удовлетворённых сессий, переформулировки запроса. Происхождение — клик-модели (отдельный модуль про поведение).

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

Внимание. Поведенческие факторы зашумлены и смещены: позиционный bias (по верхним позициям кликают чаще независимо от релевантности), bias представления, накрутка. Без дебиасинга и антифрода они вредны. См. отдельный модуль про клик-модели и Модуль 16.

Временные факторы (freshness/temporal)

Возраст документа, частота обновления, всплеск интереса к теме (query deserves freshness), сезонность. Свежесть важна не всегда — для новостных и трендовых запросов критична, для справочных вредна. Отсюда — кросс-признаки freshness × query_type.

Геофакторы (geo/local)

Расстояние до пользователя, региональная релевантность документа, локальная популярность, язык/страна. Критичны для локального поиска («кофейня рядом»), не нужны для общеинформационных запросов. Тоже работают через кросс-признаки с типом запроса.

Тематические и коммерческие факторы (topical/commercial)

Тематическое соответствие документа интенту запроса (тематический вектор хоста vs тема запроса), коммерческость/транзакционность запроса, тип страницы (товар/статья/форум). Управляют тем, какие другие факторы важны: на коммерческих запросах усиливают одни группы и режут другие (например, классические ссылки — см. 8.4).

Иллюстративная раскладка веса групп

Внимание. Цифры ориентировочны и иллюстративны. Они НЕ публикуются, меняются между классами запросов, странами и релизами и не существуют как единый фиксированный набор (глава 8.4). Ниже — лишь порядок приоритетов для интуиции.

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

Семейство                              |  Ориентировочная доля веса                  |  Тренд
---------------------------------------+---------------------------------------------+------------------------------
Поведенческое                          |  ~30–40 %                                   |  ↑ растёт
Нейро-текстовое (семантика + текст)    |  ~25–35 %                                   |  ↑ растёт
Факторы запроса (тип/интент/коммерц.)  |  ~8–12 %                                    |  → стабильно (как модуляторы)
Хост/домен (качество, авторитет)       |  ~8–12 %                                    |  → стабильно
Ссылочные (классические)               |  ~5–10 %                                    |  ↓ падает
Временные / гео                        |  остаток, сильно зависят от класса запроса  |  ситуативно

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

ИЛЛЮСТРАТИВНО (не факт!)
поведение        ████████████████████  ~30-40%
нейро+текст      ██████████████████    ~25-35%
запрос(модуляция)██████                ~8-12%
хост/домен       ██████                ~8-12%
ссылки(классич.) ████                  ~5-10%
время/гео        ▒ситуативно по классу запроса

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

SEO-врезка. Раскладка задаёт приоритеты усилий. Главное — удовлетворённость пользователя (поведенческое: люди находят ответ и не возвращаются за другим) и смысловое соответствие интенту (нейро-текст), а не плотность ключевиков и не масса ссылок. Покупка ссылок бьёт в семейство с падающим весом и высоким риском обнуления (8.4). Тип запроса (коммерческий/информационный/локальный/свежестный) определяет, какие факторы вообще в игре — оптимизировать «вообще» бессмысленно, нужно под класс запроса.

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

Заблуждение. «Ссылки — главный фактор ранжирования.» Это устаревшее на 10–15 лет представление. Классические ссылочные факторы давно уступили вес поведению и семантике, а манипулятивная их часть обнуляется (8.4, Модуль 7.4).

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

Заблуждение. «Свежесть всегда повышает ранг.» Нет — только для запросов, «заслуживающих свежести». Для запроса «теорема Пифагора» свежесть нерелевантна, и фактор почти не весит.

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

Задача. Для трёх запросов разного класса — [новости спорта сегодня] (свежестный), [купить ноутбук] (коммерческий), [как варить яйцо] (информационный) — постройте профиль ожидаемой важности семейств.

Шаги:

1. Для каждого запроса проставьте качественные веса (низкий/средний/высокий) семи семействам.
2. Объясните, как фактор уровня запроса (тип/интент) модулирует остальные через кросс-признаки.
3. Укажите, какие семейства практически выключены для каждого запроса и почему.
4. Для коммерческого запроса аргументируйте, почему классические ссылки занижены сильнее, чем для информационного.

Время ~45 мин. Критерий «сделано»: три непротиворечивых профиля; явно показана модуляция через тип запроса; обоснована классо-зависимость веса ссылок.

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

1. Назовите семь семейств факторов и по одному характерному сигналу каждого.
2. Почему вес исторически сместился от ссылок к поведению и семантике? Сформулируйте принцип «устойчивость → вес».
3. Чем bi-encoder отличается от cross-encoder по стоимости и месту в каскаде?
4. Что такое позиционный bias в поведенческих факторах и почему без дебиасинга они опасны?
5. Почему свежесть и гео работают преимущественно через кросс-признаки с типом запроса?
6. Как тематические/коммерческие факторы «управляют» весами других семейств?
7. Оцените (качественно) профиль важности семейств для навигационного запроса [сайт налоговой].
8. Почему «иллюстративную раскладку весов» нельзя считать фактом о реальной системе?

Глава 8.4. «Живые» vs «мёртвые» слоты: почему наличие фактора ≠ влияние на выдачу (продвинутый)

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

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

• Объяснить разрыв между «фактор существует/вычисляется» и «фактор влияет на ранжирование».
• Классифицировать статус фактора: активный, низковесный, отключённый, наследие (legacy), мёртвый.
• Назвать причины смерти слота: гонка вооружений, смена модели, дрейф данных, дешёвая замена, остановленный эксперимент.
• Обосновать, почему «мёртвые» слоты не удаляют сразу (воспроизводимость, дешевизна хранения, риск регресса) и почему это технический долг.
• Применить этот принцип к критике наивного SEO («оптимизирую под фактор X»).

Конспект

Главный тезис

Интуиция. Зрелая поисковая система — как старый дом с десятками слоёв проводки. Часть проводов под напряжением (питают свет), часть обрезана у щитка, но висит в стене (когда-то питала люстру, которой нет). Снаружи — пучок проводов одинаков. Изнутри — «живо» меньшинство. Факторный набор такой же: сотни слотов считаются и хранятся, но лишь часть имеет ненулевой вес в активной модели.

Формально. Пусть модель — score = model(x), x ∈ ℝ^M. Влияние фактора i на выдачу измеряется не фактом x_i существует, а чувствительностью выхода к x_i: feature importance в GBDT, |вес| в линейной модели, аблация (выключили фактор → метрики не сдвинулись → фактор мёртв). Если ∂score/∂x_i ≈ 0 на реальном распределении запросов — слот мёртв, как бы аккуратно его ни считали.

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

Существование фактора  ──►  Вычисление и хранение  ──►  Подача в модель  ──►  Ненулевой вес  ──►  ВЛИЯНИЕ
                                                         (может быть )        (часто )
        └──────────────── разрыв, который игнорирует наивное SEO ──────────────────────┘

Спектр статусов слота

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

Статус               |  Считается?       |  Подаётся в модель?  |  Вес/важность    |  Пример
---------------------+-------------------+----------------------+------------------+------------------------------------------------------------------
Активный             |  да               |  да                  |  существенный    |  нейрооценка (q,d), дебиасенный CTR
Низковесный          |  да               |  да                  |  малый, но > 0   |  классический PageRank сегодня
Отключённый (gated)  |  да               |  да, но за условием  |  ≈0 вне условия  |  сигнал, включённый только для класса запросов
Наследие (legacy)    |  да (по инерции)  |  иногда              |  ≈0              |  старые ссылочные метрики v1
Мёртвый (dead)       |  да или нет       |  нет/да              |  0               |  устаревший клик-агрегат до дебиасинга, остановленный эксперимент

Заблуждение. «Если поисковик считает фактор, значит он на него опирается.» Считают по множеству причин, не связанных с текущим влиянием: воспроизводимость старых моделей, обратная совместимость схемы, дешёвый backfill «на всякий случай», незавершённая чистка. Влияние доказывается только аблацией/важностью на активной модели, не фактом вычисления.

Почему слоты умирают

1. Гонка вооружений (Модуль 7.4). Фактор стало легко накручивать → разработчики снижают его вес до ≈0, чтобы накрутка не работала. Сигнал жив в данных, но мёртв в модели. Классический случай — покупные ссылки и накрученные старые клики.
2. Смена модели. Новый релиз (например, переход на нейроранжирование) переучивает веса; часть старых факторов оказывается избыточной (их информация уже «зашита» в эмбеддинги) и получает ≈0.
3. Дрейф данных (data drift). Распределение изменилось (новый формат страниц, другое поведение пользователей), и фактор, обученный на старом распределении, перестал коррелировать с релевантностью.
4. Дешёвая замена. Появился более точный фактор-преемник (bm25_v2, дебиасенный CTR), и предшественник теряет вес, но остаётся в схеме.
5. Остановленный эксперимент. Фактор завели под А/Б-тест (Модуль про измерение), тест проиграл, флаг выключили — слот остался «висеть».

Инженерная заметка. Почему не удаляют сразу. (а) Воспроизводимость: старые модели в проде/архиве всё ещё читают слот; удаление ломает их. (б) Дешевизна хранения: ещё одна предрассчитанная колонка почти ничего не стоит, а риск удаления велик. (в) Риск регресса: «мёртвый» на средних запросах фактор может что-то значить на узком хвосте; аблация на агрегате этого не покажет. (г) Организационно: владелец фактора ушёл, никто не решается тронуть. Итог — факторный набор растёт почти монотонно, а доля живого падает. Это реальный технический долг: усложняет отладку, раздувает фичестор, маскирует, что́ на самом деле двигает выдачу.

Инженерная заметка. Как отличают живое от мёртвого. Регулярный аудит: (1) feature importance активной модели; (2) аблация — переобучить/прогнать модель без фактора и сравнить офлайн-метрики (Модуль про измерение); (3) анализ покрытия — на какой доле запросов фактор вообще ненулевой; (4) корреляционный анализ — не дублирует ли он более новый фактор. Кандидаты на удаление помечают DEPRECATED, выдерживают карантин, затем DEAD и (редко) физически удаляют.

Внимание. «Мёртвый на агрегате» ≠ «мёртвый везде». Фактор с нулевой средней важностью может быть решающим на узком классе запросов (gated). Поэтому статус определяют сегментированно, а не одним числом.

Почему это критично для SEO

SEO-врезка. Главный вывод модуля для оптимизатора. Огромная доля «факторов ранжирования» из публичных списков и чек-листов — это мёртвые или низковесные слоты: точное вхождение ключа в meta-keywords, плотность ключевых слов, масса покупных ссылок, накрутка кликов, возраст домена сам по себе. Они либо никогда не весили много, либо целенаправленно обнулены в ходе гонки вооружений. Оптимизировать под них — расходовать ресурс на «обрезанный провод».
Рабочее правило: вес фактора обратно пропорционален лёгкости его накрутки. Чем проще «нарисовать» сигнал, тем меньше на него опирается модель. Поэтому усилия окупаются там, где сигнал трудно подделать честно: реальная польза для пользователя (поведение), смысловое соответствие интенту (семантика), общее качество хоста. Гнаться за конкретным «фактором X» из чужого списка — методологическая ошибка: вы не знаете ни его статуса (жив/мёртв), ни его веса, ни условий включения.

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

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

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

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

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

Задача (аналитическая, на проектирование аудита). Дан синтетический «реестр факторов» из 30 записей с полями id, family, last_reviewed, coverage(%), importance, correlated_with. Файл выдаётся.

Шаги:

1. Классифицируйте каждый фактор по спектру статусов (активный/низковесный/отключённый/наследие/мёртвый), опираясь на importance и coverage.
2. Найдите ≥3 пары «преемник ↔ предшественник» по correlated_with и решите, какой из пары — кандидат в DEAD.
3. Найдите фактор с низкой средней важностью, но высокой важностью на узком сегменте (отдельная колонка по классам) — обоснуйте, почему его нельзя убивать.
4. Сформулируйте процедуру аудита: какие проверки, в каком порядке, какой критерий перевода ACTIVE → DEPRECATED → DEAD.

Бонус: оцените, какую долю реестра вы бы пометили мёртвой/низковесной (ожидается «большая часть» — это и есть мысль модуля).

Время ~60 мин. Критерий «сделано»: обоснованная классификация всех 30; ≥3 верные пары преемник/предшественник; найден и защищён gated-фактор; внятная процедура аудита с критериями переходов.

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

1. Сформулируйте разрыв между «фактор вычисляется» и «фактор влияет». Как доказывают влияние?
2. Перечислите спектр статусов слота и дайте пример каждого.
3. Назовите пять причин смерти слота. Какая связана с гонкой вооружений?
4. Почему мёртвые слоты не удаляют немедленно? Приведите четыре причины.
5. Почему «мёртвый на агрегате» фактор иногда нельзя удалять? Что такое gated-фактор?
6. Сформулируйте правило «вес ∝ устойчивости к накрутке» и приведите два следствия для SEO.
7. Почему подтверждение существования фактора (в патенте, статье, чек-листе) не означает, что под него стоит оптимизировать?
8. Как организовать регулярный аудит факторов? Какие сигналы переводят фактор в DEPRECATED, а затем в DEAD?

Итоги модуля

1. Фактор — именованная функция от (запрос, документ, контекст) в число/вектор; набор значений всех факторов для пары (q,d) — признаковый вектор x, единственный вход модели ранжирования score = model(x).
2. Анатомия фактора — четыре атрибута: имя/идентификатор (стабильный, версионируемый), группа/тег, стадия вычисления (оффлайн / build-time / query-time) и способ потребления (raw / нормализованный / бакетизированный / эмбеддинг / кросс-признак). Сводится в «паспорт» с полем status.
3. Стадия вычисления определяется бюджетом латентности: дорогой query-time фактор живёт поздно в каскаде (L3) на немногих финалистах; дешёвые предрассчитанные — рано (L0/L1) на миллионах кандидатов.
4. Две главные оси классификации: динамика (статический/динамический) и уровень сущности (документ/хост/домен/запрос/пара). Запросо-зависимость — главный драйвер стоимости. Сигнал наследуется вверх (документ→хост) и вниз (хост→документ), решая холодный старт, но создавая уязвимость агрегатов.
5. Семь семейств: текстовые, нейро-семантические, ссылочные, поведенческие, временные, гео, тематические/коммерческие. Каждое — со своим происхождением в курсе, стоимостью и устойчивостью к манипуляции.
6. Иллюстративная (ориентировочная, непубличная) раскладка весов: поведение ~30–40 %, нейро-текст ~25–35 %, факторы запроса ~8–12 %, хост/домен ~8–12 %, классические ссылки ~5–10 %, время/гео — ситуативно. Вес перетёк от легко-подделываемых сигналов к трудно-подделываемым.
7. Принцип «вес ∝ устойчивости к накрутке»: чем легче фактор накрутить, тем ниже его делают веса. Устойчивость к манипуляции — неявная ось важности.
8. Главный тезис: наличие фактора ≠ влияние. Зрелая система полна «мёртвых» и низковесных слотов (legacy-ссылки, старые клики, остановленные эксперименты), которые считаются по инерции, но имеют ≈0 вес. Влияние доказывается только аблацией/важностью на активной модели, и доля живого в факторном наборе — меньшинство.

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

• Фактор / признак (feature/ranking factor) — именованная функция от (q, d, ctx) в число или вектор; компонент входа модели ранжирования.
• Сигнал (signal) — источник информации (клики, текст, граф), из которого порождают факторы; из одного сигнала — много факторов.
• Признаковый вектор (feature vector) x — набор значений всех факторов для пары (q,d); единственный вход модели.
• Паспорт фактора — метаданные сопровождения: id, описание, оси, стадия, тип, способ потребления, владелец, статус.
• Стадия вычисления — когда считается фактор: оффлайн-предрасчёт / build-time (индексация) / query-time.
• Способ потребления — как значение подаётся модели: сырое, нормализованное, бакетизированное, эмбеддинг, кросс-признак.
• Кросс-признак (cross/interaction feature) — комбинация двух факторов, кодирующая «A важен при условии B».
• Статический / динамический фактор — независимый от запроса и медленный / зависимый от запроса или быстро меняющийся.
• Запросо-зависимый / независимый (query-dependent / -independent) — значение зависит от запроса (считается на каждую пару) или нет (раз на документ).
• Уровень сущности — к чему привязан фактор: документ / хост / домен / запрос / пара (q,d).
• Наследование сигнала — заимствование факторов между уровнями (документ ↔ хост ↔ домен); средство против холодного старта.
• Холодный старт (cold start) — нехватка собственных сигналов у новой страницы/хоста.
• Семейство факторов (family) — группа по источнику сигнала: текст, нейро, ссылки, поведение, время, гео, тематика/коммерция.
• Bi-encoder / cross-encoder — раздельное (дёшево, ранние стадии) / совместное (точно, дорого, L3) нейрокодирование пары (q,d).
• Позиционный bias (position bias) — искажение поведенческих факторов из-за того, что по верхним позициям кликают чаще независимо от релевантности.
• Дебиасинг — коррекция поведенческих факторов от позиционного и иных смещений.
• «Живой» / «мёртвый» слот — фактор с ненулевым / ≈нулевым весом (влиянием) в активной модели.
• Спектр статусов слота — активный / низковесный / отключённый (gated) / наследие (legacy) / мёртвый (dead).
• Аблация (ablation) — выключение фактора и измерение сдвига метрик; способ доказать влияние.
• Feature importance — мера вклада фактора в выход модели (важность в GBDT, |вес| в линейной модели).
• Дрейф данных (data drift) — изменение распределения данных, обесценивающее обученный на старом распределении фактор.
• Gated-фактор — фактор, влияющий только при выполнении условия (например, только на классе запросов).
• Технический долг факторного набора — рост числа вычисляемых слотов без чистки мёртвых; усложняет отладку и маскирует реальные драйверы выдачи.

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

• Опирается на Модуль 4 (индекс) — build-time факторы (длина, статистики, эмбеддинги документа) лежат рядом с постингами; обратный индекс — источник текстовых факторов.
• Опирается на Модуль 6 (текстовая релевантность) — текстовые и нейро-семантические семейства факторов; BM25 как образцовый query-time фактор.
• Опирается на Модуль 7 (ссылочный граф) — ссылочное семейство и идея деградации/обнуления; глава 7.4 — прямой источник тезиса о «мёртвых» факторах и принципа «вес ∝ устойчивости к накрутке».
• Питает Модуль 12 (каскад L0-L3 и serving) — распределение факторов по стадиям L0–L3 по бюджету латентности; gated-веса и классо-зависимые политики реализуются там.
• Питает Модуль 9 (обучение ранжированию) — признаковый вектор x — вход моделей LTR; статусы и важность факторов определяются переобучением модели.
• Связан с модулем про поведение/клик-модели — поведенческое семейство, дебиасинг, позиционный bias.
• Связан с Модулем 16 (антиспам) — накрученные поведенческие/ссылочные факторы как кандидаты в обнуляемые/мёртвые; устойчивость к манипуляции как ось важности.
• Связан с модулем про измерение/А-Б — аблация и feature importance как инструменты аудита живости факторов.

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

• Классические обзоры по признаковой инженерии (feature engineering) для ранжирования и по обучению ранжированию (learning-to-rank).
• Литература по фичесторам (feature stores): версионирование, backfill, онлайн/оффлайн-консистентность факторов.
• Работы по дебиасингу поведенческих сигналов и позиционному смещению в клик-моделях.
• Обзоры по нейропоиску: bi-encoder vs cross-encoder, плотный поиск (dense retrieval) и переранжирование.
• Материалы по интерпретируемости моделей: feature importance, аблационные исследования, анализ покрытия и корреляции факторов.
• Литература по адверсариальному информационному поиску (web spam) — как источник принципа «устойчивость к манипуляции → вес».
• Критические разборы публичных «списков факторов ранжирования» — как упражнение в отличении живых сигналов от мёртвых слотов.

[rabbit_wizard]

вопрос по структуре: вы складываете BM25, авторитет из ссылочного графа и анкорные сигналы в один скор. на каком этапе нормализуете шкалы? у меня BM25 гуляет 0-25, а PageRank вообще лог-распределён, без нормировки одна фича всё забивает

[nixosnerd]

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

[zfshacker]

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