Как Google использует On-Device AI для поиска контента внутри приложений по неполным запросам

Патент Google описывает механизм для On-Device поиска и Ассистента. Система анализирует исторические данные, чтобы понять, в каком приложении находится конкретная сущность (например, песня или контакт). Если пользователь ищет сущность, не указывая приложение, система автоматически предлагает открыть нужную программу и выполнить действие (например, через deeplink).

Описание

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

Патент решает проблему обработки неполных запросов (Incomplete Query) при поиске на устройстве (On-Device Search) или через Автоматизированного Ассистента. Проблема возникает, когда пользователь указывает, ЧТО он ищет (сущность, например, название песни или кредитную карту), но не указывает ГДЕ это искать (приложение). Система должна автоматически определить правильное приложение для выполнения запроса (например, понять, какой музыкальный плеер использовать для запроса «Включи песню X»). Это улучшает пользовательский опыт и снижает необходимость повторных попыток ввода.

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

Запатентована система для автоматического определения релевантного приложения в ответ на запрос, содержащий только сущность. Для этого используется механизм анализа исторических запросов (Query Mining System), который выявляет ассоциации между сущностями и приложениями. Эти ассоциации, вместе с инструкциями по выполнению (Fulfillment Information), хранятся локально на устройстве пользователя (On-Device Repository). При получении неполного запроса система использует эти локальные данные или вероятностную модель, чтобы сгенерировать кликабельную подсказку (Suggestion), которая запускает нужное приложение и выполняет действие.

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

Система работает в двух режимах: офлайн и онлайн.

Офлайн (Query Mining): Система анализирует большие объемы исторических явных запросов (где пользователи указывали и сущность, и приложение) с использованием MapReduce. На основе этого анализа определяются связи между сущностями (как Public Entities, так и Personal Entities) и приложениями, и генерируется Fulfillment Information (например, deeplinks).
Онлайн (На устройстве): Когда пользователь устанавливает приложение, соответствующие данные об ассоциациях загружаются в локальный On-Device Repository.
Обработка запроса: Пользователь вводит неполный запрос (только сущность). Система ищет сущность в локальном репозитории или использует Probabilistic Model для предсказания нужного приложения.
Выполнение: Отображается Suggestion. При клике выполняется Fulfillment Information, открывая нужное приложение и выполняя поиск/действие.

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

Высокая (для мобильных экосистем и Ассистента). Патент подан в 2023 году и описывает ключевые технологии для улучшения работы On-Device поиска (например, системный поиск на Android) и Google Assistant. Интеграция приложений с операционной системой и использование On-Device AI являются приоритетными направлениями развития мобильных технологий.

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

(2/10). Патент имеет минимальное значение для традиционного веб-SEO. Он не описывает алгоритмы ранжирования веб-страниц на google.com. Однако он критически важен для App Store Optimization (ASO) и App Indexing (8/10). Он детально описывает механизм, с помощью которого Google направляет трафик непосредственно внутрь установленных приложений с уровня системного поиска устройства или через Ассистента, минуя веб-поиск.

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

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

Entity (Сущность): Объект, который пользователь хочет найти или с которым хочет взаимодействовать внутри приложения (например, песня, контакт, кредитная карта, фильм, файл).
Public Entity (Публичная сущность): Сущность, которая связана с определенным приложением у значительного количества пользователей. Определяется на основе превышения порогов по частоте запросов и числу уникальных пользователей.
Personal Entity (Персональная сущность): Сущность, связанная с приложением у конкретного пользователя (специфичная для пользователя).
Fulfillment Information (Информация для выполнения): Технические данные, необходимые для выполнения действия с сущностью в приложении. Упоминаются два основных типа: deeplink (прямая ссылка на контент внутри приложения) или NLU intent (намерение для Автоматизированного Ассистента).
Historical Queries (Исторические запросы): Прошлые запросы пользователей, которые содержали как название сущности (Entity Name), так и название приложения (Application Name). Являются основой для анализа.
Incomplete Query (Неполный запрос): Текущий запрос пользователя, который идентифицирует сущность, но не указывает приложение для доступа к ней.
Query Mining System: Система (использующая архитектуру MapReduce с Mappers и Reducers) для офлайн-анализа исторических запросов и выявления ассоциаций сущность-приложение.
On-Device Repository: Локальное хранилище на устройстве пользователя, где хранятся ассоциации сущность-приложение и Fulfillment Information.
Suggestion (Подсказка): Кликабельный элемент интерфейса, предлагаемый пользователю в ответ на неполный запрос. Содержит (или связан с) Fulfillment Information.
Probabilistic Model (Вероятностная модель): ML-модель, обученная на исторических данных. Используется на устройстве для предсказания вероятности того, что искомая сущность находится в том или ином установленном приложении.

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

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

