Как Google агрегирует поведенческие данные из похожих запросов для ранжирования редких и длиннохвостых запросов

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

Click Data (Данные о кликах)

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

Edit Distance (Расстояние редактирования)

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

Generalized Quality of Result Statistic (Обобщенная статистика качества результата)

Метрика качества документа для исходного запроса, рассчитанная путем агрегации user behavior data из одного или нескольких обобщенных (variant) запросов.

Generalized Query / Variant Query (Обобщенный / Вариантный запрос)

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

Long Click / Short Click (Длинный / Короткий клик)

Классификация кликов на основе dwell time. Длинный клик обычно интерпретируется как признак релевантности документа, короткий клик — как признак отсутствия релевантности.

Match Belief Score (Оценка уверенности в совпадении)

Метрика, оценивающая семантическую близость между исходным запросом и обобщенным запросом. Основана на типах и количестве обобщений, необходимых для совпадения. Используется для взвешивания данных: чем ниже оценка, тем меньше вес у поведенческих данных.

Model (Модель)

База данных, агрегирующая информацию о поведении пользователей. Хранит записи (tuples) как минимум в формате <документ, запрос, данные>.

Optional Terms (Опциональные термины)

Термины в запросе, удаление которых не меняет основного концепта (интента) запроса. Пример: удаление "Toyota" из "Toyota celica hatchback".

Partial Query Match (Частичное совпадение запроса)

Ситуация, когда один или несколько терминов исходного запроса совпадают с одним или несколькими терминами запроса в модели.

Query Generalizer (Обобщитель запросов)

Компонент системы, отвечающий за создание вариантов (обобщений) исходного запроса.

Stop Words (Стоп-слова)

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

Tuple (Кортеж)

Запись в модели, связывающая документ, запрос и агрегированные поведенческие данные для этой пары.

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

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

1. Система получает пользовательский запрос и генерирует начальный рейтинг документов.
2. Система определяет, что исходный запрос не соответствует ни одной записи в модели (model) запросов и документов.
3. В ответ на это система формирует один или несколько вариантов (variants) исходного запроса для генерации одного или нескольких других запросов, которые соответствуют записям в модели. Эти другие запросы отличаются от исходного.
4. Система выводит generalized quality of result statistic для первого документа на основе данных, связанных с этими другими запросами в модели. Эти данные указывают на агрегированное поведение пользователей (aggregate user behavior) в отношении этого документа, когда он был результатом поиска по этим другим запросам.
5. Система предоставляет эту статистику в качестве входных данных для последующего процесса ранжирования документов по исходному запросу.

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

Вариант запроса формируется путем выполнения одного или нескольких действий: замена терминов синонимами, изменение порядка терминов (перестановка) или замена терминов их основами (стемминг).

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

Вывод статистики включает модификацию статистики качества результата на основе уровня уверенности (level of certainty) для каждого из сгенерированных запросов (т.е. применение match belief score).

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

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

INDEXING / Офлайн-процессы
На этом этапе происходит построение Модели (Model Building). Система анализирует логи взаимодействия пользователей с поисковой выдачей (result selection logs), агрегирует click data (включая dwell time) и сохраняет их в виде кортежей <документ, запрос, данные>. Также может происходить предварительная обработка запросов, например, создание версий без стоп-слов.

RANKING – Ранжирование
На этом этапе генерируется начальный рейтинг (Initial Ranking) документов на основе стандартных IR-сигналов.

RERANKING – Переранжирование
Основное применение патента. Компонент Rank Modifier использует данные из Модели для корректировки начального рейтинга.

1. Проверка наличия данных: Система проверяет, есть ли в Модели данные для исходного запроса и документа.
2. Активация обобщения: Если данных нет или недостаточно, активируется Query Generalizer.
3. Генерация и поиск вариантов: Создаются варианты запроса, ищутся совпадения в Модели.
4. Расчет статистики: Вычисляется generalized quality of result statistic с учетом весов (match belief score, edit distance).
5. Модификация рейтинга: Статистика используется для переранжирования и создания финального рейтинга (Final Ranking).

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

• Исходный пользовательский запрос.
• Начальный рейтинг документов (Initial Ranking).
• Модель (Model) с агрегированными поведенческими данными.

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

• Generalized quality of result statistic для одного или нескольких документов.
• Финальный рейтинг документов (Final Ranking).

На что влияет

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

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

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

• Условие активации: Когда для пары исходный запрос-документ отсутствует или недостаточно исторических поведенческих данных в Модели.
• Условие успешного применения: Когда удается сгенерировать один или несколько вариантов (обобщений) исходного запроса, которые присутствуют в Модели для данного документа.

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

