Как Google использует статистические модели для разделения картографических запросов на «Что» (объект) и «Где» (локация)

Описание

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

Патент решает проблему неоднозначности при обработке запросов в системах поиска по картам (Map Search), вводимых в единое поле. Задача — точно определить, какие части запроса относятся к информации о местоположении (location part, «Где»), а какие — к цели поиска (query part, «Что»). Это особенно актуально для языков без четкого разделения слов пробелами (например, китайский, японский, корейский), где запрос вида «Yantai hotel» может быть введен как слитная последовательность символов.

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

Запатентована система парсинга запросов, которая использует токенизацию, аннотирование типов и статистическую модель для разделения входной строки. Система обучается на корпусе известных адресов (Addresses) и названий организаций (Titles), чтобы статистически оценивать вероятность того, является ли сегмент запроса локацией или объектом поиска. На основе этих вероятностей выбирается наилучший способ разделения запроса.

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

Система работает следующим образом:

• Токенизация и Аннотирование: Входной запрос сегментируется на токены с использованием словаря адресов (Dictionary). Каждому токену присваивается тип (например, «City», «Road», «Number» или «None»).
• Генерация вариантов разделения: Система определяет все возможные точки разделения (splitting positions) последовательности токенов.
• Статистическое моделирование: Используется модель, обученная на частоте встречаемости терминов и типов в известных адресах и названиях.
• Оценка (Scoring): Для каждого варианта рассчитывается Location Statistical Score (вероятность быть адресом) и Query Statistical Score (вероятность быть названием/запросом).
• Выбор: Выбирается вариант разделения с максимальной суммарной оценкой (сумма Location Statistical Score для части локации и Query Statistical Score для части запроса).
• Поиск: Location part используется для определения географической области (например, через геокодирование), а Query part ищется в пределах этой области.

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

Высокая. Понимание запросов, особенно в контексте локального и мобильного поиска, является фундаментальной задачей. Хотя конкретные статистические модели, описанные в патенте (основанные на N-граммах и частотах), могли быть дополнены или заменены нейросетевыми подходами, базовая задача точного отделения интента локации от интента поиска остается критически важной для Google Maps и Local Pack.

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

Патент имеет значительное влияние на Local SEO (7/10). Он описывает механизм, который определяет, как именно Google интерпретирует локационный интент пользователя и искомый бизнес или категорию. Если система неверно классифицирует название бизнеса как адрес, или наоборот, сайт или бизнес-профиль не будет показан в релевантных результатах поиска по картам или в Local Pack.

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

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

Addresses (Адреса)

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

Dictionary (Словарь)

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

Location Part (Часть локации)

Сегмент входного запроса, идентифицированный как информация о местоположении («Где»).

Location Statistical Score (Статистическая оценка локации)

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

Query Part (Часть запроса)

Сегмент входного запроса, идентифицированный как цель поиска или название сущности («Что»).

Query Statistical Score (Статистическая оценка запроса)

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

Splitting Position (Точка разделения)

Возможное место в последовательности токенов, которое делит ее на Location Part и Query Part.

Splitting Score (Оценка разделения)

Метрика, оценивающая статистическую вероятность корректности определенного варианта разделения запроса. Часто рассчитывается как сумма Location Statistical Score для части локации и Query Statistical Score для части запроса.

Statistical Model (Статистическая модель)

Модель, обученная на Titles и Addresses. Хранит частоту встречаемости различных элементов (терминов, типов, их последовательностей) в этих двух корпусах данных.

Term (Термин)

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

Titles (Названия)

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

Token (Токен)

Структурная единица парсинга, состоящая из Term и аннотированного Type.

Type (Тип)

Аннотация к термину, указывающая на тип адресной информации, которую он представляет (например, «City», «Road», «Number», «Quantifier Suffix» или «None»).

Unigram/Bigram (Униграмма/Биграмма)

Последовательность из одного (Unigram) или двух (Bigram) элементов. В патенте используются как Term Unigram/Bigram, так и Type Unigram/Bigram.

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

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

1. Входной запрос парсится в последовательность токенов (каждый токен = термин + тип).
2. Определяются возможные точки разделения (possible splitting positions).
3. Для каждой точки разделения генерируются две подпоследовательности токенов.
4. Для каждой подпоследовательности рассчитываются Location Statistic Score и Query Statistic Score. Эти оценки основаны на оценках элементов (items) и типов элементов (item types) в подпоследовательности.
5. Подпоследовательность с более высоким Location Statistic Score идентифицируется как возможная часть локации (possible location subsequence), а другая — как возможная часть запроса (possible query subsequence).
6. Для каждой точки разделения определяется общая оценка разделения (Splitting Score).
7. Выбирается разделение с наивысшей оценкой.
8. Выполняется поиск информации, соответствующей части запроса, в локации, указанной частью локации.

Claim 5 и 6 (Зависимые): Уточняют расчет Splitting Score.

