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

Описание

Какую задачу решает

Патент решает проблему неоднозначности в Implicit Queries (неявных запросах) — запросах, которые не содержат явного упоминания названия сущности (например, [отзывы], [меню] или [часы работы]). Проблема возникает, когда пользователь находится в физической близости от нескольких объектов, к которым может относиться такой запрос (например, стоит между двумя отелями и спрашивает [цены на номера]). Система позволяет пользователю взаимодействовать с поиском более естественно, не требуя указывать точное название объекта, и обеспечивает релевантный ответ, используя местоположение как ключевой контекст для устранения неоднозначности.

Что запатентовано

Запатентована система, которая использует точное местоположение пользователя для интерпретации неявных поисковых запросов. Когда система получает неявный запрос, она идентифицирует набор сущностей (Entity Set) в физической близости от пользователя. Затем она определяет, какие из этих сущностей релевантны запросу, основываясь на их типе (Entity Type). Если запрос относится к двум или более ближайшим сущностям, система предоставляет пользователю интерфейс выбора (Selection Interface) для устранения неоднозначности. После выбора сущности исходный запрос переписывается в явный (Modified Query).

Как это работает

Ключевой механизм работы системы:

• Идентификация запроса: Система определяет, является ли запрос неявным (отсутствует явное упоминание сущности).
• Получение контекста: Определяется точное местоположение устройства пользователя в момент отправки запроса.
• Идентификация кандидатов: Определяется набор сущностей, находящихся в пределах порогового расстояния от пользователя.
• Фильтрация по типу: Система проверяет, связаны ли N-граммы запроса с типом каждой ближайшей сущности. Для этого используется индекс, связывающий поисковые термины с типами сущностей (например, [меню] связано с типом [Ресторан]).
• Устранение неоднозначности: Если релевантными оказываются две или более сущности, пользователю показывается интерфейс выбора.
• Автоматический выбор (Опционально): Если пользователь недавно уже выбирал одну из этих сущностей, система может автоматически выбрать ее повторно, не показывая интерфейс.
• Переписывание запроса: Исходный запрос модифицируется, чтобы явно включить выбранную сущность (например, [меню] -> [меню Название Ресторана]).

Актуальность для SEO

Высокая. С ростом мобильного поиска, голосовых ассистентов и запросов типа «рядом со мной» (near me), способность Google точно интерпретировать неявные локальные запросы критически важна. Этот патент описывает фундаментальный механизм для обработки естественного языка в контексте локального поиска и взаимодействия с физическими объектами.

Важность для SEO

Патент имеет критическое значение для локального SEO (Local SEO) и Entity SEO. Он подчеркивает важность точной и полной информации о физических сущностях в базе данных Google (Knowledge Graph). Ключевым фактором для попадания в набор кандидатов является не только точное местоположение, но и корректное определение типа сущности (Entity Type/категоризация). Если Google неправильно классифицирует тип бизнеса, он не будет показан в ответ на релевантные неявные запросы.

Детальный разбор

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

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

Запрос, который не содержит явного упоминания (explicit reference) названия сущности. Часто это короткие запросы о характеристиках объекта (например, [отзывы], [цены], [телефон]).

Modified Query / Rewritten Query (Модифицированный/Переписанный запрос)

Запрос, сгенерированный системой на основе исходного неявного запроса и выбранной сущности. Этот запрос явно ссылается на сущность (например, [цены Отель Ромашка]).

Entity Set (Набор сущностей)

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

Entity Type (Тип сущности)

Категория, присвоенная сущности (например, [Отель], [Ресторан], [Музей]). Используется для определения релевантности неявного запроса к сущности.

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

Последовательность из одного или нескольких слов в запросе. Используются для сопоставления с типами сущностей.

Selection Interface / Disambiguation Interface (Интерфейс выбора / Устранения неоднозначности)

Пользовательский интерфейс, который отображается, когда неявный запрос соответствует двум или более ближайшим сущностям. Позволяет пользователю выбрать нужную сущность.

Automatic Selection (Автоматический выбор)

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

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

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

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

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

