Как Google использует единый Image Embedding для параллельного поиска по разным вертикалям (Web, Shopping, Local) при визуальном запросе

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

Context Data (Контекстные данные)

Информация, связанная с визуальным запросом или пользователем. Используется для определения Particular Context и выбора релевантных специализированных баз данных. Включает историю поиска/браузинга/покупок пользователя, местоположение, время, тренды, используемое приложение или классификацию объектов на изображении.

Embedding Model (Модель для создания эмбеддингов)

Машинно-обученная модель (например, нейронная сеть с энкодерами), обученная преобразовывать входное изображение в Image Embedding.

First Database / Global Database (Первая / Глобальная база данных)

Общий набор данных, связанный с множеством веб-ресурсов. Соответствует основному веб-индексу или индексу изображений Google.

Image Data (Данные изображения)

Входные данные для системы (визуальный запрос). Могут включать одно или несколько изображений, видеопоток в реальном времени (live video feed) или выделенную часть изображения.

Image Embedding (Эмбеддинг изображения)

Векторное представление (числовой вектор) изображения, сгенерированное Embedding Model. Фиксирует визуальные признаки (Image Features). Используется для поиска схожих элементов путем сравнения векторов.

Second Database / Specialized Database (Вторая / Специализированная база данных)

Набор данных, ориентированный на конкретный тип результатов, объектов, приложений или действий (покупка, навигация, бронирование). Примеры: база данных товаров (Shopping), локальная база данных (Local), база данных недвижимости (MLS), личная фотогалерея пользователя.

Text Labels (Текстовые метки)

Классификации или описания объектов на изображении. Используются в мультимодальном поиске в сочетании с Image Embedding.

Visual Tokens (Визуальные токены)

Токенизированные визуальные признаки изображения, сгенерированные блоком токенизации (Tokenizer Block). Могут использоваться для отбора кандидатов поиска или для их ранжирования.

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

Патент содержит три основных независимых пункта (Claim 1, 11, 17), описывающих разные варианты реализации системы.

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

1. Система получает визуальный запрос (Image Data).
2. Генерирует Image Embedding с помощью Embedding Model.
3. Выполняет поиск общих результатов в Первой (глобальной) базе данных, используя Image Embedding.
4. Выполняет поиск специализированных результатов во Второй (специализированной) базе данных, также используя Image Embedding.
5. Предоставляет оба набора результатов в интерфейсе.

Ядро изобретения — использование одного и того же Image Embedding для одновременного поиска в двух разных типах баз данных (общей и специализированной).

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

1. Система получает визуальный запрос и Context Data.
2. Генерирует Image Embedding.
3. Выполняет поиск в Первой (глобальной) базе данных.
4. Определяет (выбирает) специализированную базу данных, основываясь на контексте (Particular Context).
5. Выполняет поиск во Второй (выбранной специализированной) базе данных.
6. Предоставляет результаты.

Ключевое отличие от Claim 1: специализированная база данных не предопределена, а выбирается динамически на основе контекста запроса или пользователя.

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

1. Система получает визуальный запрос.
2. Генерирует Image Embedding.
3. Определяет Text Labels (классификации) для объектов на изображении.
4. Выполняет поиск в Первой базе данных, используя только Image Embedding.
5. Выполняет поиск во Второй базе данных, используя и Image Embedding, и Text Labels.
6. Предоставляет результаты.

Ключевое отличие: для разных баз данных используются разные методы поиска. Одна база использует чистый векторный поиск, другая — мультимодальный (вектор + текст).

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе система предварительно обрабатывает контент из различных баз данных (Web, Shopping, Local и т.д.). Для каждого элемента генерируются и сохраняются Search Result Embeddings. Критически важно, чтобы эти эмбеддинги находились в совместимом векторном пространстве с Image Embedding запроса.

QUNDERSTANDING – Понимание Запросов
Основное применение. При получении визуального запроса система:

1. Генерирует Image Embedding запроса в реальном времени.
2. Может генерировать Visual Tokens или Text Labels (мультимодальная обработка).
3. Собирает и анализирует Context Data.
4. Принятие решения о триггерах (Triggering): Используя контекст и/или классификацию изображения, система решает, какие специализированные базы данных (вертикали) следует активировать для поиска параллельно с общим индексом (Claim 11).

RANKING – Ранжирование (Параллельное выполнение)
Система запускает процессы поиска одновременно в выбранных базах данных (L1/Retrieval).

• Общий индекс: Поиск может выполняться только на основе Image Embedding (Claim 17).
• Специализированный индекс: Поиск может выполняться на основе Image Embedding (Claim 1) или мультимодально (Embedding + Text Labels) (Claim 17).

На этапах L2/L3 происходит ранжирование кандидатов. Патент упоминает (Claims 6-9), что Visual Tokens могут использоваться для отбора кандидатов (Retrieval), а Embedding — для их ранжирования (Ranking), или наоборот.

