Как Google строит Knowledge Graph, объединяя данные из разных источников, разрешает конфликты фактов и управляет идентификаторами сущностей

Описание

Какую задачу решает

Патент решает фундаментальную проблему построения масштабных графов знаний (таких как Google Knowledge Graph) из множества разрозненных источников данных. Ключевые проблемы:

• Разные пространства идентификаторов (Identifier Spaces): Каждый источник использует свои уникальные ID для одних и тех же сущностей (например, ID для «Том Круз» в базе фильмов отличается от ID в другом каталоге), что делает невозможным их прямое объединение.
• Конфликты и Дублирование Данных: Источники могут предоставлять противоречивую информацию (например, разные даты рождения) или дублировать факты.
• Ограничения на использование данных: Разные источники имеют разные лицензионные или конфиденциальные ограничения.
• Масштабируемость и Обновления: Источники обновляются по разным графикам, и система должна эффективно обрабатывать эти изменения без перестроения всего графа.

Что запатентовано

Запатентована двухфазная система построения и обновления комбинированных графов данных. Первая фаза (Reconciliation) отвечает за преобразование идентификаторов из исходных пространств в единое глобальное пространство (Global Identifier Space) с использованием файлов свидетельств (Evidence Files). Вторая фаза (Graph Building) объединяет нормализованные данные, устраняет дубликаты, разрешает конфликты (основываясь на консенсусе) и создает различные «представления» (Knowledge Graph Views) графа на основе заданных определений (Graph View Definitions).

Как это работает

Система работает в два этапа:

Фаза 1: Согласование (Reconciliation)

• Система отслеживает изменения в исходных данных (Source Data Graphs).
• При обнаружении изменений запускается процесс согласования только для измененного источника.
• Используя Source Evidence Files и центральный Master Evidence File, система заменяет локальные ID сущностей на глобальные (Global Identifiers). Если глобальный ID не найден, он создается («минтится»).
• Результат — Reconciled Data Graph (нормализованный граф в глобальном пространстве ID).

Фаза 2: Построение Графа (Graph Building)

• Система генерирует Entity Provenance Graph, который отслеживает происхождение каждой сущности.
• На основе Graph View Definition выбирается набор Reconciled Data Graphs.
• Все данные (триплеты) из выбранных графов объединяются.
• Происходит дедупликация: идентичные факты объединяются, но сохраняется информация обо всех источниках, подтвердивших этот факт.
• Происходит разрешение конфликтов: если факты противоречат друг другу, система выбирает тот, который подтвержден большим количеством источников (Claim 7).
• Результат — Knowledge Graph View (например, публичная версия Knowledge Graph или внутренняя версия с лицензионными данными).

Актуальность для SEO

Высокая. Описанная система является фундаментальной инфраструктурой для построения и поддержания Google Knowledge Graph. Процессы согласования сущностей (Entity Reconciliation), управления идентификаторами и разрешения конфликтов фактов критически важны для качества и полноты данных, которые Google использует в поиске, Knowledge Panels и других продуктах.

Важность для SEO

Влияние на SEO — высокое (7.5/10), особенно для Entity SEO и оптимизации под Knowledge Graph. Хотя патент описывает инфраструктуру построения графа, а не алгоритмы ранжирования веб-страниц, он раскрывает критически важные механизмы, которые определяют, как Google понимает и обрабатывает факты о сущностях. Понимание процессов Reconciliation и Conflict Resolution (особенно механизма консенсуса) необходимо для обеспечения того, чтобы Google корректно идентифицировал ваши сущности и принимал ваши данные в качестве авторитетных.

Детальный разбор

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

Combined Data Graph View (Комбинированный граф данных / Представление)

Итоговый продукт системы. Граф, построенный путем объединения данных из нескольких Reconciled Data Graphs. Может существовать несколько представлений (Views) для разных целей (например, публичное, внутреннее).

Entity Provenance Graph (Граф происхождения сущностей)

Специальный граф, который содержит информацию о происхождении каждой сущности, связывая Global Identifier с исходными данными (Source Data Graphs), которые описывают эту сущность.

Evidence File (Файл свидетельств)

Файл, содержащий маппинг (соответствие) между идентификаторами из одного пространства в другое. Существуют Source Evidence Files (предоставляются источником) и Master Evidence File (центральное хранилище).

Global Identifier (Глобальный идентификатор, Global ID)

Уникальный идентификатор сущности в рамках всей системы (во всех источниках). Используется в Reconciled Data Graphs.

Graph Building Engine (Механизм построения графа)

Компонент системы (Фаза 2), отвечающий за объединение Reconciled Data Graphs, дедупликацию, разрешение конфликтов и создание Knowledge Graph Views.

Graph View Definitions (Определения представлений графа)

