Как Google создает временные Графы Знаний для освещения срочных новостей и событий в реальном времени

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

Developing Event (Развивающееся событие)

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

Event-Specific Provisional Knowledge Graph (PKG) (Временный Граф Знаний для конкретного события)

Временная («provisional» или «ephemeral») структура данных, создаваемая для конкретного developing event. Она строится поверх основного графа знаний, но содержит новую, потенциально непроверенную информацию, ноды и связи, которых еще нет в основном графе.

Event Subscribers (Подписчики события)

Пользователи, которые выразили интерес к событию (например, задав о нем вопрос) или интересуются определенным типом событий, и которые могут получать проактивные обновления (push-уведомления).

Event Type Template (Шаблон типа события)

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

General-Purpose Knowledge Graph (KG) (Граф Знаний общего назначения)

Основная база знаний Google, содержащая верифицированные факты о сущностях (ноды) и их взаимосвязях (связи).

Live Data Stream (Живой поток данных)

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

Live Stream Monitor (Монитор живых потоков)

Компонент системы, отвечающий за анализ live data streams для обнаружения новых событий и извлечения информации.

Query Monitor (Монитор запросов)

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

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

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

1. Система анализирует два или более live data streams.
2. На основе анализа система впервые обнаруживает (newly detecting) развивающееся событие И идентифицирует связанные с ним сущности (которые уже существуют в General-Purpose Knowledge Graph).
3. В ответ на обнаружение события система создает Event-Specific Provisional Knowledge Graph (PKG).
4. PKG разделяет узлы сущностей с основным графом, но добавляет новые узлы и связи, отсутствующие в основном графе. Ключевое уточнение: один из новых узлов создается для представления самого впервые обнаруженного события.
5. После создания система запрашивает PKG для получения новой информации о событии.
6. Система инициирует отображение этой новой информации на устройствах.

Claim 2 (Зависимый от 1): Уточняет триггер анализа.

Анализ живых потоков может быть инициирован получением пользовательского запроса о событии до того, как система его официально обнаружила. На основе этого запроса система анализирует больший набор живых потоков.

Claim 4 и 5 (Зависимые): Уточняют альтернативный триггер.

Система может инициировать анализ живых потоков в ответ на то, что основной General-Purpose Knowledge Graph не содержит информации, релевантной пользовательскому запросу.

Claim 7 (Зависимый от 1): Включает определение типа события.

Система определяет тип (event type) развивающегося события на основе анализа живых потоков.

Claim 8 (Зависимый от 7): Описывает механизм проактивных уведомлений.

1. Система определяет, что пользователь заинтересован в получении информации о событиях данного типа.
2. На этом основании система проактивно отправляет (pushing) данные с новой информацией на устройство пользователя.
3. Это приводит к отображению информации без явного запроса пользователя на обновление.

Claim 10 (Зависимый от 7): Описывает метод определения типа события.

Определение типа события включает сопоставление структуры PKG (новых узлов/связей) с Шаблоном типа события (Event Type Template).

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

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

CRAWLING – Сканирование и Сбор данных
Система активно сканирует (crawls) и анализирует live data streams (например, социальные сети) через компонент Live Stream Monitor и Crawler/Parser.

INDEXING – Индексирование и извлечение признаков
Происходит быстрое индексирование в реальном времени. Данные из потоков обрабатываются через конвейер (pipeline), включающий NLP для извлечения тем (Topic Extraction) и идентификации сущностей (Entity Identification/Linking), а также обработку изображений/видео. Результатом является не обновление основного индекса, а создание временной структуры — Event-Specific Provisional Knowledge Graph (PKG). Это позволяет обойти медленные процессы проверки фактов.

QUNDERSTANDING – Понимание Запросов
Query Monitor анализирует поток запросов в реальном времени. Кластеризация семантически похожих запросов может служить триггером для обнаружения нового события. Система также распознает запросы, относящиеся к уже обнаруженным событиям.

RANKING / METASEARCH – Ранжирование / Метапоиск
При обработке запроса о событии система может определить, что основной KG не имеет ответа (Claim 4). В этом случае система обращается к PKG для получения самой свежей информации. Также система использует PKG для проактивной отправки (push) обновлений подписчикам.

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

• Live data streams (текст, изображения, видео, аудио из социальных сетей).
• Поток поисковых запросов пользователей.
• Данные из General-Purpose Knowledge Graph (для идентификации существующих сущностей).
• Геолокационные (GPS) и временные метки потоков и запросов.

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

• Созданный и обновляемый Event-Specific Provisional Knowledge Graph.
• Ответы на запросы о событиях в реальном времени (через Поиск или Ассистент).
• Проактивные уведомления (текстовые или голосовые) для подписчиков.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на QDF-запросы (Query Deserves Freshness) и запросы о последних новостях, трендах и текущих событиях.
• Конкретные типы контента: Новостные статьи, посты в блогах (особенно Live Blogs), контент в социальных сетях, видео и изображения с места событий.
• Конкретные ниши или тематики: Новости, спорт, развлечения (концерты), чрезвычайные ситуации, политика (митинги, протесты). Может затрагивать YMYL-тематики, связанные с безопасностью.

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

