Как Google персонализирует подсказки Autocomplete, используя предыдущий запрос пользователя и коллаборативную фильтрацию

Описание

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

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

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

Запатентована система и метод переранжирования вариантов завершения запроса (Query Completions) с использованием контекста сессии. Система использует предыдущий запрос пользователя (Reference Query) для идентификации других запросов (Likely Queries), которые статистически часто встречаются в одной сессии с ним. Этот процесс основан на анализе данных о сессиях множества пользователей (коллаборативная фильтрация). Варианты подсказок, совпадающие с этими Likely Queries, получают повышение в рейтинге.

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

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

• Получение контекста: Когда пользователь начинает вводить запрос (Query Prefix), система идентифицирует его предыдущий запрос (Reference Query).
• Анализ корреляций: Система обращается к базе данных сессий (User Activity Sessions), чтобы найти Likely Queries — запросы, которые часто появляются в той же сессии, что и Reference Query.
• Расчет статистической значимости: Определяется не просто частота совместной встречаемости, а статистическая значимость этой связи (насколько чаще эти запросы встречаются вместе, чем по отдельности).
• Переранжирование: Если стандартная подсказка для Query Prefix совпадает с одним из Likely Queries, ее рейтинг повышается с помощью рассчитанного коэффициента (Boost Value). Система также может вставлять новые релевантные подсказки.
• Вывод: Пользователь получает персонализированный список подсказок, адаптированный к его недавней поисковой активности.

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

Высокая. Персонализация и понимание контекста сессии (Session-Based Context) являются ключевыми направлениями развития поисковых систем. Технология, описанная в патенте, лежит в основе работы современного Google Autocomplete, обеспечивая адаптацию подсказок в реальном времени. Присутствие ключевых инженеров Google, таких как Jeffrey Dean (глава Google AI) и Noam Shazeer (один из изобретателей Transformer), подчеркивает стратегическую важность и проработанность этого механизма.

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

Патент имеет значительное, хотя и косвенное, влияние на SEO (7.5/10). Он не касается напрямую ранжирования веб-документов, но критически важен для понимания того, как работает Google Autocomplete и как Google интерпретирует связи между различными запросами и интентами на основе реального поведения пользователей. Это влияет на стратегии оптимизации под поисковые подсказки и требует глубокого анализа пути пользователя (User Journey) и того, как запросы группируются в рамках одной сессии.

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

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

Boost Value (B) (Коэффициент повышения)

Множитель, применяемый к исходному рейтингу подсказки. Рассчитывается на основе статистической корреляции между подсказкой и Reference Query. Формула расчета часто называется Lift.

Collaborative Filtering (Коллаборативная фильтрация)

Метод прогнозирования интересов пользователя на основе анализа поведения похожих пользователей. В данном патенте применяется для анализа связей между запросами в сессиях.

Likely Queries (Вероятные запросы)

Запросы, которые статистически часто встречаются в одной сессии с Reference Query. Вероятность их совместной встречаемости выше, чем вероятность их появления в случайной сессии.

P(x) (Безусловная вероятность)

Мера вероятности появления запроса ‘x’ в любой пользовательской сессии (глобальная популярность).

P(x|q) (Условная вероятность)

Мера вероятности появления запроса ‘x’ в сессии, при условии, что в этой же сессии также присутствует Reference Query ‘q’.

Prediction Engine (Механизм прогнозирования)

Компонент системы, отвечающий за анализ User activity sessions и вычисление Likely Queries для заданного Reference Query.

Proximity Window (Окно близости)

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

Query Completion (Вариант завершения запроса)

Поисковая подсказка (Autocomplete).

Query Prefix (Префикс запроса)

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

Reference Query (q) (Опорный запрос)

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

User Activity Sessions (Сессии активности пользователя)

Данные, описывающие активность пользователя (запросы, клики) за определенный период времени.

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

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

