Как Google использует контекст поисковой сессии для исправления ошибок и уточнения запросов пользователя

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

Contextual Query Processor (Процессор контекстуальных запросов)

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

Potentially Inaccurate Search Token (Потенциально неточный поисковый токен)

Токен (слово или фраза) в текущем запросе, который идентифицирован как возможно ошибочный. Это может быть опечатка (misspelled token), слово, неверно использованное в данном контексте (misused token), или просто новый токен, введенный пользователем в ходе сессии.

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

Хранилище исторических поисковых запросов и сессий, используемое для анализа поведения пользователей и выявления связанных терминов.

Related Tokens (Связанные токены)

Группа токенов, которые статистически связаны с токенами из предыдущих запросов пользователя в текущей сессии. Определяются на основе анализа Query Log.

Replacement Token (Токен замены)

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

Search Session (Поисковая сессия)

Последовательность запросов от одного пользователя, объединенная по времени, намерению или явному указанию (логин/логаут).

Search Token (Поисковый токен)

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

Subject Weights (Веса тематик)

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

Token Cluster (Кластер токенов)

Группа связанных токенов, идентифицированных из Query Log, которые часто встречаются вместе или статистически связаны (например, "stemmed" и "roses").

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

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

1. Система получает текущий запрос в рамках текущей поисковой сессии.
2. Идентифицируется набор предыдущих поисковых токенов из предыдущих запросов этой сессии.
3. Текущие токены сравниваются с предыдущими.
4. Идентифицируется Potentially Inaccurate Search Token. В этом пункте он определяется как токен, который *не* входит в набор предыдущих токенов (т.е. новый термин, введенный пользователем).
5. Определяется возможный Replacement Token. Здесь он определяется как токен, которым ранее (исторически) заменялся неточный токен с минимальной заданной частотой.
6. Идентифицируются Related Tokens из лога запросов на основе предыдущих запросов сессии.
7. Проверяется, входит ли возможный Replacement Token в группу Related Tokens.
8. Если ДА (токен замены соответствует контексту), генерируется модифицированный поисковый запрос.

Claim 2 и 3 (Зависимые): Уточняют, что Potentially Inaccurate Search Token может быть идентифицирован как токен с опечаткой (misspelled), а Replacement Token — как его исправленная версия.

Claim 7 (Независимый пункт): Описывает альтернативный метод, фокусирующийся на валидации нового термина по контексту.

1. Получение текущего запроса и идентификация предыдущих токенов сессии (аналогично Claim 1).
2. Идентификация Potentially Inaccurate Search Token как нового токена, не встречавшегося ранее в сессии.
3. Идентификация Related Tokens на основе предыдущих запросов сессии.
4. Сравнение неточного (нового) токена со связанными токенами.
5. Определение: входит ли неточный токен в число связанных токенов?
6. Если НЕТ (новый токен не соответствует контексту, установленному связанными терминами), система идентифицирует Replacement Token *из числа* Related Tokens (основываясь на исторических частотах замены).
7. Неточный токен в текущем запросе заменяется на Replacement Token.

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

Изобретение применяется на ранних этапах обработки запроса.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения патента. Система (Contextual Query Processor) работает как модуль ревизии запроса. Она анализирует входящий запрос и историю сессии, чтобы определить, нуждается ли запрос в контекстуальном исправлении или уточнении, прежде чем он будет передан основным системам ранжирования.

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит предварительная обработка данных, необходимых для работы системы (офлайн-процессы). Анализируются исторические Query Logs для построения Token Clusters, определения Related Tokens, расчета Subject Weights и выявления частоты исторических замен токенов.

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

• Текущий поисковый запрос (Current Search Query).
• История поисковой сессии (Previous Search Queries/Tokens).
• База данных замен (Replacement Token Data).
• Исторические логи запросов (Query Log).

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

• Модифицированный поисковый запрос (Modified Search Query), если была произведена контекстуальная замена.
• Исходный поисковый запрос, если замена не требуется или не найдена контекстуально релевантная замена.

На что влияет

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

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

Алгоритм применяется при выполнении следующих условий:

• Триггеры активации:
  • Обнаружена опечатка в токене текущего запроса.
  • Обнаружено слово, которое может быть неверно употреблено в контексте сессии (например, имеет низкий Subject Weight для тематики сессии).
  • Пользователь ввел новый токен в запрос, уточняя предыдущий запрос в той же сессии (сценарий, описанный в Claims 1 и 7).
• Условия применения: Система должна быть способна определить контекст сессии (найти достаточно Related Tokens) и найти подходящий Replacement Token, который соответствует этому контексту.

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

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

Процесс А: Контекстуальное исправление опечаток (на основе FIG. 5)

1. Получение запроса: Система получает текущий поисковый запрос в рамках сессии.
2. Идентификация неточности: Анализируется запрос на наличие потенциально неточных токенов (например, опечаток).
3. Генерация кандидатов: Для неточного токена идентифицируются возможные токены замены (Replacement Tokens) из базы данных замен.
4. Определение контекста: Идентифицируется группа связанных токенов (Related Tokens) из лога запросов на основе предыдущих запросов в этой сессии.
5. Валидация кандидатов: Система проверяет, присутствует ли какой-либо из Replacement Tokens в группе Related Tokens.
6. Модификация запроса: Если ДА, текущий запрос модифицируется путем замены неточного токена на контекстуально релевантный Replacement Token.
7. Обработка результатов: Система предоставляет результаты поиска по модифицированному (или исходному, если замена не произошла) запросу.

Процесс Б: Валидация и замена контекстуально неверных токенов (на основе FIG. 6 и Claims 1/7)

1. Получение запроса: Система получает текущий поисковый запрос.
2. Определение контекста: Идентифицируется группа Related Tokens на основе предыдущих запросов сессии.
3. Идентификация нового токена: В текущем запросе идентифицируется токен, который не присутствовал в предыдущих запросах сессии (Potentially Inaccurate Search Token).
4. Проверка контекста: Система определяет, существует ли этот новый токен в группе Related Tokens.
   • Если ДА: Токен считается контекстуально верным. Система предоставляет результаты по исходному запросу.
   • Если НЕТ: Токен считается контекстуально неверным (Misused Token). Переход к шагу 5.
5. Идентификация замены: Система ищет потенциальный Replacement Token. Этот токен должен быть членом группы Related Tokens и быть похожим на неточный токен (например, с использованием вектора расстояния или исторических данных о заменах).
6. Генерация модифицированного запроса: Создается новый запрос, включающий Replacement Token вместо исходного неточного токена.

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

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

Патент фокусируется на использовании данных о поведении пользователей и контексте сессии.

• Поведенческие факторы: Критически важные данные. Используются исторические Query Logs для определения того, как пользователи ищут информацию, какие термины используются вместе (Token Clusters), и какие ошибки пользователи исправляют чаще всего (исторические частоты замен).
• Пользовательские факторы: История запросов текущего пользователя в рамках активной Search Session. Эти данные используются для определения непосредственного контекста.

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

• Token Clustering (Кластеризация токенов): Используются методы кластеризации (например, k-means) или пороговые значения совместной встречаемости. Например, токен включается в кластер, если он встречается в более чем 50% запросов, содержащих другие токены этого кластера.
• Distance Vector (Вектор расстояния): Упоминается как метод для определения схожести между потенциально неточным токеном и связанными токенами, чтобы выбрать наилучшую замену (например, "flour" ближе к "flower", чем к "rose").
• Minimum Specified Rate (Минимальная заданная частота): Историческая частота, с которой один токен заменялся другим в логах запросов. Используется для валидации кандидатов на замену (упоминается в Claims).
• Subject Weights (Веса тематик): Предварительно рассчитанные веса, ассоциирующие токены с тематиками. Суммирование этих весов для токенов сессии позволяет определить тематический контекст (например, Садоводство) и оценить релевантность нового токена этому контексту.

