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

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

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

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

Approximate Orientation (Приблизительная ориентация)

Физическое положение устройства в пространстве. Включает Compass Direction (направление по компасу, азимут) и Tilt (наклон устройства относительно горизонтальной плоскости).

Compass Direction (Направление по компасу)

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

Entity (Сущность)

Объект реального мира (ресторан, отель, памятник, парк), имеющий структурированное представление в базе данных Google (например, в Knowledge Graph).

Entity Query Pattern (Шаблон запроса сущности)

Предварительно определенный шаблон, представляющий запросы, которые часто задают о конкретной сущности. Например, для сущности «Эйфелева башня» шаблоном может быть [высота *] или [когда построена *]. Используется для уточнения, о какой сущности идет речь в неявном запросе.

Explicit Query (Явный запрос)

Запрос, который содержит прямое упоминание сущности (например, «меню ресторана Awesome Pizza»). Является результатом переписывания неявного запроса.

Extended Portion (Расширенная зона)

Часть зоны поиска, которая выходит за пределы базовой зоны и простирается в направлении ориентации устройства. В патенте определяется как зона конической формы (Conical Shape).

Image Data (Данные изображения)

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

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

Запрос, который ссылается на сущность, не называя ее (например, «какое меню в этом ресторане?»).

Range (Зона поиска/Диапазон)

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

Tilt (Наклон)

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

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

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

1. Система получает запрос от устройства.
2. Определяет, что запрос неявно ссылается на какую-то сущность.
3. Получает приблизительное местоположение и ориентацию устройства.
4. Определяет первую геометрическую форму (first geometric shape) на основе местоположения. Уточняется, что это круглая форма с определенным радиусом.
5. Расширяет часть первой формы, создавая Extended Portion. Эта зона простирается дальше базового радиуса в направлении ориентации устройства. Ключевое уточнение: Extended Portion имеет коническую форму (conical in shape), центрирована по направлению ориентации и покрывает меньший угол, чем вся первая форма (круг).
6. Получает набор сущностей, которые хотя бы частично находятся внутри круглой зоны ИЛИ внутри расширенной конической зоны.
7. Выбирает одну сущность из набора.
8. Предоставляет пересмотренный запрос, явно ссылающийся на эту сущность.

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

Claim 5 (Зависимый от 1): Уточняет метод идентификации сущностей.

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

Это указывает на интеграцию компьютерного зрения. Ориентация (вероятно, Tilt) используется как триггер для захвата и анализа изображения с камеры с целью идентификации объекта, на который смотрит пользователь.

Claim 6 (Зависимый от 1): Уточняет метод выбора сущности.

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

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

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

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

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

INDEXING – Индексирование и извлечение признаков
Система полагается на данные, подготовленные на этом этапе:

• Структурированные данные о сущностях (Knowledge Graph), включая их точное местоположение и тип.
• Предварительно рассчитанные Entity Query Patterns, полученные путем анализа исторических логов поиска (Historical Data).
• Модели распознавания изображений (image models) для идентификации сущностей по Image Data.

RANKING – Ранжирование
На этот этап поступает уже переписанный, явный запрос. Ранжирование происходит на основе уточненного запроса, что обеспечивает более релевантные результаты.

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

• Исходный неявный запрос (текст или аудио).
• Approximate Location (данные GPS, WiFi).
• Approximate Orientation (данные компаса и акселерометра).
• Image Data (опционально, данные с камеры устройства).

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

• Переписанный явный запрос (Revised Query).

На что влияет

• Конкретные типы контента: В первую очередь влияет на информацию о локальных сущностях: профили компаний (Local Listings), отзывы, часы работы, меню, информация о достопримечательностях.
• Специфические запросы: Локальные информационные и транзакционные запросы, заданные с мобильных устройств, особенно те, которые используют местоимения или общие термины («этот», «здесь», «это место»). Примеры: [часы работы], [отзывы об этом отеле], [когда это было построено].
• Конкретные ниши или тематики: Туризм, рестораны, ритейл, недвижимость – любые ниши, где пользователи взаимодействуют с физическими объектами и ищут информацию о них на ходу.

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

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

