Как Google обобщает расписания общественного транспорта для создания кратких сводок (например, "Пн-Пт, 9:00-17:00")

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

Cost Function (Функция стоимости)

Математическая функция, определяющая "стоимость" поездки в зависимости от времени. Обычно это общее время в пути, включая ожидание и штрафы (penalties) за неудобства (пересадки, ходьбу). Описывается как кусочно-линейная функция.

Daytime Interval (Дневной интервал)

Окно обслуживания, преобразованное так, чтобы его продолжительность не превышала 24 часов и оно было привязано к конкретному дню недели (например, «Понедельник, 9:00–20:00»).

Guidebook Result (Результат в виде путеводителя)

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

Guidebook Summary (Сводка путеводителя)

Конечное, обобщенное представление для пользователя (например, "Пн-Пт, 9:00-18:00"). Цель алгоритма — максимизировать общее количество часов качественного обслуживания, покрываемых этой сводкой.

Quality Criterion (Критерий качества)

Пороговое значение или условие, используемое для определения, является ли стоимость поездки достаточно низкой (т.е. поездка достаточно "хорошей").

Service Window (Окно обслуживания)

Интервал времени, в течение которого Cost Function удовлетворяет Quality Criterion.

Transit Trips (Транспортные поездки)

Конкретные экземпляры поездок по маршруту с определенным временем отправления и прибытия.

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

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

1. Генерация Cost Function на основе множества поездок из пункта А в пункт Б.
2. Идентификация множества Service Windows — интервалов, где стоимость удовлетворяет Quality Criterion.
3. Преобразование Service Windows во множество Daytime Intervals (не более 24 часов, с привязкой ко дню недели).
4. Идентификация Guidebook Summary (интервал времени и набор дней недели), которая включает только части дневных интервалов и максимизирует общее количество часов (total number of hours), включенных в эту сводку.

Claim 5 (Зависимый от 1): Уточняет метод расчета Quality Criterion.

Критерий качества определяется путем идентификации локальных максимумов Cost Function (наихудшие сценарии ожидания) и вычисления медианного значения (median value) этих максимумов. Service Windows — это интервалы, где стоимость ниже этой медианы.

Claim 9 (Зависимый от 1): Детализирует процесс оптимизации (Шаг 4 из Claim 1).

1. Для каждого случая, когда части двух или более Daytime Intervals перекрываются по времени (независимо от дня недели), вычисляется общее количество часов в этих перекрывающихся частях.
2. В качестве Guidebook Summary выбирается то перекрытие, которое содержит наибольшее общее количество часов.

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

Этот патент не применим к стандартной 6-этапной архитектуре веб-поиска (Crawling, Indexing, Query Understanding, Ranking и т.д.). Он описывает процесс обработки данных и генерации ответа в рамках специализированной вертикали (Google Maps/Transit).

Взаимодействие и Данные:

• Компоненты системы: Взаимодействует с базой данных расписаний (Transit Data) и платформой анализа транспорта (Transit Analysis Platform).
• Входные данные: Запрос пользователя на маршрут (Origin, Destination) без указания времени; Структурированные данные о расписании транспорта (Transit Data).
• Выходные данные: Guidebook Summary (краткая текстовая или визуальная сводка оптимального времени для поездки).

На что влияет

Патент влияет исключительно на способ отображения и обобщения информации об общественном транспорте в продуктах Google. Он не влияет на ранжирование веб-контента, SEO-запросы, форматы контента в вебе или ниши (YMYL, E-commerce) в органическом поиске.

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

• Условия работы алгоритма: Применяется для анализа данных общественного транспорта.
• Триггеры активации: Активируется, когда пользователь запрашивает маршрут и система генерирует Guidebook Result (т.е. когда не указано конкретное время отправления или прибытия).

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

1. Идентификация поездок: Система определяет все доступные Transit Trips между заданными пунктами за определенный период (например, неделю).
2. Генерация функции стоимости: Строится Cost Function. Для каждого момента времени вычисляется стоимость поездки (время ожидания + время поездки + штрафы). Функция получается кусочно-линейной.
3. Определение критерия качества: Устанавливается порог (Quality Criterion) для определения "хорошей" поездки. Например, вычисляется медиана всех локальных максимумов (пиков стоимости) функции.
4. Идентификация окон обслуживания: Поиск всех интервалов времени (Service Windows), когда значение Cost Function находится ниже установленного порога качества.
5. Преобразование в дневные интервалы: Service Windows, которые длятся более 24 часов или пересекают границу дней, разбиваются на Daytime Intervals и привязываются к конкретному дню недели.
6. Вычисление сводки (Максимизация): Система анализирует все Daytime Intervals. Задача состоит в том, чтобы найти комбинацию дней недели и непрерывного временного интервала (т.е. прямоугольник на графике дней и времени), который покрывает максимальное общее количество часов из Daytime Intervals.
7. Предоставление сводки: Найденная оптимальная комбинация предоставляется пользователю как Guidebook Summary.

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

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

