Что робот НЕ считает: поведение, нейро-рантайм и запросные сигналы

[anna_seo]

Что робот НЕ считает: поведение, нейро-рантайм и запросные сигналы

Совмещение двух утечек - исходников робота (краулинг/индексация, срез примерно 2022) и набора факторов web_production - даёт неожиданно ясную картину. Робот строит индексную правду: ЧТО попадёт в базу, какой URL станет каноном-носителем, с какой статикой, датой, тематикой и в каком тире. Но вес документа в выдаче формируется в основном там, где робота физически нет: в поведении, нейро-рантайме и запросных функциях. Ниже - разбор тех семейств факторов, которые лежат целиком вне каталога robot/, и почему именно они держат основную долю ранжирования.

Тезис: главные рычаги выдачи (поведение, смысл документа под конкретный запрос) формируются НЕ на этапе индексации. Их нельзя подделать правкой в коде страницы - там просто нет точки приложения.

Дисклеймер: робот - срез примерно 2022, факторы - web_production 2026; имена полей, пороги и пайплайны могли смениться. Имена в роботе (proto-поля, THostRank, SeoMark) не равны cpp_name факторов один к одному - соответствие установлено по семантике сигнала. Веса формулы иллюстративны, реальные обучаемы (GBDT плюс NN) и проприетарны.

1. Поведенческие семейства: считаются в логах, а не при обходе

Самая весомая группа вне робота - поведенческая. Это окна агрегации в 90, 365, 730 и 1600 дней, собираемые из истории взаимодействий пользователей с выдачей.

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

TG_USERFEAT                     окна 90 / 365 / 730 / 1600 дней
TG_USERFEAT_CLICK_MACHINE  205
TG_USERFEAT_SEARCH_DWELL_TIME  164

типичные слоты:
  USLongPeriodUrlMobileLongClickProb   вероятность долгого клика
  US...LossesProb                      вероятность потери (отказа)
  USLongPeriodUrlMobileDt180Avg        средний dwell за окно

Источник этих величин - логи поиска (spy_log / watch_log) плюс Метрика и Браузер. Долгие клики (long-click), потери (losses) и dwell-time агрегируются в click machine. Робот к этому вычислению не причастен: он лишь хранит документ-носитель, к канону которого величины потом цепляются.

Важно не спутать перенос с вычислением. samovar получает DirectData (userdata) как ВХОД для планирования обхода - то есть поведение влияет на то, как часто переобходить URL, но это потребление сигнала, а не его производство. Аналогично quality userdata_factors агрегирует поведенческие данные в TJupiterUserDataStatsRow. Это упаковка уже посчитанных в логах чисел в индексную структуру, а не их расчёт.

Поведенческие факторы нельзя накрутить на стороне сайта в принципе - они живут в логах поиска. Их можно только заслужить: документ должен реально удерживать пользователя и не порождать возвраты в выдачу.

2. Нейро-текст: документ робот пакует, близость к запросу считает рантайм

Второй пласт вне робота - нейросетевой матчинг текста под запрос.

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

TG_TEXT_MACHINE  471   TextMachine-фичи
TG_NEURAL        309   нейро-близость query - doc
TG_LINGBOOST     151   LingBoost-расширения

TextMachine, LingBoost и KNN-расширения над парой query - doc считаются на лету в базовом поиске. Робот при индексации производит только документную сторону: эмбеддинги документа (BERT / DSSM / omni / HNSW через bert / rthub / jupiter / library). Это половина скалярного произведения. Вторая половина - вектор запроса и собственно близость - возникает в момент обработки запроса.

Подтверждение от противного есть прямо в коде сборки индекса. smelter resharder.cpp ЯВНО вычищает из шарда документные текстовые артефакты:

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

resharder.cpp удаляет:
  DssmGeneratorDwelltimeBigramsEmbedding
  ExtractedKeywords
  TextErf2Features
  KeyInvz

То есть робот эти структуры производит для индекса, но дальше они либо потребляются другим слоем, либо отбрасываются - рантайм-матчинг query - doc вынесен в отдельный слой и в самом индексе не материализуется как готовая близость. Самый весомый нейро-сигнал, близость query - doc (DssmBertDistillL2, TextMachine, LingBoost), - рантаймовый.

3. Запросные факторы: функция запроса, документа в них нет

