Как Google встраивает поиск (ботов) напрямую в чаты и голосовые звонки с помощью триггерных слов и контекста

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

Reserved Term / Keyword (Зарезервированный термин / Триггер)

Слово или фраза, используемые для активации системы поиска внутри разговора. Эти термины выбираются так, чтобы они редко встречались в обычном разговоре (например, имя сервиса или префикс «query:»).

Passive Monitoring (Пассивное отслеживание)

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

Intended Context (Предполагаемый контекст)

Смысл запроса, определяемый на основе анализа содержания предыдущего разговора (Claims 5, 12).

ONEBOX Result / Formatted Search Result (Форматированный результат поиска)

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

Conferencing (Конференц-связь)

Функция (Search-to-Call), позволяющая автоматически подключить телефонный номер, найденный в результатах поиска, к текущему разговору (Claim 2).

API (Application Programming Interface)

Интерфейс, используемый системой для отправки запросов к стандартной поисковой системе и получения результатов без необходимости модификации самой поисковой системы.

Texting conversation (Текстовый разговор)

Обмен текстовыми сообщениями, такой как чат или SMS.

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

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

1. Система получает типизированный ввод от пользователя в текстовом разговоре.
2. Ввод анализируется на наличие reserved term.
3. Ключевой аспект: На основе reserved term выбирается поисковый сервис из множества сервисов (т.е. разные триггеры могут вызывать разные поисковые системы).
4. Определяется поисковый запрос.
5. Система автоматически отправляет запрос в выбранный сервис И одновременно отправляет исходный ввод (триггер + запрос) для отображения другим участникам.
6. Результаты принимаются и автоматически вставляются в канал связи.

Claim 2 (Независимый пункт): Описывает общий метод для электронных разговоров (включая голосовые) с акцентом на действия.

1. Система электронно отслеживает разговор.
2. Идентифицируется reserved term и запрос.
3. Выбирается поисковый сервис из множества на основе reserved term.
4. Запрос отправляется, получается ответ, который вставляется в канал связи.
5. Ключевой аспект (Действие): Система принимает команду пользователя на набор телефонного номера из ответа и автоматически подключает (conferencing) адресата номера к текущему разговору в режиме конференции.

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

1. Система включает коммуникационное устройство, электронный монитор и интерфейс к поисковому сервису.
2. Интерфейс настроен на выбор поискового сервиса.
3. Ключевой аспект (Контекст): Интерфейс анализирует контент разговора для определения предполагаемого контекста (intended context) запроса.
4. Интерфейс форматирует запрос и результат, предоставляет результат в канал связи и выполняет подключение телефонного номера (conferencing) по команде.

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

Идентификация запроса включает анализ другого контента из диалога для определения intended context. Отправка запроса включает отправку как самого запроса, так и его предполагаемого контекста в поисковый сервис.

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

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

QUNDERSTANDING – Понимание Запросов
На этом этапе система обрабатывает новый тип ввода. Запрос инициируется внутри коммуникационного приложения через reserved term. Система должна распознать триггер, извлечь запрос (включая Speech-to-Text) и, что критически важно, использовать контекст разговора (intended context, Claims 5, 12) для уточнения и форматирования запроса перед отправкой в поисковую систему.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование (Интерфейс)
Результаты поиска не отображаются в виде стандартной SERP. Система должна выбрать наиболее подходящий результат (предпочтительно ONEBOX result) и переформатировать его для линейного представления (текст или речь, Text-to-Speech) в интерфейсе разговора. Это процесс смешивания результатов поиска с потоком коммуникации и обеспечения возможности действия (conferencing).

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

• Непрерывный поток данных разговора (текст или аудио).
• Определение reserved terms.
• Контекстуальные данные: предыдущие сообщения в разговоре (для intended context), местоположение пользователя (для локального поиска).

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

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

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на запросы, требующие быстрых фактических ответов, определений, локальной информации — то есть запросы, для которых поисковая система может предоставить ONEBOX или структурированный ответ.
• Типы контента: Влияет на контент, который может быть легко суммирован и представлен линейно (текст или аудио).
• Конкретные ниши: Сильное влияние на локальный бизнес (Local Search), благодаря функции прямого звонка (conferencing) из результатов поиска.

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

