Как Google разбирает сложные составные запросы на отдельные подзапросы для повышения качества ответов

Описание

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

Патент решает проблему неэффективной обработки сложных или составных запросов (compound queries), содержащих несколько независимых интентов. Традиционно пользователи вынуждены задавать такие вопросы последовательно (например, спросить о погоде, дождаться ответа, затем спросить о времени), что увеличивает время взаимодействия и количество необходимых транзакций. Изобретение направлено на то, чтобы позволить системе автоматически идентифицировать множественные интенты в одном запросе и отвечать на них параллельно.

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

Запатентована система и метод для динамического разделения одного входящего запроса на набор из двух или более подзапросов (subqueries). Ключевым элементом является механизм оценки качества (Quality Score или Measure). Система сравнивает ожидаемое качество выполнения набора подзапросов с качеством выполнения исходного запроса целиком и выбирает стратегию, которая с большей вероятностью удовлетворит пользователя.

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

Система работает в несколько этапов:

• Генерация кандидатов (Subquery Set Generator): Исходный запрос анализируется для поиска точек разделения (например, по союзу «и», спискам сущностей). Генерируются различные наборы подзапросов. Также может происходить расширение концепций в списки сущностей.
• Оценка качества (Subquery Set Scorer): Каждому набору и исходному запросу присваивается Quality Score. Эта оценка базируется на таких факторах, как частота запроса в логах, наличие известного ответа (Known Answer) или соответствие голосовому действию (Voice Action).
• Выбор стратегии (Subquery Set Selector): Система выбирает вариант (исходный запрос или лучший набор подзапросов) с наивысшей оценкой качества.
• Выполнение (Subquery Set Responder): Выполняются выбранные запросы. Если выбран набор подзапросов, система предоставляет пользователю несколько ответов по отдельности.

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

Высокая. С ростом популярности голосового поиска и диалоговых ассистентов (Google Assistant) способность эффективно обрабатывать естественные, сложные и составные запросы становится критически важной. Учитывая дату публикации (2025 год) и участие ключевых фигур Google (Behshad Behzadi), эти методы являются центральными для развития Conversational AI.

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

Влияние на SEO оценивается как значительное (7/10). Хотя патент фокусируется на Понимании Запросов (Query Understanding), а не на ранжировании, он демонстрирует, как Google декомпозирует сложные интенты до атомарных подзапросов. Это критически важно для VSO (Voice Search Optimization) и оптимизации под прямые ответы. Чтобы быть видимым, контент должен четко отвечать на конкретные, независимые вопросы, которые система предпочитает при оценке подзапросов.

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

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

Query (Запрос)

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

Subquery (Подзапрос)

Запрос, сгенерированный из части исходного запроса. Представляет собой отдельный интент.

Subquery Set (Набор подзапросов)

Группа из двух или более подзапросов, сгенерированных из одного исходного запроса.

Quality Score / Measure (Оценка качества / Мера)

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

Voice Action Operation (Операция голосового действия)

Действие, которое система может выполнить в ответ на команду (например, «включи свет»). Соответствие подзапроса такому действию повышает Quality Score.

Question with a Known Answer (Вопрос с известным ответом)

Вопрос, на который система может предоставить прямой, фактологический ответ (например, из Knowledge Graph). Соответствие такому вопросу повышает Quality Score.

N-gram Replacer (Заменитель N-грамм)

Компонент, который заменяет концептуальные фразы в запросе списками конкретных сущностей (например, заменяет «швейцарские горнолыжные курорты» на «Церматт, Санкт-Мориц, Давос»).

List Identifier (Идентификатор списка)

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

Particular Characters (Особые символы)

Символы или слова (например, «и», пробелы), используемые как потенциальные точки разделения запроса.

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

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

1. Система получает запрос.
2. На основе предварительной обработки (pre-processing) определяется позиция particular characters (например, слова «и»).
3. Генерируется набор из двух подзапросов путем разделения исходного запроса по этой позиции (до и после).
4. Определяется First Measure (Первая Мера) для исходного запроса, отражающая вероятность удовлетворения пользователя.
5. Определяется Second Measure (Вторая Мера) для набора подзапросов, отражающая вероятность удовлетворения пользователя.
6. Происходит сравнение Первой и Второй Мер.
7. Ключевое условие: Если Вторая Мера превышает Первую Меру, система предоставляет отдельные ответы для первого и второго подзапросов.

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

Claim 2 (Зависимый от 1): Уточняет альтернативное действие.

Если Первая Мера (исходный запрос) превышает Вторую Меру (набор подзапросов), система предоставляет единый ответ на исходный запрос.

Claim 4 (Зависимый от 1): Детализирует расчет Второй Меры.

Определение Второй Меры включает определение частоты (frequency), с которой подзапрос ранее отправлялся пользователями (анализ логов поиска). Система предпочитает разделения, которые приводят к популярным и естественным формулировкам запросов.

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

Изобретение применяется на этапе понимания запроса и определяет стратегию его дальнейшего выполнения.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения патента. Система функционирует как механизм интерпретации и переписывания запросов (Query Rewriting).

