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

Google использует механизм для точной интерпретации запросов в специализированных доменах (медиа, товары, музыка). Система создает базу данных сущностей с оценками их популярности (Entity Scores). При получении запроса (текстового или голосового) система сопоставляет термины с этой базой, использует оценки популярности и контекст для разрешения неоднозначностей (через Feasibility Score) и формирует структурированный запрос.

Описание

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

Патент решает проблему неточной интерпретации сложных или неоднозначных запросов (как текстовых, так и голосовых) в специализированных поисковых доменах (Search Domains). Он устраняет недостатки подходов, основанных на простом совпадении ключевых слов, которые могут приводить к нерелевантным результатам (например, когда запрос «action movie with tom cruise» возвращает результаты, содержащие слова «action» и «cruise» по отдельности, но не связанные с жанром или актером). Изобретение улучшает понимание структуры запроса и повышает точность распознавания голосовых команд.

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

Запатентована система интерпретации запросов, которая использует предварительно созданную базу данных сущностей (Entity Table) для определенного домена (например, медиаконтент, продукты, музыка). Система сопоставляет термины запроса с сущностями в этой базе, учитывая их тип (Entity Type) и оценку популярности (Entity Score). Для разрешения неоднозначностей, особенно в голосовом поиске, вычисляется оценка правдоподобия (Feasibility Score) для различных интерпретаций, и выбирается наиболее вероятная.

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

Система работает в двух режимах:

Офлайн-подготовка: Создается Entity Table для конкретного домена путем извлечения метаданных из разных источников (включая данные о кликах пользователей). Каждой сущности присваивается тип и рассчитывается Entity Score (популярность).
Онлайн-обработка: При получении запроса он сегментируется (текст) или генерируются варианты распознавания (голос). Термины ищутся в Entity Table. Система разрешает конфликты с помощью Entity Scores и контекстуальной информации. Для голосовых запросов вычисляется Feasibility Score для каждого варианта, учитывая популярность найденных сущностей и штрафы за нераспознанные слова. В итоге формируется структурированный запрос (например, Жанр: Action, Актер: Tom Cruise) или выполняется команда.

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

Высокая. Патент описывает фундаментальные механизмы распознавания именованных сущностей (NER) и разрешения неоднозначностей, которые являются критически важными для современного семантического поиска, работы Knowledge Graph и голосовых ассистентов. Использование оценок популярности (Entity Score) для выбора правильной интерпретации запроса остается ключевым подходом в системах понимания запросов (Query Understanding).

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

Патент имеет высокое значение для SEO (85/100), особенно в вертикальном поиске. Он демонстрирует, что Google стремится структурировать запрос, идентифицируя сущности и их типы. Критически важным является понятие Entity Score (популярность/значимость сущности) — оно напрямую влияет на то, как Google интерпретирует запрос еще до начала ранжирования. Это подчеркивает важность построения авторитетности и известности бренда/сущности, а также использования структурированных данных в доменах E-commerce и медиа.

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

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

Action Command (Команда действия): Термин в запросе (обычно голосовом), указывающий на желаемое действие (например, «watch», «tune», «go to», «launch»).
Contextual Information (Контекстуальная информация): Информация, извлеченная из структуры запроса (порядок слов, соседние термины), используемая для разрешения неоднозначностей. Например, помогает определить, является ли «2012» названием фильма или датой выпуска.
Entity Name (Имя сущности): Идентификатор конкретной сущности в домене (например, «Tom Cruise», «CNN», «House»).
Entity Score (Оценка сущности): Числовая метрика, отражающая популярность или релевантность сущности в конкретном домене поиска. Может рассчитываться на основе рейтингов, частоты поиска, кликов пользователей. Может быть агрегированной (например, оценка актера как среднее оценок его фильмов).
Entity Table (Таблица сущностей): База данных, содержащая Entity Names, их Entity Types и Entity Scores для определенного Search Domain. Формируется офлайн.
Entity Type (Тип сущности): Категория, к которой принадлежит сущность (например, Actor Name, Movie Title, Genre, Product Category, Action Command).
Feasibility Score (Оценка правдоподобия): Метрика, рассчитываемая для вариантов распознавания голосового запроса (Voice Recognition Terms). Определяет вероятность правильной интерпретации. Базируется на Entity Scores найденных сущностей и может включать штрафы (Penalty Score) за нераспознанные термины.
Search Domain (Домен поиска): Специфическая область поиска или вертикаль (например, медиаконтент, поиск продуктов, поиск музыки).
Voice Recognition Term (Термин распознавания речи): Один из кандидатов текстовой интерпретации голосового запроса.

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

