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

Описание

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

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

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

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

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

Когда пользователь вводит префикс (например, «louv»), система идентифицирует список подсказок («louvre», «louvre museum» и т.д.). Для каждой подсказки система знает ассоциированные ресурсы и их вес (Resource Weight/Parameter), основанный на исторической вероятности перехода. Система рассчитывает Cumulative Resource Weight, суммируя веса для одного и того же ресурса по разным подсказкам. Если совокупный вес первого ресурса не меньше совокупного веса второго ресурса, система выбирает первый ресурс и показывает его Display Data (богатый ответ) вместе со списком подсказок, до того как пользователь отправит полный запрос.

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

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

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

Влияние на SEO значительно (6.5/10). Патент не описывает ранжирование в основной выдаче (SERP), но он критически важен для видимости на этапе ввода запроса (Pre-Search Visibility). Победа в блоке Rich Suggest дает значительное преимущество в видимости и авторитетности, позволяя захватить внимание пользователя еще до перехода на SERP. Это особенно важно для навигационных, брендовых запросов и запросов о сущностях.

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

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

Content Item (Элемент контента)

Блок информации, связанный с ресурсом. Содержит Display Data и может быть представлен как Object Card (Карточка объекта).

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

Ключевая метрика патента. Агрегированный вес для конкретного ресурса, рассчитанный путем суммирования индивидуальных весов (Parameters/Resource Weights) этого ресурса по всем релевантным поисковым подсказкам, связанным с введенным префиксом.

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

Контент, который отображается в блоке богатого ответа (Rich Suggest). Включает текст, изображения, ссылки, извлеченные из ресурса.

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

Индивидуальный вес, отражающий силу связи (Relation) между конкретной подсказкой и конкретным ресурсом. Основан на вероятности того, что пользователь перейдет на этот ресурс после выбора этой подсказки (например, на основе исторического количества кликов или просмотров).

Prefix (Префикс)

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

Resource (Ресурс)

Источник контента (например, URL или веб-сайт), из которого извлекаются Display Data.

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

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

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

Вариант завершения запроса (autocomplete), предлагаемый пользователю.

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

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

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

1. Система получает Префикс от пользователя.
2. Идентифицируется ранжированный список поисковых подсказок, включающий как минимум Первую (S1) и Вторую (S2) подсказки. S1 более вероятна для выбора, чем S2.
3. Система проверяет выполнение двух условий одновременно:
   1. S1 связана с Первым ресурсом (R1).
   2. Cumulative Resource Weight для R1 (основанный на связи S1 и R1) НЕ МЕНЬШЕ (больше или равен), чем Cumulative Resource Weight для Второго ресурса R2 (основанный на связи S2 и R2).
4. Если оба условия выполнены: Идентифицируются Display Data (богатый ответ) для R1.
5. Система отправляет пользователю список подсказок ВМЕСТЕ с Display Data для R1, до отправки полного запроса в поиск.

Claim 3 и 4 (Зависимые пункты): Уточняют механизм агрегации веса (ключевой аспект).

Если в списке есть Третья подсказка (S3), которая ТАКЖЕ связана с Первым ресурсом (R1), то Cumulative Resource Weight для R1 рассчитывается на основе как связи S1-R1, так и связи S3-R1. Этот агрегированный вес затем сравнивается с весом R2.

Claim 5 и 7 (Зависимые пункты): Определяют природу весов.

Веса основаны на вероятности доступа пользователя к ресурсу. Конкретные метрики, упомянутые для расчета этой вероятности, — это «количество кликов» (number of clicks) и «количество просмотров» (number of views).

Claim 22 (Зависимый пункт, в тексте PDF): Описывает негативный сценарий.

Если условия Claim 1 не выполнены (например, вес R1 меньше веса R2, или S1 не связана с ресурсом), система отправляет список подсказок БЕЗ Display Data.

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

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

QUERY PROCESSING – Понимание Запросов (Suggest Engine)
Весь процесс реализуется внутри Suggest Engine (Движка подсказок), который обрабатывает префикс в реальном времени.

Взаимодействие с компонентами:

Suggest Engine взаимодействует с тремя ключевыми базами данных (описанными в патенте):

1. Suggested Search Query DB: Сопоставляет префиксы с ранжированным списком подсказок.
2. Parameter DB: Хранит предопределенные связи между подсказками, ресурсами и их весами (Parameters), основанными на исторических поведенческих данных.
3. Content Item DB (или Rich Suggest Content Database): Хранит готовые Display Data (Rich Suggest контент), извлеченные из ресурсов.

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

Данные на выходе: Список поисковых подсказок и (опционально) Display Data.