• Компоненты: Subquery Set Generator, Scorer и Selector работают здесь. Также задействуются N-gram Replacer и List Identifier для предварительной обработки.
• Процесс: Происходит анализ запроса, генерация кандидатов на разделение, их оценка на основе внешних данных (логи запросов, базы знаний, голосовые действия) и принятие решения о маршрутизации.

RANKING / METASEARCH (Выполнение)
Решение, принятое на этапе QUNDERSTANDING, определяет, что будет передано системам ранжирования или выполнения команд. Вместо одного сложного запроса система может инициировать два или более простых параллельных поиска или выполнения команд.

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

• Исходный запрос пользователя.
• Логи предыдущих запросов пользователей (log of prior queries).
• Базы данных Known Answers и Voice Action Operations.
• Данные о сущностях и их связях (для N-gram Replacer).

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

• Решение о том, какой запрос(ы) выполнять (исходный или набор подзапросов).
• Один или несколько ответов (результаты поиска, выполненные действия, прямые ответы).

На что влияет

• Специфические запросы: Наибольшее влияние на составные запросы (с союзами типа «и»), запросы с перечислениями (списками, например, «погода в X, Y и Z») и сравнительные запросы («что лучше, X или Y»).
• Типы контента и форматы: Система явно предпочитает контент, который предоставляет прямые ответы (Known Answer) или соответствует командам. Это повышает важность FAQ, структурированных данных и контента, оптимизированного под Knowledge Graph и Featured Snippets.
• Контекст использования: Влияние максимально в средах Google Assistant и голосового поиска, где пользователи чаще используют естественные и составные формулировки.

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

• Триггеры активации: Наличие в запросе потенциальных разделителей (particular characters, например, союзы, запятые) или идентификация списков сущностей/концепций.
• Условия применения: Алгоритм разделения применяется только тогда, когда оценка качества (Second Measure) набора подзапросов превышает оценку качества (First Measure) исходного запроса. Также может требоваться превышение минимального порога (Quality Threshold).

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

Этап 1: Получение и предварительная обработка запроса

1. Получение исходного запроса.
2. N-Gram Replacement (Опционально): N-gram Replacer заменяет концептуальные фразы (например, «швейцарские курорты») на списки сущностей (например, «Церматт, Давос…»).
3. List Identification (Опционально): List Identifier определяет структуру списка в запросе.

Этап 2: Генерация наборов подзапросов (Subquery Set Generator)

1. Генерация кандидатов (Subquery Sets). Методы включают:
   • Разделение запроса по позициям particular characters (например, «и»).
   • Разделение запроса по пробелам (перебор вариантов).
   • Расширение списка (Query Expander) в отдельные подзапросы для каждого элемента.

Этап 3: Оценка качества (Subquery Set Scorer)

1. Расчет First Measure (Quality Score) для исходного запроса.
2. Расчет Second Measure (Quality Score) для каждого сгенерированного набора подзапросов. При расчете учитывается:
   • Частота (frequency) появления подзапросов в логах поиска.
   • Количество результатов поиска для подзапросов.
   • Соответствие подзапросов Voice Action или Known Answer.
   • Полнота использования слов исходного запроса.

Этап 4: Выбор стратегии (Subquery Set Selector)

1. Выбор набора подзапросов с наивысшим Second Measure.
2. Проверка, превышает ли этот Second Measure установленный Quality Threshold.
3. Сравнение наивысшего Second Measure с First Measure исходного запроса.
   • Если Second Measure > First Measure (и порог пройден): Выбрать набор подзапросов.
   • Если First Measure >= Second Measure: Выбрать исходный запрос.

Этап 5: Выполнение и ответ (Subquery Set Responder)

1. Выполнение выбранного запроса или набора подзапросов (параллельно или последовательно, если они зависимы).
2. Агрегация ответов и предоставление их пользователю.

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

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

Патент упоминает использование следующих данных для принятия решений:

• Поведенческие факторы (Логи запросов): Критически важные данные. Используются логи предыдущих запросов от множества пользователей (log of prior queries). Частота (frequency) появления подзапроса в этих логах является ключевым фактором для расчета Quality Score (Claim 4).
• Данные Knowledge Graph / Базы знаний: Система проверяет, соответствует ли подзапрос вопросу с известным ответом (Question with a Known Answer). Также используются для N-Gram Replacement (связи между концепциями и сущностями).
• Системные данные (Голосовые действия): База данных поддерживаемых команд (Voice Action Operation).
• Контентные/Индексные данные: Упоминается использование количества результатов поиска (number of search results), отзывчивых на подзапрос, как фактора для расчета Quality Score.

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

• Quality Score (First Measure / Second Measure): Агрегированная метрика вероятности удовлетворенности пользователя. Патент не приводит формулы, но указывает, что она рассчитывается на основе комбинации факторов:
  • Frequency in logs: Чем выше частота, тем выше оценка.
  • Known Answer/Voice Action Match: Соответствие значительно повышает оценку.
  • Number of Search Results: Большее количество результатов может повышать оценку.
  • Term Coverage: Метрики, учитывающие, сколько слов из исходного запроса покрыто подзапросами (предпочтение отдается полному покрытию).
