Как Google реализует SafeSearch и верификацию возраста путем фильтрации чувствительных запросов и результатов

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

Approved Query Context (Одобренный контекст запроса)

Контекст, в котором использование Filtering Term считается безопасным и не требует активации фильтрации (White-Listed).

Device Session (Сессия устройства)

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

Filtered Content Items (FCI) (Отфильтрованные элементы контента)

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

Filtering Terms (FT) (Фильтрующие термины)

Термины (например, из «черного списка»), связанные с чувствительной тематикой (контент для взрослых, ненормативная лексика и т.д.), которые запускают процесс фильтрации (Black-Listed).

Keyword Hash Map (Хеш-карта ключевых слов)

Структура данных для эффективной проверки компонентов запроса на соответствие «белым» (WL) и «черным» (BL) спискам терминов с учетом их последовательности (уровня) и контекста.

Search Access Engine (Механизм доступа к поиску)

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

Search Instance (Поисковый экземпляр)

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

Unfiltered Content Items (UCI) (Нефильтрованные элементы контента)

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

Verification Service (Служба верификации)

Система (например, проверка возраста), которая подтверждает право пользователя на просмотр нефильтрованного контента и возвращает Access Approval (AA) или Access Denial (AD).

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

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

1. Система получает запрос.
2. Система определяет, что запрос включает Filtering Term.
3. В ответ на это: Идентифицируются FCI и UCI; Пользователю предоставляются FCI и доступ к Verification Service.
4. Если получено Access Approval, предоставляются UCI. Если отказ — доступ к UCI блокируется.

Критически важная часть Claim 1 детализирует механизм определения наличия фильтрующего термина с помощью Keyword Hash Map. Запрос сегментируется на компоненты. Компоненты сравниваются с хеш-картой, где каждый элемент имеет уровень (позицию в запросе) и статус (отфильтрованный/нефильтрованный). Запрос считается содержащим фильтрующий термин, если его компоненты соответствуют карте и последний компонент слова в запросе имеет статус «отфильтрованный».

Эта структура позволяет обрабатывать контекст. Например, если "Слово А" (BL), но "Слово А + Слово Б" (WL), то запрос "Слово А + Слово Б" не будет отфильтрован, так как статус последнего компонента будет WL.

Claim 8 (Зависимый от 1): Описывает метод генерации FCI путем пост-фильтрации. Система получает UCI по исходному запросу, затем исключает из них элементы, связанные с фильтрующим термином. Оставшиеся элементы становятся FCI.

Claim 9 (Зависимый от 1): Описывает метод генерации FCI путем пре-фильтрации (изменения запроса). Система генерирует revised query (например, удаляя термин или используя отрицательные булевы операторы — Claims 10, 11), выполняет поиск по нему и идентифицирует результаты как FCI.

Claim 13 (Зависимый от 12): Подчеркивает важность контекста. Запрос считается содержащим фильтрующий термин, только если его контекст не является одобренным (approved query context).

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

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

QUNDERSTANDING – Понимание Запросов
Search Access Engine анализирует запрос сразу после его получения. Используется Keyword Hash Map для проверки наличия Filtering Terms с учетом контекста. На этом этапе может происходить переписывание запроса (Query Revision), если выбран метод пре-фильтрации (Claim 9).

RANKING – Ранжирование
Система выполняет поиск. В зависимости от реализации, она либо запускает ранжирование по исходному запросу (чтобы получить UCI для пост-фильтрации), либо по измененному запросу (чтобы получить FCI).

RERANKING / METASEARCH – Переранжирование и Смешивание (Фильтрация)
Основное место применения логики патента. Если используется метод пост-фильтрации (Claim 8), то на этом этапе из UCI удаляются чувствительные элементы. Здесь принимается решение о том, какой набор результатов показать (FCI или UCI), и управляется интеграция доступа к Verification Service (например, показ предупреждения и ссылки).

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

