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

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

Context Consistency Measure (P(c|e)) (Мера согласованности контекста)

Оценка вероятности того, что контекстный термин 'c' появится в тексте, при условии, что в этом тексте присутствует имя сущности 'e'. Ключевая метрика для определения силы связи между сущностью и контекстом.

Context Term (Контекстный термин)

Слово или фраза, появляющиеся в тексте рядом с именем сущности. В контексте обработки запроса — это слова в запросе, не являющиеся именем сущности.

Context-Entity Name Index (Индекс контекста и имен сущностей)

Структура данных (индекс), хранящая name-context pairs и связанные с ними метрики (Context Consistency Measure, Popularity Measurement). Позволяет быстро находить сущности по заданному контексту.

Entity Name (Имя сущности)

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

Fingerprint Buckets (Бакеты отпечатков)

Механизм для группировки схожих источников текста (например, на основе хеша контента или URL). Используется для обнаружения дублированного контента и предотвращения искусственного завышения оценок (Claims 14, 15).

Mistyping Probability (P(e'|e)) (Вероятность опечатки)

Оценка вероятности того, что пользователь, введя имя 'e'', на самом деле имел в виду имя 'e'. Может рассчитываться на основе расстояния редактирования (Edit Distance, Bucket Distance) или анализа логов запросов (как часто пользователи исправляют 'e'' на 'e').

Name-Context Pair (Пара имя-контекст)

Структура данных, связывающая Entity Name и Context Term, которые встретились вместе в исходном тексте.

Popularity Measurement (P(e)) (Мера популярности)

Оценка вероятности появления имени сущности 'e' в тексте. Отражает общую частотность или известность сущности (Claim 7).

Window of Text (Окно текста)

Область текста, ассоциированная с именем сущности, из которой извлекаются контекстные термины. Может включать заданное количество слов до и после имени, заголовок документа (Title), анкорный текст (Anchor Text) ссылок или даже текст предыдущих запросов пользователя в рамках сессии (Claim 6).

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

Патент описывает как офлайн-процесс создания индекса, так и онлайн-процесс его использования для исправления запросов.

Claim 1, 20 (Независимые пункты): Описывают офлайн-процесс генерации индекса контекста и сущностей.

1. Система получает тексты из множества источников (Text Sources).
2. Из текстов извлекаются множественные name-context pairs.
3. Для каждой уникальной пары вычисляется Context Consistency Measure ($P(c|e)$). Эта мера оценивает вероятность того, что если имя сущности появляется в тексте, то и контекстный термин также появится в этом тексте.
4. Система сохраняет данные (context-entity name data) в виде поисковой структуры (индекса).

Claim 11 (Зависимый от 1): Детализирует процесс фильтрации данных в индексе.

1. Система генерирует оценку (score) для каждой name-context pair.
2. Пары, чья оценка ниже определенного порога, исключаются из индекса.

Claim 12 (Зависимый от 11): Определяет, как рассчитывается оценка для фильтрации.

Оценка для пары рассчитывается на основе $P(c|e)$ этой пары и средней меры согласованности для данного контекстного термина со всеми сущностями. Это позволяет выделить пары, где связь значительно сильнее средней (т.е. контекст специфичен для сущности).

Claim 14 и 15 (Зависимые от 11): Описывают механизм корректировки оценок для борьбы со спамом или дублированным контентом (Anti-Spam/Anti-Duplication).

Если пара имя-контекст извлечена из нескольких источников, система анализирует схожесть этих источников (используя Fingerprint Buckets, Claim 15). Если распределение источников сильно искажено (skewed from a normal distribution), что указывает на дублирование контента, оценка этой пары дисконтируется (понижается). Это предотвращает искусственное завышение оценок из-за многократного повторения одного и того же текста.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит офлайн-обработка данных для построения Context-Entity Name Index. Система анализирует текстовые источники (веб-документы, логи запросов), извлекает сущности, определяет их контекст (Window of Text) и рассчитывает ключевые метрики: $P(c|e)$ и $P(e)$. Также на этом этапе могут рассчитываться данные для $P(e'|e)$ на основе анализа логов исправлений запросов пользователями.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения изобретения в реальном времени. Когда пользователь вводит запрос, система (Spell Correction Engine) использует описанный механизм для анализа запроса, определения потенциальной сущности и контекста, и использования Context-Entity Name Index для поиска и оценки вероятных правильных написаний (Query Rewriting).

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

• Исходный запрос пользователя.
• Данные текущей поисковой сессии пользователя (для дополнительного контекста).
• Context-Entity Name Index.
• Данные о вероятностях опечаток (Mistyping Probability).

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

• Исправленный запрос (для автоматического использования поиском).
• ИЛИ Предложение по исправлению запроса (например, блок "Did you mean?").
• ИЛИ Список возможных вариантов исправления.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на запросы, содержащие имена сущностей (брендовые запросы, персональные запросы, названия продуктов). Особенно критично для сущностей, которые не являются общеизвестными и отсутствуют в стандартных словарях.
• Конкретные ниши: Влияет на все ниши, но особенно заметно в локальном поиске (поиск конкретных специалистов или местных бизнесов по имени/названию), электронной коммерции (поиск нишевых брендов или моделей) и контентных проектах (поиск авторов, экспертов).

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

• Триггеры активации: Алгоритм активируется, когда система идентифицирует в запросе потенциальное имя сущности (часто определяемое как редкий термин или последовательность терминов, похожая на имя) в сочетании с другими контекстными словами.
• Условия работы и Исключения: Применяется, когда стандартные методы проверки орфографии не дают уверенного результата. Патент также упоминает, что система может не активироваться, если исходное имя сущности уже достаточно популярно (высокий $P(e)$) или если связь между исходным именем и контекстом уже достаточно сильна (высокий Relation Score).

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

Процесс А: Офлайн-генерация индекса (Index Generation)

1. Сбор данных: Получение текстов из источников (веб-документы, логи запросов).
2. Извлечение пар: Идентификация имен сущностей (e) в текстах. Для каждой сущности определяется Window of Text (окружающие слова, заголовки, анкоры, предыдущие запросы сессии). Из этого окна извлекаются контекстные термины (c), формируя name-context pairs.
3. Расчет согласованности контекста: Для каждой уникальной пары (e, c) вычисляется Context Consistency Measure $P(c|e)$.
4. Расчет популярности: Для каждой сущности 'e' вычисляется Popularity Measurement $P(e)$.
5. Фильтрация и оценка пар: Расчет оценки (score) для каждой пары, чтобы отфильтровать слабые связи. Оценка учитывает $P(c|e)$ в сравнении со средней согласованностью для этого контекста.
6. Детектирование дубликатов: Анализ источников пар с помощью Fingerprint Buckets. Если пара часто встречается в схожем контенте (спам, шаблоны), ее оценка дисконтируется (понижается).
7. Хранение: Сохранение обработанных данных в Context-Entity Name Index.

Процесс Б: Онлайн-исправление запроса (Spell Correction)

1. Получение запроса.
2. Идентификация компонентов: Запрос разделяется на предполагаемое имя сущности (e', возможно с опечаткой) и контекстные термины (c).
3. Генерация кандидатов: Система ищет кандидатов на исправление (e) в Context-Entity Name Index. Поиск осуществляется по контекстным терминам (c) и/или частям имени e'.
4. Фильтрация кандидатов (Опционально): Кандидаты могут фильтроваться по степени отличия от исходного имени e' (например, используя Edit Distance или Bucket Distance).
5. Оценка кандидатов: Для каждого кандидата 'e' рассчитывается итоговая оценка. Приблизительная формула: $P(e) \times P(c|e) \times P(e'|e)$.
6. Выбор и ответ: Выбирается кандидат с наивысшей оценкой. Система использует его для генерации ответа (автоматическое исправление запроса, предложение "Did you mean?" и т.д.).

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

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

• Контентные факторы: Текст веб-документов. Система анализирует текст, окружающий имена сущностей (Window of Text).
• Структурные факторы: Упоминается использование заголовков документов (Title) как части Window of Text (Claim 6).
• Ссылочные факторы: Упоминается возможность использования анкорного текста (Anchor Text) ссылок, ведущих на документ или из него, как части Window of Text.
• Поведенческие факторы (Логи запросов): Query Logs и Query Sessions используются многократно:
  1. Как источник текстов для построения индекса (анализ того, какие сущности и контексты пользователи вводят вместе) (Claim 4).
  2. Для расчета Mistyping Probability $P(e'|e)$ путем анализа того, как часто пользователи исправляют одно написание на другое в рамках сессии.
  3. Для определения связанных имен (Related Names/Nicknames) на основе последовательных уточнений запросов (Claim 17).
• Технические факторы: URL или домены документов используются в процессе дисконтирования оценок для обнаружения дублированного контента (с помощью Fingerprint Buckets) (Claim 15).
• Пользовательские факторы: История поиска пользователя в текущей сессии может использоваться как дополнительный контекст (Window of Text) при исправлении текущего запроса.

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

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

1. Context Consistency Measure $P(c|e)$: Оценивает, насколько хорошо контекст запроса соответствует кандидату. Рассчитывается офлайн. Пример формулы: (Количество раз, когда 'c' появляется в окнах для 'e') / (Общее количество терминов в окнах для 'e').
2. Popularity Measurement $P(e)$: Оценивает общую вероятность кандидата. Рассчитывается офлайн. Пример формулы: (Количество встреч сущности 'e') / (Общее количество встреч всех сущностей).
3. Mistyping Probability $P(e'|e)$: Оценивает вероятность того, что исходное написание e' является опечаткой для кандидата e.

Итоговая оценка (Score): Итоговая оценка кандидата 'e' при запросе с именем 'e'' и контекстом 'c' аппроксимируется как произведение этих трех метрик:

$\text{Score} \approx P(e) \times P(c|e) \times P(e'|e)$

1. Контекст определяет сущность для целей исправления: Ключевой вывод патента заключается в том, что слова, окружающие имя сущности (в запросе и в индексе), являются определяющими для её идентификации, особенно когда имя написано с ошибкой. Система полагается на Context Consistency Measure как на основной сигнал релевантности.
2. Триангуляция сигналов (Трехфакторная модель): Эффективное исправление достигается за счет комбинации трех факторов: насколько хорошо контекст подходит к сущности ($P(c|e)$), насколько популярна сущность в целом ($P(e)$) и насколько вероятно, что исходное написание было опечаткой для данного кандидата ($P(e'|e)$).
3. Важность "Окна Текста" и Структурных Элементов: Определение Window of Text критически важно. Оно включает не только близлежащие слова на странице, но явно упоминает заголовки (Titles) и анкорные тексты (Anchor Texts), подтверждая их роль в формировании контекста сущности.
4. Защита от манипуляций (Anti-Spam): Патент включает конкретные механизмы (Fingerprint Buckets) для предотвращения искусственного завышения оценок путем дисконтирования данных, полученных из дублированного или шаблонного контента (boilerplate content).
5. Зависимость от поведения пользователей: Система активно обучается на поведении пользователей, используя логи запросов как для построения индекса контекста, так и для определения вероятностей опечаток, связанных имен (синонимов/псевдонимов) и использования истории сессии как контекста.

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

• Создание сильных контекстных ассоциаций (Co-occurrence): Необходимо активно управлять контекстом вокруг ключевых сущностей (названия бренда, продуктов, имена экспертов). Убедитесь, что эти сущности постоянно упоминаются вместе с релевантными дескрипторами (например, "[Бренд] + [Категория продукта]" или "[Имя] + [Должность/Специализация]") как на сайте, так и на внешних ресурсах. Это увеличивает Context Consistency Measure $P(c|e)$.
• Оптимизация заголовков и анкоров: Поскольку патент явно указывает, что заголовки (Titles) и анкорные тексты (Anchor Text) являются частью Window of Text, их следует оптимизировать для укрепления связи между сущностью и ее контекстом. Входящие ссылки и внутренняя перелинковка должны использовать релевантный контекст.
• Повышение популярности сущности (P(e)): Работайте над увеличением количества качественных упоминаний сущности в интернете (Digital PR, контент-маркетинг). Чем выше Popularity Measurement $P(e)$, тем выше вероятность, что система предложит вашу сущность в качестве исправления при опечатке.
• Консистентность NAP для локального SEO: Для локального бизнеса критически важно обеспечить единообразное упоминание названия компании (Name) вместе с элементами адреса (Address, Phone). Это создает сильную контекстную связь с локацией, помогая корректно обрабатывать локальные запросы с опечатками.

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

• Изоляция сущностей: Размещение названия бренда или имени человека без окружающего релевантного контекста. Это затрудняет формирование name-context pairs.
• Размытие контекста: Использование названия бренда в слишком широком или нерелевантном контексте может ослабить сильные тематические ассоциации, снижая $P(c|e)$ для целевых терминов.
• Манипуляции через дублированный контент: Попытки искусственно завысить $P(c|e)$ путем тиражирования одинаковых текстов (boilerplate content) на разных сайтах или страницах. Патент явно описывает механизм (Fingerprint Buckets) для дисконтирования оценок, полученных из схожих источников.

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

Патент подтверждает стратегическую важность управления семантическим окружением сущностей (Entity Context Management). Для SEO это означает, что работа над брендом должна включать не только наращивание упоминаний, но и контроль за тем, в каком контексте эти упоминания происходят. Система демонстрирует, как Google использует статистический анализ совместной встречаемости (co-occurrence) для разрешения неоднозначностей и понимания намерений пользователя, что является базовым принципом семантического поиска и перехода к Entity-Oriented Search.

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

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

Цель: Гарантировать, что при опечатках в фамилии доктора Google правильно идентифицирует его, используя контекст специализации и города.

1. Анализ сущности и контекста: Сущность (e) — "Dr. William Jones". Ключевой контекст (c) — {"Doctor", "Sparta", "Wisconsin"}. Частая опечатка (e') — "Will Jonis".
2. Действия по оптимизации (Усиление P(c|e)):
   • На странице профиля доктора убедиться, что его имя находится в непосредственной близости от контекстных терминов в основном контенте.
   • Включить эти термины в Title страницы.
   • При получении ссылок (например, из локальных каталогов) стараться, чтобы анкорный текст или околоссылочный текст включал эти контекстные термины.
3. Результат: Когда пользователь вводит запрос "doctor will jonis sparta wisconsin", система использует контекст для поиска кандидатов. "William Jones" получит высокую оценку благодаря сильному $P(c|e)$ и высокой вероятности опечатки $P(e'|e)$ (Jonis -> Jones), и будет предложен в качестве исправления.