Как Google использует поведение пользователей и анализ SERP для определения контекстно-зависимых синонимов

Описание

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

Патент решает фундаментальную проблему информационного поиска: традиционные тезаурусы и словари неэффективны для расширения запросов, поскольку синонимичность часто полностью зависит от контекста. Например, «music» не является общим синонимом «loops», но является хорошим синонимом в контексте запроса [free loops for flash movie]. Изобретение предлагает автоматизированный, основанный на данных метод для идентификации таких контекстно-зависимых синонимов, повышая полноту поиска (Recall) без ручного создания лексических баз.

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

Запатентована система и метод для автоматического определения синонимов термов запроса с учетом контекста. Суть изобретения заключается в анализе логов поисковых запросов (Query Logs), сгруппированных по пользовательским сессиям. Система идентифицирует пары запросов, которые отличаются только одной фразой, но имеют идентичный контекст (окружающие слова). Эти фразы становятся кандидатами в синонимы и валидируются с помощью строгих статистических тестов, основанных на частоте переформулировок пользователями и степени пересечения результатов поиска (SERP Overlap).

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

Система работает в два этапа: офлайн-генерация и онлайн-применение.

• Офлайн-анализ: Логи запросов анализируются для идентификации сессий. Из запросов генерируются Pseudo-queries (псевдо-запросы) путем замены фразы на токен (например, [gm : car prices]). Запросы с одинаковым Pseudo-query группируются, а отличающиеся фразы (например, «used» и «new») становятся кандидатами.
• Валидация: Кандидаты проверяются статистически: как часто пользователи меняют фразу в сессии и насколько похожи результаты поиска по обоим запросам. Рассчитывается оценка уверенности (Evidence Score).
• Онлайн-применение: При получении запроса система использует валидированные синонимы для создания измененного запроса (Altered Query). Это может быть расширение через оператор OR (дизъюнкция), прямая замена терма или использование синонима для корректировки ранжирования.

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

Критически высокая. Понимание контекста и семантической эквивалентности является фундаментом современного поиска. Хотя статистические методы, описанные в патенте, сегодня дополнены или заменены нейросетевыми моделями (BERT, MUM), базовые принципы — использование контекста для определения значения слова и валидация через поведение пользователей и схожесть SERP — остаются центральными для систем Query Understanding.

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

Патент имеет фундаментальное значение для SEO (9/10). Он описывает конкретный механизм, лежащий в основе перехода от лексического к семантическому поиску. Это напрямую влияет на исследование ключевых слов и стратегию контента: необходимо понимать, какие термины Google считает взаимозаменяемыми в конкретном контексте на основе поведения пользователей, а не полагаться на словари. Анализ пересечения выдачи (SERP Overlap) становится ключевой тактикой для понимания интента и кластеризации запросов.

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

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

Altered Query (Измененный запрос)

Запрос, полученный путем замены фразы в исходном запросе на синоним (кандидат).

Candidate Synonym (Кандидат в синонимы)

Фраза, которая потенциально может заменить исходную фразу в определенном контексте. Идентифицируется через анализ Pseudo-queries.

Context (Контекст)

Слова, окружающие фразу в запросе, и их позиция. Контекст может быть общим (:) или специфическим, например, (word1 : word2).

Evidence Score (Оценка уверенности)

Итоговая метрика (от 0 до 1.0), рассчитываемая на основе взвешенной суммы статистических тестов. Отражает уверенность системы в валидности синонима в данном контексте.

Phrase (Фраза)

Один или несколько последовательных термов в запросе.

Pseudo-query (Псевдо-запрос)

Шаблон запроса, созданный путем замены Phrase на токен (например, «:»). Используется для идентификации запросов с одинаковым контекстом. Пример: [gm : car prices].

Query Logs (Логи запросов)

Хранилище исторических поисковых запросов, включающее User ID, временные метки и списки топовых результатов поиска (Doc IDs/URLs).

Session (Сессия)

Последовательность запросов от одного пользователя в течение определенного временного интервала (например, один час).

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

