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

Описание

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

Патент решает проблему обработки последовательных запросов в рамках одной пользовательской сессии, особенно когда последующие запросы являются неполными (incomplete queries) или контекстуально зависимыми. Система обеспечивает глубокое понимание контекста (deep context understanding), позволяя пользователям взаимодействовать с поиском в более естественной, диалоговой манере (conversational search), не повторяя информацию, которая уже была установлена в предыдущих запросах или результатах.

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

Запатентована система для переписывания контекстуальных запросов. Когда система получает последовательность запросов (Q1, затем Q2) и определяет, что Q2 является неполным без контекста Q1, она идентифицирует грамматический шаблон (template) для Q2. Система извлекает недостающую информацию из контекстуальных данных Q1 (результаты поиска и метаданные) и использует шаблон для переписывания Q2 в полный, действенный запрос (Q3). Этот переписанный запрос Q3 затем используется для выполнения действия (например, поиска, установки напоминания, навигации).

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

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

• Установление контекста: После первого запроса (Q1) система сохраняет contextual data, включая результаты поиска и связанные метаданные (например, сущности, время, места).
• Анализ последующего запроса: При получении второго запроса (Q2) система проверяет, является ли он полным и связан ли с контекстом Q1 (например, по времени поступления или совпадению временных форм).
• Триггер переписывания: Если Q2 неполный (не хватает информации для выполнения действия), он помечается как incomplete query и активируется механизм переписывания.
• Применение шаблона: Система идентифицирует подходящий грамматический шаблон для Q2 (например, «напомнить [кому] за [время] до [событие]»).
• Контекстуальное заполнение: Недостающие элементы (labels) шаблона заполняются данными из контекста Q1.
• Генерация нового запроса: Генерируется полный запрос (Q3), который передается в Action Engine для выполнения.

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

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

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

Патент имеет высокое стратегическое значение для SEO (7.5/10), особенно в контексте оптимизации под диалоговый поиск и извлечения сущностей. Он демонстрирует, как Google использует результаты первого запроса в качестве «контекста» для интерпретации последующих действий. Чтобы контент эффективно работал в таких диалоговых сценариях, он должен быть структурирован так, чтобы система могла легко извлекать contextual data (метаданные о сущностях, событиях, времени, локациях). Это подчеркивает критическую важность структурированных данных (Schema.org) и четкого представления информации об объектах.

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

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

Action Engine (Механизм действий)

Компонент системы, который выполняет конкретные действия в ответ на полный (переписанный) запрос. Примеры действий: search action, reminder action, navigation action.

Contextual Data (Контекстуальные данные)

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

Contextual Rewrite Engine (Механизм контекстуального переписывания)

Компонент, который генерирует новый полный запрос (Q3) на основе шаблона, текущего запроса (Q2) и контекстуальных данных (из Q1).

Dialog Session Module (Модуль диалоговой сессии)

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

Grammar Rule Module (Модуль грамматических правил)

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

Incomplete Query (Неполный запрос)

Запрос (Q2), в котором отсутствует информация (additional information), необходимая для выполнения связанного с ним действия, и который требует контекста из предыдущего запроса (Q1) для интерпретации.

Labels (Метки)

Переменные части в грамматическом шаблоне (например, [person], [event time], [location]), которые заполняются данными из текущего запроса или контекста.

Template (Шаблон)

Предопределенная грамматическая структура, хранящаяся в Template Database. Шаблоны связаны с вертикальными категориями (например, «местный поиск», «напоминания») и содержат labels.

User Session (Пользовательская сессия)

Последовательность взаимодействий пользователя с системой в течение определенного периода времени (specific period of time, например, 30-120 секунд).

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

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

1. Система получает первый запрос (Q1).
2. Определяются contextual data для Q1 (результат поиска и метаданные).
3. Система получает второй запрос (Q2), следующий за Q1 в той же сессии.
4. Система определяет, что Q2 является incomplete query без использования contextual data из Q1. (Это ключевой триггер).
5. В ответ на это определение:
   1. Определяется конкретный шаблон (particular template), которому соответствует Q2, на основе грамматического правила (grammar rule) Q2.
   2. Генерируется третий запрос (Q3) на основе (i) шаблона, (ii) contextual data из Q1 и (iii) текста Q2.
   3. Q3 предоставляется как входные данные для автоматически генерируемого действенного вывода (actionable output), который является ответом на Q2.

