Как Google использует декларативные шаблоны и анализ области видимости (Scope) для извлечения структурированных данных из HTML

Описание

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

Патент решает проблему сложности и трудоемкости разработки и поддержки кастомных парсеров (скрейперов) для извлечения данных из веб-страниц и других иерархических документов (HTML/XML). Традиционные методы требуют сложного кода для навигации по DOM-дереву. Кроме того, патент устраняет риск неточного извлечения данных, предотвращая ошибочное связывание элементов, которые находятся далеко друг от друга в структуре документа.

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

Запатентован фреймворк для создания управляемых шаблонами парсеров (Template-driven parser). Суть изобретения заключается в использовании декларативных шаблонов (declaratory template) для определения отношений типа «Субъект-Предикат-Объект» (S-P-O) с помощью спецификаций сопоставления с образцом (например, XPath). Критически важным является определение шаблона области видимости (scope pattern или QueryGroupDef), который гарантирует, что извлекаемые элементы находятся в структурной близости в DOM-дереве.

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

Система работает следующим образом:

• Определение шаблона: Разработчик создает декларативный шаблон (Parse Template).
• Определение области видимости (Scope): В шаблоне задается QueryGroupDef, который определяет конкретный контейнер в DOM-дереве (например, <div> или <tr>), ограничивающий поиск связанных элементов.
• Определение отношений: Задаются Relation Templates, указывающие, как найти Субъект, Предикат и Объект внутри этой области видимости с помощью XPath (или аналогов).
• Парсинг документа: Парсер обрабатывает HTML/XML, идентифицируя все блоки, соответствующие QueryGroupDef.
• Извлечение и Валидация: Внутри каждого блока парсер извлекает S-P-O пары, проверяя соответствие правилам кардинальности (Cardinality ONE/MANY) для обеспечения точности.

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

Высокая. Извлечение структурированных данных (Information Extraction) остается фундаментальной задачей для Google, необходимой для наполнения Knowledge Graph и понимания связей между сущностями. Хотя ML-методы развиваются, шаблонные методы (template-based extraction) критически важны для высокоточного парсинга сайтов с известной и стабильной структурой.

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

Патент имеет значительное влияние на SEO (7.5/10). Хотя он описывает инфраструктуру извлечения данных, а не ранжирование, он дает ключевое понимание того, как именно Google парсит HTML для извлечения сущностей и фактов. Понимание механизма QueryGroupDef (области видимости) подчеркивает критическую важность чистой, семантически структурированной HTML-верстки, где связанные элементы логически сгруппированы в DOM-дереве. Это напрямую влияет на точность данных, которые Google извлекает с сайта.

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

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

Annotations (Аннотации)

Дополнительные данные в формате {имя, значение}, прикрепленные к извлеченному отношению (S-P-O). Например, дата или рейтинг события.

Cardinality (Кардинальность)

Определение ожидаемого количества элементов (Субъекта, Объекта или Аннотации) в пределах одной области видимости. Значения: ONE (один или ноль) и MANY (много).

Declaratory template (Декларативный шаблон)

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

QueryGroupDef (Определение группы запросов / Шаблон области видимости)

Ключевой компонент, определяющий область видимости (scope pattern) в DOM-дереве (например, конкретный <div> или <tr>). Гарантирует, что Субъект и Объект извлекаются из структурно связанных частей документа.

Relation Template (Шаблон отношения)

Спецификация для извлечения S-P-O триплета. Определяет паттерны поиска для каждого элемента и их кардинальность.

S-P-O-[U] pairs (Пары С-П-О-[П])

Формат вывода парсера: Subject (Субъект), Predicate (Предикат), Object (Объект) и опционально Userdata или Annotations.

Template-driven parser (Управляемый шаблоном парсер)

Парсер, логика работы которого определяется декларативным шаблоном.

XPath

Язык запросов, используемый в патенте как основной механизм сопоставления с образцом (pattern matching specification) для выбора узлов из HTML/XML. Упоминаются альтернативы: cssQuery, XQL, xQuery.

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

