Warum eine SQL-Datenbank für meine Frage nicht reicht — die Architektur eines Routenberaters

Die naive Lösung — und warum sie scheitert

Der erste Reflex jedes Datenmenschen: SQL. Ich habe 57 Millionen Stundenwerte in einer SQLite-Datenbank, ich habe Wochentag und Stunde als Spalten, ich kann jede beliebige Frage als SQL formulieren. Warum überhaupt etwas anderes?

Weil ich nicht in SQL fragen will. Ich will fragen: „Welche Bundesstraßen sind beliebte Motorradtouren am Wochenende?“

Für diese Frage müsste SQL erstmal definieren, was „beliebt“ heißt — vielleicht Motorradanteil über 6 Prozent? Was heißt „Wochenende“ — Samstag, Sonntag, oder auch Freitagnachmittag? Was heißt „Tour“ — eine Bundesstraße mit Kurven, eine in den Bergen, oder eine, auf der traditionell viel Motorrad fährt? Diese Übersetzung von Mensch in SQL kostet bei jeder neuen Frage Aufwand.

Schlimmer: Volltextsuche hilft auch nicht. Wenn ich „staufrei“ suche und mein Datensatz „wenig Verkehr“ enthält, findet eine klassische Suche nichts. Die Wörter sind unterschiedlich, die Bedeutung ist dieselbe. Genau hier scheitert jedes wortwörtliche System.

Stufe 1: Aus Statistik werden Sätze

Bevor irgendein Sprachmodell ins Spiel kommt, muss ich aus den Rohdaten lesbare Pattern-Texte machen. Das ist das Schwerste — und es ist nicht das, was ich erwartet hatte.

Ein Pattern-Text sieht beispielsweise so aus:

„Die B307 (Tegernsee–Sudelfeld-Achse mit Sylvensteinsee) ist am Samstag nachmittags (15–20 Uhr) ruhig befahren — durchschnittlich 284 Fahrzeuge pro Stunde. Mit 10,9 % Motorradanteil ist diese Strecke ein DE-weiter Motorrad-Klassiker — Top-Kategorie für Bikertouren. Wenig LKW-Verkehr (0,7 %) — entspannt für PKW und Motorrad. Bikertreff-Atmosphäre rund um die Mittags- und Nachmittagszeit; für Ruhesuchende eher früh morgens (05–09 Uhr).“

Solche Texte erzeuge ich für jede Kombination aus Straße, Wochentag und Stundenbucket — 10.556 Stück insgesamt. Jeder ist die textuelle Übersetzung einer statistischen Aggregation. Drei Dinge sind dabei entscheidend:

• Spitznamen rein. „B307“ ist nichtssagend, „Sylvensteinsee-Achse“ ist hingegen das, wonach Menschen suchen.
• Konzepte statt Zahlen. „Ruhig befahren“ trifft die Frage „staufrei“ — „284 Fahrzeuge pro Stunde“ tut es nicht.
• Empfehlungen einbauen. „Für Ruhesuchende eher früh morgens“ gibt dem Sprachmodell später Material zum Weiterdenken.

In meiner ersten Iteration hatte ich nüchterne Statistiksätze — und das System fand nichts. Erst als ich die Pattern-Texte semantisch angereichert habe (mit Wörtern wie „Pendlerwelle“, „Tourenstrecke“, „stauanfällig“), funktionierten die Suchen. Das war der eigentliche Aha-Moment.

Stufe 2: Sprache wird Mathematik

Damit ein Computer „staufrei“ und „wenig Verkehr“ als ähnlich erkennt, muss er beide Begriffe in dieselbe Sprache übersetzen — und die heißt Vektoren. Ein Vektor ist eine lange Liste von Zahlen, im konkreten Fall 1.024 Stück. Jeder Text bekommt einen solchen Vektor zugewiesen, und ähnliche Bedeutungen ergeben mathematisch ähnliche Vektoren.

Das Modell, das diese Übersetzung macht, heißt BGE-M3 — ein offen verfügbares Embedding-Modell, das hervorragend mit Deutsch umgeht und auf meinem Mac mini lokal läuft. Jeder meiner 10.556 Pattern-Texte wird einmal durch dieses Modell geschickt und ergibt einen Vektor. Diese Vektoren liegen in einer Vektordatenbank namens Qdrant, die ebenfalls auf dem Mac mini läuft.

Bei jeder Frage des Nutzers wird die Frage genauso durch BGE-M3 geschickt — auch sie wird zu einem 1.024-stelligen Vektor. Dann fragt Qdrant: „Welche der 10.556 gespeicherten Vektoren liegen am nächsten?“ Die Antwort sind die 30 ähnlichsten Pattern-Texte — und zwar nach Bedeutung, nicht nach Wortlaut.

