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

Описание

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

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

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

Запатентована система для сохранения, индексации и извлечения контекста между разными поисковыми сессиями. Ядром изобретения является механизм индексации прошлых сессий с помощью метаданных (tags), которые описывают как саму сессию (session tags: время, место), так и обсуждаемые в ней объекты (item tags: категории, атрибуты сущностей). При получении нового запроса, ссылающегося на прошлое, система использует эти теги для быстрого поиска релевантной сессии и извлечения ее контекста для формирования ответа.

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

Система работает в двух режимах: индексация и извлечение.

• Индексация сессии: Во время активной сессии система идентифицирует обсуждаемые сущности (items). Для них извлекаются атрибуты (item tags) из базы знаний (Annotation Database). Также фиксируются метаданные сессии (session tags), такие как время и местоположение пользователя.
• Хранение: Теги сохраняются в Индексе Сессий (Session Index Repository), а сам контекст (запросы, результаты) — в Хранилище Данных Сессий (Session Data Repository).
• Извлечение: Когда поступает новый запрос, ссылающийся на прошлое (например, «покажи тот фильм, который я искал вчера вечером»), система парсит его для извлечения тегов («фильм», «вчера вечером»).
• Поиск сессии: Система ищет пересечение этих тегов в Session Index Repository, чтобы идентифицировать нужную прошлую сессию.
• Ответ: Контекст идентифицированной сессии извлекается из Session Data Repository и используется для формирования ответа или выполнения действия.

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

Высокая. Диалоговый поиск, глубокое понимание контекста и персонализация являются стратегическими направлениями развития поиска, особенно в контексте ИИ-ассистентов, чат-ботов и голосового поиска. Хотя данный патент является продолжением заявки с приоритетом от 2014 года, описанные в нем механизмы создания «памяти» и возобновления контекста критически важны для современных диалоговых систем.

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

Патент имеет среднее значение (6/10) для традиционного SEO, но высокое значение для оптимизации под диалоговый поиск (Conversational Search Optimization) и работы с сущностями (Entity Optimization). Он не описывает алгоритмы ранжирования веб-страниц. Однако он демонстрирует, как Google использует свою базу знаний (Annotation Database, аналог Knowledge Graph) для классификации и тегирования контента, найденного пользователем. Это подчеркивает критическую важность того, чтобы сущности (продукты, места, организации) были правильно поняты и классифицированы Google. Чем точнее данные переданы (например, через микроразметку), тем больше релевантных item tags будет присвоено, увеличивая вероятность повторного использования этой информации в диалоговом поиске.

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

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

Annotation Database (База данных аннотаций)

Хранилище информации о сущностях (items), событиях и действиях. Ассоциирует каждую сущность с одним или несколькими Item Tags. Функционально схожа с Knowledge Graph.

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

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

Item (Объект, Сущность)

Сущность, событие или действие, упомянутое в запросе или в результатах поиска (например, ресторан, книга, фильм).

Item Tag (Тег объекта)

Метка или аннотация, связанная с атрибутами или свойствами Item. Например, для ресторана это может быть категория («ресторан»), тип кухни («французская») или улица.

Session (Сессия)

Серия связанных поисковых запросов от пользователя в течение определенного периода времени.

Session Data Repository (Хранилище данных сессий)

База данных, хранящая Contextual Data для пользовательских сессий, индексированная по идентификаторам сессий (ID).

Session Index Repository (Индекс сессий)

База данных, которая хранит Item Tags и Session Tags, связанные с идентификаторами сессий. Используется для быстрого поиска сессий по тегам.

Session Tag (Тег сессии)

Метаданные, описывающие контекст самой сессии. Включают:

• Time Tag (Временной тег): Когда происходила сессия (например, «утро», «вчера»).
• Location Tag (Тег местоположения): Где находился пользователь во время сессии.
• Action Tag (Тег действия): Что делал пользователь до или во время сессии (например, «после звонка жене»).
• Co-presence Information Tag (Тег совместного присутствия): С кем был пользователь во время сессии.

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

