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

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

Collection of Synonym Rules (Коллекция правил синонимов)

Активный набор правил, который используется системой переписывания запросов (Query Reviser Engine) для генерации альтернативных версий поисковых запросов.

Context (Контекст)

Условия применения правила. Правило может быть общим (General Context), применяемым независимо от других слов, или контекстно-зависимым (Specific Context), применяемым только при наличии определенных слов рядом.

Exception (Исключение)

Условие, при котором общее правило синонима не должно применяться (например, «Y->Z, кроме случая контекста C»).

Historic Usage Data (Исторические данные об использовании)

Накопленные данные из Query Logs, отражающие взаимодействие пользователей с результатами поиска, полученными с использованием конкретного правила синонима. Включают положительный и отрицательный отклик.

Query Logs (Логи запросов)

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

Synonym Model (Модель синонимов)

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

Synonym Rule Historic Quality Evaluation Engine (Система оценки исторического качества правил синонимов)

Ключевой компонент изобретения. Он оценивает правила синонимов, основываясь на Historic Usage Data, и может отменять (override) решения Synonym Model.

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

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

1. Система получает индикацию о том, что правило синонима, ранее включенное в коллекцию (в момент времени T1), теперь определено как не подлежащее включению (в момент времени T2). Уточняется, что критерии для включения в T2 отличаются от критериев в T1 (т.е. Synonym Model обновилась).
2. Система получает Historic Usage Data для этого правила.
3. На основе этих исторических данных система определяет, следует ли добавить правило обратно в коллекцию, несмотря на индикацию о его исключении.
4. Если решение положительное, правило добавляется в коллекцию.

Ядро изобретения — использование исторических данных для отмены решения обновленной модели, если это решение приводит к удалению исторически эффективного правила.

Claim 5 и 6 (Зависимые): Детализируют природу исторических данных.

Historic Usage Data включают данные, отражающие, был ли пользователь удовлетворен результатами поиска, полученными после применения правила синонима. Конкретизируется, что удовлетворенность определяется тем, выбирал ли пользователь (кликал) эти результаты или нет.

Claim 7 (Зависимый): Описывает обработку исключений (Exceptions).

Если система решает добавить правило обратно, она проверяет, были ли у этого правила определены исключения, когда оно ранее находилось в коллекции. Если да, то правило добавляется обратно с теми же самыми исключениями. Это критически важно, так как для контекста исключения исторические данные не накапливаются (правило там не применялось).

Claim 8 и 9 (Зависимые): Описывают обработку контекстов.

Если правило является контекстно-зависимым (Specific Context), система анализирует его исторические данные. При этом учитывается статус соответствующего общего правила (General Context). Если общее правило активно (Claim 8), анализируются данные обоих правил. Если общее правило не активно (Claim 9), анализируются данные только контекстно-зависимого правила.

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

Изобретение относится к этапу QUNDERSTANDING – Понимание Запросов. Оно описывает процесс валидации и поддержания качества набора синонимов, используемых для расширения запросов.

Взаимодействие компонентов:

• Synonym Engine и Synonym Model: Генерируют и оценивают правила. Их обновления запускают описываемый процесс.
• Query Logs: Источник данных (Historic Usage Data) для валидации.
• Synonym Rule Historic Quality Evaluation Engine: Управляющий модуль, который реализует логику патента. Он выступает в роли контролера качества и может переопределять решения Synonym Model.
• Collection of Synonym Rules: Хранилище активных правил, которое обновляется по результатам работы системы.

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

• Индикация об изменении статуса правила синонима (с активного на неактивный) в результате работы обновленной Synonym Model.
• Historic Usage Data для этого правила из Query Logs (положительный и отрицательный отклик).

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

• Команда на добавление (возвращение) правила синонима в Collection of Synonym Rules, возможно с восстановлением ранее существовавших исключений.

На что влияет

Патент не специфицирует ограничения по типам контента, запросов или нишам. Он влияет на все запросы, к которым потенциально могут быть применены правила подстановки синонимов. Система направлена на обеспечение стабильности и качества процесса переписывания запросов в целом.

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

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

• Временные рамки: Процесс запускается после того, как Synonym Model была обновлена и сгенерировала новый набор предлагаемых правил (это офлайн или пакетный процесс, а не real-time).
• Триггер активации: Обнаружение того, что правило синонима, которое присутствовало в коллекции до обновления модели, отсутствует в наборе правил, предложенном после обновления.
• Условие срабатывания: Historic Usage Data для данного правила удовлетворяют определенным критериям качества, установленным в Synonym Rule Historic Quality Evaluation Engine.

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

Процесс оценки и восстановления правил синонимов:

1. Обновление модели синонимов: Synonym Engine обновляет свою Synonym Model, изменяя критерии оценки правил.
2. Генерация нового набора правил: Обновленная модель генерирует новый предлагаемый набор для активной коллекции.
3. Идентификация расхождений: Система идентифицирует правило (например, Y->Z), которое ранее было активно, но теперь отсутствует (отклонено новой моделью).
4. Активация оценки: Индикация об исключении правила Y->Z поступает в Synonym Rule Historic Quality Evaluation Engine.
5. Извлечение исторических данных: Evaluation Engine извлекает Historic Usage Data для правила Y->Z из Query Logs (агрегированный положительный и отрицательный отклик пользователей).
6. Применение критериев качества: Evaluation Engine оценивает полученные данные на основе своих собственных критериев (сфокусированных только на исторической эффективности).
7. Принятие решения об отмене (Override):
   • Если данные удовлетворяют критериям: Evaluation Engine принимает решение отменить исключение правила.
   • Если данные не удовлетворяют критериям: Решение новой модели остается в силе.
