Как Google ускоряет понимание запросов, кэшируя переписанные версии частых запросов и их компонентов

Описание

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

Патент решает проблему производительности и задержек (latency) в системах расширения и переписывания запросов (Query Expansion Systems). Традиционные системы часто требуют двух последовательных обращений к бэкенду (Backend Data System): первое — для анализа результатов по исходному запросу и генерации улучшенной версии, второе — для поиска по новой версии. Это удваивает нагрузку на инфраструктуру и увеличивает время ответа пользователю.

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

Запатентована система для повышения эффективности переписывания запросов за счет офлайн-обработки и кэширования. Система заранее (офлайн) идентифицирует часто встречающиеся запросы (frequently-seen search queries) и их компоненты, генерирует для них улучшенные переписанные версии и сохраняет это соответствие в кэш-памяти (cache memory). Это позволяет избежать ресурсоемкого процесса переписывания в реальном времени.

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

Система работает в двух режимах:

• Офлайн-обработка: Анализируются логи запросов для выявления частых запросов. Для них генерируются переписанные версии, которые валидируются (например, через A/B тесты на основе поведения пользователей). Эти соответствия (оригинал -> переписанная версия) сохраняются в кэше (look-up tables).
• Онлайн-обработка: При поступлении нового запроса система мгновенно проверяет кэш. Поиск осуществляется как по точному совпадению, так и по компонентам (fragments) запроса. Если найдено совпадение, система извлекает переписанную версию из кэша и выполняет только одно обращение к Backend Data System.

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

Высокая (с точки зрения инфраструктуры). Эффективность и скорость работы поиска критически важны для Google. Хотя конкретные методы переписывания запросов значительно эволюционировали с момента подачи оригинальной заявки (приоритет от 2004 года) в сторону сложных NLP и ML моделей, фундаментальная идея кэширования результатов сложных вычислений для популярных запросов остается актуальной. Присутствие Amit Singhal среди изобретателей подчеркивает важность этого механизма для ядра поиска.

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

Патент имеет среднее значение для SEO (6/10). Он носит преимущественно инфраструктурный характер, описывая оптимизацию производительности, а не факторы ранжирования. Однако он дает важное понимание процессов Query Understanding. Патент подтверждает, что Google активно переписывает запросы, использует поведенческие данные для валидации этих изменений (Claim 9) и может модифицировать отдельные части сложных запросов (fragments), что важно учитывать при разработке семантической стратегии.

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

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

Backend Data System (Бэкенд-система данных)

Основная поисковая инфраструктура, включающая индексные серверы (Index Server) и серверы документов (Document Server), которая выполняет поиск по запросу.

Cache Memory System (Система кэш-памяти)

Онлайн-сервер, хранящий заранее рассчитанные соответствия между исходными и переписанными запросами для быстрого доступа.

Frequently-seen search queries (Часто встречающиеся поисковые запросы)

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

Look-up tables (Таблицы поиска)

Структуры данных в кэше, позволяющие быстро найти переписанную версию для данного исходного запроса или его компонента.

Offline / Online (Офлайн / Онлайн)

Офлайн — процессы, выполняемые заранее (анализ логов, генерация кэша). Онлайн — процессы, выполняемые в реальном времени при обработке запроса пользователя.

Phrase Augmentation (Аугментация фразы)

Метод переписывания, при котором к запросу добавляются связанные термины или синонимы для расширения семантического охвата (Claim 4).

Phrase Substitution (Замена фразы)

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

Query Components / Fragments / Substring (Компоненты / Фрагменты / Подстрока запроса)

Части поискового запроса. Система может кэшировать переписанные версии для этих компонентов и использовать их для модификации более длинных запросов (Claim 1, 10, 11).

Rewritten Query (Переписанный запрос)

Модифицированная версия исходного запроса, которая считается более эффективной для поиска.

User Interactions (Взаимодействия пользователей)

Данные о поведении пользователей (например, клики по результатам), используемые для валидации качества переписанных запросов в A/B тестах (Claim 9).

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

Claim 1 (Независимый пункт): Описывает основной метод эффективного переписывания запросов с использованием кэширования.

1. Система получает доступ к записям прошлых запросов (логам) за определенный период.
2. Определяется частота (frequencies) этих запросов.
3. На основе частоты выбирается первый запрос (идентификация частого запроса).
4. Для него генерируется первая переписанная версия (first rewritten query).
5. Переписанная версия кэшируется путем создания соответствия (mapping) в кэше поисковой системы.
6. Поисковая система получает второй (новый) запрос.
7. Определяется, соответствует ли второй запрос или его подстрока (substring) какому-либо кэшированному запросу.
8. Если обнаружено соответствие с первым запросом в кэше, система получает результаты поиска, используя переписанную версию вместо исходного запроса.
9. Эти результаты предоставляются в ответ на второй запрос.

Claim 3 и 4 (Зависимые): Уточняют типы генерации переписанных запросов.

