Как Google использует местоположение пользователя для понимания и переписывания неявных запросов о ближайших объектах

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

Entity (Объект, Сущность)

Именованное место с конкретным названием и местоположением (например, ресторан, отель, магазин, достопримечательность).

Entity Type (Тип объекта)

Категория, к которой принадлежит объект (например, [ресторан], [отель]). Аналог категорий в Google Business Profile.

Implicit Query (Неявный запрос)

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

Index (Индекс)

База данных, которая связывает объекты с их типами, а также типы объектов с N-граммами (поисковыми терминами), которые коррелируют с этими типами. Индекс строится на основе анализа поисковых логов.

N-gram (N-грамма)

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

Popularity (Популярность)

Атрибут объекта, явно указанный в Claim 1 для разрешения неоднозначности. Объект с наивысшей популярностью выбирается среди кандидатов.

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

Компонент поисковой системы, отвечающий за анализ и переписывание неявных запросов на основе контекста.

Review Rating (Рейтинг отзывов)

Атрибут объекта, упомянутый в описании патента как возможный фактор для разрешения неоднозначности.

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

Новый запрос, созданный путем добавления явного названия объекта к исходному неявному запросу.

Sufficiently Fresh (Достаточно свежий)

Условие, применяемое к данным о местоположении. Система активируется, только если данные о локации пользователя получены недавно.

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

Радиус вокруг пользователя, в пределах которого система ищет потенциальные объекты.

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

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

1. Система получает запрос, состоящий из терминов (N-грамм).
2. Определяется, что запрос является неявным (implicitly about some entity), т.е. в нем отсутствует явное упоминание объекта.
3. Если запрос неявный:
   1. Получается приблизительное местоположение устройства пользователя.
   2. Получается набор ближайших объектов (set of entities), находящихся в пределах порогового расстояния.
   3. Определяется, что запрос неявно относится к конкретному объекту из этого набора.
   4. Генерируется пересмотренный запрос (revised query), включающий название этого объекта.

Пункт 1 также детализирует критически важный механизм определения того, к какому именно объекту относится запрос (шаг 3c):

A. Сопоставление типа и запроса:

1. Для каждого ближайшего объекта используется index, который связывает типы объектов с коррелирующими N-граммами (причем эти N-граммы сами по себе не должны явно указывать на конкретные объекты).
2. Определяется тип объекта (entity type).
3. Проверяется, коррелируют ли N-граммы из запроса с этим типом объекта согласно индексу.

B. Формирование подмножества:

1. Объекты, чей тип коррелирует с запросом, добавляются в подмножество (sub-set of entities).

C. Разрешение неоднозначности (Disambiguation):

1. Если в подмножестве более одного объекта:
   1. Определяется общий атрибут для всех объектов в подмножестве. В Claim 1 конкретно и явно упоминается popularity (популярность).
   2. Выбирается объект с наивысшей популярностью (highest popularity) на основе этого атрибута.

Claim 3, 5, 7 (Зависимые): Уточняют, что весь процесс выполняется только при условии, что данные о местоположении достаточно свежие (sufficiently fresh).

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе система собирает и структурирует данные об объектах (entities), вероятно в Knowledge Graph: их точное местоположение, название, тип (категорию), а также вычисляет атрибуты popularity и review rating. Также офлайн происходит анализ поисковых логов для построения index, связывающего N-граммы и типы объектов.

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

1. Анализ запроса: Система определяет, является ли запрос неявным.
2. Контекстуализация: Если запрос неявный, система использует местоположение для поиска ближайших объектов (set of entities), проверяя свежесть данных.
3. Интерпретация и выбор: Система сопоставляет интент запроса с типами ближайших объектов, используя index, и выбирает наиболее подходящий объект, используя popularity для разрешения неоднозначности.
4. Переписывание: Генерируется revised query.

RANKING – Ранжирование
Система ранжирования получает на вход уже переписанный, явный запрос (revised query) и обрабатывает его стандартным образом.

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

• Исходный неявный запрос пользователя.
• Данные о местоположении пользователя (координаты, метка времени, оценка точности).
• Данные из индекса сущностей (Knowledge Graph): ближайшие сущности, их типы и атрибуты (популярность, рейтинг).
• Index корреляций (N-грамма -> Тип объекта).

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

• Revised query с явным упоминанием сущности, передаваемый на этап ранжирования.

На что влияет