Патент описывает как процесс генерации синонимов, так и несколько различных способов их применения (Claims 1, 11, 16).

Claim 1 (Независимый пункт): Описывает применение синонимов через расширение запроса (Query Expansion via Disjunction).

1. Система получает поисковый запрос.
2. Выбирается терм. Оставшиеся термы и позиция выбранного терма определяют контекст.
3. Подбирается терм-замена (синоним). Критерий: этот синоним ранее встречался в логах в той же самой позиции относительно тех же оставшихся термов (т.е. в идентичном контексте).
4. Создается Altered Query путем замены исходного терма на дизъюнкцию (OR) исходного терма и синонима. (Например, [gm cars] -> [(gm OR general motors) cars]).
5. Генерируются результаты для Altered Query.

Claim 16 (Независимый пункт): Описывает применение через прямую замену (Direct Substitution).

1. Шаги 1-3 аналогичны Claim 1.
2. Создается Altered Query путем прямой замены исходного терма на синоним (без дизъюнкции). (Например, [gm cars] -> [general motors cars]).
3. Генерируются результаты для Altered Query.

Claim 11 (Независимый пункт): Описывает применение через модификацию ранжирования (Ranking Modification).

1. Шаги 1-3 аналогичны Claim 1.
2. Генерируются результаты для исходного запроса и их ранжирование.
3. Ранжирование модифицируется на основе того, содержат ли результаты поиска терм-замену (синоним). (Позволяет повышать документы с синонимом без явного переписывания запроса).

Claims 2 и 3 (Зависимые): Детализируют офлайн-процесс генерации и валидации синонимов.

1. Анализируются Query Logs для идентификации термов, появляющихся в одинаковом контексте.
2. Определяется количество общих результатов поиска для пары запросов, отличающихся только этими термами.
3. Термы признаются синонимами в данном контексте, если количество общих результатов превышает порог.

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

Изобретение является ключевым компонентом этапа понимания запросов.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения. Он включает два процесса:

1. Офлайн-анализ (Генерация синонимов): Система периодически анализирует Query Logs, поведение пользователей в сессиях и схожесть SERP для построения базы данных контекстно-зависимых синонимов. Это включает расчет Evidence Score.
2. Онлайн-обработка (Переписывание запросов): При получении запроса система интерпретирует его контекст, ищет применимые синонимы в базе данных и выполняет Query Rewriting/Expansion (расширение, замена) или принимает решение о модификации ранжирования.

RANKING – Ранжирование
На этом этапе используется переписанный запрос. Кроме того, согласно Claim 11, система может использовать наличие валидированного синонима в документе как сигнал для модификации Ranking Score.

Входные данные (Офлайн):

• Query Logs (текст запроса, User ID, временные метки).
• Списки топовых результатов поиска (Document IDs/URLs) для запросов в логах.

Выходные данные (Офлайн):

• База данных валидированных синонимов с указанием контекста и Evidence Score.

Входные данные (Онлайн):

• Входящий запрос пользователя.
• База данных синонимов.

Выходные данные (Онлайн):

• Altered Query или модифицированные сигналы ранжирования.

На что влияет

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

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

• Офлайн-анализ: Выполняется периодически (например, еженедельно). Требует накопления достаточного объема данных для статистической значимости (упоминается необходимость минимум 1000 запросов с фразой).
• Онлайн-применение: Активируется в реальном времени, если входящий запрос соответствует контексту, для которого существует валидированный синоним, и Evidence Score этого синонима превышает установленный порог (например, >0.6 для автоматического расширения).

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

Процесс А: Офлайн-генерация и валидация синонимов

