Как Google предотвращает конфликты правил в системах проспективного поиска (фильтрации потоков данных)

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

Prospective Search (Проспективный поиск)

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

Retrospective Search (Ретроспективный поиск)

Техника поиска (например, стандартный веб-поиск Google), при которой сначала создается индекс данных, а затем по этому индексу выполняется поиск при поступлении пользовательского запроса.

Prospective Search Query (Проспективный поисковый запрос)

Заранее определенный фильтр или селектор в системе проспективного поиска. Состоит из ключей и значений (например, language="EN" AND region="US").

Query Server (Сервер запросов)

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

Mutually Exclusive (Взаимоисключающие)

Состояние, при котором два запроса не могут быть одновременно удовлетворены одним и тем же набором данных. Если запросы Not Mutually Exclusive, они перекрываются.

Sample Data Set (SDS) (Выборочный набор данных)

Временный набор данных, генерируемый системой для проверки взаимоисключаемости двух запросов. Он создается путем объединения (Union) ключей и значений из сравниваемых запросов по определенным правилам приоритета.

Data Set (Набор данных)

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

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

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

1. Система получает первый проспективный запрос (Q1), состоящий из первых ключей и значений.
2. Система определяет первый Sample Data Set (SDS) на основе объединения (Union) Q1 и второго проспективного запроса (Q2).
3. Система предоставляет индикацию о том, что Q1 не является взаимоисключающим с Q2, если SDS соответствует Q2.
4. Детализация генерации SDS (Ядро изобретения):
   • Ключи SDS определяются как объединение ключей Q1 и Q2 без дубликатов.
   • Значения для ключей SDS определяются следующим образом:
     • Если ключ отсутствует в Q1, используется значение из Q2.
     • Если ключ присутствует в Q1 (независимо от того, есть ли он в Q2), используется значение из Q1.

Ключевым элементом является специфический способ генерации Sample Data Set, где значениям из проверяемого (нового) запроса Q1 отдается приоритет. Это позволяет смоделировать потенциальный набор данных, который удовлетворяет новому запросу, и проверить, активирует ли он также существующий запрос Q2.

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

1. Получение входного проспективного запроса.
2. Сравнение входного запроса с одним или несколькими запросами из сохраненного набора (stored set). Сравнение использует логику из Claim 1 (генерация SDS с приоритетом значений входного запроса и проверка соответствия SDS выбранному сохраненному запросу).
3. Предоставление индикации, если входной запрос не является взаимоисключающим с сохраненным набором.
4. Добавление входного запроса в сохраненный набор, только если он является взаимоисключающим со всеми элементами набора.

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

Важно отметить, что описанная система не применяется в стандартной архитектуре веб-поиска Google (CRAWLING, INDEXING, QUNDERSTANDING, RANKING, METASEARCH, RERANKING), так как веб-поиск основан на Ретроспективном поиске. Патент относится к парадигме Проспективного поиска.

В контексте систем Проспективного поиска (например, системы обновлений Android-устройств, Google Alerts) изобретение применяется на этапе Управления Запросами (Query Management).

Как применяется:

• До выполнения поиска: Механизм активируется не во время обработки потока данных, а при попытке администратора или системы добавить новый проспективный запрос (фильтр) в базу данных (Query Server). Это процесс валидации правил.
• Взаимодействие компонентов: Пользователь отправляет новый запрос на Query Server. Query Server выполняет алгоритм проверки эксклюзивности, сравнивая новый запрос с существующим набором.

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

• Новый проспективный запрос (Q1).
• Существующий набор проспективных запросов.

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

• Индикация (флаг, уведомление), если Q1 не является взаимоисключающим.
• ИЛИ: Добавление Q1 в существующий набор (если он взаимоисключающий).

На что влияет

Патент не влияет на стандартные SEO-метрики, типы контента или ниши в контексте веб-поиска.

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

• Системы обновлений устройств: Предотвращает отправку дублирующихся или конфликтующих обновлений ПО или конфигураций на мобильные устройства (как указано в примерах патента, связанных с Motorola Mobility).
• Системы оповещений: Может использоваться для дедупликации правил оповещений, чтобы пользователь не получал избыточные уведомления об одном и том же событии через разные фильтры.

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

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

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

Процесс проверки нового проспективного запроса (Q1) на взаимоисключаемость с существующим набором запросов.

1. Получение первого запроса: Система получает новый входной запрос (Q1).
2. Выбор второго запроса: Система выбирает один запрос (Q2) из сохраненного набора для сравнения.
3. Определение Выборочного Набора Данных (SDS):
   • Система определяет ключи для SDS как объединение (Union) всех ключей из Q1 и Q2 без дубликатов.
   • Система определяет значения для этих ключей: Если ключ присутствует в Q1, используется значение из Q1 (Приоритет). Если ключ отсутствует в Q1, но присутствует в Q2, используется значение из Q2.
