Нейро-эмбеддинги при индексации: документная сторона нейропоиска

[anna_seo]

Нейро-эмбеддинги при индексации: документная сторона нейропоиска

Когда говорят про нейропоиск, обычно фокусируются на запросе: модель превращает текст запроса в вектор, дальше считается близость к документам, выдача переранжируется. Но половина этой математики живёт не в рантайме, а в роботе - на стадии индексации. По срезу исходников (~2022) видно, что документный эмбеддинг считается заранее, складывается в индекс и ждёт запроса. Это и есть документная сторона нейро. Разберём, какие компоненты её строят и что из этого следует для SEO.

Зачем половину считают заранее

Близость запроса к документу в простейшем виде - это скалярное произведение двух векторов. Один вектор (запросный) можно посчитать только в рантайме, когда пришёл запрос. Второй (документный) от запроса не зависит вообще - значит, его выгодно посчитать один раз при индексации и положить рядом с документом. Робот готовит именно эту половину. Рантайму базового поиска остаётся достать заранее посчитанный документный вектор, посчитать запросный и свести их в фактор близости.

Робот готовит половину скалярного произведения. Качество документного эмбеддинга - это то, что закладывается на стадии индексации и потом не пересчитывается на каждый запрос.

berthub: BERT по зонам документа

Стартовая точка - GPU-демон berthub. При индексации он гоняет BERT не по сплошному тексту страницы, а по зонам документа по отдельности. Зоны конкретные:

• title
• meta / ultimate description
• URL-токены
• main-content (основное содержательное тело страницы)

Результат упаковывается по цепочке типов и доезжает до Jupiter-индекса:

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

berthub (GPU inference)
  TExportableDocResult
    TBertData
      Jupiter TBert

Здесь важна именно зональность. Модель отдельно смотрит, что в title, что в описании, что в URL, что в основном контенте. Документный эмбеддинг получается не из усреднённой каши со страницы, а из осмысленного содержимого ключевых зон. Это прямой мост к SEO-выводу в конце.

rthub: офлайновый DSSM

Параллельно с BERT работает DSSM-ветка. rthub при индексации инференсит DSSM-эмбеддинги офлайн, метод в исходниках называется прямо:

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

rthub Prewalrus::DssmOptimizedRthubModelExtractEmbedding

То есть DSSM-вектор документа - тоже заранее посчитанная статика, а не рантайм-операция. DSSM исторически старше BERT-ветки и легче по вычислениям, поэтому им же считаются и тематические/качественные скоры (об этом ниже), но базовая роль здесь та же: дать документный вектор для последующей близости к запросу.

library docomni: omni-индекс и HNSW

Дальше эмбеддинги надо где-то хранить и уметь по ним быстро искать. Этим занимается docomni в library. Он пакует набор документных нейро-артефактов в omni-индекс:

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

library docomni упаковывает в omni-индекс:
  DssmEmbedding
  MainContentKeywords
  BertDistillL2
  NavigationL2
  + строит HNSW (KNN-граф)

HNSW (Hierarchical Navigable Small World) - это структура для приближённого поиска ближайших соседей. Граф KNN строится по документным векторам один раз при индексации. Без него близость "запрос-документ" пришлось бы считать линейным перебором по всей базе; с ним рантайм за логарифм находит кандидатов, ближайших к запросному вектору. То есть docomni не только хранит документную половину, но и заранее раскладывает её в структуру, по которой запрос сможет быстро прыгать.

mercury: BERT прямо в ERF

Часть нейро-предиктов кладётся не в omni, а прямо в ERF - в тот же компактный статический блоб документа, откуда рантайм читает обычные скалярные факторы:

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

mercury bert_filler.cpp UpdateErfWithBertPredicts

ERF (документный feature-record) читается рантаймом как статика, поэтому BERT-предикты, записанные туда mercury, доступны без отдельного похода в нейро-индекс. Это удобно для предиктов, которые ведут себя как обычные числовые факторы (тематические/качественные скоры), а не как полноразмерные векторы для KNN.

Что в итоге производит робот (сводка по компонентам)

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

Семейство DSSM-артефактов при индексации (use_artifact, TG_NEURAL)
Артефакты : DssmMainContentKeywords, DssmHostsPopularity,
            BertDistillL2, NavigationL2, омни-эмбеддинги
