Как Яндекс использует совокупный вес ресурса (Cumulative Resource Weight) для показа обогащенных ответов (Rich Suggest) в поисковых подсказках

Описание

Какую задачу решает

Патент решает задачу повышения точности и релевантности обогащенных ответов (Rich Suggest или Display Data), показываемых на этапе ввода пользователем части запроса (префикса). Основная проблема — определить, какой ресурс является доминирующим интентом пользователя, когда префикс порождает несколько разных подсказок, потенциально ведущих на разные сайты. Изобретение направлено на то, чтобы избежать показа нерелевантного обогащенного ответа, учитывая совокупность всех вероятных продолжений запроса, а не только самого популярного.

Что запатентовано

Запатентован метод выбора контента для обогащенных поисковых подсказок. Суть изобретения заключается в расчете и использовании метрики Cumulative Resource Weight (Совокупный Вес Ресурса). Этот вес агрегирует силу связи (вероятность перехода) между конкретным ресурсом и всеми релевантными подсказками для данного префикса. Решение о показе обогащенного ответа принимается на основе сравнения этих совокупных весов при выполнении строгих условий.

Как это работает

Когда пользователь вводит префикс, Suggest Engine генерирует список ранжированных подсказок. Система анализирует исторические данные о переходах, чтобы определить, с какими ресурсами связана каждая подсказка и каков вес этой связи (Parameter). Затем для каждого ресурса рассчитывается Cumulative Resource Weight путем суммирования весов всех связанных с ним подсказок. Обогащенный ответ для ресурса показывается только при выполнении двух условий: (1) этот ресурс связан с самой популярной подсказкой (Top Ranked Suggested Search Query), И (2) его совокупный вес не меньше, чем у любого другого ресурса.

Актуальность для SEO

Высокая. Обогащенные подсказки (Rich Suggests, карточки объектов) являются стандартом современных поисковых систем, включая Яндекс. Они позволяют ускорить навигацию и предоставить быстрые ответы до перехода на SERP. Описанный механизм агрегации весов для обеспечения точности этих ответов остается актуальным.

Важность для SEO

Влияние на SEO значительно (7/10), особенно для брендового, навигационного и объектного трафика. Патент описывает механизм, определяющий, какой ресурс «владеет» префиксом в интерфейсе подсказок (Pre-SERP Optimization). Попадание в Rich Suggest увеличивает видимость и может генерировать прямой трафик, минуя SERP. Это подчеркивает важность сильной ассоциации сайта с широким кластером связанных запросов и высоких поведенческих показателей (CTR) по ним.

Детальный разбор

Термины и определения

Cumulative Resource Weight (Совокупный Вес Ресурса)

Ключевая метрика патента. Агрегированная оценка, отражающая общую значимость ресурса для введенного префикса. Рассчитывается путем суммирования Parameters (весов) всех поисковых подсказок из списка, связанных с этим ресурсом.

Display Data (Отображаемые данные)

Контент, отображаемый вместе со списком подсказок (Rich Suggest). Формируется из веб-контента, извлеченного из ресурса. Может включать имя, изображение, описание, ссылки. Также упоминается как Content Item или Object Card.

Parameter / Weight (Параметр / Вес)

Индивидуальная оценка, отражающая вероятность того, что пользователь перейдет на определенный ресурс после отправки конкретной поисковой подсказки. Основывается на исторических поведенческих данных (упоминаются number of clicks и number of views).

Prefix (Префикс)

Частичный ввод пользователя в поисковую строку (в патенте указан минимум в два символа).

Resource (Ресурс)

Целевой источник контента (например, веб-страница или сайт), с которым связана подсказка.

Suggested Search Query (Поисковая подсказка)

Предлагаемый полный запрос, основанный на префиксе. Подсказки ранжируются по вероятности выбора пользователем.

Suggest Engine (Движок подсказок)

Компонент системы, отвечающий за генерацию подсказок и принятие решения о показе Display Data.

Top Ranked Suggested Search Query (Главная / Топовая подсказка)

Подсказка из списка, имеющая наибольшую вероятность быть выбранной пользователем (обычно первая в списке).

Ключевые утверждения (Анализ Claims)

Патент фокусируется на методологии выбора контента для обогащенных подсказок путем агрегации весов по нескольким подсказкам, с обязательной проверкой связи с топовой подсказкой.

Claim 1 (Независимый пункт): Описывает основной процесс агрегации и принятия решения.

1. Система получает префикс от пользователя.
2. Идентифицируется список поисковых подсказок, ранжированных по вероятности выбора. Определяется Top Ranked Suggested Search Query.
3. Идентификация групп подсказок по ресурсам:
   • Определяется первая группа (First Plurality) подсказок, связанных с первым ресурсом. Критическое условие: эта группа ДОЛЖНА включать Top Ranked Suggested Search Query.
   • Определяется вторая группа (Second Plurality) подсказок, связанных со вторым ресурсом.