Stufe 3: Hybrid-Retrieval — weil ein Algorithmus nicht reicht

Vektorsuche ist großartig bei semantischer Nähe, aber sie hat einen blinden Fleck: Eigennamen. Wenn ich „B500“ suche und ein Pattern-Text die B500 explizit erwähnt, dann ist das ein wortwörtlicher Treffer — und der wird von Vektorsuche manchmal übergangen, weil sie auf Bedeutung optimiert, nicht auf Wörter.

Deshalb läuft parallel ein zweites Verfahren: BM25 — der klassische Algorithmus aus der Textsuche, der Wortwörtlichkeit belohnt. Und ein drittes: Tag-Boost. Jeder Pattern-Text hat eine Liste struktureller Tags wie „motorrad-spitze“, „freitags-welle“ oder „schwarzwald“. Wenn die Frage eindeutig nach Motorrädern fragt, werden Patterns mit dem Motorrad-Tag bevorzugt.

Drei Ranglisten, jede mit eigener Stärke. Aus ihnen wird mit einem Verfahren namens Reciprocal Rank Fusion eine gemeinsame Reihenfolge berechnet — wer in mehreren Ranglisten weit oben steht, kommt vorne raus. Übrig bleiben die fünf besten Patterns. Das ist die Antwort des Retrievals.

Stufe 4: Aus fünf Sätzen wird eine Empfehlung

Die fünf Patterns sind nüchtern. Niemand will einen Tour-Berater, der einem fünf Statistik-Sätze hinwirft. Hier kommt das Sprachmodell ins Spiel — in meinem Fall Claude Sonnet 4.6 von Anthropic.

Es bekommt zwei Dinge: die ursprüngliche Frage und die fünf gefundenen Patterns. Plus eine kurze Anweisung, was es tun soll — etwa: „Sei freundlicher Verkehrs-Berater, bleib bei den Zahlen, gib Tageszeit-Empfehlungen“. Das Sprachmodell hat keine eigene Datenbank-Verbindung. Es kann nicht halluzinieren, weil ihm alles was es weiß als Pattern-Material vorliegt. Was es kann: die Patterns strukturieren, bewerten, vergleichen und in eine zusammenhängende Empfehlung verwandeln.

Auf die Frage „Welche Bundesstraßen sind beliebte Motorradtouren am Wochenende?“ antwortet das System dann beispielsweise:

„Drei Bundesstraßen stechen am Wochenende als besonders beliebte Motorradrouten hervor. Die B516 führt mit dem höchsten Motorradanteil: Am Sonntag mittags liegt er bei beeindruckenden 9,3 % — eine klare Bikertreff-Atmosphäre. Die B95 zeigt sonntags ebenfalls 6,3 %. Wer es absolut ruhig mag, findet auf der B53 sein Paradies: mit nur 6 bis 8 Fahrzeugen pro Stunde am Wochenende ist sie nahezu exklusiv für Zweiradfahrer. Mittags- und frühe Nachmittagsstunden sind die Hochzeit; wer Ruhe sucht, sollte zwischen 5 und 9 Uhr starten.“

Genau die Antwort, die ein Mensch will. Mit konkreten Zahlen, mit Empfehlungen, mit Bewertung. Aber gestützt auf 57 Millionen Datenpunkte, nicht auf das Bauchgefühl eines Sprachmodells.

Warum jede Stufe wirklich gebraucht wird

Versuchsweise lasse ich gerne Stufen weg, um zu prüfen ob es nicht doch einfacher geht. Bisher: nein.

Stufe weg	Was passiert
Pattern-Texte	Das Sprachmodell muss SQL formulieren — fehleranfällig und unflexibel.
Embeddings	Vokabular-Unterschiede („staufrei“ vs. „wenig Verkehr“) führen zu Treffer-Lücken.
BM25 / Tag-Boost	Eigennamen und Konzept-Tags werden verwässert, Top-Treffer wirken zufällig.
Sprachmodell	Antworten bleiben Statistik-Aufzählungen statt lesbarer Beratung.

Genau diese vier Stufen sind die Architektur. Jede einzelne reicht nicht. Erst zusammen ergibt sich ein System, das auf „Wann komme ich auf der A5 staufrei nach Hessen?“ mit einer Empfehlung antwortet, die ein Mensch ohne Vorwissen versteht.

Was als nächstes kommt

Im Teil 4 verlassen wir die Architektur und schauen uns an, was bei den Antworten herauskommt: Welche Strecken sind laut BASt-Daten Deutschlands beliebteste Motorradtouren? Wo sind die echten Geheimtipps — und wo die überlaufenen Klassiker? Mit konkreten Top-Listen, Wochentagen, Uhrzeiten — und ein paar Überraschungen.