Как Google оптимизирует анализ экрана (Google Lens/Assistant), запрашивая изображения только тогда, когда текста недостаточно

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

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

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

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

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

Contextual Information Server (Сервер контекстной информации)

Серверная система, которая анализирует содержимое экрана пользователя и предоставляет релевантную контекстную информацию.

Image Content (Графический контент)

Изображения или скриншоты, отображаемые как часть активного ресурса.

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

Компонент сервера, отвечающий за распознавание сущностей (search items) в тексте или изображениях (используя OCR или визуальное сходство).

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

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

Non-image Content (Неграфический контент)

Текстовое содержимое активного ресурса.

Query-independent request (Запрос, не зависящий от ввода пользователя)

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

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

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

Relevance Threshold (Порог релевантности)

Пороговое значение для Relevance Score. Если оценки ниже порога, система считает информацию недостаточной и может инициировать запрос изображения.

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

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

1. Устройство отправляет на сервер query-independent request о содержимом активного ресурса. Запрос включает non-image content (текст) и указывает на наличие image content, но НЕ включает сами изображения.
2. Устройство получает от сервера запрос на изображение (image request).
3. Критически важное условие: Этот запрос отправляется сервером только в ответ на определение двух фактов: (i) исходный запрос указывал на наличие изображения И (ii) relevance scores для сущностей, идентифицированных из non-image content, НЕ удовлетворяют relevance threshold.
4. В ответ на запрос устройство отправляет image content на сервер.
5. Устройство получает от сервера user interface element (контекстную карточку) с информацией, относящейся к изображению, и отображает его.

Claim 6 (Зависимый): Детализирует процесс инициации.

Система определяет намерение пользователя получить контекстную информацию (например, через долгое нажатие). В ответ она определяет, отображаются ли на экране изображения. Отправка query-independent request происходит после подтверждения наличия изображений.

Claim 7 (Зависимый от 6): Описывает метод определения наличия изображений.

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

Claim 8 (Зависимый от 6): Указывает на учет типа сетевого подключения.

Решение об инициации процесса может зависеть от того, использует ли устройство лимитированное сетевое подключение (metered network connection), что подчеркивает фокус патента на экономии ресурсов.

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

Этот патент не вписывается в стандартную архитектуру веб-поиска Google (Crawling, Indexing). Он описывает инфраструктуру и логику работы систем Контекстного Поиска (Contextual Search) или Ассистента, таких как Google Lens или функции анализа экрана в Google Assistant.

QUNDERSTANDING – Понимание Запросов (Интерпретация Контекста Экрана)
На этом этапе контент на экране интерпретируется как намерение пользователя. Client Contextual Module на устройстве формирует первичный query-independent request. Contextual Information Server анализирует эти данные (сначала текст, затем, возможно, изображение) для понимания контекста.

RANKING – Ранжирование (Определение Релевантных Сущностей)
Relevance Scoring Engine на сервере оценивает идентифицированные сущности. Item Selection Engine использует эти оценки и пороги (Relevance Threshold) для принятия ключевого решения: достаточно ли текстовых данных или необходимо запросить изображение.

METASEARCH – Метапоиск (Формирование Ответа)
Contextual Card Provider (упомянутый в описании) формирует ответ в виде Contextual Card, используя данные из Item Knowledge Graph.

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

• Текст с экрана (non-image content) (Этап 1).
• Индикатор наличия изображения (Этап 1).
• Изображение или скриншот с экрана (image content) (Этап 2, опционально).
• Данные об устройстве (например, тип сетевого подключения).

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

• Contextual Card с информацией о наиболее релевантных сущностях.

На что влияет

• Типы контента: Влияет на любой контент, отображаемый на экране пользователя – веб-страницы (как указано в Claim 9), приложения, электронные письма, сообщения, интерфейсы.
• Специфические запросы: Применяется исключительно для контекстных запросов (без ввода ключевых слов), инициированных пользователем через интерфейс (Google Lens, Assistant).

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

