Совмещение двух утечек Яндекса (исходники робота, срез примерно 2022, и описания факторов web_production) даёт редкую возможность проследить сквозной путь сигнала: от индексной подсистемы до слота в формуле. И первое, что бросается в глаза при таком сопоставлении - есть целый слой робота, который не порождает ни одного FI_*, но без которого все остальные факторы теряют смысл. Это слой выбора индексируемого документа: gemini, mirror, superdups, kwyt и поверх них selectionrank. Я называю его нулевым фактором - он сам по себе ничего не весит в выдаче, но определяет НОСИТЕЛЯ, на который ложатся все веса.
Что такое носитель и почему он первичен
Любой фактор - дата, размер хоста, ссылочный вес, накопленное поведение - привязан к какому-то документу. Но у одной и той же сущности в вебе обычно много URL: http и https, с www и без, с трекинг-параметрами и без них, дубли по контенту на разных адресах, исторические версии. Если не схлопнуть это в один канонический URL до того, как начнётся агрегация, каждый сигнал размажется по дублям. Owner-rollup посчитается по нескольким владельцам, host-size раздробится на http/https/www, ссылочные веса разойдутся по адресам, поведение пользователей не сольётся в одну точку. Поэтому каноникализация логически предшествует всему остальному - это не один из факторов, это условие, при котором факторы вообще осмысленны.
Четыре подсистемы выбора документаНулевой фактор: каноникализация не даёт ни одного слота в формуле, но определяет, на каком URL сконцентрируются все остальные сигналы. Без неё owner-rollup, host-size, link-веса и поведение дробятся по дублям.
Каждая решает свой срез задачи склейки.
Код: Выделить всё
Компонент Что выбирает Тип решения / критерий
--------- --------------------------- ------------------------------------
gemini канонический URL CanonizedUrl / MainUrl / Owner
владелец (owner) типы: MIRROR / CANONIZE / OWNER /
CASE_HOST
mirror главное зеркало хоста composite rating: Shows, Clicks,
(host -> main) IKS, CY
superdups супердубль -> main карта по simhash (near-duplicate)
kwyt актуальную версию выбор IsLast-версии документа
mirror решает задачу главного зеркала на уровне хоста (host -> main). Когда один сайт доступен по нескольким хостам (классика - www и без www, http и https как разные хосты), нужно выбрать один. Критерий - композитный рейтинг на показах, кликах, ИКС и CY-подобных метриках. Если этого не сделать, host-size, о котором ниже, посчитается отдельно для каждого варианта написания хоста и каждый получит лишь долю реального размера.
superdups закрывает контентные дубли, которые не сводятся к одному хосту: одинаковый или почти одинаковый контент на разных адресах. Карта супердубль -> main строится по simhash - локально-чувствительному хешу, который сближает near-duplicate документы. Это ловит то, что не ловит mirror: одинаковые тексты на разных сайтах и адресах.
kwyt выбирает IsLast - актуальную версию документа среди исторических. Это снимает проблему, когда у одного URL накопилось несколько проиндексированных состояний.
Куда переносятся факторы: canonized_factors
Физический перенос факторов на канон делает jupiter. Компонент canonized_factors / TCanonizedFactors переносит вычисленные факторы на выбранный канонический документ. То есть pipeline не просто помечает дубли - он перекладывает накопленную статику и сигналы на носителя, чтобы дальше всё ранжирование работало с одним URL.
Код: Выделить всё
gemini (CanonizedUrl/MainUrl/Owner)
|
v
mirror (host -> main по composite rating)
|
v
superdups (simhash: dup -> main)
|
v
kwyt (IsLast версия)
|
v
jupiter canonized_factors / TCanonizedFactors
(перенос FI_* на канон-носитель)
Стоит посмотреть на конкретные факторы, которые без канонизации деградируют.
Хостовая статика. FI_HOST_SIZE[113], исторически имени Расковалова, - размер хоста в документах без дублей. Само определение требует и склейки зеркал, и owner-rollup: jupiter host/flows.cpp регистрирует THostRank, TOwnerReqsPopularity, TRegRegionalHostRank и мапит TExternalHostdat в THostErfInfoProto, дальше erf_herf_features; lemur host/combine считает host-counters и тИЦ-подобные Cy/Acy. Без mirror размер хоста делится между http/https/www, без owner-rollup не складывается по владельцу. Тонкость: соседние живые FI_YABAR_HOST_*[249-255] и FI_BROWSER_HOST_CNT_DWELL_TIME_LOG[847] - это поведение хоста из Бара и Браузера; робот лишь привязывает их к каноничному хосту, а значения приходят из логов Yabar. То есть канонизация даёт ключ агрегации, поведение вливается в него извне.
Ссылочный граф. samovar экспортирует incoming_outgoing_links_export и host_link_graph_export с IncomingLinksAggregations (Total, Hosts, Owners, Spam%, TextLenSum). Агрегации по Hosts и Owners напрямую зависят от того, что хосты и владельцы уже схлопнуты. lemur preparatprocessor строит preparat входящих ссылок с анкорами; algo/links/seomark.h гоняет MatrixNet (105 фич) и CatBoost cb_venality (424 фичи), помечает GoodLink / SeoMark и отсекает накрутку - это и есть классификатор за FI_LINK_QUALITY_FIXED[405] и FI_NEW_LINK_QUALITY_FIXED[407]. jupiter links.cpp строит Link-Ann (lerf2, TDocLinkErfInfoProto). Если ссылки указывают на дубли, а не на канон, веса размажутся по адресам ещё до агрегации.
Даты. Даже самый чистый мост - Datetime, живой на 8/8 - привязан к канону. FI_FIRST_VALID_TS_10DAYS[442] описан как возраст относительно времени валидности документа в самоваре (поле ValidState.FirstValiditySource из samovar). FI_DATER_ADDTIME_80HOURS[1861] и _10DAYS[1862] используют RobotAddTime (samovar TRobotDate{DateTimestamp,Score} плюс quality/html_dater, MatrixNet примерно 150 фич). FI_PAGE_DATE[345] извлекает rthub DateExtractor. Упаковка - стадия dater_remap в library/selectionrank, дальше FinalErf. Если бы дубли не были склеены, у одной сущности оказалось бы несколько конфликтующих дат добавления.
Связь с отбором в индекс
Поверх выбора документа стоит selectionrank - тоже не выдачный фактор, но критичная развилка. MatrixNet-формулой над TFactorStorage (PrepareWebFactors: DocErf, DocLinkErf, PageRank, MaxFreq, USLP-статика) он решает попадание документа в тир (Platinum / WebTier0 против RobotTier). Сам факт тира - сильный статический сигнал качества, и он же определяет, для каких документов вообще существуют индексные use_artifact-факторы. Логическая цепочка такая: сначала выбирается канон-носитель, затем на него переносятся факторы, затем selectionrank по этим факторам решает, в каком тире документ окажется. Канонизация стоит в самом начале этой цепочки.
SEO-вывод
Практический смысл: борьба за дубли - это не гигиена ради гигиены, а концентрация сигнала. Каждый лишний индексируемый вариант одной страницы - это потенциальная утечка веса до точки агрегации. Робот в итоге выберет один носитель сам, но если выбор неоднозначен, часть истории сигнала может осесть не на том URL.Чистая каноникализация концентрирует все сигналы на одном URL. Технические дубли (http/https, www, параметры, пагинация, печатные версии) распыляют owner-rollup, host-size, ссылочные веса и накопленное поведение по адресам, которые поисковик всё равно схлопнет - но уже после того, как часть сигнала размылась. Задача оптимизатора - сделать выбор канона за gemini/mirror предсказуемым: один протокол, одно написание хоста, нормализованные параметры, явные канонические указания, отсутствие near-duplicate страниц, которые superdups вынужден разводить по simhash.
Дисклеймер
Срез робота - примерно 2022 год, факторы - web_production более поздний. За годы слоты добавлялись и умирали, имена полей (THostRank, SeoMark, поля proto) и пайплайны могли смениться; соответствие имён робота и cpp_name факторов установлено по семантике сигнала (ERF-поля, owner-граф, датировщик), а не по точному совпадению 1:1. Указанные веса и пороги иллюстративны - реальные обучаемы (GBDT плюс NN) и проприетарны. Связи между компонентами и факторами здесь - обоснованные гипотезы с разной степенью уверенности, high лишь там, где есть прямые улики в коде и описаниях.