Как Google Autocomplete использует статистические модели для нормализации разных фонетических написаний одного запроса

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

Kongping (KP)

Фонетическая репрезентация (романизация) китайской фразы или иероглифа в кантонском диалекте с использованием латинских символов. Не имеет единого стандарта.

Jyutping (JP)

Стандартизированная схема романизации кантонского диалекта. В патенте используется как эталонное произношение для анализа и группировки пользовательских вариантов Kongping.

Language Model Builder

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

Model File (Language-Specific Model File)

Структура данных, хранящая вероятностную модель: соответствие между нелатинскими строками (иероглифами) и вариантами их фонетической репрезентации латиницей (Kongping), а также оценки популярности (Popularity Scores) для каждого варианта.

Query Completion Table (Таблица завершения запросов)

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

Ordered Set Builder

Компонент, который анализирует Query Logs и использует Model File для генерации фонетических префиксов и заполнения Query Completion Table.

Popularity Score (Оценка популярности)

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

User Survey Data, Custom Data, 3rd Party Data

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

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

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

1. Система поддерживает базу данных языковой модели (language specific model), которая связывает нелатинские строки с несколькими вариантами латинских строк (фонетическими представлениями). Модель строится на основе данных (опросы, кастомные данные и т.д.) и отражает персональные предпочтения разных пользователей в написании.
2. Система получает две разные строки латинских символов от двух пользователей (Строка 1 и Строка 2). Различия обусловлены разными предпочтениями пользователей в фонетической записи одной и той же нелатинской строки.
3. Используя языковую модель и исторические запросы, система получает наборы предсказанных полных запросов (Набор 1 и Набор 2).
4. Наборы содержат идентичные запросы, так как и Строка 1, и Строка 2 с помощью модели были связаны с одной и той же базовой нелатинской строкой.
5. Система передает пользователям подмножества этих наборов, причем оба подмножества включают этот идентичный предсказанный запрос.

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

Claim 2 (Зависимый): Уточняет, что Строка 1 и Строка 2 являются двумя различными фонетическими представлениями одного и того же запроса на кантонском диалекте.

Claims 7 и 8 (Зависимые): Описывают ранжирование подсказок. Каждая подсказка имеет Popularity Score, и подсказки передаются в порядке убывания этой оценки. При этом один и тот же идентичный запрос может занимать разные позиции в Наборе 1 и Наборе 2, так как вероятность этого запроса может быть разной в зависимости от популярности исходного написания (Строки 1 или Строки 2).

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

Изобретение применяется на стыке инфраструктурных процессов (индексирования) и обработки запросов в реальном времени.

INDEXING – Индексирование и извлечение признаков (Офлайн-процессы)
На этом этапе происходит предварительная обработка данных:

1. Построение языковой модели: Language Model Builder анализирует данные из разных источников для создания Model File.
2. Генерация таблиц автозаполнения: Ordered Set Builder анализирует Query Logs и использует Model File для генерации Query Completion Tables. Это включает синтез возможных фонетических префиксов для популярных запросов.

QUNDERSTANDING – Понимание Запросов (Runtime / Autocomplete)
Это основная область применения патента в реальном времени. Когда пользователь вводит частичный запрос, Prediction Server получает его и выполняет поиск в предварительно созданных Query Completion Tables. Система интерпретирует ввод с учетом возможных фонетических вариаций, заложенных в таблицах.

Входные данные (Офлайн): Логи запросов, данные опросов пользователей, кастомные словари, данные из веба.
Входные данные (Онлайн): Частичный запрос пользователя (строка латинских символов).
Выходные данные: Упорядоченный список предсказанных полных запросов (может включать запросы на разных языках).

На что влияет

• Специфические языки и диалекты: Наибольшее влияние на языки без стандартизированной системы романизации (кантонский диалект как пример).
• Типы запросов: Влияет на запросы, которые пользователи вводят фонетически латиницей (имена собственные, бренды, локации).
• Географические ограничения: Актуально в регионах, где распространены такие языки (например, Гонконг), и где система идентифицирует пользователя как носителя (по IP, настройкам языка).

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

