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

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

Known Item (Известный элемент)

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

Lookup Request (Запрос на поиск)

Запрос, направленный на нахождение Known Item. Содержит информацию о его атрибутах.

Estimated Value (Предполагаемое значение)

Значение атрибута, предоставленное в Lookup Request. Называется "предполагаемым", так как система допускает, что оно может содержать ошибки.

Attribute-Value Pair (Пара атрибут-значение)

Связь между свойством объекта (атрибутом, например, "Автор") и его значением (например, "Эйнштейн").

Query Type (Тип запроса)

Предопределенный шаблон запроса, основанный на конкретном атрибуте или комбинации атрибутов. Например, запрос только по DOI или запрос по комбинации Автор И Название.

Query Type Hierarchy (Иерархия типов запросов)

Структура, ранжирующая Query Types в порядке убывания их точности (precision) или способности уникально идентифицировать Known Item.

Candidate Item (Элемент-кандидат)

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

Consistency Criterion / Predefined Criteria (Критерий согласованности)

Правила, используемые для проверки (фильтрации) того, насколько атрибуты Candidate Item соответствуют Estimated Values из исходного запроса.

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

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

1. Получение Lookup Request с предполагаемыми значениями атрибутов.
2. Определение двух или более Estimated Attribute-Value Pairs.
3. Формулирование нескольких запросов на основе Predefined Query Types. Каждый запрос имеет позицию в Query Type Hierarchy.
4. Идентификация Candidate Items путем выполнения запросов в соответствии с этой иерархией.
5. Возврат хотя бы одного кандидата.

Ядро изобретения — использование множества запросов и иерархии их выполнения. Это обеспечивает устойчивость к ошибкам: если атрибут, используемый в точном запросе (высоко в иерархии), неверен, система переходит к менее точному запросу (ниже в иерархии), который может не включать ошибочный атрибут, и все равно находит объект.

Claim 6 (Зависимый от 1): Уточняет структуру иерархии.

Типы запросов позиционируются в Query Type Hierarchy в порядке убывания точности (decreasing precision) их способности уникально идентифицировать известные элементы.

Система предпочитает идентификацию по наиболее надежным и уникальным атрибутам. Запрос по уникальному идентификатору (DOI, GTIN, ISBN) будет находиться выше в иерархии, чем запрос по названию или автору.

Claim 12 (Зависимый от 11): Описывает процесс фильтрации (filtering) кандидатов после их идентификации.

1. Для каждого Candidate Item определяются его реальные пары атрибут-значение.
2. Проверяется, соответствуют ли эти пары предопределенным критериям (predefined criteria) относительно предполагаемых пар из запроса.
3. Если соответствуют, кандидат сохраняется. Если нет, кандидат удаляется.

Это механизм проверки согласованности (Consistency Check). Если кандидат найден по одному атрибуту (например, по названию), система валидирует его, проверяя, совпадают ли другие его атрибуты (например, автор, год) с тем, что было указано в исходном запросе.

Claim 16 (Зависимый от 1): Детализирует процесс иерархического выполнения запросов (Каскадный поиск).

1. Выполнение первого подмножества запросов (наиболее точных).
2. Проверка, привело ли выполнение к получению менее чем предопределенного количества кандидатов (predefined count).
3. Если кандидатов недостаточно, выполняется второе подмножество запросов, которые находятся ниже в иерархии (менее точные).

Система работает каскадно. Она пытается найти объект самым точным способом и прибегает к менее точным методам только в случае неудачи (failover).

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

Этот патент описывает специализированный сервис или модуль поиска (Known Item Lookup Module), который используется для идентификации и сверки сущностей (Entity Reconciliation). Он не является частью стандартного ранжирования веб-страниц, но критически важен для инфраструктуры Google.

CRAWLING и INDEXING – Сканирование и Индексирование
Crawler Module сканирует источники (сайты издательств, интернет-магазины). На этапе индексирования извлекаются атрибуты (метаданные) элементов, которые сохраняются в базе данных известных элементов (Database 114-a).

QUNDERSTANDING / Specialized Lookup Service
Основное применение патента. Known Item Lookup Module принимает запрос от клиента (которым может быть основной поисковый движок, Google Scholar, система обработки фидов Merchant Center или внешний сервис) и выполняет процесс идентификации сущности.

• Парсинг: Извлечение Estimated Attribute-Value Pairs из запроса (структурированного или неструктурированного).
• Выполнение запросов (Retrieval): Иерархическое и каскадное выполнение запросов к базе данных.
• Фильтрация (Validation): Применение Consistency Criteria для валидации кандидатов.

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

• Lookup Request (структурированный или неструктурированный текст).
• Предопределенная Query Type Hierarchy.
• База данных известных элементов.

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