4. Каждой подсказке присвоен Parameter (вес), отражающий вероятность выбора ресурса при отправке этого запроса.
5. Расчет совокупных весов:
   • Вычисляется First Cumulative Resource Weight на основе агрегации параметров подсказок из первой группы.
   • Вычисляется Second Cumulative Resource Weight на основе агрегации параметров подсказок из второй группы.
6. Условие срабатывания: ЕСЛИ First Cumulative Resource Weight НЕ МЕНЬШЕ (т.е. больше или равен) Second Cumulative Resource Weight.
7. Действие: Идентифицируются Display Data (обогащенный ответ) для первого ресурса.
8. Вывод: Display Data передаются на устройство пользователя вместе со списком подсказок до отправки запроса.

Ключевой момент: для показа обогащенного ответа ресурс должен одновременно быть доминирующим интентом для всего префикса (максимальный Cumulative Resource Weight) и быть связанным с самой популярной интерпретацией префикса (Top Ranked Query).

Claim 7 (Зависимый от Claim 1): Описывает условия, при которых обогащенный контент НЕ показывается.

Система передает список подсказок БЕЗ Display Data, если выполняется хотя бы одно из условий:

• (i) Первая группа НЕ включает Top Ranked Suggested Search Query (т.е. топовая подсказка не связана с ресурсом).
• (ii) First Cumulative Resource Weight МЕНЬШЕ, чем Second Cumulative Resource Weight (т.е. ресурс не является доминирующим по весу).

Где и как применяется

Изобретение применяется на этапе взаимодействия пользователя с поисковой строкой, до отправки основного запроса и до этапа ранжирования SERP.

QUERY PROCESSING – Понимание Запросов (Suggest/Autocomplete)

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

• Suggested Search Query DB: Для получения списка ранжированных подсказок по префиксу.
• Parameter DB: Хранит предварительно рассчитанные веса (Parameters), связывающие подсказки с ресурсами и отражающие вероятность перехода.
• Content Item DB (или Rich Suggest Content Database): Хранит готовые Display Data (обогащенные ответы/карточки объектов) для ресурсов.

INDEXING – Индексирование и извлечение признаков (Offline)

Механизм полагается на офлайн-процессы:

• Анализ логов поведения пользователей для расчета весов (Parameters) и заполнения Parameter DB. В патенте упоминается, что это может выполняться с помощью Machine Learning algorithm.
• Извлечение контента из ресурсов для формирования Display Data и заполнения Content Item DB.

Входные данные: Префикс (User Input).

Выходные данные: Список подсказок (List of Suggested Search Queries) И, опционально, Display Data (обогащенный ответ).

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на навигационные, брендовые запросы и запросы, связанные с известными сущностями (Entity-related queries), для которых система может сформировать карточку объекта (Object Card). В патенте упоминается возможность определения, является ли ресурс или запрос навигационным (navigational resource/query).
• Конкретные типы контента: Влияет на видимость ресурсов, которые система считает авторитетными и доминирующими источниками (например, официальные сайты, Википедия).
• Конкретные ниши: Бренды, организации, персоналии, географические объекты, медиа — тематики, где часто ищут конкретный объект.
• Пользовательский опыт: Может приводить к увеличению числа прямых переходов из строки подсказок или к сессиям без клика по SERP (Zero-Click Searches).

Когда применяется

Алгоритм применяется каждый раз, когда пользователь вводит префикс (указано требование минимум двух символов) в поисковую строку.

Триггеры активации показа обогащенного ответа (Оба условия обязательны):

1. Условие 1 (Связь с Топом): Ресурс (Ресурс А) должен быть связан с главной подсказкой (Top Ranked Suggested Search Query).
2. Условие 2 (Доминирование Веса): Cumulative Resource Weight Ресурса А должен быть не меньше совокупного веса любого другого ресурса, связанного с этим префиксом.

Пошаговый алгоритм

Этап 1: Офлайн подготовка данных (Предварительные вычисления)

1. Анализ логов: Обработка исторических данных о поисковых сессиях и поведении пользователей.
2. Расчет весов: Для пар «Подсказка-Ресурс» вычисляется Parameter (Вес) — вероятность перехода на ресурс при выборе подсказки (на основе кликов/просмотров). Данные сохраняются в Parameter DB.
3. Генерация контента: Извлечение контента из ресурсов и формирование Display Data (карточек объектов). Данные сохраняются в Content Item DB.

Этап 2: Обработка запроса в реальном времени

