Модификаторы формулы: как класс запроса переписывает расклад факторов

Рейтинг: 0% · 0 голосов
Разбор устройства поиска и факторов ранжирования: реконструкция формулы, поведенческие, текстовые, ссылочные и хостовые факторы, антиспам, что живо и что давно мёртво. Аналитика на основе метаданных факторов web_production.
Ответить
Аватара пользователя
anna_seo
Сообщения: 58
Зарегистрирован: 11 май 2026, 05:31

Модификаторы формулы: как класс запроса переписывает расклад факторов

Сообщение anna_seo »

Зачем формуле модификаторы

Когда говорят про "формулу ранжирования", обычно подразумевают один статичный набор весов: текстовая релевантность весит столько, кликовая - столько, ссылочная - столько. Метаданные утечки web_production (1923 фактора) показывают другую картину. Поверх базовой модели сидит слой модификаторов, который переписывает расклад весов под класс запроса. Один и тот же фактор для свежего новостного запроса и для коммерческого запроса входит в итоговую оценку с разным весом - а иногда для одного класса включается, а для другого фактически зануляется.

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

В выжимке выделяются четыре механизма, каждый из которых привязан к своему детектируемому классу запроса.

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

МОДИФИКАТОР   КЛАСС ЗАПРОСА          ЧТО ДЕЛАЕТ С РАСКЛАДОМ
-----------   --------------------   ----------------------------------------
Mсвеж         свежие / новостные     резко вверх вес Datetime и RapidClicks
Mкоммерц      коммерческие           включает коммерч. релевантность,
                                      штраф за переизбыток рекламы
Mгео/перс     гео- и персональные    регион запроса + личная история (L3)
ХолодСтарт    без кликовой истории    вес B падает, опора на T и H
Дальше - по каждому.

Mсвеж - для свежих и новостных запросов

Если запрос детектируется как свежий или новостной, резко растёт вес группы Datetime и сигналов быстрых кликов (RapidClicks). Логика прозрачна: для запроса "что случилось" документ недельной давности почти бесполезен, даже если он идеально релевантен по тексту. Поэтому возраст документа из второстепенного фактора превращается в один из решающих, а быстрая кликовая реакция (RapidClicks) работает как сигнал того, что свежий документ действительно отвечает на актуальный интент.

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

Mсвеж (иллюстративно):
  w[Datetime-группа] : low  -> high
  w[RapidClicks]     : low  -> high
  смысл: свежесть вытесняет накопленную релевантность
Mкоммерц - для коммерческих запросов

На коммерческом классе включается отдельная коммерческая релевантность, которой на информационных запросах фактически нет в раскладе. Сюда входят факторы продуктности на базе DSSM [772/777/778] и CommercialDssm [812]. Это нейросетевые сигналы, оценивающие, насколько документ - реальная товарная или продуктовая страница, а не просто текст, где упомянут товар.

Параллельно включается штраф за переизбыток рекламы: на коммерческом запросе пользователю нужен товар и возможность его получить, а не страница, забитая рекламными блоками. Объём коммерческой группы значителен - на неё в выжимке указывается тег TG_COMMERCIAL порядка 76 факторов.

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

Mкоммерц (иллюстративно):
  включается:
    DSSM продуктности   [772] [777] [778]
    CommercialDssm      [812]
  штраф:
    переизбыток рекламы на странице
  объём группы:
    TG_COMMERCIAL ~ 76 факторов
Практический вывод: одна и та же страница на информационном запросе и на коммерческом оценивается фактически разными подмоделями. На коммерческом классе текстовой релевантности недостаточно - нужны сигналы продуктности, которые DSSM-факторы и считывают.

Mгео/перс - геозависимость и персонализация

Для гео- и персонально окрашенных запросов в расклад входят LOCALIZED_COUNTRY, регион запроса [245/246] и персональная история пользователя. Персонализация в выжимке привязана к уровню L3 (rearrange) - то есть к поздней стадии, где базовый список уже построен и переупорядочивается под конкретного пользователя и его регион.

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

Mгео/перс (иллюстративно):
  LOCALIZED_COUNTRY
  регион запроса      [245] [246]
  персональная история (применяется на L3 / rearrange)
Важно, что персонализация и гео работают не на этапе грубого отбора, а на переупорядочивании. Это объясняет, почему один и тот же запрос даёт разную выдачу в разных регионах и у разных пользователей при идентичной базовой релевантности документов.

ХолодСтарт - и почему он ломает привычную SEO-логику

Самый интересный модификатор - для запросов без кликовой истории. Он срабатывает по семейству факторов HasNoQueryShows (в выжимке указаны индексы 64/78). Это запросы длинного хвоста: их так мало задавали, что у модели нет накопленной кликовой статистики по парам запрос-документ.

В классической модели большой вес несёт поведенческая, кликовая компонента (обозначим её B). Но на холодном старте этой компоненты просто нет - кликать было некому. Если оставить вес B высоким, модель будет опираться на пустоту и не сможет осмысленно отранжировать хвост. Поэтому ХолодСтарт роняет вес B и переносит опору на текстовую релевантность (T) и хостовые/host-сигналы (H).

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

ХолодСтарт срабатывает по:
  HasNoQueryShows-семейство   [64] [78]

Сдвиг весов (иллюстративно):
  w[B] поведенческая  : high -> low (почти ноль)
  w[T] текстовая      :  ->  опорная
  w[H] хостовая       :  ->  опорная

смысл: нет кликов -> опираемся на текст и качество хоста,
       иначе длинный хвост вообще не отранжировать
На холодном старте поведенческая компонента не работает не потому, что она плохая, а потому, что данных нет. Модель сознательно её занижает и опирается на то, что можно посчитать без кликовой истории - текст и хост.
Что это значит для оптимизации

Главный практический вывод из слоя модификаторов: оптимизировать "вообще" бессмысленно, потому что не существует единого универсального расклада весов, под который можно подстроиться. Каждый класс запроса включает свою конфигурацию.
  • Свежий/новостной интент (Mсвеж): без свежести документа и быстрой кликовой реакции текстовая вылизанность не спасёт - вес Datetime и RapidClicks перевешивает.
  • Коммерческий интент (Mкоммерц): нужны сигналы продуктности (DSSM [772/777/778], CommercialDssm [812]) и контроль рекламной нагрузки; информационная статья на коммерческом запросе проигрывает структурно.
  • Гео/персональный интent (Mгео/перс): борьба идёт на уровне L3-переупорядочивания, важны регион [245/246] и LOCALIZED_COUNTRY, а не только базовая релевантность.
  • Длинный хвост без истории (ХолодСтарт): поведенческие накрутки бесполезны - вес B занижен. Работают текст (T) и качество хоста (H).
То есть первый шаг любой работы - определить класс запроса и, соответственно, какой модификатор будет применён и какая группа факторов станет решающей. Оптимизация под класс, а не под абстрактную "формулу" - это и есть содержательный смысл слоя модификаторов.
Ещё раз: численные веса в примерах условны. Из метаданных утечки видны имена и группировки факторов и логика их переключения по классу запроса, но не сами обучаемые коэффициенты. Всё вышеизложенное - реконструкция структуры формулы, а не её точная выгрузка.
👍 ❤️ 🔥 😄 🤔
Ответить
Поделиться темой: ✈ Telegram VK

Вернуться в «SEO и факторы ранжирования»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя