Как Google позволяет сторонним сайтам загружать свои базы данных и код прямо в поисковую систему для генерации прямых ответов

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

Data Store (Хранилище данных) / Data Table

База данных, таблица (spreadsheet), XML-файл или другой структурированный набор данных, предоставляемый третьей стороной и загружаемый в поисковую систему. Используется для генерации ответов.

Entity (Сущность)

Объект или концепция (человек, место, предмет и т.д.), которая может быть распознана в запросе и связана с узлом в графе данных (Data Graph). Параметры запроса могут быть типизированы как сущности.

First Answers (Первые ответы)

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

Instructions (Инструкции)

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

Parameter (Параметр)

Переменная часть в Query Template (например, $destination в "how far is $destination"). Значение извлекается из запроса пользователя или контекста запроса (например, местоположение пользователя).

Query Template (Шаблон запроса) / Trigger

Регулярное выражение или другой шаблон, определяющий, какие запросы должны активировать Third Party Search Application.

Sandbox (Песочница)

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

Third Party Search Application (Стороннее поисковое приложение)

Набор компонентов (Query Templates, Data Store, Instructions, Parameters), загруженный третьей стороной в поисковую систему для генерации прямых ответов.

Third-party formatted natural language answer (Ответ на естественном языке, отформатированный третьей стороной)

Прямой ответ на запрос, сгенерированный сторонним приложением. Формат (например, предложение, список, виджет) контролируется третьей стороной.

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

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

1. Генерация стандартных результатов поиска (First Answers) из инвертированного индекса.
2. Определение соответствия запроса Query Template, который является регулярным выражением с переменной частью (параметром).
3. Извлечение значения параметра из той части запроса, которая соответствует переменной части шаблона.
4. Генерация Third-party formatted natural language answer путем выполнения computer-language instructions, полученных от третьей стороны. Инструкции определяют использование параметра и форматирование ответа. Выполнение происходит в sandboxed environment.
5. Предоставление сгенерированного ответа вместе со стандартными результатами.
6. Ключевое условие: Шаблон и инструкции хранятся в поисковой системе, и генерация ответа происходит без связи с сайтом третьей стороны в момент запроса.

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

1. Получение от третьей стороны Query Template (регулярное выражение) и атрибутов параметров.
2. Получение Data Store (данные и их атрибуты) от третьей стороны.
3. Получение от третьей стороны computer-language instructions для доступа к Data Store с использованием параметра и для форматирования ответа.
4. Хранение всех компонентов в sandboxed memory поисковой системы как Third Party Search Application.
5. Система выполняет приложение и генерирует ответ в ответ на запрос без связи с сайтом третьей стороны.

Claim 8 (Зависимый от 1): Механизм контроля качества на основе поведения пользователей.

Система отслеживает количество раз, когда пользователи выбирают стандартные результаты (First Answers) вместо стороннего ответа. Если это количество достигает порогового значения, Query Template отключается (приложение перестает активироваться).

Claim 9 (Зависимый от 1): Условие активации на основе авторитетности источника.

Определение того, что запрос соответствует шаблону, включает проверку источника (третьей стороны) шаблона. Запрос активирует приложение только в том случае, если сигналы для этого источника (signals for the source) достигают определенного порога.

Claim 15 (Зависимый от 11): Интеграция с графом знаний.

Если система использует graph-based data store и параметр определен как коллекция сущностей. Генерация ответа включает распознавание части запроса как сущности в графе и передачу атрибута этой сущности (например, ID) в качестве значения параметра стороннему приложению для доступа к его Data Store.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит загрузка и хранение компонентов Third Party Search Applications: Data Stores, Query Templates и Instructions. Также вычисляются и сохраняются сигналы авторитетности (signals for the source) для третьих сторон, которые используются для верификации.

QUNDERSTANDING – Понимание Запросов
На этом этапе система анализирует запрос на соответствие Query Templates (регулярным выражениям). Происходит извлечение параметров из текста запроса. Также может происходить распознавание сущностей (NER) для связывания параметров с Data Graph и разрешение контекста (например, замена местоимений на основе предыдущих запросов).

