Как Google переписывает неявные запросы, определяя сущность по местоположению пользователя и истории поиска

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

Approximate Location (Приблизительное местоположение)

Географическое положение пользовательского устройства в момент отправки запроса, определяемое с помощью GPS, WiFi, сотовых сетей и т.д.

Entity (Сущность)

Объект (человек, место, вещь), который может быть однозначно идентифицирован. В контексте патента — чаще всего организации или точки интереса (POI) с физическим адресом.

Entity Query Pattern (Паттерн запросов сущности)

Шаблон, представляющий один или несколько исторических запросов, которые явно ссылались на конкретную сущность. Генерируется из журналов поиска (Search Log). Например, для сущности 'Alcatraz' паттерном может быть [famous inmates *] (знаменитые заключенные *).

Explicit Reference (Явная ссылка)

Запрос, который содержит точное упоминание названия сущности (например, [рейтинг Awesome Pizza]).

Implicit Reference (Неявная ссылка)

Запрос, который подразумевает сущность, но не называет ее (например, [какой здесь рейтинг] или [что это за памятник]).

Query Interpretation System (Система интерпретации запросов)

Компонент поисковой системы, отвечающий за анализ и переписывание запросов на основе контекста (в данном случае, местоположения).

Query Pattern (Паттерн запроса)

Шаблон исходного запроса пользователя, часто получаемый путем удаления стоп-слов и местоимений. Например, из [can you please show me ratings] получается паттерн [ratings].

Revised Query (Пересмотренный запрос)

Новая версия запроса, созданная системой, в которой неявная ссылка заменена на явное упоминание идентифицированной сущности.

Threshold Distance (Пороговое расстояние)

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

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

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

1. Система получает запрос от пользовательского устройства.
2. Определяется, что запрос содержит неявную ссылку (implicitly references) на какую-либо сущность.
3. В ответ на это:
   1. Получается приблизительное местоположение устройства.
   2. Получается набор сущностей, расположенных рядом с этим местоположением.
   3. Из этого набора выбирается одна сущность на основе паттернов запросов сущности (entity query patterns), связанных с ней.
   4. Предоставляется пересмотренный запрос (revised query), который явно ссылается (explicitly referencing) на выбранную сущность.

Ядро изобретения — использование Entity Query Patterns для связи неявного запроса с конкретной физической локацией.

Claim 2 (Зависимый от 1): Детализирует процесс выбора сущности (Шаг 3c).

Выбор включает получение набора Entity Query Patterns для сущности и определение того, что один из этих паттернов совпадает с паттерном исходного запроса пользователя (Query Pattern).

Это подтверждает механизм сопоставления: Интент пользователя (выраженный в его запросе) сравнивается с исторически подтвержденными интентами, связанными с ближайшими объектами.

Claim 3 и 4 (Зависимые от 1): Определяют происхождение Entity Query Patterns.

Паттерны основаны на исторических запросах, которые явно ссылались на эту сущность (Claim 3) и берутся из журнала поиска (search log) (Claim 4).

Система обучается на реальном поведении пользователей, чтобы понять, что люди обычно спрашивают о конкретном месте.

Claim 5 и 6 (Зависимые): Описывают механизм разрешения неоднозначности (Disambiguation).

Если набор кандидатов содержит несколько сущностей, которые соответствуют запросу (Claim 5), система сравнивает атрибуты (attributes) этих сущностей и выбирает одну на основе этих атрибутов (Claim 6).

В описании патента в качестве примеров атрибутов приводятся review rating (рейтинг отзывов) и popularity (популярность). Это критически важный момент для SEO: при прочих равных предпочтение отдается более популярной или высокорейтинговой сущности.

Claim 7 (Зависимый от 1): Уточняет критерий включения в набор кандидатов.

Сущность включается в набор, если ее местоположение находится в пределах порогового расстояния (threshold distance) от приблизительного местоположения пользователя.

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

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

INDEXING – Индексирование и извлечение признаков

