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

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

Benefit Estimate (Оценка выгоды)

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

Click Data / Click Log Data (Данные о кликах)

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

Cost Estimate (Оценка затрат)

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

Cost-Benefit Engine (Механизм анализа затрат и выгод)

Компонент системы, который генерирует Cost Estimate и Benefit Estimate и принимает решение о генерации временного ряда на основе их сравнения.

Level of Certainty (Уровень уверенности)

Метрика качества и надежности собранных данных временного ряда. Учитывает авторитетность источников и наличие конфликтующих данных из разных ресурсов.

System Load (Нагрузка на систему)

Показатель текущей загруженности вычислительных ресурсов поисковой системы. Является фактором при расчете Cost Estimate.

Time Series Cache (Кэш временных рядов)

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

Time Series Collection Engine (Механизм сбора временных рядов)

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

Time Series Information (Информация временных рядов)

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

Time Series Interest Engine (Механизм определения интереса к временным рядам)

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

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

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

1. Система предварительно собирает информацию временных рядов для популярных запросов (определенных по логам запросов).
2. Система получает первый запрос и определяет, что он указывает на запрос информации временных рядов.
3. Генерируется Cost Estimate (оценка затрат на включение этой информации).
4. Генерируется Benefit Estimate (оценка выгоды от включения этой информации).
5. Принимается решение: генерировать информацию, если выгода превышает затраты. Генерация может включать определение того, что нужная информация уже есть среди предварительно собранных данных (в кэше).
6. Принимается решение: НЕ генерировать информацию, если затраты превышают выгоду.

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

Определение того, что запрос указывает на потребность во временных рядах, включает один или несколько методов:

• Семантический анализ запроса на наличие индикативных терминов (например, "исторический", "со временем").
• Определение наличия временных диапазонов в запросе.
• Анализ Click Log Data для оценки реакции пользователей на предоставление временных рядов в прошлом.
• Определение того, содержат ли ресурсы, релевантные запросу, информацию временных рядов.

Claim 3 (Зависимый от 1): Детализирует факторы для расчета Benefit Estimate.

Генерация оценки выгоды включает один или несколько методов:

• Определение ожидаемого поведения пользователя на основе его характеристик (например, возраста, опыта, истории поиска).
• Определение Level of Certainty (уровня уверенности) в данных временного ряда.
• Анализ Click Log Data по прошлым результатам, где предоставлялись временные ряды.

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

Метод явно указывает, что генерация Cost Estimate включает определение расчетного количества времени обработки (estimated amount of processing time) для сбора релевантной информации временных рядов.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе Time Series Collection Engine может предварительно анализировать ресурсы (как указано в Claim 7). Система определяет, содержит ли индексируемый ресурс информацию временных рядов, извлекает ее и может сохранять в Time Series Cache, ассоциируя с ресурсом.

QUNDERSTANDING – Понимание Запросов
Включает два аспекта:

1. Офлайн: Анализ логов запросов для выявления популярных запросов, требующих временных рядов (Claim 1). Для них информация собирается заранее (pre-computation).
2. Онлайн: Time Series Interest Engine анализирует входящий запрос на наличие признаков интереса к временным рядам (Claim 2).

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
Основное применение патента происходит на этапе формирования выдачи.

1. Принятие решения: Cost-Benefit Engine активируется, если обнаружен интерес к временным рядам. Он рассчитывает Cost Estimate и Benefit Estimate.
2. Генерация функции: Если выгода превышает затраты, система генерирует блок с временным рядом (используя кэш или собирая данные на лету с помощью Time Series Collection Engine).
3. Смешивание: Сгенерированный блок интегрируется в поисковую выдачу (SERP) вместе с другими результатами.

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

• Запрос пользователя.
• Данные о нагрузке системы (System Load), задержках, сетевых ресурсах.
• Статус Time Series Cache.
• Click Log Data (история взаимодействия с подобными функциями).
• Характеристики пользователя (если известны).
• Индексированные ресурсы (для извлечения данных).

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

• Решение о генерации/не генерации временного ряда.
• Сгенерированная информация временного ряда (в виде графика или таблицы), интегрированная в SERP.

На что влияет

