Как Google использует генеративные модели (LLM) для переписывания запросов в диалоговом поиске на основе контекста беседы

Описание

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

Патент решает фундаментальную проблему диалогового поиска (Conversational Search) и чат-интерфейсов: неоднозначность запросов, зависящих от контекста предыдущего диалога. В ходе многоэтапного взаимодействия (multi-turn session) пользователи часто опускают информацию, упомянутую ранее, используя местоимения или сокращения. Поисковые системы, рассматривающие такие запросы изолированно, не могут точно определить интент. Изобретение обеспечивает механизм для точного восстановления и понимания контекстуального интента.

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

Запатентована система, которая использует генеративные модели (например, LLM) для понимания и переписывания запросов в реальном времени на основе истории диалога. Система получает текущий запрос (Input Query) и историю сессии (Multi-turn Query Data) и генерирует Contextually Aware Query (контекстно-зависимый запрос). Этот переписанный запрос инкапсулирует полный интент пользователя и используется для поиска результатов через сопоставление с графом интентов (Intent Graph).

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

Ключевой механизм включает несколько этапов:

• Сбор контекста: Система получает текущий запрос пользователя и данные предыдущих обменов репликами в рамках сессии.
• Контекстуальный анализ и Переписывание: Generative Model (LLM или VLM) анализирует запрос в контексте истории и генерирует Contextually Aware Query, дополняя исходный запрос недостающими деталями (например, заменяя местоимения на конкретные сущности).
• Генерация эмбеддинга: Переписанный запрос обрабатывается моделью эмбеддингов (Query Embedding Model) для создания векторного представления.
• Мэппинг интента: Эмбеддинг сопоставляется с кластером (Query Embedding Cluster) в Intent Graph, который объединяет запросы с похожими намерениями.
• Поиск результатов: Результаты определяются на основе этого кластера интентов.

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

Критически высокая. Патент напрямую описывает инфраструктуру, необходимую для работы современных систем диалогового поиска, таких как SGE (Search Generative Experience) и продвинутых чат-ботов (например, Gemini). Способность поддерживать контекст в течение длительных сессий является ключевым направлением развития поиска Google в 2025 году.

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

Патент имеет критическое значение для SEO (90/100). Он описывает, как именно Google интерпретирует запросы в диалоговых интерфейсах, которые становятся доминирующей формой взаимодействия с поиском. Понимание того, как LLM переписывает запросы и как система использует Intent Graph для кластеризации интентов, фундаментально меняет подход к семантическому проектированию и оптимизации контента под Conversational Search и SGE.

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

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

Contextually Aware Query (Контекстно-зависимый запрос)

Также Multi-turn Aware Query. Переписанная версия исходного запроса, сгенерированная Generative Model. Включает дополнительные детали из истории диалога для уточнения интента, делая запрос самодостаточным.

Generative Model (Генеративная модель)

Машинно-обученная модель (например, LLM или VLM — Vision Language Model), используемая для анализа контекста диалога, определения интента и переписывания запроса. Также используется как «учитель» для обучения моделей эмбеддингов.

Input Query (Входной запрос)

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

Intent Attributes (Атрибуты интента)

Дополнительные характеристики интента запроса, определяемые генеративной моделью (например, коммерческий интент, стадия воронки продаж – «late-stage funnel»).

Intent Graph (Граф интентов)

Структура данных (граф), узлы которого являются кластерами запросов (Query Embedding Clusters) с похожими интентами, а ребра связывают кластеры со схожими или связанными намерениями/темами.

Multi-turn Query Data (Данные многоэтапного запроса)

История диалоговой сессии, включающая предыдущие запросы пользователя и ответы системы.

Query Embedding (Эмбеддинг запроса)

Векторное представление Contextually Aware Query, сгенерированное моделью эмбеддингов.

Query Embedding Cluster (Кластер эмбеддингов запросов)

Группа эмбеддингов запросов со схожими интентами. Является узлом в Intent Graph.

