Как Google трансформирует табличные данные (фиды, spreadsheets, HTML-таблицы) в структурированный Граф Знаний

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

Data Graph (Граф данных) / Knowledge Document (Документ знаний)

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

Document Entity (Сущность документа)

Узел в графе, представляющий реальный объект (человек, место, вещь). Имеет определенный тип сущности (Entity Type) и может быть связан с любым количеством других узлов.

Entity Type (Тип сущности)

Классификация сущности, определяющая допустимые для нее отношения и свойства (например, "Продукт", "Бренд").

Fact Template (Шаблон факта)

Шаблон на естественном языке, описывающий факт, представленный отношением (например, "[Продукт] произведен [Бренд]"). Генерируется на основе анализа заголовков.

Graph Building Engine (Движок построения графа)

Компонент, отвечающий за создание и модификацию графа данных на основе ввода данных и определений.

Property Entity (Сущность свойства)

Узел в графе, имеющий алфавитно-цифровой тип (текст, число, валюта). Представляет собой простой атрибут и связан только с одной Document Entity.

Public Data Graph / External Data Graph (Публичный / Внешний граф данных)

Внешний граф знаний, например, Freebase (упомянутый в патенте) или современный Google Knowledge Graph.

Reconciliation (Сверка)

Процесс сопоставления текстового значения свойства с существующей Document Entity (внутренней или внешней) для установления связи.

Subtype (Подтип)

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

Tabular Data (Табличные данные)

Данные в формате строк и столбцов (электронные таблицы, фиды данных, HTML-таблицы).

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

Claim 1 (Независимый пункт): Описывает основной механизм преобразования столбца свойств в НОВЫЙ тип сущности через табличный интерфейс.

1. Система хранит граф, где первые сущности (Тип 1) имеют алфавитно-цифровые свойства.
2. Данные отображаются в табличном формате (Сущности в Столбце 1, Свойства в Столбце 2).
3. Система получает указание (через выбор Столбца 2) определить для этого свойства новый тип сущности (Тип 2).
4. Система генерирует новые сущности (Тип 2) для каждого уникального значения в этом столбце.
5. Система создает маркированное отношение (labeled relationship) между исходными сущностями (Тип 1) и новыми сущностями (Тип 2). Метка основана на заголовке столбца.
6. Исходное алфавитно-цифровое свойство удаляется.

Это механизм структурирования: преобразование плоских атрибутов (например, текстовых названий цветов в фиде) в связанные узлы графа (сущности Цвета). Он трансформирует плоские данные (Продукт -> текст "Красный") в связанные данные (Сущность Продукт -> Сущность Цвет Красный).

Claim 6 (Зависимый от 1, описан в патенте): Описывает механизм связывания с СУЩЕСТВУЮЩИМ типом сущности (Сверка/Reconciliation).

1. Система получает указание, что свойство соответствует существующему типу сущности.
2. Система определяет, что значение свойства (текст) соответствует существующей сущности этого типа (Сверка).
3. Генерируется отношение между этими двумя сущностями.
4. Исходное свойство удаляется.

Это механизм сверки (Reconciliation). Он позволяет связывать данные внутри графа, сопоставляя текстовые строки с известными узлами.

Claim 21 (Независимый пункт): Описывает механизм связывания с ВНЕШНИМ графом данных (аналогично Claim 10).

1. Хранится первый (локальный) граф данных с сущностями, имеющими текстовые свойства.
2. Определяется, что свойство соответствует типу сущности из второго (внешнего) графа данных.
3. Значение свойства сопоставляется (matching/Reconciliation) с сущностью во внешнем графе.
4. Генерируется отношение в первом графе, связывающее локальную сущность с сущностью из внешнего графа.

Это ключевой механизм для интеграции локальных данных (например, продуктового фида) с глобальным Knowledge Graph (например, сверка бренда или категории продукта).

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

Изобретение затрагивает этапы приема и структурирования данных.

INDEXING – Индексирование и извлечение признаков
Это основной этап применения. Описанные механизмы используются для обработки структурированных и полуструктурированных данных:

• Прием данных (Data Ingestion): Обработка данных, предоставленных пользователями через фиды (например, Google Merchant Center, Manufacturer Center) или API.
• Извлечение данных (Data Extraction): Преобразование полуструктурированных данных, найденных в вебе (например, HTML-таблиц и списков), в формат графа.
• Построение и обогащение Knowledge Graph: Создание новых сущностей из извлеченных данных.
• Сверка сущностей (Entity Reconciliation): Связывание извлеченных или импортированных данных с существующими сущностями в Knowledge Graph (внешний граф, как описано в патенте).

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

