Как Google создает и управляет отдельными пользовательскими индексами с контролируемым доступом (Custom/Programmable Search Engine)

Описание

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

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

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

Запатентована система для создания, управления и поиска по множеству независимых Custom Search Indexes (пользовательских поисковых индексов), которые отделены от основного Web Search Index. Эти индексы создаются на основе контента, загруженного или указанного пользователем («владельцем» контента). Ключевым элементом является то, что владелец определяет данные контроля доступа (Access Control Data), указывая, кто авторизован для поиска в этом индексе.

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

Система работает следующим образом:

• Сбор контента: Владелец контента загружает данные через API (Custom Content Upload API) или указывает источники для сканирования специальным краулером (Custom Content Crawler).
• Индексирование: Система индексирует этот контент в отдельный Custom Search Index, изолированный от основного веб-индекса.
• Контроль доступа: Владелец предоставляет Access Control Data, определяя авторизованных пользователей.
• Поиск и Аутентификация: Конечные пользователи отправляют поисковые запросы. Security Unit проверяет их авторизацию.
• Предоставление результатов: Если пользователь авторизован, система ищет в соответствующем пользовательском индексе и (опционально) основном веб-индексе, а затем предоставляет объединенные (blended) результаты.

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

Высокая. Этот патент (являющийся продолжением заявок от 2006 и 2010 годов) описывает основополагающую архитектуру для продуктов, известных как Google Custom Search Engine (CSE) и ныне Programmable Search Engine. Основная концепция создания независимых, контролируемых поисковых индексов активно используется в специализированных и корпоративных поисковых решениях.

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

Влияние на традиционное органическое SEO (ранжирование в основном индексе Google) минимальное. Это инфраструктурный патент, он не описывает алгоритмы ранжирования. Однако он важен для понимания того, как оптимизировать поисковый опыт (Search Experience Optimization) в рамках контролируемой среды, такой как корпоративная база знаний, сайт поддержки или специализированный тематический портал на базе технологии Google (Programmable Search Engine).

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

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

Access Control Data (Данные контроля доступа)

Информация, предоставляемая владельцем (Owner) пользовательского контента, которая определяет, какие пользователи авторизованы для доступа и поиска в конкретном Custom Search Index.

Accounting Unit (Блок учета)

Компонент системы, отвечающий за управление правами доступа, отчетность об использовании пользовательских индексов (Access Reporter) и отслеживание подписок (Subscription Tracker).

Authentication Token (Токен аутентификации)

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

Custom Content (Пользовательский контент)

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

Custom Content Crawler (Краулер пользовательского контента)

Краулер, предназначенный для сканирования определенного контента (в Интернете, базах данных, файлах), указанного владельцем, для включения в Custom Search Index.

Custom Content Upload API (API загрузки пользовательского контента)

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

Custom Search Index (Индекс пользовательского поиска)

Поисковый индекс, созданный на основе Custom Content. Он отличается от Web Search Index и может искаться независимо. Система поддерживает множество таких индексов.

Owner (Владелец)

Пользователь или организация, которая предоставляет Custom Content и определяет Access Control Data.

Security Unit (Блок безопасности)

Компонент, отвечающий за аутентификацию пользователей (через Authentication Unit) и управление шифрованием.

Web Search Index (Индекс веб-поиска)

Основной поисковый индекс, содержащий проиндексированный общедоступный веб-контент.

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

Анализ основан на Claims патента US9569550B1.

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

1. Система поддерживает Web Search Index и множество Custom Content Indexes.
2. Каждый пользовательский индекс основан на контенте, предоставленном соответствующим владельцем (Owner).
3. Для каждого индекса владелец предоставляет Access Control Data, идентифицирующие авторизованных пользователей.
4. Система получает поисковый запрос от пользователя (который не является владельцем контента в первом пользовательском индексе).
5. Система определяет, авторизован ли этот пользователь для доступа к первому пользовательскому индексу на основе Access Control Data, предоставленных владельцем.
6. В случае авторизации (в ответ на это определение), система получает результаты из Web Search Index И результаты из первого Custom Search Index.
7. Система предоставляет оба набора результатов в ответ на запрос.

Claim 2 (Зависимый от 1): Уточняет процесс авторизации.

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

Claim 3 (Зависимый от 2): Уточняет механизм реализации авторизации.

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

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

Процесс включает получение контента от первого владельца, генерацию первого Custom Search Index на основе этого контента и получение от владельца указания (Access Control Data), что определенные пользователи (включая того, кто ищет) авторизованы для доступа к этому индексу.

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

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

CRAWLING – Сканирование и Сбор данных
Для пользовательского контента используются альтернативные механизмы сбора: Custom Content Upload API (для прямой загрузки данных, например, XML) и Custom Content Crawler (для сканирования указанных владельцем источников, включая базы данных или специфические веб-сайты).