Публикация US20240311374A1 является патентом-продолжением, и ее Claims (Формула изобретения) фокусируются именно на интерпретации голосовых запросов.

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

Система получает голосовой запрос в определенном Search Domain.
Определяются как минимум два кандидата интерпретации (первый и второй Voice Recognition Term).
Определяется, что хотя бы часть первого кандидата соответствует Entity Name в этом домене.
На основе этой сущности вычисляется Feasibility Score для первого кандидата.
Кандидаты ранжируются на основе Feasibility Score.
Запрос выполняется с использованием кандидата, выбранного на основе ранжирования (т.е. того, у кого выше Feasibility Score).

Ядро изобретения — использование знания о сущностях домена и их значимости (через Feasibility Score) для выбора наилучшей интерпретации неоднозначного голосового ввода.

Claims 4-5 (Зависимые): Детализируют обработку команд действий.

Система определяет, соответствует ли первая часть голосового запроса Action Command Term. Сравнение происходит с сущностями в Entity Table, имеющими тип Action Command. Упоминается, что эта таблица может включать вручную курированную (curated) информацию.

Claims 6-9 (Зависимые): Описывают механизм действий по умолчанию (Default Action).

Если первая часть запроса не распознана как Action Command, система ассоциирует запрос с действием по умолчанию. Это действие может зависеть от Search Domain или от Entity Type распознанной сущности. Если распознано несколько сущностей разных типов, действие по умолчанию может определяться на основе сравнения их Entity Scores.

Claims 10-11 (Зависимые): Детализируют расчет Feasibility Score.

Расчет включает применение штрафа (penalty score). Штраф зависит от того, сколько терминов в кандидате интерпретации НЕ были распознаны как сущности в Entity Table. Также расчет может быть взвешенным средним (weighted average) оценок Entity Scores для терминов, которые были распознаны как сущности. Предпочтение отдается тем интерпретациям, которые максимально состоят из известных и популярных сущностей.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит предварительная работа (офлайн-процесс). Система собирает метаданные из различных источников, извлекает сущности, классифицирует их по типам и рассчитывает Entity Scores (популярность/значимость). Это включает анализ поведенческих данных (click log). Результаты сохраняются в Entity Table.

QUNDERSTANDING – Понимание Запросов
Это основная фаза применения патента. Система в реальном времени выполняет:

Сегментацию запроса (текстового) или генерацию кандидатов распознавания (голосового).
Распознавание именованных сущностей (NER) путем поиска в Entity Table.
Разрешение неоднозначностей (Disambiguation) с использованием Entity Scores и Contextual Information.
Ранжирование интерпретаций с помощью Feasibility Score (для голоса).
Идентификацию или назначение Action Commands.

RANKING – Ранжирование
Система напрямую не участвует в ранжировании документов, но определяет, как будет сформулирован запрос к системе ранжирования. Вместо поиска по ключевым словам система ранжирования получает структурированный запрос (например, поиск в поле Genre: Action, поиск в поле Actor: Tom Cruise).

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

Сырой запрос пользователя (текстовый или голосовой).
Entity Table, специфичная для домена.
Источники для офлайн-обработки: метаданные контента, логи кликов (click log), вручную курированные данные.

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

Набор интерпретированных сущностей (Interpreted Entity Results) с типами и оценками.
Структурированный поисковый запрос.
Выполненная команда (в случае голосового управления).

На что влияет

Специфические запросы: Наибольшее влияние на сложные запросы, содержащие несколько ограничений (например, «action movie with tom cruise»), и неоднозначные запросы. Критически важно для голосовых запросов.
Конкретные ниши или тематики: Механизм разработан для применения в четко определенных Search Domains с богатыми метаданными. Это сильно влияет на вертикали, такие как E-commerce (продукты, бренды, категории), Медиа (фильмы, актеры, жанры), Музыка и Книги.
Типы контента: Влияет на контент, который может быть четко структурирован и связан с сущностями в Entity Table.

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

Условия работы: Алгоритм применяется при обработке запросов в рамках поддерживаемого Search Domain, для которого существует Entity Table.
Триггеры активации: Активируется при получении любого запроса в соответствующем интерфейсе. Механизмы разрешения неоднозначностей (использование Feasibility Score или контекста) активируются, когда обнаруживается несколько возможных интерпретаций или несколько кандидатов распознавания речи.

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

Процесс А: Генерация Таблицы Сущностей (Офлайн)