1. Система получает первый запрос.
2. Определяется, что запрос является неявным (на основании отсутствия явного упоминания сущности).
3. В ответ на это:
   1. Получается первое местоположение устройства в момент запроса.
   2. Получается первый набор сущностей, связанных с этим местоположением.
   3. Определяется, что запрос неявно относится как минимум к двум сущностям из этого набора. Это включает:
      • Для каждой сущности: проверка, связаны ли N-граммы запроса с типом (Type) этой сущности.
      • Добавление связанных сущностей в подмножество.
   4. В ответ на это (если найдено ≥2 сущности), предоставляется первый интерфейс выбора (Selection Interface) с графическими представлениями этих сущностей.
4. Система получает пользовательский ввод, указывающий на выбор первой сущности.
5. Предоставляется первый модифицированный запрос (Modified Query), который явно ссылается на выбранную первую сущность.

Ядро изобретения — это использование комбинации местоположения пользователя и типа сущности для фильтрации кандидатов и последующее предоставление интерфейса для устранения неоднозначности, если кандидатов несколько.

Claim 3 (Зависимый): Вводит механизм автоматического выбора для последующих запросов.

1. Система получает второй запрос (также неявный).
2. Получает второе местоположение и второй набор сущностей.
3. Определяет, что второй запрос относится как минимум к двум сущностям из второго набора.
4. Автоматически выбирает вторую сущность без отображения второго интерфейса выбора.
5. Предоставляет второй модифицированный запрос.

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

Claim 4 (Зависимый от 3): Уточняет, что автоматический выбор выполняется на основе одного или нескольких факторов: времени, запроса и местоположения. Это означает, что система проверяет, насколько недавним был предыдущий выбор, насколько похож текущий запрос и насколько близко находится пользователь к предыдущему местоположению.

Claim 6 (Зависимый от 1): Уточняет, что сущность включается в набор (Entity Set), если ее местоположение находится в пределах порогового расстояния (Threshold Distance) от местоположения пользователя.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе система должна иметь доступ к структурированным данным о сущностях (например, в Knowledge Graph или локальном индексе). Для каждой сущности должны быть известны ее точное местоположение и тип (Entity Type). Также офлайн создается индекс, связывающий N-граммы поисковых запросов с типами сущностей (на основе анализа логов поиска).

QUNDERSTANDING – Понимание Запросов
Основное применение патента. Система анализирует входящий запрос в реальном времени:

1. Классифицирует запрос как неявный (Implicit Query).
2. Использует местоположение пользователя как основной контекст.
3. Идентифицирует ближайшие сущности (Entity Set).
4. Сопоставляет N-граммы запроса с типами этих сущностей для определения намерения (Intent).
5. Принимает решение о необходимости устранения неоднозначности.
6. В конечном итоге, может переписать (Rewrite) запрос в явный.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
Если система определяет необходимость устранения неоднозначности, она вмешивается в стандартный процесс формирования SERP, предоставляя пользователю Selection Interface вместо стандартных результатов поиска. Этот интерфейс сам по себе является формой поисковой выдачи, оптимизированной для выбора сущности.

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

• Исходный запрос пользователя (текст или речь).
• Точные данные о местоположении устройства (GPS, Wi-Fi и т.д.) и время запроса.
• База данных сущностей (Knowledge Graph) с указанием их местоположения и типов.
• Индекс соответствия N-грамм типам сущностей.
• История предыдущих выборов пользователя (для автоматического выбора).

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

• Интерфейс выбора (Selection Interface), отображающий релевантные ближайшие сущности.
• ИЛИ Модифицированный запрос (Modified Query), явно ссылающийся на выбранную (вручную или автоматически) сущность.

На что влияет

• Конкретные типы контента: В первую очередь влияет на страницы локальных бизнесов и организаций с физическим присутствием (Local Entities) — рестораны, отели, магазины, достопримечательности, услуги.
• Специфические запросы: Влияет на короткие, неявные информационные или транзакционные запросы, связанные с характеристиками объектов ([меню], [отзывы], [цены на номера], [купить билеты], [время работы]). Особенно актуально для мобильного и голосового поиска.
• Конкретные ниши или тематики: Максимальное влияние в высококонкурентных локальных нишах с высокой плотностью объектов (туризм, гостиничный бизнес, общепит, ритейл).

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

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