1. Получение ввода: Система получает префикс от пользователя (например, «LOUV»).
2. Генерация подсказок: Идентификация списка ранжированных подсказок. Определение главной подсказки (Top Ranked) (например, 1. LOUVRE, 2. LOUVRE MUSEUM, 3. LOUVET DE COUVRAY).
3. Идентификация ресурсов и весов: Для каждой подсказки извлекаются связанные ресурсы и их веса (Parameters) из Parameter DB.
   • LOUVRE -> Resource A (Weight 3000)
   • LOUVRE MUSEUM -> Resource A (Weight 2500)
   • LOUVET DE COUVRAY -> Resource B (Weight 1500)
4. Группировка и Агрегация: Подсказки группируются по ресурсам. Для каждого ресурса рассчитывается Cumulative Resource Weight путем суммирования Parameters.
   • Cumulative Weight (Resource A) = 3000 + 2500 = 5500
   • Cumulative Weight (Resource B) = 1500
5. Проверка условий (Decision Logic):
   1. Определение ресурса, связанного с главной подсказкой (Кандидат = Resource A).
   2. Сравнение Совокупного Веса Кандидата с весами всех остальных ресурсов. (5500 >= 1500?).
6. Формирование ответа:
   • Если Кандидат имеет максимальный (не меньший, чем у других) вес: Извлечение Display Data для Resource A из Content Item DB. Передача списка подсказок И Display Data.
   • Иначе: Передача только списка подсказок.

Какие данные и как использует

Данные на входе

• Поведенческие факторы: Критически важны для офлайн-расчетов. Используются исторические логи поисковых сессий для определения популярности подсказок (ранжирование) и для расчета Parameters (вероятности перехода на ресурс). Явно упоминаются number of clicks и number of views.
• Контентные факторы: Используются офлайн для генерации Display Data. Система извлекает контент из ресурсов (веб-страниц) для формирования карточек объектов (имя, описание, изображение, ссылки).
• Пользовательские факторы (Ввод): Префикс, вводимый пользователем в реальном времени.

Какие метрики используются и как они считаются

• Ранжирование подсказок (Ranking): Метрика, основанная на «a likelihood of being selected by the user» (вероятности выбора пользователем), т.е. на исторической частотности использования подсказки.
• Parameter (Вес связи Подсказка-Ресурс): Метрика, отражающая «a likelihood of the resource being selected as a result of the suggested search query having been submitted». Вычисляется офлайн на основе поведенческой статистики (кликов/просмотров).
• Cumulative Resource Weight (Совокупный Вес Ресурса): Основная метрика для принятия решения. Рассчитывается в реальном времени путем агрегации (например, суммирования) индивидуальных Parameters для всех подсказок, связанных с конкретным ресурсом, для данного префикса.
  
  $$W_{CR}(R_1) = \sum_{Q_i \in S_{prefix}, Q_i \rightarrow R_1} W(Q_i, R_1)$$
  
  Где $W_{CR}(R_1)$ — совокупный вес ресурса R1, $S_{prefix}$ — список подсказок для префикса, $Q_i \rightarrow R_1$ — подсказка Qi связана с ресурсом R1, $W(Q_i, R_1)$ — вес связи (Parameter).
• Условие срабатывания: Сравнение совокупных весов. Обогащенный ответ для Ресурса 1 (связанного с топ-подсказкой) показывается, если $W_{CR}(R_1) \ge W_{CR}(R_x)$ для всех других ресурсов Rx в списке.

В патенте упоминается, что офлайн-расчет весов и ассоциаций может выполняться с помощью алгоритма машинного обучения (machine learning algorithm).

Выводы

1. Историческое поведение определяет релевантность: Яндекс активно использует историю поискового поведения пользователей для информирования текущего ранжирования. Поведенческая схожесть запросов (основанная на кликах по одним и тем же документам) рассматривается как эталон (Ground Truth).
2. Два типа схожести запросов: Патент четко разделяет поведенческую схожесть (для известных запросов) и текстовую схожесть (для новых запросов). При этом текстовая схожесть обучается аппроксимировать поведенческую.
3. Обогащение запроса как механизм ранжирования: Ключевой механизм воздействия на выдачу — это добавление терминов из похожих исторических запросов в качестве признаков ранжирования (Query Enrichment). Если документ содержит эти термины, его ранг повышается.
4. Решение проблемы «холодного старта»: Система специально разработана для улучшения ранжирования по новым или редким запросам, для которых нет статистики, путем переноса знаний с семантически близких запросов с богатой историей.
5. Важность векторного поиска: Эффективность системы зависит от быстрого поиска в векторном пространстве, для чего используются специализированные алгоритмы типа HNSW.

Практика

Best practices (это мы делаем)