• Условия применения: Применяется во время синхронной электронной коммуникации (чат, SMS, VOIP-звонок).
• Триггеры активации: Активируется исключительно при обнаружении одного из предопределенных reserved terms (ключевых слов), введенных пользователем (напечатанных или произнесенных), или нажатия специальной комбинации (например, 411 во время звонка).

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

Этап 1: Установка соединения и пассивный мониторинг

1. Устанавливается канал связи между пользователями.
2. Система начинает пассивный мониторинг потока данных. Ищутся только совпадения с reserved terms. Для конфиденциальности данные могут хешироваться и сравниваться с хешами ключевых слов, или обрабатываться локально на клиенте.

Этап 2: Активация и захват запроса

1. Обнаружение reserved term в потоке разговора.
2. Система переходит в активный режим мониторинга.
3. Система может объявить о своем присутствии участникам и запросить подтверждение.
4. Система захватывает последующий ввод (текст или аудио) как поисковый запрос.

Этап 3: Обработка и выполнение запроса

1. При необходимости голосовой запрос преобразуется в текст (Speech-to-Text).
2. Система анализирует контекст разговора для определения intended context (Claims 5, 12).
3. Выбирается целевой поисковый сервис на основе триггера (Claims 1, 2).
4. Запрос форматируется для отправки. Форматирование может включать переписывание запроса для повышения вероятности получения ONEBOX result (например, добавление префикса «definition:»).
5. Запрос (и контекст) отправляется в выбранную поисковую систему.

Этап 4: Обработка и вставка результатов

1. Система получает результаты поиска.
2. Результаты форматируются для вставки в разговор. Система извлекает ключевую информацию из ONEBOX results и преобразует её в линейный формат.
3. При необходимости текст преобразуется в речь (Text-to-Speech).
4. Отформатированный результат вставляется в канал связи как сообщение от системы/бота.

Этап 5: Последующие действия

1. Система может предложить варианты действий (например, «more», «call»).
2. Если пользователь выбирает действие «call», система инициирует подключение этого номера к текущему разговору в режиме конференции (conferencing, Claim 2).
3. Система возвращается в режим пассивного мониторинга.

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

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

Патент фокусируется на обработке коммуникационных данных и взаимодействии с поисковой системой.

• Коммуникационные данные (Контент): Поток данных разговора (текст или аудио). Основной источник для обнаружения триггеров, извлечения запросов и определения контекста (intended context).
• Пользовательские факторы:
  • Явный ввод триггера (Reserved Term) и запроса.
  • Команды управления сервисом («next», «call»).
  • Профили пользователей могут использоваться для улучшения распознавания речи.
• Контекстуальные данные:
  • Непосредственный контекст разговора используется для разрешения неоднозначности запроса (Claims 5, 12).
  • Результаты предыдущего поиска в этой же сессии могут использоваться для улучшения распознавания речи последующих запросов.
• Географические факторы: Местоположение пользователя (если доступно) используется для локализации результатов поиска.

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

Патент не детализирует метрики ранжирования, но описывает следующие механизмы обработки интерфейса:

• Распознавание триггеров: Сравнение потока данных (возможно, хешированного) с предопределенными reserved terms.
• Обработка Естественного Языка (NLP):
  • Speech-to-Text (STT) для голосовых запросов.
  • Text-to-Speech (TTS) для озвучивания результатов.
  • Анализ контекста для определения intended context.
• Форматирование запроса: Адаптация извлеченного текста под API. Может включать переписывание запроса для повышения вероятности получения ONEBOX result.
• Форматирование результатов: Извлечение данных из структурированных ответов (ONEBOX) и их линеаризация для представления в чате или голосом.

