Ein KI-Pendelagent für Bengaluru, der plant, wie Sie unterwegs sind

Fragen Sie eine beliebige Navigations-App nach einer Fahrt, und Sie bekommen eine einzige Antwort: eine Route. Echtes Pendeln in einer Stadt wie Bengaluru ist komplizierter. Der schnellste Weg ist nicht immer der günstigste. Eine etwas längere Fahrt mit der Metro kann eine Stunde im Stau schlagen. Manche Menschen steigen unter keinen Umständen in ein Taxi oder eine Autorikscha. Und der Plan, der vor fünf Minuten perfekt aussah, kann jetzt falsch sein.

Aus dieser Diskrepanz entstand Commute Agent, ein KI-System, das nicht nur eine Route findet, sondern entscheidet, wie jemand reisen sollte. GoWise ist die App, die Pendler tatsächlich nutzen. Der Code ist öffentlich unter https://github.com/ssharanyab/commute-agent.

Strategien statt Routen

GoWise ist ein personalisierter multimodaler Planer für Bengaluru. Eine Fahrt ist hier kein einzelner Weg von A nach B. Sie ist eine Mischung aus Fußwegen, BMTC-Bussen, Metro, Autorikschas und Taxis, aus der Ketten wie zu Fuß, Metro, zu Fuß oder zu Fuß, Bus, zu Fuß oder Autorikscha, Metro, zu Fuß entstehen können, wo das passt.

Niemand hat diese Kombinationen fest einprogrammiert. Der Planer durchsucht das Verkehrsnetz und ermittelt machbare Fahrten algorithmisch.

Wie das System aufgeteilt ist

Die zentrale Designentscheidung ist eine feste Trennwand zwischen KI-Orchestrierung und deterministischer Entscheidungsfindung. In groben Zügen:

Flutter / GoWise
       ↓
    FastAPI
       ↓
Google ADK Orchestrator
       ↓
  Journey Builder
       ↓
Live + Historical Enrichment
       ↓
  Decision Engine
       ↓
Gemini Explanation

Flutter liefert die Oberfläche für die Pendler. Das Backend führt den Planungsablauf aus, und Google ADK übernimmt die Orchestrierung. Die wichtigste Regel lautet: Das LLM wählt niemals die Route.

Kandidaten stammen aus der Graphsuche

Der Journey Builder arbeitet auf einem Netz aus Haltestellen, Stationen, Verbindungen und Fuß- oder Zugangswegen. Eine deterministische Graphsuche macht daraus machbare multimodale Fahrten, jede mit ihrer eigenen Mischung aus Verkehrsmitteln und Umstiegen.

Niemand fragt Gemini also etwa "Wie komme ich am besten von Majestic nach Indiranagar?". Die Kandidaten werden zuerst algorithmisch erzeugt. Dadurch wird die Planung weit berechenbarer und leichter nachprüfbar, als wenn ein Sprachmodell eine Route improvisiert.

Von Kandidaten zur Entscheidung

Optionen zu erzeugen ist nur die halbe Arbeit. Als Nächstes muss das System entscheiden, welche Option für genau diesen Pendler die beste ist, und das übernimmt eine deterministische Entscheidungs-Engine mit mehreren Zielen. Pendler können verschiedene Ziele gewichten: am schnellsten, am günstigsten, am wenigsten Fußweg, am zuverlässigsten, am wenigsten Verkehr oder ausgewogen.

Die Engine bewertet die Kandidaten nach diesen Vorlieben und setzt zugleich harte Grenzen durch. Nehmen wir einen Nutzer, der sagt: keine Taxis und keine Autorikschas. Diese Worte sorgen nicht bloß dafür, dass das System diese Verkehrsmittel weniger mag. Sie werden zu Bedingungen, die jede Fahrt mit diesen Verkehrsmitteln aussortieren, und die übrigen werden bewertet und gereiht.

Bedingungen und Vorlieben getrennt zu halten, erwies sich als eine der wichtigeren Designentscheidungen.

Die Daten darunter

Das ist keine konzeptionelle Demo. Das Netz stützt sich auf echte Quellen aus Bengaluru:

• GTFS-Feeds von BMTC
• Netzdaten der Metro von BMRCL
• Behördlich veröffentlichte Tarife für Autorikschas
• Informationen zu staatlichen Regelungen
• Historische Mobilitätsdaten aus Uber Movement

Darüber liegen versionierte Snapshots und eine Herkunftsverfolgung, damit eine fehlgeschlagene Aktualisierung nicht stillschweigend einen funktionierenden Datensatz überschreibt.

Was historische Daten sagen können und was nicht