• Взаимодействует с Graph Building Engine для выполнения трансформаций.
• Использует данные из Tabular Data (вход) и управляет Knowledge Document (выход).
• Взаимодействует с Public Graphs (Knowledge Graph) для сверки.

Входные данные: Tabular Data (Фиды, CSV, HTML-таблицы, Spreadsheets), существующие графы данных.

Выходные данные: Обогащенный граф данных (Knowledge Document) с типизированными сущностями, семантическими связями и ссылками на внешние графы.

На что влияет

• Конкретные типы контента: Наибольшее влияние оказывается на контент, представленный в виде таблиц (HTML-таблицы с характеристиками, ценами, сравнениями) и данных, передаваемых через фиды (продукты, вакансии, события).
• Структурирование данных: Влияет на глубину понимания Google информации, позволяя переходить от простых текстовых атрибутов к связанным сущностям.

Патент не содержит информации о влиянии на специфические запросы, форматы контента, ниши (YMYL), языковые или географические ограничения в контексте ранжирования.

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

• Триггеры активации:
  • При импорте или индексации табличных данных (загрузка фида, сканирование HTML-таблицы).
  • Когда система выполняет сверку (Reconciliation) текстовых строк с известными сущностями в Knowledge Graph.
  • При необходимости преобразовать алфавитно-цифровые свойства в семантически значимые сущности для лучшего понимания данных.

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

Патент описывает несколько ключевых процессов трансформации данных.

Процесс А: Начальный импорт и генерация графа

1. Получение данных: Прием Tabular Data (например, фида).
2. Идентификация сущности: Определение основного типа сущности и столбца-идентификатора (например, SKU продукта).
3. Генерация базовых сущностей: Создание Document Entity для каждой строки.
4. Генерация свойств: Создание Property Entities (текстовые/числовые значения) для остальных ячеек и связывание их с базовой сущностью. Заголовки столбцов используются как названия связей.
5. Генерация метаданных: Автоматическая генерация Fact Templates на основе семантического анализа заголовков.

Процесс Б: Преобразование свойства в НОВЫЙ тип сущности (Claim 1)

1. Инициализация: Определение, что столбец свойств должен быть преобразован в новый тип сущности.
2. Анализ уникальных значений: Идентификация всех уникальных значений в этом столбце.
3. Генерация новых сущностей: Создание новой Document Entity для каждого уникального значения.
4. Перелинковка: Замена связи с текстовым свойством на связь с новой Document Entity.
5. Очистка: Удаление исходных Property Entities.

Процесс В: Сверка с СУЩЕСТВУЮЩИМ/ВНЕШНИМ типом сущности (Reconciliation, Claim 21)

1. Инициализация: Определение, что столбец свойств соответствует существующему типу сущности (например, во внешнем Knowledge Graph).
2. Сопоставление (Matching): Для каждого значения свойства система ищет соответствующую сущность в целевом графе.
3. Связывание: Если совпадение найдено, создается связь между локальной сущностью и найденной сущностью.
4. (Опционально) Создание новой сущности: Если совпадение не найдено, может быть создана новая сущность этого типа.
5. Очистка: Исходное текстовое свойство удаляется.

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

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

Патент фокусируется на структурных факторах, используемых для построения графа.

• Контентные факторы: Значения ячеек в табличных данных (алфавитно-цифровые значения свойств).
• Структурные факторы: Организация данных в строки и столбцы. Заголовки столбцов критически важны для определения названий отношений и генерации Fact Templates. Имена таблиц/листов используются для начальных типов сущностей.
• Внешние данные: Сущности и их типы из внешних графов (Public Graphs, Knowledge Graph), используемые в процессе сверки (Reconciliation).
• Пользовательский ввод (NLP): Описания на естественном языке (natural language computation), используемые для определения вычислений и подтипов (если используется интерактивный UI).

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

Патент не описывает метрики ранжирования. Он описывает детерминированные методы структурирования данных:

• Сверка сущностей (Entity Reconciliation / Matching): Процесс поиска соответствия между текстовым значением свойства и идентификатором или именем существующей сущности (Процесс В). Это ключевой механизм для связывания данных.
• Идентификация уникальных значений: Используется для определения набора новых сущностей при создании нового типа (Процесс Б).
• Обработка естественного языка (NLP) / Семантический анализ: Упоминается для интерпретации вычислений и определений подтипов, заданных пользователем на естественном языке, а также для генерации Fact Templates из заголовков.