• Триггер 1 (Запрос): Запрос классифицирован как неявный (Implicit Query) — в нем нет явного упоминания названия сущности.
• Триггер 2 (Контекст): Доступно точное и актуальное местоположение пользователя.
• Триггер 3 (Наличие кандидатов): В пределах порогового расстояния найдена хотя бы одна сущность, тип которой соответствует N-граммам запроса.
• Условие для интерфейса выбора: Интерфейс отображается, если найдено две или более релевантных сущности И система не может выполнить автоматический выбор на основе истории.

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

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

1. Получение данных: Система получает запрос Q и данные о местоположении L пользователя.
2. Классификация запроса: Определяется, является ли Q неявным запросом. Если нет, используется стандартный поиск.
3. Проверка актуальности местоположения: Проверяется, что данные L достаточно свежие и точные.
4. Идентификация ближайших сущностей: Система запрашивает базу данных сущностей и получает набор сущностей E, находящихся в пределах порогового расстояния от L.
5. Инициализация подмножества: Создается пустое подмножество релевантных сущностей R.
6. Фильтрация по релевантности (Цикл): Для каждой сущности e в наборе E:
   1. Определяется тип T сущности e.
   2. Проверяется (с помощью индекса), связаны ли N-граммы запроса Q с типом T.
   3. Если да, сущность e добавляется в подмножество R.
7. Анализ результатов фильтрации:
   1. Если R пустое: используется стандартный поиск.
   2. Если R содержит 1 сущность: перейти к шагу 10 (Переписывание запроса).
   3. Если R содержит ≥2 сущностей: перейти к шагу 8 (Устранение неоднозначности).
8. Устранение неоднозначности: Система проверяет возможность автоматического выбора на основе истории (время, место, предыдущий запрос).
   1. Если автоматический выбор возможен: выбрать сущность S, перейти к шагу 10.
   2. Если нет: перейти к шагу 9.
9. Отображение интерфейса выбора: Система генерирует и отображает Selection Interface, содержащий графические представления сущностей из R (отсортированные по расстоянию, рейтингу и т.д.). Получает выбор пользователя S.
10. Переписывание запроса: Генерируется модифицированный запрос Q’, явно включающий выбранную сущность S.
11. Выполнение поиска: Выполняется поиск по модифицированному запросу Q’.

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

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

• Географические факторы: Критически важные данные. Используется точное местоположение пользователя (User Location) и точное местоположение сущностей (Entity Location).
• Контентные факторы: N-граммы исходного запроса.
• Структурные факторы (Данные о сущностях): Тип сущности (Entity Type/Категория) является центральным элементом для определения релевантности. Также используются данные о сущности для отображения в интерфейсе выбора: название, адрес, телефон, изображения, рейтинг (Claim 2).
• Поведенческие факторы:
  1. Логи поисковых запросов используются офлайн для построения индекса соответствия N-грамм типам сущностей.
  2. История недавних выборов пользователя используется в реальном времени для механизма автоматического выбора.
• Временные факторы: Время запроса и время последнего определения местоположения (для проверки актуальности). Время предыдущего выбора (для автоматического выбора).

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

• Пороговое расстояние (Threshold Distance): Фиксированный радиус для определения близости сущности.
• Корреляция N-грамма и Типа: Метрика (вероятно, основанная на частоте совместного использования в логах), определяющая, насколько сильно термины запроса связаны с определенным типом сущности.
• Пороги для автоматического выбора:
  1. Порог времени (Threshold Time): Максимальное время, прошедшее с момента предыдущего выбора сущности.
  2. Порог расстояния (Threshold Distance): Максимальное расстояние между текущим и предыдущим местоположением пользователя.
  3. Порог количества запросов (Threshold Query Count): Количество запросов с момента предыдущего выбора.
• Метрики ранжирования в интерфейсе выбора: В патенте упоминается возможность сортировки на основе расстояния, рейтинга, популярности и предыдущих взаимодействий пользователя.

Выводы