• Индексация сущностей: Система должна хранить структурированные данные о сущностях, включая их точное местоположение, тип (ресторан, отель и т.д.) и атрибуты (review rating, popularity).
• Генерация паттернов (Офлайн): Анализ исторических данных (Historical Data / Search Log) для выявления запросов, явно ссылающихся на сущности. Эти запросы агрегируются и преобразуются в Entity Query Patterns, которые также индексируются и связываются с соответствующими сущностями.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения патента. Query Interpretation System работает здесь в реальном времени:

1. Классификация запроса: Определение, является ли запрос неявным (Implicit Reference).
2. Контекстуализация: Использование данных о местоположении пользователя (Approximate Location).
3. Поиск кандидатов: Быстрый поиск ближайших сущностей.
4. Сопоставление и выбор: Сравнение Query Pattern с Entity Query Patterns кандидатов и разрешение неоднозначностей.
5. Переписывание запроса: Генерация Revised Query.

RANKING – Ранжирование
Поисковая система (Search System) выполняет ранжирование, используя уже Revised Query (явный запрос), что позволяет стандартным алгоритмам работать более точно.

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

• Исходный запрос пользователя.
• Данные о местоположении устройства (координаты, точность, свежесть).
• Индекс сущностей (местоположение, атрибуты).
• Индекс Entity Query Patterns.

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

• Revised Query с явным указанием сущности (например, [room rates Great Hotel] вместо [show me room rates]).

На что влияет

• Конкретные типы контента: Страницы локальных бизнесов (рестораны, отели, магазины), достопримечательностей, парков и других физических объектов (POI).
• Специфические запросы: Информационные запросы о ближайших объектах (часы работы, меню, цены, отзывы, наличие услуг). Особенно сильно влияет на запросы, вводимые с мобильных устройств и через голосовой поиск.
• Конкретные ниши или тематики: Локальный бизнес (Local SEO), туризм, HoReCa.

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

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

• Триггер 1 (Интент): Система определила, что запрос содержит неявную ссылку на сущность. Это может определяться по отсутствию названия сущности в запросе, использованию местоимений или совпадению с предопределенными неявными паттернами (например, [* ratings]).
• Триггер 2 (Контекст): Доступны данные о местоположении пользователя. В патенте упоминается, что могут использоваться пороги точности (confidence score) и свежести (freshness) данных о местоположении. Если данные недостаточно точны или устарели, интерпретация может не производиться.
• Условие выполнения: В радиусе threshold distance найдена хотя бы одна сущность, чей Entity Query Pattern совпадает с Query Pattern пользователя.

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

Процесс А: Обработка запроса в реальном времени

1. Получение запроса и локации: Система получает запрос и данные о приблизительном местоположении пользователя.
2. Анализ запроса на неявность: Определяется, ссылается ли запрос неявно на какую-либо сущность.
   1. Если НЕТ (запрос явный): Выполняется стандартный поиск.
   2. Если ДА: Переход к шагу 3.
3. Валидация локации (Опционально): Проверка confidence score и freshness местоположения на соответствие порогам.
4. Получение набора сущностей: Идентификация всех сущностей в пределах threshold distance от пользователя.
5. Итеративное сопоставление паттернов: Для каждой сущности в наборе:
   1. Получение Entity Query Patterns, связанных с этой сущностью.
   2. Сравнение Query Pattern пользователя с Entity Query Patterns.
   3. Если есть совпадение, сущность добавляется в подмножество кандидатов.
6. Выбор сущности (Disambiguation):
   1. Если в подмножестве 0 сущностей: Выполняется стандартный поиск по исходному запросу (или применяется другая логика, не описанная в патенте).
   2. Если в подмножестве 1 сущность: Эта сущность выбирается.
   3. Если в подмножестве несколько сущностей: Активируется механизм разрешения неоднозначности. Сравниваются атрибуты сущностей (например, review rating, popularity). Выбирается сущность с наилучшими показателями атрибутов.