Query Embedding Model (Модель эмбеддингов запросов)

Модель, преобразующая Contextually Aware Query в Query Embedding. Обучается генерировать схожие эмбеддинги для запросов с похожими интентами.

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

Патент описывает два основных механизма: обработку запросов в реальном времени и офлайн-обучение моделей.

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

1. Система получает Input Query.
2. Система получает Multi-turn Query Data (историю сессии).
3. Система обрабатывает запрос и историю для генерации Contextually Aware Query. Этот запрос включает дополнительные детали, описывающие контекст.
4. Contextually Aware Query обрабатывается Machine-learned Embedding Model для генерации Query Embedding.
5. Система определяет Query Embedding Cluster, связанный с этим эмбеддингом. Кластер содержит эмбеддинги других схожих запросов.
6. Система определяет результаты поиска на основе этого кластера.

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

Claim 14 (Независимый пункт): Описывает метод обучения (тюнинга) модели эмбеддингов с использованием генеративной модели (Teacher-Student подход).

1. Система получает входные данные (запрос).
2. Embedding Model генерирует Query Embedding для запроса.
3. Generative Model (Учитель) определяет Query Intent (истинный интент запроса).
4. Система получает вторичные эмбеддинги (Second Query Embeddings), связанные с этим истинным интентом.
5. Оценивается функция потерь (Loss Function), которая измеряет разницу между Query Embedding (шаг 2) и вторичными эмбеддингами (шаг 4).
6. Параметры Embedding Model (Ученик) корректируются на основе функции потерь, чтобы минимизировать разницу.

Этот процесс позволяет обучить Embedding Model генерировать эмбеддинги, которые лучше отражают интент запроса, как его понимает более мощная Generative Model.

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

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

QUNDERSTANDING – Понимание Запросов
Это основной этап применения. В реальном времени система должна интерпретировать текущий запрос пользователя, используя контекст всей диалоговой сессии. Generative Model используется для переписывания запроса (Query Rewriting) в Contextually Aware Query. Затем Embedding Model преобразует его в эмбеддинг для сопоставления с Intent Graph.

RANKING – Ранжирование (L1 Retrieval)
Contextually Aware Query и/или его эмбеддинг используются для эффективного отбора кандидатов. Сопоставление с Query Embedding Cluster в Intent Graph позволяет быстро найти результаты, релевантные точному контекстуальному интенту пользователя.

Офлайн-процессы (Обучение моделей)
Механизм, описанный в Claim 14, применяется офлайн для обучения и тюнинга Query Embedding Model с использованием Generative Model в качестве «учителя». Это улучшает качество моделей, используемых на этапе QUNDERSTANDING.

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

• Текущий запрос пользователя (Input Query).
• История диалоговой сессии (Multi-turn Query Data).

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

• Переписанный, контекстно-зависимый запрос (Contextually Aware Query).
• Эмбеддинг запроса (Query Embedding).
• Итоговые результаты поиска (Search Results).

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на неоднозначные, сокращенные запросы или запросы, использующие местоимения (например, «а какая цена у него?», «сравни его с другим»), которые возникают в ходе диалога.
• Типы контента и Интерфейсы: Влияет на все типы контента, отображаемые через диалоговые интерфейсы (Conversational Search, SGE, Google Assistant, чат-боты).
• Мультимодальность: Патент упоминает, что входной запрос и история могут быть мультимодальными (например, изображение и текст). В этом случае для обработки используется соответствующая генеративная модель (например, Vision Language Model, VLM).

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

• Триггеры активации: Алгоритм активируется, когда пользователь взаимодействует с системой через диалоговый интерфейс и существует история сессии (Multi-turn Query Data).
• Условия работы: Применяется для интерпретации запросов, которые могут зависеть от предыдущего контекста для точного понимания интента в рамках multi-turn session.

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

Процесс А: Обработка диалогового запроса в реальном времени