1. Приоритет контекста сессии над словарными исправлениями: Google не просто исправляет опечатки на наиболее частотный вариант. Система стремится понять намерение пользователя в рамках текущей сессии и выбирает исправление, которое соответствует этому намерению, даже если оно менее частотно в целом.
2. Запросы не обрабатываются изолированно: Патент подтверждает, что Google анализирует поисковую сессию (Search Journey) как единое целое. Предыдущие запросы напрямую влияют на интерпретацию текущего запроса.
3. Важность исторических данных и кластеризации: Система полагается на анализ огромных массивов исторических данных (Query Logs) для выявления Token Clusters. Понимание того, какие слова естественно сочетаются друг с другом в языке и поведении пользователей, является ключом к определению контекста.
4. Механизм борьбы с контекстуальными ошибками (Misused Tokens): Система активно идентифицирует слова, которые, хотя и написаны правильно, не вписываются в тематический контекст сессии (например, по Subject Weights или отсутствию в Related Tokens), и пытается заменить их на более подходящие.
5. Уточнение запроса как источник ошибок: Патент уделяет особое внимание ситуациям, когда пользователь уточняет запрос, вводя новые термины (Claims 1 и 7). Любой новый термин рассматривается как потенциально неточный и проверяется на соответствие контексту сессии.

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

• Построение тематического авторитета (Topical Authority): Создавайте контент, который полностью охватывает тему и включает связанные концепции и термины (Related Tokens). Это повышает вероятность того, что ваш контент будет релевантен для запросов внутри Token Cluster, даже если запрос пользователя был модифицирован системой.
• Анализ пути пользователя (Search Journey): Понимайте, как пользователи исследуют вашу нишу. Какие запросы они задают сначала, и как они их уточняют? Оптимизируйте контент так, чтобы он отвечал на последовательные интенты в рамках одной сессии.
• Использование естественного языка и синонимов: Включайте в текст естественные сочетания слов и синонимы, которые Google может идентифицировать как Related Tokens. Это помогает системе правильно интерпретировать контекст вашего контента и сопоставлять его с контекстом сессии пользователя.
• Оптимизация под ясность и однозначность: Если ваша тематика включает термины, которые легко спутать (омонимы или близкие по написанию слова с разным значением), убедитесь, что контекст страницы четко поддерживает нужное значение.

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

• Оптимизация под изолированные ключевые слова: Фокус на отдельных ключевых словах без учета их связи с более широкой темой и контекстом поисковой сессии становится менее эффективным. Система может изменить запрос пользователя, если посчитает его контекстуально неверным.
• Игнорирование связанных сущностей и терминов: Создание контента, который не покрывает Related Tokens в рамках Token Cluster, снижает его видимость для пользователей, находящихся в процессе изучения темы.
• Использование неестественных сочетаний слов (Keyword Stuffing): Попытки манипулировать релевантностью путем неестественного включения ключевых слов могут привести к тому, что система не сможет правильно соотнести контент с естественными Token Clusters.

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

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

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

Сценарий 1: Контекстуальное исправление опечатки в ходе сессии

1. Предыдущий запрос пользователя: "yellow gardenia" (Желтая гардения).
2. Контекст сессии: Система определяет контекст как "Садоводство" или "Цветы". Related Tokens включают "plant", "leaves", "flower".
3. Текущий запрос пользователя: "long stemmed fluer" (длинностебельный [опечатка]).
4. Анализ: Система идентифицирует "fluer" как опечатку (Potentially Inaccurate Token). Кандидаты на замену: "flier", "flower", "flour", "fleur".
5. Контекстуальная ревизия: Система сравнивает кандидатов с Related Tokens. Кандидат "flower" присутствует в списке Related Tokens.
6. Результат: Система модифицирует запрос на "long stemmed flower" и показывает результаты по нему, так как это соответствует контексту сессии, начатой с поиска гардений.

Сценарий 2: Исправление контекстуально неверного слова (Misused Token)

1. Предыдущие запросы пользователя: "long stemmed bulbs", затем "long stemmed roses".
2. Контекст сессии: Садоводство. Subject Weights высоки для этой темы.
3. Текущий запрос пользователя: "long stemmed flour" (длинностебельная мука).
4. Анализ: Система видит, что "flour" – это новый токен в сессии. Она проверяет его соответствие контексту. "Flour" (мука) имеет низкий Subject Weight для садоводства и не входит в Related Tokens для "bulbs" и "roses".
5. Контекстуальная ревизия: Система ищет замену среди Related Tokens, которая похожа на "flour" (используя Distance Vector). Она находит "flower".
6. Результат: Система модифицирует запрос на "long stemmed flower", предполагая, что пользователь имел в виду цветок, а не муку, продолжая тему садоводства.