Определение домена: Выбирается Search Domain (например, медиаконтент).
Сбор метаданных: Доступ к различным источникам (базы данных контента, логи кликов, вручную курированные данные).
Извлечение сущностей: Идентификация Entity Names и их Entity Types из метаданных.
Расчет оценок: Вычисление Entity Score (популярности) для каждой сущности. Может включать агрегацию (например, оценка актера на основе оценок его фильмов) и взвешивание (например, по свежести).
Генерация таблицы: Создание Entity Table, включающей имена, типы и оценки.
Обновление: Периодический повтор процесса для поддержания актуальности данных.

Процесс Б: Интерпретация Текстового Запроса (Онлайн)

Получение запроса: Пользователь вводит текстовый запрос.
Сегментация: Запрос разбивается на возможные поисковые термины (n-граммы).
Поиск сущностей: Поиск терминов в Entity Table.
Получение данных сущностей: Извлечение соответствующих Entity Types и Entity Scores.
Интерпретация и Разрешение неоднозначностей: Анализ найденных сущностей с использованием Entity Scores и Contextual Information.
- Удаление маловероятных сущностей (например, с низким счетом при наличии одноименной сущности с высоким счетом).
- Объединение/удаление перекрывающихся сущностей (например, предпочтение «Tom Cruise» перед «Tom»).
- Использование контекста для уточнения типа (например, позиция слова в запросе).
Структурирование поиска: Формирование структурированного запроса, где интерпретированные сущности применяются к соответствующим полям поиска.
Выполнение и отображение: Выполнение поиска и отображение результатов.

Процесс В: Интерпретация Голосового Запроса (Онлайн)

Получение голосового запроса.
Генерация кандидатов: Система распознавания речи генерирует несколько вариантов Voice Recognition Terms.
Идентификация команд (Опционально): Анализ первой части запроса на соответствие Action Command. Если команда не найдена, может быть назначена команда по умолчанию.
Поиск сущностей: Поиск кандидатов (или их частей) в Entity Table.
Расчет правдоподобия: Вычисление Feasibility Score для каждого кандидата на основе Entity Scores найденных сущностей и применения штрафов (penalty scores) за нераспознанные слова.
Ранжирование интерпретаций: Сортировка кандидатов по Feasibility Score.
Выполнение: Выбор наилучшего кандидата и выполнение соответствующего поиска или команды.

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

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

Система использует разнообразные данные, преимущественно для офлайн-построения Entity Table:

Структурные факторы (Метаданные): Метаданные, связанные с Search Domain (названия продуктов/фильмов, производители/актеры, категории/жанры, даты выпуска и т.д.).
Поведенческие факторы (User Click Information): Логи кликов (click log), включающие частоту запросов определенных сущностей и частоту выбора конкретных результатов. Используются для расчета популярности (Entity Score).
Временные факторы: Дата выпуска/публикации контента может использоваться для взвешивания при расчете Entity Score (предпочтение более свежему контенту).
Курированные данные (Manual Curation Information): Вручную созданные списки, такие как стоп-слова («with», «the»), игнорируемые символы, а также списки Action Commands («watch», «tune»).

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

Entity Score (Оценка сущности): Метрика популярности. Рассчитывается на основе критериев, таких как пользовательские рейтинги, частота поиска, количество доступов к контенту (из логов кликов).
- Агрегация: Entity Score может быть агрегированным. Например, оценка актера может быть средним оценок фильмов с его участием.
- Взвешивание: При агрегации могут применяться веса, например, на основе даты выпуска (более новые фильмы влияют сильнее).
Feasibility Score (Оценка правдоподобия): Метрика для ранжирования интерпретаций голосовых запросов.
- База расчета: Основывается на Entity Scores сущностей, найденных в интерпретации. Может быть средним или взвешенным средним этих оценок.
- Штрафы (Penalty Scores/Weights): Применяются штрафы, если часть терминов в интерпретации не распознана как сущности. Чем больше нераспознанных слов, тем ниже Feasibility Score.

Выводы