Патент US20240411754A1 является продолжением (Continuation) более ранних патентов (например, US10275485). Claims в текущем документе фокусируются на процессе извлечения контекста.

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

1. Получение первого запроса во время первой сессии (в период времени T1).
2. Предоставление ответа на первый запрос, который ссылается на некий объект (item).
3. Получение второго запроса во время второй сессии (в период времени T2, который не следует сразу за T1).
4. Второй запрос включает: (i) термин, указывающий на атрибут объекта из первой сессии, но не идентифицирующий его уникально (например, «ресторан»), И (ii) термин, указывающий на атрибут первой сессии (например, «утром»).
5. Предоставление дополнительной информации об объекте из первой сессии в ответ на второй запрос.

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

Claim 6 (Зависимый): Уточняет, что термин, указывающий на атрибут объекта (i), может быть категорией этого объекта.

Claims 8-11 (Зависимые): Уточняют, что термин, указывающий на атрибут первой сессии (ii), может быть временем (Claim 8), местоположением пользователя (Claim 9), действием пользователя (Claim 10) или информацией о совместном присутствии (Claim 11).

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

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

INDEXING – Индексирование (Истории поиска)
На этом этапе происходит не индексирование веб-контента, а индексирование пользовательских сессий. После завершения сессии (или в процессе) система анализирует ее:

1. Идентифицирует сущности (Items) в запросах и ответах.
2. Запрашивает Annotation Database для получения Item Tags.
3. Определяет Session Tags (время, место и т.д.).
4. Сохраняет контекст в Session Data Repository и теги в Session Index Repository.

QUNDERSTANDING – Понимание Запросов
Это ключевой этап применения патента в реальном времени.

1. Система должна определить, что текущий запрос является неполным и ссылается на прошлый контекст (например, по наличию слов типа «тот», «вчера»).
2. Запрос парсится для извлечения потенциальных Item Tags (категории) и Session Tags (время, место).
3. Система интерпретирует относительные временные указатели (например, «сегодня утром») в абсолютные временные рамки.

RANKING – Ранжирование (Поиск по сессиям)
На этом этапе происходит поиск не по веб-индексу, а по Session Index Repository.

1. Система ищет идентификаторы сессий (Session IDs), которые соответствуют всем извлеченным тегам.
2. Используется логика пересечения множеств (overlap) для нахождения наиболее релевантных прошлых сессий.

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

• Текущий диалоговый запрос пользователя.
• Session Index Repository (индекс прошлых сессий пользователя).
• Session Data Repository (контекст прошлых сессий).
• Annotation Database (для понимания сущностей и их атрибутов).

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

• Извлеченный контекст (конкретная сущность) из прошлой сессии.
• Сформированный ответ или выполненное действие на основе этого контекста.

На что влияет

• Конкретные типы контента: В первую очередь влияет на контент, связанный с четко определенными сущностями (entities), которые хорошо описаны в Annotation Database: продукты (E-commerce), места и организации (локальный поиск), медиа (фильмы, книги), события.
• Специфические запросы: Диалоговые, уточняющие и контекстные запросы. Особенно актуально для голосового поиска (Voice Search) и взаимодействия с ИИ-ассистентами.
• Конкретные ниши или тематики: Локальный бизнес (поиск ресторанов, магазинов), путешествия (поиск отелей, рейсов), электронная коммерция.

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

• Триггеры активации: Алгоритм активируется, когда система определяет, что текущий запрос является неполным (недостаточно информации для выполнения действия) и что он не связан с непосредственно предшествующим запросом в текущей сессии.
• Условия работы: Запрос содержит явные или неявные указания на прошлое (например, использование прошедшего времени, временные маркеры типа «вчера», «утром») и ссылается на категории объектов или обстоятельства прошлой сессии.

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

