Как Google объединяет разные стратегии и поведенческие данные для генерации и выбора лучших альтернативных запросов

Описание

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

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

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

Запатентована архитектура системы поиска, которая интегрирует несколько независимых модулей пересмотра запросов (Query Revisers), каждый из которых реализует свою стратегию. Центральный компонент, Сервер пересмотра (Revision Server), координирует работу этих модулей, собирает предложенные альтернативы, оценивает их на основе показателя уверенности (Confidence Measure) и критериев разнообразия, и выбирает лучшие варианты. Ключевой особенностью является использование поведенческих данных для оценки качества ревизий и метод презентации альтернатив с превью результатов.

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

Система работает следующим образом:

• Оркестрация: Revision Server получает исходный запрос и параллельно рассылает его различным Query Revisers (модулям расширения, уточнения, синтаксиса, анализа сессий).
• Генерация и Оценка: Каждый модуль возвращает потенциальные пересмотренные запросы с ассоциированным Confidence Measure. Эта мера может рассчитываться динамически на основе предсказательных моделей и логов поведения пользователей (например, вероятности длинного клика).
• Сортировка и Фильтрация: Revision Server сортирует предложения по уверенности и применяет жесткие фильтры: наличие минимального числа результатов и наличие «новых» результатов (обеспечение разнообразия).
• Презентация: Лучшие пересмотренные запросы представляются пользователю. Патент описывает интерфейс, где альтернативы показываются (часто на отдельной странице) вместе с превью их топовых результатов.

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

Высокая. Архитектура, описанная в патенте, является фундаментальной для современных функций поиска, таких как «Связанные запросы» (Related Searches) и «Люди также ищут» (People Also Ask). Хотя конкретные алгоритмы внутри Query Revisers эволюционировали (например, с использованием нейронных сетей), сам принцип интеграции множества моделей, оценки уверенности на основе поведенческих сигналов (long clicks) и обеспечения разнообразия предложений остается стандартом.

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

Патент имеет высокое значение (8.5/10) для SEO. Он описывает механизмы, с помощью которых Google понимает взаимосвязи между запросами и активно направляет пользователей по альтернативным путям поиска. Понимание того, как генерируются эти альтернативы (особенно через анализ сессий и метрики удовлетворенности кликов), критически важно для построения тематического авторитета и охвата всего пути пользователя (user journey), а не только оптимизации под изолированные ключевые слова.

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

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

Broadening Reviser (Модуль расширения запроса)

Query Reviser, генерирующий менее специфичные запросы. Стратегии: добавление синонимов/связанных терминов или удаление маловажных терминов.

Confidence Measure (Показатель уверенности)

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

Expected Utility (Ожидаемая полезность)

Метрика для Session-Based Reviser. Рассчитывается как произведение частоты перехода от исходного запроса к пересмотренному и улучшения Quality Score.

Long Click (Длинный клик)

Клик на результат, после которого пользователь остается на странице в течение значительного времени (например, 60 секунд). Используется как индикатор удовлетворенности пользователя.

«New» Results («Новые» результаты)

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

Quality Score (Оценка качества запроса)

Метрика, оценивающая удовлетворенность пользователя результатами запроса. Рассчитывается на основе предполагаемой продолжительности кликов (Long Clicks).

Query Pair (Пара запросов)

Последовательность двух запросов (Q1, Q2), введенных пользователем в рамках одной сессии.

Query Reviser (Модуль пересмотра запросов)

Компонент, реализующий определенную стратегию пересмотра запросов и генерирующий альтернативные запросы.

Refinement Reviser (Модуль уточнения запроса)

Query Reviser, генерирующий более специфичные (узкие) запросы.

Reviser Confidence Estimator (Оценщик уверенности ревизий)

Компонент, использующий предиктивную модель (например, логистическую регрессию), обученную на исторических данных о кликах, для динамического расчета Confidence Measures путем предсказания вероятности Long Click.

Revision Server (Сервер пересмотра)

Центральный компонент, который координирует работу Query Revisers, собирает, оценивает, фильтрует и выбирает лучшие пересмотренные запросы.

Session-Based Reviser (Модуль пересмотра на основе сессий)

