Как Google определяет и ранжирует самые важные факты о сущностях, анализируя поисковые запросы пользователей

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

Attribute (Атрибут)

Тип информации или факт о сущности, интересующий пользователя (например, «высота», «возраст», «население»).

Entity (Сущность)

Объект поискового запроса. Человек, место, вещь или идея.

Entity-descriptive portion (Часть, описывающая сущность)

Часть запроса, которая идентифицирует сущность (например, «new york» в запросе «new york weather»).

Entity-level count (Частота на уровне сущности)

Оценочное количество запросов, которые включают определенный суффикс и относятся к конкретной сущности.

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

Категория или класс, к которому принадлежит сущность (например, «Музыкант», «Город», «Здание»).

Factual Attribute (Фактический атрибут)

Атрибут, связанный с объективным, общепринятым фактом.

Notable Type / Dominant Entity Type (Значимый/Доминантный тип)

Основной или наиболее релевантный тип сущности, если у неё их несколько.

Partial Query Count (Частичная частота запроса)

Доля от общей частоты запроса, отнесенная к конкретной сущности, если запрос неоднозначен.

Query Data (Данные запросов)

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

Query-to-Entity Map (Карта соответствия запросов сущностям)

База данных, которая связывает запросы с сущностями и предоставляет вероятностные оценки (Probability Scores) этой связи.

Score (Оценка)

Итоговая оценка важности суффикса (атрибута) для конкретной сущности, рассчитанная на основе Entity-level count и Type-level count.

Suffix (Суффикс)

Часть запроса, которая указывает на желаемый атрибут сущности (например, «weather» в запросе «new york weather»). Может находиться до или после Entity-descriptive portion.

Type-level count (Частота на уровне типа)

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

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

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

1. Система идентифицирует запросы в Query Data.
2. В каждом запросе определяется Entity-descriptive portion и Suffix.
3. Определяется общая частота (Query Counts) для каждого запроса.
4. Для неоднозначных запросов общая частота распределяется между несколькими сущностями путем присвоения каждой сущности Partial Query Count (оценка того, сколько раз запрос относился именно к этой сущности).
5. На основе Partial Query Counts оценивается Entity-level count — сколько раз конкретный суффикс использовался с конкретной (первой) сущностью.
6. Определяется тип этой сущности.
7. Определяется Type-level count — сколько раз этот суффикс использовался с любой сущностью данного типа.
8. Суффиксу присваивается итоговая Score для первой сущности на основе комбинации Entity-level count и Type-level count.

Claim 4 (Зависимый от 3, который зависит от 2 и 1): Описывает применение результатов анализа для ответов на запросы.

1. Система получает пользовательский запрос (который может не содержать конкретный суффикс).
2. Определяется, что вероятность того, что запрос относится к первой сущности, превышает порог.
3. В ответ на это система получает доступ к данным, идентифицирующим Factual Attributes, которые были ранее обозначены как часто запрашиваемые факты об этой сущности (на основе высокого ранга соответствующих суффиксов).
4. Система предоставляет информацию об этих фактических атрибутах в ответ на запрос, даже если пользователь не запрашивал их явно.

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

Распределение Query Count между несколькими сущностями происходит путем получения Probability Score для каждой сущности, указывающего на вероятность того, что запрос относится именно к ней. Partial Query Counts назначаются на основе этих вероятностных оценок.

Claim 10 (Зависимый от 1): Детализирует механизм расчета итоговой оценки (шаг 8 из Claim 1).

Итоговая Score определяется как комбинация значения, основанного на Entity-level count, и значения, основанного на Type-level count, причем вклад последнего ограничен максимальным значением (константой).

Claim 15 (Зависимый от 14, который зависит от 1): Описывает использование доминантного типа.

Если сущность принадлежит к нескольким типам, определяется их ранг и выбирается доминантный тип (Dominant Entity Type). Итоговая Score рассчитывается на основе Entity-level count и Type-level count именно для этого доминантного типа.

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

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

INDEXING – Индексирование и извлечение признаков / QUNDERSTANDING – Понимание Запросов (Офлайн-процессы)
Основная часть работы алгоритма происходит здесь. Это не стандартное индексирование контента, а скорее индексирование и анализ поведения пользователей (логов запросов) для построения базы знаний о сущностях.

• Анализ логов: Система обрабатывает огромные массивы Query Data для извлечения паттернов.
• Идентификация сущностей и атрибутов: Построение и использование Query-to-Entity Map и классификация сущностей по типам (Type Map).
• Расчет метрик: Вычисление Entity-level counts и Type-level counts.
• Ранжирование атрибутов: Расчет итоговых Scores и определение наиболее важных атрибутов для каждой сущности.
• Хранение данных: Сохранение результатов анализа (ранжированных атрибутов) для последующего использования поисковой системой.

QUNDERSTANDING – Понимание Запросов (Онлайн)
Во время обработки запроса система должна определить, к какой сущности он относится.

• Система использует Query-to-Entity Map для определения вероятности того, что запрос относится к конкретной сущности.

