Как Google эффективно извлекает Топ-N результатов с помощью итеративного битового поиска по ранжирующим оценкам

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

Index Entry (Запись индекса)

Структура данных в индексе, соответствующая определенному ресурсу (документу). Содержит Resource ID и связанные Sort Keys.

Order-preserving bijection (Биекция, сохраняющая порядок)

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

Predetermined Threshold (Предопределенный порог)

Целевое количество результатов (Топ-N), которое система стремится найти (например, 10).

Restrict Criterion (Критерий ограничения)

Параметр поиска, реализованный как битовый префикс (строка бинарных цифр, например, "110"). Используется для фильтрации Sort Key Values. Система итеративно корректирует этот критерий.

Sort Key (Ключ сортировки)

Индексированный атрибут ресурса, по которому производится сортировка. Примеры: оценка качества (Quality Score), дата публикации, размер файла, Ranking Score.

Sort Key Value (Значение ключа сортировки)

Конкретное значение Sort Key для данного ресурса, преобразованное в бинарный формат с помощью Order-preserving bijection.

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

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

1. Система хранит индекс, где каждая запись имеет Sort Key и Sort Key Value.
2. Получается запрос.
3. Получается первый Restrict Criterion (битовый префикс), используемый как параметр поиска по Sort Key Values.
4. Определяется первое количество (first count) записей, которые релевантны запросу И чьи Sort Key Values удовлетворяют критерию.
5. Проверяется, удовлетворяет ли это количество Predetermined Threshold.
6. Если ДА, набор записей извлекается, генерируются результаты поиска и предоставляются пользователю.

Claim 2 (Зависимый от 1): Описывает логику обработки ситуации "Слишком много результатов" (Refinement).

1. Если первое количество превышает порог, система модифицирует Restrict Criterion путем увеличения его битовой длины (increasing a bit-length) на один или более битов (например, с "1" на "11").
2. Определяется обновленное количество результатов.
3. Если оно все еще превышает порог, процесс итеративно повторяется с дальнейшим увеличением длины префикса для сужения поиска.

Claim 3 (Зависимый от 1): Описывает логику обработки ситуации "Слишком мало результатов" (Relaxation).

1. Если первое количество меньше порога, система модифицирует Restrict Criterion путем уменьшения на единицу бинарного значения префикса (decrementing by one a bit-level prefix) (например, с "111" на "110").
2. Определяется обновленное количество результатов в новом диапазоне.
3. Если общее количество все еще меньше порога, процесс итеративно повторяется с дальнейшим уменьшением значения префикса.

Claim 6 (Зависимый от 1): Описывает использование нескольких порядков сортировки (Multiple Sort Orders / Tie-breaking).

1. Если количество результатов превышает порог (например, из-за множества документов с одинаковым значением первого Sort Key), система вводит второй Sort Key и второй Restrict Criterion.
2. Определяется количество результатов, удовлетворяющих обоим критериям.
3. При необходимости может быть введен третий ключ и критерий.

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

Изобретение является инфраструктурным и затрагивает этапы индексирования и ранжирования (в части извлечения данных).

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит подготовка данных. Система рассчитывает или извлекает атрибуты ресурсов (Sort Keys), такие как оценки качества, даты, размеры. Эти значения преобразуются с помощью Order-preserving bijections в бинарный формат (Sort Key Values) и сохраняются в Index Entries.

RANKING – Ранжирование (Этап Retrieval / Отбор кандидатов L1/L2)
Это основная область применения. Когда система определила широкий набор релевантных документов, ей необходимо эффективно извлечь Топ-N из этого набора, отсортированных по нужному Sort Key (например, по итоговому Ranking Score или дате). Вместо полной сортировки всех кандидатов активируется описанный механизм итеративного битового поиска.

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

• Запрос пользователя и его признаки (определяющие порядок сортировки).
• Начальный набор релевантных Index Entries.
• Sort Key Values для этих записей.
• Predetermined Threshold (N).

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

• Набор из Топ-N Index Entries, отсортированных в соответствии с запрошенным порядком.

На что влияет

• Специфические запросы: Наибольшее влияние на эффективность обработки запросов, требующих четкой сортировки. Это включает запросы, чувствительные к свежести (QDF – Query Deserves Freshness), где Sort Key — это дата, или запросы в специализированных вертикалях (например, сортировка товаров по цене).
• Эффективность системы: Влияет на скорость ответа поисковой системы и потребление вычислительных ресурсов.

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

• Условия работы алгоритма: Применяется, когда необходимо извлечь ограниченное количество результатов (Топ-N), отсортированных по определенному Sort Key, из значительно большего набора релевантных документов.
• Триггеры активации: Определение системой необходимости сортировки результатов по специфическому атрибуту или использование стандартной сортировки по Ranking Score на этапе отбора кандидатов.

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

Основной итеративный процесс извлечения Топ-N

1. Инициализация: Система получает запрос, определяет начальный набор релевантных записей индекса. Определяется требуемый Sort Key (например, Качество) и Predetermined Threshold (N).
2. Получение критерия ограничения: Выбирается начальный Restrict Criterion (битовый префикс, например, "111" для наивысшего качества).
3. Подсчет результатов: Система определяет количество записей в начальном наборе, чьи Sort Key Values начинаются с данного префикса.
4. Проверка порога: Количество сравнивается с порогом N.
5. Принятие решения и Итерация:
   • Результат (Satisfied): Если количество удовлетворяет порогу, процесс завершается (Шаг 6).
   • Слишком много (Too Many / Refinement): Если количество > N, система модифицирует Restrict Criterion, увеличивая его битовую длину (например, "111" -> "1111"). Возврат к шагу 3.
   • Слишком мало (Too Few / Relaxation): Если количество < N, система сохраняет результаты. Модифицирует Restrict Criterion, уменьшая его битовое значение (например, "111" -> "110"). Возврат к шагу 3.
