Как Google анализирует видимый контент на экране пользователя для предоставления контекстной информации без ввода запроса (Contextual Search)

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

Active Resource (Активный ресурс)

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

Contextual Card / Contextual User Interface Element (Контекстная карточка / Контекстный элемент пользовательского интерфейса)

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

Document Object Model (DOM) (Объектная модель документа)

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

Item Identification Engine (Механизм идентификации элементов)

Компонент сервера, который извлекает текст из представления ресурса (через OCR или парсинг DOM) и идентифицирует Search Items.

Item Knowledge Graph (Граф знаний элементов)

База знаний (аналог Google Knowledge Graph), используемая для идентификации сущностей (Search Items) и хранения информации о них.

Query-Independent Request (Запрос, не зависящий от ввода ключевых слов)

Запрос контекстной информации, инициированный пользователем без ввода текстовых или голосовых поисковых терминов (query parameters).

Relevance Score (Оценка релевантности)

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

Search Item (Поисковый элемент / Сущность)

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

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

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

1. Система получает Query-Independent Request для Active Resource, отображаемого в приложении на переднем плане.
2. Идентификация Search Items. Ключевое ограничение: анализ проводится путем выбора только той части контента, которая в данный момент отображается на дисплее (first portion).
3. Определение типа активного ресурса (например, текстовый чат или веб-страница).
4. Определение Relevance Score для каждого элемента на основе (i) определенного типа ресурса и (ii) местоположения (location) текста на дисплее.
5. Критическая инновация: Оценки релевантности для текста в определенных местах выше, чем в других, и эти приоритетные места различаются в зависимости от типа ресурса.
6. Выбор элементов на основе оценок и предоставление Contextual User Interface Elements.

Claim 2, 3 и 4 (Зависимые): Детализируют методы извлечения контента.

• (Claim 2): Извлечение текста путем получения скриншота и применения обработки изображений (например, OCR).
• (Claim 3 и 4): Извлечение текста путем получения представления данных (например, DOM) и его парсинга.

Claim 5 и 6 (Зависимые): Детализируют расчет Relevance Score.

• Оценка релевантности основывается на внешнем виде (appearance) контента (Claim 5), в частности, на размере, цвете или позиции текста (Claim 6).

Claim 18 (Зависимый от 1): Конкретизирует расчет Relevance Score для типа ресурса «текстовый чат» (textual conversation).

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

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

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

INDEXING – Индексирование и извлечение признаков
Система полагается на предварительно созданный Item Knowledge Graph. Процессы индексирования, наполняющие Граф Знаний, критически важны для способности системы распознавать сущности и предоставлять информацию о них.

QUNDERSTANDING – Понимание Запросов (Интерпретация Контекста)
Основное применение патента. Вместо анализа введенного запроса, система интерпретирует визуальный контекст экрана как имплицитный (неявный) запрос. Это включает парсинг DOM или анализ скриншота для понимания визуальной структуры, а также извлечение сущностей с помощью Item Identification Engine.

RANKING – Ранжирование (Сущностей)
Система ранжирует идентифицированные Search Items. Relevance Scoring Engine вычисляет Relevance Score, используя сигналы визуальной значимости (размер, цвет) и расположения, причем логика ранжирования адаптируется под тип ресурса.

METASEARCH – Метапоиск и Смешивание
Contextual Card Provider генерирует финальный результат — Contextual Cards. Он агрегирует информацию из Item Knowledge Graph и определяет доступные действия (Apps, Navigation, Call).

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

• Query-Independent Request.
• Данные об активном ресурсе: Скриншот ИЛИ представление данных (DOM) видимой части экрана.
• Дополнительная информация: Тип ресурса, местоположение устройства, URL (если доступен), идентификатор пользователя (для персонализации).

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

• Один или несколько Contextual User Interface Elements (карточек).

На что влияет

• Конкретные типы контента: Влияет на любой контент, отображаемый на устройстве: веб-страницы, электронные письма, текстовые чаты (textual conversations), интерфейсы приложений.
• Визуальный дизайн и верстка (UX): Патент прямо указывает, что визуальное представление (размер, цвет, форматирование) и расположение контента (позиция на экране) используются для определения важности сущностей.
• Структура DOM: Чистота и семантика DOM влияют на способность системы точно извлекать текст и его визуальные атрибуты.
• Сущности (Entities): Система ориентирована на контент, содержащий распознаваемые сущности, присутствующие в Item Knowledge Graph.

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