• Триггеры активации: Обнаружение неявного запроса (Implicit Query). Это происходит путем сравнения запроса с известными шаблонами, указывающими на неявную ссылку (например, [рейтинг], [* отзывы]).
• Условия работы алгоритма: Наличие достаточно точных данных о местоположении и ориентации устройства. В патенте упоминается использование пороговых оценок уверенности (threshold confidence score) для точности этих данных и проверка их свежести (sufficiently fresh).
• Специфический триггер для камеры: Если угол наклона (Tilt) устройства превышает пороговое значение (threshold tilt), что указывает на ориентацию устройства для захвата изображений, может быть активирован сбор Image Data.

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

Этап 1: Получение и анализ запроса

1. Получение запроса: Система получает запрос от пользовательского устройства вместе с данными о местоположении и ориентации.
2. Идентификация неявной ссылки: Запрос обрабатывается (например, удаляются стоп-слова), и сравнивается с набором шаблонов (Query Patterns). Если найдено соответствие, запрос классифицируется как неявный. Если нет, обработка идет стандартным путем.

Этап 2: Определение контекста и зоны поиска

1. Валидация данных: Проверяется точность (confidence score) и свежесть данных о местоположении и ориентации. Если данные ненадежны, алгоритм может быть прерван.
2. Определение базовой зоны: На основе местоположения определяется базовая географическая зона (например, круг с радиусом R).
3. Определение расширенной зоны: На основе ориентации (направления по компасу) определяется расширенная конусообразная зона (Extended Portion), которая простирается дальше базового радиуса в направлении взгляда пользователя.

Этап 3: Сбор кандидатов (Сущностей)

1. Поиск по местоположению: Идентифицируются все сущности, попадающие в базовую и расширенную зоны поиска.
2. Проверка наклона (Tilt): Определяется угол наклона устройства. Если он превышает порог (пользователь держит телефон вертикально), активируется сбор Image Data.
3. Визуальное распознавание (опционально): Если Image Data получены, они отправляются в сервис распознавания сущностей (entity recognition service). Сервис сравнивает изображение с моделями (image models) сущностей поблизости и добавляет распознанные объекты в набор кандидатов.

Этап 4: Уточнение и выбор сущности

1. Фильтрация по типу: Система может фильтровать кандидатов на основе типа сущности и содержания запроса (например, если запрос содержит «меню», оставляем только рестораны).
2. Сравнение с Entity Query Patterns: Шаблон исходного запроса сравнивается с набором Entity Query Patterns для каждой сущности-кандидата. Сущности, чьи шаблоны совпадают, включаются в финальный поднабор.
3. Разрешение неоднозначности: Если в финальном поднаборе осталась одна сущность, она выбирается. Если несколько, система выбирает одну на основе дополнительных атрибутов (например, рейтинг, популярность, история пользователя) или предлагает выбор пользователю.

Этап 5: Переписывание и выполнение поиска

1. Переписывание запроса: Исходный неявный запрос переписывается в явный, включая название или идентификатор выбранной сущности.
2. Выполнение поиска: Переписанный запрос отправляется в поисковую систему для получения результатов.

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

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

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

• Географические факторы:
  • Approximate Location: Данные GPS, WiFi, сотовой сети для определения координат пользователя.
• Пользовательские факторы (Данные датчиков устройства):
  • Магнитометр: Для определения Compass Direction.
  • Акселерометр: Для определения Tilt (наклона).
  • Камера: Для сбора Image Data (визуальной информации о сцене перед пользователем).
• Поведенческие факторы (Офлайн):
  • Исторические логи запросов (Search Logs): Используются для офлайн-анализа с целью создания Entity Query Patterns (определения, какие запросы часто задают о конкретных сущностях) и корреляции терминов запроса с типами сущностей.
• Структурные факторы (Данные о сущностях):
  • База данных сущностей (Entity Graph/Database): Информация о местоположении, типе, рейтинге, популярности сущностей.
  • Image Models: Визуальные модели сущностей, используемые для распознавания изображений.

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

• Confidence Score (Оценка уверенности): Метрика точности определения местоположения и ориентации. Сравнивается с порогом (threshold confidence score) для валидации данных.
• Time Difference (Разница во времени): Метрика свежести данных о местоположении. Сравнивается с порогом для определения, актуально ли местоположение.
• Threshold Radius (Пороговый радиус): Определяет размер базовой круглой зоны поиска.
• Extended Radius (Расширенный радиус): Определяет дальность конусообразной расширенной зоны поиска (Extended Portion).
• Threshold Tilt (Пороговый наклон): Угол наклона устройства, при превышении которого может активироваться сбор Image Data.
• Image Similarity Score (Оценка схожести изображения): Метрика, определяющая соответствие между Image Data с камеры и Image Model сущности. Используется для визуального распознавания.
• Entity Attributes (Атрибуты сущности): Метрики качества или популярности сущности (например, рейтинг отзывов), используемые для разрешения неоднозначности при выборе из нескольких кандидатов.