METASEARCH – Метапоиск и Смешивание
Результаты из разных баз данных (General Search Results и Specialized Search Results) агрегируются. Система формирует единый интерфейс (Search Results Interface). Результаты могут отображаться в отдельных панелях для каждой базы или смешиваться (intermingled).

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

• Image Data (визуальный запрос).
• Context Data (местоположение, история пользователя, метаданные).
• Индексы различных баз данных с предварительно рассчитанными эмбеддингами.

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

• Наборы результатов из каждой активированной базы данных.
• Сформированный интерфейс поисковой выдачи.

На что влияет

• Конкретные типы контента: Наибольшее влияние на контент, где визуальная составляющая является основной: товары (E-commerce), локации (Local), недвижимость (упоминается MLS database), мода.
• Специфические запросы: Запросы, направленные на идентификацию объектов, поиск похожих товаров или мест (например, запросы через Google Lens).
• Конкретные ниши или тематики: E-commerce, Local Search, Недвижимость, Путешествия.

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

• Условия работы: Алгоритм применяется при получении визуального запроса.
• Триггеры активации:
  • Поиск в общей базе данных происходит по умолчанию.
  • Поиск в специализированных базах данных активируется, если система определяет релевантный контекст (Claim 11). Например, если пользователь находится в торговом центре (контекст локации) и фотографирует обувь (контекст объекта), активируется база данных товаров.

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

Описаны три основных варианта работы системы, соответствующие независимым Claims.

Вариант А: Базовый параллельный поиск (на основе Claim 1 и FIG. 3)

1. Получение данных: Система получает Image Data.
2. Генерация эмбеддинга: Image Data обрабатывается Embedding Model для создания Image Embedding.
3. Поиск в общей базе: Система ищет в Первой (глобальной) базе данных результаты, чьи эмбеддинги имеют пороговую схожесть (threshold pairwise similarity) с эмбеддингом запроса.
4. Поиск в специализированной базе: Система одновременно ищет во Второй (предопределенной специализированной) базе данных на основе того же Image Embedding.
5. Агрегация и отображение: Результаты объединяются и предоставляются в интерфейсе.

Вариант Б: Контекстно-зависимый поиск (на основе Claim 11 и FIG. 4, 7)

1. Получение данных: Система получает Image Data и Context Data.
2. Определение контекста: Данные анализируются для установления контекста (Particular Context).
3. Генерация эмбеддинга: Создается Image Embedding запроса.
4. Поиск в общей базе: Выполняется поиск в глобальной базе данных.
5. Выбор специализированной базы: Система выбирает одну или несколько специализированных баз данных, релевантных определенному контексту.
6. Поиск в специализированной базе: Выполняется поиск в выбранных базах на основе Image Embedding.
7. Агрегация и отображение: Результаты объединяются и отображаются.

Вариант В: Мультимодальный поиск с разными стратегиями (на основе Claim 17 и FIG. 8)

1. Получение данных: Система получает Image Data.
2. Мультимодальная обработка запроса: Система генерирует Image Embedding И определяет Text Labels для объектов на изображении.
3. Поиск в первой базе (Векторный): Поиск выполняется только на основе Image Embedding.
4. Поиск во второй базе (Мультимодальный): Поиск выполняется с использованием комбинации Image Embedding и Text Labels.
5. Агрегация и отображение: Результаты объединяются и отображаются.

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

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

Система использует следующие типы данных:

• Мультимедиа факторы (Визуальные данные): Image Data является основным входом. Система анализирует Image Features (визуальные признаки объектов).
• Пользовательские факторы: Используются как часть Context Data. Включают историю поиска (user search history), историю просмотров, историю покупок, предпочтения пользователя.
• Географические факторы: Местоположение (Location Data), где был сделан снимок или находится пользователь. Критично для выбора локальных баз данных.
• Временные факторы: Время суток, сезон. Используются как часть Context Data.
• Системные данные: Информация о приложении, через которое выполняется запрос (например, камера, браузер, соцсеть).

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

Патент упоминает ключевые метрики и методы:

• Pairwise Similarity (Попарная схожесть): Основная метрика для векторного поиска. Измеряет близость между Image Embedding запроса и эмбеддингами контента в базах данных. Поиск возвращает результаты, превышающие порог (threshold pairwise similarity).
• Learned Distribution (Выученное распределение): Упоминается, что эмбеддинги могут быть ассоциированы с выученным распределением, связанным с конкретным объектом или типом объекта. Может использоваться для уточнения поиска.
• Relevance Ranking (Ранжирование по релевантности): Используется для определения позиций результатов. Может основываться на схожести эмбеддингов, релевантности Visual Tokens или Text Labels.
• Классификация: Используется для генерации Text Labels и определения контекста на основе объектов в изображении (например, классификация объекта как "дом" для активации поиска по недвижимости).

