Главная ошибка в трактовке метаданных утечки web_production (1923 фактора) - читать факторы свежести как универсальный сигнал, который всегда тянет документ вверх за свежую дату. Это не так. Дата и быстрые клики работают не как постоянная добавка к релевантности, а как модификатор расклада под класс запроса. То есть в общей формуле ранжирования есть слой, который переписывает веса групп факторов в зависимости от того, к какому классу отнесён запрос. И один из таких модификаторов - свежестный.
Слой модификаторовСвежесть - это не фактор документа, это режим запроса. Документ не становится релевантнее оттого, что он свежий; он становится релевантнее, когда запрос требует свежести.
В реконструкции по метаданным выделяется группа модификаторов, каждый из которых под свой класс запроса перенастраивает картину. Свежестный - лишь один из них, и удобнее разбирать его в контексте соседей, чтобы видеть логику.
Код: Выделить всё
Mсвеж - для свежих/новостных запросов резко вверх вес Datetime
и быстрых кликов (RapidClicks); работает группа Datetime
Mкоммерц - для коммерческих: включается коммерческая релевантность
(DSSM продуктности [772/777/778], CommercialDssm [812]),
штраф за переизбыток рекламы; TG_COMMERCIAL ~76 факторов
Mгео/перс - LOCALIZED_COUNTRY, регион запроса [245/246],
персональная история (L3/rearrange)
ХолодСтарт- для запросов без кликовой истории
(семейство HasNoQueryShows, факторы 64/78): вес B падает,
модель опирается на T и H - иначе длинный хвост не отранжировать
Что именно усиливает Mсвеж
Две группы факторов получают резко повышенный вес в свежестном классе.
- Datetime - 8 факторов. Это временные характеристики документа: когда он появился, насколько актуальна его дата.
- RapidClicks - 33 фактора. Это быстрые клики, реакция пользователей в короткий промежуток после показа.
Из именованных сигналов в материале фигурируют:
Код: Выделить всё
FreshNewsDetectorPredict - предсказатель "это новостной/свежий сюжет"
AddTime - время добавления документа в индекс
FirstValidTs - первая валидная временная метка документа
Когда дата важна, а когда нет
Ключевой практический вывод из устройства модификатора: датовые факторы и быстрые клики решают только внутри свежестного класса. На запросе, который классификатор не отнёс к свежим/новостным, модификатор Mсвеж не включён, и тогда:
- свежая дата не даёт преимущества - вес Datetime остаётся низким;
- быстрые клики не переписывают выдачу - RapidClicks не в приоритете;
- выдачу определяют другие группы (текстовая релевантность, ссылочная, общая кликовая история, коммерческие/гео-сигналы по соответствующему классу).
Отсюда понятно, почему массовое проставление свежих дат на статичном, не-новостном контенте не работает и в принципе работать не может: для запроса, который не распознан как свежестный, модификатор не активирован, и факторы Datetime не получают того веса, ради которого дату трогали. Более того, рассинхрон между заявленной датой и AddTime/FirstValidTs - это не усиление сигнала, а потенциальный повод для системы не доверять заявленной свежести.Дата и быстрые клики решают исход только в свежестном классе запроса. Вне его обновление даты документа - косметика, не рычаг ранжирования.
Что это значит на практике
- Сначала класс, потом тактика. Прежде чем вкладываться в свежесть, нужно понять, свежестный ли это запрос. Если FreshNewsDetectorPredict-логика не относит сюжет к свежим, оптимизация под Datetime/RapidClicks - мимо.
- Свежесть - это пара "время + реакция". 33 фактора RapidClicks против 8 Datetime говорят, что в новостном режиме критична быстрая кликовая реакция, а не только корректная дата. Свежая дата без трафика и без быстрых кликов недотягивает.
- Достоверность временной метки. AddTime и FirstValidTs отделяют реальную свежесть от декларируемой. Игры с датой в разметке без реального обновления и реального появления в индексе не дают того, что даёт настоящая свежесть сюжета.
- Не-новостной контент. Для статичных тем датовые манипуляции не рычаг. Там работают другие группы факторов, и ресурс лучше тратить на них.
Итог простой и операциональный: свежесть - это режим, а не глобальная добавка. Datetime и RapidClicks переписывают выдачу там и только там, где запрос распознан как свежестный. На всех прочих классах дату документа имеет смысл держать честной и достоверной, но не рассчитывать, что она что-то решит.Числовые соотношения (8 факторов Datetime, 33 RapidClicks, ~76 в TG_COMMERCIAL) и состав групп взяты из метаданных утечки. Любые веса в рассуждении иллюстративны: реальные веса обучаемы и проприетарны, в самих метаданных их нет. Всё вышесказанное - реконструкция логики по структуре и именам факторов, а не выгрузка коэффициентов ранжирования. Имена FreshNewsDetectorPredict, AddTime, FirstValidTs и индексы факторов приведены как они фигурируют в источнике; их точная семантика в продакшене может отличаться от реконструированной.