INDEXING – Индексирование и извлечение признаков
Custom Content Indexer обрабатывает собранный контент и создает отдельные Custom Search Indexes. Эти индексы хранятся отдельно от Web Search Index. На этом этапе также сохраняются Access Control Data, связанные с каждым индексом.

RANKING – Ранжирование
Custom Search Engine запускается параллельно с Web Search Engine для обработки запроса по соответствующим индексам. Патент не описывает конкретные алгоритмы ранжирования, фокусируясь на инфраструктуре.

METASEARCH – Метапоиск и Смешивание
Ключевой этап применения. Security Unit проверяет авторизацию пользователя для доступа к пользовательским индексам. Если доступ разрешен, результаты из Custom Search Engine (Custom Search Results) и Web Search Engine (Web Search Results) агрегируются. Result Formatter объединяет их в единую выдачу (Blending).

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

• От владельца контента: Custom Content, Access Control Data.
• От конечного пользователя: Поисковый запрос, аутентификационная информация (токен, логин/пароль).

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

• Страница результатов поиска (SERP), содержащая смешанные Custom Search Results и/или Web Search Results.

На что влияет

• Конкретные типы контента: Наибольшее влияние на проприетарный контент, базы знаний, корпоративные интранеты, контент по подписке. Патент упоминает индексацию текста, XML данных, изображений и видео.
• Конкретные ниши: Корпоративный поиск, базы знаний (упоминается пример Oracle), каталоги продуктов (упоминаются примеры Netflix, Amazon), библиотеки, новостные издания.

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

Алгоритм применяется при выполнении следующих условий:

• Наличие индекса: В системе существует один или несколько релевантных Custom Search Indexes.
• Триггеры активации:
  • Пользователь явно выбирает поиск по пользовательскому индексу (например, используя интерфейс Custom Search).
  • Пользователь аутентифицирован, и его учетная запись связана с одним или несколькими пользовательскими индексами, которые система автоматически подключает при поиске (сценарий «Web + Custom Content Search»).
• Условие доступа: Пользователь должен удовлетворять требованиям Access Control Data, установленным владельцем контента (если индекс ограничен). Индекс также может быть публичным.

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

Процесс А: Создание и Обновление Пользовательского Индекса (Офлайн/Фоновый режим)

1. Получение контента: Система получает Custom Content от владельца через Custom Content Upload API или собирает его с помощью Custom Content Crawler из указанных источников.
2. Получение данных доступа: Система получает Access Control Data от владельца, определяющие авторизованных пользователей.
3. Индексирование: Custom Content Indexer обрабатывает контент и создает/обновляет отдельный Custom Search Index.
4. Хранение: Индекс и данные доступа сохраняются в Index Database.

Процесс Б: Обработка Поискового Запроса (В реальном времени)

1. Получение запроса: Система получает поисковый запрос от пользователя.
2. Аутентификация и Авторизация: Security Unit аутентифицирует пользователя (опционально) и определяет набор Custom Search Indexes, к которым у него есть доступ, на основе Access Control Data.
3. Параллельный поиск: Web Search Engine ищет по Web Search Index (опционально). Custom Search Engine ищет по авторизованным Custom Search Indexes.
4. Получение результатов: Генерируются Web Search Results и Custom Search Results.
5. Форматирование и Смешивание: Result Formatter объединяет результаты. В патенте показан пример, где Custom Search Results отображаются выше Web Search Results.
6. Предоставление выдачи: Объединенная страница результатов предоставляется пользователю.

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

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

Патент фокусируется на инфраструктуре и контроле доступа, а не на факторах ранжирования.

• Контентные факторы: Используется весь контент, предоставленный владельцем. Упоминается индексация текста, XML-данных, изображений и видео.
• Пользовательские факторы (Безопасность): Access Control Data (определяемые владельцем списки авторизации), данные аутентификации пользователя (логин, пароль), Authentication Tokens.
• Поведенческие факторы: Accounting Unit может использовать Feedback Logger для отслеживания доступа пользователей к контенту и получения обратной связи о качестве/релевантности. Эти данные могут использоваться для ранжирования или фильтрации результатов внутри пользовательского индекса.

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

Патент не детализирует конкретные метрики ранжирования или алгоритмы.

Он сосредоточен на следующих механизмах:

• Аутентификация и Авторизация: Бинарная проверка (авторизован/не авторизован) для доступа к конкретному Custom Search Index на основе Access Control Data.
• Отслеживание подписок: Subscription Tracker может использоваться для управления доступом к платному контенту (включая систему кредитов).
• Отчетность об доступе: Access Reporter отслеживает шаблоны доступа (идентификатор пользователя и идентификатор документа) для отчетности перед владельцами контента (например, для биллинга или отслеживания использования интеллектуальной собственности).