Процесс А: Индексация пользовательской сессии

1. Получение запроса: Система получает запрос в рамках пользовательской сессии.
2. Идентификация сущности: Определяется, что запрос или ответ на него ссылается на конкретный объект (Item) в Annotation Database.
3. Извлечение тегов объекта: Система определяет один или несколько Item Tags (атрибуты, категории) для этого объекта, используя Annotation Database.
4. Определение тегов сессии: Система определяет Session Tags (время, местоположение, действие пользователя) для текущей сессии.
5. Сохранение контекста: Контекстуальные данные (запрос, ответ, метаданные) сохраняются в Session Data Repository и связываются с ID сессии.
6. Сохранение индекса: Item Tags и Session Tags сохраняются в Session Index Repository и связываются с тем же ID сессии.

Процесс Б: Извлечение контекста из предыдущей сессии

1. Получение нового запроса: Система получает новый запрос в новой сессии.
2. Анализ запроса: Определяется, что запрос неполный и ссылается на прошлый контекст.
3. Извлечение тегов из запроса: Запрос парсится для идентификации упомянутых тегов (например, категория объекта и время).
4. Поиск идентификаторов сессий: Система ищет в Session Index Repository идентификаторы (IDs), которые ассоциированы со всеми извлеченными тегами. Этот процесс может включать:
   1. Определение первого набора ID, связанных с первым тегом (например, временем).
   2. Определение второго набора ID, связанных со вторым тегом (например, категорией).
   3. Определение пересечения (overlap) этих наборов для нахождения финальных ID.
5. Извлечение контекста: Система извлекает Contextual Data для финальных ID из Session Data Repository.
6. Выполнение действия: Система выполняет действие (например, формирует ответ, запускает навигацию) на основе извлеченных контекстуальных данных.

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

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

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

• Поведенческие факторы: История запросов пользователя (Query Logs) и история взаимодействия в рамках сессий (Session Data). Это основа для индексации.
• Географические факторы: Местоположение пользователя во время прошлых сессий. Используется для генерации Location Tag.
• Временные факторы: Время совершения прошлых сессий. Используется для генерации Time Tag.
• Пользовательские факторы: Активность пользователя на устройстве (например, звонки, установка будильника), которая может использоваться для генерации Action Tag. Также данные о совместном присутствии (Co-presence Information Tag).
• Структурные факторы (Косвенно): Система критически зависит от Annotation Database (Knowledge Graph). Эта база данных содержит сущности и их атрибуты (Item Tags). Хотя патент не описывает, как эта база наполняется, на практике она формируется в том числе на основе структурированных данных (Schema.org) с веб-сайтов.

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

Патент не описывает метрики ранжирования или оценки качества в традиционном понимании SEO. Он описывает механизм точного поиска (Retrieval) предыдущих сессий.

• Методы вычислений: Ключевым методом является фильтрация и пересечение множеств (Intersection of sets). Система ищет пересечение (overlap) идентификаторов сессий, соответствующих разным тегам, извлеченным из запроса.
• Приоритезация (упоминается в описании): Если найдено несколько кандидатов (несколько прошлых сессий соответствуют тегам), система может ранжировать их, например, отдавая приоритет идентификатору, который соответствует наибольшему количеству тегов.

Выводы

