Как Google определяет сущности как динамические «Кластеры Наблюдений» для управления конфликтующими данными и изменениями в реальном мире

Описание

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

Патент решает фундаментальную проблему управления данными о сущностях реального мира (например, бизнесах, местах), которые постоянно меняются (переезжают, сливаются, разделяются). Предыдущие системы полагались на фиксированные системные идентификаторы (system-generated identifiers). Это приводило к нестабильности: если бизнес переезжал, идентификатор мог измениться, что приводило к потере связанной информации (например, отзывов). Также патент решает проблему обработки конфликтующей, ненадежной или устаревшей информации, получаемой из множества источников, и устраняет ошибки при одновременном редактировании данных.

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

Запатентована инфраструктура управления сущностями, которая рассматривает любую информацию о сущности как неизменяемое «Наблюдение» (immutable observation). Сущность определяется не фиксированным идентификатором, а как динамический «Кластер Наблюдений» (Cluster of Observations). Каждое наблюдение содержит «Полезную нагрузку» (Payload – новый факт) и «Контекст» (Context – другие известные атрибуты). Система использует Context для сопоставления наблюдений с нужным кластером. «Система Суммаризации» (Summarization System) анализирует все наблюдения в кластере для определения текущего достоверного состояния сущности.

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

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

• Сбор Наблюдений: Информация от пользователей и поставщиков данных принимается как Observations. Каждое включает Payload (новая информация) и Context (описание сущности на момент наблюдения, например NAP).
• Неизменяемость: Наблюдения сохраняются в Observation Store и никогда не модифицируются.
• Кластеризация: Система использует Context для сопоставления нового наблюдения с существующим Cluster, который представляет сущность.
• Суммаризация: Summarization System анализирует все наблюдения в кластере (включая конфликтующие), разрешает противоречия, оценивает надежность источников и определяет «Предполагаемое текущее состояние» (inferred current state).
• Индексация: Текущее состояние хранится в Cluster Index и отображается пользователям.
• Рекластеризация: Система может разделять или объединять кластеры, если определяет, что реальные сущности изменились (слияние или разделение).

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

Критически высокая. Описанная архитектура является фундаментальной для работы Google Maps, Local Search и управления локальными сущностями в Knowledge Graph. Она объясняет, как Google справляется с огромным объемом противоречивых данных в реальном мире и обеспечивает целостность данных при изменениях (например, переезде бизнеса).

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

Патент имеет критическое значение (95/100), особенно для Local SEO и управления сущностями. Он напрямую обосновывает необходимость абсолютной согласованности данных NAP (Name, Address, Phone) в интернете. Эта согласованность формирует надежный Context, который позволяет Google корректно кластеризовать все Observations (цитаты, отзывы, ссылки, контент), связанные с бизнесом. Несогласованность может привести к фрагментации кластера и потере сигналов ранжирования.

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

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

Cluster Index (Индекс кластеров)

База данных, хранящая Summary Attribute-Value Pairs для каждого кластера. Это индекс текущего состояния всех известных сущностей.

Cluster of Observations (Кластер наблюдений)

Группа immutable observations, которые, по мнению системы, относятся к одной и той же сущности. В контексте патента это и есть определение самой сущности.

Context (Контекст)

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

Immutable Observation (Неизменяемое наблюдение)

Единица информации о сущности, которая после сохранения в системе никогда не модифицируется. Состоит из Context и Payload.

Inferred Current State (Предполагаемое текущее состояние)

Алгоритмически выведенное состояние сущности на данный момент времени. Результат работы Summarization System.

Observation Store (Хранилище наблюдений)

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

Payload (Полезная нагрузка)

Часть наблюдения, содержащая новую или обновленную информацию о сущности (например, новый номер телефона, отзыв пользователя).

Re-clustering (Рекластеризация)

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

Summarization System (Система суммаризации)

Компонент, который анализирует все наблюдения в кластере (включая устаревшие и конфликтующие) и определяет Inferred Current State.

Summary Attribute-Value Pairs (Сводные пары атрибут-значение)

Набор атрибутов, представляющий собой Inferred Current State сущности. Хранится в Cluster Index.

Trust Score (Оценка доверия)

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

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

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