METASEARCH – Метапоиск и Смешивание / RANKING – Ранжирование
На этапе формирования выдачи система использует предварительно рассчитанные данные о важных атрибутах.

• Если запрос с высокой вероятностью относится к сущности, система извлекает список её наиболее важных атрибутов (frequently requested facts).
• Эта информация используется для формирования специальных блоков выдачи (например, Knowledge Panel), которые смешиваются с органическими результатами.

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

• Query Data (логи запросов).
• Query-to-Entity Map (связи запросов и сущностей, вероятности).
• Type Map (типы сущностей).
• Входные данные от асессоров (для фильтрации фактических атрибутов).

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

• Ранжированный список атрибутов (суффиксов) для каждой сущности с итоговыми Scores.
• Набор атрибутов, обозначенных как frequently requested facts для сущностей.
• Информационные блоки (например, Knowledge Panel) в поисковой выдаче.

На что влияет

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

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

Офлайн-процесс (Анализ и Ранжирование Атрибутов):

• Применяется периодически для обработки накопленных логов запросов (например, за неделю, месяц, квартал).
• Триггер активации: Наличие новых Query Data.

Онлайн-процесс (Предоставление Фактов):

• Применяется в реальном времени при обработке пользовательского запроса.
• Триггер активации: Когда система определяет, что вероятность (likelihood) того, что запрос относится к конкретной сущности, превышает установленный порог (например, 60%, 70%, 80%).
• Условие применения: Для данной сущности должны быть предварительно определены frequently requested facts.

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

Процесс анализа логов запросов и ранжирования атрибутов.

1. Сбор и подготовка данных: Система получает доступ к Query Data (логам запросов).
2. Идентификация запросов и подсчет частоты: Определяются уникальные запросы и подсчитывается количество их повторений (Query Counts).
3. Разделение запросов: Каждый запрос обрабатывается для выделения Entity-descriptive portion (используя Query-to-Entity Map) и Suffix (оставшаяся часть запроса).
4. Анализ на уровне сущностей (Entity-Level Analysis):
   • Определение вероятностей: Для каждого запроса из Query-to-Entity Map извлекаются идентификаторы возможных сущностей и вероятностные оценки (Probability Scores) того, что запрос относится к ним.
   • Распределение частоты: Общая частота запроса (Query Count) распределяется между этими сущностями пропорционально вероятностям, формируя Partial Query Counts.
   • Расчет Entity-Level Count: Для каждой сущности суммируются Partial Query Counts для всех запросов, содержащих определенный суффикс.
5. Анализ на уровне типов (Type-Level Analysis):
   • Определение типов: Для каждой сущности определяются её типы (используя Type Map). Может быть выбран доминантный тип (Notable Type).
   • Расчет Type-Level Count: Для каждого типа суммируются Entity-level counts определенного суффикса по всем сущностям, принадлежащим к этому типу.
6. Фильтрация атрибутов:
   • Отбор кандидатов: Для каждого типа выбирается набор суффиксов с наивысшими Type-level counts (например, Топ-1000).
   • Оценка фактичности: Система получает входные данные от панели асессоров (human raters), которые оценивают, представляет ли суффикс запрос на объективный, общепринятый факт для данного типа сущности.
   • Применение фильтра: Суффиксы, не удовлетворяющие критериям фактичности (рейтинг ниже порога), удаляются.
7. Расчет оценок и ранжирование (Scoring & Ranking):
   • Расчет итоговой оценки (Score): Для каждой сущности и каждого прошедшего фильтрацию суффикса рассчитывается итоговая оценка путем линейной интерполяции Entity-level count и Type-level count. Вклад Type-level count масштабируется и ограничивается константой.
   • Ранжирование: Суффиксы ранжируются на основе итоговой оценки для каждой сущности.
8. Определение часто запрашиваемых фактов: Суффиксы, занявшие верхние позиции в ранжированном списке, сопоставляются с фактическими атрибутами (Factual Attributes), и эти атрибуты обозначаются как frequently requested facts для данной сущности.

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

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

• Поведенческие факторы: Логи запросов (Query Data) являются основным источником данных. Анализируется частота запросов (Query Counts) и состав запросов (термины).
• Системные данные (Knowledge Graph):
  • Query-to-Entity Map: Данные для распознавания сущностей в запросах и оценки вероятностей (Probability Scores).
  • Type Map: Данные о классификации сущностей по типам.
• Пользовательские факторы (Асессоры): Входные данные от human raters, используемые для оценки того, являются ли атрибуты объективными фактами.

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

• Entity-level count (C_e): Оценка частоты суффикса для сущности. Рассчитывается путем суммирования Partial Query Counts (Query Count * Probability Score) для данного суффикса и сущности.
• Type-level count (C_t): Оценка частоты суффикса для типа. Рассчитывается путем суммирования Entity-level counts (C_e) для данного суффикса по всем сущностям данного типа.
• Scaling Factor (a): Коэффициент масштабирования для Type-level count. Может рассчитываться на основе максимального Type-level count (C_MAX) для данного типа и константы (b).
  Формула: $a = min(1.0, b/C_{MAX})$