Технические особенности: Система опирается на предварительно вычисленные данные (офлайн) для обеспечения высокой скорости ответа в реальном времени.

На что влияет

• Специфические запросы: Наибольшее влияние на навигационные запросы (бренды, организации) и запросы об известных сущностях (персоны, места, объекты), где существует явный доминирующий ресурс (официальный сайт или страница в Википедии).
• Конкретные типы контента: Влияет на видимость ресурсов, которые могут предоставить структурированную информацию в формате Object Card.

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

• Условия работы: Активируется при вводе пользователем префикса (минимум два символа, как указано в патенте).
• Триггеры активации Rich Suggest: Показ богатого ответа происходит только тогда, когда Cumulative Resource Weight одного ресурса не меньше, чем у любого другого ресурса, связанного с этим же набором подсказок.
• Исключения: Если интент не ясен или ни один ресурс явно не доминирует (веса близки), богатый ответ не показывается.

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

Фаза 1: Офлайн-подготовка (Подразумевается патентом)

1. Сбор данных: Анализ логов поисковых сессий и поведения пользователей (клики, просмотры).
2. Вычисление весов: Расчет Параметров (Resource Weights) для пар «Подсказка – Ресурс», возможно, с помощью машинного обучения.
3. Извлечение контента: Краулинг ресурсов и формирование Display Data (Content Items).

Фаза 2: Обработка запроса в реальном времени (Suggest Engine)

1. Получение ввода: Система получает префикс (например, «louv»).
2. Идентификация подсказок: Получение ранжированного списка подсказок (S1=»louvre», S2=»louvre museum», S3=»louvre paris», S4=»louvet de couvray»).
3. Извлечение весов: Получение ресурсов и их индивидуальных весов из Parameter DB.
   • S1 -> R1 (wiki/louvre), W1=3000
   • S2 -> R1 (wiki/louvre), W2=2500
   • S3 -> R1 (wiki/louvre), W3=2000
   • S4 -> R2 (wiki/louvetdecouvray), W4=1500
4. Расчет Cumulative Resource Weight (Агрегация):
   • Cumulative(R1) = W1 + W2 + W3 = 7500
   • Cumulative(R2) = W4 = 1500
5. Сравнение и принятие решения: Сравнение совокупных весов. Cumulative(R1) ≥ Cumulative(R2) (7500 ≥ 1500). Условие выполнено. R1 доминирует.
6. Извлечение контента: Извлечение Display Data для R1 из Content Item DB.
7. Передача данных: Отправка клиенту списка подсказок вместе с Display Data для R1. Если бы условие на шаге 5 не выполнилось, были бы отправлены только подсказки.

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

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

• Поведенческие факторы: Критически важны для офлайн-расчета весов (Parameters/Resource Weights). Патент явно указывает на использование исторических данных о «number of clicks» (количестве кликов) и «number of views» (количестве просмотров) для определения вероятности доступа к ресурсу (Claim 5, 7).
• Контентные факторы: Текст, изображения, описания извлекаются из ресурсов офлайн для генерации Display Data (Rich Suggest content).
• Системные данные: Логи прошлых поисковых сессий (Past search sessions) используются для определения популярности подсказок и расчета поведенческих весов (Claim 26).

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

• Ранжирование подсказок (Ranking): Метрика популярности подсказки, основанная на вероятности ее выбора пользователем (частотности).
• Resource Weight / Parameter: Метрика связи «Подсказка-Ресурс». Рассчитывается как вероятность перехода на ресурс R при запросе Q (подсказке). Основана на исторических кликах/просмотрах.
• Cumulative Resource Weight: Агрегированная метрика связи «Префикс-Ресурс». Рассчитывается путем суммирования Resource Weights для одного ресурса по всем релевантным подсказкам (Si), сгенерированным для данного префикса.
  
  Формула расчета (на основе описания в патенте):
  $$Cumulative(R) = \sum_{i} ResourceWeight(S_i, R)$$

Методы вычислений: Патент указывает (Claim 29), что веса и связи могут быть определены с помощью machine learning algorithm (алгоритма машинного обучения), обученного на исторических данных.

Выводы