1. Получение данных: Система получает Input Query от пользователя и извлекает Multi-turn Query Data для текущей сессии.
2. Контекстуальный анализ: Input Query и Multi-turn Query Data передаются в Generative Model (LLM/VLM).
3. Переписывание запроса: Generative Model определяет интент и генерирует Contextually Aware Query, добавляя необходимые детали из контекста. (Пример: «сколько он стоит?» -> «цена смартфона Samsung S25 Ultra»).
4. Генерация эмбеддинга: Contextually Aware Query обрабатывается Query Embedding Model.
5. Мэппинг интента: Сгенерированный Query Embedding сопоставляется с Intent Graph для определения соответствующего Query Embedding Cluster.
6. Определение атрибутов (Опционально): Система может определить дополнительные Intent Attributes (например, коммерческий интент, стадия покупки) на основе кластера или с помощью LLM.
7. Поиск результатов: Система извлекает Search Results на основе Contextually Aware Query и/или идентифицированного Query Embedding Cluster (например, используя кэшированные результаты для кластера).

Процесс Б: Обучение модели эмбеддингов (Офлайн)

1. Получение обучающего запроса: Система выбирает запрос для обучения.
2. Генерация эмбеддинга (Ученик): Текущая версия Embedding Model генерирует Query Embedding.
3. Определение интента (Учитель): Generative Model (LLM) анализирует запрос и определяет его Query Intent.
4. Получение целевых эмбеддингов: Система получает эмбеддинги, которые соответствуют этому интенту (например, эмбеддинг самого интента или эмбеддинги других запросов с тем же интентом).
5. Расчет потерь: Вычисляется Loss Function, измеряющая расстояние между эмбеддингом ученика и целевыми эмбеддингами.
6. Корректировка модели: Параметры Embedding Model обновляются для уменьшения потерь, тем самым улучшая ее способность группировать запросы по интенту.

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

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

• Контентные (Текстовые) факторы: Текст текущего запроса (Input Query). Текст всех предыдущих запросов и ответов в сессии (Multi-turn Query Data). Эти данные являются основным источником для понимания контекста и переписывания запроса с помощью LLM.
• Мультимедиа факторы: Патент указывает, что входные данные могут быть мультимодальными (текст, изображения, аудио, видео). В этом случае используются модели, способные обрабатывать разные типы данных (например, VLM).
• Пользовательские факторы (Сессионные): Данные сессии. Факт того, что запросы поступают в рамках одной непрерывной диалоговой сессии, является ключевым для активации этого механизма.

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

• Query Embedding: Векторное представление запроса, генерируемое Query Embedding Model. Используется для сопоставления запроса с кластерами в Intent Graph.
• Intent Embedding: Векторное представление интента запроса, определенного Generative Model. Используется в процессе обучения.
• Loss Function (Функция потерь): Метрика, используемая при обучении (Процесс Б). Она измеряет разницу (расстояние) между эмбеддингом, сгенерированным обучаемой моделью, и целевым эмбеддингом (интентом). Цель обучения — минимизировать это значение.
• Intent Attributes: Качественные метки, присваиваемые интенту (например, «consumer-facing», «late-stage funnel»). Определяются с помощью LLM для более глубокого понимания нюансов интента.

Выводы

1. LLM как ядро понимания запросов в диалоге: Google использует мощные генеративные модели (LLM/VLM) на фундаментальном уровне понимания запросов (QUNDERSTANDING) в диалоговом поиске. LLM выступает в роли интерпретатора контекста сессии.
2. Активное переписывание запросов (Query Rewriting): Система не пытается понять неоднозначный запрос напрямую, а активно переписывает его в полный, контекстно-зависимый запрос (Contextually Aware Query), используя историю сессии. Это ключевой механизм для работы Conversational Search и SGE.
3. Граф интентов (Intent Graph) как основа поиска: Поиск результатов основан на сопоставлении переписанного запроса с Intent Graph. Это подтверждает стратегию Google группировать запросы по семантическому намерению, а не только по ключевым словам.
4. LLM как «Учитель» для других моделей: Патент описывает важный механизм обучения (Claim 14), где мощная Generative Model используется для обучения более быстрой Embedding Model. LLM определяет «правильный» интент, а модель эмбеддингов учится ему соответствовать. Это позволяет масштабировать понимание интента.
5. Мультимодальность и Расширенное понимание интента: Система спроектирована для обработки мультимодальных диалогов и стремится понять не только тему запроса, но и его атрибуты (Intent Attributes) — например, коммерческую направленность и стадию покупки.