7. Переписывание запроса: Генерируется Revised Query, явно включающий выбранную сущность.
8. Выполнение поиска: Поисковая система предоставляет результаты на основе Revised Query.

Процесс Б: Офлайн-генерация Entity Query Patterns

1. Анализ журналов поиска: Система анализирует Search Log для идентификации запросов, явно ссылающихся на сущности.
2. Извлечение и нормализация: Из запросов удаляются названия сущностей и формируются паттерны (например, [famous inmates of alcatraz] -> [famous inmates *]).
3. Фильтрация по частотности (Опционально): Паттерн сохраняется, только если соответствующий запрос встречался выше порогового числа раз.
4. Индексация: Entity Query Patterns сохраняются и связываются с соответствующими сущностями в индексе.

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

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

• Поведенческие факторы (Historical Data): Журналы поиска (Search Log) являются критически важным источником данных. Они используются для генерации Entity Query Patterns, определяя, какие запросы пользователи исторически связывали с конкретными сущностями.
• Географические факторы: Approximate Location пользователя (полученное через GPS, WiFi, Cellular) и точное местоположение индексированных сущностей.
• Пользовательские факторы: Устройство пользователя (для получения локации). Также упоминается возможность использования истории выбора сущностей (previously selected entities) для персонализации при разрешении неоднозначностей.
• Факторы сущности (Entity Attributes): Данные, хранящиеся для каждой сущности. В патенте явно упоминаются review rating (рейтинг отзывов) и popularity (популярность). Они используются для разрешения неоднозначностей.

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

• Threshold Distance (Пороговое расстояние): Заданный радиус для определения близости сущности к пользователю.
• Совпадение паттернов (Pattern Matching): Бинарная метрика (совпадает/не совпадает) между Query Pattern пользователя и Entity Query Patterns сущности.
• Confidence Score (Оценка уверенности) (Опционально): Метрика точности определения местоположения пользователя. Используется как порог для активации системы.
• Freshness (Свежесть) (Опционально): Временная метка данных о местоположении. Используется как порог (разница между текущим временем и временем определения локации).
• Частота запросов (Query Frequency) (Опционально): Количество раз, когда запрос был задан в Search Log. Используется как порог для генерации Entity Query Patterns.
• Значения атрибутов (Attribute Values): Числовые значения атрибутов сущности (например, средний рейтинг, показатель популярности). Используются для ранжирования кандидатов при неоднозначности.

1. Местоположение как ключевой контекст для понимания запроса: Патент демонстрирует механизм, в котором физическое местоположение пользователя используется как основной контекст для интерпретации неявных запросов. Точность геолокационных данных сущности критически важна.
2. Историческое поведение пользователей определяет интент (Entity Query Patterns): Система не пытается семантически понять, подходит ли запрос к сущности. Вместо этого она полагается на агрегированные исторические данные (Search Log), чтобы определить, какие запросы статистически связаны с данной сущностью. Это подчеркивает важность понимания того, что именно пользователи ищут в связи с конкретным объектом.
3. Атрибуты качества и популярности как факторы ранжирования: При возникновении неоднозначности (например, пользователь стоит между двумя отелями и спрашивает [цены на номера]), система использует атрибуты сущности для выбора. Явно упомянуты review rating и popularity. Это прямые факторы ранжирования в локальном поиске.
4. Переписывание запроса для повышения точности: Преобразование неявного запроса в явный (Revised Query) позволяет использовать стандартные, хорошо отлаженные алгоритмы ранжирования для предоставления точных результатов.
5. Ориентация на мобильный и голосовой поиск: Механизм идеально подходит для сценариев мобильного использования и голосового ввода, где пользователи склонны задавать короткие или контекстно-зависимые запросы.

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