• Триггеры активации: Алгоритм активируется в реальном времени каждый раз при вводе символов в строку поиска (Autocomplete/Google Suggest).
• Условия работы: Специфическая логика фонетической обработки применяется, когда ввод интерпретируется как потенциальное фонетическое представление (например, Kongping).

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

Алгоритм состоит из трех основных процессов.

Процесс А: Построение языковой модели (Model File) (Офлайн)

1. Сбор данных: Сбор фонетических представлений (Kongping, kp) из User Survey Data, Custom Data и 3rd Party Data.
2. Анализ частотности (F): Вычисление частоты использования конкретного kp для конкретного произношения (Jyutping, jp) у каждого пользователя.
3. Агрегация популярности (G): Вычисление средней популярности kp для jp по всем пользователям.
4. Расчет оценки для символа (H): Вычисление популярности kp для конкретного символа/иероглифа (C), учитывая все его возможные произношения (jp).
5. Взвешивание и сохранение (P): Объединение данных из всех источников с учетом их весов достоверности (r_i) и сохранение итоговой оценки популярности в Model File.

Процесс Б: Построение таблиц завершения запросов (Query Completion Table) (Офлайн)

1. Анализ логов: Извлечение популярного запроса из Query Log.
2. Проверка языка: Определение, является ли запрос нелатинским (например, китайским).
3. Поиск в модели: Поиск запроса в Model File для извлечения Kongpings и их оценок популярности.
4. Рекурсивное деление и Синтез (если не найдено): Если запрос не найден, он разбивается на подзапросы. Для компонентов ищутся Kongpings, а затем синтезируются общие Kongpings для фразы путем комбинации и перемножения их оценок популярности.
5. Генерация префиксов: Создание всех возможных латинских префиксов из полученных Kongpings.
6. Расчет оценок префиксов: Для каждого префикса суммируются оценки популярности всех Kongpings, начинающихся с этого префикса.
7. Фильтрация: Отбор префиксов, чья совокупная оценка популярности превышает заданный порог.
8. Сохранение: Добавление префикса, полного запроса и его оценки ранжирования в Query Completion Table.

Процесс В: Обработка частичного запроса (Онлайн)

1. Получение ввода: Прием частичного запроса от клиента.
2. Хеширование: Применение хеш-функции к частичному запросу (или его префиксу, если используется чанкинг) для создания "отпечатка" (fingerprint).
3. Поиск в таблице: Использование отпечатка для поиска соответствующей записи в Query Completion Table.
4. Извлечение и Упорядочивание: Получение набора предсказанных полных запросов и их сортировка по оценкам ранжирования (Ranking Score).
5. Передача результатов: Отправка упорядоченного списка клиенту для отображения.

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

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

• Поведенческие факторы: Query Logs используются для определения популярных запросов и их частотности. User Survey Data (данные опросов) используются для построения языковой модели, фиксируя предпочтения пользователей в фонетическом написании.
• Лингвистические/Географические данные: Custom Data (например, устоявшиеся географические названия Гонконга) используются для уточнения языковой модели авторитетными данными.
• Контентные факторы: 3rd Party Data (данные, извлеченные из веба, содержащие пары Фраза -> Романизация) используются для пополнения языковой модели.

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

Патент детально описывает расчет метрик популярности для построения вероятностной языковой модели:

• F(user, jp, kp) – Частота использования пользователем: Отношение числа раз, когда пользователь ввел Kongping (kp) для данного произношения Jyutping (jp), к общему числу вводов для этого произношения. $F = K/T$.
• G(jp, kp) – Агрегированная популярность произношения: Среднее значение F по всем пользователям (N). $G = (\sum F) / N$.
• H(C, kp) – Популярность для иероглифа: Взвешенная сумма G для всех возможных произношений (jp) данного иероглифа (C). $H = \sum (w_i * G(jp_i))$.
• P(C, kp) – Итоговая оценка популярности: Взвешенная комбинация оценок H из разных источников данных (с весами достоверности r_i), нормализованная по сумме всех оценок для данного иероглифа (C).
• Synthesized Popularity Score: При синтезе Kongping для фразы из компонентов, итоговая оценка рассчитывается как произведение оценок популярности компонентов (Score(A+B) = Score(A) * Score(B)).