• Claim 3: Включает замену исходных терминов на другие, более популярные (Phrase Substitution).
• Claim 4: Включает дополнение запроса связанными терминами (Phrase Augmentation).

Claim 9 (Зависимый от 8): Описывает метод валидации переписанных запросов перед кэшированием с помощью A/B тестирования. Это критически важный аспект.

1. Система проводит эксперимент. Первой группе пользователей возвращаются результаты по исходному (непереписанному) запросу. Второй группе — по переписанному запросу.
2. Система отслеживает и сравнивает взаимодействия пользователей (user interactions) в обеих группах.
3. Решение о кэшировании принимается на основе этого сравнения (т.е. если переписанная версия показала лучшие результаты).

Claim 10 и 11 (Зависимые): Детализируют механизм частичного совпадения (по фрагментам).

• Claim 10: Если точное совпадение для нового запроса не найдено в кэше, система проверяет наличие совпадений для «все более мелких фрагментов» (increasingly smaller fragments) запроса.
• Claim 11: Для каждого найденного фрагмента система модифицирует его в соответствии с кэшированной переписанной версией этого фрагмента.

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

Изобретение является частью этапа QUNDERSTANDING – Понимание Запросов и представляет собой инфраструктурное решение для его оптимизации.

QUNDERSTANDING (Офлайн-процессы)

• Сбор данных и Анализ: Анализ логов запросов (records of queries) для определения частоты.
• Генерация и Валидация: Генерация кандидатов на переписывание. Использование A/B тестирования и мониторинга User Interactions для валидации качества переписанных версий.
• Кэширование: Генерация и обновление look-up tables в Cache Memory System.

QUNDERSTANDING (Онлайн-процессы)

• Перехват и Проверка: При получении запроса система мгновенно проверяет look-up tables на наличие точного совпадения или совпадения по компонентам (fragments).
• Модификация запроса: Если совпадение найдено, исходный запрос модифицируется с использованием кэшированных данных.

RANKING – Ранжирование

• Этот этап получает на вход уже модифицированный запрос. Система выполняет только один поиск по этому запросу в Backend Data System.

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

• Офлайн: Логи прошлых запросов, данные о поведении пользователей (для A/B тестов).
• Онлайн: Новый запрос пользователя.

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

• Офлайн: Обновленные look-up tables в кэше.
• Онлайн: Переписанный запрос, готовый к отправке на этап RANKING.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на популярные запросы (Head и Torso), так как именно они кэшируются. Также влияет на длинные или редкие запросы (Long-tail), если они содержат популярные компоненты (фрагменты), для которых существуют кэшированные переписанные версии (благодаря механизму фрагментного совпадения).
• Типы контента / Ниши: Механизм универсален и не зависит от тематики.

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

• Триггеры активации (Офлайн): Когда частота запроса или его компонента превышает определенный порог (threshold frequency) (Claim 2).
• Условия применения (Офлайн): Кэширование применяется, только если переписанная версия признана лучшей, чем исходная. Это валидируется через A/B тестирование (Claim 9). Также в патенте упоминается, что если переписанная версия дает идентичные результаты, она может не кэшироваться.
• Триггеры активации (Онлайн): Когда новый входящий запрос точно или частично (по фрагментам) совпадает с записью в Cache Memory System.

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

Процесс А: Офлайн-генерация и обновление кэша (Периодический процесс)

1. Идентификация частых запросов: Анализ логов запросов. Выбор запросов и/или компонентов, частота которых превышает порог.
2. Генерация переписанных версий: Применение методов модификации (Phrase Substitution, Phrase Augmentation, семантическое расширение на основе анализа документов) к выбранным запросам.
3. Валидация кандидатов: Определение предпочтительности переписанной версии.
   • A/B тестирование: Сравнение User Interactions с результатами по исходному и переписанному запросу.
4. Обновление кэша: Сохранение валидированных пар (оригинал -> переписанная версия) и генерация look-up tables для онлайн-доступа.

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

1. Получение запроса: Система получает новый поисковый запрос.
2. Поиск в кэше (Точное совпадение): Проверка look-up tables на точное совпадение.
   • Если ДА: Извлечь кэшированную версию. Перейти к шагу 5.
   • Если НЕТ: Перейти к шагу 3.
3. Поиск в кэше (Совпадение по фрагментам): Поиск совпадений для компонентов запроса, переходя от более крупных к более мелким (increasingly smaller fragments).
4. Резолюция и модификация:
   • Если найдены фрагменты: Модифицировать соответствующие части запроса. Если найдено несколько фрагментов, выполнить резолюцию (объединение) переписанных данных для всех фрагментов.
   • Если фрагменты не найдены: Использовать исходный запрос (или выполнить стандартное переписывание онлайн).
5. Выполнение поиска: Отправить итоговый запрос в Backend Data System.

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

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