• Специфические запросы: Наибольшее влияние оказывается на информационные запросы, связанные с данными, изменяющимися во времени (например, [население Франции], [цена биткоина], [минимальная зарплата в Мэн]).
• Конкретные ниши или тематики: Финансы, экономика, демография, статистика, погода и другие ниши, богатые статистическими данными.
• Форматы контента: Влияет на вероятность показа расширенных блоков (SERP features) в виде графиков и таблиц данных.

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

Алгоритм применяется при выполнении следующих условий:

• Триггер активации: Когда Time Series Interest Engine определяет, что запрос, вероятно, выиграет от предоставления информации временных рядов (на основе семантики, дат или анализа ресурсов).
• Условие выполнения: Только если рассчитанный Benefit Estimate превышает Cost Estimate (или превышает его на определенный пороговый уровень).
• Особые случаи (Prompt): В патенте упоминается (Claim 5), что система может показать пользователю подсказку (Prompt), спрашивая, хочет ли он увидеть график, вместо автоматической генерации. Это может происходить, если разница между выгодой и затратами находится в определенном диапазоне (неопределенность).

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

Процесс А: Обработка запроса в реальном времени

1. Получение запроса: Система получает запрос от пользователя.
2. Определение интереса: Time Series Interest Engine анализирует запрос на наличие индикаторов интереса к временным рядам.
   • Если НЕТ: Стандартная обработка запроса.
   • Если ДА: Переход к шагу 3.
3. Генерация оценки затрат (Cost Estimate): Cost-Benefit Engine рассчитывает затраты. Проверяется наличие данных в Time Series Cache. Оценивается текущий System Load, ожидаемое время обработки, задержка и нагрузка на сеть.
4. Генерация оценки выгоды (Benefit Estimate): Cost-Benefit Engine рассчитывает выгоду. Анализируются Click Log Data, характеристики пользователя и прогнозируемый Level of Certainty данных, которые могут быть собраны.
5. Сравнение и принятие решения: Система сравнивает Выгоду и Затраты.
   • Если Затраты > Выгоды: Временной ряд не генерируется.
   • Если Выгода > Затраты: Переход к шагу 6.
   • (Опционально) Если неопределенность: Показать пользователю подсказку (Prompt) и ждать ответа.
6. Сбор данных: Time Series Collection Engine собирает данные. Если данных нет в кэше, они извлекаются и агрегируются из релевантных ресурсов.
7. Валидация и форматирование: Определяется финальный Level of Certainty. Система выбирает формат отображения (график или таблица).
8. Предоставление результатов: Информация временного ряда предоставляется пользователю вместе с результатами поиска.

Процесс Б: Офлайн-обработка (Pre-computation)

1. Анализ логов: Система анализирует журналы запросов.
2. Идентификация популярных запросов: Выявляются популярные запросы, указывающие на интерес к временным рядам (Claim 1).
3. Сбор и кэширование: Для этих запросов Time Series Collection Engine заранее собирает данные и сохраняет их в Time Series Cache.

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

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

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

Данные для оценки Затрат (Cost Estimate):

• Технические факторы (Системные метрики): Текущая нагрузка на систему (System Load), нагрузка на сеть (network resource load), метрики задержки (latency). Также упоминаются стоимость хранения (storage device cost) и стоимость экранного пространства (cost of screen space).
• Статус кэша: Наличие или отсутствие предварительно собранных данных в Time Series Cache.
• Сложность парсинга: Оценка времени, необходимого для извлечения данных из ресурсов (processing time).

Данные для оценки Выгоды (Benefit Estimate):

• Поведенческие факторы: Click Log Data — анализируется прошлая вовлеченность пользователей (клики, время просмотра) при показе временных рядов по этому или похожим запросам.
• Пользовательские факторы: Характеристики пользователя (возраст, опыт, история поиска), которые могут указывать на повышенный или пониженный интерес к данным временных рядов.
• Факторы качества данных: Оценка авторитетности источников и согласованности данных для расчета Level of Certainty. Также учитывается общее количество точек в ряду.

Данные для генерации временного ряда:

• Контентные факторы: Текст и структурированные данные (таблицы) из индексированных ресурсов, из которых извлекаются точки данных и временные метки.

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

