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

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

Common Form (Общая форма / Каноническая форма)

Упрощенная, стандартизированная форма слова, полученная путем применения правил конвертации (например, удаления акцентов, транслитерации). Используется как ключ в Synonyms Map.

Variant (Вариант)

Исходное слово, найденное в корпусе документов, которое маппится на определенную Common Form. Хранится как значение в Synonyms Map и используется как потенциальный синоним.

Synonyms Map (Карта синонимов)

Структура данных, которая связывает Common Form (ключ) с одним или несколькими Variants (значения). Для каждого варианта также хранится статистика его использования в разных языках (Relative Frequency).

Interface Language (Язык интерфейса)

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

Query Language (Язык запроса)

Вероятный язык, на котором составлен запрос. Определяется на основе Interface Language и анализа самих терминов запроса.

Collapsible Digraphs (Схлопывающиеся диграфы)

Комбинации из двух символов, которые в некоторых языках могут быть представлены одним символом. Например, «AE» вместо «Æ» или «ue» вместо «ü» в немецком.

Transliteration (Транслитерация)

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

Small Language («Малый язык»)

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

Relative Frequency (Относительная частотность)

Метрика, показывающая, как часто конкретный вариант встречается в данном языке по сравнению со всеми другими вариантами для той же Common Form в этом же языке.

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

Основное внимание в патенте уделяется общему процессу генерации синонимов и специфической логике обработки запросов для "малых языков", описанной в Claim 1.

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

1. Система получает запрос через интерфейс с определенным Interface Language.
2. Система определяет, является ли Interface Language «малым языком» (Small Language), т.е. слабо представленным в корпусе.
3. Каждый термин запроса упрощается (simplified form).
4. Если язык интерфейса — «малый», применяется специальная логика:
   • Если исходный термин ОТЛИЧАЕТСЯ от упрощенной формы (т.е. пользователь ввел акценты или специальные символы): использовать исходный термин КАК ЕСТЬ и НЕ предоставлять синонимы.
   • Если исходный термин ИДЕНТИЧЕН упрощенной форме (т.е. пользователь ввел упрощенный вариант): использовать упрощенную форму для поиска синонимов и расширения запроса.

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

Claim 2 (Зависимый от 1): Уточняет, что упрощение термина включает транслитерацию.

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

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

INDEXING – Индексирование и извлечение признаков (Офлайн-процесс)

На этом этапе происходит создание Synonyms Map. Это включает:

• Определение языка документа: Критически важный шаг для корректной нормализации слов.
• Нормализация: Слова из документов преобразуются в Common Form с использованием правил (Language-Specific Mappings), специфичных для языка документа.
• Статистический анализ: Вычисляется абсолютная и относительная частотность вариантов в разных языках.

QUNDERSTANDING – Понимание Запросов (Онлайн-процесс)

Основное применение патента происходит на этом этапе в реальном времени:

• Определение контекста: Идентификация Interface Language и расчет вероятностей Query Language.
• Нормализация (Query Rewriting): Упрощение терминов запроса (включая транслитерацию) и последующее расширение запроса путем добавления вариантов из Synonyms Map.
• Применение бизнес-логики: Активация специальной логики для Small Languages (Claim 1).

Входные данные (Онлайн):

• Исходный запрос пользователя.
• Язык интерфейса (Interface Language).
• Synonyms Map.

Выходные данные (Онлайн):

• Расширенный (аугментированный) запрос, содержащий исходные термины и их варианты, соединенные через OR.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на запросы, содержащие имена собственные, бренды или термины с диакритическими знаками, а также на запросы, вводимые с использованием транслитерации (например, Roman Indic).
• Языковые и географические ограничения: Механизм критичен для международного поиска. Логика работы сильно отличается для доминирующих языков (English, French) и Small Languages (Icelandic, Latvian).

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

• Триггеры активации: Алгоритм переписывания активируется, когда для упрощенной формы термина запроса существуют варианты в Synonyms Map, и эти варианты проходят пороговые значения вероятности.
• Исключения (Small Languages): Логика добавления синонимов блокируется при условии, описанном в Claim 1: если Interface Language определен как «малый», и исходный термин отличается от его упрощенной формы.

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

Процесс А: Создание Карты Синонимов (Офлайн)