• Триггеры активации: Явное действие пользователя (долгое нажатие кнопки, жест, команда Ассистенту).
• Условия для оптимизации: Механизм может быть особенно актуален, когда устройство использует metered network connection или имеет низкий заряд батареи.
• Условие для запроса изображения (Ключевой триггер): Активируется только если Relevance Scores сущностей, найденных из текста, ниже установленного Relevance Threshold.

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

Процесс А: Обработка на стороне устройства (Client)

1. Инициация: Обнаружение действия пользователя, запрашивающего контекстную информацию.
2. Анализ экрана: Client Contextual Module анализирует Active Resource, извлекает текст и определяет наличие изображений (например, анализируя DOM или скриншот).
3. Формирование первичного запроса: Генерируется query-independent request. Он включает текст (non-image content) и флаг о наличии изображения, но не само изображение.
4. Отправка запроса: Запрос отправляется на Contextual Information Server.
5. Обработка ответа сервера: Устройство ожидает либо Contextual Card, либо Image Request.
   • Если получена Карточка: Отобразить результат. Процесс завершен.
   • Если получен Image Request: Перейти к шагу 6.
6. Передача изображения: Устройство идентифицирует отображаемые изображения (или делает скриншот, если изображений много) и отправляет их на сервер.
7. Отображение финального результата: Полученная Contextual Card отображается пользователю.

Процесс Б: Обработка на стороне сервера (Server)

1. Получение первичного запроса: Сервер получает текст и флаг наличия изображения.
2. Идентификация и Оценка (Текст): Item Identification Engine находит search items в тексте. Relevance Scoring Engine вычисляет Relevance Scores.
3. Принятие решения (Порог): Item Selection Engine сравнивает оценки с Relevance Threshold.
   • Если порог удовлетворен: Перейти к шагу 6 (Формирование ответа).
   • Если порог НЕ удовлетворен И флаг изображения = True: Перейти к шагу 4.
4. Запрос изображения: Сервер отправляет Image Request клиенту.
5. Идентификация и Оценка (Изображение): Получив изображение, сервер анализирует его (визуальное сходство, OCR), находит новые search items и оценивает их релевантность (возможно, в сочетании с текстом).
6. Формирование ответа: Contextual Card Provider генерирует Contextual Card для наиболее релевантных сущностей и отправляет ее клиенту.

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

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

• Контентные факторы: Текст, отображаемый на экране (non-image content). Первичный источник данных.
• Структурные и Визуальные факторы: В описании патента указано, что внешний вид текста (жирность, размер, цвет, выравнивание) может использоваться для расчета Relevance Score, так как это указывает на важность текста. Также упоминается, что размер области отображения изображения (display areas) может влиять на Relevance Score (больше изображение – выше оценка).
• Мультимедиа факторы: Изображения на экране (image content). Вторичный источник данных, используемый по запросу.
• Поведенческие факторы: В описании упоминается возможность использования данных о вовлеченности пользователей (engagement) с сущностями (например, из истории поисковых запросов) для расчета Relevance Score.
• Технические/Пользовательские факторы: Тип сетевого соединения (metered network connection) может влиять на активацию режима экономии трафика.

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

• Relevance Score: Оценка уверенности в релевантности сущности. Рассчитывается на основе комбинации факторов: контентных (наличие в тексте/изображении), структурных/визуальных (внешний вид текста, размер изображения) и поведенческих (общая популярность/вовлеченность).
• Relevance Threshold: Пороговое значение. Ключевой критерий для определения достаточности текстового контента и необходимости запроса изображения.
• Методы анализа: Для текста используется извлечение сущностей и сопоставление с Item Knowledge Graph. Для изображений используются методы визуального сравнения и Оптическое распознавание символов (OCR).

Патент описывает внутренние процессы Google (архитектуру клиент-серверного взаимодействия для контекстного поиска) без прямых рекомендаций для SEO-ранжирования.

