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

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

Candidate Corrections (Кандидаты на исправление)

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

Correction Prefix (Префикс коррекции)

Начальная фраза во втором запросе, указывающая на намерение пользователя исправить предыдущий запрос (например, «No I meant», «I said»).

Correction Request (Запрос на коррекцию)

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

Misrecognition Index (Индекс ошибок распознавания)

База данных, содержащая фонетически похожие n-граммы. Используется для поиска потенциальных замен для ошибочно распознанного термина с учетом контекста или типа.

Phonetic Distance / Phonetic Quality (Фонетическое расстояние / Фонетическое качество)

Мера схожести звучания между исходным термином и термином-кандидатом. Используется для оценки вероятности того, что один термин был ошибочно распознан как другой.

Query Popularity / Query Quality (Популярность запроса / Качество запроса)

Метрика, оценивающая вероятность того, что пользователь намеревался ввести именно этот запрос. Основывается на частоте использования запроса в логах (query logs) и его семантическом качестве.

Recognition Output (Результат распознавания)

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

Voice Query (Голосовой запрос)

Аудиоввод пользователя, предназначенный для поиска.

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

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

1. Система получает первый голосовой запрос и генерирует его текстовое распознавание.
2. Система получает второй голосовой запрос.
3. Определяется, что распознавание второго запроса активирует запрос на коррекцию. Ключевой момент: это определение включает парсинг второго запроса для обнаружения correction prefix.
4. Используя распознавание первого и второго запросов, система генерирует набор кандидатов на исправление.
5. Каждый кандидат оценивается (scoring).
6. Генерируется скорректированный результат распознавания для кандидата, чья оценка удовлетворяет пороговому значению.

Claim 2 (Зависимый): Детализирует процесс генерации кандидатов.

1. Определяется ошибочно распознанная часть (misrecognition portion) первого результата распознавания.
2. Эта часть заменяется одной или несколькими кандидатными n-граммами для формирования кандидата на исправление.

Claim 3 (Зависимый): Указывает источники для получения кандидатных n-грамм.

• Распознавание корректирующей части второго запроса.
• Сгенерированные гипотезы (альтернативные варианты распознавания) корректирующей части второго запроса.
• Misrecognition index, содержащий фонетически похожие n-граммы.
• N-граммы, ассоциированные с типом или категорией, связанными с корректирующей частью второго запроса.

Claim 4 (Зависимый): Указывает фактор оценки.

• Оценка кандидата основывается, по крайней мере частично, на phonetic distance между кандидатом на исправление и первым голосовым вводом.

Claim 5, 6, 7 (Зависимые): Указывают дополнительные факторы оценки.

• Оценка кандидата основывается на query popularity (Claim 5).
• Популярность определяется по количеству совпадений в query log (Claim 6).
• Популярность основывается на изменении популярности между первым запросом и кандидатом на исправление (Claim 7).

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

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

QUNDERSTANDING – Понимание Запросов
Это основной этап применения патента. Система (в частности, Voice Query Correction Engine) работает в режиме реального времени сразу после получения голосового ввода и его первичной транскрипции с помощью Voice Recognition Engine (ASR).

1. Обработка последовательности: Система анализирует два последовательных голосовых запроса в рамках одной сессии.
2. Интерпретация намерения: Определяется, является ли второй запрос новым поиском или попыткой исправить первый. Это происходит путем анализа грамматик и поиска correction prefix.
3. Перезапись запроса (Query Rewriting): Если это коррекция, система генерирует и оценивает альтернативные формулировки запроса, используя лингвистические, фонетические и статистические данные.
4. Финальный запрос: Скорректированный текстовый запрос затем передается на этап RANKING.

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

• Аудиоданные первого и второго голосовых запросов.
• Результаты распознавания (транскрипции) и альтернативные гипотезы ASR для обоих запросов.
• Misrecognition Index (фонетические данные).
• Query Logs (статистические данные о популярности запросов).

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