Оценка разделения определяется на основе (в частности, как сумма) Location Statistic Score части локации и Query Statistic Score части запроса.

Claim 9, 10 и 12 (Зависимые): Описывают использование и создание статистической модели.

Location Statistic Score и Query Statistic Score определяются с помощью статистической модели, обученной на данных, включающих Titles и Addresses. Модель создается путем подсчета и хранения количества вхождений различных элементов (униграмм терминов и типов, биграмм, последовательностей) в токенизированных Titles и Addresses.

Claim 14 и 19 (Зависимые): Определяют формулы для расчета статистических оценок элементов.

Оценка элемента для Location Statistical Score определяется как: $\log (l$

Выводы

1. Статистический подход к пониманию локальных запросов: Патент демонстрирует, что Google использует статистические вероятности, основанные на больших объемах известных данных (адреса и названия), для разрешения неоднозначностей в картографических запросах. Интерпретация запроса не является строго детерминированной, а выбирается как наиболее вероятная.
2. Важность обучающих данных (Titles и Addresses): Точность системы напрямую зависит от качества и полноты корпусов Titles и Addresses, используемых для обучения Statistical Model. Это подчеркивает важность точности данных в базах Google (например, Google Business Profile).
3. Различие между адресом и названием усваивается: Система обучается распознавать паттерны, характерные для адресов, и паттерны, характерные для названий организаций, используя как сами слова (Terms), так и их типы (Types).
4. Аннотирование типов как ключевой признак: Использование словаря для присвоения типов (City, Road, Suffix) является критически важным шагом, который помогает системе понять структуру адреса и ограничивает количество возможных интерпретаций.
5. Адаптация под специфику языков: Механизм специально разработан для эффективной работы в языках без явных разделителей слов, решая сложную задачу сегментации и интерпретации одновременно.

Практика

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

• Обеспечение консистентности NAP (Name, Address, Phone): Критически важно поддерживать абсолютную точность и консистентность названия и адреса компании во всех источниках (сайт, Google Business Profile, каталоги, социальные сети). Эти данные, вероятно, формируют обучающие корпуса Titles и Addresses. Несоответствия могут ухудшить способность модели правильно классифицировать название или адрес.
• Использование четких локационных индикаторов: При оптимизации контента и мета-тегов используйте четкие и официальные названия локаций, которые присутствуют в адресных базах (Dictionary). Это повышает вероятность правильной токенизации и аннотирования типа (например, «City» вместо «None»).
• Структурирование адресов на сайте: Представляйте адреса в иерархическом и ожидаемом формате. Патент упоминает, что множитель оценки локации (location multiplier) может быть повышен, если часть локации содержит адресные компоненты в иерархическом порядке (например, [province+city+district+street]).
• Оптимизация для многоязычных сайтов (особенно CJK): Для сайтов на китайском, японском, корейском языках крайне важно использовать корректные и полные адресные термины, так как система полагается на Dictionary для сегментации слитного текста.

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

• Неоднозначные названия брендов: Использование названий компаний, которые могут быть легко спутаны с адресами. Например, если компания называется «Тверская Улица Сервис», система может ошибочно классифицировать «Тверская Улица» как Location Part (тип «Road»), а не как часть Query Part (название компании).
• Спам локациями в названии бизнеса (в GBP): Добавление названий городов или районов в название компании (если это не часть официального бренда) может запутать статистическую модель. Система может начать чаще ассоциировать эти термины с Titles (повышая q_count), что потенциально ухудшит их распознавание как Addresses для других запросов, или наоборот, ошибочно разделить название компании.
• Игнорирование официальных адресных суффиксов: Пропуск или искажение адресных суффиксов (например, «улица», «проспект», «дом») может привести к тому, что токен получит тип «None» вместо корректного адресного типа, снижая общий Location Statistical Score.

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

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

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

Сценарий: Парсинг неоднозначного запроса в CJK языке

1. Входной запрос (Китайский): “上海餐厅” (Шанхай Ресторан, без пробела).
2. Токенизация: Система обращается к Dictionary.
   • “上海” (Шанхай) распознается как Термин с Типом «City».
   • “餐厅” (Ресторан) не найден в словаре адресов, распознается как Термин с Типом «None».
3. Анализ разделений: Рассматривается разделение между “上海” и “餐厅”.
4. Оценка (Scoring):
   • “上海” (Шанхай): Система проверяет Statistical Model. Термин часто встречается в Addresses (высокий l_count) и реже в Titles (низкий q_count). Получает высокий Location Statistical Score.
   • “餐厅” (Ресторан): Термин редко встречается в Addresses (низкий l_count) и часто в Titles или как категория (высокий q_count). Получает высокий Query Statistical Score.
5. Результат: Суммарный Splitting Score высок. Запрос разделяется на Location Part: “上海” и Query Part: “餐厅”. Google ищет рестораны в Шанхае.

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