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

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

Description Score (Оценка описания)

Метрика качества описания трансляции. Рассчитывается на основе длины (количества слов), уникальности слов и исключения стоп-слов. Слишком короткие или слишком длинные описания могут получать низкую оценку.

Entity (Сущность)

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

Entity Annotator (Аннотатор сущностей)

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

Entity Score (Оценка сущности)

Метрика, отражающая степень популярности (degree of popularity) сущности. Может основываться на объеме связанных с ней запросов или частоте упоминаний в социальных сетях.

Fact Summary (Сводка фактов)

Блок с фактической информацией о сущности (на практике – Панель Знаний/Knowledge Panel). Отображение этого блока может являться дополнительным условием (триггером) для показа блока Live Events.

Live Event (Прямая трансляция)

Контент (аудио/видео), который транслируется в прямом эфире (streamed live) и доступен через один или несколько ресурсов в указанное время.

Organizer Score (Оценка организатора)

Метрика репутации организатора трансляции. Рассчитывается на основе количества ранее проведенных качественных трансляций и/или количества подписчиков (followers) организатора.

Quality Score (Оценка качества трансляции)

Агрегированная метрика качества трансляции. Рассчитывается офлайн как взвешенное среднее из Organizer Score, Entity Score и Description Score. Используется для фильтрации событий.

Query Intent (Интент запроса)

Намерение пользователя. Патент выделяет общий интент (General Intent – поиск информации) и специфический интент (Specific Intent – целенаправленный поиск прямой трансляции).

Query Patterns (Шаблоны запросов)

Предопределенные шаблоны (например, [смотреть * онлайн]), используемые для определения Specific Intent.

Time Difference Threshold (Порог временной разницы)

Максимально допустимое время между получением запроса и началом трансляции. Этот порог динамический и зависит от Query Intent.

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

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

1. Система получает запрос и извлекает из него набор сущностей (set of entities).
2. Определяется интент запроса (intent for the query) – ищет ли пользователь контент прямых трансляций (live streamed content). Это определение происходит путем сравнения запроса с шаблонами (Query Patterns).
3. Ветвь А (Если интент – поиск трансляции):
   1. Получаются общие результаты поиска.
   2. Идентифицируется релевантная прямая трансляция путем сравнения сущностей запроса и трансляций.
   3. Проверяется, что событие является стримом и произойдет в пределах порогового периода времени (threshold period of time).
   4. При выполнении условий система предоставляет результат трансляции (event search result) И общие результаты поиска.
4. Ветвь Б (Если интент – НЕ поиск трансляции):
   1. Получаются общие результаты поиска.
   2. Система предоставляет ТОЛЬКО общие результаты поиска.

Примечание: Claim 1 представляет упрощенную логику. Описание патента и другие пункты (например, Claim 5) уточняют, что даже при общем интенте (Ветвь Б) трансляции могут быть показаны, но с более строгими условиями.

Claim 5 (Зависимый от 4, который зависит от 1): Детализирует механизм динамического временного порога.

Временной порог определяется на основе интента. Если интент указывает на поиск трансляции (Specific Intent), порог устанавливается на первое значение (T1). Если интент общий (General Intent), порог устанавливается на второе значение (T2), которое меньше первого (T2 < T1). Это означает, что для общих запросов событие должно начаться раньше, чтобы быть показанным.

Claim 6 (Зависимый от 1): Добавляет дополнительное условие для отображения.

Решение о показе результата трансляции включает определение того, что сводка фактов (Fact Summary), связанная с сущностью, также должна быть отображена. Это привязывает показ блока Live Events к активации Панели Знаний.

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

Изобретение затрагивает несколько этапов поисковой архитектуры, интегрируя офлайн-вычисления и онлайн-процессы.

INDEXING – Индексирование и извлечение признаков
На этом этапе происходят офлайн-процессы (Live Event System):

• Сбор данных о предстоящих Live Events.
• Вычисление Entity Scores (популярности сущностей).
• Вычисление Quality Scores для каждой трансляции (включая Organizer Score и Description Score).
• Фильтрация низкокачественных трансляций и сохранение высококачественных в индексе Live Event Data.

QUNDERSTANDING – Понимание Запросов
В реальном времени:

• Извлечение сущностей (Entities) из запроса.
• Классификация интента (Query Intent) как Specific или General с использованием Query Patterns.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
Основное место применения логики патента:

• Поиск кандидатов: Система ищет в индексе Live Event Data трансляции, чьи сущности пересекаются с сущностями запроса.
• Проверка триггеров: Проверяется, активирован ли Fact Summary для данной сущности.
• Динамическая фильтрация по времени: Устанавливается Time Difference Threshold на основе Query Intent. Кандидаты фильтруются по этому порогу.
• Смешивание (Blending): Если кандидаты найдены, система формирует блок Live Events и интегрирует его в финальную выдачу (SERP).