RANKING / METASEARCH – Ранжирование / Метапоиск и Смешивание
Основное применение патента. Third-Party Trigger Engine определяет необходимость активации приложения. Если триггер срабатывает, приложение выполняется в Sandbox параллельно с генерацией стандартных результатов (First Answers). Сгенерированный Third-party formatted answer затем смешивается со стандартными результатами. Патент указывает, что сторонний ответ может быть предоставлен в позиции преимущества (position of prominence).

RERANKING – Переранжирование
Применяются фильтры качества и авторитетности. Система может использовать signals for the source, чтобы решить, активировать ли приложение или как высоко ранжировать его ответ. Также система отслеживает взаимодействие пользователей с ответом для будущей оценки качества приложения (мониторинг кликов).

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

• Запрос пользователя.
• Контекст запроса (местоположение, время, история запросов).
• База данных Query Templates.
• Компоненты Third Party Search Applications (Data Stores, Instructions).
• Сигналы авторитетности источников.
• (Опционально) Data Graph для распознавания сущностей.

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

• Third-party formatted natural language answer (если приложение активировано и успешно выполнено).
• Объединенный набор результатов поиска (SERP).

На что влияет

• Специфические запросы: Наибольшее влияние на фактографические запросы, запросы, требующие актуальных данных (real-time data), и запросы, ответы на которые находятся в структурированных базах данных (например, "статус рейса AA123", "сколько калорий в X", "расписание фильма Y").
• Конкретные типы контента: Влияет на представление данных, которые лучше всего структурированы в виде таблиц или баз данных, а не неструктурированного текста.
• Конкретные ниши: Ниши с часто обновляемыми данными (финансы, спорт, погода, транспорт, электронная коммерция).

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

Алгоритм применяется при выполнении нескольких условий:

• Триггер активации: Запрос пользователя должен точно соответствовать Query Template (регулярному выражению), предоставленному третьей стороной.
• Пороги авторитетности (Claim 9): Сигналы авторитетности (signals for the source) для третьей стороны должны превышать установленный порог. В патенте также упоминается возможность проверки, появляется ли сайт третьей стороны в стандартных результатах поиска по данному запросу как условие активации.
• Успешное выполнение: Приложение должно успешно выполниться в Sandbox в пределах отведенного времени и ресурсов и вернуть непустой ответ.

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

Процесс А: Настройка приложения (Офлайн)

1. Регистрация шаблонов запросов: Третья сторона предоставляет один или несколько Query Templates (регулярных выражений).
2. Регистрация параметров: Определяются атрибуты (имя, тип) для переменных частей шаблонов. Указывается, нужно ли использовать контекст запроса (например, местоположение). Если тип параметра – сущность, указывается коллекция сущностей.
3. Регистрация данных: Третья сторона загружает Data Store (например, таблицу) и определяет его структуру (ключи доступа).
4. Регистрация инструкций: Предоставляется код (Instructions) для доступа к данным, обработки параметров и форматирования ответа на естественном языке.
5. Верификация приложения: Поисковая система проверяет приложение. Это может включать проверку потребления ресурсов в Sandbox и проверку авторитетности связанного сайта (например, появляется ли сайт в результатах поиска по тестовым запросам, соответствующим шаблону).
6. Хранение: Компоненты приложения сохраняются на серверах поисковой системы.

Процесс Б: Обработка запроса (Рантайм)