Процесс А: Обработка запроса и переранжирование (Онлайн)

1. Получение запроса и начального рейтинга: Система получает запрос и генерирует Initial Ranking.
2. Выбор документа: Система итерирует по документам в начальном рейтинге.
3. Проверка Модели (Exact Match): Проверяется, есть ли в Модели кортеж для точного совпадения исходного запроса и документа.
   • Если ДА: Рассчитать статистику качества на основе этих данных. Перейти к шагу 8.
   • Если НЕТ: Активировать Query Generalizer. Перейти к шагу 4.
4. Генерация вариантов запроса: Система применяет техники обобщения последовательно или параллельно: удаление стоп-слов, опциональных терминов, замена синонимами, стемминг, перестановки, частичное совпадение.
5. Поиск вариантов в Модели: Система ищет сгенерированные варианты в кортежах, связанных с данным документом.
6. Выбор наилучшего совпадения (Опционально): Если найдено несколько вариантов, может быть выбран вариант с наивысшим Match Belief Score (наименьшее количество и сложность обобщений).
7. Расчет обобщенной статистики: Система агрегирует поведенческие данные из найденных кортежей. Применяется понижающий коэффициент (down-weighting) на основе Match Belief Score или Edit Distance.
8. Модификация ранжирования: Рассчитанная generalized quality of result statistic используется компонентом Rank Modifier для корректировки позиции документа.
9. Повторение: Повторить для следующего документа (шаг 2).

Процесс Б: Построение Модели (Офлайн)

1. Сбор данных: Компонент Tracking Component записывает взаимодействия пользователей (запрос, клик, dwell time) в Result Selection Logs.
2. Агрегация данных: Логи обрабатываются, данные агрегируются по парам запрос-документ (например, подсчет long clicks и short clicks).
3. Сохранение в Модели: Данные сохраняются в виде кортежей <документ, запрос, данные>.
4. Предварительная обработка (Опционально): Для существующих кортежей могут создаваться дополнительные кортежи с обобщенными версиями запросов (например, без стоп-слов), и данные могут пропагироваться между ними.

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

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

Патент фокусируется на использовании поведенческих данных и метаданных запросов.

• Поведенческие факторы (User Behavior Data): Ключевые данные. Включают Click Data, Dwell time (время на документе), классификацию кликов (Long Click, Short Click). Также упоминаются другие данные: позиция клика, информация о сессии, IR-оценки показанных результатов, заголовки и сниппеты, cookie пользователя, IP-адрес, User Agent.
• Контентные/Лингвистические факторы: Используются для процесса обобщения: списки стоп-слов, базы данных синонимов, алгоритмы стемминга.

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

