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

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

Appropriate sensitive/offensive content (Приемлемый чувствительный/оскорбительный контент)

Контент, который может быть чувствительным или оскорбительным, но является допустимым в определенном контексте (например, новости о трагедии, медицинский контент). Система должна отличать его от Inappropriate.

Candidate Query (Запрос-кандидат)

Совместно встречающийся запрос, чье Co-occurrence Value превысило установленный порог и который подлежит дальнейшей проверке.

Classifier (Классификатор)

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

Co-occurring Query (Совместно встречающийся запрос)

Запрос, введенный пользователем в течение определенного периода времени (например, от 2 минут до 1 часа) до или после ввода Reference Query в рамках одной сессии.

Co-occurrence Value (Значение совместной встречаемости)

Метрика, указывающая на силу связи между запросом и неприемлемым контентом. Рассчитывается на основе (i) общего числа появлений запроса и (ii) числа его совместных появлений с любым из Reference Queries. Часто представляет собой соотношение (ii) к (i).

Inappropriate sensitive or offensive content (Неприемлемый чувствительный или оскорбительный контент)

Целевой контент, который система должна идентифицировать и фильтровать. Примеры: CSAM (детская порнография), сцены насилия (gore), вербовка террористов.

Reference Query (Референсный запрос)

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

Seed Terms (Начальные термины)

Базовые слова, используемые для автоматической генерации Reference Queries. Делятся на два набора (например, Набор 1: общий тип контента, Набор 2: неприемлемый аспект/подмножество).

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

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

1. Система получает набор Reference Queries (известные "плохие" запросы).
2. Идентифицируется набор Co-occurring Queries, которые встречаются рядом с референсными запросами в логах поиска.
3. Каждый совместный запрос классифицируется как Candidate Query или нет.
4. Определяется, какие из Кандидатов вероятно связаны с неприемлемым контентом.
5. Эти запросы предоставляются как обучающие данные (training data) для классификатора.

Claim 8 (Независимый пункт): Детализирует полный цикл, включая генерацию референсных запросов и расчет метрик.

1. Получение первого и второго наборов Seed Terms.
2. Идентификация запросов, комбинирующих термины из обоих наборов, и классификация их как Reference Queries.
3. Идентификация Co-occurring Queries.
4. Расчет метрик: (i) общее число вхождений, (ii) число совместных вхождений.
5. Расчет Co-occurrence Value на основе этих метрик.
6. Классификация в Candidate Query (на основе Co-occurrence Value).
7. Применение одного или нескольких критериев к Кандидатам для финальной классификации как "вероятно связанного" или "маловероятно связанного" с неприемлемым контентом.
8. Предоставление "вероятно связанных" запросов как обучающих данных.

Claim 5 и Claim 11 (Зависимые): Уточняют механизм классификации в Кандидаты.

Классификация происходит, если Co-occurrence Value удовлетворяет пороговому значению (co-occurrence threshold).

Claim 6 и Claim 12 (Зависимые): Определяют критически важные критерии для финальной валидации Кандидата.

Критерии включают одно или несколько из следующих условий:

• Reference Query был получен от того же пользователя в течение определенного времени до или после Кандидата (подтверждение связи в сессии).
• Кандидат не связан с Appropriate sensitive content (исключение ложных срабатываний на приемлемый контент, например, новости).
• Кандидат был получен от этого пользователя только один раз в течение календарного дня (исключение привычного или повторяющегося поведения).

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

Изобретение связано с этапами Понимания Запросов и Фильтрации (Переранжирования).

QUNDERSTANDING – Понимание Запросов

Основная часть патента описывает офлайн-процесс, который является частью глобального понимания пространства запросов:

1. Сбор данных: Система собирает и анализирует логи поисковых сессий.
2. Обучение классификатора: Генерируются обучающие данные (Training Data) по описанному методу (анализ co-search behavior), и на их основе тренируется Classifier.
3. Применение классификатора: В реальном времени обученный классификатор используется для оценки входящих запросов и определения интента, связанного с поиском неприемлемого контента.