Выводы

1. Архитектурное разделение индексов: Google архитектурно разделяет основной веб-индекс и пользовательские индексы. Это позволяет применять разные правила сбора, индексации, доступа и, потенциально, ранжирования к разным корпусам контента.
2. Полный контроль владельца контента: Ключевой особенностью является то, что «владелец» (Owner) контролирует как состав корпуса контента (через API или указание URL для краулинга), так и права доступа к нему (через Access Control Data).
3. Инфраструктура для «Search as a Service»: Патент описывает базовую инфраструктуру, позволяющую Google предоставлять свою поисковую технологию как услугу для сторонних наборов данных (например, Programmable Search Engine или корпоративный поиск).
4. Смешивание результатов (Blending) и Авторизация: Система разработана для интеграции результатов из пользовательских индексов с результатами общего веб-поиска, но только для авторизованных пользователей. Security Unit выступает как шлюз доступа.
5. Отсутствие влияния на органическое SEO: Это инфраструктурный патент. Он не дает инсайтов о том, как Google ранжирует контент в своем основном индексе, и не влияет на стратегии органического продвижения в Web Search Index.

Практика

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

Практическое применение этого патента относится к использованию технологии Google Programmable Search Engine (CSE) или корпоративных поисковых решений, а не к традиционному SEO.

• Создание специализированных поисковых систем: Используйте эту технологию для создания качественного поиска по определенным наборам данных: корпоративной базе знаний, интранету, сайту поддержки или курируемой коллекции веб-сайтов по узкой теме.
• Оптимизация структуры данных для Custom Indexing: Если контент загружается через API (как упомянуто в патенте), предоставляйте хорошо структурированные данные (например, XML) с богатыми метаданными для более эффективного индексирования. Если контент сканируется Custom Content Crawler, обеспечьте его техническую доступность.
• Управление доступом к проприетарному контенту: Для внутренних или платных ресурсов реализуйте надежные механизмы контроля доступа (Access Control Data), чтобы гарантировать, что только авторизованные пользователи могут искать в индексе.
• Использование Blending для улучшения UX: Если применимо, настройте интеграцию так, чтобы авторизованные пользователи получали смешанные результаты (Custom + Web), предоставляя специализированные ответы наряду с общими.

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

• Путать CSE и основное SEO: Ожидать, что создание Custom Search Index или оптимизация под него повлияет на ранжирование сайта в основном Web Search Index Google. Это независимые системы.
• Игнорирование безопасности: Размещение конфиденциального контента в Custom Search Index без надлежащей реализации Access Control Data и механизмов аутентификации.
• Включение низкокачественных источников в CSE: При создании тематического поисковика добавление в корпус индекса нерелевантных или низкокачественных сайтов ухудшит качество поиска для пользователей этого CSE.

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

Патент подтверждает архитектурный подход Google к управлению различными корпусами данных и предоставлению «Поиска как услуги» (Search as a Service). Он подчеркивает гибкость инфраструктуры Google. Для бизнеса это означает возможность использовать мощь поиска Google для своих собственных, контролируемых наборов данных, не смешивая их с общедоступным вебом и контролируя доступ.

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

Сценарий 1: Поиск по базе знаний для клиентов по подписке (Приватный индекс)

1. Задача: Софтверная компания (например, Oracle, как упомянуто в патенте) хочет предоставить поиск по своей базе знаний (документация, баг-репорты) только лицензированным клиентам.
2. Реализация (по патенту):
   • Компания выступает в роли «Владельца» (Owner).
   • Она загружает базу знаний через Custom Content Upload API или указывает внутренние URL для Custom Content Crawler.
   • Система создает отдельный Custom Search Index.
   • Компания предоставляет Access Control Data, ограничивая доступ только клиентами с активной лицензией.
3. Использование: Клиент логинится на портале поддержки. При выполнении поиска Security Unit аутентифицирует его. Запрос отправляется в Custom Search Engine.
4. Результат: Клиент получает релевантные результаты из закрытой базы знаний.

Сценарий 2: Создание нишевого публичного поисковика (Публичный индекс)

1. Задача: Создать поисковик по кулинарным рецептам, который ищет только на 50 проверенных авторитетных сайтах.
2. Реализация (по патенту): Владелец создает публичный Custom Search Index (через Programmable Search Engine), указывая эти 50 сайтов как источники для Custom Content Crawler. Access Control Data не ограничивают доступ.
3. Результат: Пользователи получают высококачественный специализированный поиск, свободный от шума общего Web Search Index.

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