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

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

Article (Статья, Контент)

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

Association Data Record (Запись ассоциации)

Запись в хранилище данных, связывающая категорию и статью. Содержит Category-Article Pair Identifier.

Attribute (Атрибут)

Характеристика статьи или события. Примеры: тип файла, имя, автор, ключевые слова, дата создания, выполненное действие (например, печать).

Capture Processor (Процессор захвата)

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

Category (Категория)

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

Event (Событие)

Зафиксированное взаимодействие пользователя со статьей (например, просмотр, редактирование, отправка, печать).

Event Schema (Схема события)

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

Implicit Query (Неявный запрос)

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

Local Index (Локальный индекс)

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

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

Патент фокусируется на автоматической категоризации локального контента для использования в контекстном поиске по неявным запросам.

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

1. Система отслеживает взаимодействия пользователя на клиентском устройстве и идентифицирует event (взаимодействие со статьей, хранящейся на устройстве).
2. Идентифицируется Event Schema, соответствующая типу статьи. Схема определяет поля для типа статьи и поля, описывающие взаимодействие.
3. Идентифицируются атрибуты события, соответствующие полям схемы.
4. Определяется первая категория, связанная со статьей, на основе этих атрибутов.
5. Сохраняется Association Data Record, связывающая категорию и статью.
6. Система получает implicit search query.
7. Запрос выполняется в хранилище данных, содержащем запись ассоциации.
8. Система получает эту запись ассоциации в качестве результата.

Ядро изобретения — использование Event Schemas для структурирования пользовательских взаимодействий и последующая автоматическая категоризация контента, которая затем используется для ответов на implicit queries.

Claim 18 (Независимый пункт): Аналогичен Claim 1, но акцентирует внимание на автоматическом создании категории (automatically creating) на основе атрибутов события.

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

Claim 21 (Независимый пункт): Вариант метода, где категория создается специально на основе полей схемы, которые описывают взаимодействие со статьей (fields that describe interactions).

Это позволяет категоризировать контент по действиям, например, создавать категории "Распечатанные" (Printed) или "Отправленные по почте" (Email-Sent).

Claim 24 (Независимый пункт): Описывает применение метода к веб-страницам (web page) с использованием ключевых слов.

1. Идентифицируется событие взаимодействия с веб-страницей.
2. Идентифицируются атрибуты, причем как минимум один атрибут связан с ключевым словом (keyword).
3. Выполняется поиск в хранилище category-keyword data store для поиска категории, связанной с этим ключевым словом.
4. Сохраняется ассоциация между категорией и идентификатором веб-страницы.
5. Получается implicit search query, выполняется поиск.
6. Система выводит идентификатор веб-страницы и категорию.

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

Изобретение применяется в рамках инфраструктуры локального или персонализированного поиска (например, Google Desktop Search), которая функционирует на клиентском устройстве.

CRAWLING – Сканирование и Сбор данных (Локальный)
В данном контексте "краулинг" заменяется мониторингом и захватом (Capture Processor). Система непрерывно отслеживает активность пользователя и события файловой системы на клиентском устройстве для сбора данных о локальных файлах, электронной почте и истории просмотров.

INDEXING – Индексирование и извлечение признаков (Локальный)
Основной этап применения патента. Indexer обрабатывает захваченные события. Он использует Event Schemas для извлечения атрибутов из контента и событий. На основе этих атрибутов происходит автоматическая категоризация и создание Association Data Records, которые сохраняются в локальном индексе (Data Store).

QUNDERSTANDING – Понимание Запросов (Контекстное)
Query System анализирует текущий контекст пользователя (например, содержимое открытого документа или вводимый текст) для генерации implicit queries. Также система идентифицирует категории в явных или неявных запросах.

RANKING – Ранжирование (Локальное)
Система выполняет поиск по локальному индексу, используя сгенерированный запрос. Поиск направлен на нахождение релевантных категорий и связанных с ними статей.

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

• События (Events) взаимодействия пользователя с контентом.
• Контент (Articles) – локальные файлы, электронные письма, веб-страницы.
• Event Schemas – предопределенные форматы.
• Текущий контекст пользователя (для implicit query).

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