• Триггеры активации: Алгоритм активируется только по явному действию пользователя (например, долгое нажатие кнопки, определенный жест, обведение элемента на экране).
• Условия применения: Применяется только к контенту, который в данный момент виден на экране (foreground application) и только к видимой его части (Claim 1).

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

Этап 1: Запрос и сбор данных

1. Обнаружение намерения: Клиентский модуль на устройстве обнаруживает триггер.
2. Сбор контекста: Модуль собирает информацию о видимой части Active Resource (генерация скриншота или запрос DOM).
3. Отправка запроса: Модуль отправляет Query-Independent Request на сервер, включая собранные данные (скриншот/DOM) и метаданные.

Этап 2: Идентификация и анализ

1. Извлечение текста и структуры: Item Identification Engine извлекает текст и данные о его внешнем виде. Если это скриншот — используется OCR. Если DOM — парсинг модели.
2. Определение типа ресурса: Система определяет тип Active Resource (например, веб-страница, чат).
3. Идентификация сущностей: Извлеченный текст сопоставляется с Item Knowledge Graph для идентификации Search Items (сущностей). Рассчитываются Match Scores.

Этап 3: Ранжирование и выбор

1. Расчет релевантности: Relevance Scoring Engine рассчитывает Relevance Score для каждой сущности. Расчет динамически учитывает:
   • Тип ресурса (например, для чатов текст снизу важнее – Claim 18).
   • Визуальное представление (больший размер, цвет, центрирование повышают оценку – Claim 6).
   • Расположение (текст в меню или рекламе может понижаться, как указано в описании патента).
2. Выбор сущностей: Item Selection Engine выбирает сущности, превышающие порог релевантности (Relevance Threshold) или Топ-N сущностей.

Этап 4: Генерация и предоставление ответа

1. Генерация карточек: Contextual Card Provider запрашивает информацию и доступные действия из Item Knowledge Graph и генерирует Contextual Cards.
2. Предоставление ответа: Карточки отправляются на устройство пользователя и отображаются поверх активного ресурса.

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

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

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

• Контентные факторы: Текст, извлеченный из Active Resource (через DOM или OCR).
• Технические факторы (Представление ресурса): DOM (предпочтительно) или Скриншот. URL ресурса.
• Структурные и Визуальные факторы (Ключевые): Данные, используемые для расчета Relevance Score:
  • Тип ресурса (например, textual conversation, веб-страница).
  • Позиция текста на экране (координаты).
  • Внешний вид (Appearance): Размер шрифта, цвет, форматирование (жирность), выравнивание.
  • Структурное расположение (из DOM): Положение в иерархии документа (например, основной контент vs. меню/реклама).
• Географические факторы: Местоположение устройства может использоваться для уточнения локальных сущностей.
• Пользовательские факторы: Идентификатор пользователя может использоваться для персонализации (например, фокус на элементах, с которыми пользователь недавно взаимодействовал, как указано в описании).

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

• Match Score (Оценка соответствия): (Упоминается в описании). Оценка уверенности в идентификации сущности при сопоставлении текста с Item Knowledge Graph.
• Relevance Score (Оценка релевантности): Основная метрика для ранжирования сущностей на экране. Отражает важность Search Item в текущем контексте. Рассчитывается как функция от визуальных и структурных факторов: $RelevanceScore = f(Position, Size, Color, ResourceType)$
  • Динамическая нормализация по типу ресурса: Правила меняются динамически. Например: Если тип = "Чат", повышать оценку для текста ближе к низу экрана (Claim 18). Если тип = "Веб-страница", приоритет может быть у текста вверху или в центре.
  • Влияние визуальных факторов: Текст, который визуально выделяется, получает повышение оценки (Claim 6).
  • Пессимизация: Текст в областях, идентифицированных как неважные (меню, реклама), может получать понижение оценки (указано в описании).
• Relevance Threshold (Порог релевантности): Пороговое значение Relevance Score, которое элемент должен превысить для отображения (Claim 7).