RERANKING – Переранжирование (Фильтрация)

На финальном этапе формирования выдачи система использует результаты работы классификатора для модерации (например, через Twiddlers типа SafeSearch).

1. Если запрос классифицирован как направленный на поиск Inappropriate content.
2. Система может проверить настройки пользователя (User Preference/Behavior).
3. Происходит модификация результатов поиска: удаление неприемлемого контента из выдачи или значительное понижение ранжирования соответствующих ресурсов (Claim 14).

Входные данные (для офлайн-процесса):

• Логи поисковых сессий (Query Logs).
• Наборы начальных терминов (Seed Terms) или существующие Reference Queries.

Выходные данные (офлайн-процесса):

• Расширенный набор обучающих данных (Training Data) для классификатора.

На что влияет

• Специфические запросы и тематики: Влияет исключительно на запросы, связанные с крайне чувствительными, оскорбительными или незаконными темами (насилие, CSAM, терроризм). Не оказывает влияния на стандартные коммерческие (ecommerce) или информационные ниши. Патент направлен на обеспечение безопасности и модерацию контента.

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

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

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

Фаза 1: Генерация Референсных Запросов (Офлайн)

1. Сбор начальных данных: Получение первого набора Seed Terms (например, общая тема) и второго набора Seed Terms (например, неприемлемый аспект).
2. Идентификация комбинаций: Поиск в логах запросов, которые содержат комбинацию терминов из обоих наборов.
3. Фильтрация и Верификация: Отбор запросов по частотности и проверка (автоматическая или ручная) их связи с неприемлемым контентом.
4. Формирование базы: Классификация подтвержденных запросов как Reference Queries.

Фаза 2: Идентификация Кандидатов (Офлайн)

1. Анализ сессий: Анализ логов поиска и идентификация Co-occurring Queries — запросов, введенных тем же пользователем в течение определенного временного окна (например, 2-60 минут) до или после Reference Query.
2. Расчет метрик: Для каждого Co-occurring Query подсчитывается общее количество его появлений и количество его совместных появлений с любым Reference Query.
3. Расчет Co-occurrence Value: Вычисление значения совместной встречаемости.
4. Сравнение с порогом: Сравнение Co-occurrence Value с установленным порогом (Co-occurrence Threshold). Если значение выше порога, запрос классифицируется как Candidate Query.

Фаза 3: Фильтрация и Маркировка (Офлайн)

1. Применение поведенческих критериев: Проверка Candidate Query:
   • Подтверждение, что Reference Query был введен тем же пользователем в рамках временного окна.
   • Проверка, не вводил ли пользователь этот Candidate Query ранее в тот же календарный день (фильтр повторов).
2. Применение контентных критериев: Проверка, не связан ли Candidate Query с Appropriate sensitive content (например, новости, исследования).
3. Маркировка и Подготовка данных: Если все критерии удовлетворены, Candidate Query маркируется как "вероятно связанный с неприемлемым контентом" и добавляется в Training Data. (Опционально: генерация вариантов написания, опечаток для расширения данных - Claim 19).

Фаза 4: Применение Классификатора (Онлайн)

1. Получение и Классификация запроса: Поисковая система получает запрос и оценивает его обученным классификатором.
2. Проверка условий: Если запрос классифицирован как неприемлемый, система определяет предпочтения пользователя (например, включены ли фильтры).
3. Модификация выдачи: Предоставление модифицированных результатов поиска (удаление ссылок или понижение их ранжирования).

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

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

• Поведенческие факторы: Являются основой изобретения. Используются логи поисковых сессий (Query Logs), временные метки запросов, идентификаторы пользователей (для связывания запросов в сессию). Анализируется последовательность и временная близость запросов (co-search behavior), а также частота запросов в течение дня.
• Контентные факторы: Используются начальные термины (Seed Terms) для генерации стартового набора Reference Queries. Также используются данные для классификации контента как Appropriate или Inappropriate.
• Пользовательские факторы: Настройки фильтрации контента пользователя (User Preference/Behavior, например, SafeSearch) используются на этапе применения классификатора для принятия решения о модификации выдачи.

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