4. Проверка соответствия: Система проверяет, соответствует ли сгенерированный SDS условиям запроса Q2.
5. Оценка эксклюзивности:
   • Если SDS соответствует Q2: Запросы Q1 и Q2 не являются взаимоисключающими. Система генерирует индикацию о дублировании и завершает процесс для Q1.
   • Если SDS не соответствует Q2: Запросы взаимоисключающие на данном этапе.
6. Проверка наличия других запросов: Система проверяет, остались ли в сохраненном наборе запросы, с которыми Q1 еще не сравнивался.
   • Если ДА: Система возвращается к шагу 2 и выбирает следующий запрос для сравнения.
   • Если НЕТ: Q1 признается взаимоисключающим со всем набором.
7. Добавление запроса: Если Q1 успешно прошел все сравнения, он добавляется в сохраненный набор для последующего использования в проспективном поиске.

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

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

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

• Структура запросов: Запросы представлены как наборы пар ключ-значение (например, Language: EN, Region: U.S., Carrier: ABC WIRELESS, Device: Moto X).
• Логические операторы: Запросы могут использовать булевы, алгебраические или математические операторы (например, AND, OR, >, <) для соединения условий.

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

В патенте не используются метрики ранжирования или оценки качества. Используются только логические операции и сравнения.

• Union (Объединение): Используется для генерации набора ключей Sample Data Set из двух сравниваемых запросов.
• Value Prioritization (Приоритезация значений): Правило выбора значения для SDS (значение из нового запроса Q1 имеет приоритет над значением из существующего запроса Q2 при совпадении ключей).
• Match (Соответствие): Булева операция, определяющая, удовлетворяет ли Sample Data Set всем условиям существующего запроса. Результат (True/False) определяет, являются ли запросы взаимоисключающими.

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

1. Область применения — Проспективный Поиск: Патент строго относится к системам Prospective Search (фильтрация входящих потоков данных по заранее заданным правилам), а не к Retrospective Search (стандартный веб-поиск по индексу).
2. Цель — Устранение конфликтов запросов: Основная задача изобретения — предотвратить ситуации, когда один набор данных активирует несколько правил одновременно, что приводит к дублированию или конфликту действий.
3. Механизм обнаружения перекрытий: Используется метод генерации Sample Data Set (SDS). Ключевым элементом является правило приоритета: при объединении нового (Q1) и существующего (Q2) запросов для создания SDS, значения из Q1 имеют приоритет.
4. Логика проверки: Если сгенерированный SDS соответствует Q2, это доказывает существование потенциального набора данных, который активирует оба запроса, следовательно, они не взаимоисключающие.
5. Отсутствие связи с SEO: Механизмы, описанные в патенте, не имеют практического применения для оптимизации сайтов под алгоритмы ранжирования веб-поиска Google. Они касаются управления внутренними базами данных фильтров в специфических продуктах (например, управление обновлениями устройств).

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

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

• Понимание технологий Google: Единственная "best practice" — использовать этот патент для лучшего понимания разницы между Prospective Search и Retrospective Search. Это помогает корректно интерпретировать патенты Google и не делать ложных выводов о веб-ранжировании на основе технологий из смежных областей.

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

Не применимо. Патент не описывает факторы ранжирования или методы борьбы с SEO-манипуляциями в веб-поиске.

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

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

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

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

Сценарий: Предотвращение конфликта обновлений ПО

1. Существующий запрос (Q2) в базе:
   • Условие: Language="EN" AND Region="US" AND Carrier="ABC Wireless"
   • Действие: Отправить Обновление 1.
2. Попытка добавить Новый запрос (Q1):
   • Условие: Language="EN" AND Region="US" AND Device="MotoX"
   • Действие: Отправить Обновление 3.
3. Генерация Sample Data Set (SDS): Система объединяет ключи. Значения из Q1 имеют приоритет.
   • Language: "EN" (из Q1)
   • Region: "US" (из Q1)
   • Device: "MotoX" (из Q1)
   • Carrier: "ABC Wireless" (из Q2, так как в Q1 его нет)
4. Проверка: Соответствует ли SDS запросу Q2?
   • Q2 требует Language="EN" (Да), Region="US" (Да), Carrier="ABC Wireless" (Да).
5. Результат: Да, соответствует. Система определяет, что Q1 и Q2 не являются взаимоисключающими. Устройство, соответствующее SDS, получило бы оба обновления (1 и 3), что нежелательно.
6. Действие системы: Система уведомляет администратора о конфликте и не добавляет Q1 в базу.