• Association Data Records (связи категория-статья), сохраненные в индексе.
• Результаты поиска (идентификаторы статей и, возможно, категории).

На что влияет

• Конкретные типы контента: Влияет на любой контент на клиентском устройстве: документы (Word, PDF, PPT), электронная почта, сообщения мессенджеров, мультимедиа файлы и просмотренные веб-страницы.
• Специфические запросы: Наибольшее влияние оказывает на implicit queries, генерируемые на основе контекста. Также может улучшать явные запросы, позволяя пользователю искать или фильтровать по автоматически созданным категориям (например, "Бюджет Презентация").

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

• Триггеры активации (Индексирование): Активируется каждый раз, когда пользователь взаимодействует с контентом (создает, открывает, сохраняет, печатает, отправляет).
• Триггеры активации (Поиск): Активируется, когда система определяет изменение контекста пользователя, достаточное для генерации implicit query (например, пользователь вводит текст в документе и делает паузу или ставит точку), или когда пользователь вводит явный запрос в интерфейс локального поиска.

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

Процесс А: Категоризация контента (Индексирование)

1. Мониторинг активности: Система отслеживает взаимодействия пользователя на клиентском устройстве.
2. Захват события: Идентифицируется событие взаимодействия со статьей (например, сохранение документа).
3. Определение схемы: Выбирается соответствующая Event Schema на основе типа статьи и/или типа взаимодействия.
4. Извлечение атрибутов: Атрибуты события и статьи (например, тип файла, ключевые слова контента, имя файла) извлекаются в соответствии с полями схемы.
5. Определение категории: Система пытается найти существующие категории, соответствующие извлеченным атрибутам.
6. Создание категории (Условие): Если подходящая категория не найдена, система автоматически создает новую категорию на основе атрибутов. Категории также могут выводиться из структуры папок пользователя или его поисковых паттернов.
7. Создание ассоциации: Генерируется Association Data Record, связывающая идентификатор статьи и идентификатор категории.
8. Сохранение: Запись ассоциации сохраняется в локальном хранилище данных.

Процесс Б: Поиск на основе категорий (Retrieval)

1. Получение запроса: Система получает запрос. Это может быть implicit query, сгенерированный на основе контекста, или явный запрос от пользователя.
2. Идентификация категорий в запросе: Система анализирует запрос для выявления терминов, которые могут соответствовать категориям.
3. Поиск категорий: Выполняется поиск в хранилище данных для идентификации релевантных категорий.
4. Поиск ассоциированных статей: Извлекаются Association Data Records для найденных категорий. Этот шаг может включать обработку связей между категориями (иерархии).
5. Формирование результата: Идентификаторы статей добавляются в набор результатов.
6. Вывод результата: Набор результатов форматируется (например, с группировкой по категориям) и выводится пользователю.

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

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

Система использует широкий спектр данных, доступных на клиентском устройстве, для категоризации.

• Контентные факторы: Ключевые слова, извлеченные из текста статьи (документов, писем, веб-страниц). Используются для определения тематических категорий. Имя файла.
• Технические факторы: Тип файла (расширение файла, например, .pdf, .ppt). Используется для категоризации по типу контента. Местоположение файла (путь) или URL.
• Структурные факторы (Пользовательские): Структура папок пользователя, папки "Избранное" в браузере, папки или метки в почтовом клиенте. Могут использоваться для вывода (инференции) категорий.
• Временные факторы: Время события (создания, доступа, отправки).
• Пользовательские факторы (Взаимодействия): Действия пользователя, зафиксированные как events (печать, отправка по почте, копирование, просмотр). Используются для создания категорий, основанных на действиях.
• Поведенческие факторы (Инференция): Паттерны поиска пользователя (часто используемые ключевые слова) могут использоваться для вывода новых категорий.

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

Патент не детализирует конкретные метрики ранжирования или формулы расчета. Он фокусируется на механизме категоризации и ассоциации.