Третье семейство - чисто запросное. Эти факторы вообще не имеют документной зависимости на этапе индексации: они функции самого запроса и его покрытия.

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

TG_QUERY_ONLY / TG_DYNAMIC

  LongQuery       [17]   сумма IDF слов запроса
  WordCount       [59]   число слов
  QSegmentsBM25   [351]  BM25 по сегментам
  SyntQuality     [344]  синтаксическое качество

Считаются в рантайме на стадиях L0 / L1 / L2. Робота тут нет совсем - ни как источника, ни как хранилища. LongQuery как сумма IDF и BM25-группы описывают запрос и то, насколько документ его покрывает; покрытие проверяется в момент ранжирования.

4. Рантайм-источники: Метрика, Браузер, Yabar, BigRT, SaaSKV

Отдельный класс - онлайн-сигналы из пользовательских продуктов. YaBar и Browser-сигналы концептуально выглядят хостовыми (привязаны к хосту/URL), но их ЗНАЧЕНИЯ приходят из Бара и Браузера, а не из краулинга.

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

YaBar* / Browser*     значения из Бара / Браузера
RapidClicks           онлайн-кликовый сигнал
dynamic_factors       рантайм-вычисление
SaaSKV-рантайм        отдельный онлайн key-value источник

Робот для них в лучшем случае поставщик каноничного ключа, к которому привязывается хостовая статистика. Само число - не его.

5. Тонкость: робото-зависимые семейства тоже наполовину не из робота

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

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

RegHostStatic / RegDocStatic  содержат поведенческую статику URL/хоста:
  USLongPeriod* окна до 1600 дней
  YaBarHost*
  Browser*Dwell*

Для этих величин робот поставляет лишь каноничный ключ агрегации - правильный URL/хост, к которому подклеить статистику. Сами значения берутся из логов поиска и Бара. Одно семейство оказывается наполовину роботным: каркас от робота, наполнение от поведения.

Что это значит для SEO

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

• Робот покрывает статику почти полностью: Datetime, RegDocStatic, TG_STATIC_REGINFO, TG_WIKIPEDIA имеют чёткие сквозные мосты (датировщик и samovar дают FI_FIRST_VALID_TS / FI_DATER_ADDTIME, гео-фасет даёт FI_PAGE_REGION_*). Здесь правка на стороне сайта работает - дата, регион, тематика реально фиксируются при индексации.
• Но самый недооценённый вклад робота - не факторы, а ВЫБОР индексируемого документа. gemini / mirror / superdups / kwyt / selectionrank не дают ни одного FI_*, зато определяют носителя ВСЕХ факторов. Сломанная каноникализация дробит owner-rollup, host-size, ссылочный вес и поведение. Это нулевой фактор, от которого зависят все прочие.
• Ссылочный граф робот честно строит (samovar / lemur SeoMark, jupiter Link-Ann, анти-SEO-фильтр), но в выдаче он почти мёртв: LinkBM25 - 0 из 9, классические Xref XLR* - 3 из 60, классический PageRank в TG_UNUSED. Покупка ссылок и анкорная накрутка бьют по мёртвым слотам.
• Огромная доля слотов мертва: Domain 0 из 10, TG_CATALOG 0 из 2, TG_DOWNER 2 из 48, Annotation 3 из 133, спам-классификаторы (Spam2 / SpamKarma / NoSpam) - dead. Наличие кода в роботе не равно влиянию: catfilter размечает каталог, whois ловит спам, а соответствующий фактор может быть TG_DEPRECATED.

Вес выдачи держат три семейства, к которым у владельца сайта нет прямого доступа: поведение (long-click, losses, dwell в окнах до 1600 дней), нейро-близость документа к запросу и запросные функции. Всё это вычисляется в логах и рантайме, а не при обходе. Робот лишь решает, какой документ станет каноном-носителем этих сигналов. Поэтому реальные рычаги - удержание пользователя и смысловое соответствие запросу, а не разметка и ссылки. Подделать правкой в коде страницы то, что считается вне индексации, нельзя.

Напоминание про ограничения: связи факторов - это гипотезы со шкалой confidence, high только там, где есть прямые улики в коде. Робот - срез примерно 2022, факторы - 2026; за годы слоты добавлялись и умирали. Соответствие имён установлено по семантике сигнала, не по точному совпадению строк. Веса формулы иллюстративны.