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

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

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

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

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

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

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

Компонент Фазы 2. Объединяет нормализованные графы, удаляет дубликаты и разрешает конфликты.

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

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

Identifier Space (Пространство идентификаторов)

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

Master Evidence File (Главный файл соответствий)

Центральный репозиторий, поддерживаемый системой, который отображает все известные локальные идентификаторы из всех источников на глобальные идентификаторы. Хранит историю всех когда-либо присвоенных ID.

Reconciled Data Graph (Нормализованный граф данных)

Результат Фазы 1. Исходный граф данных, переписанный с использованием глобальных идентификаторов вместо локальных.

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

Компонент Фазы 1. Конвертирует Source Data Graphs в Reconciled Data Graphs.

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

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

Source Evidence File (Файл соответствий источника)

Файл, предоставляемый источником, который отображает его локальные ID на другое пространство идентификаторов (в идеале, на глобальное).

Triple (Триплет)

Базовая единица данных в графе, состоящая из двух узлов (сущностей) и ребра (отношения). Формат: Субъект-Предикат-Объект.

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

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

1. Система хранит первый исходный граф (в пространстве ID 1) и нормализованную версию второго исходного графа (изначально в ID 2, теперь в ID 3/Глобальном).
2. Система хранит Master Evidence File, который отображает ID 1 и ID 2 на ID 3.
3. Система генерирует нормализованную версию первого графа путем замены его идентификаторов (ID 1) на глобальные (ID 3), используя Master Evidence File.
4. Система генерирует Combined Data Graph из нормализованных версий первого и второго графов.

Это ядро изобретения: независимая обработка источников (нормализация) с последующим объединением в глобальном пространстве идентификаторов.

Claim 2 (Зависимый от 1): Детализирует процесс удаления дубликатов во время объединения.

1. Определяется, что первый триплет дублирует второй триплет.
2. Метаданные (например, источник) из первого триплета перемещаются во второй триплет.
3. Первый триплет удаляется.

Это ключевой механизм слияния данных (Data Fusion) и отслеживания происхождения (Provenance Tracking). Факт сохраняется, но обогащается информацией о всех источниках, которые его подтверждают.

Claim 4 (Зависимый от 1): Описывает создание специфических представлений (Views).

1. Система определяет набор нормализованных графов, указанных в Graph View Definition.
2. Combined Data Graph генерируется только из этого выбранного набора.

Это позволяет создавать разные версии Графа Знаний для разных нужд (например, публичная версия и внутренняя версия с лицензионными данными).

Claim 7 (Зависимый от 1): Описывает обработку расхождений между данными источника и мастер-файлом.

1. Source Evidence File отображает сущность на Глобальный ID A.
2. Master Evidence File отображает ту же сущность на Глобальный ID B.
3. Система обновляет Master Evidence File так, чтобы сущность отображалась на ОБА идентификатора (A и B).

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

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

1. Генерация первого и второго нормализованных графов (наборы триплетов).
2. Генерация комбинированного графа путем: объединения наборов, идентификации совпадающих триплетов (Триплет 1 и Триплет 2), обновления атрибута источника Триплета 2, включив в него источник Триплета 1, и удаления Триплета 1.

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

Изобретение относится к этапу INDEXING – Индексирование и извлечение признаков (Indexing & Feature Extraction).

Это инфраструктура, которая отвечает за построение Графа Знаний из структурированных источников данных. Она не участвует в обработке запросов в реальном времени, а работает в офлайн-режиме для подготовки базы данных.

Взаимодействие с другими компонентами:

• Система создает базовую структуру данных (Граф Знаний), которая затем используется на этапах QUNDERSTANDING (для распознавания сущностей в запросе) и METASEARCH/RANKING (для формирования Панелей Знаний, обогащенных сниппетов и использования семантических связей).

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

• Source Data Graphs (данные от поставщиков).
• Source Evidence Files (отображения ID от поставщиков).

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

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

На что влияет