1. Система получает Query Prefix от пользователя.
2. Получает начальный рейтинг Query Completions с их Ranking Scores.
3. Получает Reference Query для пользователя.
4. Идентифицирует сессии (matching user activity sessions), которые содержат Reference Query.
5. Идентифицирует Likely Queries, которые встречаются в этих сессиях. Для каждого рассчитывается likelihood score.
6. Ключевой момент: likelihood score представляет вероятность появления запроса в этих сессиях относительно вероятности его появления во всех сессиях.
7. Определяется совпадение между подсказкой и Likely Query.
8. Ranking Score совпадающей подсказки повышается (boosting) на величину, основанную на likelihood score.
9. Определяется и предоставляется модифицированный рейтинг.

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

Claim 3 (Зависимый от 2): Детализирует расчет коэффициента повышения (Boost Value B).

Коэффициент B рассчитывается по формуле: B = P(x|q) / P(x).

P(x|q) — вероятность подсказки ‘x’ в сессии, где есть опорный запрос ‘q’. P(x) — вероятность подсказки ‘x’ в любой сессии. Эта формула измеряет, насколько присутствие ‘q’ увеличивает вероятность ‘x’ по сравнению с базовым уровнем (статистическая мера «Lift»).

Claim 4 (Зависимый от 1): Уточняет, что Reference Query — это недавний запрос (отправленный в пределах порогового количества запросов до текущего префикса).

Claim 6 (Зависимый от 5): Описывает возможность вставки (inserting) Likely Query в рейтинг подсказок, даже если его не было в изначальном списке.

Claim 7 (Зависимый от 1): Уточняет, что идентификация Likely Queries может учитывать запросы, отправленные в пределах определенного окна близости (proximity window) от Reference Query.

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

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

CRAWLING – Сканирование и Сбор данных (Data Acquisition)
На этом этапе система собирает логи пользовательской активности, включая последовательности запросов, формируя User activity sessions. Эти данные являются сырьем для анализа.

INDEXING – Индексирование и извлечение признаков (Data Analysis)
Происходит офлайн-обработка данных. Prediction Engine анализирует Session Database для выявления корреляций между запросами. Рассчитываются условные и безусловные вероятности (P(x|q) и P(x)). Результаты могут быть сохранены в виде заранее рассчитанных распределений (precomputed distribution) Likely Queries для популярных запросов (Claim 10).

QUNDERSTANDING – Понимание Запросов
Основной этап применения. Система работает в реальном времени, когда пользователь вводит Query Prefix.

1. Query Completion Engine генерирует начальный набор подсказок.
2. Система идентифицирует Reference Query (предыдущий запрос пользователя).
3. Prediction Engine предоставляет Likely Queries для Reference Query (используя офлайн-расчеты).
4. Query Completion Reranker сопоставляет данные и применяет Boost Value для переранжирования подсказок.

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

• Query Prefix (текущий ввод пользователя).
• Reference Query (предыдущий запрос пользователя).
• Начальный список Query Completions с их Ranking Scores.
• Данные о корреляциях запросов (из Session Database или прекомпьютерных таблиц).

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

• Модифицированный (персонализированный) список Query Completions с пересчитанными Ranking Scores.

На что влияет

• Специфические запросы: Наибольшее влияние на запросы, которые являются частью многошаговых поисковых задач (User Journeys), или на короткие/неоднозначные префиксы, где контекст сессии критически важен для уточнения интента.
• Конкретные ниши или тематики: Сильное влияние в тематиках, требующих исследования, сравнения или планирования (eCommerce, путешествия, рецепты, сложные информационные запросы), где пользователи часто отправляют несколько связанных запросов подряд.

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

• Триггеры активации: Ввод пользователем Query Prefix в поисковую строку.
• Условия применения: Механизм активируется, если:
  1. У пользователя есть недавний Reference Query (в пределах Proximity Window).
  2. Для этого Reference Query существуют статистически значимые данные о Likely Queries (т.е. система имеет достаточно данных о сессиях, включающих этот запрос).
  3. Один или несколько Likely Queries совпадают с вариантами завершения текущего префикса или могут быть вставлены как новые подсказки.

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

Процесс А: Предварительная обработка (Offline)