Определение связи между Сущностью и Приложением. Это основано на анализе исторических запросов (Historical Queries), которые содержали и Сущность, и Приложение.
Определение Fulfillment Information (как выполнить поиск этой Сущности в этом Приложении).
Хранение этой ассоциации (Сущность + Fulfillment Information) локально на устройстве пользователя.
Получение нового пользовательского ввода (Incomplete Query), который указывает Сущность, но не Приложение.
В ответ на этот ввод: отображение кликабельной Suggestion на основе сохраненной локальной ассоциации.
При выборе пользователем Suggestion выполняется Fulfillment Information, что приводит к поиску Сущности внутри Приложения.

Claim 3 (Зависимый от 1): Уточняет условия конфиденциальности для публичных данных.

Система подсчитывает количество исторических запросов, связывающих Сущность и Приложение. Ассоциация сохраняется, только если это количество удовлетворяет порогу конфиденциальности (privacy threshold). Это предотвращает утечку данных о редких запросах.

Claim 4 (Зависимый от 1): Уточняет условия для персональных данных.

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

Claims 5 и 6 (Зависимые от 1): Определяют форматы Fulfillment Information.

Информация для выполнения может быть представлена в виде deeplink (Claim 5) или в виде намерения естественного языка (natural language intent) с параметрами (Claim 6).

Claim 9 (Зависимый от 1): Описывает альтернативный метод определения связи с помощью ML.

Определение связи между Сущностью и Приложением может происходить путем обработки пользовательского ввода с помощью обученной вероятностной модели (trained probabilistic model). Модель генерирует вероятности того, что сущность присутствует в различных приложениях, установленных на устройстве.

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

Обучение Probabilistic Model на основе Historical Queries.
Обработка названия Сущности моделью для получения вероятности ее присутствия в Приложении.
Определение Fulfillment Information.
Если вероятность выше порога и Приложение установлено, сохранение ассоциации локально.
Получение неполного ввода и генерация Подсказки.

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

Этот патент применяется вне архитектуры стандартного веб-поиска. Он относится к On-Device Search (системный поиск на устройстве) и Automated Assistants (например, Google Assistant).

INDEXING (Офлайн-обработка)
На этом этапе система (Query Mining System) работает офлайн, анализируя Historical Queries от множества пользователей. Это процесс анализа данных для построения базы ассоциаций (Entity Logs), а не индексирование веба.

QUNDERSTANDING (On-Device)
Процесс активируется, когда пользователь вводит запрос на устройстве. Система распознает сущность в запросе (используя Named Entity Recognition) и определяет, что запрос является неполным (приложение не указано). Затем она пытается определить намерение пользователя и идентифицировать целевое приложение.

RANKING & RERANKING (On-Device)
Система ищет распознанную сущность в локальном On-Device Repository. Если сущность найдена и связана с одним или несколькими приложениями, система должна выбрать лучшее. Для этого может использоваться Probabilistic Model, которая ранжирует установленные приложения по вероятности содержания нужной сущности.

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

