Как Google позволяет создавать кастомные поисковые системы (CSE), комбинирующие и модифицирующие результаты из разных источников

Описание

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

Патент решает проблему ограниченности и негибкости стандартных поисковых систем для решения специфических задач. Он устраняет ситуацию, когда пользователи и разработчики вынуждены принимать поведение поисковой системы «как есть» (“take-it-or-leave-it”). Изобретение позволяет разработчикам (третьим лицам) создавать специализированные поисковые интерфейсы (Custom Search Engines — CSE), которые адаптируют поведение базовых поисковых систем и комбинируют результаты из нескольких источников (например, Web и Scholar) в соответствии с заданными правилами.

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

Запатентована система, включающая Search Executor (Исполнитель Поиска), который действует как посредник между пользователем (Searcher) и одной или несколькими базовыми поисковыми системами (Underlying Search Engines). Система интерпретирует Search Specification (Спецификацию Поиска), созданную разработчиком, для модификации запросов пользователя, условного опроса нескольких поисковых систем и последующей модификации и комбинирования полученных результатов.

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

Система работает на основе спецификаций, предоставляемых разработчиком:

• Спецификация (Search Specification): Разработчик определяет правила поведения системы (часто в формате XML).
• Модификация запроса (Query Modification): Search Executor изменяет исходный запрос пользователя (например, добавляет синонимы, удаляет термины) перед отправкой в базовые поисковые системы.
• Управление источниками (Specification of Sections): Спецификация определяет, какие поисковые системы использовать (Results Sections) и при каких условиях (Conditions) (например, использовать Google Scholar, только если запрос содержит слово «academic»).
• Комбинирование (Connecting Sections): Определяются правила смешивания результатов из разных источников (например, конкатенация, чередование, смешивание).
• Модификация результатов (Results Modification): Полученные результаты фильтруются или переранжируются. Это часто делается через механизм Labels, когда определенные URL или паттерны (URL Patterns) повышаются, понижаются или удаляются.

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

Средняя. Описанная технология лежит в основе продукта Google Programmable Search Engine (ранее Google Custom Search Engine — CSE). Она актуальна для разработчиков, использующих этот продукт для создания поиска по сайту или вертикальных поисковиков. Однако патент не описывает алгоритмы основного поиска Google (Web Search), а только инфраструктуру для их кастомизации внешними системами.

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

Влияние на стандартные SEO-стратегии минимальное (2/10). Патент не раскрывает внутренние алгоритмы ранжирования Google. Вместо этого он описывает инфраструктуру, позволяющую третьим лицам создавать собственные поисковые интерфейсы (мета-поиск), которые используют индекс Google, но модифицируют запросы и результаты. Патент важен для понимания того, как работает Google CSE, но не предлагает прямых инсайтов для оптимизации под основной поиск Google.

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

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

Search Executor (Исполнитель поиска)

Центральный компонент системы, который интерпретирует Search Specification, модифицирует запросы, опрашивает базовые движки и модифицирует/комбинирует результаты.

Search Specification (Спецификация поиска)

Набор инструкций (конфигурация), предоставленный разработчиком для определения поведения кастомной поисковой системы.

Underlying Search Engine (Базовая поисковая система)

Внешняя поисковая система (например, Google Web Search, Google Scholar), которую Search Executor использует для выполнения поиска.

Query Modification Description (Описание модификации запроса)

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

Results Modification Description (Описание модификации результатов)

Часть спецификации, определяющая, как изменить полученные результаты поиска (фильтровать, повысить, понизить результаты).

Specification of Sections (Спецификация секций)

Древовидная структура данных, определяющая, какие источники данных использовать (Секции) и как их комбинировать.

Section (Секция)

Узел в Specification of Sections. Может быть Results Section (определяет базовый поисковый движок), UI Component Section или Connecting Section.

Connecting Section (Соединяющая секция)

Внутренний узел в Specification of Sections. Определяет операцию (Operation) комбинирования результатов из дочерних секций (например, конкатенация, чередование) и/или условие (Condition) для этого комбинирования.

Label (Метка)

Имя, присвоенное группе URL-паттернов (URL Patterns). Используется для применения правил модификации результатов к группе документов.

Annotations (Аннотации)

Связь между Label и набором URL-паттернов.

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

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

1. Система получает Search Specification, включающую Results Modification Description и Specification of Sections.
2. Specification of Sections определяет первую секцию (Engine 1), вторую секцию (Engine 2) и Connecting Section.
3. Connecting Section имеет ассоциированное условие (associated condition), контролирующее комбинирование результатов.
4. Система получает запрос пользователя и отправляет запросы (возможно, модифицированные) в Engine 1 и Engine 2.
5. Система получает результаты и комбинирует их на основе associated condition.
6. Система применяет Results Modification Description к объединенному набору и выводит результаты.

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

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

1. Система получает Specification of Sections, определяющую Engine 1, Engine 2 и Connecting Section.
2. Connecting Section определяет condition (условие, КОГДА комбинировать результаты) и operation (операцию, КАК комбинировать результаты).
3. После получения результатов от Engine 1 и Engine 2, система комбинирует их на основе condition и operation.