• Временные факторы: Частота запросов за определенный период времени используется для выбора кандидатов на кэширование.
• Поведенческие факторы: Критически важны. Журналы запросов (record of queries) используются для анализа популярности. User Interactions с результатами поиска (например, клики) используются в процессе A/B тестирования для валидации качества переписанных запросов (Claim 9).
• Контентные факторы (Косвенно): В описании упоминается, что при генерации переписанных версий система может анализировать частоту и контекст появления терминов в наборе результирующих документов для определения терминов расширения.

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

• Частота запроса (Frequency): Метрика популярности запроса. Сравнивается с порогом (Threshold Frequency) для выбора кандидатов.
• Предпочтение пользователя (Preference): Метрика, вычисляемая на основе сравнения User Interactions в ходе A/B тестирования. Используется для валидации качества переписанных версий.
• Вес термина (Weight): В описании упоминается метрика, указывающая степень перепредставленности (over-represented) термина в наборе документов. Основана на частоте и контексте появления термина. Используется для семантического расширения запроса.

Выводы

1. Эффективность и скорость как приоритет: Патент фокусируется на инфраструктурной оптимизации. Google стремится избежать ресурсоемких процессов генерации переписанных запросов в реальном времени, выполняя эту работу офлайн для популярных запросов.
2. Активное и многовариантное переписывание: Патент подтверждает, что Query Understanding — это активный процесс. Google использует разнообразные методы, включая замену фраз, добавление синонимов и семантическое расширение.
3. Валидация на основе поведения пользователей: Критически важный вывод (Claim 9) — качество переписанных запросов проверяется с помощью A/B тестирования и анализа User Interactions. Переписанные версии используются, только если они улучшают пользовательский опыт.
4. Переписывание на уровне компонентов (Fragments): Ключевой механизм — способность системы распознавать и переписывать отдельные фрагменты внутри более длинного запроса (Claim 10, 11). Это позволяет применять оптимизации к гораздо большему числу запросов, включая длинный хвост.

Практика

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

• Оптимизация под интент и семантику, а не ключевые слова: Поскольку Google активно переписывает запросы, добавляя синонимы и связанные концепции (Phrase Augmentation), необходимо фокусироваться на широком семантическом охвате темы. Контент должен быть релевантен всему кластеру интента, а не только исходной формулировке.
• Использование канонических и популярных формулировок: Система использует Phrase Substitution для замены формулировок на более распространенные. Следует отдавать предпочтение общепринятой терминологии и каноническим названиям сущностей в контенте.
• Фокус на поведенческих факторах (P-Factors): Патент явно указывает, что качество интерпретации запросов валидируется через User Interactions (Claim 9). Это подтверждает важность работы над CTR сниппетов и удовлетворенностью пользователя на странице, так как эти данные используются Google для оценки качества поиска.
• Структурирование контента для сложных запросов: Учитывая механизм переписывания фрагментов, важно создавать контент, который четко отвечает на отдельные компоненты сложных запросов. Система может переписать каждый компонент независимо.

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

• Фокус на точном вхождении ключевых слов (Keyword Stuffing): Это неэффективно, так как популярный запрос, вероятно, будет расширен или изменен перед ранжированием. Релевантность переписанному запросу важнее точного соответствия исходному.
• Оптимизация под неестественные или редкие формулировки: Если вы пытаетесь ранжироваться по устаревшим, ошибочным или непопулярным фразам, система, скорее всего, заменит их на канонические варианты (Phrase Substitution) перед поиском.
• Игнорирование синонимов и связанных концепций (LSI): Создание контента, оптимизированного только под одну узкую формулировку без учета семантического контекста, приведет к потере релевантности по переписанным версиям запросов.

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

Патент подчеркивает фундаментальный принцип современного SEO: мы не контролируем финальную формулировку запроса, который поступает в систему ранжирования. Стратегия должна строиться вокруг тем, сущностей и удовлетворения интента в динамически изменяющемся семантическом пространстве. Также патент демонстрирует, насколько глубоко поведенческие факторы интегрированы в работу поиска — они используются не только для ранжирования, но и для валидации качества интерпретации запросов на этапе Query Understanding.

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

Сценарий: Частичное переписывание (Partial Matching / Fragments)

На основе примера из патента.

1. Офлайн-анализ: Google проанализировал логи и закэшировал переписывание для популярных компонентов:
   • «football coach» -> «football (coach OR coaches)»
   • «coach training» -> «(coach OR coaching) (training OR trained)»

   Эти правила были валидированы через A/B тесты как предпочтительные.

2. Онлайн-обработка: Пользователь вводит запрос: «football coach training».
3. Применение: Система ищет точное совпадение (может не найти), но находит совпадения для фрагментов.
4. Резолюция (Объединение): Система объединяет модификации из найденных фрагментов. Итоговый запрос к бэкенду может быть: «football (coach OR coaches OR coaching) (training OR trained)».
5. Результат для SEO: Страницы, содержащие термины «coaches», «coaching» или «trained» (а не только базовые формы), теперь также считаются релевантными этому запросу. Контент должен учитывать эти расширения для полного семантического охвата.

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