Офлайн: Массив Historical Queries (Явные запросы: Сущность + Приложение + User ID).
Онлайн (На устройстве): Incomplete Query пользователя. Список установленных приложений. Локальный On-Device Repository.

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

Офлайн: Entity Logs (база ассоциаций сущность-приложение и Fulfillment Information).
Онлайн (На устройстве): Кликабельная Suggestion, ведущая в приложение.

На что влияет

Конкретные типы контента: Влияет на любой контент, доступный внутри приложений: товары в e-commerce приложениях, песни и плейлисты в музыкальных сервисах, контакты, заметки, файлы, банковские карты в цифровых кошельках.
Специфические запросы: Запросы, направленные на выполнение действий (Action-oriented) или поиск конкретных именованных сущностей (Entity-seeking) на устройстве.
Конкретные ниши или тематики: Все ниши, где доминируют приложения: Музыка, Видео, E-commerce, Финансы, Социальные сети, Продуктивность.

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

Триггер активации: Получение запроса, который идентифицирует сущность, но не идентифицирует приложение для доступа к ней (Incomplete Query).
Условия применения: 1. Релевантное приложение должно быть установлено на устройстве пользователя. 2. Ассоциация между искомой сущностью и этим приложением должна существовать (либо предварительно рассчитана и сохранена локально, либо предсказана Probabilistic Model в реальном времени).
Пороговые значения: Для Public Entities необходимо превышение privacy threshold. Для Probabilistic Model требуется превышение порога вероятности.

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

Процесс А: Офлайн-анализ данных (Query Mining)

Сбор исторических данных: Идентификация и сбор явных исторических запросов (формат: Сущность + Приложение + Пользователь).
Разделение данных (Split): Разделение массива исторических запросов на несколько групп (Query Logs) для параллельной обработки.
Маппинг (Map): Параллельная обработка каждой группы соответствующим Mapper. Генерация промежуточных выходных данных (например, пар <Приложение, Сущность>).
Редукция (Reduce): Агрегация промежуточных данных с помощью Reducers. Подсчет частот ассоциаций и количества уникальных пользователей для каждой пары.
Фильтрация и Классификация: Определение Public Entities (если превышены пороги) и Personal Entities. Применение Privacy Threshold.
Генерация Entity Logs: Создание финального вывода, содержащего списки сущностей для каждого приложения и связанную с ними Fulfillment Information (Deeplinks/Intents).

Процесс Б: Обработка запроса на устройстве (On-Device)

Локальное хранение (Предварительный шаг): Загрузка релевантных Entity Logs в On-Device Repository при установке приложений.
Получение ввода: Пользователь вводит неполный запрос (только Сущность).
Сопоставление (Matching): Система проверяет On-Device Repository на наличие введенной сущности.
Разрешение неоднозначности (Опционально): Если сущность связана с несколькими установленными приложениями или для подтверждения связи, используется Probabilistic Model для определения наиболее вероятного приложения.
Извлечение Fulfillment Information: Получение инструкций (deeplink или intent) для выбранного приложения.
Генерация и Рендеринг: Создание кликабельной Suggestion и ее отображение пользователю.
Выполнение (Execution): При клике пользователя на подсказку, Fulfillment Information выполняется, запуская приложение и выполняя необходимое действие (например, поиск).

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

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

Поведенческие факторы: Historical Queries (явные запросы) являются критически важными данными для обучения системы. Они включают Entity Name, Application Name и User ID. Также учитываются данные о действиях пользователя внутри приложений (например, поиск сущности через внутренний поиск приложения).
Пользовательские факторы: User ID используется для определения Personal Entities и для расчета Privacy Threshold. Также используется список приложений, установленных на конкретном устройстве.
Контентные факторы (Имена): Имена сущностей и имена приложений, включая никнеймы, синонимы и типы приложений.

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