1. Универсальность Image Embeddings как основа поиска: Ключевой вывод — Google использует единое векторное представление (Image Embedding) как универсальный "ключ" для поиска визуально похожего контента в любых своих индексах (Web, Shopping, Local). Это подтверждает стратегический переход к семантическому и визуальному пониманию контента через векторы.
2. Контекст определяет Вертикаль: Система не просто ищет везде, она интеллектуально выбирает, где искать (Claim 11). Context Data (местоположение, история пользователя, тип объекта на фото) определяют, какие специализированные базы данных будут активированы.
3. Гибкость и Мультимодальность Поиска: Google может применять разные стратегии поиска для разных баз данных одновременно (Claim 17). Например, чистый векторный поиск для общего индекса и гибридный (вектор + текст/токены) для индекса товаров, что повышает точность в специализированных вертикалях.
4. Визуальный поиск становится мульти-интентным: Предоставление результатов из разных баз одновременно направлено на удовлетворение различных намерений пользователя (узнать, купить, найти рядом) в рамках одного запроса.
5. Важность индексации во всех вертикалях: Для SEO это означает, что недостаточно присутствовать только в общем индексе. Контент должен быть доступен и оптимизирован для соответствующих специализированных индексов (например, Merchant Center для товаров, GBP для локаций), чтобы участвовать в этом параллельном поиске.

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

• Оптимизация изображений для векторного поиска: Необходимо обеспечить, чтобы ключевые изображения были высокого качества, четкими и хорошо представляли объект. Это повышает вероятность генерации точного Embedding и сопоставления с запросами пользователей по визуальной схожести.
• Обеспечение присутствия в специализированных базах данных: Критически важно быть проиндексированным в релевантных вертикалях. Для E-commerce это Google Merchant Center (Shopping), для локального бизнеса — Google Business Profile (Local). Это гарантирует участие в поиске по Specialized Databases.
• Насыщение контента контекстными сигналами: Усиливайте контекст страницы, где размещено изображение. Четкая разметка (Schema.org/Product или LocalBusiness), релевантные заголовки и описания помогают системе корректно классифицировать изображение (генерировать Text Labels) и выбрать правильную вертикаль (Claim 11).
• Оптимизация под мультимодальный поиск: Поскольку система может использовать Text Labels вместе с эмбеддингами (Claim 17), важно оптимизировать текстовые атрибуты (alt-текст, описания). Это помогает в сценариях, где поиск комбинирует визуальную схожесть и текстовые фильтры.
• Создание уникального визуального контента: Использование уникальных фотографий вместо стоковых помогает выделиться в поиске, основанном на схожести эмбеддингов, и точнее соответствовать конкретным визуальным запросам.

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

• Использование стоковых или нерелевантных изображений: Использование общих изображений, плохо отражающих суть товара или услуги, снижает эффективность визуального поиска. Embeddings таких изображений будут соответствовать множеству нерелевантных запросов.
• Игнорирование специализированных вертикалей: Фокусироваться только на SEO для веб-поиска и игнорировать оптимизацию под Google Shopping или Local Search — это упущенная возможность, так как система активно ищет результаты в этих вертикалях параллельно.
• Низкое качество изображений: Размытые или темные изображения приведут к генерации неточных эмбеддингов и снизят релевантность в визуальном поиске.
• Блокировка индексации ключевых изображений: Сокрытие изображений от краулеров не позволит системе сгенерировать Embeddings и включить их в визуальный поиск.

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

Этот патент подтверждает стратегию Google на развитие поиска за пределами текста, делая визуальный ввод (через Google Lens и аналогичные технологии) равноправным типом запроса. Для SEO это означает необходимость интеграции стратегий визуального поиска (VSO) в общую стратегию продвижения. Понимание того, как Google интерпретирует изображения через Embeddings и как контекст влияет на выбор вертикалей, становится ключевой компетенцией, особенно в E-commerce и Local SEO.

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

Сценарий 1: Оптимизация карточки товара в E-commerce (Контекстный поиск)

• Задача: Увеличить трафик из визуального поиска на карточку нового дивана.
• Действия на основе патента:
  • Качественные фото: Разместить высококачественные фотографии дивана с разных ракурсов для генерации точных Embeddings.
  • Merchant Center: Загрузить фид, чтобы товар попал в Specialized Database (Shopping).
  • Микроразметка: Внедрить Schema.org/Product. Это поможет системе определить контекст (это товар) и сгенерировать Text Labels.
• Ожидаемый результат: Пользователь фотографирует похожий диван. Система генерирует Image Embedding. Благодаря контексту (объект = мебель) система активирует базу Shopping (Claim 11). Поиск находит товар по схожести Embedding. Пользователь видит в выдаче прямую ссылку на покупку данного товара.

Сценарий 2: Привлечение локального трафика для ресторана

• Задача: Привлечь посетителей, которые фотографируют фасад ресторана.
• Действия на основе патента:
  • Оптимизация GBP: Загрузить актуальные и качественные фото фасада и интерьера в Google Business Profile.
• Ожидаемый результат: Пользователь фотографирует фасад. Система анализирует Context Data (текущее местоположение пользователя рядом с рестораном) и активирует Specialized Database (Local Search) (Claim 11). Система находит совпадение по Image Embedding в профиле ресторана и показывает пользователю информацию о ресторане, маршрут и опции бронирования (Action Links).