• Обеспечение точности геолокационных данных: Для локального бизнеса критически важно поддерживать абсолютно точные и консистентные данные о местоположении во всех системах (Google Business Profile, сайт, каталоги, микроразметка Schema.org/LocalBusiness). Это гарантирует попадание сущности в набор кандидатов (Шаг 4 алгоритма).
• Улучшение атрибутов сущности (Рейтинг и Популярность): Поскольку review rating и popularity используются для разрешения неоднозначностей, необходимо активно работать над повышением рейтинга отзывов и общей известности/популярности организации (как онлайн, так и офлайн). Это повышает вероятность выбора вашей сущности при наличии конкурентов поблизости.
• Анализ и оптимизация под Entity Query Patterns: Необходимо понимать, какие запросы пользователи исторически связывают с вашей сущностью или типом бизнеса. Анализируйте данные Search Console и логи сайта, чтобы выявить популярные запросы (например, [меню завтраков *], [стоимость парковки *]). Убедитесь, что ваш контент (на сайте и в GBP) оптимизирован для этих паттернов, чтобы система могла легко найти релевантные ответы после переписывания запроса.
• Развитие сущности (Entity Building): Укрепляйте представление вашего бизнеса как сущности в системах Google. Это включает полное заполнение GBP, использование structured data, получение упоминаний и ссылок, которые помогают системе лучше понять тип вашего бизнеса и его атрибуты.

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

• Предоставление неточных или противоречивых данных о местоположении: Это может привести к исключению сущности из набора кандидатов, даже если пользователь находится рядом.
• Игнорирование отзывов и репутации: Низкий review rating приведет к проигрышу конкурентам в ситуациях неоднозначности, когда пользователь находится рядом с несколькими релевантными объектами.
• Создание контента без учета локального интента: Фокус на общих запросах без учета специфических потребностей пользователей, находящихся поблизости (например, отсутствие информации о парковке, специальных предложениях дня), снижает полезность контента для запросов, обработанных этим алгоритмом.

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

Патент подтверждает стратегическую важность контекста в современном поиске, особенно в Local SEO. Он показывает, что релевантность определяется не только семантикой запроса, но и физическим окружением пользователя. Долгосрочная стратегия должна включать построение сильной, хорошо известной сущности с высокими показателями качества (рейтинги) и точной привязкой к местности. Понимание Entity Query Patterns становится ключевым элементом контент-стратегии для локального бизнеса.

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

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

1. Ситуация: Пользователь стоит рядом с рестораном "Awesome Pizza" и отелем "Great Hotel".
2. Запрос пользователя: [has this place won any food awards] (это место получало какие-нибудь кулинарные награды).
3. Анализ системы:
   • Оба объекта рядом.
   • Паттерн запроса: [* food awards].
   • Система проверяет исторические данные (Entity Query Patterns). Она видит, что пользователи часто ищут награды для "Awesome Pizza", но редко для "Great Hotel".
4. Действие: Система сопоставляет паттерн с "Awesome Pizza".
5. Результат: Запрос переписывается в [awesome pizza food awards].
6. SEO-действие: Ресторану необходимо иметь раздел на сайте или пост в GBP о своих наградах, чтобы быть релевантным итоговому переписанному запросу.

Сценарий 2: Разрешение неоднозначности с помощью рейтинга

1. Ситуация: Пользователь стоит между двумя отелями: "Great Hotel" (Рейтинг 4.8) и "Not-so-Great Hotel" (Рейтинг 3.1).
2. Запрос пользователя: [show me room rates] (покажите цены на номера).
3. Анализ системы:
   • Оба объекта рядом.
   • Паттерн запроса: [room rates].
   • Оба отеля соответствуют этому паттерну (он характерен для отелей). Возникает неоднозначность.
4. Действие: Система сравнивает атрибуты (review rating). "Great Hotel" имеет более высокий рейтинг.
5. Результат: Запрос переписывается в [room rates Great Hotel].
6. SEO-действие: Управление репутацией и стимулирование положительных отзывов напрямую влияет на вероятность выбора вашей организации в таких сценариях.