Патент сосредоточен исключительно на обработке данных о транспорте. Факторы, используемые в веб-поиске (контентные, ссылочные, поведенческие и т.д.), здесь не применяются.

• Транспортные данные (Transit Data): Расписания (время отправления/прибытия), частота движения, остановки, стоимость проезда (fares), информация о пересадках (transfers), необходимость идти пешком (walking distance/time).

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

• Trip Cost (Стоимость поездки): Основная метрика, вычисляемая Cost Function. Агрегирует время в пути, время ожидания и штрафы (penalties). Штрафы (например, за пересадки) конвертируются во временной эквивалент и добавляются к продолжительности.
• Quality Criterion Threshold (Порог критерия качества): Значение, используемое для фильтрации стоимости. Рассчитывается на основе анализа Cost Function. Методы расчета включают:
  • Медиана локальных максимумов Cost Function (наихудшие случаи ожидания).
  • На основе глобального минимума стоимости (например, лучшее время * 1.2 или лучшее время + 30 минут).
• Total Number of Hours / Total Area (Общее количество часов / Общая площадь): Метрика, используемая для оптимизации на финальном этапе. Система стремится максимизировать это значение при выборе итоговой сводки. Рассчитывается как длительность выбранного временного интервала, умноженная на количество дней недели в сводке.

1. Отсутствие связи с SEO: Патент является чисто инфраструктурным и специфичным для вертикали Google Maps/Transit. Он не дает никаких практических выводов или инсайтов для SEO-специалистов, работающих над продвижением сайтов в органическом веб-поиске.
2. Алгоритмическое улучшение UI/UX: Изобретение направлено на улучшение пользовательского опыта путем решения сложной задачи: как представить сложные наборы временных данных (расписаний) в удобном, обобщенном виде.
3. Оценка качества через Cost Function: Ключевым элементом является Cost Function, которая позволяет численно оценить качество поездки в любой момент времени, агрегируя разнородные факторы (время, ожидание, пересадки, стоимость).
4. Динамическое определение качества: Система использует объективные и динамические методы для определения Quality Criterion (например, медиану худших случаев), что позволяет адаптироваться к разным уровням сервиса на разных маршрутах.
5. Оптимизация представления данных: Guidebook Summary генерируется с помощью алгоритма оптимизации (максимизация площади покрытия). Это позволяет найти оптимальный баланс между краткостью сводки и её полезностью (максимизация Total Number of Hours).

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

Патент описывает внутренние механизмы работы Google Maps/Transit и не содержит информации, которая может быть использована для улучшения SEO-стратегий в органическом поиске. Практических рекомендаций для SEO нет.

Для транспортных компаний: Критически важно предоставлять Google точные и актуальные структурированные данные о расписаниях (например, в формате GTFS). Точность этих данных напрямую влияет на расчет Cost Function и, как следствие, на то, как ваш сервис будет представлен в Guidebook Summary.

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

В патенте нет информации о неэффективных или опасных SEO-тактиках.

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

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

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

Практических примеров для SEO нет. Ниже приведен пример работы алгоритма в контексте транспорта.

Сценарий: Обобщение расписания автобуса

1. Данные расписания: Автобус ходит:
   • Пн-Пт: с 6:00 до 22:00 (каждые 10 минут). (16 часов)
   • Сб: с 8:00 до 20:00 (каждые 15 минут). (12 часов)
   • Вс: с 10:00 до 18:00 (каждые 20 минут). (8 часов)
2. Предположение: Система определила, что качество обслуживания приемлемо во все часы работы (Service Windows = часы работы).
3. Вычисление сводки (Максимизация): Система перебирает варианты для максимизации общего количества часов:
   • Вариант А: "Пн-Пт, 6:00-22:00". Охват: 5 дней * 16 часов = 80 часов.
   • Вариант Б: "Пн-Сб, 8:00-20:00". Охват: 6 дней * 12 часов = 72 часа.
   • Вариант В: "Ежедневно, 10:00-18:00". Охват: 7 дней * 8 часов = 56 часов.
4. Результат: Система выберет Вариант А ("Пн-Пт, 6:00-22:00") как Guidebook Summary, так как он максимизирует общее количество покрытых часов (80).