Claim 1 (Независимый пункт): Описывает основной метод извлечения информации об отношениях из HTML/XML.

1. Система получает relationship template, который включает (A) декларативную спецификацию (определяющую Субъект и Объект и паттерны для их поиска) И (B) scope pattern (шаблон области видимости).
2. Scope pattern определяет, насколько близко Субъект и Объект должны находиться друг к другу в иерархическом документе, используя теги контейнеров.
3. Система применяет и паттерны поиска, и scope pattern для выбора и вывода пар Субъект-Объект.

Ядром изобретения является обязательное использование scope pattern для ограничения поиска и обеспечения точности извлекаемых связей.

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

Определяется дополнительный паттерн для поиска текста, связанного с Предикатом. Выводятся триплеты Субъект-Предикат-Объект.

Claim 4 (Зависимый от 3): Дополняет метод извлечением Аннотаций (Annotations).

Определяются дополнительные паттерны для поиска текста, связанного с Аннотациями. Выводятся отношения, дополненные Аннотациями.

Claim 6 (Зависимый от 4): Детализирует требования к области видимости.

Scope pattern используется для определения того, насколько близко Субъект, Объект и Аннотации должны находиться друг к другу.

Claim 7 (Зависимый от 6): Уточняет механизм работы scope pattern.

Scope pattern может ссылаться на несколько уровней вложенных тегов в иерархическом документе.

Claim 10 (Зависимый от 1): Вводит концепцию Кардинальности (Cardinality).

Спецификация включает правила кардинальности для Субъекта и Объекта, определяющие, ожидается ли элемент один раз (ONE) или много раз (MANY).

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

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

CRAWLING – Сканирование и Сбор данных
Система собирает сырые иерархические документы (HTML/XML).

INDEXING – Индексирование и извлечение признаков (Information Extraction)
Основной этап применения патента. После получения и рендеринга контента система парсинга (в патенте упоминается XPaFParserMaster) анализирует DOM-дерево.

1. Идентификация парсера: Система определяет, соответствует ли URL документа какому-либо известному шаблону парсера (используя url_regexp).
2. Применение шаблона: Если соответствие найдено, активируется соответствующий Template-driven parser.
3. Извлечение признаков (Feature Extraction): Парсер использует Parse Template для извлечения структурированных данных (S-P-O pairs). Эти данные являются признаками документа и сущностей, которые могут использоваться для наполнения баз знаний (например, Knowledge Graph).

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

• Иерархически структурированный документ (HTML/XML DOM).
• Декларативный шаблон (Parse Template), содержащий QueryGroupDefs и Relation Templates.
• URL документа.

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

• Списки отношений один-к-одному в формате S-P-O-[U] pairs (структурированные данные).

На что влияет

• Конкретные типы контента: Наибольшее влияние на контент с четкой или полу-четкой структурой: профили пользователей, списки, таблицы, каталоги товаров, страницы событий. Патент приводит примеры парсинга страниц Twitter.
• Структурные факторы: Влияет на то, как интерпретируется DOM-структура. Система полагается на HTML-теги, классы, идентификаторы и вложенность элементов для определения связей.
• Микроформаты и стандарты: Патент явно упоминает извлечение информации, специфицированной через XFN, FOAF. Пример в патенте использует микроформат vcard.

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

• Триггеры активации: Алгоритм активируется во время индексирования, когда URL обрабатываемого документа соответствует регулярному выражению (url_regexp), определенному в спецификации парсера (XPathParserDef).
• Условия работы: Применяется к документам, имеющим предсказуемую иерархическую структуру, которую можно описать с помощью шаблонов и XPath (или аналогов).

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

Процесс А: Генерация парсера (Офлайн)

1. Определение спецификации: Создается определение парсера (Parser definition), включающее QueryGroupDefs и Relation Templates.
2. Генерация кода: Спецификация обрабатывается генератором (например, Protocol buffer parser generator) для создания исполняемого кода Template-driven parser.

Процесс Б: Парсинг документа (Индексирование)

