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

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

Connector (Соединитель)

Слово в запросе (например, "near", "in"), которое используется в Query Patterns для разделения запроса на компоненты {what} и {where}.

Location Portion / {where} (Локационная часть)

Часть разделенного запроса (query split), которая интерпретируется как местоположение.

Possible Stopword / Potential Stopword (Возможное/потенциальное стоп-слово)

Термин из запроса, который присутствует в предопределенном списке слов, которые *могут* быть стоп-словами, но не обязательно являются ими в контексте данного запроса.

Query Patterns (Шаблоны запросов)

Предопределенные правила для интерпретации запроса. Определяют, как запрос может быть разделен. Примеры: {what} near {where} (Connector type), stopwords+{query} (Prefix type).

Query Split (Разделение запроса, Сплит)

Конкретная интерпретация исходного запроса, разделенная на компоненты (например, subject portion и location portion) согласно шаблону.

Scored Search Results (Оцененные результаты поиска)

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

Stopword Removal Rule (Правило удаления стоп-слова)

Правило, определяющее, из какой части query split (только из location portion, только из subject portion или из обеих) следует удалить possible stopword при генерации модифицированных запросов.

Subject Portion / {what} (Предметная часть, Субъект)

Часть разделенного запроса (query split), которая интерпретируется как предмет поиска (бизнес, категория, продукт).

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

Claim 1 (Независимый пункт): Описывает основной метод динамической идентификации стоп-слов.

1. Система получает поисковый запрос.
2. Идентифицирует possible stopword, используя предопределенный список.
3. Определяет один или несколько query splits путем сопоставления запроса с query patterns (правилами интерпретации запроса). Каждый сплит содержит location portion и/или subject portion.
4. Удаляет possible stopword из location portion и/или subject portion как минимум в одном из сплитов на основе stopword removal rule. Это правило определяет, откуда именно удалять слово (только локация, только субъект, или оба).
5. Запрашивает поисковую систему, используя компоненты ({what} и {where}) для *каждого* сгенерированного сплита (включая модифицированные и немодифицированные).
6. Получает scored search results для каждого сплита.
7. Выбирает результаты, возвращенные для одного из сплитов, в качестве ответа на исходный запрос.

Claim 4 (Зависимый от 1, описано в Claim 14): Уточняет критерий выбора: выбираются результаты с наивысшей оценкой (highest score).

Claims 5, 6, 7 (Зависимые от 1, описано в Claim 17): Детализируют логику применения stopword removal rule.

Система определяет, с чем более тесно связано possible stopword — с локацией или с субъектом.

• Если слово теснее связано с субъектом, оно удаляется из location portion.
• Если слово теснее связано с локацией, оно удаляется из subject portion.

Ядро изобретения — это генерация множественных интерпретаций запроса путем *селективного* удаления потенциальных стоп-слов на основе правил, применяемых к разным частям запроса (локация vs. субъект), и последующий выбор наилучшей интерпретации на основе качества полученных результатов поиска.

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

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

QUNDERSTANDING – Понимание Запросов
Это основной этап применения патента. Система работает как механизм интерпретации и переписывания (rewriting) запроса в реальном времени.

1. Интерпретация: Система анализирует входящий запрос, чтобы определить его структуру и выявить неоднозначные термины (possible stopwords).
2. Генерация гипотез (Query Splitting): Используя Query Patterns, система генерирует несколько гипотез о том, как разделить запрос на {what} и {where}.
3. Переписывание (Rewriting): Применяя Stopword Removal Rules, система создает модифицированные версии этих гипотез.
4. Валидация гипотез: Система отправляет все гипотезы (сплиты) на этап ранжирования для оценки их качества.

RANKING – Ранжирование
На этом этапе система выполняет параллельные поиски для всех сгенерированных query splits. Для локальных запросов это часто включает поиск в специализированных индексах (например, геокодер для {where} и индекс локальных бизнесов для {what}). Система оценивает качество результатов (Scored Search Results) для каждой интерпретации.