Производители (robot/):
  bert    : berthub  - GPU-инференс BERT по зонам
  rthub   : DssmOptimizedRthubModel - офлайн DSSM
  jupiter,
  library : docomni, HNSW (KNN-граф)
  mercury,
  melter  : omni-lumps
  quality : smelter - соц-BERT
Роль    : робот инференсит документные эмбеддинги при
          индексации и кладёт в omni/ERF - документная сторона
Близость к запросу считается в рантайме
Уверенность: medium

Где живёт запросная половина

Документный вектор сам по себе - не выдачный фактор. Он становится фактором, только когда в рантайме базового поиска посчитается близость к запросу. Соответствующие слоты:

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

FI_RELEV_SENTS_DSSM   [29]   - близость DSSM
FI_DSSM_BERT_DISTILL_L2 [579] - близость по BERT-distill L2

Оба - рантаймовые. Робот для них приготовил BertDistillL2 / DssmEmbedding со своей стороны (через docomni и mercury), запрос приходит со своей, скалярное произведение замыкается на лету. Отсюда и тег TG_NEURAL у документных артефактов, и пометка use_artifact: фактор существует не как готовое число в ERF, а как инструкция "достань заранее посчитанный артефакт и сведи с запросом".

Соседняя тематическая ветка на тех же моделях

Тот же rthub при индексации считает не только базовый эмбеддинг, но и тематические/качественные DSSM-скоры и коммерческие сигналы - они тоже пишутся в ERF как документная статика:

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

rthub при индексации:
  тематические/качественные DSSM:
    med / sos / finlaw / cruelty
    DssmPageQualityRTHub
    NavParasites
  коммерческие сигналы:
    IsComm / IsShop / *ProductProbability
    EcomFeatures
За что отвечает:
  FI_IS_ESHOP    [136]
  FI_ESHOP_VALUE [203]

Это уже не про близость к запросу, а про предикты-числа (качество страницы, коммерческость, шоп-вероятность), но механика та же: модель отрабатывает на стадии индексации, результат материализуется в ERF. Сюда же примыкает quality smelter (соц-BERT) и mobile-friendly блоб от watto. Все они - документные предикты, посчитанные заранее.

Носитель эмбеддинга: на каком URL он окажется

Отдельно стоит держать в голове, что эмбеддинг считается не на абстрактной странице, а на конкретном каноне. Слой выбора индексируемого документа (gemini - canonical/owner/main, mirror - главное зеркало, superdups - внутрихостовые дубли, kwyt - IsLast-версия) определяет, какой URL получит индексную запись и понесёт на себе все артефакты, включая нейро. Если канонизация размазала контент по дублям, то и BERT-зоны, и DSSM-вектор посчитаются на не том носителе. Это не FI_*-фактор, но он определяет носителя всех остальных, нейро в том числе.

SEO-вывод

Документный эмбеддинг строится из содержимого ключевых зон - title, meta/description, URL-токенов и main-content. berthub смотрит на эти зоны раздельно, docomni кладёт получившиеся векторы в omni и в HNSW-граф, mercury дублирует часть предиктов в ERF. Запрос замкнётся на это в рантайме через FI_RELEV_SENTS_DSSM[29] и FI_DSSM_BERT_DISTILL_L2[579].

Качественный, осмысленный контент в ключевых зонах документа даёт хороший документный эмбеддинг. Робот считает свою половину скалярного произведения именно по тому, что написано в title, description, URL и main-content - и считает заранее, на стадии индексации. Накрутить это запросной стороной нельзя: документная половина зафиксирована в индексе до того, как пришёл запрос.

Практически это означает, что для нейро-факторов работает не плотность ключей и не объём текста, а семантика зон. Title и description должны нести смысл страницы, URL - быть осмысленным и токенизируемым, main-content - содержательным телом, а не обвязкой. Эмбеддинг, построенный по такому документу, окажется ближе к релевантным запросным векторам в HNSW-графе - и это близость, которую робот подготовил один раз и навсегда (до следующей переиндексации).

Дисклеймер

Срез исходников примерно 2022 года. Имена компонентов (berthub, rthub, docomni, mercury), артефактов (BertDistillL2, NavigationL2, DssmEmbedding) и номера слотов могли смениться. Конкретные модели, пороги и архитектура векторов - обучаемые и проприетарные; здесь разобрана только наблюдаемая в исходниках механика конвейера документной стороны нейропоиска, без претензии на актуальные веса.