• Конкретные типы контента и ниши: Критически влияет на локальный бизнес (Local SEO) – рестораны, отели, ритейл, услуги, достопримечательности.
• Специфические запросы: Влияет на неявные информационные и транзакционные запросы, связанные с местоположением (например, [часы работы], [отзывы], [меню], [купить кофе]).
• Платформы: Наибольшее влияние оказывается на мобильный и голосовой поиск, где контекст местоположения часто доступен, а пользователи склонны задавать короткие неявные запросы.

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

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

• Триггер активации 1: Запрос идентифицирован как неявный (implicit query) – не содержит явного названия объекта.
• Триггер активации 2: Доступны достаточно точные (упоминается confidence score) и свежие данные о местоположении пользователя (sufficiently fresh).
• Условие применения: В радиусе от пользователя найден хотя бы один объект, чей тип (entity type) соответствует интенту запроса согласно index.

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

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

1. Получение данных: Система получает запрос и данные о местоположении устройства.
2. Определение типа запроса: Анализируется запрос. Является ли он неявным (implicit)?
   • Если НЕТ (запрос явный): Выполнить стандартный поиск по запросу.
   • Если ДА: Перейти к шагу 3.
3. Валидация местоположения: Проверяется точность (confidence score) и свежесть (freshness) данных о местоположении.
   • Если данные невалидны: Выполнить стандартный поиск по запросу.
   • Если данные валидны: Перейти к шагу 4.
4. Идентификация кандидатов: Определяется набор объектов (Set of Entities) в пределах порогового расстояния от пользователя.
5. Сопоставление интента (Фильтрация по типу): Для каждого объекта в наборе:
   1. Определяется его тип (Entity Type).
   2. Проверяется по Index, коррелируют ли N-граммы запроса с этим типом.
   3. Если ДА, объект добавляется в подмножество (Sub-set of Entities).
6. Разрешение неоднозначности (Выбор объекта): Анализируется Sub-set of Entities.
   • Если пусто: Выполнить стандартный поиск.
   • Если один объект: Выбрать этот объект.
   • Если несколько объектов: Активировать логику выбора: определить общий атрибут (согласно Claim 1 – popularity) и выбрать объект с наивысшим значением этого атрибута.
7. Переписывание запроса: Генерируется Revised Query путем добавления названия выбранного объекта к исходному запросу.
8. Выполнение поиска: Поиск выполняется по Revised Query, результаты предоставляются пользователю.

Процесс Б: Офлайн-генерация Индекса

1. Анализ логов: Система анализирует журналы поисковых запросов (search logs).
2. Идентификация корреляций: Выявляются статистические связи между конкретными N-граммами и типами объектов, которым эти запросы посвящены.
3. Создание Индекса: Формируется Index, хранящий эти корреляции (N-грамма -> Тип объекта).

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

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

Система использует несколько ключевых типов данных:

• Контентные факторы (Запрос): N-граммы исходного запроса. Используются для определения неявного интента и сопоставления с Index.
• Географические факторы: Точное местоположение пользователя (Approximate Location). Критически важно для определения набора ближайших объектов. Включает оценку точности (confidence score).
• Временные факторы: Метка времени местоположения пользователя. Используется для оценки свежести (freshness).
• Структурные факторы (Данные об объектах): Система полагается на структурированные данные об объектах (вероятно, из Knowledge Graph / Google Business Profile):
  • Название объекта.
  • Точное местоположение объекта.
  • Тип объекта (Entity Type / Категория бизнеса).
• Факторы авторитетности/Качества (Атрибуты объектов):
  • Popularity (Популярность): Используется для разрешения неоднозначности (Claim 1).
  • Review Rating (Рейтинг отзывов): Также упоминается в описании для разрешения неоднозначности.
• Пользовательские факторы: В описании упоминается возможность использования истории взаимодействия пользователя (previously selected entities) для помощи в разрешении неоднозначности.

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

• Корреляция N-граммы и Типа: Метрика, определяющая связь между поисковым термином и категорией бизнеса. Рассчитывается офлайн на основе анализа поисковых логов и хранится в Index.
• Threshold Distance (Пороговое расстояние): Заданный радиус вокруг пользователя для поиска объектов-кандидатов.
• Freshness (Свежесть локации): Разница между текущим временем и временем определения местоположения. Сравнивается с пороговым значением.
• Confidence Score (Оценка точности локации): Метрика точности определения координат пользователя.
• Popularity / Review Rating: Метрики авторитетности объекта. Используются для ранжирования кандидатов в Sub-set of Entities и выбора лучшего (highest attribute value).