• Match Belief Score: Оценка семантической близости. Рассчитывается путем применения штрафов (penalties) за каждое необходимое обобщение (например, штраф за удаление стоп-слова, штраф за синоним). Штрафы могут перемножаться при комбинировании обобщений.
• Edit Distance (ed): Метрика различия между запросами (количество вставок/удалений/замен терминов). Используется при частичном совпадении.
• Click Fraction (f): Взвешенная доля кликов для пары запрос-документ. Может рассчитываться как: $f = \frac{\#wc(query, document)}{\#c(query)}$ (где #wc – сумма взвешенных кликов, #c – общее число кликов).
• Down-weighted Click Fraction (df): Пониженная в весе доля кликов. Используется для моделирования потери семантического контекста при частичном совпадении. Рассчитывается с использованием экспоненциального затухания на основе edit distance (ed): $df(nq, uq) = f(nq, uq) \times (1+ed(nq, uq))^{-k}$ (где nq – запрос из модели, uq – исходный запрос, k > 1).
• Final Click Fraction (ff): Итоговая доля кликов для документа при частичном совпадении. Рассчитывается на основе вектора V, содержащего нормализованные суммы df для каждого термина исходного запроса: $ff = \frac{(median(V) + \alpha min(V))}{1+\alpha}$ (где α – константа).

1. Агрегация поведенческих сигналов между запросами: Патент подтверждает, что Google активно использует поведенческие данные (user behavior data, click data) не только для конкретного запроса, но и агрегирует их из семантически связанных запросов. Это позволяет системе оценивать качество документа даже при отсутствии прямых исторических данных.
2. Важность удовлетворения интента (User Satisfaction): Основой механизма являются данные о кликах и dwell time (long clicks). Положительные поведенческие сигналы на странице по одному запросу улучшают её ранжирование по множеству других связанных запросов.
3. Механизмы семантического обобщения: Система использует конкретные лингвистические и статистические методы для определения связи между запросами: синонимы, стемминг, игнорирование стоп-слов и опциональных терминов, а также частичное совпадение. Это не простое совпадение ключевых слов, а попытка найти запросы с аналогичным интентом.
4. Взвешивание на основе уверенности: Система не доверяет обобщенным данным слепо. Используются метрики уверенности (Match Belief Score) и семантической дистанции (Edit Distance). Чем дальше обобщенный запрос от оригинала, тем меньше вес его поведенческих данных. Применяются сложные формулы взвешивания, включая экспоненциальное затухание.
5. Обработка Long-Tail запросов: Этот механизм критически важен для ранжирования по НЧ и редким запросам. Он позволяет страницам, хорошо отвечающим на более общие или популярные запросы в теме, получать преимущество в ранжировании по связанным длиннохвостым запросам.
6. Пропагация данных при уточнении запроса: Патент также описывает механизм переноса поведенческих данных от уточненного запроса к исходному в рамках одной сессии, что усиливает сигналы релевантности для более общих запросов.

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

• Фокус на Topical Authority и широком охвате темы: Создавайте контент, который всесторонне покрывает тему и отвечает на различные варианты запросов (синонимы, разные формулировки). Если страница получает положительные поведенческие сигналы по популярным запросам кластера, она получит буст по всем связанным long-tail запросам за счет механизма обобщения.
• Оптимизация под User Satisfaction (Long Clicks): Обеспечьте максимальное удовлетворение интента пользователя, чтобы стимулировать long clicks и минимизировать short clicks. Это главный источник данных для Модели, описанной в патенте. Качество поведенческих факторов напрямую влияет на quality of result statistic.
• Использование синонимов и вариаций в контенте: Естественное использование синонимов и различных форм слов (стемминг) в тексте и заголовках помогает системе лучше ассоциировать страницу с различными вариантами запросов, увеличивая вероятность того, что страница будет рассмотрена при обобщении.
• Анализ семантического кластера: При анализе эффективности страницы учитывайте её производительность по всему кластеру связанных запросов, а не только по целевому ключу. Улучшение позиций по одному запросу в кластере может быть результатом агрегации сигналов из других запросов этого же кластера.

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

• Узкая оптимизация под точное вхождение ключа: Создание контента, оптимизированного только под одну конкретную формулировку запроса, неэффективно. Система обобщает запросы, и если страница нерелевантна семантическим вариантам, она не сможет воспользоваться агрегированными поведенческими данными.
• Игнорирование поведенческих факторов: Стратегии, направленные на получение клика любой ценой (кликбейт) без последующего удовлетворения интента (что приводит к short clicks), будут пессимизироваться. Эти негативные сигналы также агрегируются и могут ухудшить ранжирование по всему кластеру запросов.
• Создание разрозненных страниц под каждый НЧ запрос (Doorways): Попытка создать отдельные слабые страницы под каждую вариацию запроса менее эффективна, чем создание одной сильной страницы, которая агрегирует поведенческие сигналы из множества вариаций.

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

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

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

Сценарий: Использование данных из синонимичного запроса

1. Ситуация: Продвигается страница интернет-магазина по новому запросу "купить автомобиль с пробегом" (Query 1). Исторических данных мало.
2. Модель Google: В Модели есть много данных по запросу "купить авто бу" (Query 2) для этой же страницы, и они положительные (много long clicks).
3. Работа алгоритма: Система распознает "автомобиль" как синоним "авто" и "с пробегом" как семантически близкое к "бу". Она генерирует Query 2 как вариант Query 1.
4. Взвешивание: Рассчитывается Match Belief Score. Так как использовались синонимы, score может быть, например, 0.8.
5. Применение: Положительные поведенческие данные из Query 2 используются для расчета generalized quality of result statistic для Query 1, но с понижающим коэффициентом 0.8.
6. Результат: Страница получает буст в ранжировании по запросу "купить автомобиль с пробегом" благодаря хорошей истории по "купить авто бу".

Сценарий: Использование данных из частичного совпадения (Partial Match)

1. Ситуация: Продвигается страница по запросу "рецепт яблочного пирога с корицей быстро" (Query 1). Данных нет.
2. Модель Google: В Модели есть данные для этой страницы по запросу "рецепт яблочного пирога" (Query 2).
3. Работа алгоритма: Система определяет Query 2 как частичное совпадение для Query 1.
4. Взвешивание: Рассчитывается Edit Distance. Для превращения Query 1 в Query 2 нужно удалить 3 слова ("с корицей быстро"). Edit distance = 3.
5. Применение: Поведенческие данные из Query 2 используются для Query 1, но с применением экспоненциального затухания на основе Edit Distance=3 (вес будет значительно понижен).
6. Результат: Страница получает небольшой буст по Query 1, так как она релевантна основной части запроса.