Алгоритм активируется при обнаружении developing event.

• Триггеры активации:
• Аномалии в потоках данных: Обнаружение кластера семантически связанных постов в live data streams, особенно от пользователей, находящихся географически близко.
• Аномалии в запросах: Всплеск семантически связанных поисковых запросов (обнаруженный Query Monitor).
• Невозможность ответа: Когда пользователь задает вопрос о потенциальном событии, а основной General-Purpose Knowledge Graph не может предоставить ответ (Claim 4).
• Сигналы от доверенных источников: Мониторинг живых потоков от доверенных организаций (например, служб экстренного реагирования, репортеров).

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

Этап 1: Обнаружение события (Detection)

1. Мониторинг потоков: Система непрерывно анализирует поисковые запросы (через Query Monitor) и живые потоки данных (через Live Stream Monitor).
2. Кластеризация: Система ищет кластеры семантически, темпорально и географически близких сигналов (запросов или постов).
3. Триггер: Если обнаружен значительный кластер и/или основной КГ не содержит информации, система детектирует новое развивающееся событие.

Этап 2: Создание и Наполнение Временного Графа (Construction)

1. Сбор релевантных данных: Crawler/Parser собирает данные из идентифицированных релевантных живых потоков.
2. Обработка конвейера (Pipeline Processing):
• Текст парсится. Изображения/видео анализируются (Image/Video Sub-pipeline) для распознавания объектов/текста (OCR). Аудио транскрибируется.
• Применяются NLP-модели для извлечения тем (Topic Extraction, например, PLSA, LDA) и идентификации сущностей (Entity Identification/Linking).
3. Построение графа (PKG Construction): Provisional Knowledge Graph Manager создает PKG.
• Создается новый узел для самого события (Claim 1).
• Идентифицированные сущности связываются с существующими узлами в основном КГ.
• Создаются новые связи между событием и сущностями на основе извлеченной информации.
4. Классификация события (Event Type Classification): Структура PKG сравнивается с Event Type Templates или обрабатываются ML-моделью для определения типа события (например, «пожар»).
5. Дедупликация и обновление: Новая информация дедуплицируется (Deduplicator) и используется для обновления PKG.

Этап 3: Использование и Распространение (Utilization)

1. Обработка запросов: При поступлении запроса о событии система запрашивает PKG.
2. Идентификация подписчиков: Система определяет пользователей, заинтересованных в событии или типе события (Event Subscribers).
3. Генерация ответов и Суммаризация: NLP-модель (Sentence Summarization) генерирует сводку новой информации в естественном языке.
4. Доставка информации: Новая информация отправляется пользователям через Notification Streamer (визуально) или TTS Streamer (аудио), возможно, проактивно (push).

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

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

Система агрегирует данные из множества источников в реальном времени.

• Контентные факторы (из Live Data Streams): Текстовое содержание постов в социальных сетях, комментарии.
• Мультимедиа факторы: Изображения, видео и аудио, публикуемые в потоках данных. Они обрабатываются для распознавания объектов, текста (OCR) и речи.
• Временные факторы: Временные метки постов и запросов. Критически важны для определения актуальности и последовательности событий.
• Географические факторы: Местоположение (например, GPS-координаты) устройств, используемых для публикации постов или отправки запросов. Используются для определения местоположения события и релевантности источников.
• Пользовательские факторы (Источники): Надежность и авторитетность источника потока данных. Патент упоминает, что потоки от служб экстренного реагирования, репортеров или правительственных организаций могут считаться более надежными.
• Поведенческие факторы (Запросы): Поисковые запросы пользователей. Анализируется их семантика, частота и локация для обнаружения событий.

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

Патент не приводит конкретных формул, но описывает следующие методы и концепции:

• Кластеризация и Семантическая близость: Используется для обнаружения событий. Вероятно, основано на генерации эмбеддингов (embeddings) текстового контента и определении их близости в латентном пространстве.
• NLP (Обработка естественного языка):
• Извлечение тем (Topic Extraction): Упоминаются статистические модели, такие как PLSA (Probabilistic Latent Semantic Analysis) или LDA (Latent Dirichlet Allocation), для анализа контента потоков.
• Идентификация сущностей (Entity Identification/Linking): Используется для распознавания упоминаний сущностей и их связывания с Графом Знаний.
• Шаблоны типов событий (Event Type Templates): Используются для классификации событий путем сопоставления извлеченных данных со слотами в шаблоне (например, шаблон «спорт» ищет данные о «счете», «игроках»).
• Машинное обучение (для классификации событий): Упоминаются ML-модели (например, нейронные сети, SVM, графовые нейронные сети), обученные классифицировать типы событий на основе структуры PKG или извлеченных признаков.
• Дедупликация: Методы для определения того, является ли информация новой или повторением (репостом) существующей информации.