Конфигурационные файлы, которые определяют, какие Reconciled Data Graphs должны быть включены в конкретное Knowledge Graph View и какие ограничения доступа к нему применяются.

ID Replacement Triples (Триплеты замены идентификаторов)

Специальные триплеты, создаваемые в процессе согласования, которые связывают устаревший Global Identifier с актуальным через отношение типа «заменен на» (replaced by). Обеспечивают обратную совместимость.

Master Evidence File (Мастер-файл свидетельств)

Централизованная база данных, которая хранит все известные соответствия между исходными идентификаторами и Global Identifiers. Аккумулирует данные из всех Source Evidence Files и отслеживает историю изменений ID.

Reconciled Data Graph (Согласованный граф данных)

Промежуточный продукт (Фаза 1). Исходный граф данных, в котором все локальные идентификаторы заменены на Global Identifiers.

Reconciliation Engine (Механизм согласования)

Компонент системы (Фаза 1), отвечающий за преобразование Source Data Graphs в Reconciled Data Graphs путем маппинга идентификаторов.

Source Data Graph (Исходный граф данных)

Входные данные от внешнего источника (например, Freebase, Wikipedia, база данных музыки), представленные в виде графа с использованием локальных идентификаторов.

Triple (Триплет)

Базовая единица данных в графе (Субъект-Предикат-Объект). Может включать метаданные (source attribute).

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

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

1. Генерация согласованных графов (Фаза 1): Для каждого исходного графа создается согласованный граф (reconciled data graph). Это включает замену локальных идентификаторов узлов на глобальные (global identifier). Этот процесс запускается в ответ на обновление соответствующего исходного графа.
2. Определение набора источников: Система определяет набор выбранных источников на основе файла представления графа (graph view file).
3. Генерация комбинированного графа (Фаза 2): Создается комбинированный граф (combined data graph) путем объединения согласованных графов, соответствующих выбранным источникам. Объединение происходит по узлам с одинаковыми глобальными идентификаторами.
4. Использование: Генерация результатов поиска с использованием комбинированного графа.

Claim 2 (Зависимый): Уточняет, что перед генерацией комбинированного графа создается Entity Provenance Graph, который затем включается в комбинированный граф.

Claims 3 и 4 (Зависимые): Описывают создание нескольких различных представлений (Views) с разными наборами источников и разными уровнями доступа (например, публичный и ограниченный доступ).

Claim 5, 6, 7 (Зависимые): Детализируют процесс генерации комбинированного графа (Фаза 2), фокусируясь на обработке триплетов.

1. Объединение (Claim 5): Триплеты из выбранных согласованных графов добавляются в комбинированный граф, затем удаляются дубликаты и конфликты.
2. Удаление дубликатов (Claim 6): Если обнаружены два одинаковых триплета, система обновляет атрибут источника (source attribute) одного из них, чтобы включить информацию об источнике другого, а затем удаляет дубликат. Это сохраняет информацию о происхождении (provenance).
3. Удаление конфликтов (Claim 7): Если обнаружен конфликтующий триплет, система определяет, какой из триплетов существует в большем количестве источников, и удаляет тот, который встречается реже (разрешение конфликта консенсусом).

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

Этот патент описывает инфраструктуру построения Knowledge Graph. Он применяется на этапе обработки и структурирования данных.

CRAWLING – Сканирование и Сбор данных
Система собирает или получает Source Data Graphs из различных источников (внешние базы данных, API, результаты краулинга структурированных данных).

INDEXING – Индексирование и извлечение признаков
Это основной этап применения патента. Система не просто индексирует контент, она строит структурированную базу знаний.

• Фаза 1 (Reconciliation): Соответствует этапам нормализации и каноникализации данных. Происходит преобразование разрозненных данных в единое пространство идентификаторов (Global Identifier Space). Это критически важный процесс для связывания сущностей (Entity Reconciliation).
• Фаза 2 (Graph Building): Соответствует этапу построения финального индекса (графа знаний). Включает процессы очистки данных (дедупликация) и обеспечения качества (разрешение конфликтов). Также на этом этапе генерируется Entity Provenance Graph.

QUNDERSTANDING / RANKING / METASEARCH
Созданные Knowledge Graph Views используются системами понимания запросов для идентификации сущностей и системами ранжирования/метапоиска для формирования Knowledge Panels, каруселей сущностей и других элементов выдачи, основанных на фактах.

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

• Source Data Graphs.
• Source Evidence Files и Master Evidence File.
• Graph View Definitions.

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

• Reconciled Data Graphs.
• Обновленный Master Evidence File.
• Knowledge Graph Views (финальные графы знаний).

На что влияет