• Quality Threshold (Порог качества): Предопределенное пороговое значение для фильтрации низкокачественных вариантов разделения.

Выводы

1. Приоритет атомарных интентов: Google активно стремится декомпозировать сложные пользовательские запросы до уровня атомарных, независимых интентов (подзапросов). Это позволяет системе более точно удовлетворять потребности пользователя.
2. Дата-ориентированный подход к разделению: Решение о разделении запроса не является эвристическим (например, всегда делить по союзу «и»). Оно основано на сравнении Quality Score: запрос разделяется только если система уверена, что это улучшит результат.
3. Критическая роль логов поиска (Поведенческие данные): Частота запросов в логах (Frequency) является одним из основных сигналов для валидации сгенерированных подзапросов (Claim 4). Google проверяет, формулируют ли пользователи свои запросы подобным образом.
4. Предпочтение прямым ответам и действиям: При оценке качества подзапросов система отдает предпочтение тем, которые соответствуют Known Answers или Voice Actions. Это подтверждает стратегическую важность оптимизации под прямые ответы.
5. Механизм расширения концепций (N-Gram Replacement): Система может автоматически расширять общие концепции в списки конкретных сущностей (например, «погода на курортах» -> список запросов о погоде на каждом курорте). Это подчеркивает важность понимания связей между сущностями.

Практика

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

• Оптимизация под прямые ответы (FAQ/Q&A): Поскольку соответствие Known Answer является сильным сигналом качества для подзапроса, необходимо создавать контент, который четко и лаконично отвечает на конкретные вопросы. Используйте формат FAQ и соответствующую микроразметку. Это повышает вероятность использования вашего контента для ответа на часть составного запроса.
• Использование естественных и популярных формулировок: Анализируйте реальные запросы пользователей. Поскольку система использует частоту в логах (Frequency) для оценки качества подзапросов, оптимизация под популярные и естественные формулировки повышает вероятность того, что ваш контент будет релевантен сгенерированным подзапросам.
• Укрепление связи сущностей и Topical Authority: Механизм N-gram Replacer показывает, что Google преобразует общие понятия в списки сущностей. Развивайте авторитетность по конкретным сущностям внутри темы. Если вы пишете о «швейцарских курортах», убедитесь, что вы авторитетны по «Церматту», «Давосу» и т.д.
• Структурирование данных для сравнений: При сравнении продуктов или сущностей четко указывайте их атрибуты. Это облегчает системе извлечение данных при обработке сравнительных запросов (например, преобразование «Кто старше, X или Y» в подзапросы «Возраст X» и «Возраст Y»).

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

• Создание контента под неестественные или редкие ключевые фразы: Использование формулировок, которые редко встречаются в логах пользователей, неэффективно. Система понизит Quality Score таких интерпретаций.
• Создание «размытого» контента без конкретики: Контент, который пытается ответить на слишком много разнородных вопросов без четкой структуры, будет иметь низкий потенциал для удовлетворения подзапросов, ищущих Known Answer.
• Игнорирование простых интентов: Фокусировка исключительно на сложных, длинных запросах рискованна, так как Google может предпочесть разделить их и искать ответы на более простые компоненты.

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

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

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

Сценарий 1: Обработка составного запроса (на основе FIG. 1 патента)

1. Исходный запрос: «What time is it in Turks and Caicos and what time is it now» (Который час на Теркс и Кайкос и который час сейчас).
2. Генерация (Generator): Система генерирует варианты разделения.
   • Сет А (разделение по первому «and»): «What time is it in Turks» / «Caicos and what time is it now».
   • Сет Б (разделение по второму «and»): «What time is it in Turks and Caicos» / «what time is it now».
3. Оценка (Scorer): Сет А получает низкий балл (30%), так как подзапросы редко встречаются в логах и плохо сформированы. Сет Б получает высокий балл (95%), так как оба подзапроса частотны и ведут к Known Answers.
4. Выбор и выполнение (Selector/Responder): Выбирается Сет Б. Пользователь получает два ответа: «It’s 4:34 PM in Turks and Caicos» и «It’s 1:34 PM in Mountain View».

Сценарий 2: Расширение концепции (на основе FIG. 2 патента)

1. Исходный запрос: «What is the weather in Swiss ski resorts» (Какая погода на швейцарских горнолыжных курортах).
2. Предварительная обработка (N-Gram Replacer): Система заменяет «Swiss ski resorts» на список сущностей: «Zermatt, St. Moritz, Davos, and Engelberg».
3. Генерация (Query Expander): Система идентифицирует список и генерирует набор подзапросов: «Weather in Zermatt», «Weather in St. Moritz», «Weather in Davos», «Weather in Engelberg».
4. Оценка и выполнение: Набор получает высокий Quality Score, так как подзапросы ведут к Known Answers. Система выполняет 4 подзапроса и предоставляет 4 ответа о погоде.

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