1. Агрегация авторитетности по кластеру: Ключевой вывод — Яндекс определяет доминирующий ресурс для Rich Suggest не по самой популярной подсказке, а по совокупной значимости ресурса (Cumulative Resource Weight) для всего кластера запросов, связанных с префиксом.
2. Поведенческие данные как основа весов: Веса ресурсов напрямую зависят от исторических данных о поведении пользователей (клики, переходы). Чтобы получить Rich Suggest, необходимо исторически зарабатывать переходы по соответствующим запросам в основной выдаче.
3. Доминирование как триггер («Победитель получает все»): Богатый ответ показывается только при явном доминировании одного ресурса. При неоднозначности (близких весах конкурентов) система предпочтет не показывать ответ, приоритизируя точность.
4. Зависимость от офлайн-вычислений: Все веса и контент для ответов рассчитываются и извлекаются заранее (офлайн) для обеспечения максимальной скорости работы интерфейса подсказок.
5. Фокус на навигационные запросы: Упоминание в патенте возможности определения навигационных ресурсов/запросов (Claim 21) предполагает, что система отдает приоритет этому механизму для ускорения прямой навигации.

Практика

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

• Укрепление Topical/Entity Authority и охват кластера запросов: Необходимо быть основным пунктом назначения по всему кластеру связанных запросов (например,,,). Это увеличит Cumulative Resource Weight, так как ресурс будет аккумулировать веса от нескольких подсказок.
• Максимизация Поведенческих Факторов (CTR в SERP): Поскольку веса основаны на исторических кликах, работа над привлекательностью сниппетов в основной выдаче (SERP) и удовлетворенностью пользователей напрямую влияет на вероятность попадания в Rich Suggest. Высокий CTR укрепляет связь «Подсказка – Ресурс».
• Консолидация навигационного интента: Убедитесь, что трафик по семантически близким запросам консолидируется на основном домене, а не распределяется по множеству поддоменов, что может размыть совокупный вес.
• Оптимизация контента для извлечения (Object Card): Убедитесь, что на сайте есть четкая структура, качественные изображения и краткие описания, которые Яндекс может легко извлечь для формирования Display Data.

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

• Фрагментация присутствия: Наличие нескольких доменов или неконсолидированных поддоменов для одного бренда может размыть Cumulative Resource Weight между ними, не позволяя ни одному достичь порога доминирования.
• Игнорирование вариаций запросов: Оптимизация только под один ВЧ запрос. Если вы не получаете трафик по смежным запросам (подсказкам), ваш совокупный вес будет ниже, чем у конкурента (например, Википедии или агрегатора), который отвечает на все вариации.
• Игнорирование поведенческих сигналов: Если пользователи ищут ваш бренд или тему, но переходят на другие сайты, ваш Resource Weight будет низким.

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

Патент подтверждает стратегическую важность «нулевого этапа» поиска (взаимодействия с подсказками). Он демонстрирует, как Яндекс использует агрегированные поведенческие данные для математической оценки доминирования ресурса (Cumulative Resource Weight). Для долгосрочной SEO-стратегии это означает необходимость построения сильного, авторитетного ресурса, который является предпочтительным ответом для пользователей по всему семантическому кластеру, а не только по отдельным запросам.

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

Сценарий 1: Агрегация веса по информационному запросу (Пример из патента)

Пользователь вводит префикс «louv».

1. Подсказки и Веса:
   • «louvre» -> wiki/louvre (W=3000)
   • «louvre museum» -> wiki/louvre (W=2500)
   • «louvre paris» -> wiki/louvre (W=2000)
   • «louvet de couvray» -> wiki/louvetdecouvray (W=1500)
2. Расчет Cumulative Resource Weight:
   • R1 (wiki/louvre) = 3000 + 2500 + 2000 = 7500
   • R2 (wiki/louvetdecouvray) = 1500
3. Решение: R1 (wiki/louvre) доминирует (7500 > 1500) благодаря агрегации весов по трем разным подсказкам. Показывается Rich Suggest для R1.
4. Действие SEO (для конкуренции с Википедией): Необходимо создать страницу, которая исторически собирает больше кликов (имеет лучший CTR и удовлетворенность) по всем трем запросам («louvre», «louvre museum», «louvre paris»), чтобы увеличить свой Cumulative Resource Weight и обойти Википедию.

Сценарий 2: Определение доминирующего ресурса для бренда

Пользователь вводит префикс «сбер».

1. Подсказки и Веса (упрощенно):
   • «сбербанк» -> sberbank.ru (W=5000)
   • «сбербанк онлайн» -> online.sberbank.ru (W=4000)
   • «сбермегамаркет» -> sbermegamarket.ru (W=2000)
2. Расчет Cumulative Resource Weight:
   • R1 (sberbank.ru) = 5000
   • R2 (online.sberbank.ru) = 4000
   • R3 (sbermegamarket.ru) = 2000
3. Решение: R1 имеет наибольший совокупный вес. Система покажет Rich Suggest для sberbank.ru.
4. Действие SEO: Мониторить CTR по основному брендовому запросу для поддержания высокого Weight и обеспечить наличие качественного контента (логотип, описание) для извлечения в Display Data.

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