• Поисковый запрос пользователя.
• База данных Filtering Terms (включая Keyword Hash Map и Approved Query Contexts).
• (Потенциально) Набор UCI, полученный от поисковой системы.
• Данные пользователя для верификации и данные сессии (Device Session).

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

• Набор FCI ИЛИ набор UCI.
• Инструкции для доступа к Verification Service (ссылка, форма).

На что влияет

• Конкретные ниши или тематики: Наибольшее влияние оказывается на ниши, связанные с контентом для взрослых, насилием, разжиганием ненависти (hate speech), а также на регулируемые отрасли, где требуется верификация возраста.
• Специфические запросы: Влияет на запросы, содержащие эксплицитные термины или двусмысленные термины, которые часто приводят к выдаче чувствительного контента.
• Типы контента: Применяется ко всем типам контента в Information Corpora, включая веб-страницы, изображения, видео и т.д.

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

Алгоритм применяется при выполнении одного из условий (в зависимости от реализации):

• Триггер 1 (На основе запроса): Когда сам запрос содержит Filtering Term, который не находится в одобренном (white-listed) контексте. Определение происходит с помощью Keyword Hash Map.
• Триггер 2 (На основе результатов): Когда результаты (Unfiltered Content Items), идентифицированные для запроса, включают или ассоциированы с Filtering Term (например, помечены как контент для взрослых).
• Исключения: Фильтрация не активируется, если контекст одобрен. Патент приводит пример: термин "nude" может быть фильтруемым, но фраза "nude expression" может быть разрешена.

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

Процесс объединяет различные варианты реализации (FIG 6, 7, 8).

1. Получение запроса: Search Access Engine получает запрос от пользовательского устройства.
2. Идентификация поискового экземпляра (Search Instance): Система определяет область анализа (запрос или результаты).
3. Проверка на фильтрующие термины: Search Instance анализируется. При анализе запроса используется Keyword Hash Map для проверки статуса (BL/WL) и контекста.
4. Принятие решения о фильтрации: Содержит ли Search Instance фильтрующий термин в неодобренном контексте?
   • Если НЕТ: Перейти к шагу 9.
   • Если ДА: Перейти к шагу 5.
5. Генерация отфильтрованного контента (FCI):
   • Метод А (Пре-фильтрация): Запрос изменяется (например, удаляется термин, добавляется отрицательный булев оператор) и выполняется поиск по новому запросу (Claim 9).
   • Метод Б (Пост-фильтрация): Из набора Unfiltered Content Items удаляются чувствительные результаты (Claim 8).
6. Предоставление отфильтрованных результатов и доступа к верификации: Пользователю отправляются FCI вместе с инструкциями или ссылкой на Verification Service.
7. Проверка верификации: Система ожидает действия пользователя. Получено ли Access Approval (AA) от Verification Service?
8. Принятие решения о доступе:
   • Если НЕТ/ОТКАЗ (AD): Поддерживать отфильтрованный вид (блокировать UCI).
   • Если ДА (AA): Перейти к шагу 9.
9. Предоставление нефильтрованного контента (UCI): Полный набор результатов отправляется пользователю.
10. (Опционально) Управление сессией: Создается или обновляется Device Session на основе результата верификации для упрощения будущих поисков.

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

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

• Пользовательские факторы:
  • Идентификационные данные пользователя (имя, номер, email, пароль) используются Verification Service для подтверждения личности или возраста.
  • Device Sessions (cookies, данные входа в аккаунт) используются для поддержания статуса верификации.
• Контентные факторы (Косвенно): Если используется пост-фильтрация, контент результатов (UCI) анализируется (или используются их предварительные классификации), чтобы определить, соответствует ли он Filtering Terms.

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

• Анализ Keyword Hash Map: Основной метод вычисления для фильтрации на уровне запроса. Это метод сопоставления шаблонов компонентов запроса со списками фильтруемых/нефильтруемых терминов. Учитывается последовательность (уровни) и статус (Black-List/White-List).
• Контекстуальный анализ (Approved Query Context): Определение того, используется ли фильтрующий термин в одобренном (white-listed) контексте.
• Булева логика: Упоминается как способ изменения запросов путем генерации отрицательных булевых терминов (negative Boolean term).
• Статус Верификации: Бинарный результат (AA/AD), получаемый от Verification Service.

