Close Menu
    Telegram
    SEO HARDCORE
    • Разборы патентов
      • Патенты Google
      • Патенты Яндекс
    • Скоро
      SEO инструменты
    • Скоро
      SEO аналитика
    SEO HARDCORE
    Разборы патентов • Патенты Google

    Как Google использует LLM для декомпозиции сложных запросов на подзапросы и синтеза генеративного ответа (Основа AI Overviews)

    UTILIZING LARGE LANGUAGE MODEL (LLM) IN RESPONDING TO MULTIFACETED QUERIES (Использование Большой Языковой Модели (LLM) для ответов на многоаспектные запросы)
    • US20250117381A1
    • Google LLC
    • 2025-04-10
    • 2024-10-07
    2024 EEAT и качество SERP Патенты Google Семантика и интент

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

    • Описание
    • Детальный разбор
    • Выводы
    • Практика
    • Вопросы и ответы
    • Наверх

    Описание

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

    Патент решает проблему неэффективной обработки поисковыми системами и LLM запросов, которые являются многоаспектными (multifaceted) и/или зашумленными (noisy). Многоаспектные запросы содержат несколько различных тем или задач. Зашумленные запросы содержат постороннюю информацию, нерелевантную для решения основной задачи. Стандартные алгоритмы часто не справляются с такими запросами, предоставляя неполные ответы или упуская важные аспекты, что вынуждает пользователя вручную разбивать сложный запрос на несколько простых.

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

    Запатентована система декомпозиции запросов с использованием генеративной модели (например, LLM). Система принимает сложный ввод на естественном языке (NL based input) и использует LLM для генерации множества кандидатов в подзапросы (candidate subqueries). Затем система отбирает оптимальное подмножество, гарантируя их релевантность исходному запросу и разнообразие между собой, используя эффективные модели кодирования (encoding models). Поиск выполняется по отобранным подзапросам, а результаты агрегируются в единый ответ.

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

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

    • Генерация кандидатов (LLM): Входящий сложный запрос включается в промпт для LLM вместе с дополнительным контентом (например, few-shot examples). Для обеспечения разнообразия этот процесс может повторяться несколько раз с разными промптами.
    • Эффективный Отбор (Encoding Model): Система оценивает кандидатов с помощью метрик оценки (evaluation metrics): Relatedness (релевантность исходному запросу) и Diversity (разнообразие между подзапросами). Для эффективности эти метрики рассчитываются с помощью легковесных Encoding Models путем сравнения эмбеддингов.
    • Выполнение поиска: Поиск осуществляется только для отобранного подмножества подзапросов.
    • Генерация ответа: Результаты поиска агрегируются. Финальный ответ может быть списком результатов или генеративным резюме (generative summary), синтезированным на их основе (аналогично AI Overviews).

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

    Чрезвычайно высокая. Опубликованный в 2025 году, этот патент описывает механизм, который лежит в основе современных стратегий Google по обработке сложных, многоэтапных запросов и является технической базой для работы систем типа AI Overviews (ранее SGE). Это фундаментальный сдвиг в понимании и обработке запросов.

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

    Патент имеет критическое значение (95/100) для современных SEO-стратегий. Он описывает, как Google обходит необходимость ранжирования по сложному исходному запросу, фокусируясь вместо этого на ранжировании по его декомпозированным компонентам (подзапросам). Видимость контента в синтезированных ответах (AI Overviews) напрямую зависит от способности ранжироваться по этим конкретным, сгенерированным системой подзапросам, а не по общему многоаспектному запросу пользователя.

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

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

    Candidate Subqueries (Кандидаты в подзапросы)
    Набор потенциальных подзапросов, сгенерированных LLM на основе исходного ввода.
    Diversity Metric (Метрика разнообразия)
    Оценка степени различия между двумя подзапросами. Используется для предотвращения выбора дублирующих подзапросов и обеспечения покрытия всех аспектов.
    Encoding Model / Encoding Neural Network Model (Модель кодирования)
    Нейросетевая модель (например, sentence encoder), используемая для преобразования текста в эмбеддинги. Патент подчеркивает, что эта модель более эффективна (менее ресурсоемка), чем основная LLM.
    Embeddings (Эмбеддинги)
    Векторные представления текста. Используются для вычисления метрик релевантности и разнообразия путем сравнения дистанции (например, косинусного расстояния).
    Evaluation Metrics (Метрики оценки)
    Общий термин для метрик (Relatedness и Diversity), используемых для отбора лучшего подмножества подзапросов.
    Few-shot examples (Примеры в промпте)
    Примеры пар «сложный запрос – идеальные подзапросы», которые добавляются в промпт для LLM, чтобы направить генерацию кандидатов.
    Generative Summary / Shortened Summary (Генеративное резюме)
    Синтезированный ответ, созданный LLM на основе результатов поиска по подзапросам (аналог AI Overview).
    LLM (Large Language Model / Большая Языковая Модель)
    Генеративная модель (например, PaLM, LaMDA, Gemini), используемая для генерации кандидатов в подзапросы и, опционально, для создания финального резюме.
    Multifaceted Query (Многоаспектный запрос)
    Запрос, который относится к двум или более различным темам, задачам или проблемам.
    NL based input (Ввод на естественном языке)
    Исходный запрос пользователя.
    Noisy Query (Зашумленный запрос)
    Запрос, содержащий постороннюю информацию, которая не является существенной для решения задачи пользователя.
    Relatedness Metric (Метрика релевантности/связанности)
    Оценка, указывающая на степень соответствия подзапроса исходному пользовательскому вводу.

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

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

    1. Получение NL based input.
    2. Генерация промпта (subquery generation prompt), включающего ввод и дополнительный контент.
    3. Использование генеративной модели (LLM) для создания множества candidate subqueries.
    4. Выбор подмножества кандидатов с использованием Evaluation Metrics.
    5. Получение результатов поиска для каждого подзапроса из подмножества.
    6. Генерация финального ответа на основе этих результатов.
    7. Отображение ответа.

    Claims 4-6 (Зависимые от 1): Детализируют механизм повышения разнообразия кандидатов.

    Система генерирует дополнительные промпты с альтернативным контентом (например, другими few-shot examples, Claims 2, 5). Генерация кандидатов происходит в несколько итераций с использованием разных промптов. Это увеличивает общее разнообразие пула кандидатов.

    Claims 7-12 (Зависимые от 1): Определяют типы метрик и механизм отбора.

    Используются Diversity Metric (разнообразие относительно уже выбранных) и Relatedness Metric (связь с исходным вводом) (Claims 7, 8, 10). Критически важно, что для расчета метрик используется Encoding neural network model, которая более эффективна, чем LLM. Расчет основан на дистанции (distance measure) между эмбеддингами (Claims 9, 11). Кандидат выбирается, только если обе метрики удовлетворяют порогам (Claim 12).

    Claim 16 (Зависимый от 1): Описывает формат генеративного ответа.

    Генерация ответа может включать обработку результатов поиска с помощью генеративной модели для создания сокращенного резюме (shortened summary).

    Claims 17-20 (Зависимые от 1): Описывают механизм селективной активации.

    Система сначала определяет, нужно ли вообще запускать процесс декомпозиции (Claim 17). Это решение принимается на основе критериев, таких как длина запроса (length criterion, Claim 18), качество стандартных результатов (search result quality criteria, Claim 19) или нагрузка на сервер (server load criterion, Claim 20).

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

    Этот патент описывает архитектуру, которая интегрируется в несколько ключевых этапов поиска для обеспечения работы систем типа AI Overviews.

    QUNDERSTANDING – Понимание Запросов
    Основной этап применения. Система анализирует входящий NL based input, чтобы определить необходимость декомпозиции (селективная активация). Если активация происходит, LLM используется для генерации кандидатов. Затем Encoding Model используется для фильтрации и выбора оптимального подмножества подзапросов.

    RANKING – Ранжирование
    Система запускает несколько параллельных процессов ранжирования – по одному для каждого выбранного подзапроса. Это внутренние поисковые циклы для сбора кандидатов для финального ответа.

    METASEARCH – Метапоиск и Смешивание
    Результаты, полученные на этапе RANKING для разных подзапросов, агрегируются. Система определяет, как представить эти результаты – в виде списка или передать их обратно в LLM для генерации Generative Summary.

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

    • Исходный NL based input (запрос пользователя).
    • Набор few-shot examples (для формирования промптов).
    • Веса LLM и Encoding Model.

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

    • Синтезированный ответ (список агрегированных результатов или генеративное резюме).

    На что влияет

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

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

    Алгоритм применяется не для всех запросов, а активируется селективно (Claim 17) при выполнении определенных условий:

    • Триггеры активации: Система определяет, что запрос является multifaceted и/или noisy и что стандартный поиск может быть неэффективным.
    • Критерии (Claims 17-20):
      • Длина запроса (length criterion): количество токенов превышает порог.
      • Качество результатов поиска (search result quality criteria): если стандартный поиск по всему запросу дает низкокачественные результаты.
      • Редкость запроса: низкая частота подачи данного запроса в прошлом (frequency of submission).
      • Нагрузка на сервер (server load criterion): механизм может отключаться при высокой нагрузке.

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

    Процесс работы системы по обработке сложного запроса:

    1. Идентификация ввода: Система получает NL based input.
    2. Селективная активация: Проверяется, удовлетворяет ли ввод критериям для декомпозиции. Если нет, выполняется стандартный поиск. Если да, процесс продолжается.
    3. Генерация промптов (Итеративный процесс): Система создает один или несколько промптов для LLM. Каждый промпт включает исходный ввод и дополнительный контент (например, разные наборы few-shot examples для обеспечения разнообразия).
    4. Генерация кандидатов (LLM): Промпты обрабатываются LLM (параллельно или последовательно) для генерации пула Candidate Subqueries.
    5. Отбор подмножества (Subset Selection): (Детальный процесс фильтрации)
      1. Генерация эмбеддинга для исходного ввода с помощью Encoding Model.
      2. Для каждого кандидата в подзапросы:
        1. Генерация эмбеддинга для кандидата с помощью Encoding Model.
        2. Расчет Relatedness Metric (сравнение эмбеддинга кандидата с эмбеддингом ввода).
        3. Проверка порога релевантности. Если не пройден, кандидат отбрасывается.
        4. Расчет Diversity Metric (сравнение эмбеддинга кандидата с эмбеддингами уже отобранных подзапросов).
        5. Проверка порога разнообразия. Если не пройден (слишком похож), кандидат отбрасывается.
        6. Если оба порога пройдены, кандидат добавляется в финальное подмножество.
    6. Выполнение поиска: Система выполняет параллельные поисковые запросы для каждого подзапроса в отобранном подмножестве.
    7. Генерация ответа: Результаты поиска агрегируются. Система либо формирует структурированный список, либо (Claim 16) передает результаты в LLM вместе с промптом для суммаризации, чтобы создать Generative Summary.
    8. Рендеринг: Финальный ответ отображается пользователю.

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

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

    Патент фокусируется на обработке запроса. Основные данные на входе для механизма декомпозиции:

    • Контентные факторы: Текст исходного NL based input является основным входным сигналом.
    • Системные данные:
      • Superset of few shot examples: заранее подготовленная база данных примеров декомпозиции, используемая для генерации промптов.
      • Параметры LLM и Encoding Model.
    • Поведенческие факторы (Явно): Данные о частоте подачи запросов (frequency of submission) могут использоваться для оценки редкости ввода на этапе селективной активации (Claim 17).

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

    Ключевыми для работы системы являются две метрики, рассчитываемые на этапе отбора подмножества. Важно, что для их расчета используется эффективная Encoding Model, а не LLM.

    • Relatedness Metric (Метрика релевантности):
      • Как считается: С помощью Encoding Model генерируются эмбеддинг исходного запроса и эмбеддинг подзапроса. Метрика рассчитывается как мера расстояния (например, косинусное расстояние — cosine distance) между этими двумя векторами (Claim 11).
      • Условие срабатывания: Метрика должна превышать установленный порог релевантности.
    • Diversity Metric (Метрика разнообразия):
      • Как считается: Сравнивается эмбеддинг текущего подзапроса с эмбеддингами всех подзапросов, уже включенных в подмножество (Claim 9).
      • Условие срабатывания: Метрика должна превышать установленный порог разнообразия (т.е. дистанция должна быть достаточно большой), чтобы гарантировать, что подзапрос не дублирует уже выбранные.

    Алгоритмы машинного обучения: Система использует передовые NLP-технологии: LLM (Трансформеры) для понимания и генерации текста и Encoding Models для эффективного создания семантических эмбеддингов.

    Выводы

    1. Декомпозиция запросов — ключевая функция LLM в поиске: Одна из основных ролей LLM в поиске — это не только генерация ответов, но и стратегическая декомпозиция сложных запросов (Multifaceted и Noisy) на простые компоненты.
    2. Основа для AI Overviews: Описанный механизм (декомпозиция -> параллельный поиск -> генеративное резюме) является точным описанием функционирования систем типа AI Overviews (SGE).
    3. Баланс Релевантности и Разнообразия: Система активно стремится покрыть все аспекты исходного запроса (используя Diversity Metric для фильтрации дубликатов), при этом гарантируя, что каждый аспект релевантен исходному интенту (Relatedness Metric).
    4. Эффективность за счет разделения моделей: Критически важно, что для ресурсоемкой задачи фильтрации кандидатов используется эффективная Encoding Model (через сравнение эмбеддингов), а не основная LLM. Это позволяет масштабировать технологию.
    5. Селективная активация: Google не применяет этот дорогостоящий процесс ко всем запросам. Он активируется только для запросов, которые идентифицированы как сложные, длинные, редкие или если стандартный поиск неэффективен.
    6. Сдвиг целей SEO-оптимизации: Оптимизация под длинные, сложные запросы менее эффективна, чем оптимизация под конкретные, атомарные интенты (подзапросы), которые система генерирует в процессе декомпозиции.

    Практика

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

    • Оптимизация под конкретные подзапросы (Subquery Optimization): Сместите фокус с попыток ранжироваться по сложным многоаспектным запросам на выявление и оптимизацию под конкретные, четкие вопросы, которые могут быть сгенерированы как подзапросы. Контент должен давать прямые и полные ответы на эти атомарные интенты.
    • Построение тематического авторитета (Topical Authority): Поскольку система ищет разнообразные подзапросы для покрытия всех аспектов темы, важно иметь широкий охват контента в рамках кластера. Это увеличивает вероятность того, что ваш сайт будет выбран в качестве источника для одного или нескольких подзапросов.
    • Четкость и структурированность контента: Создавайте контент, который легко анализируется и из которого можно извлечь конкретную информацию для Generative Summary. Поскольку оценка релевантности происходит через эмбеддинги (Encoding Model), семантическая ясность критична. Используйте четкие заголовки, списки и таблицы.
    • Анализ декомпозиции интентов: При исследовании ключевых слов анализируйте сложные запросы в вашей нише и предполагайте, как LLM может их декомпозировать. Используйте эти предположения для формирования контент-плана.

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

    • Создание «шумного» контента: Оптимизация контента под длинные, разговорные запросы с большим количеством посторонней информации (noisy queries) неэффективна. Система стремится отфильтровать шум и выделить суть в виде подзапросов.
    • Поверхностное покрытие тем: Создание одной страницы, которая пытается поверхностно ответить на все аспекты сложного запроса. Более эффективно иметь страницы или блоки, глубоко прорабатывающие каждый аспект (подзапрос), чтобы выиграть ранжирование по этому конкретному подзапросу.
    • Игнорирование AI Overviews: Рассматривать этот механизм как второстепенный. Он становится центральным элементом обработки информационных запросов, и игнорирование оптимизации под синтезированные ответы приведет к потере видимости.

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

    Этот патент подтверждает стратегический переход Google от предоставления списка ссылок к предоставлению синтезированных ответов на сложные задачи (Task Completion). Архитектура, описанная в патенте, является основой AI Overviews. Для SEO это означает, что традиционное ранжирование по «главному» запросу уступает место ранжированию по набору сгенерированных системой подзапросов. Долгосрочная стратегия должна фокусироваться на том, чтобы стать лучшим источником информации для конкретных задач.

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

    Сценарий: Оптимизация контента под многоаспектный запрос (Пример из патента)

    Исходный запрос (NL based input): «Я переезжаю в новый город в дом площадью 2500 кв. футов и мне нужно найти Wi-Fi роутер, который покроет весь дом. Умный термостат тоже был бы идеален… Также мне нужен пылесос».

    Действия SEO-специалиста:

    1. Декомпозиция (Имитация LLM): Определить потенциальные подзапросы, которые сгенерирует Google, отфильтровав шум («Я переезжаю в новый город»):
      • Подзапрос 1: «лучший wifi роутер для дома 2500 кв футов»
      • Подзапрос 2: «рекомендации по умным термостатам»
      • Подзапрос 3: «лучшие пылесосы для дома»
    2. Анализ разнообразия (Diversity): Убедиться, что интенты различны (роутер, термостат, пылесос).
    3. Стратегия контента:
      • Для сайта обзоров техники: Создать три отдельные, глубоко проработанные статьи, оптимизированные под каждый из этих подзапросов. Например, детальный обзор Mesh-систем для больших домов, сравнение умных термостатов и рейтинг пылесосов.
    4. Ожидаемый результат: Система выполнит поиск по сгенерированным подзапросам. Если ваши статьи ранжируются высоко по этим конкретным запросам, они будут использованы в качестве источников для агрегированного ответа или Generative Summary (AI Overview) по исходному сложному запросу.

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

    Является ли этот патент описанием работы AI Overviews (SGE)?

    Да, этот патент описывает ключевые механизмы, лежащие в основе AI Overviews. Процесс декомпозиции сложного запроса на подзапросы, выполнение параллельного поиска по ним и последующая генерация резюме (Generative Summary, Claim 16) на основе найденных результатов точно соответствует принципам работы AI Overviews.

    Что такое многоаспектный (multifaceted) и зашумленный (noisy) запрос?

    Многоаспектный запрос содержит несколько разных интентов или задач (например, «найди роутер, термостат и пылесос»). Зашумленный запрос содержит много посторонней информации, не влияющей на суть задачи (например, «Я переезжаю в новый город, где погода другая, поэтому мне нужен умный термостат»). Этот патент направлен на решение обеих проблем.

    Как система решает, какие подзапросы использовать из всех сгенерированных вариантов?

    Система использует строгий процесс фильтрации на основе двух метрик: Релевантность (Relatedness) и Разнообразие (Diversity). Подзапрос должен быть релевантен исходному запросу И достаточно отличаться от уже выбранных подзапросов. Это гарантирует полное покрытие темы без дублирования.

    Как рассчитываются метрики релевантности и разнообразия? Используется ли для этого LLM?

    Нет, и это ключевой момент для эффективности системы. Патент указывает, что для этого используются более легковесные Encoding Models (Claim 9, 11). Система генерирует эмбеддинги для запроса и подзапросов и сравнивает расстояния между ними (например, косинусное расстояние). Это значительно быстрее, чем использование основной LLM для оценки.

    Как мне оптимизировать свой контент под этот механизм декомпозиции?

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

    Почему Google использует несколько разных промптов для генерации подзапросов?

    Использование нескольких промптов с разными примерами (few-shot examples) позволяет получить более широкий и разнообразный пул кандидатов в подзапросы (Claims 4-6). Это увеличивает вероятность того, что система покроет абсолютно все аспекты сложного пользовательского запроса, не упустив ничего важного.

    Применяется ли этот механизм ко всем запросам?

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

    Что важнее для попадания в AI Overview: авторитетность сайта (E-E-A-T) или релевантность контента подзапросу?

    Оба фактора критичны. Система выполняет стандартный поиск по сгенерированным подзапросам. Чтобы ваш контент был выбран в качестве источника для финального ответа, он должен высоко ранжироваться по этому конкретному подзапросу, что требует как высокой релевантности контента, так и достаточной авторитетности (E-E-A-T) для достижения топа.

    Может ли этот механизм навредить сайтам, оптимизированным под long-tail запросы?

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

    Как использование эмбеддингов влияет на понимание семантики?

    Использование эмбеддингов от Encoding Model позволяет системе оценивать семантическую близость (Relatedness) и различие (Diversity) между запросом и подзапросами, даже если они не содержат общих ключевых слов. Это позволяет находить релевантные и разнообразные подзапросы, основываясь на смысле, а не на буквальном тексте.

    Навигация
    • Описание
    • Детальный разбор
    • Выводы
    • Практика
    • Вопросы и ответы
    • Наверх
    Telegram
    © 2025 SEO HARDCORE

    Type above and press Enter to search. Press Esc to cancel.