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

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

Content File (Контентный файл)

Документ, веб-страница или любой другой медиа-объект, подлежащий индексированию.

Index (Индекс)

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

Inclusive Portion (Включающая часть)

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

Index Builder (Построитель индекса)

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

Index Updater (Обновитель индекса)

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

Keyword (Ключевое слово)

Термин или фраза в запросе пользователя.

Portion (Часть)

Определенный сегмент контентного файла (например, параграф, предложение, сниппет).

Portion Evaluator (Оценщик частей)

Компонент, который определяет Inclusive Portions и присваивает им оценки (values).

Portion Selector (Селектор частей)

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

Retained Portion (Сохраняемая часть)

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

Snippet (Сниппет)

Фрагмент контента, отображаемый в результатах поиска. Может использоваться для определения Portions.

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

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

1. Система хранит индекс документов, разделенных на части (portions).
2. Мониторятся запросы пользователей.
3. Определяются Inclusive Portions — части документов, которые отвечают на запрос.
4. Обновляются оценки (values) для этих частей. Уточняется, что обновленная оценка для конкретной части представляет собой количество раз, когда эта часть была признана отвечающей на запросы пользователей.
5. На основе обновленных оценок выбираются Retained Portions.
6. Индекс обновляется: части исходных документов заменяются только выбранными Retained Portions.

Claim 7 (Зависимый): Уточняет, как могут определяться Inclusive Portions. Поисковая система предоставляет результаты поиска, включающие сниппеты (snippets). Эти сниппеты могут использоваться для определения Inclusive Portions.

Claim 8 (Зависимый): Уточняет механизм обновления оценок. Оценка обновляется путем увеличения соответствующего значения для каждой Inclusive Portion при каждом случае предоставления документа в ответ на запрос.

Claim 12 (Зависимый): Уточняет механизм выбора. Retained Portions выбираются путем сравнения их оценок с пороговым значением (threshold value).

Claim 15 (Зависимый): Описывает возможность использования двухъярусной системы индексирования. Оптимизированный индекс (где документы заменены на Retained Portions) является первым индексом. Система также включает второй индекс, который сохраняет полные версии документов даже после обновления первого индекса.

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

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

INDEXING – Индексирование и извлечение признаков

1. Предварительная обработка: Index Builder может выполнять начальную фильтрацию или усечение документов перед индексацией (например, на основе TF-IDF или шаблонов).
2. Сегментация: Portion Evaluator определяет границы частей (Portions) внутри документов.
3. Оптимизация хранения: Index Updater периодически перестраивает индекс, удаляя неиспользуемые части для экономии места и ускорения доступа.

RANKING – Ранжирование
Система использует данные, генерируемые на этапе ранжирования, для оптимизации индекса. Request Monitor отслеживает, какие документы и, что более важно, какие части этих документов (Inclusive Portions) используются для удовлетворения запросов на этапе Retrieval (L1).

Взаимодействие компонентов:
Index Manager (управляющий индексом) тесно взаимодействует с Search Manager (управляющим поиском). Request Monitor наблюдает за активностью Search Manager (какие запросы поступают и какие результаты возвращаются). Portion Evaluator использует эти данные для обновления Portion Value Repository. Portion Selector и Index Updater используют эти оценки для модификации Index.

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

• Индексированные документы (Content Files).
• Поток пользовательских запросов (User Requests) и ключевых слов (Keywords).
• Результаты поиска, включая информацию о том, какие документы были возвращены и какие сниппеты были сгенерированы.

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

• Оптимизированный индекс, содержащий только Retained Portions для обработанных документов.

На что влияет

• Типы контента: Влияет на все типы индексируемого контента.
• Форматы контента: Наиболее критично для длинных документов, где значительные части могут быть нерелевантны частым запросам (например, длинные условия использования, обширные нижние колонтитулы, неструктурированные форумы, документы с большим количеством комментариев).

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

• Мониторинг и оценка: Происходят непрерывно по мере поступления запросов пользователей.
• Отбор и обновление индекса: Происходят периодически. Триггером для активации процесса оптимизации является прохождение достаточного количества времени или обработка достаточного количества запросов, чтобы накопить статистически значимые данные об использовании частей контента.

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

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

Фаза А: Предварительная подготовка (Однократно или редко)

1. Индексирование и фильтрация: Index Builder получает документы. Может применяться предварительная фильтрация (усечение длинных документов, удаление boilerplate по шаблонам, фильтрация по TF-IDF). Оставшийся контент индексируется.
2. Идентификация частей: Portion Evaluator определяет границы частей (Portions) в индексированных документах (например, по параграфам, предложениям или фиксированному числу слов).

Фаза Б: Непрерывный мониторинг (Постоянно)

1. Получение запроса и результатов: Search Manager получает запрос и предоставляет результаты. Request Monitor отслеживает этот процесс.
2. Идентификация включающих частей: Portion Evaluator определяет, какие части возвращенных документов содержат ключевые слова запроса (Inclusive Portions). Это может быть сделано на основе того, откуда был взят сниппет.
3. Присвоение/Обновление оценки: Portion Evaluator увеличивает счетчик (value) для каждой идентифицированной Inclusive Portion в Portion Value Repository.

Фаза В: Периодическая оптимизация (По расписанию)

1. Проверка триггера: Система проверяет, прошло ли достаточно времени или обработано ли достаточно запросов с момента последней оптимизации.
2. Установка порога: Portion Selector устанавливает пороговое значение (threshold) для оценок. Порог может быть динамическим и корректироваться для контроля размера индекса.
3. Сравнение и отбор: Оценки всех частей сравниваются с порогом. Части, превышающие порог, выбираются как Retained Portions.
4. Обновление индекса: Index Updater обновляет индекс, заменяя исходные индексированные документы только их Retained Portions. Несохраняемые части удаляются из этого индекса.

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

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