RERANKING – Переранжирование (или финальный этап QUNDERSTANDING)
После получения оценок от этапа Ranking, система выбирает наилучшую интерпретацию запроса (тот query split, который дал наивысший score). Результаты этого сплита формируют финальную выдачу.

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

• Исходный поисковый запрос.
• Предопределенный список possible stopwords.
• База данных Query Patterns (с правилами разделения и возможными connectors).
• Stopword Removal Rules.

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

• Финальный набор результатов поиска, соответствующий наилучшей интерпретации.

На что влияет

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

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

• Триггеры активации: Алгоритм активируется, когда во входящем запросе обнаруживается слово из списка possible stopwords, И когда запрос потенциально имеет локальный интент (соответствует локальным Query Patterns).
• Условия применения: Применяется в реальном времени при обработке запроса для разрешения неоднозначности интерпретации терминов.

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

Процесс обработки локального запроса (Пример: "visiting nurse new york")

1. Получение запроса: Система получает запрос "visiting nurse new york".
2. Идентификация потенциальных стоп-слов: Система проверяет термины по списку possible stopwords. Слово "visiting" идентифицировано.
3. Генерация Query Splits: Система сопоставляет запрос с Query Patterns и генерирует возможные интерпретации.
   • Split A: {what}: "visiting nurse", {where}: "new york"
   • Split B: {what}: {}, {where}: "visiting nurse new york"
   • Split C: {what}: "visiting nurse new york", {where}: {}
4. Применение Stopword Removal Rules: Система применяет правила для создания модифицированных сплитов. Например, правило гласит: "удалить 'visiting' только из {where} части".
   • Split A (без изменений): {what}: "visiting nurse", {where}: "new york"
   • Split B (модифицирован): {what}: {}, {where}: "nurse new york"
   • Split C (без изменений): {what}: "visiting nurse new york", {where}: {}
5. Выполнение параллельных поисков: Все сгенерированные сплиты (A, B-мод, C) отправляются в поисковую систему.
6. Оценка результатов: Система получает scored search results для каждого сплита.
   • Split A: Высокая оценка (найдены релевантные бизнесы в Нью-Йорке).
   • Split B-мод: Низкая оценка (локация "nurse new york" плохо распознана).
   • Split C: Средняя оценка (найдены результаты, но без локальной привязки).
7. Выбор лучшей интерпретации: Система сравнивает оценки. Split A имеет наивысшую оценку.
8. Результат: Система использует интерпретацию Split A. В данном случае possible stopword "visiting" было сохранено как часть субъекта поиска.

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

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

Патент фокусируется на обработке запроса и не детализирует факторы ранжирования контента. Основные данные, которые он использует:

• Текстовые данные запроса: Термины, введенные пользователем.
• Системные данные:
  • Predefined list of possible stopwords: Список слов, которые могут требовать динамической интерпретации.
  • Query Patterns: Структурированные данные (в описании упоминается protobuffer), определяющие правила интерпретации локальных запросов (например, список connectors типа "near", "in").
  • Stopword Removal Rules: Логика, определяющая селективное удаление стоп-слов из {what} или {where}.

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

• Scores of Search Results: Основная метрика для принятия решения. Система полагается на оценки, возвращаемые основной поисковой системой (Ranking Engine) для каждого query split. Патент не детализирует, как считаются эти оценки, но они используются для сравнения качества разных интерпретаций запроса. Интерпретация с highest score побеждает.
• Confidence value (Значение уверенности): Упоминается в описании патента в контексте Query Patterns. Это предварительная оценка вероятности того, что данный шаблон корректно интерпретирует запрос. Используется для выбора применимых шаблонов.