Частота запросов: Общее количество исторических запросов, связывающих конкретную Сущность с конкретным Приложением.
Количество уникальных пользователей: Количество разных пользователей, отправивших эти запросы.
Privacy Threshold (Порог конфиденциальности): Минимальное количество запросов и/или пользователей, необходимое для того, чтобы ассоциация считалась публичной (Public Entity).
Probabilities (Вероятности): Числовые значения, генерируемые Probabilistic Model, указывающие на вероятность (likelihood) нахождения сущности в конкретном приложении.
Методы анализа: MapReduce используется для эффективной параллельной обработки больших объемов исторических данных. Машинное обучение применяется для тренировки Probabilistic Model.

Выводы

Фокус на On-Device и Ассистенте, не на Веб-поиске: Патент описывает инфраструктуру для улучшения поиска на уровне операционной системы устройства и работы Автоматизированного Ассистента. Он не содержит практических выводов для ранжирования веб-сайтов в google.com.
Исторические данные как основа для предсказаний: Ключевая идея изобретения — использование данных о прошлых явных запросах (где пользователь указал все) для автоматического ответа на текущие неявные/неполные запросы.
Локализация вычислений (On-Device AI): Система спроектирована так, чтобы хранить данные (On-Device Repository) и выполнять вычисления (включая Probabilistic Model) локально на устройстве. Это обеспечивает высокую скорость отклика и повышает конфиденциальность.
Персонализация vs Глобальные данные: Четкое разделение на Public Entities и Personal Entities позволяет системе предлагать как глобально популярные ассоциации, так и результаты, основанные на индивидуальном поведении пользователя, соблюдая при этом пороги конфиденциальности.
Важность интеграции для приложений: Для владельцев приложений этот патент критически важен. Он показывает, что для обнаружения контента через системный поиск необходимо обеспечивать глубокую интеграцию (App Indexing, Deeplinks, Intents), чтобы система могла сгенерировать Fulfillment Information.

Практика

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

Поскольку патент не относится к веб-SEO, рекомендации касаются App Store Optimization (ASO) и App Indexing.

Полная реализация App Indexing и Deeplinks: Необходимо убедиться, что весь важный контент (сущности) внутри приложения индексируется Google и доступен через deeplinks. Это является необходимым условием для того, чтобы Google мог сгенерировать Fulfillment Information и направить пользователя к контенту.
Интеграция с Google Assistant (App Actions/Intents): Настройка и оптимизация NLU intents для выполнения ключевых действий в приложении голосом. Это напрямую влияет на способность Ассистента выбирать ваше приложение при обработке неполных голосовых запросов.
Четкое именование сущностей внутри приложения: Убедитесь, что ключевые сущности в приложении (товары, статьи, функции) имеют четкие и последовательные названия. Это повышает вероятность того, что пользователи будут использовать эти названия в своих запросах, что поможет Query Mining System установить правильные ассоциации.
Стимулирование использования поиска внутри приложения: Чем больше пользователей ищут сущности внутри вашего приложения (генерируя Historical Queries), тем точнее Google сможет связать эти сущности с вашим приложением на глобальном уровне.

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

Игнорирование App Indexing: Если контент приложения не индексируется, система не сможет связать сущности с вашим приложением. Пользователи, ищущие этот контент через системный поиск, не получат ваше приложение в качестве подсказки.
Отсутствие или некорректная работа Deeplinks: Даже если система определит ассоциацию, без рабочего deeplink она не сможет создать корректную Fulfillment Information и направить пользователя к нужному контенту внутри приложения.
Фокус только на веб-версию контента: Полагаться только на то, что пользователь найдет контент через веб-поиск. Этот патент показывает, что прямой трафик в приложение из системного поиска становится важным каналом.

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

Патент подтверждает стратегию Google по созданию бесшовной экосистемы и смещению фокуса с простого поиска информации к прямому выполнению задач (Task Completion). Для бизнеса это означает, что присутствие в традиционном веб-поиске недостаточно. Критически важной становится глубокая техническая интеграция мобильных приложений с операционной системой (Android) и Ассистентом. Этот механизм превращает системный поиск устройства в мощный канал привлечения и удержания пользователей приложений.

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