• Идентифицированный Known Item (каноническая сущность).
• Метаданные идентифицированного элемента (например, корректная цитата, канонический URL, агрегированные данные).

На что влияет

• Конкретные типы контента: В первую очередь влияет на контент с четко определенными атрибутами: online publications (научные статьи, книги), товары онлайн-вендоров, изображения, аудиозаписи, мультимедиа объекты, записи баз данных.
• Специфические запросы: Влияет на запросы, целью которых является поиск конкретного объекта (Known Item Search).
• Конкретные ниши: Оказывает критическое влияние на функционирование Google Scholar (идентификация статей, агрегация цитирований) и Google Shopping (идентификация товаров, сопоставление предложений). Также важен для построения и верификации Knowledge Graph.

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

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

Триггеры активации:

• Обработка и верификация цитат для привязки к существующим записям в Google Scholar.
• Когда система обнаруживает новую копию или упоминание существующего объекта (например, товар у другого продавца) и должна связать ее с канонической сущностью (Entity Reconciliation).
• При поиске товара или публикации по комбинации названия и характеристик/метаданных.

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

1. Получение и Парсинг Запроса: Система получает Lookup Request. Он парсится для определения Estimated Attribute-Value Pairs. Парсинг может использовать предопределенную структурную информацию (теги) или автоматическое распознавание атрибутов из неструктурированного текста (например, анализ формата цитаты MLA).
2. Формулирование Запросов: На основе полученных атрибутов система формулирует множество запросов в соответствии с Predefined Query Types.
3. Иерархическое Выполнение (Каскад):
   1. Определение Первого Подмножества: Выбираются запросы с наивысшим приоритетом в Query Type Hierarchy (наиболее точные), для которых есть данные в запросе (например, запрос по DOI).
   2. Выполнение: Запросы выполняются к базе данных.
   3. Проверка Количества Кандидатов: Определяется, получено ли достаточное количество Candidate Items (сравнивается с predefined count).
   4. Итерация (Failover): Если кандидатов недостаточно, система переходит к следующему подмножеству запросов, расположенных ниже в иерархии (менее точных, например, запрос по Названию), и повторяет выполнение и проверку.
4. Фильтрация и Оценка Согласованности (Consistency Check):
   1. Сравнение Атрибутов: Для каждого Candidate Item его реальные атрибуты сравниваются со всеми Estimated Attribute-Value Pairs из исходного запроса.
   2. Применение Критериев: Определяется, удовлетворяет ли кандидат предопределенным критериям согласованности. Например, год публикации должен быть в пределах +/- 5 лет от указанного, или должно быть совпадение хотя бы одного автора.
   3. Отбор Финалистов: Кандидаты, не прошедшие проверку согласованности, удаляются.
5. Возврат Результата: Система возвращает оставшиеся кандидаты. Если один кандидат удовлетворяет критериям с высокой степенью уверенности (high degree of certainty), возвращается только он.

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

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

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

• Контентные/Структурные факторы (Метаданные): Система использует Estimated Values для атрибутов известного элемента. Для научных публикаций это: Автор (author attribute), Название (title attribute), Том (volume attribute), Выпуск (issue attribute), Страницы (page attribute), Дата публикации (publication date attribute).
• Технические факторы (Идентификаторы): Уникальный идентификатор (unique object identifier, например, DOI, ISBN). Для товаров или медиа используются соответствующие идентификаторы (GTIN, ISRC).
• Технические факторы (Локаторы): URL источника (Primary URL, Secondary URL) может использоваться для корреляции разных экземпляров одного и того же элемента, найденных в разных местах.

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

• Query Precision (Точность типа запроса): Метрика, используемая для построения Query Type Hierarchy. Определяет способность типа запроса уникально идентифицировать элемент. Подразумевается, что Точность(Идентификатор) > Точность(Название) > Точность(Автор+Дата).
• Predefined Count (Предопределенное количество): Пороговое значение количества кандидатов. Если результатов меньше этого порога, система активирует каскадный переход к менее точным запросам.
• Consistency Criteria / Predefined Criteria (Критерии согласованности): Правила для фильтрации кандидатов. Включают сравнение пар атрибут-значение. Могут использоваться гибкие пороги (например, допустимое расхождение в дате публикации, упомянутое в патенте как +/- 5 лет).
• Degree of Certainty (Степень уверенности): Метрика, определяющая вероятность того, что кандидат является искомым элементом. Если она превышает высокий порог, система может вернуть только этот результат.

