ИИ-агент для поездок по Бенгалуру, который решает, как вам добираться
Как GoWise собирает маршруты из пешей ходьбы, автобусов, метро, авторикш и такси с помощью поиска по графу и движка оценки, а Gemini оставляет только объяснения и никогда не доверяет ему выбор маршрута.
Попросите любое навигационное приложение построить поездку, и вы получите один ответ: маршрут. Настоящие поездки в таком городе, как Бенгалуру, устроены сложнее. Самый быстрый путь не всегда самый дешёвый. Чуть более долгая поездка на метро может оказаться лучше часа в пробке. Кто-то ни за что не поедет на такси или авторикше. А план, который пять минут назад казался идеальным, сейчас может оказаться неверным.
Это несоответствие и привело к Commute Agent — ИИ-системе, которая не просто находит маршрут, а решает, как человеку стоит добираться. GoWise — приложение, которым пользуются сами пассажиры. Код открыт: https://github.com/ssharanyab/commute-agent.
Стратегии, а не маршруты
GoWise — персонализированный мультимодальный планировщик для Бенгалуру. Поездка здесь не один путь из A в B. Это сочетание ходьбы, автобусов BMTC, метро, авторикш и такси, из которого могут получаться цепочки вроде «пешком, метро, пешком», «пешком, автобус, пешком» или «авторикша, метро, пешком», где это уместно.
Никто не прописывал эти комбинации вручную. Планировщик ищет по транспортной сети и алгоритмически вычисляет осуществимые поездки.
Как разделена система
Главное проектное решение — жёсткая граница между ИИ-оркестрацией и детерминированным принятием решений. В общих чертах:
Flutter / GoWise
↓
FastAPI
↓
Google ADK Orchestrator
↓
Journey Builder
↓
Live + Historical Enrichment
↓
Decision Engine
↓
Gemini Explanation
Flutter отвечает за интерфейс для пассажира. Бэкенд выполняет процесс планирования, а оркестрацией занимается Google ADK. Вот самое важное правило: LLM никогда не выбирает маршрут.
Варианты поездок дают поиск по графу
Journey Builder работает с сетью остановок, станций, пересадок и пеших связок или подходов. Детерминированный поиск по графу превращает её в осуществимые мультимодальные поездки, у каждой из которых своё сочетание видов транспорта и пересадок.
Так что никто не спрашивает у Gemini что-нибудь вроде "как лучше доехать от Majestic до Indiranagar?". Сначала варианты генерируются алгоритмически. Это делает планирование гораздо предсказуемее и проще для проверки, чем если бы языковая модель импровизировала маршрут.
От вариантов к решению
Сгенерировать варианты — только полдела. Дальше системе нужно решить, какой вариант лучше для конкретного пассажира, и это делает детерминированный многокритериальный движок решений. Пассажир может расставить веса целей: быстрее всего, дешевле всего, меньше всего ходьбы, надёжнее всего, меньше всего пробок или баланс.
Движок оценивает варианты по этим предпочтениям и одновременно соблюдает жёсткие ограничения. Возьмём пользователя, который говорит: без такси и без авторикш. Эти слова не просто заставляют систему недолюбливать эти виды транспорта. Они становятся ограничениями, которые отбрасывают каждую поездку с ними, а оставшиеся варианты оцениваются и ранжируются.
Разделение ограничений и предпочтений оказалось одним из самых важных проектных решений.
Данные в основе
Это не концептуальное демо. Сеть опирается на реальные источники по Бенгалуру:
- фиды BMTC GTFS
- данные о сети метро BMRCL
- тарифы на авторикши, опубликованные властями
- информация о государственной политике
- исторические данные о передвижениях из Uber Movement
Поверх этого — версионированные снимки и отслеживание происхождения данных, так что неудачное обновление не может незаметно перезаписать рабочий набор данных.
Что история может сказать, а что нет
Исторические данные дают контекстные сигналы о маршруте: ожидаемое время в пути, насколько оно колеблется, надёжность, покрытие и отклонение от обычных условий. Модель намеренно позиционируется как оценщик контекста маршрута и не претендует на прогноз произвольного будущего трафика. Такая честность важна. ИИ-система должна прямо говорить, что знают её модели.
Текущие условия
История не может описать поездку, которая начинается прямо сейчас. Для участков по дорогам GoWise может подключать данные маршрутизации Google Maps, которые дают актуальные оценки с учётом пробок. Разделение чёткое: история говорит, что нормально, а живая маршрутизация — как обстоят дела в эту минуту. Движок решений рассуждает над поездками, обогащёнными и тем и другим.
Узкая роль Gemini
Gemini, вызываемый через Google ADK, — это слой объяснений. Когда детерминированный движок уже выбрал поездку, Gemini получает обоснованные факты об этом выборе и пишет понятное пассажиру объяснение. Это не даёт модели выдумывать ID маршрутов, оценки, стоимость или рассуждения, которые ничем не подкреплены. Проще говоря, решает система, а объясняет Gemini.
Персонализация как часть планирования
Представьте поездку от Majestic до Indiranagar для трёх разных пассажиров. Одному нужен самый дешёвый вариант. Другой не хочет много ходить. Третий отказывается от такси и авторикш. Транспортная сеть для всех троих одна и та же. Разный только контекст решения. Персонализация здесь — часть самого планирования, а не косметическое изменение интерфейса.
Где место Google Maps
GoWise не стремится заменить Google Maps, которые отлично ведут человека по выбранному маршруту. GoWise решает более ранний вопрос: какую стратегию передвижения вообще выбрать? Maps ведёт по маршруту, а GoWise решает и собирает, как вам ехать, а затем передаёт выбор в Maps для пошаговой навигации.
Перепланирование на ходу
Поездка не стоит на месте, и когда условия меняются достаточно сильно, первая рекомендация может перестать быть лучшей. Адаптивный слой берёт контекст текущей поездки, обновляет изменившиеся условия, заново оценивает варианты и проверяет, не должна ли победить другая стратегия. Это превращает продукт из разового планировщика маршрутов в агента, принимающего решения о передвижении.
Уроки разработки
Прикрутить LLM ещё не значит автоматически получить ИИ-агента. Большая часть тяжёлой работы оказалась обычной детерминированной инженерией:
- построить транспортный граф, которым действительно можно пользоваться
- находить мультимодальные поездки, которые по-настоящему отличаются друг от друга
- справляться с первой и последней милей
- сохранять идентичность транспортных объектов между этапами планирования
- справляться с неполными данными
- отличать неизвестные значения от нулей
- проектировать многокритериальную оценку, которая что-то значит
- правильно применять ограничения пользователя
- держать объяснения в привязке к тому, что на самом деле решено
LLM — лишь одна часть. Интеллект возникает из того, как все части работают вместе.
Что дальше
Есть куда расти: более богатые фиды транспорта в реальном времени, более детальные пешеходные сети, больше транспортных провайдеров, более сильное планирование во времени, обучаемая персонализация и более крупные наборы данных. Долгосрочная цель — не более симпатичный планировщик маршрутов. Цель — система, которая понимает пассажира, сеть, текущий контекст и компромиссы между способами передвижения.
Вопрос получше
Мы отлично научились спрашивать самый быстрый маршрут, но пассажиру часто нужно знать совсем не это. Полезнее спросить, как вам стоит добираться с учётом того, кто вы, что для вас важно и что происходит прямо сейчас. GoWise — попытка ответить именно на этот вопрос.