• Укрепление связи Бренд-Ресурс по всему кластеру: Необходимо обеспечить, чтобы ваш официальный ресурс был наиболее кликабельным ответом не только по основному брендовому запросу, но и по всем его популярным вариациям (например, с ошибками, с уточнениями «официальный сайт», «контакты»). Это максимизирует Cumulative Resource Weight.
• Максимизация позитивных поведенческих сигналов (CTR): Поскольку веса (Parameters) основаны на кликах, критически важно иметь высокие CTR в основной выдаче по всем запросам, которые могут появляться в подсказках. Работайте над привлекательностью сниппетов.
• Оптимизация под Граф Знаний и структурированные данные: Поскольку Display Data часто формируется как карточка объекта (Object Card), важно обеспечить корректное представление вашей сущности в графе знаний Яндекса. Используйте микроразметку (Schema.org) и поддерживайте актуальность данных в справочниках (Яндекс Бизнес), чтобы система могла сформировать качественный Rich Suggest.
• Стимулирование навигационного спроса: Чем чаще пользователи ищут ваш бренд и переходят на ваш сайт, тем выше будут индивидуальные Parameters и тем вероятнее, что брендовый запрос станет Top Ranked Query.

Worst practices (это делать не надо)

• Размытие брендового трафика на множество доменов (Каннибализация): Если трафик по брендовым запросам распределяется между основным сайтом, лендингами и субдоменами, совокупный вес каждого отдельного ресурса может оказаться недостаточным для доминирования. Консолидация предпочтительнее.
• Игнорирование низкочастотных брендовых вариаций: Пренебрежение long-tail запросами и связанными поисками лишает контент возможности получать дополнительный вес за счет механизма обогащения.
• Создание тонкого контента (Thin Content): Контент, который отвечает только на очень узкий запрос и не содержит связанной информации, не получит преимуществ от этого алгоритма.

Стратегическое значение

Этот патент подтверждает стратегический приоритет Яндекса на понимание семантики и интента пользователя через анализ больших данных о поведении. Он показывает, как поведенческие данные напрямую влияют на интерпретацию текстовой релевантности. Для SEO это означает, что невозможно разделить работу над контентом и работу над поведенческими факторами. Долгосрочная стратегия должна строиться на создании авторитетных ресурсов, которые становятся центром притяжения для пользователей по широкому спектру связанных запросов в рамках одной тематики.

Практические примеры

Сценарий 1: Доминирование бренда (Успех)

1. Префикс: «Тинь»
2. Подсказки и Веса (условно):
   • 1. «Тинькофф» (Топ) -> Ресурс А (tinkoff.ru) (Вес: 10000)
   • 2. «Тинькофф банк» -> Ресурс А (tinkoff.ru) (Вес: 8000)
   • 3. «Тиньков Олег» -> Ресурс Б (wikipedia.org) (Вес: 2000)
3. Расчет: Совокупные веса: А = 10000+8000 = 18000. Б = 2000.
4. Проверка: Топ подсказка связана с А. Вес А (18000) >= Вес Б (2000).
5. Результат: Показывается Rich Suggest для tinkoff.ru.

Сценарий 2: Недостаточный совокупный вес (Неудача для Топ-подсказки)

1. Префикс: «Рецепт б»
2. Подсказки и Веса (условно):
   • 1. «Рецепт блинов» (Топ) -> Ресурс А (site1.ru) (Вес: 1000)
   • 2. «Рецепт борща» -> Ресурс Б (site2.ru) (Вес: 800)
   • 3. «Рецепт булочек» -> Ресурс Б (site2.ru) (Вес: 700)
3. Расчет: Совокупные веса: А = 1000. Б = 800+700 = 1500.
4. Проверка: Топ подсказка связана с А. Вес А (1000) >= Вес Б (1500)? Нет.
5. Результат: Rich Suggest НЕ показывается. Отображается только стандартный список подсказок, так как ресурс А не является доминирующим для префикса.

Сценарий 3: Топ-подсказка не связана с доминантом (Неудача для доминанта)

1. Префикс: «Фильм М»
2. Подсказки и Веса (условно):
   • 1. «Фильм Мстители» (Топ) -> Ресурс А (Кинопоиск) (Вес: 5000)
   • 2. «Фильм Матрица» -> Ресурс Б (Онлайн-кинотеатр) (Вес: 4000)
   • 3. «Фильм Майор Гром» -> Ресурс Б (Онлайн-кинотеатр) (Вес: 4000)
3. Расчет: Совокупные веса: А = 5000. Б = 4000+4000 = 8000.
4. Проверка: Топ подсказка связана с А. Вес А (5000) >= Вес Б (8000)? Нет.
5. Результат: Rich Suggest НЕ показывается. Ресурс А не доминирует по весу. (Хотя Ресурс Б доминирует по весу, он не связан с топовой подсказкой, но это условие проверяется для Ресурса А).

Вопросы и ответы