1. Получение документа и Выбор парсера: Система получает документ (HTML/XML). Управляющая система (XPaFParserMaster) проверяет URL на соответствие url_regexp известных парсеров и активирует нужный.
2. Идентификация областей видимости (Scope Identification): Парсер анализирует DOM-дерево и идентифицирует все сегменты, соответствующие шаблону области видимости (QueryGroupDef).
3. Итерация по областям видимости: Для каждой найденной области видимости система выполняет следующие шаги.
4. Выполнение запросов (Query Execution): Внутри текущей области видимости выполняются XPath запросы для поиска Субъекта, Объекта, Предиката и Аннотаций, как определено в Relation Template.
5. Постобработка (Extraction Regexp): Если определено регулярное выражение extraction_regexp, извлеченный текст дополнительно обрабатывается для очистки или выделения нужной части.
6. Валидация кардинальности (Cardinality Check): Система подсчитывает количество найденных элементов и проверяет их соответствие правилам Cardinality (ONE/MANY).
   • Например, если S=ONE и O=MANY, Субъект дублируется для каждого Объекта.
   • Если S=MANY и O=MANY, количество результатов должно совпадать.
7. Обработка ошибок: Если правила кардинальности нарушены (например, ожидается ONE, а найдено MANY), извлечение отношения для данной области видимости пропускается.
8. Эмиссия отношений (Relation Emission): Если валидация прошла успешно, система формирует и выводит структурированное отношение (S-P-O pair).

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

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

Система использует исключительно данные, присутствующие в структуре обрабатываемого документа и его URL.

• Структурные факторы (Критически важные): DOM-структура документа является основным источником данных. Система анализирует:
  • HTML/XML теги (<div>, <span>, <a>, <table>, <tr>).
  • Атрибуты тегов (class, id, href, src).
  • Вложенность элементов (иерархия), которая критична для определения области видимости (QueryGroupDef) и выполнения XPath запросов.
• Контентные факторы: Текстовое содержимое элементов и значения атрибутов, которые извлекаются в качестве значений S-P-O.
• Технические факторы: URL документа используется для определения того, какой шаблон парсинга следует применить (через url_regexp).

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

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

• Pattern Matching Specification: Основной механизм извлечения. Используется XPath, но упоминаются альтернативы (cssQuery, XQL, xQuery).
• QueryGroupDef (Шаблон области видимости): Определяет структурные границы (контейнер) в DOM, внутри которых должны быть найдены связанные элементы.
• Cardinality (Кардинальность): Правила валидации количества извлеченных элементов (ONE или MANY). Используется для контроля корректности парсинга.
• Регулярные выражения (Regex): Используются для фильтрации URL (url_regexp) и для постобработки извлеченных данных (extraction_regexp). В патенте упоминается использование библиотеки RE2.

Выводы

1. Google использует масштабируемую систему шаблонного парсинга: Патент описывает инфраструктуру, позволяющую Google эффективно извлекать структурированные данные с множества сайтов без написания сложного процедурного кода для каждого из них, используя декларативные шаблоны.
2. Точность через структурную близость (Scope): Ключевой инновацией является механизм QueryGroupDef (scope pattern). Это доказывает, что Google требует, чтобы связанные данные находились в структурной близости в DOM-дереве (в одном логическом контейнере), а не просто присутствовали на странице.
3. S-P-O как целевой формат для Knowledge Graph: Система ориентирована на извлечение данных в формате триплетов (Субъект-Предикат-Объект), что является стандартным форматом для хранения фактов в базах знаний, таких как Knowledge Graph.
4. Критическая зависимость от качества HTML/XML: Эффективность этого метода напрямую зависит от качества, согласованности и семантичности верстки. Сложная, непоследовательная или нелогичная структура DOM может препятствовать точному извлечению данных.
5. Важность стандартов и микроформатов: Патент явно упоминает использование стандартов (XFN, FOAF, vcard), что подтверждает важность использования устоявшихся схем разметки для облегчения парсинга, даже если система может работать и без них.

Практика

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