Claim 13 (Независимый пункт): Описывает процесс модификации запроса и результатов с использованием механизма меток (Labels).

1. Система получает Search Specification и генерирует query modification data, label definitions и result modification data.
2. Получив запрос пользователя, система модифицирует его на основе query modification data.
3. Система отправляет модифицированный запрос в поисковую систему и получает результаты.
4. Система применяет label к части результатов на основе label definitions.
5. Система модифицирует результаты на основе примененных labels и result modification data.

Этот пункт описывает механизм постобработки и переранжирования результатов с помощью присвоения меток (например, на основе URL) и применения правил к этим меткам.

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

Этот патент описывает систему (CSE), которая функционирует как надстройка (мета-поисковый слой) над существующими поисковыми системами. Она не является частью основного конвейера Google Поиска.

QUNDERSTANDING – Понимание Запросов (Локальное)
Search Executor выполняет собственную модификацию запроса. Он интерпретирует Query Modification Description, чтобы изменить запрос пользователя *до* его отправки в базовые движки.

RANKING – Ранжирование (Взаимодействие)
Само ранжирование выполняется внешними Underlying Search Engines. Search Executor отправляет им модифицированные запросы и получает упорядоченные списки.

METASEARCH – Метапоиск и Смешивание (Основное применение)
Search Executor использует Specification of Sections для управления метапоиском:

• Выбор источников: Определяет, какие базовые движки использовать (Results Sections).
• Условная активация: Использует Conditions, чтобы решить, нужно ли опрашивать определенный движок.
• Комбинирование (Blending): Использует Connecting Sections и их Operations (конкатенация, чередование, смешивание) для объединения результатов из разных источников.

RERANKING – Переранжирование (Локальное)
Search Executor выполняет постобработку:

• Применение меток (Labeling): Система присваивает Labels результатам (обычно по URL Patterns).
• Модификация результатов: Использует Results Modification Description для повышения (Promote), понижения (Demote) или удаления (Remove) результатов на основе меток.

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

• Search Specification (от разработчика).
• Исходный запрос (от пользователя).

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

• Модифицированные и скомбинированные результаты поиска (пользователю).

На что влияет

• Область влияния: Алгоритм влияет исключительно на результаты, отображаемые через конкретную реализацию Search Executor (например, конкретный экземпляр Google CSE). Он не оказывает влияния на ранжирование в основном органическом поиске Google.

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

• Условия работы: Алгоритм работает всегда, когда запрос обрабатывается через настроенный Search Executor (например, когда пользователь использует Google CSE).
• Триггеры активации: Внутри спецификации могут быть заданы условия (Conditions) для активации определенных секций. Например, секция, опрашивающая Google Scholar, может активироваться, только если в запросе присутствует термин «academic» (QueryContains).

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

Этап 0: Предварительная обработка (Офлайн или при запуске)

1. Получение спецификации: Разработчик предоставляет Search Specification.
2. Анализ спецификации: Specification Analyzer парсит спецификацию и генерирует внутренние структуры данных: Query Modification Data, Label Definitions (включая URL-паттерны) и Result Modification Data.

Этап 1: Обработка запроса (Онлайн)

1. Получение запроса: Search Executor получает запрос от пользователя.
2. Интерпретация секций: Section Interpreter обходит дерево Specification of Sections.
3. Выполнение секций: Система выполняет дочерние секции (итеративно или параллельно). Для каждой Results Section:
   • Проверка условий: Проверяется, выполняется ли Condition для этой секции. Если нет, секция пропускается.
   • Модификация запроса: Query Modifier применяет Query Modification Data к исходному запросу.
   • Отправка и получение: Модифицированный запрос отправляется в соответствующую Underlying Search Engine. Получаются результаты.
   • Применение меток: Label Applier применяет Labels к результатам на основе Label Definitions (например, по URL Patterns).
   • Модификация результатов: Result Changer изменяет порядок или фильтрует результаты на основе Result Modification Data и примененных меток.
4. Комбинирование результатов: Combiner объединяет результаты из разных секций в соответствии с операциями (Operation) и условиями (Condition), определенными в Connecting Sections.
5. Генерация UI и Вывод: Добавляются элементы интерфейса (UI Components, например, фасеты), и объединенные результаты предоставляются пользователю.

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

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

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

• Контентные факторы: Термины из исходного запроса пользователя. Ключевые слова и синонимы, указанные в Query Modification Description для добавления или удаления из запроса.
• Технические факторы: URL результатов, возвращаемых базовыми движками. URL Patterns, указанные в спецификации, используются для сопоставления с URL результатов и применения Labels.
• Структурные данные (Спецификация): Древовидная структура Specification of Sections, определяющая логику выполнения и комбинирования.

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

Патент не определяет собственные метрики ранжирования; он полагается на порядок результатов, возвращаемый Underlying Search Engines. Однако он использует следующие механизмы для модификации:

• Сопоставление с паттернами: Используются URL Patterns для идентификации сайтов или разделов сайтов и применения к ним Labels.
• Весовые коэффициенты: Спецификация может включать веса (weight) для повышения (Promote) или понижения (Demote) терминов в запросе или результатов в выдаче (если базовый движок это поддерживает).
• Логические операции: Используется булева логика (AND, OR, NOT) и проверка наличия терминов (QueryContains) для определения условий активации секций и применения модификаций.
• Операции модификации: Применяются явные операции: Add, Restrict, Remove, Promote, Demote.

Выводы

1. Инфраструктура для кастомного метапоиска (CSE): Патент описывает гибкую инфраструктуру для создания кастомных поисковых систем, которые могут модифицировать поведение базовых поисковых движков и комбинировать результаты из нескольких источников. Это архитектура Google CSE.
2. Разделение модификаций ввода и вывода: Архитектура четко разделяет этап модификации запроса (препроцессинг) и этап модификации результатов (постпроцессинг). Это позволяет независимо настраивать охват и ранжирование в рамках CSE.
3. Механизм Меток (Labels) как основа постобработки: Ключевым механизмом для управления результатами является система Labels. Метки присваиваются результатам (обычно по URL Patterns) и используются для применения правил повышения, понижения или фильтрации.
4. Условное и структурное комбинирование (Sections): Specification of Sections позволяет создавать сложную логику смешивания (Blending). Connecting Sections определяют, как (Operation) и когда (Condition) объединять результаты из разных источников (например, Web и Scholar).
5. Отсутствие инсайтов о ранжировании Google: Критически важно понимать, что патент не дает информации о том, как Google ранжирует документы внутри своих основных систем. Он описывает только то, как внешний Search Executor может манипулировать вводом и выводом этих систем.

Практика

ВАЖНО: Патент описывает инфраструктурные процессы для предоставления сервиса Custom Search Engine (CSE) и не дает прямых рекомендаций для SEO в основном поиске Google.

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

Рекомендации применимы только при использовании Google CSE для организации поиска на своем сайте.

• Оптимизация поиска по сайту (с использованием CSE): Если вы используете Google CSE, этот патент детально объясняет его функционал. Используйте Query Modification для добавления релевантных синонимов или ключевых слов. Используйте Results Modification и Labels (через URL Patterns), чтобы продвигать наиболее важные разделы сайта (Promote) или фильтровать нежелательный контент (Remove) в результатах вашего внутреннего поиска.
• Структурирование URL: Поскольку система полагается на URL Patterns для идентификации и маркировки контента, поддержание чистой и логичной структуры URL облегчает системам (и администраторам CSE) идентификацию и группировку разделов сайта.

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

• Экстраполяция на основной поиск Google: Главная ошибка — интерпретировать описанные здесь механизмы (например, повышение результатов по Labels или добавление ключевых слов в запрос) как факторы ранжирования в основном поиске Google (Web Search). Это исключительно функции платформы CSE.
• Игнорирование контекста CSE: При анализе поведения пользователей внутри сайта, использующего CSE, нельзя забывать, что выдача может быть сильно модифицирована настройками Search Specification и отличаться от стандартной выдачи Google.

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

Патент демонстрирует архитектурный подход Google к созданию метапоисковых систем и смешиванию результатов. Хотя здесь описана кастомизируемая версия (CSE), концепции условного вызова разных индексов (Sections) и их последующего комбинирования (Connecting Sections) концептуально схожи с тем, как может работать внутренний механизм Universal Search в Google. Это подтверждает важность структурированного подхода к управлению различными источниками данных в поиске.

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

Практических примеров для органического SEO нет.

Сценарий: Настройка поиска по сайту университета с помощью Google CSE

Цель: Создать поиск, который ищет по основному сайту, но приоритизирует сайты Стэнфорда и Карнеги-Меллон, а также добавляет результаты из Google Scholar для академических запросов (Пример основан на FIG. 8 патента).

1. Создание Спецификации (Search Specification): Разработчик создает XML-спецификацию.
2. Определение Меток (Labels) и Аннотаций: Создается метка «Приоритетные_Университеты» и связывается с URL Patterns *.stanford.edu/* и *.cmu.edu/*.
3. Настройка Секции 1 (Web Search): Создается Results Section (source=»web»).
   • Query Modification: Добавляются термины «paper OR research» к запросу ().
   • Results Modification: Применяется правило «Promote» для метки «Приоритетные_Университеты» ().
4. Настройка Секции 2 (Scholar Search): Создается вторая Results Section (source=»scholar»).
   • Condition: Секция активируется (), только если запрос содержит слово «academic» ИЛИ «professor» ().
5. Настройка Комбинирования: Создается Connecting Section (например, ConcatenationSection) для объединения результатов Секции 1 и Секции 2.
6. Результат: Когда пользователь ищет «AI professor», Search Executor активирует обе секции. Он отправит модифицированные запросы, повысит результаты Стэнфорда/CMU в первой части и добавит результаты Scholar во второй части выдачи.

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