Claim 4 (Зависимый): Описывает организацию шаблонов.

Шаблоны классифицируются по вертикальным категориям (vertical categories), тематикам (subjects) и грамматическим правилам. Система определяет тематику и вертикаль Q2 (используя контекст Q1, если необходимо) и выбирает шаблон, соответствующий этой тематике/вертикали и грамматическому правилу Q2.

Claim 5 (Зависимый): Определяет incomplete query как запрос, в котором отсутствует дополнительная информация, необходимая для выполнения действия. Генерация Q3 включает определение этой недостающей информации из contextual data.

Claim 6 (Зависимый от 5): Уточняет использование сущностей и местоимений.

Если первый запрос относится к сущности (entity), то дополнительная информация для второго запроса может включать соответствующее местоимение (pronoun) для этой сущности, что помогает связать запросы (разрешение кореференции).

Claim 7 (Зависимый): Уточняет один из методов определения связи (Tense Matching).

Система проверяет соответствие грамматического времени (tense) между Q1/результатом Q1 и Q2. Если время совпадает (например, оба в будущем времени), это может указывать на то, что Q2 связан с контекстом Q1 и является неполным без него.

Claim 9 (Зависимый): Детализирует генерацию Q3 с помощью поддерживающих правил.

Система может использовать поддерживающие грамматические правила (supporting grammar rules), связанные с метками. Например, если шаблон содержит относительное время («за час до события»), правило может вычислить точное время для выполнения действия.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе система должна извлекать и индексировать метаданные и сущности из ресурсов. Эта информация позже используется как contextual data, когда ресурс появляется в результатах поиска по первому запросу (Q1). Четкость и структурированность данных критичны.

QUNDERSTANDING – Понимание Запросов
Основное место применения патента. Dialog Session Module отслеживает сессию. Grammar Rule Module анализирует входящий запрос Q2 на предмет полноты и грамматической структуры. Если Q2 неполный, Contextual Rewrite Engine использует контекст Q1 и шаблоны из Template Database для генерации Q3. Это процесс переписывания запроса на основе контекста сессии в реальном времени.

RANKING / Action Execution
Переписанный запрос (Q3) передается либо в стандартную систему ранжирования (если это поисковое действие), либо в специализированный Action Engine (для напоминаний, навигации и т.д.). Исходный запрос Q2 не используется для ранжирования напрямую.

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

• Первый запрос (Q1) и его контекстуальные данные (результаты, метаданные).
• Второй запрос (Q2).
• База данных шаблонов (Template Database).
• Данные о пользовательской сессии (тайминги).

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

• Третий, переписанный запрос (Q3), который является полным и действенным.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на диалоговый поиск (conversational search), голосовой поиск и взаимодействие с ассистентами, где пользователи склонны задавать последующие, контекстно-зависимые вопросы.
• Конкретные типы контента и Вертикали: Патент упоминает высокую надежность для вертикалей, таких как местный поиск (local search), напоминания, погода, спорт, авиарейсы. Это контент, богатый структурированными данными (время, место, событие).
• Языковые ограничения: Система разработана как расширяемая на любые подходящие языки, помимо английского, при условии наличия соответствующих грамматических шаблонов.

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

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

• Временные рамки: Второй запрос (Q2) должен поступить в течение определенного периода времени после первого (Q1) (например, 30-120 секунд).
• Триггер активации (Incompleteness): Ключевое условие — второй запрос (Q2) должен быть идентифицирован как incomplete query. То есть, он не содержит всей информации, необходимой для выполнения предполагаемого действия.
• Наличие контекста и связи: Должны существовать релевантные contextual data от Q1, которые могут заполнить пробелы в Q2. Система может проверять связь через лингвистические сигналы (местоимения) или совпадение времени (tense matching).
• Наличие шаблона: Для Q2 должен быть найден подходящий грамматический шаблон в Template Database.

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

Процесс обработки диалоговой сессии