1. Система поддерживает коллекцию кластеров immutable observations. Каждый кластер представляет сущность и имеет summary attribute-value pairs, которые описывают inferred current state этой сущности.
2. Получается новое наблюдение (new observation).
3. Выбирается соответствующий кластер.
4. Выполняется Суммаризация (Summarizing): обновление summary attribute-value pairs на основе как нового наблюдения, так и ранее существовавших наблюдений в кластере.
5. Обновленные сводные данные сохраняются, и пользовательский интерфейс обновляется.

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

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

1. Новое наблюдение содержит context attribute-value pairs (соответствующие текущему состоянию) и payload value (отличающееся от текущего состояния).
2. Выбор кластера основан на context.
3. Обновление сводных данных происходит, если система определяет, что payload value более точен (more accurate), чем текущее значение в сводке.

Claim 7 (Зависимый от 1): Определяет критерии для сопоставления наблюдения с кластером (Entity Reconciliation).

Выбор кластера основан на context нового наблюдения и сравнении его с summary attribute-value pairs кластера по как минимум двум из следующих критериев:

• Сравнение уличного адреса (street address).
• Определение географического расстояния (geographic distance) между геолокациями.
• Сравнение номера телефона (phone number).
• Определение расстояния редактирования (edit distance) между названиями (title).

Это техническое обоснование критической важности NAP и геолокации для идентификации локальных сущностей.

Claim 11 (Зависимый от 1): Касается процесса суммаризации и доверия.

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

Claims 12, 13, 14 (Зависимые от 1): Описывают механизмы Рекластеризации.

Система может динамически адаптироваться:

• Claim 12 (Разделение): Если система определяет, что один кластер представляет две разные сущности, она производит перекластеризацию в два отдельных кластера.
• Claim 13 (Слияние): Если система определяет, что два или более кластеров представляют одну сущность (дубликаты), она объединяет их в единый кластер.
• Claim 14 (Коррекция): Если наблюдения были некорректно сопоставлены с кластером, они перемещаются в правильный кластер.

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

Этот патент описывает инфраструктуру индексирования и управления данными для сущностей (Knowledge Graph Management), которая затрагивает несколько этапов поиска.

CRAWLING – Сканирование и Сбор данных
Система собирает Observations из различных источников: фиды от Data Providers, пользовательские правки (например, через Google Maps), отзывы, а также данные, извлеченные краулерами из веба (цитаты).

INDEXING – Индексирование и извлечение признаков
Основное применение патента. Entity Management System функционирует как специализированный индекс для сущностей.

1. Хранение: Полученные данные сохраняются как immutable observations в Observation Store.
2. Кластеризация (Entity Resolution): Новые наблюдения сопоставляются с существующими кластерами с использованием Context (NAP, Geo).
3. Суммаризация (Определение Истины): Summarization System запускается для вычисления inferred current state и обновления Cluster Index. Это процесс разрешения конфликтов и оценки надежности (Trust Score).
4. Рекластеризация: Система может перестраивать индекс, если сущности изменились (переезд, слияние).

RANKING / METASEARCH – Ранжирование и Метапоиск
Системы ранжирования (например, алгоритмы локального поиска) и Метапоиск (для формирования Knowledge Panel или блока локальной выдачи) используют данные из Cluster Index. Они полагаются на Summary Attribute-Value Pairs как на достоверное текущее состояние сущности.

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

• Observation, включающее Payload и Context (NAP, Геокоординаты, Spatial Cell ID).
• Метаданные о наблюдении: источник, время, оценка надежности источника (Trust Score).

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

• Summary Attribute-Value Pairs (текущее состояние сущности), сохраненные в Cluster Index.
• Сигналы для рекластеризации (слияние или разделение кластеров).

На что влияет

• Конкретные типы контента: В первую очередь влияет на сущности, имеющие географическое положение (Local Entities): бизнесы, организации, достопримечательности (Google Maps, Local Search, Google Business Profile).
• Конкретные ниши или тематики: Критически важно для всех локальных бизнесов (ритейл, услуги, рестораны и т.д.).

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

• Триггеры активации: Процесс активируется при получении любого нового Observation — будь то пользовательская правка в реальном времени, загрузка фида от поставщика данных или поступление данных от краулера.
• Частота применения: Постоянно. Процессы кластеризации и суммаризации происходят непрерывно по мере поступления новых данных.

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

Процесс А: Обработка нового наблюдения (Matching)