6. Завершение и выдача: Система формирует набор результатов поиска.

Оптимизации и особые случаи:

• Обработка связей (Ties): Если значения Sort Key первого и N-го результата в текущем наборе "существенно схожи", итерации могут быть прекращены.
• Множественные ключи: Если результатов слишком много из-за связей по первому ключу, вводится второй Sort Key и процесс повторяется с учетом обоих критериев.
• Исчерпание (Exhaustion): Если найдены все оставшиеся релевантные документы, система выбирает лучший Топ-N из них и прекращает итерации.

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

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

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

• Системные данные (Предварительно рассчитанные метрики): Основными данными являются Sort Key Values. Это могут быть любые сортируемые атрибуты, рассчитанные на этапе индексирования. В патенте упоминаются примеры:
  • Оценка качества ресурса (quality of the resource).
  • Временные факторы (creation time, дата получения).
  • Технические факторы (size of a resource).

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

• Преобразование данных: Система использует Order-preserving bijections для конвертации различных типов данных (floating point, double, signed/unsigned integer, character string) в унифицированный бинарный формат.
• Restrict Criterion: Битовый префикс, используемый для фильтрации. Модифицируется путем изменения длины или значения.
• Predetermined Threshold (N): Пороговое значение для управления итеративным процессом.
• Алгоритмы поиска: Упоминается возможность использования алгоритма бинарного поиска (binary search algorithm) для эффективного поиска Sort Key Values на основе Restrict Criterion.

1. Фокус на эффективности извлечения, а не на ранжировании: Патент описывает инфраструктурный механизм оптимизации производительности (Retrieval). Он не определяет, как рассчитываются факторы ранжирования (Sort Keys), но объясняет, как система быстро находит документы с наивысшими значениями этих факторов.
2. Итеративный битовый поиск вместо полной сортировки: Ключевая инновация — избегание ресурсоемкой сортировки большого количества кандидатов за счет итеративного уточнения диапазона поиска с помощью битовых префиксов (Restrict Criterion).
3. Универсальность и гибкость сортировки: Механизм универсален и может применяться к любому атрибуту, конвертированному в Sort Key Value (качество, дата, размер и т.д.), благодаря использованию Order-preserving bijections.
4. Поддержка сложных сценариев сортировки: Система способна эффективно обрабатывать сортировку по нескольким критериям (Multiple Sort Orders) для разрешения ничьих (tie-breaking) или выполнения сложных запросов.
5. Зависимость от предварительных вычислений: Эффективность механизма зависит от наличия предварительно рассчитанных и проиндексированных в нужном формате Sort Key Values.

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

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

• Обеспечение точности временных меток: Поскольку дата и время являются ключевыми примерами Sort Keys, этот механизм позволяет Google эффективно сортировать контент по свежести (QDF). Убедитесь, что даты публикации и обновления (в Schema.org, Sitemaps и на странице) точны и доступны для индексации.
• Использование четких структурированных данных: Для E-commerce и контентных сайтов важно предоставлять точные данные об атрибутах (цена, рейтинг) через микроразметку. Это гарантирует, что система сможет корректно интерпретировать эти данные как Sort Keys и использовать их при запросах с соответствующей сортировкой.
• Фокус на максимизации ранжирующих метрик: Стратегически важно фокусироваться на улучшении факторов, которые формируют основные Sort Keys (релевантность, E-E-A-T, качество). Этот механизм гарантирует, что если ваш сайт имеет наивысшие оценки, он будет эффективно и быстро найден системой.

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

Патент не направлен против конкретных SEO-тактик, но можно сделать косвенный вывод:

• Манипуляция временными метками: Искусственное обновление дат без существенного изменения контента. Хотя этот конкретный механизм просто отсортирует контент по предоставленным датам, другие системы Google могут выявить такие манипуляции и понизить общую оценку качества, что приведет к снижению значений основных Sort Keys.

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

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

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

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

Сценарий: Эффективное извлечение Топ-10 результатов по Quality Score

Задача: Найти 10 лучших результатов (N=10). Sort Key = Quality Score (представлен 3 битами, от 000 до 111).

1. Инициализация: Система идентифицирует 100,000 релевантных документов. Начальный Restrict Criterion = "1" (поиск высоких оценок).
2. Итерация 1: Поиск по префиксу "1". Найдено 50,000 документов. (Слишком много).
3. Итерация 2 (Refinement): Увеличение длины префикса. Новый критерий = "11". Найдено 25,000 документов. (Слишком много).
4. Итерация 3 (Refinement): Увеличение длины префикса. Новый критерий = "111". Найдено 3 документа. (Слишком мало).
5. Итерация 4 (Relaxation): Система сохраняет 3 документа. Осталось найти 7. Уменьшение значения префикса. Новый критерий = "110".
6. Итерация 5: Поиск по префиксу "110". Найдено 15 документов. (Удовлетворяет порогу).
7. Результат: Система выбирает Топ-7 из последних 15 и объединяет с первыми 3. Топ-10 сформирован за 5 итераций без полного сканирования 100,000 документов.