Ссылочный граф и SeoMark: как робот строит граф и режет накрутку

[anna_seo]

Ссылочный граф и SeoMark: как робот строит граф и режет накрутку

Разбор по утечке исходников поиска (срез примерно 2022). Делю систему на две половины: робот - это краулинг и индексация (samovar, lemur, jupiter, library, mercury), а search/ - рантайм формирования выдачи. В этом треде интересует ссылочное семейство: как робот честно строит весь ссылочный граф, что он с ним делает дальше, и почему при этом большая часть классических ссылочных факторов в формуле фактически мертва.

Короткий тезис: граф строится полностью и качественно, но отдача с него низкая. Покупка ссылок бьёт по мёртвым слотам И режется классификатором накрутки SeoMark. Дальше - подробно, по компонентам.

1. samovar: экспорт графа

Первый узел конвейера - samovar. Именно он материализует ссылочный граф из обхода и отдаёт два экспорта:

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

incoming_outgoing_links_export   входящие/исходящие ссылки документа
host_link_graph_export           ссылочный граф на уровне хостов

Ключевая структура - IncomingLinksAggregations. Это агрегаты по входящим ссылкам, и состав полей сам по себе говорит, на что смотрит робот:

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

IncomingLinksAggregations
  Total        всего входящих ссылок
  Hosts        число уникальных хостов-доноров
  Owners       число уникальных owner-ов (склеенных групп хостов)
  Spam%        доля ссылок, помеченных как спамные
  TextLenSum   суммарная длина анкор-текстов

Важно, что Hosts и Owners разведены отдельно. Тысяча ссылок с одного owner и тысяча ссылок с тысячи разных owner-ов - для робота это совершенно разные сущности уже на стадии агрегации, ещё до всякого ML. Spam% тоже считается прямо здесь, то есть доля мусора в ссылочном профиле фиксируется на самом раннем этапе.

2. lemur: preparat входящих ссылок и SeoMark

Дальше эстафету берёт lemur. Компонент preparatprocessor собирает агрегированный preparat входящих ссылок - уже с анкор-текстами, привязанными к каждой ссылке. Это вход для классификатора качества.

Сам классификатор живёт в algo/links/seomark.h. Он двухступенчатый:

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

SeoMark (algo/links/seomark.h)
  MatrixNet              105 фич
  CatBoost cb_venality   424 фич
  выход: GoodLink / SeoMark

MatrixNet на 105 фичах даёт первичную оценку, а CatBoost-модель cb_venality (само имя - venality, продажность) на 424 фичах добивает решение. По результату ссылка помечается как GoodLink либо получает SeoMark - метку накрутки. Это и есть тот самый классификатор качества входящих ссылок, который стоит за слотами FI_LINK_QUALITY_FIXED[405] и FI_NEW_LINK_QUALITY_FIXED[407].

SeoMark не понижает вес плохой ссылки - он её отсекает. Накрученная ссылка не попадает в полезный сигнал. То есть купленная ссылочная масса в значительной части просто не доходит до формулы как положительный фактор.

Здесь же в lemur (host/combine, BanDetector) считаются хост-счётчики и тИЦ-подобные агрегаты Cy/Acy.

3. jupiter: Link-Ann и упаковка в индекс

jupiter (links.cpp) строит ссылочные аннотации - Link-Ann. Технически это lerf2 и структура TDocLinkErfInfoProto. На уровне library тем же занимается TLinksMapper, который раскладывает данные в refkeyinv и reflerf. mercury добавляет CanonizedLinkFactors - 18 бакетов канонизированных ссылочных факторов.

Полный конвейер ссылочного семейства выглядит так:

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

samovar     incoming_outgoing_links_export, host_link_graph
              IncomingLinksAggregations (Total/Hosts/Owners/Spam%/TextLenSum)
   |
lemur       preparatprocessor (preparat + анкоры)
              SeoMark: MatrixNet 105 + CatBoost cb_venality 424 -> GoodLink
   |
jupiter     links.cpp -> lerf2 / TDocLinkErfInfoProto (Link-Ann)
   |
library     TLinksMapper -> refkeyinv / reflerf
   |
mercury     CanonizedLinkFactors (18 бакетов)

Механизм рабочий и сквозной: граф строится, анкоры сохраняются, накрутка фильтруется, всё пакуется в индекс. Уверенность в том, что граф строится - высокая. Вопрос только в том, что из этого реально читает формула.

4. Что мёртвое, а что живое

И вот тут начинается главное. Семейства TG_LINK_GRAPH / LinkBM25 дают 18 из 39 факторов в группе, но из LinkBM25 живы 0 из 9. Картина по конкретным слотам:

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