• Единый скорректированный текстовый запрос (corrected recognition output).

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на голосовые запросы, содержащие имена собственные, названия брендов, топонимы или термины, которые имеют фонетически схожие, но семантически разные варианты (омофоны или близкие по звучанию слова). Пример в патенте: [Baroque artists] vs [Broke artists].
• Типы контента и Ниши: Патент не делает различий по типам контента или тематикам. Он применяется универсально ко всем голосовым взаимодействиям.

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

• Условия работы: Алгоритм применяется в рамках одной поисковой сессии при получении последовательных голосовых вводов.
• Триггеры активации: Активация происходит, когда система обнаруживает, что второй голосовой запрос соответствует одной из предопределенных грамматик коррекции. Патент приводит примеры таких грамматик, включая:
  • Использование correction prefix («No I meant...»).
  • Команда замены («No, not X, Y»).
  • Уточнение типа или категории («I meant the country»).
  • Диктовка по буквам («It's spelled O-S-L-O»).

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

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

1. Система получает первый голосовой запрос.
2. Генерируется первый результат распознавания (транскрипция) с помощью ASR. (Например, пользователь сказал «Baroque artists», система распознала [Broke artists]).
3. Система получает второй голосовой запрос. (Например, «No I meant baroque artists»).

Этап 2: Детекция коррекции

1. Система анализирует распознавание второго запроса на наличие триггеров коррекции.
2. Проверяется соответствие грамматикам коррекции, например, ищется correction prefix.
3. Если коррекция не обнаружена, второй запрос обрабатывается как новый поиск.
4. Если коррекция обнаружена, запускается процесс исправления.

Этап 3: Генерация кандидатов (Candidate Generation)

1. Система определяет ошибочно распознанную часть первого запроса и корректирующую информацию из второго запроса.
2. Генерируются кандидаты на исправление с использованием нескольких методов:
   • Прямое распознавание: Использование распознанной корректирующей части из второго запроса для замены.
   • Гипотезы ASR: Использование альтернативных вариантов распознавания второго запроса (если ASR не уверена).
   • Misrecognition Analysis: Поиск в Misrecognition Index терминов, которые фонетически похожи на ошибочный термин.
   • Spelling Analysis: Если пользователь продиктовал слово по буквам, система собирает его.
   • Type/Category Analysis: Если пользователь указал категорию (например, «I meant the country»), система ищет фонетически похожие термины в этой категории.

Этап 4: Оценка кандидатов (Candidate Scoring)

1. Каждый кандидат оценивается для определения его достоверности. Используются следующие факторы:
   • Grammar matching: Уверенность системы в том, что грамматика коррекции была распознана верно.
   • Replacement phonetic quality: Оценка фонетического сходства. Насколько вероятно, что кандидат мог быть ошибочно распознан как исходный термин.
   • Query quality: Оценка популярности и семантического качества итогового кандидата (на основе query logs).
   • Replacement query quality: Оценка улучшения качества запроса по сравнению с исходным (например, сравнивается популярность [Baroque artists] и [Broke artists]).
2. Факторы комбинируются (возможно, с весами) для получения итоговой оценки кандидата.

Этап 5: Выбор и применение

1. Выбирается кандидат с наивысшей оценкой.
2. Если оценка превышает установленный порог уверенности, этот кандидат принимается как corrected recognition output.
3. Скорректированный запрос используется для поиска и предоставляется пользователю.

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

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

Патент фокусируется исключительно на обработке ввода и не упоминает традиционные SEO-факторы (контентные, ссылочные, технические).

• Пользовательские факторы (Ввод): Аудиоданные (Voice Queries) от пользователя.
• Системные данные (ASR): Текстовые транскрипции (Recognition Output) и альтернативные гипотезы распознавания речи.
• Фонетические данные: Misrecognition Index — база данных фонетически схожих n-грамм и их фонетических представлений.
• Поведенческие факторы (Статистика): Query Logs — исторические данные о частоте использования запросов, используемые для определения Query Popularity.
• Лингвистические данные: Предопределенные грамматики и префиксы (Correction Prefix) для идентификации намерения коррекции.

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

• Grammar Matching Confidence: Вероятность того, что второй запрос соответствует определенной грамматике коррекции.
• Replacement Phonetic Quality: Рассчитывается на основе фонетического расстояния (phonetic distance), например, с использованием фонетического редакционного расстояния (phonetic edit distance) между n-граммами.
• Query Popularity: Определяется на основе подсчета количества раз, когда запрос был введен пользователями, согласно query logs.
• Query Quality: Агрегированная метрика, включающая Query Popularity, семантическое качество запроса (pattern of the query) и вероятность того, что запрос приведет к прямому ответу (answer box).
• Replacement Query Quality: Сравнение Query Quality исходного запроса и скорректированного запроса. Оценивает степень улучшения запроса после перезаписи.

1. Фокус на диалоговом взаимодействии: Патент демонстрирует стремление Google сделать голосовой поиск более естественным и устойчивым к ошибкам распознавания речи, имитируя человеческий диалог.
2. Комбинированный подход к пониманию: Система использует комбинацию лингвистических правил (грамматики, префиксы), фонетического анализа (Misrecognition Index, Phonetic Distance) и статистических данных (Query Popularity) для интерпретации намерений пользователя.
3. Важность Query Logs: Популярность запроса (Query Popularity) является ключевым фактором для валидации исправлений. Система предпочитает исправления, которые приводят к часто используемым запросам.
4. Использование семантики для уточнений: Механизм Type/Category analysis показывает, что Google использует понимание сущностей и их типов для разрешения неоднозначностей (например, если пользователь говорит «я имел в виду страну», система ищет сущности типа «Country»).
5. Инфраструктурный характер: Патент описывает внутренние механизмы обработки ввода (ASR/NLP) и не дает прямых практических рекомендаций для SEO-оптимизации контента или сайтов.

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

Хотя патент является инфраструктурным и направлен на улучшение распознавания речи, он дает некоторое понимание приоритетов Google, которое можно учитывать в SEO-стратегии:

• Ориентация на устоявшиеся интенты: Система использует Query Popularity как важный сигнал для подтверждения корректности запроса. Это подтверждает важность оптимизации под запросы, которые реально используются аудиторией, а не под искусственно созданные или крайне редкие формулировки.
• Использование ясного и распространенного языка: При оптимизации под голосовой поиск следует использовать естественные формулировки, которые менее подвержены фонетической неоднозначности. Это снижает риск первичного неправильного распознавания ASR-системами.
• Четкое определение сущностей и их типов: Механизм Type/Category analysis показывает, что система может использовать категории для исправления ошибок. Использование структурированных данных (Schema.org) и четкое позиционирование контента помогает Google правильно идентифицировать тип сущности (например, продукт, место, организация), что может косвенно помочь в разрешении неоднозначностей при голосовом вводе.

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

• Попытки манипулировать механизмом коррекции: Этот механизм работает на уровне обработки ввода пользователя и не поддается влиянию со стороны SEO-специалистов.
• Оптимизация под фонетически сложные или двусмысленные термины без контекста: Если бренд или продукт имеет сложное название, необходимо предоставлять достаточно контекста на странице и использовать структурированные данные, чтобы помочь системам понять тематику и тип сущности.

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

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

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

Сценарий: Исправление названия бренда через указание категории (использование Type/Category Analysis)

1. Ситуация: SEO-специалист продвигает сайт компании «Cybereason» (решения по кибербезопасности).
2. Исходный голосовой запрос (Q1): Пользователь говорит «Cybereason».
3. Распознавание Q1: Система ошибочно распознает как [Cyber raisin] (Кибер изюм).
4. Второй голосовой запрос (Q2): Пользователь говорит «No, I meant the security company».
5. Активация механизма: Система распознает correction prefix «No, I meant» и определяет категорию «security company».
6. Генерация кандидатов (Type/Category Analysis): Система ищет сущности в категории «security company», которые фонетически похожи на [Cyber raisin].
7. Выбор кандидата: «Cybereason» идентифицируется как подходящий кандидат с высоким phonetic quality и соответствующим типом.
8. Результат: Система перезаписывает запрос на [Cybereason] и выдает релевантные результаты.
9. Действие SEO: Убедиться, что компания четко ассоциирована с категорией «security company» в Knowledge Graph и на собственном сайте (например, через Schema.org/Organization), чтобы облегчить системе процесс идентификации типа сущности при голосовой коррекции.