Практика

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

• Оптимизация под диалоговые сценарии (Conversational Flow): Проектируйте контент так, чтобы он поддерживал диалог и отвечал на потенциальные последующие вопросы. Это увеличивает вероятность того, что ваш контент будет соответствовать Contextually Aware Query, который генерирует система по мере развития диалога.
• Фокус на кластерах интентов, а не на ключевых словах: Поскольку система использует Intent Graph для группировки схожих запросов, необходимо оптимизировать контент под целые кластеры намерений. Обеспечьте полное раскрытие темы (Topical Authority), чтобы соответствовать различным формулировкам внутри одного кластера интентов.
• Четкость и структурированность для Embedding Models: Создавайте семантически когерентный контент. Это поможет Query Embedding Model (которая обучается с помощью LLM) точно классифицировать ваш контент и сопоставить его с правильным Query Embedding Cluster.
• Оптимизация под мультимодальный поиск: Интегрируйте качественные изображения и видео с релевантным текстовым описанием, так как система способна обрабатывать мультимодальные диалоги (используя VLM) для понимания контекста.

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

• Изолированная оптимизация под отдельные запросы: Оптимизация страницы только под один специфический запрос без учета того, как он вписывается в более широкий диалог или пользовательское путешествие, становится менее эффективной. Система ищет контент, релевантный всему контексту сессии.
• Оптимизация под короткие, неоднозначные ключи: Фокусироваться на коротких запросах неэффективно, так как в диалоговом поиске Google перепишет их, добавив специфику из контекста.
• Игнорирование SGE и Conversational Search: Рассматривать диалоговый поиск как второстепенный канал. Данный патент показывает, что инфраструктура для понимания таких запросов является приоритетом для Google.
• Фрагментированный контент: Создание множества мелких страниц, отвечающих на узкие вопросы, вместо создания хабов, поддерживающих глубокое погружение в тему и многоэтапное взаимодействие.

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

Этот патент подтверждает стратегический переход Google к диалоговому поиску (Conversational Search/SGE). Способность системы поддерживать контекст и переписывать запросы на лету с помощью LLM означает, что SEO-стратегии должны адаптироваться к миру, где запросы динамичны и зависят от сессии. Ключевым становится оптимизация под понимание контента генеративными и эмбеддинговыми моделями, а также соответствие кластерам в Intent Graph. Долгосрочная стратегия должна фокусироваться на создании авторитетного контента, который полноценно удовлетворяет сложные, многоэтапные пользовательские задачи.

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

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

1. Действие пользователя (Диалог):
   Пользователь: «Покажи лучшие кроссовки для бега по пересеченной местности.»
   Система: [Показывает результаты, включая Модель X и Модель Y]
   Пользователь: «А какие из них водонепроницаемые?»
   Система: [Фильтрует результаты, показывая Модель Y]
   Пользователь: «Сколько стоит эта модель?» (Input Query)
2. Работа системы (согласно патенту): Система анализирует Multi-turn Query Data. Generative Model переписывает запрос в Contextually Aware Query: «Цена водонепроницаемых кроссовок для бега по пересеченной местности Модель Y».
3. Действия SEO-специалиста: Необходимо убедиться, что карточка товара Модели Y содержит четкую информацию о цене, назначении (бег по пересеченной местности) и свойстве (водонепроницаемость). Эта информация должна быть легко извлекаемой и семантически понятной.
4. Ожидаемый результат: Query Embedding Model точно сопоставит переписанный запрос с карточкой товара, и система предоставит пользователю точную цену.

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