1. Визуальная иерархия интерпретируется как семантическая важность: Патент подтверждает, что Google использует визуальное представление контента (размер, цвет, позицию) как прямой сигнал для определения важности сущностей на странице в режиме контекстного поиска. Визуально доминирующий контент считается более релевантным.
2. Интерпретация сигналов зависит от контекста (Типа Ресурса): Система динамически меняет правила оценки важности. Патент явно указывает (Claim 18), что в чатах приоритет отдается контенту внизу (последние сообщения), тогда как на веб-страницах логика иная.
3. Анализ строго ограничен видимой областью (Viewport): Система анализирует только то, что пользователь видит на экране в момент активации функции (Claim 1). Контент за пределами видимой области игнорируется в этом процессе.
4. Анализ Рендеринга (DOM или OCR): Google может анализировать контент как путем парсинга структуры документа (DOM), что предпочтительно для точности, так и путем визуального анализа (Screenshot + OCR), что обеспечивает универсальность.
5. Критическая зависимость от Графа Знаний: Весь процесс построен вокруг идентификации Search Items и их сопоставления с Item Knowledge Graph для предоставления информации и действий.

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

Хотя патент не влияет на органическое ранжирование напрямую, он дает критическое понимание того, как Google интерпретирует визуальное представление и структуру контента.

• Соблюдение четкой визуальной иерархии (UX/Design): Используйте дизайн для выделения ключевых сущностей (название продукта, бренда, локации). То, что выглядит важным для пользователя (размер, контраст, расположение), будет считаться важным и для системы при расчете Relevance Score (Claim 6).
• Оптимизация видимой области (Viewport Optimization): Размещайте ключевые сущности в основном контенте, предпочтительно в видимой области экрана. Поскольку анализ ограничен видимым контентом (Claim 1), важно, чтобы основная тема была очевидна без прокрутки.
• Обеспечение чистого DOM и семантической верстки (Technical SEO): Обеспечьте логичную структуру DOM. Это облегчает системе извлечение контента и точное определение визуальных характеристик элементов, если она использует парсинг DOM (Claim 3), а не OCR.
• Оптимизация под Граф Знаний (Entity SEO): Убедитесь, что ваши ключевые сущности точно представлены в Графе Знаний и имеют связанные действия (телефон, адрес). Система использует Item Knowledge Graph для генерации карточек.
• Использование текста вместо изображений (Entity Clarity): Предоставляйте важную информацию в виде текста. Хотя система может использовать OCR (Claim 2), парсинг DOM более надежен.

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

• Запутанная визуальная иерархия и перегруженный дизайн: Использование макетов, где второстепенная информация (реклама, навигация) визуально доминирует над основным контентом. Это может привести к неправильному расчету Relevance Score и выбору неверных сущностей.
• Размещение ключевой информации только в "неважных" зонах: Размещение важных сущностей только в футере или боковых меню. Система может пессимизировать такие зоны (согласно описанию патента).
• Использование изображений для критически важного текста: Зависимость от OCR менее надежна и может привести к ошибкам в идентификации Search Items.

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

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

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

Сценарий: Оптимизация страницы локального бизнеса

Цель: Убедиться, что при использовании функции контекстного поиска на странице контактов система корректно идентифицирует бизнес и предлагает действия "Позвонить" и "Проложить маршрут".

1. Обеспечение данных для Графа Знаний: Убедиться, что бизнес присутствует в Google Business Profile с корректным адресом и телефоном (данные для Item Knowledge Graph).
2. Визуальное представление на сайте:
   • Разместить название бизнеса, адрес (NAP) в верхней части страницы (приоритетная позиция для веб-страницы).
   • Использовать крупный шрифт и контрастный цвет для NAP (влияет на Relevance Score согласно Claim 6).
   • Предоставить данные в текстовом формате (не картинкой) для надежного парсинга DOM (Claim 3).
3. Ожидаемый результат: Пользователь активирует функцию. Система анализирует DOM. Благодаря визуальному выделению и расположению, NAP получает высокий Relevance Score. Система идентифицирует сущность бизнеса и генерирует Contextual Card с кнопками "Call" и "Navigate".