• Сущности (Entities): Патент напрямую влияет на то, как Google идентифицирует, объединяет и хранит информацию обо всех типах сущностей (люди, места, организации, концепции и т.д.).
• Качество данных и достоверность: Механизмы дедупликации и разрешения конфликтов направлены на повышение точности и согласованности данных в Knowledge Graph.
• Масштабируемость: Двухфазная архитектура позволяет Google эффективно добавлять новые источники данных и обрабатывать обновления без необходимости пересчета всего графа.

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

• Триггеры Фазы 1 (Reconciliation): Активируется при обнаружении изменений в конкретном Source Data Graph или соответствующем Source Evidence File. Обработка происходит инкрементально только для измененного источника.
• Триггеры Фазы 2 (Graph Building): Выполняется периодически (например, ежедневно) или по требованию для перестроения Knowledge Graph Views с использованием последних версий Reconciled Data Graphs.
• Исключения и особые случаи: Система поддерживает версионность Reconciled Data Graphs, что позволяет откатиться к предыдущей версии в случае нестабильности или ошибок после обновления данных.

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

Система состоит из двух независимых процессов.

Процесс А: Фаза 1 – Согласование (Reconciliation Engine)

1. Мониторинг источников: Система проверяет, изменился ли исходный граф данных или его файл свидетельств. Если нет, процесс останавливается.
2. Итерация по идентификаторам: Если обнаружены изменения, система перебирает все локальные идентификаторы (Source IDs) в исходном графе.
3. Определение Глобального ID (Global ID): Для каждого Source ID определяется соответствующий Global ID. Это включает:
   • Проверку Source Evidence File (включая поиск цепочек маппингов через другие источники).
   • Проверку Master Evidence File.
   • Сравнение ID из источника и мастера. При несовпадении система разрешает конфликт и обновляет Master Evidence File.
   • Создание нового ID: Если Global ID не найден, система генерирует («минтит») новый уникальный Global ID и добавляет его в Master Evidence File.
4. Подстановка ID: Локальный идентификатор заменяется на выбранный Global ID во всех триплетах исходного графа.
5. Генерация триплетов замены (ID Replacement): Если сущность ранее имела другой Global ID, создаются специальные триплеты (например, «Old_ID replaced_by New_ID») для обратной совместимости.
6. Сохранение: Генерируется и сохраняется новый Reconciled Data Graph. Предыдущие версии сохраняются для возможности отката.

Процесс Б: Фаза 2 – Построение Графа (Graph Building Engine)

1. Генерация графа происхождения: Создается Entity Provenance Graph.
2. Выбор графов: Система использует Graph View Definition для определения того, какие Reconciled Data Graphs следует включить в данное представление.
3. Объединение триплетов: Все триплеты из выбранных графов (включая граф происхождения) объединяются.
4. Дедупликация и сохранение происхождения: Система ищет дублирующиеся триплеты. При обнаружении дубликата один триплет удаляется, но метаданные о его источнике (source attribute) переносятся в оставшийся триплет.
5. Разрешение конфликтов: Система ищет конфликтующие утверждения. Конфликт разрешается путем выбора одного из вариантов. Основной критерий (Claim 7) — выбор факта, подтвержденного большим количеством источников (консенсус). Также может использоваться доверие к источнику.
6. Генерация и сохранение представления: Оставшиеся триплеты формируют Knowledge Graph View. Он сохраняется в локации, соответствующей его уровню доступа.

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

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

Патент фокусируется на структурных данных и идентификаторах.

• Структурные факторы (Graph Data): Основные входные данные — это графы, состоящие из триплетов (Субъект-Предикат-Объект).
• Идентификаторы (Identifiers): Локальные идентификаторы (Source IDs) и глобальные идентификаторы (Global IDs).
• Метаданные о происхождении (Provenance): Информация о том, из какого источника поступил каждый триплет или сущность (source attribute).
• Конфигурационные данные: Graph View Definitions, Evidence Files.

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

Патент не описывает метрики ранжирования, но описывает метрики и логику для обработки данных:

• Соответствие идентификаторов (ID Matching): Используется для процесса Reconciliation. Логика включает прямое сравнение и поиск цепочек соответствий в Evidence Files.
• Дублирование триплетов (Triple Duplication): Определяется путем точного совпадения Субъекта, Предиката и Объекта.
• Частота источника (Source Frequency/Consensus): Ключевая метрика, используемая для разрешения конфликтов (Claim 7). Рассчитывается как количество источников, подтверждающих данный факт (триплет). Факт с большей частотой предпочтительнее.
• Доверие к источнику (Source Trustworthiness): Упоминается в описании (но не в Claims) как возможный критерий для разрешения конфликтов (предпочтение фактов из более надежного источника).

Выводы