1. Диалоговый поиск требует памяти: Патент описывает конкретный механизм реализации «памяти» в поиске, позволяющий сохранять контекст между сессиями. Это необходимо для создания естественного диалога и возможности возобновления задач.
2. Критическая роль Knowledge Graph (Annotation Database): Способность системы функционировать напрямую зависит от качества и полноты Annotation Database. Система должна уметь распознавать сущности (Items) и знать их атрибуты (Item Tags), чтобы индексировать сессии.
3. Атрибуты и категории важнее названий для восстановления контекста: Механизм позволяет пользователю ссылаться на объект, используя только его категорию («тот ресторан») вместо точного названия, при условии наличия других уточняющих тегов (например, времени).
4. Метаданные сессии как ключ к контексту: Время, местоположение пользователя и его действия (Session Tags) индексируются и используются как важные фильтры для поиска релевантного прошлого контекста.
5. Значение для SEO в оптимизации сущностей: Для SEO-специалистов этот патент подтверждает стратегическую важность оптимизации сущностей (Entity Optimization). Необходимо обеспечить, чтобы Google мог точно идентифицировать сущность и все ее ключевые атрибуты, чтобы она могла быть эффективно тегирована и впоследствии извлечена в диалоговом поиске.

Практика

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

• Максимальное использование структурированных данных (Schema.org): Поскольку система полагается на Annotation Database для получения Item Tags, необходимо предоставлять максимально полную и точную информацию о сущностях через микроразметку. Это касается продуктов, организаций, мест, событий, статей (автор, дата). Чем больше атрибутов вы предоставите, тем больше тегов Google сможет использовать.
• Оптимизация сущностей (Entity Optimization): Работайте над тем, чтобы ключевые сущности вашего бизнеса были распознаны и представлены в Knowledge Graph. Это включает работу с Google Business Profile, Википедией/Викиданными и обеспечение консистентности данных о сущности в сети.
• Локальное SEO и точность атрибутов: Для локального бизнеса критически важно поддерживать точность NAP (Name, Address, Phone), а также специфических атрибутов (например, тип кухни для ресторана, наличие парковки). Эти данные становятся Item Tags и позволяют системе позже идентифицировать ваш бизнес по запросам типа «тот итальянский ресторан на Маркет-стрит».
• Создание контента, богатого сущностями и атрибутами: При создании контента убедитесь, что ключевые сущности четко определены и описаны с указанием их свойств. Это помогает системам NLP извлекать данные для Annotation Database.

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

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

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

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

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

Сценарий 1: Локальный бизнес (Ресторан)

Действие SEO: Владелец ресторана «Gary Danko» обеспечивает полное заполнение Google Business Profile и использует микроразметку LocalBusiness на сайте, указывая атрибуты: категория (Restaurant), тип кухни (French), адрес (Point Street), рейтинг.

1. Сессия А (Утро): Пользователь ищет «лучшие французские рестораны в Сан-Франциско». Google видит «Gary Danko», и благодаря оптимизации, индексирует сессию с тегами: Item: Gary Danko, Item Tags: restaurant, French, Point Street, Session Tag: morning.
2. Сессия Б (Вечер): Пользователь спрашивает ассистента: «Как проехать в тот французский ресторан, который я искал утром?».
3. Обработка: Система извлекает теги: Item Tag: restaurant, French, Session Tag: morning.
4. Результат: Система находит Сессию А, извлекает контекст (Item: Gary Danko) и запускает навигацию. Без качественной оптимизации атрибутов (тегов) система могла бы не понять, о каком именно ресторане идет речь.

Сценарий 2: E-commerce (Книга)

Действие SEO: Интернет-магазин использует разметку Product и Book, указывая ISBN, автора (Robert T. Kiyosaki), название (Rich Dad Poor Dad) и категорию (Book).

1. Сессия А (Понедельник): Пользователь ищет «книга Кийосаки богатый папа бедный папа». Google индексирует сессию с тегами: Item: Rich Dad Poor Dad, Item Tags: book, Robert T. Kiyosaki, Session Tag: Monday.
2. Сессия Б (Среда): Пользователь спрашивает: «Сколько стоила та книга Кийосаки, которую я смотрел в понедельник?».
3. Обработка: Система извлекает теги: Item Tag: book, Kiyosaki, Session Tag: Monday.
4. Результат: Система находит Сессию А, извлекает контекст и предоставляет актуальную цену на книгу «Rich Dad Poor Dad».

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