1. Временные Графы Знаний (PKG) для реального времени: Google активно использует временные структуры данных (Provisional Knowledge Graphs) для агрегации информации о срочных событиях. Это позволяет системе реагировать быстро, не дожидаясь верификации данных для основного Графа Знаний. Скорость приоритетнее точности на ранних этапах события.
2. Live Data Streams как первоисточники знаний: Социальные сети, поисковые запросы и другие живые потоки рассматриваются как первичные источники информации во время developing events.
3. Автоматическое обнаружение событий через кластеризацию: Система обнаруживает новые события путем анализа аномалий и кластеризации семантически, географически и темпорально близких сигналов из запросов и социальных сетей.
4. Важность классификации событий (Event Type): Быстрое определение типа события (например, спорт, пожар) критически важно. Оно используется для структурирования информации (с помощью Event Type Templates) и для определения заинтересованной аудитории (подписчиков).
5. Переход к проактивному поиску (Push vs Pull): Патент описывает механизм проактивной доставки информации (push-уведомления) пользователям, которые интересовались событием или типом события, что является частью стратегии перехода от реактивного поиска к проактивной помощи (например, Google Assistant, Discover).
6. Мультимодальный анализ: Система не ограничивается текстом, а включает специализированные конвейеры для анализа изображений и видео из живых потоков для понимания контекста события.

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

• Скорость реакции (для новостных сайтов и издателей): Критически важно публиковать информацию максимально быстро во время срочных событий. Система предназначена для захвата самой свежей информации из live data streams.
• Активное использование Live-форматов и Социальных сетей: Используйте форматы, которые система интерпретирует как live data streams – официальные аккаунты в социальных сетях (Twitter/X), Live Blogs на сайте. Эти источники могут быть напрямую использованы для наполнения PKG.
• Четкая идентификация сущностей: При освещении событий необходимо четко и недвусмысленно указывать ключевые сущности (Кто, Что, Где). Это помогает системе (Entity Identification/Linking) правильно связать информацию с нодами в Графе Знаний и корректно построить PKG.
• Использование мультимедиа в реальном времени: Поскольку патент описывает конвейеры для обработки изображений и видео, использование релевантных, уникальных медиафайлов с места событий может повысить ценность вашего потока данных для системы.
• Развитие сущностей и авторитетности (E-E-A-T): Работайте над тем, чтобы ваша организация и авторы были четко представлены в основном Графе Знаний. Патент предполагает, что надежным и авторитетным источникам может отдаваться приоритет при формировании PKG.

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

• Медленное освещение событий: Задержка в публикации информации о developing events приведет к тому, что PKG будет сформирован на основе данных из социальных сетей или более быстрых конкурентов.
• Неоднозначное упоминание сущностей: Использование местоимений или жаргона без четкого указания сущностей затрудняет для системы понимание того, о ком или о чем идет речь.
• Игнорирование социальных сетей: Рассматривать социальные сети только как канал дистрибуции, а не как источник данных для Google. Отсутствие активности во время живых событий снижает шансы на попадание в PKG.
• Публикация недостоверной информации (Фейки): Хотя PKG содержит непроверенную информацию, система учитывает надежность источников. Систематическая публикация фейков может привести к снижению доверия к источнику и его игнорированию системой Live Stream Monitor.

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

Патент подтверждает стратегию Google по интеграции данных из социальных сетей и других источников реального времени непосредственно в поисковые продукты для обеспечения максимальной свежести (QDF). Для SEO-специалистов это означает, что оптимизация под срочные события требует не только работы с сайтом, но и стратегического подхода к управлению live data streams. Видимость по горячим темам зависит от способности быть быстрым, точным и авторитетным источником информации в реальном времени.

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

Сценарий: Освещение спортивного матча в реальном времени

1. Действие: Спортивный новостной сайт ведет текстовую трансляцию матча в формате Live Blog и параллельно публикует обновления в официальном Twitter-аккаунте.
2. Как делать: Каждое обновление должно четко идентифицировать сущности. Вместо «Он забил гол!» использовать «Игрок [Имя Фамилия] (Команда А) забил гол команде (Команда Б) на [Минута] минуте. Счет [X-Y]». Использовать релевантные изображения и короткие видео моментов.
3. Ожидаемый результат: Google обнаруживает developing event (матч). Информация из Twitter и Live Blog используется для наполнения Provisional Knowledge Graph. При запросах пользователей о счете или ключевых моментах матча, Google использует эту информацию для отображения в реальном времени (например, в спортивных блоках выдачи или через Ассистента).

Сценарий: Чрезвычайное происшествие в городе (Локальное SEO)

1. Действие: Местный новостной портал первым узнает о крупном пожаре.
2. Как делать: Немедленно опубликовать короткую новость и начать активное освещение в социальных сетях с указанием точного адреса или района (сущность-локация), времени начала и известных фактов (например, «Пожарные машины прибыли»). Использовать геотеги в постах.
3. Ожидаемый результат: Google обнаруживает всплеск запросов и постов о пожаре, используя геолокационные данные. Система создает PKG, используя данные портала как один из первых источников. Портал получает высокую видимость по локальным запросам, связанным с пожаром, а пользователи поблизости могут получать проактивные уведомления.