• Score (S_e): Итоговая оценка важности суффикса для сущности. Рассчитывается как линейная интерполяция C_e и C_t, с ограничением вклада C_t константой (b).
  Формула: $S_e = C_e + min(a \cdot C_t, b)$

1. Важность атрибутов определяется спросом пользователей: Патент демонстрирует, что Google определяет ключевые атрибуты сущности не на основе внутренней логики или мнения экспертов, а путем прямого анализа того, что ищут пользователи (анализ суффиксов в логах запросов).
2. Обработка неоднозначности сущностей: Система имеет сложный механизм для работы с омонимами (например, «Ягуар» как животное и как автомобиль). Частота запросов распределяется между сущностями на основе вероятностей (Probability Scores), что позволяет точно определить востребованность атрибутов для каждой из них.
3. Комбинирование данных сущности и типа (Сглаживание): Ключевым элементом является интерполяция данных конкретной сущности (Entity-level) и данных её типа (Type-level). Это позволяет системе определять важные атрибуты даже для «длинного хвоста» сущностей, по которым мало статистики. Если о маленьком городе мало ищут, система предположит, что пользователям интересны те же атрибуты, что и для всех городов (население, погода).
4. Ограничение влияния типа: Чтобы данные по типу не перекрывали специфику популярной сущности, вклад Type-level count в итоговую оценку математически ограничивается константой (b).
5. Фокус на фактах и роль асессоров: Система целенаправленно фильтрует результаты, оставляя только те атрибуты, которые представляют собой объективные факты. Для этого используются оценки асессоров, которые проверяют наиболее популярные атрибуты на фактичность.
6. Превентивное предоставление информации: Цель всего процесса — определить frequently requested facts, чтобы показывать их пользователю (например, в Knowledge Panel), даже если его запрос не содержал прямого указания на эти атрибуты.

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

• Исследование интентов для сущности и её типа: Необходимо анализировать, какие атрибуты пользователи ищут для вашей сущности (бренда, продукта, персоны) и для сущностей аналогичного типа. Это позволит понять, какие факты Google, скорее всего, сочтет наиболее важными (frequently requested facts).
• Создание контента под ключевые атрибуты: Обеспечьте наличие на сайте качественного, фактического контента, отвечающего на вопросы о ключевых атрибутах вашей сущности. Если анализ показывает, что пользователи часто ищут «[Ваш бренд] + отзывы» или «[Ваш продукт] + характеристики», убедитесь, что эта информация легко доступна и оптимизирована.
• Структурирование данных (Schema.org): Используйте микроразметку для четкого указания значений ключевых атрибутов. Это помогает поисковым системам извлекать факты для заполнения информационных панелей, которые формируются на основе механизма, описанного в патенте.
• Оптимизация под Entity SEO: Работайте над тем, чтобы ваша сущность была однозначно идентифицирована Google и корректно классифицирована по типу. Это гарантирует, что система будет использовать релевантные Type-level data при ранжировании ваших атрибутов.
• Мониторинг Knowledge Panel: Отслеживайте, какие атрибуты Google показывает в информационной панели для вашей сущности и сущностей конкурентов. Это прямое отражение работы данного алгоритма.

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

• Игнорирование типа сущности: Оптимизация сущности без учета её типа неэффективна. Система использует данные по типу для сглаживания, поэтому важно соответствовать общим паттернам пользовательского интереса в категории.
• Фокус на нефактических атрибутах: Продвижение субъективной или быстро устаревающей информации в качестве ключевых атрибутов менее эффективно, так как система фильтрует атрибуты, не являющиеся объективными фактами (с помощью асессоров).
• Предоставление противоречивой информации: Распространение разных значений для одного и того же фактического атрибута в разных источниках может затруднить его верификацию и попадание в Knowledge Panel.

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

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

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

Сценарий: Оптимизация представления нового жилого комплекса (Сущность типа «Здание»/«Жилой комплекс»)

1. Анализ спроса (Имитация работы алгоритма): SEO-специалист анализирует популярные суффиксы для других ЖК: «планировки», «цены», «срок сдачи», «застройщик», «адрес», «фото». Это аналог Type-level data.
2. Анализ текущего спроса: Специалист изучает запросы по названию нового ЖК. Например, пользователи чаще ищут «[Название ЖК] срок сдачи». Это аналог Entity-level data.
3. Определение приоритетов: Система Google скомбинирует эти данные. Даже если по новому ЖК мало запросов, атрибуты «планировки» и «цены» получат высокий Score за счет данных по типу. «Срок сдачи» получит высокий Score за счет прямых запросов.
4. Действия SEO: Убедиться, что на официальном сайте есть четкая, структурированная информация (в тексте и Schema.org) по этим ключевым атрибутам: точный срок сдачи, актуальные цены, доступные планировки.
5. Ожидаемый результат: При запросе «[Название ЖК]» Google с большей вероятностью сформирует информационную панель, включающую именно эти ключевые факты, так как они были идентифицированы как frequently requested facts.