1. Получение первого запроса (Q1): Система получает Q1 и начинает пользовательскую сессию.
2. Определение контекстуальных данных Q1: Система выполняет поиск по Q1 и определяет результаты. Извлекаются метаданные (сущности, время, локации и т.д.) из результатов. Эти данные сохраняются как contextual data сессии.
3. (Опционально) Предварительный выбор шаблонов: На основе контекста Q1 система может заранее определить набор вероятных последующих шаблонов.
4. Получение второго запроса (Q2): Система получает Q2.
5. Проверка временных рамок: Система проверяет, поступил ли Q2 в течение установленного времени сессии. Если нет, Q2 обрабатывается как новый независимый запрос.
6. Проверка полноты Q2 (Incompleteness Check): Система анализирует Q2, чтобы определить, достаточно ли в нем информации для выполнения действия.
   • Если Q2 полный: Q2 обрабатывается независимо.
   • Если Q2 неполный: Переход к следующему шагу.
7. Определение ассоциации с контекстом: Система подтверждает, что неполный Q2 связан с контекстом Q1. Это может включать проверку соответствия времени (tense matching) или наличия местоимений, ссылающихся на сущности из Q1.
8. Выбор шаблона: Модуль грамматических правил анализирует Q2 и выбирает наиболее подходящий шаблон.
9. Заполнение меток шаблона: Система определяет информацию для меток в шаблоне. Часть информации берется из Q2, а недостающая часть — из contextual data Q1.
10. Генерация третьего запроса (Q3): Механизм контекстуального переписывания генерирует Q3, подставляя заполненные метки в шаблон. Могут применяться поддерживающие грамматические правила (например, расчет точного времени из относительного).
11. Выполнение действия: Q3 передается в Action Engine для выполнения (поиск, напоминание и т.д.).

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

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

Патент фокусируется на обработке запросов и использовании контекста, а не на факторах ранжирования контента. Он использует следующие типы данных:

• Контентные/Структурные факторы (в виде Contextual Data): Система полагается на данные, извлеченные из результатов поиска по Q1. Это включает текст результата и, что критически важно, метаданные, связанные с ним (сущности, даты, время, локации). Это подчеркивает важность структурированных данных и четкого представления информации на страницах.
• Поведенческие факторы: Query Logs и Selection Logs могут использоваться офлайн для генерации или уточнения грамматических шаблонов.
• Временные факторы: Время между запросами (Q1 и Q2) используется для определения границ пользовательской сессии. Грамматическое время (tense) самих запросов используется для подтверждения их контекстуальной связи.
• Пользовательские факторы: Запросы привязаны к уникальному идентификатору пользователя или устройства для отслеживания сессии.
• Лингвистические факторы: Грамматическая структура запросов, использование местоимений (pronouns).

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

Патент не описывает расчет метрик ранжирования, но описывает следующие критерии и процессы:

• Определение границ сессии: Используется пороговое значение времени (например, 30-120 секунд) между запросами.
• Оценка полноты запроса (Incompleteness): Определяется, содержит ли запрос всю необходимую информацию для выполнения действия. Это основано на грамматическом анализе и требованиях конкретных действий/шаблонов. Если ключевые метки не могут быть заполнены из самого запроса, он считается неполным.
• Выбор шаблона: Основан на сопоставлении грамматической структуры запроса Q2 с шаблонами в Template Database, с учетом вертикали и тематики контекста.
• Соответствие времени (Tense Matching): Сравнение грамматического времени (настоящее, будущее) между Q1/его результатом и Q2 для подтверждения контекстуальной связи.
• Поддерживающие грамматические правила: Применяются для трансформации данных при генерации Q3 (например, преобразование относительного времени в абсолютное: «за 1 час до 14:40» -> «в 13:40»).

Выводы