1. Сбор и анализ сессий: Система собирает и анализирует User Activity Sessions для идентификации пар запросов (q, x), встречающихся в одной сессии.
2. Расчет вероятностей: Вычисляются P(x) (общая частота x) и P(x|q) (частота x при наличии q). Применяются методы сглаживания и обработки редких данных.
3. Расчет Boost Value: Для статистически значимых пар вычисляется B = P(x|q) / P(x).
4. Сохранение: Данные о Likely Queries и их Boost Values сохраняются для быстрого доступа.

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

1. Получение ввода и контекста: Система получает Query Prefix и идентифицирует Reference Query (q).
2. Генерация начальных подсказок: Query Completion Engine генерирует первый набор Query Completions.
3. Получение вероятных запросов: Система извлекает Likely Queries (x) и их Boost Values (B) для данного Reference Query (q).
4. Сопоставление: Система определяет, какие из начальных подсказок совпадают с Likely Queries.
5. Применение повышения: Исходный Ranking Score (S) совпадающих подсказок умножается на Boost Value (B) (S’ = B * S).
6. Вставка новых подсказок (Опционально): Система может вставить Likely Queries, которых не было в начальном списке (Claim 6).
7. Модификация рейтинга и вывод: Система формирует финальный список и отображает его пользователю.

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

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

Система полагается почти исключительно на поведенческие данные.

• Поведенческие факторы:
  • User Activity Sessions: Логи запросов, сгруппированные по сессиям. Это основной источник данных для анализа корреляций.
  • Частота запросов: Данные о том, как часто конкретный запрос встречается во всех сессиях (используется для расчета P(x)).
  • Совместная встречаемость (Co-occurrence): Данные о том, как часто два запроса встречаются в одной сессии (используется для расчета P(x|q)).
• Пользовательские факторы:
  • Текущий ввод: Query Prefix.
  • История сессии: Недавний Reference Query пользователя.
• Временные факторы: Используются для определения границ сессий и Proximity Window.

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

• P(x|q) (Условная вероятность): Рассчитывается как количество сессий, содержащих и ‘x’, и ‘q’, деленное на общее количество сессий, содержащих ‘q’. Формула: P(x|q) = N(x,q) / N(q).
• P(x) (Безусловная вероятность): Рассчитывается как количество сессий, содержащих ‘x’, деленное на общее количество всех сессий. Формула: P(x) = N(x) / N.
• Boost Value (B) (Коэффициент повышения / Lift): Основная метрика для переранжирования. Формула: B = P(x|q) / P(x).
• Скорректированный Ranking Score (S’): Итоговая оценка подсказки. Формула: S’ = B * S (где S — исходная оценка).
• Обработка редких данных: Патент описывает методы для предотвращения искажений из-за недостатка данных (например, для редких запросов):
  • Использование минимального порога количества сессий (N_min).
  • «Раздувание» знаменателя (P(x)) при малом количестве наблюдений для уменьшения буста.
  • Использование доверительных интервалов (binomial proportion confidence interval) для оценки P(x|q), например, использование нижней границы интервала.
• Смещение бустинга (Biasing): Упоминается возможность использования экспоненты ‘e’ для смещения бустинга в сторону редких (e < 1) или частых (e > 1) терминов. Формула: B = P(x|q) / P(x)^e.
• Методы анализа: Используется Collaborative filtering для анализа совместной встречаемости запросов.

Выводы

1. Персонализация на основе немедленного контекста: Google Autocomplete активно использует предыдущий запрос пользователя (Reference Query) для адаптации подсказок в реальном времени. Контекст сессии является сильным сигналом интента.
2. Коллаборативная фильтрация как основа связей: Связи между запросами определяются через Collaborative Filtering. Если множество пользователей переходят от запроса А к запросу Б в рамках одной сессии, Google учится, что эти запросы связаны общей задачей. Это поведенческая связь, а не только семантическая.
3. Статистическая значимость (Lift): Ключевым является не просто совместная встречаемость, а ее статистическая значимость. Формула B = P(x|q) / P(x) (Lift) показывает, насколько сильнее связь между запросами в контексте сессии по сравнению с их глобальной популярностью.
4. Возможность вставки новых подсказок: Система может не только переранжировать существующие подсказки, но и вставлять новые (Likely Queries), если они сильно коррелируют с предыдущим запросом, даже если они менее популярны глобально (Claim 6).
5. Важность User Journey для SEO: Патент подчеркивает необходимость для SEO-специалистов понимать полный путь пользователя и то, как запросы кластеризуются в сессиях. Анализ ключевых слов должен включать понимание того, что пользователи ищут до и после целевого запроса.