• Конкретные типы контента: Влияет на все типы структурированных данных о сущностях – людях, местах, организациях, продуктах, медиаконтенте и т.д.
• Конкретные ниши или тематики: Влияет на все тематики, представленные в Графе Знаний. Особенно сильно проявляется в областях, где существует множество источников данных, покрывающих одну тему (например, кино, музыка, биографии, локальный бизнес), так как там требуется активное согласование и разрешение конфликтов.

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

Алгоритм применяется в офлайн-режиме при обновлении данных Графа Знаний.

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

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

Фаза 1: Reconciliation (Нормализация и Согласование)

1. Проверка триггеров: Система обнаруживает изменения в исходном графе данных или файле соответствий источника.
2. Итерация по идентификаторам: Система перебирает каждый локальный идентификатор (Source ID) в исходном графе.
3. Определение Глобального ID:
   1. Проверка Source Evidence File (SEF) на наличие прямого отображения на Глобальный ID.
   2. Если прямого нет, проверка цепочек отображений (например, ID Источника A -> ID Источника B -> Глобальный ID).
   3. Проверка Master Evidence File (MEF) на наличие существующего отображения для данного локального ID.
   4. Разрешение конфликтов и обновление:
      • Если ID есть в MEF, но нет в SEF: Используется ID из MEF.
      • Если ID есть в обоих и совпадают: Используется этот ID.
      • Если ID есть в обоих и НЕ совпадают: Используется ID из SEF (как более актуальный), а MEF обновляется, чтобы включать ОБА ID для этой сущности (сохранение истории).
      • Если ID есть в SEF, но нет в MEF: Используется ID из SEF, MEF обновляется.
   5. Создание нового ID (Minting): Если ID не найден нигде, генерируется новый уникальный Глобальный ID, и MEF обновляется.
4. Подстановка: Локальный ID заменяется на определенный Глобальный ID во всех триплетах графа.
5. Генерация триплетов замены ID: Создаются специальные триплеты для исторических ID (например, Старый_ID "заменен на" (replaced by) Новый_ID) для обеспечения обратной совместимости.
6. Вывод: Сохраняется Reconciled Data Graph.

Фаза 2: Build (Построение Представления)

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

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

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

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

• Структурные факторы: Основной вход – это структурированные данные в формате графа (триплеты: субъект, предикат, объект).
• Метаданные источника: Информация о происхождении (provenance) каждого триплета и ограничения на использование/лицензии, связанные с источником.
• Идентификаторы: Локальные и глобальные идентификаторы сущностей и отношений.

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

Патент не описывает метрики ранжирования, но описывает метрики и правила для слияния данных и разрешения конфликтов:

• Доверие/Качество источника (Source Trust/Quality) (Неявно): При разрешении конфликтов система может предпочесть факты из более надежного или точного источника. Патент не уточняет, как именно определяется это доверие.
• Частота утверждения (Frequency of Assertion): При разрешении конфликтов система может выбрать факт, который встречается в наибольшем количестве источников. Это возможно благодаря отслеживанию происхождения данных при удалении дубликатов.
• Ограничения кардинальности (Cardinality Constraints): Правила, определяющие, сколько отношений может иметь сущность (например, только один рост, одна дата рождения). Используются для обнаружения конфликтов.

1. Двухфазное разделение процессов: Google отделяет нормализацию данных (Reconciliation) от построения финального графа (Build). Это обеспечивает эффективность (обрабатываются только измененные источники) и гибкость (можно создавать множество различных представлений графа).
2. Централизованное управление идентификаторами: Master Evidence File является главным авторитетом для глобальных ID. Он управляет слиянием сущностей и хранит полную историю всех присвоенных идентификаторов, что критически важно для стабильности системы.
3. Критичность происхождения данных (Provenance): Система тщательно отслеживает источник каждого факта (триплета). Когда дубликаты объединяются, информация об источниках также сливается. Это позволяет оценить достоверность факта.
4. Стратегия разрешения конфликтов: Конфликты (например, разные даты рождения) разрешаются на этапе построения графа. Патент явно указывает на использование количества источников, подтверждающих факт (консенсус), или достоверности (trustworthiness) источника (авторитет) в качестве критериев для выбора "правильного" факта.
5. Обратная совместимость и история: Система гарантирует, что старые глобальные ID продолжают работать даже после слияния сущностей и изменения основного ID, используя отношения типа "заменен на" (replaced by).

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