Query Reviser, использующий исторические данные о Query Pairs для предложения альтернатив на основе того, что другие пользователи искали дальше.

Syntactical Reviser (Модуль синтаксического пересмотра)

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

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

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

1. Генерация пересмотренных запросов для исходного запроса с использованием различающихся стратегий.
2. Вычисление Confidence Measure для каждого пересмотренного запроса на основе частоты встречаемости пары запросов (исходного и пересмотренного). (Примечание: Хотя в описании патента обсуждаются и другие методы расчета уверенности, Claim 1 фокусируется именно на частоте пар, что характерно для Session-Based Reviser).
3. Сравнение показателей уверенности.
4. Автоматический выбор подмножества пересмотренных запросов на основе сравнения.
5. Оценка результатов поиска и выбор подмножества этих результатов (для предпросмотра).
6. Предоставление исходных результатов на первой веб-странице.
7. Предоставление одновременного отображения выбранных пересмотренных запросов и их результатов предпросмотра на второй веб-странице.

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

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

Claim 6 (Зависимый): Детализирует критерии выбора пересмотренных запросов. Выбор происходит, если:

• Результаты поиска содержат минимальное количество результатов.
• Результаты поиска содержат минимальное количество «New» Results (не присутствующих в исходной выдаче или в уже выбранных альтернативах) – это критерий разнообразия.
• Общее количество выбранных запросов не превышает максимум.

Claim 14 (Зависимый): Детализирует метод расчета частоты встречаемости (используемой в Claim 1). Он включает анализ данных пользовательских сессий для подсчета индивидуальных запросов и пар запросов, и вычисление частоты как отношения количества пар к количеству исходных запросов.

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

Изобретение применяется на этапах понимания запроса и формирования финальной выдачи.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения. Revision Server координирует работу различных Query Revisers для генерации альтернативных формулировок, которые могут лучше соответствовать намерению пользователя. Это включает семантический, синтаксический и поведенческий анализ. Также включает офлайн-процессы: анализ логов для обучения Session-Based Reviser и Reviser Confidence Estimator.

RANKING – Ранжирование
Система выполняет ранжирование для потенциальных пересмотренных запросов. Это необходимо Revision Server для получения результатов, чтобы оценить их качество и разнообразие (проверка «New» Results) перед финальным выбором.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
На этом этапе принимается решение о том, как представить выбранные альтернативные запросы пользователю (например, в блоке «Related Searches» или на отдельной странице) и насколько заметно это сделать, основываясь на Confidence Measure.

Входные данные:

• Исходный запрос пользователя.
• Исторические данные (Log Files): логи сессий (Query Pairs), данные о кликах и их продолжительности.
• Лингвистические данные: списки синонимов, списки фраз, стоп-слова.

Выходные данные:

• Отсортированный список выбранных пересмотренных запросов.
• Набор топовых результатов поиска для каждого выбранного запроса (предпросмотр).

На что влияет

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

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

• Условия работы: Алгоритм генерации альтернатив применяется при обработке большинства пользовательских запросов.
• Триггеры активации и презентации: Решение о показе альтернатив пользователю зависит от Confidence Measure.
  • Если ни одно предложение не превышает минимальный порог уверенности, альтернативы могут не показываться.
  • Если уверенность очень высока, альтернатива может быть показана очень заметно (например, вверху страницы).
  • При средней уверенности может быть показана ссылка на отдельную страницу или блок внизу выдачи.

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

Процесс обработки запроса сервером пересмотра (Revision Server)