1. Получение запроса: Система получает запрос от пользователя.
2. Генерация стандартных результатов: Параллельно запускается процесс генерации First Answers из индекса.
3. Проверка триггеров: Система оценивает запрос на соответствие Query Templates. Может включать обработку естественного языка (например, замену местоимений).
4. (Условно) Проверка авторитетности: Если шаблон совпал, система может проверить, достигают ли сигналы авторитетности источника порога или присутствует ли сайт в сгенерированных стандартных результатах.
5. Извлечение параметров: Если триггер активирован, система извлекает значения параметров из запроса и контекста запроса.
6. (Опционально) Разрешение сущностей: Если параметр является сущностью, система находит соответствующую сущность в Data Graph и извлекает нужный атрибут (например, ID).
7. Выполнение приложения: Система запускает Instructions приложения в Sandbox, передавая извлеченные параметры. Приложение выполняет логику (расчет или доступ к локальному Data Store).
8. Генерация ответа: Приложение генерирует Third-party formatted natural language answer.
9. Проверка ответа: Система проверяет, был ли ответ предоставлен в течение лимита времени и не является ли он пустым.
10. Смешивание и предоставление: Сгенерированный ответ предоставляется вместе со стандартными результатами, часто на заметной позиции.

Процесс В: Мониторинг и Обновление (Офлайн)

1. Обновление данных: Система периодически получает обновления для Data Store от третьей стороны.
2. Мониторинг взаимодействий: Система отслеживает клики пользователей. Если пользователи часто игнорируют сторонний ответ и кликают на стандартные результаты (порог достигнут), приложение может быть отключено.

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

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

• Контентные факторы (Сторонние): Data Store (таблицы, базы данных), загруженные третьей стороной. Instructions (код) для форматирования ответа.
• Технические факторы: URL сайта третьей стороны, используемый для оценки авторитетности и атрибуции ответа.
• Поведенческие факторы: Журналы поиска (Search Records) используются для мониторинга взаимодействия пользователей с ответами (клики на другие результаты) для контроля качества.
• Пользовательские факторы (Контекст): Местоположение пользователя, дата и время запроса, история запросов (для разрешения контекста, например, местоимений), user-id.
• Системные данные: Data Graph (граф знаний) для разрешения параметров запроса в сущности. Инвертированный индекс для генерации First Answers и проверки присутствия сайта третьей стороны в выдаче.

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

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

• Соответствие шаблону: Оценка на основе регулярных выражений (Regex matching) между запросом и Query Template.
• Signals for the source (Сигналы для источника): Метрики авторитетности сайта третьей стороны. Используются для определения, достаточно ли авторитетен источник для активации приложения (Claim 9).
• Ranking Signal Threshold (Порог ранжирования): Минимальный ранг, который должен иметь сайт третьей стороны в стандартной выдаче по данному запросу, чтобы приложение было активировано (используется для верификации качества).
• Порог взаимодействия (Interaction Threshold): Пороговое количество раз, когда пользователи выбирают First Answers вместо стороннего ответа. При достижении порога приложение отключается (Claim 8).
• Resource Consumption Thresholds (Пороги потребления ресурсов): Максимальное время выполнения и объем ресурсов (CPU/Memory), доступные приложению в Sandbox.

1. Хостинг стороннего кода и данных: Ключевая особенность патента — Google готов размещать и выполнять сторонние данные и код (Instructions) непосредственно на своей инфраструктуре. Это позволяет генерировать ответы на запросы, требующие доступа к специфическим базам данных, без задержек на внешние API-вызовы.
2. Скорость и контроль через Sandbox: Выполнение в Sandbox критично. Это позволяет Google гарантировать скорость ответа (упоминается <20ms) и безопасность, строго контролируя ресурсы и функции, доступные стороннему приложению.
3. Автоматизированное масштабирование интеграции данных: Система позволяет тысячам третьих сторон интегрировать свои данные без необходимости ручного взаимодействия с инженерами Google, решая проблему масштабирования.
4. Жесткие требования к активации (Триггеры): Активация приложения зависит от точного соответствия Query Template (регулярному выражению). Это означает, что система нацелена на очень специфические типы запросов.
5. Авторитетность источника как условие: Google не позволит любому сайту использовать эту систему. Патент явно указывает на использование сигналов авторитетности источника (signals for the source) и проверку присутствия сайта в стандартной выдаче как необходимые условия для активации приложения (Claim 9).
6. Контроль качества через поведение пользователей: Существует четкий механизм пессимизации. Если пользователи игнорируют ответ, сгенерированный приложением, и предпочитают стандартные результаты, приложение будет отключено (Claim 8).
7. Интеграция с Графом Знаний: Система может распознавать сущности в запросах и передавать их идентификаторы в сторонние приложения (Claim 15), что позволяет связывать неструктурированные запросы со структурированными данными третьих сторон.

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