1. Двухфазное построение Knowledge Graph: Google не объединяет данные напрямую. Сначала происходит обязательный этап нормализации (Reconciliation), где локальные ID заменяются глобальными, и только потом данные объединяются (Graph Building). Это обеспечивает эффективность и гибкость.
2. Согласование сущностей (Entity Reconciliation) критично: Центральным элементом системы является управление глобальными идентификаторами (Global IDs) через Master Evidence File. Способность системы корректно связать разные упоминания одной сущности определяет полноту данных о ней.
3. Отслеживание происхождения (Provenance) повсеместно: Google точно знает, откуда пришел каждый факт. Entity Provenance Graph генерируется и используется для управления данными и оценки их качества.
4. Консенсус как механизм истины: При наличии противоречивых фактов система использует автоматизированные методы для выбора одного. Основной механизм, защищенный патентом (Claim 7), — это консенсус (предпочтение факту, подтвержденному наибольшим количеством источников).
5. Knowledge Graph не монолитен: Система генерирует различные «представления» (Views) графа для разных нужд и уровней доступа (например, публичные и лицензионные данные).
6. Обратная совместимость ID: Система отслеживает историю изменения глобальных идентификаторов и использует ID Replacement Triples (отношение «replaced by»), чтобы гарантировать, что запросы по старым ID будут вести на актуальную сущность.

Практика

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

• Обеспечение четкой идентификации сущностей (Помощь в Reconciliation): Критически важно помочь Google в процессе согласования. Используйте стандартизированные идентификаторы и ссылки на авторитетные источники. Внедряйте полную разметку Schema.org, активно используйте свойство sameAs для связи с Wikidata, официальными базами данных (например, MusicBrainz, IMDb) и используйте стандартные идентификаторы (GTIN, ISBN).
• Построение консенсуса (Consensus Building для Conflict Resolution): Поскольку система разрешает конфликты, основываясь на частоте упоминания факта (Claim 7), необходимо обеспечить широкое распространение корректной информации о вашей сущности (бренд, персона, продукт) на авторитетных сторонних ресурсах (СМИ, отраслевые каталоги, энциклопедии).
• Обеспечение консистентности данных (NAP): Следите за тем, чтобы информация о ключевых сущностях была идентичной на вашем сайте, в микроразметке и на внешних площадках. Это минимизирует риск возникновения конфликтов данных.
• Мониторинг и исправление ошибок в Knowledge Graph: Отслеживайте информацию о ваших сущностях в Knowledge Panels. При обнаружении ошибок оперативно исправляйте данные в первоисточниках, на которые опирается Google, чтобы выиграть в процессе Conflict Resolution при следующем обновлении графа.

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

• Использование амбивалентных или локальных идентификаторов: Опираться только на название сущности без предоставления уникальных идентификаторов (Schema.org, sameAs) усложняет процесс Reconciliation и может привести к созданию дубликатов сущностей или неверному слиянию.
• Предоставление противоречивой информации: Публикация данных, которые конфликтуют с общепринятыми фактами из авторитетных источников. Система автоматически отклонит ваши данные в пользу консенсуса, если у вас нет очень высокого уровня доверия.
• Несогласованность данных (Inconsistency): Наличие разных версий информации о сущности на разных страницах вашего сайта или в разных профилях в сети. Это может привести к тому, что система не сможет определить канонический факт.

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

Этот патент подтверждает стратегическую важность Entity SEO. Понимание того, как Google строит Knowledge Graph, переходит из разряда «интересных фактов» в операционную необходимость. Стратегия должна фокусироваться не только на контенте, но и на представлении этого контента в виде фактов и сущностей, которые легко идентифицируются (Reconciliation) и подтверждаются (Conflict Resolution через консенсус). Обеспечение согласованности данных во всей экосистеме является ключевым фактором успеха.

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

Сценарий: Разрешение конфликта характеристик продукта

1. Исходные данные: Ритейлер А указывает вес продукта X как 5 кг. Ритейлеры B, C и D, а также официальный сайт производителя указывают вес продукта X как 4.5 кг. Все они предоставляют данные через фиды или микроразметку.
2. Фаза 1 (Reconciliation): Google обрабатывает данные из всех 5 источников. Система идентифицирует продукт X во всех источниках (например, по GTIN) и присваивает ему единый Global ID.
3. Фаза 2 (Graph Building): При объединении данных система обнаруживает конфликт для отношения «вес». Тройка [Продукт X, вес, 5 кг] имеет 1 источник. Тройка [Продукт X, вес, 4.5 кг] имеет 4 источника.
4. Разрешение конфликта: Основываясь на механизме, описанном в Claim 7 (предпочтение факту с большим количеством источников), система выбирает вес 4.5 кг.
5. Результат: В Knowledge Graph будет указан вес 4.5 кг. Данные ритейлера А по этому параметру будут проигнорированы.

Вопросы и ответы