1. Местоположение как основной контекст для неявных запросов: Патент описывает конкретный механизм, в котором физическое местоположение пользователя становится главным фактором для понимания интента запросов без явного указания объекта.
2. Критичность структурированных данных и категоризации: Система полностью полагается на точные данные о местоположении и типе (категории) бизнеса (Entity Type). Ошибки в категоризации могут исключить бизнес из рассмотрения, так как она используется для сопоставления с интентом запроса через Index.
3. Автоматическое переписывание запросов до ранжирования: Google не пытается ранжировать результаты по неявному запросу напрямую. Вместо этого он переписывает запрос в явный (revised query) на этапе Query Understanding, добавляя название конкретного бизнеса.
4. Популярность как решающий фактор (Tie-Breaker): В ситуациях неоднозначности (когда рядом находятся несколько подходящих бизнесов) система отдает предпочтение более авторитетным. Popularity прямо указана в Claim 1 как критерий выбора. Это подтверждает важность сигналов авторитетности (Prominence) в Local SEO.
5. Требование к свежести данных: Система активируется только при наличии точных и свежих (sufficiently fresh) данных о местоположении, подчеркивая ориентацию на обработку контекста в реальном времени.

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

Рекомендации напрямую касаются оптимизации для Local SEO и Google Business Profile (GBP).

• Точность и полнота данных в GBP: Убедитесь, что название, адрес и телефон абсолютно точны. Точное местоположение (пин на карте) критично для попадания в Set of Entities, когда пользователь находится рядом.
• Оптимизация категорий (Entity Type): Выбор основной категории в GBP имеет решающее значение. Категория должна точно соответствовать Entity Type, который Google ассоциирует с вашими основными услугами. Это гарантирует, что ваш бизнес будет рассмотрен при релевантных неявных запросах.
• Повышение популярности (Popularity/Prominence): Работайте над повышением узнаваемости и популярности бизнеса онлайн (упоминания, локальные ссылки) и офлайн. Popularity используется для разрешения неоднозначности в пользу более известного бизнеса.
• Управление репутацией и отзывами (Review Rating): Активно работайте над получением высоких оценок. Хотя Claim 1 указывает на Popularity, Review Rating также упоминается в патенте как атрибут для выбора между кандидатами.
• Оптимизация под неявные интенты: Убедитесь, что информация, которую пользователи ищут через неявные запросы (часы работы, меню, цены, контакты), легко доступна в вашем GBP и на вашем сайте.

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

• Неправильная категоризация бизнеса: Выбор нерелевантных категорий приведет к тому, что система не сможет сопоставить ваш Entity Type с интентом пользователя, даже если он стоит у вашей двери.
• Игнорирование отзывов и популярности: Низкий рейтинг или недостаток сигналов популярности приведут к проигрышу конкурентам, находящимся рядом, при обработке неявных запросов, так как система предпочтет более авторитетного кандидата.
• Неточные данные о местоположении: Ошибки в адресе или неправильно установленный пин на карте могут исключить ваш бизнес из рассмотрения для пользователей, которые физически находятся рядом.

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

Патент подчеркивает стратегическую важность перехода от традиционного веб-поиска к контекстуальному поиску, основанному на объектах (Entity Search) и физическом окружении пользователя. Для локального бизнеса оптимизация сущности (GBP) и работа над сигналами авторитетности и качества (E-E-A-T), выраженными через популярность и рейтинги (Prominence), становятся решающими факторами для получения трафика в конкурентной локальной среде.

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

Сценарий: Выбор кофейни в бизнес-центре

1. Ситуация: Пользователь стоит в холле бизнес-центра, где расположены две кофейни: "Coffee A" (высокая популярность) и "Coffee B" (средняя популярность).
2. Запрос пользователя (Implicit Query): [латте цена].
3. Действие системы:
   1. Система определяет запрос как неявный и проверяет свежесть локации.
   2. Определяется точное местоположение пользователя. Обе кофейни попадают в Set of Entities.
   3. Используя Index, система определяет, что [латте цена] коррелирует с типом [Кофейня]. Обе кофейни попадают в Sub-set of Entities.
   4. Разрешение неоднозначности: Система сравнивает атрибуты. "Coffee A" имеет более высокую Popularity.
4. Переписывание (Revised Query): [латте цена Coffee A].
5. Результат: Пользователь видит результаты поиска для "Coffee A". "Coffee B" не получает этот трафик из-за более низкой популярности.