На что влияет

• Типы контента: Прямые видеотрансляции, стримы, вебинары, аудио-трансляции.
• Специфические запросы: Запросы, связанные с известными сущностями (бренды, люди, организации) и событиями. Особенно влияет на запросы с явным интентом поиска трансляции («смотреть онлайн», «live stream»).
• Ниши и тематики: Спорт, киберспорт, новости, политика, развлечения, технологические презентации.

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

Алгоритм применяется при выполнении кумулятивного набора условий:

• Качество: Quality Score трансляции превышает установленный порог (проверяется офлайн).
• Релевантность: Сущности запроса совпадают с сущностями трансляции.
• Значимость сущности (Триггер): Система определила, что для совпадающей сущности должен быть показан Fact Summary.
• Своевременность: Время до начала трансляции не превышает Time Difference Threshold.
• Динамическое условие (Интент): Значение Time Difference Threshold устанавливается динамически: выше для Specific Intent, ниже для General Intent.

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

Процесс А: Офлайн-оценка качества трансляций (Фильтрация)

1. Сбор данных: Получение суперсета предстоящих прямых трансляций из различных источников (видеохостинги, социальные сети).
2. Извлечение признаков: Для каждой трансляции определяются организатор, связанные сущности (с помощью Entity Annotator) и текст описания.
3. Расчет суб-оценок:
   1. Расчет Organizer Score: Оценка репутации на основе истории качественных трансляций и количества подписчиков.
   2. Получение Entity Score: Запрос оценок популярности связанных сущностей из индекса.
   3. Расчет Description Score: Анализ длины и уникальности слов в описании.
4. Расчет Quality Score: Вычисление агрегированной оценки как взвешенного среднего суб-оценок.
5. Фильтрация и Индексация: Сравнение Quality Score с порогом. Трансляции, превысившие порог, сохраняются в индексе Live Event Data.

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

1. Получение запроса.
2. Понимание запроса:
   1. Извлечение сущностей из запроса.
   2. Определение Query Intent (Specific или General) с использованием Query Patterns.
3. Идентификация кандидатов: Поиск в индексе Live Event Data трансляций с совпадающими сущностями.
4. Проверка Fact Summary: Определение, будет ли отображаться Fact Summary для сущности. Если нет, процесс останавливается.
5. Установка динамического порога: Определение Time Difference Threshold. T1 (высокий) для Specific Intent; T2 (низкий) для General Intent.
6. Фильтрация по времени: Расчет времени до начала каждой трансляции-кандидата и сравнение его с установленным порогом.
7. Формирование выдачи: Трансляции, прошедшие все фильтры, включаются в SERP в виде блока Live Events вместе с общими результатами.

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

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

• Контентные факторы: Текст описания (Description) прямой трансляции. Используется для расчета Description Score и извлечения сущностей.
• Структурные факторы (Метаданные события): Идентификатор организатора (Organizer), связанные сущности (Entities), запланированное время и дата начала.
• Поведенческие и Исторические факторы:
  • История организатора: Количество ранее проведенных высококачественных трансляций.
  • Социальные сигналы: Количество подписчиков (followers) организатора.
  • Исторические данные о запросах и упоминания в соцсетях: Используются для расчета популярности сущностей (Entity Score).
• Временные факторы: Время начала трансляции и текущее время запроса.

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

Система использует комплекс метрик для оценки качества:

• Organizer Score: Рассчитывается на основе количества прошлых качественных событий и количества подписчиков. Может быть нормализованным значением (например, от 0 до 1) при достижении определенных порогов.
• Entity Score: Отражает популярность сущности. Получается из внешнего индекса, рассчитывается на основе объема запросов или упоминаний.
• Description Score: Рассчитывается на основе количества слов (word count), возможно, с учетом уникальности и исключением стоп-слов. Оценка максимальна, если количество слов находится в оптимальном диапазоне (не слишком короткое и не слишком длинное).
• Quality Score: Агрегированная оценка. Рассчитывается как взвешенное среднее (weighted average) из суб-оценок. Веса могут настраиваться (например, вес Organizer Score может быть выше веса Description Score). $QS = f(OrganizerScore, EntityScores, DescriptionScore)$
• Time Difference: Разница между временем начала трансляции и временем запроса.
• Dynamic Time Difference Threshold: Порог для Time Difference. Имеет два значения: T1 (для Specific Intent) и T2 (для General Intent), где T1 > T2.

