Как Google использует сущности, шаблоны и Knowledge Graph для уточнения смысла поисковых подсказок (Autocomplete)

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

Ambiguous Query Suggestion (Неоднозначная поисковая подсказка)

Подсказка, которая может относиться к нескольким различным сущностям (например, «Phoenix»). Определяется путем анализа результатов поиска по этой подсказке или запросом к базе знаний.

Annotated Query Suggestion (Аннотированная поисковая подсказка)

Поисковая подсказка, дополненная семантическим описанием для уточнения её значения (например, «britney spears - Singer»).

Document Centric Weighting (Документо-центричное взвешивание)

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

Entity (Сущность)

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

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

Категория, к которой принадлежит сущность (например, Singer, City, Movie). Определяет выбор шаблона для аннотации.

Query Suggestion Annotation Engine

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

Submission Query (Отправляемый запрос)

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

Template (Шаблон)

Предопределенная структура для генерации описания, основанная на типе сущности. Шаблон определяет фиксированные термины, переменные поля и их расположение (например, «US President #», «Movie [year]»).

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

Примечание: Пункты 1-25 патента US20160217181A1 отменены (canceled). Анализ основан на активных пунктах (Claims 26-45).

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

1. Система идентифицирует поисковые подсказки для запроса.
2. Определяется, что выбранная подсказка ассоциирована с конкретной entity.
3. Идентифицируется тип этой сущности (entity type).
4. Идентифицируется шаблон (template) для этого типа сущности. Шаблон определяет фиксированные термины, переменные поля и их позиционное отношение.
5. Определяется значение для переменного поля на основе свойств конкретной сущности.
6. Генерируется описание для подсказки на основе шаблона.
7. Описание добавляется к подсказке, формируя annotated query suggestion, которая предоставляется пользователю.

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

Claim 27 (Зависимый от 26): Детализирует действие при выборе пользователем аннотированной подсказки.

При выборе пользователем аннотированной подсказки система отправляет submission query. Этот запрос нацелен на конкретную сущность и включает по крайней мере один термин, который отсутствует как в самой подсказке, так и в добавленном описании.

Это критически важный механизм скрытого переписывания запроса (hidden query rewriting). Система использует выбор пользователя для отправки внутреннего, более точного запроса, который может содержать идентификаторы сущности или дополнительные уточняющие термины, невидимые пользователю.

Claim 28 (Зависимый от 26): Описывает обработку неоднозначности.

Система определяет, что подсказка также ассоциирована с дополнительной сущностью (additional entity). Для неё генерируется дополнительное описание, и формируется отдельная дополнительная аннотированная подсказка.

Это механизм disambiguation, позволяющий отображать несколько вариантов для одного текста подсказки (например, «Phoenix» как город и как группа).

Claim 31 и 32 (Зависимые): Описывают триггер и метод определения неоднозначности.

Генерация описания (Claim 31) может происходить в ответ на определение того, что подсказка является неоднозначной (ambiguous). Неоднозначность (Claim 32) определяется путем выполнения поиска по тексту подсказки и анализа результатов: если в результатах идентифицировано разнообразие сущностей, подсказка признается неоднозначной.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит сбор данных. Извлекаются сущности, определяются их типы (entity types) и свойства, которые сохраняются в базе знаний (Knowledge Graph). Также индексируются авторитетные ресурсы (например, Wikipedia, Freebase, упомянутые в патенте), которые используются для определения описаний и их весов (Document Centric Weighting).

QUNDERSTANDING – Понимание Запросов (Основной этап)
Это основной этап применения патента, конкретно в подсистеме генерации поисковых подсказок (Autocomplete).

1. Получение частичного запроса: Система получает ввод пользователя в реальном времени.
2. Генерация кандидатов: Query Suggestion Engine предлагает варианты завершения.
3. Анализ подсказок: Query Processing Engine анализирует кандидатов на предмет наличия сущностей и неоднозначности.
4. Генерация аннотаций: Query Suggestion Annotation Engine использует данные этапа INDEXING (типы, свойства, шаблоны, веса) для создания описаний.

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

• Частичный запрос пользователя.
• Список кандидатов в подсказки.
• Данные из Knowledge Graph (сущности, типы, свойства).
• Шаблоны для типов сущностей.
• Данные об авторитетных документах (для взвешивания описаний).

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

• Список аннотированных поисковых подсказок (Annotated Query Suggestions).
• (Скрыто) Потенциально переписанный submission query, который будет отправлен при выборе подсказки.

На что влияет

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

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

• Триггеры активации: Алгоритм активируется в реальном времени, когда система идентифицирует, что поисковая подсказка:
  1. Ссылается на известную сущность (entity).
  2. Является неоднозначной (ambiguous), т.е. может относиться к нескольким популярным сущностям.
• Исключения: В патенте упоминается, что очень популярные сущности (например, «Michael Jordan») могут не аннотироваться, так как предполагается, что пользователи их легко узнают и уточнение не требуется.

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

Этап 1: Получение и первичный анализ подсказок

1. Система получает частичный запрос от пользователя.
2. Генерируется список стандартных поисковых подсказок.
3. Каждая подсказка анализируется для определения необходимости аннотации.

Этап 2: Определение неоднозначности и идентификация сущностей

1. Для подсказки определяется, ссылается ли она на одну или несколько сущностей (используя Knowledge Graph или анализ результатов поиска по тексту подсказки).
2. Если результаты поиска содержат ссылки на несколько разных популярных сущностей, подсказка помечается как ambiguous.
3. Если подсказка ссылается преимущественно на одну сущность, она помечается как требующая аннотации (если не является сверхпопулярной).

Этап 3: Генерация описаний (Annotation Generation)

Для каждой подсказки (или каждой интерпретации неоднозначной подсказки) система ищет лучшее описание. Используется несколько методов:

Метод A: Применение шаблонов (Template-based Generation - Claim 26)

1. Определяется тип сущности (entity type).
2. Выбирается соответствующий шаблон (template) (например, для типа «Song» шаблон «[Artist] [year]»).
3. Система извлекает значения переменных полей (Artist, year) из свойств сущности в Knowledge Graph.
4. Генерируется описание по шаблону.

Метод B: Взвешивание описаний (Document Centric Weighting - Описано в патенте)

1. Идентифицируется начальная группа потенциальных описаний (например, из Knowledge Graph).
2. Анализируется авторитетный документ, связанный с сущностью (например, статья в Wikipedia).
3. Каждому описанию присваивается вес на основе его использования в документе (частота, расположение, оформление).
4. Выбирается описание с наибольшим весом.

Этап 4: Формирование и отображение выдачи

1. Система формирует финальный список аннотированных подсказок.
2. Если подсказка неоднозначна, создается несколько записей, по одной для каждой основной интерпретации (например, Phoenix – Arizona, Phoenix – Band).
3. Список ранжируется и отображается пользователю.

Этап 5: Обработка выбора пользователя

1. Пользователь выбирает аннотированную подсказку.
2. Система формирует и отправляет submission query. Согласно Claim 27, это может быть внутренний переписанный запрос, содержащий дополнительные термины или идентификаторы сущности, отсутствующие в отображаемом тексте.

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

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

• Пользовательские факторы: Частичный запрос, вводимый пользователем. Логи прошлых запросов (для генерации базовых подсказок и оценки популярности).
• Данные о Сущностях (Entity Data): Критически важные данные из Knowledge Graph.
  • Идентификаторы сущностей.
  • Типы сущностей (Entity Types).
  • Свойства и атрибуты сущностей (для заполнения шаблонов).
  • Алиасы (альтернативные названия).
• Контентные и Структурные факторы (из внешних ресурсов): Система анализирует авторитетные источники (упомянуты Wikipedia, Freebase). Текст и структура этих документов используются для определения неоднозначности (например, наличие Disambiguation page) и для расчета Document Centric Weighting.

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

• Ambiguity Score (Оценка неоднозначности): Метрика, определяющая, насколько сильно подсказка связана с разными сущностями. Рассчитывается на основе анализа разнообразия сущностей в топовых результатах поиска по этой подсказке или по данным Knowledge Graph.
• Entity Popularity (Популярность сущности): Оценка известности сущности. Используется для фильтрации (сверхпопулярные могут не аннотироваться) и для ранжирования вариантов при disambiguation.
• Document Centric Weighting (Вес описания): Метрика для выбора лучшего описания из кандидатов. Рассчитывается для авторитетного документа и учитывает:
  • Расположение: Насколько рано описание встречается в тексте.
  • Частота: Как часто описание используется.
  • Оформление (Decorations): Визуальное выделение термина.
  • TF-IDF: Упоминается как возможный дополнительный метод взвешивания.

1. Сущности как основа понимания запроса: Патент демонстрирует, что Google активно использует Entity Recognition уже на этапе ввода запроса. Система стремится как можно раньше связать ввод пользователя с конкретной сущностью в Knowledge Graph.
2. Борьба с неоднозначностью (Disambiguation): Устранение неоднозначности является ключевой задачей. Google предпочитает предложить пользователю явный выбор между разными интерпретациями (например, Phoenix как город или группа), чем заставлять его уточнять запрос вручную.
3. Использование шаблонов (Templates) и Типизация: Для обеспечения консистентности описаний Google использует предопределенные шаблоны, привязанные к типам сущностей (Entity Types). Это указывает на критическую важность наличия четкой типизации и полных данных о свойствах сущности в Knowledge Graph.
4. Важность авторитетных источников (Wikipedia): Механизм Document Centric Weighting показывает, как Google анализирует структуру контента в авторитетных источниках (таких как Wikipedia) для определения наиболее важных дескрипторов сущности.
5. Скрытое переписывание запроса (Hidden Query Rewriting): Критически важный вывод из Claim 27: выбор аннотированной подсказки может привести к отправке submission query, который отличается от того, что видит пользователь. Система может добавлять скрытые термины или идентификаторы для более точного таргетинга на выбранную сущность.

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

• Обеспечение распознавания сущности (Entity Recognition): Ключевая задача для брендов, продуктов и персон — гарантировать, что они распознаются Google как четкая сущность. Это включает работу над присутствием в Knowledge Graph, согласованное использование разметки Schema.org и построение авторитетности в сети.
• Управление типом сущности (Entity Type): Необходимо добиться корректной классификации вашей сущности. Правильный тип (например, Software Company, Musician, Local Business) определяет, какой шаблон будет использован для аннотации. Подкрепляйте тип через разметку и контент.
• Оптимизация авторитетных источников (Wikipedia Optimization): Так как Google использует авторитетные источники (в патенте явно упомянута Wikipedia) для расчета Document Centric Weighting, необходимо следить за тем, как ваша сущность описана там. Ключевые дескрипторы должны быть расположены в начале текста (например, в первом предложении).
• Полнота данных о сущности: Поскольку система использует шаблоны (Templates), заполняемые свойствами сущности (например, год выпуска, автор), важно обеспечить полноту этих данных в Knowledge Graph и на собственном сайте (через разметку).
• Управление неоднозначностью бренда: Если название бренда неоднозначно, активно работайте над тем, чтобы ваша интерпретация была достаточно авторитетной для отображения в подсказках. Обеспечьте, чтобы система могла легко отличить ваш бренд от других сущностей с тем же именем.

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

• Игнорирование Knowledge Graph и Schema.org: Рассчитывать только на текстовую оптимизацию без работы над представлением бренда как сущности. Это может привести к тому, что бренд не будет корректно идентифицирован и аннотирован в подсказках.
• Несогласованные данные о бренде: Предоставление противоречивой информации о типе сущности или её ключевых свойствах в разных источниках (сайт, соцсети, каталоги). Это затрудняет выбор корректного шаблона и описания.
• Манипуляции с описаниями в сторонних источниках: Агрессивное редактирование Wikipedia с целью искусственно повлиять на Document Centric Weighting может привести к санкциям на этих платформах и игнорированию правок со стороны Google.

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

Патент подтверждает стратегию Google «Things, not strings» (Сущности, а не строки). Понимание того, как Google идентифицирует, классифицирует и описывает сущности на самых ранних этапах поиска, критично для построения долгосрочной SEO-стратегии. Этот механизм влияет на формирование спроса и уточнение интентов. Для SEO это означает, что работа над Entity Optimization является фундаментальным требованием для видимости в поиске, начиная с поисковой строки.

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

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

Компания выпускает программное обеспечение под названием «Mercury». Это название неоднозначно (планета, химический элемент, автомобиль).

1. Задача: Обеспечить, чтобы при вводе «Merc» в подсказках появлялся вариант, относящийся к ПО.
2. Действия (Основанные на патенте):
   • Идентификация сущности: Создать четкую сущность для ПО «Mercury» (Schema.org/SoftwareApplication, присутствие в Knowledge Graph, статья в Wikipedia).
   • Определение типа и шаблона: Убедиться, что сущность классифицирована как ПО (Entity Type). Google может использовать шаблон типа «[Brand] software» или дескриптор «Software».
   • Оптимизация описания (Document Centric Weighting): В статье Wikipedia и на официальном сайте в первом абзаце должно быть четко указано: «Mercury is a software for...». Это повышает вес дескриптора «software».
3. Ожидаемый результат: При вводе «Merc» пользователь увидит:
   mercury — Planet
   mercury — Element
   mercury — Software ← Наша цель
4. Выбор пользователя: Когда пользователь выбирает «mercury — Software», Google (согласно Claim 27) может отправить внутренний submission query, нацеленный на сущность ПО (например, используя идентификатор сущности или добавив скрытые уточняющие термины), что гарантирует релевантную выдачу.