• Идентификация уникальных наборов данных: Определите, какими уникальными структурированными данными обладает ваш сайт (например, каталоги продукции с актуальными ценами, статистические данные, расписания, технические спецификации). Эта система предназначена для вывода таких данных.
• Построение авторитетности в нише: Поскольку активация приложений зависит от signals for the source и присутствия сайта в стандартной выдаче, необходимо быть признанным авторитетом по темам, связанным с вашими данными. Без сильного E-E-A-T доступ к этой системе маловероятен.
• Использование структурированных данных и API: Хотя патент описывает загрузку данных в Google, на практике это часто реализуется через структурированную разметку (Schema.org) и API (например, Google Merchant Center, Flight data feeds). Убедитесь, что ваши данные легко доступны, структурированы и актуальны. Патент подтверждает стратегическую важность предоставления данных в машиночитаемом формате.
• Оптимизация под прямые ответы и Entity Recognition: Убедитесь, что Google корректно распознает сущности, упоминаемые на вашем сайте. Интеграция с Data Graph позволяет системе связывать запросы о сущностях с вашими данными.
• Мониторинг качества и полезности данных: Предоставляемые данные должны быть максимально полезными и точными. Система Google будет отслеживать, как пользователи реагируют на ответы, и отключит источники низкокачественных или нерелевантных данных.

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

• Предоставление неточных или устаревших данных: Система предполагает высокую частоту обновления данных (high frequency changing content). Предоставление устаревших данных приведет к негативному пользовательскому опыту и отключению приложения.
• Попытки спама или манипуляций через Data Store: Попытки внедрить нерелевантный контент или спам через загружаемые данные будут неэффективны, так как система контролирует выполнение в Sandbox и отслеживает качество ответов.
• Игнорирование стандартного SEO: Нельзя полагаться только на интеграцию данных. Если сайт теряет авторитетность или перестает ранжироваться по целевым запросам в стандартной выдаче, он может потерять право на активацию Third Party Search Application.

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

Патент подтверждает стратегическое направление Google на предоставление прямых ответов и переход от роли поисковой системы к роли движка ответов (Answer Engine). Для бизнеса это означает двойную стратегию: с одной стороны, необходимо стремиться стать поставщиком данных для таких систем, чтобы сохранить видимость в SERP и укрепить бренд как авторитетный источник. С другой стороны, необходимо учитывать риск потери трафика, так как пользователи получают ответы непосредственно в выдаче. Долгосрочная стратегия должна фокусироваться на построении авторитета и предоставлении данных в структурированном, машиночитаемом виде.

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

Сценарий: Интеграция данных о статусе авиарейсов для авиакомпании

1. Цель: Предоставить пользователям актуальный статус рейса прямо в Google SERP.
2. Действия (Настройка): Авиакомпания (третья сторона) определяет Query Template: "статус рейса $flight_number". Она загружает Data Store, содержащий актуальную информацию о рейсах (время вылета, прилета, задержки, гейт). Она предоставляет Instructions: код, который принимает $flight_number, ищет его в Data Store и форматирует ответ: "Рейс $flight_number вылетает из $origin в $time, гейт $gate".
3. Проверка Google: Google убеждается, что авиакомпания авторитетна для предоставления этих данных.
4. Действия (Рантайм): Пользователь вводит "статус рейса AA123". Google распознает шаблон, извлекает "AA123".
5. Выполнение: Google запускает код авиакомпании в Sandbox. Код находит AA123 в локально загруженной базе данных.
6. Результат: Google показывает прямой ответ: "Рейс AA123 вылетает из JFK в 14:00, гейт B20" на первой позиции, без обращения к сайту авиакомпании в момент запроса.