1. Получение и Сохранение: Система получает новое Observation (Payload + Context) и сохраняет его в Observation Store.
2. Генерация запроса: На основе Context формируется запрос для поиска в Cluster Index. Запрос может включать название, телефон, адрес и Spatial Cell ID.
3. Идентификация кандидатов: Система ищет кластеры, чьи Summary Attribute-Value Pairs соответствуют запросу.
4. Оценка (Scoring) и Фильтрация: Для каждого кандидата рассчитывается оценка схожести (score) между Context наблюдения и сводными данными кластера. Оценка учитывает совпадение телефона, адреса, географическое расстояние и расстояние редактирования названий (Claim 7). Кластеры с недостаточной схожестью отфильтровываются.
5. Ассоциация: Наблюдение ассоциируется с кластером, набравшим наивысший балл (если он превышает порог). Если подходящий кластер не найден, может быть создан новый.

Процесс Б: Обновление состояния сущности (Summarization)

1. Активация: После ассоциации наблюдения с кластером, кластер отправляется в Summarization System.
2. Анализ наблюдений: Система анализирует все immutable observations в кластере, включая только что добавленное.
3. Разрешение конфликтов и Оценка надежности: Система взвешивает конфликтующие данные, учитывая метаданные, такие как Trust Score источника (Claim 11) и время наблюдения.
4. Определение текущего состояния: Система вычисляет inferred current state.
5. Обновление индекса: Cluster Index обновляется новыми Summary Attribute-Value Pairs.
6. Инициация Рекластеризации (Опционально): Если система суммаризации обнаруживает, что структура кластеров некорректна, она инициирует перекластеризацию (Claims 12-14).

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

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

Система использует конкретные атрибуты сущности для идентификации (Кластеризация) и оценки надежности (Суммаризация).

• Контентные факторы: Название сущности (Title). Категории бизнеса.
• Географические факторы:
  • Адрес (Street Address).
  • Географическое положение (Geographic Location), например, координаты.
  • Spatial Cell ID (идентификатор пространственной ячейки).
• Контактные данные: Номер телефона (Phone Number), Домашняя страница (Homepage).
• Пользовательские факторы (UGC и Доверие):
  • Отзывы (Reviews) и Рейтинги (Ratings).
  • Источник наблюдения (пользователь или поставщик данных).
  • Оценки доверия (Trust Score) источника (Claim 11).
• Временные факторы: Метка времени (timestamp) получения наблюдения.

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

Метрики Кластеризации (Сопоставление Context и Cluster):

• Geographic Distance (Географическое расстояние): Расстояние между геолокацией в Context и геолокацией кластера. В патенте упоминаются пороговые значения (например, 1000 м или 200 м).
• Edit Distance (Расстояние редактирования): Метрика схожести между названием в Context и названием кластера. Используется для учета опечаток или вариаций.
• Attribute Matching (Совпадение атрибутов): Прямое сравнение значений атрибутов (адрес, телефон).
• Matching Score: Агрегированная оценка, основанная на комбинации вышеуказанных метрик для выбора наилучшего кластера.

Метрики Суммаризации (Определение текущего состояния):

• Trust Score (Оценка доверия): Используется для взвешивания наблюдений при разрешении конфликтов. Наблюдения от источников с высоким Trust Score имеют приоритет.

Выводы

1. Сущности — это динамические Кластеры, а не статические записи: Патент подтверждает, что Google не использует традиционную базу данных с фиксированными ID для сущностей. Сущность определяется как Cluster of immutable observations. Это позволяет системе адаптироваться к изменениям в реальном мире (переезды, слияния).
2. Неизменяемость данных (Google ничего не забывает): Все полученные данные (Observations) сохраняются навсегда, даже если они неверны или устарели. Они могут не отображаться в текущем состоянии, но остаются в системе и могут быть переоценены.
3. Контекст (NAP+Geo) является ключом к идентификации: Система использует Context — комбинацию Названия, Адреса, Телефона и Геолокации — для сопоставления новой информации с правильной сущностью (Claim 7). Согласованность этих данных критически важна.
4. «Истина» вычисляется динамически (Суммаризация): То, что пользователи видят (Summary Attribute-Value Pairs), является результатом работы Summarization System. Эта система постоянно вычисляет inferred current state, взвешивая все доступные наблюдения и разрешая конфликты.
5. Надежность источника влияет на Суммаризацию: Trust Score источника используется для определения текущего состояния (Claim 11). Данные из авторитетных источников имеют больший вес при разрешении конфликтов.
6. Механизмы самокоррекции (Рекластеризация): Система способна исправлять ошибки индексации, объединяя дубликаты или разделяя смешанные сущности через процесс Re-clustering (Claims 12-14).