1. Качество трансляции (Quality Score) — это фильтр на входе: Google активно фильтрует прямые трансляции офлайн. Quality Score, основанный на репутации организатора, популярности темы и качестве описания, определяет, попадет ли трансляция в индекс событий. Низкокачественные стримы отсеиваются до этапа ранжирования.
2. Привязка к сущностям (Entities) обязательна для релевантности: Сопоставление запроса и трансляции происходит на уровне сущностей, а не ключевых слов. Трансляция должна быть четко ассоциирована с известными сущностями в Графе Знаний.
3. Интеграция с Графом Знаний (Fact Summary Trigger): Показ блока Live Events связан с отображением Fact Summary (Панели Знаний) для соответствующей сущности. Это ограничивает показ трансляций только для хорошо известных и проработанных сущностей.
4. Интент пользователя управляет своевременностью показа: Система использует динамические временные пороги. Если пользователь явно ищет стрим (Specific Intent, определяемый через Query Patterns), Google покажет трансляцию заранее. Если запрос общий (General Intent), показываются только те трансляции, которые начнутся в ближайшее время.
5. Репутация организатора (E-E-A-T) критична: Organizer Score, основанный на истории качественных трансляций и количестве подписчиков, является ключевой составляющей Quality Score. Это подчеркивает важность долгосрочной работы над авторитетностью канала/аккаунта.

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

• Наращивание репутации организатора (Organizer Score): Последовательно проводить высококачественные трансляции и активно работать над увеличением числа подписчиков (followers) на платформе стриминга. Это напрямую влияет на Quality Score будущих трансляций и является применением принципов E-E-A-T к живому контенту.
• Четкая ассоциация трансляций с сущностями (Entities): Убедиться, что метаданные трансляции (название, описание) четко указывают на ключевые сущности (имена спикеров, название мероприятия, бренд). Эти сущности должны присутствовать в Графе Знаний.
• Оптимизация описаний (Description Score): Создавать содержательные, уникальные описания оптимальной длины. Избегать слишком коротких или переспамленных текстов. Использовать релевантные термины и упоминания сущностей.
• Работа над значимостью сущностей (Fact Summary Trigger): Развивать связанные сущности (бренд компании, личный бренд спикера), чтобы повысить вероятность появления Fact Summary (Панели Знаний) по соответствующим запросам, что является триггером для показа блока Live Events.
• Использование структурированных данных: Внедрять разметку (например, VideoObject с BroadcastEvent) на страницах анонсов, чтобы явно указать поисковой системе на время начала (startDate) и статус (isLive). Это помогает системе корректно индексировать событие.
• Оптимизация под специфический интент (Specific Intent): При анонсировании трансляций использовать формулировки, соответствующие Query Patterns (например, «Смотрите прямую трансляцию [Название]»), чтобы воспользоваться более мягкими временными порогами.

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

• Запуск важных трансляций с новых или неавторитетных аккаунтов: Низкий Organizer Score приведет к низкому Quality Score, и трансляция не пройдет первичный фильтр качества.
• Использование коротких, шаблонных или отсутствующих описаний: Это негативно скажется на Description Score и уменьшит шансы на попадание в выдачу.
• Игнорирование связи с сущностями: Проведение трансляций без четкой привязки к известным сущностям делает невозможным работу механизма сопоставления (Entity Matching).
• Публикация анонса в последнюю минуту: Поскольку оценка качества (Quality Score) происходит офлайн, системе требуется время для обработки данных о трансляции до ее начала.

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

Патент подтверждает стратегию Google по интеграции разноформатного контента в основную выдачу с опорой на Граф Знаний и качество источников. Для SEO это означает, что продвижение прямых эфиров тесно связано с управлением репутацией (E-E-A-T организатора) и развитием связанных сущностей. Система отдает предпочтение авторитетным источникам и четко идентифицируемым событиям, снижая видимость низкокачественного стриминга.

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

Сценарий: Презентация нового продукта технологической компанией (например, Google I/O).

Офлайн-подготовка Google:

• Organizer Score: У аккаунта Google максимальный балл (много подписчиков, история).
• Entity Score: У сущностей «Google I/O» и «Android» высокая популярность.
• Итог: Трансляция получает высокий Quality Score и попадает в индекс Live Event Data.

Онлайн-обработка запросов (за неделю до события):

1. Запрос 1 (General Intent): «Google I/O». Интент общий. Система применяет строгий временной порог (например, 2 часа). Событие через неделю не показывается.
2. Запрос 2 (Specific Intent): «Смотреть Google I/O онлайн». Интент специфический (совпадение с Query Pattern). Система применяет мягкий временной порог (например, 2 недели). Событие показывается в блоке Live Events с указанием даты начала.

Онлайн-обработка запросов (за 5 минут до события):

1. Запрос 1 (General Intent): «Google I/O». Интент общий. Порог строгий (2 часа). Событие начинается через 5 минут. Оно показывается в блоке Live Events (при условии, что Fact Summary также активирован).