1. Сбор данных: Идентификация обучающего корпуса документов.
2. Определение языка: Определение языка каждого документа в корпусе.
3. Создание словаря: Составление словаря всех уникальных слов с подсчетом частоты их встречаемости в каждом языке.
4. Нормализация (Mapping to Common Form): Каждое слово преобразуется в общую форму на основе правил, специфичных для языка документа, в котором оно найдено.
5. Генерация Карты Синонимов: Создание структуры, где ключи — это Common Forms, а значения — исходные слова (варианты).
6. Фильтрация и Расчет метрик:
   • Удаление редких вариантов (на основе абсолютных порогов частоты) для фильтрации опечаток.
   • Расчет относительной частотности (Relative Frequency) каждого варианта.
   • Удаление вариантов с низкой относительной частотностью (например, менее 10%).

Процесс Б: Обработка и Переписывание Запроса (Онлайн)

1. Получение запроса и контекста: Получение запроса и определение Interface Language.
2. Определение языка запроса: Расчет вероятностей того, что запрос принадлежит к различным языкам. Выбор наиболее вероятного Query Language.
3. Упрощение запроса (Simplification): Нормализация каждого термина запроса (удаление акцентов, схлопывание диграфов, транслитерация).
4. Проверка на «Малый язык» (Small Language Check - Claim 1):
   • Система проверяет, является ли Interface Language «малым».
   • Если ДА, и если Исходный термин ≠ Упрощенному термину: пропустить шаги 5-7 для этого термина (использовать как есть).
5. Поиск вариантов: Использование упрощенных терминов как ключей для поиска в Synonyms Map.
6. Оценка вариантов (Scoring): Расчет оценки применимости для каждого варианта. Оценка = Сумма по всем языкам (Вероятность языка запроса * Относительная частотность варианта в этом языке).
7. Фильтрация и Аугментация: Если оценка варианта превышает порог (например, 50%), он добавляется к запросу как дизъюнкция (OR) с исходным термином.
8. Выполнение поиска: Использование расширенного запроса для поиска по корпусу.

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

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

• Контентные факторы: Текст документов в обучающем корпусе. Используется для генерации словаря и Synonyms Map.
• Языковые данные: Определенный язык каждого документа в корпусе. Язык интерфейса пользователя (Interface Language).
• Структурные данные (Правила): Специфичные для языка карты конвертации (Conversion Maps), определяющие правила нормализации, удаления акцентов и транслитерации. Также используются черные списки (Blacklists) символов или слов для фильтрации шума.
• Поведенческие факторы (Косвенно): В патенте упоминается, что вероятность языка запроса может определяться на основе прошлых запросов и языка результатов, которые выбирал пользователь.

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

• Абсолютная частотность: Количество вхождений варианта в документы определенного языка. Используется для фильтрации редких слов (опечаток).
• Относительная частотность (Relative Frequency): Рассчитывается как (Частота варианта V в языке L) / (Суммарная частота всех вариантов для той же Common Form в языке L). Используется для определения значимости варианта.
• Вероятность языка запроса (Query Language Probability): Вектор, содержащий для каждого языка вероятность того, что запрос составлен на этом языке.
• Оценка применимости варианта (Variant Applicability Score): Метрика для определения того, насколько вариант подходит в качестве синонима. Рассчитывается путем суммирования по всем языкам произведения вероятности языка запроса на относительную частотность варианта в этом языке. Формула: $Score(V) = \sum_{L} (P(L|Query) * RelFreq(V|L))$.
• Пороги (Thresholds): Используются абсолютные и относительные пороги частотности для фильтрации Synonyms Map, а также порог вероятности синонимов (synonyms probability threshold, например, 50%) для включения варианта в запрос.

1. Язык контента и запроса определяет правила нормализации: Google не использует универсальный подход к удалению акцентов. То, как слово нормализуется, зависит от языка документа (при индексировании) и предполагаемого языка запроса (при поиске). Правила для немецкого языка не будут применены к турецкому, и наоборот.
2. Переписывание запроса основано на статистике и вероятностях: Система не просто добавляет все возможные акцентированные варианты. Она использует комбинацию вероятного языка запроса и статистической значимости (Relative Frequency) варианта в этом языке, основываясь на данных корпуса.
3. Транслитерация и диграфы как часть нормализации: Патент явно включает обработку транслитерации и схлопывающихся диграфов (например, «ue» в немецком) в процесс упрощения терминов, позволяя связывать разные орфографические представления.
4. Защитный механизм для «Малых языков» (Small Languages): Google применяет консервативный подход к языкам, слабо представленным в индексе (Claim 1). Если пользователь использует интерфейс на таком языке и вводит термин с акцентами, система НЕ будет его расширять, чтобы сохранить точность и избежать подмешивания результатов из доминирующих языков.
5. Приоритет корректной орфографии: Система спроектирована так, чтобы находить правильно написанный контент (с акцентами) по упрощенным запросам. Это дает преимущество качественным ресурсам, соблюдающим правила языка.

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