1. Физический контекст критичен для мобильного поиска: Google активно использует не только местоположение пользователя, но и точную ориентацию устройства (куда он смотрит и как держит телефон), чтобы понять интент мобильного запроса о реальном мире.
2. Направленный поиск, а не только близость: Система не просто ищет объекты поблизости. Она определяет конусообразную зону поиска в направлении взгляда пользователя. Это означает, что объект, находящийся дальше, но прямо по курсу, может быть предпочтительнее объекта, который ближе, но находится сбоку или сзади.
3. Интеграция компьютерного зрения (Visual Search): Патент описывает механизм, при котором ориентация устройства (в частности, наклон) может служить триггером для использования камеры (Image Data) с целью идентификации сущности. Это подтверждает слияние традиционного поиска с технологиями типа Google Lens.
4. Важность Entity Query Patterns: Система использует предварительно рассчитанные данные о том, что пользователи обычно спрашивают о конкретных сущностях. Это используется для разрешения неоднозначности. Если пользователь спрашивает о «меню», система отдаст предпочтение ресторану, а не отелю, даже если оба находятся в зоне поиска.
5. Требования к точности данных о сущностях: Для работы системы необходимы точные данные о местоположении сущностей и их атрибутах (тип, рейтинг). Ошибки в этих данных приведут к некорректной интерпретации запросов.

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

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

• Обеспечение точности локальных данных (Local SEO): Критически важно поддерживать абсолютную точность адреса и местоположения (Pin location) в Google Business Profile (GBP) и других локальных каталогах. Это необходимо, чтобы сущность корректно попадала в зону поиска пользователя (Range и Extended Portion).
• Насыщение профиля сущности визуальными данными: Загружайте качественные фотографии экстерьера здания с разных ракурсов в GBP. Это может помочь системе компьютерного зрения сформировать точные Image Models, что улучшит распознавание вашего объекта при использовании Image Data с камеры пользователя.
• Оптимизация под Entity Query Patterns: Анализируйте, какие вопросы пользователи чаще всего задают о вашем бизнесе или типе бизнеса (часы работы, цены, наличие конкретных услуг, отзывы). Убедитесь, что эта информация доступна и структурирована (в GBP, на сайте, в разметке Schema.org). Это повысит вероятность того, что система сопоставит неявный запрос пользователя с вашей сущностью.
• Работа над атрибутами сущности (Рейтинг и Популярность): Поскольку при наличии нескольких кандидатов система может выбирать сущность на основе рейтинга или популярности, необходимо системно работать над улучшением этих показателей (стимулирование отзывов, управление репутацией).

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

• Манипуляции с местоположением: Попытки указать неверное местоположение или создать фейковые точки могут привести к тому, что система не сможет корректно идентифицировать сущность в физическом контексте пользователя.
• Игнорирование визуальной составляющей: Отсутствие фотографий экстерьера или использование устаревших изображений может снизить эффективность распознавания объекта системой компьютерного зрения.
• Предоставление неполной информации: Если информация, соответствующая популярным Entity Query Patterns (например, меню для ресторана), отсутствует или плохо структурирована, система может предпочесть конкурента, у которого эта информация есть.

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

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

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

Сценарий: Оптимизация ресторана для захвата неявных запросов о меню.

1. Анализ (Entity Query Patterns): Определяем, что пользователи часто ищут «меню», «цены на блюда», «винная карта» стоя у входа в ресторан.
2. Действия по оптимизации:
   • Проверяем точность геолокации в GBP.
   • Загружаем актуальные, четкие фотографии фасада ресторана в GBP.
   • Добавляем полное меню в GBP (через раздел Меню) и на сайт (в текстовом виде и с разметкой Menu/hasMenuItem).
3. Ожидаемый результат: Пользователь стоит на улице перед рестораном (ресторан попадает в Extended Portion) и спрашивает Google Ассистента: «Покажи меню этого места». Система корректно идентифицирует ресторан (используя геолокацию, ориентацию и, возможно, камеру), сопоставляет запрос с Entity Query Pattern [меню *], переписывает запрос, добавляя название ресторана, и выдает пользователю меню из GBP или сайта.