• Контентные факторы: Текст документа и его структура (параграфы, предложения) используются для определения границ Portions.
• Поведенческие факторы: Ключевые данные для этого патента. Система использует:
  • Журналы запросов (User Requests) и ключевые слова (Keywords).
  • Данные о том, какие документы были показаны в ответ на запросы.
  • Сгенерированные сниппеты (Snippets) – используются как способ определения Inclusive Portions (Claim 7).
  • В одном из вариантов реализации (Claim 11) упоминается возможность использования данных о выборе документа пользователем (клики) для обновления оценок.

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

• Portion Value (Оценка части): Основная метрика. В патенте указано, что эта оценка представляет собой количество раз, когда данная часть была признана отвечающей на запросы пользователей (Claim 1). Основной способ расчета – инкрементальный счетчик (Claim 8).
• Threshold Value (Пороговое значение): Метрика, используемая Portion Selector для определения того, какие части следует сохранить. Если Portion Value > Threshold Value, часть сохраняется (Claim 12).
• TF-IDF (Term Frequency-Inverse Document Frequency): Упоминается в патенте (Description, Col 13), но только как возможный фактор для предварительной фильтрации документов на этапе начального индексирования, а не для основного процесса выборочного сохранения.

1. Эффективность индекса важнее его полноты: Патент демонстрирует готовность Google пожертвовать полнотой индексирования документа ради повышения скорости и уменьшения размера индекса.
2. Сохранение в индексе основано на использовании: Сохранение контента в индексе напрямую зависит от того, насколько часто этот конкретный фрагмент удовлетворяет реальные запросы пользователей. Контент, который не используется, будет удален.
3. Риск деиндексации релевантного контента: Существует риск того, что релевантный контент может быть исключен из индекса, если он редко ищется пользователями или если запросы сформулированы так, что система не сопоставляет их с этим конкретным фрагментом.
4. Важность структуры и сниппетов: Структура документа (параграфы) и сниппеты, которые Google генерирует для страницы, могут определять границы частей (Portions), которые оцениваются системой.
5. Потенциал двухъярусного индексирования: Патент явно описывает возможность применения этого механизма к первичному (быстрому и дорогому) индексу, в то время как полные документы могут храниться во вторичном (более медленном и дешевом) индексе (Claim 15).

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

• Фокус на соответствии интенту и реальным запросам: Создавайте контент, который напрямую отвечает на известные запросы пользователей. Необходимо гарантировать, что ключевые части вашего контента востребованы, чтобы они стали Retained Portions.
• Четкая структура контента: Используйте четкую семантическую структуру (заголовки, абзацы, списки). Это помогает системе корректно определить границы частей (Portions) и точно оценить их полезность.
• Оптимизация под сниппеты: Убедитесь, что ключевые темы вашей страницы генерируют релевантные сниппеты в SERP. Патент указывает, что сниппеты могут использоваться для определения Inclusive Portions (Claim 7). Если важная часть контента никогда не попадает в сниппет, её ценность может быть недооценена.
• Размещение важной информации в начале (Front-loading): Хотя система оценивает все части, размещение ключевой информации в начале повышает вероятность её использования в сниппетах и, следовательно, корректной оценки её полезности.

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

• Скрытие ключевой информации в длинном, нефокусированном тексте: Если важная информация "погребена" в тексте, который редко соответствует запросам, она рискует быть удаленной из индекса.
• Чрезмерное использование Boilerplate и шаблонного контента: Создание страниц, где основной контент значительно уступает по объему навигации, рекламе или шаблонным блокам. Эти блоки могут быть либо отфильтрованы на начальном этапе, либо получат низкую оценку полезности и будут удалены.
• Игнорирование реального поискового поведения: Оптимизация исключительно под ключевые слова, которые пользователи на самом деле не используют для поиска данного контента. Система оценивает полезность на основе реальных запросов, а не потенциальной релевантности.

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

Этот патент подтверждает движение Google в сторону понимания контента на уровне пассажей (Passage Understanding) и критическую важность соответствия реальному поисковому поведению. Он подчеркивает, что индексирование всей страницы не гарантировано. Стратегия должна фокусироваться на создании контента, где каждая часть имеет четкую цель и соответствует определенному набору интентов. Это инфраструктурный патент, но он напрямую влияет на то, какой контент будет доступен для ранжирования.

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

Сценарий: Оптимизация индекса для длинного руководства

1. Ситуация: Сайт опубликовал длинное руководство (5000 слов) "Полное руководство по уходу за кофемашиной". Оно разделено на 10 разделов.
2. Поведение пользователей: Анализ показывает, что 80% трафика приходит по запросам, связанным с Разделом 3 ("Как очистить кофемашину от накипи"), и 15% по Разделом 7 ("Устранение протечек"). Остальные разделы почти не получают трафика.
3. Работа алгоритма:
   • Система Google определяет Разделы 3 и 7 как Inclusive Portions для большинства запросов и постоянно увеличивает их оценки (values).
   • Остальные 8 разделов редко становятся Inclusive Portions, их оценки остаются низкими.
4. Оптимизация индекса: При следующей итерации оптимизации Google устанавливает порог. Разделы 3 и 7 его превышают и становятся Retained Portions.
5. Результат: В первичном индексе Google эта страница теперь представлена только контентом из Разделов 3 и 7. Если пользователь введет запрос, релевантный Разделу 5 (например, "настройка помола в кофемашине"), эта страница больше не будет найдена в первичном индексе, так как Раздел 5 был удален.