Обзор модуляЧасть V · ~9 ч · Сложность: (средний) · Пререквизиты: Модуль 4, 5, 16
Часть документов теряет ценность со временем, а часть запросов имеет смысл только «прямо сейчас». «Что случилось сегодня», «счёт матча», «курс на сегодня», свежий релиз библиотеки — на таких запросах статья двухлетней давности проигрывает заметке часовой давности, даже если первая авторитетнее и подробнее. Этот модуль — о том, как поисковая система измеряет возраст контента, распознаёт потребность запроса в свежести, успевает проиндексировать новое за секунды-минуты и корректно подмешивает свежесть в ранжирование, не ломая авторитетные стабильные результаты.
В сквозном конвейере «обход → индекс → факторы → ранжирование → выдача → постобработка → измерение» модуль протягивает одну сквозную нить через несколько стадий. На стадии индекса живёт быстрый контур индексации (Модуль 4.5), который делает свежий документ находимым почти мгновенно. На стадии факторов датировщик материализует возраст и частоту обновления документа как статику. На стадии понимания запроса классификатор (Модуль 5) выставляет флаг потребности в свежести. На стадии ранжирования этот флаг переключает формулу (связь с выбором формулы под класс запроса, Модуль 12), добавляя буст свежести и функцию её угасания. На выдаче свежий контент нередко выносится в отдельную группировку (новостной блок). А антиспам (Модуль 16) страхует всё это от манипуляций «накручиванием даты».
К концу модуля вы будете уметь: оценивать дату и «возраст» документа из разнородных и ненадёжных сигналов; строить классификатор потребности запроса в свежести и отличать его от запросов, где свежесть вредна; проектировать near-realtime контур индексации событий; формализовать буст свежести и закон угасания; и — главное — балансировать свежесть против авторитетности, не скатываясь ни в «вечную классику в топе на новостных запросах», ни в «лента сырых непроверенных заметок вместо ответа».
Как читать по трекамВнимание. Модуль средний по сложности ((средний)), но глава 17.2 (near-realtime контур индексации) — продвинутая ((продвинутый)): там появляются два пути чтения индекса, видимость записей, дообогащение статикой и компромисс «скорость появления ↔ полнота сигналов». Если материал Модуля 4.5 подзабылся — перечитайте его перед 17.2.
- Студент CS — обязательны 17.1 (датировщик и детект потребности запроса как две задачи классификации/оценки) и 17.4 (формализация буста и угасания, баланс свежесть/авторитет как взвешивание факторов). Глава 17.2 — концептуально (два контура, видимость, дообогащение). Глава 17.3 — на уровне идей. Лабы 17.1 и 17.4 сделать руками.
- Инженер поиска/ML — весь модуль обязателен. Особое внимание: инженерные заметки про устойчивость датировщика к манипуляциям (17.1), про два пути чтения и flush/merge в realtime-контуре (17.2), про отдельный индекс событий и его TTL (17.2), про калибровку угасания и порядок стадий буста (17.3, 17.4).
- SEO-специалист — обязательны SEO-врезки во всех главах: какие сигналы даты учитываются и почему «переставить дату» не работает (17.1); почему свежесть помогает не на всех запросах и где она бесполезна или вредна (17.1, 17.3); как угасание свежести превращает «новое» в «старое» и что значит «обновлять контент» осмысленно (17.4). Математику угасания — обзорно.
- Смешанный/руководитель — Обзор, конспект 17.1 и 17.4 целиком, 17.2 и 17.3 по диагонали. Это объясняет, почему новое индексируется не мгновенно, почему «свежее» не всегда значит «лучше» и почему буст свежести — всегда компромисс, а не бесплатное благо.
- 17.1. Датировщик документа и детект потребности запроса в свежести — как оценить возраст документа из ненадёжных сигналов и как понять, нужна ли запросу свежесть вообще. (средний)
- 17.2. Near-realtime контур индексации событий — быстрый путь, делающий новость находимой за секунды-минуты; отдельный индекс событий, видимость, дообогащение. (продвинутый)
- 17.3. Буст свежих документов и отдельные группировки для свежего контента — как поднять свежее в ранжировании и когда выносить его в новостной блок. (средний)
- 17.4. Баланс свежесть ↔ авторитетность; угасание свежести — взвешивание конкурирующих факторов и закон затухания ценности со временем. (средний)
Цели обучения
После главы студент сможет:
- Различать две независимые задачи: оценку возраста документа (датировщик) и оценку потребности запроса в свежести.
- Перечислить источники сигналов о дате документа и оценить их надёжность.
- Спроектировать датировщик, устойчивый к манипуляциям и противоречивым сигналам.
- Построить классификатор потребности запроса в свежести и отличить его от запросов, где свежесть нейтральна или вредна.
- Связать оба сигнала: возраст документа без флага потребности запроса бесполезен, и наоборот.
Свежесть в поиске — это отношение двух величин: насколько документ свежий и насколько запросу свежесть вообще нужна. Эти величины измеряются разными подсистемами и не должны путаться.
Разделим главу на две части: датировщик (свойство документа, считается офлайн как статика) и детектор потребности запроса (свойство запроса, считается на этапе понимания запроса).Интуиция. Дата документа — это свойство товара («когда испекли хлеб»). Потребность запроса в свежести — это свойство спроса («хочу ли я именно свежий хлеб или мне всё равно»). На запрос «теорема Пифагора» свежесть товара не важна — старый «хлеб» (учебник) идеален. На запрос «новости о землетрясении» нужен хлеб из последней партии. Буст свежести включается только тогда, когда спрос на свежесть высок, и применяется к документам с малым возрастом. Перепутать эти две оси — главная ошибка проектирования.
Часть A. Датировщик документа
Задача датировщика. Каждому документу сопоставить две оценки: дату публикации (publish_date) и дату последнего значимого обновления (last_significant_update). Из них рантайм выводит возраст age = now − date — главный вход буста свежести (17.3) и угасания (17.4).
Проблема в том, что надёжной даты у веб-документа обычно нет. Есть набор противоречивых, легко-подделываемых сигналов, из которых датировщик должен извлечь правдоподобную оценку.
Источники сигналов о дате (по убыванию доверия — но всё относительно):
Код: Выделить всё
Сигнал | Где берётся | Надёжность | Проблема
---------------------------------------------+-------------------------------------------+--------------+---------------------------------------------------------------------------
Структурированная разметка даты | микроразметка статьи/новости в HTML | средняя | задаётся автором, легко подделать/завысить
Дата в URL | /2026/06/13/... | средняя | фиксируется при создании, но не отражает обновления
Видимая дата в тексте | «13 июня 2026», «вчера», «2 часа назад» | средняя | относительные даты («вчера») надо разрешать на момент *обхода*
HTTP-заголовки (Last-Modified) | ответ сервера | низкая | часто = текущее время генерации страницы (динамика), а не контента
Дата из карты сайта (sitemap lastmod) | sitemap | низкая | сплошь и рядом проставляется автоматически «сегодня»
Дата первого обхода планировщиком | журнал краулера | высокая | надёжная нижняя граница: «не позже момента, когда мы это впервые увидели»
Контентная подпись (SimHash) между обходами | сравнение версий | высокая | детектирует *реальное* изменение тела, а не косметику
Алгоритм оценки (примирение сигналов). Датировщик не берёт один сигнал, а агрегирует их с приоритетом надёжности и проверками на согласованность:Инженерная заметка. Самые надёжные сигналы — внутренние, наблюдаемые самой системой: дата первого обхода и факт изменения контента между обходами. Их автор не контролирует. Внешние сигналы (разметка, URL, текст) автор контролирует полностью, поэтому датировщик использует их как подсказки, а не как истину, и сверяет с внутренними наблюдениями.
Код: Выделить всё
оценить_дату(doc):
кандидаты = []
если есть first_crawl_date: кандидаты += (first_crawl_date, вес=высокий, тип=upper_bound_публикации)
если есть дата_в_URL: кандидаты += (url_date, вес=средний)
если есть разметка_даты: кандидаты += (markup_date, вес=средний)
если есть видимая_дата_в_тексте: кандидаты += (text_date, вес=средний)
# 1) жёсткая верхняя граница: дата не может быть позже первого обхода
publish_date = медиана/взвешенная_оценка(кандидаты), но не позже first_crawl_date
# 2) фильтр будущего: дата в будущем относительно now → отбросить как шум
если publish_date > now: publish_date = first_crawl_date
# 3) обновление = реальное изменение тела между обходами
если simhash(version_t) сильно != simhash(version_{t-1}):
last_significant_update = время_обхода_t
иначе:
last_significant_update = publish_date # косметика не считается обновлением
return publish_date, last_significant_update
Публикация против обновления. Это разные сигналы, и буст свежести опирается на тот, что уместен классу запроса. «Что нового про X» хочет недавнюю публикацию; «актуальная документация Y» хочет недавнее значимое обновление давно существующей страницы. Поэтому датировщик хранит обе даты, а формула выбирает нужную.Пример. Страница заявляет в разметке 2019-01-01, в URL — /2024/..., а планировщик впервые увидел её 2026-06-10 и зафиксировал реальное изменение тела 2026-06-12. Датировщик: дата публикации — не позже 2026-06-10 (верхняя граница из первого обхода перекрывает противоречивые внешние сигналы), значимое обновление — 2026-06-12. Возраст на запрос от 2026-06-13 — около суток, а не «семь лет», как заявляет разметка.
Заблуждение. «Раз я обновил страницу — она снова свежая.» Только если обновление значимое (изменилось тело, факты, данные), а не косметика (поменяли год в подвале, переставили дату). Датировщик ловит реальное изменение через контентную подпись (SimHash, Модуль 3/16). Косметическое «освежение даты» — это манипуляция, и она нейтрализуется.
Часть B. Детектор потребности запроса в свежести (QDF)SEO-врезка. Что реально влияет на воспринимаемый возраст: дата первого обхода (когда вас впервые увидели) и факт содержательного изменения контента. Что не работает: переставить дату в разметке/подвале, проставить lastmod=сегодня в sitemap без изменения контента, добавить «обновлено» без правок по сути. Осмысленное «обновление» — это дополнить статью новыми фактами/данными так, чтобы изменилось тело; тогда датировщик зафиксирует значимое обновление. Подделка даты — антиспам-сигнал (Модуль 16), а не путь в топ.
Задача. Для запроса q оценить freshness_demand(q) ∈ [0,1] — насколько пользователь хочет именно свежий результат. Этот сигнал — частный, но важнейший выход классификатора интента (Модуль 5), и он включает/выключает буст свежести в формуле (Модуль 12). В литературе подход известен как «запрос требует свежести» (query deserves freshness, QDF).
Откуда берётся потребность в свежести:
- Лексика запроса — явные маркеры: «новости», «сегодня», «сейчас», «последние», «свежий», «обновление», «релиз», «расписание на …», год/дата. Слабый, но дешёвый сигнал.
- Всплеск спроса (spike detection) — резкий рост частоты запроса относительно базовой линии. Если «город X» сегодня запрашивают в 50× чаще обычного — что-то случилось, спрос на свежесть высок. Самый сильный сигнал для внезапных событий.
- Всплеск свежего контента — резкий рост числа новых документов по теме (много новых публикаций за час) коррелирует с событием.
- Поведение на свежем — на этом запросе пользователи кликают преимущественно по недавним документам (клик-сигнал, Модуль 11). Это «обучает» QDF без явных слов в запросе.
- Класс запроса — некоторые классы свежие по своей природе (спорт, котировки, погода, афиша), другие — вечнозелёные (определения, рецепты, справка).
Три зоны потребности в свежести:Интуиция. Самый надёжный детектор события — не слова в запросе, а аномалия частоты. Землетрясение, гол, отставка — никто не пишет в запросе «новость», люди просто резко начинают искать имя/место. Спайк спроса + спайк свежего контента = «происходит сейчас» → потребность в свежести высокая, даже если в запросе ноль временных слов.
Код: Выделить всё
Зона | Пример запроса | freshness_demand | Что делать
------------------------+------------------------------------------------------------+--------------------+------------------------------------------------------------
Высокая | «землетрясение сегодня», «счёт матча», «курс на сегодня» | ≈ 1 | сильный буст свежести, возможен новостной блок
Нейтральная | «отзывы о модели X», «как настроить Y» | ≈ 0.3–0.6 | лёгкое предпочтение свежего при прочих равных
Низкая / отрицательная | «теорема Пифагора», «рецепт борща», «биография автора A» | ≈ 0 | свежесть не важна или вредит — нужна авторитетная классика
Внимание. Бывает отрицательная потребность в свежести: на «как починить кран» или «доказательство теоремы» новый сырой пост хуже выверенного авторитетного руководства. Включить буст свежести здесь — значит поднять шум над сигналом. Поэтому QDF — это не «насколько свежи документы», а «насколько свежесть уместна», и для части запросов уместность нулевая или отрицательная.
Заблуждение. «Свежее всегда лучше, поэтому буст свежести можно включить везде по чуть-чуть.» Нет. На вечнозелёных и навигационных запросах свежесть нейтральна или вредна: вы вытесните проверенную классику недавним шумом. Буст свежести — переключатель под класс запроса (Модуль 12), а не глобальная добавка.
Частые заблужденияSEO-врезка. Свежесть помогает там, где у запроса высокий спрос на свежесть (события, новости, сезонные/трендовые темы, быстро меняющиеся факты). Свежесть не помогает (и обновление «ради даты» бесполезно) на вечнозелёных и навигационных запросах: там выигрывают авторитет, полнота и стабильность. Прежде чем «освежать» страницу, спросите: на каких запросах она ранжируется — свежих или вечнозелёных? Для первых уместно регулярно дополнять её актуальными данными; для вторых ценнее наращивать авторитет и полноту.
Заблуждение. «Дата в разметке/sitemap — это и есть дата документа.» Это лишь один из ненадёжных сигналов, полностью контролируемый автором. Датировщик примиряет его с внутренними наблюдениями (первый обход, реальное изменение тела) и ограничивает верхней границей «не позже, чем мы это впервые увидели».
Лаба / практикаЗаблуждение. «Если в запросе нет слова "новости", свежесть ему не нужна.» Сильнейший признак события — аномальный всплеск частоты запроса, а не временные слова. QDF ловит события по спайку спроса и по клик-поведению, а не только по лексике.
Вход. (1) Таблица из 6 документов с противоречивыми сигналами даты: markup_date, url_date, first_crawl_date, simhash двух последовательных версий. (2) Журнал частоты для 5 запросов за 14 дней (базовая линия + текущий день).
Шаги.
- Реализуйте оценить_дату(doc) по алгоритму из конспекта: примирите сигналы, наложите верхнюю границу по первому обходу, отфильтруйте даты из будущего, определите значимое обновление по различию SimHash.
- Для каждого документа выведите publish_date, last_significant_update, age.
- Реализуйте простой spike-детектор: spike(q) = freq_today / median(freq_baseline); пометьте запросы с spike ≥ 5 как «высокий спрос на свежесть».
- Совместите: для запроса «высокого спроса» и документа возрастом > 30 дней объясните, почему буст свежести его не спасёт.
Критерий «сделано». Верхняя граница по первому обходу применена ко всем; косметическое изменение (близкий SimHash) не засчитано как обновление; spike-детектор отделил событийные запросы от стабильных; письменно сформулировано, почему датировщик и QDF — две ортогональные оси. Время ~50 мин.
Контрольные вопросы
- Почему дата первого обхода надёжнее даты из разметки, хотя обе могут быть неточными?
- Чем отличаются publish_date и last_significant_update и для каких запросов важен каждый?
- Как датировщик отличает значимое обновление от косметического «освежения даты»?
- Приведите запрос с отрицательной потребностью в свежести и объясните, что произойдёт, если включить на нём буст.
- Почему всплеск частоты запроса — более сильный сигнал события, чем наличие слова «новости»?
- Как клик-поведение (Модуль 11) может научить QDF без единого временного слова в запросе?
- Что вернёт датировщик, если все внешние сигналы указывают дату в будущем относительно now?
Цели обучения
После главы студент сможет:
- Объяснить, почему батч-построение индекса не успевает за событиями и зачем нужен отдельный быстрый контур.
- Описать схему совместной работы near-realtime (NRT) контура и батч-контура: два пути чтения, видимость записей, дообогащение статикой.
- Спроектировать отдельный индекс событий с коротким TTL и его связь с основным индексом.
- Оценить компромисс «скорость появления ↔ полнота сигналов/качество ранжирования».
- Связать контур с источниками быстрых данных (потоки публикаций, push-уведомления об обновлении).
Глава развивает Модуль 4.5 (реалтайм-контур vs батч) применительно к событиям. Здесь критична минимизация задержки появления (indexing latency) — времени от публикации документа до момента, когда он находим в выдаче.
Два контура, один ответИнтуиция. Батч-построение индекса — это «переиздание энциклопедии раз в период»: тщательно, со всеми сигналами, но редко. Для новости о событии задержка «до следующего ночного батча» катастрофична: пользователь ищет сейчас, а в индексе ещё ничего нет. Нужен быстрый путь, который делает документ находимым за секунды-минуты ценой временно-неполных сигналов.
Система держит два пути в индекс:
- Батч-контур (медленный, полный). Строит/пересобирает основные сегменты индекса, материализует всю статику: авторитет на свежем ссылочном графе, накопленные поведенческие сигналы, агрегаты качества хоста, полную каноникализацию. Качество сигналов — максимальное, задержка — часы.
- NRT-контур (быстрый, неполный). Принимает поток новых/изменившихся документов и добавляет их в горячий in-memory сегмент почти сразу. Документ становится находимым за секунды-минуты, но с урезанным набором факторов — дорогая статика ещё не посчитана.
Код: Выделить всё
публикация / изменение документа
│
┌─────────────────┴─────────────────┐
▼ ▼
┌────────────────────┐ ┌────────────────────────┐
│ NRT-контур (быстро)│ │ Батч-контур (полно) │
│ горячий in-memory │ │ холодные сегменты, │
│ сегмент, лёгкая │ │ полная статика, │
│ статика, секунды │ │ авторитет/поведение, │
│ │ │ каноникализация, часы │
└─────────┬───────────┘ └───────────┬────────────┘
│ │
│ flush / merge (фоном): │
│ горячий сегмент → холодный, │
│ документ дообогащается полной │
│ статикой при следующем батче/merge │
▼ ▼
┌──────────────────────────────────────────────────┐
│ На запрос читаются ОБА: горячий + холодные, │
│ результаты объединяются в один ответ │
└──────────────────────────────────────────────────┘
Видимость записиИнженерная заметка. Поиск по горячему in-memory сегменту и по сжатым холодным сегментам — два разных пути чтения, которые надо объединить в одном ответе на запрос (Модуль 4.5). Горячий сегмент хранит постинги в быстро-вставляемом, менее сжатом виде; холодные — в плотном сжатии. Цена realtime — поддержка двух представлений и постоянные flush/merge в фоне: горячий сегмент периодически сбрасывается и сливается в холодный, и при этом документ дообогащается полной статикой.
Ключевой вопрос NRT: через сколько после публикации документ виден в выдаче? Это и есть indexing latency, и она складывается из:
Код: Выделить всё
indexing_latency = t_обнаружения # узнать, что документ появился/изменился
+ t_доставки # довести его до индексатора (очередь/поток)
+ t_лёгкой_обработки # токенизация, лёгкая статика, дедуп
+ t_видимости_сегмента # пока запись станет читаемой (commit/refresh горячего сегмента)
Отдельный индекс событийВнимание. NRT ускоряет видимость, но жертвует качеством сигналов. Только что добавленный документ ещё не имеет полной статики: ссылочный авторитет не пересчитан на свежем графе, поведенческих сигналов нет, агрегаты качества грубые. Он находится, но ранжируется по неполному набору факторов, пока следующий батч/merge не дообогатит его. Это прямое следствие шва офлайн/онлайн (Модуль 4.3): realtime материализует то, что считается быстро, а дорогую статику доливает батч.
Часто свежий событийный контент держат в отдельном индексе (event/news index), а не только в горячем сегменте основного:
- Малый и быстрый. В нём только недавние документы → он маленький, целиком в памяти, обходится за миллисекунды.
- Короткий TTL. Документ живёт в индексе событий ограниченное время (часы-дни). Устаревшие записи выпадают (или мигрируют в основной индекс холодными сегментами). TTL прямо связан с угасанием свежести (17.4).
- Отдельная формула. В индексе событий доминирует свежесть; авторитет вторичен (но всё равно нужен — см. 17.4 про защиту от шума).
- Подмешивается федерацией. На запрос с высоким QDF движок федерации (Модуль 14) запрашивает индекс событий как отдельную вертикаль и вставляет результаты в выдачу (новостной блок, 17.3).
Инженерная заметка. Отдельный индекс событий выгоден тем, что развязывает скорость и масштаб: основному индексу (10⁸–10¹¹ документов) дорого делать NRT на каждом документе, а индексу событий (малое число свежих) — дёшево обновляться часто. Запрос с высоким спросом на свежесть бьёт по маленькому быстрому индексу, остальные — по большому основному. TTL не даёт индексу событий распухать.
Заблуждение. «Realtime-индексация значит, что новый документ сразу ранжируется как зрелый.» Нет: он сразу находится, но ранжируется по урезанным сигналам. Полный авторитет/поведение придут с дообогащением (следующий батч/merge). Поэтому свежий документ держится в топе на свежем запросе во многом за счёт буста свежести, а не за счёт зрелых факторов — и когда свежесть угаснет (17.4), он должен «дозреть» по авторитету, иначе просядет.
Частые заблужденияSEO-врезка. Задержка индексации (indexing latency) — это окно, за которое ваш свежий материал станет находимым. Сократить его помогают: машинно-читаемые потоки обновлений (фиды/протоколы оповещения), стабильно частая публикация (источник, который часто и предсказуемо обновляется, обходится чаще), отсутствие технических барьеров обхода. Но помните: попав в индекс быстро, документ первое время ранжируется по неполным сигналам — мгновенного авторитета у новой страницы нет.
Заблуждение. «Если есть NRT-контур, батч-построение не нужно.» Наоборот: они дополняют друг друга. NRT даёт скорость и неполные сигналы; батч даёт полноту и качество. Без батча документы навсегда остались бы с урезанной статикой.
Лаба / практикаЗаблуждение. «Индекс событий — это просто отфильтрованный по дате основной индекс.» Это отдельная структура с коротким TTL, своей (свежестной) формулой и высокой частотой обновления; он подмешивается федерацией, а не заменяет основной поиск.
Вход. Поток из 20 «событий» с временными метками публикации и параметрами контура: t_обнаружения, t_доставки, t_лёгкойобработки, период refresh горячего сегмента tвидимости_сегмента. Плюс TTL индекса событий = 48 ч.
Шаги.
- Для каждого документа посчитайте indexing_latency по формуле из конспекта и постройте распределение (медиана, p95).
- Промоделируйте поведение при двух режимах: только-pull (большое t_обнаружения) и push-поток (малое). Сравните медианную задержку.
- Промоделируйте жизнь документа в индексе событий: добавление → нахождение по урезанным сигналам → дообогащение статикой при merge → выпадение по TTL. Отметьте момент, когда документ должен «дозреть» по авторитету, чтобы не просесть.
- Объясните, что произойдёт с запросом высокого спроса на свежесть, если t_видимости_сегмента = 1 час.
Критерий «сделано». Корректно разложена и посчитана задержка; показано влияние модели обнаружения; нарисован жизненный цикл с моментами дообогащения и выпадения по TTL; письменно сформулирован компромисс «скорость ↔ полнота сигналов». Время ~55 мин.
Контрольные вопросы
- Из каких слагаемых складывается задержка индексации и какое из них сжимает push-модель?
- Почему на запрос читаются оба контура, и в чём сложность объединения горячего и холодных сегментов?
- Какими сигналами обделён только что добавленный через NRT документ и когда он их получит?
- Зачем отдельный индекс событий, если можно просто фильтровать основной по дате?
- Как TTL индекса событий связан с угасанием свежести (17.4)?
- Как спайк спроса (17.1) влияет на частоту переобхода источников?
- Почему «находится быстро» не равно «ранжируется как зрелый документ»?
Цели обучения
После главы студент сможет:
- Формализовать буст свежести как добавочный фактор, активируемый потребностью запроса (freshness_demand).
- Объяснить, почему буст должен зависеть и от возраста документа, и от спроса запроса (мультипликативная связь).
- Спроектировать вынос свежего контента в отдельную группировку (новостной/событийный блок) и решение о его триггере.
- Оценить риск переусиления свежести (шум вытесняет качество) и способы его контроля.
- Связать буст с выбором формулы под класс запроса (Модуль 12) и федерацией вертикалей (Модуль 14).
Буст свежести — это добавочный вклад в скор за малый возраст документа, активируемый потребностью запроса. Ключевое слово — «активируемый»: на запрос без спроса на свежесть буст должен быть нулевым (см. 17.1, отрицательная потребность).
Форма буста
Буст зависит от двух осей одновременно — спроса запроса и возраста документа — и связывает их мультипликативно:
Код: Выделить всё
freshness_boost(q, d) = freshness_demand(q) · decay(age(d))
Код: Выделить всё
score(q,d) = base_relevance(q,d) + w_fresh · freshness_boost(q,d) + ... прочие факторы
Интуиция. Мультипликативность критична. Буст велик только когда обе оси высоки: запрос хочет свежего И документ свежий. Свежий документ на вечнозелёном запросе (freshness_demand≈0) буста не получает. Старый документ на событийном запросе (decay(age)≈0) буста не получает. Это автоматически выключает буст там, где он вреден, без отдельных правил.
Пример. Запрос «землетрясение сегодня», freshness_demand=0.95. Документ A — заметка возрастом 1 час, decay=0.9 → буст 0.95·0.9·w_fresh (большой). Документ B — авторитетная статья «о землетрясениях» возрастом 3 года, decay≈0 → буст ≈ 0, ранжируется по базовой релевантности. На запрос «что такое землетрясение» freshness_demand≈0.1 → буст обнуляется у обоих, выигрывает авторитетная статья B.
Отдельная группировка для свежего контентаИнженерная заметка. Буст применяется на той стадии каскада, где формула уже знает класс запроса, — обычно на L2/реранке (Модуль 12), где доступны и freshness_demand, и материализованный age. Включается он переключением формулы под класс запроса (Модуль 12): флаг freshness_flag/значение freshness_demand из классификатора (Модуль 5) выбирает профиль с ненулевым w_fresh.
Иногда свежесть мало просто «подмешать» в органику — свежий контент выносят в отдельный блок (новостной/событийный): визуально обособленную группу свежих результатов, отсортированных преимущественно по свежести.
Зачем отдельный блок, а не только буст в органике:
- Разный режим сортировки. Внутри блока правит свежесть (новейшее сверху), в органике — релевантность с лёгким бустом. Смешивать две сортировки в одном списке плохо.
- Честный сигнал пользователю. Обособленный блок «свежее по теме» понятен: пользователь видит, что это лента событий, а не вечный ответ.
- Источник — отдельный индекс. Блок наполняется из индекса событий (17.2) через федерацию (Модуль 14) как отдельная вертикаль.
Код: Выделить всё
показать_блок_свежего(q):
return freshness_demand(q) ≥ τ_block # порог триггера блока
И есть_свежие_документы_по_теме(q) # в индексе событий что-то есть
Внимание. Переусиление свежести опасно. Слишком большой w_fresh или слишком пологий decay ⇒ свежий шум (сырые, непроверенные, низкокачественные заметки) вытесняет качественные результаты. Контроль: (1) порог минимального качества/авторитета для попадания в свежий буст (полный мусор не бустится, даже будучи свежим); (2) калибровка w_fresh по метрикам (Модуль 19) отдельно на свежем срезе запросов; (3) триггер блока с порогом τ_block, чтобы блок не вылезал на нейтральных запросах.
Заблуждение. «Чтобы свежее всплывало, надо просто сильно поднять вес свежести.» Слишком сильный буст превращает выдачу на околособытийных запросах в ленту сырого шума. Буст ограничен мультипликативной связью с QDF, порогом качества и калибровкой по метрикам; «просто поднять вес» ломает баланс с авторитетом (17.4).
Частые заблужденияSEO-врезка. Попасть в свежий буст/новостной блок можно только если запрос имеет спрос на свежесть И ваш документ реально свежий И проходит порог качества/авторитета (чистый свежий мусор не бустится). Это объясняет, почему «свежесть ради свежести» на вечнозелёных запросах ничего не даёт: там freshness_demand≈0, мультипликатор обнуляет буст. И почему попадание в новостной блок временно: документ держится там, пока свежесть не угасла (17.4).
Заблуждение. «Буст свежести — это глобальная прибавка ко всем свежим документам.» Он мультипликативно завязан на спрос запроса; на запросах без спроса на свежесть он равен нулю.
Лаба / практикаЗаблуждение. «Новостной блок показывается всегда, когда есть свежие документы.» Нет: триггер блока требует и достаточного freshness_demand, и наличия свежего контента по теме; иначе блок не показывается.
Вход. 8 запросов с известными freshness_demand (от 0 до 0.95) и для каждого — 5 документов с базовой релевантностью, возрастом и оценкой качества. Параметры: w_fresh, decay(age) (возьмите простое экспоненциальное угасание из 17.4), порог качества q_min, порог блока τ_block.
Шаги.
- Посчитайте freshness_boost = freshness_demand · decay(age) и итоговый score для всех пар; отсортируйте.
- Сравните выдачу с бустом и без для запросов трёх зон (высокая/нейтральная/низкая потребность). Покажите, что на низкой буст ничего не меняет.
- Подберите w_fresh так, чтобы на событийном запросе свежая качественная заметка обошла старую авторитетную, но свежий мусор (низкое качество) не обошёл.
- Реализуйте показатьблоксвежего(q) и определите, на каких из 8 запросов блок триггерится.
Критерий «сделано». Мультипликативная связь продемонстрирована (буст=0 при freshness_demand=0 ИЛИ старом документе); найден w_fresh, поднимающий качественное свежее, но не мусор; триггер блока корректен; письменно описан риск переусиления. Время ~50 мин.
Контрольные вопросы
- Почему буст свежести связывает спрос запроса и возраст документа мультипликативно, а не аддитивно?
- Что произойдёт с бустом на вечнозелёном запросе и почему это правильно?
- На какой стадии каскада применяется буст и почему именно там (связь с Модулем 12)?
- Зачем выносить свежее в отдельный блок, а не только подмешивать в органику?
- Какие три механизма удерживают свежий буст от вытеснения качества шумом?
- Чем управляется триггер новостного блока и где он встаёт в выдаче (связь с Модулем 14)?
- Почему попадание документа в новостной блок принципиально временное?
Цели обучения
После главы студент сможет:
- Сформулировать конфликт свежести и авторитетности как взвешивание конкурирующих факторов в одной формуле.
- Записать закон угасания свежести и подобрать его форму/период полураспада под класс контента.
- Объяснить, почему свежесть должна угасать, а авторитетность — нет, и как они «передают эстафету».
- Спроектировать защиту от шума: минимальный порог качества/авторитета даже для самого свежего контента.
- Калибровать баланс по метрикам (Модуль 19) и распознавать перекос в обе стороны.
Свежесть и авторитетность — конкурирующие факторы. Свежий документ молод и потому беден зрелыми сигналами (мало ссылок, нет накопленного поведения — см. 17.2). Авторитетный документ зрел, но может быть устаревшим. Хорошее ранжирование на свежих запросах — это управляемый компромисс между ними, меняющийся со временем.
Угасание свежести (freshness decay)
Ценность свежести затухает со временем: документ возрастом 1 час и возрастом 1 неделя по-разному «свежи» даже на событийном запросе. Эту динамику задаёт функция угасания decay(age) ∈ [0,1], убывающая от 1 (только что) к 0 (давно).
Типовая форма — экспоненциальное угасание:
Код: Выделить всё
decay(age) = exp(−age / τ)
τ зависит от класса контента/запроса:Интуиция. Свежесть — как радиоактивность заметки: интенсивно «фонит» сразу после публикации и затухает по экспоненте. τ — это «насколько быстро тема стынет». У спортивного счёта τ — минуты/часы (через сутки никому не нужно). У обзора технологии τ — недели/месяцы. У энциклопедической статьи угасание неприменимо — там свежесть вообще не фактор (freshness_demand≈0).
Код: Выделить всё
Класс | Характерное τ | Комментарий
------------------------------------+-----------------+--------------------------
Внезапное событие, счёт, котировка | минуты–часы | стынет почти мгновенно
Новость, релиз | часы–дни | актуально несколько дней
Обзор, аналитика тренда | недели–месяцы | медленное угасание
Вечнозелёный контент | — | свежесть не применяется
Свежесть угасает, авторитет — нет: эстафетаИнженерная заметка. τ калибруют по поведению на свежем срезе (Модуль 11/19): как быстро падает доля кликов по документу с ростом его возраста на запросах данного класса. Можно держать несколько τ (по классам контента) и выбирать по классу запроса (Модуль 12). Альтернативы экспоненте — гиперболическое (1/(1+age/τ), более тяжёлый хвост) или ступенчатое угасание; форму выбирают по тому, как реально падает спрос.
Ключевая динамика: на момент публикации документ держится в топе бустом свежести (зрелых сигналов у него ещё нет, 17.2). По мере угасания (decay→0) буст исчезает — и документ должен «дозреть» по авторитету/качеству, иначе провалится. То есть свежесть и авторитет передают эстафету:
Код: Выделить всё
скор свежего документа во времени:
вклад
│ ╲ свежесть (угасает, decay→0)
│ ╲___
│ _____╲________ авторитет (накапливается батчем: ссылки, поведение)
│ ╱ ‾‾‾‾‾‾‾‾‾‾
└────────────────────────────── время
публикация дни/недели
Защита от шума: пол по качествуИнтуиция. Свежесть — это «аванс»: молодой документ получает фору, пока не накопил зрелые сигналы. Если за время угасания свежести он заслужил ссылки и хорошее поведение — он удержится уже на авторитете. Если нет (был чистым хайпом без ценности) — он закономерно проседает, когда аванс свежести кончился. Система не «забывает» свежий документ — она перестаёт его субсидировать.
Свежесть не должна полностью перебивать авторитет, иначе свежий шум вытеснит качество (см. 17.3). Поэтому:
- Минимальный порог качества/авторитета для доступа к бусту: документ ниже порога не бустится, даже будучи самым свежим.
- Ограниченный вес. w_fresh калибруется так, чтобы свежесть могла переставить документы сопоставимого качества, но не вытащить мусор над авторитетной классикой.
- Авторитет как страховка в индексе событий. Даже там, где правит свежесть (17.2), авторитет источника остаётся фактором — он отделяет надёжные свежие источники от свежего шума.
Внимание. Перекос ловится в обе стороны. Слишком сильная свежесть: на околособытийных запросах всплывают сырые, непроверенные, низкокачественные заметки; авторитетные разборы исчезают. Слишком слабая свежесть: на явно событийных запросах в топе старая «классика», пользователь не находит того, что случилось сейчас. Оба перекоса видны на свежем срезе метрик (Модуль 19); калибруют w_fresh, τ и пороги по ним, отдельно от общего среза, иначе свежие запросы «растворятся» в массе вечнозелёных.
Заблуждение. «Свежесть и авторитет — антагонисты, надо выбрать что-то одно.» Нет, они работают по фазам: свежесть даёт фору молодому документу, авторитет принимает эстафету по мере угасания. Конфликт разрешается во времени, а не выбором «или-или».
Частые заблужденияSEO-врезка. Свежесть — временная фора, а не постоянное свойство. Заметка, поднявшаяся на буст свежести, удержит позиции после угасания только если за это время накопит зрелые сигналы (ссылки, хорошее поведение) — то есть окажется реально ценной. Хайп без ценности закономерно проседает, когда «аванс свежести» кончается. Отсюда практический вывод: на свежих темах важна скорость публикации (поймать окно высокого спроса, 17.2), но удержание даёт только содержательное качество. И ещё: на одной странице нельзя быть «вечно свежим» косметическими правками даты — датировщик это не засчитывает (17.1).
Заблуждение. «Если документ свежий, угасание не страшно — он же не постареет мгновенно.» τ зависит от класса: у счёта матча/котировки свежесть стынет за часы. Документ без зрелых сигналов проседает ровно тогда, когда его decay падает, — это надо учитывать в стратегии.
Лаба / практикаЗаблуждение. «Калибровать буст свежести можно по общим метрикам качества.» Свежие запросы — малая доля общего трафика; на общем срезе перекос свежести незаметен. Калибровать w_fresh/τ/пороги надо на свежем срезе запросов отдельно.
Вход. Журнал из 6 свежих документов: для каждого — кривая накопления авторитета по дням (ссылки/поведение, из «батча») и класс контента (свой τ). Запрос событийного класса с freshness_demand=0.9. Параметры: w_fresh, форма decay, порог качества q_min.
Шаги.
- Для каждого документа постройте во времени два вклада в скор: w_fresh·freshness_demand·decay(age) (угасает) и накапливающийся авторитет.
- Найдите для каждого документа момент «передачи эстафеты» — когда авторитет обгоняет угасающую свежесть. Для документа без накопления авторитета покажите проседание.
- Подберите τ под класс так, чтобы счёт-подобный контент угасал за часы, а обзор — за недели.
- Введите q_min и продемонстрируйте, что свежий документ ниже порога не поднимается, как бы он ни был свеж.
- Промоделируйте оба перекоса (слишком большой/малый w_fresh) и опишите, как каждый виден на свежем срезе метрик.
Критерий «сделано». Построены и пересечены две кривые вклада; найден момент эстафеты; продемонстрировано проседание без авторитета; пол качества работает; письменно описаны симптомы обоих перекосов и почему калибровать надо на свежем срезе. Время ~55 мин.
Контрольные вопросы
- Почему свежесть должна угасать, а авторитет — нет? Что было бы при неугасающей свежести?
- Что такое τ и период полураспада свежести, и как они связаны?
- Опишите «эстафету» свежести и авторитета во времени. Что происходит с документом-хайпом без накопления авторитета?
- Зачем нужен минимальный порог качества для доступа к бусту свежести?
- Назовите симптомы перекоса в сторону свежести и в сторону авторитета. Где они видны?
- Почему нельзя калибровать буст свежести по общему срезу метрик?
- Как τ различается для счёта матча и для обзора технологии, и почему?
- Свежесть — это отношение двух осей. Возраст документа (датировщик, статика) и потребность запроса в свежести (QDF, понимание запроса) — ортогональны. Буст включается только когда обе высоки. Перепутать их — главная ошибка.
- Датировщик примиряет ненадёжные сигналы. Внешние сигналы даты (разметка, URL, sitemap) контролируются автором и ненадёжны; внутренние (первый обход, реальное изменение тела по SimHash) — надёжны. Дата ограничена сверху моментом первого обхода; косметика не считается обновлением.
- Потребность в свежести бывает нулевой и отрицательной. Сильнейший детектор события — всплеск частоты запроса, а не временные слова. На вечнозелёных/навигационных запросах свежесть нейтральна или вредна.
- NRT-контур даёт скорость ценой полноты сигналов. Два контура (быстрый неполный + медленный полный) работают вместе: документ находится за секунды-минуты, но ранжируется по урезанным факторам до дообогащения батчем. Отдельный индекс событий с коротким TTL развязывает скорость и масштаб.
- Буст свежести мультипликативен. freshness_demand(q) · decay(age(d)): ноль по любой оси → нулевой буст. Это автоматически выключает свежесть там, где она вредна, без отдельных правил. Свежий контент часто выносят в отдельный блок через федерацию (Модуль 14).
- Свежесть угасает экспоненциально, авторитет накапливается. decay=exp(−age/τ); τ зависит от класса контента (часы для счёта, недели для обзора). Свежесть — временной аванс; по мере угасания эстафету принимает авторитет, и документ без зрелых сигналов закономерно проседает.
- Баланс защищают порогом качества и калибровкой. Свежий мусор не бустится (пол по качеству); w_fresh/τ/пороги калибруют на свежем срезе метрик (Модуль 19), иначе перекос незаметен. Манипуляции датой — антиспам-сигнал (Модуль 16).
- Главное: свежесть — переключаемый под класс запроса, ограниченный во времени фактор, а не глобальное благо; её ценность в уместности и своевременности, а не в новизне самой по себе.
- Датировщик (dater) — подсистема, оценивающая дату публикации и значимого обновления документа из разнородных сигналов.
- Возраст документа (age) — now − date; главный вход буста свежести и функции угасания.
- Дата публикации (publish_date) — оценка момента появления документа; ограничена сверху датой первого обхода.
- Значимое обновление (last_significant_update) — момент реального изменения тела документа (по контентной подписи), в отличие от косметической правки.
- Дата первого обхода (first_crawl_date) — надёжная внутренняя верхняя граница даты публикации: «не позже, чем мы это впервые увидели».
- Потребность запроса в свежести / QDF (query deserves freshness) — оценка freshness_demand(q) ∈ [0,1], насколько запросу уместен свежий результат; выход классификатора (Модуль 5).
- Всплеск спроса (spike) — аномальный рост частоты запроса относительно базовой линии; сильнейший детектор внезапного события.
- Near-realtime индексация (NRT) — быстрый контур, делающий документ находимым за секунды-минуты, ценой временно-неполных сигналов.
- Задержка индексации (indexing latency) — время от публикации документа до момента, когда он находим в выдаче.
- Горячий сегмент — in-memory сегмент индекса для свежих записей, в быстро-вставляемом представлении; периодически сбрасывается и сливается с холодными.
- Дообогащение — добавление полной статики (авторитет, поведение) к свежему документу при следующем батче/merge.
- Индекс событий (event/news index) — отдельный малый индекс свежего контента с коротким TTL, своей свежестной формулой, подмешиваемый федерацией.
- TTL индекса событий — срок жизни записи в индексе событий, по истечении которого она выпадает/мигрирует; связан с угасанием свежести.
- Буст свежести (freshness boost) — добавочный вклад в скор freshness_demand(q)·decay(age(d)), активируемый потребностью запроса.
- Угасание свежести (freshness decay) — убывающая со временем функция decay(age); типично exp(−age/τ).
- τ (характерное время угасания) — период, за который ценность свежести падает в e раз; период полураспада t½ = τ·ln2.
- Новостной/событийный блок — отдельная группировка свежих результатов в выдаче, наполняемая из индекса событий через федерацию.
- Пол по качеству (q_min) — минимальный порог качества/авторитета для доступа документа к бусту свежести; защита от свежего шума.
- Эстафета свежесть→авторитет — фазовая передача: молодой документ держится бустом свежести, по мере угасания удерживается уже накопленным авторитетом (или проседает).
- Свежий срез — выборка запросов с высоким спросом на свежесть, на которой отдельно калибруют буст, иначе перекос растворяется в общем трафике.
- Опирается на Модуль 4 (индексирование), особенно 4.5 — near-realtime контур (17.2) — это прямое продолжение «реалтайм vs батч»: два пути чтения, видимость записей, дообогащение статикой. Возраст/частота обновления материализуются как статика (4.3).
- Опирается на Модуль 5 (понимание запроса) — freshness_demand/freshness_flag (QDF) — выход классификатора интента; он включает буст свежести в формуле.
- Связан с Модулем 16 (антиспам) — манипуляции датой (фейковая разметка, освежение даты без правок) нейтрализуются: датировщик опирается на внутренние наблюдения и контентную подпись (SimHash, общая с Модулем 3/16).
- Питает Модуль 12 (каскад ранжирования) — буст свежести и decay подключаются переключением формулы под класс запроса; применяются на L2/реранке, где известны и freshness_demand, и age.
- Использует Модуль 14 (метапоиск и федерация) — новостной/событийный блок встраивается в выдачу как отдельная вертикаль через слотовую модель и вертикальный триггер.
- Использует Модуль 11 (поведенческие сигналы) и Модуль 19 (метрики/A·B) — клик-поведение обучает QDF и калибрует τ; w_fresh/τ/пороги калибруют на свежем срезе метрик.
- Опирается на Модуль 3 (каноникализация) — контентная подпись (SimHash) для детекта значимого обновления — та же, что и для near-duplicate.
- Работы по оценке даты/возраста веб-документов и устойчивости к манипуляциям временными метками.
- Литература по «query deserves freshness» и распознаванию событийных/трендовых запросов (детект всплесков частоты, time-series аномалии запросного потока).
- Материалы по near-real-time индексации, моделям видимости записей (commit/refresh) и совмещению горячих/холодных сегментов.
- Обзоры по временным/новостным факторам ранжирования и моделям угасания (recency decay, exponential/hyperbolic decay), периоду полураспада ценности.
- Литература по балансу свежести и авторитетности, recency-чувствительным метрикам качества и калибровке на временных срезах.
- Материалы по федеративному/агрегированному поиску в части новостных/событийных вертикалей и их триггеров.