Фактор                          Слот   Статус
FI_PAGE_RANK                     [0]    классический PR в TG_UNUSED
FI_NUM_LINKS                     [37]   живёт (счётчик)
FI_LINK_QUALITY_FIXED            [405]  живёт (SeoMark)
FI_NEW_LINK_QUALITY_FIXED        [407]  живёт (SeoMark)
FI_LINK_PAIR                     [54]   dead
FI_LINK_BM25_WEIGHTED_1          [395]  dead
LinkBM25 (вся группа)                   0/9 dead

То есть классический PageRank лежит в TG_UNUSED - он считается носителем, но в формулу не входит. Вся группа LinkBM25 (взвешенный по анкорам ссылочный BM25) мертва целиком. Живут лишь несколько link-quality-классификаторов поверх SeoMark и простой счётчик ссылок.

Аннотационный слой (Annotation / Xref). Здесь похожая картина: 3 из 133 и 3 из 60 живых. jupiter материализует анкорные и query-to-url аннотации в ann-keyinv через TIndexAnnAggregation, lemur даёт preparat-анкоры, library - annotations/linkannwad, mercury - FastAnnotation, melter - ann/linkann lumps. Но что из этого работает:

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

FI_NHOP_TEXT_BCLM_WEIGHTED   [666]  живёт  хопо-текстовый BCLM
FI_NHOP_TEXT_BCLM_PLANE      [795]  живёт  хопо-текстовый BCLM
FI_QU_BM15_WEIGHTED          [761]  живёт  query-to-url
FI_HAS_ALL_WORDS_IN_LINK     [82]   dead
FI_LR_RELEV                  [88]   dead
XLR* (классические Xref Гулина)     dead

Живёт аннотационно-браузерный слой: хопы (FI_NHOP_TEXT_BCLM_*) и запросы-к-URL. FI_QU_BM15_WEIGHTED[761] описан как индекс документ-в-запросы, по которым на него переходили - то есть это не про ссылку как таковую, а про то, по каким запросам пользователи на URL переходили. А классические Xref-релевантности Гулина (всё семейство XLR*) мертвы.

Сухой остаток по графу: робот строит весь ссылочный граф с анкорами и SeoMark-фильтром. Но LinkBM25 полностью мёртв (0/9), классический PageRank в TG_UNUSED, Xref XLR мёртв. Живёт только аннотационно-браузерный слой - хопы и запросы-к-URL.

5. Зачем тогда вообще строить граф

Резонный вопрос: если так много мёртвого, зачем робот честно гоняет весь конвейер. Несколько причин.

• GoodLink/SeoMark - это в первую очередь защитный механизм. Чтобы отсечь накрутку, граф всё равно нужно построить целиком, иначе нечего классифицировать.
• Spam% и owner-агрегаты с раннего этапа samovar питают хост- и owner-статику, а не только ссылочные слоты.
• Аннотационный слой (хопы, query-to-url) - живой и опирается ровно на ту же ссылочную инфраструктуру.
• Канонизация (gemini/mirror/superdups) склеивает ссылки и анкоры на один канон, иначе они размазались бы по дублям. Без owner-rollup и склейки зеркал даже живые сигналы дробились бы по http/https/www.

6. Выводы для SEO

Покупка ссылок попадает в двойную ловушку. Во-первых, бьёт по мёртвым слотам - LinkBM25 0/9, классический PageRank в TG_UNUSED, XLR мёртв, то есть прямого ссылочного веса в формуле почти нет. Во-вторых, режется SeoMark (MatrixNet 105 + CatBoost cb_venality 424), который не понижает, а отсекает накрученные ссылки ещё на индексации. Это бьёт дважды.

Что из этого следует практически:

• Разнообразие доноров по Owners важнее объёма по Total - робот их разводит на уровне агрегации samovar.
• Высокий Spam% в профиле фиксируется рано и портит ссылочную метку через SeoMark.
• Реально полезен живой слой - переходы (query-to-url, FI_QU_BM15_WEIGHTED) и хопо-текстовые аннотации (FI_NHOP_TEXT_BCLM_*). Это ближе к трафику и поведению, чем к голой ссылочной массе.

И отдельная ремарка: всё выше - про индексацию, про то, как робот строит и фильтрует граф. В рантайме формирования выдачи (search/) есть ещё и явный сброс ссылок - механика на стороне рантайма, которая обнуляет ссылочный вклад для части документов. Это отдельный сюжет, разберу его в другом треде.

Дисклеймер: срез примерно 2022, имена компонентов, факторов и пороги могли смениться. Конкретные веса иллюстративны - реальные обучаемы и проприетарны. Статусы live/dead - по состоянию слотов в формуле на момент среза.