8. Восстановление правила и исключений: Если принято решение об отмене, система проверяет, были ли у правила ранее определены исключения (Exceptions). Правило возвращается в Collection of Synonym Rules с восстановлением всех предыдущих исключений.

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

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

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

• Поведенческие факторы: Являются основой изобретения. Используются Historic Usage Data, которые отражают, был ли пользователь удовлетворен результатами поиска, полученными при применении правила синонима. Конкретно упоминаются данные о том, выбирал ли пользователь (кликал) эти результаты или нет.
• Системные данные: Информация о статусе правил (активно/удалено), их типе (общий/специфический контекст) и наличии исключений.

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

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

• Положительный отклик (Positive Feedback): Количественный показатель взаимодействий, указывающих на удовлетворенность пользователя (например, количество кликов на результаты, полученные с помощью синонима).
• Отрицательный отклик (Negative Feedback): Показатель взаимодействий, указывающих на неудовлетворенность (например, отсутствие кликов на такие результаты).
• Критерии оценки: Synonym Rule Historic Quality Evaluation Engine использует критерии, основанные на этих метриках. В примерах патента предполагается, что правило считается эффективным, если количество положительных откликов значительно превышает количество отрицательных. Также может использоваться CTR.

1. Пользовательские данные как истина в последней инстанции: Патент демонстрирует, что для Google исторические данные о реальном поведении пользователей (Historic Usage Data) имеют приоритет над алгоритмическими моделями (Synonym Model) при оценке качества синонимов. Если синоним работает на практике, система стремится его сохранить.
2. Защита от алгоритмических регрессий: Описан конкретный механизм обеспечения стабильности (safeguard). Google использует этот механизм для автоматического исправления ситуаций, когда эффективные правила отключаются из-за обновлений алгоритмов.
3. Гранулярное отслеживание эффективности: Google отслеживает эффективность синонимов на детальном уровне, учитывая конкретные контексты (Specific Context) и исключения (Exceptions).
4. Точность восстановления правил: Система гарантирует, что если правило восстанавливается на основе исторических данных, его исключения также восстанавливаются. Это предотвращает применение правила в тех контекстах, где оно не было проверено на практике (Claim 7).
5. Важность удовлетворения интента: Для SEO это подтверждает, что положительные поведенческие сигналы, возникающие при переходе на сайт, валидируют релевантность страницы запросу (и его синонимичным вариантам) в глазах системы.

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

• Фокус на глубоком удовлетворении интента: Создавайте контент, который максимально полно отвечает на запрос пользователя, включая его возможные синонимичные интерпретации. Если пользователь переходит на вашу страницу по расширенному запросу и демонстрирует удовлетворенность, это генерирует Positive Feedback в Query Logs Google. Эти данные напрямую используются для валидации и сохранения синонимической связи между запросом и вашим контентом.
• Расширение тематического охвата и использование естественного языка: Обеспечьте широкий охват темы, используя разнообразную лексику. Это повышает вероятность того, что ваш контент будет релевантен для синонимов, которые Google тестирует. Чем больше синонимических связей будет подтверждено положительным пользовательским опытом на вашем сайте, тем стабильнее будет трафик.
• Мониторинг вариантов запросов в GSC: Анализируйте, по каким вариантам запросов ранжируется страница. Это помогает понять, как Google интерпретирует интент и какие синонимы он использует для вашей тематики, и адаптировать контент под реальные формулировки пользователей.

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

• Создание контента с низкой удовлетворенностью: Если контент оптимизирован под ключевое слово, но плохо отвечает на интент, пользователи будут демонстрировать Negative Feedback. Если Google тестирует синоним, который ведет на такой контент, накопленные отрицательные данные приведут к тому, что эта синонимическая связь будет отклонена и не будет сохранена описанным механизмом.
• Манипуляции с синонимами (Keyword Stuffing/LSI-копирайтинг): Попытки искусственно насытить текст синонимами неэффективны. Система валидирует правила на основе реального поведения пользователей, а не только на основе анализа контента.

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

Этот патент подтверждает критическую роль данных о поведении пользователей в обучении и валидации систем понимания естественного языка (NLP/NLU) Google. Понимание запроса в значительной степени корректируется наблюдаемой удовлетворенностью пользователей. Стратегически, это подчеркивает переход от чисто текстовой релевантности к измеряемой полезности контента. Долгосрочная SEO-стратегия должна фокусироваться на создании контента, который генерирует сильные положительные поведенческие сигналы.

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

Сценарий: Сохранение синонима благодаря положительному пользовательскому опыту

1. Ситуация: Сайт имеет страницу, оптимизированную под запрос «окулист», которая также хорошо отвечает на запросы пользователей, ищущих «офтальмолога».
2. Работа системы (Старая модель): Google установил правило синонима «офтальмолог -> окулист». Пользователи активно переходят на страницу по обоим запросам (высокий CTR). В Query Logs накапливается положительный Historic Usage Data для этого правила.
3. Обновление модели: Google обновляет Synonym Model. Новая модель, возможно, из-за ужесточения лингвистических критериев, решает, что эти термины не всегда являются синонимами, и отключает правило.
4. Активация защитного механизма: Synonym Rule Historic Quality Evaluation Engine обнаруживает отключение. Он проверяет исторические данные и видит значительный положительный отклик.
5. Результат: Evaluation Engine отменяет решение новой модели и принудительно возвращает правило «офтальмолог -> окулист» в активную коллекцию. Сайт продолжает получать трафик по обоим запросам благодаря качественному контенту и положительному пользовательскому опыту.