1. Сбор и сортировка данных: Сбор Query Logs. Сортировка по User ID и времени для организации запросов в сессии. Фильтрация коротких запросов (<3 слов).
2. Генерация Pseudo-queries: Для каждого запроса создание всех возможных Pseudo-queries путем замены фразы на токен (:), оставляя минимум два слова контекста.
3. Компиляция информации: Создание записей для каждого Pseudo-query, включающих исходный запрос, замененную фразу и топ результатов поиска. Фиксация случаев, когда разные фразы используются в одном Pseudo-query в рамках одной сессии.
4. Идентификация кандидатов: Группировка записей по Pseudo-query. Идентификация различных фраз на месте токена как Candidate Synonyms.
5. Сбор статистики: Для каждой пары (Фраза А, Синоним Б) в каждом контексте собирается статистика:
   • TDQ: Общее количество уникальных запросов с А.
   • i) Existence: Количество запросов с А, для которых запрос с Б также существует в логах.
   • ii) Commonality Data Available: Количество пар, для которых есть данные о результатах.
   • iii/iv) High/Low Commonality: Количество пар с минимум 3 / минимум 1 общим результатом.
   • v/vi) Session Successor/Predecessor: Количество переключений А->Б / Б->А в сессиях.
6. Квалификация и Оценка (Qualification): Применение статистических тестов (FIG. 3).
   1. Проверка предварительных условий (например, >65% пар имеют 1+ общий результат; частота замены >1/2000).
   2. Расчет метрик (frequently_alterable, frequently_much_in_common, frequently_altered, high_altering_ratio) с использованием функции Scale.
   3. Расчет итоговой оценки Evidence Score.
7. Сохранение: Сохранение синонимов, превысивших пороговый Evidence Score, в базу данных.

Процесс Б: Онлайн-применение синонимов

1. Получение запроса: Система получает запрос.
2. Анализ контекста и поиск синонимов: Поиск валидированных синонимов в базе данных для фраз в текущем контексте.
3. Принятие решения: На основе Evidence Score система выбирает метод применения: расширение (Claim 1), замена (Claim 16) или модификация ранжирования (Claim 11).
4. Генерация и выполнение Altered Query: Создание и выполнение измененного запроса или корректировка ранжирования.

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

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

Патент полностью полагается на анализ исторических данных из логов поиска.

• Поведенческие факторы (Критически важно):
  • Query Logs: Текст запросов.
  • User ID и Временные метки: Используются для группировки запросов в Sessions.
  • Последовательность запросов в сессии: Анализ порядка запросов для выявления переформулировок (замены одного терма на другой в том же контексте).
• Системные данные (SERP Data):
  • Результаты поиска (Document IDs/URLs): Списки топовых результатов для запросов из логов. Используются для оценки семантической близости через расчет пересечения выдачи (SERP Overlap).

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

Система использует набор статистических тестов для расчета Evidence Score. TDQ = Total Distinct Queries.

• frequently_alterable (i/TDQ): Доля запросов, для которых измененный запрос (с синонимом) также существует в логах.
• frequently_much_in_common (iv/ii или iii/ii): Доля пар запросов (исходный и измененный), которые имеют значительное количество общих результатов поиска. Ключевой индикатор семантической близости.
• frequently_altered (v/TDQ): Доля запросов, после которых пользователь ввел измененный запрос в той же сессии.
• high_altering_ratio (v/vi): Отношение частоты замен А на Б к частоте замен Б на А. Позволяет определить предпочтительный терм.

Расчет итоговой оценки (Evidence Score):

Метрики нормализуются с помощью функции Scale и агрегируются (с весами):

$soft_and = freq_alterable + 2 * freq_much_in_common + 0.5 * freq_altered + high_altering_ratio$

Финальная оценка рассчитывается как:

$Evidence=1.0-exp(-sof{t}_{a}nd$

Выводы

1. Контекст определяет синонимичность: Ключевой вывод — Google не использует универсальные словари. Является ли слово синонимом, определяется исключительно контекстом (окружающими словами в запросе).
2. Поведение пользователей (User Behavior) как источник истины: Система изучает язык, наблюдая за тем, как пользователи переформулируют запросы в рамках одной сессии (Session). Если пользователи часто заменяют А на Б, это сильный сигнал синонимичности.
3. Совпадение результатов поиска (SERP Overlap) как валидатор: Ключевым критерием семантической близости является пересечение результатов поиска (метрика frequently_much_in_common). Если разные запросы возвращают схожий набор документов, они решают одну и ту же задачу.
4. Многообразие применения: Система может применять синонимы по-разному: через расширение запроса (OR), прямую замену терма или модификацию ранжирования. Выбор зависит от рассчитанной оценки уверенности (Evidence Score).
5. Автоматизация и статистика: Метод полностью автоматизирован и основан на строгом статистическом анализе больших данных (логов), что обеспечивает масштабируемость и объективность.

Практика

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

• Анализ совпадения выдачи (SERP Overlap) для кластеризации: Сделайте анализ SERP Overlap стандартной практикой. Если два запроса показывают высокое пересечение результатов (например, >60-70%), Google считает их семантически идентичными (согласно метрике frequently_much_in_common). Такие запросы следует таргетировать на одну страницу.
• Изучение реальных пользовательских запросов и переформулировок: Анализируйте данные GSC, Google Trends, PAA и подсказки, чтобы понять, как пользователи ищут информацию и какие термины они считают взаимозаменяемыми (сигнал frequently_altered). Это дает представление о том, как система видит вашу нишу.
• Использование контекстуально релевантных синонимов в контенте: Насыщайте тексты естественными вариациями ключевых слов и синонимами, которые уместны в контексте темы. Это повышает релевантность контента для расширенных запросов, которые Google генерирует автоматически.
• Фокус на Интенте, а не на Точном Вхождении: Поскольку Google активно переписывает запросы, концентрация на полном ответе на информационную потребность пользователя важнее, чем оптимизация под конкретную формулировку.

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

• Использование синонимов из словаря без учета контекста: Механическое добавление синонимов из тезауруса неэффективно. Google валидирует синонимы только в том случае, если они используются взаимозаменяемо пользователями в конкретном контексте.
• Игнорирование контекста и окружающих слов (Co-occurrence): Оптимизация страницы под изолированный термин без обеспечения правильного контекстного окружения снижает эффективность, так как система может неверно интерпретировать значение термина или не найти для него валидированных синонимов.
• Создание отдельных страниц для близких синонимов (Каннибализация): Создание разных страниц для терминов, которые Google считает контекстуальными синонимами (высокий SERP Overlap), приведет к каннибализации, так как система видит их как один интент.

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

Этот патент является одним из фундаментальных документов, подтверждающих переход Google от лексического поиска к семантическому. Он демонстрирует, как Google использует «мудрость толпы» (анализ поведения миллионов пользователей) и анализ данных (SERP Overlap) для построения динамической и контекстно-зависимой карты языка. Для SEO это означает, что долгосрочная стратегия должна быть направлена на понимание интента пользователя во всех его проявлениях и вариациях, а не на оптимизацию под фиксированный набор ключевых фраз.

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

Сценарий: Определение синонимии для аббревиатуры

1. Анализ логов (Офлайн): Google видит в логах следующие запросы:
   • User 1: [gm car prices], затем [general motors car prices]
   • User 2: [best gm vehicles]
   • User 3: [general motors vehicles reviews]
2. Генерация Pseudo-queries: Система создает Pseudo-query [: car prices] и [: vehicles].
3. Идентификация кандидатов: В этих контекстах «gm» и «general motors» идентифицируются как кандидаты в синонимы.
4. Валидация: Система видит, что пользователи переключаются между терминами в сессии (User 1), и что результаты поиска для [gm car prices] и [general motors car prices] сильно пересекаются (например, 8 из 10 общих результатов).
5. Оценка: Рассчитывается высокий Evidence Score (например, 0.9).
6. Применение (Онлайн): Когда новый пользователь вводит [gm cars], Google автоматически расширяет запрос до [(gm OR general motors) cars] (Claim 1).
7. Результат для SEO: Страница, оптимизированная под «General Motors», будет ранжироваться по запросам, содержащим только «GM».

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