Практика

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

• Обеспечение абсолютной согласованности NAP+Geo: Это самая важная рекомендация. Название, Адрес, Телефон и Геокоординаты должны быть идентичными во всех источниках (сайт, Google Business Profile (GBP), каталоги). Эта согласованность формирует надежный Context, гарантируя, что все Observations будут корректно сгруппированы в один кластер.
• Активное управление цитатами (Citations Management): Регулярный мониторинг и исправление неверных данных на сторонних площадках критически важны. Каждая неверная цитата — это Observation с неправильным контекстом, который может загрязнять кластер или способствовать его фрагментации.
• Повышение авторитетности источников данных: Так как Summarization System учитывает Trust Score источников, важно размещать информацию в авторитетных отраслевых и локальных каталогах, которые Google считает доверенными Data Providers.
• Четкое сигнализирование об изменениях (Переезд/Ребрендинг): При изменении NAP необходимо быстро обновить информацию во всех ключевых источниках, начиная с GBP. Это позволяет Summarization System быстро определить новое inferred current state и минимизировать риск некорректной рекластеризации (например, потери отзывов).
• Стимулирование генерации «Наблюдений» (UGC): Необходимо стимулировать отзывы пользователей, загрузку фотографий. Чем больше качественных наблюдений связано с кластером, тем лучше система понимает сущность и тем стабильнее ее представление.

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

• Несогласованность NAP (например, Коллтрекинг в каталогах): Использование разных номеров телефонов или вариантов написания названия создает риск фрагментации сущности. Система может решить, что это разные бизнесы, и создать отдельные кластеры.
• Игнорирование пользовательских правок и отзывов: Пользовательские данные являются важными Observations. Игнорирование предложенных правок может привести к тому, что Summarization System примет нежелательные данные как текущее состояние, если источник правки имеет высокий Trust Score (например, Local Guide).
• Попытки «сбежать» от негативных отзывов путем создания новой сущности: Поскольку система использует Re-clustering для слияния дубликатов (Claim 13), она, скорее всего, объединит новый профиль со старым кластером, если контекст останется схожим, восстановив негативные отзывы.

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

Этот патент является основополагающим для Local SEO и Knowledge Graph. Он демонстрирует, что управление локальной сущностью — это непрерывный процесс управления тем, как Google собирает и кластеризует информацию. Стратегия должна фокусироваться на согласованности, полноте и авторитетности данных во всей экосистеме, чтобы гарантировать формирование единого, сильного и точного кластера для сущности.

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

Сценарий 1: Обеспечение переноса отзывов при переезде бизнеса

1. Ситуация: Ресторан переезжает в новое здание на той же улице.
2. Действия по патенту: Необходимо убедиться, что Context остается максимально стабильным, в то время как Payload (адрес) меняется.
   • Обновить адрес в GBP, используя функцию переезда. Это создает авторитетное Observation с контекстом (стабильное название, телефон) и пейлоадом (новый адрес).
   • Одновременно обновить адрес на сайте и в ключевых каталогах.
3. Ожидаемый результат: Summarization System видит авторитетные наблюдения об изменении адреса. Благодаря стабильному контексту, она продолжает ассоциировать существующие наблюдения (отзывы) с тем же кластером. Summary Attribute-Value Pairs обновляются новым адресом без потери истории.

Сценарий 2: Борьба с фрагментацией сущности из-за неконсистентного NAP (Коллтрекинг)

1. Ситуация: У бизнеса есть два разных номера телефона в разных каталогах (из-за коллтрекинга). Google иногда показывает дубликаты на Картах.
2. Действия по патенту: Проблема в том, что Observations с разными контекстами могут формировать разные кластеры.
   • Провести полный аудит цитат.
   • Исправить данные во всех источниках, приведя их к единому стандарту NAP (убрать коллтрекинг).
   • Найти и объединить дубликаты в Google Maps (через правки или поддержку GBP).
3. Ожидаемый результат: По мере того как Google получает новые Observations с согласованным Context, система сможет объединить фрагментированные кластеры (Re-clustering, Claim 13) в один. Summarization System определит единый правильный номер телефона как inferred current state.

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