1. Устойчивость к ошибкам является приоритетом при идентификации сущностей. Google разработал систему, которая предполагает наличие ошибок во входных данных (например, в цитатах, отзывах или описаниях товаров) и активно обходит их, не полагаясь на точное совпадение всех атрибутов.
2. Иерархия атрибутов для идентификации. Не все атрибуты имеют одинаковый вес. Уникальные идентификаторы (DOI, GTIN, ISBN) являются наиболее точными (high precision) и проверяются в первую очередь. Название, авторы/бренды и даты используются как вторичные идентификаторы.
3. Механизм множественных каскадных запросов. Для надежной идентификации система не использует один запрос с логикой "И". Вместо этого применяется каскад запросов (Query Type Hierarchy) с разными комбинациями атрибутов, что позволяет найти объект, даже если часть данных неверна.
4. Обязательная проверка согласованности (Consistency Check). Нахождение совпадения по одному атрибуту недостаточно. Система валидирует результат, сверяя остальные атрибуты кандидата с исходным запросом, используя гибкие критерии (predefined criteria).
5. Основа для Entity Reconciliation. Этот механизм лежит в основе способности Google связывать разные упоминания или копии одного и того же объекта, найденные в интернете. Это критически важно для построения Knowledge Graph и функционирования специализированных поисковых вертикалей (Scholar, Shopping).

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

• Приоритет уникальных идентификаторов: Всегда предоставлять точные и валидные уникальные идентификаторы (GTIN для товаров, ISBN для книг, DOI для научных работ) в микроразметке и на странице. Согласно патенту, это самый точный Query Type, который имеет наивысший приоритет в Query Type Hierarchy и обеспечивает быструю и точную идентификацию.
• Полное и точное заполнение метаданных (Schema.org): Для сущностей (Product, ScholarlyArticle и т.д.) необходимо максимально полно заполнять все доступные атрибуты в микроразметке. Чем полнее данные, тем больше типов запросов система сможет сгенерировать, что повышает надежность идентификации и валидации (Consistency Check).
• Обеспечение согласованности данных (Consistency): Обеспечивать согласованность ключевых атрибутов (Название, Автор/Бренд, Идентификаторы) при упоминании сущности в разных источниках (например, на сайте и в фидах Merchant Center). Это повышает Degree of Certainty при идентификации элемента.
• Для Академического SEO (Google Scholar): Обеспечивать высокую машиночитаемость метаданных статей. Это помогает корректно извлекать атрибуты, которые затем используются Known Item Lookup Module для верификации цитирований и агрегации показателей, даже если сторонние сайты цитируют вас с ошибками.

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

• Отсутствие уникальных идентификаторов: Полагаться только на название и описание товара или статьи при отсутствии стандартных идентификаторов. Это снижает точность идентификации и вынуждает систему использовать менее надежные Query Types, что может привести к ошибкам в сопоставлении.
• Манипуляции или противоречия в метаданных: Попытки выдать один объект за другой или предоставление противоречивых данных (например, разные GTIN для одного товара). Механизм Consistency Check предназначен для выявления таких несоответствий и отфильтрует объект, если его атрибуты противоречивы.
• Скудные структурированные данные: Использование минимального набора полей в Schema.org. Это ограничивает способность системы использовать различные Query Types для идентификации вашего контента.

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

Патент детально описывает инфраструктуру для Entity Reconciliation — процесса сверки и объединения разрозненных данных об одном и том же объекте. Это подтверждает стратегический фокус Google на точном понимании сущностей. Для SEO это означает, что критически важно обеспечить максимально точное, полное и стандартизированное описание ключевых сущностей сайта (товаров, статей, организаций), используя уникальные идентификаторы, чтобы гарантировать их корректное распознавание, каноникализацию и представление в поиске.

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

Сценарий: Идентификация товара в E-commerce с ошибкой в GTIN

1. Исходные данные (Lookup Request): Запрос на товар с атрибутами: Название: "Nikon COOLPIX L830", Бренд: "Nikon", GTIN: 123456789018 (ошибочный). Фактический GTIN товара: 123456789012.
2. Обработка системой:
   1. Запрос 1 (Высокий приоритет, Query Type: GTIN): Система выполняет поиск по GTIN 123456789018. Результатов нет (из-за ошибки).
   2. Fallback (Каскад): Система переходит к следующему уровню иерархии.
   3. Запрос 2 (Средний приоритет, Query Type: Brand + Title): Система выполняет поиск по {Brand: Nikon, Title: "Nikon COOLPIX L830"}.
   4. Результат Запроса 2: Находит Кандидата (товар с фактическим GTIN 123456789012).
   5. Фильтрация (Consistency Check): Система сравнивает атрибуты кандидата с исходным запросом. Бренд совпадает. Название совпадает. GTIN не совпадает, но остальные критерии выполнены с высокой уверенностью.
3. Результат: Система идентифицирует товар как искомый Known Item, несмотря на ошибку в предоставленном GTIN.