1. Инициализация: Получение исходного запроса (параллельно с отправкой в основной Search Engine).
2. Генерация кандидатов (Fan-out): Параллельная отправка запроса всем сконфигурированным Query Revisers (Broadening, Syntactical, Refinement, Session-Based и т.д.).
3. Сбор и Расчет Уверенности: Получение от каждого модуля списка потенциальных пересмотренных запросов. Для каждого рассчитывается Confidence Measure (статически, через Expected Utility или динамически через Reviser Confidence Estimator).
4. Сортировка: Сортировка всех полученных предложений по Confidence Measure от высокого к низкому.
5. Итеративная оценка и выбор: Обработка списка сверху вниз:
   1. Получение результатов: Запрос результатов поиска для текущего кандидата у Search Engine.
   2. Фильтрация по наличию результатов: Проверка, возвращает ли запрос минимальное количество результатов (например, > 0). Если нет, отбросить.
   3. Фильтрация по разнообразию (Diversity): Проверка, содержит ли топ результатов минимальное количество «New» Results (например, > 2), которые не присутствуют в топе исходного запроса или в топе уже выбранных альтернативных запросов. Если нет, отбросить.
   4. Выбор: Если фильтры пройдены, выбрать этот пересмотренный запрос.
   5. Проверка лимита: Если достигнуто максимальное количество выбранных запросов (например, 4), прекратить обработку.
6. Форматирование и предоставление: Создание страницы (или блока) с выбранными запросами и их топовыми результатами для предпросмотра. Предоставление этой информации пользователю.

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

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

Система использует разнообразные данные, в зависимости от типа активных Query Revisers:

• Поведенческие факторы (Ключевые):
  • Логи сессий (Session Logs / Log Files): Используются Session-Based Reviser для идентификации Query Pairs. Также используются Session Tracker для сбора данных.
  • Данные о кликах (Click Data / Click-through behavior): Используются для расчета Quality Score и обучения Reviser Confidence Estimator.
  • Продолжительность клика (Click Duration / Length of click): Предполагаемая продолжительность взаимодействия пользователя с результатом. Long Clicks используются как ключевой индикатор удовлетворенности.
• Контентные/Лингвистические факторы:
  • Списки синонимов/Тезаурусы: Используются Broadening Reviser.
  • Списки фраз (Phrase Lists) и N-граммы: Используются Syntactical Reviser для определения фраз, которые стоит заключить в кавычки.
  • Списки стоп-слов: Используются Syntactical Reviser для принудительного включения (например, через оператор «+»).
  • Списки имен и фамилий: Используются для идентификации имен собственных.

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

• Confidence Measure (Показатель уверенности): Оценка вероятности успеха пересмотренного запроса. Методы расчета:
  • Статический: Заранее заданные значения для стратегии.
  • Expected Utility: Для Session-Based Reviser.
  • Динамический (Predictive Model): Использование модели машинного обучения (например, логистической регрессии) в Reviser Confidence Estimator для предсказания вероятности «длинного клика» на основе признаков запросов.
• Quality Score (Оценка качества запроса): Оценка удовлетворенности результатами. Рассчитывается на основе продолжительности кликов. Патент описывает S-образную кривую (например, 20 сек = 0.1, 40 сек = 0.5, 60 сек = 0.9).
• Expected Utility (Ожидаемая полезность): Формула: $Frequency(Q1 \to Q2) * (QualityScore(Q2) — QualityScore(Q1))$.
• Частота перехода (Frequency of Occurrence): Рассчитывается как отношение количества сессий, где за запросом Q1 следовал запрос Q2, к общему количеству сессий с запросом Q1.
• Критерии фильтрации: Пороги для минимума результатов (например, 1), минимума «New» Results (например, 2) и максимума предложений (например, 4).

Выводы

1. Интеграция множества стратегий: Google не полагается на один метод улучшения запросов. Система использует расширяемую архитектуру (Revision Server) для одновременного применения и сравнения результатов работы различных стратегий (семантических, синтаксических, поведенческих).
2. Ранжирование предложений по уверенности (Confidence): Все сгенерированные альтернативы оцениваются с помощью Confidence Measure. Этот показатель может рассчитываться сложными методами, включая ML-модели, прогнозирующие удовлетворенность пользователя.
3. Критическая роль поведенческих данных и удовлетворенности: Удовлетворенность пользователя (Quality Score), измеряемая через продолжительность кликов (Long Clicks), является центральной метрикой. Она используется для расчета Expected Utility и обучения моделей предсказания уверенности.
4. Обеспечение разнообразия (Diversity) как жесткое требование: Система применяет строгий фильтр: альтернативный запрос выбирается, только если он приносит «New» Results, отличные от исходной выдачи. Это максимизирует охват интентов.
5. Важность данных о сессиях: Анализ того, что пользователи ищут сразу после текущего запроса (Session-Based Reviser и Query Pairs), является сильным сигналом для генерации релевантных альтернатив.
6. Контекстное представление: Патент подчеркивает важность показа альтернативных запросов вместе с их результатами (предпросмотр), чтобы пользователь мог оценить релевантность предложения до клика.