• Используйте корректную орфографию и диакритику: Всегда используйте правильные акценты и специальные символы (например, «Français», а не «Francais»). Патент подтверждает, что Google имеет сложный механизм (Synonyms Map) для сопоставления упрощенных пользовательских запросов с вашим правильно написанным контентом.
• Обеспечьте правильное определение языка контента: Убедитесь, что Google корректно идентифицирует язык ваших страниц (HTML lang, hreflang). Это критично, так как правила нормализации слов при создании Synonyms Map зависят от определенного языка документа.
• Учитывайте транслитерацию в семантике: В языках, где часто используется транслитерация (например, Хинди/Roman Indic, Русский), полезно понимать, какие транслитерированные запросы могут приводить на ваш контент. Система может связывать транслитерированные запросы с контентом в оригинальном скрипте.
• Стратегия для «Малых языков»: При работе с сайтами на слабо представленных языках (например, Исландский, Латышский) фокусируйтесь на максимальной точности. Механизм защиты (Claim 1) может ограничить расширение запросов. Если пользователи ищут с акцентами, критически важно иметь контент, точно соответствующий этому написанию.

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

• Намеренное упрощение контента: Не следует удалять акценты или использовать диграфы вместо специальных символов в контенте. Система Google спроектирована для решения этой проблемы на стороне запроса, а не на стороне контента.
• Смешивание языков в одном документе: Это может затруднить определение основного языка документа, что приведет к некорректной нормализации слов и ошибкам в Synonyms Map.
• Игнорирование языка интерфейса пользователя: При анализе трафика учитывайте, через какой интерфейс приходят пользователи. Это влияет на то, как Google интерпретирует и переписывает их запросы, особенно в случае с Small Languages.

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

Патент демонстрирует стремление Google понимать и уважать лингвистические нюансы и конвенции разных языков, вместо того чтобы применять универсальную «грубую» нормализацию. Стратегически это означает, что для успешного международного SEO необходимо глубокое понимание целевого языка, включая его орфографию, использование диакритики и практику транслитерации. Создание авторитетного контента, соблюдающего языковые нормы, является долгосрочным преимуществом.

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

Сценарий 1: Обработка диакритики (Доминирующий язык - Французский)

1. Контент: Страница на французском: «Les éléphants d'Afrique».
2. Запрос пользователя: Пользователь с французским интерфейсом ищет «elephants afrique».
3. Процесс Google: Язык интерфейса — не «малый». Google определяет Query Language как французский. Запрос упрощается до «elephant afrique». Исходная форма = Упрощенной.
4. Переписывание: Система находит вариант «éléphants» в Synonyms Map с высокой частотностью во французском. Запрос переписывается как «(elephants OR éléphants) afrique».
5. Результат: Страница с правильной орфографией высоко ранжируется.

Сценарий 2: Защита «Малого языка» (Исландский) — Ввод с акцентами

1. Контекст: Исландский язык слабо представлен (Small Language).
2. Запрос пользователя: Пользователь с исландским интерфейсом ищет «Hár» (Волосы).
3. Процесс Google: Интерфейс — «малый язык». Исходный термин «Hár». Упрощенная форма «Har». Исходная форма ≠ Упрощенной.
4. Результат: Согласно Claim 1, система ищет только «Hár» и НЕ добавляет синонимы, чтобы избежать показа нерелевантных результатов для английского «Har».

Сценарий 3: Защита «Малого языка» (Исландский) — Ввод без акцентов

1. Запрос пользователя: Тот же пользователь ищет «Har».
2. Процесс Google: Интерфейс — «малый язык». Исходная форма «Har». Упрощенная форма «Har». Исходная форма = Упрощенной.
3. Результат: Согласно Claim 1, система ищет варианты в Synonyms Map и может расширить запрос до «(Har OR Hár)».