1. Нормализация неоднозначного ввода: Патент демонстрирует сложный механизм, позволяющий Google статистически обрабатывать и нормализовать различия в фонетическом написании запросов. Система признает, что разные строки ввода могут представлять один и тот же интент или сущность.
2. Data-driven подход к языку: Вместо использования строгих лингвистических правил, Google применяет вероятностный подход, основанный на реальных данных о предпочтениях пользователей (User Survey Data) и авторитетных источниках (Custom Data).
3. Комплексная офлайн-обработка для скорости онлайн: Эффективность системы автозаполнения в реальном времени обеспечивается масштабной предварительной обработкой — построением сложных языковых моделей, рекурсивным анализом запросов и синтезом фонетических представлений для заполнения Query Completion Tables.
4. Приоритет сущности/интента над написанием: Механизм подчеркивает переход от буквального сопоставления ключевых слов к пониманию базовой сущности или интента еще на этапе ввода запроса.
5. Мультиязычность автозаполнения: Система способна одновременно интерпретировать ввод латиницей и как префикс слова (например, английского), и как фонетическое представление (например, Kongping), предлагая смешанные подсказки на разных языках.

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

• Анализ фонетического спроса в целевых регионах (International SEO): При работе на рынках, где используются языки без стандартной романизации (например, Гонконг), необходимо исследовать, как пользователи фонетически записывают латиницей ключевые термины и бренды. Не полагайтесь только на официальную транслитерацию.
• Мониторинг Google Autocomplete: Регулярно проверяйте Google Suggest по различным популярным фонетическим вариантам написания вашего бренда или ключевых запросов. Это позволяет убедиться, что система корректно ассоциирует эти варианты с вашим контентом/брендом.
• Использование устоявшихся романизаций в контенте: Патент указывает, что Google придает больший вес авторитетным данным (Custom Data). Использование общепринятых или официальных вариантов романизации в контенте сайта может укреплять ассоциацию в моделях Google.
• Оптимизация под сущности и интент: Подтверждается важность фокуса на сущностях и удовлетворении интента. Поскольку Google нормализует различные варианты написания к одной базовой сущности, контент должен быть авторитетным источником по этой сущности, а не набором ключевых слов.

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

• Чрезмерная оптимизация под фонетические написания: Не стоит пытаться оптимизировать контент под конкретные варианты Kongping или другие фонетические транслитерации. Google нормализует их самостоятельно. Усилия должны быть направлены на основную тему или сущность.
• Игнорирование локальных особенностей ввода: Ошибочно предполагать, что ввод латинскими символами в регионе типа Гонконга означает поиск на английском языке. Система активно интерпретирует такой ввод как фонетический и предлагает результаты на локальном языке.
• Игнорирование данных Suggest: Создание контент-стратегии без учета популярных формулировок из Suggest является неэффективным, так как подсказки основаны на реальных логах и сложных лингвистических моделях.

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

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

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

Сценарий: Оптимизация видимости бренда в Гонконге

1. Задача: Убедиться, что бренд 寶馬 (BMW) появляется в Autocomplete при вводе латиницей в Гонконге.
2. Исследование (на основе патента): Известно, что пользователи могут вводить название фонетически как "boma" или "poma". Google использует статистическую модель для обработки этих вариантов.
3. Действия SEO-специалиста:
   • Проверить Autocomplete (используя локальный поиск Гонконга) для ввода "bo", "bom", "boma", а также "po", "pom", "poma".
   • Проанализировать, появляется ли бренд 寶馬 в подсказках для обоих вариантов.
4. Ожидаемый результат: Бренд должен появляться в подсказках для обоих вариантов ввода, так как система распознает их как фонетические репрезентации 寶馬. Если бренд не появляется для популярного варианта, это может указывать на необходимость усиления ассоциации этого написания с брендом в авторитетных внешних источниках (которые Google может использовать как 3rd Party Data).