Практика

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

• Анализ и моделирование User Journeys: Необходимо выходить за рамки отдельных ключевых слов и анализировать последовательности запросов. Понимайте, какие запросы предшествуют вашим целевым запросам и какие следуют за ними. Это поможет понять контекст, в котором пользователи ищут ваш контент.
• Создание контента, поддерживающего сессию (Session-Supporting Content): Разрабатывайте контентные хабы, которые отвечают на несколько связанных интентов в рамках одной темы. Если пользователь ищет «лучшие кроссовки для бега» (Reference Query), ваш контент должен также покрывать смежные темы, такие как «как выбрать размер кроссовок» или «техники бега», чтобы поддерживать его дальнейшее исследование.
• Использование Autocomplete как инструмента исследования поведения (Session Priming): Анализируйте подсказки Autocomplete, эмулируя различные поисковые сессии. Введите запрос А (прайминг сессии), затем начните вводить запрос Б и посмотрите, как меняются подсказки. Это даст представление о том, какие связи Google видит на основе поведения пользователей.
• Оптимизация под связанные задачи: Убедитесь, что ваша стратегия покрывает запросы, которые имеют высокий Boost Value (B) по отношению к основным запросам в вашей нише. Это увеличит видимость вашего бренда или ключевых слов в персонализированных подсказках.

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

• Изолированный анализ ключевых слов: Рассмотрение каждого ключевого слова в вакууме, основываясь только на его частотности, без учета его места в общей поисковой сессии пользователя.
• Игнорирование контекста сессии при создании контента: Создание страниц, оптимизированных только под один узкий запрос, без предоставления пользователю путей для дальнейшего исследования темы (ответов на Likely Queries).
• Манипуляции с Autocomplete: Попытки искусственно манипулировать подсказками могут быть неэффективными, так как система основана на статистически значимых корреляциях из огромного массива данных и имеет механизмы защиты от выбросов (обработка редких данных).

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

Патент подтверждает, что Google активно использует данные о поведении пользователей (User Activity Sessions) для понимания связей между запросами и интентами. Это механизм, который позволяет Google строить «граф сессий» (Session Graph), основанный на реальных путях пользователей. Стратегически это означает, что SEO должно фокусироваться на решении задач пользователя целиком (Task Completion), а не только на ранжировании по отдельным запросам. Понимание коллаборативной фильтрации помогает строить контент-стратегии, ориентированные на реальные сценарии использования поиска.

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

Сценарий: Оптимизация для eCommerce (Магазин электроники)

1. Анализ User Journey: SEO-специалист определяет, что пользователи часто начинают с обзоров, а затем переходят к сравнению моделей и поиску аксессуаров.
2. Эмуляция сессии:
   • Пользователь вводит Query 1 (Reference Query): «Обзор Samsung Galaxy S25».
   • Затем пользователь начинает вводить Query 2 (Prefix): «Че».
3. Стандартные подсказки (без контекста): «Челябинск», «Чемпионат мира», «Чебурашка».
4. Персонализированные подсказки (с контекстом): Система анализирует данные сессий и видит, что после обзора телефона пользователи часто ищут аксессуары (высокий Boost Value).
   • «Чехол для Samsung Galaxy S25» (Повышено)
   • «Черный Samsung Galaxy S25 цена» (Повышено)
5. Действия SEO: Убедиться, что магазин имеет сильное присутствие по этим связанным запросам (аксессуары, цвета, цены) и что контент на сайте поддерживает этот сценарий (например, блок «Аксессуары» на странице обзора), укрепляя поведенческие сигналы и соответствие пути пользователя.

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