• Event Schema Matching: Основной механизм для структурирования данных. Система сопоставляет событие с предопределенной схемой для извлечения атрибутов.
• Attribute-to-Category Mapping: Используются таблицы или индексы соответствия для связи атрибутов (например, типа файла или ключевых слов из category-keyword data store) с категориями.
• Автоматическое создание категорий: Система использует эвристики для создания новых категорий на основе атрибутов, если соответствия не найдены.
• Category Relationships: Патент упоминает возможность иерархических или иных связей между категориями (например, вложенность категории "PowerPoint" в категорию "Презентация").

Патент описывает внутренние процессы Google для организации локального или персонализированного индекса пользователя и не содержит прямых рекомендаций для традиционного веб-SEO.

1. Фокус на локальном и контекстном поиске: Изобретение предназначено для организации информации на уровне пользователя (Local Index), а не для ранжирования в глобальном веб-индексе.
2. Автоматическая категоризация через события: Ключевой механизм — это использование Event Schemas для структурированного понимания того, что такое контент (тип файла, ключевые слова) и как с ним взаимодействовали (печать, отправка). Это позволяет системе автоматически и динамически создавать категории.
3. Действия пользователя как сигнал классификации: Взаимодействие пользователя (например, печать) является важным сигналом для категоризации контента, наравне с его содержанием.
4. Implicit Queries как основа поиска: Описанная система категоризации разработана в первую очередь для обслуживания implicit queries — поиска, инициированного системой на основе контекста пользователя в реальном времени.
5. Структурирование взаимодействий: Патент подчеркивает важность структурированного подхода (через схемы) к пониманию пользовательских взаимодействий для улучшения информационного поиска.

Этот патент является инфраструктурным и описывает технологии локального/персонализированного поиска (например, Google Desktop Search). Прямых практических выводов для стандартного SEO (продвижения сайтов в глобальном поиске Google.com) он не дает.

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

Хотя патент не направлен на веб-SEO, он подтверждает общие принципы хорошей организации информации, которые могут быть полезны косвенно:

• Четкая структура и семантика контента: Система полагается на извлечение ключевых слов и атрибутов для категоризации (включая веб-страницы, согласно Claim 24). Создание контента с четкой семантикой и структурой облегчает автоматическую классификацию любыми поисковыми системами.
• Использование стандартных форматов и метаданных: Система использует атрибуты, такие как тип файла и метаданные, для определения Event Schemas. Обеспечение корректности метаданных в публикуемом контенте (например, PDF-файлах) помогает системам правильно его интерпретировать.

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

Патент не выделяет конкретных SEO-тактик как неэффективных или опасных для веб-поиска.

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

Стратегическое значение патента заключается в понимании того, как Google развивал технологии персонализации и контекстного поиска. Он демонстрирует ранние подходы к использованию поведения пользователя и локального контекста (implicit queries) как сигналов для поиска информации. Хотя эти конкретные механизмы могут не использоваться в современном веб-поиске в том же виде, общая философия использования контекста и автоматической классификации остается фундаментальной для Google.

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

Практических примеров применения для веб-SEO нет, так как патент описывает локальный поиск. Ниже приведен пример того, как работает описанная в патенте система.

Сценарий: Автоматическая категоризация и контекстный поиск

1. Взаимодействие: Пользователь получает по почте файл "Budget2025.ppt" и сохраняет его.
2. Захват события и Схема: Система локального поиска фиксирует событие "Сохранение файла". Применяется Document Schema.
3. Извлечение атрибутов: Извлекаются атрибуты: Тип файла=".ppt", Имя файла="Budget2025", Ключевые слова из контента.
4. Автоматическая категоризация: Система создает или обновляет категории: "PowerPoint" (по типу файла), "Бюджет" (по имени и контенту). Создаются ассоциации между файлом и этими категориями.
5. Контекст пользователя: Позже пользователь начинает писать электронное письмо: "Коллеги, пожалуйста, ознакомьтесь с прогнозом бюджета...".
6. Implicit Query: Система локального поиска генерирует неявный запрос на основе контекста письма (например, "прогноз бюджета").
7. Поиск и Результат: Система ищет соответствующие категории ("Бюджет", "PowerPoint") и отображает файл "Budget2025.ppt" в боковой панели (как показано на FIG. 5 патента) как релевантный текущему контексту.