1. Местоположение как основной контекст для разрешения неоднозначности: Патент демонстрирует, как Google использует физическое местоположение пользователя в качестве главного фактора для понимания неявных локальных запросов. Это позволяет системе сузить круг потенциальных ответов до физически доступных объектов.
2. Критическая важность Типа Сущности (Entity Typing): Для интерпретации намерения пользователя система полагается не на контент страниц, а на Тип Сущности (категорию). Сопоставление N-грамм запроса с типом является ключевым механизмом фильтрации. Если тип определен неверно, система не сможет связать сущность с релевантным неявным запросом.
3. Связь между естественным языком и структурированными данными: Механизм позволяет обрабатывать естественные (неявные) запросы и преобразовывать их в структурированные (явные) запросы, пригодные для поиска в базе данных. Это достигается за счет использования индекса, построенного на анализе поисковых логов.
4. Контекстная история для оптимизации UX: Система использует историю предыдущих взаимодействий (Automatic Selection), чтобы избежать повторного запроса на устранение неоднозначности, если контекст (время, место) существенно не изменился.
5. Фокус на Local SEO и структурированных данных: Успешное функционирование этой системы напрямую зависит от качества и точности данных в Knowledge Graph и локальном индексе (данные из Google Business Profile).

Практика

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

• Точная категоризация в Google Business Profile (GBP): Выбор максимально точной основной и дополнительных категорий критически важен. Это напрямую влияет на то, как Google определяет Entity Type. Необходимо убедиться, что категории соответствуют тем типам, с которыми связаны целевые неявные запросы (например, если вы отель, убедитесь, что у вас есть категория [Отель], чтобы отвечать на запрос [цены на номера]).
• Обеспечение точности геолокации (NAP Consistency): Необходимо гарантировать абсолютную точность и консистентность данных о местоположении (Name, Address, Phone) на сайте, в GBP и во всех внешних источниках (каталогах, картах). Неточное местоположение исключит сущность из Entity Set.
• Использование структурированных данных (Schema.org): Необходимо четко определять тип сущности на сайте с помощью соответствующей разметки LocalBusiness (и ее подтипов, таких как Hotel, Restaurant) и указывать точные географические координаты (GeoCoordinates), адрес (PostalAddress) и контактную информацию. Это помогает Google валидировать Entity Type и местоположение.
• Оптимизация под неявные запросы: Убедитесь, что на сайте и в профиле GBP присутствует контент, который соответствует популярным неявным запросам для вашего типа бизнеса (меню, прайс-листы, подробные отзывы, информация о бронировании). Хотя это не влияет на первичную идентификацию сущности, это влияет на информацию, отображаемую в Selection Interface (Claim 2 упоминает отображение потенциальных результатов).

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

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

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

Патент подтверждает стратегический приоритет Google в области мобильного и локального поиска, а также стремление к обработке естественного языка. Для SEO это означает, что работа над видимостью сущности в Knowledge Graph и точностью ее атрибутов (особенно типа и местоположения) является фундаментом локального продвижения. Система позволяет Google предоставлять прямые ответы на локальные запросы, минуя стандартное ранжирование веб-страниц на начальном этапе. Чтобы быть видимым, бизнес должен быть корректно структурированной сущностью в базе данных Google.

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

Сценарий: Оптимизация ресторана итальянской кухни

1. Ситуация: Пользователь стоит на улице, где расположены два заведения: «Венеция» (итальянский ресторан) и «Сакура» (суши-бар). Пользователь вводит запрос [пицца дня].
2. Действия SEO-специалиста для «Венеции»:
   1. В GBP установлена основная категория [Итальянский ресторан] и дополнительная [Пиццерия].
   2. На сайте используется разметка Restaurant с указанием servesCuisine: «Italian», «Pizza».
   3. Геоданные точны и консистентны.
3. Работа системы:
   1. Система идентифицирует обе сущности как близкие.
   2. Система анализирует N-грамму [пицца].
   3. Индекс показывает, что [пицца] сильно коррелирует с типами [Пиццерия] и [Итальянский ресторан] («Венеция») и слабо коррелирует с типом [Суши-бар] («Сакура»).
4. Результат: Система определяет, что релевантна только «Венеция». Selection Interface не отображается. Запрос автоматически переписывается в [пицца дня Венеция], и пользователь получает ответ. Если бы «Венеция» была неправильно категоризирована (например, просто [Кафе]), система могла бы не распознать ее как релевантную запросу о пицце.

Вопросы и ответы