Приоритет сущностей над ключевыми словами: Патент подтверждает, что Google стремится интерпретировать запрос как набор структурированных сущностей и ограничений, а не как набор ключевых слов. Понимание того, к какому типу относится термин (актер, жанр, продукт), является ключевым для интерпретации.
Популярность (Entity Score) как фактор интерпретации: Entity Score (популярность или значимость сущности в домене) используется не для ранжирования результатов, а на более раннем этапе — для разрешения неоднозначностей и выбора правильной интерпретации запроса. Популярные сущности имеют преимущество.
Контекст и структура запроса критичны: Система использует Contextual Information (порядок слов, соседние термины) для определения роли сущности. Одно и то же слово может быть интерпретировано по-разному в зависимости от его окружения в запросе.
Голосовой поиск смещен в сторону известных сущностей: Механизм Feasibility Score явно отдает предпочтение тем вариантам распознавания речи, которые состоят из известных и популярных сущностей. Интерпретации с нераспознанными или непопулярными терминами штрафуются (Penalty Score).
Специализация по доменам: Эффективность механизма зависит от качества Entity Table для конкретного Search Domain. Это объясняет высокую точность поиска в развитых вертикалях (например, продукты, фильмы).
Важность поведенческих данных: Логи кликов и данные о поведении пользователей напрямую используются для определения популярности сущностей (Entity Score), что замыкает петлю обратной связи между поведением пользователей и интерпретацией запросов.

Практика

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

Повышение популярности и узнаваемости сущностей (Entity Score): Необходимо работать над повышением значимости ключевых сущностей сайта (бренда, продуктов, авторов). Поскольку Entity Score основан на поведенческих факторах (клики, поиски, рейтинги), стратегии по увеличению брендового трафика, улучшению CTR и стимулированию положительных отзывов напрямую влияют на то, как Google будет интерпретировать запросы, связанные с этими сущностями.
Использование четких и согласованных идентификаторов сущностей: Используйте точные и общепринятые названия для продуктов, категорий, брендов и других сущностей. Это увеличивает вероятность корректного сопоставления с Entity Table.
Внедрение релевантной микроразметки (Schema.org) и фидов: Предоставляйте поисковым системам структурированные метаданные, соответствующие вашему Search Domain (например, Product, Movie, фиды Google Merchant Center). Это помогает Google в процессе построения Entity Table и корректной идентификации Entity Types.
Оптимизация под голосовой поиск через популярные сущности: При оптимизации контента под голосовой поиск используйте естественные языковые конструкции, включающие популярные Entity Names и потенциальные Action Commands (например, «купить [Название популярного продукта]»).
Анализ интерпретации запросов в вашей нише: Изучайте, как Google интерпретирует неоднозначные запросы в вашей тематике. Если ваша сущность менее популярна, чем одноименная сущность другого типа, необходимо использовать дополнительный контекст в контенте и разметке для ее дифференциации.

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

Использование неоднозначных или общих названий для ключевых сущностей: Создание бренда или продукта с названием, которое конфликтует с очень популярной сущностью другого типа, затруднит его корректную интерпретацию системой из-за разницы в Entity Score.
Игнорирование структурированных данных: Отсутствие микроразметки или фидов в специализированных доменах (E-commerce, медиа) усложняет для Google задачу извлечения сущностей и определения их типов, снижая точность интерпретации запросов.
Фокус только на ключевых словах без учета их роли (Entity Type): Оптимизация под ключевое слово без понимания его роли в контексте запроса неэффективна, так как система ищет структурированные данные (например, оптимизация под «Action» как ключевое слово, когда система ищет его в поле «Genre»).

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

Этот патент подчеркивает стратегическую важность перехода к SEO, ориентированному на сущности (Entity-Oriented SEO), особенно в вертикальном поиске. Он показывает, что авторитетность и популярность (выраженные через Entity Score) влияют на самые ранние этапы обработки запроса (Query Understanding). Долгосрочная стратегия должна фокусироваться на построении сильных, узнаваемых сущностей. Также патент указывает на то, что в голосовом поиске преимущество имеют те, кто уже популярен.

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

Сценарий 1: Разрешение неоднозначности в E-commerce

Ситуация: Пользователь ищет «Apple» в домене поиска продуктов (E-commerce).
Применение патента: Система проверяет Entity Table для этого домена. Находит «Apple» (Тип: Brand/Manufacturer, Entity Score: Очень высокий) и «Apple» (Тип: Food/Fruit, Entity Score: Средний).
Результат: Из-за значительно более высокого Entity Score в контексте домена E-commerce, система интерпретирует запрос как поиск продуктов бренда Apple.
Действия SEO (для продавца фруктов): Необходимо активно использовать контекст («Fresh Apple», «Buy Apple Fruit») и соответствующую разметку (Schema.org/Food), чтобы помочь системе дифференцировать интент при более специфичных запросах.

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