1. Фундаментальный механизм перехода от "Строк к Вещам": Патент детально описывает механику преобразования неструктурированных табличных данных в семантически богатый граф знаний. Это основа для понимания того, как Google обрабатывает фиды данных и извлекает информацию из HTML-таблиц.
2. Критическая важность Сверки (Reconciliation): Значительная часть патента посвящена механизмам сопоставления текстовых строк с существующими сущностями, как внутри документа, так и во внешних графах (Knowledge Graph). Это подчеркивает стратегическую важность консистентности данных и использования стандартных идентификаторов.
3. Автоматизация структурирования: Описанные алгоритмы (создание новых типов из уникальных значений, автоматическое связывание) показывают, как Google автоматизирует процесс построения графа из больших массивов полуструктурированных данных.
4. Использование существующей структуры как подсказки: Система использует структуру и лексику исходных данных (заголовки столбцов как названия отношений). Четкая и логичная структура исходных данных (фидов, таблиц) облегчает их корректную обработку.
5. Интеграция данных: Возможность связывания локальных данных с внешними графами позволяет системе обогащать понимание данных за счет контекста из публичных источников знаний.

Практическое применение в SEO

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

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

• Оптимизация фидов данных (Merchant Center, и т.д.): Механизмы сверки (Процесс В) подчеркивают важность чистых и консистентных данных в фидах.
  • Используйте стандартизированную терминологию для атрибутов (цвета, размеры, бренды), чтобы они могли быть точно сверены с известными сущностями в Knowledge Graph.
  • Обеспечьте наличие и консистентность уникальных идентификаторов (GTIN, MPN, внутренние ID).
• Использование семантических HTML-таблиц: Представляйте данные на сайте (характеристики, сравнения, цены) в виде корректных HTML-таблиц (<table>, <th>). Используйте четкие и однозначные заголовки столбцов, так как они используются для определения названий отношений (Relationships) и генерации Fact Templates.
• Стратегическое использование микроразметки (Schema.org): Патент показывает, как Google стремится связать данные с графом. Используйте Schema.org для явного определения сущностей и их связей.
  • Применяйте @id для четкой идентификации сущностей, облегчая процесс сверки.
  • Используйте sameAs для связи ваших локальных сущностей с устоявшимися сущностями во внешних графах (например, Wikidata), что соответствует механизму Claim 21 (связывание с внешним графом).
• Консистентность терминологии (Entity Consistency): Поддерживайте высокую консистентность при упоминании сущностей на всем сайте и во всех источниках данных. Это помогает движку сверки корректно идентифицировать, что разные упоминания относятся к одной и той же сущности.

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

• Неконсистентные значения атрибутов в фидах: Использование разных значений для одного и того же атрибута (например, разные написания бренда или цвета: "Синий", "Син.", "Темно-синий"). Это усложняет сверку (Процесс В) и может привести к созданию дубликатов (Процесс Б) или неправильной ассоциации сущностей.
• Отсутствие или дублирование идентификаторов: Предоставление фидов без уникальных идентификаторов затрудняет процесс построения графа и отслеживания сущностей.
• Использование сложной верстки вместо семантических таблиц: Представление табличных данных с помощью <div> или изображений мешает системам корректно извлекать и структурировать информацию согласно описанным механизмам.
• Неоднозначные заголовки таблиц: Использование нечетких заголовков может привести к неправильной интерпретации связей системой при генерации Fact Templates.

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

Патент подтверждает стратегический переход Google от анализа ключевых слов к пониманию сущностей и их взаимосвязей ("strings to things"). Он детализирует инфраструктуру, используемую для приема и трансформации сырых данных в Knowledge Graph. Для SEO это означает, что успех все больше зависит от способности предоставить данные в форме, которая легко извлекается, интерпретируется и сверяется (Reconciliation) с глобальным графом знаний. Стратегия должна фокусироваться на точности и полноте представления сущностей.

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

Сценарий: Оптимизация продуктового фида для корректной сверки брендов

1. Ситуация: В Google Merchant Center загружается продуктовый фид (Tabular Data) со столбцом Brand Name. В этом столбце встречаются значения "Nike", "Nikey" и "Найк".
2. Обработка Google (по патенту):
   • Google импортирует фид (Процесс А). Продукты становятся Document Entities, а название бренда — текстовым свойством (Property Entity).
   • Система запускает процесс сверки (Процесс В), пытаясь сопоставить эти текстовые значения с сущностями типа "Бренд" во внешнем Knowledge Graph.
   • "Nike" и, возможно, "Найк" успешно сопоставляются с официальной сущностью Nike.
   • "Nikey", скорее всего, не будет сопоставлен или будет ошибочно классифицирован как отдельный неизвестный бренд.
3. Действия SEO-специалиста: Проанализировать фид данных и провести нормализацию атрибутов. Заменить "Nikey" и "Найк" на стандартное написание "Nike".
4. Ожидаемый результат: Все продукты корректно ассоциируются с сущностью бренда Nike в системах Google. Это улучшает понимание ассортимента и повышает видимость продуктов в поиске по брендовым запросам.