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

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

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$

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