1. Приоритет пользовательского опыта над полной блокировкой: Google предпочитает показать пользователю безопасную часть выдачи (FCI), а не блокировать поиск полностью при обнаружении чувствительных терминов. Это позволяет пользователям получать доступ к информации, даже если их запрос затрагивает фильтруемые темы.
2. Гибкость механизмов фильтрации (Пре- и Пост-фильтрация): Патент описывает два основных подхода: пре-фильтрация (изменение запроса до поиска) и пост-фильтрация (фильтрация результатов после поиска). Это дает системе гибкость в реализации SafeSearch.
3. Контекст имеет значение (Whitelisting и Approved Context): Система не просто реагирует на отдельные слова. Использование Keyword Hash Map и проверка Approved Query Context явно указывают на то, что контекст фразы определяет, будет ли активирована фильтрация. Фраза может содержать фильтруемое слово, но быть разрешенной в целом.
4. Два триггера фильтрации: Фильтрация может быть инициирована как анализом самого текста запроса, так и характером результатов, которые этот запрос возвращает (Search Instance).
5. Верификация как шлюз: Чувствительный контент не удаляется из индекса, а помещается за шлюз верификации (например, подтверждение возраста). Доступ к нему возможен, но требует дополнительных действий и подтверждения прав доступа.

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

• Понимание классификации контента (SafeSearch): Для сайтов, чей контент может граничить с чувствительными темами (медицина, искусство, социальные исследования), критически важно понимать, как Google классифицирует их контент. Используйте четкие сигналы, чтобы помочь Google правильно интерпретировать контекст.
• Обеспечение контекстуальной ясности: При обсуждении чувствительных тем в безопасном контексте убедитесь, что контекст однозначен. Это поможет попасть в Approved Query Context и избежать попадания под фильтры, даже если используются потенциальные Filtering Terms.
• Четкая сегментация контента (SFW/NSFW): Если сайт содержит как общедоступный (SFW), так и чувствительный (NSFW) контент, они должны быть строго разделены. Это снижает риск того, что фильтрация чувствительного контента повлияет на видимость безопасных разделов сайта.

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

• Смешивание типов контента: Размещение контента для взрослых или другого чувствительного материала вперемешку с общим контентом создает высокий риск того, что весь сайт будет отфильтрован для пользователей с включенным SafeSearch или неверифицированных пользователей.
• Использование двусмысленного языка и кликбейта: Неоправданное использование терминов, которые могут быть классифицированы как Filtering Terms, для привлечения внимания увеличивает вероятность фильтрации контента, даже если он по сути безопасен.

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

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

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

Сценарий: Академический ресурс, обсуждающий чувствительную тему.

Задача: Опубликовать статью "Социальное влияние контента для взрослых" так, чтобы она была доступна максимально широкой аудитории, включая пользователей с включенным SafeSearch.

1. Анализ запросов: Пользователи могут искать информацию, используя термины, которые входят в Filtering Terms (например, "влияние порнографии").
2. Риск: Если Google посчитает контекст недостаточно академическим, статья может быть классифицирована как UCI (нефильтрованный контент) и скрыта от пользователей с SafeSearch.
3. Действия SEO-специалиста:
   • Обеспечить явный академический контекст: использовать формальный язык, ссылки на исследования, указать авторство экспертов.
   • Избегать использования сенсационных или двусмысленных заголовков.
   • Убедиться, что на сайте нет рекламы или ссылок на ресурсы для взрослых.
4. Ожидаемый результат: Система Google распознает контекст как Approved Query Context. Статья классифицируется как безопасная и включается в FCI (отфильтрованный контент), оставаясь видимой для всех пользователей.