• Cost Estimate: Агрегированная метрика затрат. Рассчитывается на основе взвешивания факторов, таких как System Load, Latency, Processing Time и статуса кэша. Конкретные формулы в патенте не приводятся.
• Benefit Estimate: Агрегированная метрика выгоды. Рассчитывается на основе взвешивания Level of Certainty, анализа Click Log Data и характеристик пользователя. Конкретные формулы не приводятся.
• Level of Certainty: Метрика уверенности в данных. Может снижаться, если данные из разных источников конфликтуют, или повышаться, если данные получены из авторитетных источников (например, правительственных сайтов) или если разница между конфликтующими данными невелика.

1. Баланс ресурсов и UX: Google активно управляет своими вычислительными ресурсами. Сложные SERP-функции, такие как визуализация данных, генерируются не всегда, а только когда это оправдано с точки зрения затрат и ожидаемой пользы для пользователя.
2. Вовлеченность как мера выгоды: Прошлое поведение пользователей (Click Data) является ключевым фактором при определении "Выгоды". Если пользователи не взаимодействуют с определенной функцией по данному типу запросов, Google с меньшей вероятностью будет тратить ресурсы на ее генерацию.
3. Качество данных определяет показ: Level of Certainty (уверенность в качестве и точности данных) напрямую влияет на оценку выгоды. Google предпочитает не показывать данные, если не уверен в их надежности или если источники конфликтуют.
4. Стоимость извлечения имеет значение: Сложность парсинга и сбора данных (Processing Time) является ключевым компонентом "Затрат". Чем сложнее извлечь данные, тем выше стоимость и тем меньше вероятность генерации временного ряда.
5. Офлайн-обработка для скорости: Для популярных запросов Google предпочитает рассчитывать и кэшировать временные ряды заранее (офлайн), чтобы минимизировать затраты и задержки во время реального поиска.

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

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

• Снижение "Затрат" для Google (Упрощение парсинга): Структурируйте исторические данные максимально четко. Используйте чистые HTML-таблицы (<table>) для представления временных рядов. Это снижает Processing Time, необходимый для извлечения данных, тем самым уменьшая Cost Estimate для Google.
• Использование микроразметки: Применяйте релевантную разметку Schema.org (например, Dataset), чтобы помочь поисковой системе идентифицировать и интерпретировать наборы данных на странице.
• Повышение "Выгоды" для Google (Увеличение Level of Certainty): Обеспечьте высокое качество и авторитетность данных. Указывайте источники, даты публикации и обновления данных. Работайте над общим авторитетом сайта (E-E-A-T) в нише, связанной с данными. Чем выше доверие к сайту, тем выше Level of Certainty.
• Согласованность данных: Убедитесь, что данные на вашем сайте согласованы и не конфликтуют с другими авторитетными источниками, так как конфликты снижают Level of Certainty.
• Ориентация на запросы с временным интентом: Создавайте контент, отвечающий на запросы, которые подразумевают интерес к истории или трендам (например, "история процентных ставок", "динамика цен на недвижимость").

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

• Представление данных в виде изображений или сложных скриптов: Размещение временных рядов внутри изображений, сложных JavaScript-визуализаций или PDF без текстового слоя значительно увеличивает "Затраты" (Processing Time) на извлечение данных, делая их использование Google маловероятным.
• Неструктурированный текст: Описание временных рядов в виде длинных абзацев текста (например, "в 2010 году было X, а в 2011 стало Y...") сложнее для парсинга, чем таблицы.
• Предоставление устаревших или ненадежных данных: Публикация данных без проверки или из сомнительных источников снижает Level of Certainty и, следовательно, "Выгоду" для Google.

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

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

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

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

Задача: Повысить вероятность того, что Google покажет график на основе данных со страницы "Население Берлина по годам".

1. Анализ текущей реализации: Данные представлены в виде списка, разбросанного по нескольким абзацам. Источники не указаны.
2. Применение Best Practices (Снижение Затрат): Все данные сводятся в единую HTML-таблицу с двумя колонками: "Год" и "Население". Добавляется разметка Dataset.
3. Применение Best Practices (Повышение Выгоды): Внизу таблицы добавляется ссылка на официальный источник данных (например, Статистическое управление Берлина). Проверяется актуальность данных. Это повышает Level of Certainty.
4. Ожидаемый результат: Google требуется меньше времени на парсинг (ниже Cost Estimate) и он больше доверяет данным (выше Benefit Estimate). Вероятность генерации графика временного ряда в SERP увеличивается.