Практика

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

• Анализ «Related Searches» и «People Also Ask»: Активно изучайте, какие альтернативные запросы предлагает Google для ваших целевых кластеров. Это прямой результат работы подобной системы. Это помогает выявить, как Google соединяет темы на основе реальных сессий (Session-Based Reviser) и какие смежные интенты он считает релевантными.
• Построение тематического авторитета и охват User Journey: Создавайте контент, который охватывает не только основной запрос, но и те запросы, к которым пользователи часто переходят в рамках одной сессии (Query Pairs). Это увеличивает релевантность сайта для всего пути пользователя.
• Оптимизация под удовлетворенность пользователя (Long Clicks): Поскольку Quality Score (удовлетворенность) измеряется через продолжительность кликов и используется для валидации альтернативных запросов, крайне важно создавать контент, который полностью отвечает на интент пользователя и удерживает его внимание, избегая «pogo-sticking».
• Использование широкого семантического ядра (Синонимы и Фразы): Учитывайте работу Broadening Reviser (добавление синонимов) и Syntactical Reviser (идентификация фраз). Включайте релевантные синонимы и естественные словосочетания в контент, чтобы соответствовать различным вариантам пересмотренных запросов.

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

• Фокус на изолированных ключевых словах: Оптимизация страницы только под одну точную формулировку запроса без учета смежных тем и следующих шагов пользователя. Система может предложить пользователю альтернативный запрос, который уведет его на другой ресурс, лучше покрывающий тему целиком.
• Создание контента, ведущего к быстрым отказам (Short Clicks): Если контент не удовлетворяет пользователя, это снижает Quality Score для связанных запросов. Это негативно скажется на том, как часто система будет считать эти запросы (и ваш контент) полезными для пользователей.
• Игнорирование широкого или узкого интента: Создание контента, который не учитывает возможности как расширения, так и сужения темы. Необходимо соответствовать как работе Refinement Reviser (уточнения), так и Broadening Reviser (обобщения).

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

Этот патент подтверждает, что Google рассматривает поиск не как единичное событие (запрос-ответ), а как процесс или путешествие (journey). Система активно пытается понять контекст и предсказать следующий шаг пользователя, используя для этого множество сигналов, в первую очередь поведение других пользователей. Стратегия SEO должна быть направлена на охват всего тематического пространства и обеспечение высокого уровня удовлетворенности на каждом этапе поиска.

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

Сценарий: Охват пути пользователя при поиске продукта

1. Исходный запрос пользователя: [кроссовки Nike]. Запрос слишком широкий.
2. Активация системы: Revision Server запрашивает альтернативы.
3. Работа Revisers:
   • Refinement Reviser предлагает уточнения: [кроссовки Nike Air Max], [кроссовки Nike для бега].
   • Session-Based Reviser анализирует логи и видит, что пользователи часто переходят к запросу [сравнение Nike и Adidas] или [отзывы о Nike Pegasus] с высокой Expected Utility.
4. Выбор и представление: Система выбирает [кроссовки Nike Air Max] и [отзывы о Nike Pegasus] как наиболее уверенные и разнообразные предложения и показывает их в блоке «Related Searches».
5. Действия SEO-специалиста: Для успешного ранжирования недостаточно иметь общую страницу категории. Необходимо также иметь:
   1. Оптимизированные страницы подкатегорий/продуктов (Air Max, Pegasus).
   2. Контент, отвечающий на информационные и сравнительные интенты (отзывы, сравнения).
   3. Обеспечить высокий Quality Score (длинные клики) на этих страницах.
6. Ожидаемый результат: Сайт появляется в выдаче на разных этапах поиска пользователя, захватывая трафик как по общим, так и по уточненным и связанным запросам.

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