Хотя патент описывает внутреннюю инфраструктуру Google, он имеет важные последствия для стратегий оптимизации сущностей (Entity Optimization) и работы с Графом Знаний.

• Максимизация согласованности данных (Consistency): Google собирает и согласовывает данные из множества источников. Необходимо обеспечить максимальную согласованность данных о вашей сущности (Название, Адрес, Телефон, ключевые атрибуты) во всех внешних профилях (GBP, социальные сети, отраслевые каталоги, Wikipedia/Wikidata). Это облегчает процесс Reconciliation (Фаза 1) и снижает риск создания дубликатов сущностей.
• Присутствие в надежных источниках (Trust): Поскольку разрешение конфликтов может основываться на достоверности источника (авторитет), приоритетом является создание и поддержание точной информации в источниках с высоким авторитетом (например, Wikipedia, крупные отраслевые базы данных, официальные реестры).
• Наращивание подтверждений (Corroboration / Frequency of Assertion): Если Google сталкивается с конфликтующими фактами, он может выбрать тот, который подтверждается наибольшим количеством источников (консенсус). Убедитесь, что ключевые факты о вашем бренде/сущности широко подтверждаются на многих релевантных сайтах.
• Использование постоянных идентификаторов (Schema.org): Используйте schema.org/sameAs, чтобы связать вашу сущность с ее идентификаторами в основных базах данных (например, Wikidata ID, официальные государственные ID). Это действует аналогично Source Evidence File, явно указывая Google, как ваша локальная информация соотносится с известными глобальными идентификаторами.

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

• Несогласованные данные о бренде (NAP): Наличие разных адресов, названий или дат основания в интернете увеличивает нагрузку на Reconciliation Engine и создает риск того, что Google выберет неверную информацию во время разрешения конфликтов или разделит вашу сущность на несколько.
• Игнорирование внешних данных: Полагаться только на оптимизацию своего сайта. Граф Знаний явно строится из disparate inputs; внешние сигналы и структурированные данные из сторонних источников являются критически важными входными данными.
• Пренебрежение профилями на сторонних платформах: Игнорирование профилей на платформах вроде Wikidata, GBP или отраслевых баз данных означает, что у Google меньше надежных входных данных для согласования, что может ослабить присутствие сущности в Графе Знаний.

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

Патент подтверждает фундаментальную важность внешних структурированных данных для понимания мира Google. SEO-стратегия должна включать оптимизацию сущностей, которая выходит далеко за рамки собственного сайта. Патент подчеркивает, что понимание сущности Google – это слияние (fusion) множества источников. Управление этим слиянием путем предоставления согласованных, подтвержденных и явно связанных данных является ключевой задачей SEO. Также патент объясняет, как Google разрешает разногласия: по консенсусу (частота упоминаний) или по авторитету (доверие к источнику).

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

Сценарий: Разрешение конфликта даты основания компании.

1. Ситуация: Сайт компании и 5 низкокачественных каталогов утверждают, что она основана в 2010 году. Wikipedia, официальный государственный бизнес-реестр и 3 крупные новостные статьи утверждают, что она основана в 2008 году.
2. Процесс Google (Фаза 1): Google собирает все эти факты (триплеты) и сопоставляет различные упоминания компании с единым Глобальным ID.
3. Процесс Google (Фаза 2): Graph Building Engine объединяет данные и обнаруживает конфликт: отношение "дата основания" имеет два разных объекта (2010 и 2008).
4. Разрешение конфликта: Механизм применяет правила разрешения конфликтов.
   • Вариант А (Trust/Авторитет): Он определяет Wikipedia и госреестр как более надежные источники, чем каталоги. Он выбирает 2008 год.
   • Вариант Б (Frequency/Консенсус): Он подсчитывает утверждения. Если доверие к источникам считается равным, он может выбрать дату с большим числом утверждений.
5. Действия SEO: Выявить конфликт. Исправить информацию на сайте на 2008 год. Обновить каталоги, если возможно. Использовать schema.org/foundingDate с правильной датой (2008) и связать через sameAs с идентификатором в госреестре.