1. Контекст сессии как основа для интерпретации запросов: Google активно пытается связать последовательные запросы в диалог. Если текущий запрос неполный, система ищет недостающую информацию не только в тексте предыдущего запроса, но и в его результатах и связанных метаданных.
2. Критичность извлечения метаданных (Contextual Data): Способность системы поддерживать диалог напрямую зависит от качества contextual data, извлеченных из результата первого запроса (Q1). Если Google не может извлечь четкие метаданные (время, место, сущность) из страницы, он не сможет использовать эту страницу как контекст для последующих действий.
3. Грамматические шаблоны для действий: Google использует предопределенные шаблоны (Templates), связанные с конкретными вертикалями (местный поиск, рейсы, спорт) и действиями (напоминания, навигация), для интерпретации и переписывания неполных запросов.
4. Определение «неполноты» запроса как триггер: Запрос считается неполным (incomplete query), если он не содержит достаточно информации для выполнения действия. Это ключевой триггер для активации механизма контекстуального переписывания.
5. Переписывание запроса перед выполнением: Неполный запрос (Q2) не обрабатывается напрямую. Вместо этого он переписывается в полный запрос (Q3), который затем используется для поиска или выполнения действия.
6. Лингвистические сигналы для валидации связи: Система использует сложные лингвистические маркеры, такие как временная форма (tense) и местоимения (pronouns), для подтверждения связи между запросами.

Практика

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

• Оптимизация для извлечения сущностей (Entity Extraction): Убедитесь, что ключевые сущности (продукты, события, организации, локации) и их атрибуты (время, дата, адрес, цена) представлены на странице четко и однозначно. Это позволяет Google легко извлекать их как contextual data после первого запроса (Q1).
• Активное использование структурированных данных (Schema.org): Внедряйте подробную микроразметку (например, Event, Flight, LocalBusiness, Product). Это напрямую помогает системе извлекать точные метаданные, которые необходимы для заполнения меток (labels) шаблонов действий в последующих запросах.
• Оптимизация под диалоговый поиск и многоэтапные сессии: Создавайте контент, который дает четкие ответы и поддерживает развитие диалога. Анализируйте, как пользователи ищут информацию последовательно, и оптимизируйте контент так, чтобы он отвечал не только на первый вопрос, но и предоставлял контекст для ожидаемых следующих шагов (например, от поиска информации к действию).
• Обеспечение лингвистической и темпоральной четкости: Используйте ясный язык и правильные временные формы. Поскольку система использует tense matching для связи запросов, контент должен быть написан так, чтобы его временной контекст был очевиден (например, анонс предстоящего события должен использовать будущее время).

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

• Неоднозначное представление информации: Размещение ключевой информации (например, времени работы или адреса) только в виде изображений или в неструктурированном тексте затрудняет извлечение contextual data.
• Игнорирование микроразметки для событий и локаций: Отсутствие Schema.org снижает вероятность того, что ваш контент будет эффективно использоваться в диалоговых сессиях, требующих точных данных для выполнения действий (напоминания, навигация).
• Фокус только на ключевых словах без учета сущностей и действий: Оптимизация под текстовые совпадения без учета лежащих в их основе сущностей и связанных с ними действий (Actionable Intents) неэффективна для систем, описанных в патенте, которые оперируют шаблонами и метаданными.

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

Патент подтверждает движение Google от простого поиска информации к выполнению действий и диалоговому взаимодействию (Conversational AI / Search as an Assistant). Для SEO это означает, что оптимизация должна выходить за рамки традиционного ранжирования и фокусироваться на том, насколько хорошо контент поддерживает выполнение задач пользователя (Task Completion). Стратегический приоритет смещается в сторону семантического SEO: понимания сущностей, их атрибутов и связанных с ними действий. Сайты, которые предоставляют четкие, структурированные данные, будут предпочтительнее в качестве источника контекста для Google Assistant и SGE.

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

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

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

1. Анализ взаимодействия: Пользователь ищет Q1: «Концерт [Исполнитель] в [Город]». Наш сайт ранжируется на первой позиции.
2. Оптимизация Contextual Data: Внедрена микроразметка Event с точными данными:
   • startDate: [Точная дата и время]
   • location (Place): [Название площадки, полный адрес]
3. Результат взаимодействия: Пользователь задает Q2: «Как туда добраться?».
4. Обработка системой: Система определяет Q2 как incomplete query (не указано место назначения). Она идентифицирует шаблон навигации «get directions to [destination location]». Система извлекает точный адрес площадки из contextual data (благодаря Schema.org).
5. Переписанный запрос (Q3): «Проложить маршрут до [Точный адрес площадки]».
6. Ожидаемый результат: Google успешно выполняет навигационное действие (navigation action), используя наш сайт как надежный источник контекста.

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