Сценарий: Автоматический выбор музыкального приложения

Действие (ASO/Разработка): Разработчик приложения «MusicApp» реализует App Indexing для всего каталога песен и настраивает deeplinks для воспроизведения.
Сбор данных (Google): Множество пользователей часто ищут через Ассистента: «Play ‘Bohemian Rhapsody’ on MusicApp». Google анализирует это и фиксирует связь между сущностью ‘Bohemian Rhapsody’ и приложением MusicApp как Public Entity.
Локальное хранение: На устройстве пользователя, где установлен MusicApp, эта ассоциация сохраняется в On-Device Repository.
Неполный запрос: Пользователь говорит Ассистенту: «Play ‘Bohemian Rhapsody'». Приложение не указано.
Действие системы: Ассистент проверяет On-Device Repository, находит связь с MusicApp и соответствующий deeplink (Fulfillment Information).
Результат: Ассистент немедленно запускает MusicApp и включает песню, не задавая уточняющих вопросов о том, какое приложение использовать.

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

Влияет ли этот патент на ранжирование моего сайта в Google Поиске?

Нет, этот патент не описывает алгоритмы ранжирования веб-страниц в google.com. Он полностью сосредоточен на поиске на уровне операционной системы устройства (On-Device Search) и работе Автоматизированного Ассистента. Его цель — определить, какое установленное приложение следует использовать для ответа на запрос пользователя.

Какое значение этот патент имеет для владельцев мобильных приложений (ASO)?

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

Что такое Fulfillment Information и почему это важно?

Fulfillment Information — это техническая инструкция, которая сообщает системе, как именно выполнить действие в приложении. Обычно это deeplink (прямая ссылка на контент) или NLU Intent (команда для Ассистента). Это важно, потому что без этой информации система может знать, что контент находится в приложении, но не сможет его открыть или запустить.

Как я могу убедиться, что Google знает о контенте внутри моего приложения?

Необходимо внедрить App Indexing (например, используя Firebase App Indexing API). Это позволяет Google сканировать контент вашего приложения и создавать ассоциации между сущностями (вашим контентом) и вашим приложением. Также важно корректно настроить deeplinks для доступа к этому контенту.

Что такое Public Entity и Personal Entity в контексте патента?

Public Entity — это глобально популярная ассоциация (например, популярный фильм и приложение Netflix), известная большому числу пользователей. Personal Entity — это пользовательская ассоциация (например, конкретная заметка в личном приложении для заметок). Система использует оба типа данных для предоставления релевантных подсказок.

Как система решает, какое приложение выбрать, если у меня установлено несколько похожих приложений?

Если сущность связана с несколькими установленными приложениями, патент описывает использование Probabilistic Model. Эта модель на основе исторических данных и контекста предсказывает, какое приложение наиболее вероятно имел в виду пользователь, и предлагает его в первую очередь.

Что такое Query Mining System и MapReduce в этом патенте?

Query Mining System — это внутренняя система Google, которая анализирует огромные объемы исторических запросов. Она использует технологию MapReduce для параллельной обработки этих данных, чтобы эффективно подсчитать частоту ассоциаций между миллионами сущностей и приложений у разных пользователей.

Почему данные хранятся локально (On-Device Repository)?

Хранение ассоциаций локально на устройстве пользователя имеет два ключевых преимущества. Во-первых, это обеспечивает очень быстрый отклик системы, так как не требуется сетевой запрос к серверам Google. Во-вторых, это повышает конфиденциальность, особенно при обработке Personal Entities.

Что такое Privacy Threshold?

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

Может ли этот механизм использоваться для голосовых запросов?

Да, он активно используется Автоматизированными Ассистентами. Когда пользователь говорит «Включи песню X», не указывая приложение, именно этот механизм помогает Ассистенту понять, какой музыкальный плеер следует запустить. В этом случае Fulfillment Information часто имеет формат NLU Intent.