• Соблюдение структурной близости (DOM Proximity): Это ключевая практика. Убедитесь, что связанные элементы (например, название продукта, его цена и изображение; или имя автора и дата публикации) сгруппированы вместе в DOM-дереве внутри общего родительского контейнера (например, <article>, <li>, <div class=»card»>). Это соответствует требованиям QueryGroupDef.
• Использование чистой и семантичной HTML-структуры: Применяйте семантические теги по назначению (<table> для таблиц, <ul>/<ol> для списков). Это делает структуру предсказуемой для шаблонных парсеров.
• Консистентность шаблонов верстки: Поддерживайте абсолютно единый шаблон верстки (теги, классы, атрибуты) для однотипных страниц (например, всех карточек товаров или статей блога). Шаблонные парсеры эффективны только при стабильной структуре.
• Использование стандартных микроформатов и Schema.org: Внедряйте структурированную разметку. Патент явно упоминает парсинг vcard, XFN и FOAF. Использование стандартизированных атрибутов облегчает идентификацию и извлечение данных.
• Использование описательных и стабильных CSS-классов и ID: Применяйте осмысленные имена классов (например, class=»price») и избегайте динамических или обфусцированных классов, которые меняются при каждой сборке, так как это затрудняет создание стабильных XPath/CSS селекторов.

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

• Разделение связанных данных в DOM: Размещение связанных элементов далеко друг от друга в DOM-дереве (например, название товара в одном блоке, а цена в другом, без общего родительского контейнера). Это нарушает принцип области видимости (QueryGroupDef) и приведет к ошибкам извлечения.
• Использование несемантичной верстки для структуры («Divitis»): Использование <div> для всего или использование таблиц для верстки макета затрудняет определение реальных семантических связей между элементами.
• Непоследовательная верстка: Использование разных HTML-структур или классов для одних и тех же элементов на разных страницах сайта или даже в пределах одной страницы.
• Полагаться на визуальную близость вместо структурной: Использование CSS или JavaScript для визуального позиционирования элементов так, что визуальная близость на экране не соответствует структурной близости в DOM. Парсеры анализируют DOM.

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

Этот патент подтверждает стратегическую важность технического SEO и качества верстки в эпоху семантического поиска и сущностей. Он демонстрирует, что структура HTML является интерфейсом для передачи структурированных данных поисковой системе. Обеспечение легкой парсируемости сайта системами, подобными описанной в патенте, является необходимым условием для полноценного представления сущностей сайта в Knowledge Graph и SERP-фичах, даже если явная микроразметка (Schema.org) не используется.

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

Сценарий: Оптимизация страницы «Наша Команда» для извлечения данных

Плохая реализация (Сложно для парсинга):

Имена сотрудников в одном блоке, а их должности в другом, несвязанном блоке.

<div class="names">
  <p>Иван Иванов</p>
  <p>Петр Петров</p>
</div>
<div class="titles">
  <p>CEO</p>
  <p>CTO</p>
</div>

Проблема: Парсер не сможет точно сопоставить Ивана с CEO, так как нет общей области видимости (QueryGroupDef) для каждого человека. При попытке использовать кардинальность MANY-MANY система может ошибочно связать элементы или выдать ошибку.

Хорошая реализация (Оптимизировано для шаблонного парсинга):

Каждый сотрудник находится в своем контейнере.

<div class="team-list">
  <div class="person-card"> <!-- Scope для Человека 1 -->
    <span class="name">Иван Иванов</span>
    <span class="title">CEO</span>
  </div>
  <div class="person-card"> <!-- Scope для Человека 2 -->
    <span class="name">Петр Петров</span>
    <span class="title">CTO</span>
  </div>
</div>

Как это использует Google:

1. Google определяет QueryGroupDef (Scope) для поиска контейнеров: //div[@class=’person-card’].
2. Внутри каждого контейнера Google применяет Relation Template (Кардинальность ONE-ONE):
   • Subject: ./span[@class=’name’]
   • Predicate: «hasTitle» (литерал)
   • Object: ./span[@class=’title’]
3. Результат: Точное извлечение фактов: [Иван Иванов] [hasTitle] [CEO] и [Петр Петров] [hasTitle] [CTO].

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