1. Приоритет эффективности: Ключевая идея патента – экономия ресурсов (трафика и батареи). Google предпочитает сначала попытаться понять контекст с помощью "дешевого" текстового анализа, прежде чем запрашивать и обрабатывать "дорогие" изображения.
2. Текст как основной источник контекста: Система спроектирована так, чтобы полагаться на текст в первую очередь. Если текст на экране позволяет достичь Relevance Threshold, анализ изображения не производится.
3. Изображение как условный источник: Анализ изображения активируется только при неудаче текстового анализа. Это механизм уточнения контекста, а не основной способ его получения.
4. Анализ визуального представления: Система учитывает не только содержание, но и его визуальное представление (внешний вид текста, размер изображения) для определения важности элементов и расчета Relevance Score.
5. Контекстный поиск без запроса: Патент детализирует механизм работы query-independent requests, характерный для систем типа Google Lens/Assistant, где содержимое экрана выступает в роли неявного запроса.

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

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

• Обеспечение четкого текстового контекста: Убедитесь, что ключевые сущности (названия продуктов, брендов, локаций) присутствуют на странице в виде текста рядом с соответствующими изображениями. Это позволяет системе понять контекст на первом, экономичном этапе анализа.
• Использование структурного выделения и форматирования: Поскольку патент упоминает использование внешнего вида текста (размер, цвет, жирность) для расчета Relevance Score, используйте стандартные методы выделения (заголовки, акцентное форматирование) для ключевых сущностей на странице.
• Оптимизация изображений для распознавания (для Этапа 2): Для случаев, когда система переходит к анализу изображения, применяйте лучшие практики для Google Lens: используйте четкие, высококачественные изображения объектов, которые легко идентифицировать.
• Укрепление присутствия в Графе Знаний: Работайте над тем, чтобы ваши сущности были полно представлены в Knowledge Graph, так как он используется для идентификации сущностей и наполнения Contextual Cards.

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

• Размещение ключевой информации только в изображении: Если название товара или бренда присутствует только на картинке, система не сможет распознать его на Этапе 1. Это увеличивает зависимость от анализа изображения (Этап 2), который медленнее и менее надежен.
• Игнорирование структуры и визуальной иерархии: Предоставление контента без четкой структуры или визуальных акцентов не позволяет системе использовать эти сигналы для определения важности информации при расчете Relevance Score.

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

Патент подтверждает способность Google анализировать полностью отрендеренный контент на лету за пределами стандартного краулинга. Для долгосрочной SEO-стратегии это подчеркивает важность того, чтобы контент был понятным и доступным в любом контексте отображения. Google стремится обеспечить взаимодействие с контентом максимально эффективно, предпочитая текст изображению для быстрого понимания сути.

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

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

Пользователь видит страницу ресторана "Paul's Diner" и активирует Google Lens (Screen Search).

Вариант 1 (Плохая реализация): Название ресторана только в виде логотипа. Текст на странице: "Это номер четыре в нашем списке отличных бургерных".

1. Этап 1: Устройство отправляет текст. Сервер анализирует его, находит сущность "Бургер" с низким Relevance Score. Порог не достигнут.
2. Этап 2: Сервер запрашивает изображение (логотип). Устройство отправляет его. Сервер распознает логотип как "Paul's Diner".
3. Результат: Система возвращает карточку ресторана, но с задержкой и расходом трафика.

Вариант 2 (Хорошая реализация): Название ресторана в логотипе И продублировано в заголовке H1. Текст на странице: "Paul's Diner – номер четыре в нашем списке отличных бургерных".

1. Этап 1: Устройство отправляет текст. Сервер идентифицирует сущность "Paul's Diner" из текста (заголовка). Relevance Score высокий. Порог достигнут.
2. Этап 2: Не требуется. Изображение не запрашивается.
3. Результат: Система немедленно возвращает карточку ресторана. Результат получен быстрее, трафик сэкономлен.