Historische Daten liefern Kontextsignale für eine Route: erwartete Fahrzeit, wie stark diese Zeit schwankt, Zuverlässigkeit, Abdeckung und Abweichung vom Normalzustand. Das Modell ist bewusst als Schätzer des Routenkontexts angelegt und erhebt keinen Anspruch, beliebigen künftigen Verkehr vorherzusagen. Diese Ehrlichkeit zählt. Ein KI-System sollte offen sagen, was seine Modelle wissen.

Aktuelle Bedingungen

Historische Daten können keine Fahrt beschreiben, die genau jetzt beginnt. Für Straßenabschnitte kann GoWise Routing-Daten von Google Maps hinzuziehen, die aktuelle, verkehrsabhängige Schätzungen liefern. Die Aufteilung ist sauber: Die Historie sagt, was normal ist, und das Live-Routing sagt, wie es gerade aussieht. Die Entscheidungs-Engine arbeitet mit den Fahrten, die durch beides angereichert sind.

Die eng umrissene Aufgabe von Gemini

Gemini, aufgerufen über Google ADK, ist die Erklärungsschicht. Nachdem die deterministische Engine eine Fahrt gewählt hat, erhält Gemini belegte Fakten zu dieser Wahl und schreibt eine verständliche Erklärung für die Fahrgäste. Das hindert das Modell daran, Routen-IDs, Bewertungen, Kosten oder Begründungen zu erfinden, die durch nichts gedeckt sind. Einfach gesagt: Das System entscheidet, und Gemini erklärt.

Personalisierung als Teil der Planung

Stellen Sie sich die Fahrt von Majestic nach Indiranagar mit drei verschiedenen Fahrgästen vor. Einer will die günstigste Option. Ein anderer möchte nicht viel laufen. Ein dritter lehnt Taxis und Autorikschas ab. Das Verkehrsnetz bleibt für alle drei identisch. Was sich unterscheidet, ist der Entscheidungskontext. Personalisierung ist hier Teil der Planung selbst und keine kosmetische Änderung an der Oberfläche.

Wo Google Maps ins Spiel kommt

GoWise will Google Maps nicht ersetzen, das hervorragend darin ist, jemanden entlang einer gewählten Fahrt zu führen. GoWise beantwortet die vorgelagerte Frage: Welche Mobilitätsstrategie sollten Sie überhaupt wählen? Maps navigiert eine Route; GoWise entscheidet und stellt zusammen, wie Sie reisen, und übergibt die Wahl dann an Maps für die Schritt-für-Schritt-Navigation.

Neu planen unterwegs

Ein Arbeitsweg steht nicht still, und wenn sich die Bedingungen genug ändern, ist die erste Empfehlung womöglich nicht mehr die beste. Die adaptive Schicht nimmt den bestehenden Fahrtkontext, aktualisiert die veränderten Bedingungen, bewertet die Kandidaten neu und prüft, ob eine andere Strategie gewinnen sollte. Damit wird das Produkt von einem einmaligen Routenplaner zu einem Agenten, der Mobilitätsentscheidungen trifft.

Lehren aus dem Bau

Ein angeflanschtes LLM ergibt nicht automatisch einen KI-Agenten. Der Großteil der harten Arbeit war schlichtes deterministisches Engineering:

• Einen Mobilitätsgraphen bauen, mit dem sich wirklich arbeiten lässt
• Multimodale Fahrten finden, die sich tatsächlich voneinander unterscheiden
• Die erste und die letzte Meile abdecken
• Die Identität von Verkehrsobjekten zwischen den Planungsphasen erhalten
• Mit unvollständigen Daten zurechtkommen
• Unbekannte Werte von Nullen unterscheiden
• Eine Bewertung mit mehreren Zielen entwerfen, die etwas aussagt
• Die Bedingungen der Nutzer korrekt anwenden
• Erklärungen an das binden, was tatsächlich entschieden wurde

Das LLM ist ein Teil davon. Die Intelligenz entsteht daraus, wie alle Teile zusammenarbeiten.

Wie es weitergeht

Es gibt Raum zum Wachsen: reichhaltigere Echtzeit-Feeds für den Nahverkehr, feinere Fußwegnetze, mehr Mobilitätsanbieter, stärkere Planung über die Zeit, gelernte Personalisierung und größere Datensätze. Das langfristige Ziel ist kein schönerer Routenplaner. Es ist ein System, das den Pendler, das Netz, den aktuellen Kontext und die Abwägungen zwischen den Fortbewegungsarten versteht.

Die bessere Frage

Wir sind sehr gut darin geworden, nach der schnellsten Route zu fragen, aber das ist oft nicht das, was ein Pendler wissen will. Nützlicher ist die Frage, wie Sie reisen sollten, je nachdem, wer Sie sind, was Ihnen wichtig ist und was gerade passiert. GoWise ist ein Versuch, genau diese Frage zu beantworten.