• Co-occurrence Value: Ключевая метрика. Рассчитывается для каждого запроса на основе двух показателей: (i) общее количество вхождений запроса в логи; (ii) количество вхождений запроса, когда он соседствует с Reference Query. Метрика обычно нормализована, например, как отношение (ii)/(i). $\text{Co-occurrence Value} \approx \frac{\text{Число совместных вхождений с Reference Queries}}{\text{Общее число вхождений запроса}}$
• Пороги частотности (Particular Threshold): Используются для отсева слишком редких запросов (Claim 9).
• Временные пороги (Determined Time Period): Определяют максимальное время между запросами для того, чтобы они считались совместно встречающимися (окно сессии).
• Co-occurrence Threshold: Пороговое значение для Co-occurrence Value, необходимое для того, чтобы запрос стал Кандидатом.

Патент описывает внутренние процессы Google, направленные на модерацию контента и обеспечение безопасности поиска, без прямых рекомендаций для SEO. Он дает следующее понимание работы системы:

1. Инфраструктура безопасности, а не ранжирования: Это не алгоритм ранжирования общего веб-поиска, а система для обучения классификаторов, используемых в модерации выдачи (например, SafeSearch).
2. Анализ сессий как метод классификации: Ключевым механизмом является использование анализа поисковых сессий (co-search behavior). Система исходит из предположения, что запросы, часто вводимые незадолго до или после известных "плохих" запросов, также, вероятно, являются "плохими".
3. Многоступенчатая фильтрация для точности: Для минимизации ложных срабатываний используется сложная логика: расчет Co-occurrence Value, сравнение с порогами и применение специфических поведенческих критериев (например, фильтр запросов, повторяющихся в течение дня - Claim 6).
4. Различение контекста чувствительного контента: Система явно разделяет Inappropriate (неприемлемый) и Appropriate (приемлемый) чувствительный контент. Это указывает на попытку Google различать контекст, например, между новостями о насилии и поиском инструкций к насилию.
5. Автоматизация и масштабирование: Цель патента — автоматизировать процесс выявления новых способов поиска неприемлемого контента, минимизируя ручной труд.

Патент является инфраструктурным и фокусируется на безопасности контента. Он не дает практических выводов для SEO-продвижения большинства стандартных сайтов.

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

• Четкое позиционирование контента (для специфических ниш): Если сайт работает в нишах, которые могут касаться чувствительных тем (новости, история, психология, медицина), крайне важно убедиться, что контент представлен в образовательном, документальном или новостном контексте. Это поможет системам классифицировать его как Appropriate sensitive content, а не Inappropriate.
• Понимание анализа сессий: SEO-специалисты должны понимать, что Google анализирует поведение пользователей в рамках сессий (co-search behavior) для классификации запросов. Этот общий принцип используется не только для безопасности, но и для лучшего понимания интента в общем поиске, что подтверждает важность оптимизации под задачи пользователя (user journey).

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

• Создание пограничного контента: Создание контента, который граничит с запрещенными или крайне неприемлемыми темами (насилие, CSAM, терроризм, hate speech). Этот патент описывает механизмы, которые Google использует для активного обнаружения запросов, ведущих к такому контенту, и его последующего подавления в выдаче.
• Оптимизация под "Inappropriate" запросы: Попытки ранжироваться по запросам, которые могут быть классифицированы как Inappropriate. Система будет активно модифицировать выдачу (понижать или удалять результаты), даже если пользователь явно ищет такой контент (если это не запрещено законом).

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

Патент подтверждает высокую степень развития технологий Google в анализе поведения пользователей на уровне сессий. Способность использовать контекст соседних запросов (co-search behavior) для классификации текущего запроса является мощным инструментом. Хотя в данном патенте он применяется для обеспечения безопасности, аналогичные механизмы анализа сессий используются и в общем поиске для уточнения намерений пользователя и улучшения релевантности.

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

Практических примеров для применения в SEO нет, так как патент направлен на фильтрацию и подавление контента, а не на его продвижение или оптимизацию.