1. Поиск интегрируется в коммуникации (Conversational Search): Патент описывает фундаментальный сдвиг к поиску, встроенному в поток общения. Система функционирует как бот или ассистент внутри чата/звонка.
2. Приоритет прямых ответов (AEO): Система явно предпочитает ONEBOX results, так как их проще всего переформатировать и представить линейно (текстом или голосом). Это критически важно для оптимизации под готовые ответы и структурированные данные.
3. Контекст разговора как сигнал (Claims 5, 12): Система предназначена для анализа разговора, предшествующего запросу, чтобы понять его intended context. Запросы не обрабатываются изолированно, а как часть диалога.
4. От поиска к действию (Search-to-Action, Claim 2): Ключевая функция — возможность немедленно действовать на основе результатов, в частности, позвонить (conferencing) объекту из результатов поиска прямо из разговора. Это имеет огромное значение для локального SEO.
5. Выбор сервиса по триггеру (Claims 1, 2): Система может использовать разные поисковые вертикали или сервисы в зависимости от того, какое триггерное слово было использовано.
6. Интерфейс, а не ранжирование: Патент сосредоточен на пользовательском интерфейсе и механике доставки результатов, полагаясь на стандартные поисковые системы для ранжирования.

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

• Оптимизация под прямые ответы (AEO) и Featured Snippets: Поскольку система предпочитает сводные (ONEBOX) результаты, оптимизация контента для захвата Featured Snippets критически важна. Используйте четкие форматы вопросов и ответов, определения и краткие резюме, которые легко вставить линейно в чат или озвучить.
• Улучшение локального SEO и данных для действий (Search-to-Call): Учитывая функцию конференц-связи (Claim 2), убедитесь, что информация о локальном бизнесе (NAP) точна, актуальна в Google Business Profile и размечена (Schema.org LocalBusiness, telephone). Это облегчает системе возможность представить и набрать правильный номер прямо из разговора.
• Использование структурированных данных (Schema.org): Внедряйте микроразметку (FAQ, How-To, Product). Это помогает системе генерировать структурированные результаты, идеально подходящие для диалоговых интерфейсов.
• Оптимизация под голосовой поиск (VSO): Поскольку механизм используется в голосовых звонках, контент должен быть написан естественным языком, легко читаемым и понятным на слух (для корректного синтеза речи).
• Построение тематического авторитета (Topical Authority) для понимания контекста: Осознавая, что система анализирует контекст разговора (Claims 5, 12), создавайте всесторонний контент. Это помогает системе понять, как ваш контент связан с текущим диалогом.

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

• Сложные визуализации как основная информация: Использование сложных графиков или интерактивных элементов для передачи ключевой информации делает контент непригодным для линейной текстовой вставки или аудио воспроизведения.
• Многословный, неструктурированный контент: Длинный контент без четких резюме или ответов затрудняет системе извлечение необходимой информации для краткого ответа в диалоге.
• Скрытие или устаревание контактной информации: Если номера телефонов неактуальны или труднодоступны для парсинга, это блокирует функцию Search-to-Call и приводит к потере конверсий в локальном бизнесе.
• Игнорирование микроразметки: Отсутствие структурированных данных снижает вероятность того, что ваш контент будет выбран системой для вставки в разговор, так как его сложнее парсить и форматировать.

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

Патент подтверждает стратегию Google по развитию conversational search и повсеместному присутствию Ассистента. Для SEO это означает, что оптимизация смещается от традиционных веб-страниц к оптимизации сущностей (Entities) и информации о них. Приоритет отдается структурированной, авторитетной и легко извлекаемой информации, которую Google может использовать в любом интерфейсе. Это сигнализирует о растущей важности «Нулевой позиции» как основного механизма доставки в этих интерфейсах.

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

Сценарий: Оптимизация локального ресторана для In-Conversation Search и Search-to-Call

1. Ситуация: Два пользователя обсуждают в чате (или по телефону), где поужинать.
2. Действие пользователя: Один из них вводит/говорит: «[Триггер]: лучший итальянский ресторан рядом».
3. Действие системы: Система активируется, использует местоположение, отправляет запрос. Получает Formatted Search Result (Local Pack).
4. Вставка результата: Система вставляет/озвучивает: «Ресторан 'Roma', ул. Ленина 10, рейтинг 4.8.».
5. Конверсия (Claim 2): Пользователь говорит: «Позвони им». Система инициирует конференц-звонок с рестораном для бронирования столика.
6. Необходимые SEO-действия: Ресторан «Roma» получил этот результат благодаря оптимизированному GBP, высокому рейтингу и наличию структурированных данных LocalBusiness на сайте, что обеспечило легкое извлечение данных и возможность звонка.