Ситуация: Голосовой запрос «Заказать пиццу Пепперони». Система распознавания речи генерирует кандидатов: 1) «Заказать пиццу Пепперони», 2) «Заказать пиццу Папе Рони».
Применение патента: Система вычисляет Feasibility Score.
- Кандидат 1: Распознаны сущности: «Заказать» (Action), «пицца» (Product Type), «Пепперони» (Specific Product/Flavor). Entity Scores высокие.
- Кандидат 2: «Папе Рони» либо не распознано (применяется Penalty Score), либо имеет низкий Entity Score в этом домене.
Результат: Кандидат 1 получает более высокий Feasibility Score. Система выбирает его и выполняет структурированный поиск или заказ.
Действия SEO: Убедиться, что названия популярных продуктов четко указаны на сайте и в разметке Product.

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

Что такое Entity Score и как он влияет на интерпретацию запроса?

Entity Score — это метрика популярности или значимости сущности в конкретном домене. Она рассчитывается офлайн на основе метаданных и поведенческих сигналов (клики, рейтинги). При обработке запроса эта оценка критически важна для разрешения неоднозначностей. Если термин в запросе может относиться к нескольким сущностям, система с большей вероятностью выберет ту, у которой выше Entity Score.

Как SEO-специалист может повлиять на Entity Score?

Напрямую рассчитать Entity Score нельзя, но можно влиять на факторы, которые его формируют. Это включает повышение узнаваемости бренда или продукта, стимулирование брендовых запросов, улучшение поведенческих факторов (CTR в выдаче, вовлеченность на сайте), получение положительных отзывов и рейтингов. Все, что увеличивает популярность сущности в глазах пользователей, потенциально повышает ее Entity Score.

Что такое Feasibility Score и почему он важен для голосового поиска?

Feasibility Score — это оценка правдоподобия для вариантов распознавания голосового запроса. Голосовой ввод часто неоднозначен. Система рассчитывает этот балл, проверяя, насколько хорошо вариант распознавания состоит из известных и популярных сущностей (с высоким Entity Score). Варианты, содержащие много нераспознанных слов (штрафуются penalty score) или непопулярных сущностей, получают низкую оценку. Это означает, что голосовой поиск смещен в пользу уже известных и популярных брендов/продуктов.

Как система использует контекст (Contextual Information) для интерпретации запросов?

Система анализирует структуру запроса: порядок слов и соседние термины. Например, в запросе «action movie 2012», наличие слов «action movie» перед «2012» подсказывает системе, что «2012» скорее всего является датой выпуска (Release Date), а не названием фильма (Movie Title). Если бы запрос состоял только из «2012», интерпретация в пользу названия фильма была бы более вероятной.

Какова роль микроразметки и фидов данных в контексте этого патента?

Микроразметка и фиды играют ключевую роль в офлайн-процессе построения Entity Table. Предоставляя структурированные данные (например, через Schema.org или Google Merchant Center), вы помогаете Google извлекать метаданные, точно идентифицировать Entity Names и, что самое важное, корректно определять их Entity Types (например, что это продукт, а не статья). Это напрямую влияет на точность интерпретации запросов, связанных с вашим сайтом.

Применяется ли этот механизм в общем веб-поиске или только в специализированных вертикалях?

Патент описывает механизм для конкретных Search Domains (медиа, продукты, музыка, книги), где метаданные хорошо структурированы. Однако базовые принципы — идентификация сущностей, использование оценок популярности и контекста для разрешения неоднозначностей — являются фундаментальными и применяются в общем веб-поиске, используя Knowledge Graph в качестве глобальной Entity Table.

Что происходит, если система не распознает команду действия в голосовом запросе?

Если пользователь не произнес явную команду (например, сказал просто «CNN» вместо «Включи CNN»), система попытается назначить действие по умолчанию (Default Action). Это действие выбирается на основе Search Domain (например, если запрос сделан на телевизоре) или на основе Entity Type распознанной сущности (если «CNN» распознан как канал, действием будет включение канала).

Как обрабатываются перекрывающиеся сущности в текстовом запросе?

Система разрешает перекрытия, обычно отдавая предпочтение более длинной и полной сущности. Например, если в запросе есть «Tom Cruise», и система находит сущности как для «Tom», так и для «Tom Cruise», она, скорее всего, удалит или объединит «Tom» в пользу «Tom Cruise», чтобы избежать дублирования и повысить точность интерпретации.

Может ли Entity Score быть агрегированным?

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

Что такое «штрафы» (Penalty Scores) при интерпретации голосовых запросов?

Это механизм пессимизации интерпретаций голосового запроса, если они содержат слова, не распознанные как известные сущности в Entity Table. Чем больше нераспознанных слов, тем ниже итоговый Feasibility Score. Это заставляет систему предпочитать интерпретации, которые полностью состоят из известных сущностей и команд.