1. Динамическая интерпретация вместо статических правил: Ключевой вывод — Google не полагается на статические списки стоп-слов для локальных запросов. Вместо этого система активно тестирует несколько гипотез интерпретации запроса в реальном времени.
2. Качество результатов определяет интерпретацию запроса: Решение о том, является ли слово стоп-словом или значимым термином, принимается на основе качества (score) результатов поиска, которые генерирует каждая интерпретация. Это подход "validation-by-ranking".
3. Фундаментальное разделение на {what} и {where}: Для локального поиска критически важно правильное разделение запроса на субъект и местоположение. Система использует Query Patterns и Stopword Removal Rules для разрешения неоднозначностей в этом разделении.
4. Селективное удаление стоп-слов: Stopword Removal Rules применяются избирательно. Слово может быть удалено из локационной части, но сохранено в предметной, и наоборот. Это позволяет сохранить значимые термины в названиях бизнесов, даже если они похожи на стоп-слова.
5. Разрешение неоднозначности: Механизм напрямую направлен на повышение точности понимания неоднозначных локальных запросов, где термины могут быть интерпретированы по-разному.

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

• Обеспечение однозначности локальных сущностей: Для локального SEO критически важно, чтобы название бизнеса и его категория были четко определены и недвусмысленны. Если название содержит общие слова (глаголы, предлоги), необходимо убедиться, что Google корректно распознает его как единую сущность (субъект, {what}). Это достигается за счет консистентности NAP (Name, Address, Phone) в сети и четкого указания категорий в Google Business Profile.
• Создание контента под разные шаблоны запросов: Понимая, что Google использует Query Patterns (например, {what} near {where}), следует оптимизировать контент под эти структуры. Используйте четкие указания на услуги и локации в текстах и заголовках (например, "Visiting Nurse Services in New York").
• Анализ интерпретации запросов: При исследовании ключевых слов обращайте внимание на то, как Google интерпретирует запросы, содержащие потенциальные стоп-слова. Если Google часто ошибается в определении вашего бизнеса как субъекта, это сигнал к усилению сигналов авторитетности и релевантности для этой сущности.

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

• Использование неоднозначных названий брендов без поддержки: Создание бренда, чье название легко спутать с общим действием или локацией (например, "Go To Plumbing"), создает риск, что часть названия будет динамически удалена как стоп-слово, если сущность недостаточно авторитетна.
• Keyword Stuffing, затрудняющий парсинг: Перенасыщение текстов ключевыми словами и локациями в неестественных конструкциях может привести к генерации множества низкокачественных query splits, что ухудшит общее ранжирование.
• Игнорирование локального контекста: Оптимизация только под название услуги без учета локационного контекста может привести к тому, что система не сможет корректно сформировать query split с {what} и {where}.

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

Патент подтверждает, что понимание запросов (Query Understanding) является сложным, итеративным процессом. Для локального поиска Google готов выполнять несколько поисков параллельно, чтобы убедиться в правильности интерпретации интента. Это подчеркивает стратегическую важность построения сильных, четко определенных локальных сущностей. Если ваша сущность ({what}) сильна и однозначна, система предпочтет ту интерпретацию запроса, которая включает ваш бренд, даже если он содержит неоднозначные слова.

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

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

Бизнес: "Visiting Angels Home Care" (Услуги по уходу на дому). Слово "Visiting" есть в списке possible stopwords.

1. Задача: Убедиться, что по запросу "visiting angels san francisco" система не интерпретирует "visiting" как стоп-слово.
2. Действия SEO-специалиста:
   • Обеспечить максимальную консистентность упоминаний (citations) названия "Visiting Angels Home Care" на авторитетных локальных ресурсах и в каталогах.
   • В Google Business Profile использовать основную категорию, соответствующую услуге (Home Health Care Service).
   • На сайте использовать структурированный контент, четко связывающий полное название бренда с локацией (например, в Title, H1, микроразметке LocalBusiness).
3. Как работает система Google (согласно патенту):
   • Google генерирует сплиты. Может быть применено правило удалить "visiting" из {what}.
     Split 1: {what}: "Visiting Angels", {where}: "San Francisco"
     Split 2 (модифицированный): {what}: "Angels", {where}: "San Francisco"
   • Система выполняет оба поиска.
4. Ожидаемый результат: Благодаря сильным сигналам сущности "Visiting Angels Home Care", Split 1 вернет высококачественные результаты (профиль компании, официальный сайт). Split 2 вернет менее релевантные результаты. Система выберет Split 1, корректно сохранив слово "Visiting" как часть бренда.